<RhodiumToad>modern compilers make the logic of boehm-gc questionable <tekakutli>merazi_1 what did you do today to further our agenda? <dsmith>leoprikler: Actually, guile had it's own GC before boehm. Inherited from SCM. <merazi_1>tekakutli: Nothing really 😓 I've been doing some basic uni stuff today, preparing for the week. <rlb>...and iirc, getting the handling right *everywhere* on the C side was not always easy (wrt the previous non-conservative collector). <dsmith>Ya. lots of mysterious bugs just went away, but on the other hand, added another dependency. <vijaymarupudi>I'm not sure how central boehm is to the code, but I wonder if no-ops (for now) could be provided to increase or decrease a ref count for an SCM object <vijaymarupudi>So that in a future, a command line flag could opt for a more hands on approach? ***sneek_ is now known as sneek
<apteryx_>how do we recursively dereference a (potential) symbolic link? readlink would only dereference it once, correct? <apteryx_>ah, there is an example as readlink* in (guix utils0 <leoprikler>Does Guile (the language) have something similar to Emacs Lisp's with-demoted-errors? <leoprikler>I know Guix has false-if-exception*, but it's not quite what I'm looking for. <RhodiumToad>there isn't a builtin for it, but it should be doable <RhodiumToad>it doesn't seem to be documented, but false-if-exception has an optional warning arg <RhodiumToad>(false-if-exception expr #:warning template arg ...) <RhodiumToad>(false-if-exception (error "foo!") #:warning "demoted error ") outputs ;;; demoted error foo! <RhodiumToad>that said, doing your own thing using with-exception-handler or catch might be preferable <leoprikler>just the error be printed (perhaps with the right prefix) <leoprikler>I don't know how continuable exceptions are handled – would the code continue after the throw without me doing anything or would I need extra code for that? <RhodiumToad>do you want demoted errors to be continued if possible? <RhodiumToad>false-if-exception doesn't do that, it unwinds all errors <leoprikler>I should probably just read the manual on continuable exceptions first <leoprikler>so it appears this is the default (#:unwind?=#f) behaviour of with-exception-handler? <dsmith-work>How timely. I was just looking at with-exception-handler last night. <RhodiumToad>the default for with-exception-handler is to invoke the handler without unwinding, in the tail position of the raise-exception call <RhodiumToad>however, most exceptions are not continuable, so if the handler just returns, it'll throw another exception (to the previous handler) <RhodiumToad>it works to have two nested handlers, the inner one to print the error and the outer one to unwind for &non-continuable, but I don't know if there's a more elegant way <dsmith-work>RhodiumToad: Is that double level needed? Just print the error in the unwound handler. <RhodiumToad>that wouldn't continue a continuable exception, though <RhodiumToad>the request (aiui) was for code that would automatically continue any continuable exception and catch any non-continuable one, printing it either way <RhodiumToad>that assumes that #f is always a reasonable thing to return to a continuable exception <RhodiumToad>also this assumes guile 3 with its unification of exceptions and throws <JLouis>what would be equivalent in Guile to prin1-to-string that data can be saved in file? <dsmith-work>So what makes an exception continuable or not? Yeah, by calling raise or raise-continual or whatever. What are examples of exceptions that could be continuable and some that are not? <RhodiumToad>raise-exception has an optional argument which says it's continuable <RhodiumToad>afaik it's not dependent on the type of exception or anything else <dsmith-work>Right, but I'm really asking the deeper question. What kinds of execeptions are or should continuable? Or should not be? ***apteryx_ is now known as apteryx
<leoprikler>dsmith-work: if you're writing procedural code you might want to throw continuable exception for optional stuff failing <leoprikler>RhodiumToad: what would happen if I inverted the order? <leoprikler>I.e. in the inner exception handler unwind the stack if it's a non-continuable exception, then rethrow as continuable and in the outer one simply format the error? <RhodiumToad>the problem is that I didn't find a way to know if the exception was continuable except to try and continue it <RhodiumToad>which results in a &non-continuable exception if it turned out not to be continuable <RhodiumToad>and that gets thrown to the outer handler and not the inner one <RhodiumToad>(i.e. it gets thrown to the handler outside the one that tried to continue the error)