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

Re: [Pharo-project] In Latest OB I cannot add a class variable

by Mariano Martinez Peck

Lukas, now I have another problem. I am not sure if it is OB latest code related, but I think so. If you take any class, suppose RBSemanticTest and go to its definition. Change it so that it extends from ProtoObject instead of TestCase. When you accept the code (save it), the browser goes directly to Browse ProtoObject, actually to : ProtoObject subclass: #ProtoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Objects'. ProtoObject superclass: nil and then RBSemanticTest is not changed at all. Thanks! Mariano On Thu, Sep 30, 2010 at 9:46 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Thanks Lukas. It is working now. > > Cheers > > Mariano > > > On Thu, Sep 30, 2010 at 8:44 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > >> The latest OB and Refactory code should fix this and a couple of related >> issues. >> >> Lukas >> >> On 30 September 2010 12:11, Lukas Renggli <renggli(a)gmail.com> wrote: >> > Strange, I'll look into it later today. >> > >> > Lukas >> > >> > On Thursday, September 30, 2010, Mariano Martinez Peck >> > <marianopeck(a)gmail.com> wrote: >> >> Hi Lukas. I am using latest OB + RB in PharoDev 1.1 and I have a >> problem trying to add a class variable. >> >> >> >> To reprpoduce >> >> 1) take any class, for example TestCase. >> >> 2) Go to the class side >> >> 3) add a class side variable. For example: >> >> >> >> TestCase class >> >> instanceVariableNames: 'history something' >> >> >> >> 4) The problem is in >> >> >> >> InteractiveAddClassChange >> definingSuperclass >> >> ^ Smalltalk globals at: self superclassName >> >> >> >> >> >> since self superclassName answers nil, because >> >> >> >> >> >> AddClassChange class >> superclassName >> >> className isNil >> >> ifTrue: [ self fillOutDefinition ]. >> >> ^ superclassName >> >> >> >> className prints -> #'Unknown Class' >> >> >> >> I attach PharoDebug.log also. >> >> >> >> Cheers >> >> >> >> Mariano >> >> >> > >> > -- >> > Lukas Renggli >> > www.lukas-renggli.ch >> > >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

Oct. 2, 2010

[Pharo-project] [ANN] Dynamic Stockholm 2010!

by GÃ¶ran Krampe

Hi fellow Squeakers/Pharooners! On the 19th of october there is a free event in Stockholm that I think will be really good! Unfortunately I can not attend myself. Cincom (Julian Fitzell, Tim Matthews), DevoTeam Quaint (BjÃ¶rn EiderbÃ¤ck) and TPG Objektfabriken (GÃ¶ran Krampe) joined forces and invite you to an evening full of presentations and informal exchange around dynamic languages. Topics will comprise âDynamic languages on mobile platformsâ (Mikael Kindborg, MoSync), âWeb development with Seasideâ (Julian Fitzell, Cincom) as well as a series of mini presentations highlighting cool aspects of each language â the entire agenda will be published shortly. To ensure your seat at this free-of-charge event, please sign up here: http://dynamicstockholm2010.eventbrite.com Of course, there is a distinct Smalltalk-aroma around this event - and we almost named it Smalltalk Stockholm 2010 - but since the content ended up in such an interesting mix of dynamic languages we renamed it. Hope at least some of you might be able to attend! And I guess we will try to tape the presentations. regards, GÃ¶ran

Oct. 2, 2010

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

by StÃ©phane Ducasse

Matt Sven I love to see your framework emerging like that. Keep pushing. This is a warm feeling for us (with our head in the gory details of the system) so see that other people are creating cool abstractions on top of it. Stef > Hi everyone, > > On Oct 1, 2010, at 8:10 AM, Lukas Renggli wrote: > >> Wow, very impressive. >> >> What I would like to see is some kind of high-level API for convenient >> access to all features. Something along >> >> response := ZnHttp new >> url: 'http://www.foo.com'; >> userAgent: 'FakeAgent'; >> cookieAt: 'something' put: '123'; >> parameterAt: 'q' put: 'smalltalk'; >> onFailure: [ :error | self inform: 'failed' ]; >> onProgress: [ :status | ... ]; >> get >> >> Lukas >> > > This is actually where I'd like to head with the client API. I had started my own HTTP client about 2 days before Sven announced Zinc, so it made more sense contribute to his project. My initial work was a subclass off of ProtocolClient and was kind of monolithic, so my first steps have been to make things mesh nicely with Zinc. > > My initial prototype before I started working on Zinc had a very similar API to your example, so my thoughts are definitely aimed for that direction. > > Matt > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 2, 2010

Re: [Pharo-project] Issue 3036: SUnit Refactoring

