Whilst trawling through ancient dusty mantis reports I found this little fella' - http://bugs.squeak.org/view.php?id=1554 and thought to myself, "well now, this one will be closable because someone will surely have modified the compiler a fair bit by now and solved this". Wrong. Despite the fairly amazing amount of heat that the discussion released back in 2003 (ten years ago! eeek!) it appears nothing was done at the time beyond a proposed fix that only got into Mantis-land two years late through Ken Causey's good offices.
I tried out the suggested test code in a very recent (#12641) image and 8 out of 10 test passed. Now I'm no compiler guru and don't claim to have any special opinion on this except that it looked pretty serious back then and probably ought to be fixed if at all possible. Unless someone has good reasons for those two 'failing' tests to be considered unimportant, of course. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim There are two ways to write error-free programs; only the third one works. |
On 21 July 2013 00:41, tim Rowledge <[hidden email]> wrote:
> Whilst trawling through ancient dusty mantis reports I found this little fella' - http://bugs.squeak.org/view.php?id=1554 and thought to myself, "well now, this one will be closable because someone will surely have modified the compiler a fair bit by now and solved this". Wrong. Despite the fairly amazing amount of heat that the discussion released back in 2003 (ten years ago! eeek!) it appears nothing was done at the time beyond a proposed fix that only got into Mantis-land two years late through Ken Causey's good offices. > > I tried out the suggested test code in a very recent (#12641) image and 8 out of 10 test passed. Now I'm no compiler guru and don't claim to have any special opinion on this except that it looked pretty serious back then and probably ought to be fixed if at all possible. Unless someone has good reasons for those two 'failing' tests to be considered unimportant, of course. Those two tests - are they the tests that Ken says failed before loading the changeset, and work afterwards? frank > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > There are two ways to write error-free programs; only the third one works. |
Note that bindingOf: contents moved to bindingOf:environment: since Environment, so the fix might have to be updated. BTW when I browse implementors of bindingOf: I see many Trait>>bindingOf: Is it just me?2013/7/21 Frank Shearar <[hidden email]>
|
In reply to this post by Frank Shearar-3
On 21-07-2013, at 2:14 PM, Frank Shearar <[hidden email]> wrote: > On 21 July 2013 00:41, tim Rowledge <[hidden email]> wrote: >> Whilst trawling through ancient dusty mantis reports I found this little fella' - http://bugs.squeak.org/view.php?id=1554 and thought to myself, "well now, this one will be closable because someone will surely have modified the compiler a fair bit by now and solved this". Wrong. Despite the fairly amazing amount of heat that the discussion released back in 2003 (ten years ago! eeek!) it appears nothing was done at the time beyond a proposed fix that only got into Mantis-land two years late through Ken Causey's good offices. >> >> I tried out the suggested test code in a very recent (#12641) image and 8 out of 10 test passed. Now I'm no compiler guru and don't claim to have any special opinion on this except that it looked pretty serious back then and probably ought to be fixed if at all possible. Unless someone has good reasons for those two 'failing' tests to be considered unimportant, of course. > > Those two tests - are they the tests that Ken says failed before > loading the changeset, and work afterwards? I can't tell, unfortunately. They're not explicitly mentioned in the report and I couldn't spot any directly related commentary in the message thread. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim "Both.." said Pooh, as the guillotine came down |
On 07/21/2013 05:05 PM, tim Rowledge wrote:
> > On 21-07-2013, at 2:14 PM, Frank Shearar<[hidden email]> wrote: > >> On 21 July 2013 00:41, tim Rowledge<[hidden email]> wrote: >>> Whilst trawling through ancient dusty mantis reports I found this little fella' - http://bugs.squeak.org/view.php?id=1554 and thought to myself, "well now, this one will be closable because someone will surely have modified the compiler a fair bit by now and solved this". Wrong. Despite the fairly amazing amount of heat that the discussion released back in 2003 (ten years ago! eeek!) it appears nothing was done at the time beyond a proposed fix that only got into Mantis-land two years late through Ken Causey's good offices. >>> >>> I tried out the suggested test code in a very recent (#12641) image and 8 out of 10 test passed. Now I'm no compiler guru and don't claim to have any special opinion on this except that it looked pretty serious back then and probably ought to be fixed if at all possible. Unless someone has good reasons for those two 'failing' tests to be considered unimportant, of course. >> >> Those two tests - are they the tests that Ken says failed before >> loading the changeset, and work afterwards? > > > I can't tell, unfortunately. They're not explicitly mentioned in the report and I couldn't spot any directly related commentary in the message thread. > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > "Both.." said Pooh, as the guillotine came down I'm not certain I understand the question(s), however... Yes, if I had it to do over again and realized that it would be years before issues like these would be resolved, well then again there were signs of that even then. In any case, I should have been more explicit about specifically what tests were failing for me. Tim: Are you saying that both before and after the [FIX] is loaded the same 8 tests fail? Well, given the time that has passed the provided tests may be more valuable than the proposed fix at this point. Search http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-October/thread.html for 'ClassVarsFix' for possibly relevant context. Ken |
On 21-07-2013, at 7:31 PM, Ken Causey <[hidden email]> wrote: > > > Yes, if I had it to do over again and realized that it would be years before issues like these would be resolved, well then again there were signs of that even then. In any case, I should have been more explicit about specifically what tests were failing for me. Hindsight can be a wonderful thing… I'm not sure any of us thought there would be Squeak to still worry about by now. > > Tim: Are you saying that both before and after the [FIX] is loaded the same 8 tests fail? Well, given the time that has passed the provided tests may be more valuable than the proposed fix at this point. Given the amount of changes to the compiler since then and the decided lack of my compiler knowledge, I didn't feel safe to try loading it. The tests seemed to load ok, which was nice. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Oxymorons: Software documentation |
Basic correction is just a matter of rewritting bindingOf: (now moved to bindingOf:environment:) Then there are UI corrections that probably need deeper review.2013/7/22 tim Rowledge <[hidden email]>
|
So we could fix it like this: bindingOf: varName environment: anEnvironment "Answer the binding of some variable resolved in the scope of the receiver" | aSymbol binding | aSymbol := varName asSymbol. "First look in classVar dictionary of the whole hierarchy" (self classThatDefinesClassVariable: varName) ifNotNilDo: [:x | ^x classPool bindingOf: varNameSymbol]. "Next look in shared pools." self sharedPools do:[:pool | binding := pool bindingOf: aSymbol. binding ifNotNil:[^binding]. ]. "Next look in declared environment." binding := anEnvironment bindingOf: aSymbol. binding ifNotNil:[^binding]. "Finally look higher up the superclass chain and fail at the end." superclass == nil ifTrue: [^ nil] ifFalse: [^ superclass bindingOf: aSymbol]. However, I wonder if it is a super idea to ask for superclass bindingOf: - First, the will start the classVar look-up of whole hierarchy (minus one) again. - Second, imagine that class A is defined in environment E1, and class B is a subclass of A defined in a specific environment E2. I don't think so, so I'd rather remove last statement. What do you think? There is also the sharedPools problem, is a SharedPool visible by all subclasses? Nicolas 2013/7/22 Nicolas Cellier <[hidden email]>
|
Free forum by Nabble | Edit this page |