- Pharo-dev - lists.pharo.org

[Pharo-project] Emacs and Smalltalk code

by Oscar E A CallaÃº

Hi all, I'm using Aquamacs (mac UI for emacs) as my default editor. But I have a problem, when trying to read a .st file, I don't get the syntax highlighting (so all is black-&-white). How I can solve this issue? Cheers.

Oct. 8, 2012

Re: [Pharo-project] Global session object?

by Igor Stasenko

On 8 October 2012 13:41, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 08.10.2012 13:25, Igor Stasenko wrote: >> >> On 8 October 2012 13:06, Henrik Sperre Johansen >> <henrik.s.johansen(a)veloxit.no> wrote: >>> >>> On 08.10.2012 13:03, Henrik Sperre Johansen wrote: >>>> >>>> >>>> >>>> IMO, lazily checking whether the image has been restarted whenever you >>>> want to do something stinks. >>>> Registering to be notified when image starts/stops is a lot better. >>> >>> Not to mention, less error-prone. >>> Miss one session check that the current session is the right one >>> somewhere... and everything might blow up if that is the first piece of >>> functionality used. >>> >> True. >> I did not said that my method should replace old. Sometimes lazy >> initialization is not what you want. >> But having no way to perform lazy initialization is even worse. > > Ah, I just objected to the notion that startup lists inherently stinks, and > took the diametrical view for the sake of argument :) > Yes, lazy initialization has its uses too, but some guidelines/advice* on > when to what those uses are, and when you'd use startUp: registration > instead, is needed I think. > > Notice; in most cases where such cleanup at startup is needed (sockets, > window handles, etc.), additional cleanup is needed when the object goes out > of scope during regular use, and so a registry usually exist. Yes. > Thus, your startup code isn't usually > X allInstancesDo: #something > but > X weakRegistry allEntriesDo: #someting. > > which stinks a whole lot less. > in perfect world, yes :) But world is imperfect.. For example, look here: FT2Handle>>shutDown: quitting "we must not save handles (which are pointers) in the image" self clearRegistry. FreeTypeFace allInstances do:[:i | "destroy any faces that are still being referenced" i isValid ifTrue:[i destroyHandle]]. FT2Handle allSubInstances do: [:h | h beNull]. "if some handle was not registered" because of the above, when i pass freetype faces handles to Cairo, which caching a lot of stuff inside (obviously for performance reasons), when you save an image, and then try to use Cairo after that (like rendering text with same font) an image is crashing. Which means that "we must not save handles (which are pointers) in the image" now blocking me from having nice interoperability with Cairo.. Needless to say that destroying handles will force their recreation after snapshot, since image continues running and will keep using freetype fonts. This is actually the reason why i want to introduce session object(s), so that i can fix freetype code to play more nicely with cairo library. > Cheers, > Henry > > > *So in my view, to use lazy init over startUp registration, it would need > to: > - Concern instance data. > - Not need weak cleanup. > - Be containable to a single accessor > -- Best regards, Igor Stasenko.

Oct. 8, 2012

Re: [Pharo-project] Global session object?

by Igor Stasenko

On 8 October 2012 13:39, David T. Lewis <lewis(a)mail.msen.com> wrote: > I like your idea, but just so this does not get overlooked: > > See also [Stack]Interpreter>>getThisSessionID which is used in e.g. > OSProcessPlugin>>primitiveGetSession for external resource management. > You could move the primitive into the interpreter if you wanted to make > it mandatory. > > This is the same session identifier that is used in the file and socket > plugins, so it might have some advantages over using a newly allocated > object that would not get allocated until after the plugins are already > initialized. But it does need VM support, so your Object new approach is > better in that respect. > yes, i saw that. The issue with sessionID, generated by VM, that there is a chance of collision: globalSessionID := 0. [globalSessionID = 0] whileTrue: [globalSessionID := self cCode: 'time(NULL) + ioMSecs()' inSmalltalk: [(Random new next * SmallInteger maxVal) asInteger]]. while 'Object new' can never collide, no matter what happens :) Also, according to VM sources, this thing is obsolete, or at least not used as it supposedly should be used, like in primitive literal: Interpreter>>primitiveExternalCall "Call an external primitive. The external primitive methods contain as first literal an array consisting of: * The module name (String | Symbol) * The function name (String | Symbol) * The session ID (SmallInteger) [OBSOLETE] * The function index (Integer) in the externalPrimitiveTable (i don't remember where, i also seen more code, when hacking HydraVM, with commented sections of code which dealt with session id, but then turned into NOP). Another question, why session id was not exposed to language by VM (your primitive in OSProcess plugin does that, but since plugin is optional, the question remains the same). The proposed change is trivial to introduce and use, but what important, it don't requires altering VM. Altering VM in order to fix/improve session management, will immediately bring new issue: how to play nicely when running images which expect such feature to be present, while users (for no good reason, of course ;) using old/obsolete VMs to run image. This is yet another thing which demonstrates that the less code you put in VM, the less you have to maintain and care less about compatibility issues. That's why i think that VM should be stupid, contain no complex logic and excessive features, only ones which having good reason to stay there (either no way how to do same thing in language, or gives a nice performance advantage). > Dave -- Best regards, Igor Stasenko.

