January 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] Updated Polymorph

by Gary Chambers

Got annoyed with the PreferenceBrowser not fully tying in with themes so have reworked it a bit. Interesting to see that less code is needed when utilising the theme helper methods. Done as overrides for Squeak compatability, of course. Really need to start thinking of the base being Pharo with patches for Squeak though. Polymorph-Widgets-gvc.33 on SqueakSource. Regards, Gary.

Jan. 27, 2009

Re: [Pharo-project] why #ifNotNil: accepts parameter?

by StÃ©phane Ducasse

On Jan 27, 2009, at 5:04 PM, Esteban Lorenzano wrote: > Very interesting stef, thanks a lot... > > but now, I'm not sure of what I did with OB-Tools (I just replace > ifNotNil: [ :blah | ... ] with ifNotNilDo: [ :blah | ... ]... I > understand why the first version of ifNotNil: is done like that in > pharo... but what I do with compatibility? will pharo still support > ifNotNilDo:? > And, I also agree with lukas. blahDo: is ugly, if you have an elegant > solution... but, what I have to do with OB-Tools? I replace methods > (like before) or better I create a package OB-Tools-Squeak with > extensions for Squeak? > > I know... this is hardly a "pharo issue", but maybe can provide pharo > developers of clues of what to do if they are trying to keep > compatibiity (I know, that's not a pharo goal -compatibility-, but > sometimes may be necessary). May be package extensions separately. By accident have you seen the dates of the fixes proposed by vassili 2007 this is not that long compared to the changes of compiled method that we are waiting since at least 2001. So this is why changing is important. But changing for better :) Stef > > > Cheers, > Esteban > > On 2009-01-27 13:09:30 -0200, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> said: > >> I found this blog entry really nice on this specific question. >> >> http://blog.3plus4.org/2007/04/ >> >> >> On Jan 27, 2009, at 1:44 PM, Esteban Lorenzano wrote: >> >>> Hi, >>> I'm trying to understand why pharo modifies squeak behavior of >>> ifNotNil: and introduces the optional parameter... is there a >>> reason? >>> >>> Cheers, >>> Esteban >>> >>> >>> >>> _______________________________________________ >>> 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 >

Jan. 27, 2009

Re: [Pharo-project] why #ifNotNil: accepts parameter?

by Lukas Renggli

> And, I also agree with lukas. blahDo: is ugly, if you have an elegant > solution... but, what I have to do with OB-Tools? I replace methods > (like before) or better I create a package OB-Tools-Squeak with > extensions for Squeak? I guess the best is to follow the Seaside coding conventions (http://www.seaside.st/community/conventions) for cross platform code like OB-Tools. You might also want to use Slime (http://www.lukas-renggli.ch/blog/slime) because it automatically fixes simple issues like the #ifNotNilDo: thing. Also keep in mind that OB-Tools is supposed to run on GemStone , so better not use #ifNotNilDo:. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 27, 2009

Re: [Pharo-project] why #ifNotNil: accepts parameter?

by Esteban Lorenzano

Very interesting stef, thanks a lot... but now, I'm not sure of what I did with OB-Tools (I just replace ifNotNil: [Â :blah |Â ... ] with ifNotNilDo: [ :blah |Â ... ]... I understand why the first version of ifNotNil: is done like that in pharo... but what I do with compatibility? will pharo still support ifNotNilDo:? And, I also agree with lukas. blahDo: is ugly, if you have an elegant solution... but, what I have to do with OB-Tools? I replace methods (like before) or better I create a package OB-Tools-Squeak with extensions for Squeak? I know... this is hardly a "pharo issue", but maybe can provide pharo developers of clues of what to do if they are trying to keep compatibiity (I know, that's not a pharo goal -compatibility-, but sometimes may be necessary). Cheers, Esteban On 2009-01-27 13:09:30 -0200, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> said: > I found this blog entry really nice on this specific question. > > http://blog.3plus4.org/2007/04/ > > > On Jan 27, 2009, at 1:44 PM, Esteban Lorenzano wrote: > >> Hi, >> I'm trying to understand why pharo modifies squeak behavior of >> ifNotNil: and introduces the optional parameter... is there a reason? >> >> Cheers, >> Esteban >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 27, 2009

Re: [Pharo-project] why #ifNotNil: accepts parameter?

by StÃ©phane Ducasse

I found this blog entry really nice on this specific question. http://blog.3plus4.org/2007/04/ On Jan 27, 2009, at 1:44 PM, Esteban Lorenzano wrote: > Hi, > I'm trying to understand why pharo modifies squeak behavior of > ifNotNil: and introduces the optional parameter... is there a reason? > > Cheers, > Esteban > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 27, 2009

Re: [Pharo-project] why #ifNotNil: accepts parameter?

by Esteban Lorenzano

On 2009-01-27 11:05:49 -0200, Lukas Renggli <renggli(a)gmail.com> said: >> I'm trying to understand why pharo modifies squeak behavior of >> ifNotNil: and introduces the optional parameter... is there a reason? > > Squeak for that matter is incompatible with all other existing > Smalltalk implementations. Luckily that was changed in Pharo. the > compiler can easily figure out if an argument needs to be passed into > the block or not. There is really no need for all these ugly #...Do: > methods. > > Lukas Yes, I understand... but now I have a compatibility issue with OB-Tools (works on pharo, doesn't works on squeak) :( Anyway, I understand :) Cheers, Esteban

