- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] ClassOrganizer oddities

by Igor Stasenko

2009/10/27 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/10/27 Igor Stasenko <siguctua(a)gmail.com>: >> 2009/10/26 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> so what is the fix? >>> I would really like to get announcement instead of event >>> systemNotification but I'm sure that this >>> can be a bit tricky. >>> >> >> Yes, tricky :) >> Here what i have in mind: >> >> Any change to system should be captured _before_ it applied. >> This allows us to introduce a policy which can validate the change and decide >> whether it allowed to be made or not. >> >> I made the SystemChangeEvent class, which having following state: >> Â - changeKind - a symbol, which identifies the change > > Hi Igor, > IMHO, nowadays, the trend would be to create subclasses rather than > internal symbols... > Shouldn't there be a symmetry with the hierarchy of changes in > DeltaStream (for example) ? > Well, my own 'trend' is to use GLOBALS as little as possible. So instead of spawning a whole tree of different event types, and then spit them around in different places, i prefer to use messages instead. I am using a single #newSystemEvent: message to create an instance of system event. So, there will be only a few places, where #SystemChangeEvent global be referenced, and therefore you can refactor the whole thing by changing few places. I don't plan to put into the SystemChangeEvent any kind of clever code. It just a state holder, notthing more. And handlers usually do a simple dispatch to handle the event. Moreover, i won't be using numerous #isXXXXX stinky tests, which is just a code bloat and don't really helpful unless you writing plainly wrong code ( remember? "don't ask - tell" ) :) For instance, i tried to track all listeners of particular SystemNotification event, and had hard times to find them out, because its dispatching scheme generates the selector consisting from 3 parts: itemKind, changeKind, 'Event:' (see implementation of #eventSelector) but when i staring at code which creates a notification, i don't see these selectors, and to figure out, that is the actual method is used to handle given notification i need to go exploring the internals of dozens of AbstractEvent subclasses. In contrast, if i would want to find out all handlers of particular SystemChangeEvent , i would need only to see implementors of changeKind selector (such as #changeSelectorCategory) , which is right before my eyes, in the code which emits the system change event. But i want to hear your counterarguments, why bunch of subclasses is more appropriate. Symmetry with DeltaStreams: no symmetry. The difference is that deltas capturing 'before' and 'after' state. While for SystemChangeEvent, there is no 'after' happened yet. It should carry the only state which is enough to analyze & perform the change. And its not necessary that this state will consist of simple objects (strings, symbols etc), simply for speed & efficiency purposes - i could pass the CompiledMethod instance instead of the source of method, behavior object, instead of a class name and 'isMeta' boolean, and so on. Moreover, it is not necessary that change will be applied at all. The users of SystemChangeEvent operating directly with system data model, therefore you don't need to translate everything to simplest forms, as deltastreams doing, because these events living & dying inside the system and have little use for outside. Of course, the arbiter object, which i mentioned before could easily capture all 'before' and 'after' state, and then broadcast this to all subscribers. And of course its free to translate the event into more edigible form. > Nicolas > >> Â - parameters - a dictionary , which holding different parameters, >> important for change >> Â - subject - the object which is going to be changed (or taking a main >> role in change) >> Â - action - a block closure which , if evaluated, will apply the >> change to system >> >> For example, here the method which creates & populates the system change event: >> >> classify: element under: heading suppressIfDefault: aBoolean >> >> Â Â Â Â (self subject newSystemEvent: #changeSelectorCategory) >> Â Â Â Â Â Â Â Â subject: element; >> Â Â Â Â Â Â Â Â param: #behavior->self subject; >> Â Â Â Â Â Â Â Â param: #category->heading asSymbol; >> Â Â Â Â Â Â Â Â param: #suppressIfDefault->aBoolean; >> Â Â Â Â Â Â Â Â action: [ super classify: element under: heading suppressIfDefault: >> aBoolean ]; >> Â Â Â Â Â Â Â Â signal. >> --------- >> >> The event handling procedure is following: >> >> - first of all, an event passed to a system arbiter object >> - a system arbiter checking with the policy >> - if everything ok, change is applied by evaluating action. >> - and finally, change is announced to any interesting parties >> >> I want to make each package to hold own policy (a set of flags >> identified by name, to ease fileout). >> Then, any event could be validated by policy by issuing: >> Â package policy validate: change >> >> For example, lets see , what validations we could introduce for method >> recategorization event. >> >> Â - lets take most interesting case, when we want to recategorize the >> method in ClassA, which belongs to PackageA, >> Â and putting it into extension category, like *PackageB >> >> Â - check, if we allow any changes to ClassA (policy of PackageA) >> Â - check if PackageA allows method extensions (policy of PackageA) >> Â - check if PackageB allows extending the classes of another packages >> (policy of PackageB) >> Â - check if extension overrides existing method >> Â - and of course, we should check that given extension does not >> creates a circular dependency between the packages. >> >> There, of course, some problems which arising. >> - changes nesting. >> Â Some changes is complex ones, and even a simple method >> recategorization could lead to another event - creating a new >> Â category in class. Â Optimally, it would be cool to have only most >> basic events, which can't be nested. And any action which may lead to >> multiple changes, should be split on a number of basic ones. >> A SystemChangeNotifier solving this by allowing doing things silently: >> Â SystemChangeNotifier uniqueInstance doSilently: [ ... ]. >> so, any changes within the block , if any, won't be announced. >> >> - atomicity support. To support the bulk model updating, i can imagine >> the framework, which capturing any changes without applying them, by >> building/collecting all changes in parallel, and then applying them by >> a single mass-become. This is what SystemEditor does. >> >> - metaprogramming. There should be a means to leave a room for >> metaprogramming. We wouldn't want to signal a system change for >> anonymous classes, and many other things, which can be tricky here. >> >> P.S. as you can see , the plans is quite bold, and will require >> numerous refactorings :) So, the more people is interested in that, >> the better. >> >>> Stef >>> >> >> -- >> 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.

Oct. 27, 2009

[Pharo-project] SeasideTesting

by Norbert Hartl

Hi, is there a SeasideTesting that is working in pharo? Norbert

Oct. 27, 2009