<mark_weaver>zv: sorry, I had to go afk for a bit... to be clear, I didn't write the implementation of SRFI-64 either. I submitted some minimal patches upstream to make it work better with Guile 2, which were accepted upstream, and then I imported the upstream implementation into Guile. <mark_weaver>anyway, can you show me some example code that demonstrates the problem you're seeing? <mark_weaver>preferably a self-contained example that I can try running on my system <zv>the basics all work (test-equal '(1 2 3) '(1 2 3)) etc <zv>git@github.com:zv/SICP-guile.git <zv>will automatically run the tests <zv>git clone git@github.com:zv/SICP-guile.git <zv>you can add this to tests/evaluator.scm: (test-eq (query/eval '(job ?x (computer programmer))) '((job (Fect Cy D) (computer programmer)) (job (Hacker Alyssa P) (computer programmer)))) <zv>(just to demonstrate that no macro is causing this issue, etc.) <mark_weaver>sicp4.scm doesn't appear to use SRFI-64, but rather defines its own 'test-equal' macro <zv>mark_weaver, i thought you might say that <zv>so here it is with raw test-equal <zv>oh, i may have added test-equal into sicp.scm as a stopgap measure, feel free to remove that as well <zv>feel free to remove the test-runner, etc. none of that has mattered in the past <mark_weaver>zv: so, one thing I notice is that you've reversed the arguments to 'test-equal'. the expected value comes first, and the test expression follows. <mark_weaver>srfi-64 will only guard against exceptions from within the test expression. <mark_weaver>(I haven't tried running it yet; I tend to be careful what I run on my machine :) <zv>mark_weaver: nothing goes wrong, it simply doesn't do anything at all. <zv>i just switched guile to 2.0.12 and now it says "unbound variable test-equal" <paroneayea>what do I do in the case of trying to call pointer->procedure on something that has one of its own defined types (I'm guessing a struct) as an argument? <paroneayea>and it's not a pointer to a struct, you pass in thte struct <zv>mark_weaver although your point about the test v. actual expressions is a good point <mark_weaver>paroneayea: if a struct (as opposed to a pointer) is passed as an argument, you need to know the details of that struct type to make the call. <paroneayea>which says "CTX maybe set to NULL", but gcry_ctx_t appears to be a struct <paroneayea>ACTION apologizes for being ignorant about C-land <mark_weaver>"typedef struct gcry_context *gcry_ctx_t;" defines 'gcry_ctx_t' to be a pointer to struct gcry_context <zv>ok mark, turns out im the moron here <zv>you were totally right about the expected/test-expr <zv>yes, and what remained was because i had failed to realize that use-modules wouldn't override an existing method definition ***logicmoo is now known as dmiles
<OrangeShark>paroneayea: I am just working on adding more stuff to the haunt docs <paroneayea>ACTION segfaults guile by not knowing what e's doing with the FFI <paroneayea>mark_weaver: davexunit: don't suppose either of you (or someone else more knowledgable about C / the FFI) would have any idea what I'm doing wrong that's crashing guile? I have a *guess* <paroneayea>my guess is that passing in a bytevector pointer for "const void *KEY" isn't actually working <paroneayea>though maybe I should be calling gcry_kdf_derive to derive the key <paroneayea>I figured that was just for the PKI stuff, not HMAC, but I don't really know. <paroneayea>I forgot to (dereference-pointer mac) when calling pointer->mac