I'm building guile 1.5.6, and I get this error from "make check":
make[1]: Entering directory `/fs/home/mount/home/prj/src/sptools/guile-1.5.6'
make check-TESTS
make[2]: Entering directory `/fs/home/mount/home/prj/src/sptools/guile-1.5.6'
Testing /home/prj/src/sptools/guile-1.5.6/pre-inst-guile
I have guile 1.4.1 installed in an unusual place, so PREFIX/lib isn't
in the usual search path for shared libraries. It seems guile should
always search PREFIX/lib, preferably before the systemwide directories
and after those listed in $LD_LIBRARY_PATH. (Actually, it should
search all the -rpath
I wrote:
> When I evaluate (use-modules (ice-9 readline)), guile search only /lib
> when looking for libguilereadline.so (not even /usr/lib).
More info: if I create a symlink in /lib for libguilereadline.so, then
it will continue searching in /usr/lib after /lib. It seems to search
all directori
Thien-Thi Nguyen <[EMAIL PROTECTED]> wrote:
> the fix is to install libguilereadline et al "internally" (under
> $pkglibdir) and reference them directly.
So in a future version, this will Just Work?
> could you post platform info?
Linux 2.4.18, glibc 2.2.5, ncurses 5.2, readline 4.2a, gcc 3.1,
I'm new to Scheme, so maybe this isn't a bug, but this script:
#!/usr/local/bin/guile -s
!#
(let ()
(define x #t)
(define y x)
#t)
gives me this error:
ERROR: Unbound variable: x
I had thought the definition of x was supposed to be visible
throughout the body of the enclosing (let). I can
Michael Vanier <[EMAIL PROTECTED]> wrote:
> Well, it's even more hosed that you realize :-( When I do what you say, it
> reports that it can't find libguile-bessel.so in /usr/lib. When I copy
> libguile-bessel.so into /usr/lib, it reports that it can't find it in
> /usr/local/lib (the next path
Judy Hawkins <[EMAIL PROTECTED]> wrote:
> I tried to load the srfi-13 module:
>
>
>
> guile> (use-modules (srfi srfi-13))
> /usr/local/share/guile/1.6.0/srfi/srfi-13.scm:159:1: In procedure
> dynamic-link in expression (load-extension
> "libguile-srfi-srfi-13-14-v-1" "scm_init_srfi_13"):
> /u
[EMAIL PROTECTED] wrote:
> /usr/include/arpa/inet.h:74: previous declaration of 'inet_aton'
> make[1]: *** [net_db.lo] Error 1
> make[1]: Leaving directory 'home/doctrit/temp/guile-1.3.4/libguile'
> make: *** [all-recursive] Error 1
That's a very old version of guile; the b
Some symbols are written in such a way that they can't be read back.
guile> '#{foo\}\# bar}#
#{foo}#\ bar}#
It seems to me that the space does not need to be escaped, but at
least one of "}" or "#" does need it.
paul
___
Bug-guile mailing list
[EMAI
"Jose Roberto B. de A. Monteiro" <[EMAIL PROTECTED]> wrote:
> "Kevin Ryde" wrote:
>> "Jose Roberto B. de A. Monteiro" <[EMAIL PROTECTED]> writes:
>>> - (request (format #f "~A ~A ~A" method path http:version))
>>> + (request (format #f "~A ~A ~A\r\nHost: ~A" method path http:version
>
Guido Sohne <[EMAIL PROTECTED]> wrote:
...
> works fine. However if your .guile has the following in it
>
> (define-module (guile-user))
> (use-modules (ice-9 readline))
> (activate-readline)
>
> then all kind of wierdness goes on ...
I get the same result in either case. The only difference for
$ uname -mpsr
OpenBSD 3.3 i386 Intel Pentium III (Tualatin) ("GenuineIntel" 686-class)
$ guile --version | sed q
Guile 1.6.4
$ guile -c '(use-modules (srfi srfi-13))'
ERROR: In procedure dynamic-func:
ERROR: symbol not found
./configure correctly discovered:
checking for _ prefix in compiled symbo
(OOC, would a patch like this be appropriate for 1.6? What's the
policy there?)
ISTR someone suggested triggering the garbage collector after so many
open()s; that might make this patch unnecessary - if it included
opendir(), that is. Anyway:
Index: guile-core/ice-9/ftw.scm
Marius Vollmer <[EMAIL PROTECTED]> wrote:
> What about calling the gc automatically when an open failes with
> EMFILE or ENFILE in functions like scm_open_file? Even better would
> be keeping a running total like scm_mallocated to run the gc well
> before fds are exhausted, but that is one thing m
Squashing more bugs for weird symbol names.
* print.c (scm_print_symbol_name): Handle #{`foo}#, #{,foo}#,
and #{.}# specially.
This is still not complete, though. There are still problem cases
like #{0.0}#, #{-i}#, etc. Rather than trying to duplicate all the
number-detection lo
I wrote:
> * print.c (scm_print_symbol_name): Handle #{`foo}#, #{,foo}#,
> and #{.}# specially.
>
> This is still not complete, though. There are still problem cases
> like #{0.0}#, #{-i}#, etc.
This patch handles those numeric cases. It incorporates and overrides
my earlier patch.
Kevin Ryde <[EMAIL PROTECTED]> wrote:
> It'd be better not to hard code a system name. Is there some way to
> test which of the two works?
Or is there a TZ designation that works everywhere - say, expressed as
an offset from UTC?
paul
___
Bug-guile
Andreas Vögele <[EMAIL PROTECTED]> wrote:
> There's no common synonym for CET but the time zone EST5EDT seems to work on
> GNU/Linux, Solaris, HP-UX and Mac OS X.
It also works for me on {Free,Net,Open}BSD and BSD/OS. (Then again,
the NetBSD and BSD/OS machines use that time zone by default anywa
Building 1.6.5 fails for me:
...
creating guile
cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc chars.doc
continuations.doc debug.doc dynl.doc dynwind.doc environments.doc eq.doc error.doc
eval.doc evalext.doc extensions.doc feature.doc fluids.doc fports.doc gc.doc goops.doc
gsubr
Rob Browning <[EMAIL PROTECTED]> wrote:
> Just out of curiousity, do you have a version of guile already
> installed on that machine in the default path, and if so (and if it's
> easy), are the results any different if you remove that copy of guile
> (including libs) and clean/re-build 1.6.5?
I do
Rob Browning <[EMAIL PROTECTED]> wrote:
> It's not the PATH, that might be the problem. It's the lib dir. If
> you have 1.6.4 installed in /usr/lib, then you'd need to actually
> uninstall it to test.
Ah. Everything is installed in its own directory here, and there even
is no /usr/lib or /lib (
Marius Vollmer <[EMAIL PROTECTED]> wrote:
> subdirs_with_ltlibs="libguile-ltdl srfi guile-readline" # maintain me
No effect.
> Maybe it's some change in the autotools. Could you try your local
> versions with guile-1.6.5? (I.e., run autoreconf in the top source
> dir.)
My autoconf, aut
The libtool changes in 1.6.7 seem to have fixed this.
paul
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Kevin Ryde <[EMAIL PROTECTED]> wrote:
> I don't think that function ever returns, gcc probably shouldn't
> complain about such cases.
__attribute__((noreturn)) may be helpful in that case.
paul
___
Bug-guile mailing list
Bug-guile@gnu.org
http://list
24 matches
Mail list logo
