From: Jeremy Hinegardner Date: 2008-12-02T16:55:41+09:00 Subject: Re: crate 0.1.1 Released On Tue, Dec 02, 2008 at 11:04:32AM +0900, Luis Lavena wrote: > On Dec 1, 3:12?pm, Jeremy Hinegardner wrote: [...] > > > > There may be some performance advantage for require in that it only has > > to do a select from a db, vs open up .zip file for ever require, but I > > won't consider that a valid argument at this point. ? > > > > Sorry to bring this, but Python packages the standard library and your > application into zip files. > > It maps the File requests that deal with files to the zip file, which > the handler is open once and keep opened until the application ends. Cool, I didn't know that. And I see that the rubyzip library does override require and that might another option for a future crate. > There is one problem with this which is search for the proper > requirement, which I guess having a sqlite engine backing up will make > it easy. > > 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. This is the same approach used by rubygems. What this means for a crate application is that mixing filesystem .rb files with those stored in sqlite databases may cause odd behavior if something fiddles with $LOAD_PATH. > BTW: great release! Thanks! enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner jeremy@hinegardner.org