Re: frysk-core/frysk/proc ChangeLog IsaIA32.java I ...

Re: frysk-core/frysk/proc ChangeLog IsaIA32.java I ...

[Mark Wielaard]

Andrew,

On Tue, 2007-06-26 at 22:12 +0000, cagney@sourceware.org wrote:
> 	2007-06-26  Andrew Cagney  <cagney@redhat.com>
> 	
> 	* Manager.java: Update, package frysk.proc.ptrace renamed to
> 	frysk.proc.live.
> 	* IsaX8664.java: Ditto.
> 	* IsaIA32.java: Ditto.
> 	* IsaPowerPC.java: Ditto.
> 	
> 	Index: frysk-core/frysk/proc/live/ChangeLog
> 	2007-06-18  Andrew Cagney  <cagney@redhat.com>
> 	
> 	* Rename package frysk.proc.ptrace to frysk.proc.live.

You cannot just rename things when you have been told that doing so
would be a bad thing. If there is a discussion questioning your proposed
actions don't just ignore the questions of why you want to make a
certain change and just go ahead and do it anyway. If you continue doing
so you might risk loosing commit privileges.

I was pretty mad when I saw this commit and just wanted to silently
revert it without telling you why, since you had clearly not listened
when you were asked to not to do this and you knew it would cause
trouble. But the damage is done now already and I'll just update my
patches instead of making cvs even more of a mess than it already is
with this change. The precise naming of a package doesn't matter that
much in the grand scheme.

Please act like a team member in the future and respect the group of
people you work together with on this project. You will have to learn to
better communicate about the why of your actions, especially if people
point out in advance that just doing things the way you personally like
isn't in the best interest of the project as a whole and will cause
trouble and more work for others.

Thanks,

Mark

Re: frysk-core/frysk/proc ChangeLog IsaIA32.java I ...

[Andrew Cagney]

Mark,

These changes affect three people directly: me, you and phil.  Phil and 
I want this; and for you, it is cosmetic. Why are you so resistant to 
what you yourself recognize has no effect on the code you work on?

Andrew

Re: frysk-core/frysk/proc ChangeLog IsaIA32.java I ...

[Phil Muldoon]

Andrew Cagney wrote:
> Mark,
>
> These changes affect three people directly: me, you and phil.  Phil 
> and I want this; and for you, it is cosmetic. Why are you so resistant 
> to what you yourself recognize has no effect on the code you work on?

I've been caught up in deliverables so I have not been really paying 
attention to this thread, perhaps as much as I should have. Apologies 
for that. I think there are several issues caught up here, and they are 
getting confused as one.

First I do not care about what the name is. It's not important to me. 
dead and live, proc and corefile, pink or blue, vanilla or strawberry it 
is something that is fluid and can change now and in the future. That 
can be taken as complicit agreement of disagreement. I just don't have 
strong feelings here.

However, I think the larger picture here, and I think is lost in the 
"change over discussion" trend, is that the current proc model is pretty 
faulty in some of its assumptions and really needs refactoring. For the 
last six months I've been working on tweaking this and that so that 
Proc/Task/Host is not live process specific. So in the longer to mid 
term there really needs to be a rethink of that model.. Right now,  
Andrew, Mark and myself are the main people twiddling the bits here, I 
think we all have our own strong ideas on how this should work. I think 
this thread has spawned because these ideas are not reconciled. In the 
debate of this thread, and myself just ignoring it for various reasons, 
I think there is a plain and clear need for a roundtable I'd hazard a 
guess we agree more than we disagree, and it just needs to be thrashed 
out. However we all have our deadlines, and for one reason or another 
this design discussion has slipped through the cracks, and people have 
moved forward with their ideas. I'm also guilty of not discussing a lot 
of my changes.

We should table a discussion on the whys and the why nots soon.

Regards

Phil

Re: frysk-core/frysk/proc ChangeLog IsaIA32.java I ...

[Mark Wielaard]

Hi Phil,

On Wed, 2007-06-27 at 09:56 -0500, Phil Muldoon wrote:
> However, I think the larger picture here, and I think is lost in the 
> "change over discussion" trend, is that the current proc model is pretty 
> faulty in some of its assumptions and really needs refactoring. For the 
> last six months I've been working on tweaking this and that so that 
> Proc/Task/Host is not live process specific. So in the longer to mid 
> term there really needs to be a rethink of that model.. 

Yes I think you hit the actual issue. I agree.

And I think that was why I was so disappointed about the process. A
design discussion is good and I thought that was what we were having.
But all we got in the end was an imho random renaming of a perfectly
good package name without any real design discussion. Cleaning up after
such a change isn't that hard and that was indeed not what I was angry
about. Although of course I rather not see extra work in the first
place. I would have happily done that work if I got the feeling there
was a real cleaned up design coming that couldn't be done without such a
renaming of packages. But that didn't emerge from the discussion at all.
And you are right that was what the discussion should have been about.

Cheers,

Mark

Re: frysk-core/frysk/proc ChangeLog IsaIA32.java I ...

[Phil Muldoon]

