<m455>is there a way to hide the compilation message before running a guile script for the first time? <m455>darn :P thank you for your answer though! <mwette>maybe try (current-warning-port (%make-void-port "w")) ; I've played with that before but don't remember the outcome <ArneBab>wingo: would I have to change something with this change to keep (set-source-properties! (source-properties line) working — to keep the source information when transforming from read wisp code to scheme? <daviid>ArneBab: afaict, all changes that were discussed recently, including those of today, have been pushed and are in the main branch - maybe you'd like to 'just' try... my 2c ***janneke_ is now known as janneke
<ArneBab>daviid: can I use guile-next from guix for that? <daviid>ArneBab: can't you just git clone ... not using guix <avalenn>I just get hit by the fact that redefining exactly the same record-type twice leads to two incompatible types. When I do reload in REPL in dev phase. <lloda>avalenn: you can avoid that with the #:uid parameter to make-record-type <lloda>but what i usually do is define records in separate modules so i can recompile everything else indepedently <avalenn>I am using define-record-type macro so no chance here <avalenn>The separate module is a good trick. I did not think about it. <wingo>a neat little puzzle i came across the other day <wingo>what is the fastest way to compute the factorial of 1000000 <wingo>for me, recursive fac gives about 160s. <wingo>however there is a way that lets you get around 0.4s <wingo>(i say recursive fac but i meant iterative) <wingo>i.e. (define (fac n) (let lp ((acc 1) (n n)) (if (zero? n) acc (lp (* acc n) (1- n)))) <ft>I would have thought that to be pretty good. <ft>And you've got something that improves performance x400? Huh. <ft>I guess it would have to be something clever, that reduces the number of multiplications. But my math-fu might be too weak. :) <wingo>my 0.4s is just the idea from line 10 in the gist <wingo>my math-fu is also weak fwiw :P <wingo>incidentally we beat v8, both for the optimized solution and the naive solution <ft>Ah, so the idea to to avoid hitting bitints for as long as possible? <wingo>i mean that's one of their ideas but not the important one <wingo>it's not the same as in JS, where bigints are a completely separate type from normal numbers, in guile we just have ints which are transparently either fixnums or bignums <ft>Haha. So I didn't spoil the puzzle for everyone yet. :) ***daviid` is now known as daviid
<ft>Ah, I think I get it now. But I'd have never gotten there without the gist. <ft>wingo: Is there a trick to make the javascript go fast though? I dumped the gist into a file and ran "node foo.js" and it takes forever, and not like a couple of seconds. ***civodul is now known as civodul`
***civodul` is now known as civodul
<civodul>i think i didn't find a good translation of the trick <ft>Calculating the factorial with that node call took ~170s. And it's still producing the string to figure out how many digits it has. I must be doing something wrong. I have never had to execute a piece of javascript before. :) <ft>"toString: 22:12.628 (m:ss.mmm)" Nice. :) ***iridium.libera.chat sets mode: +o ChanServ
***epony is now known as Guest3959
<civodul>quizz: if you read an sexp that has a textual representation of N bytes, how much space can you expect it to occupy in memory? (lower bound) <civodul>assuming the sexp has only symbols, strings, and parens *dsmith-work takes a wild guess <civodul>wingo: am i right that scm_i_make_symbol can use scm_i_substring_read_only instead of scm_i_substring_copy?