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

[Pharo-project] AutomaticMethodCategorizer in Pharo

by Mariano Martinez Peck

Hi folks. I really like the AutomaticMethodCategorizer from Squeak. I see they are not included in Pharo dev images. Is this just a preference or they don't work on pharo? I didn't found them in squeaksource. So, how can I install AutomaticMethodCategorizer and AutomaticMethodCategorizerOB in Pharo? Thanks Mariano

June 4, 2009

Re: [Pharo-project] Fixes I had to make to the latest pharo image to be able to work with it

by David RÃ¶thlisberger

Hi Hernan, thanks for your fixes! Some comments of mine: > All the rest are OB related. > 4) When pressing the mouse right button (on windows) I had a error > saying OBTextSelection does not understand #isClassNode, so I > implemented returning false. Again, I did not verify if an > OBTextSelection should receive that message or not, I just implemented. Integrated in latest OB. > --------------- > 5) After loading a Monticello package I could not open an OB browser > anymore. Again, the problem is that ea is nil sometimes. > > OBBrowser>>scanNodeCommands: ann > (cmdFactories select: [:ea | ea notNil and: [ ea takesNodes]]) > do: [:ea | ann addFactory: ea] > ------------------- Cna you tell me how to reproduce this? Which MC package did you load when you got the problem? > OBBrowser>>scanTextCommands: ann > (cmdFactories select: [:ea | ea notNil and: [ ea takesText ]]) do: [:ea > | ann addFactory: ea] > ------------------ > 7) This is an error I reported to OB a long time ago, related with > pressing or selecting the cancel option. Integrated in latest OB. David

June 4, 2009

Re: [Pharo-project] an odd bug

by Hernan Wilkinson

hmm, let me rectify what I said. Yesterday I had to errors related to this bug. The first one is the one that Sean says and I sent the fix in other mail. It check for leftMorphs to be nil in the method noticeMouseOver: event:I look for sender of that message and are HandMorph and Morph, so that is not a raise condition but just something that can happen. But when fix that error I got another one in the method processMouseOver: , where it does "leftMorphs isEmpty " and there leftMorphs was nil and the only reason for that was a raise condition... but that error never happened againg.... Conclusion: I think just checking for nil in noticeMouseOver:event: is enough to solve the error, and I do not know why the other error happened but I may have been a really rare situation... Bye, Hernan. On Thu, Jun 4, 2009 at 4:11 AM, Michael Rueger <m.rueger(a)acm.org> wrote: > StÃ©phane Ducasse wrote: > > Thanks. > > > > I think that for the MouseOverHandler it would be good to know if this > > is related to Sensor changes. > > Mike what you think? > > It shouldn't. On the Morphic side there weren't any changes to process > behavior, it still pulls the events out of the queue in the step cycle. > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 4, 2009

[Pharo-project] [ANN][Dev-Images] June 2009 versions

by Damien Cassou

Hi, I've just uploaded new dev and web images based on Squeak3.9.1-7075, Squeak3.10.2-7179 and Pharo0.1-10324. More information and download: http://damiencassou.seasidehosting.st/Smalltalk/squeak-dev Pharo-based images can be downloaded at: http://pharo-project.org/download Download statistics at http://damiencassou.dabbledb.com/publish/dev-imagesdownloads Changes in this version: --------------------------- - Pharo images are based on version 10324 - New version of OCompletion for Pharo Contained packages: ------------------------ This image contains the following packages (some packages are only in the squeak-web image): Aida version 5.6 Algernon version 1.2 AST version 164 AutomaticMethodCategorizer version 0.25 AutomaticMethodCategorizerOB version 0.2 DynamicBindings version 2.7 eCompletion version 0.102 eCompletion-Traits version 0.1 eCompletionOmniBrowser version 0.5 Installer version 4.3 Installer-Core version 4.3.313 Installer-Formats version 4.3.3 Installer-Scripts version 4.3.8 KomHttpServer version 7.0.45 KomServices version 1.19 Magritte-Model version 1.1.1.340 Magritte-Seaside version 1.1.1.284 Magritte-Tests version 1.1.1.149 OB-Enhancements version 0.328 OmniBrowser version 0.447 OmniBrowser-Algernon version 0.5 OmniBrowser-Full version 0.27 OmniBrowser-Morphic version 0.88 OmniBrowser-Refactory version 145 OmniBrowser-Regex version 0.18 OmniBrowser-Standard version 0.406 Pier version current Pier-Blog version 1.1.1.108 Pier-Documents version 1.1.1.8 Pier-EditorEnh version 1.1.1.17 Pier-Model version 1.1.1.271 Pier-Seaside version 1.1.1.340 Pier-Security version 1.1.1.121 Pier-Tests version 1.1.1.117 Polymorph EventEnhancements version 1.1 Polymorph Geometry version 1.1 Polymorph TaskbarIcons version 1.0 Polymorph ToolBuilder version 1.3 Polymorph Tools Diff version 1.3 Polymorph Widgets version 1.4 Refactoring Core version 48 Refactoring Spelling version 5 RoelTyper version 0.60 RSRSS2 version 2.8.3.11 Scriptaculous version 2.8.3.242 ScriptManager version 0.6 Seaside version 2.8.3.572 Seaside-Adapters-Core version pmm.2.mcz Seaside-Adapters-Swazoo version 9 Seaside-Squeak-Adapters version pmm.3.mcz SeasideAdaptersCompatibility version pmm.1.mcz Shout version 3.15-tween.72 ShoutWorkspace version 1-tween.4 SmaCC runtime version 13 Sport version 2.31 Squeak dev packages version 0.28 Squeak web packages version 0.2 SUnit-improved version 4.0.118 SUnitGUI-improved version 4.0.50 Swazoo version 2.1 Universes version 52 Universes OmniBrowser version 0.38 VBRegex version 1.9 YAXO version 14 -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 4, 2009