Mark Wielaard wrote:
> Hi Phil,
>
> On Wed, 2007-06-27 at 09:56 -0500, Phil Muldoon wrote:
>   
>> However, I think the larger picture here, and I think is lost in the 
>> "change over discussion" trend, is that the current proc model is pretty 
>> faulty in some of its assumptions and really needs refactoring. For the 
>> last six months I've been working on tweaking this and that so that 
>> Proc/Task/Host is not live process specific. So in the longer to mid 
>> term there really needs to be a rethink of that model.. 
>>     
>
> Yes I think you hit the actual issue. I agree.
>
> And I think that was why I was so disappointed about the process. A
> design discussion is good and I thought that was what we were having.
> But all we got in the end was an imho random renaming of a perfectly
> good package name without any real design discussion. Cleaning up after
> such a change isn't that hard and that was indeed not what I was angry
> about. Although of course I rather not see extra work in the first
> place. I would have happily done that work if I got the feeling there
> was a real cleaned up design coming that couldn't be done without such a
> renaming of packages. But that didn't emerge from the discussion at all.
> And you are right that was what the discussion should have been about.
>   

Moving forward, here is something I have been thinking about. As 
Host/Proc/Task.java  are basically "contracts" of how a Host/Proc/Task 
should be modeled on any system, they should in fact be straight 
interfaces, not abstract classes. This achieves two things:

1) Stops code being placed in Host/Proc/Task that really should not be 
there, but in some concrete class (implementor).
2) Just defines the structure of a Host/Proc/Task without placing any 
expectations on its implementation. Implementation details should not be 
a concept at this level.

Furthermore the whole concept of a state machine should be moved 
entirely to the implementing classes. I'm not sure how this will scale 
throughout the frysk model, but a state machine is fake for a corefile 
proc. It has no state, it's stone-cold dead. It will never live again 
(I'm ignoring the fact that someday someone might try to resurrect the 
process in its state just before it died). It will never spawn or lose 
tasks.

I'll take a radical view here and say the proc/ namespace is too busy. 
In fact, I think the proc/ model should just have:

- Interfaces

- sub-packages like dead/ and live/ that implement the interfaces. In 
those sub-packages should be all the ByteBuffer details that should be 
entirely package private to stop instantiation of process specific 
ByteBuffers. All tests, and so on.

It's a germ of an idea at the moment, but something I've warmed too over 
the weeks I've been thinking on it.

Regards

Phil

Re: frysk-core/frysk/proc ChangeLog IsaIA32.java I ...

[Andrew Cagney]

Phil Muldoon wrote:
> Moving forward, here is something I have been thinking about. As 
> Host/Proc/Task.java  are basically "contracts" of how a Host/Proc/Task 
> should be modeled on any system, they should in fact be straight 
> interfaces, not abstract classes. This achieves two things:
>
> 1) Stops code being placed in Host/Proc/Task that really should not be 
> there, but in some concrete class (implementor).
> 2) Just defines the structure of a Host/Proc/Task without placing any 
> expectations on its implementation. Implementation details should not 
> be a concept at this level.
>
> Furthermore the whole concept of a state machine should be moved 
> entirely to the implementing classes. I'm not sure how this will scale 
> throughout the frysk model, but a state machine is fake for a corefile 
> proc. It has no state, it's stone-cold dead. It will never live again 
> (I'm ignoring the fact that someday someone might try to resurrect the 
> process in its state just before it died). It will never spawn or lose 
> tasks.
>
> I'll take a radical view here and say the proc/ namespace is too busy. 
> In fact, I think the proc/ model should just have:
>
> - Interfaces
>
> - sub-packages like dead/ and live/ that implement the interfaces. In 
> those sub-packages should be all the ByteBuffer details that should be 
> entirely package private to stop instantiation of process specific 
> ByteBuffers. All tests, and so on.
>

Yes, exactly; much of what is in Task, and Proc should be booted down a 
level; mostly to frysk.proc.live.LiveTask.

> It's a germ of an idea at the moment, but something I've warmed too 
> over the weeks I've been thinking on it.
>
> Regards
>
> Phil
>

Re: frysk-core/frysk/proc ChangeLog IsaIA32.java I ...

[Mark Wielaard]

On Wed, 2007-06-27 at 09:32 -0400, Andrew Cagney wrote:
> I want this; and for you, it is cosmetic. Why are you so resistant to 
> what you yourself recognize has no effect on the code you work on?

As I said during the meeting I don't mind decisions being made or
patches submitted. But we have to make sure they are real decisions and
not just somebody deciding the discussion is over without notifying
anybody of that and then just pushing a change anyway. I was honestly
not expecting this one, because I thought we were still debating the
actual design of the refactoring that was needed. And I do favor a
refactoring that doesn't disrupt ongoing work, test results and loss of
cvs annotation and logs. Even if those are minor issues that only cost a
little amount of productivity loss. If that can be avoided completely
that is clearly my preference. A simple "OK I reviewed all the
arguments, I give higher priority to X above Y because of Z, so I am
going to work on the following changes..." would have been fine.

Thanks,

Mark