Re: slib with guile 1.9.7
| From: l...@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) | Date: Tue, 02 Feb 2010 23:17:27 +0100 | | ... | | scheme@(guile-user)> (if (not (defined? 'foo))(define foo 2)) | Throw to key `syntax-error': | ERROR: In procedure sc-expand: | ERROR: definition in expression context in subform `foo' of `2' | | I wonder whether we should hack ‘if’ to support this idiom, for | backward compatibility, since it used to be relatively common. | | At any rate, the following should work both with 1.8 and 2.0 (and | probably older versions): | | (if (not (defined? 'foo)) | (module-define! (current-module) 'foo 2)) I have unconditionalized the definitions for browse-url, vector->array, array->vector, and random:chunk in slib/guile.init. The development version is updated: http://groups.csail.mit.edu/mac/ftpdir/users/jaffer/slib.zip Also, the CVS repository is updated: https://savannah.gnu.org/cvs/?group=slib
Re: Mac OS X .dylib not working
Hi, Ken Raeburn writes: > [Is Hans on one of these lists now? His original message to bug-guile > said not and asked to be cc'ed.] We might have lost him then. ;-) > On Feb 2, 2010, at 13:01, Ludovic Courtès wrote: >> The Guile manually specifically tells that FNAME should not contain >> an extension. > > That could be unfortunate, since it means that unlike other Mac > applications, a Guile application would not be able to customize its > plugin names to use Foo.quuxplugin type names. Guile apps would be > limited to a hardcoded set of suffixes then, right? Guile doesn’t modify FNAME, it just passes it on to ‘lt_dlopenext ()’. >> Surprisingly, I just noticed that Guile itself doesn’t use the >> ‘-module’ option of Libtool when creating its ‘libguile-srfi-srfi-1’ >> module (which is meant to be dlopened *or* directly linked against), >> although this has never caused any problems on OS X. If you search >> for that in [1], ‘libguile-srfi-srfi-1’ is actually created with >> ‘-dynamiclib’. > > Current versions of Mac OS X can load shared libraries (.dylib) as > well as the bundle format that seems to have been the original plugin > form (.so, .bundle, ...). So in practice, assuming you can dlopen and > dlclose a shared library works pretty well, though I gather it might > not have worked as well in earlier releases. OK. > But we should also support the format(s) intended for plugin modules > as well, and the naming conventions (which appear to be somewhat > varied, and less consistent than on other OSes). Since libguile-srfi-srfi-1 is intended both to be dlopened and linked directly against, we’d need to link it twice, once with ‘-module’ and another one to create the shared library. I can’t imagine myself tweaking the build system in non-trivial ways to accommodate old versions of OS X, though... Thanks, Ludo’.
Re: Mac OS X .dylib not working
[Is Hans on one of these lists now? His original message to bug-guile said not and asked to be cc'ed.] On Feb 2, 2010, at 13:01, Ludovic Courtès wrote: > The Guile manually specifically tells that FNAME should not contain an > extension. That could be unfortunate, since it means that unlike other Mac applications, a Guile application would not be able to customize its plugin names to use Foo.quuxplugin type names. Guile apps would be limited to a hardcoded set of suffixes then, right? > Surprisingly, I just noticed that Guile itself doesn’t use the ‘-module’ > option of Libtool when creating its ‘libguile-srfi-srfi-1’ module (which > is meant to be dlopened *or* directly linked against), although this has > never caused any problems on OS X. If you search for that in [1], > ‘libguile-srfi-srfi-1’ is actually created with ‘-dynamiclib’. Current versions of Mac OS X can load shared libraries (.dylib) as well as the bundle format that seems to have been the original plugin form (.so, .bundle, ...). So in practice, assuming you can dlopen and dlclose a shared library works pretty well, though I gather it might not have worked as well in earlier releases. But we should also support the format(s) intended for plugin modules as well, and the naming conventions (which appear to be somewhat varied, and less consistent than on other OSes). At least, that's my impression; I'm not an expert in that area of the OS, I've just read some of the docs... Ken
