- Pharo-dev - lists.pharo.org

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

by Lukas Renggli

Ok, I fixed that. The refactoring engine now supports all the 24 (!!!) distinct patterns of defining a subclass/trait in Pharo (see below). Name: Refactoring-Changes-lr.15 Author: lr Time: 2 October 2010, 1:50:13 pm UUID: 82093dfb-e7f2-4ff7-afe7-ac7196632196 Ancestors: Refactoring-Changes-lr.14 - also support subclasses of nil The undo operation of the respective actions should work as well. The exception here is an asymmetry (bug?) in the Pharo class definition strings that causes classes without traits to be printed without the #uses: claus. Evaluating this definition string does not remove the trait composition if the class happens to have one though. Lukas #('`className class instanceVariableNames: `#instanceVariableNames' '`className class uses: `@traitComposition instanceVariableNames: `#instanceVariableNames' '`@superclass subclass: `#className instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category' 'ProtoObject subclass: `#className instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category. `className superclass: `@superclass' '`@superclass subclass: `#className uses: `@traitComposition instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category' 'ProtoObject subclass: `#className uses: `@traitComposition instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category. `className superclass: `@superclass' '`@superclass variableByteSubclass: `#className instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category' 'ProtoObject variableByteSubclass: `#className instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category. `className superclass: `@superclass' '`@superclass variableByteSubclass: `#className uses: `@traitComposition instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category' 'ProtoObject variableByteSubclass: `#className uses: `@traitComposition instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category. `className superclass: `@superclass' '`@superclass variableSubclass: `#className instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category' 'ProtoObject variableSubclass: `#className instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category. `className superclass: `@superclass' '`@superclass variableSubclass: `#className uses: `@traitComposition instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category' 'ProtoObject variableSubclass: `#className uses: `@traitComposition instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category. `className superclass: `@superclass' '`@superclass variableWordSubclass: `#className instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category' 'ProtoObject variableWordSubclass: `#className instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category. `className superclass: `@superclass' '`@superclass variableWordSubclass: `#className uses: `@traitComposition instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category' 'ProtoObject variableWordSubclass: `#className uses: `@traitComposition instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category. `className superclass: `@superclass' '`@superclass weakSubclass: `#className instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category' 'ProtoObject weakSubclass: `#className instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category. `className superclass: `@superclass' '`@superclass weakSubclass: `#className uses: `@traitComposition instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category' 'ProtoObject weakSubclass: `#className uses: `@traitComposition instanceVariableNames: `#instanceVariableNames classVariableNames: `#classVariableNames poolDictionaries: `#poolDictionaries category: `#category. `className superclass: `@superclass' '`traitName classTrait uses: `@traitComposition' 'Trait named: `#traitName uses: `@traitComposition category: `#category') On 2 October 2010 13:01, Lukas Renggli <renggli(a)gmail.com> wrote: >> Lukas, now I have another problem. I am not sure if it is OB latest code >> related, but I think so. > > No, that was always the case. > >> 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 > > Creating a subclass like this was never supported by the refactoring engine. > > You have to write it like: > > nil subclass: #ProtoObject > Â Â Â Â instanceVariableNames: '' > Â Â Â Â classVariableNames: '' > Â Â Â Â poolDictionaries: '' > Â Â Â Â category: 'Kernel-Objects' > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch

Oct. 2, 2010

Re: [Pharo-project] Statistic tools in Pharo

by CÃ©drick BÃ©ler

Le 29 sept. 2010 Ã 15:39, Alexandre Bergel a Ã©crit : >>> Thanks Jimmie. >>> About half of the tests are red. This library is about linear Algebra. Not really about statistics. >>> But thanks for the link! >>> >>> Alexandre >> >> If it's the same as what you can find in VW, in addition to linear algebra, it includes numerical methods for quite a few probability distributions as well though. > > Ok, thanks for the input! FWIW, I plan to implement Bayesian Network in Smalltalk... Nevertheless, it will be more a research project... Until now, I haven't found any project nor code in that direction... except maybe SBN (Simple Bayesian Network) in ruby... 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. 2, 2010

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

by Lukas Renggli

> Lukas, now I have another problem. I am not sure if it is OB latest code > related, but I think so. No, that was always the case. > 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 Creating a subclass like this was never supported by the refactoring engine. You have to write it like: nil subclass: #ProtoObject Â Â Â instanceVariableNames: '' Â Â Â classVariableNames: '' Â Â Â poolDictionaries: '' Â Â Â category: 'Kernel-Objects' Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 2, 2010

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