- Pharo-dev - lists.pharo.org

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

by Andres Valloud

In VisualWorks, the place where objects that are likely never garbage live is called perm space. You get a GC speedup roughly proportional to the fraction of the image that is perm space (because you don't have to scan it or mark it), as long as the GC is not global (i.e.: when you also want to get rid of perm space garbage). On 5/24/11 7:29 , Igor Stasenko wrote: > On 24 May 2011 15:20, Toon Verwaest<toon.verwaest(a)gmail.com> wrote: >> 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... >> > > Yes. Object spaces with gates between them. > > But this is orthogonal to Ephemerons. > >

May 25, 2011

[Pharo-project] [update 1.3] #13215

by Marcus Denker

13215 ----- Issue 4266: TasklistMorph>>selectTask DNU http://code.google.com/p/pharo/issues/detail?id=4266 Issue 1817: [etoy] Should remove project http://code.google.com/p/pharo/issues/detail?id=1817 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 25, 2011

Re: [Pharo-project] Questions of understanding

by Friedrich Dominicus

Mariano Martinez Peck <marianopeck(a)gmail.com> writes: > https://gitorious.org/cogvm/blessed/blobs/master/platforms/unix/plugins/ > SerialPlugin/sqUnixSerial.c This code contains the old implementaton of the Serial Plugin not the extensions of things like openPortByName. The Serail Plugin I'm talking about has the following implementation on the Smalltalk Size -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

May 25, 2011

Re: [Pharo-project] Gettext package?

by Marcus Denker

On May 24, 2011, at 11:13 PM, Hilaire Fernandes wrote: > I ported the gettext package from Etoys to Pharo with help of other > (Henrik). > I have to admit I mostly forgot about its internal, even if I amn using > it for DrGeo. > In between, some part of the gettext package in Etoys was improved, I > forgot which part exactly. Bert may remember a bit more. > > Do whatever you think is appropriate with the package. As you hacked the > package recently you are definitely in a better position to split it in > different component. > Right now there is support for internationalisation in the image.... but not really used. Would it make sense to replace that with Gettext? (and make gettecht a core feature?) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 25, 2011

Re: [Pharo-project] Questions of understanding

by Friedrich Dominicus

> https://gitorious.org/cogvm/blessed/blobs/master/platforms/unix/plugins/ > SerialPlugin/sqUnixSerial.c > > Â > > So the sources file contains things like openPort but not > openPortByName. So what do I have to do to get into the patches such > that the new SerialPlugin.c can be generated? > > Ah yes I used the pages at > http://marianopeck.wordpress.com/2011/04/10/ > building-the-vm-from-scratch-using-git-and-cmakevmmaker/ > > > > now you can read: http://marianopeck.wordpress.com/2011/04/05/ > first-stop-vms-scm-and-related-stuff > > :) > Â > > for learning that.... Thanks I'll have another look. Regards Friedrich

May 25, 2011

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

by Serge Stinckwich

On Tue, May 24, 2011 at 5:52 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Tue, May 24, 2011 at 12:46 PM, Rafael Luque > <rafael.luque.leiva(a)gmail.com> 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. > > Â <clubSmalltalk(a)googlegroups.com>, > > we are all there :) I guess this is mostly a south-american mailing list :-) How many people from spain here ? Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

May 25, 2011

Re: [Pharo-project] Gettext package?

by Hilaire Fernandes

