From: Neil Jerram <neil@ossau.uklinux.net>
Cc: ttn@glug.org, guile-devel@gnu.org, guile-user@gnu.org
Subject: Re: [d.love@dl.ac.uk: dynamic loading of native code modules]
Date: 16 Apr 2002 21:23:24 +0100 [thread overview]
Message-ID: <m3sn5vpf43.fsf@laruns.ossau.uklinux.net> (raw)
In-Reply-To: 87lmbpiocf.fsf@raven.i.defaultvalue.org
>>>>> "Rob" == Rob Browning <rlb@defaultvalue.org> 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
next prev parent reply other threads:[~2002-04-16 20:23 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-12 1:06 [d.love@dl.ac.uk: dynamic loading of native code modules] Thien-Thi Nguyen
2002-04-13 8:50 ` Neil Jerram
2002-04-14 0:58 ` Rob Browning
2002-04-14 22:22 ` Neil Jerram
2002-04-15 4:21 ` Rob Browning
2002-04-16 20:23 ` Neil Jerram [this message]
2002-04-17 5:25 ` Rob Browning
2002-04-20 8:14 ` Thien-Thi Nguyen
2002-04-20 11:07 ` Neil Jerram
2002-04-15 12:15 ` Marius Vollmer
2002-04-16 20:24 ` Neil Jerram
2002-04-17 0:53 ` NIIBE Yutaka
2002-04-20 7:57 ` Thien-Thi Nguyen
2002-04-17 5:36 ` Rob Browning
2002-04-17 5:43 ` Rob Browning
2002-04-20 7:53 ` Thien-Thi Nguyen
2002-04-21 15:20 ` Rob Browning
2002-04-21 15:51 ` Robert A. Uhl
2002-04-21 16:27 ` Rob Browning
2002-05-14 8:53 ` Thien-Thi Nguyen
2002-04-14 21:30 ` Marius Vollmer
2002-04-15 17:58 ` Andreas Rottmann
2002-04-15 19:06 ` Marius Vollmer
2002-04-24 8:00 ` Thien-Thi Nguyen
2002-04-24 14:33 ` Rob Browning
2002-04-24 14:51 ` rm
2002-04-24 15:14 ` Andreas Rottmann
2002-04-24 15:48 ` Rob Browning
2002-04-24 16:15 ` Bill Gribble
2002-04-24 16:24 ` Rob Browning
2002-04-24 18:10 ` Andreas Rottmann
2002-04-24 20:36 ` Rob Browning
[not found] ` <87wuuwhm08.fsf@raven.i.defaultvalue.org>
2002-04-25 2:05 ` Joshua Judson Rosen
2002-04-25 3:03 ` Rob Browning
2002-04-24 18:06 ` Andreas Rottmann
2002-04-24 20:40 ` Rob Browning
2002-04-24 20:53 ` Andreas Rottmann
2002-04-30 0:26 ` Lynn Winebarger
2002-04-30 1:35 ` Thien-Thi Nguyen
2002-04-30 2:33 ` Lynn Winebarger
[not found] ` <0204292133140I.10649@locke.free-expression.org>
2002-05-04 0:19 ` Thien-Thi Nguyen
2002-04-30 0:20 ` Lynn Winebarger
2002-04-24 15:28 ` Rob Browning
2002-05-15 0:19 ` Thien-Thi Nguyen
2002-04-24 18:34 ` Thien-Thi Nguyen
2002-04-24 18:58 ` Rob Browning
2002-04-25 5:32 ` Thien-Thi Nguyen
2002-05-01 5:00 ` Lynn Winebarger
2002-05-01 13:50 ` Rob Browning
2002-04-24 0:52 ` Thien-Thi Nguyen
2002-04-20 9:06 ` Thien-Thi Nguyen
2002-04-20 12:21 ` Neil Jerram
2002-04-20 12:44 ` Thien-Thi Nguyen
2002-04-24 0:09 ` Thien-Thi Nguyen
2002-04-14 0:34 ` Rob Browning
2002-04-14 2:55 ` Rob Browning
2002-04-24 0:24 ` Thien-Thi Nguyen
2002-04-24 5:25 ` Rob Browning
2002-04-24 21:18 ` Marius Vollmer
2002-04-25 4:10 ` Thien-Thi Nguyen
2002-04-28 15:32 ` Marius Vollmer
2002-04-28 20:19 ` Thien-Thi Nguyen
2002-05-14 10:57 ` Thien-Thi Nguyen
2002-05-14 16:11 ` Bill Gribble
2002-05-14 20:54 ` Thien-Thi Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3sn5vpf43.fsf@laruns.ossau.uklinux.net \
--to=neil@ossau.uklinux.net \
--cc=guile-devel@gnu.org \
--cc=guile-user@gnu.org \
--cc=ttn@glug.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).