- Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: [squeak-dev] Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!

by StÃ©phane Ducasse

> Thanks thanks thanks thanks for a refresh on that! > Thanks! > > Stef > > On Mar 8, 2010, at 5:55 PM, Randal L. Schwartz wrote: > >>>>>>> "Randal" == Randal L Schwartz <merlyn(a)stonehenge.com> writes: >> >> Randal> And I believe some heavyweights (with actual lawyers they paid) have >> Randal> already weighed in that the LGPL is equivalent to the *GPL* in a >> Randal> Smalltalk context, so unless the code is explicitly dual-licensed with >> Randal> a more permissive license as well, it taints the entire distro. >> >> Here's the reference: >> >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-January/124027.… >> >> -- >> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 >> <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> >> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. >> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion >> > > > >

March 8, 2010

Re: [Pharo-project] [update 1.1] #11243

by StÃ©phane Ducasse

Thanks. Apparently the mailing-list is working again. Stef On Mar 8, 2010, at 3:13 PM, Lukas Renggli wrote: > Here are 3 additional tests that verify that these reserved variables > are not shadowed. > > Please integrate :-) > > Lukas > > On 8 March 2010 15:01, Lukas Renggli <renggli(a)gmail.com> wrote: >> Actually this is already fixed by the previous fix. Jorge and I are >> going to write some new tests. >> >> Lukas >> >> On 8 March 2010 14:50, Lukas Renggli <renggli(a)gmail.com> wrote: >>> Erwann just noticed another kind of serious shadowing bug. >>> >>> The closure compiler allows to declare methods like the following: >>> >>> foo: self >>> | super thisContext true false nil | >>> ^ super := thisContext := true := false := nil := self >>> >>> These argument and temporary names should all be disallowed as all >>> other Smalltalk compiler do (and also the pre closure one in Pharo >>> did). Using the implicit variables as argument or temp names leads to >>> absolutely unmaintainable code. >>> >>> Lukas >>> >>> On 5 March 2010 12:16, Lukas Renggli <renggli(a)gmail.com> wrote: >>>> The problem is that some ancestor versions disappeared, what makes it >>>> impossible to merge. We've manually integrated the delta into: >>>> >>>> Name: Tests-lr.79 >>>> Author: lr >>>> Time: 5 March 2010, 12:16:05 pm >>>> UUID: 99f8b58a-0923-4264-9ea6-58fec6cf4d18 >>>> Ancestors: Tests-MichaelRueger.78 >>>> >>>> - merged Jorges Code >>>> >>>> Lukas >>>> >>>> On 5 March 2010 11:25, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> Jorge >>>>> >>>>> could you publish the tests for 1.1 because I could not find my way 11 conflicts for 1.1? >>>>> >>>>> Stef >>>>> >>>>> >>>>>> Hi Adrian, >>>>>> >>>>>> Sorry for the delay, too many things today. >>>>>> >>>>>> Ok, I added 17 test to Tests-Compiler which model the cases of >>>>>> shadowing, at least the ones I could come up with. I also modified the >>>>>> Encoder>>bindTemp: in order to make it a little bit more intention >>>>>> revealing. >>>>>> >>>>>> My changes are in: >>>>>> >>>>>> Compiler-JorgeRessia.144 >>>>>> Tests-JorgeRessia.46 >>>>>> >>>>>> Some comments: >>>>>> >>>>>> - In order to test the not interactive mode I had to mock the >>>>>> Transcript. I could not find a better solution, if anybody has a >>>>>> better one just let me know I'll change it. >>>>>> - There is a special case which is that when you are NOT in >>>>>> interactive mode if the shadowed variable is a temp then the syntax >>>>>> error is triggered as in interactive mode. This is the behavior >>>>>> implemented before I did the changes. Is that what we want? >>>>>> - I added this test to Tests-Compiler package, I would have preferred >>>>>> to add them to Compiler-Tests but there was nothing there. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Jorge >>>>>> >>>>>> On Thu, Mar 4, 2010 at 8:45 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>>>>> Hi Jorge, >>>>>>> >>>>>>> Just let me know when you think the code is ok for 1.0 or when you have something different that I should integrate. Thanks! >>>>>>> >>>>>>> Cheers, >>>>>>> Adrian >>>>>>> >>>>>>> On Mar 4, 2010, at 09:37 , Jorge Ressia wrote: >>>>>>> >>>>>>>> Hi Adrian, >>>>>>>> >>>>>>>> Yep, I have the same problem as you. My idea was to make it work as >>>>>>>> before without completely changing it. Basically because I did not >>>>>>>> have the test support to validate my changes. >>>>>>>> Anyhow, what I propose is to write a bunch of tests for every case >>>>>>>> that we know and then if new cases show up add them to the test suite. >>>>>>>> And then play with the code. >>>>>>>> >>>>>>>> I will work on that today, is that ok? >>>>>>>> >>>>>>>> For the explanation of what is going on is that now node can be an >>>>>>>> instance variable node, then the behavior that was there was not >>>>>>>> appropriate in the sense that instance variable nodes do not >>>>>>>> understand #scope. >>>>>>>> However, why this validation "(node isTemp or: [requestor >>>>>>>> interactive])" was there in the first place is not that clear to me, >>>>>>>> but it's been there since 1999. >>>>>>>> >>>>>>>> I'll try to build the tests and come up with a better solution. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Jorge >>>>>>>> >>>>>>>> On Thu, Mar 4, 2010 at 9:14 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>>>>>>> Jorge, >>>>>>>>> >>>>>>>>> I looked at the code to integrate in 1.0. And I really have troubles understanding it (even after drawing a boolean table for the different combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning is shown when node isTemp is false and requestor interactive is true? Is the comment still accurate? >>>>>>>>> >>>>>>>>> This is the code: >>>>>>>>> >>>>>>>>> "When non-interactive raise the error only if its a duplicate" >>>>>>>>> (node isTemp or: [requestor interactive]) >>>>>>>>> ifTrue:[ ((node isTemp) and: [node scope <= 0] ) >>>>>>>>> ifFalse: [^self notify:'Name is already defined' ]] >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> On Mar 3, 2010, at 20:47 , StÃ©phane Ducasse wrote: >>>>>>>>> >>>>>>>>>> 11243 >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> - Issue 2102: Fix the fact that local temp can shadow silently instance var --- fixed >>>>>>>>>> Problem fixed: >>>>>>>>>> We cannot have twice the same block arg in a method >>>>>>>>>> >>>>>>>>>> [:each | each ...] >>>>>>>>>> [:each | each ...] >>>>>>>>>> >>>>>>>>>> THANKS jorge :) >>>>>>>>>> Do you like good bio beer? >>>>>>>>>> >>>>>>>>>> Stef >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Pharo-project mailing list >>>>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Pharo-project mailing list >>>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> >>>> -- >>>> Lukas Renggli >>>> http://www.lukas-renggli.ch >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 8, 2010

