bug#13848: Statically linking guile-2.0.
Hi, Sorry for the delay. Jan Schukat shoo...@email.de skribis: ice-9/boot-9.scm:106:20: In procedure #procedure a434b00 at ice-9/boot-9.scm:97:6 (thrown-k . args): ice-9/boot-9.scm:106:20: In procedure dynamic-pointer: Symbol not found: scm_init_popen make[3]: *** [ice-9/popen.go] Error 1 I see: the (ice-9 popen) module depends on functionality that is missing when building with --disable-posix, so it cannot be built. This is a bug: Guile shouldn’t try to build ice-9/popen.scm when --disable-posix is used. Regarding file names on MinGW, Andy Wingo did a lot of work recently to integrate them correctly. This will be in Guile 2.0.8, but in the meantime could you try building Guile’s ‘stable-2.0’ branch from Git? git clone git://git.sv.gnu.org/guile.git git checkout stable-2.0 autoreconf -vfi ./configure make make check Thanks in advance, Ludo’.
bug#13848: Statically linking guile-2.0.
Ok, tried that on linux. autoreconf demanded automake 1.12, which isn't available via .debs on ubuntu yet, so I installed that from the sources. after that I get this error message: configure.ac:873: warning: macro 'AM_GNU_GETTEXT' not found in library autoreconf: running: /usr/bin/autoconf --force configure.ac:900: error: possibly undefined macro: AM_GNU_GETTEXT If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 I simply don't know enough about automake internals to even know where to begin to go about such errors. What library would such macros be defined in? And if I knew that, would I even want to do any changes there? Or is that generated from one of the dozens of scripts in the auto toolchain? I wouldn't even know where one might apply that m4_pattern_allow. What I can gather it could also just be a sign of a syntax error in the configure.ac. Regards Jan Schukat On 03/05/2013 11:22 AM, Ludovic Courtès wrote: Hi, Sorry for the delay. Jan Schukat shoo...@email.de skribis: ice-9/boot-9.scm:106:20: In procedure #procedure a434b00 at ice-9/boot-9.scm:97:6 (thrown-k . args): ice-9/boot-9.scm:106:20: In procedure dynamic-pointer: Symbol not found: scm_init_popen make[3]: *** [ice-9/popen.go] Error 1 I see: the (ice-9 popen) module depends on functionality that is missing when building with --disable-posix, so it cannot be built. This is a bug: Guile shouldn’t try to build ice-9/popen.scm when --disable-posix is used. Regarding file names on MinGW, Andy Wingo did a lot of work recently to integrate them correctly. This will be in Guile 2.0.8, but in the meantime could you try building Guile’s ‘stable-2.0’ branch from Git? git clone git://git.sv.gnu.org/guile.git git checkout stable-2.0 autoreconf -vfi ./configure make make check Thanks in advance, Ludo’.
bug#13848: Statically linking guile-2.0.
Jan Schukat shoo...@email.de skribis: autoreconf demanded automake 1.12, which isn't available via .debs on ubuntu yet, so I installed that from the sources. after that I get this error message: configure.ac:873: warning: macro 'AM_GNU_GETTEXT' not found in library autoreconf: running: /usr/bin/autoconf --force configure.ac:900: error: possibly undefined macro: AM_GNU_GETTEXT If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 You need to install the ‘gettext’ package and re-run autoreconf. Even easier: grab a tarball from http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest. Note that the reason I’m suggesting using the latest 2.0 is to fix file name problems on MinGW. So you can take the tarball from the above URL, and build from there on MinGW. Ludo’.
bug#11887: string-number edge cases
Hi Ian, On Mon 09 Jul 2012 14:29, Ian Price ianpric...@googlemail.com writes: PARSE ERROR (+InF.0 +inf.0 +inf.0 +Inf.0) = #f PARSE ERROR (-iNF.0 -inf.0 -inf.0 -Inf.0) = #f PARSE ERROR (+NAN.0 +nan.0 +nan.0 +NaN.0) = #f These are not errors. +NAN.0 is not even not a number :) PARSE ERROR (+nan.1 #f) = +nan.0 PARSE ERROR (+nan.01 #f) = +nan.0 These are only supported because 2.0.0 was released with +nan.1 parsing as +nan.0. It signals a deprecation warning with a note to this effect. Guile from master should pass these particular tests. PARSE ERROR (nan.0 #f) = +nan.0 PARSE ERROR (inf.0 #f) = +inf.0 PARSE ERROR (#e+nan.0 #f) = +nan.0 PARSE ERROR (#e+inf.0 #f) = +inf.0 PARSE ERROR (#e-inf.0 #f) = -inf.0 These are errors. If the number contains a division by zero, we get a numerical overflow error. scheme@(guile−user) (string-number 3/0) ERROR: In procedure string−number: ERROR: Throw to key `numerical−overflow' with args `(make−ratio Numerical overflow #f #f)'. This is also an error. We should plumb through some extra arg to mem2ureal, I guess, to check for a zero denominator. Andy -- http://wingolog.org/
bug#12202: psyntax defeats autoload
On Tue 14 Aug 2012 18:14, l...@gnu.org (Ludovic Courtès) writes: (define-module (foo) #:autoload (does-not-exist) (baz)) (define (chbouib) (baz)) (pk 'hello) Trying to evaluate it fails this way: $ guile --no-auto-compile t.scm Backtrace: In ice-9/boot-9.scm: [...] 292: 3 [get-global-definition-hook baz (hygiene foo)] In unknown file: ?: 2 [module-variable #directory (foo) b3b510 baz] In ice-9/boot-9.scm: 2732: 1 [b #autoload (does-not-exist) b3b3f0 baz #f] In unknown file: ?: 0 [scm-error misc-error #f ...] ERROR: In procedure scm-error: ERROR: missing interface for module (does-not-exist) ... which defeats the whole purpose of autoloads. What about something along these lines (untested)? This is a great idea. We should assume that autoloads are not macros. Not sure we can change it in 2.0 though, because there could be uses of autoloaded macros. However your patch won't work: diff --git a/module/ice-9/psyntax.scm b/module/ice-9/psyntax.scm index 6c264a6..8a30f82 100644 --- a/module/ice-9/psyntax.scm +++ b/module/ice-9/psyntax.scm @@ -289,15 +289,20 @@ (lambda (symbol module) (if (and (not module) (current-module)) (warn module system is booted, we should have a module symbol)) - (let ((v (module-variable (if module + (let ((m (if module (resolve-module (cdr module)) -(current-module)) -symbol))) + (current-module +(case (module-kind m) + ((autoload) + ;; don't try to actually load the module + #t) + (else + (let ((v (module-variable m symbol))) (and v (variable-bound? v) (let ((val (variable-ref v))) (and (macro? val) (macro-type val) (cons (macro-type val) - (macro-binding val) + (macro-binding val because the module-kind of the module will never be `autoload' here. As you can see in your backtrace, the module-kind is `directory' -- the autoload only ends up getting loaded while grovelling (foo)'s import array. Andy -- http://wingolog.org/
bug#11988: eval-case redefinition?
On Thu 19 Jul 2012 15:22, Daniel Llorens daniel.llor...@bluewin.ch writes: I was cleaning up an old script which goes like this: (define (eval-case ...) ... val) (define var (eval-case ...)) This worked from the REPL, but when loading the file with (load script), var was always #unspecified. It turns out that (my) eval-case is never executed in this case. I wonder if this is related to bug 13865. I tried a script with these contents: (define (eval-case val) val) (define var (eval-case 2)) And I can reproduce the bug with stable-2.0. `master' seems to have the right behavior however. If I had to guess I would think that this was fixed by the following commit on `master': commit 19ef14f9b8b73c04acbbfa6bd993908171bc69f7 Author: Andy Wingo wi...@pobox.com Date: Fri Nov 4 19:37:04 2011 +0100 defined identifiers scoped in the current module * ice-9/psyntax.scm (chi-top-sequence): Wrap defined identifiers with the current module. Fixes http://savannah.gnu.org/bugs/?31472. Or one of the commits around it that has to do with toplevel bindings. Tough to tell, as that code is significantly different in master as compared to stable-2.0. Andy -- http://wingolog.org/
bug#12808: segfault with (weird use of) make-struct and make-vtable
On Mon 05 Nov 2012 22:24, Areth Unknown unknown.ar...@gmail.com writes: This code makes guile segfault, tested in the versions 2.0.6.49 and 2.0.6.66 .. (define v-blocks (make-vtable pR)) ;; note that this is a protected tail array read-only (define block-2 (make-struct v-blocks 1 ;; note that this only has one element '((0 2 2 0) (0 2 2 0) (0 0 0 0) (0 0 0 0 ;; (struct-ref block-2 0) ;; = Segmentation fault (core dumped) -- Thanks for the report; will be fixed in 2.0.8. Andy -- http://wingolog.org/
bug#12929: case-lambda*
On Mon 19 Nov 2012 11:38, Daniel Llorens d...@jast.ch writes: http://lists.gnu.org/archive/html/guile-user/2012-11/msg00032.html Fixed, with notes in that thread. Thanks again for the report! Andy -- http://wingolog.org/
bug#10790: [bug-guile] guile-2.0.5 test fails on Solaris x86/x86_64
Hi,
For some reason this mail went just to me instead of to the bug also.
For that reason I'm top-quoting all of it. Anyway, we have had a couple
releases since this report, with lots of fixes. Please open a new bug
for new build errors. Thanks!
Andy
On Sat 07 Jul 2012 23:51, Nelson H. F. Beebe be...@math.utah.edu writes:
OK, I got the guile-2.0.5.220-5f8d bundle via the
http://hydra.nixos.org/jobset/gnu/guile-2-0
links yesterday, and got builds going. I didn't have time to complete
a report before I had to leave for the day.
On Solaris 11 x86_64 with guile-2.0.5, I had reported this test
failure:
make[5]: Entering directory
`/local/build/bare/guile-2.0.5/test-suite/standalone'
Assertion failed: SCM_I_IS_THREAD (data.thread), file threads.c, line
1135
/bin/sh: line 10: 24532: Abort
FAIL: test-system-cmds
In yesterday's build, I got this:
PASS: test-system-cmds
...
===
All 29 tests passed
===
...
Running time.test
FAIL: time.test: strftime: C99 %z format: EST+5
Totals for this test run:
passes: 34066
failures: 421
unexpected passes: 0
expected failures: 30
unresolved test cases: 558
untested test cases:1
unsupported test cases: 11
errors: 2
FAIL: check-guile
==
1 of 1 test failed
Please report to bug-guile@gnu.org
==
That is a pretty impressive pass guile tests!
I only tried the guile-2.0.5.220-5f8d builds on Solaris 10 and 11
x86_64 and x86 systems because time is very tight. I have three
upcoming trips, and next Saturday is departure day.
On Solaris 10, I still get the old error:
Assertion failed: SCM_I_IS_THREAD (data.thread), file threads.c, line
1138
/bin/bash: line 5: 26626 Abort (core dumped)
srcdir=. builddir=.
CHARSETALIASDIR=/local/build/bare/guile-2.0.5.220-5f8d/lib
GUILE_AUTO_COMPILE=0 ../../meta/uninstalled-env
${dir}$tst
FAIL: test-system-cmds
plus these
FAIL: gc.test: gc: Lexical vars are collectable
...
Running numbers.test
/bin/bash: line 5: 29826 Segmentation Fault (core dumped)
CHARSETALIASDIR=/local/build/bare/guile-2.0.5.220-5f8d/lib ${dir}$tst
FAIL: check-guile
These could well all be compiler issues, but as I reported earlier,
there is not much to choose from on Solaris Intel systems, with only a
native Sun/Oracle compiler release, plus a rather old gcc release. I
keep trying to get gcc-4.x (x = a great many) versions to build and
install, but so far, only gcc-4.2.4 mostly completed successfully
(5-Nov-2010). Since rms left the gcc project several years ago, gcc
compiler portability has gone down the tubes, sigh..., and the
compiler families have grown hugely.
I think that we should consider the guile build issue closed for
Solaris 11 x86_64. As new guile releases appear, I'll continue to do
builds, but I won't have much time until November, or later.
---
- Nelson H. F. BeebeTel: +1 801 581 5254
-
- University of UtahFAX: +1 801 581 4148
-
- Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu
-
- 155 S 1400 E RM 233 be...@acm.org be...@computer.org
-
- Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/
-
---
--
http://wingolog.org/
bug#11887: string-number edge cases
Andy Wingo wi...@pobox.com writes: On Mon 09 Jul 2012 14:29, Ian Price ianpric...@googlemail.com writes: If the number contains a division by zero, we get a numerical overflow error. scheme@(guile−user) (string-number 3/0) ERROR: In procedure string−number: ERROR: Throw to key `numerical−overflow' with args `(make−ratio Numerical overflow #f #f)'. This is also an error. We should plumb through some extra arg to mem2ureal, I guess, to check for a zero denominator. FYI, I produced a simple patch a while back to fix this (see below), but it had an interesting side effect: it caused the reader to read things like 3/0 and 4+3/0i as symbols. More generally, anything for which 'scm_string_to_number' returns false is treated as a symbol by 'read'. I'm not sure how I feel about this. What do you think? Mark diff --git a/libguile/numbers.c b/libguile/numbers.c index 66c95db..9013f0c 100644 --- a/libguile/numbers.c +++ b/libguile/numbers.c @@ -5809,7 +5809,7 @@ mem2ureal (SCM mem, unsigned int *p_idx, return SCM_BOOL_F; divisor = mem2uinteger (mem, idx, radix, implicit_x); - if (scm_is_false (divisor)) + if (scm_is_false (divisor) || scm_is_eq (divisor, SCM_INUM0)) return SCM_BOOL_F; /* both are int/big here, I assume */
bug#10519: guile and (mini-)gmp
Hello all, I wrote: I'm embarrassed to admit that the integration of mini-gmp into guile has long been waiting on my pending numerics patches. I'll try to get going on this (and some other things) for the 2.0.8 release. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10519#8 I've posted a new set of patches for stable-2.0 to guile-devel: http://lists.gnu.org/archive/html/guile-devel/2013-03/msg00011.html This patch set eliminates the known obstacles to integration of mini-gmp. Regards, Mark
bug#12216: peek-char incorrectly *CONSUMES* eof
I reported: Guile's peek-char has a bug; it incorrectly *consumes* eof instead of just reporting it. Andy Wingo replied: I have the feeling that for interactive use, if you expect to read a EOF from a port and then continue, you have to not use peek-char. You need to handle your own lookahead buffer. I know it's not a great answer, but I can't think of anything else that makes sense. We don't want to read an EOF and then continue. We peek-char to not *CONSUME* an interactive EOF. Once peek-char returns EOF, every following peek-char should *also* return EOF until the EOF is read. That isn't what currently happens. E.G.: (define (demo) (write (peek-char)) (write (peek-char))) (demo) ; Now type control-D ENTER. ; It SHOULD produce #eof twice, after peeking EOF, ; but instead it produces #eof #\newline #eof#eofguile (demo) --- David A. Wheeler
bug#11887: string-number edge cases
I think this isn't working as it should either.
scheme@(guile-user) +1i
$1 = 0.0+1.0i
scheme@(guile-user) 1i
;;; unknown-location: warning: possibly unbound variable `#{1i}#'
ERROR: In procedure #procedure 101d6d4a0 ():
ERROR: In procedure module-lookup: Unbound variable: #{1i}#
bug#12887: Broken pipe while generating guile-procedures.texi
Andy Wingo wi...@pobox.com skribis: On Fri 07 Dec 2012 22:59, l...@gnu.org (Ludovic Courtès) writes: Ooh, I see. This is related to commit ed4c3739 (see http://lists.gnu.org/archive/html/guile-devel/2011-12/msg00160.html). What happens is that the directory name may be correctly decoded when passed as an argument: [ludo@pluto:~/tmp/Courtès]$ strace -f -o ,,s ~/src/guile/meta/guile -L $PWD -c '(set-port-encoding! (current-output-port) UTF-8)(pk %load-path)' ;;; ((/home/ludo/tmp/Courtès ...)) But then ‘scm_stat’ calls ‘scm_to_locale_string’, which uses the wrong encoding at this point [...] Nice debugging for a nasty problem. So, as mentioned in the thread above, 2.2 will not have this problem. But for 2.0, I can’t even imagine an ugly hack that would help. Thoughts? What about an environment variable that can tell Guile to do the setlocale(). We can set the environment variable during the build so that at least the build works, and whisper it to users when they run into problems (while noting that the variable will not be read in 2.2). Yes, sounds like a plan. ‘GUILE_INSTALL_LOCALE’? Or should we go ahead and document it, and simply have its default value change between 2.0 and 2.2? Yes, even better, since the setlocale change will have to be documented at least in NEWS anyway. Are you willing to look into it? Ludo’.
bug#13848: Statically linking guile-2.0.
Gettext was installed. Actually I don't know any linux distributions where it isn't installed by default. On mingw the latest source snapshot tarball (after taking care of the struct timespec trouble) ends in a compilation error on I can't really make any sense off: SNARF numbers.x numbers.c:7643:5: error: missing binary operator before token ( Seems to be another I'll handled pre-processor guard. So for now I just get some of my actual work done under linux with the normal 2.0.7 tarball and my mentioned changes and wait for 2.0.8. Then I'll try again and will find some new and some of the same old problems again and go from there and probably write again. And then I'm probably gonna wait for the 2.0.9 tarball with some new and some old problems, and write again. Regards Jan Schukat On 03/05/2013 06:25 PM, Ludovic Courtès wrote: Jan Schukatshoo...@email.de skribis: autoreconf demanded automake 1.12, which isn't available via .debs on ubuntu yet, so I installed that from the sources. after that I get this error message: configure.ac:873: warning: macro 'AM_GNU_GETTEXT' not found in library autoreconf: running: /usr/bin/autoconf --force configure.ac:900: error: possibly undefined macro: AM_GNU_GETTEXT If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 You need to install the ‘gettext’ package and re-run autoreconf. Even easier: grab a tarball from http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest. Note that the reason I’m suggesting using the latest 2.0 is to fix file name problems on MinGW. So you can take the tarball from the above URL, and build from there on MinGW. Ludo’.
bug#11887: string-number edge cases
On Tue, Mar 05, 2013 at 03:49:13PM +0100, Andy Wingo wrote: Hi Ian, On Mon 09 Jul 2012 14:29, Ian Price ianpric...@googlemail.com writes: PARSE ERROR (+InF.0 +inf.0 +inf.0 +Inf.0) = #f PARSE ERROR (-iNF.0 -inf.0 -inf.0 -Inf.0) = #f PARSE ERROR (+NAN.0 +nan.0 +nan.0 +NaN.0) = #f These are not errors. +NAN.0 is not even not a number :) I double-checked, but in the upcoming R7RS it is (see 7.1, paragraph 2 of draft 7). It looks like R6RS was case-sensitive in its numerical syntax and +NAN.0 is disallowed by it. Cheers, Peter -- http://www.more-magic.net
bug#11887: string-number edge cases
On Tue, Mar 05, 2013 at 02:04:55PM -0500, Mark H Weaver wrote: FYI, I produced a simple patch a while back to fix this (see below), but it had an interesting side effect: it caused the reader to read things like 3/0 and 4+3/0i as symbols. More generally, anything for which 'scm_string_to_number' returns false is treated as a symbol by 'read'. I think this is simple and at least internally consistent. Several Schemes assume something like 1/0 is a symbol; Chicken does this as well, with the numbers egg loaded, so does Gambit. Raising an error is also acceptable. According to the lexical syntax 1/0 *is* a valid number, so you could argue that it *must* parse as a number, which is impossible so an error should occur. This is also related to how string-number deals with it; if it returns #f it is essentially saying this is not valid numerical syntax and should fail to parse as a number. Not raising an exception on (string-number 1/0) but raising an exception on (with-input-from-string 1/0 read) is a bit odd, I'd say. Cheers, Peter -- http://www.more-magic.net
bug#12892: ‘gc-stats’ w/o ‘bytes-malloced’
On Wed 06 Mar 2013 06:51, Thien-Thi Nguyen t...@gnuvola.org writes: What is the meaning of this field? It's a copy of the C global var ‘scm_mallocated’, which tracks current allocation (all malloced minus all freed). There is no such C global var. We could track total allocations registered via scm_gc_register_allocation. Sounds complicated. On the contrary, this function is called already for mallocations. Andy -- http://wingolog.org/
