Hi Ludovic, On Wed 21 Oct 2009 18:22, l...@gnu.org (Ludovic Courtès) writes:
> Andy Wingo <wi...@pobox.com> writes: > >> On Tue 20 Oct 2009 10:27, l...@gnu.org (Ludovic Courtès) writes: > > [...] > >>> In theory, we could interpret the ‘.go’ cookie and byte-swap things if >>> needed... >> >> In theory yes. In practice we map things read-only so they can be cached >> and not copied, and we'd have to instrument individual VM ops > > Or we could copy the bytecode (when it’s foreign) instead of mmapping > it, and translate instructions that are endianness-sensitive. > > Now, I agree it’s a big task, and one I’d rather avoid 2 months before > 2.0. I agree. (I'd rather avoid it altogether.) >>> I’m in favor of ‘.go’ alongside ‘.scm’: that’s what happens with >>> .elc/.el and .pyc/.py and it had been the plan from 1.9.0 until >>> recently. >> >> For python, pyc files are in $libdir, for exactly this reason. > > Out of curiosity, are .pyc endianness- and word-size-sensitive? I think so, yes. I could be wrong. > What about .elc? Don't know. > Guile itself currently installs ‘.go’ under $pkgdatadir. That would > need to be changed to $pkglibdir/1.9, right? .scm files got to $pkgdatadir, .go files to $pkglibdir. > Also we now have $GUILE_LOAD_PATH and $GUILE_LOAD_COMPILED_PATH. Should > we also have an equivalent to ‘-L’? Hm, good question. I don't know the answer to that one. Regards, Andy -- http://wingolog.org/