Jan. 27, 2009

Re: [Pharo-project] why #ifNotNil: accepts parameter?

by Lukas Renggli

> I'm trying to understand why pharo modifies squeak behavior of > ifNotNil: and introduces the optional parameter... is there a reason? Squeak for that matter is incompatible with all other existing Smalltalk implementations. Luckily that was changed in Pharo. the compiler can easily figure out if an argument needs to be passed into the block or not. There is really no need for all these ugly #...Do: methods. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 27, 2009

[Pharo-project] why #ifNotNil: accepts parameter?

by Esteban Lorenzano

Hi, I'm trying to understand why pharo modifies squeak behavior of ifNotNil: and introduces the optional parameter... is there a reason? Cheers, Esteban

Jan. 27, 2009

[Pharo-project] New pharo dev

by Damien Cassou

Based on 10213: https://gforge.inria.fr/frs/download.php/16049/pharo0.1-10213dev09.01.3.zip -- Damien Cassou http://damiencassou.seasidehosting.st

Jan. 27, 2009

Re: [Pharo-project] Writing a conditions for breakpoint

by Igor Stasenko

2009/1/27 Gary Chambers <gazzaguru2(a)btinternet.com>: > > ----- Original Message ----- > From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, January 27, 2009 12:01 AM > Subject: Re: [Pharo-project] Writing a conditions for breakpoint > > >> 2009/1/27 Igor Stasenko <siguctua(a)gmail.com>: >>> 2009/1/27 Gary Chambers <gazzaguru2(a)btinternet.com>: >>>> If I remember rightly the existing breakpoint scheme just recompiled the >>>> method without source logging. Naturally you could get into a horrible >>>> mess >>>> with the source not matching the bytecodes. >>>> >>>> Just a thought. Since that, I believe, was why "breakpoints" were >>>> considered >>>> broken. >>>> >>> >>> I'm using different approach by changing the method in method's >>> dictionary without doing any change in original compiled method. > > > Isn't replacing the method dictionary entry the same as replacing the > compiled method? > nearly the same, except that you don't need to deal with bytecodes and hack method to get what you need. I forgot to add - i'm using a squeak's 'object as method' feature, so it not requires to do hard work with compiler or generating synthetic method with custom bytecodes, which doesn't match the source. > >>> Then, once your program runs to the point of method invocation - its >>> intercepted ,and there are a number of choices: >>> - break into debugger >>> - continue running as usual >>> etc. >>> >>> This is enough for start (you can set a breakpoint on method >>> entry/exit, but can't place break inside of method's body). >>> For more advanced, it would require step by step execution of method's >>> bytecodes (in same way as debugger doing this), then you can pick any >>> bytecode position to place a break there. This can be possible only in >>> a good cooperation with debugger - because for placing breakpoint >>> inside a method body you need to provide a UI to select the place by >>> showing a user the method source, and then interpreting user's input >>> to a bytecode position. >>> >>> I think being able to break at method entry/exit is well enough to >>> cover about 99% of all cases where you need breakpoints (remember - >>> this is smalltalk and methods tend to be very short). >>> The rest 1% you may require only if you want to debug a bytecodes. >>> >> >> Even more, i think going so deep (enable breaks in method's body) its >> not worth efforts - in the end, user can always choose to write 'self >> halt' at any place he may need to. Without any extra efforts from our >> side :) >> >>>> Regards, Gary. >>>> >>>> ----- Original Message ----- >>>> From: Mariano Martinez Peck >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Sent: Monday, January 26, 2009 9:33 PM >>>> Subject: Re: [Pharo-project] Writing a conditions for breakpoint >>>> >>>>> >>>>> here, i'm speaking about setting breakpoints using UI i.e. without >>>>> changing the method. >>>>> I wrote a simple OB-based breakpoint manager, where you can edit >>>>> breakpoints list and possibly set a condition to break. >>>>> Of course, you can always put 'wand isZapped ifTrue: [self halt]' in >>>>> any method, but this having one huge drawback: >>>>> once you modify the method, a change is recorded into .changes, as >>>>> well as many other parts of the system get notified about such change. >>>>> But we don't want to mark packages modified, nor unnecessary pollute >>>>> .changes file only because we need to test some functionality (by >>>>> putting a breakpoint), right? >>>>> Because such practice makes harder to manage the source code (you >>>>> forced to always get back to places where you put the halt to remove >>>>> it, and this is a bit annoying). >>>> >>>> >>>> +1 100% >>>> >>>>> >>>>> > -- >>>>> > Damien Cassou >>>>> > http://damiencassou.seasidehosting.st >>>>> > >>>>> > _______________________________________________ >>>>> > 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. >>>>> >>>>> _______________________________________________ >>>>> 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. >>> >> >> >> >> -- >> 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 > -- Best regards, Igor Stasenko AKA sig.

Jan. 27, 2009