***DerGuteM1 is now known as DerGuteMoritz
***fitzgen_ is now known as fitzgen
<amz3`>dump of hn finished, extraction of urls in progress <wingo>ok i have golfed the xorshift128+ compilation down from 54 words to 23 <wingo>the only boxing is for the return value <wingo>now to see if the optimization borks anything... ***katratxo_ is now known as katratxo
<davexunit>does open the door for unboxing any non-logxor things? <wingo>well logior, logand, logsub were already done <wingo>maybe there are some pending lognot cases <wingo>and this does unbox more in arithmetic cases (e.g. (logand #xff (+ a b))). <davexunit>I still lots of fiddling to do with my game engine to avoid boxing and other allocation in the core loop <wingo>this doesn't affect floats at all <davexunit>though I think I need struct unboxing to really do what I'm after. <davexunit>but I'm desperate for performance enhancements so I was trying to think if there was anything these optimizations could apply to. <wingo>mostly useful if you have 64-bit numbers <brendyn>When I run M-x run-geiser, the guile repl uses lots of cpu for 30-60 seconds or so before finally showing up. Seems it is compiling .scm files or some such? <wingo>brendyn: probably related to your other issue about .go file warnings ***dsmith is now known as dsmith-work
<ahstro>Is there any way to make keyboard combinations work like expected in Guile? E.g., ^N and ^P go backwards and forwards in history? <lloda>put this line: (use-modules (ice-9 readline)) (activate-readline) <wingo>paroneayea: an interesting result -- the xorshift128+ rng, written in scheme, is only 50% slower than guile's (random #xffffFFFF) <wingo>not a csprng of course but it's a better non-cryptographic rng than guile's MWC <davexunit>(I don't recall seeing any external seed state, anyway) <wingo>(let ((state (u64vector s0 s1))) (lambda () ...)) <davexunit>oh I see what I did. I didn't see that it was returning a procedure <paroneayea>wingo: so are we going to replace guile's MWC with this? ;) <wingo>tbh i kinda think using guile's rng is always the wrong thing. if you need true randomness you need a csprng. if you need reproducibility you should use your own RNG so that you can reliably save the seed state and be robust in the face of changes to Guile's RNG. <wingo>i am not sure what guile's blessed rng is for, basically <wingo>and the api around *random-state* is trash <davexunit>every language implementation comes with a RNG <wingo>yeah i can understand that. i think the right thing tho is probably to make a module, get that module accepted in guile, and deprecate guile's core RNG interfaces in favor of that module <wingo>and replace guile's core RNG code with shims that call out to the module <davexunit>I thought you were saying remove the RNG altogether <wingo>yeah having a module sounds ok <ahstro>Is it possible to start a repl and have the variables/procedures defined in a file available? <quigonjinn>ahstro: the simplest way it to use the -l <file> flag, when firing up the repl. <a_a_>Hi! Is there anything like (random-int start end) in Guile? <a_a_>I guess (random n) will do for now <jmd> How am I to interpret (1 2 . 3) ? <jmd>OrangeShark: Yes. I just wonder why it is not printed (1 . (2 . 3)) <jmd>But not easier to interpret. <OrangeShark>you would have to determine whether a list ends in null or not before printing it as a list or the dotted pair notation <davexunit>jmd: would you really want the list (1 2 3 4 5) printed as (1 . (2 . (3 . (4 . (5. '()))))) ? <jmd>davexunit: But that list ends in '() -- as do all lists. <jmd>my example, does not end in '(). Ipso facto, it is not a list. <davexunit>there's no way to know without traversing the entire list <jmd>So in other words this is a limitation of the REPL. <OrangeShark>I guess you can write a REPL with a different print that would have to traverse pairs to determine which print format to use <davexunit>it's printed this way because it's deemed more readable <davexunit>it would be trivial to print the list differently based on the result of 'proper-list?' <davexunit>but it's not done because it's not how most people want to see an improper list printed <DeeEff[m]>Are we talking about (a b . c) vs (a . (b . c))? <DeeEff[m]>granted pairs in Scheme certainly do cause confusions for beginners (e.g. I thought it was lists all the way down vs everything is a pair and most pairs form trees that look like lists if they are flat...) <jmd>DeeEff[m]: I think that is basically the problem. From the left, it looks like a list. But it is not. <DeeEff[m]>which is I think the mental thing that blocks a lot of people from truly grokking the difference between lisp and scheme <dsmith>Yeah, some people can't see the list for the pairs. <moosnat>is it possible to `eval` a sexp in an environment with no functions defined?