From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.user Subject: Re: [d.love@dl.ac.uk: dynamic loading of native code modules] Date: 13 Apr 2002 09:50:22 +0100 Sender: guile-user-admin@gnu.org Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1018702147 31706 127.0.0.1 (13 Apr 2002 12:49:07 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 13 Apr 2002 12:49:07 +0000 (UTC) Cc: guile-devel@gnu.org, 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 16wMxm-0008FH-00 for ; Sat, 13 Apr 2002 14:49:06 +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 16wMwp-0007nc-00; Sat, 13 Apr 2002 08:48:07 -0400 Original-Received: from mail.uklinux.net ([80.84.72.21] helo=s1.uklinux.net) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16wMw6-0007kx-00; Sat, 13 Apr 2002 08:47:22 -0400 Original-Received: from portalet.ossau.uklinux.net (IDENT:root@ppp-6b-166.3com.telinco.net [212.159.139.166]) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id g3DClFk30424; Sat, 13 Apr 2002 13:47:15 +0100 Original-Received: from laruns.ossau.uklinux.net.ossau.uklinux.net (neil@laruns.ossau.uklinux.net [192.168.1.3]) by portalet.ossau.uklinux.net (8.9.3/8.8.7) with ESMTP id NAA15407; Sat, 13 Apr 2002 13:47:58 +0100 Original-To: ttn@glug.org In-Reply-To: Original-Lines: 61 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Errors-To: guile-user-admin@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.user:166 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:166 >>>>> "Thien-Thi" == Thien-Thi Nguyen writes: Thien-Thi> guile-1.4 supports extending module name semantics to allow mapping also Thien-Thi> to .so in addition to .scm files (albeit low level uses dyn* directly -- Thien-Thi> could use update (patches welcome)). 1.6 does not at the moment (it was Thien-Thi> removed). grep "dyn" reveals 1537 hits since 2000-01. anyone have grep "dyn" where? Thien-Thi> specific pointers for removal rationale? where is that refbot? I think just that the scm_init_xxx - scm_register_module_xxx - scm_init_module_xxx was thought rather awkward, and that too much of the boot-9.scm code was trying to be cleverer than it could justify. I recall an email from Marius saying this, but I don't have a specific pointer. Thien-Thi> it is possible to provide support again in `resolve-interface', but this Thien-Thi> support should not be put in boot-9.scm. instead, resolve-interface Thien-Thi> ought to add a user hook somewhere, or be tunable in some other way. Thien-Thi> this allows users to customize their concept of "interface" in a Thien-Thi> well-defined environment (entirely :-) suited for such customization. Thien-Thi> instantiable modules can be supported, etc. Thien-Thi> in parallel w/ this change is of course revival of (use-modules FOO) Thien-Thi> possibly resolving to .../libfoo.so.x.y.z, using the above hook and the Thien-Thi> modern load-extension interface. the previous mapping proc needs Thien-Thi> rationalization and some design to keep weird use-cases in check. Yes, I think this would be good, actually, and that the mechanism/hooks that you suggest are exactly the right approach. The description you gave of the Emacs patch glossed over one detail - what's the name of the function that gets called to initialize the dynamically loaded module? I think it would be acceptable to derive it algorithmically from the module name (and obviously impose this as a requirement on the module coder). If we can agree this, it would be good to do it in 1.6, for continuity. (Of interface, I mean; module coding would change slightly, as just stated.) Thien-Thi> another runner in the race is replacing lowest levels of the module Thien-Thi> system w/ environments, using the above hook (or similar internal hook) Thien-Thi> for implementation. getting load-extension and environments together, Thien-Thi> basically. Sounds orthogonal to me; is it? Thien-Thi> alternatively, we need to document *why* 1.6 chooses to rob the users Thien-Thi> so, at least to ourselves. "This has been found to be too tricky, and Thien-Thi> is no longer supported" is, although not dis-honest, still pretty lame. Upon reflection, I agree. More generally, looking back through mailing list history, it's actually astonishing how much support for various stuff that Guile has _lost_ along the way. My overall impression is that we (collectively) have been too glib about this. Neil _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user