IRC channel logs

2018-01-06.log

back to list of logs

<davexunit>do any of the "instruction explosion" things apply to the 2.2 series?
<davexunit>I've got some hella bad bytecode and I'm not sure what percentage is my fault
<davexunit>why on earth would I see an f64->scm instruction followed by an scm->f64 instruction using the same register when that register was not used for an instructions in-between?
<davexunit>any instructions*
<davexunit>this is happening all over the place. 1) read unboxed float from bytevector 2) box float 3) unbox float 4) do unboxed op like bv-f32-set!
<amz3>I have the following C definition https://dpaste.de/4wxP
<amz3>I am trying to create bindings for that function
<amz3>when i declare that absolute-time-get return an uint64 everything seems fine
<amz3>but when I declare that it returns a raw pointer, and pass the pointer to (pointer->bytevector pointer 8) it fails with a segfault
<amz3>any ideas?
<amz3>maybe the 'struct { abs_value_us uint64 }' is optimized into the eqv of 'typedef uint64'
<amz3>or something
<amz3> https://stackoverflow.com/questions/19887384/do-c-compilers-optimize-structs-with-a-single-member
<amz3>seems like single int member struct is the same as int
<amz3>in most cases...
<amz3>oh it's possible to use a custom event loop in gnunet client programs
<amz3>at last I wrapped my head around how gnunet works and started an alternative set of bindings
<amz3>this was not my week end plan... but anyway... it's more useful :)
<amz3>I think the new code is less confusing
***w2gz is now known as w1gz
<manumanumanu>Where does guile look for libraries when I do dynamic-link?
<manumanumanu>I am trying to link to libsodium which is installed using both apt (an older version) and guix
<manumanumanu>and for some wonky reason it doesn't work
<manumanumanu>It might also be my system which is old and tired
<manumanumanu>but ldconfig shows it (the apt version)
<rlb>manumanumanu: not sure about current guile, but I think I used to set the LD_LIBRARY_PATH to pick up various libs.
<rlb>manumanumanu: might also try strace to see where it's looking.
<manumanumanu>rlb: but it should be properly in my load path :(
<rlb>Well, strace will tell you where it's actually looking, and what it's looking for (i.e. what specific filenames), and you could also try what looks like a redundant LD_LIBRARY_PATH setting to see if it has an effect, then try to figure out why if it does.
<rlb>...perhaps something like "strace -f ... 2>&1 | grep foo" if the lib has foo in the name. Can also be more discriminating via -e open, -e stat, etc.
<rlb>(or just save the output to a file via -o trace.log and use less, emacs, whatever to poke around)
<manumanumanu>rlb: thanks. It is very weird. It is looking in my some guix directories, but not in my profile lib dir. IÍ„'ll ask in #guix
<mwette> manumanumanu: I believe DYLD_LIBRARY_PATH and (assq-ref %guile-build-info 'extensiondir) and (assq-ref %guile-build-info 'libdir) will work