IRC channel logs
2025-06-05.log
back to list of logs
<mwette>lechner: You were asking about arrays in cdata the other day. Was it about setting array values? <lechner>I am currently aliasing fixed-length char[] arrays in a struct utmp as byte vectors. it's a bit cumbersome but works perfectly <lechner>the ffi helper really works perfectly. the number of projects I am using it in has exploded. it really enabled me to do a lot of new things in Guile <mwette>OK. I think this might work: (cdata-set! addr #(192 168 2 1) 'ut_addr) <mwette>For ut_line you'd have to convert string to chars to integers and pad the zeros. <mwette>Good to hear it's being used. I don't have a good idea of how many users there are, so thanks for the info. <lechner>mwette / what could happen if I don't pad the zeros? it's a fixed structure <mwette>If you don't pad, I think cdata-set! will return an error: can't set this array value. <mwette>and checking the code I still have debug prints in there :( <rlb>Anyone know offhand why coverage.test might start failing if you convert check-guile from sh to guile (wondered if it might be "nesting" related somehow.) <mwette>rlb: I wonder if you use `printenv' (in guile) inside the scripts both ways if that may provide some indication. <rlb>yeah - I decided to try to just side-step the issue, i.e. restore check-guile to sh, pain though it is :) <rlb>...really wish sh had arrays for this (paths), but can work around it. <rlb>Do we already have something more succinct than a dynamic-wind with a reentrancy guard for things like "finally (close-port p)"? <lechner>Hi, how may I avoid "possibly unbound variable" for a procedure provided by a foreign extension when compiling .go files with guild, please? <noe>custom-ports.scm says: ;; Replaced by extension; here just to suppress warnings. <noe>(define %make-custom-port error) <noe>lechner, I know no better answer, maybe others know? <noe>Talking about custom-ports.scm in guile, it also says in the define-module “#:declarative? #f ; Because of extension.” Is this to make sure the private definitions can be accessed by the extension? <rlb>Main justification right now is so that we can adopt upstream SRFI tests without changing them much. <rlb>(and still get the results folded in to the automake parallel test results) <ArneBab>noe: without #:declarative #f, global bindings can be inlined, so redefining them may not have an effect. <noe>Ah yes, makes sense thanks!