I ported the gettext package from Etoys to Pharo with help of other (Henrik). I have to admit I mostly forgot about its internal, even if I amn using it for DrGeo. In between, some part of the gettext package in Etoys was improved, I forgot which part exactly. Bert may remember a bit more. Do whatever you think is appropriate with the package. As you hacked the package recently you are definitely in a better position to split it in different component. Hilaire Le 24/05/2011 11:11, Johan Brichau a Ã©crit : > Hi guys, > > 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 > > (see more info below -- mails > > > Begin forwarded message: > >> From: Johan Brichau <johan(a)inceptive.be> >> Date: 24 May 2011 08:26:33 GMT+02:00 >> To: Philippe Marschall <philippe.marschall(a)gmail.com> >> Cc: GemStone Seaside beta discussion <beta(a)seaside.gemstone.com> >> Subject: Re: [GS/SS Beta] Gettext (for use by Gettext-Seaside) ported to Gemstone >> Reply-To: GemStone Seaside beta discussion <beta(a)seaside.gemstone.com> >> >> Hi Philippe, >> >> Yes, those are classes I left out (but they don't have the WA prefix). >> >> I also prefer that there is a shared common package for both platforms but there are more differences spread over several methods. >> Off the top of my head, most differences are located in the MOFile class. Also, the 'startup' methods that are used to trigger a locale refresh when starting the Pharo image are not applicable in Gemstone. >> >> I'm willing to work towards a common package + platform-specific packages. Probably, we have to hear what the Pharo people (and specifically Hilaire Fernandes) think about it. >> >> cheers >> Johan >> >> On 23 May 2011, at 20:08, Philippe Marschall wrote: >> >>> 2011/5/23 Johan Brichau <johan(a)inceptive.be>: >>>> Hi all, >>>> >>>> The Gettext [1] implementation of Pharo has now been ported to Gemstone, such that we can use it for internationalization in web applications together with Gettext-Seaside. >>>> More precisely, the Gettext package is a prerequisite for Gettext-Seaside. >>>> >>>> With the "develop in Pharo, deploy in Gemstone" philosophy, I ported only those parts that are required to deploy the translation files in the Seaside web apps. >>>> The implementation that generates translation files from the codebase is a bit more entrenched into platform-specific libraries. So, one has to generate the translation catalogs to disk in Pharo, edit them with a tool like poedit, and deploy the locale with the Gemstone deployment. >>> >>> Clever. I guess WAGetTextExporter and WATranslatedArgumentsFinder are >>> the classes that don't work in Gemstone. If so I could split the >>> package into a portable part and a Pharo part so you don't need to >>> load them im GemSonte. >>> >>> Cheers >>> Philippe >> > > > -- Education 0.2 -- http://blog.ofset.org/hilaire

May 24, 2011

Re: [Pharo-project] [Seaside] ESUG SummerTalk - Fuel, binary object serializer

by Tudor Girba

Congratulations, Martin! This is great news. I am looking forward to using it even tighter in Moose :) Cheers, Doru On 24 May 2011, at 22:39, Martin Dias wrote: > Hi folks. I am really happy to announce that ESUG is sponsoring me for Fuel development through the ESUG SummerTalk. I am Martin Dias, a student at Buenos Aires, Argentina. The idea behind this SummerTalk is to implement Fuel, a binary, fast and general-purpose object graph serializer in Pharo. It is based on VisualWorks' Parcels ideas. > > Actually, the project has already started since several months. Tristan Bourgois and I started with the project while doing an internship with RMoD, INRIA. Since a couple of months, Mariano Martinez Peck joined the team, and now he is the official mentor in the SummerTalk. > > ESUG website for SummertTalk: http://www.esug.org/wiki/pier/Promotion/SummerTalk/SummerTalk2011 > > The website with all the necessary information is here: http://rmod.lille.inria.fr/web/pier/software/Fuel > It even includes slides explaining the algorithm. In addition, a paper is in progress. > > For the moment, Fuel already provides the following features: > > - Fast pickle format. It is much faster to materialize than to serialize. > - Correctly support class reshape (when the class of serialized objects has changed). > - Serialize ANY kind of object. For the moment there is no object to our knowledge that we cannot serialize and materialize. > - Be able to completely serialize classes and traits (not just a global name). > - Support cycles and avoid duplicates in the graph. > - Integration to Moose with an extension to export and import their models. > - Detection of globals: for example if you serialize Transcript, it is not duplicated and instead managed as a global reference. > - Solve common problems like Set rehash. > - Buffered writing: we use a buffered write stream for the serialization part (thanks Sven!). > - No need of special support from the VM. > - Try to have a good object oriented design. > - Well tested (about 120 tests, for the moment). > - Large set of benchmarks (even benchmarks for Moose extension). > > And of course, there are a lot features for the future. You can see some of them in the website and some in the issue tracker: http://code.google.com/p/fuel/issues/list > > We really appreciate all kind of feedback and comments. If you want to try it, check in the website how to do it. It is extremely easy. > > Once again, I want to thank a lot to ESUG for sponsoring the project. I plan to create a "news" section in the website with some RSS. I will keep you informed. > > Best regards, > Martin > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- www.tudorgirba.com "Being happy is a matter of choice."

May 24, 2011

[Pharo-project] ESUG SummerTalk - Fuel, binary object serializer

by Martin Dias

Hi folks. I am really happy to announce that ESUG is sponsoring me for Fuel development through the ESUG SummerTalk. I am Martin Dias, a student at Buenos Aires, Argentina. The idea behind this SummerTalk is to implement Fuel, a binary, fast and general-purpose object graph serializer in Pharo<http://www.pharo-project.org/>. It is based on VisualWorks' Parcels ideas. Actually, the project has already started since several months. Tristan Bourgois and I started with the project while doing an internship with RMoD, INRIA <http://rmod.lille.inria.fr/web/pier>. Since a couple of months, Mariano Martinez Peck <http://marianopeck.wordpress.com/> joined the team, and now he is the official mentor in the SummerTalk. ESUG website for SummertTalk: http://www.esug.org/wiki/pier/Promotion/SummerTalk/SummerTalk2011 The website with all the necessary information is here: http://rmod.lille.inria.fr/web/pier/software/Fuel It even includes slides explaining the algorithm. In addition, a paper is in progress. For the moment, Fuel already provides the following features: - Fast pickle format. It is much faster to materialize than to serialize. - Correctly support class reshape (when the class of serialized objects has changed). - Serialize ANY kind of object. For the moment there is no object to our knowledge that we cannot serialize and materialize. - Be able to completely serialize classes and traits (not just a global name). - Support cycles and avoid duplicates in the graph. - Integration to Moose <http://www.moosetechnology.org/> with an extension to export and import their models. - Detection of globals: for example if you serialize Transcript, it is not duplicated and instead managed as a global reference. - Solve common problems like Set rehash. - Buffered writing: we use a buffered write stream for the serialization part (thanks Sven!). - No need of special support from the VM. - Try to have a good object oriented design. - Well tested (about 120 tests, for the moment). - Large set of benchmarks (even benchmarks for Moose extension). And of course, there are a lot features for the future. You can see some of them in the website and some in the issue tracker: http://code.google.com/p/fuel/issues/list We really appreciate all kind of feedback and comments. If you want to try it, check in the website how to do it. It is extremely easy. Once again, I want to thank a lot to ESUG for sponsoring the project. I plan to create a "news" section in the website with some RSS. I will keep you informed. Best regards, Martin

May 24, 2011

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

by Rafael Luque

Thank you Mariano, I've just joined to this group. 2011/5/24 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > On Tue, May 24, 2011 at 12:46 PM, Rafael Luque < > rafael.luque.leiva(a)gmail.com> wrote: > >> >> I don't know the spanish mailing list about Smalltalk or Pharo. > > > <clubSmalltalk(a)googlegroups.com>, > > we are all there :) > > >

May 24, 2011