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

Re: [Pharo-project] [update] #10492 (1.0rc1)

by Niko Schwarz

Well, by doing that you will confuse users that only relied on the consensual functionality of asNumber. It's difficult both ways, and because of that, I'd suggest going the lazy way and not helping the users other than by adding a comment to #asNumber which explains the evolution of the message and points to #squeezeOutNumber. I know that the users would appreciate help in the migration, but I don't see a non-obtrusive way to do so. Cheers, Niko On Tue, Oct 27, 2009 at 2:59 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Not really > > we could do the following > Â Â Â Â - check all the users of asNumber and let them as asNUmber or > squeezeOutNumber > Â Â Â Â - then put a deprecation during the alpha phase that state that they > should pay attention > Â Â Â Â - when we are in rc 1.1 we remove the deprecation > Â Â Â Â - create a package which would override it with a deprecation. > > stef > > > On Oct 27, 2009, at 2:38 PM, Niko Schwarz wrote: > >> Well, what do you propose? Deprecating asNumber calls altogether? >> >> Cheers, >> >> Niko >> >> On Sat, Oct 24, 2009 at 10:32 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Yes a good deprecation is needed. >>> >>> Stef >>> On Oct 24, 2009, at 11:13 AM, Adrian Lienhard wrote: >>> >>>> Sounds ok. At the same time as integrating the change, all senders >>>> of >>>> asNumber in the image need to be checked and adapted to the new >>>> semantics if necessary. IIRC MC was not properly working after the >>>> change. Also, users and maintainers of external packages should be >>>> made aware of the change since it may break their code. >>>> >>>> Adrian >>>> >>>> On Oct 24, 2009, at 10:46 , StÃ©phane Ducasse wrote: >>>> >>>>> Thanks niko >>>>> >>>>> So does everybody agree with >>>>> Â Â Â asNumber raising an error >>>>> Â Â Â and >>>>> Â Â Â squeezeOutNumber >>>>> >>>>> I like the proposal. >>>>> >>>>> Stef >>>>> >>>>> On Oct 24, 2009, at 10:30 AM, Niko Schwarz wrote: >>>>> >>>>>> Hi all, I made a follow-up patch like discussed on the workshop. >>>>>> Now >>>>>> porting becomes as easy as changing "asNumber" to >>>>>> "squeezeOutNumber". >>>>>> >>>>>> Name: SLICE-issue-1258-squeezeOutNumber-NikoSchwarz.2 >>>>>> >>>>>> >>>>>> This slice adds squeezeNumberOutOfString: to Number, as >>>>>> discussed in >>>>>> the Pharo workshop. On the way, it >>>>>> fixes an issue in SqNumberParser, where it would return itself >>>>>> rather >>>>>> than the result of the failblack, when >>>>>> parsing fails. >>>>>> >>>>>> Also, a test is added to test and document the new squeezing >>>>>> number >>>>>> out of strings behavior. >>>>>> >>>>>> Example usage: >>>>>> >>>>>> Â Â Â self assert: '123blabla' squeezeOutNumber equals: 123. >>>>>> Â Â self assert: 'blabla123' squeezeOutNumber equals: 123. >>>>>> Â Â self assert: 'blabla12blabla' squeezeOutNumber equals: 12. >>>>>> Â Â self assert: ('12.3bla' squeezeOutNumber -12.3 ) abs < 0.0001. >>>>>> Â Â self assert: '.1' squeezeOutNumber > 0. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Niko >>>>>> >>>>>> On Tue, Oct 20, 2009 at 2:14 PM, Adrian Lienhard <adi(a)netstyle.ch> >>>>>> wrote: >>>>>>> 10492 (this is the stream of the branch 1.0rc1) >>>>>>> ----- >>>>>>> >>>>>>> - Issue 1320: Â [squeak trunk] Sort the conflicts. This is >>>>>>> required >>>>>>> when >>>>>>> merging a distant version, like Pharo for example... >>>>>>> - Issue 1338: Â HostWindowTests>>testOne is failing in Windows >>>>>>> - Issue 1345: Â Revert Number class>>readFrom: (was integrated >>>>>>> with >>>>>>> issue 1258) >>>>>>> >>>>>>> ___________________ >>>>>>> http://www.adrian-lienhard.ch/ >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 27, 2009

