- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Ann] Ephemerons for Cog

by Henrik Sperre Johansen

On 24.05.2011 15:30, Chris Cunnington wrote: > On 24 May 2011 14:46, Chris Cunnington<smalltalktelevision at gmail.com <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project>> wrote: > >/ "But if the dependents are stored in some global dictionary from model to > />/ sequence of dependents then the > />/ reference from the global dictionary keeps both the model and the dependents > />/ alive." > / > > > So, how presence of namespaces could make GC faster? > > Well I'm hardly presuming to know, but if you have one dictionary acting as a global namespace. As far as I understood ephemerons, the > problem is you have a single dictionary/namespace. Both the model and the view connect to an object. The model lets it go. The view > doesn't. So this is an object you want to collect, because the model has let it go. This means you have a phantom reference that tricks > the GC. That seems to me to be what ephemerons solve. I'm looking solely at the MVC Eliot mentioned, because shorn of context the > description didn't mean anything to me. "An ephemeron holds onto some object via its key field in a quasi-weak manner such that the garbage collector will only consider the key live if it can be reached from the roots and not reachable by the ephemeron's other inst vars." <- This is the key property of ephemerons. In the case of weak Announcement actionBlock subscription: The block references it's enclosing methodContext. The methodContext receiver instvar references the object whose method created the block. Thus, if you keep a traditional WeakAssociation object -> block, (which you will if object is the subscriber) you will always have a strong reference to object from the value. If this were an ephemeral association, the references to key stored in value are not traversed by the gc, and thus object is not marked in use/subsequently GC'd. Cheers, Henry

May 24, 2011

[Pharo-project] [Ann] Ephemerons for Cog

by Chris Cunnington

On 24 May 2011 14:46, Chris Cunnington<smalltalktelevision at gmail.com <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project>> wrote: >/ "But if the dependents are stored in some global dictionary from model to />/ sequence of dependents then the />/ reference from the global dictionary keeps both the model and the dependents />/ alive." / > So, how presence of namespaces could make GC faster? Well I'm hardly presuming to know, but if you have one dictionary acting as a global namespace. As far as I understood ephemerons, the problem is you have a single dictionary/namespace. Both the model and the view connect to an object. The model lets it go. The view doesn't. So this is an object you want to collect, because the model has let it go. This means you have a phantom reference that tricks the GC. That seems to me to be what ephemerons solve. I'm looking solely at the MVC Eliot mentioned, because shorn of context the description didn't mean anything to me. You have ephemerons to reveal the phantom reference. Bam - then the object gets collected. As this seemed to be all about dictionaries, which I take as being synonymous with namespaces if the model and the view were in separate dictionaries, then you couldn't have the problem that ephemerons solve. I wouldn't take me all that seriously here. I'm just trying to play around after reading Eliot's post three times. Smalltalk being folklore, I'm endeavoring to get you to talk about this just a little bit more. Chris

May 24, 2011

Re: [Pharo-project] [Ann] Ephemerons for Cog

by Toon Verwaest

On 05/24/2011 02:57 PM, Igor Stasenko wrote: > On 24 May 2011 14:46, Chris Cunnington<smalltalktelevision(a)gmail.com> wrote: >> "But if the dependents are stored in some global dictionary from model to >> sequence of dependents then the >> reference from the global dictionary keeps both the model and the dependents >> alive." >> >> When I hear "global dictionary" I think of a namespace. Perhaps namespaces >> could add efficiency to the GC. >> > I don't see how this could improve anything. > During full GC, it has to mark all reachable objects, because those > which won't be marked will be reclaimed. > > So, how presence of namespaces could make GC faster? If you know up-front that the namespace doesn't disappear, you could separate those objects from the rest of the objects (in a separate heap) and avoid marking/sweeping altogether. Basically a multi-heap generational GC; with namespaces rather than just generations based on age. Pointers going from one heap to another would have to go over a handle table, as is usual...

May 24, 2011

Re: [Pharo-project] [Ann] Ephemerons for Cog

by Igor Stasenko

