March 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Add Alien in 1.1 (Issue 1360)

by Schmidt, Marco

I have updated issue 1360 with a zip file containing my current build. The zip-File was too large for the mailing list... Marco Schmidt

March 5, 2010

[Pharo-project] [update 1.1] #11244

by StÃ©phane Ducasse

- remove the default password squeak in the MCHttpRepository creation template - Introduction of tests for validating the different use cases of Shadowing in CompilerTest. - Improvement in the Encoder>>bindTemp: method in order to make explicit the decisions Thanks Jorge and lukas :)

March 5, 2010

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

by StÃ©phane Ducasse

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

March 5, 2010

[Pharo-project] AlienPlugin

by StÃ©phane Ducasse

Excellent marco!!!!! This is an excellent news! Stef Begin forwarded message: > From: "Schmidt, Marco" <Marco.Schmidt(a)eads.com> > Date: March 5, 2010 11:06:10 AM GMT+01:00 > To: <Pharo-project(a)lists.gforge.inria.fr> > Subject: Test Alien on Win32... > > > Finally I had time to give AlienPlugin another try under Win32. Here it is. At the moment Iâm testing and building an interface to libcurl. > My work is based on the current vm-source (Andreas Raab, version 3.11.5) with some modifications harvested from the newspeak-source code. I have a local git-repository with all patches needed ready to review and integrate. Should we use github to mirror the squeakvm-repo? > > Marco Schmidt

March 5, 2010

Re: [Pharo-project] Having fun with booleans

by Igor Stasenko

On 5 March 2010 11:17, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > > Den 05.03.2010 10:08, skrev Peter Hugosson-Miller: >> On 5 mar 2010, at 09.33, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: >> >> >>> The problem is the side effects, is suddenly Boolean>>and: stops to >>> be lazy. >>> Possibly evaluating blocks that shouldn't be evaluated. >>> >> No, but there is one subtle difference anyway: both #and: and #or: >> will return a Boolean (the receiver) if the block argument isn't >> executed, whereas #ifTrue: and #ifFalse: will return nil in that case. >> So if you do something with the return value, then the bytecode will >> be different for sure. >> >> But it's academic anyway: the use of #and: and #or: gives the reader a >> very strong hint that the argument block (if executed) is supposed to >> return a Boolean, so to use it purely for branching in the code could >> be seen as misleading. >> >> -- >> Cheers, >> Peter >> > I like that argument turned on its head, namely that ifTrue: ifFalse: > gives the reader a very strong hint that the argument blocks are used > purely for branching, thus using them to (eventually) return a boolean > can be seen as misleading :) > > i.e. I tend to prefer to use Igors and: example for code I often see written > > a < b ifTrue: [... a couple of actions, then returning true or false ...] > Â Â Â Â ifFalse: [^false] > yes, sometimes i find it inconvenient ,that i can't do chaining: (a<b ifTrue: [ self foo. c<d ]) ifTrue: [ ... ] since #ifTrue: answers nil if condition evaluated to false. > Cheers, > Henry >> >>> Fernando >>> >>> On Mar 5, 2010, at 8:22 AM, Igor Stasenko wrote: >>> >>> >>>> Hello, >>>> I just realized, that one can completely avoid using ifTrue/ifFalse >>>> branches, but use #or: and #and: instead. >>>> >>>> a > b ifTrue: [ ... ] >>>> could be written as: >>>> a > b and: [ ... ] >>>> >>>> a > b ifFalse: [ ... ] >>>> could be written as: >>>> a > b or: [ ... ] >>>> >>>> and >>>> a > b ifTrue: [ self foo ] ifFalse: [ self bar ] >>>> could be written as: >>>> >>>> a > b and: [ self foo]; or:[ self bar ] >>>> >>>> :) >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> 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 > -- Best regards, Igor Stasenko AKA sig.

March 5, 2010

Re: [Pharo-project] Having fun with booleans

by Peter Hugosson-Miller

On 5 mar 2010, at 10.17, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > > Den 05.03.2010 10:08, skrev Peter Hugosson-Miller: >> On 5 mar 2010, at 09.33, Fernando olivero <oliverof(a)lu.unisi.ch> >> wrote: >> >> >>> The problem is the side effects, is suddenly Boolean>>and: stops to >>> be lazy. >>> Possibly evaluating blocks that shouldn't be evaluated. >>> >> No, but there is one subtle difference anyway: both #and: and #or: >> will return a Boolean (the receiver) if the block argument isn't >> executed, whereas #ifTrue: and #ifFalse: will return nil in that >> case. >> So if you do something with the return value, then the bytecode will >> be different for sure. >> >> But it's academic anyway: the use of #and: and #or: gives the >> reader a >> very strong hint that the argument block (if executed) is supposed to >> return a Boolean, so to use it purely for branching in the code could >> be seen as misleading. >> >> -- >> Cheers, >> Peter >> > I like that argument turned on its head, namely that ifTrue: ifFalse: > gives the reader a very strong hint that the argument blocks are used > purely for branching, thus using them to (eventually) return a boolean > can be seen as misleading :) > > i.e. I tend to prefer to use Igors and: example for code I often see > written > > a < b ifTrue: [... a couple of actions, then returning true or > false ...] > ifFalse: [^false] And I'm definitely with you on that score! In fact it's how I decide which method to use :-) -- Cheers, Peter > Cheers, > Henry >> >>> Fernando >>> >>> On Mar 5, 2010, at 8:22 AM, Igor Stasenko wrote: >>> >>> >>>> Hello, >>>> I just realized, that one can completely avoid using ifTrue/ifFalse >>>> branches, but use #or: and #and: instead. >>>> >>>> a > b ifTrue: [ ... ] >>>> could be written as: >>>> a > b and: [ ... ] >>>> >>>> a > b ifFalse: [ ... ] >>>> could be written as: >>>> a > b or: [ ... ] >>>> >>>> and >>>> a > b ifTrue: [ self foo ] ifFalse: [ self bar ] >>>> could be written as: >>>> >>>> a > b and: [ self foo]; or:[ self bar ] >>>> >>>> :) >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> 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

