IRC channel logs
2025-02-26.log
back to list of logs
<fantazo>Oh hi, I just noticed that you have an IRC channel. How nice that people still use this civilized tech. <fantazo>I'm proud that I finally managed to compile goblins on arch and get it running somehow. That the guile tls bindings `make check' always marks some checks as failed, made me dubious if I did something wrong. <andreas-e>Hello! After some updates to my second blog post about Goblins for computations, I am starting to think about the third one. I think I can cook up a solution to the problem I want to solve (give out tasks to clients, as soon as one client comes back with a finished task, send out a new one) in the current framework, but I am also wondering about the following, which would provide an alternative solution. <andreas-e>As in mathematics, there are "for all" and "there exists", I could imagine in addition to the joiner "all-of" one called "one-of". Would that be in the spirit of Goblins and easy to implement? <andreas-e>For instance, "one-of" could take a list of promises, and as soon as one of them resolves (if there are several, any of them would do) it would call the contained lambda expression with the result of the promise. <andreas-e>One could also imagine a (non-functional) variant in which additionally, the resolved promise would be removed from the list. <andreas-e>Exactly, this was new in 0.14, very nice! I suppose I would need a "race*" variant that takes a list. <andreas-e>Could this be achieved with "(race ,@my-list)'? <tsyesika>yeah (apply race my-list) something like that. <tsyesika>the main version of goblins has race* but 0.15 missed out by like a week to have that added <andreas-e>Indeed, "apply" was missing, or "eval"; but "apply" is easier. <andreas-e>I try to learn goblins and to use it in the high-performance computing context of my work, with the aim of replacing MPI. <andreas-e>It is a steep learning curve; so I am writing things up as I go and explain my findings. <andreas-e>I hope it can be some sort of complement to the goblins tutorial. And I hope that in the end I will have a framework in hand into which I can plug my actual computations. <fantazo>goblins is interesting. I haven't yet grasped it, but currently it feels a little less intuitive than say concurrent processes in Erlang/Elixir. <andreas-e>I do not know Erlang. I am struggling with promises and the fact that one cannot wait/synchronise for their fulfillment. At the same time, it is convenient to not need to explicitly handle the communication like in MPI, where every send needs to be matched by a receive to avoid deadlocks. <andreas-e>Well, coming from imperative programming, I am already struggling somewhat with Scheme ;-) <fantazo>andreas-e: well, Erlang is basically that what goblins does, just without vats and I would say way more libraries and tooling. For example the system supports out of the box a crude way to build a cluster by just starting two vms on the same machine or other machines with a couple of magic flags. <fantazo>And then woho! magic you can send processes messages, if you know their pid on the machine. <fantazo>and as I see goblins, it has the basic toolings in place to do this. but maybe I'm ignorant of the full picture, because I haven't yet made a deep dive into it. <andreas-e>It looks to me like you can do the same thing in goblins by just telling each other the TCP address and port of the other machine. Except that you can also do it over Tor. <fantazo>it's also not a fair comparison. Erlang/OTP exists like 38 years, you need to develop that stuff and goblins is young at v0.15.0 <dthompson>erlang is indeed a very mature system, but one thing it lacks is capability security <fantazo>dthompson: true, which is why I find goblins interesting. lispy languages just need to their place they deserve in history of computing. <fantazo>I'm not here as an Erlang/Elixir-Weenie, I just coded with that stuff and like it. I'm all for all what passes messages around. <jfred>andreas-e: oh, that's a very cool use case for goblins! <jfred>Man, pixel art is tricky. You can't really do a rough outline at these tiny resolutions so until you start adding details it just looks awful haha <andreas-e>I have a question on transactionality in goblins. I have a cell containing a list, and assume that different actors add and remove elements to the list. <dthompson>blobs of a single color are good for "outlining" <andreas-e>Assume that one of them adds 'a roughly like so: ($ cell (cons 'a ($ cell))) <andreas-e>Another one removes 'b with a function I still need to look up, roughly like so: ($ cell (remove-from-list ($ cell) 'b)) <andreas-e>Now I have a race condition, no? I cannot be sure that one of them finishes before the other one starts. Potentially both do the look-up ($ cell) at the same time, then one adds 'a, one removes 'b, and whoever puts the result back first will win, no? <andreas-e>Or assuming that I put both of them as a reaction to a message into two separate actors, does goblin guarantee that both code blocks are executed one after the other (in a potentially unknown order)? <andreas-e>Do things change if I attach these to two different methods in the same actor? <andreas-e>Is there a write-up of how such things are supposed to happen? I remember that transactions and them being able to be rolled back played a role in some goblins talks/ <andreas-e>Well, that was one questions for some value of "one" ;-) <tsyesika>they're within the same vat so you know they're not happening at the same time <tsyesika>vats only ever handle one message at a given time. <andreas-e>Okay, thanks. This is good. And it implies that it does not matter in which actor the methods are hidden, one or two. <dthompson>andreas-e: yeah tsyesika is right. each vat processes a single message at a time. <andreas-e>Where I suppose that "only one message at a time" is not perfectly true, since messages are contained in each other. <tsyesika>if you did it across vats, e.g. (on (<- my-cell) (lambda (cell-contents) (<-np my-cell (cons 'a cell-contents)))) that'd be a problem <tsyesika>(I said across vats but using arrow like this even within the same vat is potentially a problem and not something you'd probably want to be doing) <andreas-e>I hope I understand things correctly. What I would do is to modify a cell only with $ from within one vat. But the messages causing the modification could come from outside. That is fine, right? Except that their order cannot be foreseen. <dthompson>andreas-e: what do you mean by "messages are contained in each other"? <dthompson>the vat is a glorified message queue: it reads a message from the queue, invokes the relevant actor, sends any resulting outgoing messages, and loops <andreas-e>So the addition could be something like (<- add 'a), the removal something like (<- remove 'b), calling two actors in the same vat; and these two actors act on a cell in the same vat with $. That is fine, right? And in this example the result would be determined. (<- add 'a) (<-remove 'a) could still cause problems, depending on which message arrives first. <dthompson>if you have code that sends both of those messages in that order then it's guaranteed that the add happens before the remove <andreas-e>dthompson: Well, I meant that for instance in this case, the (<- add 'a) message involves two contained ($ cell) messages. So in reality, we work on a tree of messages. While the first (<- add message is handled and before that handling is finished, you need to start the ($ cell message. It is like a function call stack in C: you are in several functions at the same time; here several messages are handled at the same time. While you carry out <andreas-e>the ($ cell, you need to remember where you are, then get back to it, then handle the second ($ cell, and only then the (<- add is finished. I agree that this can probably be handled by a LIFO message queue with a bit of stack-trace-like memory. The result is a depth-first traversal of the message graph, I think; with some randomness in the breadth part of the graph, since the timing of message arrival is not deterministic. <dthompson>if those messages are coming from different processes/threads/etc. then you'd need additional coordination <dthompson>andreas-e: messages sent with $ are applied immediately <dthompson>it's very much like regular procedure application in that sense <andreas-e>I assume they come from different processes. So their order is not guaranteed. But from what I understand of your explanations, add and remove are carried out sequentially, in either of the two orders. <andreas-e>Okay for the $. Somehow I had assumed that the local $ messages are mixed with the incoming <- messages, although I think that this is correctly explained in the documentation. <andreas-e>So using ($ cell makes addition and removal atomic. Thanks for helping me out! <andreas-e>Can I 'enliven the same sturdyref twice, or does this cause a problem? If yes, is there a corresponding 'kill? <tsyesika>you can enliven a sturdyref multiple times, it won't cause any issues <andreas-e>Once I have enlivened a sturdyref, I get back a promise; can I extract the sturdyref out of this again? It would be useful for logging/debugging purposes. <andreas-e>To see which 'register on one side correspond to which 'enliven on the other side. <dthompson>andreas-e: goblins doesn't keep a reverse mapping, but you could keep your own side table if you want <andreas-e>Okay, thanks! It is not enough of a pain point to warrant extra development for me. <dckc>andreas-e, the blog posts are nice! <dckc>re "text is great for trees, not for graphs" https://github.com/leithaus did a nifty thing called ToGL. I can't find it just now, but I'm pretty sure it's in there somewhere. <dckc>ok, this channel has reached the "I can't keep up" point. Congrats! 