jemc changed the topic of #ponylang to: Welcome! Please check out our Code of Conduct => https://github.com/ponylang/ponyc/blob/master/CODE_OF_CONDUCT.md | Public IRC logs are available => http://irclog.whitequark.org/ponylang | Please consider participating in our mailing lists => https://pony.groups.io/g/pony
<SeanTAllen> not sure you want that None at the end
<SeanTAllen> so what's your output when you run that?
<Xyliton_> https://gist.github.com/TheFreakLord/2c960955afa13562032a72fc97963222#file-wai-pony-L17 this change makes the output worse. It shows that I get more calls to the websocket notify than to the behaviour
unbalancedparen has joined #ponylang
<SeanTAllen> swap out your Debug calls for @printf[I32] calls
<Xyliton_> okay
<SeanTAllen> what OS are you using?
<SeanTAllen> also how many CPUs do you have?
<Xyliton_> I'm on arch linux, using an i7 4790 (that's 4 cores, 8 threads at ~3.8 GHz)
<Xyliton_> here's the printf output http://hnng.moe/f/PMw
<SeanTAllen> thats quite a bit more interesting
<SeanTAllen> so your design is kind of odd
<SeanTAllen> and its basically sending lots of messages to itself
<SeanTAllen> im not sure what is happening
<SeanTAllen> but you seem to be getting stuck before it gets to ever executing the message send for the heartbeat
<Xyliton_> how is it sending messages to itself?
<SeanTAllen> that's basically all its doing
<SeanTAllen> transitively sending messages to itself
<SeanTAllen> can you gist the code with the @printfs
<Xyliton_> the actor is never calling the received of the websocket notify though
<Xyliton_> so it won't make the ws notify call _received from the actor
<SeanTAllen> and what is your output?
<Xyliton_> the last image I sent
<SeanTAllen> ok
<Xyliton_> here's a new one
<SeanTAllen> do you understand why the print messages are in that order?
<SeanTAllen> why you see INTERNAL_RECEIVED before RECEIVED ?
<Xyliton_> I do. The websocket notify prints first and then sends the stuff to the actor
<Xyliton_> that's what I'm expecting
<SeanTAllen> it sends it to the actor that it is running inside of
<SeanTAllen> why are you doing that async?
<Xyliton_> can I do it sync too?
<SeanTAllen> yes
<SeanTAllen> your notify is running inside that actor
<Xyliton_> I thought I can't give a non-tag reference to both the notify and timer?
<SeanTAllen> i dont think you understand
<Xyliton_> I don't think I do either
<SeanTAllen> this...
<SeanTAllen> doesnt have to be async
<Xyliton_> so I can turn that behaviour into a function?
<SeanTAllen> yes
<SeanTAllen> but im having a really hard time following the flow of this
<SeanTAllen> because it loops around on itself
<Xyliton_> how does it loop?
<SeanTAllen> im pretty sure that is where the problem is
<Xyliton_> the notify receives a message and sends it to the actor, which processes it
<Xyliton_> there's nothing going back to the notify
Matthias247 has quit [Read error: Connection reset by peer]
<Xyliton_> so how can it loop?
<SeanTAllen> DiscordWS actor creates a socket and gives it a notify that has a reference to the DiscordWS actor
<Xyliton_> yes
<Xyliton_> don't I need that reference to get the data into my actor?
<SeanTAllen> sorry im having a hard time following this
<SeanTAllen> ignore me for a minute here
<SeanTAllen> ok yeah you cant do sync
<SeanTAllen> when exactly is the timer getting called?
<Xyliton_> the timer itself is getting called every 41250*1_000_000 whatever-units-timers-work-with
<Xyliton_> forgot if it was nano or micro seconds
<SeanTAllen> i dont see any output for it being called in what you sent
<Xyliton_> because I didn't run it for ~40 seconds
<Xyliton_> I can do that if you want though
<SeanTAllen> or something shorter
<SeanTAllen> that isnt very helpful output
<Xyliton_> that's as far as it goes
<Xyliton_> shortly after that the connection is closed because it doesn't receive a heartbeat
<SeanTAllen> Do you have any loops of any sort in that websocket code?
<Xyliton_> loops as in "while loop" or a logical loop because I messed the code up?
<SeanTAllen> any sort of loop
<SeanTAllen> the most likely case is that your actor is stuck running a behavior in a loop
<SeanTAllen> and the message for the heartbeat is stuck behind it
<SeanTAllen> change the timer interval to 1
<SeanTAllen> run again
<SeanTAllen> post output
<Xyliton_> when setting it to a small value it works
<Xyliton_> but the server I'm connecting to will hate me for sending a heartbeat before it sent me some message so it will close the connection
<SeanTAllen> right so
<SeanTAllen> you are getting stuck in a loop somehow
<SeanTAllen> where it never gets to execute the message if its sent later
<SeanTAllen> why i dont know
<SeanTAllen> that you'd need to figure out
staticassert has joined #ponylang
<staticassert> Anyone here know Erlang? I have a fairly high level question
<SeanTAllen> need to run
<SeanTAllen> good luck
<SeanTAllen> staticassert: whats the q?
<staticassert> I'm wondering about supervisors. In Erlang, you give a Supervisor a bunch of child definitions and i believe it returns a upservisor. How do you interact with individual children?
<staticassert> that is - how does the supervisor know which child to rout ea given message to?
<SeanTAllen> its been a couple years since i wrote erlang so i dont remember
<SeanTAllen> i'd ask in #erlang
<staticassert> oh cool, thanks
<SeanTAllen> im liable to give you the wrong answer via the haze of time
<SeanTAllen> and i need to run, so no time to look up to refresh
<SeanTAllen> staticassert: new website going up soon
<staticassert> sweet, good to know
Xyliton_ has quit [Quit: Lost terminal]
<tokenrove> staticassert: you don't send messages directly to the supervisor, generally. it just exists to catch the exiting children and restart them.
<staticassert> oh, interesting. So then how do you interact with the children? Do you get their names back when you create the supervisor?
<tokenrove> usually you register names for things you need to communicate with without some other relationship
<tokenrove> but now that you mention it, I suppose you could get the list of children from the supervisor. You'd need to get the new pids of children that restart somehow, though.
<tokenrove> This is perhaps a usecase I haven't encountered much. There are a lot of different ways to use Erlang.
<staticassert> hm. well the supervisor could have a map internally, and it could return the hashes, and then the 'send' would send the hash to the supervisor, where it would look up the associated actor
<staticassert> then the actor could die but the hash that was handed out as the name owuld stay the same
<staticassert> idk ill have to look into this further, thanks though
staticassert has quit [Quit: Page closed]
unbalancedparen has quit [Quit: WeeChat 1.7]
chemist69 has quit [Ping timeout: 260 seconds]
chemist69 has joined #ponylang
gmcabrita has quit [Quit: Connection closed for inactivity]
madgoat has joined #ponylang
madgoat has left #ponylang [#ponylang]
<catern> is there a reason that actor model systems usually have a single message queue per actor?
<catern> why not one message queue per remote procedure?
<catern> that seems more in keeping with capability-security
jemc has joined #ponylang
jemc has quit [Ping timeout: 240 seconds]
graaff has joined #ponylang
_whitelogger has joined #ponylang
_whitelogger has joined #ponylang
chemist69 has quit [Ping timeout: 260 seconds]
chemist69 has joined #ponylang
bngl has joined #ponylang
K4rolis has quit [Ping timeout: 240 seconds]
Matthias247 has joined #ponylang
obadz has quit [Quit: WeeChat 1.7]
obadz has joined #ponylang
_whitelogger has joined #ponylang
gmcabrita has joined #ponylang
bngl is now known as K4rolis
chemist69 has quit [Ping timeout: 264 seconds]
chemist69 has joined #ponylang
Candle has quit [Ping timeout: 246 seconds]
Candle has joined #ponylang
chemist69 has quit [Ping timeout: 240 seconds]
chemist69 has joined #ponylang
Matthias247 has quit [Read error: Connection reset by peer]
<SeanTAllen> catern: you wouldn't be able to do casual messaging in that case. how do you decide which queue to process messages off of?
<SeanTAllen> i'm not sure what you mean by "that seems more in keeping with capability-security".
jemc has joined #ponylang
jemc has quit [Ping timeout: 260 seconds]
<catern> SeanTAllen: but even in system without causal messaging order, there's a single message queue per actor
<catern> SeanTAllen: and I meant that if you have a separate message queue per async procedure, then to hand out a reference to a async procedure all you need to do is hand out a reference to the message queue
chemist69 has quit [Ping timeout: 264 seconds]
<SeanTAllen> that's all very handwave and theoretical. what's the practical benefit?
<SeanTAllen> how do you select which queue to read from and in what order?
<SeanTAllen> i dont think that you would be able to program in such a system
<SeanTAllen> i could call A.a and then a A.b
<SeanTAllen> and not know that b would happen after a
chemist69 has joined #ponylang
jemc has joined #ponylang
jemc has quit [Client Quit]
jemc has joined #ponylang
<catern> SeanTAllen: oh I see, good point, that's why everyone has the central message queue first
chemist69 has quit [Quit: WeeChat 1.7]
graaff has quit [Quit: Leaving]
jemc has quit [Ping timeout: 260 seconds]
jemc has joined #ponylang
jemc has quit [Ping timeout: 258 seconds]
chemist69 has joined #ponylang
vaninwagen has joined #ponylang
mrkishi has quit [Ping timeout: 260 seconds]
Matthias247 has joined #ponylang
jmiven has quit [Quit: co'o]
jmiven has joined #ponylang
vaninwagen has quit [Ping timeout: 246 seconds]
mrkishi has joined #ponylang
Guest23017 has joined #ponylang
Guest23017 has quit [Quit: BitchX-1.2.1 -- just do it.]
Matthias247 has quit [Read error: Connection reset by peer]
K4rolis has quit [Ping timeout: 268 seconds]