We can add it, but maybe it is redundant. Each Moose model exported with Fuel encodes the version and signature at the beginning of the stream. The signature is "FLMoose" and the version is the current version of FuelMooseExtension (right now it is 1.4 and I am proposing the new version 1.5). So if you try to import with a different version/signature, then an error is thrown. Is that enough?

On Tue, May 29, 2012 at 10:18 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: Hi, Excellent! Let's move on. I do not think there are many data that depend on 1.6. And if there are cases, people can just do the migration. Ok. The Moose image is built by loading ConfigurationOfFuelMooseExtension #stable. Please go ahead and upgrade this. And I guess you load the 'default' group?

On a related note, perhaps it would be a good idea to change the name of the file extensions to be something like .fuel1dot8 to denote the version of the format. We can add it, but maybe it is redundant. Each Moose model exported with Fuel encodes the version and signature at the beginning of the stream. The signature is "FLMoose" and the version is the current version of FuelMooseExtension (right now it is 1.4 and I am proposing the new version 1.5). So if you try to import with a different version/signature, then an error is thrown. Is that enough?

Cheers, Doru On 29 May 2012, at 21:42, Mariano Martinez Peck wrote: -- www.tudorgirba.com "Speaking louder won't make the point worthier." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Mariano http://marianopeck.wordpress.com _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On Wed, May 30, 2012 at 3:23 PM, Ben Coman <btc(a)openinworld.com> wrote: It is atomic. However, think it another way. Imagine that when you do FLMaterialize materializeFrom: aStrema I have to give you back the object graph. If an error happens in the middle, the "part" of the graph being materialized is just some variables in some code of the materializer. Is not "registered" somewhere in the system. So even if there could be some part of the graph, the instance of the materializer will be at some point garbage collected, together with the rest of the stuff. So..to make it clear, it does not exist what you say as "half loaded". I give you back the graph or I don't. Not right now, but we could add it if desired. We already talked about Martin about that. The idea was to kind of "simulate" the materialization (reading the stream) and get an object with information. So that you can ask for example, the needed classes.

-- Mariano http://marianopeck.wordpress.com

From ConfigurationOfFuelMooseExtension >> #version15: you can read the

** Mariano Martinez Peck wrote: On Wed, May 30, 2012 at 4:40 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: On Wed, May 30, 2012 at 3:23 PM, Ben Coman <btc(a)openinworld.com> <btc(a)openinworld.com> wrote: ** Mariano Martinez Peck wrote: Another thing would be to somehow document the requirements for loading the file. For example, in the case of FuelMooseExtension, it is required that Fame and potentially FAMIX are loaded. Yes. Do we get any support from Fuel in this regard? Not really. If you have serialized something in an image XXX and you have serialized instances of that image, and you try to import in an image YYY where you DON'T have those classes, then you will have a clear error saying "FAMIXXXX not found in Smalltalk globals". What happens in this instance? Is the load atomic or does it end up half loaded? It is atomic. However, think it another way. Imagine that when you do FLMaterialize materializeFrom: aStrema I have to give you back the object graph. If an error happens in the middle, the "part" of the graph being materialized is just some variables in some code of the materializer. Is not "registered" somewhere in the system. So even if there could be some part of the graph, the instance of the materializer will be at some point garbage collected, together with the rest of the stuff. So..to make it clear, it does not exist what you say as "half loaded". I give you back the graph or I don't. Is there a way to list all required classes before performing an actual load ? Not right now, but we could add it if desired. We already talked about Martin about that. The idea was to kind of "simulate" the materialization (reading the stream) and get an object with information. So that you can ask for example, the needed classes. Now Martin pointed me out the previous discussion we had about it. Basically, it consist of something like this: info := FLMaterializer newDefault infoFrom: stream. info globalClasses --> {Point. Zaraza. Etc.} info internalClasses ---> {} info objectCount ---> 32000 info clusterCount ---> 5 info fuelVersion -> 15 info allGlobals -> {Transcript. ... ] etc... what do you think? Looks good. Whereas I assume that globalClasses lists every class withing the fuel file, I would perhaps also have a line: info requiredClasses --> { ClassNotInCurrentImage } as a short list of classes that need to be loaded. ------------- Now another passing thought - to what degree is compatibility required to match between in-image Class and serialized class in-file. For example, you export objectA of type classA when classA defines an instance variable "X", but subsequently "X" is removed and then you try to import objectA back in ? _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev