IRC channel logs


back to list of logs

<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>PuercoPop: we all use autoconf
<daviid>you may look at guile-squee as well
<daviid>have to leave the place I'm working now, talk to you later
<daviid> the devel branch, because master is not merged yet and I autotooled a while ago on the devl branch
<daviid>it is a simple and easy to 'copy' project to start with, with texinfo doc as well ...
<PuercoPop>daviid: thanks
***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
<dsmith-work>Happy Friday, Guilers!!
<OrangeShark>happy friday
<manumanumanu>happy happy!
<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
<manumanumanu>hmh... I could try running the expanded code in chez.
<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.
<manumanumanu>ijp: what does that mean?
<ijp>I don't know offhand how vectors are represented, but if they are treated as arrays, then they will break in all the complexity associated with them. See
<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>10 000 000 elements.
<manumanumanu>it was a silly loop just to measure overehead
<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
<manumanumanu>got it down to 10%
***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
<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
<dsmith-work>ijp: Ouch!
<cmaloney>good day
<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
<paroneayea>think that's possible to hack in?
<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 do that sometimes
<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.