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
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:
- 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.
- If you don't take into account the time to compute attributes we can have improvement up to 30% in export time.
- 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Speaking louder won't make the point worthier."
On Tue, May 29, 2012 at 10:18 PM, Tudor Girba tudor@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:
Hi Doru. I have updated FuelMooseExtension to work with the latest
stable version of Fuel 1.8. I think this is worth it because:
- 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.
- If you don't take into account the time to compute attributes we can
have improvement up to 30% in export time.
- 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Speaking louder won't make the point worthier."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Tue, May 29, 2012 at 1:39 PM, Mariano Martinez Peck marianopeck@gmail.com 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?
On Tue, May 29, 2012 at 10:49 PM, Chris Cunningham cunningham.cb@gmail.comwrote:
On Tue, May 29, 2012 at 1:39 PM, Mariano Martinez Peck marianopeck@gmail.com 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?
verifyVersionFrom: aDecoder
| streamVersion | streamVersion := aDecoder nextEncodedUint16. (self version = streamVersion) ifFalse: [ FLBadVersion signalCurrentVersion: self version streamVersion: streamVersion ]
Imagine you have exported with 1.5 and you are now importing with 1.4 the message of the exception is:
'Unexpected stream version 15 where it should be 14.'
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
On 29 May 2012, at 22:39, Mariano Martinez Peck wrote:
On Tue, May 29, 2012 at 10:18 PM, Tudor Girba tudor@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?
Yes.
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:
- 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.
- If you don't take into account the time to compute attributes we can have improvement up to 30% in export time.
- 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Speaking louder won't make the point worthier."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@iam.unibe.ch 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."
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.
Ok, we can add that. But as far as I can see, the USER of Moose chooses the filename/extension when exporting a mode. Am right? look:
exportToFLOpeningFileDialog <menuItem: 'Export model to FL' category: 'Import / Export'> | stream | stream := UITheme builder fileSave: 'Your title here' extensions: #('fl') path: nil. stream isNil ifFalse: [ self exportToFLStream: stream. stream close. Notification signal: 'Save successful!' ]
so...how can I force a file extension if the user actually put it? On the other hand, the method fileSave: 'Your title here' extensions: #('fl') path: nil.
shows files with extension 'fl'. So when you are importing with Fuel XXX, which fuel files should you search? only the ones of your version? all fuel files?
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".
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:
- 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.
- If you don't take into account the time to compute attributes we
can have improvement up to 30% in export time.
- 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Speaking louder won't make the point worthier."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Wed, May 30, 2012 at 3:23 PM, Ben Coman btc@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.
cheers -ben
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Wed, May 30, 2012 at 4:40 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, May 30, 2012 at 3:23 PM, Ben Coman btc@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?
cheers -ben
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
So...let's be agile ;) I have just commited a new stable version 1.5 which I guess will be installed in the next Moose built. I would really appreciate if you can test it (export and import models using the Fuel extension).
From ConfigurationOfFuelMooseExtension >> #version15: you can read the
release notes:
- Migrate to Fuel version 1.8 - If we do not take into account the time to compute attributes we can have improvement up to 40% in export time. - Remove dependency to FuelContainer!!! - Remove FLFameClusterization.
Cheers
On Wed, May 30, 2012 at 6:05 PM, Ben Coman btc@openinworld.com wrote:
** Mariano Martinez Peck wrote:
On Wed, May 30, 2012 at 4:40 PM, Mariano Martinez Peck marianopeck@gmail.com wrote:
On Wed, May 30, 2012 at 3:23 PM, Ben Coman btc@openinworld.com btc@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Ben Coman -
Chris Cunningham -
Mariano Martinez Peck -
Tudor Girba