<akkad>him and nat were a bit too much <PuercoPop>Is there a common way to structure a guile project? <daviid>PuercoPop: yes, somehow there is, though with diffs here and there of course, but anyway, the best you could do is to look at other guile projects, there are quite a lot out there <PuercoPop>The ones I looked at (from davexunit mostly) use autoconf, but I'm not sure why <daviid>you may look at guile-squee as well <daviid>have to leave the place I'm working now, talk to you later <daviid>it is a simple and easy to 'copy' project to start with, with texinfo doc as well ... ***vicenteH` is now known as vicenteH
<davexunit>PuercoPop: yeah, the autotools are the way to go. I won't say that the autotools are good, they are terrible, but they are the least terrible option available. they actually work for all possible use-cases a user might have, and `./configure && make && make install` is easy for users. ***dsmith-w` is now known as dsmith-work
<manumanumanu>Is there anything about the vector implementation in guile that makes it... slowish? <manumanumanu>I am trying to figure out a neat way to implment for/vector in my racket-like for loops, but whatever I whip up is still slower than just wrapping a for/list in list->vector <random-nick>manumanumanu: did you look at the disassembled bytecode? <ijp>the array situation is somewhat complex, and that may affect it. Also vectors don't get represented specially by guile, whereas pairs do <manumanumanu>random-nick: nah, but since the loops need to keep track of position and such to be able to grow the vectors, the code was a bit more complex. I just thought it would be faster since it didn't have to chase pointers. <ijp>I'm not saying this is the problem, but it is one thing that might be <lloda`>we got rid of most of that in 2.2. There are residues in the code, but the main functions vector-ref, vector-set!, vector-length etc. are all clean and strictly below any array stuff. <ijp>lloda`: ah, good to know <manumanumanu>There is a larger overhead for vectors over lists in guile than in chez though. The expanded for/vector code runs faster in chez than (list->vector (for/list ...)), whereas it was the other way around in guile <ijp>how big are these vectors? <manumanumanu>I'll keep the "proper" for/vector code in case things change in the future <ijp>how much overhead is there roughly? <manumanumanu>The problem is probably that I have to keep track of length and grow them as needed <ijp>for this sort of pattern, building the list and converting is probably sensible anyway, unless you make them specify the vector length <ijp>25% does seem really high though ***rlb` is now known as rlb
<manumanumanu>ijp: the code is now better optimized than before, so now it is slightly faster. I had to coax the guile optimizer a bit <manumanumanu>But I am not very familiar with the disassembler. are consecutive (vector-length) optimized or can I save some extra time keeping track of the length? <ijp>it would be optimised well before the disassembler <ijp>or at least, I would imagine so, I haven't actually checked <ijp>I seem to have introduced an indirect infinite loop in my module system code...wtf <ijp>essentially it can't find my version of the equal? function, so it tries to find it, but that goes through resolve-module which uses equal? <ijp>no idea why it can't be found though <ijp>hmm, I still can't find the loop <paroneayea>ijp: if a second pair of eyes would help, I could look, but I think it's enough new stuff that by the time I wrapped my head around it you might find it :) <ijp>paroneayea: no, I think I know where it is, I just don't see how to resolve it cleanly <paroneayea>ijp: feel free to rubber duck here if you'd like :) <ijp>I suspect that equal? needs to be handled specially when being compiled, since otherwise this infinite loop seems inevitable <ijp>I'm just going to have a look in compile-bytecode first <paroneayea>well, if a kludge will make movement possible, a kludge is better than being stuck :) <paroneayea>I am embarassed by how frequently I end up committing "Oops, removing an accidental `pk'." <paroneayea>though a lot of those pk's could be improved by that preserving-variables-for-debugging compiler task <paroneayea>maybe eventually I'll learn enough to help there <ijp>I don't get that so much, but I do forget to commit newly created files fairly often <paroneayea>I am way less likely to make these kinds of mistakes if I commit via magit and am forced to follow GNU ChangeLog style commits tbh <paroneayea>though I do find ChangeLog style commits kind of a dreary activity to type up (but magit does make it so much easier with the C key) <ArneBab_>ijp: I tend to just use vc-next-action for most simple changes (C-x v v) — which are the ones which just touch one file. If I did not add the file yet, I have to do that twice.