[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Minimal Guile
Re: Minimal Guile
Wed, 4 Jan 2012 10:52:56 -0800 (PST)
>> There are some theoretical corner cases where it could be useful.
>> Don't know if these would ever occur in practice.
>> - Systems that don't use a Unix-like filesystem heirarchy
> I also don't see how Unix-like filesystem semantics affect this
If there were a go archive, I could finally make a port to
MS-DOS because I could ignore the 8.3 filesystem limitation. ;-)
> If this single file is to be built only during the package build
> process, and never modified after that, then it should be super-easy to
> invent your own little homebrew format. If we assume that the library,
> executable, and go-bundle files are always distributed together, that
> also means that we're free to change the format at will. I guess it
> could be as simple as this:
> * Concatenate all of the .go files together, making sure to align each
> .go file on a page boundary (4 kilobytes) so that each one can be
> individually mmapped.
> * Generate a C file that includes the entire directory of files within
> an initialized array. It could be as simple as an array of structs
> with three fields: module name, start offset in the big file, and
> length. If you sort this array by module name before generating the
> file, then you could use binary search to find the file.
> * Once the C file is generated, relink libguile with this file included.
> (The first time libguile is built, it could include a stub version of
> the C file with an empty directory, so that it knows to use the
> traditional module-loading mechanism).
> * To allow graceful error messages in case the wrong go-bundle is used
> with the wrong library, there should be some kind of fingerprint put
> in both the go-bundle and the C file index. Check the fingerprint
> before trying to load things from the go-bundle.
That's good advice.