IRC channel logs


back to list of logs

<wingo>civodul: indeed...
<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>not their places
<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>ok cool :)
<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
<wingo>thoughts welcome
<wingo>zzzzzzzzzzzzz :)
<civodul>hmm fluids have always been thread-local no?
<civodul>new threads would inherit the initial value, not the location
<civodul>or am i confused?
<civodul>anyway the implementation was certainly not super efficient!
***bobo is now known as Guest80747
<amz3>héllo :)
<amz3>viva 2.2
<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>s/server/web server/
<amz3>basically I have not enough unit tests
<amz3>but building them is daunting
<wingo>i implemented atomic ops
<wingo>and a fallback using mutexes
<wingo>and only just now noticed that i'm using the fallback all the time ><
<wingo>friggin autoconf
<paroneayea>heya amz3
<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>ah ok
<paroneayea>make sense?
<paroneayea>no bundling of emacs here :)
<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
<zacts>(for example)
<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>ah ok
<zacts>oh I see
<zacts>ice-9 contains much more of what I'm looking for
<zacts>what does ice-9 stand for?
<zacts>oh cool
<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>ah ok
<random-nick>also the C-interfacing parts are in C
<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: yes, that's what's in master
<random-nick>ft: 2.0 has a compiler tower but it is structured differently
<ft>ACTION nods
<ft>I vaguely remember reading wingo's blog about that evolution.