IRC channel logs


back to list of logs

<davexunit>it took me about 3 hours to build guile master
<davexunit>on a core i5
<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>wingo: I don't have a minimal test case for this yet, but here's an out-of-context procedure and its associated disassembly
<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
<madsy>roelj: Is the documentation example useful at all?
<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>I'm at a total loss.
<davexunit>this is the most baffled I've ever been with a guile issue
<davexunit>it has to be my fault..
<davexunit>yup, it's my faul.t
<lfam>Yay! You figured it out
<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
<davexunit>now I can move onto other issues
<davexunit>like why my simple example segfaults
<lfam>Dive into C
<lfam>That's why you got into Guile, right? ;)
<davexunit>all my meshes are rendered wrong
<davexunit>most examples just show a black screen
<davexunit>wow, this is weird.
<davexunit>it *doesn't* segfault when run with strace
<lfam>Haha, that's a fun one
<lfam>Just ship it with an strace wrapper ;)
<davexunit>hmm, the crash appears nondeterministic
<davexunit>and happens during a bytevector-copy! call
<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>I wonder if this is another compiler bug
<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
<davexunit>needs further investigation...
<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>and Artanis borrowed this method
<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
<nalaginrut>ACTION will send a mail
<nalaginrut>alright, I found this could be help
<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 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
<amz3`>héllo :)
<rjmacready>amz3`: hî ! :)
***micro` is now known as Guest42042
<davexunit>alright, I've got another guile 2.2 stumper for yoy guys
<davexunit>fire up your guile 2.2 REPL and do this:
<davexunit>,use (system foreign)
<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>this is not so on guile 2.0
<davexunit>I did a 'git blame' on the 'sizeof' implementation, it hasn't changed since 2012.
<davexunit>so I guess the problem lies deeper.
***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>for that user group, that is.
<davexunit>oh wait, I mixed some stuff up. it was to libreplanet-discuss. -_-
<davexunit>ACTION is oblivious
<zacts>hi guilers