- Pharo-dev - lists.pharo.org

Re: [Pharo-project] OB column width resizing

by StÃ©phane Ducasse

bill did you check the idea of igor about layout that acts as anchors? Stef On Jun 17, 2011, at 11:49 PM, Schwab,Wilhelm K wrote: > As my Pharo MVP framework grows, I am starting to miss Dolphin's layout managers. The voodoo of automatically inserting splitters is, IMHO, time thrown after bad. We should instead have easy-to-use widgets that do what one expects and then explicitly place them where they belong. > > Dolphin's proportional layouts can be set as horizontal or vertical, and one can add splitters to allow the proportions to be changed. An aspect called #arrangement can be set to zero to make something fixed size or to any number which then becomes that much out of the sum of peer #arrangement values. > > My first priority is to get any type of layout that is reliable with deeply nested composites. Not there yet :( > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean(a)clipperadams.com] > Sent: Friday, June 17, 2011 4:00 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] OB column width resizing > > Lukas Renggli wrote: >> >> See >> http://groups.google.com/group/omnibrowser-dev/browse_thread/thread/3957238… >> > > Thx :( > > -- > View this message in context: http://forum.world.st/OB-column-width-resizing-tp3606264p3606347.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

June 18, 2011

[Pharo-project] SS is down

by laurent laffont

....... sad because it's raining here ...... Laurent

June 18, 2011

Re: [Pharo-project] MethodFinder should use pragmas

by StÃ©phane Ducasse

I understand your fear but we should try and see. For SmallLint the problem is that there are too many rules and we should not have that many annotation. So metadata should be added to the packages. Stef > > On Jun 17, 2011, at 10:33 AM, Damien Cassou wrote: > >> I would like to have your opinion on >> http://code.google.com/p/pharo/issues/detail?id=4426 >> > > > The problem is that it looks not nice to have pragmas in all methods as part of the source code.. > Imagine we do that for 5 different things (e.g. Slint), than the source is smaller than the annotations > and readability suffers... > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

June 18, 2011

Re: [Pharo-project] Integer>>#factorial

by StÃ©phane Ducasse

Is there an interest for security or other points? Stef On Jun 16, 2011, at 12:38 PM, Sven Van Caekenberghe wrote: > Hi, > > On Planet Smalltalk I read about this challenge: http://www.parcplace.net/list/vwnc-archive/1106/msg00080.html the goal being to optimize the current, naive Integer>>#factorial implementation. > > I had some old Lisp code hanging around, implementing an algorithm that I once found somewhere, and I ported it to Smalltalk. I am sure there are faster solutions, but this one is twice as fast as the original while still being easy to understand and it has a useful, safe helper method: > > Integer>>#svcFactorial > "Answer the factorial of the receiver." > > self = 0 ifTrue: [ ^ 1 ]. > self > 0 ifTrue: [ ^ 1 productUpTo: self ]. > self error: 'Not valid for negative integers' > > Integer>>#productUpTo: anInteger > "Answer the product of all integers from the receiver (non-inclusive) up to anInteger (inclusive)." > > | difference split | > self assert: (self between: 0 and: anInteger). > "the idea is to multiply LargePositiveIntegers of approximately the same size" > difference := anInteger - self. > difference = 0 ifTrue: [ ^ 1 ]. > difference = 1 ifTrue: [ ^ anInteger ]. > difference = 2 ifTrue: [ ^ (anInteger - 1) * anInteger ]. > difference = 3 ifTrue: [ ^ (anInteger - 2) * (anInteger - 1) * anInteger ]. > difference = 4 ifTrue: [ ^ (anInteger - 3) * (anInteger - 2) * (anInteger - 1) * anInteger ]. > split := (self + anInteger) bitShift: -1. > ^ (self productUpTo: split) * (split productUpTo: anInteger) > > Would it be a good idea to replace the current implementation with this one ? > > Sven > >

June 18, 2011

Re: [Pharo-project] OSProcess $PATH

by David T. Lewis

On Fri, Jun 17, 2011 at 12:59:27PM -0700, Sean P. DeNigris wrote: > env := OSProcess thisOSProcess environment copy. > path := (env at: #PATH), ':/opt/local/bin/'. > env at: #PATH put: path. > (PipeableOSProcess command: 'docsplit text "my_document.pdf"' environment: > env workingDir: nil input: nil output: nil error: nil errorPipelineStream: > nil) output > > Sean Exactly right. See also #environmentAt:put: which uses a primitive to call the C library putenv() to set the value in the environment of the process in which the VM is running. Dave

June 18, 2011

Re: [Pharo-project] TWM and Keymapping

by laurent laffont

On Fri, Jun 17, 2011 at 3:58 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > BTW, thanks for pushing this! :) > > Indeed, actually I hope Keymapping + TWM + WindowOrganizer will be in 1.4 so we can have a more productive IDE. Laurent. > > On Fri, Jun 17, 2011 at 10:57 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> >> >> On Fri, Jun 17, 2011 at 3:24 AM, laurent laffont < >> laurent.laffont(a)gmail.com> wrote: >> >>> Hi Guillermo, >>> >>> Now TWM works with ConfigurationOfKeymapping 1.8. >>> >>> Gofer it >>> squeaksource: 'TilingWindowManager'; >>> package: 'ConfigurationOfTilingWindowManager'; >>> load. >>> ConfigurationOfTilingWindowManager loadDevelopment. >>> >>> >>> >>> Something I want to fix: if an editor has the focus, TWM shortcuts don't >>> work. >>> >> I've tried: >>> >>> TilingTWMSettings class>>buildKeyMappingSettingsOn: aBuilder >>> <keymap> >>> ..... >>> {PasteUpMorph. SystemWindow. TextEditor. SmalltalkEditor} >>> do: [:aClass| aBuilder attachShortcutCategory: #twmShortcut to: aClass ]. >>> >>> but no success ..... >>> >> >> Probably the TextEditor overrides a shortcut in a non desired way... Does >> it happen for every twm shortcut? We should write a testcase... >> >> >>> >>> >>> >>> Laurent Laffont - @lolgzs <http://twitter.com/#%21/lolgzs> >>> >>> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ >>> Blog: http://magaloma.blogspot.com/ >>> Developer group: http://cara74.seasidehosting.st >>> >>> >> >

June 18, 2011

Re: [Pharo-project] Fuel - a fast object deployment tool

by Nicolas Cellier

2011/6/17 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Fri, Jun 17, 2011 at 2:39 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> 2011/6/17 Eliot Miranda <eliot.miranda(a)gmail.com>: >> > >> > >> > On Fri, Jun 17, 2011 at 1:26 AM, Martin Dias <tinchodias(a)gmail.com> >> > wrote: >> >> >> >> Hi Eliot, >> >> I am very happy to read your mail. >> >> >> >> On Wed, Jun 15, 2011 at 3:29 PM, Eliot Miranda >> >> <eliot.miranda(a)gmail.com> >> >> wrote: >> >>> >> >>> Hi Martin & Mariano, >> >>> Â Â Â regarding filtering. Â Yesterday my colleague Yaron and I >> >>> successfully >> >>> finished our port of Fuel to Newspeak and are successfully using it to >> >>> save >> >>> and restore our data sets; thank you, its a cool framework. Â We had to >> >>> implement two extensions, the first of which the ability to save and >> >>> restore >> >>> Newspeak classes, which is complex because these are instantiated >> >>> classes >> >>> inside instantiated Newspeak modules, not static Smalltalk classes in >> >>> the >> >>> Smalltalk dictionary. Â The second extension is the ability to map >> >>> specific >> >>> objects to nil, to prune objects on the way out. Â I want to discuss >> >>> this >> >>> latter extension. >> >>> In our data set we have a set of references to objects that are >> >>> logically >> >>> not persistent and hence not to be saved. Â I'm sure that this will be >> >>> a >> >>> common case. Â The requirement is for the pickling system to prune >> >>> certain >> >>> objects, typically by arranging that when an object graph is pickled, >> >>> references to the pruned objects are replaced by references to nil. >> >>> Â One way >> >>> of doing this is as described below, by specifiying per-class lists of >> >>> instance variablesÂ whose referents shoudl not be saved. Â But this can >> >>> be >> >>> clumsy; there may be references to objects one wants to prune from >> >>> e.g. more >> >>> than one class, in which case one may have to provide multiple lists >> >>> of the >> >>> relevant inst vars; there may be references to objects one wants to >> >>> prune >> >>> from e.g. collections (e.g. sets and dictionaries) in which case the >> >>> instance variable list approach just doesn't work. >> >>> Here are two more general schemes. Â VFirst, most directly, Fuel could >> >>> provide two filters, implemented in the default mapper, or the core >> >>> analyser. Â One is a set of classes whose instances are not to be >> >>> saved. Â Any >> >>> reference to an instance of a class in the toBePrunedClasses set is >> >>> saved as >> >>> nil. Â The other is a set of instances that are not to be saved, and >> >>> also any >> >>> reference to an instance in the toBePruned setÂ is saved as nil. Â Why >> >>> have >> >>> both? Â It can be convenient and efficient to filter by class (in our >> >>> case we >> >>> had many instances of a specific class, all of which should be >> >>> filtered, and >> >>> finding them could be time consuming), but filtering by class can be >> >>> too >> >>> inflexible, there may indeed be specific instances to exclude (thing >> >>> for >> >>> example of part of the object graph that functions as a cache; pruning >> >>> the >> >>> specific objects in the cache is the right thing to do; pruning all >> >>> instances of classes whose instances exist in the cache may prune too >> >>> much). >> >>> As an example here's how we implemented pruning. Â Our system is called >> >>> Glue, and we start with a mapper for Glue objects, FLGlueMapper: >> >>> FLMapper subclass: #FLGlueMapper >> >>> instanceVariableNames: 'prunedObjectClasses newspeakClassesCluster >> >>> modelClasses' >> >>> classVariableNames: '' >> >>> poolDictionaries: '' >> >>> category: 'Fuel-Core-Mappers' >> >>> It accepts newspeak objects and filters instances in the >> >>> prunedObjectsClasses set, and as a side-effect collects certain >> >>> classes that >> >>> we need in a manifest: >> >>> FLGlueMapper>>accepts: anObject >> >>> "Tells if the received object is handled by this analyzer. Â We want to >> >>> hand-off >> >>> instantiated Newspeak classes to the newspeakClassesCluster, and we >> >>> want >> >>> to record other model classes. Â We want to filter-out instances of any >> >>> class >> >>> in prunedObjectClasses." >> >>> ^anObject isBehavior >> >>> ifTrue: >> >>> [(self isInstantiatedNewspeakClass: anObject) >> >>> ifTrue: [true] >> >>> ifFalse: >> >>> [(anObject inheritsFrom: GlueDataObject) ifTrue: >> >>> [modelClasses add: anObject]. >> >>> false]] >> >>> ifFalse: >> >>> [prunedObjectClasses includes: anObject class] >> >>> It prunes by mapping instances of theÂ prunedObjectClasses to a special >> >>> cluster. Â It can do this in visitObject: since any newspeak objects it >> >>> is >> >>> accepting will be visited in its visitClassOrTrait: method (i.e. it's >> >>> implicit that all arguments to visitObjects: are instances of the >> >>> prunedObjectsClasses set). >> >>> FLGlueMapper>>visitObject: anObject >> >>> analyzer >> >>> mapAndTrace: anObject >> >>> to: FLPrunedObjectsCluster instance >> >>> into: analyzer clustersWithBaselevelObjects >> >>> FLPrunedObjectsCluster is a specialization of the nil,true,false >> >>> cluster >> >>> that maps its objects to nil: >> >>> FLNilTrueFalseCluster subclass: #FLPrunedObjectsCluster >> >>> instanceVariableNames: '' >> >>> classVariableNames: '' >> >>> poolDictionaries: '' >> >>> category: 'Fuel-Core-Clusters' >> >>> FLPrunedObjectsCluster >>serialize: aPrunedObject on: aWriteStream >> >>> super serialize: nil on: aWriteStream >> >>> >> >>> So this would generalize by the analyser having an e.g. >> >>> FLPruningMapper >> >>> as the first mapper, and this having a prunedObjects and a >> >>> priunedObjectClasses set and going something like this: >> >>> FLPruningMapper>>accepts: anObject >> >>> ^(prunedObjects includes: anObject) or: [prunedObjectClasses includes: >> >>> anObject class] >> >>> FLPruningMapperÂ >>visitObject: anObject >> >>> analyzer >> >>> mapAndTrace: anObject >> >>> to: FLPrunedObjectsCluster instance >> >>> into: analyzer clustersWithBaselevelObjects >> >>> and then one would provide accessors in FLSerialzer and/or FLAnalyser >> >>> to >> >>> add objects and classes to theÂ prunedObjects andÂ prunedObjectClasses >> >>> set. >> >>> For efficiency one could arrange that the FLPruningMapper was not >> >>> added >> >>> to the sequence of mappers unless and until objects or classes were >> >>> added >> >>> toÂ theÂ prunedObjects andÂ prunedObjectClasses set. >> >> >> >> Excellent. I love the botanical metaphor of pruning! Of course we can >> >> include FLPruningMapper and FLPrunedObjectsCluster in Fuel. >> >> >> >> We are also interested in pruning objects but not necessarily replacing >> >> them by nil, but for another user defined objects. For example proxies. >> >> We >> >> can extend the pruning stuff for doing that. >> > >> > That was an idea Yaron came up with. Â That instead of >> > usingÂ fuelIgnoredInstanceVariableNames one uses e.g. >> > Object>>objectToSerialize >> > Â Â Â ^self >> > and then if one wants to prune specific inst vars in MyClass one >> > implements >> > MyClass>>objectToSerialize >> > Â Â Â ^self shallowCopy prepareForSerialization >> >> Hi Eliot, >> >> I'm not convinced by the shallowCopy solution, except for the simple >> structures. >> If object graph is complex (have share nodes, loops, ...) then you >> gonna end up in a replication problem equivalent to the one Fuel is >> trying to solve. > > The assumption is that the analyser would create a maximum of one proxy per > object in the graph (default, no proxy) and that it would map objects with > proxies to their proxies. Â So if proxies only nilled out inst vars I don't > see a problem. Â What's attractive about this is that it provides a general > solution to a couple of problems, a) how to replace a class of objects by > some substitute (e.g. nil), b) how to prune state that needn't be saved. Â It > is also conceptually simple; one just creates a proxy instance; no defining > metadata, such as inst var names, and hence the code is always up-to-date > (e.g. a class redefine won't automatically uncover renamed inst vars in > serialization metadata). Ah, OK, it occurs after the graph analysis, which I did not catch at first read. Now I understand better. Nicolas >> >> Nicolas >> >> > MyClass>>prepareForSerialization >> > Â Â Â instVarIDontWantToSerialize := nil. >> > Â Â Â ^self >> > and for objects one doesn't want to serlalize one implements >> > MyNotToBeSerializedClass>>objectToSerialize >> > Â Â Â ^nil >> > So its more general. Â But I would pass the analyser in as an argument, >> > which >> > would allow things like >> > MyPerhapsNotToBeSerializedClass>>objectToSerializeIn: anFLAnalyser >> > Â Â Â ^(anFLAnalyser shouldPrune: self) >> > Â Â Â Â Â ifFalse: [self] >> > Â Â Â Â Â ifTrue: [nil] >> > which would of course be the default in Object: >> > Object>>objectToSerializeIn: anFLAnalyser >> > Â Â Â ^(anFLAnalyser shouldPrune: self)Â ifFalse:: [self] >> > >> >> >> >> >> >>> >> >>> I think both Yaron and I feel the Fuel framework is comprehensible and >> >>> flexible. Â We enjoyed using it and while we took two passes at coming >> >>> up >> >>> with the pruning scheme we liked (our first was based on not >> >>> serializing >> >>> specific ins vars and was much more complex than our second, based on >> >>> pruning instances of specific classes) we got there quickly and will >> >>> very >> >>> little frustration along the way. Â Thank you very much. >> >> >> >> :-) thank you! >> >> >> >>> >> >>> Finally, a couple of things. Â First, it may be more flexible to >> >>> implement >> >>> fuelCluster as fuelClusterIn: anFLAnalyser so that if one is trying to >> >>> override certain parts of the mapping framework an implementation can >> >>> access >> >>> the analyser to find existing clusters, e.g. >> >>> MyClass>>fuelClusterIn: anFLAnalyser >> >>> ^self shouldBeInASpecialCluster >> >>> ifTrue: [anFLAnalyser clusterWithId: MySpecialCluster id] >> >>> ifFalse: [superÂ fuelClusterIn: anFLAnalyser] >> >>> This makes it easier to find a specific unique cluster to handle a >> >>> group >> >>> of objects specially. >> >> >> >> I can't imagine a concrete example but I see that it is more >> >> flexible... >> >> the cluster obtained via double dispatch can be anything polymorphic >> >> with >> >> MySpecialCluster... that's the point? >> > >> > To be honest I'm not sure. Â But passing in the analyser in things like >> > fuelCluster or objectToSerialize is I think a good idea as it provides a >> > convenient communication path which in turn provides considerable >> > flexibility. >> >> >> >> >> >>> >> >>> Lastly, the class-side cluster ids are a bit of a pain. Â It would be >> >>> nice >> >>> to know a) are these byte values or general integer values, i.e. can >> >>> there >> >>> be more than 256 types of cluster?, and b) is there any meaning to the >> >>> ids? >> >>> Â For example, are clusters ordered by id, or is this just an integer >> >>> tag? >> >>> Â Also, some class-side code to assign an unused id would be nice. >> >>> You might think of virtualizing the id scheme. Â For example, if >> >>> FLCluster >> >>> maintained a weak array of all its subclasses then the id of a cluster >> >>> could >> >>> be the index in the array, and the array could be cleaned up >> >>> occasionally. >> >>> Â Then each fuel serialization could start with the list of cluster >> >>> class >> >>> names and ids, so that specific values of ids are specific to a >> >>> particular >> >>> serialization. >> >> >> >> I do agree, these ids are an heritage from the first prototypes of >> >> fuel, >> >> they should be revised. a) yes, it is encoded in only one byte; b) just >> >> an >> >> integer tag, the only purpose of the id was for decoding fast: read a >> >> byte >> >> and then look in a dictionary for the corresponding cluster instance. >> >> We >> >> could even store the cluster class name but that's inefficient. >> > >> > Yes, but how inefficient? Â What's the size of all the cluster names? >> > Â Â Â FLCluster allSubclasses inject: 0 into: [:t :c| t + c name size + 1] >> > 670 >> > >> > So you'd add less than a kilobyte to the size of each serialization and >> > get >> > complete freedom from ids. Â Something to think about. >> >> >> >> Virtualizing the id scheme is a good idea. Much more elegant and >> >> extensible. The current mechanism not only limits the number of >> >> possible >> >> clusters, but also "user defined" extensions can collide, for example >> >> if >> >> your Glue cluster id is the same of the Moose cluster id. >> >> >> >> I added an issue in our tracker. >> >> >> >> If it makes sense, maybe the weak array you suggest can be also used to >> >> avoid instantiating lots of FLObjectCluster like we are doing in >> >> Object: >> >> >> >> fuelCluster >> >> Â Â Â ^ self class isVariable >> >> Â Â Â Â Â Â ifTrue: [ FLVariableObjectCluster for: self class ] >> >> Â Â Â Â Â Â ifFalse: [ FLFixedObjectCluster for: self class ] >> >> >> >> the second time you send fuelCluster to an object, it can reuse the >> >> cluster instance. >> > >> > Right. Â I think that's important, and is one reason why I think passing >> > in >> > the analyser is important, because it allows certain objects to discover >> > existing clusters in the analyzer and join them if they want to, instead >> > of >> > having to invent and maintain their own cluster uniquing solution >> > . >> >>> >> >>> again thanks for a great framework. >> >> >> >> Thanks for your words and the feedback. Is Glue published somewhere? >> > >> > No, and its extremely proprietary :) Â Newspeak however is available and >> > we >> > may end up maintaining a port of Fuel for Newspeak. >> > best regards, >> > Eliot >> > >> >> >> >> regards >> >> Martin >> >> >> >> >> >>> >> >>> best, >> >>> Eliot >> >> >> >> >> >>> >> >>> On Mon, Jun 13, 2011 at 10:16 AM, Mariano Martinez Peck >> >>> <marianopeck(a)gmail.com> wrote: >> >>>> >> >>>> >> >>>> On Thu, Jun 9, 2011 at 3:35 AM, Eliot Miranda >> >>>> <eliot.miranda(a)gmail.com> >> >>>> wrote: >> >>>>> >> >>>>> Hi Martin and Mariano, >> >>>>> Â Â Â a couple of questions. Â What's the right way to exclude certain >> >>>>> objects from the serialization? Â Is there a way of excluding certain >> >>>>> inst >> >>>>> vars from certain objects? >> >>>> >> >>>> >> >>>> Eliot and the rest....Martin implemented this feature in >> >>>> Fuel-MartinDias.258. For the moment, we decided to put >> >>>> #fuelIgnoredInstanceVariableNames at class side. >> >>>> >> >>>> Behavior >> fuelIgnoredInstanceVariableNames >> >>>> Â Â Â "Indicates which variables have to be ignored during >> >>>> serialization." >> >>>> >> >>>> Â Â Â ^#() >> >>>> >> >>>> >> >>>> MyClass class >> fuelIgnoredInstanceVariableNames >> >>>> Â ^ #('instVar1') >> >>>> >> >>>> >> >>>> The impact in speed is nothing, so this is good. Now....we were >> >>>> thinking >> >>>> if it is common to need that 2 different instances of the same class >> >>>> need >> >>>> different instVars to ignore. Is this common ? do you usually need >> >>>> this ? >> >>>> We checked in SIXX and it is at instance side. Java uses the prefix >> >>>> 'transient' so it is at class side... >> >>>> >> >>>> thanks >> >>>> >> >>>> >> >>>> -- >> >>>> Mariano >> >>>> http://marianopeck.wordpress.com >> >>>> >> >>> >> >> >> > >> > > > > -- > best, > Eliot >

