IRC channel logs

2025-01-17.log

back to list of logs

<apteryx>ArneBab: did you see #75041?
<apteryx>it's a follow-up to the recently merged SRFI 64 doc
<apteryx>adding some of your suggestions (mostly examples)
<apteryx>bug #67255 has a small patch that would be nice to merge too
<apteryx>fixing the 'rename' directive for r7rs' define-library
<lechner>Hi, is there an intuitive explanation of what happens when with-exception-handler is annotated with #:unwind? #t?
<ArneBab>apteryx: when running the tests with your patches, I get the error srfi-modules.texi:5526: unknown command `iterate'
<ArneBab>Did you want @itemize @bullet ?
<stevelitt>Terminology question: In (display "Hello World") , what is the thing delineated by parentheses called? What's "display" called? What's "\"Hello World\"" called?
<lshoravi>stevelitt: Not sure I understand your question, but there could be multiple answers depending on context. `display` could be called the procedure, and `Hello World` would be its first argument
<lshoravi>stevelitt: the entire form could be called a s-expression, in this case a procedure call
<stevelitt>Thanks lshoravi . So a procedure call is a subset of s-expressions, is this correct? Also, for practical purposes in Guile, an s-expression is also a list, possibly multilevel, is this correct?
<lloda>subset isn't really the word. The s-expression is syntax for the procedure call
<stevelitt>lloda, are you saying that ("Peter" "Paul" "Mary") isn't an s-expression?
<stevelitt>I mean we all know ("Peter" "Paul" "Mary") is a list, but is it also an s-expression?
<stevelitt>Oh, I might have been wrong about that.
<lloda>that is both, but it's not what i meant. The exact same s-expression can be syntax for a procedure call, for a macro call, or for plain data, depending on context. These things are not 'kinds' of s-expressions
<stevelitt>Thanks lloda. Is the ability of the same s-expression to be a procedure call, macro call or data called "Homoiconicity"?
<ArneBab>stevelitt: to some degree yes. Homoiconicity is that code looks the same as data: it’s all just s-expressions. But for example a string (i.e. "Hello World") cannot be a procedure.
<ArneBab>stevelitt: homoiconicity in the case of Scheme also means that if you put a macro around some code (e.g. (my-macro (display "Hello"), then the macro receives the code as structured data that it can modify.
<ArneBab>stevelitt: and the result of the macro is executable code again. And the macro can just call procedures that work on other data (i.e. drop the first element in a list) to modify the code.
<ArneBab>stevelitt: here’s an example that replaces the first element with the write procedure: (define-syntax-rule (writer (code ...)) (apply write (cdr (list code ...))))
<ArneBab>(writer (display "Hello World")) ⇒ "Hello World", while (display "Hello World") ⇒ Hello World ← without the quotes.
<lechner>Hi, what's a good way to keep a reference "alive" across a shared library call, please?
<rlb>lechner: in C or in scheme (and what do you mean by "alive").
<rlb>gc-wise?
<lechner>rlb / in scheme. i have reason to suspect that some of these pointers or other nearby pointers are gc'd before conversation-function runs https://codeberg.org/lechner/guile-pam/src/commit/861e2e9b282e7d919240aa3d79f7b7d2dc66964d/scm/pam.scm#L165-L168
<lechner>rlb / i did this elsewhere but never checked if it is optimized away https://codeberg.org/lechner/guile-pam/src/commit/861e2e9b282e7d919240aa3d79f7b7d2dc66964d/scm/pam/legacy/module.scm#L59
<rlb>Is that trying to preserve "options"?
<rlb>And is the call you're talking about that final call on line 61?
<rlb>I think we might have a bug when displaying port (fport) names. r4rs.test is crashing on riscv64 in a porterbox chroot in ttyname() in fport_print() with ENODEV, and it looks like that's an expected condition. i.e. just because isatty() is true, doesn't mean that ttyname won't return ENODEV.
<rlb>(See the NOTES in ttyname(3) and the description in info libc.)
<lechner>rlb, not line 61. In the second link, it's across the call to entry-point (in substance but not approach, per mwette's recommendation). In the first link, it's across the call to conversation-function
<rlb>Ahh, I might not know the domain well enough -- i.e. this is relevant you your earlier discussions. In general, though, anything "bound" at the scheme level throughout the period when it's being used on the "c side" should be safe from gc, I think. i.e. if it's a scheme argument, or let bound, or...
<lechner>rlb / okay, thanks!
<mwette>Say `foo' is a ffi i/f to C function `foo'; when you execute `(let ((a (string->pointer "hello"))) (foo a))' can `a' (i.e., "hello") be GC'd before foo completes? If so, then there needs to be something after (foo a) that references `a', right?
<mwette>There should be a simple way to make a reference that can't be optmized away. One can use guardians, but it'd be nice to have a single call.
<mwette>rlb: Oh, so you are saying guile will not collect args to c-calls?
<mwette>or better said, args to c calls are marked across those calls.
<rlb>mwette: I thought the *scheme* side would keep any given binding throughout its entire scope -- but the C side, of course, can much less generous. Hence all the scm_remember_upto_... calls.
<mwette>rlb: I'm curious how that works. I guess as long as a reference to "hello" is on the stack then it should be OK. So in lechner's case above he should not need protection within the scope of the argument.
<stevelitt>I'm exploring the basics of tail recursion. I know the right way to print a list is with map, but how would I modify https://dpaste.com/ESV64YCNE to use tail recursion.
<mwette>OK. So, I must have been mixing up in-scope and out-of-scope. Sorry, lechner, if I did.
<dsmith>stevelitt, for-each, not map. map doesn't define the order, while for-each does. Also, for-each is for side effects, like display. Map is more for transforming
<stevelitt>Thanks dsmith. How can I substitute recursion for for-each?
<shawnw>with a named let.
<rlb>Do we have any minimums wrt posix, etc.? Or rather, just wondered when/if we might be able to rely on "_r" variants of functions (e.g. ttyname_r(), etc.).
<rlb>Though I suppose if we wanted to keep all options open, we could add relevant wrappers, i.e. one that falls back to mutex and non _r when _r isn't available...
<rlb>(or something like that)
<mwette>makes sense. and alloc the extra argument in the C code?
<rlb>Hadn't even looked carefully at what we'd need, just always wonder whenever I see the global/locking variants.
<rlb>For now, I just duplicated the code from scm_ttyname() and sent a patch to devel.
<rlb>Adding it to debian immediately, so I can finish up restoring 3.0.10 -- though I'm not even sure it'd fail on the buidds (suspect it's just the porterbox chroot envt).
<rlb>On the buildds there'll presumably just be no isatty() at all.
<rlb>(no tty, rather, so isatty will be false)
<shawnw>Speaking of ttys, I'd love to see Unix 98/POSIX pty functions added. posix_openpt, grantpt, unlockpt, ptsname...
<dsmith>guile-ncurses perhaps? https://www.gnu.org/software/guile-ncurses/manual/guile-ncurses.html#Pseudoterminal-helper-procedures
<lechner>mwette / thanks for your thoughtful reply. are all the levels of (cdata-ref (cdata& (cdata& ... ))) here "within the scope of the argument" https://codeberg.org/lechner/guile-pam/src/commit/861e2e9b282e7d919240aa3d79f7b7d2dc66964d/scm/pam.scm#L165-L168
<rlb>Not sure what those calls do, but iirc nested intermediate values may *not* be protected, unless they're held some other way. i.e. if the inner cdata call returns something that cdata-ref is going to need, but nothing else refers to it (e.g. the return value of the outer cdata call), then you may be in trouble.
<lechner>i am seeing some irregularities
<lechner>but not often
<lechner>mwette / also, how about options here https://codeberg.org/lechner/guile-pam/src/commit/861e2e9b282e7d919240aa3d79f7b7d2dc66964d/scm/pam/legacy/module.scm#L59
<rlb>One way to test that would be to let* bind each one individually, then make the cdata-ref call.
<lechner>i may have misspoken. i think daviid said to protect them like he did in g-golf
<rlb>(but better of course if just based on an understanding of what the calls do, etc...)
<mwette>shit no! I keep coming back to this. make-bytevector code has `contents = scm_gc_malloc_pointerless'
<rlb>I would assume that options is fine, at least as far as the call within the function are concerned, because it's an argument.
<rlb>i.e. you don't need that (list options) -- won't do anything anyway.
<mwette>But `cdata&' generates a bytevector for a pointer to data.
<dsmith>stevelitt, https://bpa.st/EMPQ
<mwette>message-struct is bound in scope, so that shouldn't disappear, I guess. I wonder if the intermediate one could, in `(cdata& (cdata& message-struct))'
<rlb>if it's hiding a pointer inside a bytevector that's not protected via smob mark(er) then I perhaps.
<rlb>(smob marking(ish) "or something else")
<rlb>But I'm just wildly guessing -- don't know this particular domain at all.
<shawnw>dsmith: Those functions, yes, but native to Guile's POSIX routines, not some external library.
<mwette>like rlb said, maybe create a binding in the let form for each level.
<mwette>lechner: also, I see (cdata-ref (cdata-sel obj)) in that code. Just (cdata-ref obj) should work.
<lechner>mwette / thanks! yeah, i use cdata-ref only for unboxing
<lechner>Hi, what is a quit-exception? Would it be issued on a program error?
<mwette>OK. I get it.
<lechner>mwette / didn't make a difference, so it's probably a bug elsewhere in my code
<mwette>lechner: a big debug hammer would be to make a global guardian and add the ref's to that guardian