How to store live objects in Monticello?

> Hi,
>
> I am trying to do something like this: I have a class LoadProjectTest that is
> essentially a singleton and the LoadProjectTest  class is in category
> eToys-Tests. I'd like to do something like this: In the image where this
> class originates, I am creating the instance, and setting one instance
> variable with some value from a local file. I'd like the instance to be
> stored in Monticello, when I "save" the category. Then, when the MCZ is
> loaded into another image, the instance would be there, filled with the value
> as created in the originating image.
>
> However, when I load the MCZ into another image, the instance is null;
> although I was assuming otherwise, that makes sense as the Monticello
> repository stores code not live objects.
>
> Is it possible to, somehow, to make Monticello to keep the instance, so it is
> deserialized from the MCZ when the MCZ is loaded into the target image?

> Hi,
>
> I am trying to do something like this: I have a class  
> LoadProjectTest that is
> essentially a singleton and the LoadProjectTest  class is in category
> eToys-Tests. I'd like to do something like this: In the image where  
> this
> class originates, I am creating the instance, and setting one instance
> variable with some value from a local file. I'd like the instance  
> to be
> stored in Monticello, when I "save" the category. Then, when the  
> MCZ is
> loaded into another image, the instance would be there, filled with  
> the value
> as created in the originating image.
>
> However, when I load the MCZ into another image, the instance is null;
> although I was assuming otherwise, that makes sense as the Monticello
> repository stores code not live objects.
>
> Is it possible to, somehow, to make Monticello to keep the  
> instance, so it is
> deserialized from the MCZ when the MCZ is loaded into the target  
> image?

> On Sun, Feb 11, 2007 at 10:07:48PM -0500, Milan Zimmermann wrote:
> > Hi,
> >
> > I am trying to do something like this: I have a class LoadProjectTest
> > that is essentially a singleton and the LoadProjectTest  class is in
> > category eToys-Tests. I'd like to do something like this: In the image
> > where this class originates, I am creating the instance, and setting one
> > instance variable with some value from a local file. I'd like the
> > instance to be stored in Monticello, when I "save" the category. Then,
> > when the MCZ is loaded into another image, the instance would be there,
> > filled with the value as created in the originating image.
> >
> > However, when I load the MCZ into another image, the instance is null;
> > although I was assuming otherwise, that makes sense as the Monticello
> > repository stores code not live objects.
> >
> > Is it possible to, somehow, to make Monticello to keep the instance, so
> > it is deserialized from the MCZ when the MCZ is loaded into the target
> > image?
>
> You would write some class initialization code that creates this
> instance, and stores it where you see fit. Put your code in the
> class-side initialize method.
>
> A good example of a code that does just that is the class
> ExternalType in category FFI-Kernel. Look at the methods in
> category "class initialization"
>
> > Thanks Milan
>
> Hope it helps.

> Mathew,
>
> do you mean class-side initilization that would run when the MCZ is  
> loaded in
> the image on the "target" system? If so, that is not what I am  
> looking for -
> I am explicitly trying to initialize that member only on the first  
> system
> that creates the MCZ. In more detail, when creating resource for  
> the test, I
> stream eToys .pr file into a String, and the tests then stream  
> Projects from
> this string as if they were loading the .pr file. The reason I need  
> that, is
> I cannot (and do not want to) ship these .pr files around with the  
> tests.
>
> Milan
>
> On 2007 February 12 00:27, Matthew Fulmer wrote:
>> On Sun, Feb 11, 2007 at 10:07:48PM -0500, Milan Zimmermann wrote:
>>> Hi,
>>>
>>> I am trying to do something like this: I have a class  
>>> LoadProjectTest
>>> that is essentially a singleton and the LoadProjectTest  class is in
>>> category eToys-Tests. I'd like to do something like this: In the  
>>> image
>>> where this class originates, I am creating the instance, and  
>>> setting one
>>> instance variable with some value from a local file. I'd like the
>>> instance to be stored in Monticello, when I "save" the category.  
>>> Then,
>>> when the MCZ is loaded into another image, the instance would be  
>>> there,
>>> filled with the value as created in the originating image.
>>>
>>> However, when I load the MCZ into another image, the instance is  
>>> null;
>>> although I was assuming otherwise, that makes sense as the  
>>> Monticello
>>> repository stores code not live objects.
>>>
>>> Is it possible to, somehow, to make Monticello to keep the  
>>> instance, so
>>> it is deserialized from the MCZ when the MCZ is loaded into the  
>>> target
>>> image?
>>
>> You would write some class initialization code that creates this
>> instance, and stores it where you see fit. Put your code in the
>> class-side initialize method.
>>
>> A good example of a code that does just that is the class
>> ExternalType in category FFI-Kernel. Look at the methods in
>> category "class initialization"
>>
>>> Thanks Milan
>>
>> Hope it helps.
>

