IRC channel logs

2026-06-12.log

back to list of logs

<mwette>probie: check the define-structure example near the end of https://www.scheme.com/tspl4/syntax.html
<mwette>... but ft's is a better match
<probie>I don't suppose anyone is willing to endure wisp syntax to tell me what I'm doing wrong https://paste.sr.ht/~probie/6c0c38b4c819c0f393842b42c0bb35230d6772f8
<probie>define-sum works, except when define-adt tries to use it, where I get things like `<btree-null-tree>-1b74c78076de21d7` instead of just `<btree-null-tree>`
<probie>Ok, so I've fixed it, by just more closely following what ft is doing as opposed to the manual, but I don't know why it fixes it. https://paste.sr.ht/~probie/50b6e68e6ec41dc4ac51133cf11a7db9736cd13e
<ArneBab_>probie: my approach to asking about wisp code is to transform it with wisp2lisp, then people used to regular scheme can understand it much more easily. You get wisp2lisp by installing wisp itself: https://hg.sr.ht/~arnebab/wisp
<ArneBab_>probie: if you use x in datum->syntax, I think that uses the wrong lexical context.
<ArneBab_>probie: but that’s deep macrology that I also struggle with (I didn’t know #'name and #'parent).
<probie>ArneBab_: #'name and #'parent are just variables(?) that I bind as part of `syntax-case`
<probie>Twelve hours ago, I'd never even used `syntax-case` before, and I still don't quite understand how `datum->syntax` works
<identity>probie: if you want some resources on syntax-case, see ‹Writing Hygienic Macros in Scheme with Syntax-Case› at <https://web.archive.org/web/20170811221525/http://www.cs.uml.edu/%7Egiam/91.531/Textbooks/RKDybvig.pdf> (this one is pre-R⁶RS, so details differ) and ‹Extending a Language — Writing Powerful Macros in Scheme› at <https://mnieper.github.io/scheme-macros/README.html>
<probie>Guile doesn't have anything like Common Lisp's declare, does it?
<identity>well, what are you planning to use that for?
<identity>(to be clear, there is no direct equivalent to ‹declare›)
<probie>identity: this is mostly out of curiosity, but I specifically mean the `(declare (type t x))` kind of declare (not the optimise/inline shenanigans)
<janneke>how do i get the contents of this new-fangled &exception so that i can do (and know that i can do) (strerror errno)?
<janneke>(ERROR #<&compound-exception components: (#<&external-error> #<&origin origin: "open-file"> #<&message message: "~A: ~S"> #<&irritants irritants: ("No such file or directory" "foobar")> #<&exception-with-kind-and-args kind: system-error args: ("open-file" "~A: ~S" ("No such file or directory" "foobar") (2))>)>)
<janneke>there is: exception-irritants, and exception-origin; but there's no exception-with-kind-and-args, or exception-exception-with-kind-and-args, or exception-kind, or exception-args?
<janneke>ACTION is completely puzzled
<identity>probie: you can do (assert (type? obj)) for a similar effect; for inlining, there is define-inlinable
<janneke>ACTION reads boot-9
<janneke>okay, this works -- but it's still terrible
<janneke>(match (struct-ref exception 0)
<janneke> ((external origin message irritants exception) ...))
<janneke>then via (kind (pke 'KIND (exception-kind exception))) you can check for 'system-error
<janneke>ACTION is amazingly underwhelmed and is most probably "not getting it"
<janneke>and no idea how robust this is, are there always 5 fields?
<yarl>o/
<mwette>To me, it's odd to have the complexity of exceptions in mostly simple Scheme.
<ekaitz>mwette: done well they should be just a simple record and a variable
<ekaitz>(variable meaning a guile variable, a dynamically scoped "box")
<old>probie: I want to add declare to the compiler at some point
<old>janneke: this might help? https://codeberg.org/lapislazuli/blue/src/commit/40ae4f5f1ec2536a0ede54636701688b8569b9bf/blue/exceptions.scm#L125
<Zelphir>Hi! I am using a guix shell to run a Guile program that makes use of (web client) and (http-get ...) to GET a web page. (My little project is building a link checker, that checks, whether all links on my entirely static website work.) However when I use (http-get ...) with my website, I get the error: "ERROR: In procedure getaddrinfo: In procedure getaddrinfo: Servname not supported for ai_socktype". I found this error in reports by other people for other
<Zelphir>ecosystems, but I couldn't find a fix. Does anyone know this issue? Here is how I use Guix: `guix time-machine --channels=guix-env/channels.scm -- shell --manifest=guix-env/manifest.scm --container -- bash` and then I use Guile: `Guile -L . main.scm` and in `main.scm` I use the (web client) module indirectly (it is used in a module `utils`, that I use-module in my `main.scm`).
<Zelphir>One post I found online mentioned, that they installed `netbase`, but that's already newest version on my Debian system. And I have used http-get from web client before and didn't have this issue, I think.
<Zelphir>Ah and my `manifest.scm` has the following content: `(specifications->manifest
<Zelphir> '("guile"
<Zelphir> "gnutls"
<Zelphir> "bash"
<Zelphir> "make"))
<Zelphir>`
<mwette>did you want "guile-gnutls" ?
<Zelphir>Let me try that.
<Zelphir>I tried "guile-gnutls", no change. Then I tried both "guile-gnutls" and "gnutls", still no change, still same error.
<Zelphir>Hm. If I install the dependencies (guile-gnutls and gnutls) in my main guix profile, then I get around this error. That means, instead of using guix shell, I do: (1) `GUIX_PROFILE="/home/xiaolong/.guix-profile"` (2) `. "$GUIX_PROFILE/etc/profile"` (3) `unset GUIX_PROFILE` and then (4) `guile -L . main.scm`. And I read on https://www.ducea.com/2006/09/11/error-servname-not-supported-for-ai_socktype/ that it might be an `/etc/services` issue. Maybe inside a
<Zelphir>guix shell `http` is not defined in its version of `/etc/services`. That would at least explain, why it suddenly works, when not using a guix shell, but the main profile.
<Zelphir>So I think it is not a Guile problem, but a guix problem. Should take it over to the guix irc channel maybe.
<Zelphir>OK solved the problem. Truly was something I didn't do for the guix shell: Forgot the `--network` flag and had to `--expose` the host's certificates after that.
<rlb>janneke: https://codeberg.org/rlb/guile/commit/e18ca1602bb43cd03bd09a3f2f305461ba142cfe ? :)
<rlb>It's currently in the utf-8 branch.
<rlb>There's also an exception-errno accessor fn (already in main) in test-suite/guile-test because I needed it.
<rlb>But I agree that we should at least have a standard way to determine of exceptions have errnos and then get the errno when they do.
<janneke>rlb: ah, that could be helpful; thanks!
<janneke>old: yeah/but that's "old"-style throw, right? that's what we came from, sort of :)
<rlb>janneke: yes, the helper in errors is for system-error. The patch is for "promoting" errno into its own "composite exception" in the newer regime.
<rlb>s/helper in errors/helper in guile-test/
<rlb>i.e. so you can probe for it in a compound exception, and extract the value.
<rlb>right now we just discard it
<janneke>yeah, nice
<ArneBab_>probie: have a look at https://www.draketo.de/software/guile-define-typed and https://srfi.schemers.org/srfi-253/srfi-253.html#spec--define-checked
<ArneBab_>mwette, old: I’m trying to create a minimal working example of my fibers sleep failures (fiber not waking up), but failing. I now have 1000 fibers flawlessly forwarding data through channels and sockets and sleeping in-between.
<ArneBab_>mwette, old: my code: https://paste.debian.net/hidden/400e5ff0 – I don’t know why this works but my code breaks. Will have to search further …
<mwette>ArneBab_: I sympathize. These types of issues can be difficult to reproduce. I'll look at it.
<mwette>ArneBab_: did you try w/o the prints ?
<ArneBab_>I’ll try
<ArneBab_>mwette: after removing all output it still works without problems …
<mwette>I'm running it w/o prints. Roughtly how long does it run for you? Seems hung for me.
<ArneBab_>It takes many minutes
<mwette>OK. Thanks.
<ArneBab_>I reduced iterations and num-fibers to 100 each when running without prints
<ArneBab_>but the failing code runs with prints (that’s how I found out that it blocks in sleep)
<mwette>`top' shows 0.0%CPU for guile.
<ArneBab_>that sounds like it blocked …
<ArneBab_>(but not for me?)
<ArneBab_>did you also remove the display into the socket?
<ArneBab_>(that starts the whole chain)
<ArneBab_>(display (get-message (list-ref channels (1- (length channels)))) (car sockets31))
<ArneBab_>and (display 's (car sockets31))
<mwette>oop
<mwette>oops
<ArneBab_>those are the two displays that have to stay in
<ArneBab_>(because the failing code also uses socketpairs and channels together so I hoped that would allow me to reproduce)
<mwette>lemme retry
<ArneBab_>the pipeline even works with 100.000 fibers, and without problems
<mwette>now it's going
<mwette>and finished
<ArneBab_>The good thing: it shows just how capable fibers are. The bad: can’t reproduce my problem :-)
<ArneBab_>at a million fibers I see some stuttering appear in the output, but it still works
<ArneBab_>I wonder whether sleep not returning has a different reason.
<mwette>On your original code, you could try to attach gdb to the blocked process: `gdb --pid ...' It's been a while for me, so not sure exactly how to go from there.
<old>ArneBab_: you could snapshot the timer wheel
<old>timer-wheel-dump
<old>call it every 5 seconds
<old>let your system go for a bits until you get the deadlock
<old>you will get a snapshot of the deadlock timer wheel. That ought to give some clue
<old>You can also just let your system go and make a heartbeat to an external thread (outside of fiber)
<old>if a heartbeat is missed after X seconds, consider the system deadlock and take a snapshot of the timer wheel
<old>if you want better determinism, go into full cooperative mode, pass #:parallelism 1 #:hz 0
<ArneBab_>mwette: attaching gdb is an idea …
<ArneBab_>#:hz 0 sounds like an idea!
<old>with gdb you also ought to get a backtrace of the threads
<ArneBab_>this is how the backtrace looks when it’s blocked: https://paste.debian.net/hidden/e2552185
<old>the main problem with display
<old>and here the port_poll
<old>is that no async tick is done
<old>so no signal handing and so no timer
<old>but hm
<old>poll should EINTR, IIRC it is the thread who receive the signal, yet I don't see anything in scm_i_write_bytes or print that will do an async tick on EINTR
<old>also, port_poll is not prepating to sleep on some fd like scm_select
<old>I find this odd
<old>it should
<old>otherwise it can not be wake
<ArneBab_>old, mwette: if you want to see it fail live, you should be able to reproduce via hg clone https://hg.sr.ht/~arnebab/terras-heritage && cd terras-heritage && ./terras-heritage.w --server
<ArneBab_>Then open http://localhost:9423 in a browser, and reload until it stops after showing only one or two letters (could happen at the first try)
<old>is it normal I get: In procedure write-char: Wrong type argument in position 2 (expecting open output port): #<closed: file 7f24df3ab3f0>
<ArneBab_>That happens when you reload, because the browser then closes the port and that closing is propagated
<ArneBab_>so it should be normal
<ArneBab_>but I should be careful saying that, because somewhere there is a nasty bug that I’ve been failing to find for two weeks now (in hobby time, so maybe two days fulltime)
<old>okay
<old>I do get the lock on port_poll
<old>and I think I had already a fix somewhere stashed for that ..
<ArneBab_>puh, not just my system
<old>was messing with print/display and the REPL to make it more responsive in general to signal
<old>and that path is kind of a problem sometime
<old>will make a patch soon
<old>and sent it to you if it works here
<ArneBab_>thank you!
<ArneBab_>Do you have an idea why it works flawlessly on the server?
<ArneBab_> https://dryads-wake.1w6.org/terras-heritage/ ← this runs the same code but does not lock up
<ArneBab_>ACTION should consider himself lucky that the code fails locally, but *not* in production …
<old>I could not tell off hand
<old>could be the number of core on the machine running making it less possible to reproduce
<ArneBab_>that sounds plausible. The number of cores also made a difference before (which is why paralellism is set to 1 in the fiber: on 16 cores there’s quite a bit of overhead otherwise).