Search
Sunday, 27th of November 2022, 19:21:24 UTC
22:32:58
stassats
i guess i've acquiesced to the fact that i can't escape emacs
22:33:06
stassats
gotta start making slime better again
23:43:42
aeth
maybe something could come from this discussion from 2019? https://sourceforge.net/p/sbcl/mailman/sbcl-devel/thread/20190507014112.wiwiles2vofjmbop%40Ergus/#msg36659403
23:44:11
aeth
at least, someone was looking into porting Emacs's Lisp to sbcl
23:45:05
stassats
it doesn't seem like the language is the biggest problem of emacs
1:09:20
stassats
huh, after i load cl+ssl i can no longer interrupt slime
1:14:36
stassats
and only if i load ssl from homebrew, not the system one
1:22:50
stassats
and only when i do cffi:load-foreign-library, but not sb-alien:load-shared-object
1:27:56
stassats
ok, cffi does (call-within-initial-thread 'load-shared-object path)
1:28:36
stassats
which is bad in itself, but why the differences
1:32:40
stassats
adding sb-sys:with-interrupts to call-within-initial-thread helps
1:32:52
stassats
but how could it affect the repl thread
1:33:04
ieure
I'm trying to use gzip-stream, but it doesn't seem to work and I can't find any examples. Can anyone point out what I'm doing wrong here? http://paste.debian.net/1262099/
1:33:46
stassats
i think that's more of a question for #lisp
1:33:54
ieure
I suppose you're right.
1:34:35
stassats
is it a binary stream?
1:34:46
stassats
can you do (write-byte 20 stream)
1:37:46
|3b|
ah, is that the one where sb-gray functions don't work on non-gray streams?
1:38:20
stassats
well it says fundamental-binary-output-stream right there
1:38:30
ieure
stassats, (write-byte 20 zfd) does work.
1:38:45
|3b|
yeah, looks like it does just call it on underlying stream https://github.com/mcna/gzip-stream/blob/master/gzip-stream.lisp#L92-L93
1:38:59
ieure
I guess if I'm writing gzipped stuff the underlying stream needs to be binary, which I didn't specify.
1:40:02
stassats
slap a flexi stream on it
1:40:26
stassats
like in https://github.com/mcna/gzip-stream/blob/master/gzip.lisp#L3
1:43:38
stassats
the stream-write-char method is highly mysterious
1:44:02
ieure
Okay, yeah, that works. Thanks for the pointer.
1:44:53
stassats
ok, back to the signal mask mystery
1:46:07
|3b|
i guess they think you might like raw text mixed in with your gzip?
1:48:53
stassats
i wish i could just trace pthread_sigmask
1:50:31
stassats
but i can't imagine how interrupting a thread and loading a shared library there can affect the signal mask of another thread
2:00:00
stassats
no interrupt is needed, load libcrypto.dylib in another thread with a different sigmask, all other threads get that sigmask
2:00:46
stassats
looks like a kernel bug or something
2:08:01
stassats
i can workaround by adding sb-sys:with-interrupts to cffi::call-within-initial-thread
2:09:58
stassats
pop the stack to the original mystery
2:10:35
stassats
it's mysteries all the way down
2:13:32
stassats
which is, sb-bsd-sockets:socket-connect doesn't handle EINTR
2:13:41
stassats
which can come from the gc
2:16:04
stassats
worse is better anyone?
2:28:06
stassats
again, macos only, not respecting SA_RESTART?
2:33:40
stassats
now i get GC invariant lost, file "gc-common.c", line 1736
2:42:01
stassats
at least that's the case on ppc64-linux too
2:42:06
stassats
looks lime memory ordering
2:53:10
stassats
well, restarting connect(2) doesn't work
2:53:11
stassats
Socket error in "connect": 56 (Socket is already connected)
2:53:20
stassats
so what am i supposed to do, apple
2:59:20
stassats
can't hid it under without-gcing, as it can be slow
Monday, 28th of November 2022, 7:21:24 UTC