bug#32329: call-with-input-file and call-with-output-file should use textual ports
Hi Göran, Göran Weinholt writes: > the call-with-input-file and call-with-output-file procedures in (rnrs > io simple) should open textual ports. In Guile 2.2.4, they open binary > ports: > > (define (call-with-input-file filename proc) > (call-with-port (open-file-input-port filename) proc)) > > (define (call-with-output-file filename proc) > (call-with-port (open-file-output-port filename) proc)) > > Changing the inner calls to open-input-file and open-output-file is > sufficient to fix this bug. > > A consequence of using binary ports here is that the I/O is not > transcoded, so UTF-8 data is corrupted. Fixed in commit 4c91de3e45e7c98d5b7c484509fe5c59bd70f9fd on the 'stable-2.2' branch. Thanks! Mark
bug#32240: Segfault when execlp vim/nano
Hi, ouzb65ty writes: > When I call (execlp "vim") or (execlp "nano") in Guile : > Fatal error 11: Segmentation fault[1]31380 segmentation fault guile > test.scm When calling the 'exec*' procedures, in both Scheme and C, you should pass at least two arguments. The first argument is the program to run, and the second argument will become argv[0] in the executed program. Normally this should be the program name again, although in some cases it is useful to pass a different value as argv[0]. Note that in the Guile manual, the entry for 'execlp' begins by saying that it's "Similar to 'execl', however ...", and the description of 'execl' states: "If ARG is missing, FILENAME is executed with a null argument list, which may have system-dependent side-effects." On my GNU/Linux system, I see this: scheme@(guile-user)> (execlp "ls") A NULL argv[0] was passed through an exec system call. Aborted Based on your report, I guess that on Darwin it leads to a segfault. In any case, you are using 'execlp' incorrectly. It might be that we should raise an error at the Scheme level if these procedures are called with only one argument. Anyway, does it work if you run (execlp "vim" "vim") instead? Mark
bug#32254: Solaris 11.3 and missing GC_get_heap_usage_safe symbol
Hi Jeffrey, Jeffrey Walton writes: > I'm working on Solaris 11.3 with the 2.2.4 tarball. I'm trying to > build and test Guile. > > Make is not completing the build step: > > solaris2:guile-2.2.4$ make V=1 > make all-recursive > make[1]: Entering directory '/export/home/build/guile-2.2.4' > Making all in lib > make[2]: Entering directory '/export/home/build/guile-2.2.4/lib' > make all-recursive > make[3]: Entering directory '/export/home/build/guile-2.2.4/lib' > make[4]: Entering directory '/export/home/build/guile-2.2.4/lib' > make[4]: Nothing to be done for 'all-am'. > make[4]: Leaving directory '/export/home/build/guile-2.2.4/lib' > make[3]: Leaving directory '/export/home/build/guile-2.2.4/lib' > make[2]: Leaving directory '/export/home/build/guile-2.2.4/lib' > Making all in meta > make[2]: Entering directory '/export/home/build/guile-2.2.4/meta' > make[2]: Nothing to be done for 'all'. > make[2]: Leaving directory '/export/home/build/guile-2.2.4/meta' > Making all in libguile > make[2]: Entering directory '/export/home/build/guile-2.2.4/libguile' > make all-am > make[3]: Entering directory '/export/home/build/guile-2.2.4/libguile' > /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu11 > -I/usr/local/include -D_REENTRANT -pthreads -Wall -Wmissing-prototypes > -Wdeclaration-after-statement -Wpointer-arith -Wswitch-enum > -fno-strict-aliasing -fwrapv -fvisibility=hidden -g2 -O2 -m64 > -march=native -fPIC -I/usr/local/include -D_REENTRANT -pthreads > -L/usr/local/lib/64 -m64 -Wl,-R,/usr/local/lib/64 -o guile > guile-guile.o libguile-2.2.la -lsocket -lnsl -ldl -lpthread -lm > libtool: link: gcc -std=gnu11 -I/usr/local/include -D_REENTRANT > -pthreads -Wall -Wmissing-prototypes -Wdeclaration-after-statement > -Wpointer-arith -Wswitch-enum -fno-strict-aliasing -fwrapv > -fvisibility=hidden -g2 -O2 -m64 -march=native -fPIC > -I/usr/local/include -D_REENTRANT -pthreads -m64 -Wl,-R > -Wl,/usr/local/lib/64 -o .libs/guile guile-guile.o > -L/usr/local/lib/64 ./.libs/libguile-2.2.so -lbgc > /usr/local/lib/64/libffi.so /usr/local/lib/64/libunistring.so > /usr/local/lib/64/libiconv.so /usr/local/lib/64/libgmp.so -lltdl > -lsocket -lnsl -ldl -lpthread -lm -pthreads -R/usr/local/lib/64 > Undefined first referenced > symbol in file > GC_get_heap_usage_safe ./.libs/libguile-2.2.so > ld: fatal: symbol referencing errors > collect2: error: ld returned 1 exit status What version of the Boehm-Demers-Weiser garbage collector (BDW-GC a.k.a. libgc) are you linking with here? GC_get_heap_usage_safe has been part of BDW-GC's public API since version 7.2, which is the minimum version supported by Guile 2.2, as noted in our README. Guile's configure script attempts to verify that you have BDW-GC 7.2 or newer with the following code in configure.ac: # # # Boehm's GC library # # AC_MSG_CHECKING(for which bdw-gc pkg-config file to use) AC_ARG_WITH(bdw_gc, [ --with-bdw-gc=PKG name of BDW-GC pkg-config file], [bdw_gc="$withval"], [bdw_gc=bdw-gc]) AC_MSG_RESULT($bdw_gc) PKG_CHECK_MODULES([BDW_GC], [$bdw_gc >= 7.2]) However, if you don't have 'pkg-config' installed on your system, I guess this check will be skipped. Regards, Mark
bug#32279: activate-readline interaction with git
Hi Jelle, Jelle Licht writes: > Loading the (git) module after a call to (activate-readline) from > (ice-9 readline) stalls my repl, in most (9 out of 10) cases. The (git) module is not part of core Guile, and is not maintained by the Guile developers. Am I correct in guessing that it's part of the 'guile-git' project? If so, I suggest reporting the problem here: https://gitlab.com/guile-git/guile-git/issues I'd be glad to discuss the issue with the 'guile-git' developers, but I think the investigation will need to start with them, given that I have zero knowledge of 'guile-git' internals and wouldn't know where to begin looking for the source of this problem. Regards, Mark
bug#32160: auto compile fails to recompile when included source files change
Hi Arun, Arun Isaac writes: > Guile's auto compile fails to recompile when included source files > change. > > For example, I have two source files -- foo.scm and bar.scm. foo.scm > includes bar.scm using `include'. When I run foo.scm for the first time, > it is auto compiled and run correctly. But, if I modify bar.scm and run > foo.scm again, foo.scm is not rebuilt and the old version is run. Yes, this is a known limitation in Guile's auto-compilation support. Unfortunately, we don't have any system in place to track these dependencies between modules. Years ago, I spent some time thinking about how to do it, but it's nontrivial given the unstructured and imperative model by which modules load themselves and their dependencies. The .go file format would also need to be extended to embed the dependency information. There's also the question of how to fingerprint the dependencies. If timestamps are used, it would defeat deterministic builds, but if hashes are used, it might dramatically slow down module loading, especially given that it would not be sufficient to check the immediate dependencies: the full transitive closure of the module dependency graph would need to be traversed. And then there's the unfortunate fact that although circular module dependencies are (sensibly) prohibited by standard Scheme and most other languages, in Guile they are not prohibited, and although they cause a great many headaches, they sort-of-work if you are lucky, and Guix now depends heavily on them. Last I checked, Guix has a large number of package modules (well over 50, and possibly more than 100 at this point) that form a strongly connected component in the module dependency graph. I'm sorry that I don't have a better answer for you. If you'd like to investigate further, I'd be glad to give you pointers and advice, but it's not a project for the faint-hearted :-/ Regards, Mark
bug#32160: auto compile fails to recompile when included source files change
My response to Arun Isaac was rejected by his mail server: SMTP error from remote mail server after RCPT TO:: 550 Sender Policy Framework (SPF) verification failed I do not have DNS records supporting SPF for my domain netris.org, and apparently his mail server is configured to reject all mail that is not authenticated by SPF. So, I'm unable to send him email. Oh well. This is the first time I've run into this problem. If someone could let him know about this issue, I would be grateful. Mark
bug#32160: auto compile fails to recompile when included source files change
Mark H Weaver writes: > My response to Arun Isaac was rejected > by his mail server: [...] > If someone could let him know about this issue, I would be grateful. to...@tuxteam.de kindly forwarded my messages to Arun, so there's no need for anyone else to do it now. Thanks, Tomas! Mark
