***kluk_ is now known as kluk
<flatwhatson>manumanumanu: +1 for srfi-197 in guile, i think they'd be particularly useful in guix where you can be chaining a bunch of package transform functions <taylan2>tbh I'd rather just use let* or let-values* than learn all these new macros ***taylan2 is now known as taylan
<taylan>chain-when looks pretty neat though. although a good 'loop' macro should be able to do it as cleanly. (I never familiarized myself with any of them, like foof-loop.) <apteryx>how can I handle an exception by doing some specific action (e.g., re-establish a lost connection), and restart from where the execution failed? I'd need to use some mechanism that doesn't unwind the stack, right? Would the continuation resume by re-attempting the call that caused the error, or would I need to unwind the stack by one step? <taylan>apteryx: you could call the operation in a loop, breaking on success or after N attempts <apteryx>taylan: right, a retry loop. I was thinking something more unusual such as where the connection problem is detected, throw an error that'd contain the information necessary to fix the connection in place, and resume from there <taylan>hmm, I think that would require every possibly-throwing operation to be aware of this mechanism and restart itself after the handler fixes the issue <taylan>in the end it will be like a retry loop that's just more granular in where it restarts <apteryx>the condition raised could contain the continuation to resume perhaps? <apteryx>and when that specific condition would be raised, the handler could reusem it after fixing the problem <apteryx>changing topic, is anyone else having issues with ,break-at-source ? It doesn't seem to want to; I'm in a (guix scripts offload) module, I try: ,break-at-source offload.scm 721 (there's a procedure definition on that line) and it returns: "No procedures found at ~a:~a. "offload.scm" 721" ***ecraven- is now known as ecraven
<maximed>apteryx: about non-unwinding exception-handlng: see with-throw-handler or #:unwind? of with-exception-handler ***berndj-blackout is now known as berndj
<maximed>wingo: Something I was wondering about the new cross-module inlining: does it work well when cross-compiling? For example... <wingo>maybe it should be off in that case. it would inline from the host architecture <maximed>... I have this Scheme file defining O_NONBLOCK, O_PATH, ... flags (actually, they were different flags but whatever) <wingo>i hadn't even thought about that <maximed>for cross-platform support, I've defined a define-enumeration macro. It looks at %current-target-system. <maximed>Something like (define-enumeration O_NONBLOCK #:hurd 9 #:linux 3) (actual values are different) <maximed>wingo: I don't think cross-module inlining needs to be disabled altogether (but idk the implementation details). Maybe just check if the .go files we're trying to inline from are for the correct architecture and OS? <wingo>we couldn't even load them if they were for the wrong architecture, but for hurd vs linux i dunno <wingo>probably i would just turn it off if host and target systems are not the same, at least in the short term <maximed>Maybe a CROSS_GUILE_LOAD_COMPILED_PATH is required, to keep the natively-compiled .go (which we'll use for macro's) and cross-compiled (which we'll use for cross-module inlining) separatere <maximed>just disabling cross-module inlining when cross-compiling seems good in the short term <maximed>wingo: did you receive my patch to guile-fibers? (wait-until-readable-operation or something) IIRC, the last version works and even has some tests and documentation <maximed>I haven't really had an opportunity to use it yet though <wingo>i think i saw it but have not been a good maintainer :P <wingo>did you not want to re-use the existing epoll for some reason? <wingo>like there is schedule-task-when-fd-readable from (fibers scheduler) <wingo>which could be a good primitive for the "block" part of the operation <maximed>I guess the first version did not use schedule-task-when-fd-readable, but the latest version does <wingo>the select call is a problem tho, as it won't work for fd > 1024... <maximed>select does not work for fd > 1024? First time I've heard of that. Is that guile-specific? <maximed>do you mean ‘number of fds’ > 1024, or the fd > 1024? <wingo>of course guile should probably translate its scheme select interface to use poll or something... <maximed>Could ‘we’ implement 'select' (the Scheme procedure) with 'poll' (the C system call) in Guile? *maximed checks if that's done already <wingo>would require some more work <maximed>wingo: Read NEWS. In ‘Bugs fixed’: ** Prefer poll(2) over select(2) to allow file descriptors above FD_SETSIZE. <wingo>i was looking at the implementation of "select" fwiw <wingo>which uses the fd_set data type, which is the data type that has the limit <maximed>(ice-9 poll) is not documented unfortunately <wingo>thing is, if you are using fibers, there's no issue -- just schedule-task-when-fd-readable in a scheduler in a new thread <wingo>checking again for readability doesn't add any safety <maximed>The idea is to avoid suspending a fiber if the port is already writable / readable <wingo>but you have to syscall for that <wingo>and if you're going to syscall, you might as well use the epoll in the scheduler <wingo>different tradeoffs obviously <maximed>latency / performance tradeoff I guess? <maximed>I don't have any benchmarks or something. Whatever works I guess <wingo>fwiw you can use char-ready? for input <wingo>it returns #t even if only a byte is ready <maximed>yes but there is no can-write-char? for output. <maximed>I guess the (readable? port) and (writable? port) can be removed for now (presuming tests pass) until we have concrete performance figures <wingo>i think that's a good option <wingo>right, this is for the operations interface... yarr <wingo>ok in that case i would use char-ready? for the readable? -- it's strictly better as it is more portable, takes fd > 1024, and returns #t if there is data in the read buffer *maximed is in what's called the "block" (translated, pun intended) here. I'll update io-wakeup.scm ... when the (study-thunk) fiber completes. <wingo>sneek: later tell maximed the writable? side would have to take buffering into account somehow -- what to do if there is room in the write buffer? <maximed>wingo: from 'select' documentation in Guile: "The ability of port buffers to provide input or accept output is taken into account. <sneek>maximed, you have 1 message! <sneek>maximed, wingo says: the writable? side would have to take buffering into account somehow -- what to do if there is room in the write buffer? *maximed "blocking" for real this time ***bsima1 is now known as bsima
***chris is now known as Guest6168
<civodul>great that you found 8b994be59fc4d9d23d8fad546deca3dbb2d29df7 as a potential culprit <civodul>these kinds of bugs are always interesting :-) <civodul>(i have much less enthusiastic stuff to do for work...) ***Server sets mode: +ntz
<dsmith-work>wingo: Thinking about bugs 42345 and 42757 . What about making a call to an internal definition with the wrong number of args an error instead of a warning? ***unCork is now known as Cork