***linas__ is now known as linas
*nalaginrut is loving vlist these days... <amoe>what's the recommended way to write unit tests for guile code? <Madsy>Where is mark_weaver when you need him <Madsy>Going to compile the latest guile snapshot for Windows as soon as mark gets here <Madsy>cluck: Are you one of the guile developers? <cluck>if there's something you have guile related questions just ask, someone will answer when they get the chance <Madsy>cluck: Yeah I'm waiting for mark_weaver. Going to build guile for him, for Windows <Madsy>I just wondered what snapshot to use <civodul>you can start building right now, no need to wait for mark ;-) <Madsy>civodul: That's the one I'm building right now <Madsy>civodul: I just wanted to ask mark to make sure I built the right release <civodul>Madsy: yeah the point was to make sure the latest 2.0 works fine for Windows <civodul>so if you grabbed the tarball just now, that's perfect <Madsy>civodul: I have a feature request to make. Either revamp the doc snarfing, or improve the existing doc snarfing tools. For example, guile_filter_doc_snarfage expects the other scripts to be in the same directory it seems. <Madsy>Also an individual makefiles (or make target) for the snarf tools would be great <Madsy>And maybe install them into $PREFIX/bin <Madsy>Right now if I want my application to be portable with docstring generation, I have to yank out the .c files for the tools from guile and compile them myself as a prebuild step <Madsy>And I assume I have release all my source then, as opposed to be able to use LGPL <civodul>but yeah, the snarfing stuff needs love <Madsy>Yeah, I'm considering it. I just suck at the autoconf stuff. <Madsy>The fixes to the tools/scripts are easy enough <civodul>actually i think we should distribute Guile modules, not C/Awk files, for that job <Madsy>You mean, use guile itself for doc snarfing? <Madsy>Sounds like a chicken-and-egg problem. Doc snarfing is required to build most of the guile modules. <Madsy>Which is inside guile itself <Madsy>But how can it use guile, if it also requires guile to run? Seems to me you have to build guile first without docstrings then <Madsy>And then rebuild it with docstrings while calling the guile bootstrap <civodul>we already do that, see libguile/texi-fragments-to-docstrings <Madsy>Yeah I remember that you need to run guile in the build to at least compile the modules <Madsy>That gave me some pain when cross-compiling <Madsy>I had to build the same version of guile locally, so I could use the local version to compile the modules <cluck>racket's got some fancy doc now, i'm sort of jealous :| <Madsy>civodul: I got a compile error when building now. Perhaps you can help? <Madsy>Oh.. wait. It gets includes from the wrong directory? <Madsy>Something in the build system has changed between guile-2.0.9.182-c8e83-dirty and guile-2.0.9.219-e1bb-dirty <civodul>make sure you use the latest, which is v2.0.9-219-ge1bb79f <Madsy>civodul: Do I have to get that from git? <Madsy>I can't find that version on hydra <civodul>Madsy: you should be able to get it from the hydra link above <Madsy>But I don't see ge1bb79f there ***linas_ is now known as linas
<Madsy>Ah, it was the one I used. I got confused because the file name didn't contain the whole hash you mentioned <nalaginrut>I posted a blog for building blog with tekuti ;-) <nalaginrut>I posted a blog for building blog with tekuti ;-) <ft>hm, no guile 2.0 packages for any of the three major BSDs? <Madsy>Hm, I found a bug, but I'm not entirely sure what caused it <Madsy>civodul: Is it correct that c-tokenize.c should include config.h? c-tokenize.c is compiled with the host's own compiler, even when cross-compiling, since it's a tool used by the build process. <Madsy>mark_weaver: I'm building the latest snapshot now. But I ran into what I think is a bug <Madsy>c-tokenize.c is one of the programs that's used by the doc snarfing, right? So it is always built natively <civodul>Madsy: the config.h is fixed in current stable-2.0 <Madsy>Anyways, so c-tokensize.c includes <config.h> configured for a cross build when c-tokenize.c is being built natively. <Madsy>What do you mean? Do I need another snapshot? <mark_weaver>civodul: this must be a different problem, because e1bb is fresh <civodul>mark_weaver: normally the tarball includes c-tokenize.c, so it's easy to check if it #include <config.h> first or not <Madsy>Here's the rub: c-tokenized.c includes <config.h>. config.h #defines gid_t, nlink_t, uid_t to ints but without defining the guards. So when c-tokenized.h also includes <stdlib.h>, "typedef __gid_t gid_t" fails because it becomes "typedef __gid_t int" <mark_weaver>civodul: I just pulled, and e1bb79f is the latest stable-2.0: "build: Make c-tokenize.c build on non-GNU systems." <civodul>Madsy: yes, but can you check whether #include <config.h> is the first line? <Madsy>civodul: Yes, it is. Right after a #line statement <Madsy>So, what's the quick fix? Remove the config.h include? <ft>Is my libgc too old, if I get "undefined reference" for GC_unregister_my_thread, GC_pthread_create, GC_register_my_thread and GC_pthread_detach when linking the guile binary? <Madsy>ft: Which version of guile are you building? <Madsy>And which version of libgc do you have? <ft>Madsy: It's the current HEAD from "stable-2.0" and boehm-gc-7.2e. All of this on NetBSD. <civodul>Madsy: so the problem is: /usr/include/x86_64-linux-gnu/sys/types.h:65:17: error: two or more data types in declaration specifiers right? <Madsy>Because of "typedef __some_type_t int" <Madsy>ft: libgc 7.2 is definitely not too old <ft>That's what I thought. Hm. <Madsy>ft: Are you cross-compiling? Or have you built a static version of libgc? <mark_weaver>ft: you need the "boehm-gc-threaded" package, and pass BDW_GC_LIBS="-L/usr/local/lib -lgc-threaded" to configure <ft>Madsy: I'm using NetBSD's package for libgc, and I can see a shared version of the library. <mark_weaver>ft: you might also as zacts, who has made new freebsd ports recipes for boehm-gc and a recent guile snapshot. <ft>mark_weaver: Ah, I didn't know about -lgc-threaded. I'll try that. Thanks. :) <ft>Could be that the NetBSD package of the library doesn't include a libgc-threaded library. Because I don't see such a file. <civodul>actually, it doesn't make much sense to include <config.h> here when cross-compiling <Madsy>civodul: Yes. And yes, that's what I said <Madsy>So I did a quickfix by simply commenting out the include <mark_weaver>civodul: and yet the build on darwin failed because 'config.h' wasn't included early enough, and one of the gnulib header files complained. <Madsy>My suggestion is to add proper guards for the #define type definitions in config.h, so they don't collide with stdlib.h <mark_weaver>civodul: "Javascript is required for ZeroBin to work." :-( <mark_weaver>thanks. I'm not set up to do a cross-compile test, but maybe Madsy can try it. <dje42>Not that you want to take it this far, but gcc handles this by running autoconf twice, once for host and once again for build (when host != build). <Madsy>civodul: I'll test the patch a bit later. First I want to see if the snapshot works at all <dje42>[well, s/autoconf/configure/ to be more precise] <Madsy>Is there a reason behind guile installing itself in both /bin and /root ? <mark_weaver>guile installed itself in /root ? I've never seen or heard of that before. <mark_weaver>is that coming from one of your flags passed to configure? <Madsy>I just passed --prefix=/home/madsy/mingw. It installed itself in mingw/bin, mingw/share and mingw/root <mark_weaver>I don't know where that "root" is coming from, but searching for it in the tree is like looking for a needle in a haystack. <Madsy>mark_weaver: I'll run the testsuite now for 2.0.9.219-e1bb-dirty <mark_weaver>sounds good. it might be easier now, because (I hope) that many more posix interfaces will work on mingw <mark_weaver>for example, you might not need to pass the list of tests to run explicitly. it might be able to iterate the directory itself now, and the ./check-guile script might work. <Madsy>mark_weaver: There are still some tests that are started in the testsuite that don't exist <Madsy>test-suite/tests/compiler.test <mark_weaver>Madsy: what do you mean by "don't exist"? you mean it tried to load a file that wasn't there? <Madsy>The same tests that were missing last time are still missing <Madsy>See the ones I marked "primitive-load-path: Unable to find file" <Madsy>I assume the issues with open-file is for the same reason <mark_weaver>so, a big chunk of our test suite has never been included in any tarball, and we never noticed until now. <mark_weaver>if not for the fact that I had to send you the list of tests to run, we might not have noticed for a while. <Madsy>I *did* tell you last time, but you were busy when I did :) <Madsy>mark_weaver: A quick thing you might fix with Windows is that guile crashes if it fails to find a legal load path <mark_weaver>how does it crash? what load path did you try, and how did you specify it? <Madsy>It works fine if I set the influential environment variables of course. But if not specified at all, the program simply crashes hard <Madsy>I might be able to run it in gdb from MSYS. But you'll have to wait for me to do a rebuild <Madsy>I didn't compile it with debugging information <mark_weaver>(I'm not sure if it would provide enough clues for me to guess the problem) <Madsy>That's the problem. Guile crashes before I get a REPL at all <Madsy>But I can probably get you a gdb backtrace <Madsy>Also, I wonder if the load paths can be relative to the guile binary directory? <Madsy>For example: "../share/guile/2.0/ccache" <Madsy>Eventually I really need to be able to set a relative loadpath somehow <Madsy>The directory guile.exe is in <mark_weaver>for now, you can set all of these variables from either scheme or C at startup, but I agree it would be good to do it automatically on Windows. <mark_weaver>long ago, LRN suggested "saving the hInstance handle that it gets in DllMain(), then using GetModuleFileName () on that handle to obtain location of the libguile-whatever.dll" <Madsy>That would work, but then you force windows users to compile the library dynamically <mark_weaver>well, I guess it would be good to support both methods. <Madsy>Getting the full path to guile.exe shouldn't be hard <mark_weaver>what about when guile.exe is not the thing being run? <Madsy>Oh, you mean when people use libguile? Good point. <mark_weaver>how does one find the full path to the current executable on Windows? <Madsy>Hm.. can't you just read argv[0] ? <mark_weaver>you can try, but at least on POSIX, argv[0] often doesn't have the full path. it's what the user typed, so usually just the base name. <dje42>Looking in libiberty/lrealpath.c I see a call to GetFullPathName. <mark_weaver>another thing that's not clear to me: how to hook into DllMain properly, for a POSIX-style library built using mingw. <mark_weaver>I guess that mingw is probably installing its own DllMain that needs to be run. <Madsy>mark_weaver: ports.test still fails because popen is broken <Madsy>I thought maybe that was one of the POSIX functions you fixed :) <mark_weaver>Madsy: yeah, that would be nice. eliz wrote an implementation of popen for Windows, but only for non-threaded builds. <mark_weaver>(it temporarily remaps the stdin/stdout/stderr file descriptors before spawning the subprocess, and the restores them after. <Madsy>That's weird because popen.test passed. ports.test failed, but it uses popen <Madsy>I'm positive I compiled with thread support <mark_weaver>we haven't merged eliz's patch, so non-threaded guile wouldn't fix it <mark_weaver>Madsy: popen.test is rigged to effectively skip all tests if the popen module is not available. <mark_weaver>eliz outlined how to implement popen properly on windows, by using a native windows api that spawns a subprocess with stdin/stdout/? handles passed in explicitly. <mark_weaver>dje42: thanks for the pointer. that's part of what's needed, but I think there might still be a missing piece. <dje42>I don't know if libiberty's "pex" support would work here, but IWBN to share the code, it does try to solve a similar problem (dunno if it's similar enough). <mark_weaver>on POSIX at least, argv[0] is not always a relative path from the current directory. we might have to search the PATH for it. <dje42>ISTR libiberty having code to do that too. Can't always trust my memory though, and it might have been for a different purpose. <mark_weaver>I wish there was a more reliable way, though. this all seems fragile. <dje42>I can imagine libiberty not sufficiently supporting the threaded case, and the gcc folks not interested in adding it. <Madsy>Where does _GC_pthread_create and _GC_pthread_detach come from? <Madsy>I thought I had built guile successfully with thread support on Windows, but I was wrong <Madsy>I fixed some issues I had which lead to configure not picking up W32 pthreads, but I'm now stuck with unresolved symbols for those above <Madsy>I'm linking statically against W32 pthreads <dje42>Guessing, libgcc needs to be reconfigured/rebuilt with the needed support. <Madsy>Maybe --enable-threads=win32 is wrong when compiling libgc? <Madsy>When the pthreads library acts like POSIX pthreads <dje42>Those functions definitely come from libgc. <dje42>Looking at libgc/configure.ac, it looks like --enable-threads=win32 may not be what you want. <dje42>If you've configured guile for pthreads, then libgc needs to be configured for pthreads as well (guessing, but seems logical). <dje42>--enable-threads=win32 looks like it enables something different (native win32 threads?) <dje42>Try --enable-threads=pthreads ? [seems like it from reading libgc/configure.ac, assuming you want pthreads in guile] <Madsy>dje42: So what does --enable-threads=windows do for guile? <Madsy>I thought that simply enabled thread support for windows via gnulib <dje42>I don't see any --enable-threads support in guile-2.0.9/configure.ac (for example). <Madsy>:/configure --help says: --enable-threads={posix|solaris|pth|windows} <dje42>Interesting. Not sure (yet) where that's coming from. <Madsy>But I'll try pthreads instead, thanks <Madsy>The only problem is that mingw doesn't have a flag for it. So -pthreads is not allowed <dje42>Ah, --enable-threads comes from gnulib. (ref: m4/threadlib.m4) <dje42>guile uses --with-threads and only supports --with-threads=pthreads <Madsy>Yeah, not to mention I'm trying to use two different threading implementations in the same application <dje42>mark_weaver: I don't see m4/threadlib.m4 in 2.0.9, but I do see it on the stable-2.0 branch. new for 2.0.10? Seems like there's room for more confusion when 2.0.10 is released. <Madsy>What file do I delete to reset configure's cache? <Madsy>Hm, I don't find that file, but variables aredefinitely caches <dje42>I know in gdb, the config.cache is one level down from the top level build directory.