frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead}

frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead}

[Andrew Cagney]

This picks up an earlier refactoring, where the specific instances of a 
Host et.al. were moved to sub-packages.  As I noted back then, the 
sub-package names, in hindsite, weren't the best choice - reflecting 
implementation (using ptrace) rather than properties (live or dead).

The intent is to rename frysk.proc.{ptrace,corefile} -> 
frysk.proc.{live,dead}

Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead}

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

On Wed, 2007-06-13 at 09:12 -0400, Andrew Cagney wrote:
> This picks up an earlier refactoring, where the specific instances of a 
> Host et.al. were moved to sub-packages.  As I noted back then, the 
> sub-package names, in hindsite, weren't the best choice - reflecting 
> implementation (using ptrace) rather than properties (live or dead).
> 
> The intent is to rename frysk.proc.{ptrace,corefile} -> 
> frysk.proc.{live,dead}

Could you explain a bit more what kind of public interface (differences)
you see between these two packages? How would it compare with the public
frysk.proc interface for Tasks?

My feeling is that it isn't a good idea to just rename the
implementation packages ptrace, corefile to these properties you find
more appealing. You should layer the properties on top of the
implementation techniques.

There might be more implementations later like utrace and/or some
userspace /proc implementation layered on top of utrace that Chris is
working on. But we will still use ptrace for systems that don't support
utrace (yet). And with some magic we can probably give the core file
implementation some of the live properties by emulating memory, register
access and instruction stepping. So multiple implementations might map
to different instances of these properties.

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead}

[Andrew Cagney]

Mark,

Good questions.  The key difference is that a dead system has no state 
(well, ok, only one) where as a live system is statefull and 
consequently, a dead system has no reason to implement or handle 
abstract methods such as sendrecContinue et.al where as a live system 
does.  Over time we'll accumulate other "live" hosts - utrace, remote, 
and then when we've a problem, we'll with new information available, 
likely review how to better break down the "live" case.

This further refinement, and introduction of frysk.proc.live.LiveTask 
lets us finish the refactoring task I started of separating out specific 
implementations of a Host (corefile, ptrace) from the abstract model.  
For instance, those state variables in frysk.proc.Task and corresponding 
methods can be localized to frysk.proc.live.

Andrew

Mark Wielaard wrote:
> On Wed, 2007-06-13 at 09:12 -0400, Andrew Cagney wrote:
>   
>> This picks up an earlier refactoring, where the specific instances of a 
>> Host et.al. were moved to sub-packages.  As I noted back then, the 
>> sub-package names, in hindsite, weren't the best choice - reflecting 
>> implementation (using ptrace) rather than properties (live or dead).
>>
>> The intent is to rename frysk.proc.{ptrace,corefile} -> 
>> frysk.proc.{live,dead}
>>     
>
> Could you explain a bit more what kind of public interface (differences)
> you see between these two packages? How would it compare with the public
> frysk.proc interface for Tasks?
>
> My feeling is that it isn't a good idea to just rename the
> implementation packages ptrace, corefile to these properties you find
> more appealing. You should layer the properties on top of the
> implementation techniques.
>
> There might be more implementations later like utrace and/or some
> userspace /proc implementation layered on top of utrace that Chris is
> working on. But we will still use ptrace for systems that don't support
> utrace (yet). And with some magic we can probably give the core file
> implementation some of the live properties by emulating memory, register
> access and instruction stepping. So multiple implementations might map
> to different instances of these properties.
>
> Cheers,
>
> Mark
>   

Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead}

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 2163 bytes --]

Hi Andrew,

On Thu, 2007-06-14 at 09:59 -0400, Andrew Cagney wrote:
> Good questions.  The key difference is that a dead system has no state 
> (well, ok, only one) where as a live system is statefull and 
> consequently, a dead system has no reason to implement or handle 
> abstract methods such as sendrecContinue et.al where as a live system 
> does.

Yes, but those are implementation details. Not differences in public
interface are they?

>   Over time we'll accumulate other "live" hosts - utrace, remote, 
> and then when we've a problem, we'll with new information available, 
> likely review how to better break down the "live" case.

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?