Re: [Pharo-project] XML Parser / Pastell

by Alexandre Bergel

Note that this email is sent to the Pharo mailing list. It is actually more appropriate since the moose mailing list members are also part of Pharo. > I have an update I will push in a day or two that extends namespace > support to attributes and also preserves the order of attributes. > Additionally, the tokenizer has been sped up somewhat. I have also > renamed some of the SAX handlers, but if you have a subclass that > implements them, they will still be invoked but with a warning that > they have been deprecated. Using deprecation is good > I am going back on using Symbols to identify elements and > attributes. The performance of such a Symbol-based system is quite > erratic; running benchmark1 several times (at a much higher > interval), I repeatedly got results in the ~5800 to ~6200 range in a > clean image with XML-Support loaded into it from Monticello. Saving > the image and running it again, I got results in the range of ~4400 > to ~4700. There seems to be a performance hit associated with using > symbols in this fashion that does not abate until you save the image > at least once. Even then my tests seem to indicate that a String- > based system would be slightly faster. This is probably due to the > initial overhead of interning Symbols and the subsequent overhead of > looking them up. Really strange. What make you think it is related to Symbol? Cheers, Alexandre > > ---- On Thu, 04 Mar 2010 12:35:39 -0800 Alexandre Bergel <alexandre(a)bergel.eu > > wrote ---- > >> Hi, >> >> I exchanged a number of emails with Jaayer and Norbert regarding some >> improvements of XMLSupport and its port to Gemstone. >> It may be a bit difficult for people to follow this, but I think it >> is >> important to not discuss privately. >> >>>>>>> I already changed >>>>>>> >>>>>>> XMLTokenizer>>nextName >>>>>>> .... >>>>>>> ^ self fastStreamStringContents: nameBuffer >>>>>>> >>>>>>> to >>>>>>> >>>>>>> XMLTokenizer>>nextName >>>>>>> .... >>>>>>> ^ (self fastStreamStringContents: nameBuffer) asSymbol >>>>>>> >>>>>>> in the gemstone parser to be more consistent. >>>>>> >>>>>> Have you noticed any slow down for this? >>>>>> >>>>> No I didn't do any tests. But if internally all names are symbols >>>>> than I guess converting it while reading is the best way to do. >>>> >>>> I added benchmark1 in XMLParserTest. Really simple way to measure >>>> progress (or slowdown). >>>> On my machine, I have: >>>> XMLParserTest new benchmark1 >>>> => 2097 >>>> >>>> Adding "(self fastStreamStringContents: nameBuffer) asSymbol" >>>> increase the bench to 2273 >>>> >>> I don't believe this ;) you read them as string from the stream. If >>> they are managed as symbols somehow they need to be converted. If >>> not at this place then on some other. I would suspect that there are >>> doubled calls to asSymbol. Could you check the sources? >> >> There is indeed a slowdown. I am not sure where it comes from >> however. >> Executing twice "XMLParserTest new benchmark1" does not return the >> same result. Actually, it increases at each execution! I thought that >> a garbage collect before running the bench would help, does >> apparently >> it does not. >> >> Calling asSymbol on a symbol should not be perceptible I believe. >> >> Cheers, >> Alexandre >> >> >>>>> anElement attributes class (I wrote species but that will fail in >>>>> gemstone too I guess. Hell!) >>>> >>>> I just committed with species. Let me know. This is easy to adjust. >>>> >>> Ok. >>> >>>>>>> The gemstone XML Parser decides somehow to use >>>>>>> IdentityDictionary internally. I think this should be allowed. I >>>>>>> just changed Dictionary to IdentityDictionary so the = test >>>>>>> reflects the right type. If you change it it is clear that it >>>>>>> fails. Because pharo uses Dictionary internally. So you might >>>>>>> see that it is not a question of using Dictionary or >>>>>>> IdentityDictionary but a question of the wrongness of using = >>>>>> >>>>>> How the XMLNodeTest should look like to accommodate your >>>>>> situation? >>>>>> >>>>> I need to recheck this. The problem is really that the XML Parser >>>>> creatios instances of class Association but { #key->'value' } >>>>> creates an instance of class SymbolAssociation. That means I would >>>>> know how to fix the test but I want to understand the implications >>>>> of all of this. I'll get to you if I know anything new. >>>> >>>> Ok. >>>> >>> My mail to the gemstone list led to a ticket about removing class >>> checks from Association. That would be easing the handling a lot. >>> >>> Norbert >>>>> >>>>> >>>>>> Alexandre >>>>>> >>>>>>> >>>>>>>>> Here there is an assumption about the allAttributes collection >>>>>>>>> while using = as comparsion. But there is also an assumption >>>>>>>>> about the order of the content. I changed this to >>>>>>>>> >>>>>>>>> self assert: (firstPerson allAttributes includesAllOf: >>>>>>>>> #(#'first-name' #'employee-number' #'family-name')). >>>>>>>>> self assert: (firstPerson allAttributeAssociations asArray >>>>>>>>> includesAllOf: {(#'first-name'->'Bob'). (#'employee-number'- >>>>>>>>>> 'A0000'). (#'family-name'->'Gates')}). >>>>>>>> >>>>>>>> Very right. My mistake. But wouldn't an asSortedCollection do >>>>>>>> the thing? Do you not test the size of the array. >>>>>>>> >>>>>>>>> This is not the best way to do because the check is only in >>>>>>>>> one direction but for this test it is ok. Somehow the second >>>>>>>>> assert fails and I have to check what is going on here. >>>>>>>> >>>>>>>> Yeah, my mistake. Sorry. The elements may be differently >>>>>>>> ordered. Would a asSortedCollection help? >>>>>>>> >>>>>>>> I have now granted you an access to the repository. You should >>>>>>>> be able to directly commit in it. >>>>>>>> >>>>>>>> Jaayer, what is your Squeaksource account? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Alexandre >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 28.02.2010, at 02:01, Alexandre Bergel wrote: >>>>>>>>> >>>>>>>>>>> thanks for now. I did a first merge attempt. It will be >>>>>>>>>>> quite a bit of work. For me the xml parser is an important >>>>>>>>>>> component. With the newest changes it became biased towards >>>>>>>>>>> pharo. There are things like ClassTestCase, Unicode >>>>>>>>>>> CharacterSet. These are for sure improvements/changes in >>>>>>>>>>> pharo you like to use. But they make porting a lot more >>>>>>>>>>> difficult. I would be glad if we could find some way to >>>>>>>>>>> lower the porting barrier. The necessary class I could put >>>>>>>>>>> in the squeak compat package in gemstone. But then the xml >>>>>>>>>>> parser will depend on the squeak package which I don't like. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Norbert, >>>>>>>>>> >>>>>>>>>> XMLParser effectively depends on Squeak specific classes. I >>>>>>>>>> wrote a small script that identify the squeak classes used in >>>>>>>>>> XML-Support. Here is the list: LanguageEnvironment, Unicode, >>>>>>>>>> LocaleID, CharacterSet >>>>>>>>>> >>>>>>>>>> I guess that porting the whole multilingual support may not >>>>>>>>>> be that easy. The tag xml:lang is used to select the proper >>>>>>>>>> support. It should be easy for you to ignore it I guess. >>>>>>>>>> >>>>>>>>>> CharacterSet seems to be one that has to be ported. It is not >>>>>>>>>> a big class. It depends on WideCharacterSet. I am not sure >>>>>>>>>> whether this is useful in your case however. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Alexandre >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 8, 2010

Re: [Pharo-project] [squeak-dev] Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!

by merlyn＠stonehenge.com

>>>>> "Randal" == Randal L Schwartz <merlyn(a)stonehenge.com> writes: Randal> And I believe some heavyweights (with actual lawyers they paid) have Randal> already weighed in that the LGPL is equivalent to the *GPL* in a Randal> Smalltalk context, so unless the code is explicitly dual-licensed with Randal> a more permissive license as well, it taints the entire distro. Here's the reference: http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-January/124027.… -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

March 8, 2010

Re: [Pharo-project] [squeak-dev] Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!

by merlyn＠stonehenge.com

>>>>> "Yanni" == Yanni Chiu <yanni(a)rogers.com> writes: Yanni> GLORP is LGPL, with a subsequently added explanation of how the the Yanni> license should be interpreted in a Smalltalk context. INAL, but this Yanni> still seems muddy, since it's unclear whether or not the author's Yanni> interpretation and intentions would override the actual license, which Yanni> is LGPL. Or, is it the case that the actual license is LGPL + author Yanni> addendums - gah, another license mess. And I believe some heavyweights (with actual lawyers they paid) have already weighed in that the LGPL is equivalent to the *GPL* in a Smalltalk context, so unless the code is explicitly dual-licensed with a more permissive license as well, it taints the entire distro. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

March 8, 2010

Re: [Pharo-project] [update 1.1] #11243

by Lukas Renggli

Naturally in the Pharo Inbox: Name: Tests-lr.122 Author: lr Time: 8 March 2010, 3:12:26 pm UUID: faa9eb31-f84e-4e49-916e-991115a6f2da Ancestors: Tests-StephaneDucasse.121 - added tests for the compiler to test shadowing of self, super, thisContext, true, false and nil On 8 March 2010 15:13, Lukas Renggli <renggli(a)gmail.com> wrote: > Here are 3 additional tests that verify that these reserved variables > are not shadowed. > > Please integrate :-) > > Lukas > > On 8 March 2010 15:01, Lukas Renggli <renggli(a)gmail.com> wrote: >> Actually this is already fixed by the previous fix. Jorge and I are >> going to write some new tests. >> >> Lukas >> >> On 8 March 2010 14:50, Lukas Renggli <renggli(a)gmail.com> wrote: >>> Erwann just noticed another kind of serious shadowing bug. >>> >>> The closure compiler allows to declare methods like the following: >>> >>> foo: self >>> Â Â | super thisContext true false nil | >>> Â Â ^ super := thisContext := true := false := nil := self >>> >>> These argument and temporary names should all be disallowed as all >>> other Smalltalk compiler do (and also the pre closure one in Pharo >>> did). Using the implicit variables as argument or temp names leads to >>> absolutely unmaintainable code. >>> >>> Lukas >>> >>> On 5 March 2010 12:16, Lukas Renggli <renggli(a)gmail.com> wrote: >>>> The problem is that some ancestor versions disappeared, what makes it >>>> impossible to merge. We've manually integrated the delta into: >>>> >>>> Name: Tests-lr.79 >>>> Author: lr >>>> Time: 5 March 2010, 12:16:05 pm >>>> UUID: 99f8b58a-0923-4264-9ea6-58fec6cf4d18 >>>> Ancestors: Tests-MichaelRueger.78 >>>> >>>> - merged Jorges Code >>>> >>>> Lukas >>>> >>>> On 5 March 2010 11:25, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> Jorge >>>>> >>>>> could you publish the tests for 1.1 because I could not find my way 11 conflicts for 1.1? >>>>> >>>>> Stef >>>>> >>>>> >>>>>> Hi Adrian, >>>>>> >>>>>> Sorry for the delay, too many things today. >>>>>> >>>>>> Ok, I added 17 test to Tests-Compiler which model the cases of >>>>>> shadowing, at least the ones I could come up with. I also modified the >>>>>> Encoder>>bindTemp: in order to make it a little bit more intention >>>>>> revealing. >>>>>> >>>>>> My changes are in: >>>>>> >>>>>> Â Â Â Â Â Â Â Â Â Â Â Compiler-JorgeRessia.144 >>>>>> Â Â Â Â Â Â Â Â Â Â Â Tests-JorgeRessia.46 >>>>>> >>>>>> Some comments: >>>>>> >>>>>> - In order to test the not interactive mode I had to mock the >>>>>> Transcript. I could not find a better solution, if anybody has a >>>>>> better one just let me know I'll change it. >>>>>> - There is a special case which is that when you are NOT in >>>>>> interactive mode if the shadowed variable is a temp then the syntax >>>>>> error is triggered as in interactive mode. This is the behavior >>>>>> implemented before I did the changes. Is that what we want? >>>>>> - I added this test to Tests-Compiler package, I would have preferred >>>>>> to add them to Compiler-Tests but there was nothing there. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Jorge >>>>>> >>>>>> On Thu, Mar 4, 2010 at 8:45 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>>>>> Hi Jorge, >>>>>>> >>>>>>> Just let me know when you think the code is ok for 1.0 or when you have something different that I should integrate. Thanks! >>>>>>> >>>>>>> Cheers, >>>>>>> Adrian >>>>>>> >>>>>>> On Mar 4, 2010, at 09:37 , Jorge Ressia wrote: >>>>>>> >>>>>>>> Hi Adrian, >>>>>>>> >>>>>>>> Yep, I have the same problem as you. My idea was to make it work as >>>>>>>> before without completely changing it. Basically because I did not >>>>>>>> have the test support to validate my changes. >>>>>>>> Anyhow, what I propose is to write a bunch of tests for every case >>>>>>>> that we know and then if new cases show up add them to the test suite. >>>>>>>> And then play with the code. >>>>>>>> >>>>>>>> I will work on that today, is that ok? >>>>>>>> >>>>>>>> For the explanation of what is going on is that now node can be an >>>>>>>> instance variable node, then the behavior that was there was not >>>>>>>> appropriate in the sense that instance variable nodes do not >>>>>>>> understand #scope. >>>>>>>> However, why this validation "(node isTemp or: [requestor >>>>>>>> interactive])" was there in the first place is not that clear to me, >>>>>>>> but it's been there since 1999. >>>>>>>> >>>>>>>> I'll try to build the tests and come up with a better solution. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Jorge >>>>>>>> >>>>>>>> On Thu, Mar 4, 2010 at 9:14 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>>>>>>> Jorge, >>>>>>>>> >>>>>>>>> I looked at the code to integrate in 1.0. And I really have troubles understanding it (even after drawing a boolean table for the different combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning is shown when node isTemp is false and requestor interactive is true? Is the comment still accurate? >>>>>>>>> >>>>>>>>> This is the code: >>>>>>>>> >>>>>>>>> "When non-interactive raise the error only if its a duplicate" >>>>>>>>> (node isTemp or: [requestor interactive]) >>>>>>>>> Â Â Â Â ifTrue:[ ((node isTemp) and: [node scope <= 0] ) >>>>>>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [^self notify:'Name is already defined' ]] >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> On Mar 3, 2010, at 20:47 , StÃ©phane Ducasse wrote: >>>>>>>>> >>>>>>>>>> 11243 >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> - Issue 2102: Fix the fact that local temp can shadow silently instance var --- fixed >>>>>>>>>> Â Â Â Problem fixed: >>>>>>>>>> We cannot have twice the same block arg in a method >>>>>>>>>> >>>>>>>>>> Â Â Â [:each | each ...] >>>>>>>>>> Â Â Â [:each | each ...] >>>>>>>>>> >>>>>>>>>> THANKS jorge :) >>>>>>>>>> Do you like good bio beer? >>>>>>>>>> >>>>>>>>>> Stef >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Pharo-project mailing list >>>>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Pharo-project mailing list >>>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> >>>> -- >>>> Lukas Renggli >>>> http://www.lukas-renggli.ch >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > -- Lukas Renggli http://www.lukas-renggli.ch

