From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14048 invoked by alias); 18 Jun 2007 18:02:50 -0000 Received: (qmail 14003 invoked by uid 22791); 18 Jun 2007 18:02:48 -0000 X-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_40,DK_POLICY_SIGNSOME,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Jun 2007 18:02:44 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l5II2ej4015759; Mon, 18 Jun 2007 14:02:40 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l5II2eGe025279; Mon, 18 Jun 2007 14:02:40 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l5II2cPt026985; Mon, 18 Jun 2007 14:02:39 -0400 Message-ID: <4676C8D3.90107@redhat.com> Date: Mon, 18 Jun 2007 18:15:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Mark Wielaard CC: frysk Subject: Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} References: <466FED51.3030804@redhat.com> <1181815036.4474.23.camel@dijkstra.wildebeest.org> <467149C9.8050509@redhat.com> <1181898053.4482.28.camel@dijkstra.wildebeest.org> <4672A4C3.4060009@redhat.com> <1181935650.4482.75.camel@dijkstra.wildebeest.org> In-Reply-To: <1181935650.4482.75.camel@dijkstra.wildebeest.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q2/txt/msg00318.txt.bz2 Mark, Reading between the lines I suspect your concern here isn't so much about this specific change but about the rate of change in general? Remember Frysk as a project is relatively free flowing when it comes to its code and refactoring. We don't spend days or weeks musing over choices, or trying to design perfection. Instead we design for todays problem and let tomorrows developers re-design for their future. This gives us much flexibility while while ensuring that we are focused on real rather than hypothetical needs. Here I implemented frysk.proc.ptrace, and contrary to what you assert, it is a mess. It forced the exposure of numerous public variables in frysk.proc.Task. By instead re-aligning the sub-packages to focus on "liveness" and refactor all "liveness" variables and code out of frysk.proc and into frysk.proc.live.LiveTask (e.g., implementation of requestAddObserver blah) I can move forward and fix this problem. Can we do that? Andrew Mark Wielaard wrote: > On Fri, 2007-06-15 at 10:40 -0400, Andrew Cagney wrote: > >> Mark Wielaard wrote: >> >>> Yes, but my point is more that pre-mature refactoring at this point >>> seems not a good idea. We don't seem to have all the information yet. >>> But maybe you do have a clear picture already. I am trying to get an >>> idea what we would really gain from it at this point. Which api users do >>> you have in mind and what are they doing now through frysk.proc (or >>> directly through frysk.proc.ptrace and frsyk.proc.core) that would be >>> better modeled through the proposed properties-based package >>> abstractions? >>> >>> >> The user visible interface is frysk.proc, the rest is internal. >> > > OK, so you mean that for other parts of frysk there is just Task and > Proc to deal with. LiveTask or DeadTask is just an implementation detail > and an interface to the rest of the system? Then I am a little confused > why you want these renames. If it is all about implementation details > then the implementation names ptrace and core are much more appropriate. > > >> We could equally argue that the frysk.proc.ptrace refactoring was >> pre-mature. For that we discussed, agreed, and then I implemented; the >> result while a step forward has clear problems; perhaps I could revert >> it. This next step is along that path. >> > > No need to revert that, I do like the split between proc, proc.ptrace > and proc.core and I do like to see that separation of public interfaces > and implementation details. But I am truly not clear on the precise > refactoring you are planning to do. It seems completely unnecessary to > do a total rename for the refactoring of some methods into > frysk.proc.ptrace and frysk.proc.core for the general frysk.proc > classes. Could you give an concrete example that shows what you think > needs to be done? Having an api prototype that you are thinking of will > help review things for others. > > Thanks, > > Mark >