[Pharo-project] Aconcagua and latest pharo version

by Hernan Wilkinson

Some Aconcagua 2.0 test fail in the latest version. The reason is related to the changes made to ScaledDecimal that now does a #coerce:The coerce sends the message isFraction, but a Measure could be a fraction but not an instance of class Fraction, for example: 1/2 meters. I know this could sound rare, but I think it is reasonable. That means that isFraction could respond true even though the object is not instance of Fraction. Therefore, I had to change the #coerce: method to this: coerce: aNumber "Note: this quick hack could be replaced by double dispatching" aNumber class = self class ifTrue: [^self class newFromNumber: aNumber scale: (scale max: aNumber scale)]. ((aNumber class = Fraction) or: [aNumber isInteger]) ifTrue: [^self class newFromNumber: aNumber scale: scale]. ^aNumber Instead of "aNumber isFraction" now it does "aNumber class = Fraction". (I can not use isKindOf: because MeasureBagFraction is subclass of Fraction and would not work properly). So, I do not know if it is a good idea to open a defect on this because the comment of the method says it is a quich hack... so maybe the best thing to do is for that person that is doing these changes to run also the Aconcagua test to see if everything keeps working after the changes or contact me before releasing the changes to check Aconcagua works fine. Bye, Hernan.

June 4, 2009

Re: [Pharo-project] an odd bug

by Michael Rueger

StÃ©phane Ducasse wrote: > Thanks. > > I think that for the MouseOverHandler it would be good to know if this > is related to Sensor changes. > Mike what you think? It shouldn't. On the Morphic side there weren't any changes to process behavior, it still pulls the events out of the queue in the step cycle. Michael

June 4, 2009

Re: [Pharo-project] an odd bug

by StÃ©phane Ducasse

Thanks. I think that for the MouseOverHandler it would be good to know if this is related to Sensor changes. Mike what you think? Stef On Jun 4, 2009, at 1:53 AM, Gary Chambers wrote: > That's an old one... a bit late here so look it up on Mantis. > ANYTHING that manipulates morphs etc. in a process other than the UI > process is liable to break in one way or another. > > The mouse over handler is just one of the most frequent (most > events)... > > The workaround we have is to do the nil check. A Workaround though... > > Regards, Gary > ----- Original Message ----- > From: Hernan Wilkinson > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Wednesday, June 03, 2009 8:59 PM > Subject: Re: [Pharo-project] an odd bug > > I think I founded the problem... I don't know what makes it happen > or how to solve it yet :-) > But the problem is a raise condition. In method > MouseOverHandler>>processMouseOver: anEvent the instance variable > leftMorphs is set to nil, but when accessing that variable there > is no check for nil. So, if processMouseOver: anEvent is running in > two different processes, in one leftMorphs could set to nil while in > the other process is still been used... > > Is it possible for processMouseOver: anEvent to be evaluated in more > than one process? If that is true, so that is the problem... if not, > nothing makes sense... > > 2009/6/3 Mariano Martinez Peck <marianopeck(a)gmail.com> > I didn't know that. logDebuggerStackToFile is the option? > > It's strange because this is enable by default and I don't think > Sean change it. > > > > On Wed, Jun 3, 2009 at 5:39 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com > > wrote: > This is controlled by a Preference setting... > > Nicolas > > 2009/6/3 Sean Allen <sean(a)monkeysnatchbanana.com>: > > dont have one. there isnt any debug.log in the directory with the > image ( or > > any other pharo associated directory. ) > > > > 2009/6/3 Mariano Martinez Peck <marianopeck(a)gmail.com> > >> > >> It would be helpful if you attach debug.log. This file is located > in the > >> same directory where the image is. > >> > >> Cheers, > >> > >> Mariano > >> > >> 2009/6/3 Sean Allen <sean(a)monkeysnatchbanana.com> > >>> > >>> that i dont really know how to describe... so i'm going to > attach a > >>> screenshot... > >>> i opened the lastest pharo dev image... checked to see if the > redraw bug > >>> that i have been experiencing was still there... > >>> went to quick and got a sudden flurry of message not understood > errors ( > >>> see screenshot of the rearranged windows )... > >>> i wasnt able to reliably reproduce but, when doing the same > thing ( open > >>> and quit... ) about 2 out of every five times i > >>> got message not understood windows popping up. > >>> > >>> > >>> _______________________________________________ > >>> 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

