IRC channel logs
2020-12-07.log
back to list of logs
<tohoyn>daviid: configure works with both guile-3.0 and guile-2.2 installed when I change GUILE_PROGS([2.0.14]) to GUILE_PROGS([2.2]) <tohoyn>daviid: I think there is a bug with the m4 macros. GUILE_PROGS([2.0.14]) should work, too. <tohoyn>daviid: I think GUILE_PROGS should use the version determined by GUILE_PKG <leoprikler>tohoyn: yep, it's GUILE_PKG([3.0 2.2]) followed by GUILE_PROGS <tohoyn>leoprikler: GUILE_PROGS without arguments? <leoprikler>In that case guile-filesystem simply can't be ported that far back <leoprikler>./configure: line 2401: syntax error near unexpected token `3.0' <leoprikler>./configure: line 2401: `GUILE_PKG(3.0 2.2 2.0)' <leoprikler>civodul: so unless you pack your own guile.m4, that won't work <leoprikler>autoreconf -vif; configure; make; when building against Guile 1.8 <civodul>oh yes, you have to use today's guile.m4 <civodul>the macro in that guile.m4 deals with 1.8 <daviid>tohoyn: the actual g-golf configure.ac file is correct <daviid>the arg of the GUILE_PROGS macro is to determine the minimum version required to compile/run g-golf, so for example, it wouldn't worj if it finds you have 2.0, but version 2.0.13 <daviid>the g-golf guile.m4 macros is 'nearly the latest' :), the only diff is in comments and the default required version if unspecified - but the machinery that checks for major, minor and micro version is identical (that 'machinery' was patched before, g-golf has that patch) <spk121>hi, does anyone happen to know if Guile will build using only minigmp, instead of the full gmp? <wingo>spk121: we should certainly make it possible! <civodul>minigmp was designed largely so Guile could use it <wingo>i would really like to rework our GMP usage to use the "nail" API directly <spk121>wingo: if no one has tried it, maybe I'll give it a go to see what happens *dsmith-work has emojify minor mode enabled <rlb>civodul: yes, it's straightforward (should be), and glad you pinged me. I'd been meaning to ping you and kept forgetting. <rlb>I can get you better instructions later, but here I can see it in a debian (bullseye I think) vm after an "apt build-dep guile-3.0/experimental" (with some pins to avoid pulling in much else -- suspect that's mostly just relevant for the libgc dep), then put the src tree in /dev/shm as /dev/shm/gnutls/gnutls-X.Y (as apt-source does -- you could just apt-source from /dev/shm/gnutls too), then (cd /tmp && ln -s /dev/shm/gnutla .) and then <rlb>just build normally and then try running the tests with "... < /dev/null". Hangs every time in reauth.scm. <rlb>I haven't had time to check for example, whether you really need to be in /tmp/ with the symlink, etc., but that arrangement (which I guess is one some of the build deps use) reliably hangs. <rlb>s/build deps/buildds/ <rlb>I toyed with it a bit, but also didn't have time to track it down. It appears to be swallowing an exception when it hangs. <rlb>(from gnutls maybe, something about the keys/files) <rlb>I don't remember for sure. <rlb>Feel free to shout and I can set it back up tonight or tomorrow night (CST) and get better/additional information. <civodul>i was looking for instructions not involving Debian, if possible <civodul>alternatively, if you can attach gdb to the two reauth.scm process and grab a backtrace, that could help! <rlb>Even with the same libgc and guile version and with those steps (i.e. from /tmp/ symlinked to /dev/shm)? <rlb>also of course critical to "... < /dev/null" <rlb>when running the build/test, though I can reproduce it afterward with just that single test an d< /dev/null, so might not need < /dev/null for anything other than that bit. <rlb>Certainly, happy to help -- I'll look later, but I can't recall how I managed to get the error output last time, i.e. everything's silent on the terminal. I can't recall whether I found it in a log, or hacked up the test to stash it somewhere. <civodul> /tmp -> /dev/shm and "< /dev/null" make no difference for me <rlb>OK, I'll try to capture the error later, and also double-check the process. fwiw in addition to the buildds, I was able to reproduce it in a vagrant vm (sometimes use those for quick testing) via "vagrant init debian/testing64"... If you have that available somewhere, I could likely provide fairly precise reproduction steps. (Or of course for any debian bullseye host you didn't mind mangling a bit wrt package installs.) <rlb>Suppose of course the debian package build process/flags/whatever might also be involved, but as yet it "feels" like a race of some sort. <tohoyn>str1ngs: I have made initial debianized version of G-Golf. I can send the files to you if you want them. <str1ngs>sneek: later tell tohoyn that would be very useful. <fnstudio>i know lset-intersection but not sure how to use it in this particular case <fnstudio>as if i go through the (outer) list with `apply` then that will result in `lset-intersection` being fed a list of lists instead of the unpacked elements <fnstudio>is there an idiom/approach to this that i should look up/into? <justin_smith>fnstudio: call apply intersection on each sublist, or use map across them to get the list of intersections <justin_smith>fnstudio: also you have too many ', ' is not a syntax for "make a list", it prevents evaluation recursively and only needs to be used once <justin_smith>fnstudio: (map (lambda (l) (apply lset-intersection eqv? l)) '(((1 2 3) (1 3 4 5 6)) ((1) (1 2 8) (1 9)))) => ((1 3) (1)) <justin_smith>(that's after running (use-modules (srfi srfi-1)) of course) <fnstudio>justin_smith: that's awesome! thanks so much <justin_smith>fnstudio: I'm realizing what I said about single-quote "'", would have been more clear if i'd, um, quoted it <fnstudio>justin_smith: :D, no that's fine, thanks, i'm still awkwardly moving my first steps with quoting/quasiquoting/etc <justin_smith>fnstudio: the idea is '(1 2 3) and ''(1 2 3) are not equal, and