- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Seaside] Re: Re: ESUG SummerTalk - Fuel, binary object serializer
by Martin Dias May 26, 2011

May 26, 2011

Hi Yanni, On Wed, May 25, 2011 at 1:10 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 25/05/11 11:53 AM, Mariano Martinez Peck wrote: > >> >> Sorry Yanni, I didn't follow. Could you please explain a bit more? what >> do you want to serialize? do you want to be able to choose some classes >> as light and some as non-light? where do you want to materialize ? in >> the same image or in another one ? When you said discard....what would >> you do with the instances of those non-light classes for example? you >> don't materialize them? and what happens to the objects that were >> pointing to them ? why would be the scenario useful for ? security ? >> > > ==== > Yes, security. Here's my first post again, with different formatting: > > In another use case, I'd like to serialize from one image, and deserialize > in another image - *under end user control*. [e.g. web app] > > > The issue here is that "nasty" code could be introduced: > - 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? > ==== > > So a simple "safe-mode" option on de-serialization would probably be > sufficient. It is a good point. For the moment, when you deserialize a full class into the image, their methods are created, and bytecodes are copied from the stream without any validation check. Anyway, you could deserialize the class, run your own validations, and then install the class (I mean, add the class to Smalltalk globals, do the class initialization, run announcements). > > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >

1 0

Re: [Pharo-project] Do we freeze 1.3?
by Marcus Denker May 26, 2011

May 26, 2011

On May 25, 2011, at 7:41 PM, laurent laffont wrote: > Is 1.3 will be a release of one or two images finally ? > Two, as changing it would mean doing that instead of a release. (remember, a "release" is just a snapshot of what is done, it should never require anything do be done other than what is there. Hmm... don't know if that's understandable ;-) So we just freeze what is ther *now*, and then move on to 1.4. And there than we can do things. > Laurent > > > On Wed, May 25, 2011 at 11:29 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hello, > > 1.3 seems to stabilize... > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.3 > > just 12 issues left. > > We could freeze soon. > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

[Pharo-project] some news about the consortium
by StÃ©phane Ducasse May 25, 2011

May 25, 2011

Hi pharoers yesterday we got a meeting with INRIA people and we discussed the creation of an INRIA consortium. We will follow the INRIA process and propose officially the creation. For that we will have to present a proposal by end of June so we will do it. I would like to see the consortium taking life by end of the year and there are still some work to be done there. Stef

2 2

[Pharo-project] Feedback on Nautilus
by Alexandre Bergel May 25, 2011

May 25, 2011

Hi! * What the icon means? * Can I add a number of packages (based on regular expression?) to a group in one click? Have a look at the 'promote categories' command in OB. It is a bit boring to have to look for a particular package, especially when they are alphabetically ordered. * What can be interesting, is to separate system packages from user packages, as it is done in many IDE. Currently, my packages Spy-* are represented the same way than Kernel. Putting system packages below user packages would improve the situation I feel. Maybe an option to not show system packages would be better. * Nautilus does not seem to work. (Only Nautilus2 does). I open Nautilus and clicking on a package opens an error. Maybe it will be better on one unique browser. This will make your life easier. Just focus on the one you use everyday. * The command "Add in Group ... " raises a DNU. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 1

[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