Base64Codec - Personal usage.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Base64Codec - Personal usage.

Randy Manning
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


Reply | Threaded
Open this post in threaded view
|

Re: Base64Codec - Personal usage.

MDC-2
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
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Base64Codec - Personal usage.

Blair McGlashan-3
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


Reply | Threaded
Open this post in threaded view
|

Re: Base64Codec - Personal usage.

Chris Uppal-3
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