- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] [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. -- Pavel > > Issue 6993: update Pharo Kernel generation > http://code.google.com/p/pharo/issues/detail?id=6993 > > Issue 6991: Move #cleanUpForProduction to its own class > http://code.google.com/p/pharo/issues/detail?id=6991 > > > > Diff information: > http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.980.diff > http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.735.diff > http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1284.diff > http://ss3.gemstone.com/ss/Pharo20/Graphics-Display Objects-MarcusDenker.88.diff > > -- > Marcus Denker -- http://marcusdenker.de > >

Nov. 18, 2012

Re: [Pharo-project] Beeper

by Pavel Krivanek

Issue and slice created: http://code.google.com/p/pharo/issues/detail?id=6996 -- Pavel On Sun, Nov 18, 2012 at 9:47 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi Stef, >> >> firstly I do not understand why we have SoundService at all when we >> have AbstractSoundSystem. > > Yes me too :) > >> And why it is a AppRegistry. AppRegistry >> associates some application, tool. It is very confusing to use it for >> a sound provider. Then I do not understand why it is named >> AbstractSoundSystem and not simply SoundSystem (remember >> AbstractString). > > Yes let us clean all that :) > Can you take the lead on that? > We could include the sound package in the release. > >> >> On Sat, Nov 17, 2012 at 9:33 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Hi pavel >>> >>> In fact the registration default sound system is broken and we should fix it. >>> I forgot what is the problem :) >>> >>>> Hi, >>>> >>>> I would like to discuss the Beeper class a little bit. The main >>>> purpose of this class is to provide Beeper beep message and use >>>> SoundService with respect to current sound enabled settings or VM >>>> implemented primitive for beeping. >>> >>> Yes this was the idea and to remove it from smalltalk. >>> >>>> I think that we should: >>>> - move the beep function to UIManager >>>> - change all calls of Beeper beep to UIManager default beep >>>> - in MorphicUIManager use classic Beeper implementation >>>> - move Beeper to System-Sound package >>>> - in default UIManager implementation use VM beep primitive >>> >>> Imagine an headless system without even ui (we did that in the microscopic kernel) and the only interaction >>> we got at the beginning was to do beep. After we could write a file something. >>> So moving beep to UI anything worries me. >> >> On my system the beep primitive does nothing so I use quitPrimitive >> for that ;-) >> >>> >>>> There are two main reasons for that. You surely do not want to listen >>>> beeping server with Pharo images running remote UIs and I want to make >>>> Pharo Kernel independent on SoundService. >>> >>> I see when we load the sound package beep is not using beep primitive but the associated sound. >>> May be Beep should have a kind of call back system >>> by default invoke its own primitive >>> and when sound system is loaded it should invoke sound system via the call back >>> I thought is was like that because I do not want to link sound to kernel that for sure. >>> >>>> What do you think? >>> >>> May be we should simply fix the behavior when adding sound service. >>> >>> Stef >>>> >>>> -- Pavel >>>> >>> >>> >> > >

Nov. 18, 2012

Re: [Pharo-project] [Pharo-Project] About new TxText text model

by Camillo Bruni

On 2012-11-14, at 17:36, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello. > > I look deep at TxText package where Igor and Camillo introduced new text > model. > > Text model based on sequence of span objects. There are now two kind of > spans: CharacterSpan and LineSeparator. Each span has reference to next and > previous spans. There is TxSelection object which contains cursor. So you > can insert new text at cursor, you can cut selection, replace selection > with another text. Such maniulation changes text model structure. It can > create new span objects. It can split current span at cursor position, It > can remove selected spans. Also you can move cursor up, down, left, right. > Cursor always know about current span and span position. > > I like design :). And I want use this package. And I have questions and > suggestions: > > 1) Cursor is end of selection object. So now when you move cursor selection > changed, because start of selection stay same. Am I right? yes > I think cursor movement should always reset selection. It is what we see > with basic text editors. > But cursor now is just instance of TxPosition which implements simple > position protocol (move left, up...). It just change current span and span > position by movement. TxPosition knows nothing about TxSelection object. > That's why I think Cursor class should be introduced here which alway reset > text selection by any move. > And if you want to change selection bounds just get explicitly start or end > of selection and use position api. > What do you think? Humm not so sure about this :). Your argument in favor of a default behavior which conforms to other editors is definitely something to consider. In the end it's not that much work to get the a decent default behavior. Somewhere in the view where you modify the mode you can do `text selection collapse`. If you want you can try to implement it ;) and we see how it feels to use it that way (most probably I will be in favor then..) > 2) Next question about changes notification of text model. First I want > Cursor and Selection objects are annnouncers. So I can implement > CursorPresenter and SelectionPresenter to show such objects and handle > changes. For example when CursorMovedAnnouncement happen I can move cursor > caret morph at appropriate position. this sounds like a good idea! I don't remember if we replace/create new instances of the cursors/selections... This might have an impact on where you want to listen for changes. But definitely we want something like that to decouple the model from any view. > Another idea is make span objects announcers. Maybe it is not good idea but > I want to subscribe at SpanAdded, SpanRemoved. SpanChanged, SpanSplitted. > With such events I can make very simple implementation of TextEditor as > list of SpanMorph's. Maybe it is not optimized solution but I think it is > most simple thing. So I want to try it. > > 3) What about auto wrap behaviour? > If you have auto wrap option at text editors you have line width > restriction. And you should spit real lines of text to visual lines which > satisfed this restriction. And text mode should know about such restriction > because any text insertion can require new visual lines creation. I don't think the basic model should know about the visual lines. We discussed that for a while, but in the end that's purely a view on the basic model. For instance if you want to get the insertion point when clicking on some text view you have to take so many model-unrelated things into account (global transformation, font sizes). > I think insertion single line text at span position should be executed by > special "restriction object". It should return new characters of span which > satisfied that restriction. And it should return new span object (or just > remains characters) which will present new visual lines. Then this "remains > characters" should be inserted to next span at 0 position. > When wrap behavior not needed "restriction object" just inserts new text > into current characters at given position and returns result. > If you agree about such logic please suggest good name for such > "restriction object" and instance variable where it will placed (at TxModel > I think) > > Ok, now what do you think about all this? > I want implement all my suggestions. But first I want listen your opinions. > > Best regards, > Denis

Nov. 18, 2012