by StÃ©phane Ducasse

> In the course of working through A Mentoring Course on Smalltalk, I applied > some small refactorings to SUnit. > > Issue: http://code.google.com/p/pharo/issues/detail?id=3036 > > Fix in inbox: SUnit-SeanDeNigris.114 > > * TestCase now uses class>>suiteClass instead of referencing the class name > directly > * TestSuite now uses #resultClass instead of referencing the class name > directly I did that long time go but it was lost apparently. Sean we just merged SUnit 4.0 so can you have a look. Stef > > Also, 114 is a merge of SUnit-StephaneDucasse.113 and SUnit-SeanDeNigris.106 > (a package saved in my local cache). Should I upload SUnit-SeanDeNigris.106 > also? > > Thanks. > Sean > > -- > View this message in context: http://forum.world.st/Issue-3036-SUnit-Refactoring-tp2914375p2914375.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 2, 2010

Re: [Pharo-project] Source in image [WAS] Re: [Pharo-users] Distributing 'minimal' image

by Nicolas Cellier

2010/10/2 Igor Stasenko <siguctua(a)gmail.com>: >>> >>> I WOULD LOVE that. I mean, I don't care if the dev image is 10 mb bigger, >>> if >>> I will improve performance since I don't need to fetch a .sources file. >>> what would be awesome is if we can have both, this is: for the dev image, >>> I >>> would like to have the sources in the image, but not for PharoCore. Or >>> maybe >>> also in PharoCore but to be sure to be able to remove them, and use >>> .sources/decompiler as it is now. Maybe put that in #cleanUpForProduction >>> or >>> similar. >>> >>> thoughts? >> >> You'd also lose versioning, since a trailer can only hold one version of the >> source code. Btw, do you really have a performance issue reading the >> sources? With Cog and Squeak 4.2, I get: >> >> methods := CompiledMethod allInstances shuffle. >> [ methods do: #getSource ] timeToRun "===> 1162" >> >> So it takes ~25 microseconds to fetch the source of a method on average. >> That's more than 39000 methods per second. It should be enough IMHO. >> >> > > Well, you can always change the trailer(s) to hold additional info. > As i told before, we need a source management layer, which allows > multiple different implementations, > then its not quite important how/where we persisting sources, since we > could switch between them, > or use different source manager on a per-method basis. > Sure, I was thinking of it, but removed methods will hardly have a trailer for example. And reconstructing the history will be difficult too. Nicolas >> Levente >> > > -- > 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 >

Oct. 2, 2010

Re: [Pharo-project] [update 1.2] #12161 - #12172

by StÃ©phane Ducasse

OK marcus will give a try. We will have to clean all these points with weakstuff once for all and getting more or less aligned with the work levente did. Stef On Oct 1, 2010, at 5:48 PM, Igor Stasenko wrote: > Here what happens: > > Original method WeakKeyDictionary>>finalizeValues > > WeakKeyDictionary>>finalizeValues > "Clear all associations with nil keys" > array do:[:assoc| > 1 to: array size do:[:i | | assoc | > assoc := array at: i. > assoc ifNotNil:[ > assoc expire ifTrue:[ > expired := expired + 1. > tally := tally - 1. > ]. > ]. > ]. > > And i noticed that after recompilation of this method, it starts > spending much more time to scan 14k entries: > > [MCMethodDefinition cachedDefinitions finalizeValues ] timeToRun > 167 > > (my guess that this method was never recompiled with new Eliot's closures). > > Now, if i change it to: > finalizeValues > "Clear all associations with nil keys" > 1 to: array size do:[:i | | assoc | > assoc := array at: i. > array do:[:assoc| > assoc ifNotNil:[ > assoc expire ifTrue:[ > expired := expired + 1. > tally := tally - 1. > ]. > ]. > ]. > > so, #to:do: is inlined by compiler, then numbers is much better: > > [MCMethodDefinition cachedDefinitions finalizeValues ] timeToRun > 4 > > Just try it yourself, if you not believe. > > -- > 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

Oct. 2, 2010

Re: [Pharo-project] Source in image [WAS] Re: [Pharo-users] Distributing 'minimal' image

by Igor Stasenko

>> >> I WOULD LOVE that. I mean, I don't care if the dev image is 10 mb bigger, >> if >> I will improve performance since I don't need to fetch a .sources file. >> what would be awesome is if we can have both, this is: for the dev image, >> I >> would like to have the sources in the image, but not for PharoCore. Or >> maybe >> also in PharoCore but to be sure to be able to remove them, and use >> .sources/decompiler as it is now. Maybe put that in #cleanUpForProduction >> or >> similar. >> >> thoughts? > > You'd also lose versioning, since a trailer can only hold one version of the > source code. Btw, do you really have a performance issue reading the > sources? With Cog and Squeak 4.2, I get: > > methods := CompiledMethod allInstances shuffle. > [ methods do: #getSource ] timeToRun "===> 1162" > > So it takes ~25 microseconds to fetch the source of a method on average. > That's more than 39000 methods per second. It should be enough IMHO. > > Well, you can always change the trailer(s) to hold additional info. As i told before, we need a source management layer, which allows multiple different implementations, then its not quite important how/where we persisting sources, since we could switch between them, or use different source manager on a per-method basis. > Levente > -- Best regards, Igor Stasenko AKA sig.

Oct. 2, 2010

Re: [Pharo-project] "A Mentoring Course on Smalltalk" Code License

by Andres Valloud

I am not sure the code in the book needs a license. After all, eventually you will get the distribution for the source code in question and then you will (should) have an MIT license... does that make sense? On 9/30/10 19:23 , Sean P. DeNigris wrote: > > > Andres Valloud-4 wrote: >> >> Well, since this discussion is public now :) >> > hee hee > > > Andres Valloud-4 wrote: >> >> ... exactly what seems to be >> the problem? The book talks about code that is often in the public >> Store repository. Is the problem that the code in the public Store >> repository doesn't have an MIT license? Or is the problem that the book >> that talks about the code in the public Store repository doesn't say >> "and the code has an MIT license"? >> > > Would a license expert weigh in here? Andres, would it be difficult to add > a note to the book specifying that the code in it is MIT?

Oct. 2, 2010

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

by GermÃ¡n Arduino

Excellent work, thanks 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. > > 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] Source in image [WAS] Re: [Pharo-users] Distributing 'minimal' image

