IRC channel logs


back to list of logs

<Keele>In G-Golf, how can I use constants from GTK such as GDK_KEY_Return?
<Keele>I've managed to connect a callback for 'key-pressed and I get the keyval nicely, but I would rather not copy the codes from gdk/gdkkeysyms.h
<civodul`>ACTION found a pretty serious issue in Fibers channels on aarch64:
<civodul`>does that ring a bell?
<old>civodul: I suppose get-message use atomic operations. How such operations implemented in Guile and what are the memory barriers involved?
<old>x86 is a TSO architecture while arm is much weaker.
<old>grepping through guile repo, I can't find any __atomic builtins reference. How are atomic actually generated by the VM?
<Arsen>I see libguile/atomics-internal.h uses stdatomic
<old>if present
<Arsen>the fallback is in the same file ;)
<old>I know with mutex ..
<civodul>old: in this example, it's a single-threaded program, so cooperative scheduling
<civodul>so it's unlikely to be a memory model kind of issue
<old>builtin atomic should be used here it's avaivalle for gcc and clang for ever
<old>civodul: okay no memory order probleme here then
<Arsen>I'd not be assuming gcc either - better to add a check for that too
<old>gcc supports builtin atomics since 4.6 I think
<dokma>dthompson: I've installed the new version of guile-websocket with the patch from a few days ago.
<dokma>When trying to initiate a wss: connection it sends a GET /ws/btcusdt@kline_1m HTTP/1.1
<dokma>Shouldn't it be HTTPS ??
<flatwhatson>dokma: no, HTTPS is just HTTP over a tls connection
<flatwhatson>the version string doesn't change
<dokma>When I do:
<dokma>(make-websocket "wss://")
<dokma>This gets sent:
<dokma>GET /ws/btcusdt@kline_1m HTTP/1.1
<dokma>Upgrade: websocket
<dokma>Connection: Upgrade
<dokma>Sec-WebSocket-Key: wMvJDODp/rnVB65+4Z8IRA==
<dokma>Sec-WebSocket-Version: 13
<dokma>But the server responds with:
<dokma>read(9, "HTTP/1.1 400 Bad Request\r\n", 26)
<dokma>read(9, "Server: openresty\r\n", 20)
<dokma>read(9, "Date: Mon, 02 May 2023 10:15:40 GMT\r\n", 36)
<dokma>read(9, "Content-Type: text/html\r\n", 26)
<dokma>read(9, "Content-Length: 166\r\n", 22)
<dokma>read(9, "Connection: close\r\n", 19)
<dokma>read(9, "\r\n", 2)
<dokma>read(9, "<html>\n<head><title>400 Bad Request</title></head>\n<body bgcolor=\"white\">\n<center><
<dokma>Is there anything that Guile sent to the server that is malformed?
<dokma>I suppose Binance wouldn't accept the request at all if it wasn't encrypted?
<flatwhatson>the https connection worked fine, but the websocket upgrade was rejected by the server
<dokma>flatwhatson: are you implying that my request was correct but it was rejected anyways?
<flatwhatson>it's not malformed, but obviously it didn't work, so it's not "correct"
<dokma>The funny thing is that when I use the same uri with websocat it works
<dokma>websocat wss://
<dokma>^^^ works just fine
<dokma>So the uri is correct. The request is supposedly correct?
<dokma>Or at least not malformed.
<flatwhatson>compare the requests between the two tools
<dokma>I've been trying to figure out how to sniff out what websocat is sending to Binance but haven't managed it so far...
<dokma>I can't see anything similar to the GET request I posted in the strace output
<flatwhatson>maybe you need strace -f if there's a wrapper script
<dokma>No mention of HTTP anywhere even with strace -f
<dokma>Looks like websocat doesn't send anything at all...
<dokma>Just starts reading
<RhodiumToad>strace is not much use when looking at https connections since it sees only the encrypted data in most cases
<flatwhatson>i tested guile-websocket wss support against wss://
<RhodiumToad>if you're seeing unencrypted data in strace, you're likely not using https
<dokma>flatwhatson: do you still have that test code?
<flatwhatson>just (make-websocket "wss://") in a repl and call websocket-send/receive on it
<dokma>I'm getting some error:
<dokma>scheme@(guile-user)> (make-websocket "wss://")
<dokma>ice-9/boot-9.scm:1685:16: In procedure raise-exception:
<dokma>In procedure getaddrinfo: Servname not supported for ai_socktype
<dokma>Seems like there is a problem with my system.
<dokma>I have Guile 3.0.9
<dokma>with GNUTLS
<graywolf>Is there a way to use spawn while inheriting file descriptors? Documentation recommends to stay clear of primitive-fork in favor of spawn, but it does not look like there is a flag to inherit all file descriptors.
<graywolf>So asking here if there is some flag I've missed or something.
<old>graywolf: I don't think so. I am not familiar with posix_spawn, but I guess that the intended behavior is to only keep 0,1 2
<jpoiret>graywolf: no there isn't currently
<jpoiret>We could maybe add a more low-level interface to posix_spawn
<jpoiret>Although inheriting fds seems like something you don't want to be doing
<Arsen>py's approach of effectively-cloexec-until-specified-otherwise is nice, I think
<Arsen>er, clofork, I think
<graywolf>jpoiret: I agree that not inheriting is sane default, but it would be nice to be able to whitelist FDs to inherit. In my case I'm spawning (well, execlp-ing now) a helper program, that needs to have a pipe to synchronize with it's parent, but it also needs to be able to use stdin (terminal). So for my usecase it would seem to be an appropriate solution.
<old>graywolf: so you need a fourth fd?
<graywolf>In my case case, 4th would be enough, but if spawn would be changed, generic whitelisting mechanism would make more sense I would think
<old>in the mean time, perhaps a named pipe would do?
<old>if the child accepts such argument in the first place ofc
<danisanti>how can I save a lisp image in GNU Guile? And how to load the image?
<danisanti>is it possible?
<dthompson>danisanti: not that I know of
<danisanti>dthompson: thank you. Do you know of other Scheme implementation that can save a lisp image?
<dthompson>someone else might have an answer. I only use guile.
<danisanti>dthompson: ok.
<dthompson>maybe guache or chez or chicken? they seem like they might be the kind of project that would have something like that... just a wild guess, of course.
<danisanti>dthompson: thanks
<danisanti>dthompson: gauche or chicken doesn't seem to.
<dthompson>ah okay.
<dthompson>the "lisp image" concept is much more of a common lisp thing
<dthompson>so I guess it's not too surprising
<danisanti>dthompson: and older lisps also used images
<danisanti>it is a shame that scheme has not implemented it. Will try gambit and call it a day, as a no.
<dthompson>I don't really know the history enough to know if this comes down a difference in philosophy.
<danisanti>thanks dthompson . You have been very helpful to me. I don't think any Scheme is able to save and load images.
<dthompson>I should do some research on where this difference originates
<danisanti>have a good day dthompson. Time to wash some dishes... :-/
<dthompson>heh, feels like I spend half my day doing that
<dthompson>good luck danisanti
<danisanti>ahaah. I share that feeling
<nij->Anyone familiar with guile emacs?
<johnjaye>yes it was an abandoned project to port emacs to the guile virtual machine.
<nij->someone tried to rewrite the emacs runtime in guile?!
<johnjaye>i'm not sure. i think so
<johnjaye>the idea is you would still be coding in elisp. but then it would translate to guile
<nij->What's the point @@?
<nij->It creates another implementation of emacs, and the community got to choose which to develop..