IRC channel logs
2025-04-10.log
back to list of logs
<dthompson>anyone know how to run a single test suite file when hacking on guile? <dthompson>the typical 'make check TESTS=test-suite/tests/blah.test' isn't working for me <daviid>dthompson: yes, here is an example - ./check-guile numbers.test <dthompson>daviid: thank you! been so long that I've needed to do this <rlb>dthompson: I've forgotten more than once too -- fwiw, there's some "documentation" at the top of ./check-guile... <lechner>mwette / Hi, do I have to wrap in libguile callbacks that are written Guile but called from C ? <lechner>they always work when called from Guile, regardless of whether they were written in Guile or C, but they don't work when written in Guile and called from C. <lechner>well, mine don't work in a very convoluted shared library back-and-forth <lechner>I guess this comes down a question as to what procedure->pointer does <lechner>i could write a libguile wrapper in C that calls Guile, is what I'm saying <lechner>Hi, is there a standard library with the equivalent of mkdir -p? <rlb>...hmm, recent changes to main broke the utf8 branch -- I'll take a look tomorrow (failure in foreign.test dll-name-match?) if that sounds familiar to anyone. <mwette>lechner: Just use the one defined for C, I think. I think mkdir -p is in guix code. <apteryx>what are common continuation barriers in Guile? <apteryx>perhaps sleep is a continuation barrier in guile <apteryx>I'm getting the 'Attempt to suspend fiber within continuation barrier' error when attempting to use 'certtool' in a shepherd one-shot? service <lechner>apteryx / how are you starting certtool? <apteryx>just (system* (file-append gnutls "/bin/certtool") "--help") was enough <apteryx>I'm coming up with a small reproducer, I'll share in a bit <lechner>apteryx / Some time ago, I discussed that with Ludo on IRC. I had seen the same error in one of my timers. Ludo said system* provided the continuation barrier, and there was no resolution. You may wish to ask Ludo <old>system would block the fibers normally no? <old>I don't know if fibers support sub-process invokation. If not, it's probably possible to do so by using `spawn' and pidfd_open <apteryx>it shepherd the design uses a single thread so that forking from a thread is possible, IIUC <apteryx>see (info "(shepherd) Service Internals") <apteryx>that's for the shepherd process itself <apteryx>and then each service is on a separate thread, IIUC <apteryx>and forking from these has to work, because that's how every daemon typically (always?) launches <apteryx>lechner: the continuation barrier issue I hit was because I had forgetten to wrap my start script in a procedure <apteryx>I've now encountered a different, small problem in bug#77707 <old>Is this kind of error only something emacs+guile users encounter? <stdin>:1785:0: warning: possibly unbound variable `p' <old>I sometime introduce a `p' or `n' by not pressing C- in Emacs. The evaluator then tell me that there's an unbound variable , but not where :-/ <trannus_aran>is there a quick `python -m http.server 8000` equivalent for guile? It looks like I can hop into a repl, `,use (web server)` and call `(run-server ...)` but I need a handler of some kind, hmm <dthompson>trannus_aran: not in guile proper but there is one in hoot. the one liner is: guile -c '((@ (hoot web-server) serve))' <trannus_aran>I take it I can just pass in some kind of `(λ (body response) ...)` to `run-server` but I'm not sure what would be minimal and still work <dthompson>(I should upstream this to guile but I haven't done that) <trannus_aran>yeah, that would be awesome if you get the chance to, it's oneliners like that that have me half-begrudgingly going back to python haha <dthompson>hard to compete with the money that gets poured into python <ieure>We cannot allow a Benevolent Dictator Gap! <trannus_aran>yup, but like you say, in this instance there's already something out there! :) Also hard to compete with python's money, but an extensible language does multiply a degree of what a single dev can do ;P <trannus_aran>if only python had TCO and halfway decent lambda syntax, alas... <dthompson>I'm currently trying to revive a very old patch that should have made it into guile a long time ago. a json module. <dthompson>maybe after that I will submit this simpe static file server <lechner>Hi, why do people generally prefer #:use-modules as part of define-module instead of the separate stanza? <old>lechner: you mean a file for public interface and a file for implementation? <ArneBab>dthompson: I mean steal, not copy in full ⇒ grab from there what could be useful. <ArneBab>There’s quite a bit more in there than just serving, though: I built it as a path towards peer-to-peer distribution of files via the Gnutella download mesh so clients can cooperate on serving the data, but I didn’t finish it yet. <ArneBab>It also supports multi-file uploads (and uploads ☺) which has become its main use for us: get files from mobile phones to the desktop. Because synchronizing phones to Linux isn’t very robust. <lechner>old, no just #:use-module inside define-module instead of a separate use-modules <rlb>*wow* - TIL (the hard way) guile and rnrs have opposite bytevector-copy! argument orders... <lilyp>yeah, that really was a mistake in r6rs <lilyp>r7rs' (scheme base) fixes this <ArneBab>dthompson: regarding the webserver: my code assignment should be on file. It’s OK for me that it applies to anything that you want to bring from the wispserve code into Guile. <rlb>lilyp: our (scheme base) and "native" bytevector-copy!s have the opposite order -- or is that what you meant? <lilyp>(scheme base) ought to be dst-first as Dennis Ritchie intended <rlb>Right -- I had (scheme base) when I was reading (rnrs bytevectors) docs in our info pages :) <rlb>but also took a minute because all the args were still the right types, so no crash... <lilyp>yeah, that's why C++ uses spans and ranges nowadays <rlb>OK, have an initial srfi 207 imported, adjusted, and passing all its tests -- also augmented our reader for the new syntax. <rlb>(haven't adjusted the writer yet -- guessing we'll want a read-enable or something similar since it won't/shoulnd't be on by default) <rlb>sorry "write enable"