[Pharo-project] OCompletion in the rc1 dev image

by Niko Schwarz

Hi list, in the most recent dev image (9.10.5), OCompletion is broken for me. I lost my reproducible test case, but the gist was that sometimes when OCompletion had no idea which type a temporal variable would be, you were unable to insert code behind that variable, because if you tried, a debugger would show up. The problem appears to be Debugger>guessTypeForName:. debuggerMap can be nil and if it is, the method fails. I changed the method to the following, and then the strange errors that occur on my image disappear: guessTypeForName: aString | index object | index := debuggerMap ifNotNil: [(debuggerMap tempNamesForContext: self selectedContext) indexOf: aString ifAbsent: []]. object := index ifNil: [index := self receiver class allInstVarNames indexOf: aString ifAbsent: []. index ifNil: [^ nil]. self receiver instVarAt: index] ifNotNil: [self selectedContext tempAt: index]. ^ object class Essentially, I leave index at nil, if debugerMap is nil. I don't know enough about OCompletion to tell whether this is a fix, or makes things worse somehow. Cheers, Niko

Oct. 27, 2009

Re: [Pharo-project] [update] #10492 (1.0rc1)

by StÃ©phane Ducasse

Not really we could do the following - check all the users of asNumber and let them as asNUmber or squeezeOutNumber - then put a deprecation during the alpha phase that state that they should pay attention - when we are in rc 1.1 we remove the deprecation - create a package which would override it with a deprecation. stef On Oct 27, 2009, at 2:38 PM, Niko Schwarz wrote: > Well, what do you propose? Deprecating asNumber calls altogether? > > Cheers, > > Niko > > On Sat, Oct 24, 2009 at 10:32 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Yes a good deprecation is needed. >> >> Stef >> On Oct 24, 2009, at 11:13 AM, Adrian Lienhard wrote: >> >>> Sounds ok. At the same time as integrating the change, all senders >>> of >>> asNumber in the image need to be checked and adapted to the new >>> semantics if necessary. IIRC MC was not properly working after the >>> change. Also, users and maintainers of external packages should be >>> made aware of the change since it may break their code. >>> >>> Adrian >>> >>> On Oct 24, 2009, at 10:46 , StÃ©phane Ducasse wrote: >>> >>>> Thanks niko >>>> >>>> So does everybody agree with >>>> asNumber raising an error >>>> and >>>> squeezeOutNumber >>>> >>>> I like the proposal. >>>> >>>> Stef >>>> >>>> On Oct 24, 2009, at 10:30 AM, Niko Schwarz wrote: >>>> >>>>> Hi all, I made a follow-up patch like discussed on the workshop. >>>>> Now >>>>> porting becomes as easy as changing "asNumber" to >>>>> "squeezeOutNumber". >>>>> >>>>> Name: SLICE-issue-1258-squeezeOutNumber-NikoSchwarz.2 >>>>> >>>>> >>>>> This slice adds squeezeNumberOutOfString: to Number, as >>>>> discussed in >>>>> the Pharo workshop. On the way, it >>>>> fixes an issue in SqNumberParser, where it would return itself >>>>> rather >>>>> than the result of the failblack, when >>>>> parsing fails. >>>>> >>>>> Also, a test is added to test and document the new squeezing >>>>> number >>>>> out of strings behavior. >>>>> >>>>> Example usage: >>>>> >>>>> self assert: '123blabla' squeezeOutNumber equals: 123. >>>>> self assert: 'blabla123' squeezeOutNumber equals: 123. >>>>> self assert: 'blabla12blabla' squeezeOutNumber equals: 12. >>>>> self assert: ('12.3bla' squeezeOutNumber -12.3 ) abs < 0.0001. >>>>> self assert: '.1' squeezeOutNumber > 0. >>>>> >>>>> Cheers, >>>>> >>>>> Niko >>>>> >>>>> On Tue, Oct 20, 2009 at 2:14 PM, Adrian Lienhard <adi(a)netstyle.ch> >>>>> wrote: >>>>>> 10492 (this is the stream of the branch 1.0rc1) >>>>>> ----- >>>>>> >>>>>> - Issue 1320: [squeak trunk] Sort the conflicts. This is >>>>>> required >>>>>> when >>>>>> merging a distant version, like Pharo for example... >>>>>> - Issue 1338: HostWindowTests>>testOne is failing in Windows >>>>>> - Issue 1345: Revert Number class>>readFrom: (was integrated >>>>>> with >>>>>> issue 1258) >>>>>> >>>>>> ___________________ >>>>>> http://www.adrian-lienhard.ch/ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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

