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

Re: [Pharo-project] [ANN] Pharo-1.1.1-dev10.09.1

by Mariano Martinez Peck

2010/10/1 Bart Gauquie <bart.gauquie(a)gmail.com> > Great, > > gave it a try, loaded my app I was developing, and the page rendering speed > in Seaside has dropped from 15-20 msecs to 5-10 :-). > With the standard SqueakVM or with CogVM? > And all my tests are green! > > keep them coming! > > :) > Regards, > > Bart > > 2010/10/1 Mariano Martinez Peck <marianopeck(a)gmail.com> > >> Hi folks. We are releasing Pharo 1.1.1. This image is exactly same as >> Pharo 1.1 but based on PharoCore 1.1.1. The versions of the external >> packages is the same as in Pharo 1.1. The difference is that PharoCore1.1.1 >> has integrated some fixes and the support for CogVM. This means that >> Pharo-1.1.1-dev10.09.1 can be run with both, normal PharoVM and CogVM. For >> CogVM we recommend to use the last binaries that can be found in >> http://www.mirandabanda.org/files/Cog/VM/. Right now the last one is >> http://www.mirandabanda.org/files/Cog/VM/VM.r2313/ >> >> This CogVM version fixes the problem with "Objects as methods", and thus, >> all the #run:with:with are working. This means that tools like TestCoverage >> and AutoTest are working correctly with CogVM. >> >> The link to the image is: >> https://gforge.inria.fr/frs/download.php/27543/Pharo-1.1.1-dev10.09.1.zip >> >> Cheers >> >> Mariano >> >> _______________________________________________ >> 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. 1, 2010

Re: [Pharo-project] haltOnce and haltOnCount

by Hernan Wilkinson

cool! I didn't see it :-) 2010/10/1 Marcus Denker <marcus.denker(a)inria.fr> > > On Oct 1, 2010, at 8:08 PM, Hernan Wilkinson wrote: > > > PS: A #haltIf: aBlock message would be handy too :-) > > > already there: > > 1 haltIf: [1<2]. > 1 haltIf: [:rec | rec isInteger]. > 1 haltIf: (1<2). > 1 haltIf: #doIt > > especially putting a symbol is very useful. e.g. you can out the selector > of the test and then even > put a haltIf: into system methods called all the time. (e.g. collections). > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Oct. 1, 2010

Re: [Pharo-project] haltOnce and haltOnCount

by Marcus Denker

On Oct 1, 2010, at 8:08 PM, Hernan Wilkinson wrote: > > PS: A #haltIf: aBlock message would be handy too :-) already there: 1 haltIf: [1<2]. 1 haltIf: [:rec | rec isInteger]. 1 haltIf: (1<2). 1 haltIf: #doIt especially putting a symbol is very useful. e.g. you can out the selector of the test and then even put a haltIf: into system methods called all the time. (e.g. collections). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 1, 2010

Re: [Pharo-project] haltOnce and haltOnCount

by Guillermo Polito

There is already an issue about removing that responsibility from Object. I made a little enhancement some months ago (it was the first issue I fixed :P) but it never got integrated because it was not urgent. http://code.google.com/p/pharo/issues/detail?id=2394&q=halt&colspec=ID%20Ty… Cheers! 2010/10/1 Hernan Wilkinson <hernan.wilkinson(a)10pines.com> > ah, ok, I imagine that but what it was a bit of a surprise for me is that > it is implemented in Object... I mean, I know that halt is also implemented > in Object and it is the natural place to implement those messages, but if we > want to build a "modular" system, messages like halt, error, etc should be > removed from Object and seeing that Object is growing in its > responsibilities with these messages I think that goes against that path... > of course, if you decided that the trade off deserves it, fine by me... > I was thinking that halt for example could be implemented in MethodContext > (or ContextPart) so you can write something like "thisContext halt" and not > couple Object with Halt (of course we would be coupling MethodContext with > Halt, but it is a smaller coupling)... or just remove halt as a message and > force everybody to just write "Halt signal" of "Halt signalOnce" etc. I > mean, why Object implements halt? I know it is handy to do "self halt" but > also as handy as "Halt signal"... the only reason I see to implement halt in > Object is the possibility for any subclass to override that message, but I > haven't seen that in my years of smalltalker... > > Anyway, just a late's Friday thought :-) > > PS: A #haltIf: aBlock message would be handy too :-) > > > > On Fri, Oct 1, 2010 at 8:53 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> + 1 really really important >> >> On Sep 30, 2010, at 11:38 PM, Alexandre Bergel wrote: >> >> > I used haltOnce quite often when I had to debug the rendering facilities >> in Mondrian. >> > Putting "self halt" in a drawOn: method can easily freeze your image. >> > >> > Alexandre >> > >> > >> > >> > On 30 Sep 2010, at 17:18, Hernan Wilkinson wrote: >> > >> >> Hi, >> >> when are these messages used? what are the scenarios? >> >> I just want to understand why they are there... >> >> >> >> -- >> >> HernÃ¡n Wilkinson >> >> Agile Software Development, Teaching & Coaching >> >> Mobile: +54 - 911 - 4470 - 7207 >> >> email: hernan.wilkinson(a)10Pines.com >> >> site: http://www.10Pines.com >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > 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 >> > > > > -- > *HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com <http://www.10pines.com/>* > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 1, 2010

Re: [Pharo-project] haltOnce and haltOnCount

by Hernan Wilkinson

