<daviid>can't we do this? (match some ((or () ("") ("..") (".." . orest)) 'blue) (_ 'red)) it raises an error, unnown orest variable <mark_weaver>what would you expect 'orest' to be bound to if it matches () ("") or ("..") ? <mark_weaver>if you don't care what's there, you could put _ in place of orest, and th <daviid>ah, that is what i want indeed let me try <mark_weaver>and in that case, you can also get rid of the ("") which is then redundant <mark_weaver>sneek: later tell daviid: 'remove-dot-segments' will do the wrong thing for something like .././../foo/../bar <mark_weaver>sneek: you need to remove all the . and .. components from the front, but keep track of how many of those were .., and then add that many .. components back to the front when the loop is finished. <mark_weaver>sneek: later tell daviid you need to remove all the . and .. components from the front, but keep track of how many of those were .., and then add that many .. components back to the front when the loop is finished. <mark_weaver>sneek: later tell daviid I haven't looked closely at your 'merge-paths' yet <mark_weaver>guix doesn't do copyright assignment, but I told him he could snarf the code <paroneayea>mark_weaver: yeah but is daviid's project copyright assigned to the fsf? ***michel_mno_afk is now known as michel_mno
<ArneBab>bernalex: layman -a lisp # ← gets you guile 2.0.11 <bernalex>ArneBab: as I mentioned, that's what I did. <ArneBab>bernalex: oh, just saw (later in the backlog) that you’re a Gentoo pm. So much for giving you the layman commandline ☺ <ArneBab>IIRC the file collisions for guile 1.8 and guile 2.x are the man- and info-pages. <ArneBab>but it only now occured to me that I could simply install guile 1.8 with USE=-doc <wingo>paroneayea: it's on my mind distantly, but closer to typed racket than rust i think <wingo>given that we have a gc many of the linearity concerns of rust are less central <paroneayea>wingo: the thing that seemed interesting to me about the post was more about the compiler being informed as to whether things were immutable/mutable and some other things, and thus able to help inform whether certain patterns were safe for concurrency *wingo will read it again more closely at some point <paroneayea>wingo: do you think a typed guile is fairly feasible? Just how much rearchitecting would that take? :) <wingo>paroneayea: doing it like typed racket is feasible <wingo>typed racket is layered over normal racket <paroneayea>I have not really looked in depth at typed racket, admittedly... the only typed system I've played with is common lisp's optional typing stuff <wingo>typed racket is great; you should check it out :) <paroneayea>(in general I need to do more checking out of racket :)) <ArneBab>davexunit: do you have a repository with your static site generator? <ArneBab>do you know if there are any plans to archive everything on gitorious? <davexunit>I heard something about archive.org doing something <ArneBab>it would hurt a lot to lose all the repos in there <davexunit>ArneBab: note: the example code calls a "blog" procedure that isn't in the repo currently <davexunit>so consider it an idea of what things could look like, but not something that actually works yet. <ArneBab>davexunit: first feedback: If dir "site" does not exist it fails instead of creating it <davexunit>ArneBab: thanks. yeah, I'm aware of that but haven't fixed it. <ArneBab>davexunit: an example would be nice - I can’t see how I’d structure an sxml file <davexunit>ArneBab: yeah, I just didn't get around to committing it over the weekend. <davexunit>I can show you how to structure an sxml file, though, for kicks <davexunit>and you should be able to use the atom-feed and atom-feeds-by-tag builder procedures <ArneBab>the code says I need one key named 'content <davexunit>'((title . "Testing") (content . (sxml goes here))) <ArneBab>(and make date does not like what it sees) <ArneBab>srfi/srfi-19.scm:1111:24: In procedure #<procedure 7a6480 at srfi/srfi-19.scm:1110:13 (date pad-with port)>: <ArneBab>srfi/srfi-19.scm:1111:24: In procedure struct_vtable: Wrong type argument in position 1 (expecting struct): (make-date 0 0 0 0 1 1 1970) <davexunit>since this is just scheme code, you need to represent a date that way. in plain text formats, the date is parsed from a string. <davexunit>I'll add the patch tonight once I'm home from work <davexunit>I'd like to remove the date from the default metadata <davexunit>and instead write a procedure in haunt/post.scm that fetches the date, or returns the %default-date. <davexunit>that way the blog/atom-feed/whatever procedures don't have to worry about handling the case of a missing date. <ArneBab>the patch doesn’t make everything build, yet: I still get an error later <ArneBab>(or rather the same error, but date should work now) <davexunit>I wish I brought my laptop with me today, I could show you some code that I haven't pushed... <davexunit>didn't expect anyone to actually try using haunt :) <ArneBab>and it deletes the site dir whenever a build fails <ArneBab>I thought about doing some benchmarking of Guile datastructures and wanted to create a site for that. <davexunit>yeah, it's does a recursive delete of the site directory <ArneBab>automatic testing for big-O notation would be nice <ArneBab>it would be, if creating the site-dir would already work ☺ <davexunit>ArneBab: looks like you forgot to use unquote in your sxml <ArneBab>(it’s in the default config, though) <davexunit>but you specified the 'date' key in your sxml file, right? <davexunit>could you update your merge request with the proper quasiquoting? <davexunit>I didn't notice the bug with my config because all of my posts had dates :/ <ArneBab>it’s not like you promised easy to use code :) <davexunit>well it ought to be with a little more hacking :) <davexunit>ArneBab: writing new builders isn't too hard, if you look at the source you'll notice that they are just procedures that accept a site object and list of posts and return pages. <davexunit>and be warned that I haven't yet figured out how I want to represent static assets like css, javascript, images, etc. <ArneBab>I’ll wait a bit then - I still need to figure out how exactly I want to benchmark <davexunit>ArneBab: let me know if my design choices prevent you from doing what you want <davexunit>I'm trying to make as few assumptions as possible with this <davexunit>I'm very excited that you're giving this a shot. :) <ArneBab>one important thing I see is using quasiquote in the posts: I’ll likely want to call scheme code from those. <davexunit>also cool that it was the absolute easiest "format" to make <ArneBab>It would be useful I think - but the page I’m thinking of building is too simple for that ☺ <ArneBab>(I just want a quick way to share the benchmark results right-away) <ArneBab>(and I want to play with Guile for that instead of throwing it on my normal website ☺) <ArneBab>(so your site generator came just in time) <davexunit>wingo: I don't have my code in front of me, but I poked around with your fector module more last night, and it seemed like fector-push! and fector-push inserted elements at different ends of the fector. <davexunit>ArneBab: glad that I have such good timing. :) <ArneBab>I need to get back to work - happy hacking! <wingo>davexunit: yeah i found a bug somewhere in it <davexunit>I was writing the fector version of 'append' ***michel_mno is now known as michel_mno_afk
***cluck` is now known as cluck
***karswell` is now known as karswell
<wingo>hah, was typing into the ether <wingo><wingo> davexunit: fixed fector-push! <wingo><wingo> and related transient procs <wingo><wingo> makes it quite a bit slower tho <wingo><wingo> ah no i was testing on 2.0 <wingo><wingo> pretty much the same perf afaict <wingo><wingo> so i guess cons lists and vlists and fectors live on a perf spectrum <wingo><wingo> cons lists are fastest (?) for just making a chain of elements <wingo><wingo> vlists are a bit slower because they're more involved <wingo><wingo> and vlist-ref is a lot faster than list-ref, for some N <wingo><wingo> i wonder what that N is actually <wingo><wingo> anyway, fectors support fairly efficient persistent set! <wingo><wingo> which i guess would be their attraction <wingo><wingo> still seems like hamts are the data structure to go for... <wingo>so a little test says that vlist-ref is faster than list-ref, for optimally sized vlists, for all indexes I > 60 <wingo>fectors are faster for fector-ref for I > 100 <wingo>vlists are funny in that vlist-ref takes time log(I), where I is the index you are reffing from the end <wingo>so depending on what index you ref, you get different times <davexunit>I haven't read the implementation too much, but I was under the impression this was using something like HAMTs, due to the 2^5 branching factor thing. <wingo>davexunit: fectors do something similar to hamts but are more optimized if your keys are packed ints starting from 0, with a known lenght <wingo>i measured compilation time btw with intmaps and did come to 2^5 as a good branching size, same as clojure <wingo>with the simplify2 compiler bits <wingo>yeah vlists are pretty strange things, yo <wingo>the predictability of fectors is nice <davexunit>wingo: if fectors are optimized for this purpose, what does "still seems like hamts are the data structure to go for..." mean? <wingo>vlists can also leak memory, but i've never known that to be a problem <wingo>davexunit: well as a general-purpose data structure, i mean <wingo>fectors only have ints for keys <wingo>yeah i think transients are pretty fun too :) <wingo>making a 1e6-element fector is faster than making a 1e6-element hash table <davexunit>I don't care for vhashes, so HAMTs would be nice <wingo>put a lot of work into trying to optimize them, would be nice to throw that away :) <davexunit>I should give these fectors a spin in a game <wingo>where should they live eventually? <davexunit>but it currently wouldn't be too impressive because my rendering layer is so slow that a bunch of objects on screen would suck no matter which data structure I used <wingo>separate project, in guile, what? <wingo>also i'm sure there is a better name than fector <davexunit>wingo: I think they should be in core guile. <wingo>although i just wrote fash.scm <davexunit>people have asked about persistent vectors a la Clojure on several occasions. <wingo>maybe there are other better things, fectors are just where i got to but i don't read enough of other scheme libs <wingo>like maybe ijp has a good thing <wingo>or maybe DerGuteMoritz knows of a good persistent vector implementation in chicken <davexunit>I say integrate whatever is best, whether it be what you wrote or someone else wrote. :) <wingo>it uses the wright matcher and srfi-9, nothing else really <wingo>there's a "define-inline" thing that it does that you could hack around <wingo>i'm sure there's a nice chickenism for that <DerGuteMoritz>wingo: did you come up with that data structure yourself or is it based on something? <wingo>DerGuteMoritz: it's based on PersistentVector.java, mostly <wingo>not quite the same -- it will make transients when needed, and you can still work with transients after making a persistent <DerGuteMoritz>wingo: you mean it makes transients internally for bulk operations? <wingo>DerGuteMoritz: i mean that it has both fector-push and fector-push! <wingo>the former takes a persistent and will call persistent-fector if passed a transient <wingo>and the latter takes a transient and will call transient-fector if given a persistent <paroneayea>I guess the advantage of fectors over vlists is you don't have O(n) lookup for an element, right? :) <paroneayea>I assume, at least, that vlists are O(n) but I guess I never looked. <paroneayea> • Random access has typically constant-time complexity. <wingo>vlists aren't thread-safe because they use mutation internally to know whether a cons can just write the next, unused element in an internal array or whether it needs to branch a new head <wingo>paroneayea: well, vlists don't have an update operation, beyond cons/cdr <wingo>also vlist access time is log(n) in the worst case but it varies on the index you are accessing <wingo>with fector's it's log(n) also but more predictable <davexunit>ArneBab: I squashed your patches into one, modified the commit log, and pushed.