[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guile 1.9.7 vs. 1.8.7
From: |
Ludovic Courtès |
Subject: |
Re: guile 1.9.7 vs. 1.8.7 |
Date: |
Thu, 28 Jan 2010 15:22:11 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Hello,
Petr Gajdos <address@hidden> writes:
> Information on
>
> http://www.gnu.org/software/guile/manual/html_node/SLIB-installation.html
>
> doesn't lead to proper slib installation for me. I am using slib3b2
> which seems to be installing well this way with 1.8.7. I don't know if
> this is bug in guile or slib or it is my fault.
>
> The result is:
[...]
> 3 (boot-closure (define base:define define))
Indeed, this expression works with first-class macros in 1.8 but no
longer works in 1.9. I don’t think 1.9 will ever get support for this
back, so I guess the right solution would be to adapt SLIB’s guile.init.
(This can be done using ‘(cond-expand (guile-2 ...))’.)
Would you like to coordinate with the SLIB maintainer to fix this?
> While guile 1.8.7 is starting less than one second, it takes
> approximatelly 12 seconds to start guile 1.9.7 on the same system,
> even if I run
That’s weird. Are you sure all the .scm files under module/ got
compiled and that the resulting .go files were installed and are in the
search path?
In my experience Guile 1.9 starts faster than 1.8.
> When I install and run guile first time, I get the following:
>
> laura:/> guile
> ;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0
> ;;; or pass the --no-autocompile argument to disable.
> ;;; compiling /usr/share/guile/1.9/ice-9/r5rs.scm
> ;;; compiling /usr/share/guile/1.9/system/base/compile.scm
It’s a sign that these files weren’t compiled when you built Guile.
Please run ‘make’ again in the build tree. This should create
module/ice-9/r5rs.go, etc., such that these won’t need to be
auto-compiled when Guile starts.
[...]
> Exception during displaying of backtrace: unbound-variable
>
> ERROR: In procedure module-lookup:
> ERROR: Unbound variable: compile-file
*This* is a real bug I guess. :-)
Thanks for your report,
Ludovic.