Oct. 8, 2012

Re: [Pharo-project] Global session object?

by Henrik Sperre Johansen

On 08.10.2012 13:25, Igor Stasenko wrote: > On 8 October 2012 13:06, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> On 08.10.2012 13:03, Henrik Sperre Johansen wrote: >>> >>> >>> IMO, lazily checking whether the image has been restarted whenever you >>> want to do something stinks. >>> Registering to be notified when image starts/stops is a lot better. >> Not to mention, less error-prone. >> Miss one session check that the current session is the right one >> somewhere... and everything might blow up if that is the first piece of >> functionality used. >> > True. > I did not said that my method should replace old. Sometimes lazy > initialization is not what you want. > But having no way to perform lazy initialization is even worse. Ah, I just objected to the notion that startup lists inherently stinks, and took the diametrical view for the sake of argument :) Yes, lazy initialization has its uses too, but some guidelines/advice* on when to what those uses are, and when you'd use startUp: registration instead, is needed I think. Notice; in most cases where such cleanup at startup is needed (sockets, window handles, etc.), additional cleanup is needed when the object goes out of scope during regular use, and so a registry usually exist. Thus, your startup code isn't usually X allInstancesDo: #something but X weakRegistry allEntriesDo: #someting. which stinks a whole lot less. Cheers, Henry *So in my view, to use lazy init over startUp registration, it would need to: - Concern instance data. - Not need weak cleanup. - Be containable to a single accessor

Oct. 8, 2012

Re: [Pharo-project] Global session object?

by David T. Lewis