June 4, 2009

Re: [Pharo-project] Fixes I had to make to the latest pharo image to be able to work with it

by StÃ©phane Ducasse

Thanks. I think that for the MouseOverHandler it would be good to know if this is related to Sensor changes. Mike what you think? Stef On Jun 3, 2009, at 11:38 PM, Hernan Wilkinson wrote: > Hi, > I know this is not the right way to send fixes, but it is the > fastest... so maybe it is useful for those who need them. > I had a lot of problems using the last pharo image, some are > related with the new debugger, some are old errors related with > buttons, some are related with the OmmiBrowser (I send them here too > because I know that the OB authors are subscribed to this list and > because that is the main pharo browser), etc. > Most of the problems are because nil receives a message that does > not understand. I did not look for the reason that made the variable > reference nil (maybe the best solution) but only added a #isNil > check (the fastest solution). > I had to disable the new debugger and get back to the old one > (Debugger) because I was getting to many errors with the new one > saying "It could not debug a running process". > Here are the fixes: > > 1) This one made the image to crash because it entered a infinite > loop. The problem is that sometime getStateSelector is nil. > > PluggableButtonMorph>>getModelState > "Answer the result of sending the receiver's model the > getStateSelector message." > > ^(getStateSelector isNil or: [ model isNil ]) > ifTrue: [false] > ifFalse: [model perform: getStateSelector] > --------------- > > 2) This one is related with what Sean Allen reported. Again > leftMorphs is nil, so I added a #isNil check. (For me this class is > a mess, but I do not have the experience to change it yet) > > MouseOverHandler>>noticeMouseOver: aMorph event: anEvent > "Remember that the mouse is currently over some morph" > leftMorphs isNil ifFalse: [ > (leftMorphs includes: aMorph) > ifTrue:[leftMorphs remove: aMorph] > ifFalse:[enteredMorphs nextPut: aMorph]. > overMorphs nextPut: aMorph.] > -------------- > > 3) OCompletion does not work with the old debugger > because#guessTypeForName: references tempNames that is not > defined... So I just disallowed it. > > Debugger>>guessTypeForName: aString > | index object | > index := nil. "tempNames > 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 > -------------- > All the rest are OB related. > 4) When pressing the mouse right button (on windows) I had a error > saying OBTextSelection does not understand #isClassNode, so I > implemented returning false. Again, I did not verify if an > OBTextSelection should receive that message or not, I just > implemented. > > OBTextSelection>>isClassNode > > ^false > --------------- > 5) After loading a Monticello package I could not open an OB browser > anymore. Again, the problem is that ea is nil sometimes. > > OBBrowser>>scanNodeCommands: ann > (cmdFactories select: [:ea | ea notNil and: [ ea takesNodes]]) > do: [:ea | ann addFactory: ea] > ------------------- > 6) Similar to 5. > > OBBrowser>>scanTextCommands: ann > (cmdFactories select: [:ea | ea notNil and: [ ea takesText ]]) do: > [:ea | ann addFactory: ea] > ------------------ > 7) This is an error I reported to OB a long time ago, related with > pressing or selecting the cancel option. > > OBDefinitionPanel>>aboutToChange: ann > > | ans answerResult vetoBlock | > > self canDiscardEdits ifTrue: [^ true]. > vetoBlock := [ ann veto ]. > ans := OBChoiceRequest > prompt: 'Code has been modified. Do you want to accept > or discard the changes?' > labels: {'Accept'. 'Discard'. 'Cancel'} > values: (Array > with: [self changed: #accept] > with: [self changed: #clearUserEdits] > with: vetoBlock ). > > answerResult := ans value. > answerResult isNil ifTrue: vetoBlock. > -------------------- > > I hope it helps. > > Hernan. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 4, 2009

Re: [Pharo-project] iphone testers for fractions calculator needed

by John McIntosh

This squeak app went live in the iTunes app store at 6:07pm PST June 3rd, the typical 7 day app review cycle. http://www.mobilewikiserver.com/Fraction.html On Sat, May 16, 2009 at 11:35 PM, John M McIntosh < johnmci(a)smalltalkconsulting.com> wrote: > I've built a fractions calculator for the iPhone and need a few folks to > really test it. (confirm it's sane). > =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

June 4, 2009

Re: [Pharo-project] an odd bug

by StÃ©phane Ducasse

in hte past there were project = subworld and a property couuld be local to the world or not. On Jun 3, 2009, at 10:24 PM, Sean Allen wrote: > > > 2009/6/3 Mariano Martinez Peck <marianopeck(a)gmail.com> > I didn't know that. logDebuggerStackToFile is the option? > > It's strange because this is enable by default and I don't think > Sean change it. > > yeah that is enabled and i dont have a debug log. > > what is the difference between enabled and local checkboxes? > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 4, 2009