<madsy>--disable-threads make no difference either, heh. <mark_weaver>madsy: set the PKG_CONFIG_PATH environment variable. <mark_weaver>pthreads are the only kind of threads that guile supports. if you don't have pthreads, then you have to disable threads. <mark_weaver>if you build guile without threads, then I think you need to build libgc without threads also. <mark_weaver>when you say that it looks for pthreads even if you disable threads, can you be more specific? what symptom do you see that makes you say it's looking for pthreads? <madsy>mark_weaver: But windows doesn't have posix threads? <mark_weaver>I really have no idea, sorry. I've never even *used* windows in my entire life :) <madsy>Anyways, Windows doesn't have posix threads, so if guile is supposed to be portable, it has to use Win32's CreateThreadEx function instead <madsy>Err.. CreateThread() or CreateProcessEx() as replacements for pthread_create and fork() <madsy>mark_weaver: Hm.. you're right. It's from the libgc includes. It's strange it even built with MinGW if it depends on pthreads <madsy>Ooh.. there is a pthreads port for Windows ***cky944 is now known as cky
<madsy>mark_weaver: The snapshot you sent me isn't compatible with the latest version of libgc <madsy>But due to a mingw bug, I can't compile libgc 7.0 or 7.1 <mark_weaver>7.4 is the latest, cutting edge. there's also 7.2e, which is the recommended stable version. <madsy>Ok anyway, I tested with gc 7.2. There's a small compatibility breakage between 7.1 and 7.2 it seems. <mark_weaver>afaik, the tarball you have should work with either, at least not GNU/Linux. <mark_weaver>for now, I recommend 7.2e. that's the most likely to be robust. <mark_weaver>if that doesn't work, 7.4 might also be worth a try. <madsy>I might be wrong but it seems like GC_set_finalizer_notifier is used as a function-pointer in libguile, finalizers.c:26 <madsy>But in libgc 7.2, GC_set_finalizer_notifier is a used symbol for an actual function <mark_weaver>madsy: line 26 of finalizers.c is: #include "libguile/bdw-gc.h" <madsy>I get the same complaint both when cross-building and when compiling natively for Ubuntu/Linux <mark_weaver>that code is only present if HAVE_GC_SET_FINALIZER_NOTIFIER is false. <madsy>Okay, how did it end up as false? <madsy>It even happens when I'm not cross-building and using a prebuilt libgc for Ubuntu <mark_weaver>when cross-building, I guess it can't do those autoconf tests properly, so I guess those things will have to be set manually. <mark_weaver>but when not cross-building, it should definitely work. <madsy>I have libgc 7.2 as a native library in Ubuntu <madsy>libgc1c3:amd64 1:7.2d-0ubuntu5 <madsy>I've built guile 2.0.9 before <mark_weaver>madsy: okay, well, config.log should have some clues. Search for GC_set_finalizer_notifier in that file. <madsy>Yeah, I'll be back when I know more <madsy>mark_weaver: The test for that macro failed because it didn't find my compiled libgc under ~/mingw/lib. The test didn't set the library include path, regardless of my --with-sysroot setting <madsy>LDFLAGS=/home/madsy/mingw/lib ./configure ... did the trick <mark_weaver>I think it uses 'pkg-config' by default, so maybe you need to set PKG_CONFIG_PATH so that it can find the bdw-gc.pc file of your locally installed libgc. <madsy>Haha.. now the build tried to invoke guile in wine. It crashed :( <madsy>Maybe I can use my native guile 2.0.9 instead to finish the build? <mark_weaver>oh, I guess you have the kernel rigged to run wine automatically? <madsy>yeah, it invokes .exe suffix files in wine <madsy>I have to inspect whether it's wine or guile which is to blame for the crash, but it would be nice to at least complete the build. Can I use an existing guile binary for that? <madsy>As I said, I got 2.0.9 already built natively <madsy>It says the guile binary set with GUILE_FOR_BUILD has to be the exact same version as I'm cross-building. Is that still the case with the snapshot I gor from you, and 2.0.9 ? <mark_weaver>no. the native guile you use has to be from the same tarball. <mark_weaver>(or at least it has to be close enough, but this pre-2.0.10 and 2.0.9 are not close enough) <madsy>Hm.. then I have to build this version of guile natively before I can cross-compile. Darn. <madsy>I have a few theories of what could be wrong now though. Either libgc doesn't like 64-bit builds for Windows targets, or wine doesn't like the binary for some reason. <madsy>I'll see if the guile binary works in a windows VM <mark_weaver>if not, maybe you can run it in some kind of debugger, and get a backtrace. <mark_weaver>Multiple people have gotten Guile working on Mingw, anyway. <madsy>I doubt they cross-built it from Linux though. This is hard :p <mark_weaver>I think they probably did cross-compile it from GNU. <mark_weaver>I think that's how things are generally done with mingw, no? <zxq9>Is there an easy/recommended way to get guile 2 on osx? <mark_weaver>they might have been targetting mingw32 though, not 64. <zxq9>Or is it a build-your-own-deps sort of thing? <mark_weaver>zxq9: homebrew has it, at least. but I think you have to pass some kind of "--devel" option, or something, to get 2.0. <mark_weaver>I'm pretty sure that multiple homebrew-like-systems have it. <zxq9>ok, I'll look into that. Haven't done homebrew or similar on osx (sort of avoid it other than for work...) <zxq9>I'll mess with homebrew -- it seems to be the go-to subsystem for installing stuff I'm used to using. <mark_weaver>I'm using "similiar" in a very broad sense, btw. they probably aren't that similar when you get down to it, but I don't know enough about them to discern their differences. <madsy>mark_weaver: Whenever I say Linux I mean Linux distros in general, I don't mean the kernel. Forgive the sloppy terminology, but that's a hard one to change for me <mark_weaver>zxq9: I guess you need something like "brew install guile --devel". without the --devel, you might get 1.8, which is very old and long-unsupported. <mark_weaver>madsy: I know what you mean, but I'm trying to break your bad habit :) <mark_weaver>it's a serious problem for the GNU system that so many people call our system "Linux". <mark_weaver>it's ironic that as the GNU system is becoming increasingly popular, used by millions of people, most of them don't even know it's GNU. <mark_weaver>You can swap in FreeBSD's kernel and hardly notice a difference in the overall system, and yet people still call the system "Linux". <turbofail>yeah, the GNU tools are pretty important. linux without a GNU userland can be a frustrating experience <zacts>yeah, I'm trying to decide what I should focus my time on. I like the idea of a gnu/kfreebsd guix, and I also like the idea of NuBSD. I also really like the idea of improving gnu ideals. <zacts>so I may focus more of my time on gnu stuff. It's like so many interesting projects. <zacts>I guess I'm kind of a nerd and like all kinds of free software projects and alternate operating systems. <zacts>but I really do feel strongly in helping move forward the gnu ideals. <zacts>anyway, I am building a new guile on FreeBSD-10. I'll let you know if I get all of the tests passed <zacts>I keep on getting these turkish language failures <zacts>I've installed all of the gnu iconv ports I could find <brendyn>zacts: sounds fun, but i mean it seems to be large projects that go for more quirky combinations like kfreebsd with gnu. you wouldnt want to spread too thin on multiple different projects <brendyn>note that im outside the guix project, so i can only give generalised views, and my general view as that a well established gnu/linux with all the cool features on display will be chick/dude magnet <brendyn>if its this mess you need to git clone yourself and setup thats not so good. finishing touches can make more of an impact than years of coding work <mark_weaver>zacts: I wouldn't worry too much about the Turkish locale thing. if those are the only tests that fail on freebsd, we're in very good shape. <mark_weaver>the bug is not in guile, anyway, but in some other library. <mark_weaver>out of curiosity, what version of GNU libunistring is in freebsd ports? <mark_weaver>(I'm not sure that's the relevant library for this problem, but I'm curious if it's an old version, and if so, how old) <zacts>mark_weaver: I'm also getting 41 unresolved test cases <mark_weaver>If someone from Turkey uses FreeBSD, maybe they will report the bug (which probably affects most (all?) programs on the system) and get it fixed. <mark_weaver>zacts: same here. those aren't freebsd-specific. things we should improve some day. <zacts>ok, well. that seems promising. are there any other things you want me to check/test for the 2.0.10 release? <mark_weaver>zacts: no, it sounds like the port is ready to submit upstream as soon as 2.0.10 comes out. <mark_weaver>maybe you could start by getting the boehm-gc-threaded-posix (or whatever it's called) submitted upstream. <zacts>boehm-gc and boehm-gc-threaded are a mess right now. <mark_weaver>fwiw, if I were upstream, I would say: how about renaming it to 'boehm-gc-pthreads'. <zacts>yeah, that sounds like a good idea <zacts>I'm working with upstream FreeBSD directly. A couple of people are way interested in porting guile too, but I'm doing the bulk of the work. I'll mention that to them. <mark_weaver>it's been a long road getting guile-2.0 pushed out to distros, and it makes us very happy when progress is made on that front. so if I meet you in person some time, I owe you a beer :) <impaktor>will there be an announcement somewhere when 2.0.10 is released? <taylanub>impaktor: Probably on guile-devel and/or guile-user, and the home-page will list the new version as the latest stable. Don't know of other places. <nalaginrut>impaktor: well, no matter if it's the top one, there's few people will read it <taylanub>K&R is definitely not an "essential book of computer science," that list seems very random. <nalaginrut>I've read Hopcraft's Automata Theory, then I don't fear regex anymore ;-) *nalaginrut suspended if many voted guys read these book listed... <add^_>finally got my kinesis! sweeet! <mark_weaver>impaktor: yes, it will definitely be announced on guile-devel, guile-user, and info-gnu@gnu.org. Other places too, but I don't have the complete list. <mark_weaver>wingo: any chance you could take a quick look at my 'stop-server-and-clients!' patch? It's the most recent post on guile-devel. I ended up doing a much more proper job than I originally intended. I cancel the REPL threads and use a pipe to signal the server to shut down cleanly. <mark_weaver>thanks! I have an updated coop-repl-servers patch also, that avoids MVars and adapts to these other changes. Will post soon. <davexunit>a lot of neat stuff happening lately. I was excited to see a 1.0 release of guile-wm. <davexunit>unfortunately my configuration doesn't work with the new version <davexunit>so I need to sort that out. falling back to gnome 3 since I'm working from home today. <davexunit>mark_weaver: yeah, par for the course. just need to set aside some time to fix it when I don't need to depend on it. <mark_weaver>great stuff... looking forward to switching to guile-wm after 2.0.10 is out the door. <impaktor>I'm using stumpwm, but just using the basic features of it. I would be happy to switch to guile-wm, if it is mature enough to replace stumpw, but I guess guile-wm requires the end user to do a lot of heavy writing/configuring? <impaktor>Reading the guile-wm page, I don't really understand what it does, or where it's at with features. I take that as a sign that I'm not ready for guile-wm yet? <davexunit>impaktor: it's still a young piece of software, but the advantage for me over stumpwm is that I know the guile ecosystem and scheme far better than I know common lisp. <davexunit>mark_weaver: guile-wm does some interesting tricks to deal with multi-threading issues with the REPL server. <davexunit>so perhaps mark witmer will be happy to hear about the new coop repl server? <davexunit>I looked at the stumpwm source to see how they did it. <davexunit>when C-t C-t is pressed, they emit a fake C-t keypress event. <mark_weaver>right. I guess it's not trivial, if the code to insert keypress events isn't already there. I'd have to look up how to do that. <davexunit>yeah, I got lost in the details of using XCB correctly. <davexunit>I should just email mark witmer about it. his tiling wm module might already address the issue for all I know. <add^_>Hm, what is this amazing thing I'm hearing about? <mark_weaver>in ratpoison, which I use, C-t C-t switches to the second-most recent window (convenient for switching back and forth between two windows), and C-t t generates a C-t keypress. <mark_weaver>(although GNU Screen uses C-a by default, which I always remap to C-\\) <davexunit>mark_weaver: oh sorry, C-t t is what I meant. <davexunit>mark_weaver: never thought to remap C-a to C-\\ <impaktor>is ratpoison still alive? I thought stumpwm had replaced it. <mark_weaver>I don't know if it's still developed; probably not, I'd guess; but it does what I need for now. <mark_weaver>davexunit: to use C-\\ in screen, put this in ~/.screenrc: "escape ^\\\\\\" <impaktor>"Apr-07-2013 Death to the rodent! Ratpoison 1.4.6 has been released!" <davexunit>thanks. good ol' intuitive screen configuration. <civodul>impaktor: Ratpoison does the job for me <davexunit>I actually haven't used ratpoison. just stumpwm briefly. <davexunit>I'm *just* figuring out that it's called ratpoison because you don't use the mouse <civodul>oooh, new Guile-WM and new Guile-SSH <davexunit>guile-ssh seems cool, but I can't think of what to use it for. <jemarch>hm, guile-ssh looks like something that may fit my needs... <jemarch>does it wraps the ssh_scp_* functions? <madsy>When cross-compiling, isn't GUILE_FOR_BUILD suppose to make the build guile script invoke the guile binary of my choice? It keeps invoking the cross-compiled guile.exe here for some reason. <mark_weaver>madsy: two things that might be relevant here: GUILE_FOR_BUILD is checked for by the configure script, so it has to be set then. also, it's not even looked for if configure doesn't realize that's a cross-compile. did you specify --host? <madsy>mark_weaver: host specified, of course. Or else it wouldn't find my mingw. GUILE_FOR_BUILD is also set at configure time, and I checked config.log to see if it was set. It is. <mark_weaver>yeah, grepping my build directory, I see that GUILE_FOR_BUILD is not consulted in the Makefiles at all. <madsy>mark_weaver: I'm not specifying CC_FOR_BUILD because I have a mingw toolchain in path with the correct suffix <madsy>I can't seem to complete the texi generation and go-compilation without this, so :) <mark_weaver>madsy: does configure think it's cross compiling? search for "checking whether we are cross compiling" in config.log <madsy>You're right, it's 0. How did that happen? <madsy>But I already checked GUILE_FOR_BUILD. It is indeed set to the correct path <mark_weaver>configure doesn't even look at GUILE_FOR_BUILD if it doesn't think it's cross compiling. <mark_weaver>search for "checking whether we are cross compiling" in config.log and see what happened. <mark_weaver>oh, it might be that it checks whether it can run the binary. and maybe the fact that your system is set to automatically run the binaries in wine, that makes it think it's not cross compiling. <mark_weaver>and indeed, if you can actually run the binaries in wine, that's probably ideal. <madsy>It's not ideal because guile.exe keeps crashing in wine. But I'll find a way to address this <mark_weaver>I'm sure there's a way to override specific tests in configure, but the details of how to do that is a bit beyond my autofoo. <madsy>mark_weaver: Hopefully this is one of the last hurdles. Configure picked up the cross compiling now. <madsy>But that windows binaries were automatically invoked by wine is kind of bizarre <madsy>Not very nice from a security standpoint <madsy>Yeah I disabled it with update-binfmts <mark_weaver>ah, right, CONFIG_BINFMT_MISC, that's what I'm thinking off. I guess ubuntu enables it by default. <mark_weaver>madsy: there might be some relevant configuration in /etc/init/binfmt-support.conf <mark_weaver>otherwise, it might get reenabled the next time the wine package is updated <madsy>Yeah I'll look into it. It's not a huge deal except when I'm cross compiling <madsy>Now, the last issue I have is the Windows path, and primitive-load-path. Is it possible to make guile look for its modules relative to its current directory? *mark_weaver just noticed that when he compiles Guile and runs "make check" in an environment with all Guix binaries, "unresolved test cases" is only 14, whereas if I compile and check in Debian wheezy, the number is 52. <madsy>Wouldn't that make it look for the modules in its current directory? <mark_weaver>sorry, I don't understand the fine distinction you are making. <madsy>No, I asked for relative to its directory. Like ../lib/guile/something <madsy>Relative to --prefix, guile is in bin <mark_weaver>madsy: I still don't understand what you're asking for, so let me just say what Guile does. it looks for module (foo bar baz) in <DIR>/foo/bar/baz.scm, where <DIR> is a component of %load-path. %load-path is initialized to include the components of GUILE_LOAD_PATH during initialization (plus some others determined at compile-time) <mark_weaver>if you're asking for a way to make the Guile installation freely movable by the user, so it can be put anywhere and "just work", we don't support that yet. however, you can work around it by setting GUILE_LOAD_PATH and a few other environment variables from within a wrapper script. <mark_weaver>also, if you're interested in helping to implement more proper support for a relocatable Guile directory on Windows, I'd be glad to work with you on that. <madsy>Could you list all the required environment variables for me? <madsy>I either have to mess with those and make them relative, or I have to limit guile in Windows to run inside MSYS <madsy>That's assuming my guile binary actually works with proper paths, and nothing went wrong in the build though. Only one way to find out <mark_weaver>well, GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH are the most important ones. let me see if I can find some others. <mark_weaver>LRN summarized what needs to be done for a more proper solution: <mark_weaver>He wrote: infer paths in the usual way - by saving the hInstance handle that it gets in DllMain(), then using GetModuleFileName () on that handle to obtain location of the libguile-whatever.dll, then checking if that dll is in a "bin" directory, and taking parent directory of that "bin" directory as the prefix, and then appending things like "/etc/config.d" and "/share/guile/stuff" to that prefix <mark_weaver>that's for dynamically-loaded shared libraries that are loaded on-demand from Guile. <mark_weaver>we use libltdl for that. I don't know how libltdl behaves on Windows though. <madsy>What's the default paths for these? I assume the default for GUILE_LOAD_PATH is /share/guile/2.0/ <madsy>And GUILE_LOAD_COMPILED_PATH is /lib/guile/2.0/ccache <mark_weaver>Well, the %load-path normally contains: $PREFIX/share/guile/2.0 $PREFIX/share/guile/site/2.0 $PREFIX/share/guile/site $PREFIX/share/guile <mark_weaver>and %load-compiled-path normally contains: $PREFIX/lib/guile/2.0/ccache and $PREFIX/lib/guile/2.0/site-ccache <mark_weaver>so I guess you should set GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH to approximate those. <mark_weaver>GUILE_SYSTEM_EXTENSIONS_PATH normally defaults to having: $PREFIX/lib and $PREFIX/lib/guile/2.0/extensions <madsy>mark_weaver: That did the trick. Guile works here now in Windows 7 :) <madsy>Outside an MSYS environment even <madsy>And the paths could be relative from what I can see <mark_weaver>sure, although relative paths could be problematic if the program changes the current working dir and then loads a module or shared-lib. <mark_weaver>better to change those relative paths into absolute paths before the main program starts running, I think. <mark_weaver>madsy: so that's a 64-bit guile? does it support threads? <madsy>Yes and yes, but I'll have to test threading before I can say anything about it. <madsy>The guile binary takes just under 5 MiB <madsy>Also, I'm worried about the GC being unstable since libgc doesn't officially support 64-bit Windows <mark_weaver>sounds reasonable. the one from Guix for x86_64 is just under 4 MB. <madsy>Is there any nontrivial guile application I can test, which is easy to install? <madsy>Hm.. not sure how to do that on the target system <madsy>If it's a bunch of shell scripts, I could invoke those from within MSYS <madsy>Not certain if that would work though <mark_weaver>well, I would take the "check-guile" script from the top-level build dir, and maybe hack some different paths into it (near the top) <mark_weaver>and copy the contents of test-suite/* somewhere on windows, with the TEST_SUITE_DIR variable in the script set to match its location. <mark_weaver>and then just try running it with no arguments, or maybe just with the -i argument. <madsy>mark_weaver: I think I can run the test suite inside mingw if I'm clever <mark_weaver>probably, although a test under actual Windows would probably be better than a test under wine. <madsy>And MSYS runs in Windows. It's just a slightly more unix'y environment <madsy>So you can run shell scripts <mark_weaver>check-guile basically just sets some variables and runs guile. everything else is done within guile itself. <mark_weaver>you could actually get away without a shell at all, by simulating what it does. (it's fairly simple) <mark_weaver>check-guile is not the entire test suite, but it's most of it. <madsy>So no need for standard toos like sed, awk or perl? <mark_weaver>no, you shouldn't need those. maybe some of the tests assume a shell or something. <mark_weaver>a shell is probably only needed for the tests that exercise subprocess handling and such.. <mark_weaver>the guile script that actually runs the test suite is test-suite/guile-test. it wouldn't be hard to just run "guile", load that file in, augment the load path, and call 'main' with some arguments. <mark_weaver>run: guile --debug -L /BLAH-BLAH/test-suite --no-auto-compile <mark_weaver>then from the REPL prompt: (primitive-load-path "guile-test") <mark_weaver>and then: (main '("--test-suite" "BLAH-BLAH/test-suite" "--log-file" "check-guile.log")) <mark_weaver>oh, sorry, that last line should be: (main '("guile" "--test-suite" "BLAH-BLAH/test-suite" "--log-file" "check-guile.log")) <cky>madsy: Glad to see you participating here much more. :-D <cky>mark_weaver: Meet madsy, OpenGL geek from Norway. :-) (I first met him on #stackoverflow, and we still hang out there a lot.) <mark_weaver>cool! yes, I remember seeing madsy and unknown_lamer geek about GL stuff a while back :) <mark_weaver>madsy got current Guile stable-2.0 running on Windows 7 with 64-bit mingw, statically-built, and running without MSYS. great stuff :) <cky>That is very impressive! <davexunit>madsy: that's awesome! maybe guile-2d can run on windows someday :) <madsy>I'm experiencing a weird quirck though. When I run guile.exe when it's not in CWD, I get "ERROR: Unbound variable: eval-when" <madsy>But it works if I invoke guile.exe from the directory it's in <madsy>Ah.. it's just an MSYS issue <mark_weaver>madsy: another mistake in that last line: (main '("guile" "--test-suite" "/BLAH-BLAH/test-suite/tests" "--log-file" "check-guile.log")) <madsy>I thought I could trick guile.exe to run under MSYS, and it works, kind of. I have to cd into its directory before invoking it <mark_weaver>did you use relative paths in any of the environment variables you set? <mark_weaver>otherwise, I don't see why the current directory should matter. <madsy>Well, they're relative as far as Windows is concerned. But full paths inside MSYS itself <madsy>That is, all the paths start with a '/' <mark_weaver>do you need to add a drive prefix to make it fully absolute? <madsy>In Windows in general, yes. But that's not a legal path in MSYS <madsy>With proper paths outside MSYS (with driver letters), guile.exe works whereever <madsy>So it's probably due to some MSYS magic <madsy>mark_weaver: I did what you suggested. I got: <madsy>ERROR: In procedure memoize-variable-access!: <madsy>ERROR: Unbound variable: lstat <mark_weaver>ah, bummer. that's not bound when --disable-posix is used. <madsy>So the test suite depends on POSIX. Not much we can do about that <mark_weaver>I remember a thread recently on this topic. basically, that --disable-posix disables too much. many of these things are actually available on mingw. <mark_weaver>it would be interesting to try building guile for mingw without --disable-posix, and then arranging to automatically disable the things that are actually missing. <mark_weaver>it would result in a much more useful guile-on-windows. <mark_weaver>well, it looks like that code won't be used if you pass the list of tests to run, instead of expecting it to traverse the filesystem looking for the list itself. <mark_weaver>maybe there are other problems too, but it's worth a try :) <madsy>mark_weaver: The first string, "guile" is the path to the guile interpreter, right? So to get around my path issue, I have to replace that with a shell script. <mark_weaver>and hopefully the shell script passes along the other arguments at the end. <madsy>mark_weaver: Okay, this one was more bizarre: <madsy>ERROR: In procedure string=?: <madsy>ERROR: In procedure string=: Wrong type argument in position 2 (expecting string): g <mark_weaver>does it leave you in the debugger? can you get a backtrace (",bt") ? <mark_weaver>did it happen right away, or did see some output first? <mark_weaver>does it leave you in the debugger? i.e., does the prompt end with " [1]>"? <madsy>Yes, it leaves me in the debugger. I did a backtrace <madsy>This one is weird. How did the 'g' get there? :D <mark_weaver>oh, well, first of all, you need to replace "/BLAH-BLAH/" with the right path. <mark_weaver>I'm still confused about the error, but that's one problem. <madsy>I just saw it myself, but I get the same error after fixing the mistake <madsy>This obviously happens while evaluating the argument strings; before any tests are run <mark_weaver>I think what must have happened here is that the argument list passed to 'main' had a CDR at the end that was the bare symbol 'g'. maybe something got corrupted in the copy-paste? <madsy>No, I tried to run with just two tests as well. Same problem. <madsy>Hm, I might be getting somewhere. Hold on. <madsy>I ran this now, and it's doing something, but I don't see a log anywhere, and no output <madsy>Is the env test suppose to take a very long time? <mark_weaver>no, most of the tests run very quickly. something must be wrong. <madsy>Also, the Ctrl-C handler crashes hard on Windows <madsy>But for all I know, it might be my build <mark_weaver>The existing Ctrl-C handling probably assumes posix. <mark_weaver>I don't think it would be very hard to get Guile working a lot better on Windows. We just need someone who uses Windows who's willing to do the work. <mark_weaver>if you can run a REPL and type basic expressions and have them work, that's means that all the really hard stuff is working. <mark_weaver>what would be really useful is to try to build without --disable-posix, and then work through the issues one by one, perhaps putting in #ifdefs to make native windows calls where needed, in place of the missing posix calls. <madsy>I've run about 4 tests now. All of them fail to complete or print any output <madsy>And they block forever, so I'm testing them one by one <mark_weaver>'main', in the 'guile-test' script, should print "Running <test-name>\\n" before running each test. <mark_weaver>maybe it has to do with I/O buffering, or something. <madsy>I can paste the backtrace I get from a Ctrl-C <mark_weaver>oh, I see that 'run-tests' is run within 'with-code-coverage', which is probably some black magic that might not work on windows. <mark_weaver>oh, well, only if coverage is enabled, which i guess it isn't by default. <mark_weaver>madsy: looks to me like there's an error, and then there's another error while trying to print the error message, ad infinitum. <madsy>An error in an exception handler? <mark_weaver>what happens if you comment out the calls to 'set-port-conversion-strategy!' on lines 220 and 221 of guile-test? <mark_weaver>I think we need to get a backtrace from a C debugger. <mark_weaver>The question: Why is 'write-char' running out of stack? <mark_weaver>is there an infinite recursion, or is the default stack limit too small? <madsy>Remember, I get that trace after pressing Ctrl-C, so it might be the signal handler's fault <mark_weaver>at this point, I would probably start inserting 'pk' calls in guile-test, to see how far it gets before getting stuck. <mark_weaver>madsy: yeah, good point. I take back what I said before that ended with "ad infinitum". <madsy>Commenting out set-port-conversion-strategy! made no difference. Still hanging with no output. <madsy>I could add some printing calls to guile-test and see how far it gets <madsy>No, what is it and how do I use it? <mark_weaver>(pk arg ... final-arg) prints a message with all the args, and returns 'final-arg'. <mark_weaver>so it's convenient to wrap around expressions. I like to put (pk 'label ...) in place of ... to see what ... returned. <mark_weaver>so yeah, sprinkle those around guile-test and see how far it gets. <madsy>At least it's comforting to know that it isn't the tests that fail <mark_weaver>if you don't see anything, maybe output is not getting flushed properly. (force-output (current-output-port)) should flush. <mark_weaver>(current-output-port) is supposed to be unbuffered by default, but maybe that's not the case on windows or non-posix. <mark_weaver>who knows, maybe the tests are working fine, but the output is never getting flushed? :) <mark_weaver>I suppose you could test that by typing this at the REPL: (let loop () (display #\\!) (sleep 1) (loop)) <madsy>You don't usually need to flush on windows. <madsy>And guile does show output when I invoke the REPL myself <mark_weaver>does the expression I just gave show the individual characters printed once per second? <madsy>Nope, it's fairly fast when I invoke the REPL <mark_weaver>no? how is it different from what I described? more than once per second? <madsy>Yeah, extremely fast. Like 2 lines per second <madsy>Another curious thing I just discovered. The default Ctrl-C handler in Windows works in the guile repl when I tried your loop <madsy>My bet is that the default Ctrl-C handler doesn't like complex jumps <madsy>"works" meaning a clean exit <mark_weaver>hmm, yeah, maybe something like that. though there are exception handlers at the REPL. <mark_weaver>wait, does Ctrl-C exit guile completely, or bring you back to the REPL? <madsy>It exits guile completely, yep. I didn't enter the debugger after ending your loop <mark_weaver>okay, that's not what's supposed to happen, but without posix I'm not surprised. <mark_weaver>well, it might be more useful to try to get guile working without --disable-posix. <mark_weaver>it might actually be less effort than what we're doing now :) <madsy>Yeah. There are workarounds for most of it <madsy>Do internet sockets in guile use WinSock 2.2 for Windows builds? <mark_weaver>I have a vague recollection that either Eli or LRN built it without --disable-posix, and things mostly worked except some problem with the REPL, but I might be remembering wrong. <mark_weaver>madsy: I don't think so. I think we just use Posix interfaces for almost everything now. <mark_weaver>actually, looking at the pkgbuild.sh script that LRN sent me, which produced a mostly working guile, I see no --disable-posix <mark_weaver>looks like he just passed "--prefix" and "--enable-maintainer-mode". <madsy>Hm, I could try a rebuild. But as MinGW lacks posix libraries, I'm not sure how that's supposed to work. <mark_weaver>I know he was using MSYS. Might that be relevant here? <mark_weaver>the build script actually checks for MSYS, and if it's not there, prints "You must be in an MSYS shell to build a msys package" <madsy>Kind of. If so, he did the build from Windows, not cross-compiling from a Linux distro. <madsy>And MSYS might have some ported POSIX libraries with MinGW-patches <mark_weaver>if MSYS provides some POSIX interfaces, is there a way to link to it when cross-building? <madsy>The problem with those is that they're usually only made for MSYS and Windos in mind. With horrible makefiles. <mark_weaver>ideally, Guile would be able to use the Windows APIs directly where needed. I'd certainly much prefer to be able to cross-compile from GNU/Linux. <mark_weaver>it's possible that gnulib might have some of what we need too. <madsy>Trying to build with posix support now. If I get the same symptoms, I'll sprinkle some pk's around in guile-test and let you know how far it gets <mark_weaver>if you find that the REPL doesn't work at all with the POSIX version, that wouldn't be surprising, but if so, don't despair. I was told that the test suite mostly ran. as I recall, the problem was related to trying to install a signal handler or something. <madsy>Some good news. Without --disable-posix, the debugger works in the REPL now <madsy>sleep is still a noop though <mark_weaver>madsy: so, it appears that we are already using many parts of the Windows API, including sockets, via gnulib. <mark_weaver>so Guile code is calling posix interfaces, but gnulib includes wrappers for those functions. <madsy>Oh.. so without gnulib, ./configure ignores a lot of functions? <madsy>I know for sure I did not build gnulib <mark_weaver>but it's thanks to Gnulib that things work as well as they do, even though Guile's own code mostly just uses the posix interfaces. <madsy>By the way, does (pk 'some-macro (some-macro)) work? <madsy>Hm, I must have had a typo then. <mark_weaver>well, 'pk' is just a normal procedure. if (some-macro) expects to be at top-level, it won't be anymore. <mark_weaver>I guess I should have said that (some-macro) needs to expand into an expression. <mark_weaver>(as opposed to a definition, or a mix of definitions and expressions) <madsy>mark_weaver: Huh, I don't get it. Not even main gets invoked here <mark_weaver>madsy: probably things are just not being output, for some reason. <mark_weaver>did you try calling (force-output (current-output-port)) ? <madsy>It is being output. I mean, I can add a (pk 'foo) to toplevel outside any function and it does get displayed at load time <mark_weaver>madsy: regarding 'sleep': what is SCM_HAVE_SYS_SELECT_H defined to in libguile/scmconfig.h? <mark_weaver>well, when you load things, maybe force-output is being called by something else. <madsy>SCM_HAVE_SYS_SELECT is configured to 0 <mark_weaver>okay. I think something regarding select needs to be fixed here. gnulib has a nice wrapper for select, and I suspect it's not being used. <mark_weaver>madsy: can you show me your modified 'guile-test' script, with the 'pk' at the start of main? <madsy>I might have a mistake in default-test-suite, I'll fix that <madsy>Still, I *should* see the first pk on the second line in main <mark_weaver>can you swap the order of the 'force-output' and the 'pk' at the top of main? <madsy>Ah right, it's a flush. I thought it was a single-time disable for buffering <madsy>No difference. Still no output <madsy>If I get a log file, what should its path be? <mark_weaver>well, it would go into the current directory, I guess. <mark_weaver>just before "(let" at the top of main, can you insert the characters: "#;" ? <mark_weaver>that will comment out the entire body, so *all* it does in print. <mark_weaver>I guess the flush isn't working, and maybe something later is hanging things up such that it never flushes. <madsy>Haha, what the hell is going on. It still *blocks* without output <madsy>I even double checked I saved the file properly <mark_weaver>okay, from the REPL, try these: (display "foo\\n") and (begin (write '(1 2)) (newline)) <madsy>Everything works until I invoke main. I have no idea what's going on <mark_weaver>one difference is that because it's loaded with primitive-load-path, main is interpreted, whereas the things you type at the REPL are compiled to VM bytecode. <mark_weaver>try typing ",o interp #t" at the REPL to disable compilation. <mark_weaver>well, another difference, of course, is that main is calling different procedures. <madsy>Just not after invoking main <madsy>Everything works before invoking main <mark_weaver>what happens if you type (define (main args) (pk 'enter)) <madsy>Works fine, I just did that 5 minutes ago <mark_weaver>what about: (define (main args) (pk 'enter) (force-output (current-output-port))) <madsy>Before or after setting primitive-load-path? <mark_weaver>maybe something that's loaded from 'guile-test' is messing things up. <madsy>But what boggles my mind is that everything works just before invoking main <madsy>And main after commenting out the body, only contains a pk statement <mark_weaver>what if you use 'load' instead of 'primitive-load-path'. but give it the full pathname. <madsy>Can I force guile to always compile or always interpret? <mark_weaver>oh, and when you invoke guile, get rid of the --no-auto-compile flag for this test. <mark_weaver>"load" will compile, at least if --no-auto-compile is not passed. <mark_weaver>I guess the issue has to do with interpretation vs compilation. <mark_weaver>at the REPL, you can control whether the individual expressions you type are compiled or interpreted using ",o interp #t" or #f. <mark_weaver>when you load files, 'primitive-load' and 'primitive-load-path' use the interpreter, and produced interpreted procedures. <madsy>Yeah I removed that argument <madsy>But what is the full path? Is guile-test a directory here or the script? <mark_weaver>I don't know if this is relevant, but I just noticed that there are two definitions of 'main' in that file. <mark_weaver>looks like the first one just invokes the second one. very strange. <mark_weaver>maybe you should create a new, simple script that just defines a simple 'main', that just prints. <mark_weaver>and then try loading that in various ways, and invoking it. <madsy>mark_weaver: Sometimes I get the impression that the REPL is waiting for more input <madsy>Yet, giving it nonsensical input does not make it halt on an error <mark_weaver>well, it does a 'read' first. newlines are just whitespace. <mark_weaver>'read' keeps reading until it has a complete expression, or finds a lexical error. <madsy>Exactly, so if it blocks on read to get more input, it should be possible to check that by writing "ahdsdasdaj)))))))))))))" <mark_weaver>well, unless it's a string it's in the middle of trying to read. <mark_weaver>on POSIX, Ctrl-D would work, by causing the terminal to signal EOF. <mark_weaver>but I don't know how to do that on windows, if it's even possible. <madsy>Ok, yay. I'm one step further. It DID block on input. I don't know why though. Maybe it's the damn windows paths inside strings that get interpreted weirdly <mark_weaver>however, I guess it's more likely that something else is wrong. <madsy>\\ needs to be \\\\ and so on <mark_weaver>right. I think you can just use / instead. as I understand it, windows interprets those as directory separators also, no? <mark_weaver>but yeah, those backslashes might be causing problems. <mark_weaver>but I can tell you this: if you use 'primitive-load-path' or 'load' or whatever, an unterminated string/list/comment won't carry over into the REPL after the load is done. <madsy>Eh.. it seems to have trouble with windows newlines too <madsy>Writing everything on one line works, but splitting it up does not.