IRC channel logs


back to list of logs

<mwette>Is the declarative issue w/ 3.0.7, or the repo? My stuff all compiles, but I've been moving mutable globals to (make-parameter ...) for a while. Not sure I have all of them.
<drakonis>i looked into r7rs-large and wow this is impressive
<drakonis>but how long is it going to take to be complete?
<daviid>sneek: later tell tohoyn i pushed a fix for the bug raised by your run-demo example, on the master branch, let me know if it indeed fixes the problem for you ... it does fix it here ...
<sneek>Got it.
<tohoyn>sneek: botsnack
<sneek>tohoyn, you have 1 message!
<sneek>tohoyn, daviid says: i pushed a fix for the bug raised by your run-demo example, on the master branch, let me know if it indeed fixes the problem for you ... it does fix it here ...
<tohoyn>sneek: later tell daviid the bug has disappeared here, to
<sneek>Got it.
<civodul>some more Guile in an HPC/research context:
<dsmith-work>Happy Friday, Guilers!!
<civodul>happy Friday!
<sneek>tohoyn: Greetings!
<tohoyn>sneek: botsnack
<wingo>civodul: did you manage to get '-O1 -Ono-inlinable-exports -Ono-resolve-free-vars' numbers ?
<civodul>wingo: i started it the build minutes ago!
<wingo>excellent :)
<civodul>i should be able to tell you soon
<civodul>i did that by removing '(#:inlinable-exports? #:resolve-free-vars? #:cross-module-inlining?) from the optimization options
<civodul>wingo: it peaks at 2.1G, which is marginally better
<wingo>hoo, very marginal
<civodul>"du -hc gnu/packages/*.scm" says 27M
<civodul>we're two orders of magnitude above :-)
<civodul>it's hard to understand how this all plays out
<civodul>just loading the files before they're compiled leads to more than 600M resident
<wingo>civodul: how did the build times compare? similar ratios?
<wingo>ok so here's an open question, is it the inline-digits that did something to memory usage? or is something else between 3.0.7 and main
<wingo>also there's 809b1651289b330fbcc30d539e1b3c5c20bc83af, which increases nesting...
<wingo>civodul: when you say that you removed '(#:inlinable-exports? #:resolve-free-vars? #:cross-module-inlining?) from the optimization options what do you mean
<wingo>it is a bit distressing to think inline-digits would be at fault for the memory increase :P
<civodul>wingo: i took (optimizations-for-level n) and removed those keyword/value pairs from the list
<civodul>which AFAICS should have the desired effect?
<civodul>(that's because Guix uses its own (guix build compile) module to build stuff)
<wingo>sure i guess that should have the right effect
<wingo>civodul: actually i would imagine that you might need to change those options explicitly to #f. not sure tho
<wingo>i.e. the default set of enabled options is what you get from the optimization level. then if you pass specific options to enable/disable, that's on top of the optimization level
<wingo>(since the core has an idea of optimization levels, i mean)
<dsmith-work>sneek: botsnack
<civodul>wingo: looking at optimize.scm, it seems just not having the keyword is enough, no?
<sneek>dsmith-work: wb
<dsmith-work>sneek: botsnack
<lagash>civodul: cool article, is Arun on here? there's a broken link
<civodul>lagash: i don't think Arun is on IRC, but i can push a fix
<civodul>which link?
<lagash>pardon, it was a link to a link, links to which isn't there, should be
<lagash>I suppose I could just email them?
<civodul>lagash: ah yes, definitely
<stis>Tjena guilers!
*stis thinking about prolog compiling directly to VM code in stead of via scheme
<stis>Maybe some custom operations is needed
<stis>Speed is a real problem in guile-log, the constraint solver taken from swiu prolog takes 15 minutes to compile
<stis>And I think that the reason for the slowness is not the parser as I timed it. It is the guile compiler.
<stis>Too many lambdas I think
<stis>swi prolog compiles that module in less than a second
<stis>3 orders of magnitude slower with guile-log, that's too much
<jgeerds>Hi, I'm currently struggling with the "list-index" function. Even if I take the code example from the official documentation, it fails with (list-index odd? '(2 4 6 9)) => ice-9/boot-9.scm:1685:16: In procedure raise-exception: In procedure car: Wrong type argument in position 1 (expecting pair): #<procedure odd? (_)>. Did I miss anything?
<stis>looks like the arguments shuuld be switched. for the function to work
<stis>nah that one seam to be buggy
<stis>ok, you are using guiles list-index, load srfi-1 first
<stis>(use-modules (srfi srfi-1))
<stis>then the code should work
<stis>I have no idea what guiles list-index should be used
<jgeerds>oh, thank you so much! That was indeed my fault.
<jgeerds>There is even a (very old) bug report due to the shadowing:
<ArneBab>civodul: very cool! (re ccwl)