March 8, 2010

Re: [Pharo-project] [update 1.1] #11243

by Lukas Renggli

Here are 3 additional tests that verify that these reserved variables are not shadowed. Please integrate :-) Lukas On 8 March 2010 15:01, Lukas Renggli <renggli(a)gmail.com> wrote: > Actually this is already fixed by the previous fix. Jorge and I are > going to write some new tests. > > Lukas > > On 8 March 2010 14:50, Lukas Renggli <renggli(a)gmail.com> wrote: >> Erwann just noticed another kind of serious shadowing bug. >> >> The closure compiler allows to declare methods like the following: >> >> foo: self >> Â Â | super thisContext true false nil | >> Â Â ^ super := thisContext := true := false := nil := self >> >> These argument and temporary names should all be disallowed as all >> other Smalltalk compiler do (and also the pre closure one in Pharo >> did). Using the implicit variables as argument or temp names leads to >> absolutely unmaintainable code. >> >> Lukas >> >> On 5 March 2010 12:16, Lukas Renggli <renggli(a)gmail.com> wrote: >>> The problem is that some ancestor versions disappeared, what makes it >>> impossible to merge. We've manually integrated the delta into: >>> >>> Name: Tests-lr.79 >>> Author: lr >>> Time: 5 March 2010, 12:16:05 pm >>> UUID: 99f8b58a-0923-4264-9ea6-58fec6cf4d18 >>> Ancestors: Tests-MichaelRueger.78 >>> >>> - merged Jorges Code >>> >>> Lukas >>> >>> On 5 March 2010 11:25, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> Jorge >>>> >>>> could you publish the tests for 1.1 because I could not find my way 11 conflicts for 1.1? >>>> >>>> Stef >>>> >>>> >>>>> Hi Adrian, >>>>> >>>>> Sorry for the delay, too many things today. >>>>> >>>>> Ok, I added 17 test to Tests-Compiler which model the cases of >>>>> shadowing, at least the ones I could come up with. I also modified the >>>>> Encoder>>bindTemp: in order to make it a little bit more intention >>>>> revealing. >>>>> >>>>> My changes are in: >>>>> >>>>> Â Â Â Â Â Â Â Â Â Â Â Compiler-JorgeRessia.144 >>>>> Â Â Â Â Â Â Â Â Â Â Â Tests-JorgeRessia.46 >>>>> >>>>> Some comments: >>>>> >>>>> - In order to test the not interactive mode I had to mock the >>>>> Transcript. I could not find a better solution, if anybody has a >>>>> better one just let me know I'll change it. >>>>> - There is a special case which is that when you are NOT in >>>>> interactive mode if the shadowed variable is a temp then the syntax >>>>> error is triggered as in interactive mode. This is the behavior >>>>> implemented before I did the changes. Is that what we want? >>>>> - I added this test to Tests-Compiler package, I would have preferred >>>>> to add them to Compiler-Tests but there was nothing there. >>>>> >>>>> Cheers, >>>>> >>>>> Jorge >>>>> >>>>> On Thu, Mar 4, 2010 at 8:45 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>>>> Hi Jorge, >>>>>> >>>>>> Just let me know when you think the code is ok for 1.0 or when you have something different that I should integrate. Thanks! >>>>>> >>>>>> Cheers, >>>>>> Adrian >>>>>> >>>>>> On Mar 4, 2010, at 09:37 , Jorge Ressia wrote: >>>>>> >>>>>>> Hi Adrian, >>>>>>> >>>>>>> Yep, I have the same problem as you. My idea was to make it work as >>>>>>> before without completely changing it. Basically because I did not >>>>>>> have the test support to validate my changes. >>>>>>> Anyhow, what I propose is to write a bunch of tests for every case >>>>>>> that we know and then if new cases show up add them to the test suite. >>>>>>> And then play with the code. >>>>>>> >>>>>>> I will work on that today, is that ok? >>>>>>> >>>>>>> For the explanation of what is going on is that now node can be an >>>>>>> instance variable node, then the behavior that was there was not >>>>>>> appropriate in the sense that instance variable nodes do not >>>>>>> understand #scope. >>>>>>> However, why this validation "(node isTemp or: [requestor >>>>>>> interactive])" was there in the first place is not that clear to me, >>>>>>> but it's been there since 1999. >>>>>>> >>>>>>> I'll try to build the tests and come up with a better solution. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Jorge >>>>>>> >>>>>>> On Thu, Mar 4, 2010 at 9:14 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>>>>>> Jorge, >>>>>>>> >>>>>>>> I looked at the code to integrate in 1.0. And I really have troubles understanding it (even after drawing a boolean table for the different combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning is shown when node isTemp is false and requestor interactive is true? Is the comment still accurate? >>>>>>>> >>>>>>>> This is the code: >>>>>>>> >>>>>>>> "When non-interactive raise the error only if its a duplicate" >>>>>>>> (node isTemp or: [requestor interactive]) >>>>>>>> Â Â Â Â ifTrue:[ ((node isTemp) and: [node scope <= 0] ) >>>>>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [^self notify:'Name is already defined' ]] >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Adrian >>>>>>>> >>>>>>>> On Mar 3, 2010, at 20:47 , StÃ©phane Ducasse wrote: >>>>>>>> >>>>>>>>> 11243 >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> - Issue 2102: Fix the fact that local temp can shadow silently instance var --- fixed >>>>>>>>> Â Â Â Problem fixed: >>>>>>>>> We cannot have twice the same block arg in a method >>>>>>>>> >>>>>>>>> Â Â Â [:each | each ...] >>>>>>>>> Â Â Â [:each | each ...] >>>>>>>>> >>>>>>>>> THANKS jorge :) >>>>>>>>> Do you like good bio beer? >>>>>>>>> >>>>>>>>> Stef >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Pharo-project mailing list >>>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > -- Lukas Renggli http://www.lukas-renggli.ch

