Oh, I forgot,* Compiler>>compiledMethodFor: textOrStream in: aContext to: receiver notifying: aRequestor ifFail: failBlock logged: logFlag* has no senders.
Was that replaced by* Compiler>>evaluate: textOrStream in: aContext to: receiver notifying: aRequestor ifFail: failBlock logged: logFlag *? On Tue, May 18, 2010 at 3:52 AM, Carla F. Griggio <carla.grig...@gmail.com>wrote: > Hi everybody! > > Well, maybe you are already aware of this... maybe not. I tried to find an > issue about this and unless I didn't think of the right keywords, it's not > there. > > I was debugging a template method and sudenly I found myself spending ours > trying to find out why I got different results when printing the result of a > message sent to super and when steping into that message and printing the > (same) result there. > > Imagine this simple situation (I attatch the complete code and some tests > so you can reproduce this): > > AverageTotalization inherits from Totalization. > WeightedAverageTotalization inherits from AverageTotalization. > > Totalization>>total > ^self summatory > > AverageTotalization>>total > ^*(**super total)* / self denominator > > AverageTotalization>> denominator > ^values size > > WeightedAverageTotalization>> denominator > "Weights is a dictionary" > ^self weights values sum > > > If I debug aWeightedAverateTotalization total and try to print *super > total* in the debugger ParagraphEditor, I'll get this result: > > (self summatory / self denominator) > > instead of just: > > self summatory > > This only happens when I print or inspect or other do-its in the debugger > window. The method lookup works OK when just evaluating the code (the tests > I made are green). > > I think that when you print or inspect (etc) *super total*, the evaluation > context takes WeightedAverageTotalization class instead of > AverageTotalization, so when total is sent to super under that context, the > code is looked up on AverageTotalization instead of Totalization. > Could that be possible? Am I thinking right? > > I spent a *while* chasing this bug, and I found a solution, but I don't > know if it's OK or if it's the best. It's simple and it seems to work. I > tested it in the last PharoCore1.1 unstable image. > > I attach some code to reproduce the error (you'll get a halt when you run > the test, read the comments, the problem is clear when you run the weighted > average test), and the code that fixes this. > > If you confirm that this was not a known issue, I'll register it on the > issue tracker with both these attachments. > > If it was a known issue... well, I learned :) (I think XD) > > Cheers! > > Carla. >
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
