IRC channel logs

2018-06-24.log

back to list of logs

<brendyn>How can I make sxml->xml just return a string instead of writing to the default output port?
<daviid>brendyn: with-output-to-string ?
<manumanumanu>ArneBab: I am updating them in a couple of days. I will add pre-check and post-checks, which will give them almost feature parity to racket's
<manumanumanu>this has two uses: support for iterating over srfi-12x's generators and a proper in-value
<manumanumanu>The thing you can do with racket's for loops are that you much more easily implement some kind of loops by doing syntax transformations using lambdas. That means that they can add non-tail-recursive for/list without any special case for for/list. Pretty neat stuff, but I have no idea how they do it
<manumanumanu>That makes for/list multi-shot continuation safe at the cost of making it potentially very expensive to re-instate a continuation
<manumanumanu>For that I have for/list/pure (which uses a non-linear reverse at the end)
<wingo>just recurse! guile's map uses recursion, without reverse
<manumanumanu>wingo: that was the plan, but re-instating a long stack takes a lot of time
<manumanumanu>iirc
<manumanumanu>racket had to make for/list do a reverse at the end, because it ended up making for/list and continuations very slow
<manumanumanu>jumping in and out of a (map ...) takes a lot more time than jumping in and out of a (loop ...) that reverses at the end
<manumanumanu>maybe I tested it wrong, but I made a generator using map and a generator using a let loop with an accumulator (just testing, not really any real world code) and the map one was a lot slower
<manumanumanu>using a generator based on delimited continuations
<manumanumanu>so I do a reverse! for for/list, which means about the same base-case performance as a recurse-based one, but with better performance for one-shot continuations at the cost of multi-shot-continuation safety
<manumanumanu>anyway. if someone has any better idea, I am happy to try it out. I want my macros to be as fast as possible
<manumanumanu>i doubt they will become much faster, as I still haven't found a loop where it isn't as fast as a hand-rolled one (peval ftw!)
<manumanumanu>wingo: I have been meaning to ask you about that. I don't really trust my (make-coroutine-generator) enough, so I thought I would go right to the source: from my tests re-instating a big call stack delimited continuation is slower than re-instating a small one . Is this the case?
<wingo>yep
<wingo>o(n) in size of stack, also any dynamic-winds, captured fluid bindings, captured prompts
<jlicht>hi guile! Is there anything other than r6rs-protobuf that will allow me to easily deal with protocol buffers using Guile?
<manumanumanu>wingo: thanks. then i'll stay with the current implementation. if anyone needs multi-shot continuations, they will hopefully notice the bad behaviour and check the docs.
<ft>huh. I wonder why my emacs keeps clearing the echo area a fraction of a second after geiser puts some autodoc stuff in there. ...doesn't do that with eldoc in elisp files...
<civodul>wingo: looks like you frame filters API for GDB was never applied, was it? https://sourceware.org/ml/gdb-patches/2015-02/msg00362.html
<civodul>still haven't found what's causing stacks to not be fully marked(?), but at least i fixed a couple of things in gdb support \\o/
<civodul>not very productive