- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Introducing smallUML: a little project to help us document :)

by Sean P. DeNigris

Carla F. Griggio wrote: > > OK, although I tried to use what I separated in the Minimal Connectors > package and there are still some things missing to be able to use it > independently. So (although we're already talking about that here XD) we > shouldn't announce that yet. > Any progress with Minimal Connectors? I would love to use it in several of the projects I'm working on. Thanks. Sean -- View this message in context: http://forum.world.st/Introducing-smallUML-a-little-project-to-help-us-docu… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 1, 2010

Re: [Pharo-project] [Metacello] Re: loading groups with metacello

by Mariano Martinez Peck

On Fri, Oct 1, 2010 at 7:13 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Mariano Martinez Peck wrote: > >> >> >> On Fri, Oct 1, 2010 at 2:16 PM, Veronica Isabel Uquillas Gomez < >> vuquilla(a)vub.ac.be <mailto:vuquilla@vub.ac.be>> wrote: >> >> Hi Mariano, >> >> You already saw my problem. >> >> With this you can check what is happening: (ConfigurationOfGlamour >> project version: 'default') record: #('Core' 'Tests' 'Extras') >> >> >> I don't understand why this loads Grease for example. Dale any idea? >> I checked loadDirective but I didn't understand. >> >> Cheers >> >> Mariano >> >> >> all the pre-requisites are being loaded and not only the groups. >> >> >> Regards, Veronica _______________________________________________ >> Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr <mailto: >> Pharo-project(a)lists.gforge.inria.fr> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > Okay, Here's the printString of the loadDirectives: > > linear load : > linear load : default [ConfigurationOfGlamour] > load : ConfigurationOfGrease > linear load : default [ConfigurationOfGlamour] > load : ConfigurationOfMondrian > atomic load : default [ConfigurationOfGlamour] > load : Glamour-Announcements > load : Glamour-Helpers > load : Glamour-Core > load : Glamour-Presentations > load : Glamour-Browsers > load : Glamour-Tests-Core > load : Glamour-Morphic-Theme > load : Glamour-Examples > load : Glamour-Tools > linear load : default [ConfigurationOfMondrian] > load : ConfigurationOfHealthReportProducer > linear load : default [ConfigurationOfMondrian] > load : ConfigurationOfProfStef > atomic load : default [ConfigurationOfMondrian] > linear load : 1.3 [ConfigurationOfProfStef] > load : ConfigurationOfShout > linear load : 1.3 [ConfigurationOfProfStef] > linear load : 1.1.1 [ConfigurationOfShout] > load : Shout-lr.90 > load : ShoutWorkspace.pharo-1-1-SeanDeNigris.6 > load : ProfStef-Core-LaurentLaffont.11 > load : ProfStefBrowser-LaurentLaffont.26 > load : ProfStef-Tests-LaurentLaffont.8 > load : ProfStef-Help-LaurentLaffont.1 > load : Mondrian > load : CollectionExtensions > atomic load : 0.1-baseline [ConfigurationOfHealthReportProducer] > load : HealthReportProducer > load : Glamour-Scripting > linear load : 1.0-alpha9.1 [ConfigurationOfGrease] > load : ConfigurationOfRefactoringBrowser > linear load : 1.0-alpha9.1 [ConfigurationOfGrease] > load : Grease-Core-lr.37 > load : Grease-Pharo-Core-jok.18 > linear load : 1.3 [ConfigurationOfRefactoringBrowser] > load : AST-Core-lr.73 > load : Refactoring-Core-lr.136 > load : Grease-Slime-jok.5 > load : Magritte-Model > load : Magritte-Morph > load : Glamour-Morphic-Renderer > load : Glamour-Tests-Morphic > > and here's the section related to Grease (very end of directives): > load : Glamour-Scripting > linear load : 1.0-alpha9.1 [ConfigurationOfGrease] > load : ConfigurationOfRefactoringBrowser > linear load : 1.0-alpha9.1 [ConfigurationOfGrease] > load : Grease-Core-lr.37 > load : Grease-Pharo-Core-jok.18 > linear load : 1.3 [ConfigurationOfRefactoringBrowser] > load : AST-Core-lr.73 > load : Refactoring-Core-lr.136 > load : Grease-Slime-jok.5 > load : Magritte-Model > load : Magritte-Morph > load : Glamour-Morphic-Renderer > load : Glamour-Tests-Morphic > > The load directive is in "load order" which is "reverse prerequisite > order". In other words, the clue for why Grease is loaded lies in the > directives _following_ the Grease directives... > ahhhhhhhh I was looking BEFORE, not after hehehe.. what an idiot I am :) > > In this case Magritte-Model immediately follows the loading of Grease > implying that Magritte-Model, requires Grease (and then confirmed by looking > at the configuration) > > Reading on: Magritte-Morph requires Magritte-Model, > Glamour-Morphic-Renderer requires Magritte-Morph and Glamour-Tests-Morphic > requires Glamour-Morphic-Renderer. > > From the configuration, Glamour-Tests-Morphic is a member of Tests and > Tests is being loaded (or recorded in this case). > > Does this help? > Completly understood :) > > Note that ConfigurationOfGlamour is not using ConfigurationOfMagritte2. I > think that is because of problems with earlier versions of the > CofigurationOfMagritte2, when seaside30 was loaded when you tried to load > Magritte. The latest ConfigurationOfMagritte2 doesn't have that problem > anymore, Glamour could be using ConfigurationOfMagritte2 now. > > Dale >

Oct. 1, 2010

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

by Mariano Martinez Peck

2010/10/1 Eliot Miranda <eliot.miranda(a)gmail.com> > Hi Mariano, > > 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. >> > > WHile some simple things now work there's definitely at least one bug > remaining (perform:withArguments: doesn't work for objects-as-methods) and > Nicolas tried a more demanding test (the coverage test from XTreams) and > found problems; see > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033230.…. > I'll be releasing a new VM that will fix the perform issue, but it remains > to be seen whether the bugs Nicolas as found are fixed by this. So while > .33 is better Cog still doesn't support objects-as-method correctly. > Thanks Eliot for making this clear. Just let us know when this is fixed :) Cheers Mariano > > HTH > Eliot > > >> 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] [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