HomePage | RecentChanges | Preferences

Difference (from prior major revision) (no other diffs)

Changed: 1,251c1


Erlang global process registry

wsmoak [7:45 AM]
if I generate a project `mix new connect_four --sup` and then add some workers like ConnectFour.Game and ConnectFour.Player ... I can see in the observer that they get started under ConnectFour.Supervisor. (They're all Agents right now.) Later in the Game module code... how do I look up / find / talk to the players? Can I ask the supervisor for one of its children later, or am I supposed to be tracking that (the pid?) in the game itself?

wsmoak [7:49 AM]
I'm looking at the Acquirex code, and he has the players 'join' the game. (I'm not using gen_fsm either.)

sasajuric [7:58 AM]
@wsmoak: Iíd likely use gproc registration for that. I made some comments about it here:

Generalizing AcquireX? to Multiple Simultaneous Games? ē /r/elixir
AcquireX? Repo: This repo is great for looking at how to write OTP code, but with everything talking to each...

wsmoak [8:39 AM]
thanks @sasajuric ! So it sounds like the simplest thing that can possibly work is indeed to remember the player pids in the Game's state. (which I realize will break if one gets re-started.) And the next thing appears to be using Process.whereis/1 since they are all registered with names.

sasajuric [8:41 AM]
you can work around the failure problem if you use one_for_all in the parent supervisor

sasajuric [8:41 AM]
thatís not perfect error isolation, but it simplifies things

sasajuric [8:41 AM]
so if any game participant fails, the whole game fails

wsmoak [8:43 AM]
Are there docs for gproc published anywhere? Searching, I keep getting back to github and the readme is pretty sparse. is the best I've found, but quite old.

sasajuric [8:44 AM]
@wsmoak: This is the reference I use:

gproc - Extended process registry for Erlang

sasajuric [8:45 AM]
gproc is a bit strange initially, but once you get used to it itís pretty cool.

sasajuric [8:45 AM]
Basically, for game participants, you could use reg/1 with {:p, :l, game_id}

sasajuric [8:46 AM]
You need to do this from each process, gproc doesnít allow external registration (i.e. that one process registers some other process).

The registration above is non-unique, which allows you to register multiple processes under the same id

sasajuric [8:46 AM]
first two atoms in the tuple in this case must be :p and :l (non-unique property, local)

sasajuric [8:47 AM]
the third element in the tuple is arbitrary term, you might want to use something like {:player, game_id}

sasajuric [8:48 AM]
finally, you could use wih {:p, :l, {:player, game_id}} to get all players (pids) of a particular game

And more discussion...

wsmoak [8:49 AM]
ah, just read the markdown under docs, got it.
thank you! gproc does seem like the right choice in the end. I need to trip over a few things that you already know first, and get there myself. :simple_smile:

fishcakez [8:50 AM]
alternatively you can use {:n, :l, {game_id, player_id}} and use a select to get all players in a game

fishcakez [8:50 AM]
gproc really has a lot of powerful functionality

wsmoak [8:51 AM]
it's connect four. there are always, only, ever two players. :smile:

sasajuric [8:51 AM]
@fishcakez: that will fetch just one player, right?

fishcakez [8:51 AM]
@wsmoak: not how I play :disappointed:

fishcakez [8:52 AM]
@sasajuric: you can use a select like {:n, :l, {gameid, :"_"}}

wsmoak [8:52 AM]
lol... maybe if this ever works I will write the awesomely distributed multi-player three-dimensional version of connect four :stuck_out_tongue:

sasajuric [8:52 AM]
@fishcakez: yeah, thatís a good point. I personally still prefer properties for that, but maybe I should consider matchspecs :simple_smile:

fishcakez [8:53 AM]
properties are just matchspecs under covers so its just taste

sasajuric [8:53 AM]
indeed, but in that case, I donít need to write them :smile:

sasajuric [8:53 AM]
that being said, this reduces the pressure on the ETS table

fishcakez [8:54 AM]
@sasajuric: Having read your thoughts on :gen_fsm we think so differently

sasajuric [8:54 AM]
Somehow Iím not surprised :simple_smile:

sasajuric [8:55 AM]
Not that itís bad or anything, but fsm processes personally confuse me. Itís obviously personal taste.

fishcakez [8:56 AM]
yeah, I really like gen_fsm, probably my favourite.

fishcakez [8:57 AM]
I think because I like to see the callgraph and only call functions when needed

fishcakez [8:57 AM]
I find something like put_new a horrible function

sasajuric [8:58 AM]
hmm, Iím not sure I understand what you mean by callgraph.

fishcakez [8:59 AM]
the order the functions are called from one another

fishcakez [9:00 AM]
if you imagine that a module is a graph with functions are vertices

fishcakez [9:00 AM]
and a function call is an edge

sasajuric [9:01 AM]
yeah, that can be helpful in more complex scenarios, though I personally didnít encounter such

sasajuric [9:01 AM]
As I said, I usually read the code by looking at a single operation and asking myself how is this handled.

sasajuric [9:01 AM]
Itís harder to get that answer in state-oriented graph

fishcakez [9:01 AM]
Right I was saying how we think differently

sasajuric [9:01 AM]
Exactly :simple_smile:

sasajuric [9:02 AM]
But itís not just about fsms here. Another thing is that gen_fsm conflates FSM with message passing, which is another thing I dislike about it

fishcakez [9:03 AM]
I missed that in the thread did you talk about it there?

sasajuric [9:03 AM]
Yeah, wait, let me find that post

sasajuric [9:06 AM]
@fishcakez: Ah, it looks like I didnít make it so explicit. The idea I mentioned is here: starting with ďGoing furtherĒ. The main point is under the code sketch.

augustorsouza [9:06 AM]
is there a way to use less memory?

fishcakez [9:08 AM]
@sasajuric: yeah I find your action orientated approach very OOP :stuck_out_tongue:

sasajuric [9:09 AM]
Perhaps itís due to my OOP background. Regardles, thatís how I think about the problems :simple_smile:

fishcakez [9:09 AM]
yeah I am just teasing though

sasajuric [9:10 AM]
I certainly brought some OO baggage with me to Erlang. That being said, I donít think OO is 100% bad, and feel some principles apply universally.

fishcakez [9:10 AM]
@augustorsouza: seems like a bug in rebar

fishcakez [9:11 AM]
@sasajuric: but when I mention callgraph it is not so much about state/vertices but rather the flow or transitions

fishcakez [9:11 AM]

fishcakez [9:12 AM]
that is probably why the telecom guys lap the gen_fsm up because they love the state transitions

fishcakez [9:12 AM]
or girls

sasajuric [9:13 AM]
Itís really about perspective. FSM puts states and transitions first. What Iím proposing puts actions first. You can slice it one way or another. As I said, FSM probably makes more sense when there are complex states, but most, if not all, cases I have seen were not complex enough.

sasajuric [9:13 AM]
However, even if/when Iíd prefer FSM, Iíd like it to be decoupled from message passing. Why do I need a behaviour and messages for that? Thatís a completely separate mechanism, even if it will mostly map 1:1 to actions.

fishcakez [9:14 AM]
yeah I find the exact opposite to you :confused:

fishcakez [9:16 AM]
@augustorsouza: apparently not a rebar bug: just how it is

Elixir - Could not compile dependency idna
Error message: iex -S mix Eshell V7.0 (abort with ^G) ==> idna (compile) Killed ** (Mix) Could not compile dependency idna, /root/.mix/rebar command failed. If you want to recompile this

sasajuric [9:17 AM]
@fishcakez: Even with that different thinking, do you think FSM should be tightly-coupled with message passing?

fishcakez [9:17 AM]
@sasajuric: I have mixed feelings on it but generally I like it

fishcakez [9:18 AM]
I hate to say there is a problem when I am unsure what I would do differently

fishcakez [9:18 AM]

fishcakez [9:18 AM]
if I was to write my own gen_fsm type thing likely I would just end up re-implementing gen_fsm :confused:

sasajuric [9:22 AM]
Yeah, as soon as I look the API of gen_fsm and see stuff like send_event, send_all_state_event, sync_send_event, sync_send_all_state_event, send_event_after and all those callback return tuples, my head goes fuzzy and my heart sinks :simple_smile:

sasajuric [9:22 AM]
I canít help but thinking that gen_server with call/cast is way simpler, yet just as powerful. [10:39 AM]
@sasajuric: OO isn't bad. Mutability isn't bad either. It's default mutability that leads to lots and lots of side-effect errors. [10:39 AM]
Developers won't fight the defaults in a language because we're too busy trying to meet impossible deadlines :smile: (edited)

sasajuric [10:44 AM] I think OO and mutability are independent concepts. You could theoretically have immutable OO (though Iím not aware of an existing implementation). When I was refering to my OO baggage above, I wasnít talking about mutability. [11:04 AM]
@sasajuric: They are independent concepts. [11:04 AM]
It's just that most OO is mutable by default (aka imperative).

HomePage | RecentChanges | Preferences
This page is read-only | View other revisions
Last edited December 22, 2019 11:05 am by (diff)