March 5, 2010

Re: [Pharo-project] Having fun with booleans

by Henrik Johansen

Den 05.03.2010 10:08, skrev Peter Hugosson-Miller: > On 5 mar 2010, at 09.33, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > > >> The problem is the side effects, is suddenly Boolean>>and: stops to >> be lazy. >> Possibly evaluating blocks that shouldn't be evaluated. >> > No, but there is one subtle difference anyway: both #and: and #or: > will return a Boolean (the receiver) if the block argument isn't > executed, whereas #ifTrue: and #ifFalse: will return nil in that case. > So if you do something with the return value, then the bytecode will > be different for sure. > > But it's academic anyway: the use of #and: and #or: gives the reader a > very strong hint that the argument block (if executed) is supposed to > return a Boolean, so to use it purely for branching in the code could > be seen as misleading. > > -- > Cheers, > Peter > I like that argument turned on its head, namely that ifTrue: ifFalse: gives the reader a very strong hint that the argument blocks are used purely for branching, thus using them to (eventually) return a boolean can be seen as misleading :) i.e. I tend to prefer to use Igors and: example for code I often see written a < b ifTrue: [... a couple of actions, then returning true or false ...] ifFalse: [^false] Cheers, Henry > >> Fernando >> >> On Mar 5, 2010, at 8:22 AM, Igor Stasenko wrote: >> >> >>> Hello, >>> I just realized, that one can completely avoid using ifTrue/ifFalse >>> branches, but use #or: and #and: instead. >>> >>> a > b ifTrue: [ ... ] >>> could be written as: >>> a > b and: [ ... ] >>> >>> a > b ifFalse: [ ... ] >>> could be written as: >>> a > b or: [ ... ] >>> >>> and >>> a > b ifTrue: [ self foo ] ifFalse: [ self bar ] >>> could be written as: >>> >>> a > b and: [ self foo]; or:[ self bar ] >>> >>> :) >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 > > >

March 5, 2010

Re: [Pharo-project] Having fun with booleans

by Peter Hugosson-Miller

On 5 mar 2010, at 09.33, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > The problem is the side effects, is suddenly Boolean>>and: stops to > be lazy. > Possibly evaluating blocks that shouldn't be evaluated. No, but there is one subtle difference anyway: both #and: and #or: will return a Boolean (the receiver) if the block argument isn't executed, whereas #ifTrue: and #ifFalse: will return nil in that case. So if you do something with the return value, then the bytecode will be different for sure. But it's academic anyway: the use of #and: and #or: gives the reader a very strong hint that the argument block (if executed) is supposed to return a Boolean, so to use it purely for branching in the code could be seen as misleading. -- Cheers, Peter > Fernando > > On Mar 5, 2010, at 8:22 AM, Igor Stasenko wrote: > >> Hello, >> I just realized, that one can completely avoid using ifTrue/ifFalse >> branches, but use #or: and #and: instead. >> >> a > b ifTrue: [ ... ] >> could be written as: >> a > b and: [ ... ] >> >> a > b ifFalse: [ ... ] >> could be written as: >> a > b or: [ ... ] >> >> and >> a > b ifTrue: [ self foo ] ifFalse: [ self bar ] >> could be written as: >> >> a > b and: [ self foo]; or:[ self bar ] >> >> :) >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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

March 5, 2010

Re: [Pharo-project] About danny help :)

by StÃ©phane Ducasse

On Mar 5, 2010, at 7:50 AM, Danny Chan wrote: > >>> <classcomment> >>> Here comes the comment for the class >>> </classcomment> >> >> Why XML? > > No special reason, just made up something, so that both a normal class comment > and the big picture documentation for the package can coexist. > > >> In addition I would like to have a tag for promoting test to be list in the >> help. <documentation> > > Hm, I just thought about this: Why not have one pragma, call it <help:>, that > takes as an argument some kind of string encoded path, for example for a test > with a nice example something like this: > > testInstanceCreation > <help: 'Examples/Instance Creation'> > > "Here we show some different ways to create new instances" > > ... > > And then in addition to API documentation that strictly follows the class > structure we have dynamically generated books that are structured along the > help pragmas. Yes!! I proposed that several times already. Could be prefixed automatically by the package in which the method is defined. > > Danny > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 5, 2010

Re: [Pharo-project] Having fun with booleans

by Fernando olivero

The problem is the side effects, is suddenly Boolean>>and: stops to be lazy. Possibly evaluating blocks that shouldn't be evaluated. Fernando On Mar 5, 2010, at 8:22 AM, Igor Stasenko wrote: > Hello, > I just realized, that one can completely avoid using ifTrue/ifFalse > branches, but use #or: and #and: instead. > > a > b ifTrue: [ ... ] > could be written as: > a > b and: [ ... ] > > a > b ifFalse: [ ... ] > could be written as: > a > b or: [ ... ] > > and > a > b ifTrue: [ self foo ] ifFalse: [ self bar ] > could be written as: > > a > b and: [ self foo]; or:[ self bar ] > > :) > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 5, 2010