<TwoNotes>
But code as he suggests will not compile, becuase the actor has uninitialized fields.
<TwoNotes>
And initializing those fields can involve manipulating a FilePath.
<TwoNotes>
And it is impossible to fake up a stand-in for an AmbientAuth
<TwoNotes>
Unless they all become unions with None, which I then have to check for on every reference.
<jonas-l>
which actor has uninitialized fields? MyNetActor?
<TwoNotes>
Maybe the thing to do is that a Main actor should not have ny fields of its own at all. Just do everything in a big 'try' block and pass the reuls off to another actor that cna just assume it has all the FilePaths already set up.
<TwoNotes>
The actor of which I speak is the one I am writing.
rurban1 has quit [Ping timeout: 276 seconds]
<TwoNotes>
It is difficult to deal with FilePaths in a constructor.
<SeanTAllen>
twonotes that is generally what we do. verify that the resource you need is available before trying to construct an actor that uses it.
<TwoNotes>
Perhaps a little 'primitive', lets call it an actor factory, to do all that try-protected stuff, and then it creates the real acor
<TwoNotes>
*actor
<TwoNotes>
But then, the factory function has to return the actor tag or None, which just kicks the problem back to the caller.
SilverKey has quit [Quit: Halted.]
<SeanTAllen>
well yes, you have to deal with errors or lack of access etc
<SeanTAllen>
if you want to open a file and it doesnt exist or you aren't allowed, you have to handle that
<TwoNotes>
Hmm, so best practice would be that a Main actor should not have any fields at all, just do all that checking, exit if it can't, then create another actor to do the real work.
<TwoNotes>
If I create an actor but do not retain a reference to it, will it live on anyway?
<jonas-l>
I think the application terminates when there are no pending messages and no new messages can be possibly created
<jonas-l>
so not having a reference to an actor should be fine
<TwoNotes>
As long as there is some way that actor might receive a message in the future?
<SeanTAllen>
our Main actor(s) TwoNotes are all setup. Make sure that we have access to what we need, etc, and construction of actors that do the work.
<TwoNotes>
Oh, so it is a design pattern I should be using
copy` has joined #ponylang
jemc has joined #ponylang
<SeanTAllen>
well, its what we have been doing. not sure i would say "should" but it is working for us
<jemc>
TwoNotes: right, my intention with my example psuedocode earlier was that Main would have no fields and no logic other than constructing the other actors (or erroring out) - MyNetActor, possibly along with other actors would take the place of what you currently have in Main
<jemc>
I think that probably is a good pattern for us to adopt - Main as a jumping-off point for your other actors, rather than containing any real meat of its own
SilverKey has joined #ponylang
<jemc>
and yes, if you've got sockets driving your event graph with external input, there's no reason to hold a reference to those parts of the graph from Main just to keep them alive - the possibility of external input from the socket is enough to keep those graphs alive
<SeanTAllen>
its the only reference type where an alias isnt substitutible for the reference itself
<SeanTAllen>
(because iso says 'only one')
<jemc>
well, trn is the other one
<jemc>
iso is read-unu and write-unique, trn is read-permissive and write-unique
<Candle>
Ok (ish..!) The way I understand it is that the Main actor is transfering ownership of the Listener to the ServerRef actor.
<Candle>
(So that the Listener is isolated to the ServerRef and not Main)
<Candle>
Which makse sense as the listener can be totally mutable and therefore we need to maintain thread safety.
<SeanTAllen>
you need to consume the listener so that it cant be used again
<SeanTAllen>
so you need to ` consume listener` on line 16
<Candle>
Yes, got there, there's another one that 'service' in TCPConnection.create is a String and not a U16, which is why I was quiet :p
<Candle>
^ which is easy to fix.
<Candle>
Just takes ... too long to compole on the rpi :(
amclain has joined #ponylang
<ohir>
Candle: to speedup compiles on rpi make ramfs and use it as your wd
<Candle>
That introduces other headaches, but not a bad idea!
<ohir>
Candle: mount --bind is your friend :)
<ohir>
Candle: if you have too much stuff, rsync -a is better otherwise
<Candle>
jemc: SeanTAllen: ohir: Thanks all!
SilverKey has quit [Quit: Halted.]
SilverKey has joined #ponylang
lucus16 has left #ponylang ["-"]
rurban has joined #ponylang
rurban1 has joined #ponylang
rurban2 has joined #ponylang
rurban has quit [Ping timeout: 250 seconds]
rurban1 has quit [Ping timeout: 240 seconds]
<TwoNotes>
Not just Main. Any object with fields must initialize all of them. For some types (IniMap for example) you can easily create an empty one in case of an error, and keep going. But AmbientAuth is not like that.
<jemc>
right, so you resolve `env.root as AmbientAuth` in your `Main` actor and you never have to deal with that ambiguity in any other code
<jemc>
ideally, you would also attenuate to the minimum auth you need (say, NetAuth)
<jemc>
then pass the auth itself to your other actors from Main
<jemc>
rather than passing the entire env
rurban2 has quit [Quit: Leaving.]
lispmeister has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
SilverKey has quit [Quit: Halted.]
rurban has joined #ponylang
SilverKey has joined #ponylang
rurban has left #ponylang [#ponylang]
puzza007 has quit [Ping timeout: 260 seconds]
_andre has quit [Ping timeout: 240 seconds]
_andre has joined #ponylang
puzza007 has joined #ponylang
jemc has quit [Ping timeout: 260 seconds]
jemc has joined #ponylang
gsteed has joined #ponylang
<SeanTAllen>
candle there's a bit of a hacked together cross compiler...
<jemc>
nyarum: in pony, you want to avoid blocking calls, so we don't use sleep - instead you want to set a timer to do some action after some interval of time
<jemc>
SeanTAllen wrote a post about this - I'll find the link
<nyarum>
Ah, so. Now I think it is just theoretical case, found another solution
SilverKey has quit [Quit: Halted.]
SilverKey has joined #ponylang
<TwoNotes>
Endless cycle in one actor is exactly what the timer class can do for you
gsteed has quit [*.net *.split]
Candle has quit [*.net *.split]
sylvanc has quit [*.net *.split]
doublec has quit [*.net *.split]
DanC__ has quit [*.net *.split]
M-hrjet has quit [*.net *.split]
Guest78801 has quit [*.net *.split]
<nyarum>
Just I found Repeat in itertools :)
<nyarum>
It is endless cycle.
gsteed has joined #ponylang
Candle has joined #ponylang
sylvanc has joined #ponylang
doublec has joined #ponylang
DanC__ has joined #ponylang
Guest78801 has joined #ponylang
M-hrjet has joined #ponylang
_andre_ has joined #ponylang
<jemc>
nyarum: you probably want to be careful about an endless iteration within an actor's behaviour (that is, you probably want to avoid it) - it will prevent that actor from handling other messages, from doing GC, etc
<jemc>
if that's what you're doing, a better pattern is recursively calling a behaviour
<jemc>
effectively, the actor sends itself a message to run that behaviour again "soon"
_andre has quit [Ping timeout: 260 seconds]
srenatus has quit [Quit: Connection closed for inactivity]
rurban has joined #ponylang
rurban has left #ponylang [#ponylang]
draynium has quit [Max SendQ exceeded]
<SeanTAllen>
yeah, nyarum, you want a timer to periodically run whatever it is you are doing. periodically could be every millisecond, but you need to exit your behavior or you won't GC.
<TwoNotes>
If an actor has no fields, when it is idle is it only consuming that 256-byte overhead space?
<TwoNotes>
And if my Main actor does nothing but start up other actors, after it has done that would it be totally reclaimed?
<jemc>
good question about the Main actor being GC'd - assuming it's treated like any other actor, then the answer is yes - it will be GC'd once it can no longer receive any new messages - I haven't checked in the source though to see if Main is a special case or not - I would imagine it is not a special case for GC
<jemc>
regarding the 256-byte overhead of actors in general, yes, my understanding is that your assumption is correct, though I haven't personally audited the code for other bytes
<TwoNotes>
Maybe the "Main" actor should be better thought of as the "Init" actor when explaining its role.
<TwoNotes>
Its job is to initializae everything, not actually be the mainline
_andre_ has quit [Quit: leaving]
aturley has quit [Ping timeout: 260 seconds]
<mcguire>
I asked this the other day, but either no one saw it or I didn't see the response:
<mcguire>
Out of curiosity, why does the runtime put the tty into a weird mode?
<jemc>
mcguire: not sure - I haven't looked at that code or encountered any problems with it
<jemc>
you might be able to do some digging with `git blame` to see what git commit added that change
<jemc>
(which might or might not illuminate the reason for it)
<mcguire>
Good point. I keep forgetting about blame and bisect.