IRC channel logs
2025-03-05.log
back to list of logs
<janneke>using define-actor with #:key and #:self gives me: Unrecognized keyword: #:key <janneke>(using only #:key or only #:self works fine) <janneke>ACTION removes #:self self, and adds a self #:key so be set upon init for now <andreas-e>janneke, I just tried it out, obtain the same result, and am none the wiser... <andreas-e>A question of my own: I am trying to persist a netlayer, and am copy-pasting parts of the examples. <andreas-e>When I register an object on the netlayer, I get this error message: <andreas-e>Cannot save deltas until a whole graph has been stored first <janneke>andreas-e: thanks; yeah and #:key (foo "bar") gives also an interesting error (when using #:self) <tsyesika>the #:self keyword also has some persistence issues so we're planning to change how self works <tsyesika>obviously we could have just not had the inner self actor not take arguments, don't remember if there was any reason we had the inner self actor have arguments <tsyesika>andreas-e: persistent vats initially when spawned write out the entire graph to the store and then just write deltas after that. Occasionally if you hit an error when spawning the vat the initial graph won't be written and then in future turns when it tries to write a delta it'll fail. I'm guessing that's probably happened in your case <tsyesika>Not sure if there are any improvements to be made there. Maybe we could keep around some information to tell us if we've managed to write out the full graph, then switch to deltas after <andreas-e>tsyesika: Indeed that appears to have happened. I have now copy-pasted an example from the documentation. <andreas-e>The top of the pastebin is the script I am running, the bottom the error message; with goblins-0.15.0 from Guix. <tsyesika>you're right it doesn't work, it's missing the captp-env <andreas-e>For me it also fails with version 0.14.0, but with a different error message. <tsyesika>`(make-persistence-env #:extends (list tcp-tls-netlayer-env))` needs to be `(make-persistence-env #:extends (list captp-env tcp-tls-netlayer-env)` <andreas-e>I had understood and tested, thanks! Now on to testing whether what I really wanted to do works :) <jfred>garbados: I was just giving Hoot a try and ran into the same issue with 'guild compile-wasm' that you did. I think you need 'guile-next' instead of 'guile-3.0' in your dependencies for Hoot <jfred>finally updating guix on my reform too because I went to try out goblins in hoot and realized I was on too old of a goblins version to do that <garbados>jfred: now i get "module not found (goblins)" <jfred>same, trying to figure that one out. I don't yet have a good handle on how module discovery works when compiling hoot programs <garbados>i'm just mimicking what i see in the goblins and hoot repos because i can't find any documentation on standard packaging practices <janneke>ACTION just found that goblin doesn't play nice with (match (($ <record-type>) ..) <janneke>i guess you could use (match ((? recond-type?) ...)) but yeah; other ideas? <janneke>move matchers to a utility file possibly? <janneke>otherwise, possibly going for (use-modules ((goblins) #:select (($ . <-$)))) for now <andreas-e>garbados, jfred: How did you install goblins? In guix it should be enough to install guile-goblins. <andreas-e>Otherwise you could add its location to the environment variable GUILE_LOAD_PATH. <civodul>janneke: i guess it’s ok if you #:rename the ‘$’ binding from Goblins? <sneek>civodul, you have 1 message! <sneek>civodul, apteryx says: in commit dd64f441d3, I introduced a configuration option to invoke udevd with --debug, which causes more verbose output to go to stderr; oddly this seems to hang shepherd, or oiat least the boot. Could writing to stderr this early during boot be problematic from some shepherd logging point of view? <jfred>andreas-e: Via guix, but in a project-specific manifest. I've always found that I've needed to include guile (or guile-next in this case) in my manifest for that to work (presumably because the system version of guile won't be able to find the guile libraries in a 'guix shell') <garbados>i pray i do not have to compile from source <andreas-e>There is no way to speed up the "Computing derivation" phase. <garbados>cool, so updating just takes an hour or more and that's just how it is? <garbados>"take one of the commits" what do you mean? cherry-pick it to where? build guix from source? <andreas-e>Well, maybe not. I do not think that the results of "guix pull" on data.guix.gnu.org are communicated back to the substitute server. <garbados>"this phase should only take a few minutes" do you want me to run `time guix pull` so i have data to show you how long it takes <andreas-e>I am not talking about all of "guix pull", but specifically the "Computing derivation" part of it. <andreas-e>Other parts of "guix pull" are derivations that will result in data in the store. So when you have a machine with several users who do "guix pull", all of them need to do the "Compute derivation" phase; apart from that the first one will have to suffer and for the other ones it will be a bit faster. <jfred>garbados: re: commits, you can refer to a specific guix commit in a 'channels.scm' file (defaults to ~/.config/guix/channels.scm, but you can override the default file with 'guix pull -C /path/to/channels.scm') <andreas-e>Sometimes the derivations are on the substitute servers. <garbados>i have tried modifying the channels.scm file but have never gotten it right. is there an example or documentation i can refer to, jfred ? <andreas-e>You can also just do "guix pull --commit=37ec17c43af4bb8e60e8e1882a0225139ac39e8b" <andreas-e>No need to touch channels files; the commit refers to the guix repo itself (I do not think you can specify commits for other channels in this way). <jfred>andreas-e: guix defaults to channels without substitutes though, right? so that would still result in building all the package definitions if I'm not mistaken <andreas-e>and use one of the commits in the "Channel changes" column. <jfred>garbados: the code snippet at the guix manual link I posted above is a valid channels.scm file, if that helps <andreas-e>I never tried this code snippet, it is a very good idea, and I think it does internally the same thing as what I suggested to do by hand. <garbados>jfred : i will try it after guix pull completes. i don't want to interrupt the terrible mysteries of guix <jfred>garbados: One other thing that might help: if you want to "undo" a guix pull for whatever reason, you don't need to do the long "guix pull" process again, you can run "guix pull --list-generations" and then "guix pull --switch-generation=<num>" where <num> is a generation number from "--list-generations" <jfred>in contrast to a normal guix pull, switching to a previous generation is nearly instant <jfred>(because ultimately it's just switching around some symlinks) <garbados>if i run into the same problem i had last time ("guile-hoot not found") i will, um, try some of the things listed, and pray <garbados>accursed question: are there plans for implementations of goblins in other languages? <garbados>ok. an hour later, fresh guix, guix pull completed, hash guix, and: `module not found (goblins)` <garbados>running `guix shell --container` gets me a different error: `Unbound variable: compile-file` <garbados>i am just following the instructions in the documentation. i am out of my depth and i just want it to work <jfred>garbados: I just managed to get past that point by adding the guile-goblins repo to my repo as a submodule and including it in the load path with "guild compile-wasm -L". But then I ran into another issue with a dependency of Goblins that I wasn't expecting, so I'm stuck. Posted on the forum here: https://community.spritely.institute/t/running-goblins-on-hoot/690 <andreas-e>I just tried "guix shell guile guile-goblins". This does not update the GUILE_LOAD_PATH variable. <andreas-e>I would try to do the following: "guix package -i guile-next guile-goblins ..." with all the packages in your manifest on the command line. <andreas-e>Then try whether the module is found. In the end you can still go back using "guix package --roll-back". <andreas-e>Actually "guix package -m manifest.scm" should also work. <garbados>i don't know what to do next and i'm just gonna give up at this point. i have a checkout of guile-goblins and guile-hoot and adding them to my load path changes nothing. i still get "unbound variable: compile-file" <dthompson>garbados: hard to say with any certainty but a common pitfall is having a shell config that clobbers the environment variables that 'guix shell' sets up <dthompson>to test, I ran 'guix shell', 'echo 42 > foo.scm', then 'guild compile-wasm -o foo.wasm foo.scm' and all was well <dthompson>also iirc last time we talked I shared code for building a newer hoot from a git commit to get around breakage from a recent guile-next update in guix <dthompson>jfred: I think andreas-e has shell config problems. <dthompson>the typical problem is a .bashrc that overwrites environment variables. it's one of those things that you shouldn't do but is widespread practice. .bash_profile is the appropriate place for setting environment variables. <dthompson>I recommend incorporating the package into your guix.scm and using it instead of guile-hoot <dthompson>but you can use it as-is now just to test things out <jfred>by copying the modified package definition from the manifest (define guile-hoot* ...) into guix.scm above your goblins-playground package and changing "guile-hoot" in your propagated-inputs to "guile-hoot*" <garbados>oh boy a new error: module not found (ice-9 vlist) <dthompson>that's an easy one. you need to add guile's module source to your load path while compiling. <dthompson>something like '-L $GUIX_ENVIRONMENT/share/guile/3.0/' ought to do the trick <garbados>just to be clear, this is my invocation: `guild compile-wasm -o www/goblins.wasm guile/goblins.scm -L ../guile-goblins -L ../guile-hoot` <dthompson>and also not correct anyhow as the hoot libraries would be in ../guile-hoot/lib but those are built-in so you don't need any flags <dthompson>hoot aims to be a full implementation of guile but we're not there yet so there is still this separation between guile's standard library and hoot's <dthompson>for goblins, we've made sure that the subset of the modules we need from guile's standard library will compile <garbados>so i got it to run. i guess i will need to include guile-goblins as a git submodule <garbados>is there a way to make `guix shell` both run a command in isolation, and use guix.scm? like `guix shell -- my-command` except in such a way that it uses guix.scm before running the command <dthompson>that's an option, or if you're fine with the version that's in guix you can just use the sources that are already installed <garbados>i'm trying to make a `npm run guild` command that compiles wasm and then exits the shell <dthompson>this should get you all the goblins stuff: '-L $GUIX_ENVIRONMENT/share/guile/site/3.0' <dthompson>garbados: I don't quite understand the question. 'guix shell -- my-command' *does* use guix.scm before running the command <dthompson>'guix shell -- guild compile-wasm -o foo.wasm foo.scm' for example <dthompson>garbados: when used in a script, you need to do 'guix shell -D -f guix.scm' <dthompson>the default behavior only occurs when run interactively, not from a script <garbados>great, that's what i wanted to know. on to the next error... <garbados>the problem appears to be that it's evaluating $GUIX_ENVIRONMENT prior to entering the shell. i don't know how to make it do so *after* entering the shell <jfred>oh, yeah, because the shell is doing variable expansion immediately before it even runs guix... hmm <garbados>i would just really like to have a one-liner for this, so that i can, for instance, have a CI process build the necessary wasm files, or a dev workflow that doesn't require operating in a guix shell <jfred>garbados: one possibility: guix shell -D -f guix.scm -- bash -c 'guild compile-wasm -L ../guile-goblins -L $GUIX_ENVIRONMENT/share/guile/3.0/ -o www/goblins.wasm guile/goblins.scm' <jfred>single-quotes suppress variable expansion at the top level and then the new bash instance expands variables once it starts <garbados>now i can start updating goblins.scm to bring more features into the browser :) <jfred>I pulled in goblins only via some shenanigans and that worked: guild compile-wasm -L $GUIX_ENVIRONMENT/share/guile/3.0 -L $(readlink $GUIX_ENVIRONMENT/share/guile/site/3.0/goblins)/../ -o test.wasm test.scm <jfred>(...but I don't like it, haha) <jfred>seems to be related to hoot trying to build itself or some such <janneke>i'm using (sleep x) but that seems to block everything, what am i missing? <tsyesika>Sleep blocks the entire vat, you can make a promise with sleep by using something like this: (spawn-fibrous-vow (lambda () (sleep 1) #t)) <tsyesika>Usually you want to look at using promises instead of polling though <janneke>i want a keep-alive thingy, that sends a 'ping every x seconds <tsyesika>Ah right. Yeah you probably want something like what I suggested then <tsyesika>We probably want to add the is to actor-lib <janneke>ACTION tries to wrap their head around <janneke>#<&compound-exception components: (#<&error> #<&origin origin: #f> #<&message message: "No current syscaller"> #<&irritants irritants: ()> #<&exception-with-kind-and-args kind: misc-error args: (#f "No current syscaller" () #f)>)> <dthompson>jfred: seems that adding the guile site dir is no good, darn <dthompson>or maybe not? idk but it's complaining about the (hoot primitives) module which doesn't make sense to me <dthompson>maybe your environment is misconfigured somehow? idk <dthompson>janneke: (with-vat vat (spawn-fibrous-vow (lambda () ...))) <jfred>dthompson: it does seem to be related to the guile site dir including hoot itself, I get the same thing if I include only the hoot directory from the store (with e.g. -L $(readlink $GUIX_ENVIRONMENT/share/guile/site/3.0/hoot)/../) <janneke>dthompson: okay, so i'm using this in an actor, do i need to pass the vat to that actor and then do (with-vat vat ...) inside the actor's methods? <dthompson>jfred: really what we need is a way to install hoot libraries and not uses guile's install dirs at all, so as not to mix up host vs. target code which is what is happening here <dthompson>we just don't have the tooling built for this yet <dthompson>janneke: no 'with-vat' is just used to bootstrap your program <dthompson>it's the entry point to do some work within goblins <janneke>dthompson: yeah, i have that on toplevel <janneke>tsyesika: yeah that was my understanding...hmm <dthompson>having some code to look at would help spot the issue <dthompson>this is probably the most common pitfall we've seen <jfred>and then maybe there should be a 'hoot build' command or similar that wraps the guile compiler and sets up the right search paths to find installed hoot libraries <dthompson>idk about that. we already have HOOT_LOAD_PATH <dthompson>being both a cross-compiler and a whole-program compiler adds to the conceptual burden here <dthompson>we just need a good way to gather up code in a *separate location* from what the guile vm is using <dthompson>jfred: ah I see why (hoot primitives) is an issue. it's special. it's a module on both the host and the target, but sinc e it's the root of the module graph it is created procedurally <dthompson>cow_2001: this is due to a change in guile main that was made post hoot 0.6.0 release. guix updated the guile-next package and now things are broken. <dthompson>if your program (and all included modules) doesn't use define-values then you can avoid it <janneke>tsyesika: i'm trying to move the snuik irc bot from 8sync to goblins...but it's still quite a battlefield <janneke>i'll see if i can make a simple example <jfred>dthompson: aha :) I will admit that keeping track of what runs on the host and what runs on the target breaks my brain a little bit when browsing the hoot source haha <cow_2001>just replaced (define-values (bare tree fire) (values 0 1 2)) with three defines... <tsyesika>:) I wrote an IRC bot with goblins a while ago. It was quite some time ago though so I don't know if it still runs or if it's even good code hehe <dthompson>janneke: oh neat project! should be very doable. we can help. <tsyesika>I apparently updated it 11 months ago. I have no memory of this <dthompson>jfred: it breaks my brain too and I work on it! <jfred>dthompson: setting (hoot primitives) aside, if hoot is eventually meant to be a complete guile, does it make sense to gather up libraries in a separate location specifically for hoot? <dthompson>I think the sensible thing to do would be to automatically add guile's own modules to the load path (not the 'site' dir) <dthompson>we have copied a module or two into hoot when it needed significant changes but we don't want to continue doing that <dthompson>nor do we want make exact copies that can get out of sync <janneke>hmm, it seams i need to to ^read-write-io or something...8sync would make all io non-blocking but that needs wrapping in goblins <tsyesika>yeah I think you'd want to use the io actors for dealing with sockets <tsyesika>Hopefully the docs around io actors are enough, but if you want to see more uses of io actors, most of our netlayers use them too when dealing with sockets. <dthompson>jfred: yeah that's a good temporary measure. hoot can just do this procedurally at some point. <dthompson>janneke: the i/o is nonblocking in goblins due to fibers, but nonblocking is not sufficient <janneke>the "sleeper" example from the 8sync docs just worked (tm), i'll see if i can create a simple example maybe tomorrow <dthompson>a nonblocking read is still going to suspend the vat's fiber <dthompson>(define (timeout duration) (spawn-fibrous-vow (lambda () (sleep duration) #t))) has been sufficient when I needed to wait for timeouts <dthompson>then I can (on (timeout 5) (lambda _ (pk 'hey))) or whatever <jfred>dthompson: What would be the downside of including installed site modules in the default load path though? (Assuming there was some way to get around the 'hoot primitives' issue) <janneke>i've seen code that uses fiber's (perform-operation (sleep-operation timeout)) that seems to also work <dthompson>it's a wrapper around that perform-operation code