<koz_>dsmith-work: A stupid error. <wleslie>dsmith-work: welcome back! we missed you. <solrize>paroneayea, nice, that's good experience <koz_>Tail recursion truly *is* its own reward. <koz_>Is there a premade Guile function that takes an arity-1 function and a list, and returns the element of the list that receives the highest numerical score from the function? <koz_>Or am I gonna have to hand-roll it? <fps>koz_: not knowing much guile: why not implement a order, sort the list and take the car? <fps>the order i would imagine is a 2-ary function that could take your 1-ary function to compare the two in a closure <koz_>fps: I just realized I could do this by combining max, map and my function, lol. <koz_>You map out, then reduce on max. <fps>many roads lead to rome <taylan>koz_: would hand-roll with named let, personally <taylan>if you only need the highest result, then map + apply/max will do, but if you need the object that gave the highest result, that's a bit trickier with map/apply/max <taylan>hihest value: (apply max (map proc objs)) <taylan>could do something slightly weird to avoid the named let: (let* ((vals (map proc objs)) (highest (apply max vals)) (index (list-index (cut eqv? <> highest) vals))) (list-ref objs index)) <taylan>I'd probably just go with the named let, personally <koz_>Now I have a different issue. <koz_>I basically have to separate 24 elements into 16 and 8. What's a good way of enumerating *every* such separation, assuming order doesn't matter? <koz_>(assume all 24 elements are unique) <lloda>koz_: google up Knuth vol IV, 'Generating all combinations', algo L or T <andy_js>I’m builing guile 2.1.1 and it seems to be taking an eternity. Is this normal? <andy_js>This is on a machine with 24 cores and 192GB RAM. What the heck is it doing? <andy_js>I haven’t yet seen it make it past compiling the contents of the ice-9 directory. <wingo>andy_js: did you make -j24? to begin with it compiles ice-9/eval.scm and ice-9/psyntax-pp.scm serially, then the rest in parallel <wingo>it bootstraps itself off of a simple c interpreter, progressively compiling more of the compiler <wingo>which speeds up the process as it goes <wingo>it takes about an hour to build on a consumer -j4 machine <wingo>so i assume you are waiting for psyntax-pp.scm to compile :) <wingo>it is the one that takes the longest, and parallelizing it doesn't help for various reasons <wingo>i need to write all of those reasons up some day, it's a bit of a faq right now <wingo>as well as options for making it faster <andy_js>There could be other factors at play though. It was erroring out originally with “stack-overflow”. <wingo>did you modify the build in any way or were you just making in the root with -j24 ? <andy_js>I hacked up libguile/debug.c (changed the default stack size from 160000 to 0) to get it past building eval.go. <wingo>did you build with -O0, perhaps? <andy_js>Good question. I might have done. Let me check. <wingo>that would make the C interpreter consume more stack space, which would explain the stack-overflow while compiling the scheme interpreter <wingo>it will also slow down everything else by a factor of 3 or so <wingo>i usually use -O2, i don't know if -O3 does anything for us <wingo>tx for the report tho, we need to test -O0 builds and possibly increase the default C stack limit... <wingo>andy_js: what does "ulimit -s" print for you <andy_js>I set it to unlimited. It was 10240 by default. <wingo>i think when you set it to unlimited then Guile ends up choosing an arbitrary limit for the c stack <wingo>not sure i remember tho; the c stack limit is only important when compiling eval.scm <wingo>only during bootstrap, basically <andy_js>I set it to ulimited in an attempt to resolve the problem. I did it before hacking up the source. <andy_js>Didn’t make any noticable difference. <wingo>maybe the limit is arbitrary in any case <wingo>i assume you are on an x86-64 machine <wingo>so.... if you make clean you can even revert your modification and things should work. if you need -O0 you can then "make -C libguile clean all CFLAGS='-g -O0'" later <wingo>or you can keep your modification and things should also work <wingo>but anyway, i would expect a total compilation time of around 40 minutes due to some non-parallelizable bits <andy_js>Oh you’ve got to be kidding me. The darn thing just coredumped. <wingo>ACTION hasn't compiled -O3 in a while <wingo>i am rebuilding with -O3 here, on an older i7, though for 64 bits and gcc 5.2 <wingo>note of course that a core dump is one way a c stack overflow would manifest itself <wingo>on a 64-bit system where my .go files were compiled already i recompiled libguile with -O3 on gcc 5.2 and the test suite passes for me, fwiw... <andy_js>No coredump with -O2. It’s compiling the stuff in the ice-9 dir again. Maybe this time it’ll actually make it past that stage. <andy_js>Oh wow it just compiled eval.go much faster than last time. <andy_js>You know if compiling with -O0 doesn’t work it might be a good idea to document or have some configure check look for it in CFLAGS. <wingo>i think the goal is to have compilation work with all -O settings, though we should probably echo a warning if we see -O0 <wingo>but the crash with -O3 sounds like a bug somewhere :( <andy_js>Is it worth me trying to put together a patch? <andy_js>For the -O0 check and warning I mean. <andy_js>I’m not going to tackle that core dump. <wingo>sure, it would be welcome :) <wingo>if you can reproduce the core dump some time tho a backtrace would be welcome too :) <wingo>just send a mail to bug-guile@gnu.org with the info <andy_js>I’ll look into that once I have it compiling. Right now it’s on psyntax-pp.go <wingo>that will take some 15 or 20 minutes. <andy_js>It’s kind of annoying because I can compile a kernel in that time. <andy_js>This seems to be taking longer than 15-20 minutes. <wingo>the psyntax-pp compile you mean? <wingo>it will finish eventually :) <andy_js>SUCCESS! It made it past that phase. ***__ransom__ is now known as ransom_
<andy_js>Do emails to bug-guile@gnu.org need to be approved before they are visible? <paroneayea>davexunit: thinking of your picture language comments last night <paroneayea>davexunit: and then watching the stumpwm people considering making a "new generation" window manager <paroneayea>I can't help but think that something like the SICP picture language would be a great design for a tiling WM's abstractions <paroneayea>building up so many procedures may become hard to inspect? <taylan>ACTION still just uses everything full-screen :P <amz3>how can I catch Ctrl-C in a guile program? <davexunit>paroneayea: yeah, I want to do what xmonad does, basically, just in lisp. <davexunit>which would look a lot like SICP's picture language <davexunit>guile-wm needs a purely functional interface, though. <dsmith-work>I'd rather it be customizable in Guile than lua, but I basically use it out-of-the-box. <davexunit>guile-wm was great because it's live hackable. <amz3>madsy: thanks, what's Ctrl-C signal name? <paroneayea>I think guile-wm was also doing something like "splat to the X11 layer directly!" <paroneayea>I think a good guile WM today might want an abstraction layer there, especially given wayland looming <OrangeShark>I wonder how a desktop environment with guile would be <Xe>i tried installing guile from source and it broke my non-source guile install <Xe>how do I clear out the cached compiled thingys? <Xe>clearing out the cache didn't work <amz3>Xe: did you try make uninstall? <amz3>actually i'm trying to execute some code when stoping the web server <amz3>problem is sigaction works, but when I try it with the web server it doesn't <amz3>Xe now try to purge the install of guile with your system package management system and re-install it <amz3>well on ubuntu... it works... I use guile-2.1 installed from source <amz3>another solution is to install guix on top of debian <amz3>I'm out of ideas sorry, maybe someone else will chim in <davexunit>idea: a git repository web interface called "Sauce" <lfam>davexunit: sounds like a Boston joke ;0 <amz3>my sigaction wasn't working because run-server already register a sigaction, so that I don't need to do so. ***Guest8443 is now known as berndj
<wirrbel>I have a procedure containing a named-let form. Basically I would like to trace that named let function, but I cannot do this from the REPL, as the function is within the scope of the procedure <wirrbel>any other way then pulling it out into a defined function? <koz_>What's the simplest way of finding the modal value from a list of numbers? <koz_>(modal meaning 'the most common') <amz3>koz_: I don't a simpler way but counting via an hashmap or alist <amz3>wirrbel: using pk isn't enough to "trace" the behavior? <amz3>wirrbel: I don't see the issue of pulling the named-let outside the procedure <amz3>pk which called peek, it prints the input and return it <amz3>sorry it's prints all the args and return the last <koz_>davexunit and amz3: Thanks, I ended up doing that anyhow. <koz_>In your folks' experience, would Guile have serious issues with a list of about 750,000 elements? <koz_>(The elements in question would be rationals) <davexunit>is this is relation to building the histogram? <davexunit>long lists haven't been an issue for me most of the time <koz_>davexunit: This is in relation to generating all combinations. <koz_>(which I still need to find a way to do) <davexunit>it really depends if O(n) access time will be a problem for you or not <koz_>What I'm really after is an algorithm that can generate all size-16 subsets of the set { x | 0 <= x < 24 }. 