Hi Janneke, On Wed 23 Feb 2011 12:54, Jan Nieuwenhuizen <janneke-l...@xs4all.nl> writes:
> This morning I've spend some time to reduce this problem into > a single scheme file, see attached. > > Again, here's what happens when I run it twice, starting from > a clean cache. > > First run > > 12:47:07 janneke@vuurvlieg:~/vc/schikkers-list > $ rm -rf ~/.cache/guile > 12:47:10 janneke@vuurvlieg:~/vc/schikkers-list > $ ./compile-cache-run-problem.scm > ;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0 > ;;; or pass the --no-autocompile argument to disable. > ;;; compiling ./compile-cache-run-problem.scm > ;;; compiled > /home/janneke/.cache/guile/ccache/2.0-0.T-LE-4/home/janneke/vc/schikkers-list/compile-cache-run-problem.scm.go > HALLO > 12:47:16 janneke@vuurvlieg:~/vc/schikkers-list > > Second run > > $ ./compile-cache-run-problem.scm > Backtrace: > In module/ice-9/boot-9.scm: > 170: 13 [catch #t #<catch-closure 86895a0> ...] > In unknown file: > ?: 12 [catch-closure] > In module/ice-9/boot-9.scm: > 62: 11 [call-with-prompt prompt0 ...] > In module/ice-9/eval.scm: > 389: 10 [eval # #] > In module/ice-9/boot-9.scm: > 1864: 9 [save-module-excursion #<procedure 8697c78 at > module/ice-9/boot-9.scm:1878:3 ()>] > 1172: 8 [load "./compile-cache-run-problem.scm" #f] > In unknown file: > ?: 7 [load-compiled/vm > "/home/janneke/.cache/guile/ccache/2.0-0.T-LE-4/home/janneke/vc/schikkers-list/compile-cache-run-problem.scm.go"] > In ./compile-cache-run-problem.scm: > 20: 6 [#<procedure 868a560 ()>] > In module/oop/goops.scm: > 1552: 5 [#<procedure 8afe820 at module/oop/goops.scm:1550:0 (class . > initargs)> #] > In unknown file: > ?: 4 [%initialize-object #<<notation> 8b01010> ()] > In module/oop/goops.scm: > 1552: 3 [#<procedure 8afe820 at module/oop/goops.scm:1550:0 (class . > initargs)> #] > In ./compile-cache-run-problem.scm: > 12: 2 [#<procedure 8b04e40 at ./compile-cache-run-problem.scm:10:0 (obj > . initargs)> # ...] > In module/ice-9/boot-9.scm: > 115: 1 [#<procedure 85fc4d8 at module/ice-9/boot-9.scm:110:6 (thrown-k . > args)> unbound-variable ...] > In unknown file: > ?: 0 [catch-closure unbound-variable "module-lookup" ...] > > ERROR: In procedure module-lookup: > ERROR: Unbound variable: for-each > [1]12:47:17 janneke@vuurvlieg:~/vc/schikkers-list > $ Guile now exhibits the second behavior only, and not the first behavior. I think the reason is that map and for-each are now implemented in Scheme, and thus not primitive generics, and srfi-1 doesn't turn them into generics any more. Since the duplicates-handler thing is actually a list or handlers, and you don't mention `last' in the list, no binding for `for-each' gets imported. I suspect the difference between first and second runs had to do with the interaction between srfi-1 and goops, combined with the loading-order bug that I fixed. Yuk, right? Strictly speaking this recent map / srfi-1 / goops change is incompatible. But, I hope you'll agree it's for the better; do let us know if you need some sort of compatibility shim. Andy -- http://wingolog.org/
