IRC channel logs
2023-12-21.log
back to list of logs
<Guest86>Hi, sorry for the very basic question but I am having trouble finding an answer. <Guest86>then ran guix shell --pure guil-next guile-hoot <Guest86>I get an error in the next section. The documentation suggests, "The file name js-runtime/reflect.wasm assumes you are currently located in the Hoot build directory. Adjust as necessary for your context. " <Guest86>My question is how do I find the Hoot build directory in the new hoot 0.2 ? <dthompson>Guest86: I'll preface my answer by saying that in hoot 0.3.0, reflect.wasm will be automatically loaded for you and you won't have to worry about this again. for right now, though, you can find reflect.wasm with guix like this: echo $(guix build guile-hoot)/share/guile-hoot/js-runtime/reflect.wasm <dthompson>(call-with-input-file "/gnu/store/.../reflect.wasm" parse-wasm) <dthompson>we're very glad this is going away in 0.3.0... <Guest86>I understand! Thank you for the details. <dthompson>I have been fixing bugs a lot this week. also added some basic exception printing which 0.2.0 doesn't have :x <dthompson>today I wrote a little guile web server that automatically recompiled my wasm file when the scheme source file changes. makes development feel a little more like the instant gratification you get when you edit a javascript file and refresh... just a little slower <Guest86>I don't know if this is useful to you or not, but: <Guest86>scheme@(guile-user)> (define hoot-factorial <Guest86>i get errors with reflect-wasm, but it works with if I replace reflect-wasm with reflector <Guest86>It is also very possible that I don't understand enough to know why it should have worked. :) <dthompson>Guest86: oops, it looks like I forgot to update the "latest" pointer for the docs to point at the 0.2.0 docs! that typo is fixed in the 0.2.0 docs. <e-snail>hi, in geiser, `(spawn-vat)` is telling me `In thread: Unbound variable: events-impl-create` <dthompson>e-snail: hmmm, that sounds like a fibers error but I haven't seen it before. <dthompson>fibers is a library we use for the concurrency stuff <e-snail>I'm sure it's related to geiser/guix because it seems to work in the guix-installed guile REPL; I just don't know how to move forward debugging <dthompson>well, I can see that events-impl-create is a symbol in fibers, in the (override fibers events-impl) module <dthompson>that module has a bunch of epoll stuff in it. I'm not familiar enough with the implementation of fibers to know what might be going on. <dthompson>I use goblins via geiser a bunch and haven't seen this <e-snail>there was a debian guile clashing with the guix guile; uninstalled it and it works <e-snail>I can eval sexps in the geiser REPL but if I try to C-x C-e to eval them from another buffer, (ice-9 boot-9) complains "No current syscaller" <e-snail>anyone know what geiser stuff I need to do for that to work? <dthompson>"no current syscaller" means you're trying to eval something outside the context of a vat <e-snail>right, I'm wondering how I can get geiser-eval-* to work as expected when the REPL is in the context of a vat <dthompson>oh I see the mixup. using the REPL buffer and evaling in a scheme buffer are two entirely different things <dthompson>when you eval from within a buffer, you're evaluating in the context of the module that buffer defines <e-snail>I assumed it was sending to the active REPL <dthompson>it's not as if you are copy/pasting expressions into that interactive REPL buffer <dthompson>they're being evaluated by the same guile process, but in a different context <dthompson>the reason for this is so that you can work on many guile modules simultaneously and have the evaluation happen in the top-level environment of whatever module your buffer defines <e-snail>so when does spritely plan to publish the Structure and Interpretation of Goblins Programs? 🤔 <e-snail>could copy the original SICP cover and give the wizard some goblin familiars <dthompson>we do have plans to write more about actor programming patterns and stuff <jfred>Something I've been thinking about lately: could you relatively transparently distribute vats across machines in a cluster as they're created? I'm imagining, for example, each new vat that's created getting scheduled as a pod on a Kubernetes cluster. (K8s may not be the best clustering system for this, just a relatively popular one) <dthompson>well vats have to be explicitly spawned on a given machine <dthompson>but more generally, load balancing is definitely possible <dthompson>you could have a gateway actor in a vat on machine A that proxies requests actors in vats on machines B, C, and D <jfred>I was thinking about this as I was working on my Horton implementation - currently I'm creating a vat for each user to keep their proxies separate in some ways, but in the long term I probably would want to be able to distribute those across machines somehow too <dthompson>like you have actors spawning new vats? I dunno if that's the best idea <jfred>I can see how to load balance between actors on other machines, but I'm wondering about the scenario where those other actors don't yet exist <jfred>but yeah, currently I do haha - and it seems to work at least :P <dthompson>one way you could model this is with an actor that is the cluster interface and it has a registry of members <dthompson>when a new user is created, it picks a member to host the user <dthompson>having actors that spawn vats feels like "higher order vats" and maybe there's a good reason to do it but I think you could probably avoid the complexity <dthompson>it's also helpful if you can model your problem space in terms of actors only <e-snail>is there any index of projects people are making with goblins? <jfred>hmm. that's a good point re: having an actor acting as the cluster interface... re: vats for each user though, it feels like it might be desirable to keep users in separate event loops though, because then blocking behavior in one vat mostly can't affect the others <dthompson>jfred: single tenant vs. multi-tenant could be a decision left up to the cluster host <dthompson>the same model would work for both. single tenant is the trivial multi-tenant case :) <dthompson>e-snail: not currently! we are aware of a few projects, like jfred's horton <jfred>the other thing I've been thinking about is how to get to the point where a single machine going down is recoverable <e-snail>I'm sure there will be an awesome-goblins repo soon enough <dthompson>yeah I think we could use something like that. we're beginning to gear up more community-focused things now that we're starting to get enough attention. <dthompson>jfred: probably that case requires our safe serialization layer that we're working on <jfred>I'm excited to give that a try once it's ready <dthompson>but yeah my general advice is: focus on actors, not vats <dthompson>for development you can simulate a whole cluster in a single vat. move some actors elsewhere and that will work, too. :)