Re: [Pharo-project] Best way for embed a file on Smalltalk image method
I would really like to know why this is so big. Stef On Oct 19, 2010, at 1:06 PM, nullPointer wrote:
Hi
I´m doing a class for embed files in class methods. I want know if exists a best way for do that task than I´m using... I do something like that...
codeSource := CLStringBuilder new. codeSource appendLine: nameOfResource; tab; appendFormat: '^''{1}'' -> ''' withValues: {fileName}.
readStream := FileStream readOnlyFileNamed: aFilePath.
base64Contents := (Base64MimeConverter mimeEncode: readStream binary) contents.
codeSource append: base64Contents asString. codeSource append:''''.
CLSystem createMessageInClass: self withCodeSource: (codeSource asString) inProtocol: 'resources' inClassSide: true.
I get the next result:
courierNewBoldttf
^'Courier New Bold.ttf' -> 'AAEAAAATAQAABAAwRFNJR0rTjTkACiUQAAAbgEdERUYTqQ1VAApAkAAAAkxHUE9T3wr9iAAK QtwAADeeR1NVQgwWqYIACnp8AAAT1k9TLzIQrF1xAAABuAAAAGBWRE1YNVhPeQAAGrwAABGU Y21hcHepKTsAACxQAAAhqmN2dCCka4hDAABqbAAACA5mcGdtUXaa9wAATfwAAAdZZ2FzcAAW AAkACiUAAAAAEGdseWbVwXRoAACjvAAI9Z5oZWFk05ZxuQAAATwAAAA2aGhlYQrAAZoAAAF0 .......... '.
Exists a enhanced way for do that? My main problem is the image grow very much. When I export to Monticello I get a file of 900 KB. When embed a file of 600KB the final size on Monticello file is 2MB!! and almost 4MB of difference in size of image :(
Many thanks for the help
-- View this message in context: http://forum.world.st/Best-way-for-embed-a-file-on-Smalltalk-image-method-tp... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
data " #[ 1 2 3 4 5 6 .... ] " ^ Compiler evaluate: (((self class sourceCodeAt: #data) asString findTokens: $") at: 2). On 19 October 2010 21:40, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I would really like to know why this is so big.
Stef
On Oct 19, 2010, at 1:06 PM, nullPointer wrote:
Hi
I´m doing a class for embed files in class methods. I want know if exists a best way for do that task than I´m using... I do something like that...
     codeSource := CLStringBuilder new.        codeSource appendLine: nameOfResource; tab;                    appendFormat: '^''{1}'' -> ''' withValues: {fileName}.
       readStream := FileStream readOnlyFileNamed: aFilePath.
       base64Contents := (Base64MimeConverter mimeEncode: readStream binary) contents.
       codeSource append: base64Contents asString.        codeSource append:''''.
       CLSystem createMessageInClass: self            withCodeSource: (codeSource asString)            inProtocol: 'resources'            inClassSide: true.
I get the next result:
courierNewBoldttf
   ^'Courier New Bold.ttf' -> 'AAEAAAATAQAABAAwRFNJR0rTjTkACiUQAAAbgEdERUYTqQ1VAApAkAAAAkxHUE9T3wr9iAAK QtwAADeeR1NVQgwWqYIACnp8AAAT1k9TLzIQrF1xAAABuAAAAGBWRE1YNVhPeQAAGrwAABGU Y21hcHepKTsAACxQAAAhqmN2dCCka4hDAABqbAAACA5mcGdtUXaa9wAATfwAAAdZZ2FzcAAW AAkACiUAAAAAEGdseWbVwXRoAACjvAAI9Z5oZWFk05ZxuQAAATwAAAA2aGhlYQrAAZoAAAF0 .......... '.
Exists a enhanced way for do that? My main problem is the image grow very much. When I export to Monticello I get a file of 900 KB. When embed a file of 600KB the final size on Monticello file is 2MB!! and almost 4MB of difference in size of image  :(
Many thanks for the help
-- View this message in context: http://forum.world.st/Best-way-for-embed-a-file-on-Smalltalk-image-method-tp... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
I use the same procedure than embed images, but I don´t understand the great difference of size. :| -- View this message in context: http://forum.world.st/Best-way-for-embed-a-file-on-Smalltalk-image-method-tp... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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. Cheers, Henry
On 20.10.2010 10:46, Henrik Sperre Johansen wrote:
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.
Wow, still early in the morning here... :) Ofc ,for binary input, a byte in a ByteArray stores the full 8 bits per input byte, while a byte represented in base64 string format stores 6 bits per input byte. Which means 25% overhead compared to raw binary data. Cheers, Henry
participants (4)
-
Henrik Sperre Johansen -
Igor Stasenko -
nullPointer -
Stéphane Ducasse