November 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] traits file-in problem

by Pavel Krivanek

Hi, if I file-out the category Tests-Traits-MOP to own *.st file and then try to load it into the Pharo Kernel, this test will fail because of this expression: self assert: (MOPTestClassA>>#c2) origin = Trait2. in this case it shows that the origin of MOPTestClassA>>#c2 is Trait3. The solution of this issue was to recompile the loaded classes. But it shows that the we miss some mechanism for preservation of system consistency when changing classes with traits. Cheers, -- Pavel

Nov. 19, 2012

[Pharo-project] Support: Redline Smalltalk ...

by James Ladd

Hey All, As you know I really love Smalltalk. So much so I have created a version of it that runs on the Java Virtual Machine. Please can you look at this campaign (http://www.indiegogo.com/smalltalk?a=1366536) and possibly support me raising some money to further develop Redline Smalltalk into a Version 1.0 product. If you hate this sort of post than apologies but you can't blame a developer for trying. Keep well, Rgs, James. http://redline.st

Nov. 19, 2012

Re: [Pharo-project] CachedBlockClosure was gone on purpose?

by Eliot Miranda

I replaced the implementation with one based on properties. It's in Squeak trunk and works fine. The VisualWorks style clean-block implementation is more complex but arguably not better, and being based on become: is less well suited to Squeak. On Sat, Nov 17, 2012 at 4:07 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Nov 17, 2012, at 9:05 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > > On Nov 17, 2012, at 8:20 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > > > >> Because it is not present in 2.0 but I couldn't find any issue about > that. > >> > > Issue was http://code.google.com/p/pharo/issues/detail?id=6708 > > -- > Marcus Denker -- http://marcusdenker.de > > > -- best, Eliot

Nov. 19, 2012

Re: [Pharo-project] about sharing class binding and others

by StÃ©phane Ducasse

On Nov 18, 2012, at 10:40 PM, James Foster wrote: > I don't see the benefit of the added complexity. As it is now, at compile time the reference is not bound to a global but to an Association holding the global. If you want to change the value of the global you can do so and the method will reference the new value. Also, if you want to do name-lookup at runtime you can explicitly code it to do that. > > My objection to always doing run-time name lookup is that I would like to be able to create a module that is self-contained and binds to the the classes I provide without risking that someone else will replace my classes. I would like you to be able to load my module, containing my classes and methods, and we both can be confident that your later changes (including different classes with the same name) will not impact my classes and methods. > > If you want a parameterized module, then the module should be explicitly coded to take a parameter and use it explicitly. yes Module name: 'FOO' binds: #A to: #Core.Z Module name: 'FOO2' binds: #A to: #My.Z My original mail was to measure how much it costs to avoid to have the sharing of the system dictionary class binding in the method literal. Because the design above requires to not share binding. I'm going over the master of camille and I would like to make such points clearer. So with my little investigation it shows that we can support life programming without sharing bindings. Stef > I think it is not as clear to let the module think it is referencing a Point but in fact play a trick on it to have it reference a different class. > > - James > > On Nov 16, 2012, at 6:17 PM, StÃ©phane Ducasse wrote: > >> While I love the idea of sharing the systemDictionary class binding in the method to gain immediate update in case of >> change I was questioning myself if we could not gain from not having (for example to get parametrized modules). >> >> The point is that we are not constantly changing classes especially when not programming but running program. >> >> So let us do some experiments: >> >> CompiledMethod allInstances size >> 58891 >> >> (CompiledMethod allInstances select: [:each | each classBinding value name = #Point]) size >> 100 >> >> [CompiledMethod allInstances select: [:each | each classBinding value name = #Point]] timeToRun >> 23 >> >> this is the best case since classBinding is at a fixed size >> >> now looking for any reference to Point >> >> (CompiledMethod allInstances select: [:cm | >> cm literals anySatisfy: [:each | each class = Association >> and: [each key = #Point ]]]) size >> 134 methods. >> >> [CompiledMethod allInstances select: [:cm | >> cm literals anySatisfy: [:each | each class = Association >> and: [each key = #Point ]]]] timeToRun >> 91 ms >> >> so it looks to me that this sharing is not something that we should not changed if needed. >> >> What do you think? >> >> Stef >> > >

Nov. 18, 2012

Re: [Pharo-project] about sharing class binding and others

by Peter Hugosson-Miller

On Sun, Nov 18, 2012 at 10:40 PM, James Foster <Smalltalk(a)jgfoster.net>wrote: > I don't see the benefit of the added complexity. As it is now, at compile > time the reference is not bound to a global but to an Association holding > the global. If you want to change the value of the global you can do so and > the method will reference the new value. Also, if you want to do > name-lookup at runtime you can explicitly code it to do that. > > My objection to always doing run-time name lookup is that I would like to > be able to create a module that is self-contained and binds to the the > classes I provide without risking that someone else will replace my > classes. I would like you to be able to load my module, containing my > classes and methods, and we both can be confident that your later changes > (including different classes with the same name) will not impact my classes > and methods. > > If you want a parameterized module, then the module should be explicitly > coded to take a parameter and use it explicitly. I think it is not as clear > to let the module think it is referencing a Point but in fact play a trick > on it to have it reference a different class. > > - James > > On Nov 16, 2012, at 6:17 PM, StÃ©phane Ducasse wrote: > > > While I love the idea of sharing the systemDictionary class binding in > the method to gain immediate update in case of > > change I was questioning myself if we could not gain from not having > (for example to get parametrized modules). > > > > The point is that we are not constantly changing classes especially when > not programming but running program. > > > > So let us do some experiments: > > > > CompiledMethod allInstances size > > 58891 > > > > (CompiledMethod allInstances select: [:each | each classBinding value > name = #Point]) size > > 100 > > > > [CompiledMethod allInstances select: [:each | each classBinding value > name = #Point]] timeToRun > > 23 > > > > this is the best case since classBinding is at a fixed size > > > > now looking for any reference to Point > > > > (CompiledMethod allInstances select: [:cm | > > cm literals anySatisfy: [:each | each class = Association > > and: [each > key = #Point ]]]) size > > 134 methods. > > > > [CompiledMethod allInstances select: [:cm | > > cm literals anySatisfy: [:each | each class = Association > > and: [each > key = #Point ]]]] timeToRun > > 91 ms > > > > so it looks to me that this sharing is not something that we should not > changed if needed. > > > > What do you think? > > > > Stef > > > +1 -- Cheers, Peter

Nov. 18, 2012

Re: [Pharo-project] about sharing class binding and others

by James Foster

I don't see the benefit of the added complexity. As it is now, at compile time the reference is not bound to a global but to an Association holding the global. If you want to change the value of the global you can do so and the method will reference the new value. Also, if you want to do name-lookup at runtime you can explicitly code it to do that. My objection to always doing run-time name lookup is that I would like to be able to create a module that is self-contained and binds to the the classes I provide without risking that someone else will replace my classes. I would like you to be able to load my module, containing my classes and methods, and we both can be confident that your later changes (including different classes with the same name) will not impact my classes and methods. If you want a parameterized module, then the module should be explicitly coded to take a parameter and use it explicitly. I think it is not as clear to let the module think it is referencing a Point but in fact play a trick on it to have it reference a different class. - James On Nov 16, 2012, at 6:17 PM, StÃ©phane Ducasse wrote: > While I love the idea of sharing the systemDictionary class binding in the method to gain immediate update in case of > change I was questioning myself if we could not gain from not having (for example to get parametrized modules). > > The point is that we are not constantly changing classes especially when not programming but running program. > > So let us do some experiments: > > CompiledMethod allInstances size > 58891 > > (CompiledMethod allInstances select: [:each | each classBinding value name = #Point]) size > 100 > > [CompiledMethod allInstances select: [:each | each classBinding value name = #Point]] timeToRun > 23 > > this is the best case since classBinding is at a fixed size > > now looking for any reference to Point > > (CompiledMethod allInstances select: [:cm | > cm literals anySatisfy: [:each | each class = Association > and: [each key = #Point ]]]) size > 134 methods. > > [CompiledMethod allInstances select: [:cm | > cm literals anySatisfy: [:each | each class = Association > and: [each key = #Point ]]]] timeToRun > 91 ms > > so it looks to me that this sharing is not something that we should not changed if needed. > > What do you think? > > Stef >

Nov. 18, 2012

[Pharo-project] [update 2.0] #20407

by Marcus Denker

20407 ----- Issue 6998: remove possilbe defaultCanvasClass recursion http://code.google.com/p/pharo/issues/detail?id=6998 Issue 6997: Cleanup some unuses SystemNavigation methods... http://code.google.com/p/pharo/issues/detail?id=6997 Issue 6946: RBParser does not support Pragmas after the temporary declaration http://code.google.com/p/pharo/issues/detail?id=6946 Issue 6945: Specialize RBParser to directly generate RBTermporaryNode and RBArgumentNode http://code.google.com/p/pharo/issues/detail?id=6945 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.982.diff http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.739.diff http://ss3.gemstone.com/ss/Pharo20/PackageInfo-MarcusDenker.91.diff http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1287.diff http://ss3.gemstone.com/ss/Pharo20/AST-Tests-Core-MarcusDenker.17.diff http://ss3.gemstone.com/ss/Pharo20/AST-Core-MarcusDenker.105.diff -- Marcus Denker -- http://marcusdenker.de

Nov. 18, 2012

Re: [Pharo-project] Canvas repackaging (WAS: Re: [update 2.0] #20404)

by Pavel Krivanek

On Sun, Nov 18, 2012 at 8:34 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>> On Sat, Nov 17, 2012 at 9:12 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>> 20404 >>>> ----- >>>> >>>> Issue 6994: move DisplayScreen >> #defaultCanvasClass to Morphic >>>> http://code.google.com/p/pharo/issues/detail?id=6994 >>> >>> This fix has very interesting consequence when loading Morphic. >>> Because when the Morphic package is loaded, it firstly loads >>> Form>>#defaultCanvasClass that calls "Display defaultCanvasClass". But >>> Display is a Form too so before the DisplayScreen implementation >>> (^FormCanvas) is loaded too, it can lead and leads to infinite >>> recursion. >>> >> I actually wonder if we need all the indirection (defaultCanvasClass and friends). >> >> I looked at the senders, and it is not used everywhere... Canvas sometimes is rerenced >> directly, sometimes not. >> >> In addition, Canvas should not be in Morpic but there should be a Canvas package that >> Morphic *uses* but that is completely independend of Morphic. >> >> Marcus > > Does it make sense to create two packages. One for abstract Canvas and > second for Form-based Canvas classes? The current (abstract) Canvas > implementation seems to be messed with direct Forms support too. > > Can for example someone from Athens tell something to this topic? > > However because of atomic loading the repackaging of Canvas classes > may not solve this issue and we need to return FormCanvas in > Form>>defaultCanvasClass directly. > > -- Pavel > http://code.google.com/p/pharo/issues/detail?id=6998 -- Pavel

Nov. 18, 2012

[Pharo-project] Canvas repackaging (WAS: Re: [update 2.0] #20404)

by Pavel Krivanek

>> On Sat, Nov 17, 2012 at 9:12 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> 20404 >>> ----- >>> >>> Issue 6994: move DisplayScreen >> #defaultCanvasClass to Morphic >>> http://code.google.com/p/pharo/issues/detail?id=6994 >> >> This fix has very interesting consequence when loading Morphic. >> Because when the Morphic package is loaded, it firstly loads >> Form>>#defaultCanvasClass that calls "Display defaultCanvasClass". But >> Display is a Form too so before the DisplayScreen implementation >> (^FormCanvas) is loaded too, it can lead and leads to infinite >> recursion. >> > I actually wonder if we need all the indirection (defaultCanvasClass and friends). > > I looked at the senders, and it is not used everywhere... Canvas sometimes is rerenced > directly, sometimes not. > > In addition, Canvas should not be in Morpic but there should be a Canvas package that > Morphic *uses* but that is completely independend of Morphic. > > Marcus Does it make sense to create two packages. One for abstract Canvas and second for Form-based Canvas classes? The current (abstract) Canvas implementation seems to be messed with direct Forms support too. Can for example someone from Athens tell something to this topic? However because of atomic loading the repackaging of Canvas classes may not solve this issue and we need to return FormCanvas in Form>>defaultCanvasClass directly. -- Pavel

Nov. 18, 2012

Re: [Pharo-project] [update 2.0] #20404

by Marcus Denker

On Nov 18, 2012, at 3:45 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > On Sat, Nov 17, 2012 at 9:12 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> 20404 >> ----- >> >> Issue 6994: move DisplayScreen >> #defaultCanvasClass to Morphic >> http://code.google.com/p/pharo/issues/detail?id=6994 > > This fix has very interesting consequence when loading Morphic. > Because when the Morphic package is loaded, it firstly loads > Form>>#defaultCanvasClass that calls "Display defaultCanvasClass". But > Display is a Form too so before the DisplayScreen implementation > (^FormCanvas) is loaded too, it can lead and leads to infinite > recursion. > I actually wonder if we need all the indirection (defaultCanvasClass and friends). I looked at the senders, and it is not used everywhere... Canvas sometimes is rerenced directly, sometimes not. In addition, Canvas should not be in Morpic but there should be a Canvas package that Morphic *uses* but that is completely independend of Morphic. Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 18, 2012