Oct. 27, 2009

Re: [Pharo-project] [update] #10492 (1.0rc1)

by Niko Schwarz

Well, what do you propose? Deprecating asNumber calls altogether? Cheers, Niko On Sat, Oct 24, 2009 at 10:32 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes a good deprecation is needed. > > Stef > On Oct 24, 2009, at 11:13 AM, Adrian Lienhard wrote: > >> Sounds ok. At the same time as integrating the change, all senders of >> asNumber in the image need to be checked and adapted to the new >> semantics if necessary. IIRC MC was not properly working after the >> change. Also, users and maintainers of external packages should be >> made aware of the change since it may break their code. >> >> Adrian >> >> On Oct 24, 2009, at 10:46 , StÃ©phane Ducasse wrote: >> >>> Thanks niko >>> >>> So does everybody agree with >>> Â Â Â asNumber raising an error >>> Â Â Â and >>> Â Â Â squeezeOutNumber >>> >>> I like the proposal. >>> >>> Stef >>> >>> On Oct 24, 2009, at 10:30 AM, Niko Schwarz wrote: >>> >>>> Hi all, I made a follow-up patch like discussed on the workshop. Now >>>> porting becomes as easy as changing "asNumber" to >>>> "squeezeOutNumber". >>>> >>>> Name: SLICE-issue-1258-squeezeOutNumber-NikoSchwarz.2 >>>> >>>> >>>> This slice adds squeezeNumberOutOfString: to Number, as discussed in >>>> the Pharo workshop. On the way, it >>>> fixes an issue in SqNumberParser, where it would return itself >>>> rather >>>> than the result of the failblack, when >>>> parsing fails. >>>> >>>> Also, a test is added to test and document the new squeezing number >>>> out of strings behavior. >>>> >>>> Example usage: >>>> >>>> Â Â Â self assert: '123blabla' squeezeOutNumber equals: 123. >>>> Â Â self assert: 'blabla123' squeezeOutNumber equals: 123. >>>> Â Â self assert: 'blabla12blabla' squeezeOutNumber equals: 12. >>>> Â Â self assert: ('12.3bla' squeezeOutNumber -12.3 ) abs < 0.0001. >>>> Â Â self assert: '.1' squeezeOutNumber > 0. >>>> >>>> Cheers, >>>> >>>> Niko >>>> >>>> On Tue, Oct 20, 2009 at 2:14 PM, Adrian Lienhard <adi(a)netstyle.ch> >>>> wrote: >>>>> 10492 (this is the stream of the branch 1.0rc1) >>>>> ----- >>>>> >>>>> - Issue 1320: Â [squeak trunk] Sort the conflicts. This is required >>>>> when >>>>> merging a distant version, like Pharo for example... >>>>> - Issue 1338: Â HostWindowTests>>testOne is failing in Windows >>>>> - Issue 1345: Â Revert Number class>>readFrom: (was integrated with >>>>> issue 1258) >>>>> >>>>> ___________________ >>>>> http://www.adrian-lienhard.ch/ >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >

Oct. 27, 2009

Re: [Pharo-project] What happened to InputSensor? -- Pharo by Example Lights Out game is broken

by Lukas Renggli

InputSensor has been replaced with InputEventSensor. The global Sensor points to the right instance in old and new images. Lukas 2009/10/27 Oscar Nierstrasz <oscar(a)iam.unibe.ch>: > > Hi Folks, > > The class InputSensor has mysteriously disappeared between > > PharoCore-1.0-10488-BETA.zip > > and > > PharoCore-1.0-10491rc1.zip > > Does anyone know what happened to it? Â The class is needed by the > First Application chapter in the Pharo by Example book. > > - on > > > _______________________________________________ > 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

