From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19764 invoked by alias); 18 Jun 2007 18:56:21 -0000 Received: (qmail 19757 invoked by uid 22791); 18 Jun 2007 18:56:20 -0000 X-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO X-Spam-Check-By: sourceware.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (83.160.170.119) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Jun 2007 18:56:17 +0000 Received: from dijkstra.wildebeest.org ([192.168.1.29]) by gnu.wildebeest.org with esmtp (Exim 4.43) id 1I0MQs-00036L-3x; Mon, 18 Jun 2007 20:58:34 +0200 Subject: Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} From: Mark Wielaard To: Andrew Cagney Cc: frysk In-Reply-To: <4676C8D3.90107@redhat.com> 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> <4676C8D3.90107@redhat.com> Content-Type: text/plain Date: Mon, 18 Jun 2007 19:06:00 -0000 Message-Id: <1182192973.4534.90.camel@dijkstra.wildebeest.org> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) 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/msg00322.txt.bz2 On Mon, 2007-06-18 at 14:02 -0400, Andrew Cagney wrote: > 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? No, more the rate of changes I don't really understand the why of. I like to have more design discussion on the list so we all know why and what changes are proposed and being worked on. > 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. That is good. But what I am missing is the actual problem statement. What exactly isn't possible today and what is possible tomorrow after such a change is made. My concern is that some of this is just refactoring for refactorings sake. That is why I ask the why and what questions. > 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. I don't believe I assert that at all. The split of the proc interface and the proc.ptrace and proc.core implementation refactoring is not complete though if it exposes things in the interfaces that should be in the implementation packages. > 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? We can certainly refactor the proc interfaces and implementation subpackages. But you are mixing two things in your plan. The renaming of existing packages and classes (which I don't see any benefit of) and exposing flaws in of the refactoring of the proc, proc.ptrace and proc.core code because there is a clear separation between interface and implementation. Cheers, Mark