May 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] Dr. Geo II release 11.06
by Hilaire Fernandes May 25, 2011

May 25, 2011

Announced there http://blog.ofset.org/hilaire/index.php?post/drgeo-11-06 The XO version of Dr. Geo II comes with the new COG Smalltalk Virtual Machine from Eliot Miranda, giving an average boost of +300% Feedback welcome! Enjoy Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

1 0

Re: [Pharo-project] [Seaside] Re: ESUG SummerTalk - Fuel, binary object serializer
by Mariano Martinez Peck May 25, 2011

May 25, 2011

On Wed, May 25, 2011 at 5:14 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 24/05/11 4:39 PM, Martin Dias wrote: > >> >> 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. >> > > I had a brief look and will look some more. I may try to use it to > serialize a Pier kernel. > > heheheheh. We would LOVE that. In fact, I told martin few months ago to do EXACTLY that. If you could give it a try or need help, please let us know. > In another use case, I'd like to serialize from one image, and deserialize > in another image - under end user control. The issue here is that "nasty" > code could be introduced: e.g. capture the Fuel output, deserialize, add > nasty code, re-serialize, then send onward for import to image. Would it be > possible to have some sort of "virus" filter? Maybe something like the Star > Trek transporter that can filter out nasty stuff before re-materializing. :) > For a start, maybe an inclusion list and/or an exclusion list of classes and > globals would be useful. > > I guess this should be easy to do. For the moment: - globals objects are hardcoded in #globalNames - globals behaviors (classes and traits) are managed (by default) in kind of "light" serialization. Where we only serialize the global name which means that the class has to be present in Smalltalk globals in the image that you want to materialize. You can change the default behavior and be able to completely serialize a class/trait. But this is much more complicated and it is still work on process (ClassBuilder is not your best friend). Cheers -- Mariano http://marianopeck.wordpress.com

2 2

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

May 25, 2011

13215 ----- Issue 4269: MultiCanvasCharacterScanner is unused http://code.google.com/p/pharo/issues/detail?id=4269 Issue 4271: remove update uploading support from FileList http://code.google.com/p/pharo/issues/detail?id=4271 Issue 4270: SegmentScanner is unused http://code.google.com/p/pharo/issues/detail?id=4270 Issue 4266: TasklistMorph>>selectTask DNU http://code.google.com/p/pharo/issues/detail?id=4266 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

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

May 25, 2011

On May 25, 2011, at 11:03 AM, Henrik Sperre Johansen wrote: > On 25.05.2011 08:14, Marcus Denker wrote: >> 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 > > If you mean String >> #translated, the previous localization functionality in NaturalLanguageTranslator has been replaced by stubs since 1.2. > The System Integration part of gettext package I mentioned hooks into this, and is the expected thing to use for those needing it. > > Personally, I don't think it belongs in Core. But does it belong into that what we call Pharo? -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

3 3

[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