On 24 May 2011 14:46, Chris Cunnington <smalltalktelevision(a)gmail.com> wrote: > "But if the dependents are stored in some global dictionary from model to > sequence of dependents then the > reference from the global dictionary keeps both the model and the dependents > alive." > > When I hear "global dictionary" I think of a namespace. Perhaps namespaces > could add efficiency to the GC. > I don't see how this could improve anything. During full GC, it has to mark all reachable objects, because those which won't be marked will be reclaimed. So, how presence of namespaces could make GC faster? > Chris -- Best regards, Igor Stasenko AKA sig.

May 24, 2011

[Pharo-project] [Ann] Ephemerons for Cog

by Chris Cunnington

"But if the dependents are stored in some global dictionary from model to sequence of dependents then the reference from the global dictionary keeps both the model and the dependents alive." When I hear "global dictionary" I think of a namespace. Perhaps namespaces could add efficiency to the GC. Chris

May 24, 2011

Re: [Pharo-project] [Ann] Ephemerons for Cog

by StÃ©phane Ducasse

thanks for the explanation... it is a nice form of the drawings we have on our boards. Igor implemented them since he could not resist. Stef On May 24, 2011, at 5:28 AM, Eliot Miranda wrote: > > > On Mon, May 23, 2011 at 5:47 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > What is Ephemerons? > > Smart associations that can be used to implement per-object finalization. An ephemeron holds onto some object via its key field in a quasi-weak manner such that the garbage collector will only consider the key live if it can be reached from the roots and not reachable by the ephemeron's other inst vars. If the only references to objects referred to by ephemeron keys are through the other fields of ephemerons with otherwise unreachable keys then the these objects are collectable. The garbage collector works in two phases. First it traces all objects from the roots, topping the trace at any ephemeron whose key is unreachable. The second phase then loops until a fixed point is reached; all ephemerons with unreachable keys are added to the finalization queue and the objects reachable from the key and the ephemeron's other fields are traced. Any ephemerons with unreached keys are added to the finalization queue. This phase continues until no more ephemerons are found. Then, if the finalization queue is non-empty, the GC signals the rest of the system that there are finalizable ephemerons. The image then takes over, drain ing the ephemerons in the queue and sending e.g. mourn to each ephemeron which can then send finalize to its key and remove itself from any dictionaries in which it exists, allowing it and its key to be garbage-collected after finalization. > > What's the rationale? Often one wants to associate state with finalizable objects, such that that state refers back to the finalizable obejcts. The classic examples are views in MVC. RThe views are dependents of some model and we may want want the model to be finalized when no object (including dependents) refer to the model. But we don't want references from the dependents to keep the object alive. But if the dependents are stored in some global dictionary from model to sequence of dependents then the reference from the global dictionary keeps both the model and the dependents alive. If we replace the association with a weak key association then the references from the dependents back to the model keep the model alive. But with ephemerons there is an implicit switch, implemented by the GC, that causes the system to exclude references from the transitive closure of the dependents unless the model is reachable from the roots, excluding references from ephemeron keys. > > So ephemerons provide a mechanism for providing per-instance finalization and property lists (dependents being a special case of property list). They allow the system to detect when an object is reachable from the roots, excluding an arbitrary set of references (reachable from an ephemeron's other fields) which do not count towards an object being considered live. They allow for finalization to be managed by the system, above the VM, while the VM's job is just to determine reachability and liveness. > > make sense? clear as mud? > > best, > Eliot > > > Alexandre > > > > Le 23 mai 2011 Ã 20:43, Igor Stasenko <siguctua(a)gmail.com> a Ã©crit : > > > I felt a bit hacky today and decided to implement Ephemerons. > > > > I tried to run it on both StackVM and Cog VMs, > > it seems to work fine (at least all 4 tests, which my brain were > > capable to produce, are green. ;) > > > > > > You can find the VM code on SqS/VMMaker in package: > > VMMaker-oscog-IgorStasenko.67 > > > > Also, i created a separate issue on Cog issue tracker to track it. > > http://code.google.com/p/cog/issues/detail?id=44 > > > > The implementation may contain a bugs. So, it needs review and testing. > > Now i would like all interested parties to give a feedback and help > > integrating it into our production images. > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > >

May 24, 2011

Re: [Pharo-project] Smalltalk/Pharo User Group in Spain

by StÃ©phane Ducasse

On May 24, 2011, at 12:46 PM, Rafael Luque wrote: > Thank you all for your suggestions, > > This is a probe of another nice feature I like about Smalltalk and Pharo: its great community. Perhaps it is not the most numerous but it is always very accessible and willing to help. > > I don't know the spanish mailing list about Smalltalk or Pharo. Jordi, do you know about it? I will get in contact with Jordi to try to organize an Smalltalk User Group in Madrid area. Their experience in Barcelona would be of great use. > > Stef, I'm seriously thinking about to attend to the next ESUG at Edinburgh. I take the opportunity to find ou if other Smalltalkers from Spain will attend to the event. > > I'm not in relation with any university. Really I'm founder and head of development of a small software company and my main interest is to evaluate the benefits of a future use of Smalltalk in real projects in my company. Is the ESUG's program to give lectures in Smalltalk also available for companies or user groups with no profit motive in mind such us the future Madrid Smalltalk User Group? sure. ESUG is the beat of our community. This is full of energy and fun and you can also decide to pair program with some of us over the week - everything is possible at esug. > Thank you, > > Rafael Luque > > 2011/5/23 Jordi Delgado <jdelgado(a)lsi.upc.edu> > Hi, > > We have a small group in Barcelona, see what we do here: http://smalltalk.cat > (it is in catalan, but I'm sure this is not a problem). We were born as a group > three years ago, and we organized last ESUG conference. > > We are not in the Madrid area, but I think we can help. > > Bests, > > Jordi > > > > > > > Hi Stef, > > > > > > I am in contact with an university in Italy; I do not know what you are meaning with "host a lecture", but if I can help, please tell me. > > > > ESUG has a program to send teacher to teach Smalltalk in University or related places. We can use this program if people wants to get lectures on OOP and Smalltalk. > > So if you have connection and people wants to get in touch with smalltalk but are afraid to do so, then we can do something :) > > > > Stef > > > > > > > > Lorenzo > > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > > > To: <Pharo-project(a)lists.gforge.inria.fr> > > > Cc: "NicolÃ¡s Paez" <nicopaez(a)gmail.com> > > > Sent: Monday, May 23, 2011 9:10 AM > > > Subject: Re: [Pharo-project] Smalltalk/Pharo User Group in Spain > > > > > > > > > Hi rafael > > > > > > > > > Thanks for helping for the translation. are in the spanish speaking mailing-lists? > > > I will probably do a lecture before the esug conference at edinburgh. Are you planning to attend ESUG? > > > Tell us what could be done to help you. Do you have contact with any university where we could host a lecture? > > > would remtote pair programming help you? > > > > > > Stef > > > > > > > > >> > > >> Hi all, > > >> > > >> I'm a software developer with experience mainly based on Java EE and, in the last years, also Groovy and Grails. I'm interesed in Smalltalk and their related frameworks several years ago, so I'm trying to learn about Smalltalk, Pharo, Seaside, etc. by myself. I'm participating in the Pharo By Example translation to spanish and implementing the katas from 12meses12katas [1] chalenge in Pharo. > > >> > > >> In spite of my efforts I'm still far away to be fluent in Smalltalk and I think the interchange with other Smalltalkers could be of great help in my way of learning. For this reason I would like to meet other Smalltalkers in the Madrid area, and perhaps we could organize an Smalltalk User Group in Madrid. Please, anyone is interested? > > >> > > >> [1] http://www.12meses12katas.com/ > > > > > > > > > > > > > > > > > >

