<davexunit>it took me about 3 hours to build guile master <madsy>I'll be pleasantly surprised if my notes from 2 years ago still works with little modification <davexunit>man this srfi-4 issue continues to confound me <davexunit>in the disassembly output, I see things like: <davexunit>45 (module-box 6 37833 26487 37831 #t);; `(@@ (guile) u32vector-set!)' <davexunit>so, I can understand why I see the error I do, but I don't know why it happens <roelj>I've been staring at my screen for an hour now.. Can anyone explain how let-syntax works? Has anyone blogged about this? <madsy>roelj: Yeah, the documentation is a bit short on that one <davexunit>I just can't get *any* other module to exhibit the problem I am having. <davexunit>if I copy/paste the *same* code into a different module and compile it, the disassembly is correct. <davexunit>this is the most baffled I've ever been with a guile issue <davexunit>I screwed something up and the build system was using the old, broken guile <davexunit>so all of my tests with 'guild compile' and 'guile' were using the new guile, and thus worked <lfam>That's why you got into Guile, right? ;) <lfam>Just ship it with an strace wrapper ;) <davexunit>sometimes a loop counter of mine goes to 234, and the program runs without segfaulting but still isn't right <davexunit>but when the loop counter goes to 235 it segfaults <davexunit>wingo: it appears that I can corrupt memory with a bad bytevector-copy! <davexunit>in my case, it seems to be causing a non-deterministic error where sometimes the loop counter goes beyond what should be the maximum value <davexunit>removing the bytevector-copy! call from the loop body makes it deterministic again. <davexunit>this bytevector pokery wasn't an issue on guile 2.0 <nalaginrut>gcc in Android NDK is deprecated now, I still have no better alternative of mobile OS, I don't want to use Android if any possible... <nalaginrut>mark_weaver: is it any possible to improve pointer->procedure to keep `errno' safe when there's async? I'm going to write cFFI to parse C code directly, but we have to find a way to handle `errno' properly in generic purpose. <nalaginrut>mark_weaver: the current way to handle `errno' in Guix limited the context not to use async call <nalaginrut>it's fine for guix and artanis, but if there's guile-cffi, it has to keep `errno' safe in any generic usage <Chaos`Eternal>and i wrote guile-inotify2 almost one year ago and pending on this problem <madsy>Hm.. my magical incantation from two years ago for building libgc doesn't seem to work for gc-7.2f <madsy>When cross-compiling libgc, do I have to build libatomic_ops in a special way and seperately from libgc itself? <madsy>I remember I used Makefile.direct to cross-compile libgc before, but libatomic_ops only uses autoconf. So it dies when CC and HOST_CC are set directly ***micro` is now known as Guest63870
***micro` is now known as Guest85969
***micro` is now known as Guest42042
<davexunit>alright, I've got another guile 2.2 stumper for yoy guys <davexunit>(= (sizeof (list uint32 '* int)) (sizeof (list uint32 '* int int))) <davexunit>the result of this the above snippet is #t on both computers I have access to <davexunit>I did a 'git blame' on the 'sizeof' implementation, it hasn't changed since 2012. ***micro` is now known as Guest39402
<davexunit>sneek: later tell wingo looks like I've found another interesting bug: (= (sizeof (list uint32 '* int)) (sizeof (list uint32 '* int int))) ***micro` is now known as Guest11063
***micro` is now known as Guest39776
***micro` is now known as Guest66017
***rlb` is now known as rlb
<davexunit>interesting, the latest person posting on help-guix also posted on the Boston Linux and UNIX user group's mailing list. <davexunit>they probably heard of Guix because I am the next scheduled speaker. <davexunit>oh wait, I mixed some stuff up. it was to libreplanet-discuss. -_-