From: Jeremy Hinegardner <jeremy@...>
Date: 2008-12-03T11:04:18+09:00
Subject: Re: crate 0.1.1 Released

On Wed, Dec 03, 2008 at 06:12:53AM +0900, Joel VanderWerf wrote:
> Jeremy Hinegardner wrote:
>> On Tue, Dec 02, 2008 at 11:04:32AM +0900, Luis Lavena wrote:
> ...
>>> I'll need to check it out how it works with gems that depends on
>>> extensions, since dlopen / LoadLibrary needs a real file and cannot
>>> map a memory address to load the symbols (just thinking out loud here,
>>> maybe you already figured this out).
>> You might call it cheating, what I do is clear out $LOAD_PATH after
>> initializing the interpreter and before handing off control to the
>> wrapped up ruby application.  The require order is then, the ruby
>> original require followed by the amalgalite overridden require.  That way, 
>> if the require is a loaded module (which is now statically
>> compiled in) the ruby internal rb_require() will return success, and if
>> it is a .rb file LoadError will be raised and then amalgalite will take
>> care of loading the appropriate file from the sqlite database.
>
> So, still wondering about Luis's question... how do you load extensions?

Crate applications are standalone applications.  There is no loading of
extensions per se.  When you package your ruby application with crate you
compile in all the necessary extensions statically.  They are all initialized
when the interpreter starts.  

An issue arises when, in your .rb files, you have a "require 'zlib'" or some
other require that would in a standard ruby execution would dynamically load an
extension.  In a crate packaged application, this is really a noop because the
extension is already loaded, since it is comopiled in, but the require statement
needs to not throw a LoadError.

By having the built in require (rb_require()) attempt first, it essentially does
this noop and does not throw the LoadError, and the application goes ahead and 
uses the classes that it wants.  And the issue is gone.

Make sense?

enjoy,

-jeremy

-- 
========================================================================
 Jeremy Hinegardner                              jeremy@hinegardner.org