I have looked at the Base64Codec, but have not figured out how to implement
it for my personal usage. Here's the problem: I have a Package containing over 100 methods similar to the example shown below. The majority of these methods are very much larger than that given in this example. The size of my package is approaching 250Kb. E_001_Hydrogen>>nistIsotopeData "Answer the NIST Isotope data for: Hydrogen. PROGRAMMATICALLY GENERATED CODE... See AtomDataReader - Class comment." ^#(#(#($p '1') #($s 'H') #($n '1') #($m '1.0078250321(4)') #($a '99.9885(70)') #($w '1.00794(7)') #($i 'g,m,r,c,w')) #(#($n '2') #($m '2.0141017780(4)') #($a '0.0115(70)')) #(#($n '3') #($m '3.0160492675(11)')) #(#($n '4') #($m '4.02783(12)')) #(#($n '5') #($m '5.03954(102)')) #(#($n '6') #($m '6.04494(28)'))) I would very much like to shrink, and later expand, the returned Array in this example with the Base64Codec. If anyone has implemented the Base64Codec for their personal use, even in a rudimentary form, please post an example reply. Thanks to all Smalltalkers, Randy Manning |
Hi Randy
If I am not mistaken patch 4 comes with a Base64Codec, that in addition that is recommendable to have the image to the day. Best regards MDC "Randy Manning" <[hidden email]> escribió en el mensaje news:lpZ1d.21460$[hidden email]... > I have looked at the Base64Codec, but have not figured out how to implement > it for my personal usage. > > Here's the problem: > I have a Package containing over 100 methods similar to the example shown > below. The majority of these methods are very much larger than that given in > this example. The size of my package is approaching 250Kb. > > E_001_Hydrogen>>nistIsotopeData > "Answer the NIST Isotope data for: Hydrogen. PROGRAMMATICALLY GENERATED > CODE... See AtomDataReader - Class comment." > > ^#(#(#($p '1') #($s 'H') #($n '1') #($m '1.0078250321(4)') #($a > '99.9885(70)') #($w '1.00794(7)') #($i 'g,m,r,c,w')) #(#($n '2') #($m > '2.0141017780(4)') #($a '0.0115(70)')) #(#($n '3') #($m '3.0160492675(11)')) > #(#($n '4') #($m '4.02783(12)')) #(#($n '5') #($m '5.03954(102)')) #(#($n > '6') #($m '6.04494(28)'))) > > I would very much like to shrink, and later expand, the returned Array in > this example with the Base64Codec. > > If anyone has implemented the Base64Codec for their personal use, even in a > rudimentary form, please post an example reply. > > Thanks to all Smalltalkers, > Randy Manning > > > > |
In reply to this post by Randy Manning
"Randy Manning" <[hidden email]> wrote in message
news:lpZ1d.21460$[hidden email]... >I have looked at the Base64Codec, but have not figured out how to implement > it for my personal usage. > > Here's the problem: > I have a Package containing over 100 methods similar to the example shown > below. The majority of these methods are very much larger than that given > in > this example. The size of my package is approaching 250Kb. > ... Erm, Base64 is a text encoding for binary data, not a compression mechanism. A base64 encoded byte stream will be somewhat larger than the original binary. 250Kb doesn't seem like a terribly large package? Regards Blair |
In reply to this post by Randy Manning
Randy Manning wrote:
> I would very much like to shrink, and later expand, the returned Array in > this example with the Base64Codec. > > If anyone has implemented the Base64Codec for their personal use, even in > a rudimentary form, please post an example reply. First off, you should read the class comment for Base64Codec ! However, assuming you are happy to risk future problems, you can encode an object as a base64 string with code like: o := Object new. enc := String writeStream. Base64Codec encodeFrom: o binaryStoreBytes readStream onto: enc. enc := enc contents. which will set 'enc' to the base64 String. To decode it (which should be future-proof since OA will presumably have to maintain backward compatibility for "old" packages which use this form): dec := ByteArray fromBase64String: enc. p := Object fromBinaryStoreBytes: dec. If you don't want to tie yourself to the OA class, then you could use Steve Wart's Base64Encoder/Decoder which is available somewhere on DolphinHarbor. As Blair has pointed out, the String form is not compressed; the example you gave produces a 754-character String in this way, verses only 310 for the array expression itself. You /could/ use compression (you'll find fairly comprehensive zlib-based compression on my website, www.metagnostic.org), but that only gives you back the space you've lost by binary-coding in the first place. In your example, compressing the binary store bytes before Base64 encoding them reduces the size of the encoded String to 290 characters. However, if I needed to bind this sort of data into a package then I might not use a source representation at all. I'd be tempted to generate a LookupTable (or similar) with all the data in, assign that to a global, and then include that global as part of my package -- thus letting the system do the work of encoding/decoding it for me. Your automatically-generated methods (assuming you still wanted them) would then reference that global. You might even be able to use the ##(...) notation, to do the lookup at compile time, but I'm unsure whether packaged methods are compiled before or after packaged globals are installed. One problem with that approach would be that the STB+Base64-encoded global would be pretty big, and would probably slow down package loading (you could use compression and set the thing up from a pre- or post- install script instead of letting the package system do it for you, but that would be noticeably more complicated). Another would be that changing the global's internals would not automatically result in the package being marked as 'changed', so you'd have to remember it yourself. HTH -- chris |
Free forum by Nabble | Edit this page |