On Fri, Oct 14, 2011 at 2:40 AM, Hernán Morales Durand < hernan.mora...@gmail.com> wrote:
> Hi Martin > > 2011/10/13 Martin Dias <tinchod...@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? > I don't know it has sense, also it depends on your case... but if MyRemoteString just has a instVar 'filename' or 'fileIndex' to fetch the real string from disk when necessary... it should be easy to serialize instances of such MyRemoteString. > > > 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 :) > thanks... probably for Fuel 1.8! > > > Martin > > > > On Tue, Oct 11, 2011 at 4:10 PM, Mariano Martinez Peck > > <marianop...@gmail.com> wrote: > >> > >> > >> On Tue, Oct 11, 2011 at 12:56 AM, Hernán Morales Durand > >> <hernan.mora...@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 <marianop...@gmail.com>: > >>> > > >>> > > >>> > On Mon, Oct 10, 2011 at 9:35 PM, Hernán Morales Durand > >>> > <hernan.mora...@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 > >> > > > > > >