>From: Matthew Fulmer <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Re: How to store live objects in Monticello?
>Date: Sun, 11 Feb 2007 22:27:08 -0700
>
>On Sun, Feb 11, 2007 at 10:07:48PM -0500, Milan Zimmermann wrote:
> > Hi,
> >
> > I am trying to do something like this: I have a class LoadProjectTest
>that is
> > essentially a singleton and the LoadProjectTest  class is in category
> > eToys-Tests. I'd like to do something like this: In the image where this
> > class originates, I am creating the instance, and setting one instance
> > variable with some value from a local file. I'd like the instance to be
> > stored in Monticello, when I "save" the category. Then, when the MCZ is
> > loaded into another image, the instance would be there, filled with the
>value
> > as created in the originating image.
> >
> > However, when I load the MCZ into another image, the instance is null;
> > although I was assuming otherwise, that makes sense as the Monticello
> > repository stores code not live objects.
> >
> > Is it possible to, somehow, to make Monticello to keep the instance, so
>it is
> > deserialized from the MCZ when the MCZ is loaded into the target image?
>
>You would write some class initialization code that creates this
>instance, and stores it where you see fit. Put your code in the
>class-side initialize method.
>
>A good example of a code that does just that is the class
>ExternalType in category FFI-Kernel. Look at the methods in
>category "class initialization"
>
> > Thanks Milan
>
>Hope it helps.
>
>--
>Matthew Fulmer -- http://mtfulmer.wordpress.com/
>Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
>

> > Is it possible to, somehow, to make Monticello to keep the
> > instance, so it is
> > deserialized from the MCZ when the MCZ is loaded into the target
> > image?
>
> I'm not sure that is a good idea, but in principle, yes, this is
> possible.
>
> MC is extensible, it asks each class in the package it is going to
> store for its "classDefinitions". You can return an Array with
> multiple definitions, not only the MCClassDefinition that is usually
> returned. You could try to add a special MCDefinition that would
> represent a serialized instance. Might be quite hard, though.
>

>
> - Bert -
>
> On Feb 12, 2007, at 13:50 , Milan Zimmermann wrote:
> > Mathew,
> >
> > do you mean class-side initilization that would run when the MCZ is
> > loaded in
> > the image on the "target" system? If so, that is not what I am
> > looking for -
> > I am explicitly trying to initialize that member only on the first
> > system
> > that creates the MCZ. In more detail, when creating resource for
> > the test, I
> > stream eToys .pr file into a String, and the tests then stream
> > Projects from
> > this string as if they were loading the .pr file. The reason I need
> > that, is
> > I cannot (and do not want to) ship these .pr files around with the
> > tests.
> >
> > Milan
> >
> > On 2007 February 12 00:27, Matthew Fulmer wrote:
> >> On Sun, Feb 11, 2007 at 10:07:48PM -0500, Milan Zimmermann wrote:
> >>> Hi,
> >>>
> >>> I am trying to do something like this: I have a class
> >>> LoadProjectTest
> >>> that is essentially a singleton and the LoadProjectTest  class is in
> >>> category eToys-Tests. I'd like to do something like this: In the
> >>> image
> >>> where this class originates, I am creating the instance, and
> >>> setting one
> >>> instance variable with some value from a local file. I'd like the
> >>> instance to be stored in Monticello, when I "save" the category.
> >>> Then,
> >>> when the MCZ is loaded into another image, the instance would be
> >>> there,
> >>> filled with the value as created in the originating image.
> >>>
> >>> However, when I load the MCZ into another image, the instance is
> >>> null;
> >>> although I was assuming otherwise, that makes sense as the
> >>> Monticello
> >>> repository stores code not live objects.
> >>>
> >>> Is it possible to, somehow, to make Monticello to keep the
> >>> instance, so
> >>> it is deserialized from the MCZ when the MCZ is loaded into the
> >>> target
> >>> image?
> >>
> >> You would write some class initialization code that creates this
> >> instance, and stores it where you see fit. Put your code in the
> >> class-side initialize method.
> >>
> >> A good example of a code that does just that is the class
> >> ExternalType in category FFI-Kernel. Look at the methods in
> >> category "class initialization"
> >>
> >>> Thanks Milan
> >>
> >> Hope it helps.

