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

Re: [Pharo-project] [Pharo-users] Planning a nice pharo conference :)

by Luc Fabresse

2011/10/13 Norbert Hartl <norbert(a)hartl.name>: > > Am 13.10.2011 um 22:12 schrieb StÃ©phane Ducasse: > >> Hi guys >> >> the last time when we met with sven, we came up with the idea of doing a nice pharo conference targeted at exchanging information, >> frameworks, tips and trick on server set up, community building, drinking beers and more. >> >> So we could host such conference in beginning of may for example. What do you think? >> Would you be interested to join a two-three days conference focusing on dev and business? >> > Of course. And as it is only a 3,5 hour trip by train there is no "no go". > > Norbert > I am in too! Luc > >

Oct. 14, 2011

[Pharo-project] [ANN] Fuel release version 1.7

by Martin Dias

Hi folks! We have released the new version 1.7 of Fuel, a binary serialization framework for Pharo that provides extremely fast deserialization. More information on our home page<http://rmod.lille.inria.fr/web/pier/software/Fuel>. Again, I thank ESUG for sponsoring me through the SummerTalk<http://www.esug.org/wiki/pier/Promotion/SummerTalk/SummerTalk2011> program. You can download this version in Pharo 1.2.1 or 1.3 with: Gofer new squeaksource: 'Fuel'; package: 'ConfigurationOfFuel'; load. ((Smalltalk at: #ConfigurationOfFuel) project version: '1.7') load. The list of changes includes performance optimizations, design clean-ups, and new features. - The FLSerializer and FLMaterializer API has changed. They are no longer implementing the algorithms but are a kind of FaÃ§ade. - Developer guides with examples: Getting Started<http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.7/StreamsGuide>and Customizing the graph<http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.7/Hooks> . - Serialization substitutions: "Store this object instead of me." - Global sends: "Restore me by sending this selector to this global" - Versioning the stream: We prefix the stream with a version number that should match when loading. - Performance optimizations on instances of: -- Word-like classes. (We thank a lot to Henrik Sperre Johansen for your help!) -- ByteString and Symbol. -- Date, Time, Duration and DateAndTime. -- Point and Rectangle. -- MethodDictionary. Now materialization is 2000x faster, thanks to its new rehash without become. - Huge clean-up in Tests package. Cheers! MartÃn Dias

Oct. 14, 2011

Re: [Pharo-project] [squeak-dev] Any serializer can customize serialization strategy?

by HernÃ¡n Morales Durand

Hi Martin 2011/10/13 Martin Dias <tinchodias(a)gmail.com>: > Hi Hernan, > Could your "specific Strings" be instances of a variant of RemoteString that > compresses and decompresses? Then they will occupy less memory in your image > and it would be easier to serializer and deserialize the proxy object. I'd like to keep my objects cross-dialect, so if that's not an issue it would be ok to use a RemoteString. I don't see why it would be easier to serialize/deserialize? > Thanks for the feedback, I also don't like the visitor interface we have for > customizations. In fact, I think it is not a visitor but a double-dispatch. > And I would prefer to merge the two hooks Mariano proposed to something > like: > String >> > fuelMapOn: aDefaultMapper (ExternalCompressor shouldCompressString: self) > ifTrue: [aDefaultMapper mapSubstitution: self by: (ExternalCompressor > compress: self)] ifFalse: [super fuelMapOn: aDefaultMapper] > > Do you like more this way? Absolutely :) > Martin > > On Tue, Oct 11, 2011 at 4:10 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> >> >> On Tue, Oct 11, 2011 at 12:56 AM, HernÃ¡n Morales Durand >> <hernan.morales(a)gmail.com> wrote: >>> >>> Thanks Mariano, >>> >>> That's pretty much what I want, but... why to expose the visitor >>> interface? ;) >> >> Good question. Honesty, it was the only way we have found to do it with >> Fuel. I think (but I am not sure) that one of the drawbacks of the pickle >> format is that it analysis phase (as we call it in Fuel) make some hooks >> more complicated to implement than a classic serializer. >> >>> >>> Just to give a little feedback of what I have in my mind: >>> >>> mySerializer setEngine: ExternalCompressor for: ( MyClass -> >>> #myStringIVar ) >>> >> >> Well, you can also create an specific Fuel cluster for MyClass that does >> exactly that. Basically you have to create FLMyClassCluster, implement >> methods like #serializeWith: and #materializeFrom:Â and there you >> serialize/materialize the specific #myStringIVar with a special way and the >> rest as normal. Then you subclass the FLDefaultMapper, say YourMapper and >> you implement #visitXXX >> Then you have to implement MyClass >> visitXXX. >> Of course, you should be able to generalize such cluster and be able to >> reuse it for different classes or instVars. >> >> I am not saying this is the best way. I am just telling you one possible >> solution you can do by extending Fuel for your needs. Of course, you may >> need to understand how Fuel works first. But of course, we can help if you >> want. >> >>> >>> or >>> >>> mySerializer setEngine: ExternalCompressor for: incomingStream >>> >>> Now with machines generating daily 6 TBytes of raw data, one of the >>> keys will be data compression. >>> >> >> it looks like ;) >> >> >>> >>> 2011/10/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>> > >>> > >>> > On Mon, Oct 10, 2011 at 9:35 PM, HernÃ¡n Morales Durand >>> > <hernan.morales(a)gmail.com> wrote: >>> >> >>> >> Is there any serializer (Fuel/StOMP/Ma object >>> >> serialization/BOSS/SRP/SIXX??) which let me attach an external >>> >> compressor/decompressor for specific Strings to the >>> >> serialization/deserialization process? >>> > >>> > In Fuel you can do: >>> > >>> > String >> fuelSubstitution >>> > Â Â Â ^ ExternalCompressor compress: self >>> > >>> > String >> fuelAccept: aVisitor >>> > Â Â ^ (ExternalCompressor shouldCompressString: self) >>> > Â Â ifTrue: [aVisitor visitSubstitution: self] >>> > Â Â ifFalse: [super fuelAccept: aVisitor] >>> > >>> > But the problem is that if #compress: answers an instance of String, >>> > you >>> > should be careful that if #shouldCompressString:Â asnwers true to the >>> > compressed string, then you will end up in an infinitive loop. >>> > >>> > See: http://rmod.lille.inria.fr/web/pier/software/Fuel/Hooks and >>> > FLHookedSubstitutionTest >>> > >>> > I think StOMP should support this as well: >>> > http://stomp.smalltalk-users.jp/home/how-to-use-stomp/hook-methods >>> > >>> > The previous hook you let you replace the original String with its >>> > compression during serialization. Which make sense because if you are >>> > going >>> > to compress it is better to do it during serialization. >>> > >>> >> With external I mean it could >>> >> be in a separate binary (I could arrange the binding though). >>> > >>> > I am not sure if I understood. >>> > >>> > >>> > >>> >> >>> >> Thanks >>> >> >>> >> HernÃ¡n >>> >> >>> > >>> > >>> > >>> > -- >>> > Mariano >>> > http://marianopeck.wordpress.com >>> > >>> > >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > >

Oct. 14, 2011

Re: [Pharo-project] [update 1.4] #14191

by Alain Plantec

thanks, yes, It could be improved further, tell me or better open issues. for complex trees as in the SettingBrowser, there is not so much gain. background loading is the way to go. Alain On 13/10/2011 22:08, StÃ©phane Ducasse wrote: > Oh yes! > took us some times to get in but it is worth it. > Stef > > > >> This is exciting :) >> >> Doru >> >> >> On 12 Oct 2011, at 11:43, StÃ©phane Ducasse wrote: >> >>> The kind of update we all love :) >>> >>> Stef >>> http://code.google.com/p/pharo/issues/detail?id=4904 >>> 14191 >>> ----- >>> >>> - Speed improvement: 10 to 12 times faster ! >>> the speed is now very near from what is possible with PluggableListMorph. >>> the TimeProfiler is now very efficient. >>> >>> - made MorphTreeModel composable (see MCSliceMaker which is not a MorphTreeModel subclass anymore) >>> >>> - Start to use Annoucements instead of change/update (see MorphTreeSelectionChanged announcement) >>> >>> - no item forgotten when sliding with the mouse for auto multiselection (as in the TestRunner, try to select items with the mouse, some items are not selected if the mouse slides too fast) >>> >>> - no need for TickList* (8 classes) and no need for a CheckList class >> -- >> www.tudorgirba.com >> >> "Beauty is where we see it." >> >> >> >> >

Oct. 14, 2011

Re: [Pharo-project] [vwnc] Any serializer can customize serialization strategy?

by HernÃ¡n Morales Durand

Hi Paul, Thanks for your detailed reply. What you describe seems suitable for my needs (I'm interested in simplest techniques, my problem is complex enough to try premature improvements at the tool level :) however I cannot comment more until I do some real experiments with SRP. Thanks again HernÃ¡n 2011/10/12 Paul Baumann <paul.baumann(a)theice.com>: > HernÃ¡n, > > There are several ways to do it with SRP. > > The encoding supports embedded data (variable and fixed width), so you could do inline serialization. It is clever enough that it is even possible to do this with positional access even to base64 encoded data. Tricks like that are used for example to update individual values in a persistent index. There are simpler techniques that should work for any marshaler... > > All marshalers should have some form of pre-save and post-load exchange. SRP has many ways to pre-save and post-load while maintaining relative references. SRP can even do post-load exchanges after the rest of the object graph is loaded and still keep relative references (without using a #become:). > > Save a proxy in place of the object. The proxy would be a class that you create to do what you want as a post-load actions. You can create the proxy as part of a pre-save action. The proxy can have the encoded binary ByteArray you want embedded in the data. The post-load of the proxy would typically unmarshal the embedded data. Here is an example of a class-based exchange: > > SpecialSaveObject>>srpSavePreMap: aContext > Â Â Â Â ^MyOtherMarshalProxy newFor: self > > MyOtherMarshalerProxy.binData > > MyOtherMarshalerProxy class>>newFor: anObject > Â Â Â Â ^self new save: anObject > > MyOtherMarshalProxy>>save: anObject > Â Â Â Â binData := self marshaler saveAsBinary: anObject. > > MyOtherMarshalerProxy>>srpLoadPostMap: aContext > Â Â Â Â ^OtherMarshaler loadFromBinary: binData > > Depending on your needs, you might want your object to remember the embedded data. In that case, you could store the encoded data in an inst var that is lazy-initialized as a pre-save action and save only that inst var. A post-load action could perhaps read the other attributes from the encoded data that you saved. > > SRP also allows any object to answer back "extended attributes" that are saved with an object (#srpExtendedAttributes) and can be restored after loading (#srpExtendedAttributes:). Extended attributes are typically data you want associated with an object that is not directly referenced by the object. You could save/load encoded data along with the SRP saved object. > > Paul Baumann > > > > -----Original Message----- > From: vwnc-bounces(a)cs.uiuc.edu [mailto:vwnc-bounces@cs.uiuc.edu] On Behalf Of HernÃ¡n Morales Durand > Sent: Monday, October 10, 2011 15:36 > To: Pharo Development; The general-purpose Squeak developers list; vwnc mailing list > Subject: [vwnc] Any serializer can customize serialization strategy? > > Is there any serializer (Fuel/StOMP/Ma object > serialization/BOSS/SRP/SIXX??) which let me attach an external > compressor/decompressor for specific Strings to the > serialization/deserialization process? With external I mean it could > be in a separate binary (I could arrange the binding though). > Thanks > > HernÃ¡n > > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. >

Oct. 14, 2011

[Pharo-project] OSProcess bug in Pharo 1.3

by Sean P. DeNigris

Every time I save my image, UnixOSProcessAccessor>>#grimReaperProcess causes 'MessageNotUnderstood: receiver of "wait" is nil'. Is anyone else experiencing this? Thanks. Sean -- View this message in context: http://forum.world.st/OSProcess-bug-in-Pharo-1-3-tp3903350p3903350.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 14, 2011

Re: [Pharo-project] [squeak-dev] Re: Migrating Complex in a separate package

by Nicolas Cellier

Here is a first commit of Squeak/trunk Complex into a separate Math-Complex package. This is useful for Pharo users at least. No rename, no refactoring (but methods #asComplex and #adaptToComplex:andSend: moved to Number) , just the Squeak version. Nicolas 2011/10/12 Juan Vuletich <juan(a)jvuletich.org>: > Nicolas Cellier wrote: >> >> Thanks all for your answers. >> Too many words for a single post, so I compiled a few comments and >> Complex implementation reflections in this blog entry: >> http://smallissimo.blogspot.com/2011/10/about-complex-in-squeak.html >> >> I'm not satisfied with current status because we are mixing two paradigms. >> >> Note that putting Complex outside the image is also an easy solution >> for playing with paradigms without causing undesired side effects to >> Complex-unaware-Applications. >> But maybe it's too easy to divert like this, and we should better >> think harder ;) >> >> Nicolas >> > > Thanks! Good analysis, hard decision. > > In any case, I don't think it is needed to have Complex as an external > package just for the automatic conversion issue. It is enough to have a > preference. > > Cheers, > Juan Vuletich > >> 2011/10/11 Ricardo Moran <richi.moran(a)gmail.com>: >> >>> >>> On Tue, Oct 11, 2011 at 9:51 AM, Juan Vuletich <juan(a)jvuletich.org> >>> wrote: >>> >>>> >>>> Juan Vuletich wrote: >>>> >>>>> >>>>> Hi Folks, >>>>> >>>>> Rodney Polkinghorne wrote: >>>>> >>>>>> >>>>>> ... >>>>>> >>>>>> extra fact: >>>>>> - Complex is absent from Cuis >>>>>> >>>>>> >>>>> >>>>> Not for long :) . I have already integrated it and will be in next Cuis >>>>> release. I think Complex belongs in the base system. >>>>> >>>> >>>> Oh, forgot to say. I also think that >>>> Â -1 sqrt = 1i >>>> should be true, and I'm working on it (together with some other tweaks >>>> to >>>> #sqrt and friends I'll publish when finished). >>>> >>> >>> +1. I was just about to comment on that one :) >>> It always bothered me that "-1 sqrt" wouldn't answer "1i". It seems like >>> an >>> incomplete implementation, being that we have the class Complex. >>> At the time I "fixed" it by just relying on the fact that the sqrt >>> primitive >>> fails when the receiver is negative, but that solution seems very >>> hackish. I >>> wonder what your solution looks like? :) >>> Cheers, >>> Richo >>> >>> >>>> >>>> Thoughts? >>>> >>>> Cheers, >>>> Juan Vuletich >>>> >>>> >>> >>> >>> >>> >> >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 10.0.1410 / Virus Database: 1522/3943 - Release Date: 10/07/11 >> >> >> >> > > >

Oct. 13, 2011

Re: [Pharo-project] [Pharo-users] Planning a nice pharo conference :)

by Norbert Hartl

Am 13.10.2011 um 22:12 schrieb StÃ©phane Ducasse: > Hi guys > > the last time when we met with sven, we came up with the idea of doing a nice pharo conference targeted at exchanging information, > frameworks, tips and trick on server set up, community building, drinking beers and more. > > So we could host such conference in beginning of may for example. What do you think? > Would you be interested to join a two-three days conference focusing on dev and business? > Of course. And as it is only a 3,5 hour trip by train there is no "no go". Norbert

Oct. 13, 2011

Re: [Pharo-project] Planning a nice pharo conference :)

