1.9 on the 19th; freeze 10 june (this wednesday)

1.9 on the 19th; freeze 10 june (this wednesday)

[Andy Wingo]

Hey folks,

After talking with Ludovic I think we're aiming for next friday for a
release, 19 june. In order to test thoroughly, I'd like to put Guile
master into "freeze mode" this Wednesday, 10 June.

What does that mean? It means, between 10 June and the 1.9.1 release, no
new code should go into Guile master. It is time to focus on testing.
Commits to fix regressions would be welcome, as would documentation.

If there are no objections, then let's settle on that.

One more thing, since time is running short: if there are people reading
this that package software for distributions, please package
libunistring, or poke the right person to do that. It will make
installing Guile easier. Thanks!

Andy
-- 
http://wingolog.org/

Re: 1.9 on the 19th; freeze 10 june (this wednesday)

[Ludovic Courtès]

Hi Andy,

I happen to have a very short time slot to do some testing...

Anyway, here's what "make check" tells me:

--8<---------------cut here---------------start------------->8---
FAIL: test-fast-slot-ref
;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-autocompile argument to disable.
;;; compiling /home/ludo/src/guile/module/srfi/srfi-1.scm
;;; compiling /home/ludo/src/guile/module/system/base/compile.scm
;;; it seems /home/ludo/src/guile/module/system/base/compile.scm
;;; is part of the compiler; skipping autocompilation

[...]