> On 2007 February 12 08:06, Bert Freudenberg wrote:
>> A workaround would be to put that string into a method, and
>> unserialize the project into the class var in the class-side
>> #initialize.
>
> Yes, this is basically what I am trying to do now. Basically (sort  
> of ) a copy
> and paste from the live string into a method and adding ^'' around  
> (through a
> ByteArray and a few hoops, as I cannot just copy and paste).
>
> Speaking of copy/paste: When I do Alt-p on something like:
>
> (ProjectsToTestContainer getContainedProjectHolders at: 1) getProject
>
> It shows something like:
>
> a ByteArray(80 75 3 4 20....etc...)
>
> when the result is very long, it shows "...etc" at the end. Same if  
> I print to
> Transcript. Is there some way to force showing all the contents?
>
>>
>> A totally hackish thing would be to include the project file in the
>> MCZ, which is just a ZIP archive after all, and when #initialize is
>> called on your class, walk up the call chain to find the Monticello
>> instance that initiated the load - peek into its innards to get at
>> the file ;-)
>
> Maybe not as hackish ;) I think this would allow a less "manual"  
> process when
> adding another project to test.
>
> Thanks Milan
>>
>> - Bert -
>>
>> On Feb 12, 2007, at 13:50 , Milan Zimmermann wrote:
>>> Mathew,
>>>
>>> do you mean class-side initilization that would run when the MCZ is
>>> loaded in
>>> the image on the "target" system? If so, that is not what I am
>>> looking for -
>>> I am explicitly trying to initialize that member only on the first
>>> system
>>> that creates the MCZ. In more detail, when creating resource for
>>> the test, I
>>> stream eToys .pr file into a String, and the tests then stream
>>> Projects from
>>> this string as if they were loading the .pr file. The reason I need
>>> that, is
>>> I cannot (and do not want to) ship these .pr files around with the
>>> tests.
>>>
>>> Milan
>>>
>>> On 2007 February 12 00:27, Matthew Fulmer wrote:
>>>> On Sun, Feb 11, 2007 at 10:07:48PM -0500, Milan Zimmermann wrote:
>>>>> Hi,
>>>>>
>>>>> I am trying to do something like this: I have a class
>>>>> LoadProjectTest
>>>>> that is essentially a singleton and the LoadProjectTest  class  
>>>>> is in
>>>>> category eToys-Tests. I'd like to do something like this: In the
>>>>> image
>>>>> where this class originates, I am creating the instance, and
>>>>> setting one
>>>>> instance variable with some value from a local file. I'd like the
>>>>> instance to be stored in Monticello, when I "save" the category.
>>>>> Then,
>>>>> when the MCZ is loaded into another image, the instance would be
>>>>> there,
>>>>> filled with the value as created in the originating image.
>>>>>
>>>>> However, when I load the MCZ into another image, the instance is
>>>>> null;
>>>>> although I was assuming otherwise, that makes sense as the
>>>>> Monticello
>>>>> repository stores code not live objects.
>>>>>
>>>>> Is it possible to, somehow, to make Monticello to keep the
>>>>> instance, so
>>>>> it is deserialized from the MCZ when the MCZ is loaded into the
>>>>> target
>>>>> image?
>>>>
>>>> You would write some class initialization code that creates this
>>>> instance, and stores it where you see fit. Put your code in the
>>>> class-side initialize method.
>>>>
>>>> A good example of a code that does just that is the class
>>>> ExternalType in category FFI-Kernel. Look at the methods in
>>>> category "class initialization"
>>>>
>>>>> Thanks Milan
>>>>
>>>> Hope it helps.
>

> On 2007 February 12 08:06, Bert Freudenberg wrote:
>> A workaround would be to put that string into a method, and
>> unserialize the project into the class var in the class-side
>> #initialize.
>
> Yes, this is basically what I am trying to do now. Basically (sort  
> of ) a copy
> and paste from the live string into a method and adding ^'' around  
> (through a
> ByteArray and a few hoops, as I cannot just copy and paste).
>
> Speaking of copy/paste: When I do Alt-p on something like:
>
> (ProjectsToTestContainer getContainedProjectHolders at: 1) getProject
>
> It shows something like:
>
> a ByteArray(80 75 3 4 20....etc...)
>
> when the result is very long, it shows "...etc" at the end. Same if  
> I print to
> Transcript. Is there some way to force showing all the contents?

