<wingo>it was also because dynamic states were kinda wonky <wingo>i am going zzz but ponder this :) <wingo>it seems dangerous to me to have fluids share a "place" for their values between multiple threads <wingo>what you actually want is when you spawn a thread (or create a new dynamic state), is to inherit the current values of the fluids <wingo>so make-dynamic-state should capture values <wingo>instead of capturing a place <wingo>i implemented that and now the test suite still passes <wingo>that is a bit unexpected but a happy thing :) <wingo>actually maybe that's what dynamic states did... <wingo>the other thing is that this lets us mark some fluids as being local-only, meaning that their values aren't inherited by a make-dynamic-state / make-thread / etc <wingo>so we can have truly thread-local variables made on fluids, without the danger that those variables (places/boxes) escape the thread <wingo>(is that true for a continuation that moves threads? will have to think about it.) <wingo>anyway, some benchmarking to do before landing, and etc etc <civodul>hmm fluids have always been thread-local no? <civodul>new threads would inherit the initial value, not the location <civodul>anyway the implementation was certainly not super efficient! ***bobo is now known as Guest80747
<amz3>paroneayea: how can I test https support using guix? <amz3>what about a http-get*? that goes through the ceremony to open a socket for the uri et al. ? <amz3>I am in a skill plateau, climbing the hill seems overhelmingly difficult <amz3>basically I'm stuck with culturia the search engine. Building a "whole" database myself seems very difficult <amz3>Even it seems mostly working, scaling the code in terms of line of codes seems impossible <amz3>debugging is very difficult because each time I need to spin a server, unit testing is impossible <amz3>basically I have not enough unit tests <amz3>but building them is daunting <wingo>and a fallback using mutexes <wingo>and only just now noticed that i'm using the fallback all the time >< <paroneayea>amz3: hm I have a package but I haven't submitted it yet! <zacts>wait so guile emacs is now part of guile.git? <paroneayea>zacts: not quite... there's a wip-elisp branch that supports emacs lisp, as a language <paroneayea>which is used by the guile emacs branch of emacs <zacts>I'm trying to navigate the guile.git for guile specific code <zacts>where is the interpreter there? I don't see a src/ directory <ft>The C code is in libguile. The Scheme code is in modules. <zacts>is there an effort to port much code implemented in C to guile? <ft>The first thing that happens when guile starts is in modules/ice-9/boot.scm <zacts>it seems much of the interpreter is implemented in C <zacts>ice-9 contains much more of what I'm looking for <zacts>s/much code implemented in C to guile/much code implemented in C to guile scheme/ <random-nick>zacts: the virtual machine is implemented in C, and the guile scheme to guile bytecode compiler is implemented in guile scheme <zacts>could guile-scheme be ported to another VM? <zacts>say something implemented for JavaScript? <random-nick>zacts: guile's bytecode compiler is implemented in stages which form a "compiler tower" <random-nick>zacts: scheme gets translated to tree-il, where a few of the optimisations are done, which is translated to CPS, where basically all optimisations are done, which actually translated to guile bytecode <ft>random-nick: That's what's happening in master, right? <random-nick>ft: 2.0 has a compiler tower but it is structured differently <ft>I vaguely remember reading wingo's blog about that evolution.