- Pharo-dev - lists.pharo.org

[Pharo-project] Gettext package?
by Johan Brichau May 25, 2011

May 25, 2011

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 >

4 4

[Pharo-project] [update 1.3] #13215
by Marcus Denker May 25, 2011

May 25, 2011

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.

1 1

Re: [Pharo-project] Gettext package?
by Marcus Denker May 25, 2011

May 25, 2011

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.

2 1

[Pharo-project] [Ann] Ephemerons for Cog
by Chris Cunnington May 25, 2011

May 25, 2011

"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

5 5

[Pharo-project] ESUG SummerTalk - Fuel, binary object serializer
by Martin Dias May 24, 2011

May 24, 2011

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

2 1

[Pharo-project] [COTDC] 68 - MultiNewParagraph
by laurent laffont May 24, 2011

May 24, 2011

Today: MultiNewParagraph Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

1 0

[Pharo-project] [COTDC] 67#2 - MultiDisplayScanner
by laurent laffont May 24, 2011

May 24, 2011

Today: MultiDisplayScanner Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

2 2

Re: [Pharo-project] Questions of understanding
by Marcus Denker May 24, 2011

May 24, 2011

On May 24, 2011, at 5:37 PM, Friedrich Dominicus wrote: > Ok I spend my time today on building a new virtual machine. And my > assumptions in my last mail were wrong. The code is not hand-written > but is generated. Now I understand that. But now I see that while > building the virtual machine the stuff probabably is taken form the > PharoV10.sources file from which it seems SerialPlugin.c is build. > PharoV10.sources should not contain any VM Related sources... the VMMaker package has the source for the VM. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

May 24, 2011

http://www.jarober.com/blog/blogView?showComments=true&printTitle=IM_29:_Ph… Stef

1 0

[Pharo-project] [Ann] Ephemerons for Cog
by Chris Cunnington May 24, 2011

May 24, 2011

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

3 2