<mark_weaver>davexunit: websockets for guile would be very welcome! <davexunit>the chicken scheme websockets library depends on a parser combinator library... I hope that's not strictly necessary. *davexunit reads a bit of the websocket spec while waiting for food to arrive <davexunit>does anyone have a sha-1 implementation lying around? <ijp>maybe guile-lib / industria <davexunit>websockets requires some base64 encoding and sha-1 hashing. <ijp>yeah, industria has sha1 *davexunit attempts to figure out how to get the http server to handle the ws:// scheme <davexunit>aha, only the client specifies ws://, the server does not see a uri like that. <davexunit>more confusion. I need to somehow send a response back to the client and then hold the connection open after. <davexunit>I can't figure out what to do after the initial handshake <davexunit>I'm using guile's built-in http web server, but the websocket flow seems to be different enough that I will need to write a custom server. <davexunit>the chicken scheme websockets implementation manages to make it work, though. <linas>So I've got soe weird guile-2.2 behavior that I don't understand ... <linas>Start guile shell, run some things that get into C code, and from the C code, I call guile again ***michaniskin is now known as Guest7102
<linas>specifically catch and eval_c_eval_string <linas>the inner bit throws an exception, its caught, and then the big surprise <linas>the thread finalizers end up calling my C finalizers and tearing down my whole guile environment <linas>I have not checked to see if guile-2.0 does this too. <taylanub>linas: 2.2 has some changes to finalizer behavior IIRC; wingo was talking about it and asking for opinions on what method seems best or so <linas>I'll have to get his attention, then. Just cause there is some exception doesn't seem like an excuse to tear down my C guile environment <linas>I mean, the C extension finalizers should run only if one is leaving guile forever and ever, not because some thred exited. <taylanub>linas: it might just be a bug, or entirely unrelated, don't let me mislead you :) <taylanub>(a bug in the implementation of the new behavior, or an entirely unrelated bug, I mean) <linas>Hmm Unless I stupidly amd misreading this stack trace because I forgot to scm_gc_c_protect_object ... surely not <linas>oh wait .. huh, this may very well be my error. I was doing something completely new and .. Hrmmm <taylanub>linas: I'm now reading the citations in Wingo's mail to get a better understanding of the whole topic, and it really sounds irrelevant to your problem; sorry about the noise <linas>no, that was good. The word "finalizer" appears in my stack trace, and I mistook the function being called for the one that does the global shutdown <linas>instead, it is just deleting what turns out to be a very important object for me. <linas>because it seems I failed to protect it...