IRC channel logs
2023-06-07.log
back to list of logs
<daviid>can someone remind me what's the deal wrt translation, i mean _ and gettext: iirc _ has been 'taken' by guile core (?) what is the recommendation to call gettext these days? <RhodiumToad>in the context of C code in a module, or scheme code, or...? <daviid>RhodiumToad: scheme code, like we were doing (_ "Over") ... <daviid>i lost track of when and why _ was 'taken over' by guile :) <RhodiumToad>the manual says, "It is conventional to use G_ as a shorthand for gettext." <lloda>i'd like to get guile-cairo fixed but i don't have headspace atm. If anyone can comment/review on daviid's last patch that would be great <elevenkb>What are those repl commands like ,module called? Is there any documentation on how they are defined? <elevenkb>wingo: Thanks ๐
didn't notice that section. <wingo>see the modules in module/system/repl to see how to define new commands <wingo>who thinks they know what with-throw-handler does <wingo> (lambda (key) (pk 'c) (throw 'a)))) <wingo> (lambda (key) (pk 'b) (throw 'c)))) <wingo> (lambda (key) (pk 'a) (throw 'b))) <dthompson>the nesting of the code suggests that it throws to key 'b, which then throws to key 'c, but since the handler for 'c is outside the context of the handler for 'b, you would 'c to propagate all the way to guile's own top-level exception handler. am I reading this right? if so, why am I also wrong? :) <wingo>well you have to think more about dynamic nesting than lexical nesting. <wingo>when `throw` throws an exception, throw handlers run inside the continuation of the throw <wingo>so the initial (throw 'b) gets handled by (lambda (key) (pk 'b) (throw 'c)) <wingo>which should be the same as substituting the initial (throw 'b) with (begin (pk 'b) (throw 'c)) <wingo>though it may not precisely be a tail call <wingo>the throw 'c then turns into throw 'a <wingo>which... is it then handled by the 'b throw handler? or does the program not terminate <wingo>i am not sure that the documentation is clear on this point. <wingo>in all released versions of guile, that second throw 'b ends up bubbling out. <wingo>the throw handlers can be active just once in the continuation. <old>wait so throw 'a in handler 'c will be called? <wingo>the semantics are very weird <old>even if the throw of 'c is done in the handler of 'b becuase that handler is in the continuation of 'c ? <wingo>if there is a throw within a throw handler, it is as if it were at the point of the original throw <old>well it does make sens if the stack is not unwind <old>so you end up with weird spaghetti control flow <wingo>i feel like there is a kind of intuitive sense which has some edge cases that aren't expressed well <wingo>especially when composed with delimited continuations; the dynamic environment of what exception handlers are active can change during the propagation of an exception, if a continuation is captured and reinstated e.g. on another thread <wingo>so the semantics can't just be "capture the exception handlers then process them", it has to proceed by small steps each time <old>wingo: that would only be problematic if doing premption I'm a right? <old>in a fully cooperative scheduler, you can avoid such context-switching when in exception handler <wingo>maybe? could be that your fiber suspends and then doesn't get pre-empted but does get migrated to another thread <old>ah so migration is a problem also <wingo>civodul: do take a look at wip-custom-ports when you have a chance <civodul>wingo: make-custom-port returns a "port" while scm_make_port_type returns a "port type", right? <sneek>civodul, you have 1 message! <sneek>civodul, mirai says: how does that work? What happens if I add two distinct services (like networkmanager and iwd) that both provide 'networking? <wingo>there is some discussion of this in the .texi node <civodul>the Scheme part ("Low-Level Custom Ports") uses the phrase "port type" in some places tho <civodul>could you "indent --gnu-style custom-ports.c"? <wingo>incidentally i tested speed, rewriting open-bytevector-output-port in terms of custom ports (or r6rs custom binary ports); the port-type version in c is faster (1.8x multiplier or so) because it allocates less. gc cost dominates. <wingo>certainly. incidentally pre-commit hooks etc might be nice <wingo>organizing the callbacks on the port type means each individual port has a smaller closure <civodul>i've implemented half-baked textual ports a few times <civodul>re soft ports, do we really need a new make-soft-port? <civodul>or could we keep make-soft-port with the same interface, and recommend custom textual ports as a replacement? <wingo>custom textual ports do not have a good interface imo <wingo>(1) mutable string buffer where guile has none <wingo>(2) positional rather than keyword arguments <wingo>(3) doesn't handle all of guile's port facilities <wingo>also the old soft ports are unbuffered. they really just need to go <wingo>(over some appropriate time frame of course) <civodul>i'm just wondering how to best manage the transition <civodul>or what about calling the new make-soft-port something like make-custom-textual-port or something? <wingo>so the sketch is to have make-soft-port in (guile) be just the old version <wingo>then you opt into the new version by (use-modules (ice-9 soft-ports)) <wingo>and eventually we deprecate the wrapper in (guile) <wingo>you might wonder, why bother with the name punning between old and new versions <wingo>(1) hard to come up with a new one, vs r6rs custom textual ports and soft ports <wingo>(2) you have to have a new module anyway if you are rebasing soft ports on top of low-level custom ports, so might as well use that new module <wingo>i'm sure there are other possibilities tho, if you think of a good one let's do it <wingo>re: tests it is probably a good idea, though it does not spark joy :) <civodul>i can imagine, but it's better than having to deal with the aftermath <civodul>re pretty-print, the new one looks *much* nicer! <civodul>i always wonder to what extent one can rely on port line/column info though <civodul>there are code paths that bypass line/column tracking, for instance <wingo>right the codepaths that bypass line/column are the bytevector ones <wingo>so if all `write` / `display` output goes through textual output we are good <civodul>there might be other paths in libguile no? <wingo>yes but it's the same concern <wingo>because you need encoding to output text <wingo>and write/display output text <wingo>those paths do update line/column afaiu <civodul>can a custom port bypass port/line tracking? <wingo>having an extensible pretty-print like the guix one would be nice <civodul>i glanced at the other commits and it looks great to me <civodul>custom textual ports + no continuation barriers = happiness! <wingo>tx for review. in summary: indent, textual port tests, check "port type" language in make-soft-port docs <civodul>really cool that we're gradually reaching the point where we can capture continuations from anywhere