IRC channel logs
2022-01-14.log
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>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 <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! <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 <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) <civodul>wingo: looking at optimize.scm, it seems just not having the keyword is enough, no? <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 <lagash>I suppose I could just email them? *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.