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: 14 Apr 2002 23:22:28 +0100 Sender: guile-user-admin@gnu.org Message-ID: References: <874rifqeo8.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 1018823272 21148 127.0.0.1 (14 Apr 2002 22:27:52 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 14 Apr 2002 22:27:52 +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 16wsTP-0005Uz-00 for ; Mon, 15 Apr 2002 00:27:52 +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 16wsSp-0007rS-00; Sun, 14 Apr 2002 18:27:15 -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 16wsSO-0007oS-00; Sun, 14 Apr 2002 18:26:48 -0400 Original-Received: from portalet.ossau.uklinux.net (IDENT:root@ppp-6b-41.3com.telinco.net [212.159.139.41]) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id g3EMQVd14245; Sun, 14 Apr 2002 23:26:31 +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 XAA01859; Sun, 14 Apr 2002 23:26:18 +0100 Original-To: Rob Browning Original-Lines: 128 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:172 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:172 >>>>> "Rob" == Rob Browning writes: Rob> Neil Jerram writes: >> 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). Rob> Some of the higher level abstractions and flexibility sound Rob> good, but I'm a little concerned about automatically Rob> generating the init function from the module name -- this Rob> makes it hard (as I mentioned before) to create modules that Rob> share the same C lib or modules that require multiple C libs. Rob> It may also make it difficult to easily wrap up existing libs Rob> without having to create unnecessary "dummy stub" libs, and Rob> feels a little like overspecification. Ah yes, I remember the discussion now. Rob> Of course this would only be a problem if it was the *only* Rob> interface. If we also provided a flexible enough low-level Rob> interface for loading shared libs, then having a more Rob> automagic, optional higher-level interface might be fine. I'm pretty sure that Thi was wanting to reinstate (use-modules ...) support _in addition to_ keeping load-extension and dynamic-call etc. >> 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.) Rob> My current plan is for 1.8 to have versioned scheme level Rob> modules (i.e. use-modules modules), and some workaround that Rob> allows for versioned dynamic-link'ing (in part to avoid Rob> libtool problems with installations of multiple guile Rob> versions), so I don't think there's much chance for seamless Rob> continuity between 1.6 and 1.8 anyway. Given that, I don't Rob> think it's worth holding up 1.6 for this, and in truth, my Rob> personal feeling (given my experiences with the module system Rob> and shared libraries while working on gnucash, g-wrap, Rob> mainstream guile, and other projects) is that the current 1.6 Rob> system is a lot easier to follow. In the normal case, by Rob> looking at one .scm file, you know exactly what's going on, Rob> and what's part of a module's interface. Rob> (define-module (foo bar)) Rob> (dynamic-call "my_init_func" (dynamic-link "libmylib")) Rob> (export func1) Rob> (export func2) Rob> ... 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? If it is, then that's probably sufficient for 1.6, and I'll add something to the docs to make that clear. Rob> (load-extension might also (should?) be used here). To me Rob> this code is *really* clear, but other people's mileage may Rob> vary :> Yes, load-extension should be used here. The difference is that load-extension provides a way of handling the case where the LIB is already statically linked in. (And the case where it has previously been dynamically linked?) I think the code is still pretty explicit: (load-extension "libmylib" "my_init_func") >> 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. Rob> I guess I'd have to disagree here too. Most of the stuff that I can Rob> think of that we've "lost" actually makes guile cleaner and less Rob> confusing to me, and the stuff that we've added (or are adding) makes Rob> guile much more useful. As examples of things we've done or planned Rob> since 1.4: Rob> drop gh_* -> less confusing Rob> add documentation for scm_* -> more useful. Rob> add goops -> *much* more useful Rob> adding GMP -> (for bignums -- on the way to rationals?) more useful Rob> fixing libtool versioning issues -> more useful (more packagable) Rob> planning to drop certain macro "flexibility" so we can support a Rob> clear evaluation model and perhaps eventually support compilation -> Rob> more useful. Rob> etc., but do you have particular things you think we've dropped that Rob> have actually hurt substantially? Rob> Overall I think guile may have (had?) a bit of excess baggage, and Rob> I've felt like there's likely to be a decent amount of pruning, Rob> pruning which should make guile stronger, before it becomes the Rob> extension languge (and perhaps often scheme implementation) of choice Rob> if it *is* going to. I guess rightly or wrongly I've been considering Rob> 1.6 and 1.8 to be fairly serious "housecleaning" releases... Well, I agree with all the examples you give here, but what about the following? - dropped support for multibyte strings [unless I'm misunderstanding the old mailing lists, Guile used to have these !] - dropped/lost support for Tcl/Tk - dropped/lost support for Ctax and other things (parser, rx etc.) in the guile-lang-allover package (or guile-rgx-ctax in CVS) - dropped/lost support for Hobbit compilation Now, apart from multibyte strings, none of these should be in the core (and I haven't checked whether they were ever distributed as such). Most of the examples here are to do with compatibility of Guile core with its surrounding packages, and so shouldn't conflict with the wonderful pruning/cleanups that have been going on in the last couple of years (and which I totally support). So how did we lose them? I shall resist the temptation to quote Lady Bracknell. Neil _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user