IRC channel logs
2024-09-08.log
back to list of logs
<old>robin: Need to load it in memory with load-thunk-in-memory <old>the segfault itself it not solved <old>Where is emit-atomic-scm-set!/immediate defined? ; used in (language cps compile-bytecode) <mwette>those things are usually in system/vm somewhere <old>vm-operations.h I see <old>wonder why the atomic operation are primcall lowered to VM instruction, but there is also C call to them possible <graywolf>Is there some procedure that would allow me to do a read on non-blocking socket and get back something like 'would-block is it would block? <graywolf>It seems that "normal" ones just block until they can read, so the non-blocking part is blocking... which is a bit weird <mwette>graywolf: Did you set the port to non-blocking? (fcntl sock F_SETFL (logior O_NONBLOCK (fcntl sock F_GETFL))) <graywolf>I did, lines 5 and 6 in the paste bin. I have re-tried with your line above and it still seems to block <old>graywolf: look at Non-Block I/O in the info manual <old>"Guile will block by polling on the socket’s ‘read-wait-fd’ or ‘write-wait-fd’, to preserve the illusion of a blocking read or write." <old>" So far we have just reproduced the status quo: the file descriptor is non-blocking, but the operations on the port do block." <old>" But here we run into a difficulty. The ports code is implemented in C, which means that although we can suspend the computation to some outer prompt, we can’t resume it because Guile can’t resume delimited continuations that capture the C stack." <old> To overcome this difficulty we have created a compatible but entirelyparallel implementation of port operations. To use this implementation,do the following: (use-modules (ice-9 suspendable-ports)) (install-suspendable-ports!)"" <old>"This will replace the core I/O primitives like ‘get-char’ and ‘put-bytevector’ with new versions that are exactly the same as the ones in the standard library, but with two differences. One is that when a read or a write would block, the suspendable port operations call out the value of the ‘current-read-waiter’ or ‘current-write-waiter’ parameter, as appropriate. *Note Parameters::. The default r <graywolf>Well yeah, I did read that. But I am writing a library, so I wanted to avoid forcing the users into enabling suspendable ports. <old>you don't have choice <graywolf>Ok, I guess I will just roll my own port type <old>I don't understand why we have this behavior tho <old>If I want a NONBLOCK pipe, why would emulate blocking on it <old>it is counter intuitive <graywolf>Yeah I agree. I assume there is *some* reason, but do not see it currently. Like, FD does not become nonblocking by itself, someone had to explicitely request that... Another is that it would be great to be able to turn on/off the suspendability per port. So libraries could use it without affecting global state. <old>well suspendable ports are meant to be used for fibers I suppose <old>so it makes sens to act globally <old>But nothing prevent Guile to simply check "Hey this file descriptor has O_NONBLOCK, I should honor this request and return (or throw) EWOULDBLOCK" <old>source of frustration for sure <graywolf>I mean that is pretty much what my port type will do ¯\_(ツ)_/¯ <old>also, if install-suspendable-ports! really only change core bindings, it would be possible to have an equivalent `install-suspendable-ports!/local' for changing the bindings only in (current-module) <old>thus, doing what you want for a library without affecting other users <old>see (ice-9 suspendable-ports) <old>(define port-bindings ...) <old>(guile), (ice-9 binary-ports), (ice-9 rdelim) <old>I suppose, you just need to apply install-suspendable-ports! to (current-module) instead of this list <graywolf>Hm, one downside of that would be that for example (read-string-all) would (I guess) not use my "local" suspendable bindings, since it is defined in different module <old>implementations in ice-9 suspendable-ports loop back <old>so you can't even just return without throwing an exception <ekaitz>hi! i kind of have a PEG -> Sexp transformer but I have extra parenthesis here and there i'm not really understanding where they are coming from <ekaitz>i don't see why some of the parts are wrapped in parenthesis <ekaitz>;;; ((#<syntax begin> (#<syntax define-peg-pattern> #<syntax a> #<syntax body> #<syntax (or ((? "1")) ((not-followed-by "2")) (peg-any) ("12133") ((or "1" "a" "s" "d" "f" "g" "a" "g" "2" (range #\a #\z))))>))) <ekaitz>like why is (not-followed-by ...) wrapped in parenthesis? <ekaitz>i think some map is not great, but I'm almost there <ekaitz>i would need some help reviewing this but I think it works <mwette>ACTION working new backend called cdata (vs bytestructures) for the ffi-helper; back to 2-steps-fwd-1-step-bck from last month's 1-step-fwd-2-step-bck; .go sized reduced 50%