June 18, 2011

Re: [Pharo-project] OB column width resizing

by Schwab,Wilhelm K

As my Pharo MVP framework grows, I am starting to miss Dolphin's layout managers. The voodoo of automatically inserting splitters is, IMHO, time thrown after bad. We should instead have easy-to-use widgets that do what one expects and then explicitly place them where they belong. Dolphin's proportional layouts can be set as horizontal or vertical, and one can add splitters to allow the proportions to be changed. An aspect called #arrangement can be set to zero to make something fixed size or to any number which then becomes that much out of the sum of peer #arrangement values. My first priority is to get any type of layout that is reliable with deeply nested composites. Not there yet :( Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean(a)clipperadams.com] Sent: Friday, June 17, 2011 4:00 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] OB column width resizing Lukas Renggli wrote: > > See > http://groups.google.com/group/omnibrowser-dev/browse_thread/thread/3957238… > Thx :( -- View this message in context: http://forum.world.st/OB-column-width-resizing-tp3606264p3606347.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 17, 2011

Re: [Pharo-project] Fuel - a fast object deployment tool

by Eliot Miranda

On Fri, Jun 17, 2011 at 2:39 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/6/17 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > > On Fri, Jun 17, 2011 at 1:26 AM, Martin Dias <tinchodias(a)gmail.com> > wrote: > >> > >> Hi Eliot, > >> I am very happy to read your mail. > >> > >> On Wed, Jun 15, 2011 at 3:29 PM, Eliot Miranda <eliot.miranda(a)gmail.com > > > >> wrote: > >>> > >>> Hi Martin & Mariano, > >>> regarding filtering. Yesterday my colleague Yaron and I > successfully > >>> finished our port of Fuel to Newspeak and are successfully using it to > save > >>> and restore our data sets; thank you, its a cool framework. We had to > >>> implement two extensions, the first of which the ability to save and > restore > >>> Newspeak classes, which is complex because these are instantiated > classes > >>> inside instantiated Newspeak modules, not static Smalltalk classes in > the > >>> Smalltalk dictionary. The second extension is the ability to map > specific > >>> objects to nil, to prune objects on the way out. I want to discuss > this > >>> latter extension. > >>> In our data set we have a set of references to objects that are > logically > >>> not persistent and hence not to be saved. I'm sure that this will be a > >>> common case. The requirement is for the pickling system to prune > certain > >>> objects, typically by arranging that when an object graph is pickled, > >>> references to the pruned objects are replaced by references to nil. > One way > >>> of doing this is as described below, by specifiying per-class lists of > >>> instance variables whose referents shoudl not be saved. But this can > be > >>> clumsy; there may be references to objects one wants to prune from e.g. > more > >>> than one class, in which case one may have to provide multiple lists of > the > >>> relevant inst vars; there may be references to objects one wants to > prune > >>> from e.g. collections (e.g. sets and dictionaries) in which case the > >>> instance variable list approach just doesn't work. > >>> Here are two more general schemes. VFirst, most directly, Fuel could > >>> provide two filters, implemented in the default mapper, or the core > >>> analyser. One is a set of classes whose instances are not to be saved. > Any > >>> reference to an instance of a class in the toBePrunedClasses set is > saved as > >>> nil. The other is a set of instances that are not to be saved, and > also any > >>> reference to an instance in the toBePruned set is saved as nil. Why > have > >>> both? It can be convenient and efficient to filter by class (in our > case we > >>> had many instances of a specific class, all of which should be > filtered, and > >>> finding them could be time consuming), but filtering by class can be > too > >>> inflexible, there may indeed be specific instances to exclude (thing > for > >>> example of part of the object graph that functions as a cache; pruning > the > >>> specific objects in the cache is the right thing to do; pruning all > >>> instances of classes whose instances exist in the cache may prune too > much). > >>> As an example here's how we implemented pruning. Our system is called > >>> Glue, and we start with a mapper for Glue objects, FLGlueMapper: > >>> FLMapper subclass: #FLGlueMapper > >>> instanceVariableNames: 'prunedObjectClasses newspeakClassesCluster > >>> modelClasses' > >>> classVariableNames: '' > >>> poolDictionaries: '' > >>> category: 'Fuel-Core-Mappers' > >>> It accepts newspeak objects and filters instances in the > >>> prunedObjectsClasses set, and as a side-effect collects certain classes > that > >>> we need in a manifest: > >>> FLGlueMapper>>accepts: anObject > >>> "Tells if the received object is handled by this analyzer. We want to > >>> hand-off > >>> instantiated Newspeak classes to the newspeakClassesCluster, and we > want > >>> to record other model classes. We want to filter-out instances of any > >>> class > >>> in prunedObjectClasses." > >>> ^anObject isBehavior > >>> ifTrue: > >>> [(self isInstantiatedNewspeakClass: anObject) > >>> ifTrue: [true] > >>> ifFalse: > >>> [(anObject inheritsFrom: GlueDataObject) ifTrue: > >>> [modelClasses add: anObject]. > >>> false]] > >>> ifFalse: > >>> [prunedObjectClasses includes: anObject class] > >>> It prunes by mapping instances of the prunedObjectClasses to a special > >>> cluster. It can do this in visitObject: since any newspeak objects it > is > >>> accepting will be visited in its visitClassOrTrait: method (i.e. it's > >>> implicit that all arguments to visitObjects: are instances of the > >>> prunedObjectsClasses set). > >>> FLGlueMapper>>visitObject: anObject > >>> analyzer > >>> mapAndTrace: anObject > >>> to: FLPrunedObjectsCluster instance > >>> into: analyzer clustersWithBaselevelObjects > >>> FLPrunedObjectsCluster is a specialization of the nil,true,false > cluster > >>> that maps its objects to nil: > >>> FLNilTrueFalseCluster subclass: #FLPrunedObjectsCluster > >>> instanceVariableNames: '' > >>> classVariableNames: '' > >>> poolDictionaries: '' > >>> category: 'Fuel-Core-Clusters' > >>> FLPrunedObjectsCluster >>serialize: aPrunedObject on: aWriteStream > >>> super serialize: nil on: aWriteStream > >>> > >>> So this would generalize by the analyser having an e.g. FLPruningMapper > >>> as the first mapper, and this having a prunedObjects and a > >>> priunedObjectClasses set and going something like this: > >>> FLPruningMapper>>accepts: anObject > >>> ^(prunedObjects includes: anObject) or: [prunedObjectClasses includes: > >>> anObject class] > >>> FLPruningMapper >>visitObject: anObject > >>> analyzer > >>> mapAndTrace: anObject > >>> to: FLPrunedObjectsCluster instance > >>> into: analyzer clustersWithBaselevelObjects > >>> and then one would provide accessors in FLSerialzer and/or FLAnalyser > to > >>> add objects and classes to the prunedObjects and prunedObjectClasses > set. > >>> For efficiency one could arrange that the FLPruningMapper was not added > >>> to the sequence of mappers unless and until objects or classes were > added > >>> to the prunedObjects and prunedObjectClasses set. > >> > >> Excellent. I love the botanical metaphor of pruning! Of course we can > >> include FLPruningMapper and FLPrunedObjectsCluster in Fuel. > >> > >> We are also interested in pruning objects but not necessarily replacing > >> them by nil, but for another user defined objects. For example proxies. > We > >> can extend the pruning stuff for doing that. > > > > That was an idea Yaron came up with. That instead of > > using fuelIgnoredInstanceVariableNames one uses e.g. > > Object>>objectToSerialize > > ^self > > and then if one wants to prune specific inst vars in MyClass one > implements > > MyClass>>objectToSerialize > > ^self shallowCopy prepareForSerialization > > Hi Eliot, > > I'm not convinced by the shallowCopy solution, except for the simple > structures. > If object graph is complex (have share nodes, loops, ...) then you > gonna end up in a replication problem equivalent to the one Fuel is > trying to solve. > The assumption is that the analyser would create a maximum of one proxy per object in the graph (default, no proxy) and that it would map objects with proxies to their proxies. So if proxies only nilled out inst vars I don't see a problem. What's attractive about this is that it provides a general solution to a couple of problems, a) how to replace a class of objects by some substitute (e.g. nil), b) how to prune state that needn't be saved. It is also conceptually simple; one just creates a proxy instance; no defining metadata, such as inst var names, and hence the code is always up-to-date (e.g. a class redefine won't automatically uncover renamed inst vars in serialization metadata). > Nicolas > > > MyClass>>prepareForSerialization > > instVarIDontWantToSerialize := nil. > > ^self > > and for objects one doesn't want to serlalize one implements > > MyNotToBeSerializedClass>>objectToSerialize > > ^nil > > So its more general. But I would pass the analyser in as an argument, > which > > would allow things like > > MyPerhapsNotToBeSerializedClass>>objectToSerializeIn: anFLAnalyser > > ^(anFLAnalyser shouldPrune: self) > > ifFalse: [self] > > ifTrue: [nil] > > which would of course be the default in Object: > > Object>>objectToSerializeIn: anFLAnalyser > > ^(anFLAnalyser shouldPrune: self) ifFalse:: [self] > > > >> > >> > >>> > >>> I think both Yaron and I feel the Fuel framework is comprehensible and > >>> flexible. We enjoyed using it and while we took two passes at coming > up > >>> with the pruning scheme we liked (our first was based on not > serializing > >>> specific ins vars and was much more complex than our second, based on > >>> pruning instances of specific classes) we got there quickly and will > very > >>> little frustration along the way. Thank you very much. > >> > >> :-) thank you! > >> > >>> > >>> Finally, a couple of things. First, it may be more flexible to > implement > >>> fuelCluster as fuelClusterIn: anFLAnalyser so that if one is trying to > >>> override certain parts of the mapping framework an implementation can > access > >>> the analyser to find existing clusters, e.g. > >>> MyClass>>fuelClusterIn: anFLAnalyser > >>> ^self shouldBeInASpecialCluster > >>> ifTrue: [anFLAnalyser clusterWithId: MySpecialCluster id] > >>> ifFalse: [super fuelClusterIn: anFLAnalyser] > >>> This makes it easier to find a specific unique cluster to handle a > group > >>> of objects specially. > >> > >> I can't imagine a concrete example but I see that it is more flexible... > >> the cluster obtained via double dispatch can be anything polymorphic > with > >> MySpecialCluster... that's the point? > > > > To be honest I'm not sure. But passing in the analyser in things like > > fuelCluster or objectToSerialize is I think a good idea as it provides a > > convenient communication path which in turn provides considerable > > flexibility. > >> > >> > >>> > >>> Lastly, the class-side cluster ids are a bit of a pain. It would be > nice > >>> to know a) are these byte values or general integer values, i.e. can > there > >>> be more than 256 types of cluster?, and b) is there any meaning to the > ids? > >>> For example, are clusters ordered by id, or is this just an integer > tag? > >>> Also, some class-side code to assign an unused id would be nice. > >>> You might think of virtualizing the id scheme. For example, if > FLCluster > >>> maintained a weak array of all its subclasses then the id of a cluster > could > >>> be the index in the array, and the array could be cleaned up > occasionally. > >>> Then each fuel serialization could start with the list of cluster > class > >>> names and ids, so that specific values of ids are specific to a > particular > >>> serialization. > >> > >> I do agree, these ids are an heritage from the first prototypes of fuel, > >> they should be revised. a) yes, it is encoded in only one byte; b) just > an > >> integer tag, the only purpose of the id was for decoding fast: read a > byte > >> and then look in a dictionary for the corresponding cluster instance. We > >> could even store the cluster class name but that's inefficient. > > > > Yes, but how inefficient? What's the size of all the cluster names? > > FLCluster allSubclasses inject: 0 into: [:t :c| t + c name size + 1] > 670 > > > > So you'd add less than a kilobyte to the size of each serialization and > get > > complete freedom from ids. Something to think about. > >> > >> Virtualizing the id scheme is a good idea. Much more elegant and > >> extensible. The current mechanism not only limits the number of possible > >> clusters, but also "user defined" extensions can collide, for example if > >> your Glue cluster id is the same of the Moose cluster id. > >> > >> I added an issue in our tracker. > >> > >> If it makes sense, maybe the weak array you suggest can be also used to > >> avoid instantiating lots of FLObjectCluster like we are doing in Object: > >> > >> fuelCluster > >> ^ self class isVariable > >> ifTrue: [ FLVariableObjectCluster for: self class ] > >> ifFalse: [ FLFixedObjectCluster for: self class ] > >> > >> the second time you send fuelCluster to an object, it can reuse the > >> cluster instance. > > > > Right. I think that's important, and is one reason why I think passing > in > > the analyser is important, because it allows certain objects to discover > > existing clusters in the analyzer and join them if they want to, instead > of > > having to invent and maintain their own cluster uniquing solution > > . > >>> > >>> again thanks for a great framework. > >> > >> Thanks for your words and the feedback. Is Glue published somewhere? > > > > No, and its extremely proprietary :) Newspeak however is available and > we > > may end up maintaining a port of Fuel for Newspeak. > > best regards, > > Eliot > > > >> > >> regards > >> Martin > >> > >> > >>> > >>> best, > >>> Eliot > >> > >> > >>> > >>> On Mon, Jun 13, 2011 at 10:16 AM, Mariano Martinez Peck > >>> <marianopeck(a)gmail.com> wrote: > >>>> > >>>> > >>>> On Thu, Jun 9, 2011 at 3:35 AM, Eliot Miranda < > eliot.miranda(a)gmail.com> > >>>> wrote: > >>>>> > >>>>> Hi Martin and Mariano, > >>>>> a couple of questions. What's the right way to exclude certain > >>>>> objects from the serialization? Is there a way of excluding certain > inst > >>>>> vars from certain objects? > >>>> > >>>> > >>>> Eliot and the rest....Martin implemented this feature in > >>>> Fuel-MartinDias.258. For the moment, we decided to put > >>>> #fuelIgnoredInstanceVariableNames at class side. > >>>> > >>>> Behavior >> fuelIgnoredInstanceVariableNames > >>>> "Indicates which variables have to be ignored during > serialization." > >>>> > >>>> ^#() > >>>> > >>>> > >>>> MyClass class >> fuelIgnoredInstanceVariableNames > >>>> ^ #('instVar1') > >>>> > >>>> > >>>> The impact in speed is nothing, so this is good. Now....we were > thinking > >>>> if it is common to need that 2 different instances of the same class > need > >>>> different instVars to ignore. Is this common ? do you usually need > this ? > >>>> We checked in SIXX and it is at instance side. Java uses the prefix > >>>> 'transient' so it is at class side... > >>>> > >>>> thanks > >>>> > >>>> > >>>> -- > >>>> Mariano > >>>> http://marianopeck.wordpress.com > >>>> > >>> > >> > > > > > -- best, Eliot

