<zacts>mark_weaver: ok, let me see about this FreeBSD stuff right now. /me is making a FreeBSD vm to test everything out. ***Madsy_ is now known as Madsy
<zacts>mark_weaver: are you around, or is he asleep? :-) <zacts>but, what is your schedule like tonight? <zacts>I'm fetching guile-2.0.10 right now. <zacts>and I will have questions in about 15-20 min. <Madsy>There's an actual release for 2.0.10 now? :) <mark_weaver>but the release will be happening in just a few days. <Madsy>Any luck on your side to get a windows binary working? <mark_weaver>Madsy: I've been unable to build a libgc with MinGW that doesn't crash when running its own "gctest" program. <Madsy>I gave up for now and focused on finishing my demo for Ubuntu <Madsy>Oh.. I might try that again. Because the tests ran fine here when guile built and ran cleanly <Madsy>That said, I never ran gctest. I only ran the sub-tests and checked that they all returned 0 <zacts>if I have time I'll test it on NetBSD and OpenBSD also. <Madsy>mark_weaver: So, can we with any certainty say that the error is with libgc alone? <Madsy>Because that would at least narrow down the search for the error somewhat <mark_weaver>Madsy: at first, I didn't run gctest. Guile crashed in a way that made me suspect libgc. So then I tried 'gctest' and that failed too in a similar way. <Madsy>Damn.. me losing track of how I built libgc is the most annoying thing that have happened to me in a while <Madsy>I wonder if I used libgc 7.1 when it was working, instead of 7.2e <Madsy>I also remember I built w32-pthreads statically, but from what you've said, it wasn't being linked to anyway <mark_weaver>I fixed the problem that was causing pthreads-w32 to be needed when it shouldn't have been. <Madsy>Okay nice. Then it must be an issue with the libgc version <Madsy>I'll try 7.1 and 7.2 (not 7.2e) <Madsy>And maybe 7.0. Those four versions cover all the versions of libgc I've ever tried <Madsy>The build error I ran into last time, is it fixed? <Madsy>The missing #defines in config.h <mark_weaver>Madsy: btw, it's worth taking a look in doc/README.win32 in the libgc source. <Madsy>Indeed. Thanks for reminding me. I might have overlooked something. <Madsy>I probably used an extra flag or something I forgot. <zacts>mark_weaver: is there a link to a specific version instead of 'latest'? <Madsy>mark_weaver: By the way, you don't happen to have the tar.gz for libgc 7.2 (not 7.2e) ? <Madsy>The libgc source link is down <zacts>I want to share the patches and have them work with sha256/sha512 when I send them out. <zacts>mark_weaver: I guess I can do that <zacts>well, actually yeah, I can do that. <zacts>(now that I think of it, each person can generate their own shasums when they get my patches until we send a pr when 2.0.10 is released) <Madsy>mark_weaver: Ah thanks. I was probably on one of his old pages <mark_weaver>zacts: if you get it working with this latest snapshot, then you could just wait until 2.0.10 before sending out the patch. it'll only be a couple of days. <mark_weaver>(I'm reluctant to suggest hardcoding the current "latest" snapshot (2.0.9.241-950a), because it has some test suite failures on big-endian machines that I've since fixed, but hydra hasn't yet caught up) <Madsy>mark_weaver: How did you cross-compile the libgc testsuite? I forgot <mark_weaver>well, when running 'configure' it handled it automatically. <mark_weaver>I enabled bitfmt support while running "make check" (but disabled it while building) <mark_weaver>"update-bitfmts --disable wine" or "update-bitfmts --enable wine" to make it so that *.exe files can be run directly. <Madsy>I got rid of that completely <mark_weaver>well, in any case, running "make check" builds the test programs before running them. or you could just do "make gctest.exe" I suppose. <mark_weaver>but it would be good to run all the test programs, ideally. <Madsy>That's what I did last time. I hacked the makefile until it built all the individual tests <Madsy>Then I copied them over into the VM <mark_weaver>for me, "make check" built all the test programs without any hacking, when using ./configure <mark_weaver>btw, which pthreads-w32 libraries did you build? there are several variants, based on what kind of exception handling scheme to use. <mark_weaver>(although I don't see why we should need pthreads-w32) <Madsy>The static version of the C variant without exception handling <Madsy>libpthreadGC2 I think the version is called <zacts>mark_weaver: it's building dependencies now.. I'll let you know in a few minutes. <zacts>also, I'll be sure to run the test suite. <zacts>just built libiconv, now it's at libtool. <zacts>mark_weaver: ok it says my pkg-config is too old <zacts>is there an alternative to pkg-config I can use? <zacts>oh just a sec.. I may have a fix <mark_weaver>zacts: you can set PKG_CONFIG=true and then set BDW_GC_FLAGS, BDW_GC_LIBS, LIBFFI_CFLAGS, and LIBFFI_LIBS manually, as described in the README. but maybe you have a better solution. <Madsy>Or just install all your libraries in one place, and set -I in CFLAGS and -L in LDFLAGS <mark_weaver>you still need to set LIBFFI_LIBS and BDW_GC_LIBS, because those include -l flags. <mark_weaver>I recommend you set all those variables as arguments to configure if you don't have a suitable pkg-config. <mark_weaver>setting CFLAGS might also have the effect of overriding default CFLAGS, dunno. <mark_weaver>and of course, you may recall that you needed to set BDW_GC_LIBS anyway, to point it to -lgc-pthreads (or whatever you called it) instead of the default -lgc <zacts>mark_weaver: thanks, I set those env variables for this build. <zacts>btw may I /msg you so I don't flood the channel and channel logs? <Madsy>mark_weaver: Ok, this seems promising. gctest.exe runs okay on Windows 7 now <Madsy>Bah.. if I build libgc without threads, guile doesn't compile <Madsy>Maybe I forgot --disable-threads <mark_weaver>I think you also need to define a preprocessor macro during the build, iirc, for the sake of gc.h <Madsy>Yeah, I get undefined references to _GC_register_my_thread and _GC_pthread_create and a few others <Madsy>My current libgc is built without any threading at all afaik, so it doesn't supply those <Madsy>Using 2.0.9.219-e1bb right now, because I know that one has worked in the past <zacts>mark_weaver: I have someone who is going to help test the latest snapshot tomorrow morning on pkgsrc NetBSD and pkgsrc Gnu/Linux. <zacts>and tonight I'll see how it works on OpenBSD -current <Madsy>mark_weaver: Testing 950a now <mark_weaver>zacts: it's probably best to get it working on FreeBSD first. we know that one is close. <zacts>mark_weaver: well yes, for sure. I won't start on OpenBSD until FreeBSD is done. <zacts>except I will let the other guy do work on pkgsrc at the same time, but I'm thinking FreeBSD will be working tonight. <zacts>I know of at least 3 - 4 people from FreeBSD land who are totally interested in learning about guile. <zacts>so I think you guys are doing great work with portability, and things like that. <mark_weaver>also, authors of programs that use guile are interested in making sure it works on many platforms. <mark_weaver>so yeah, it's important for us to make guile-2.0 easy to install on as many platforms as possible. <zacts>yeah, this will allow things like a newer lilypond when it switches to guile-2.0, guilemacs, etc.. <zacts>but I'll probably be working on guix by then. I'm growing tired of FreeBSD ports.. <mark_weaver>well, if this could be your final act on FreeBSD ports, it would be a good one :) <zacts>yeah, it will allow for people to more easily import a future lilypond / guilemacs (eventually?) / guile-wm (eventually?) / ... <zacts>so in a way I'm really doing work to port many programs at once with this one <zacts>btw, mark_weaver I think the build is almost done, so my gut feeling is that I won't need you until tomorrow. <zacts>so I don't remember your schedule; I don't want to keep you up for my patch. <zacts>and I have homework to do, so I'm afk. <zacts>laters. I will pastebin my results and link here directly to mark_weaver <mark_weaver>zacts: okay, thanks! any info about failing tests would be helpful. (from "make check") <Madsy>mark_weaver: Where did all the thread settings go in guile-2.0.9.241-950a? <Madsy>Is enabling the thread feature and enabling multithreaded guile considered the same thing now? <mark_weaver>Madsy: the thread settings shouldn't have been there. it was a bug. <mark_weaver>Madsy: with --without-threads to build without threads. <Madsy>So the thread package is implicitly always enabled when building guile with thread support? <Madsy>Whether (provided? 'threads) returns #t or #f <Madsy>I have to build the latest guile locally too. It got stuck on compiling .go files when I last cross compiled <Madsy>So I assume the latest .scm sources contains code which didn't work well with e1bb <mark_weaver>yeah, you're supposed to use the exact same version for the native and cross builds. I'm not sure off-hand when you can get away with fudging that. <Madsy>Yep, that's what I've done so far <Madsy>Building e1bb while having e1bb on the system <Madsy>I'm building 950a locally right now and it gets stuck on compiling psyntax-pp.go <Madsy>I just said I used to build e1bb before because that's what I had locally <Madsy>But now I'm installing the latest so I can try that one <Madsy>Should it use several minutes? <Madsy>Seems like compiling the new sources take a ton of more time than before <Madsy>In 2.0.8 and 2.0.9 stable, each .go took like 2 seconds to compile <mark_weaver>I assure you, the first few files were never that fast. <mark_weaver>the issue is that the compiler itself has not yet been fully compiled, so it's very slow at first. <mark_weaver>in fact, at that point, *none* of it has been compiled. <Madsy>Hm.. is the process different in how much time it uses when you compile locally, and when you have a GUILE_FOR_CC ? <mark_weaver>now, if you have a fully built guile and use it to compile just that one file, it's fairly fast. <mark_weaver>e.g. when cross-compiling psyntax-pp.go using the fully-built native guile. <Madsy>Ah, right. That explains it. I was thinking of when cross compiling <zacts>mark_weaver: so far so good! it builds, now I'm doing 'make check' <zacts>and then I need to figure out how to make freebsd ports install it. <zacts>then I'll run it, and try out the repl <zacts>mark_weaver: yeah, but I think I mixed downloaded packages with user built packages, which can mess up pkgng <zacts>pkgng = freebsd ports package program *zacts can't wait for a guix distro.. like totally. <mark_weaver>ah, so freebsd ports allows the creation of binary packages that can be downloaded by users? <zacts>mark_weaver: it does now with the new pkgng <mark_weaver>how does that generally work? "make install" with DESTDIR set, perhaps? <zacts>pkgng 1.3 will allow for mixing of user built packages and downloaded packages, apparently. I'm not an expert yet on pkgng. <mark_weaver>well, if you're on your way out of the freebsd world, no need to learn it, I suppose. <zacts>the first two lines explain how DESTDIR / PREFIX work <zacts>mark_weaver: yeah, well I'm not totally leaving the BSD world. I'm still interested in learning how OS internals work with minix, and I may study the BSD kernels a bit for educational reasons. <mark_weaver>Guile's "make install" honors DESTDIR, and I'm reasonably sure that's the right tool for creating a binary package. <zacts>but as far as what I really want to work on, I'm looking at guix, scheme, and possibly Linux kernel, minix, or HURD <zacts>Minix3 is just fun. I can't let it go, I'm learning so much with it, and it's totally just fun to work on. <zacts>but you should expect to see me import stuff like i3wm, dwm, etc.. to guix soon. <zacts>I'm really wanting to make guix my primary project to contribute to right now. <zacts>I'm just finishing up this BSD stuff right now, due to previous 'I will do this' promises. so I've got to do it even though it's drugery. <mark_weaver>just keep in mind that it's still rough around the edges at this point :) <mark_weaver>but things are moving fast and it has huge potential, IMO. <zacts>mark_weaver: oh, yeah. I'm using slackware, perhaps I'll try out dragora. I'm just looking for a fun project to work on while I learn SICP/scheme, comp sci, programming.. <zacts>something to work on while in school, until I gain enough experience to work on things like HURD / C / haskell / system patches. <zacts>but project ideas I'm totally interested in, within a few years, would be to import OpenBSD pf into minix / hurd. import NetBSD tcp stack into minix3, and possibly implement / import pf into HURD somehow. <zacts>that's the big goal I have in the back of my mind.. <zacts>but I have tons to learn.. I'll probably be hanging out on #scheme idling and asking questions. <zacts>I'm far more interested in scheme. <zacts>(ok enough of my ramblings :-) <mark_weaver>it's good to know C for understanding of low-level stuff, but for most programming it's better to use something much higher-level, IMO. <b4283>zacts: what's this pf you're talking about? the firewall? <zacts>mark_weaver: well, the only reason I want to learn C is for OS level stuff, and UNIX. <Madsy>mark_weaver: Ahh.. finally! I got guile-2.0.9.241-950a working :) <Madsy>mark_weaver: All the bugs you fixed seems to have made a difference. In addition, when building libgc for Windows, one should use the Makefile.direct makefile, not ./configure <zacts>mark_weaver: isn't part of guile written in C? <zacts>if I ever want to contribute to guile, C would be good to know.. <zacts>but that's lightyears ahead of where I"m at now <mark_weaver>initially, it was almost 100% C. but now it's less than 50% C, and things are rapidly moving in the direction of more Scheme and less C. <zacts>ok, sorry for my flood. I'm just totally excited about being almost done with my port <mark_weaver>Madsy: ah yes, I tried using that in my most recent attempt, but gctest still failed. I must have done something wrong. <mark_weaver>Madsy: but then, I was trying to build with threads that last time. <Madsy>gctest fails in Wine, but not in a VM like VirtualBox or on a real machine. <mark_weaver>Madsy: thanks very much for testing that and getting it to work. hopefully you have some record of what you did this time :) <Madsy>I do, and I'm writing it up for future reference <mark_weaver>Madsy: excellent. please send us a copy of your notes when you get a chance. <zacts>mark_weaver: all tests passed, except for the turkish language bindings. <zacts>same as before, there were warnings and I can paste those tomorrow, but the only '^FAIL' lines were four turkish binding failures due to a FreeBSD bug. <zacts>so I think upstream 2.0.10 will be good to go for FreeBSD <zacts>I'm going to test build it on a build farm for FreeBSD-8 FreeBSD-9 FreeBSD-10 and FreeBSD -current <zacts>but I'm done with this for tonight <Madsy>No problem. I'm glad to have something useful to show, for once. <mark_weaver>Madsy: is there some important relation between the ${PREFIX} and /home/madsy/mingw ? (you used the latter as your --with-sysroot setting) <mark_weaver>Madsy: also, are you sure you used --disable-threads ? the intended option is --without-threads. I'm not sure what --disable-threads does, if anything. <Madsy>I updated the gist. It shouldn't contain any of my paths now <Madsy>When I wrote $PREFIX, I meant the prefix for where you have ./include and ./lib for the rest of the dependencies <mark_weaver>Madsy: is there a new URL for the updated gist? I just refreshed it, and it still has "--with-sysroot=/home/madsy/mingw". <Madsy>And I set --prefix to $PREFIX/deploy, so that's where everything gets installed <Madsy>I'm not sure if --with-sysroot makes any difference. I set the include and library paths in CFLAGS and LDFLAGS anyway <mark_weaver>I confess, I've never used --with-sysroot. I don't know what it does. <Madsy>And yeah, I meant --without-threads. I guess I was lucky and got the same result (null threads) anyway <Madsy>--with-sysroot is supposed to use that path as a root for searching for libraries and includes. But it doesn't seem to work all the time. <Madsy>--with-sysroot=/home/madsy is supposed to look in /home/madsy/include and /home/madsy/lib <saul>When declaring a foreign function, how do I specify a return type of 'void' to 'pointer->procedure'? <saul>Nevermind, it apparently uses void :blush: <mark_weaver>pass 'void' as the first argument to 'pointer->procedure :) <Madsy>mark_weaver: I have a questions regarding finalizers. Since OpenGL doesn't have any complex types, I just implemented OpenGL ad-hoc, so that its "objects" are integers, just like when using the C interface. But how do I make sure the resources are always cleaned up? <Madsy>Can I define a finalizer for a 'place' in Scheme? <Madsy>Or am I forced to make a complex type in C if I need a finalizer? <mark_weaver>however, there has to be some GC-heap-allocated object. you can't detect when an integer becomes no longer referenced. <Madsy>When you say integer, do you mean literals, variables or both? <Madsy>Are you saying that say an object in a let form holding an integer value isn't GC-heap allocated? <mark_weaver>it may or may not be. the compiler tries to allocate it on the stack. <Madsy>But if the integer is inside a list or a part of a bytevector, that would work right? <mark_weaver>yes, then you could use a guardian to protect the list or bytevector. you could also use SRFI-9 records. <Madsy>Or if I closure over some integer and returns a function which has returns that integer, I could add the function to the guardian <mark_weaver>if you want automatic cleanup, I think you need to change your APIs so that instead of using integers for these handles, they are opaque objects containing the integer internally. and then you use a guardian on the opaque object (probably a SRFI-9 record containing just one field) <Madsy>Yeah, I think capturing it will be pretty clean <mark_weaver>I'm not sure why you prefer a procedure over a record. <mark_weaver>records are nice because you can print them nicely, you can do type checking, etc. <zacts>they ran into problems, and their computer almost deadlocked when trying to build something, I think doc or something.. <zacts>this was from Homebrew on OSX <mark_weaver>we don't support guile-1.8 anymore, not for several years. <zacts>they mentioned that -R was kind of messy, don't know if you if you guys have fixed this in guile-2.0, but it may be some constructive criticism that can improve guile. <zacts>so guile-1.8 is totally legacy now <mark_weaver>zacts: The "default_conversion_strategy_var" problem that was referenced in that log had to do with clang 3.4's preprocessor acting differently than all other preprocessors we've used in the past. I fixed the build with clang 3.4 very recently. <zacts>alright, yeah. I'm going to share my patches with them, once I get them to build on redports. <zacts>mark_weaver: maybe, I just wanted to share this with you in case it might lead to improvements. <zacts>but perhaps dim is wrong too. :-) <zacts>I'm not really agreeing nor disagreeing with him, I'm just sharing information so we can have the best 2.0.10 release possible <mark_weaver>I have no idea what is this "-R" that he keeps referring to. <zacts>oh, yeah. I'm finding out. I don't know either. <zacts>you know it's kind of odd, I've noticed more BSD devs are more opinionated about their software and jump to conclusions about other software, often without justification. <mark_weaver>their attitude does not make me inclined to spend time on them. <zacts>yeah, but I just wanted to share the information about their build failures. someone linked me that log I showed you. I don't normally hang out there. <zacts>[14:44] <@dim> it's actually not a flag that is in the gcc manual, but for historic reasons gcc passes this through to the linker <zacts>[14:44] <@dim> for GNU ld, -R can mean either -rpath (which is the meaning most people think it has), or --just-symbols, depending on the argument.