From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.lisp.guile.devel Subject: [d.love@dl.ac.uk: dynamic loading of native code modules] Date: Thu, 11 Apr 2002 18:06:43 -0700 Sender: guile-devel-admin@gnu.org Message-ID: Reply-To: ttn@glug.org NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1018573942 3994 127.0.0.1 (12 Apr 2002 01:12:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 12 Apr 2002 01:12:22 +0000 (UTC) Cc: guile-user@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16vpbx-00012J-00 for ; Fri, 12 Apr 2002 03:12:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16vpbl-0008RF-00; Thu, 11 Apr 2002 21:12:09 -0400 Original-Received: from ca-crlsbd-u4-c4c-174.crlsca.adelphia.net ([68.66.186.174] helo=giblet) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16vpae-0008Mc-00; Thu, 11 Apr 2002 21:11:00 -0400 Original-Received: from ttn by giblet with local (Exim 3.33 #1 (Debian)) id 16vpWV-0001wJ-00; Thu, 11 Apr 2002 18:06:43 -0700 Original-To: guile-devel@gnu.org Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:357 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:357 From: Dave Love Subject: dynamic loading of native code modules Date: 10 Apr 2002 23:22:27 +0100 To: gnu-emacs-sources@gnu.org This patch for Emacs 21.1 basically extends `load' to allow loading compiled C modules and provides a script to build them. See also the attached README. [...] * Features These changes add the ability to dynamically load modules coded in C, like the Emacs interpreter core using Libtool facilities. This works just by extending `load' to accept file names with extension `.la' which describe Libtool-built modules. These are found on `load-path', like Lisp files, taking precedence over Lisp of the same base name if an extension isn't specified. They work with `require' (if the module provides a feature) and `eval-after-load' (should that ever be useful). They can't be loaded from remote filesystems. There is a feature test `dynamic-modules-p' added for the facility, but I'm not sure that's actually useful. Modules can only be loaded once and cannot be unloaded; it may be possible to remove these constraints. The script `build-emacs-module' cans the Libtool and doc-snarfing steps for building modules from source. XEmacs has a rather more complicated native code module system. I'm not sure the complication is necessary, and it doesn't build on libtool. (Bill Perry, who did the original XEmacs implementation, agrees that using Libtool is the right thing.) [...] guile-1.4 supports extending module name semantics to allow mapping also to .so in addition to .scm files (albeit low level uses dyn* directly -- could use update (patches welcome)). 1.6 does not at the moment (it was removed). grep "dyn" reveals 1537 hits since 2000-01. anyone have specific pointers for removal rationale? where is that refbot? it is possible to provide support again in `resolve-interface', but this support should not be put in boot-9.scm. instead, resolve-interface ought to add a user hook somewhere, or be tunable in some other way. this allows users to customize their concept of "interface" in a well-defined environment (entirely :-) suited for such customization. instantiable modules can be supported, etc. in parallel w/ this change is of course revival of (use-modules FOO) possibly resolving to .../libfoo.so.x.y.z, using the above hook and the modern load-extension interface. the previous mapping proc needs rationalization and some design to keep weird use-cases in check. another runner in the race is replacing lowest levels of the module system w/ environments, using the above hook (or similar internal hook) for implementation. getting load-extension and environments together, basically. these all are branches that can be pursued relatively independently after discussion yields a design. in the end, they are all part of defining the execution model, if i understand that term correctly, and moving things to "user space" is what it's all about (slack!). alternatively, we need to document *why* 1.6 chooses to rob the users so, at least to ourselves. "This has been found to be too tricky, and is no longer supported" is, although not dis-honest, still pretty lame. thi _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel