***catonano_ is now known as catonano
<manumanumanu>mwette: regarding the syntax hygiene: I am having a look at quasisyntax to see if I could make a hygienic version of it. srfi-72 is based on explicit renaming, which I suspect will be hard to bolt on :) <mwette>manumanumanu: Good luck. Looks very non-trivial. *rlb thinks our tests should print the expected and actual values when there's a failure. r7rs.test doesn't yet (I think). <dsmith>For any test error reporting in general. <rlb>(Also want line numbers or distinct names right now...) <spk121>Hmm. This is a new one. guild compile bombs with ... <spk121>ice-9/boot-9.scm:1669:16: In procedure raise-exception: <spk121>Throw to key `numerical-overflow' with args `("ash" "Numerical overflow" #f #f)'. <rekado>mwette: I’m working on Guile bindings to DRMAA. The implementation of that library is usually not available at build time. When I add “#:library '("libdrmaa.so")” to the FFI file it will try to find it at build time. <rekado>is there a way to appease compile-ffi that the library will be available at runtime? <rekado>I’m now using (list (or (getenv "GUILE_DRMAA_LIBRARY") "GUILE_DRMAA_LIBRARY unset")) <rekado>it’s probably not a good idea, but it’s enough to continue hacking <mwette>in the .scm, by hand change (define ffi-drmma-llibs ...) to (define ffi-drmma-llibs (delay (list ...))) and in the rest of the file replace ffi-drmmalllibs with (force ffi-glib-llibs) <mwette>Maybe that should be the default behavior. <roptat>jonsger, when compiling some of my own code <roptat>loading the module in the repl and using that code is fine though, so I'm not sure what's wrong <mwette>or maybe there is an eval-when solution <mwette>rekado: can you try 'guild compile-ffi -X drmaa.ffi' That will not compile the generated .scm file. (Also, try 'guild compile-ffi -h') <mwette>rekado: I've made the promise wrapper around dynamic-link the normal behavior now. It should appear in v1.03.1 (no release date planned yet)