<civodul>mark_weaver: finally posted that message about CBIPs <civodul>well, we kind of knew that, but still :-) <ArneBab>dsmith-work: don’t they see that they are breaking existing code? <ArneBab>mark_weaver: did you already test my documentation-fix? <kurohin>is there any example on how to use the scm_with_guile and usa a lambda as the function argument, can it be done? <zRecursive>After `git clone git://git.sv.gnu.org/guile.git`, `./autogen` reports "m4: illegal option -- - \\n usage: m4 [-d flags] [-t name] [-gs] [-D name[=value]]...\\n [-U name]... [-I dirname]... file..." on FreeBSD 9.1 <mark_weaver>However, I'm not sure that the GNU autotools are designed to work with other version of m4. <mark_weaver>you don't need autotools or m4 at all when compiling from a tarball release. <mark_weaver>but if you compile from git, you need fairly recent GNU autotools, and possibly also GNU m4. <mark_weaver>but this is civodul's area of expertise, so I'll let him respond further. <mark_weaver>zRecursive: do you have GNU m4 on your system? I notice that autogen.sh will honor the M4 environment variable, which sould point to the m4 command you want to use. <mark_weaver>zRecursive: the other thing you could try is just running "autoreconf -i --force --verbose", which is the only thing autogen.sh does other than print a bunch of version numbers. it might simply be the "m4 --version" command that your m4 doesn't like. <zRecursive>mark_weaver: `whereis m4` => m4: /usr/bin/m4 /usr/src/usr.bin/m4 <mark_weaver>okay. you may still have problems when you run ./configure. <mark_weaver>btw, I'm pretty sure you need at least automake 1.12 <zRecursive>After `pkg install automake-1.14`, `autogen` still reports same error. Now `autoreconf -i --force --verbose` ... <mark_weaver>btw, fwiw, you might be happier on the stable-2.0 branch for now. master is not yet ABI stable, and also has some missing features in its new VM/compiler implementation, like debugging. <mark_weaver>the lack of ABI stability means that we might change something that requires that you recompile all your scheme code as well as any libraries linked against libguile. <zRecursive>`coonfigure` reports "Package 'bdw-gc' has version '7.1', required version is '>= 7.2'", what is bdw-gc ? `pkg search bdw-gc` doesnot find it. <mark_weaver>actually, there's 7.2e now, which is surely preferable. <zRecursive>it is boehm-gc-7.2e in freebsd repo. upgrade now <mark_weaver>I'm not sure that recent master (since the new VM) has yet been tested on FreeBSD, so you're blazing a trail here. <zRecursive>mark_weaver: no problem. i have guile-1.8.8 here <mark_weaver>btw, beware that it takes a long time to bootstrap guile, because initially the compiler is being interpreted while compiling itself. <zRecursive>error ! ./.libs/libguile-2.2.so: undefined reference to `GC_unregister_my_thread' <zRecursive>`GC_get_suspend_signal', `GC_allow_register_threads',`GC_register_my_thread' ... <mark_weaver>it sounds like your boehm-gc doesn't have thread support. <mark_weaver>either you need to configure guile --without-threads, or install a boehm GC with threading support. <mark_weaver>I seem to recall that FreeBSD has multiple packages for GC, with and without threading. <mark_weaver>if you switch your boehm gc, make sure to rerun configure and make clean. <mark_weaver>by default, Guile's configure finds out the needed CFLAGS and LDFLAGS for libgc using: pkg-config --cflags "bdw-gc >= 7.2" <mark_weaver>if that does the wrong thing on your system, then you can pass the BDW_GC_LIBS and BDW_GC_CFLAGS variables to configure <zRecursive>`pkg-config --cflags "bdw-gc >= 7.2"` => -I/usr/local/include <mark_weaver>well, I have no idea where FreeBSD put boehm-gc-threaded, so I have no idea whether that's right or not. <mark_weaver>on GNU/Linux systems, the pkg-config configuration files are in /usr/lib/pkgconfig/ <mark_weaver>for you, maybe it's in /usr/local/lib/pkgconfig, I don't know. <mark_weaver>can you see the list files that make up the boehm-gc-threaded package? where's the .pc file? <mark_weaver>zRecursive: also, did you rerun configure and 'make clean', like I suggested? <zRecursive>boehm-gc-threaded depends boehm-gc, so i canot remove boehm-gc <mark_weaver>normally, to link against Boehm GC, you just need -lgc. but I have a feeling that FreeBSD gave a nonstandard name to the threaded version. <zRecursive>it is /usr/local/lib/libgc-threaded.so -> libgc-threaded.so.1 <mark_weaver>okay, so you probably need to pass BDW_GC_LIBS="-L/usr/local/lib -lgc-threaded" to configure. <mark_weaver>and you might also need BDW_GC_CFLAGS="-I/usr/local/include", but that's just a guess. <mark_weaver>and it's probably a good idea to "make clean" after rerunning configure with new flags. <zRecursive>`./configure BDW_GC_LIBS="-L/usr/local/lib -lgc-threaded"` seems work <zRecursive>Anyway it is not a happy thing to build Guile from source :) <zRecursive>`pkg install guile` is good however repo. is too old <mark_weaver>it would be good if someone would submit a new build recipe for freebsd. <mark_weaver>maybe they include more precompiled code than we do. <mark_weaver>we actually bootstrap from source code, which many self-hosted compilers don't do these days. <mark_weaver>I suppose we could distribute a set of precompiled .go files. <nalaginrut>actually, several bugs, now tekuti supports Chinese well ;-) <ijp>wingo? I thought you ran off with the circus, or something <ft>The circus might have wifi, though. <ijp>certainly I planned to, but apparently they have ample stock of lion food <wingo>i ran off with the circus, yes <ijp>utah seems to be accumulating quite a bunch of schemers <wingo>dunno, that paper is by andrew keep <ijp>who is also apparently at utah ***linas__ is now known as linas
<mark_weaver>civodul: any update on fixing hydra.nixos.org for guile stable-2.0? <civodul>mark_weaver: i actually fixed it, i swear! <mark_weaver>civodul: I think you fixed the problem on guile-master, but not this one. <mark_weaver>the error is the same as it was before: while trying to checkout the git branch, local changes to files would be overwritten. <civodul>i fixed the Nix language errors, and reported a problem like this one <mark_weaver>does "guild list" work for people? there's a bug report for guile 2.0.9 on debian that claims that it lists no commands, even though the commands actually work when used. <mark_weaver>"guild list" works for me, but then I have compiled guile from source code on all my machines. <civodul>mark_weaver: i think the guildhall breaks it somehow <civodul>for me it breaks in In guildhall/spells/pathname.scm <civodul>with: rnrs/arithmetic/fixnums.scm:224:2: ERROR: R6RS exception <mark_weaver>that's very strange. I don't understand why "guild list" would be running any code from guildhall. <dsmith-work>Yes. (compile, disassemble, display-commentary, doc-snarf, help, use2dot) <mark_weaver>oh, I see. it does run code from each module. of course. <mark_weaver>well, I have guildhall installed, and it still works for me. It would be good to find out what's going wrong there. <mark_weaver>I've fixed some fixnum bugs since 2.0.9, maybe related. *taylanub is greatly puzzled by the most recent bugreport on the ML, re. string-match unbound error in Guile Unix script. <mark_weaver>he needed to import (ice-9 regex), which for some reason is loaded by default at the REPL (not sure why). <mark_weaver>actually, I'm curious where those extra REPL modules are being loaded from. does anyone here know off-hand? <civodul>np, thanks to ikwildrpepper of NixOS <bu^>hi there, CG_MARKERS=1 solved my issue with gc 7.4.0 now building is ok, took less than 25 mins