ah, ok, I imagine that but what it was a bit of a surprise for me is that it is implemented in Object... I mean, I know that halt is also implemented in Object and it is the natural place to implement those messages, but if we want to build a "modular" system, messages like halt, error, etc should be removed from Object and seeing that Object is growing in its responsibilities with these messages I think that goes against that path... of course, if you decided that the trade off deserves it, fine by me... I was thinking that halt for example could be implemented in MethodContext (or ContextPart) so you can write something like "thisContext halt" and not couple Object with Halt (of course we would be coupling MethodContext with Halt, but it is a smaller coupling)... or just remove halt as a message and force everybody to just write "Halt signal" of "Halt signalOnce" etc. I mean, why Object implements halt? I know it is handy to do "self halt" but also as handy as "Halt signal"... the only reason I see to implement halt in Object is the possibility for any subclass to override that message, but I haven't seen that in my years of smalltalker... Anyway, just a late's Friday thought :-) PS: A #haltIf: aBlock message would be handy too :-) On Fri, Oct 1, 2010 at 8:53 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > + 1 really really important > > On Sep 30, 2010, at 11:38 PM, Alexandre Bergel wrote: > > > I used haltOnce quite often when I had to debug the rendering facilities > in Mondrian. > > Putting "self halt" in a drawOn: method can easily freeze your image. > > > > Alexandre > > > > > > > > On 30 Sep 2010, at 17:18, Hernan Wilkinson wrote: > > > >> Hi, > >> when are these messages used? what are the scenarios? > >> I just want to understand why they are there... > >> > >> -- > >> HernÃ¡n Wilkinson > >> Agile Software Development, Teaching & Coaching > >> Mobile: +54 - 911 - 4470 - 7207 > >> email: hernan.wilkinson(a)10Pines.com > >> site: http://www.10Pines.com > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > _______________________________________________ > > 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 > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Oct. 1, 2010

Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)

by Igor Stasenko

I just tried to update image with old cache: [ Utilities updateFromServer] timeToRun 397707 and without it: [ Utilities updateFromServer] timeToRun 347708 397707 / 347708 asFloat 1.143795943722894 so, roughly 14% of CPU time (about 50 seconds) wasted on scanning the cache at each GC. Of course this measure a bit dirty, because there a network activity involved . On 1 October 2010 20:33, Igor Stasenko <siguctua(a)gmail.com> wrote: > Here the simple fix for it. > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Oct. 1, 2010

Re: [Pharo-project] [squeak-dev] Re: Help is now able to define where subbooks are placed

by Hannes Hirzel

Yes, this is very useful for me. Thank you Enrico and Thorsten! --Hannes On 10/1/10, Enrico Spinielli <enrico.spinielli(a)googlemail.com> wrote: > Torsten, > all thanks go to you for having thought/designed/implemented _and_ for > following HelpSystem up! > > Well done > Bye > Enrico > > On Fri, Oct 1, 2010 at 00:19, Torsten Bergmann <astares(a)gmx.de> wrote: >> Hi Enrico, >> >> found the time this evening to integrate your idea >> that custom help books should be able to define >> where subbooks should be placed/displayed: >> >> Â Â #pages >> Â Â Â ^(firstPage MyAppSubTutorial secondPage thirdPage) >> >> >> Just update your Squeak image to #10565 and you dont >> need to workaround this problem using a custom >> builder anymore. >> >> It is now also mentioned in the help systems help >> itself. See chapter "STEP 7 - TIPS AND TRICKS". >> >> I've also opened an issue together with the >> changeset for Pharo 1.2 so that it will be >> integrated in one of the next pharo updates. >> >> http://code.google.com/p/pharo/issues/detail?id=3022 >> >> Thanks for the idea and initial code! >> >> Bye >> T. >> -- >> Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! >> Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail >> > > > > -- > Enrico Spinielli > "Do Androids dream of electric sheep?"â Philip K. Dick > "Hear and forget; see and remember;do and understand."âMitchel Resnick > >

Oct. 1, 2010

Re: [Pharo-project] [ANN] Pharo-1.1.1-dev10.09.1

by Bart Gauquie

Great, gave it a try, loaded my app I was developing, and the page rendering speed in Seaside has dropped from 15-20 msecs to 5-10 :-). And all my tests are green! keep them coming! Regards, Bart 2010/10/1 Mariano Martinez Peck <marianopeck(a)gmail.com> > Hi folks. We are releasing Pharo 1.1.1. This image is exactly same as Pharo > 1.1 but based on PharoCore 1.1.1. The versions of the external packages is > the same as in Pharo 1.1. The difference is that PharoCore1.1.1 has > integrated some fixes and the support for CogVM. This means that > Pharo-1.1.1-dev10.09.1 can be run with both, normal PharoVM and CogVM. For > CogVM we recommend to use the last binaries that can be found in > http://www.mirandabanda.org/files/Cog/VM/. Right now the last one is > http://www.mirandabanda.org/files/Cog/VM/VM.r2313/ > > This CogVM version fixes the problem with "Objects as methods", and thus, > all the #run:with:with are working. This means that tools like TestCoverage > and AutoTest are working correctly with CogVM. > > The link to the image is: > https://gforge.inria.fr/frs/download.php/27543/Pharo-1.1.1-dev10.09.1.zip > > Cheers > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 1, 2010

Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)

by Igor Stasenko

Here the simple fix for it. -- Best regards, Igor Stasenko AKA sig.

Oct. 1, 2010

Re: [Pharo-project] Base64MimeConverterTest>>#testOnByteArray raise an error

by Pavel Krivanek

The problem is that when the method base64Encoded was moved, packages Collections and Network were marked as dirty but not the package MimeConverter so the new version was not sent to the repository. -- Pavel 2010/10/1 Cyrille Delaunay <cy.delaunay(a)gmail.com> > ByteArray >> base64Encoded is no longer defined in Pharo 1.2, but used in the test Base64MimeConverterTest>>#testOnByteArray. It raise a DNU message. > > I opened an Issue: > http://code.google.com/p/pharo/issues/detail?id=3027&q=base64Encoded&colspe… > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 1, 2010