Backtrace:
In unknown file:
   ?: 17* [apply #<procedure resolve-interface (name739 . args738)> (#)]
   ?: 18  [resolve-interface (system repl command)]
    ...
   ?: 19  (let* ((module752 #)) (let* (#) (begin # #)))
   ?: 20* [resolve-module (system repl command)]
   ?: 21  (if (equal? name725 (quote (guile))) the-root-module723 ...)
    ...
   ?: 22  (begin (try-load-module name725) (resolve-module name725 #f))
   ?: 23* [try-load-module (system repl command)]
   ?: 24  [try-module-autoload (system repl command)]
    ...
   ?: 25  (begin (dynamic-wind (lambda () #) (lambda () #) (lambda () #)) didit815)
   ?: 26* [dynamic-wind #<procedure #f ()> #<procedure #f ()> #<procedure #f ()>]
   ?: 27* [#<procedure #f ()>]
   ?: 28* [with-fluid* #<fluid 7> #f #<procedure #f ()>]
   ?: 29* [#<procedure #f ()>]
   ?: 30* [save-module-excursion #<procedure #f ()>]
   ?: 31  (let (# #) (dynamic-wind # thunk654 #))
   ?: 32  [dynamic-wind #<procedure #f ()> #<procedure #f ()> #<procedure #f ()>]
   ?: 33* [#<procedure #f ()>]
   ?: 34* (begin (primitive-load-path # #f) (set! didit815 #t))
   ?: 35* [primitive-load-path "system/repl/command" #f]
In /home/ludo/src/guile/module/system/repl/command.scm:
 258: 36* [#<program 404a63f0 ()>]

<unnamed port>: In procedure module-lookup in expression (primitive-load-path (in-vicinity dir-hint813 name811) #f):
<unnamed port>: unbound variable: compile-file
guile --use-srfi=1,10 fails to run
FAIL: test-use-srfi

[...]

==================================
2 of 16 tests failed
Please report to bug-guile@gnu.org
==================================
--8<---------------cut here---------------end--------------->8---

`check-guile' complains as well.  The first time, it segfaulted (sorry,
I don't have enough time to reproduce it and gather more data right
now); the next times, it succeeds with zero failures (possibly a side
effect of having auto-compiled something?), but shows many errors such
as:

--8<---------------cut here---------------start------------->8---
ERROR: compiler.test: basic: compile to value - arguments: ((unbound-variable #f "Unbound variable: ~S" (compile) #f))

[...]

ERROR: tree-il.test: void: (void) - arguments: ((unbound-variable #f "Unbound variable: ~S" (compile) #f))
ERROR: tree-il.test: void: (begin (void) (const 1)) - arguments: ((unbound-variable #f "Unbound variable: ~S" (compile) #f))
ERROR: tree-il.test: void: (apply (primitive +) (void) (const 1)) - arguments: ((unbound-variable #f "Unbound variable: ~S" (compile) #f))
-8<---------------cut here---------------end--------------->8---

I re-run `check-guile' after removing `module/system/base/compile.go',
but it doesn't help.

Also:

--8<---------------cut here---------------start------------->8---
$ ./meta/guile
;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-autocompile argument to disable.
;;; compiling /home/ludo/src/guile/guile-readline/ice-9/readline.scm
;;; compiling /home/ludo/src/guile/module/system/base/compile.scm
;;; it seems /home/ludo/src/guile/module/system/base/compile.scm
;;; is part of the compiler; skipping autocompilation

[...]

;;; compiling /home/ludo/src/guile/module/language/objcode/spec.scm
;;; WARNING: compilation of /home/ludo/src/guile/module/language/objcode/spec.scm failed:
;;; key misc-error, throw args (#f "~A ~S" ("no such language" objcode) #f)
;;; compiling /home/ludo/src/guile/module/system/vm/objcode.scm
;;; WARNING: compilation of /home/ludo/src/guile/module/system/vm/objcode.scm failed:
;;; key misc-error, throw args (#f "~A ~S" ("no such language" objcode) #f)
;;; compiling /home/ludo/src/guile/module/language/scheme/spec.scm
;;; WARNING: compilation of /home/ludo/src/guile/module/language/scheme/spec.scm failed:
;;; key misc-error, throw args (#f "~A ~S" ("no such language" scheme) #f)

[...]

--8<---------------cut here---------------end--------------->8---

Again, this may be a simple bootstrapping issue.  Ideas?

Thanks,
Ludo'.

PS: Going on vacations now, so happy hacking!  ;-)

Re: 1.9 on the 19th; freeze 10 june (this wednesday)

[Andy Wingo]

On Sat 06 Jun 2009 16:16, ludo@gnu.org (Ludovic Courtès) writes:

> Hi Andy,
>
> I happen to have a very short time slot to do some testing...
>
> Anyway, here's what "make check" tells me:
>
> FAIL: test-fast-slot-ref
> ;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0
> ;;;       or pass the --no-autocompile argument to disable.
> ;;; compiling /home/ludo/src/guile/module/srfi/srfi-1.scm
> ;;; compiling /home/ludo/src/guile/module/system/base/compile.scm
> ;;; it seems /home/ludo/src/guile/module/system/base/compile.scm
> ;;; is part of the compiler; skipping autocompilation

This must mean you didn't run a `make' first. Is this the case? If so,
we should fix up our make rules to require a `make' first.

Andy
-- 
http://wingolog.org/

Re: 1.9 on the 19th; freeze 10 june (this wednesday)

[Andy Wingo]

On Sat 06 Jun 2009 16:16, ludo@gnu.org (Ludovic Courtès) writes:

> Again, this may be a simple bootstrapping issue.  Ideas?

Just thought of another thing: master Guile checks that .go mtime ==
.scm mtime, not just >=, and when it compiles is touches the .go
appropriately. But make checks >=. So perhaps you just need to make
clean && make to join the new mtime touching regime.

Enjoy your vacations :-) It is raining here!

A
-- 
http://wingolog.org/

Re: 1.9 on the 19th; freeze 10 june (this wednesday)

[Ken Raeburn]

On Jun 6, 2009, at 05:45, Andy Wingo wrote:
> Hey folks,
>
> After talking with Ludovic I think we're aiming for next friday for a
> release, 19 june. In order to test thoroughly, I'd like to put Guile
> master into "freeze mode" this Wednesday, 10 June.

I just tried building the guile-master-20090610 snapshot on my Mac and  
it failed.

* r6rs-ports.c needs to include "libguile/r6rs-ports.x", like the  
other source files do, instead of "r6rs-ports.x"

* There needs to be a SCM_API declaration of scm_cells_allocated, or  
it won't be exported from the library, and the test programs won't  
link.  I put one in gc.h and it seems to work.  The library sources  
apparently get compiled with -fvisibility=hidden, and SCM_API  
overrides that.  (Which makes me wonder why it isn't blowing up for  
everyone on other systems...)

* At least in test-suite/standalone the preprocessor options telling  
the compiler where to find Guile's headers seem to come after the  
configure-time CPPFLAGS.  This doesn't work out well if I need the  
latter to tell Guile where GNU MP is installed, but there's also a  
version of Guile installed there too.

/bin/sh ../../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H - 
I. -I../../../guile-master-20090610/test-suite/standalone -I../..   -I/ 
opt/local/include -I/Users/raeburn/dev/e/aae/g/hak/include -I../../../ 
guile-master-20090610/test-suite/standalone -I../../../guile- 
master-20090610 -I../.. -I../../../guile-master-20090610/lib -I../../ 
lib  -I/opt/local/include -I/Users/raeburn/dev/e/aae/g/hak/include - 
D_THREAD_SAFE  -Wall -Wmissing-prototypes -Werror -g -O2 -MT  
libtest_extensions_la-test-extensions-lib.lo -MD -MP -MF .deps/ 
libtest_extensions_la-test-extensions-lib.Tpo -c -o  
libtest_extensions_la-test-extensions-lib.lo `test -f 'test-extensions- 
lib.c' || echo '../../../guile-master-20090610/test-suite/ 
standalone/'`test-extensions-lib.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../../guile- 
master-20090610/test-suite/standalone -I../.. -I/opt/local/include -I/ 
Users/raeburn/dev/e/aae/g/hak/include -I../../../guile-master-20090610/ 
test-suite/standalone -I../../../guile-master-20090610 -I../.. - 
I../../../guile-master-20090610/lib -I../../lib -I/opt/local/include - 
I/Users/raeburn/dev/e/aae/g/hak/include -D_THREAD_SAFE -Wall -Wmissing- 
prototypes -Werror -g -O2 -MT libtest_extensions_la-test-extensions- 
lib.lo -MD -MP -MF .deps/libtest_extensions_la-test-extensions-lib.Tpo  
-c ../../../guile-master-20090610/test-suite/standalone/test- 
extensions-lib.c  -fno-common -DPIC -o .libs/libtest_extensions_la- 
test-extensions-lib.o
../../../guile-master-20090610/test-suite/standalone/test-extensions- 
lib.c: In function ‘libtest_extensions_init’:
../../../guile-master-20090610/test-suite/standalone/test-extensions- 
lib.c:42: error: ‘scm_t_extension_init_func’ undeclared (first use in  
this function)
../../../guile-master-20090610/test-suite/standalone/test-extensions- 
lib.c:42: error: (Each undeclared identifier is reported only once
../../../guile-master-20090610/test-suite/standalone/test-extensions- 
lib.c:42: error: for each function it appears in.)
../../../guile-master-20090610/test-suite/standalone/test-extensions- 
lib.c:42: error: syntax error before ‘libtest_extensions_init2’
make[4]: *** [libtest_extensions_la-test-extensions-lib.lo] Error 1

Here "-I/opt/local/include -I/Users/raeburn/dev/e/aae/g/hak/include"  
come from CPPFLAGS set at configure time (as per the configure script  
usage message), and ../guile-master-20090610 is the root of the  
sources relative to the root of the build tree.  Both GNU MP and Guile  
1.8.6 are installed in /opt/local; the "hak" tree is where I installed  
libunistring.  Using "-save-temps" and examining the resulting .i file  
shows that /opt/local/include/libguile.h is being included.

Ken

Re: 1.9 on the 19th; freeze 10 june (this wednesday)

[Andy Wingo]

Hi Ken,

On Thu 11 Jun 2009 04:13, Ken Raeburn <raeburn@raeburn.org> writes:

> On Jun 6, 2009, at 05:45, Andy Wingo wrote:
>
> * r6rs-ports.c needs to include "libguile/r6rs-ports.x", like the other
> source files do, instead of "r6rs-ports.x"

Neil seems to have fixed this one. Thanks for the report.

> * There needs to be a SCM_API declaration of scm_cells_allocated, or it
> won't be exported from the library, and the test programs won't  link.
> I put one in gc.h and it seems to work.  The library sources  apparently
> get compiled with -fvisibility=hidden, and SCM_API  overrides that.
> (Which makes me wonder why it isn't blowing up for  everyone on other
> systems...)

Which test programs are these? I don't see references to
scm_cells_allocated anywhere other than in gc.c. Perhaps this is related
to your next comment:

> * At least in test-suite/standalone the preprocessor options telling the
> compiler where to find Guile's headers seem to come after the
> configure-time CPPFLAGS.  This doesn't work out well if I need the
> latter to tell Guile where GNU MP is installed, but there's also a
> version of Guile installed there too.

It seems you hit http://thread.gmane.org/gmane.lisp.guile.bugs/3874 .

I guess we should fix this before the prerelease...

Regards,

Andy
-- 
http://wingolog.org/

Re: 1.9 on the 19th; freeze 10 june (this wednesday)

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> Hi Ken,
>
> On Thu 11 Jun 2009 04:13, Ken Raeburn <raeburn@raeburn.org> writes:
>> * At least in test-suite/standalone the preprocessor options telling the
>> compiler where to find Guile's headers seem to come after the
>> configure-time CPPFLAGS.  This doesn't work out well if I need the
>> latter to tell Guile where GNU MP is installed, but there's also a
>> version of Guile installed there too.
>
> It seems you hit http://thread.gmane.org/gmane.lisp.guile.bugs/3874 .
>
> I guess we should fix this before the prerelease...

Aha; given that this isn't a regression, I was going to do this
immediately after the prerelease; but I'm happy to squeeze it in
before if you think that's better.

I think what we need just is

- import of the Gnulib `havelib' module (actually we already import
  this indirectly, but now we need it directly)

- AC_LIB_LINKFLAGS(gmp) in configure.in

- update of the "Additional INSTALL instructions" section in README,
  to mention the --with-xxx-prefix configure options, and to point to
  the Gnulib doc on how these work (and how they sometimes don't).

Do you want to squeeze this in?

Regards,
        Neil

Re: 1.9 on the 19th; freeze 10 june (this wednesday)

[Andy Wingo]

Hi Neil,

On Sat 13 Jun 2009 15:51, Neil Jerram <neil@ossau.uklinux.net> writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> It seems you hit http://thread.gmane.org/gmane.lisp.guile.bugs/3874 .
>>
>> I guess we should fix this before the prerelease...
>
> Aha; given that this isn't a regression, I was going to do this
> immediately after the prerelease; but I'm happy to squeeze it in
> before if you think that's better.
>
> I think what we need just is
>
> - import of the Gnulib `havelib' module (actually we already import
>   this indirectly, but now we need it directly)
>
> - AC_LIB_LINKFLAGS(gmp) in configure.in
>
> - update of the "Additional INSTALL instructions" section in README,
>   to mention the --with-xxx-prefix configure options, and to point to
>   the Gnulib doc on how these work (and how they sometimes don't).
>
> Do you want to squeeze this in?

Well, given that we still have 6 days for people to test the snapshot
tarballs, and it seems to be well-tested code, and it has no impact on
existing use-cases that work... I'd be inclined to include it, yes.
(Man, I still net to get on that NEWS work. Tomorrow!)

Can you take care of it? I'd be happy to if you don't get around to it.

Cheers,

Andy
-- 
http://wingolog.org/

Re: 1.9 on the 19th; freeze 10 june (this wednesday)

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> Hi Neil,
>
> On Sat 13 Jun 2009 15:51, Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> I think what we need just is
>>
>> - import of the Gnulib `havelib' module (actually we already import
>>   this indirectly, but now we need it directly)
>>
>> - AC_LIB_LINKFLAGS(gmp) in configure.in
>>
>> - update of the "Additional INSTALL instructions" section in README,
>>   to mention the --with-xxx-prefix configure options, and to point to
>>   the Gnulib doc on how these work (and how they sometimes don't).
>>
>> Do you want to squeeze this in?
>
> Well, given that we still have 6 days for people to test the snapshot
> tarballs, and it seems to be well-tested code, and it has no impact on
> existing use-cases that work... I'd be inclined to include it, yes.
> (Man, I still net to get on that NEWS work. Tomorrow!)
>
> Can you take care of it? I'd be happy to if you don't get around to it.

Sure, should be possible during this weekend.

    Neil

Re: 1.9 on the 19th; freeze 10 june (this wednesday)

[Neil Jerram]

Neil Jerram <neil@ossau.uklinux.net> writes:

>>> I think what we need just is
>>>
>>> - import of the Gnulib `havelib' module (actually we already import
>>>   this indirectly, but now we need it directly)
>>>
>>> - AC_LIB_LINKFLAGS(gmp) in configure.in
>>>
>>> - update of the "Additional INSTALL instructions" section in README,
>>>   to mention the --with-xxx-prefix configure options, and to point to
>>>   the Gnulib doc on how these work (and how they sometimes don't).

I pushed a couple of commits:
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=39b94fee4304d56babf5bd62e10c5786a79f4389
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=a89cafc0562942680db63fe8ddf89f466ba2f7af

I don't feel totally sure about

-AC_CONFIG_AUX_DIR([.])
+AC_CONFIG_AUX_DIR([../build-aux])

because of crossing the implied boundary between the guile-readline
subdistro and the main guile distro; but it seems to work, and to be
consistent with how the Autoconf manual says AC_CONFIG_AUX_DIR should
be used.

And a few other queries:

- Should we have AC_LIB_LINKFLAGS(ltdl) too, to provide similar
  handling and searching for libltdl?

- Is the new README text correct that Guile depends on libiconv and
  libintl?  i.e. is it impossible for Guile to build without these?
  (If so, the "Required External Packages" section of README should be
  updated to mention these too.)

- Any comments on or improvements to the new README text?

Thanks,
     Neil

Re: 1.9 on the 19th; freeze 10 june (this wednesday)

[Ken Raeburn]

On Jun 13, 2009, at 09:16, Andy Wingo wrote:
> Hi Ken,
>
> On Thu 11 Jun 2009 04:13, Ken Raeburn <raeburn@raeburn.org> writes:
>
>> On Jun 6, 2009, at 05:45, Andy Wingo wrote:
>>
>> * r6rs-ports.c needs to include "libguile/r6rs-ports.x", like the  
>> other
>> source files do, instead of "r6rs-ports.x"
>
> Neil seems to have fixed this one. Thanks for the report.

Great, thanks.

>> * There needs to be a SCM_API declaration of scm_cells_allocated,  
>> or it
>> won't be exported from the library, and the test programs won't   
>> link.
>> I put one in gc.h and it seems to work.  The library sources   
>> apparently
>> get compiled with -fvisibility=hidden, and SCM_API  overrides that.
>> (Which makes me wonder why it isn't blowing up for  everyone on other
>> systems...)
>
> Which test programs are these? I don't see references to
> scm_cells_allocated anywhere other than in gc.c. Perhaps this is  
> related
> to your next comment:

I think you're right; the installed <libguile/inline.h> does refer to  
scm_cells_allocated, and the new one does not.  Sorry, I should've  
caught that after I discovered the header issue.

>> * At least in test-suite/standalone the preprocessor options  
>> telling the
>> compiler where to find Guile's headers seem to come after the
>> configure-time CPPFLAGS.  This doesn't work out well if I need the
>> latter to tell Guile where GNU MP is installed, but there's also a
>> version of Guile installed there too.
>
> It seems you hit http://thread.gmane.org/gmane.lisp.guile.bugs/3874 .
>
> I guess we should fix this before the prerelease...

Yeah... an easy way to chase it down might be to "poison" the  
installed headers so as to break anything that includes them (e.g.,  
with syntactic errors or #error directives), and try doing a build.

Ken