Oct. 27, 2009

[Pharo-project] What happened to InputSensor? -- Pharo by Example Lights Out game is broken

by Oscar Nierstrasz

Hi Folks, The class InputSensor has mysteriously disappeared between PharoCore-1.0-10488-BETA.zip and PharoCore-1.0-10491rc1.zip Does anyone know what happened to it? The class is needed by the First Application chapter in the Pharo by Example book. - on

Oct. 27, 2009

Re: [Pharo-project] Preferences refactoring pushed

by Alain Plantec

Michael Rueger wrote: > Alain Plantec wrote: > >> * Remove the annotationPane preference (no more annotation pane in >> browsers and MC) >> * Remove optionalButtons preferences (optional buttons are always >> present except in the ChangeSetSorter) > Hi Michael, > > Very likely I've missed some discussion about this, but I find the > annotation pane incredible useful, not just in the change sorter. I should have said "no more annotation pane in old browser (the one of the core) and in MC." annotation panes from Pharo are still present and untouched by this SLICE. an OB specific setting will have to be declared. Have a look at the issue discussions (Issue 810). <http://code.google.com/p/pharo/issues/detail?id=810> Is it ok like that ? Alain > > I also hate the optional buttons (useless and very bad UI as well > IMHO), but that might just be me used to using short cuts ;-) > > So how is the annotation information accessible in the future? > > Michael > >

Oct. 27, 2009

Re: [Pharo-project] Preferences refactoring pushed

by Michael Rueger

Alain Plantec wrote: > * Remove the annotationPane preference (no more annotation pane in > browsers and MC) > * Remove optionalButtons preferences (optional buttons are always > present except in the ChangeSetSorter) Very likely I've missed some discussion about this, but I find the annotation pane incredible useful, not just in the change sorter. I also hate the optional buttons (useless and very bad UI as well IMHO), but that might just be me used to using short cuts ;-) So how is the annotation information accessible in the future? Michael

Oct. 27, 2009

Re: [Pharo-project] NewCompiler for pharo?

by Niko Schwarz

Hi Stef, On Sun, Oct 25, 2009 at 10:37 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > - is there a way to get something compiled in between? Two of us use the ThothCompiler in the mean time, which supports all the source code transformations of the NewCompiler, because it features the same AST: - http://smalltalkthoughts.blogspot.com/2009/09/introducing-thothcompiler.html If I understand it correctly, NewCompiler sort of works, but is being cleaned up. I'm sure Lukas and Jorge can correct me here. Cheers, Niko

Oct. 27, 2009

[Pharo-project] PhExample, because well designed tests expand on one another (Sneak Preview)

by Niko Schwarz

Hi list! Imagine you want to test the Stack class, and your first test just creates a test and checks if it's empty. Then in your second test, you create the same empty stack, but now push an element 'apple' and check if the size is one. Then in your third test, you do all the same, and then you pop the element and check that it is an apple. Wouldn't it be great if you could write your test cases such that they could expand on one another? If you didn't need to copy paste the code of the previous test and just say that you require the previous one! Well, that's what PhExample lets you do. And as a bonus, tests are ignored if the test they expand on does not pass. This gives you less failed tests, because examples are executed only if the examples they expand on pass too! That gives you the simplest failing examples in your set to look at! And best of all, you can run all examples with ye old TestRunner! The example discussed above would read in code as follows: EGExample subclass: #ForExampleStack â¦ shouldBeEmpty "Create the empty stack" | stack | stack := Stack new. stack should be isEmpty. stack size should = 0. ^ stack shouldPushElement "Push one element" | stack | stack := self given: #shouldBeEmpty. stack push: 42. stack should not be isEmpty. stack size should = 1. stack top should = 42. ^ stack shouldPopElement "And pop it again" | stack | stack := self given: #shouldPushElement. stack pop should = 42. stack should be isEmpty. stack size should = 0. Find the code at http://www.squeaksource.com/PhExample.html. The repository is write-global, so feel free to drop your ideas! PhExample is based on JExample by Lea Haensenberger, Adrian Kuhn, and Markus Gaelli. See http://scg.unibe.ch/research/jexample.

Oct. 27, 2009