March 8, 2010

Re: [Pharo-project] [update 1.1] #11243

by Lukas Renggli

Actually this is already fixed by the previous fix. Jorge and I are going to write some new tests. Lukas On 8 March 2010 14:50, Lukas Renggli <renggli(a)gmail.com> wrote: > Erwann just noticed another kind of serious shadowing bug. > > The closure compiler allows to declare methods like the following: > > foo: self > Â Â | super thisContext true false nil | > Â Â ^ super := thisContext := true := false := nil := self > > These argument and temporary names should all be disallowed as all > other Smalltalk compiler do (and also the pre closure one in Pharo > did). Using the implicit variables as argument or temp names leads to > absolutely unmaintainable code. > > Lukas > > On 5 March 2010 12:16, Lukas Renggli <renggli(a)gmail.com> wrote: >> The problem is that some ancestor versions disappeared, what makes it >> impossible to merge. We've manually integrated the delta into: >> >> Name: Tests-lr.79 >> Author: lr >> Time: 5 March 2010, 12:16:05 pm >> UUID: 99f8b58a-0923-4264-9ea6-58fec6cf4d18 >> Ancestors: Tests-MichaelRueger.78 >> >> - merged Jorges Code >> >> Lukas >> >> On 5 March 2010 11:25, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Jorge >>> >>> could you publish the tests for 1.1 because I could not find my way 11 conflicts for 1.1? >>> >>> Stef >>> >>> >>>> Hi Adrian, >>>> >>>> Sorry for the delay, too many things today. >>>> >>>> Ok, I added 17 test to Tests-Compiler which model the cases of >>>> shadowing, at least the ones I could come up with. I also modified the >>>> Encoder>>bindTemp: in order to make it a little bit more intention >>>> revealing. >>>> >>>> My changes are in: >>>> >>>> Â Â Â Â Â Â Â Â Â Â Â Compiler-JorgeRessia.144 >>>> Â Â Â Â Â Â Â Â Â Â Â Tests-JorgeRessia.46 >>>> >>>> Some comments: >>>> >>>> - In order to test the not interactive mode I had to mock the >>>> Transcript. I could not find a better solution, if anybody has a >>>> better one just let me know I'll change it. >>>> - There is a special case which is that when you are NOT in >>>> interactive mode if the shadowed variable is a temp then the syntax >>>> error is triggered as in interactive mode. This is the behavior >>>> implemented before I did the changes. Is that what we want? >>>> - I added this test to Tests-Compiler package, I would have preferred >>>> to add them to Compiler-Tests but there was nothing there. >>>> >>>> Cheers, >>>> >>>> Jorge >>>> >>>> On Thu, Mar 4, 2010 at 8:45 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>>> Hi Jorge, >>>>> >>>>> Just let me know when you think the code is ok for 1.0 or when you have something different that I should integrate. Thanks! >>>>> >>>>> Cheers, >>>>> Adrian >>>>> >>>>> On Mar 4, 2010, at 09:37 , Jorge Ressia wrote: >>>>> >>>>>> Hi Adrian, >>>>>> >>>>>> Yep, I have the same problem as you. My idea was to make it work as >>>>>> before without completely changing it. Basically because I did not >>>>>> have the test support to validate my changes. >>>>>> Anyhow, what I propose is to write a bunch of tests for every case >>>>>> that we know and then if new cases show up add them to the test suite. >>>>>> And then play with the code. >>>>>> >>>>>> I will work on that today, is that ok? >>>>>> >>>>>> For the explanation of what is going on is that now node can be an >>>>>> instance variable node, then the behavior that was there was not >>>>>> appropriate in the sense that instance variable nodes do not >>>>>> understand #scope. >>>>>> However, why this validation "(node isTemp or: [requestor >>>>>> interactive])" was there in the first place is not that clear to me, >>>>>> but it's been there since 1999. >>>>>> >>>>>> I'll try to build the tests and come up with a better solution. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Jorge >>>>>> >>>>>> On Thu, Mar 4, 2010 at 9:14 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>>>>> Jorge, >>>>>>> >>>>>>> I looked at the code to integrate in 1.0. And I really have troubles understanding it (even after drawing a boolean table for the different combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning is shown when node isTemp is false and requestor interactive is true? Is the comment still accurate? >>>>>>> >>>>>>> This is the code: >>>>>>> >>>>>>> "When non-interactive raise the error only if its a duplicate" >>>>>>> (node isTemp or: [requestor interactive]) >>>>>>> Â Â Â Â ifTrue:[ ((node isTemp) and: [node scope <= 0] ) >>>>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [^self notify:'Name is already defined' ]] >>>>>>> >>>>>>> Cheers, >>>>>>> Adrian >>>>>>> >>>>>>> On Mar 3, 2010, at 20:47 , StÃ©phane Ducasse wrote: >>>>>>> >>>>>>>> 11243 >>>>>>>> ----- >>>>>>>> >>>>>>>> - Issue 2102: Fix the fact that local temp can shadow silently instance var --- fixed >>>>>>>> Â Â Â Problem fixed: >>>>>>>> We cannot have twice the same block arg in a method >>>>>>>> >>>>>>>> Â Â Â [:each | each ...] >>>>>>>> Â Â Â [:each | each ...] >>>>>>>> >>>>>>>> THANKS jorge :) >>>>>>>> Do you like good bio beer? >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > -- Lukas Renggli http://www.lukas-renggli.ch