June 17, 2011

Re: [Pharo-project] Fuel - a fast object deployment tool

by Nicolas Cellier

2011/6/17 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Fri, Jun 17, 2011 at 1:26 AM, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> Hi Eliot, >> I am very happy to read your mail. >> >> On Wed, Jun 15, 2011 at 3:29 PM, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >>> >>> Hi Martin & Mariano, >>> Â Â Â regarding filtering. Â Yesterday my colleague Yaron and I successfully >>> finished our port of Fuel to Newspeak and are successfully using it to save >>> and restore our data sets; thank you, its a cool framework. Â We had to >>> implement two extensions, the first of which the ability to save and restore >>> Newspeak classes, which is complex because these are instantiated classes >>> inside instantiated Newspeak modules, not static Smalltalk classes in the >>> Smalltalk dictionary. Â The second extension is the ability to map specific >>> objects to nil, to prune objects on the way out. Â I want to discuss this >>> latter extension. >>> In our data set we have a set of references to objects that are logically >>> not persistent and hence not to be saved. Â I'm sure that this will be a >>> common case. Â The requirement is for the pickling system to prune certain >>> objects, typically by arranging that when an object graph is pickled, >>> references to the pruned objects are replaced by references to nil. Â One way >>> of doing this is as described below, by specifiying per-class lists of >>> instance variablesÂ whose referents shoudl not be saved. Â But this can be >>> clumsy; there may be references to objects one wants to prune from e.g. more >>> than one class, in which case one may have to provide multiple lists of the >>> relevant inst vars; there may be references to objects one wants to prune >>> from e.g. collections (e.g. sets and dictionaries) in which case the >>> instance variable list approach just doesn't work. >>> Here are two more general schemes. Â VFirst, most directly, Fuel could >>> provide two filters, implemented in the default mapper, or the core >>> analyser. Â One is a set of classes whose instances are not to be saved. Â Any >>> reference to an instance of a class in the toBePrunedClasses set is saved as >>> nil. Â The other is a set of instances that are not to be saved, and also any >>> reference to an instance in the toBePruned setÂ is saved as nil. Â Why have >>> both? Â It can be convenient and efficient to filter by class (in our case we >>> had many instances of a specific class, all of which should be filtered, and >>> finding them could be time consuming), but filtering by class can be too >>> inflexible, there may indeed be specific instances to exclude (thing for >>> example of part of the object graph that functions as a cache; pruning the >>> specific objects in the cache is the right thing to do; pruning all >>> instances of classes whose instances exist in the cache may prune too much). >>> As an example here's how we implemented pruning. Â Our system is called >>> Glue, and we start with a mapper for Glue objects, FLGlueMapper: >>> FLMapper subclass: #FLGlueMapper >>> instanceVariableNames: 'prunedObjectClasses newspeakClassesCluster >>> modelClasses' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Fuel-Core-Mappers' >>> It accepts newspeak objects and filters instances in the >>> prunedObjectsClasses set, and as a side-effect collects certain classes that >>> we need in a manifest: >>> FLGlueMapper>>accepts: anObject >>> "Tells if the received object is handled by this analyzer. Â We want to >>> hand-off >>> instantiated Newspeak classes to the newspeakClassesCluster, and we want >>> to record other model classes. Â We want to filter-out instances of any >>> class >>> in prunedObjectClasses." >>> ^anObject isBehavior >>> ifTrue: >>> [(self isInstantiatedNewspeakClass: anObject) >>> ifTrue: [true] >>> ifFalse: >>> [(anObject inheritsFrom: GlueDataObject) ifTrue: >>> [modelClasses add: anObject]. >>> false]] >>> ifFalse: >>> [prunedObjectClasses includes: anObject class] >>> It prunes by mapping instances of theÂ prunedObjectClasses to a special >>> cluster. Â It can do this in visitObject: since any newspeak objects it is >>> accepting will be visited in its visitClassOrTrait: method (i.e. it's >>> implicit that all arguments to visitObjects: are instances of the >>> prunedObjectsClasses set). >>> FLGlueMapper>>visitObject: anObject >>> analyzer >>> mapAndTrace: anObject >>> to: FLPrunedObjectsCluster instance >>> into: analyzer clustersWithBaselevelObjects >>> FLPrunedObjectsCluster is a specialization of the nil,true,false cluster >>> that maps its objects to nil: >>> FLNilTrueFalseCluster subclass: #FLPrunedObjectsCluster >>> instanceVariableNames: '' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Fuel-Core-Clusters' >>> FLPrunedObjectsCluster >>serialize: aPrunedObject on: aWriteStream >>> super serialize: nil on: aWriteStream >>> >>> So this would generalize by the analyser having an e.g. FLPruningMapper >>> as the first mapper, and this having a prunedObjects and a >>> priunedObjectClasses set and going something like this: >>> FLPruningMapper>>accepts: anObject >>> ^(prunedObjects includes: anObject) or: [prunedObjectClasses includes: >>> anObject class] >>> FLPruningMapperÂ >>visitObject: anObject >>> analyzer >>> mapAndTrace: anObject >>> to: FLPrunedObjectsCluster instance >>> into: analyzer clustersWithBaselevelObjects >>> and then one would provide accessors in FLSerialzer and/or FLAnalyser to >>> add objects and classes to theÂ prunedObjects andÂ prunedObjectClasses set. >>> For efficiency one could arrange that the FLPruningMapper was not added >>> to the sequence of mappers unless and until objects or classes were added >>> toÂ theÂ prunedObjects andÂ prunedObjectClasses set. >> >> Excellent. I love the botanical metaphor of pruning! Of course we can >> include FLPruningMapper and FLPrunedObjectsCluster in Fuel. >> >> We are also interested in pruning objects but not necessarily replacing >> them by nil, but for another user defined objects. For example proxies. We >> can extend the pruning stuff for doing that. > > That was an idea Yaron came up with. Â That instead of > usingÂ fuelIgnoredInstanceVariableNames one uses e.g. > Object>>objectToSerialize > Â Â Â ^self > and then if one wants to prune specific inst vars in MyClass one implements > MyClass>>objectToSerialize > Â Â Â ^self shallowCopy prepareForSerialization Hi Eliot, I'm not convinced by the shallowCopy solution, except for the simple structures. If object graph is complex (have share nodes, loops, ...) then you gonna end up in a replication problem equivalent to the one Fuel is trying to solve. Nicolas > MyClass>>prepareForSerialization > Â Â Â instVarIDontWantToSerialize := nil. > Â Â Â ^self > and for objects one doesn't want to serlalize one implements > MyNotToBeSerializedClass>>objectToSerialize > Â Â Â ^nil > So its more general. Â But I would pass the analyser in as an argument, which > would allow things like > MyPerhapsNotToBeSerializedClass>>objectToSerializeIn: anFLAnalyser > Â Â Â ^(anFLAnalyser shouldPrune: self) > Â Â Â Â Â ifFalse: [self] > Â Â Â Â Â ifTrue: [nil] > which would of course be the default in Object: > Object>>objectToSerializeIn: anFLAnalyser > Â Â Â ^(anFLAnalyser shouldPrune: self)Â ifFalse:: [self] > >> >> >>> >>> I think both Yaron and I feel the Fuel framework is comprehensible and >>> flexible. Â We enjoyed using it and while we took two passes at coming up >>> with the pruning scheme we liked (our first was based on not serializing >>> specific ins vars and was much more complex than our second, based on >>> pruning instances of specific classes) we got there quickly and will very >>> little frustration along the way. Â Thank you very much. >> >> :-) thank you! >> >>> >>> Finally, a couple of things. Â First, it may be more flexible to implement >>> fuelCluster as fuelClusterIn: anFLAnalyser so that if one is trying to >>> override certain parts of the mapping framework an implementation can access >>> the analyser to find existing clusters, e.g. >>> MyClass>>fuelClusterIn: anFLAnalyser >>> ^self shouldBeInASpecialCluster >>> ifTrue: [anFLAnalyser clusterWithId: MySpecialCluster id] >>> ifFalse: [superÂ fuelClusterIn: anFLAnalyser] >>> This makes it easier to find a specific unique cluster to handle a group >>> of objects specially. >> >> I can't imagine a concrete example but I see that it is more flexible... >> the cluster obtained via double dispatch can be anything polymorphic with >> MySpecialCluster... that's the point? > > To be honest I'm not sure. Â But passing in the analyser in things like > fuelCluster or objectToSerialize is I think a good idea as it provides a > convenient communication path which in turn provides considerable > flexibility. >> >> >>> >>> Lastly, the class-side cluster ids are a bit of a pain. Â It would be nice >>> to know a) are these byte values or general integer values, i.e. can there >>> be more than 256 types of cluster?, and b) is there any meaning to the ids? >>> Â For example, are clusters ordered by id, or is this just an integer tag? >>> Â Also, some class-side code to assign an unused id would be nice. >>> You might think of virtualizing the id scheme. Â For example, if FLCluster >>> maintained a weak array of all its subclasses then the id of a cluster could >>> be the index in the array, and the array could be cleaned up occasionally. >>> Â Then each fuel serialization could start with the list of cluster class >>> names and ids, so that specific values of ids are specific to a particular >>> serialization. >> >> I do agree, these ids are an heritage from the first prototypes of fuel, >> they should be revised. a) yes, it is encoded in only one byte; b) just an >> integer tag, the only purpose of the id was for decoding fast: read a byte >> and then look in a dictionary for the corresponding cluster instance. We >> could even store the cluster class name but that's inefficient. > > Yes, but how inefficient? Â What's the size of all the cluster names? > Â Â Â FLCluster allSubclasses inject: 0 into: [:t :c| t + c name size + 1] 670 > > So you'd add less than a kilobyte to the size of each serialization and get > complete freedom from ids. Â Something to think about. >> >> Virtualizing the id scheme is a good idea. Much more elegant and >> extensible. The current mechanism not only limits the number of possible >> clusters, but also "user defined" extensions can collide, for example if >> your Glue cluster id is the same of the Moose cluster id. >> >> I added an issue in our tracker. >> >> If it makes sense, maybe the weak array you suggest can be also used to >> avoid instantiating lots of FLObjectCluster like we are doing in Object: >> >> fuelCluster >> Â Â Â ^ self class isVariable >> Â Â Â Â Â Â ifTrue: [ FLVariableObjectCluster for: self class ] >> Â Â Â Â Â Â ifFalse: [ FLFixedObjectCluster for: self class ] >> >> the second time you send fuelCluster to an object, it can reuse the >> cluster instance. > > Right. Â I think that's important, and is one reason why I think passing in > the analyser is important, because it allows certain objects to discover > existing clusters in the analyzer and join them if they want to, instead of > having to invent and maintain their own cluster uniquing solution > . >>> >>> again thanks for a great framework. >> >> Thanks for your words and the feedback. Is Glue published somewhere? > > No, and its extremely proprietary :) Â Newspeak however is available and we > may end up maintaining a port of Fuel for Newspeak. > best regards, > Eliot > >> >> regards >> Martin >> >> >>> >>> best, >>> Eliot >> >> >>> >>> On Mon, Jun 13, 2011 at 10:16 AM, Mariano Martinez Peck >>> <marianopeck(a)gmail.com> wrote: >>>> >>>> >>>> On Thu, Jun 9, 2011 at 3:35 AM, Eliot Miranda <eliot.miranda(a)gmail.com> >>>> wrote: >>>>> >>>>> Hi Martin and Mariano, >>>>> Â Â Â a couple of questions. Â What's the right way to exclude certain >>>>> objects from the serialization? Â Is there a way of excluding certain inst >>>>> vars from certain objects? >>>> >>>> >>>> Eliot and the rest....Martin implemented this feature in >>>> Fuel-MartinDias.258. For the moment, we decided to put >>>> #fuelIgnoredInstanceVariableNames at class side. >>>> >>>> Behavior >> fuelIgnoredInstanceVariableNames >>>> Â Â Â "Indicates which variables have to be ignored during serialization." >>>> >>>> Â Â Â ^#() >>>> >>>> >>>> MyClass class >> fuelIgnoredInstanceVariableNames >>>> Â ^ #('instVar1') >>>> >>>> >>>> The impact in speed is nothing, so this is good. Now....we were thinking >>>> if it is common to need that 2 different instances of the same class need >>>> different instVars to ignore. Is this common ? do you usually need this ? >>>> We checked in SIXX and it is at instance side. Java uses the prefix >>>> 'transient' so it is at class side... >>>> >>>> thanks >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >> > >

June 17, 2011