IRC channel logs

<jfred>So I think I've run into this before in the Racket version, but something I've been running into... how would you go about testing async Goblins code? The tests in the Goblins project itself use actormaps directly, but I'm trying out some actors that themselves spawn vats with objects in them and I'd like to exercise that

<jfred>The test in this file for example doesn't run, I assume because the promise isn't resolved before the test run ends: https://gitlab.com/jfrederickson/guile-horton/-/blob/master/tests/test-user-manager.scm

<jfred>(I had some success in another test module $-calling a method that returned a promise and waiting on that with `on`, but now I'm putting things in separate vats so it needs to be async)

<jfred>Ah... I'm poking around at the REPL and the very first promise never resolves with `,vat-resolve` either. I guess I have a bug to track down haha, even if I could wait for that last promise to resolve before finishing tests it currently never would

<vvvvmvr[m]>in here https://gitlab.com/spritely/guile-goblins/-/blob/main/tests/utils.scm there's a method resolve-vow-and-return-result -- might be a way to do this (though I do not know for sure). I do think the internal unit tests make use of this, however.

<vvvvmvr[m]>s/method/function

<vvvvmvr[m]>Also, fairly obvious, but I think you'd want the test-equal to be wrapped around a call to that, otherwise, if the promise never resolves the test won't even execute (since right now test-equal is inside the promise)

<jfred>Ah! That looks helpful

<jfred>and yeah, I forget why I was doing it that way before... I think because it was the only way I knew how to get at the actual resolved promise value from within my test

<jfred>this looks like it might do the trick though, I'll give it a go. thanks!

<cwebber>vvvvmvr[m]: jfred: yay, glad the official tests helped you find how to do your own tests :)

<jfred>cwebber: That's how I learned how to do a lot of things in Goblins! The tests have been wonderful examples of how to use it. (And that was exactly what I was looking for, thanks vvvvmvr[m] for the help!)

<vvvvmvr[m]>The tests are also really cute, existential, or fun sometimes

<jfred>they are, haha

<vvvvmvr[m]>ACTION sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/818c524819cf99b7d388f4481a38cdf052dd7b61

<cwebber>jfred: :D

<jfred>One odd thing that I guess is an artifact of the Guile project structure: I was able to `#:use-module (tests utils)` in my test module to make use of that module from guile-goblins, but it actually feels a bit odd that I *could* do that haha

<jfred>since it's a very generic module name

<vvvvmvr[m]>Yeah, I guess theoretically that should be prefixed with "goblins" ?

<dthompson>the namespace is correct because the test modules live in the tests/ directory in the project root

<vvvvmvr[m]>I noticed that later... I was wondering, is there a way to prevent an exported module from being exposed by the root package? For example, what if there was a module (tests utils) defined in a different package, and you wanted to use both the goblins package and that one? Is there any concept of an "internal module export"?

IRC channel logs

2023-07-10.log