IRC channel logs


back to list of logs

<davexunit>good evening, guilers!
***linas__ is now known as linas
<nalaginrut>morning guilers~
<nalaginrut>davexunit: heya~
*nalaginrut is loving vlist these days...
<nalaginrut>seems Guile has no plan for GSoC this year?
<nalaginrut>sorry, this link
<amoe>what's the recommended way to write unit tests for guile code?
<Madsy>Where is mark_weaver when you need him
<civodul>Hello Guilers!
<amoe>civodul: hi!
<Madsy>hey civodul :-)
<Madsy>Going to compile the latest guile snapshot for Windows as soon as mark gets here
<Madsy>Is this the tar I should test for mark?
<Madsy>Or do I get HEAD from git?
<Madsy>hey cluck
<cluck>hi Madsy
<Madsy>cluck: Are you one of the guile developers?
<cluck>no, just a lurker
<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>Madsy: try
<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
<Madsy>civodul: So thanks
<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>that's not correct
<civodul>but yeah, the snarfing stuff needs love
<civodul>patches welcome :-)
<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
<civodul>like i did in GnuTLS
<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
<civodul> is what i was referring to
<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>not a problem
<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- and guile-
<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>civodul: ? That's the one I just used
<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?
<civodul>hey artyom-poptsov
<artyom-poptsov>Hi civodul
<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>Hey mark_weaver :)
<mark_weaver>Hi Madsy!
<Madsy>mark_weaver: I'm building the latest snapshot now. But I ran into what I think is a bug
<mark_weaver>tell me more
<Madsy>c-tokenize.c is one of the programs that's used by the doc snarfing, right? So it is always built natively
<mark_weaver>what's the name of your tarball?
<mark_weaver>okay, that's fresh.
<civodul>Madsy: the config.h is fixed in current stable-2.0
<civodul>*config.h problem
<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>ah ok
<civodul>actually no
<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?
<civodul>actually the 4th 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>civodul: yes
<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. :)
<mark_weaver>ft: you're welcome
<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>Madsy: are you cross-comiling?
<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
<civodul>because config.h is for the host
<civodul>ah ok
<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.
<mark_weaver>civodul: what do you think is the proper fix here?
<Madsy>My suggestion is to add proper guards for the #define type definitions in config.h, so they don't collide with stdlib.h
<civodul>Madsy, mark_weaver: can you try this patch:
<mark_weaver>civodul: "Javascript is required for ZeroBin to work." :-(
<civodul>mark_weaver, Madsy:
<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).
<mark_weaver>oh, but that will require new autotools and flex.
<Madsy>civodul: I'll test the patch a bit later. First I want to see if the snapshot works at all
<mark_weaver>Madsy: okay, sounds good.
<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
<Madsy>And also mingw/lib/guile
<mark_weaver>Madsy: when did it install in 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
<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>for example
<mark_weaver>Madsy: what do you mean by "don't exist"? you mean it tried to load a file that wasn't there?
<mark_weaver>is compiler.test not in the tarball?
<Madsy>The same tests that were missing last time are still missing
<mark_weaver>ah, indeed, it is missing from the makefile
<mark_weaver>what other tests?
<Madsy>Here's the log you got the last time:
<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 :)
<mark_weaver>indeed, thanks!
<stis>hej guilers!
<mark_weaver>hi stis
<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
<mark_weaver>can you get me a backtrace?
<Madsy>From gdb or guile?
<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>the guile backtrace might be good enough too
<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
<mark_weaver>relative to what?
<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>I don't know what happens on windows
<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.
<mark_weaver>but I confess I have no idea
<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.
<mark_weaver>s/and the/and then/
<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>but we just need someone to write the code.
<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 don't know what argv[0] will be on Windows.
<mark_weaver>dje42: okay, I'll have a look. thanks for the idea.
<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>I just did
<Madsy>It made no difference
<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/, 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/, 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/ (for example).
<dje42>There is --with-threads.
<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
<Madsy>It has to be -lpthreads
<dje42>Ah, --enable-threads comes from gnulib. (ref: m4/threadlib.m4)
<dje42>guile uses --with-threads and only supports --with-threads=pthreads
<dje42>Confusing, eh?
<Madsy>Yeah, not to mention I'm trying to use two different threading implementations in the same application
<dje42>Have fun! :)
<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>Is this in guile?
<dje42>I know in gdb, the config.cache is one level down from the top level build directory.