March 8, 2010

Re: [Pharo-project] [update 1.1] #11243

by Lukas Renggli

Erwann just noticed another kind of serious shadowing bug. The closure compiler allows to declare methods like the following: foo: self | super thisContext true false nil | ^ super := thisContext := true := false := nil := self These argument and temporary names should all be disallowed as all other Smalltalk compiler do (and also the pre closure one in Pharo did). Using the implicit variables as argument or temp names leads to absolutely unmaintainable code. Lukas On 5 March 2010 12:16, Lukas Renggli <renggli(a)gmail.com> wrote: > The problem is that some ancestor versions disappeared, what makes it > impossible to merge. We've manually integrated the delta into: > > Name: Tests-lr.79 > Author: lr > Time: 5 March 2010, 12:16:05 pm > UUID: 99f8b58a-0923-4264-9ea6-58fec6cf4d18 > Ancestors: Tests-MichaelRueger.78 > > - merged Jorges Code > > Lukas > > On 5 March 2010 11:25, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Jorge >> >> could you publish the tests for 1.1 because I could not find my way 11 conflicts for 1.1? >> >> Stef >> >> >>> Hi Adrian, >>> >>> Sorry for the delay, too many things today. >>> >>> Ok, I added 17 test to Tests-Compiler which model the cases of >>> shadowing, at least the ones I could come up with. I also modified the >>> Encoder>>bindTemp: in order to make it a little bit more intention >>> revealing. >>> >>> My changes are in: >>> >>> Â Â Â Â Â Â Â Â Â Â Â Compiler-JorgeRessia.144 >>> Â Â Â Â Â Â Â Â Â Â Â Tests-JorgeRessia.46 >>> >>> Some comments: >>> >>> - In order to test the not interactive mode I had to mock the >>> Transcript. I could not find a better solution, if anybody has a >>> better one just let me know I'll change it. >>> - There is a special case which is that when you are NOT in >>> interactive mode if the shadowed variable is a temp then the syntax >>> error is triggered as in interactive mode. This is the behavior >>> implemented before I did the changes. Is that what we want? >>> - I added this test to Tests-Compiler package, I would have preferred >>> to add them to Compiler-Tests but there was nothing there. >>> >>> Cheers, >>> >>> Jorge >>> >>> On Thu, Mar 4, 2010 at 8:45 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>> Hi Jorge, >>>> >>>> Just let me know when you think the code is ok for 1.0 or when you have something different that I should integrate. Thanks! >>>> >>>> Cheers, >>>> Adrian >>>> >>>> On Mar 4, 2010, at 09:37 , Jorge Ressia wrote: >>>> >>>>> Hi Adrian, >>>>> >>>>> Yep, I have the same problem as you. My idea was to make it work as >>>>> before without completely changing it. Basically because I did not >>>>> have the test support to validate my changes. >>>>> Anyhow, what I propose is to write a bunch of tests for every case >>>>> that we know and then if new cases show up add them to the test suite. >>>>> And then play with the code. >>>>> >>>>> I will work on that today, is that ok? >>>>> >>>>> For the explanation of what is going on is that now node can be an >>>>> instance variable node, then the behavior that was there was not >>>>> appropriate in the sense that instance variable nodes do not >>>>> understand #scope. >>>>> However, why this validation "(node isTemp or: [requestor >>>>> interactive])" was there in the first place is not that clear to me, >>>>> but it's been there since 1999. >>>>> >>>>> I'll try to build the tests and come up with a better solution. >>>>> >>>>> Cheers, >>>>> >>>>> Jorge >>>>> >>>>> On Thu, Mar 4, 2010 at 9:14 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>>>> Jorge, >>>>>> >>>>>> I looked at the code to integrate in 1.0. And I really have troubles understanding it (even after drawing a boolean table for the different combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning is shown when node isTemp is false and requestor interactive is true? Is the comment still accurate? >>>>>> >>>>>> This is the code: >>>>>> >>>>>> "When non-interactive raise the error only if its a duplicate" >>>>>> (node isTemp or: [requestor interactive]) >>>>>> Â Â Â Â ifTrue:[ ((node isTemp) and: [node scope <= 0] ) >>>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [^self notify:'Name is already defined' ]] >>>>>> >>>>>> Cheers, >>>>>> Adrian >>>>>> >>>>>> On Mar 3, 2010, at 20:47 , StÃ©phane Ducasse wrote: >>>>>> >>>>>>> 11243 >>>>>>> ----- >>>>>>> >>>>>>> - Issue 2102: Fix the fact that local temp can shadow silently instance var --- fixed >>>>>>> Â Â Â Problem fixed: >>>>>>> We cannot have twice the same block arg in a method >>>>>>> >>>>>>> Â Â Â [:each | each ...] >>>>>>> Â Â Â [:each | each ...] >>>>>>> >>>>>>> THANKS jorge :) >>>>>>> Do you like good bio beer? >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > -- Lukas Renggli http://www.lukas-renggli.ch

March 8, 2010

[Pharo-project] about the hudson server

by stephane ducasse

Hi yanni I wanted to know if you can tell us what means (unstable) in the report summary http://hudson.jooshr.org/job/Pharo1.1/81/ is it because the tests cannot run? Stef

March 8, 2010