<davexunit>paroneayea: this tutorial is really nice. good job! <rlb>guile-2.2 (2.2.2+1-1) has been uploaded to debian unstable. <rlb>ACTION wonders whether they're going to have to increase the build timeouts for some of the architectures... <daviid>rlb: congratulation! can't answer your quiz, but is this based on the tarball or a git master clone? <rlb>based on the git tag, otherwise it wouldn't be so bad. <rlb>takes ~5-6 hours on my machine, though arguably not the fastest. <daviid>oh, then it really can take hours to compile, some reported up to a day on old and slow machines <rlb>mips is going to be *ugly* <daviid>rlb: you should ask the guix folks, they have a good experience about that <rlb>Well, in the end, doesn't matter - it is what it is unless I decide to try to use the archive .go files, and I'm currently inclined against, unless we have to. We'll see what the buildds say. <rlb>Eventually we'll want guile to be a reproducible build, but one thing at a time. <daviid>rlb: I agree with you, and guile build itself is now reproducible, if not mistaken, so it shouldn't be too hard to make guile debian packages reproducible as well <daviid>rlb: did you succeed in having 2.0.14 in stable? <rlb>daviid: not yet, and may not happen, but we'll plan for all of the important bits from 14 to be there even if we can't get everything, and/or change the version. <rlb>daviid: I don't think there's a big difference atm, but I need to double-check. <rlb>Might also be able to switch to 14 in the first stable update, but we'll see. <daviid>rlb: ok, i beleive there has been impotant changes in between 2.0.11 and 2.0.14, but most importantly, i beleive for users, have the upstream stable in a stable distro is better (maybe only on the psy side :) <rlb>daviid: oh, you meant jessie, I was thinking about stretch. <rlb>stretch has 13 plus some patches. <rlb>jessie is further back, certainly, and harder to change. <daviid>ok, it would be cool to have 14 in stretch, imo (i think 14 is reproducible, but that would have to be confirmed with civodul, or looking at the patches) <rlb>If nothing else, I think I'll at least plan to upload 14 for the first stretch update after the release. <daviid>rlb: really cool! tx for all this work <rlb>Then I need to get started on trying to remove 2.0 from buster. <rlb>Hopefully that won't be nearly as bad as 1.8 was... <rlb>daviid: you're certainly welcome. <rlb>I'm also not sure how soon 2.2 might make it in to sid from new - don't know if stretch is consuming the same reviewers. <nalaginrut>after this release, I can't wait for the further optimizing of Guile compiler <nalaginrut>btw, guile-tjit has excellent optimizing for things like event-loop, I'd love to have it. I'll spend time on hacking guile-tjit <nalaginrut>davexunit: AOT is a term to imply the native compilation <wingo>nalaginrut: i was thinking about it this morning :) probably some form of "instruction explosion" first <wingo>will make things slower before they become faster tho. anyway, have to branch off stable-2.2 first <manumanumanu>I admit defeat. I can't make our wordcount faster in any meaningful way <ArneBab_>wingo: can I make string-split faster somehow? <ArneBab_>wingo: that’s the core limitation manumanumanu and I face <wingo>probably string-split isn't the right thing to use for counting words, if that's the question <ArneBab_>that’s the question. read-line is nice and fast, but then splitting the lines gets slow <wingo>don't split then. count the words in the line directly via a loop and string-index, or just a loop and string-ref <manumanumanu>Oh, but we need the word as well to get the frequency per word <nalaginrut>wingo: is it possible to just add a backend for native code to replace bytecode part? I guess it's probably flexible enough to do so, or maybe not yet <nalaginrut>artanis-0.2 released, now I can have my supper casually <manumanumanu>ArneBab_: This was fun. Are there any other challenges like that? <manumanumanu>I have done the first 50 project euler challenges, but they have started becoming too hard for me <ArneBab_>manumanumanu: there’s always the debian benchmarks game, but that needs some reading to start <ArneBab_>there are existing racket operations which could be ported <manumanumanu>ArneBab_: they are always doing so many weird things those racketeers. <nikita1>amz3: for plotting I use ploticus project <manumanumanu>but (for (in-lines (current-input-port)) seems pretty convenient :) <ArneBab_>manumanumanu: I just got it another 10% faster by first splitting by tab, then by newline and finally by space <ArneBab_>read-delimited \\n isn’t actually slower than read-line <ArneBab_>(that’s then using domain knowledge, though) <ArneBab_>manumanumanu: this is the fastest I got now, execute with time taskset -ac 0 cat data/huwikisource-latest-pages-meta-current.xml | taskset -ac 0,1 guile -L guile guile/wordcount.scm >/dev/null <ArneBab_>(taskset reduces the CPU switching: it doesn’t actually make the script faster, but reduces the amount of work done on other processors) <ArneBab_>(I’m pretty sure that we’re in low-level stuff with that) <ArneBab_>manumanumanu: I also created the much slower version which uses skip-lists — but in turn almost halves the memory requirements <ArneBab_>manumanumanu: correction: the full dataset is 40x as large as the reduced one. The 700MiB memory our code needs right now will blow up to far too much. <manumanumanu>We are doing a hell of a lot of appends though. Append is O(n), which is not optimal <manumanumanu>oh, you can delete the (define buf [...]-line. We don't use that anymore <manumanumanu>we can remove that. it is better to just iterate over the sublists <paroneayea>amz3: so you were playing with biwascheme right? <paroneayea>rekado: I'm thinking of putting together a guile-webutils library under LGPLv3+. would you be interested in including something based off your code for that? <amz3`>paroneayea: no vanilla biwascheme doesn't support sxml <paroneayea>eventually I'd love an sxml option in the browser <paroneayea>where I can render templates the same both client and server side <amz3`>I have that in my todo list, not far away <paroneayea>amz3`: planning on porting the sxml stuff from the sourceforge release <amz3`>I don't know that sourceforge release <amz3`>hmmm, I don't manipulate the dom directly in my work <amz3`>tho, I do declare the content of the page in sxml <amz3`>I am not sure how ssax.sf.net can be helpful <paroneayea>but I'd like to render the same kind of templates I'm writing server side also client-side <paroneayea>thatt way if I have people using stuff without js, but I have some js components <rekado>paroneayea: I only wrote enough to be able to use the “fine-uploader” javascript thingie <rekado>I don’t think it’s very pretty, but I was under a deadline and haven’t worked on it since <rekado>paroneayea: the rcas-web thing is under AGPLv3+, but you’re free to snarf whatever you want under GPLv3+ as well. <civodul>rekado: is there an instance running somewhere? ***ertesx is now known as ertes