<EEVV>
what is the best way to have a TCPConnectionNotify affect other TCPConnectionNotifies? I want to make a sort of chat system where one connection sends the message to the server and the server broadcasts it to the other connections
<EEVV>
and I wanted to have a shared database between the connections
<EEVV>
I don't know how to achieve these
<EEVV>
especially since the TCPConnectionNotify is a class, I think I could be able to do it if it was an actor
<vaninwagen>
Dont use TCPConnectionNotify, use TCPConnection and store it in a map under some address/username
<vaninwagen>
You get the TCPConnection (itself an actor) passed in to your TCPConnectionNotify when it got connecter
<vaninwagen>
*connected
endformationage has joined #ponylang
<vaninwagen>
I'd suggest using another actor for storing the Map, maybe Map[String, TCPConnection tag]
<SeanTAllen>
EEVV: yes, you need an actor that is the "shared database"
<vaninwagen>
And it exposes some behaviours for adding and removing the connections and broadcast or send to a specific connection
<EEVV>
vaninwagen, the problem is my TCPConnectionNotify has some state is stores
<EEVV>
like the connection can only get access to the database under certain states
<SeanTAllen>
you can supply a tag to that actor to the TCPConnectionNotifiers when they are created.
<SeanTAllen>
Really you want a minimal amount of logic in the notify
<EEVV>
and also if my database gets changed it resends the changed data to the connections
<vaninwagen>
Yeah, i also used that kind of pattern before
<EEVV>
SeanTAllen, for example my TCPConnectionNotify has `aes` field which stores the encryption stuff... when it needs to send something or receive it encrypts or decrypts using that field respectively
<SeanTAllen>
i would call that minimal amount of logic
<EEVV>
SeanTAllen, but the problem is I need access to TCPConnectionNotify, which is not possible because it is returned as iso^
<EEVV>
so do I make a map for the aes?
<EEVV>
it would've been easier if my TCPConnectionNotify was an actor because then I could call a `send` behavior which would handle encryption
<vaninwagen>
Put the logic for each connection maybe inside a separate actor per connection. The notify has a reference to that actor and you could store rederences to that actor somewhere else in a database
<vaninwagen>
Delegate all your logic to that actor
<vaninwagen>
This one you can share around
<EEVV>
yeah, I wanted to try something like this, but I wanted to make sure it is a good method
<EEVV>
but I want to ask why is TCPConnectionNotify a class?
<EEVV>
why not actor
<SeanTAllen>
I dont think you understand the purpose of TCPConnectionNotify
<SeanTAllen>
its a class to specialize an actor
<SeanTAllen>
you can do everything you want by supplying an actor to the TCPConnectionNotify on creation
<SeanTAllen>
and do everything you want in that actor.
<EEVV>
ok
<EEVV>
SeanTAllen, how would I do something like a behavior return?
<EEVV>
say I have a database and I say `get(something)`
<SeanTAllen>
you dont
<SeanTAllen>
you do what you need for basic tcp connection stuff and send it off to other actors that do the logically processing
<SeanTAllen>
and then they can use .write to send data out as required on the correct connections
<EEVV>
I ran into a problem again: I made a new actor `Client` which I put in my `Connection` which is `TCPConnectionNotify`... But how am I supposed to pass my actor the `TCPConnection ref`? I cannot pass ref
<vaninwagen>
Assign it to a variable of type TCPConnection tag, this one you can pass around
<vaninwagen>
any tag argument/field/variable should also accept a ref, if i am not mistaken
<EEVV>
vaninwagen, will I be able to do `.write` on this TCPConnection tag?
<SeanTAllen>
yes
<EEVV>
ok, thanks
<SeanTAllen>
write a behavior
jemc has joined #ponylang
jemc has quit [Client Quit]
<vaninwagen>
We are getting there EEVV
<EEVV>
vaninwagen, where?
<EEVV>
what happens if I keep a TCPConnection even after the connection ended?
<vaninwagen>
We are getting where you want that thing to be
<EEVV>
oh, nice
<EEVV>
Okay so right now I have in my listener actor Server and this will have an array of Client tag (maybe I shouldn't use array?) and each Client has a tag of Server
<EEVV>
does this seem alright?
<EEVV>
When a client wants to send something to everyone it will call some Server behavior and in turn Server will call all of the Client behavior (all as in all in the array Client tag)
<EEVV>
I'm wondering if pony has a set datastructure where it is content based
<EEVV>
I'm thinking of replacing the array with a set
<EEVV>
if I want to make a request for the language (change some behavior) can I do that on the github issues?
<SeanTAllen>
I think i opened it a couple years ago
<SeanTAllen>
its been kind of sitting there
<SeanTAllen>
repeat... until doesnt seem to be used much
<SeanTAllen>
maybe because of the bug
<SeanTAllen>
or maybe the bug has been sitting there because no one feels the pain
<SeanTAllen>
i cant find the issue though
<SeanTAllen>
please feel free to open a new issue given i cant find the old one
<EEVV>
okay
<EEVV>
also how do streams work in pony? I mean the `env.out.print` always seems to print in the right order, but for example behaviors are not guaranteed to be executed in the same order
<SeanTAllen>
sorry i dont understand what you mean
<EEVV>
is print a behavior?
<SeanTAllen>
yes
<SeanTAllen>
behaviours are executed in the order that the messages were received
<EEVV>
so it is possible for some messages to be printed earlier than others?
<EEVV>
even though intuitively it may seem otherwise?
<SeanTAllen>
no
<SeanTAllen>
please define "earlier"
<EEVV>
in terms of code further lines = later
<SeanTAllen>
pony has casual ordering
<EEVV>
if I do a for loop can the current iteration print to the screen before the previous iteration?
<SeanTAllen>
any messages sent from Actor A to Actor B will processed by B in the order they were received which is the order they were sent
<SeanTAllen>
no
<EEVV>
ah ok
<EEVV>
I have code that behaves weird
<EEVV>
first I print that prints the id which is just `host + ":" + service` but then I tell the client `.set_id` and give it the same string... the weird thing is the first print happens even after the client already received some data
<EEVV>
the client prints stuff when it receives the data
<EEVV>
and it uses the same id string
<EEVV>
maybe it is because client uses Debug.out and the connection notify is using _env.out.print
<EEVV>
yeah I think it is
<SeanTAllen>
Debug out is printing to stderr
<SeanTAllen>
its a different actor than env.out
<EEVV>
oh
<EEVV>
makes sense
<SeanTAllen>
there is no ordering guarantee across actor
<SeanTAllen>
* actors
<EEVV>
yes that I can understand
<EEVV>
can I make debug use env.out?
<SeanTAllen>
no
<EEVV>
before, I used ifdef with a env.out, I guess I'll do the same
<SeanTAllen>
but you can create your own
<EEVV>
yeah I did
<EEVV>
before I switched to Debug lol
<SeanTAllen>
but
<EEVV>
sometimes it is tedious to give everything Env
<SeanTAllen>
then your Debug would need to get Env.
<EEVV>
yes
<EEVV>
also going back to the earlier topic of message ordering: does this mean if I tell to a database (which will be an actor for sake of example) to create a new entry and then after that I tell it to delete the entry, is it guaranteed that in the end the entry will no longer exist?
<SeanTAllen>
unless you send another message to create a new entry later, yes
<EEVV>
oh cool
<SeanTAllen>
actually let me clarifty that
<SeanTAllen>
lets say somehow you had:
<SeanTAllen>
actor A send "create entry Foo"
<SeanTAllen>
and actor B sends "delete entry Foo"
<EEVV>
there is no order there right
<SeanTAllen>
there's no guarantee on the order those messages will arrives at Actor C
<EEVV>
alright
<SeanTAllen>
i'm assuming that actor A sends both create and delete
<SeanTAllen>
i just wanted to be clear on that
<EEVV>
yes that's the correct assumption in my case
<EEVV>
is it necessary to implement a hash function for that type to be used in a Set?
<EEVV>
oh I think I can just return 0 before actually implementing one
<SeanTAllen>
yes
<EEVV>
I heard somewhere that sets can be internally binary trees, which only require comparable
<EEVV>
maybe in the future we could have a TagSet which on the lower level uses the pointer as a hash instead of hashing contents?
<EEVV>
not sure if this is possible
<SeanTAllen>
So you want a set based on identity?
<EEVV>
yes
<SeanTAllen>
SetIs
<SeanTAllen>
it already exists
<EEVV>
oh
<EEVV>
very nice
EEVV has quit [Quit: Page closed]
srenatus has quit [Quit: Connection closed for inactivity]