> This further refinement, and introduction of frysk.proc.live.LiveTask 
> lets us finish the refactoring task I started of separating out specific 
> implementations of a Host (corefile, ptrace) from the abstract model.  
> For instance, those state variables in frysk.proc.Task and corresponding 
> methods can be localized to frysk.proc.live.

Are you sure they are "live"-properties and not just implementation
details of the ptrace-implementation? Can you give a list of variables
and methods you think aren't just ptrace implementation details, but are
properties of a LiveTask?

My main concern here is that we are abstracting cases for which there is
just one implementation at this point (or rather, just renaming the
specific implementations as if they are abstract properties) and that we
are better of waiting till we actually have multiple implementations
with shared properties to see how a properties based setup based on live
or dead looks like.

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead}

[Andrew Cagney]

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.

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.

Remember, live processes can change state and so have observers, dead 
processes do not.

Andrew

Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead}

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 1927 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead}

[Andrew Cagney]

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
>   

Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead}

[Mark Wielaard]

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

Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead}

[Andrew Cagney]

Mark Wielaard wrote:
>
>
> 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.
>   

Sorry, I don't follow, what do you think I am planning, and why do you 
think it is mixed?

Andrew

Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead}

[Mark Wielaard]

On Mon, 2007-06-18 at 19:29 -0400, Andrew Cagney wrote: 
> > 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.
> >
> Sorry I don't follow, the but.  This is good.

Try showing that it is good and what the problem it is that it solves
with some concrete examples. An simple example of existing code and what
it should/could be might make things a lot more concrete and clear for
others to see which actual problem this solves.

> On Mon, 2007-06-18 at 18:27 -0400, Andrew Cagney wrote:
> Mark Wielaard wrote:
> >
> > 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.
> >   
> Sorry, I don't follow, what do you think I am planning, and why do you 
> think it is mixed?

You don't make a clear distinction between on the one hand what exactly
you propose to move from the proc interfaces into the ptrace and core
implementation packages, and on the other hand the complete renaming of
the packages plus introduction of the new live and dead concepts.

I believe these new concepts of live and dead aren't really different
from the ptrace vs core distinction we have now. And if so then renaming
everything doesn't solve any actual problem, but just introduces random
change. But your examples don't make this clear to me.

My proposal is that you first describe the separation of interface and
implementation between proc, ptrace and core, and then if we have a good
separation between interface packages and implementation packages then
you introduce the live and dead property concepts based on that.

Cheers,

Mark

Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead}

[Andrew Cagney]

Mark Wielaard wrote:
> On Mon, 2007-06-18 at 19:29 -0400, Andrew Cagney wrote: 
>   
>>> 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.
>>>
>>>       
>> Sorry I don't follow, the but.  This is good.
>>     
>
> Try showing that it is good and what the problem it is that it solves
> with some concrete examples. An simple example of existing code and what
> it should/could be might make things a lot more concrete and clear for
> others to see which actual problem this solves.
>   

A specific example that I mentioned previously was requestAddBLAH.  live 
processes handle that, dead processes do not.

>   
>> On Mon, 2007-06-18 at 18:27 -0400, Andrew Cagney wrote:
>> Mark Wielaard wrote:
>>     
>>> 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.
>>>   
>>>       
>> Sorry, I don't follow, what do you think I am planning, and why do you 
>> think it is mixed?
>>     
>
> You don't make a clear distinction between on the one hand what exactly
> you propose to move from the proc interfaces into the ptrace and core
> implementation packages, and on the other hand the complete renaming of
> the packages plus introduction of the new live and dead concepts.
>   
Hardly, we're discussing end-goals.  There's no need to describe in 
detail intermediate steps here.

> I believe these new concepts of live and dead aren't really different
> from the ptrace vs core distinction we have now. And if so then renaming
> everything doesn't solve any actual problem, but just introduces random
> change. But your examples don't make this clear to me.
>   

Could there be confusion between a attribute such as liveness with an 
implementation choice such as ptrace.  Not unlike how Collection is the 
super object, List is a refinement, and ArrayList is a specific 
implementation choice.

> My proposal is that you first describe the separation of interface and
> implementation between proc, ptrace and core, and then if we have a good
> separation between interface packages and implementation packages then
> you introduce the live and dead property concepts based on that.
>   
And the way we do that is with the code.  If I don't like the results 
i'll fix them.

