This post was really poorly formatted and contained a couple typos.
This version should be easier to read.  Sorry...

- brent

>
>I understand some people would like Ruby to use less memory. However,
>it would require ruby to behave differently (for regexps, maybe also
>in strings and such) depending on whether this library is loaded or
>not.
>What could probably be done is loading the unicode data only when it
>is required by the interpreter, but that may cause at the first use
>slowdowns difficult to understand for someone who does not fully know
>how ruby works. And loading afterwards will probably be a bit slower.
>
>And a little remark : ruby 1.9 is going in a less lightweight way than
>1.8, especially with threads being OS threads. For lightweight work,
>ruby 1.9 may not be the best choice (I think some people will probably
>continue using 1.8 for some time, or switch to an other
>implementation). But I think having different implementations for
>different uses may be a good thing.
>
>  
>

Actually, upon further reflection, I realized that Linux and most
other modern OS's load code via page faults anyway.  These OSes
will not load these enormous tables (into RAM) if they are *never*
accessed in any way by Ruby.

Is it safe to assume that if one never does a RegExp operation on a
Unicode string that the code and tables in unicode.c will not be accessed?

Or, will a RegExp on an ASCII string also load these tables?


Also, what about other encodings, besides Unicode?
How would these be supported, if not via dynamically loaded libraries?


    To your last remark:

Originally, I intended to port our embedded application from Ruby
1.6.8 to 1.8.6 for the (very valid) reasons that you cite.
We only are moving from 1.6.8 because some obscure gc bug
causes random crashes in our app. [The only non-standard
library we use is termios]

Because we are on 1.6.8, no one wants to look into the problem.  What
convinced me to jump directly to 1.9 was the fact that I do not need
to complete the port until the middle of 2008.  By then, the focus of
new development and support will have shifted to the 1.9 --> 2.0 tree
and the 1.8 tree will be in maintenence mode.

Further, the language spec is changing enough that the choice between
1.8 or 1.9 is not just about implementation.  For instance, 1.9's new
hash (and the better keyword argument syntax that enables) are
attractive.  We have biologists writing simple Ruby scripts for control
of chemical protocols, so our end-users will benefit
from this change.

I'm still unsure as to whether I've made the right choice.  Any well
reasoned feedback would be appreciated.

- brent