IRC channel logs

<ArneBab_>old: I think I found the problem: when I don’t serve music files, then there’s no stalling. Because the browser does not actually read the music files it requests, so trying to write into the client-socket stalls and blocks all writing.

<ArneBab_>old: and it may not happen on the server, because there I use nginx as SSL terminator which may buffer what I send the browser.

<ArneBab_>old: the final fix was to set the client socket buffer to one lager than the size of the file served and to use force-output: https://hg.sr.ht/~arnebab/terras-heritage/rev/7ef547091877049371c29f8e94b1bd091c083441

<ArneBab_>The fibers web server should not be affected, because it uses a chunked response.

<dariqq>Hi. Whats the story of how (gcrypt base64) ended up in guile-gcrypt despite not using libgcrypt and written in pure guile? Depending on guile-gcrypt just for base64 also seems wrong

<civodul>dariqq: it’s “historical”: it just happened that both were needed in similar contexts

<civodul>and it had no better home

<dariqq>i guess I can continue the tradition outlined in the file comment and copy paste it into my project. Also base64 and base16 are available in gnutls as well but maybe there are some extra options that gnutls does not support?

<old>ArneBab_: nice! so no need for async in port-poll ?

<ArneBab_>old: I wouldn’t say no need, but rather that I found a workaround: ensure that the buffers do not get filled.

<ArneBab_>old: the root cause, as far as I could trace it now, is that browsers open the connection to media files, but if they don’t get played, they do not read from them. So the party that blocked writing was the browser (by not reading).

<old>ArneBab_: oh I do remember that if I pressed play for the media, it resumed the hang text

IRC channel logs

2026-06-20.log