[ruby-talk:01579] Re: Ruby supported/distributed libraries--can all be used together?

((comp.lang.misc & ruby-talk ML))

<[e-mail]>
> Hi,
>
> At Thu, 24 Feb 2000 10:36:54 GMT,
> Dave Thomas <[e-mail]> wrote:
>
> > Now I guess to fit this scheme, you could pre-compile them all, and
> > then save out the Ruby image that contained the symbol table and parse
> > tree, making them instantly accessible to subsequent programs.
> (snip)
> > However, I *do* see merit in the scheme. If you want to bundle a Ruby
> > application that uses a lot of library functionality, it would be
> > easier to be able to ship one file, not twenty. Maybe having some kind
> > of dump mechanism, a la TeX, would be useful in those circumstances.

Good point. One of the other things I had in mind was something like the
perl2exe program.

But there is another facet of this Ruby library question that I want to
return to, which is whether any additional conventions are needed to insure
that all modules/libraries could be invoked together for future
mega-applications.

> To bundle library files into one pre-compiled binary, you can use
> "rb2c"(in RAA), a Ruby-to-C translator. rb2c'ed binaries have
> following advantages:
>
>  * You can get one pre-compiled exectable binary.
>  * Speed up in starting up, because there's no parsing step.
>  * Slight speed up in execution.
>
> and also have disadvantages:
>
>  * Larger size. (Dumped pre-parsed nodes will be smaller.) ex. 1M
>    bytes for rdtool on stripped linux ELF format.
>  * Less reliability than the interpreter.
>  * Needs C compiler.
>  * OS dependent.
>
> IMO, rb2c is too big hammer to bundle libraries, but is available.
> I'm wondering whether node-dumping meets the effort or not.  IMHO,
> node-dumping mechanism is too early to implement.  I'm looking forward
> to coming rewriting of the interpreter ;-)

And I'm looking forward to renaming it the "realtime compiler", which is a
better description in my interpretation. :-)

Conrad