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