CompileMethod limits [Was: Re: How to store live objects in
Monticello?]
Milan Zimmermann
milan.zimmermann at sympatico.ca
Sat Feb 24 08:53:50 UTC 2007
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?
-# 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.
>
> OTOH, a common way is base64 encoding your binary data into a string.
I looked at the Base64MimeConverter but I already had the project as
ByteArray so I did a simple manual serialize/desirialize as space separated
decimals 0-255 which works. I should replace it with using the
Base64MimeConverter.
Thanks Milan
>
> >> 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 -
More information about the Squeak-dev
mailing list
|