Andrew

Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead}

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 5213 bytes --]

On Tue, 2007-06-19 at 17:58 -0400, Andrew Cagney wrote:
> Mark Wielaard wrote:
> > On Mon, 2007-06-18 at 19:29 -0400, Andrew Cagney wrote: 
> >> Sorry I don't follow, the but.  This is good.
> >>     
> > Try showing that it is good and what the problem it is that it solves
> > with some concrete examples. An simple example of existing code and what
> > it should/could be might make things a lot more concrete and clear for
> > others to see which actual problem this solves.
> >   
> A specific example that I mentioned previously was requestAddBLAH.  live 
> processes handle that, dead processes do not.

Dead (although I do think that is a silly term, try using Frozen)
processes do handle that. It is just that some observers are immediately
triggered since the process is always ready and others never since the
action that the observer is waiting for will never occur. That might or
might not be something that is convenient, or something that can be
better modeled otherwise. My question really was where you see an actual
problem in the current code and give an example of how to more elegantly
solve that issue.

> > You don't make a clear distinction between on the one hand what exactly
> > you propose to move from the proc interfaces into the ptrace and core
> > implementation packages, and on the other hand the complete renaming of
> > the packages plus introduction of the new live and dead concepts.
> >   
> Hardly, we're discussing end-goals.  There's no need to describe in 
> detail intermediate steps here.

OK, what are the end-goals?

> > I believe these new concepts of live and dead aren't really different
> > from the ptrace vs core distinction we have now. And if so then renaming
> > everything doesn't solve any actual problem, but just introduces random
> > change. But your examples don't make this clear to me.
> >   
> Could there be confusion between a attribute such as liveness with an 
> implementation choice such as ptrace.  Not unlike how Collection is the 
> super object, List is a refinement, and ArrayList is a specific 
> implementation choice.

Yes, I think that is the confusion. You propose to just rename
proc.ptrace and proc.core to live and dead, while they are perfectly
good implementation choices for your concepts of live and frozen (nee
dead). Renaming things doesn't solve problems, it just moves problems
and makes things harder for others to follow. So concentrate on the
attributes you want to model first instead of randomly renaming specific
implementation files.

> > My proposal is that you first describe the separation of interface and
> > implementation between proc, ptrace and core, and then if we have a good
> > separation between interface packages and implementation packages then
> > you introduce the live and dead property concepts based on that.
> >   
> And the way we do that is with the code.  If I don't like the results 
> i'll fix them.

No. That is not how you work with a group of people on a project. You
try to explain the why of changes you do so everybody has a clear vision
of the goals, what problems it actually solves and give some examples of
actual code that illustrates your goals. Then the group as a whole can
help with the results and anticipate where the project is moving.

This long thread just started with a suggestion to move around some
package names and classes to which I said that I didn't like that, but
that I was interested in the concepts behind the idea and would like to
know a bit more about the problems you had seen with the current setup
and how your suggestion would fix some concrete problems. This isn't
about criticizing your work (although I was very unhappy that you just
moved things around while we were still discussing whether or not that
was a good idea), but about understanding what you actually want to
achieve. Which real world problems it solves and how it makes frysk a
better platform.

We have a large group of diverse people working on frysk all over the
planet. I don't have the luxury of being near you and see your
hand-waving when you explain things or use osmosis to absorb all your
knowledge. And that is true for almost every pairing of frysk hackers.
So to raise the collective awareness of the problems we have, the flaws
in our current setup that prevent us to solve some things and the
solutions we come up with, we have to try and explain things as clearly
as we can to each other. That is all I ask.

You might leave the project, someone else might join at a later time,
people move through the whole frysk codebase to improve and fix things
etc. So we need to have these discussions about what, why and how we are
solving things with frysk. That way the collective awareness of our
group of hackers grows. And more than just one individual knows the why
of the design of the different parts of frysk. So please try to share
your knowledge with others, even if that means explaining things that
are obviously clear to yourself. People do want to learn from you. And
you might actually get some nice feedback and ideas for improvements
back.

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead}

[Andrew Cagney]

Mark,


Mark Wielaard wrote:
> 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.
>
>   

Sorry I don't follow, the but.  This is good.

Andrew