evaluate this silly example from a text editor:
Object compile: 'outOfScopeExample true ifTrue: [| i | i := 1]. ^i'. ^Object new perform: #outOfScopeExample Well surprise, it compiles... It doesn't raise a SyntaxErrorNotification because the OutOfScopeNotification is caught by ParagraphEditor evaluateSelection... Instead, above evaluation will answer 1. Gasp, not a thing to teach in schools ! Now try to write this code in a SUnit, the SUnit will fail when ran from the TestRunner, but will succeed when ran from the browser (evaluating something like self debug: #testOutOfScope). You see, things are getting worse... I nearly turned crazy on a related bug : I subclassed MessageAsTempNode which answers -1 when sent #scope, which cause an out of scope Notification. Of course, i wrote SUnit tests that all ran fine when launched from the browser (sorry, i'am used to VW RB interface, where i enforced good habits to write and run tests immediately, not spending several clicks to open a separate TestRunner and select my TestCase. TestRunner is good for massive non regression tests, it is not tailored for Xtreme Programming). MessageAsTempNode is used by inspector/debugger to compile contextual evaluations... and compiler generates an out of scope notification when it encounters such a contextual variable (i'am not sure that this is correct because thisContext is not out of scope)... Fortunately, debugger and inspector are interactive things, so ParagraphEditor trick catch that and make it work finally... Is this real programmer's intention, or just lucky circumstances? Exception handling sometimes look sexy, but deserve special care. Putting it in a central place like ParagraphEditor, you can expect creating undesired side effects... Unless all this is desired ? Nicolas |
On 7-Apr-06, at 3:46 PM, nicolas cellier wrote: > evaluate this silly example from a text editor: > > Object compile: 'outOfScopeExample > true ifTrue: [| i | i := 1]. > ^i'. > ^Object new perform: #outOfScopeExample Squeak doesn't have proper closures. Your code is compiled exactly like |i| true ifTrue:[i:= 1]. ^i The i is not actually out of scope, unlike in VW. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim 'Profanity: the universal programming language' |
Le Samedi 08 Avril 2006 01:33, tim Rowledge a écrit :
> On 7-Apr-06, at 3:46 PM, nicolas cellier wrote: > > evaluate this silly example from a text editor: > > > > Object compile: 'outOfScopeExample > > true ifTrue: [| i | i := 1]. > > ^i'. > > ^Object new perform: #outOfScopeExample > > Squeak doesn't have proper closures. Your code is compiled exactly like > > |i| > true ifTrue:[i:= 1]. > ^i > The i is not actually out of scope, unlike in VW. > > tim Tim, you have the right explanation, i do not contest that. But try to fileOut the outOfScopeExample, or publish it in Monticello, and file it in again; or simply modify it from a Browser: you cannot. That is what i contest: following one path, you can (incorrectly in my opinion), following another you cannot (what i think is a proper behavior even if the underlying implementation does not enforce closures). Either you have to remove the OutOfScopeNotification and claim that this is a language feature, or you have to enforce the notification everywhere. Current implementation have a hole and shouldn't remain as is. Nicolas |
Hi nicolas
often the state of squeak is not the way we would like. But we should improve it step by step so if you have tests fixes, please keep going. Sqeuak needs excellent guy like you!!! Stef > >> On 7-Apr-06, at 3:46 PM, nicolas cellier wrote: >>> evaluate this silly example from a text editor: >>> >>> Object compile: 'outOfScopeExample >>> true ifTrue: [| i | i := 1]. >>> ^i'. >>> ^Object new perform: #outOfScopeExample >> >> Squeak doesn't have proper closures. Your code is compiled exactly >> like >> >> |i| >> true ifTrue:[i:= 1]. >> ^i >> The i is not actually out of scope, unlike in VW. >> >> tim > > Tim, you have the right explanation, i do not contest that. > > But try to fileOut the outOfScopeExample, or publish it in > Monticello, and > file it in again; or simply modify it from a Browser: you cannot. > > That is what i contest: following one path, you can (incorrectly in my > opinion), following another you cannot (what i think is a proper > behavior > even if the underlying implementation does not enforce closures). > > Either you have to remove the OutOfScopeNotification and claim that > this is a > language feature, or you have to enforce the notification everywhere. > > Current implementation have a hole and shouldn't remain as is. > > Nicolas > > > |
Le Samedi 08 Avril 2006 12:13, vous avez écrit :
> Hi nicolas > > often the state of squeak is not the way we would like. But we should > improve it > step by step so if you have tests fixes, please keep going. > Sqeuak needs excellent guy like you!!! > > Stef > Thanks Stef for this kind mail, I'd rather see my work so far limited to minor bugs and unconsistencies tracking as the labour of an ant in the squeak colony. But if that can be usefull to higher value added packages, i am happy. Squeak, if not the top cleanest smalltalk implementation, is not bad at all. It is highly usable as proven by all these nice projects. I understand how vast the task of maintaining it is for (crazy?) guys like you... So many thanks to all of you, and take the [GRR] as a trait of humour, in no way something agressive. We should all support you in trying to make Squeak built on clean, consistent and not too big basis. Doing so, we are helping ourselves for the future. I put the OutOfScope Pb at http://bugs.impara.de/view.php?id=3448 So maybe should any related discussion continue there. Nicolas |
Hi
> I put the OutOfScope Pb at http://bugs.impara.de/view.php?id=3448 > So maybe should any related discussion continue there. Just out of curiosity, what you tried to recompile the image with this patch? Yes it should work, but I wouldn't be surprised if it doesn't ;) And if it doesn't it shows us places we need to fix. Cheers Philippe |
In reply to this post by Nicolas Cellier-3
>
> Thanks Stef for this kind mail, > I'd rather see my work so far limited to minor bugs and > unconsistencies > tracking as the labour of an ant in the squeak colony. but ant step and important. And may be from time to time a big rewrite :) > But if that can be usefull to higher value added packages, i am happy. > > Squeak, if not the top cleanest smalltalk implementation, is not > bad at all. > It is highly usable as proven by all these nice projects. > I understand how vast the task of maintaining it is for (crazy?) > guys like > you... So many thanks to all of you, and take the [GRR] as a trait > of humour, > in no way something agressive. Sure I could far more aggressive than that :) > We should all support you in trying to make Squeak built on clean, > consistent > and not too big basis. Doing so, we are helping ourselves for the > future. > > I put the OutOfScope Pb at http://bugs.impara.de/view.php?id=3448 > So maybe should any related discussion continue there. Yes but this is really important to see the discussion also in the mailing-list. Also do not hesitate to raise the issue or fixes that are pending to be harvested because mantis is not transparent to me. Stef > > Nicolas > > > |
> > I put the OutOfScope Pb at http://bugs.impara.de/view.php?id=3448 > > So maybe should any related discussion continue there. > > > > Nicolas > > Yes but this is really important to see the discussion also in the > mailing-list. > Also do not hesitate to raise the issue or fixes that are pending to > be harvested > because mantis is not transparent to me. > > Stef > OK, solution is coming from Andreas, i put a patch based on his idea at http://bugs.impara.de/view.php?id=3448 |
Free forum by Nabble | Edit this page |