[Pharo-project] Best way for embed a file on Smalltalk image method

Henrik Sperre Johansen henrik.s.johansen at veloxit.no
Wed Oct 20 04:46:44 EDT 2010

  On 20.10.2010 09:50, nullPointer wrote:
> I use the same procedure than embed images, but I don´t understand the great
> difference of size. :|
You're storing a ByteArray which stores 256bits per byte as a base64 
string, which stores 64bits per byte.

If you also cache it somewhere, you're basically using 5 times the size 
of what you import, 4x for the literal base64 string, and 1x for the 
cached byteArray itself.

For a smaller image size, you could just use the ByteArray itself, ie:
^#[10 44 56 43 ]
at the cost of potentially larger .changes and Monticello files.

The reason you're storing it as a base64 string in the first place, is 
that smalltalks will automatically replace lfs with crs when you store a 
method, so if your binary data happens to contain an lf byte, the raw 
string for the binary data will not be the same if you copy/paste it 
anywhere, modify it by hand and accept the changes, or store it to an MC 
package, then load it.
The base64 encoding does not use those trouble characters, and thus the 
things described above will work.

On 20.10.2010 09:50, nullPointer wrote:

>   not is the same compress the value of association to zip, with #zipped method
> and for upset the file out of image uncompress the string? I don´t
> understand the use of pragmas.

Eliots suggestion of storing metadata for binary data in method tags is 
a good one.
Not sure if his example, which seemed to indicate storing a string with 
gzipped binary data, avoids the above mentioned issue though.


More information about the Pharo-dev mailing list