I like your idea, but just so this does not get overlooked: See also [Stack]Interpreter>>getThisSessionID which is used in e.g. OSProcessPlugin>>primitiveGetSession for external resource management. You could move the primitive into the interpreter if you wanted to make it mandatory. This is the same session identifier that is used in the file and socket plugins, so it might have some advantages over using a newly allocated object that would not get allocated until after the plugins are already initialized. But it does need VM support, so your Object new approach is better in that respect. Dave On Mon, Oct 08, 2012 at 05:11:34AM +0200, Igor Stasenko wrote: > I wanna have this: > > SmalltalkImage>>snapshot: save andQuit: quit > ... > resuming ifTrue: [ session := self newSession ]. > ... > > (where session is additional instance variable of SmalltalkImage). > > SmalltalkImage>>newSession > "Just answer unique object, which never can be identical to any > previous session object, > this is all what we need for detecting session change. > A session object don't needs to carry any state (we have plenty of > other objects in image which can do this for us). it just needs to be > unique" > > ^ Object new. > > SmalltalkImage>>session > ^ session > > then, i can write in own code: > > Smalltalk session == mySession ifFalse: [ self initForNewSession. > mySession := Smalltalk session ] > > So, basically, this little addition allows you to detect whether > session changed or not between > two different calls to your code (given that you remembered the > previous session somewhere). > Currently we don't have such feature, and looking how some existing > code deals with session management, > i see how it can be simplified. > If you want to do something similar today, you will need to register > in startup list.. which IMO stinks ;) > > i don't like using startup lists, since you never know , what is the > right order of resource initialization, > and what inter-dependencies they may form, and changing dependencies > over time will require changing startup order, again and again. Not > fun. > This technique allows you to lazily re-initialize any of your > object(s) due to session change, once the control flow hits your code, > but not before. > (so you don't have to do all accounting at image startup time, you > doing it only when it required/requested, which means shorter image > startup time). > > The notion of session is highly important for external resource management. > > I using it in NativeBoost from very beginning, and wanna propose to > use it globally. > > > -- > Best regards, > Igor Stasenko.

Oct. 8, 2012

Re: [Pharo-project] Global session object?

by Igor Stasenko

On 8 October 2012 13:06, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 08.10.2012 13:03, Henrik Sperre Johansen wrote: >> >> >> >> IMO, lazily checking whether the image has been restarted whenever you >> want to do something stinks. >> Registering to be notified when image starts/stops is a lot better. > > Not to mention, less error-prone. > Miss one session check that the current session is the right one > somewhere... and everything might blow up if that is the first piece of > functionality used. > True. I did not said that my method should replace old. Sometimes lazy initialization is not what you want. But having no way to perform lazy initialization is even worse. > Cheers, > Henry > -- Best regards, Igor Stasenko.

Oct. 8, 2012

Re: [Pharo-project] Global session object?

by Igor Stasenko

On 8 October 2012 13:03, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 08.10.2012 11:31, Camillo Bruni wrote: >> >> Just from the deleted wiki page on our google code project site: >> >> >> Squeak startup and shutdown lists are iterated too often, and startup is >> ignored by the network classes. >> >> = Introduction = >> == Squeak/Pharo Problems == >> Squeak's startup and shutdown lists are not used as such. Each snapshot >> forces a shutdown and then a startup. This is not only inefficient, it is >> unfair to things like open sockets, database connections, etc. Platform >> windows will not be well served: imagine shutting down the entire IDE for a >> snapshot; something needs to be done. > > This is false, using startUp:/shutDown: serves exactly this purpose. > >> >> Dolphin does not free external resources on a snapshot. Resources are >> freed on shutdown (by registering for the shutdown events) and >> pointers/handles are cleared on *startup*. Having worked with it for years, >> I have gone from considering it strange to believing it is the correct >> design. >> >> >> == First Steps Toward a Fix == >> It became clear that my life would be easier given a singleton >> SessionManager that triggers #sessionStarted and #sessionStopped. The open >> question was whether Squeak's startup and shutdown lists with the quitting >> and resuming flags would be enough to reproduce Dolphin's behavior, which is >> to trigger #sessionStarted and #sessionStopped when *and only when* the >> image starts and stops, respectively. Somewhat surprisingly, it appears to >> be. I am left wondering why people have tolerated the need to litter images >> with #initializeNetwork sends; that should be done once every time the image >> starts. > > And this is true, you can achieve the same using startUp:/shutDown: as you > can in Dolphin. > Whether that is the best interface, or a manager/announcer would be better > is a different question. > > Ironically, the session object Igor describes would necessitate the same > kind of intrusive checks as #initializeNetwork. > Then you should do things once at startup. > IMO, lazily checking whether the image has been restarted whenever you want > to do something stinks. > Registering to be notified when image starts/stops is a lot better. > I want both. Doing everything at startup time is not necessary , especially when you want faster startup time. And regarding stinks.. how do you think, a following pseudo-code is less stinky: startup MyClassOne allInstancesDo: [:i | i resetExternalHandle ]. MyOtherClass allInstancesDo: [:i | i clearExternalHandle ]. .... YetAnOtherClass allInstancesDo: [:i | i reinitExternalHandles ]. (a tip: allInstances scanning whole heap) > Cheers, > Henry -- Best regards, Igor Stasenko.

Oct. 8, 2012

Re: [Pharo-project] Global session object?

by Henrik Sperre Johansen

On 08.10.2012 13:03, Henrik Sperre Johansen wrote: > > > IMO, lazily checking whether the image has been restarted whenever you > want to do something stinks. > Registering to be notified when image starts/stops is a lot better. Not to mention, less error-prone. Miss one session check that the current session is the right one somewhere... and everything might blow up if that is the first piece of functionality used. Cheers, Henry

Oct. 8, 2012

Re: [Pharo-project] Global session object?

by Henrik Sperre Johansen

On 08.10.2012 11:31, Camillo Bruni wrote: > Just from the deleted wiki page on our google code project site: > > > Squeak startup and shutdown lists are iterated too often, and startup is ignored by the network classes. > > = Introduction = > == Squeak/Pharo Problems == > Squeak's startup and shutdown lists are not used as such. Each snapshot forces a shutdown and then a startup. This is not only inefficient, it is unfair to things like open sockets, database connections, etc. Platform windows will not be well served: imagine shutting down the entire IDE for a snapshot; something needs to be done. This is false, using startUp:/shutDown: serves exactly this purpose. > > Dolphin does not free external resources on a snapshot. Resources are freed on shutdown (by registering for the shutdown events) and pointers/handles are cleared on *startup*. Having worked with it for years, I have gone from considering it strange to believing it is the correct design. > > > == First Steps Toward a Fix == > It became clear that my life would be easier given a singleton SessionManager that triggers #sessionStarted and #sessionStopped. The open question was whether Squeak's startup and shutdown lists with the quitting and resuming flags would be enough to reproduce Dolphin's behavior, which is to trigger #sessionStarted and #sessionStopped when *and only when* the image starts and stops, respectively. Somewhat surprisingly, it appears to be. I am left wondering why people have tolerated the need to litter images with #initializeNetwork sends; that should be done once every time the image starts. And this is true, you can achieve the same using startUp:/shutDown: as you can in Dolphin. Whether that is the best interface, or a manager/announcer would be better is a different question. Ironically, the session object Igor describes would necessitate the same kind of intrusive checks as #initializeNetwork. IMO, lazily checking whether the image has been restarted whenever you want to do something stinks. Registering to be notified when image starts/stops is a lot better. Cheers, Henry

Oct. 8, 2012

Re: [Pharo-project] Global session object?

by Camillo Bruni

Just from the deleted wiki page on our google code project site: Squeak startup and shutdown lists are iterated too often, and startup is ignored by the network classes. = Introduction = == Squeak/Pharo Problems == Squeak's startup and shutdown lists are not used as such. Each snapshot forces a shutdown and then a startup. This is not only inefficient, it is unfair to things like open sockets, database connections, etc. Platform windows will not be well served: imagine shutting down the entire IDE for a snapshot; something needs to be done. == Dolphin's Solution == Dolphin solves the problem through session managers that control the startup and shutdown sequences; they polymorphically adapt to manage deployed GUI applications, the IDE, console applications, etc. Events triggered off of a singleton session manager sub-instance assist in external resource management. Dolphin does not free external resources on a snapshot. Resources are freed on shutdown (by registering for the shutdown events) and pointers/handles are cleared on *startup*. Having worked with it for years, I have gone from considering it strange to believing it is the correct design. == First Steps Toward a Fix == It became clear that my life would be easier given a singleton SessionManager that triggers #sessionStarted and #sessionStopped. The open question was whether Squeak's startup and shutdown lists with the quitting and resuming flags would be enough to reproduce Dolphin's behavior, which is to trigger #sessionStarted and #sessionStopped when *and only when* the image starts and stops, respectively. Somewhat surprisingly, it appears to be. I am left wondering why people have tolerated the need to litter images with #initializeNetwork sends; that should be done once every time the image starts. == Code == See http://code.google.com/p/pharo/issues/detail?id=1200 On 2012-10-08, at 10:41, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > Yes, session management is cross-cutting concern, so it makes sense to > have it in the system, and not just as a NB feature. > > Object new, is a cool workaround for the unique ID! > > Fernando > > On Mon, Oct 8, 2012 at 8:33 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Hello, >> >> Yes, this sounds good. >> >> Marcus >> >> On Oct 8, 2012, at 5:11 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> I wanna have this: >>> >>> SmalltalkImage>>snapshot: save andQuit: quit >>> ... >>> resuming ifTrue: [ session := self newSession ]. >>> ... >>> >>> (where session is additional instance variable of SmalltalkImage). >>> >>> SmalltalkImage>>newSession >>> "Just answer unique object, which never can be identical to any >>> previous session object, >>> this is all what we need for detecting session change. >>> A session object don't needs to carry any state (we have plenty of >>> other objects in image which can do this for us). it just needs to be >>> unique" >>> >>> ^ Object new. >>> >>> SmalltalkImage>>session >>> ^ session >>> >>> then, i can write in own code: >>> >>> Smalltalk session == mySession ifFalse: [ self initForNewSession. >>> mySession := Smalltalk session ] >>> >>> So, basically, this little addition allows you to detect whether >>> session changed or not between >>> two different calls to your code (given that you remembered the >>> previous session somewhere). >>> Currently we don't have such feature, and looking how some existing >>> code deals with session management, >>> i see how it can be simplified. >>> If you want to do something similar today, you will need to register >>> in startup list.. which IMO stinks ;) >>> >>> i don't like using startup lists, since you never know , what is the >>> right order of resource initialization, >>> and what inter-dependencies they may form, and changing dependencies >>> over time will require changing startup order, again and again. Not >>> fun. >>> This technique allows you to lazily re-initialize any of your >>> object(s) due to session change, once the control flow hits your code, >>> but not before. >>> (so you don't have to do all accounting at image startup time, you >>> doing it only when it required/requested, which means shorter image >>> startup time). >>> >>> The notion of session is highly important for external resource management. >>> >>> I using it in NativeBoost from very beginning, and wanna propose to >>> use it globally. >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >

Oct. 8, 2012