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