by Pat Maddox

YES On Oct 13, 2011, at 1:12 PM, StÃ©phane Ducasse wrote: > Hi guys > > the last time when we met with sven, we came up with the idea of doing a nice pharo conference targeted at exchanging information, > frameworks, tips and trick on server set up, community building, drinking beers and more. > > So we could host such conference in beginning of may for example. What do you think? > Would you be interested to join a two-three days conference focusing on dev and business? > > Stef > > > >

Oct. 13, 2011

Re: [Pharo-project] Planning a nice pharo conference :)

by Sven Van Caekenberghe

Me too ! On 13 Oct 2011, at 22:33, Mariano Martinez Peck wrote: > I would like to go :) > > On Thu, Oct 13, 2011 at 10:21 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Good idea! > We should include a research flash track where people can quickly show what they are working on. > For the date, having it near ICSE'12 would be good. > > Alexandre > > > On 13 Oct 2011, at 17:12, StÃ©phane Ducasse wrote: > > > Hi guys > > > > the last time when we met with sven, we came up with the idea of doing a nice pharo conference targeted at exchanging information, > > frameworks, tips and trick on server set up, community building, drinking beers and more. > > > > So we could host such conference in beginning of may for example. What do you think? > > Would you be interested to join a two-three days conference focusing on dev and business? > > > > Stef > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > >

Oct. 13, 2011