Christopher Baines writes:
> For years now I've been trying to work out how to do reliable HTTPS
> networking with Guile, where reliable just means that it can't hang
> indefinitely.
>
> After a few wrong turns, I believe the way to do this is use
> non-blocking
Since this allows specifying additional behaviours for the socket
through using SOCK_CLOEXEC and/or SOCK_NONBLOCK (when bitwise or'ed with
SOCK_STREAM).
Note that Guile/guile-gnutls currently doesn't support performing the
TLS handshake on a non-blocking socket, so this currently won't work.
* mo
As described in the GnuTLS documentation on Asynchronous operation,
GNUTLS_NONBLOCK should be passed to gnutls_init, and the Guile
equivalent is passing connection-flag/nonblock to make-session.
Additionally, error/again or error/interrupted should lead to a retry of
the handshake, after waiting f
For years now I've been trying to work out how to do reliable HTTPS
networking with Guile, where reliable just means that it can't hang
indefinitely.
After a few wrong turns, I believe the way to do this is use
non-blocking ports as that combined with suspendable ports in Guile
allows you to provi
Tony Garnock-Jones writes:
> I'm seeing some very strange behaviour from `atomic-box-swap!` (but
> not `atomic-box-compare-and-swap!`) on Guile 3.0.9 from Homebrew on
> OSX Sonoma using an M3 Pro cpu. The issue does not seem to manifest on
> x86_64. Could it be some interaction between Guile and
I've encountered a situation where signal handlers don't seem to
run. With the following program, sending it SIGINT won't trigger the
handler, however if you remove the system* call, then the handler will
run.
(use-modules (ice-9 threads))
(call-with-new-thread
(lambda ()
;; Remove th
I've got a core dump of Guile reaching the abort in call-scm<-scmn-scmn.
#0 0x7fb8912d8fec in __pthread_kill_implementation () from
/gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6
#1 0x7fb89128f202 in raise () from
/gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-
I seem to have got Guile stuck in wait-condition-variable.
This is Guile 3.0.9 (specifically
/gnu/store/x4m56h5qkim0pnvx6vgvp541mrdwdrah-guile-3.0.9/bin/guile).
Here's some strace output.
futex(0x7f52a1495af4, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0,
{tv_sec=1700032632, tv_nsec=0}, FU
Someone else has this problem, which makes me feel a bit better since I
had no idea what's going on here.
I'm assuming that (backtrace) causing issues is still a problem with
Guile itself, but it seems like there's some involvement of
guile-fibers (which fits with my experience):
https://github
I've got this problem in the guix-build-coordinator, but I've been so
far unable to reproduce it in a standalone manor.
When (backtrace) is called, the output seems to start, but then stops as
seen below. The memory usage also seems to then start increasing with
increasingly large jumps over a per
Hey,
I've been seeing some strange occasional errors for a while now.
Here are some log messages from the guix-build-coordinator:
worker-thread: exception: (encoding-error put-char conversion to port encoding
failed 84 # s)
encoding-error (put-char conversion to port encoding failed 84 # s)
Based on the implementation in ports.c. I don't understand what this
code is really doing, but the suspendable ports implementation differs
from the similar C code for a couple of inequalities.
* module/ice-9/suspendable-ports.scm (decode-utf8, bad-utf8-len): Flip a
couple of inequalities.
* test
Here's a simple reproducer:
(use-modules (ice-9 binary-ports)
(ice-9 suspendable-ports)
(rnrs bytevectors))
(define (test)
(let* ((sequence
'(#xf4 #xa4 #xbd #xa4))
(p (open-bytevector-input-port
(u8-list->bytevector sequ
The sleep procedure is documented as returning 0 when it's not
interrupted by a signal.
This behaviour seems to have changed in guile as distributed by GNU Guix
(see the time-machine commands below). Previously, guile used the select
system call which seemed to change the timeout argument to the t
It seems that with-exception-handler might be breaking
false-if-exception inside terminal-width from (system repl debug).
I've come across this when trying to use with-exception-handler to print
backtraces for exceptions.
→ cat backtrace-crash.scm
(peek "COLUMNS" (getenv "COLUMNS"))
(with-exc
Ludovic Courtès writes:
> Hi Chris,
>
> Christopher Baines skribis:
>
>> When rendering synopsis or descriptions as plain text, acronyms are not
>> handled correctly, they're just omitted entirely.
>>
>> Flexible objects for representing @ac
16 matches
Mail list logo
