Andreas --
How did you debug this? I remember you saying to Ned that his stack trace didn't go down far enough to get to the problem..
-----Original Message----- From: Andreas Raab [mailto:andreas.raab@gmx.de] Sent: Thursday, February 27, 2003 4:04 PM To: 'Discussing the Squeak Foundation' Cc: squeak-dev@lists.squeakfoundation.org Subject: RE: Outstanding 3.4 bugs?
Hi Ned,
These bugs (and more, like the much-discussed bug with adding an instVar to ClassDescription) still exist in 3.4g.
Here's an update on this problem. I could trace it down to a very obscure breakage of the superclass/subclass invariant which can only happen when you recompile any of the essential behaviors (Behavior, ClassDescription, Class).
How did you debug this? I remember you saying to Ned that his stack trace didn't go down far enough to get to the problem..
Well, I recreated the problem, saw that the error you get was a recursive one, deduced that it must be happening in ContextPart>>printOn: put an exception handler in there to simply print "<error>" (this might actually be generally helpful) and then I could see that the problem originated from Metaclass>>name which apparently tried to concatenate a Dictionary with a String. Evaluating "thisClass instVarAt: ..." in the debugger (since you can't inspect it) showed me that the values of every instVar were shifted by one from what it should be which is the exact effect you see when you "forget" to reshape a subclass of some other class. From there, you can start hacking ClassBuilder - I put a halt in there if some class' name wasn't a stringy object. That showed me the "first place where the problem occurs" - e.g., the last class after which it gets broken. In this halt you see that (and which) the meta classes are broken and the stack tells you the rest of the story.
Cheers, - Andreas
-----Original Message----- From: Andreas Raab [mailto:andreas.raab@gmx.de] Sent: Thursday, February 27, 2003 4:04 PM To: 'Discussing the Squeak Foundation' Cc: squeak-dev@lists.squeakfoundation.org Subject: RE: Outstanding 3.4 bugs?
Hi Ned,
These bugs (and more, like the much-discussed bug with adding an instVar to ClassDescription) still exist in 3.4g.
Here's an update on this problem. I could trace it down to a very obscure breakage of the superclass/subclass invariant which can only happen when you recompile any of the essential behaviors (Behavior, ClassDescription, Class).
Okay, restating the problem actually helped me to understand how to fix it.
"Change Set: MetaClassBuilderFix Date: 27 February 2003 Author: Andreas Raab
This change set fixes a rather obscure bug with reshaping the entire class hierarchy from ClassBuilder. The problem was introduced by accidentally breaking the superclass/subclass invariant. The CS fixes this problem, by doing so actually removes some code and documents the critical invariants (both by putting comments into the methods affected and by making those methods private which temporarily break the crucial invariants).
The class comment has been extended to document the fundamental assumption that ClassBuilder needs access to ALL of the subclasses no matter where no matter how they are created. "
A general question: Do you think this fix looks reasonably safe enough to include with 3.4gamma? I was going to finalize 3.4 by tomorrow, but if we add this, we would need to postpone the release by a few days at least to test this a bit. On the other hand, this is a sort-of important fix which may be worth delaying 3.4 by a few days.
If we added this, I would probably create a quickie 3.4gammaTwo, and I would encourage people to do some class-rebuilding related testing on it.
- Doug Way
Andreas Raab wrote:
Okay, restating the problem actually helped me to understand how to fix it.
"Change Set: MetaClassBuilderFix Date: 27 February 2003 Author: Andreas Raab
This change set fixes a rather obscure bug with reshaping the entire class hierarchy from ClassBuilder. The problem was introduced by accidentally breaking the superclass/subclass invariant. The CS fixes this problem, by doing so actually removes some code and documents the critical invariants (both by putting comments into the methods affected and by making those methods private which temporarily break the crucial invariants).
The class comment has been extended to document the fundamental assumption that ClassBuilder needs access to ALL of the subclasses no matter where no matter how they are created. "
Name: MetaClassBuilderFix.cs.gzMetaClassBuilderFix.cs.gz Type: ChangeSet (application/x-unknown-content-type-cs_auto_file) Encoding: base64
Doug,
This isn't for me to decide. Of course, *I* think that it works, but I thought so before and I was wrong ;-( I'll (happily ;) leave this decision to the guides.
Cheers, - Andreas
-----Original Message----- From: Doug Way [mailto:dway@riskmetrics.com] Sent: Friday, February 28, 2003 1:07 AM To: The general-purpose Squeak developers list; Andreas Raab Subject: Re: [FIX] ClassBuilder problem
A general question: Do you think this fix looks reasonably safe enough to include with 3.4gamma? I was going to finalize 3.4 by tomorrow, but if we add this, we would need to postpone the release by a few days at least to test this a bit. On the other hand, this is a sort-of important fix which may be worth delaying 3.4 by a few days.
If we added this, I would probably create a quickie 3.4gammaTwo, and I would encourage people to do some class-rebuilding related testing on it.
- Doug Way
Andreas Raab wrote:
Okay, restating the problem actually helped me to
understand how to fix it.
"Change Set: MetaClassBuilderFix Date: 27 February 2003 Author: Andreas Raab
This change set fixes a rather obscure bug with reshaping
the entire class
hierarchy from ClassBuilder. The problem was introduced by
accidentally
breaking the superclass/subclass invariant. The CS fixes
this problem, by
doing so actually removes some code and documents the
critical invariants
(both by putting comments into the methods affected and by
making those
methods private which temporarily break the crucial invariants).
The class comment has been extended to document the
fundamental assumption
that ClassBuilder needs access to ALL of the subclasses no
matter where no
matter how they are created. "
Name: MetaClassBuilderFix.cs.gzMetaClassBuilderFix.cs.gz Type: ChangeSet
(application/x-unknown-content-type-cs_auto_file)
Encoding: base64
On Thursday, February 27, 2003, at 04:07 PM, Doug Way wrote:
A general question: Do you think this fix looks reasonably safe enough to include with 3.4gamma? I was going to finalize 3.4 by tomorrow, but if we add this, we would need to postpone the release by a few days at least to test this a bit. On the other hand, this is a sort-of important fix which may be worth delaying 3.4 by a few days.
If we added this, I would probably create a quickie 3.4gammaTwo, and I would encourage people to do some class-rebuilding related testing on it.
I think it would be worth delaying the release of 3.4 to include this fix. Having easy-to-install packages for Traits and Islands would be very beneficial. The more people can play around with and exercise that code, the better.
Colin Putney Whistler.com
Doug Way dway@riskmetrics.com wrote:
A general question: Do you think this fix looks reasonably safe enough to include with 3.4gamma?
The question one should be asking at this stage is more along the lines of "do I absolutely, positively _have_ to fix this right now and am I absolutely, positively able to confirm it doesn't break anything?" than "does it look about right?".
3.4 is already very much later than we originally intended and I suggest that we release it and have Andreas' fix available in the update stream asap. Bug fixes are, after all, what that is for. If neccessary the traits and islands packages could include it.
Let's release.
tim
Colin writes:
I think it would be worth delaying the release of 3.4 to include this fix. Having easy-to-install packages for Traits and Islands would be very beneficial. The more people can play around with and exercise that code, the better.
I don't think that's a convincing rationale for inclusion in 3.4. The 3.4 release is a vehicle for SqueakMap. I think only problems which have a catastrophic effect on a newcomer's ability to use SqueakMap should delay 3.4.
Ned writes (on the Foundation list):
...since Andreas just posted the ClassBuilder fix, I'm thinking that may be worth including and postponing the release by a few days for people to test.
Why? (And I don't use question marks lightly in this message, since I know they could cause more delay. :)
Since I'm doing that, I could also perhaps include Ned's recent ArchiveViewer fix, since I've looked at that and its seems straightforward and is a somewhat important fix.
(:
I don't think "somewhat important" cuts it at this release stage. Instead, I think it's better to weigh the results of leaving something out, rather than of including it.
My recollection of our group discussions at OOPSLA, in November 2002, were that we would take 3.2, add SqueakMap support to it, and release it as 3.4. It is now February 2003. This surprises me, even given our history. :)
I think we should release 3.4 now, and defer all outstanding available fixes into the 3.5a stream (subject to harvester approval). In our current situation, I think anyone likely to encounter the bugs described recently will be able to get them easily from the update stream. In the meantime, newcomers will have easier access to SqueakMap sooner. I think it's time to release.
thanks,
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org/resume Smalltalkers do: [:it | All with: Class, (And love: it)]
(Resent to squeak-dev, since my email address wasn't set right for squeak-dev's anti-spam processor before.)
Colin writes:
I think it would be worth delaying the release of 3.4 to include this fix. Having easy-to-install packages for Traits and Islands would be very beneficial. The more people can play around with and exercise that code, the better.
I don't think that's a convincing rationale for inclusion in 3.4. The 3.4 release is a vehicle for SqueakMap. I think only problems which have a catastrophic effect on a newcomer's ability to use SqueakMap should delay 3.4.
Doug writes (on the Foundation list):
...since Andreas just posted the ClassBuilder fix, I'm thinking that may be worth including and postponing the release by a few days for people to test.
Why? (And I don't use question marks lightly in this message, since I know they could cause more delay. :)
Since I'm doing that, I could also perhaps include Ned's recent ArchiveViewer fix, since I've looked at that and its seems straightforward and is a somewhat important fix.
(:
I don't think "somewhat important" cuts it at this release stage. Instead, I think it's better to weigh the results of leaving something out, rather than of including it.
My recollection of our group discussions at OOPSLA, in November 2002, were that we would take 3.2, add SqueakMap support to it, and release it as 3.4. It is now February 2003. This surprises me, even given our history. :)
I think we should release 3.4 now, and defer all outstanding available fixes into the 3.5a stream (subject to harvester approval). In our current situation, I think anyone likely to encounter the bugs described recently will be able to get them easily from the update stream. In the meantime, newcomers will have easier access to SqueakMap sooner. I think it's time to release.
thanks,
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org/resume Smalltalkers do: [:it | All with: Class, (And love: it)]
On Thursday 27 February 2003 06:07 pm, Craig Latta wrote:
Since I'm doing that, I could also perhaps include Ned's recent ArchiveViewer fix, since I've looked at that and its seems straightforward and is a somewhat important fix.
(: I don't think "somewhat important" cuts it at this releasestage. Instead, I think it's better to weigh the results of leaving something out, rather than of including it.
If someone loads SqueakMap, they get SARInstaller. And then they get the fix.
So it's only people who *don't* get SqueakMap loaded into their images who are even going to see this problem.
I'd say:
RELEASE!
Okay, I'm very easily talked out of delaying the 3.4 release any further :-) (and was having second thoughts after posting that last message), so I agree with the prevailing opinion to leave this change out and go ahead with the release.
The Traits and Islands packages for 3.4 can include Andreas' fix as part of their install, which shouldn't significantly hinder people from exercising that code... those packages are both pretty experimental anyway.
- Doug Way
On Thursday, February 27, 2003, at 08:59 PM, Craig Latta wrote:
Colin writes:
I think it would be worth delaying the release of 3.4 to include this fix. Having easy-to-install packages for Traits and Islands would be very beneficial. The more people can play around with and exercise that code, the better.
I don't think that's a convincing rationale for inclusion in 3.4. The 3.4 release is a vehicle for SqueakMap. I think only problems which have a catastrophic effect on a newcomer's ability to use SqueakMap should delay 3.4.
Doug writes (on the Foundation list):
...since Andreas just posted the ClassBuilder fix, I'm thinking that may be worth including and postponing the release by a few days for people to test.
Why? (And I don't use question marks lightly in this message, since I know they could cause more delay. :)
Since I'm doing that, I could also perhaps include Ned's recent ArchiveViewer fix, since I've looked at that and its seems straightforward and is a somewhat important fix.
(:
I don't think "somewhat important" cuts it at this release stage. Instead, I think it's better to weigh the results of leaving something out, rather than of including it.
My recollection of our group discussions at OOPSLA, in November 2002, were that we would take 3.2, add SqueakMap support to it, and release it as 3.4. It is now February 2003. This surprises me, even given our history. :)
I think we should release 3.4 now, and defer all outstanding available fixes into the 3.5a stream (subject to harvester approval). In our current situation, I think anyone likely to encounter the bugs described recently will be able to get them easily from the update stream. In the meantime, newcomers will have easier access to SqueakMap sooner. I think it's time to release.
thanks,
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org/resume Smalltalkers do: [:it | All with: Class, (And love: it)] _______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Yes, exactly. Let's get this 3.4! Gives us some time to exercise the fix (Nathanael will look at it more or less straight away anyway).
On Friday, February 28, 2003, at 05:19 AM, Doug Way wrote:
Okay, I'm very easily talked out of delaying the 3.4 release any further :-) (and was having second thoughts after posting that last message), so I agree with the prevailing opinion to leave this change out and go ahead with the release.
The Traits and Islands packages for 3.4 can include Andreas' fix as part of their install, which shouldn't significantly hinder people from exercising that code... those packages are both pretty experimental anyway.
- Doug Way
On Thursday, February 27, 2003, at 08:59 PM, Craig Latta wrote:
Colin writes:
I think it would be worth delaying the release of 3.4 to include this fix. Having easy-to-install packages for Traits and Islands would be very beneficial. The more people can play around with and exercise that code, the better.
I don't think that's a convincing rationale for inclusion in 3.4. The 3.4 release is a vehicle for SqueakMap. I think only problems which have a catastrophic effect on a newcomer's ability to use SqueakMap should delay 3.4.
Doug writes (on the Foundation list):
...since Andreas just posted the ClassBuilder fix, I'm thinking that may be worth including and postponing the release by a few days for people to test.
Why? (And I don't use question marks lightly in this message, since I know they could cause more delay. :)
Since I'm doing that, I could also perhaps include Ned's recent ArchiveViewer fix, since I've looked at that and its seems straightforward and is a somewhat important fix.
(:
I don't think "somewhat important" cuts it at this release stage. Instead, I think it's better to weigh the results of leaving something out, rather than of including it.
My recollection of our group discussions at OOPSLA, in November 2002, were that we would take 3.2, add SqueakMap support to it, and release it as 3.4. It is now February 2003. This surprises me, even given our history. :)
I think we should release 3.4 now, and defer all outstanding available fixes into the 3.5a stream (subject to harvester approval). In our current situation, I think anyone likely to encounter the bugs described recently will be able to get them easily from the update stream. In the meantime, newcomers will have easier access to SqueakMap sooner. I think it's time to release.
thanks,
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org/resume Smalltalkers do: [:it | All with: Class, (And love: it)] _______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Roel Wuyts Software Composition Group roel.wuyts@iam.unibe.ch University of Bern, Switzerland http://www.iam.unibe.ch/~wuyts/ Board Member of the European Smalltalk User Group: www.esug.org
Hi all!
Just wanted to chip in and agree we should release - I read through the discussion and agree that these aren't showstoppers. Hey, I am playing catch up with my inbox - who knows, we might already have released. :-)
Sidenote: Making automated "releases" like the first every month is IMHO not a "release". That is more like a nightly build. The release isn't a release just because we say it is - it is a release because we have been going through the alpha/beta/gamma phases. Doing that in one month doesn't sound useful to me.
But I agree that we can try to make some form of regular schedule for the releases. 2 per year sounds reasonable to me (just a hipshot).
regards, Göran
I agree.
On Monday, March 3, 2003, at 09:41 AM, goran.hultgren@bluefish.se wrote:
Sidenote: Making automated "releases" like the first every month is IMHO not a "release". That is more like a nightly build. The release isn't a release just because we say it is - it is a release because we have been going through the alpha/beta/gamma phases. Doing that in one month doesn't sound useful to me.
But I agree that we can try to make some form of regular schedule for the releases. 2 per year sounds reasonable to me (just a hipshot).
Having two release a year sounds reasonable and will push the CD production :).
Stef
Prof. Dr. Stéphane DUCASSE (ducasse@iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Brent Vukmer -
Colin Putney -
Craig Latta -
Craig Latta -
Doug Way -
goran.hultgren＠bluefish.se -
Ned Konz -
Roel Wuyts -
Stephane Ducasse -
Tim Rowledge