New release of FuelMooseExtension

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.

The Moose image is built by loading ConfigurationOfFuelMooseExtension #stable. Please go ahead and upgrade this.

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.

Cheers,
Doru

On 29 May 2012, at 21:42, Mariano Martinez Peck wrote:

> Hi Doru. I have updated FuelMooseExtension to work with the latest stable version of Fuel 1.8. I think this is worth it because:
>
> 1) Right now you are using an old version of Fuel (1.6) which is like an year ago. The older it is the more difficult it will be in the future to update.
> 2) If you don't take into account the time to compute attributes we can have improvement up to 30% in export time.
> 3) Fuel 1.8 is integrated by default in Pharo 2.0 now, meaning that you will have problems when moving Moose to Pharo 2.0 (because you would need 1.6).
>
> Of course the bad news is that if you have already exported files you won't be able to import them with this new version.
>
> If you agree, let me know. I will create a new version 1.5 in ConfigurationOfFuelMooseExtension but I don't know how the Moose image is built (it seems it is not using ConfigurationOfFuel).
>
> Cheers
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Speaking louder won't make the point worthier."


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On Tue, May 29, 2012 at 1:39 PM, Mariano Martinez Peck
<[hidden email]> wrote:
snip

> 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?

Just curious, is the error thrown enough to tell us that the problem
is a wrong version, and which version we should be using to read the
file?

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> 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?

It is. But, I was just saying that by adding the version in the naming scheme we would essentially provide documentation. This can be particularly useful given that it is likely that each version of Fuel will change the format.

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.

Do we get any support from Fuel in this regard?

Cheers,
Doru

>
> Cheers,
> Doru
>
>
> On 29 May 2012, at 21:42, Mariano Martinez Peck wrote:
>
> > Hi Doru. I have updated FuelMooseExtension to work with the latest stable version of Fuel 1.8. I think this is worth it because:
> >
> > 1) Right now you are using an old version of Fuel (1.6) which is like an year ago. The older it is the more difficult it will be in the future to update.
> > 2) If you don't take into account the time to compute attributes we can have improvement up to 30% in export time.
> > 3) Fuel 1.8 is integrated by default in Pharo 2.0 now, meaning that you will have problems when moving Moose to Pharo 2.0 (because you would need 1.6).
> >
> > Of course the bad news is that if you have already exported files you won't be able to import them with this new version.
> >
> > If you agree, let me know. I will create a new version 1.5 in ConfigurationOfFuelMooseExtension but I don't know how the Moose image is built (it seems it is not using ConfigurationOfFuel).
> >
> > Cheers
> >
> > --
> > Mariano
> > http://marianopeck.wordpress.com
> >
> > _______________________________________________
> > Moose-dev mailing list
> > [hidden email]
> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Speaking louder won't make the point worthier."
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"The coherence of a trip is given by the clearness of the goal."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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?

Is there a way to list all required classes before performing an actual load ? 

cheers -ben

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On Wed, May 30, 2012 at 3:23 PM, Ben Coman <[hidden email]> 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.

 

cheers -ben

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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

Mariano Martinez Peck wrote:

On Wed, May 30, 2012 at 4:40 PM, Mariano Martinez Peck <
[hidden email]> wrote:

  

On Wed, May 30, 2012 at 3:23 PM, Ben Coman [hidden email] 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
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev