Extension search path changed in 1.9
Hello!
‘sysdep_dynl_init’ has been doing this for some time in 1.9:
--8---cut here---start-8---
env = getenv (GUILE_SYSTEM_EXTENSIONS_PATH);
[...]
if (env)
lt_dladdsearchdir (env);
else
{
lt_dladdsearchdir (SCM_LIB_DIR);
lt_dladdsearchdir (SCM_EXTENSIONS_DIR);
}
--8---cut here---end---8---
While these functions /append/ their argument to ltdl’s search path,
said path (‘user_search_path’ in ltdl.c) actually prevails over
$LTDL_LIBRARY_PATH and $LD_LIBRARY_PATH:
--8---cut here---start-8---
static int
try_dlopen (lt_dlhandle *phandle, const char *filename, const char *ext,
lt_dladvise advise)
{
[...]
const char *search_path = user_search_path;
if (search_path)
file = find_file (user_search_path, base_name, dir);
if (!file)
{
search_path = getenv (LTDL_SEARCHPATH_VAR);
if (search_path)
file = find_file (search_path, base_name, dir);
}
[...]
}
--8---cut here---end---8---
(See
http://git.savannah.gnu.org/cgit/libtool.git/tree/libltdl/ltdl.c#n1342.)
This introduces a difference compared to 1.8.
In 1.8, to run the test suite of libguile-foo from its build tree, I
typically had a ‘pre-inst-guile’ like this:
--8---cut here---start-8---
exec @abs_top_builddir@/libtool --mode=execute \
-dlopen @abs_top_builddir@/src/libguile-foo.la \
@GUILE@ $@
--8---cut here---end---8---
which amounts to “LD_LIBRARY_PATH=$PWD/src/.libs:$LD_LIBRARY_PATH” on
GNU/Linux.
However, this no longer works with 2.0: if libguile-foo.so is already
present in SCM_EXTENSIONS_DIR, then it will be loaded instead of the one
from the build tree.
In 2.0, the script above can be fixed by preceding the guile invocation
by:
--8---cut here---start-8---
GUILE_SYSTEM_EXTENSIONS_PATH=@abs_top_builddir@/src
export GUILE_SYSTEM_EXTENSIONS_PATH
--8---cut here---end---8---
I’m not sure what can be done. We could document
$GUILE_SYSTEM_EXTENSIONS_PATH.
I suspect it may hit other Guile users, so at least this message
documents the problem. :-)
Thanks,
Ludo’.
Re: [PATCH 3/4] Work towards a more complete implementation of `(rnrs io ports)'
Hi Andreas,
Looks good, but...
Andreas Rottmann a.rottm...@gmx.at writes:
(call-with-port): Don't use `dynamic-wind', as it is against its
specification in R6RS 8.2.6.
[...]
(define (call-with-port port proc)
Call @var{proc}, passing it @var{port} and closing @var{port} upon exit of
@var{proc}. Return the return values of @var{proc}.
- (dynamic-wind
- (lambda ()
-#t)
- (lambda ()
-(proc port))
- (lambda ()
-(close-port port
+ (call-with-values
+ (lambda () (proc port))
+(lambda vals
+ (close-port port)
+ (apply values vals
I don’t see what in §8.2.6 would be against ‘dynamic-wind’, and
http://www.r6rs.org/formal-comments/comment-197.txt seems to suggest
that it’s OK.
Thanks,
Ludo’.
Re: [PATCH 3/4] Work towards a more complete implementation of `(rnrs io ports)'
l...@gnu.org (Ludovic Courtès) writes:
Hi Andreas,
Looks good, but...
Andreas Rottmann a.rottm...@gmx.at writes:
(call-with-port): Don't use `dynamic-wind', as it is against its
specification in R6RS 8.2.6.
[...]
(define (call-with-port port proc)
Call @var{proc}, passing it @var{port} and closing @var{port} upon exit
of
@var{proc}. Return the return values of @var{proc}.
- (dynamic-wind
- (lambda ()
-#t)
- (lambda ()
-(proc port))
- (lambda ()
-(close-port port
+ (call-with-values
+ (lambda () (proc port))
+(lambda vals
+ (close-port port)
+ (apply values vals
I don’t see what in §8.2.6 would be against ‘dynamic-wind’,
To quote that paragraph about `call-with-port':
,
| Proc must accept one argument. The call-with-port procedure calls proc
| with port as an argument. If proc returns, port is closed automatically
| and the values returned by proc are returned. If proc does not return,
| port is not closed automatically, except perhaps when it is possible to
| prove that port will never again be used for an input or output
| operation.
`
I interpreted that the way I did based on the question of what should
happen when `proc' throws an exception (or otherwise invokes a
continuation that makes it leave its current dynamic extent). To me, it
seems that in this case, `proc' does not _return_, and hence the port
should not be closed. Just to clarify, by a procedure returning, I
understand delivering a value (or values) to its continuation, which
does not happen if the procedure invokes some arbitrary (other)
continuation.
FWIW, `call-with-port' is implemented without `dynamic-wind' in Ikarus,
Ypsilon and Larceny.
and http://www.r6rs.org/formal-comments/comment-197.txt seems to
suggest that it’s OK.
Hmm, to me, the answer given to that comment does not really indicate
whether the proposed implementation using `dynamic-wind' is acceptable
or not (which is unfortunate).
Regards, Rotty
--
Andreas Rottmann -- http://rotty.yi.org/
Re: The progress of hacking guile and prolog
Hello, That might make sense. The documentation certainly looks interesting. What I'm thinking of is like racket contracts, but with the idea of trusted modules, which might involve static checking. For instance, if the contract is that map's second parameter is a list, you'd normally want to check that. But if a module that used map could guarantee that it would always pass a list as the second argument, then you'd arrange things so the second module could skip the type check. I'm curious in general though whether it would be possible and worthwhile to statically check programmer-defined ideas, as long as the interface is easy enough to use. For instance, what if you could ask Guile to check that your tree structure always remained a binary tree? Or better, what if you wrote a GUI program and checked that the callbacks you passed to the GUI library would always return? (I know it's not possible in general, but I think it will work for a subset of procedures that will include some interesting ones.) Noah On Sat, Nov 20, 2010 at 6:25 AM, Andy Wingo wi...@pobox.com wrote: Hi Noah, On Thu 04 Nov 2010 03:40, Noah Lavine noah.b.lav...@gmail.com writes: I think that Guile should offer optional static checking - not just of types, but of everything that we can check. It seems like you're really asking for *dynamic* checking -- not only checking properties that can be proved statically, without running the program, but also runtime properties. In this regard, I have a positive impression of the work that people are doing on contracts, especially the Racket folks. http://docs.racket-lang.org/reference/contracts.html Happy reading, Andy -- http://wingolog.org/