by Levente Uzonyi

On Fri, 1 Oct 2010, Mariano Martinez Peck wrote: > On Fri, Oct 1, 2010 at 8:26 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 1 October 2010 08:48, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >>> >>> >>> On Thu, Sep 30, 2010 at 11:07 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> >> wrote: >>>> >>>> Hi all, >>>> >>>> I am planning to put online a minimal image that contains AspectMaps, >> with >>>> some models pre-loaded. Two questions: >>>> - Is there an easy way to strip this image of dev tools et cetera? >>> >>> Not really. The easiest way is to have a Configuration of Metacello that >>> takes care of loading all your code with all your dependencies. Then, >> take a >>> PharoCore and load your code there. >>> In addition, you may want to evaluate "ScriptLoader cleanUpForProduction" >> at >>> the end. Check the method to see what it does. >>> >>>> >>>> - How can I make it so that I can distribute it without the changes >> file? >>>> (Right now the image complains of a missing changes file if it is not >> there >>>> ...) >>>> >>> >>> I am aware of "Smalltalk abandonSources" to avoid using .sources. You >> won't >>> see things like the temp names, and stuff will be decompiled instead. >> >> With a little effort, you can embed source code into method trailers. >> Then you won't need .sources nor .chanes to see the real source >> instead of decompiling it. >> But you will loose method stamps. >> > > I WOULD LOVE that. I mean, I don't care if the dev image is 10 mb bigger, if > I will improve performance since I don't need to fetch a .sources file. > what would be awesome is if we can have both, this is: for the dev image, I > would like to have the sources in the image, but not for PharoCore. Or maybe > also in PharoCore but to be sure to be able to remove them, and use > .sources/decompiler as it is now. Maybe put that in #cleanUpForProduction or > similar. > > thoughts? You'd also lose versioning, since a trailer can only hold one version of the source code. Btw, do you really have a performance issue reading the sources? With Cog and Squeak 4.2, I get: methods := CompiledMethod allInstances shuffle. [ methods do: #getSource ] timeToRun "===> 1162" So it takes ~25 microseconds to fetch the source of a method on average. That's more than 39000 methods per second. It should be enough IMHO. Levente > > > > >> >>> For the .changes you can start the image without them, there will raise a >>> popup at the beginning. The problem is if you then do sometthing that >> should >>> be written there. Not sure here... >>> >> yeah. >> >>> cheers >>> >>> Mariano >>> >>> >>> >>>> >>>> Thanks in advance! >>>> -- >>>> Johan Fabry >>>> jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry<http://dcc.uchile.cl/%7Ejfabry> >>>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-users mailing list >>>> Pharo-users(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> Pharo-users(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >

Oct. 1, 2010

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

by Sean P. DeNigris

Carla F. Griggio wrote: > > Let me know what are your projects about and how you would use this :O > I've been working on a mind-mapping-like app and some visual browsing tools (e.g. an implementorsOF browser that draws a graph of possible execution paths), and have been implementing connectors-like functionality from scratch, but I'd be happy to give the "from scratch" part up ;-) 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] Chilean mailing list

by Alexandre Bergel

> We've just create a mailing list for discussing about Pharo/Smalltalk in Chile. > pharo-chile(a)googlegroups.com > http://groups.google.com/group/pharo-chile > > Does it make sense ? I ask because maybe with clubSmalltalk (in Spanish) is enough..... Yes it makes sense because most of the members list are from the University of Chile. This means that people know each other. The effect will be different with ClubSmalltalk. Moreover, during my lectures and presentations I talk much more about "Pharo" than "Smalltalk". Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 1, 2010

[Pharo-project] Source in image [WAS] Re: [Pharo-users] Distributing 'minimal' image

by Mariano Martinez Peck

On Fri, Oct 1, 2010 at 8:26 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 1 October 2010 08:48, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > > > On Thu, Sep 30, 2010 at 11:07 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> > wrote: > >> > >> Hi all, > >> > >> I am planning to put online a minimal image that contains AspectMaps, > with > >> some models pre-loaded. Two questions: > >> - Is there an easy way to strip this image of dev tools et cetera? > > > > Not really. The easiest way is to have a Configuration of Metacello that > > takes care of loading all your code with all your dependencies. Then, > take a > > PharoCore and load your code there. > > In addition, you may want to evaluate "ScriptLoader cleanUpForProduction" > at > > the end. Check the method to see what it does. > > > >> > >> - How can I make it so that I can distribute it without the changes > file? > >> (Right now the image complains of a missing changes file if it is not > there > >> ...) > >> > > > > I am aware of "Smalltalk abandonSources" to avoid using .sources. You > won't > > see things like the temp names, and stuff will be decompiled instead. > > With a little effort, you can embed source code into method trailers. > Then you won't need .sources nor .chanes to see the real source > instead of decompiling it. > But you will loose method stamps. > I WOULD LOVE that. I mean, I don't care if the dev image is 10 mb bigger, if I will improve performance since I don't need to fetch a .sources file. what would be awesome is if we can have both, this is: for the dev image, I would like to have the sources in the image, but not for PharoCore. Or maybe also in PharoCore but to be sure to be able to remove them, and use .sources/decompiler as it is now. Maybe put that in #cleanUpForProduction or similar. thoughts? > > > For the .changes you can start the image without them, there will raise a > > popup at the beginning. The problem is if you then do sometthing that > should > > be written there. Not sure here... > > > yeah. > > > cheers > > > > Mariano > > > > > > > >> > >> Thanks in advance! > >> -- > >> Johan Fabry > >> jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry<http://dcc.uchile.cl/%7Ejfabry> > >> PLEIAD Lab - Computer Science Department (DCC) - University of Chile > >> > >> > >> > >> > >> _______________________________________________ > >> Pharo-users mailing list > >> Pharo-users(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > > > > _______________________________________________ > > Pharo-users mailing list > > Pharo-users(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

Oct. 1, 2010

Re: [Pharo-project] Chilean mailing list

by Mariano Martinez Peck

On Fri, Oct 1, 2010 at 10:18 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Hi All! > > We've just create a mailing list for discussing about Pharo/Smalltalk in > Chile. > pharo-chile(a)googlegroups.com > http://groups.google.com/group/pharo-chile > Does it make sense ? I ask because maybe with clubSmalltalk (in Spanish) is enough..... > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 >

Oct. 1, 2010

[Pharo-project] Chilean mailing list

by Alexandre Bergel

Hi All! We've just create a mailing list for discussing about Pharo/Smalltalk in Chile. pharo-chile(a)googlegroups.com http://groups.google.com/group/pharo-chile Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 1, 2010

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

by Carla F. Griggio

I've just arrived home this week, so I made no progress over the last two weeks. But at ESUG I talked a little with Fernando Olivero and made me realize that I'm very close to finish the Minimal Connectors package, at least the minimal minimal connectors XD I'll let you know :) Let me know what are your projects about and how you would use this :O On Fri, Oct 1, 2010 at 4:19 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > > 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. > > _______________________________________________ > 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] [Metacello] Re: loading groups with metacello

by Dale Henrichs

Mariano Martinez Peck wrote: > > > On Fri, Oct 1, 2010 at 7:13 PM, Dale Henrichs <dhenrich(a)vmware.com > <mailto:dhenrich@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> > <mailto:vuquilla@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@lists.gforge.inria.fr> > <mailto:Pharo-project@lists.gforge.inria.fr > <mailto:Pharo-project@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 :) Not necessarily ... I didn't "figure that out" until after I'd understood why Grease was being loaded ... haha! Dale

Oct. 1, 2010

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