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 |
Use method tags. See e.g. Travis Griggs' assets framework. You could use something like
courierNewBoldttf <fontName: 'Courier New Bold.ttf' encoding: 'gzip'
data: 'AAEAAAATAQAABAAwRFNJR0rTjTkACiUQAAAbgEdERUYTqQ1VAApAkAAAAkxHUE9T3wr9iAAK QtwAADeeR1NVQgwWqYIACnp8AAAT1k9TLzIQrF1xAAABuAAAAGBWRE1YNVhPeQAAGrwAABGU Y21hcHepKTsAACxQAAAhqmN2dCCka4hDAABqbAAACA5mcGdtUXaa9wAATfwAAAdZZ2FzcAAW AAkACiUAAAAAEGdseWbVwXRoAACjvAAI9Z5oZWFk05ZxuQAAATwAAAA2aGhlYQrAAZoAAAF0 .......... '. and extracting the data is easy. On Tue, Oct 19, 2010 at 4:06 AM, nullPointer <[hidden email]> wrote:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by gerard alis
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-tp3001915p3001915.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] 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 <[hidden email]> 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-tp3001915p3001915.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Stéphane Ducasse
I use the same procedure than embed images, but I don´t understand the great difference of size. :|
|
In reply to this post by Eliot Miranda-2
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.
I will probe save the string compressed and uncompress later. Thanks for the help :) |
In reply to this post by gerard alis
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |