<doublec>
There seems to be no way to clone to a val
<doublec>
Or anything sendable except tag for that matter
theodus has quit [Client Quit]
<SeanTAllen>
i see.
<SeanTAllen>
this is an interesting one.
<SeanTAllen>
you'd need a deep copy to make it safe.
<SeanTAllen>
the compiler in this case is operating on it as a generic and for some types of items in a set it would be unsafe
polypus74 has joined #ponylang
<doublec>
Can't we define the generic interfae such that the element is whatever can safely alias as iso->V (where V is element type)
<doublec>
and return an iso
<SeanTAllen>
interface to clone?
<doublec>
yes
<doublec>
possibly an iso->V is something too restrictive for anything useful
<polypus74>
doublec: that gist is just what i was trying to do
<doublec>
Yeah, it'll mean tag for collections of ref
<doublec>
polypus74: can you make the set in the field an iso?
<polypus74>
If i use an iso field, then i still can't send it or clone it as a val right? What i want is a local mutable field which ican somehow send a val copy of to a different actor
<doublec>
polypus74: yes, because you can clone it in a recover block
<doublec>
hmm, maybe you can't
<SeanTAllen>
you'd need to do a deep clone to do that polypus74. whats the design this fits into?
<SeanTAllen>
all that said, HashSet clone only returning a ref^ aint pretty
<SeanTAllen>
im not sure what the reasoning behind that is...
<SeanTAllen>
at the moment, i'm strongly leaning towards calling that a bug and opening an issue
<polypus74>
Well, this is all motivated by the fact that the udp notifier can only be replaced and not modified within a udp socket. I have a set of actors (tags) which i need to keep track of in my udp wrapper class, and when one is added or removed, i need to swap out the notifier.
<SeanTAllen>
ah
<SeanTAllen>
ok
<SeanTAllen>
i figured it out
<polypus74>
So that it can send messages to my set of actors. This way i avoid having to instantiate an actor to do that dispatching. Would be great if there were a behaviour taking a lambda to modify the notifier
<SeanTAllen>
still feels like a bug.. anyway, reading your bit now polypus74
<doublec>
sadly it can't be iso because of the call to 'set' in the implementation of clone
<doublec>
set is a 'ref' and 'value' it is being set to may not be sendable
<doublec>
so automatic recovery doesn't work
<SeanTAllen>
what do you mean the udp notifier can't be modified polypus74 ?
<SeanTAllen>
@doublec i feel like this should be opened as an issue. it impacts other collections as well. thoughts?
<polypus74>
AFAICT you can only swap out a UDPNotifier from a UDPSocket, there is no way to touch it as it is sent iso, correct?
<SeanTAllen>
polypus74: i'm not sure what you mean by a udp notifier can't be modified. can you give an example what "modified" would be?
<SeanTAllen>
what do you mean "touch it"?
<SeanTAllen>
what sort of modification do you want to do to the notifier?
<doublec>
SeanTAllen: I think we need an answer to "how do I clone a ref collection to send it" which should be probably be discussed in an issue
<polypus74>
When you create a socket you pass in a notifier as iso. After that the socket owns it, so how would i add or remove actors from the set i would like it to manage?
<SeanTAllen>
doublec: care to open that one?
<doublec>
SeanTAllen: polypus74 would like the notifier to send to a list of actors that can change. But once the notifier is added to the socket it can't be changed.
<SeanTAllen>
ah, i see what you are saying polypus74, you want to be able to send messges to the notifier, correct? so it can update its state based on something outside of incoming/outgoing data, correct?
<polypus74>
correct
<doublec>
polypus74: I'd make the notifier have a reference to an actor that manages the list
<polypus74>
Yes
<SeanTAllen>
it can be changed, its the message sending that is an issue
<SeanTAllen>
So, Sylvan and I have been working on solving exactly that problem
<polypus74>
Yeah. I was trying to avoid that extra actor. Perhaps premature optimization
<SeanTAllen>
the horrible answer to how you can deal with it is do what we are doing at Sendence which is running custom, hacked up versions of the net library.
<doublec>
polypus74: It'd need to be an actor since you don't know what thread the notifier is notifying on
<SeanTAllen>
sylvanc and i have been calling that feature you want "async lambda"
<doublec>
polypus74: and you'd have races accessing the collection
<SeanTAllen>
basically the ability of a class to say, "here, send me this message" and have its enclosing actor deliver it without needing to change to interface to the enclosing actor
<SeanTAllen>
so something like this is coming. its needed for a number of features.
<polypus74>
Ok. Thanks guys
<jemc>
I'm joining the conversation later, so I may be lacking in context, but this seems like the same old "iso clone" problem we've been kicking the can about for a while now
<SeanTAllen>
in the meantime, what we are doing at sendence is running a custom version of "net" to add the functionality we need to TCPConnection. Its not a good answer but its the best you can do at the moment until that feature lands. I need to bug sylvanc about it and see where it is at and if he needs help bringing it home.
<doublec>
jemc: sounds like it
<jemc>
sylvanc recently proposed adding an "isolate" idiom that would act as an iso-oriented version of clone (doing copy where necessary)
<jemc>
don't think there's an RFC for it though
<SeanTAllen>
there isn't
<SeanTAllen>
and yeah that issue does come up a lot, doesn't it jemc?
<jemc>
:D
<jemc>
I think it ultimately ends up coming back to the "turnstile" operator we've chattered about
rosstuck has quit [Remote host closed the connection]
jemc has joined #ponylang
tm-exa has quit [Ping timeout: 240 seconds]
amclain has joined #ponylang
CcxCZ has quit [Quit: rebooting]
<kushalp>
Hello! I'm trying to write up a Pony for Rubyists chapter for one of the gitbooks. I have a small (toy) Ruby that spins up a Thread and (asynchronously) executes the body. It's not pretty, but I wanted to show how simple the equivalent would be in Pony. Here's what my Ruby code looks like:
<jemc>
kushalp: looks about right to me - although if this is for showing off Pony idioms, I'd suggest following the "principle of least privilege" a bit more - that is, you `Greeter` doesn't need the whole `Env`, which carries a ton of authority to do stuff - It only needs to be able to print to stdout, so you should pass it `env.out` instead of the entire `env`
<jemc>
also, I write a lot of Ruby code in my day job so I'm happy to help review other examples if you need it
jemc has quit [Read error: Connection reset by peer]
<kushalp>
jemc: Great, thanks!
<kushalp>
One more question, I'm "stealing" the Java class example for Ruby at the moment. Here's the equivalent Pony code:
<kushalp>
Thanks for finding the offending commit so quickly!
dynarr has quit [Client Quit]
<SeanTAllen>
kushalp: its fixed on master if you want to build from source
kulibali has joined #ponylang
Praetonus has quit [Quit: Leaving]
dynarr has joined #ponylang
<kushalp>
👍
<kushalp>
SeanTAllen: are any of the Sendence folks going to be at Strange Loop this week?
<SeanTAllen>
kushalp: i was going to be but had to cancel. i don't believe anyone else is going. we have release coming up at the end of october and everyone is pretty heads down.
<kushalp>
SeanTAllen: Ah, that's a shame. Good luck with the release!
<kushalp>
I think I have half a draft of a Pony for Rubyists post written. I'll finish it on my flight from NY to STL tomorrow
<kushalp>
And then PR it for others to review
<SeanTAllen>
nice
<SeanTAllen>
i get to be envious of everyone at Strangeloop
<jemc>
I can't go, but I'm excited to see the next round of talks to come onto their youtube for my perusal
<SeanTAllen>
i enjoy seeing friends more than conferences themselves at this point.
<SeanTAllen>
still, strangeloop is one of my favorites