May 24, 2011

Re: [Pharo-project] Gettext package?

by StÃ©phane Ducasse

I do not have enough experience so I'm all earing what you have to say. Hilaire? > What is the future of the Gettext package in the PharoNonCorePackages repository? > Is the intention to include it in Pharo core? Should that package become a separate project? Something else? > > I am asking this because I am using it for internationalization support in our Seaside apps (together with the Gettext-Seaside package by Philippe Marschall). > Hence, I created a port of the relevant parts to GemStone, following the "develop in Pharo, deploy in GemStone" philosophy. > > Now, the ported package is a complete duplicate + appropriate changes, but it's better if we create a common package and separate the platform-specific parts out. > But I would not want to interfere with anyone's plans, specifically Hilaire Fernandes' plans, probably (who seems to be the author of the package). > > So, I would like to get in touch with the stakeholders of the package and discuss where it's going. > > cheers > Johan

May 24, 2011

Re: [Pharo-project] Tiling windows

by GastÃ³n Dall' Oglio

Yes! it's really exciting :) "Keep task list open": go to World menu => System => Settings => Search for "task" =>check "Keep task list open". Now, open various system Browsers, Workspaces and other types of windows, and then hold cmd (or alt in linux) and next press right next b next w next a, and so on. Of this manner you can filter various windows of different kind using the task list. TilingWindowManager :/ ... LayoutWindowManager? Sorry for short answer, my English is very poor :( 2011/5/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Ok we need a 1.3 version because now we get excited. > > Stef > > On May 24, 2011, at 8:51 AM, laurent laffont wrote: > > > > > > > 2011/5/24 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> > > Laurent and corious :) > > > > I add some TasklistMorph behavior. With the open list (cmd-rigth or > cmd-left): > > * cmd-up: maximize all windows > > * cmd-down: minimize all windows > > * cmd-b: apply SystemBrowser windows's filter > > * cmd-w: apply Worspace windows's filter > > * cmd-a: remove windows's filter > > > > ** The cmd-b work in 1.2.1, in 1.3 you have to change > TasklistMorph>>keyStroke: because I use OBSystemBrowser class by way of > example and therefore does not perform properly filtered. > > > > > > I did not understand until I enable the setting "Keep task list open" :) > > > > I've started a TilingWindowManager project (I will upload it this evening > on SS) so we can put all our stuff + tests without polluting TaskBar & > Tasklist too much. > > > > Indeed, after 3 days I can't live without the tiling buttons :) > > > > Laurent. > > > > > > > > 2011/5/23 laurent laffont <laurent.laffont(a)gmail.com> > > 2011/5/23 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> > > Laurent, I attached a package I've added some improvements to your work, > I have found useful. Of course I am not knowledgeable about morph, just > added some and perhaps can serve as inspiration. > > > > Thanks GastÃ³n, I like the idea. It will be a good step forward in having > better window management. Now we should rewrite this clean + tests (may be > adding the notion of widgets like in KDE / Gnome). > > > > As windows fill all the space, would be good to have a button to open the > world menu. > > > > I would love having the possibility of splitting the World + back and > forward configuration like Emacs winner mode, keyboard driven. > > > > Since several days I use http://most-advantageous.com/optimal-layout/ on > OSX and there's some great ideas too. > > > > Laurent. > > > > > > > > 2011/5/23 laurent laffont <laurent.laffont(a)gmail.com> > > On 1.2: > > > > Gofer it > > squeaksource: 'LaurentLSandbox'; > > version: 'Polymorph-Widgets-LaurentLaffont.388'; > > load. > > > > > > Then open or move a window so the TaskBar is updated and you have a new > "magic" button on bottom left. > > > > (note this is hacky actually, I will write a nicer version this week if > people like it). > > > > Laurent. > > > > On Mon, May 23, 2011 at 9:06 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > send a cs that we can play with it :) > > > > On May 22, 2011, at 8:25 PM, laurent laffont wrote: > > > > > Hi, > > > > > > what do you think of adding this in Pharo ? > > > > > > |taskbar tileWindowsBlock| > > > > > > tileWindowsBlock := [ > > > |windows numberOfColumns numberOfRows windowWidth windowHeight| > > > windows := (World submorphs select: [:m| m isSystemWindow and: [m > isNotMinimized]]) asOrderedCollection. > > > numberOfColumns := windows size sqrtFloor. > > > numberOfRows := (windows size / numberOfColumns) rounded. > > > windowWidth := World width // numberOfColumns.. > > > windowHeight := World height - taskbar height // numberOfRows. > > > > > > Matrix > > > rows: numberOfRows > > > columns: numberOfColumns > > > tabulate: [:row :column| |window| > > > windows ifNotEmpty: [ > > > window := windows remove: windows first. > > > window > > > bounds: ( > > > ((column - 1 * windowWidth) @ (row - 1 * > windowHeight)) > > > extent: (windowWidth) @ windowHeight) > > > ] > > > ] > > > ]. > > > > > > > > > taskbar := (World submorphs detect: [:m| m isTaskbar]). > > > > > > taskbar > > > addMorph: (IconicButton new > > > target: tileWindowsBlock; > > > actionSelector: #value; > > > labelGraphic: taskbar theme smallWindowIcon; > > > color: Color transparent; > > > yourself). > > > > > > > > > Laurent Laffont - @lolgzs > > > > > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > > > Blog: http://magaloma.blogspot.com/ > > > Developer group: http://cara74.seasidehosting.st > > > > > > > > > > > > > > > > > > > >

May 24, 2011

Re: [Pharo-project] [Ann] Ephemerons for Cog

by Alexandre Bergel

Thanks Eliot for this description. Alexandre On 23 May 2011, at 23:28, Eliot Miranda wrote: > > > On Mon, May 23, 2011 at 5:47 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > What is Ephemerons? > > Smart associations that can be used to implement per-object finalization. An ephemeron holds onto some object via its key field in a quasi-weak manner such that the garbage collector will only consider the key live if it can be reached from the roots and not reachable by the ephemeron's other inst vars. If the only references to objects referred to by ephemeron keys are through the other fields of ephemerons with otherwise unreachable keys then the these objects are collectable. The garbage collector works in two phases. First it traces all objects from the roots, topping the trace at any ephemeron whose key is unreachable. The second phase then loops until a fixed point is reached; all ephemerons with unreachable keys are added to the finalization queue and the objects reachable from the key and the ephemeron's other fields are traced. Any ephemerons with unreached keys are added to the finalization queue. This phase continues until no more ephemerons are found. Then, if the finalization queue is non-empty, the GC signals the rest of the system that there are finalizable ephemerons. The image then takes over, drain ing the ephemerons in the queue and sending e.g. mourn to each ephemeron which can then send finalize to its key and remove itself from any dictionaries in which it exists, allowing it and its key to be garbage-collected after finalization. > > What's the rationale? Often one wants to associate state with finalizable objects, such that that state refers back to the finalizable obejcts. The classic examples are views in MVC. RThe views are dependents of some model and we may want want the model to be finalized when no object (including dependents) refer to the model. But we don't want references from the dependents to keep the object alive. But if the dependents are stored in some global dictionary from model to sequence of dependents then the reference from the global dictionary keeps both the model and the dependents alive. If we replace the association with a weak key association then the references from the dependents back to the model keep the model alive. But with ephemerons there is an implicit switch, implemented by the GC, that causes the system to exclude references from the transitive closure of the dependents unless the model is reachable from the roots, excluding references from ephemeron keys. > > So ephemerons provide a mechanism for providing per-instance finalization and property lists (dependents being a special case of property list). They allow the system to detect when an object is reachable from the roots, excluding an arbitrary set of references (reachable from an ephemeron's other fields) which do not count towards an object being considered live. They allow for finalization to be managed by the system, above the VM, while the VM's job is just to determine reachability and liveness. > > make sense? clear as mud? > > best, > Eliot > > > Alexandre > > > > Le 23 mai 2011 Ã 20:43, Igor Stasenko <siguctua(a)gmail.com> a Ã©crit : > > > I felt a bit hacky today and decided to implement Ephemerons. > > > > I tried to run it on both StackVM and Cog VMs, > > it seems to work fine (at least all 4 tests, which my brain were > > capable to produce, are green. ;) > > > > > > You can find the VM code on SqS/VMMaker in package: > > VMMaker-oscog-IgorStasenko.67 > > > > Also, i created a separate issue on Cog issue tracker to track it. > > http://code.google.com/p/cog/issues/detail?id=44 > > > > The implementation may contain a bugs. So, it needs review and testing. > > Now i would like all interested parties to give a feedback and help > > integrating it into our production images. > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 24, 2011