IRC channel logs

2018-07-03.log

back to list of logs

<rekado>fold applies a function of two arguments (the current value and an accumulator) and applies it to a list, starting with a seed.
<apteryx`>rekado: sounds excactly like what I need. Thanks!
<apteryx`>not really sure where to insert my fold when using it with call-with-input-file though.
<apteryx`>cons seems simpler here
<apteryx`>if someone sees otherwise please let me know :)
<apteryx`>what is wrong with this regex (ice-9 regex): (make-regexp "ISO 8879.*(\\"iso-.*\\.gml\\")")
<apteryx`>oh, the literal dot needs a double escape like \\\\. it seems
<apteryx`>not sure why
<apteryx`>to use fold with call-with-input-file, I find I'd like my file lines to appear as a stream that I can feed to fold... is there already something I can use for this?
<lavaflow>I'm not sure if I'm doing something wrong, but it seems like (web server) doesn't work with handlers that return a procedure for the body that write bytes (not text) to the output port.
<lavaflow>if I write text to the output port, then it works. otherwise I get locale stuff: Throw to key `decoding-error' with args `("scm_from_stringn" "input locale conversion error" 92 #vu8(137
<lavaflow>maybe I'm doing something wrong, maybe it's because I don't have content-type set correctly? but if I set it to image/png (which is correct in this case) it still doesn't work.
<lavaflow>it looks like sanitize-response calls call-with-encoded-output-string... maybe I should set the charset to ISO-8859-1?
<lavaflow>yeah this seems to work.
<manumanumanu>So, regarding pattern matching again: is there any way to match the car and cdr of a list that is as fast as just using car and cdr? (a as ...) is pretty slow
<wingo>match should be just as fast fwiw
<wingo>either ice-9 match or pmatch
<manumanumanu>wingo: nah... x xs ... is slow, x . xs is fast
<manumanumanu>I RTFM and tried it
<manumanumanu>where (x xs ...) on a big list is slow and x . xs is fast and produces the same result for my use case
<manumanumanu>(x . xs)
<manumanumanu>(x . xs) is just as fast as my old cond-based approach using car and cdr
<civodul>right, ellipses mean 'list?', which is O(n)
<civodul>but (x . xs) is just as fast as car/cdr
<manumanumanu>i guessed as much :)
<civodul>when in doubt you can try ",optimize" at the REPL
<manumanumanu>I am planning on doing a deep dive into ice-9 match and maybe try to add =? which is a mix of ? and = so that one can bind the result of a predicate
<manumanumanu>and maybe even try to add a regexp matcher
<manumanumanu>and pray that my patch is accepted :)
<manumanumanu>civodul: I was pretty flabbergasted when I looked at the ,opt output of match. it really produces fast code!
<civodul>esp. if you try: ,opt (match '(x . y) ((x . _) x))
<civodul>:-)
<manumanumanu>doing (= pred? (and (not #f) identifier)) isn't really optimal...
<manumanumanu>wait... is list? O(n)????
<rekado_>manumanumanu: I’d think it must be because the last item determines if it is a real list.
<rekado_>manumanumanu: it’s not a list if it’s just a bunch of conses or a circular list.
<manumanumanu>jesus I didn't know that
<wingo>hehe on the bright side, you could see a lot of speedups now in your code :)
<manumanumanu>I thougt it was just like pair but with #t for '()
<manumanumanu>oh man
<wingo>no a list is either '() or a pair with a list in the cdr
<manumanumanu>which is a recursive definition
<manumanumanu>I see that now
<manumanumanu>I have been blind
<lavaflow>wait, is list? actually O(n) in practice in guile? I think racket optimizes that to constant time somehow so I assumed guile did too
<lavaflow>mutable cons cells prevent that maybe?
<wingo>mutable cons cells prevent (list? x) from implying (list? x) at some point in the future
<wingo>because intervening mutations can invalidate the predicate
<wingo>but, afaiu racket does not optimize list? to constant time.
<wingo>corrections are welcome of course :)
<lavaflow>I could be wrong about that, somebody told me racket does a while ago and I never really questioned it.
<lavaflow>ah here we go, racket documentation claims about list? "This procedure effectively takes constant time due to internal caching (so that any necessary traversals of pairs can in principle count as an extra cost of allocating the pairs)."
<wingo>neat
<wingo>so i guess when they do an immutable cons, they propagate a list? bit from the cdr
<wingo>neat hack
<wingo>tx for the tip :)
<civodul>wingo: sounds nice, we should do something like this :-)
<OrangeShark>hello everyone
<dsmith-work>Hey Hi Howdy, Guilers
<rain1>generous with the greetings today
<civodul>hey hey!
<dsmith-work> civodul: Contrats on the new release!
<civodul>thanks :-)
<janneke>Congrats on the release, and thanks!
<roelj>Is there an equivalent to canonicalize-path that returns the absolute path for a possibly non-existent directory?
<janneke>roelj: what if the possibly-non-exintent directory would be a symlink?
<janneke>you probably have to remove elements until you hit upon an existing prefix and add from there
<roelj>Well, being a symlink is OK. I just need the absolute path.
<roelj>So, maybe I can combine it with 'dirname'.
<roelj>Hmm, is there something to write a path separator (so that it works portably)?
<janneke>use parse-path?
<roelj>Oh, I see: file-name-separator-string.
<Labu>Hello all
<manumanumanu>are symbols always eq? even 'symbol (from compile time) and 'symbol (from runtime)
<manumanumanu>yes
<manumanumanu>Labu: hello
<Labu>Hi manumanumanu I don't know but I expect that are eq?
<manumanumanu>wingo: racket's way of doing it is nice until you want circular lists, for which you then need to either do some lazy mumbo jumbo or rely on in-cycle for their for-loops
<stis>yes, but I guess that object-address is different from runtime to runtime so e.g. eq vhashes of symbols can't be serialized directly
<stis>manumanumanu: nonmutable cons means no circular lists if all elements is of such type
<manumanumanu>I was just afraid there might be som differences between interned and uninterned symbols
<manumanumanu>or that there might become a mismatched
<manumanumanu>-ed
<manumanumanu>stis: btw! I looked into ice-9 match. It should be trivial to extend it with user-specified matches
<manumanumanu>the magic is in match-two, which currently matched against syntax-rules literals
<stis>yes the nontrivial part is to get it included in upstream.
<manumanumanu>:D
<stis>you should discuss this with foof in #scheme, his the maintainer of upstream match
<manumanumanu>I don't believe ashinn is human. He is a code-producing alien that writes libraries made for just me
<stis>:)
<manumanumanu>It won't be included upstream, because that change would be intrusive to the portable syntax-rules only approach
<stis>yes that's why I like the racket matcher, although practically ice-9 match is good enough
<manumanumanu>but a =? might be ok
<stis>probably not it can brake existing code
<stis>where a car is match with a var called =?
<stis>In the reacket matcher you define a matcher like a sexp (matcher-name args ...)
<stis>where you can define your own matcher-name and export those symbols e.g. you would be safe is somone else defined a different matcher =?
<stis>so (list (list 1 2) 3 4) matches '((1 2) 3 4)
<manumanumanu>i should fork then
<stis>it's a bit more verbose but allows arbritrary extensions
<manumanumanu>and become upstream
<manumanumanu>:D
<stis>heh yes I do that for a living and have I think 2 differnent version of the matcher
<stis>I use that to match prolog constructs with the same semantics som ice-9 match
<manumanumanu>stis: oh another btw: my for loops are done :) Apart from post-guards, they are feature complete. I am just going to write a lot of tests and then make a serious release
<manumanumanu>and package for guix and stuff :)
<manumanumanu>If I manage to speed up the macro expansion I'm going to give post guards another jab, but as it is right now, I doubt I can add them and still stay below 0.2s for complex loop expansion
<manumanumanu>(which was my goal for this 6 year old computer)
<stis>manumanumanu: coolio!!
<stis>night folks!!
<manumanumanu>nighty
<manumanumanu>So: profilig macro expansion... any tricks?
<rain1>you are finding macro expansion slow? how have you implemented the macro?
<manumanumanu>rain1: oh... I just tested agaist what the macro expands to. The expansion overhead is almost none.
<manumanumanu>sorry about that.
<manumanumanu>I just thought that the macros were complex, but apparently that was just a minuscle part of it. most of the time is spent o other things
<ArneBab>amz3: webdev is crufty nowadays, that’s my feeling, too. But it has this "just send someone a link to try" going for it …
<ArneBab>manumanumanu: nice! congrats on feature completion!