<jmiven>
Hi! In the context of the contructor of a class, what is the receiver? Specifically, I'm not sure what "new iso create()" implies for the object. Is iso the capability of the object created? In which case, what is the difference with "class iso MyClass"?
<SeanTAllen>
o lord, someone is looking at the first pony i wrote
<SeanTAllen>
"new iso create" means that the default reference type for this class when created is iso
<SeanTAllen>
that is part of a notifier and notifier always have to be `iso` when handed off to a TCPListener et al
<SeanTAllen>
so... without that, if it was new create() you'd have to do... recover iso Listener end
<SeanTAllen>
and that gets rather old after a while
<SeanTAllen>
if its on the create, you can change it
<SeanTAllen>
if its on the class, that is how the class is
<SeanTAllen>
so
<SeanTAllen>
class val Foo
<SeanTAllen>
is always going to be immutable after creation
<SeanTAllen>
hopefully that helps jmiven
<jmiven>
Oh, OK thanks SeanTAllen it helps!
<jmiven>
reference capabilities aren't easy to understand but it's the good kind of not-easy
<SeanTAllen>
its a rough hump to get over but worth it
<SeanTAllen>
they have helped us catch a lot of bugs that would have taken months to track down
<SeanTAllen>
definitely has us moving much faster when developing our app
<polypus74>
SeanTAllen: out of curiosity. what's your app?
<jmiven>
interesting :-) pony has got me excited
<jmiven>
need to sleep now :-D
mvzink has joined #ponylang
mvzink has quit [Quit: A merry Christmas to all, and to all a good night!]
TonyLo_ has joined #ponylang
TonyLo_ has quit [Ping timeout: 276 seconds]
pyon has quit [Quit: Dammit, Emacs.]
c355e3b has quit [Quit: Connection closed for inactivity]
<jemc>
polypus74: tonight I hope to push to github some of my progress on the pony-redis client
<jemc>
I've had it basically working since like the first night but I've been doing lots of futzing and massaging of the internals to try to arrive at something relatively clean
<jemc>
I've been wanting to upload my progress for a while, but I keep futzing instead - hopefully me saying this publicly will help motivate me to follow through tonight ;)
<polypus74>
jems: v/ cool. i'm working (very slowly) on a NATS client. trying to get around TCP in pony still
<polypus74>
s/jems/jemc
<polypus74>
looking forward to seeing your redis client. will probably help me with my little project
<SeanTAllen>
polypus74: do you need any TCP help?
<jemc>
I've definitely run into some of the classic pony pain points, as well as a few new ones - I'm hoping that some further yak shaving on this project (which is otherwise pretty simple) will yield some nice RFCs to make pony a nicer place
<jemc>
bbl
<SeanTAllen>
there's a ton of stuff that will be so much nicer once Sylvanc has time to get asynclambda in place.
<SeanTAllen>
i'm currently writing new incoming and outgoing tcp stuff for our app to get around the problems that not having asynclambda creates which if I remember correctly, was polypus74's issue.
<polypus74>
SeanTAllen: yeah. last time i asked a networking Q, the answer seemed to be that i needed asynlambda, or that at least it would make things nicer.
<polypus74>
as for help. well your blog posts have already been some help. i've done a bot of low level UDP hacking before, but in this case both pony and TCP are pretty new to me
<SeanTAllen>
yeah, if you still have the same problem, the solution for now is to make changes to TCPConnection on your side
<polypus74>
s/boy/bit
<polypus74>
bot/bit
<polypus74>
one Q: what exactly do init_size and max_size do in TCPConnection.create?
<polypus74>
SeanTAllen: as for old problem, i'm just creating a client actor and having the Notifier hold a reference to that. make things simple
<SeanTAllen>
read buffer sizes polypus74
<SeanTAllen>
initial size of the read buffer and the max size to let it grow to
<polypus74>
meaning that for any given invocation of received on the Notifier i the Array[U8] will at most be max_size correct
<SeanTAllen>
yes
<SeanTAllen>
are you familiar with the expect() call ?
<polypus74>
no. i saw it n=but was wondering about it
<polypus74>
can't bloody type today
<SeanTAllen>
expect is the number of bytes that you want delivered
<SeanTAllen>
you can use it for framed protocols
<SeanTAllen>
say your protocol is 4 bytes of header, and that header is how many bytes the payload is....
<polypus74>
ok good to know. unfortunately the NATS protocol can't be parsed that way. in my experiments so far, i noticed that even with small incoming messages they were getting split across multiple calls to received. i suppose that is to be expected with TCP and i have to buffer messages until they are complete, correct? fyi, i have seen buffered.Reader
<polypus74>
SeanTAllen: thanks for the tips
<SeanTAllen>
yes you would have to.
<SeanTAllen>
how do you know when they are complete?
<polypus74>
depends on the type of incoming message. but that is well defined
<polypus74>
\r\n and/or byte length given
<SeanTAllen>
Byte length will work w expect
<SeanTAllen>
Assuming bte length given always takes the same amount of space
<SeanTAllen>
Delimiters are the worst for parsing
<SeanTAllen>
Good luck
<polypus74>
it's actually not too bad. pretty simple, like redis. but thanks
xshuiniu has quit [Remote host closed the connection]
xshuiniu has joined #ponylang
malthe_ is now known as malthe
dinfuehr has quit [Ping timeout: 276 seconds]
dinfuehr has joined #ponylang
dinfuehr has quit [Ping timeout: 272 seconds]
dinfuehr has joined #ponylang
<malthe>
git st
<malthe>
ugh :-)
rosstuck has joined #ponylang
c355e3b has joined #ponylang
_andre has joined #ponylang
jemc has joined #ponylang
jemc has quit [Quit: WeeChat 1.4]
jemc has joined #ponylang
rosstuck has quit [Ping timeout: 272 seconds]
rosstuck has joined #ponylang
rosstuck has quit [Ping timeout: 244 seconds]
rosstuck has joined #ponylang
rosstuck has quit [Remote host closed the connection]
TonyLo_ has joined #ponylang
TonyLo_ has quit [Read error: Connection reset by peer]
<jemc>
SeanTAllen: sylvanc: had another idea that could solve some of the same pain points as the async lambda idea
<jemc>
we could have a mechanism for actor composition - actor B could "embed" actor A and have a `ref` reference to it
<jemc>
they would share the same mailbox, but B wouldn't have access to private methods or fields of A
<jemc>
A wouldn't have to know anything about B, it would just need to expose some synchronous API methods that would be useful in this context
<jemc>
basically the same set of synchronous methods exposed to a notifier in the notifier pattern would be exposed to the "outer" actor in the composition
<jemc>
so I could create an `actor MyConnection` that embeds a `TCPConnection`, and expose some asynchronous behaviours in its API, that internally can use the synchronous API of the TCPConnection
<SeanTAllen>
i dont think that remove the need i have for asynclambda
<SeanTAllen>
but it could also be handy
<jemc>
it's possible the two would have related implementations
<jemc>
for example, a lambda is an anonymous primitive or class (depending on whether it has captures), that gets created and used in the "call site" of the lambda
<jemc>
an async lambda would be an anonymous actor that would have a shared mailbox mechanism, much like the composed actors in this other idea
<jemc>
I will file an RFC for further discussion
mvzink has joined #ponylang
<SeanTAllen>
Excellent
<mvzink>
is there anywhere i can read about this asynclambda business? i wrote an echo server with TCPConnection, but i'll be doing some "real" TCP stuff soon here, so i'd like to get up to date on issues and upcoming changes related to networking
<SeanTAllen>
Not yet. It's an idea that has been kicking around
<SeanTAllen>
RFC would be first surfacing to people
<mvzink>
ok. i believe i get github notifications for the rfcs repo so i'll keep an eye out :)
<SeanTAllen>
It's pretty much related to having composable, reusable functionality that can be added to actors wo having to change their code
<SeanTAllen>
Well, rather, wo adding new behaviors.
<mvzink>
hmmm... jemc's suggestion sounds kind of like actor mixins; what would async lambdas look like?
<SeanTAllen>
In some actor languages, you can send messages to anything. Actor, class, whatever. In pony you can't. And it causes issues when say, you want to introduce a credit flow Backpressure system.
<SeanTAllen>
I'm working on such a system now but had to rewrite TCPConnection and other parts of net to make it work because existing composition isn't rich enough
<SeanTAllen>
Async lambda allows a class that has a non tag reference to an actor to create a lambda whose results will be delivered to it async.
<SeanTAllen>
So a notifier could receive messages in response to actions it takes
<SeanTAllen>
Like receive a credit request message from actors that are sending write messages to the enclosing TCPConnection
<mvzink>
interesting. and why does it matter that the class has a non-tag reference to the actor?
<SeanTAllen>
Proof that you are enclosed in that actor
<SeanTAllen>
The only type of reference you can get from "outside" is a tag
<jemc>
SeanTAllen: I actually have a feeling that a credit flow system could be implemented using actor embedding, but I'd have to know more to be sure
<jemc>
I don't want to try to override the idea of async lambdas, but I do think that perhaps actor embedding could be a simpler first step in that direction
<jemc>
kind of like anything that uses lambdas in Pony now could be implemented using explicit primitives and classes (since that's what a lambda compiles to), but lambdas are more convenient for certain use cases
<jemc>
(setting aside the fact that lambdas as they currently exist have some pretty ugly usability problems that we need to fix up)
<SeanTAllen>
The problem is the embedding has the multiple inheritance problem
<SeanTAllen>
And doesn't work well w interacting w notifies
<SeanTAllen>
Notifiers
<SeanTAllen>
I know because I tried the idea
<mvzink>
sweet, thanks jemc, i'll give that a read. seems really interesting after a skim.
<SeanTAllen>
In the meantime, we are running custom network code
<jemc>
SeanTAllen: I don't see why embedding actors would have a multiple inheritance problem, when embedded classes do not - at least I assume you are referring to the "diamond of death"
<jemc>
but perhaps you can explain in more full-form in the RFC comments
<jemc>
in terms of interacting with notifiers, I'd been considering that a bit, and I think we can come up with some feasible patterns for interop
<jemc>
regarding the "diamond of death" problem, as I understand it, that's much of the reason why Pony does not have inheritance, and why sylvanc came up with embedding as an alternative that brings many of the same benefits, without the dangers of shared method namespace or ambiguous memory layout of fields
<jemc>
so embedded actors would have the same set of advantages and disadvantages
_andre has quit [Ping timeout: 264 seconds]
<SeanTAllen>
What is the type of an actor that embeds a TCPConnection?
<jemc>
from the type system perspective, and what methods are exposed, the outer type is "unrelated" to the inner type - just as with embedded classes (think `embed` keyword), the outer type does not "inherit" the methods of the inner type, it merely gets the opportunity to wrap them
<SeanTAllen>
That's very problematic
<SeanTAllen>
Take TCPConnection
<SeanTAllen>
It's created by a listener notifier in accept
<SeanTAllen>
It's a TCPConnection
<SeanTAllen>
I can't wrap it to be something that does credit flow Backpressure
<SeanTAllen>
Even if i thought that was a good idea
<SeanTAllen>
I think async lambda ends up being simpler
<jemc>
I'd have to understand more about your use case to understand why it is problematic for you
<jemc>
and again, I'm not trying to tell you that we shouldn't implement async lambda
<SeanTAllen>
Because I can't augment TCPConnection
<SeanTAllen>
it's simply not possible
<SeanTAllen>
Without breaking the type system
<jemc>
but as of right now you and sylvanc are the only ones who know anything about the design/features of async lambda - there is no RFC to discuss
<SeanTAllen>
That's true
<SeanTAllen>
It's waiting for sylvanc to finish his thesis
<SeanTAllen>
Stupid thesis
<jemc>
it sounds like you're using a very narrow view of "possible"
<SeanTAllen>
Getting in the way of my needs
<SeanTAllen>
The thesis that is
<jemc>
even if what you're saying is true for the current API of TCPListener and TCPConnection (which I'm not convinced of so far), it's not a type system impossibility, it's an API incompatibility
<SeanTAllen>
If you create an interface for every actor
<jemc>
the outer actor does not need to be type-system-interchangable for the inner actor for this pattern to be useful
<SeanTAllen>
Then it can return something of that interface but then it's typed as the interface not the full API of the outer actor
<SeanTAllen>
It does if you don't control the type of it
<jemc>
the type of what?
<jemc>
I completely control the type of MyConnection and the code that uses it
<SeanTAllen>
I'll write it up on your RFC
<jemc>
at no point outside the implementation of MyConnection do I know or care that there is a TCPConnection underneath
<SeanTAllen>
There's no way to use this with anything that looks like TCP listener and TCP connection
<jemc>
yes there is, provided the API is designed with this pattern in mind
<jemc>
if you use "looks like" in a very exact sense, then sure, you're right - but even in that case you can still augment client-side TCPConnections
<SeanTAllen>
I don't see how you put them together easily
<SeanTAllen>
It certainly breaks all existing code bases
<SeanTAllen>
How do I augment a client side TCPConnection to have a new behavior?
<SeanTAllen>
I don't see how you do it with a staticly typed language
<jemc>
SeanTAllen: I'm hearing a lot of hyperbole and implicit assumptions on this end that are making it difficult to have a fruitful conversation
<jemc>
I'm going to get back to other things and we can discuss more later, hopefully in more concrete terms
<jemc>
at any rate, if this pattern won't solve your particular problem (that I have no way of knowing the details of) in the way you hope and imagine, that's fine, and we don't have to pretend that it will do so
<jemc>
again, I'm not trying to tell you that we shouldn't implement async lambda
<jemc>
and my problem spaces and pain points are obviously different from yours, since we seem to be talking about them in such different terms
<SeanTAllen>
When I'm not on my phone, I'll send you a complete write up
<SeanTAllen>
Ok maybe not for many days
<SeanTAllen>
I leave for vacation soon
<SeanTAllen>
But in the not so distant future
montanonic has joined #ponylang
<jemc>
SeanTAllen: hearing more about your use case would definitely be interesting and informative, though at this point I think I don't want to try to convince you that my RFC will solve your problem when you say it won't - I'm fine with that answer - it's enough for me that it will solve *my* problems
<SeanTAllen>
Yeah
<SeanTAllen>
I think it solves a lot of problems
<SeanTAllen>
I think we need both
<SeanTAllen>
Probably
<jemc>
agreed
<SeanTAllen>
I have loosely held strong opinions
<jemc>
:D
<SeanTAllen>
I have to get the Backpressure RFC in because my method names are awful
<jemc>
I'm excited to see it
<SeanTAllen>
And API feedback is very needed
<SeanTAllen>
It's very simple
<jemc>
I will file the embedded actor RFC tonight
<SeanTAllen>
But it's been very handy for us
adamkittelson_ has joined #ponylang
mankyKitty_ has joined #ponylang
adamkittelson has quit [Ping timeout: 252 seconds]
mankyKitty has quit [Ping timeout: 252 seconds]
jonrh has quit [Ping timeout: 252 seconds]
adamkittelson_ is now known as adamkittelson
mankyKitty_ is now known as mankyKitty
jonrh has joined #ponylang
M-Ingo has quit [Ping timeout: 240 seconds]
irx[m] has quit [Ping timeout: 240 seconds]
mcguire1 has joined #ponylang
montanonic has quit [Remote host closed the connection]
mcguire has joined #ponylang
malthe has quit [Ping timeout: 252 seconds]
malthe_ has joined #ponylang
Xe has quit [Ping timeout: 252 seconds]
Xe has joined #ponylang
M-Ingo has joined #ponylang
Xe has quit [Ping timeout: 252 seconds]
Xe has joined #ponylang
irx[m] has joined #ponylang
emancu has joined #ponylang
Matthias247 has quit [Read error: Connection reset by peer]