From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: [d.love@dl.ac.uk: dynamic loading of native code modules] Date: 16 Apr 2002 21:23:24 +0100 Sender: guile-devel-admin@gnu.org Message-ID: References: <874rifqeo8.fsf@raven.i.defaultvalue.org> <87lmbpiocf.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1018989016 1761 127.0.0.1 (16 Apr 2002 20:30:16 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 16 Apr 2002 20:30:16 +0000 (UTC) Cc: ttn@glug.org, 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 16xZah-0000S9-00 for ; Tue, 16 Apr 2002 22:30:15 +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 16xZab-0007d8-00; Tue, 16 Apr 2002 16:30:09 -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 16xZYH-0007Tx-00; Tue, 16 Apr 2002 16:27:45 -0400 Original-Received: from portalet.ossau.uklinux.net (IDENT:root@ppp-6a-14.3com.telinco.net [212.159.138.14]) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id g3GKRJ700547; Tue, 16 Apr 2002 21:27:20 +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 VAA01978; Tue, 16 Apr 2002 21:27:47 +0100 Original-To: Rob Browning Original-Lines: 82 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 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:393 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:393 >>>>> "Rob" == Rob Browning writes: >> Using this kind of approach, is it always possible to emulate the >> effect of the old use-modules behaviour by installing a .scm file >> that loads the required library? Rob> More or less, the primary differences that I can think of are that in Rob> the old approach you would put the shared libs in a /usr/share Rob> directory (which isn't quite right according to the FHS and causes Rob> problems on shared NFS volumes which expect only arch-independent data Rob> in /usr/share), where with the new approach the libs need to be Rob> located somewhere that libltdl can find them (system lib path, Rob> LD_LIBRARY_PATH or LDTL_LIBRARY_PATH). Also with the old approach, Rob> any functions defined in your shared lib would automatically and Rob> unavoidably be exported from the module that the shared lib Rob> represented -- with the new approach you need to either add an export Rob> for each function to the .scm file by hand, or write some module code Rob> to export all symbols defined in the module after the shared lib has Rob> been initialized -- i.e. Rob> (for-each Rob> (lambda (sym) (export sym)) Rob> (module-bindings (current-module))) Rob> or similar... In summary, then, if a module author previously packaged his/her library so that it could be loaded by (use-modules (pkg whatnot)), there is a way that he/she can continue to make (use-modules (pkg whatnot)) work in 1.6. That sounds OK to me. >> - dropped/lost support for Tcl/Tk, [also Ctax etc.] Rob> That strikes me as an "add on" that is only going to stick around for Rob> as long as there are enough people interested in guile's tcl/tk Rob> support to continue maintaining it [...] Rob> I guess in the end I feel that in the absence of infinite resources, Rob> extensions from the guile core that don't have enough demand to create Rob> and sustain the communities that develop and support them often will Rob> (and likely should) fade away. Rob> Things people want and need *will* get worked on. [...] True, but I'm still slightly worried that one of the influences on {the set of people interested enough to maintain surrounding packages} might be a gradual trickle of incompatible changes in the core. So (although I didn't state it clearly before) I guess my point is that the bitrotting of such modules might be pointing to a problem that results from an accumulation of small changes like the use-modules one here. On the other hand, a project that doesn't change is a dead project, and packages that can't cope with a small amount of change may not be worth coddling, and I agree with you that the utility of recent additions and cleanups far exceeds that of Tcl/Tk and Ctax support. >> - dropped/lost support for Hobbit compilation Rob> This one I've talked to Marius about off and on at some length, and Rob> have actually worked on a bit myself (Hobbit and CVS in particular). Rob> I think the conclusion was that guile's evaluator needs to be reworked Rob> in some of the ways that Marius, Lynn, and others, including myself Rob> have talked about, or any work on compilation is likely to be way too Rob> much effort for too little gain. Guile is not currently built to Rob> support compilation cleanly -- the addition of syntax-case and the Rob> ways in which it breaks hobbit (among other things) points this out. Rob> As Marius has mentioned we likely need a cleaner evaluation model Rob> (with clear separations between "read time", "compile time", and Rob> "execution time" before we're going to be able to make a lot of Rob> sustainable headway here. The good thing is that if we do manage to Rob> seprate these things in a resonable way, we may end up with a lot of Rob> interesting flexibility wrt to offline-compilation, JIT compilation, Rob> byte-compilation, etc. All very reasonable, and yet... something used to work, and now it doesn't. But on this point I'm unqualified to understand what the issues really were, so I'll shut up now! :-) Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel