Re: Should we distribute libltdl?
A big question is the ease of installation for those using OS package
systems vs those doing things by hand. My view is that the really big
issue is making things
a) easy to package
and
b) easy to use once packaged
Since that's what is in the critical path to having things like
gnumeric have guile support out of the box.
FWIW NetBSD pkgsrc installs libltdl via the devel/libltld package.
Do people other than guile hackers build guile by hand, and if so do
they use package systems to get things like readline and gmp?
Here's the guile control file for pkgsrc. But it seems to link in the
special guile ltldl:
/usr/pkg/bin/guile:
-lcrypt.0 => /usr/lib/libcrypt.so.0
-lm.0 => /usr/lib/libm387.so.0
-lm.0 => /usr/lib/libm.so.0
-lpthread.0 => /usr/lib/libpthread.so.0
-lguile-ltdl.1 => /usr/pkg/lib/libguile-ltdl.so.1
-lguile.12 => /usr/pkg/lib/libguile.so.12
-lc.12 => /usr/lib/libc.so.12
# $NetBSD: Makefile,v 1.58 2004/11/18 12:30:49 wiz Exp $
DISTNAME= guile-1.6.5
CATEGORIES= lang
MASTER_SITES= ${MASTER_SITE_GNU:=guile/}
MAINTAINER= [EMAIL PROTECTED]
HOMEPAGE= http://www.gnu.org/software/guile/guile.html
COMMENT=GNU's Ubiquitous Intelligent Language for Extension
CONFLICTS= guile14<1.4.1nb1 guile-oops-[0-9]*
USE_BUILDLINK3= YES
GNU_CONFIGURE= YES
USE_GNU_TOOLS+= make
USE_LIBTOOL=YES
USE_GNU_READLINE= YES
USE_MAKEINFO= YES
INFO_FILES= guile.info guile-tut.info goops.info r5rs.info
TEST_DIRS= ${WRKSRC}
TEST_TARGET=check
.include "../../mk/bsd.prefs.mk"
.if ${OPSYS} == "Darwin"
CPPFLAGS+= -Dmacosx
post-patch:
@${MV} ${WRKSRC}/guile-config/guile-config.in.orig \
${WRKSRC}/guile-config/guile-config.in
.endif
.include "../../devel/libltdl/buildlink3.mk"
.include "../../devel/ncurses/buildlink3.mk"
.include "../../devel/readline/buildlink3.mk"
.include "../../mk/pthread.buildlink3.mk"
.include "../../mk/bsd.pkg.mk"
--
Greg Troxel <[EMAIL PROTECTED]>
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
Re: Should we distribute libltdl?
Greg Troxel <[EMAIL PROTECTED]> writes: > A big question is the ease of installation for those using OS package > systems vs those doing things by hand. My view is that the really big > issue is making things > a) easy to package > and > b) easy to use once packaged Those two things would benefit when Guile explicitely declares as a external dependency. The Right Thing for a Guile OS package such as a .deb or .rpm is not to contain libltdl but to depend on the package that contains libltdl. > Here's the guile control file for pkgsrc. But it seems to link in the > special guile ltldl: Yes, in the 1.6 series we use our own version of libltdl. This is no longer the case. ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: primitive-fork hang
Kevin Ryde <[EMAIL PROTECTED]> writes: > Marius Vollmer <[EMAIL PROTECTED]> writes: >> >> Does it still fail for you? > > Yes. I'm not sure if it's something I've done. I had trouble getting > gdb to show anything. I remember seeing strange blocking as well, and I think it was because some pipe wasn't being closed properly in the parent or child. That open pipe prevented one of the parties from seeing EOF, or something like that. ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: Should we distribute libltdl?
Bruce Korb <[EMAIL PROTECTED]> writes: > My opinion: the more impediments to installation that there are > results in more folks deciding that it isn't worth the bother. > I really hate downloading a package only to find that there's > a bunch of other stuff to find, download and install first. Yes, but I think Guile is very reasonable with its "bunch of other stuff". It only really requires libgmp and libltdl. The versions of these that are in the mainstream distributions should suffice. Also, the question right is not whether should rely on libltdl, it is whether we should distribute libltdl and automatically install it when needed. That is, should Guile say "You don't seem to have libltdl, I will quietly install it for you." or should it say loudly "You don't seem to have libltdl, please install it, for example from ..."? On Debian, for example, it would be much cleaner to "apt-get install libltdl3-dev" instead of letting Guile install libltdl into /usr/local/lib, say. ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: Should we distribute libltdl?
Hi Marius, Marius Vollmer wrote: > Yes, but I think Guile is very reasonable with its "bunch of other > stuff". It only really requires libgmp and libltdl. The versions of > these that are in the mainstream distributions should suffice. The mainstream distributions "of Linux" :). My world is about 1/4 Linux and doesn't Guile's "u" stand for "ubiquitous"? ;-) > Also, the question right is not whether should rely on libltdl, it is > whether we should distribute libltdl and automatically install it when > needed. That is, should Guile say "You don't seem to have libltdl, I > will quietly install it for you." or should it say loudly "You don't > seem to have libltdl, please install it, for example from ..."? The "for example from" clause would make the failure much more palatable than the straight up obtuse failures from other packages. I would still _prefer_ to see either an "I've installed it for you" message, or even a "I cannot install Guile unless you let me install libltdl with an ``--enable-libltdl-install'' configure option". Telling me to go off and fetch a package at some well-known location is "okay." Since you are not proposing to fail the configure and leave no clues, in the end I am okay with whatever you want to do :). Thank you. Cheers - Bruce ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: Should we distribute libltdl?
Bruce Korb <[EMAIL PROTECTED]> writes: > Since you are not proposing to fail the configure and leave no clues, Yes, good documentation is of course needed. Right now, Guile fails with configure: error: libltdl not found. See README. And the README says: Required External Packages Guile requires the following external packages: - GNU MP, at least version 4.1 GNU MP is used for bignum arithmetic. It is available from http://swox.com/gmp - libltdl from libtool, at least from libtool version 1.5.6 libltdl is used for loading extensions at run-time. It is available from http://www.gnu.org/software/libtool/ > in the end I am okay with whatever you want to do :). Ok! :) ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: Should we distribute libltdl?
On Tue, Mar 08, 2005 at 09:13:48AM -0800, Bruce Korb wrote: > Hi Marius, > > Marius Vollmer wrote: > > > Yes, but I think Guile is very reasonable with its "bunch of other > > stuff". It only really requires libgmp and libltdl. The versions of > > these that are in the mainstream distributions should suffice. > > The mainstream distributions "of Linux" :). My world is about 1/4 Linux > and doesn't Guile's "u" stand for "ubiquitous"? ;-) Ynd right you are :-) There's GNU outside of Linux > > Also, the question right is not whether should rely on libltdl, it is > > whether we should distribute libltdl and automatically install it when > > needed. That is, should Guile say "You don't seem to have libltdl, I > > will quietly install it for you." or should it say loudly "You don't > > seem to have libltdl, please install it, for example from ..."? > > The "for example from" clause would make the failure much more palatable > than the straight up obtuse failures from other packages. I would still > _prefer_ to see either an "I've installed it for you" message, or even > a "I cannot install Guile unless you let me install libltdl with an > ``--enable-libltdl-install'' configure option". Telling me to go off and > fetch a package at some well-known location is "okay." > > Since you are not proposing to fail the configure and leave no clues, > in the end I am okay with whatever you want to do :). Hmm, from two other often-used libraries: both expat and neon seem to be libraries used by many OSS projects. Many seem to distrubute their own version of these libraries but give the user a chance to use the system installed versions (by means of a configuration option '--with-local-expat' or the like). Same goes for the Boehm garbage collector ... Can't guile distribute libltdl but only use it iff there's no local version found (or if the user states her intention by configure magic)? cheers Ralf Mattes > Thank you. Cheers - Bruce > > > ___ > Guile-devel mailing list > Guile-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/guile-devel ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: Should we distribute libltdl?
Marius Vollmer <[EMAIL PROTECTED]> writes: > Those two things would benefit when Guile explicitely declares as a > external dependency. The Right Thing for a Guile OS package such as a > .deb or .rpm is not to contain libltdl but to depend on the package > that contains libltdl. For the record, now that we don't need customizations, I don't have any problem with dropping our copy of libltdl. Alhough I agree that it would be good to have a clear configure error message when libltdl is not detected. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
About 'futures'
Hi, what is the difference between (join-thread (begin-thread (foo))) and (future-ref (future (foo))) I am thinking about implementing futures as just (define-macro (future exp) `(begin-thread ,exp)) (define future-ref join-thread) Would that make sense? ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: Should we distribute libltdl?
Rob Browning wrote: Marius Vollmer <[EMAIL PROTECTED]> writes: Those two things would benefit when Guile explicitely declares as a external dependency. The Right Thing for a Guile OS package such as a .deb or .rpm is not to contain libltdl but to depend on the package that contains libltdl. For the record, now that we don't need customizations, I don't have any problem with dropping our copy of libltdl. Alhough I agree that it would be good to have a clear configure error message when libltdl is not detected. That's my view too. Perhaps I'm spoilt by being a Debian user, but if other OS's don't have a decent package system, they really ought to sort that out. Neil ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: About 'futures'
On Tue, 08 Mar 2005 19:04:17 +0100, Marius Vollmer <[EMAIL PROTECTED]> wrote: > what is the difference between > > (join-thread (begin-thread (foo))) > > and > > (future-ref (future (foo))) The first construct is guaranteed to start a new OS thread with its own, complete, dynamic context. The indended usage pattern is an application divided into a number of threads handling different tasks. The implementation is optimized for the completeness of the environment provided in the thread rather than, e.g., startup time. The second is a lightweight mechanism intended for fast, small-scale, parallelism, such as in the `letpar' or 'par-map' constructs which evaluate its component expressions in parallel. The implementation is optimized for quick start and delivery of the result rather than providing a complete context rooted in a new OS thread. The current implementation caches a number of "workers", so rather than spawning a new thread, `future' simply implies signalling a condition variable. (The current implementation is not complete since the dynamic context is not re-initialized for each evaluation in a worker thread. In order to complete the implementation one needs to define what "dynamic context" includes in this case. The aim is that it should be minimal.) > I am thinking about implementing futures as just > > (define-macro (future exp) `(begin-thread ,exp)) > (define future-ref join-thread) > > Would that make sense? I don't think so for obvious reasons. It would not make sense to spawn new pthreads for the kind of usage patterns for which futures are intended. In my opinion it's better to scrap futures entirely than to provide the suggested implementation above. But I would surely miss them. I have used these parallel language constructs to make computations go faster on an SMP machine. It makes beautiful sense when the subexpressions of a letpar are matrix computations with operations implemented on the C level. Note also that futures, by their nature, necessarily needs to be maintained together with the guile-core rather than being provided by a separate package. M ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: About 'futures'
Marius Vollmer <[EMAIL PROTECTED]> writes: > what is the difference between > > (join-thread (begin-thread (foo))) > > and > > (future-ref (future (foo))) > > I am thinking about implementing futures as just > > (define-macro (future exp) `(begin-thread ,exp)) > (define future-ref join-thread) > > Would that make sense? Based on what I know of the semantics of the respective operations, it seems fine. Though is a terminated thread very "heavy"? i.e. is it much heavier than a cons pair? If so, then one optimization for futures would be to implement them such that when the thread is finished, the thread pointer is dropped, so that only the result remains. One way to do that might be to represent a future as (cons thread result-destination). Given that, future-ref would either join-thread or call cdr as appropriate. Although you'd probably also need a mutex which might obviate any potential resource savings achieved by dropping the thread. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: Should we distribute libltdl?
> Yes, but I think Guile is very reasonable with its "bunch of other > stuff". It only really requires libgmp and libltdl. The versions of > these that are in the mainstream distributions should suffice. The mainstream distributions "of Linux" :). My world is about 1/4 Linux and doesn't Guile's "u" stand for "ubiquitous"? ;-) I'm very sensitive to this, as my world is about 0.01 Linux (mostly NetBSD). My point was that modern operating systems usually have some flavor of package management. Linux distriutions have ways, FreeBSD and OpenBSD have ports, NetBSD has pkgsrc, and it seems there are ways to do this on Solaris and Mac OS X. Note that pkgsrc works on many OSes - I believe all of the above, IRIX, and even AIX sort of. Using the included libraries when the package is not found only seems reasonable for libraries that will be statically linked into the installed program, so that doing this doesn't preclude later installing the needed libraries. This seems not to be how guile does it, so that seems to be asking for trouble, but perhaps I misunderstand. -- Greg Troxel <[EMAIL PROTECTED]> ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: About 'futures'
Mikael Djurfeldt <[EMAIL PROTECTED]> writes: > > The current implementation caches a number of "workers", so rather > than spawning a new thread, Do they get gc'ed after a while? The relative lightness of futures probably wants mentioning in the manual. ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
