IRC channel logs

<tohoyn>sneek: botsnack

<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

IRC channel logs

2020-12-19.log