IRC channel logs
2021-04-24.log
back to list of logs
<leoprikler>I think it's roughly Scheme eval, dlopen, string stuff and open patches in the ml <rlb>lampilelo: not atm, and I'm pretty sure you wouldn't want to look at it yet. It's still strewn all over the floor. But if you're interested, I'll keep that in mind if/when I get a bit further and try to make something public sooner than I might have otherwise. <Zelphir>Hi! Is there a way to make sxml->xml output prettified/indented XML strings? <sneek>Zelphir, you have 1 message! <sneek>Zelphir, leoprikler says: the manual only talks about languages implemented in Guile itself, not third party projects <lampilelo>rlb: it's just plain curiosity, it's not like i depend on it <mwette>Zelphir: Regarding formatted sxml->xml, I typically open a pipe to xmllint --format and output to that. <Zelphir>mwette: Is that a command line tool? Piping from inside the Guile code? And: Do you happen to have an example anywhere : )? <mwette>(define (open-xmllint-pipe filename) (open-output-pipe (string-append "xmllint --format --output " filename " -"))) <mwette>then something akin to (sxml->xml sxml (open-xmllint-pipe "foo.xml")) <stis>Hey guilers! do one need to specify compiller options to compile let/ec effektively? <leoprikler>Zelphir other than that, you may want to adapt ice-9 pretty-print for your purposes <mwette>leoprikler: I think he wants to pretty-print xml not sxml. <mwette>The other approach is to re-write sxml->xml to do what "xmllint --format" does. <chrislck>this would be a nice addition to the sxml family <Zelphir>To be more clear: Yes, I do want to format the output of sxml->xml nicely, before it is send to the browser. However, I will also look at ice-9 pretty-print. Thank you Leo. <rlb>I wonder if, in a utf-8 world, mutation sharing substrings maintain much of their value, particularly cost/complexity-wise in the code. I suppose as long as you stick to bulk operations, which you'll want to do anyway, they might still be useful. <rlb>I also wondered what the requirements for some functions are, like string-trim, e.g. if there's nothing to trim, can it just return the original argument instead of a new string -- or perhaps only if the string isn't shared/mutable, or...? <manumanumanu>stis: I don't think that is really a thing... However, looking at the scheme benchmarks, even using delimited continutations, guile is slower than many schemes in the continuation-limited benchmarks (like fibc, for example). <manumanumanu>stis: one thing I have noticed giving quite a bit of overhead with continuations is the size of them (a large cons chain takes a lot longer time to escape and restore than, say, a loop with an accumulator), but I don't think that matters much with let/ec. <stis>manumanumanu: for this case one could optimize to get super speedy. But this is not something guile seams to be doing (yet) <stis>Also because I'm doing set! in python (yes python semantics means that) there is a loss of a factor of 3 if we assume the let/ec is optimized <manumanumanu>stis: regarding loop, btw: I have not spent any time thinking about python (the less I spend the happier I become), but there must be some kind of subset of list comprehensions where you don't need set! <manumanumanu>I am planning to download python on guile to try it out! It is such a nice project. I don't know enough python to be able to help though. <manumanumanu>there is always this little required set! somewhere that just ruins all the fun :( <stis>yes but that means a hairy lot of code, it is possible though to make it improve. For example if continue is not used we gain a factor of 2 and are 2x speedier than CPython <manumanumanu>Do you have to rely on exceptions to signal iterator ends? <stis>yes we need that and for loops doing very few runs it is expensive. Also there is a let/ec for the break notion <manumanumanu>that shit would have been sooo much easier with a guile TAGBODY :) :) <stis>but the let/ec for the continue is for every loop run so to remove that is the most important step usually <stis>yes it would, but a good optimizer for delimited continuation would mean that we can implement a tagbody in terms of delimeted continuations and then optimize the result so that it behaves as a tagbody <stis>I have an tagbody implementation using delimited continuations actuially <stis>so in principle we do not need to add a tagbody primitive <manumanumanu>I had one with call/cc, which worked fine in chicken, but was slow as molasses for guile. I rewrote it for guile. I have some questions about nested use though, and I haven't put it online yet. <stis>no it is an older one and do not work on wingos state of the art guile