IRC channel logs

2020-12-19.log

back to list of logs

<tohoyn>sneek: botsnack
<sneek>:)
<lampilelo>can anyone reproduce this? i don't know if it's a bug or if my environment is messing things up: https://dpaste.com/3EK9NY3DR
<RhodiumToad>what guile version?
<lampilelo>3.0.4
<RhodiumToad>what I get is an unending stream of "In procedure %readline: readline is not reentrant"
<RhodiumToad>oh, you expect it to be run non-interactively?
<lampilelo>no, interactively
<RhodiumToad>whatever, I can reproduce it at the REPL by using guile -q and omitting the (activate-readline)
<lampilelo>something's up, definitely, this example should just work, or am i using it wrong?
<lampilelo>this works for me: https://dpaste.com/7D9BLJCFV
<RhodiumToad>aha.
<RhodiumToad>well, I can't see how that could ever have worked
<RhodiumToad>basically, filename-completion-function is simply not handling the NULL return from rl_filename_completion_function at all
<lampilelo>yeah, i wasn't sure if it's a bug because it seemed that the completion function wasn't getting called with state set to false at all, and from what i gathered it should on the first call
<lampilelo>if you manually call (readline-completion-function "" #f) and then call (readline-completion-function "" #t) it works fine, the error appears if the call with #t is the first one
<RhodiumToad>it doesn't work fine
<RhodiumToad>keep calling the #t one repeatedly
<RhodiumToad>it'll iterate through the files in the dir, and then error out after the last one
<lampilelo>that's because a higher level function should check if the result of the completion function is a string or #f, on #f it should stop iterating, so it's expected behavior
<lampilelo>an*
<RhodiumToad>but it never returns #f
<lampilelo>oooooooohh, you're right, so the lack of the check for NULL is THE bug
<lampilelo>i
<lampilelo>i'll test it later and send a patch to bug-guile
<tohoyn>daviid: any comments about the debianized G-Golf?
<soda__hobart>what would be the best way to create a SCM list from the contents of a small C array of primitive datatypes, using the C api?
<soda__hobart>i've looked at the documentation and i'm not quite clear on what to do
<RhodiumToad>C array of values of some common type, like ints?
<soda__hobart>yep
<soda__hobart>maybe like a dozen elements, in most cases
<soda__hobart>in a few cases, maybe 100 or so
<RhodiumToad>hm, for a really long array then making a bytevector and converting to a list might be good, but that may be overkill for a dozen
<soda__hobart>yeah, the bytevector thing was the only thing in the docs that i could find constructors and stuff for
<soda__hobart>well, i found the C function to create a scm list
<RhodiumToad>scm_list_n ?
<soda__hobart>but i got confused by the `lstlst` parameter in the list append function
<RhodiumToad>honestly for a short list you'd probably just want to cons it up from the end
<soda__hobart>yeah, i thought of that too
<soda__hobart>should i do it recursively?
<RhodiumToad>I'd just iterate
<soda__hobart>cool
<RhodiumToad>something like lst = SCM_EOL; for (i = n-1; i >= 0; --i) lst = scm_cons(whatever,lst);
<soda__hobart>go from the back, yeah
<soda__hobart>cool, thanks a bunch
<soda__hobart>yeah, it would have taken me a minute to figure out that SCM_EOL terminator, i appreciate that
<RhodiumToad>it's in the manual under "General Libguile Concepts"
<soda__hobart>oh yeah, i have that handy. i'm pretty new at C, so it's a bit much to assimilate at tmes
<soda__hobart>it seems pretty easy and straightforward on the whole, though.
<soda__hobart>i like learning C, too, it has taught me a lot about the unix-style systems, like what file descriptors and sockets are, and why EVERYTHING_IS_UPPER_CASE
<soda__hobart>sweet, it works