<vaninwagen>
squirmybroom35: in this very case you can do something like: (first_u16.u32() << 16 and second_u16.u32()).hash()
<vaninwagen>
There is also a general method can can be applied to anything that is best practice in the java world: https://stackoverflow.com/a/2741898
<vaninwagen>
Regarding how to properly determine a hashcode for your custom class
profetes has joined #ponylang
endformationage has joined #ponylang
nisanharamati has joined #ponylang
<profetes>
Hello, while working with Promises I happened to have 250 actors queried, but only 1 fulfilling the promise, the rest of actors rejected it. I have now an array of 250 Promises, how do I find the one that was fulfilled, so I can attach further processing of the returned value? Like that: https://github.com/plprofetes/advent_of_code/blob/master/2018/aoc2/aoc2.pony#L35, or is there any simpler way to "map-reduce" distributed
<profetes>
computation? PonyPatterns is kinda brief on that subject...
<profetes>
ideally I'd love to know what kind of patterns are at my disposal when sharing the work with actors, but waiting for them to finish and return the value.
<profetes>
"return" being async, of course
profetes has quit [Quit: Leaving]
<vaninwagen>
I know what you mean, but i think there is no such thing yet, unfortunately in the stdlib
<vaninwagen>
You'd need sth like Promises.join() but with the logic of getting the first that is fulfilled, discarding all rejected promises profetes
<profetes>
+vaninwagen, thanks for the answer, I was afraid someone might say that.. Are there any other patterns I could try that you would recommend? This is more general issue, since I may have an processing agent and I want to be notified when processing is done. I cannot assume that causality is sufficient, since internal logic may require more messages to be sent. How do you know when agent is done computing?
<profetes>
Eg. https://adventofcode.com/2018/day/3 naiive approach may spawn 1M agents. It's stupid to Promise them all, right? Another solution might be that agent reports itself on "parent-agent" as done, but this requires more complex communication logic on behavior call order / protocol.
<vaninwagen>
Your second thought might be worth exploring
<profetes>
and i guess i would need to explicitly send "this" tag as a parameter, since there's no way to know who has called my behavior, right?
<vaninwagen>
Yes, you need to thread through some reference to an actor receiving the result
<vaninwagen>
Maybe there is a convenient pattern around a treelike structure of workers, aggregating the result up the tree to the root
<profetes>
this downgrades actor programming model to a little more than thread pool, since actors are short lived processing units, instead of long-running processes...
<vaninwagen>
It would be horrible to promise each agent in your setup, as promises are implemented as actors themselves
<profetes>
and it a bit of queue-like protocol, like ZMQ
<profetes>
and it becomes a bit of queue-like protocol, like ZMQ
<profetes>
yeah, I know, another 1M actors ;)
<vaninwagen>
Honestly i didnt spend much thought on actor system patterns/architectures yet
<profetes>
thanks for brainstorming, nevertheless :)
<profetes>
I'd like to know a bit more from Wallaroo perspective, but I'm not ready to read that codebase just yet :)
<vaninwagen>
I can give the Promises.select a shot nonetheless. Gonna share a gist when i have something
<profetes>
wow, that would be awesome
<SeanTAllen>
profetes: actors dont have to be short lived
<profetes>
SeanTAllen: I know, and I'd like them not to be, and I'm trying to model my problems in a way that let actors live. And I'm now struggling with orchestration of agents when doing AoC.
<SeanTAllen>
What's the aoc exercise?
<profetes>
I did day 2 and I am pretty happy with it, I spawn 250 actors to solve all possibilities, and that's cool. But I end up sending 250 promises where just 1 is successful, just to propagate the results up to the Main
<profetes>
And I'm looking for more proper way of doing that
<profetes>
In day 3 I'm tempted to model problem (not optimal, but fun) with 1M actors. And returning values from them via Promise in just not right, hence I'm brainstorming here. It's a matter of how to check the state of the world, what's the best pattern, or suggested patterns? Another classical problem is "when actor computations are done?". If I'm framing the model incorrectly - let me know.
<vaninwagen>
Thanks for sharing your experiences. This AOC is a great opportunity to wield out some missing or weak spots
<vaninwagen>
If anyone else has feedback, we'd love to hear it
<profetes>
I think Pony has great potential, I've chosen it over Microsoft Orleans for AoC and I want to prove Pony in typical scenarios. I think actor based solutions are the future and I want to be part of that future. Thank you (in advance) for any support :)
<aturley>
i'm still planning on streaming advent of code work in Pony at 3PM EST (in about 50 minutes) here: https://www.twitch.tv/aturls
<vaninwagen>
Do it!
<aturley>
profetes did you see boohairdfreek's AoC day 2 solution with promises?