>
> >> A totally hackish thing would be to include the project file in the
> >> MCZ, which is just a ZIP archive after all, and when #initialize is
> >> called on your class, walk up the call chain to find the Monticello
> >> instance that initiated the load - peek into its innards to get at
> >> the file ;-)
> >
> > Maybe not as hackish ;) I think this would allow a less "manual"
> > process when
> > adding another project to test.
>
> Well, it is a one-time hack because you cannot reproduce a similar
> MCZ by writing it out again.
>
> - Bert -

> On 2007 February 13 06:10, Bert Freudenberg wrote:
>>
>> Use #storeString instead of #printString.
>
> Hi Bert,
>
> Thanks for your comments along the way. I ended up storing each project
> as "manually serialized" ByteArrays returned from a method.
>
> Along the way I found a problem related to compiler which prevented me  
> from
> using the "storeString" for large volume.
>
>    -# I used MultiByteFileStream to stream project into a ByteArray, for
> example byteArr:=#(80 75 3 4 20 0 0 0 0 0 76 134 203 ....). Then I tried
> something like:
>
>     byteArr := #(80 75 3 4 20 0 0 0 0 0 76 134 203) asByteArray.
>     byteArrStoreString := byteArr storeString.
>     method := 'method1 ^',  '''', byteArrStoreString, ''''.
>     TestCompile compile: method classified: 'my-compile-test'
>
> This worked for the short ByteArray above, but for a long one, I get an  
> Error
> from CompileMethod:
>
>   "Error: Cannot compile - too many literal variables"
>
> There are limits in the CompileMethod code such as:
> nTemps > 63 ifTrue:
> [^ self error: 'Cannot compile -- too many temporary variables'].
> nLits > 255 ifTrue:
> [^ self error: 'Cannot compile -- too many literals variables'].
> A naive question, does this have to do with the way classes are  
> represented in
> the VM?

> Hi Milan,
>
>>     byteArr := #(80 75 3 4 20 0 0 0 0 0 76 134 203) asByteArray.
>>     byteArrStoreString := byteArr storeString.
>>     method := 'method1 ^',  '''', byteArrStoreString, ''''.
>>     TestCompile compile: method classified: 'my-compile-test'
>>
>> This worked for the short ByteArray above, but for a long one, I  
>> get an Error
>> from CompileMethod:
>>
>>   "Error: Cannot compile - too many literal variables"

> On Feb 24, 2007, at 10:07 , Klaus D. Witzel wrote:
>
>> Hi Milan,
>>
>>>     byteArr := #(80 75 3 4 20 0 0 0 0 0 76 134 203) asByteArray.
>>>     byteArrStoreString := byteArr storeString.
>>>     method := 'method1 ^',  '''', byteArrStoreString, ''''.
>>>     TestCompile compile: method classified: 'my-compile-test'
>>>
>>> This worked for the short ByteArray above, but for a long one, I get  
>>> an Error
>>> from CompileMethod:
>>>
>>>   "Error: Cannot compile - too many literal variables"
>
>>>   -# So I ended up "manually serializing" the ByteArray, esentially as  
>>> a
>>> literal String such as '80 75 3 4 20 0 0 0 0 0 76 134 203' in the small
>>> example above. Then deserialized after the method answered.
>
>
> I was suggesting using #storeString on the Form, not the ByteArray. This  
> is more efficient because it uses words instead of bytes, and it uses  
> only one literal. This way, the parsing work is done only once when  
> compiling. Reading decimal from a String at runtime is particularly  
> inefficient. Don't do that ;)

> >
> > There are limits in the CompileMethod code such as:
> > nTemps > 63 ifTrue:
> > [^ self error: 'Cannot compile -- too many temporary variables'].
> > nLits > 255 ifTrue:
> > [^ self error: 'Cannot compile -- too many literals variables'].
> > A naive question, does this have to do with the way classes are
> > represented in
> > the VM?
>
> Since I am [in part] responsible for having the above checks in a
> consistent way, here's my part of the answer:
>
> No. These limits exist because the header field in CompiledMethod has room
> for just these respective number of bits.
>
> Has nothing to do with, how classes are represented in the VM, but with,
> how CompiledMethods are represented in the VM.