alxs has quit [Quit: Computer's gone to sleep. ZZZzzz…]
alxs has joined #ponylang
alxs has quit [Client Quit]
bimawa has joined #ponylang
bimawa has quit [Ping timeout: 248 seconds]
bimawa has joined #ponylang
bimawa has quit [Ping timeout: 240 seconds]
btbytes has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
btbytes has joined #ponylang
btbytes has quit [Ping timeout: 265 seconds]
bimawa has joined #ponylang
bimawa has quit [Ping timeout: 240 seconds]
dipin has joined #ponylang
jaro has quit [Ping timeout: 260 seconds]
bimawa has joined #ponylang
bimawa has quit [Ping timeout: 240 seconds]
dipin has quit [Quit: dipin]
acarrico has quit [Ping timeout: 260 seconds]
bimawa has joined #ponylang
bimawa has quit [Ping timeout: 260 seconds]
bimawa has joined #ponylang
bimawa has quit [Ping timeout: 240 seconds]
bimawa has joined #ponylang
bimawa has quit [Ping timeout: 260 seconds]
endformationage has quit [Quit: WeeChat 1.9.1]
bimawa has joined #ponylang
bimawa has quit [Ping timeout: 264 seconds]
bimawa has joined #ponylang
bimawa has quit [Ping timeout: 260 seconds]
bimawa has joined #ponylang
bimawa has quit [Ping timeout: 256 seconds]
bimawa has joined #ponylang
bimawa has quit [Ping timeout: 256 seconds]
bimawa has joined #ponylang
bimawa has quit [Ping timeout: 240 seconds]
khan has quit [Remote host closed the connection]
bimawa has joined #ponylang
bimawa has quit [Ping timeout: 256 seconds]
RandomResearcher has joined #ponylang
bimawa has joined #ponylang
<RandomResearcher>
Hey peeps, good morning. I was wondering if there is a publication on the pony language that outlines the general language. I've found the pony papers on the website under community/papers but, just going by the titles, they seem to be focussed on one particular aspect of pony (which is to be expected).
<RandomResearcher>
As a side question: does Pony support something like inheritance or trait composition for actors?
bimawa has quit [Ping timeout: 240 seconds]
<dave24>
randomresearcher: There is a good tutorial as an introduction to the language: https://tutorial.ponylang.org
<dave24>
and yes, traits do work with actors and can be combined with the intersection operator: &
<RandomResearcher>
I'm interested in that mechanism. Is this mechanism discussed somewhere in a paper?
<RandomResearcher>
Aha. Just made a guess and found info on intersection types in "A Principled Design of Capabilities in Pony"
<RandomResearcher>
Thank you!
bimawa has joined #ponylang
bimawa has quit [Ping timeout: 260 seconds]
<RandomResearcher>
Please correct me if I'm wrong. Traits in Pony can define both functions and behaviours, can be inherited from by both actors and classes. Traits are stateless. Is it correct when I say that a trait cannot reference its composer, e.g. via a "this" reference?
bimawa has joined #ponylang
<dave24>
randomresearcher: Your first two statements are true.
<dave24>
I don't know about the last two.
<dave24>
I just tried it, you can reference `this` in a default implementation of a trait function.
<dave24>
Note also that of course a class can never satisfy a trait/interface as soon as it has behaviours.
<dave24>
And about stateful traits, I'm not sure what you mean. I know nothing about the object and can therefore not access any of it's fields in the default implementation. But that does not apply to the specialised implementation.
<RandomResearcher>
Indeed, a class 'inheriting' from a trait that defines a behaviour is a compile error (as expected). I tried invoking a function on a class via "this" in the default implementation of a trait in the Pony Playground, and it threw a type error at me: "can't find declaration of ..."
<RandomResearcher>
That's why I asked if traits can reference "this". Perhaps I am doing something wrong?
<dave24>
You can reference `this`, but you don't know what fields it has so you can't access them.
<RandomResearcher>
Aha so "this" in a trait refers to the trait, and not the object that the trait is composed into.
<dave24>
hmm
<dave24>
this does refer to the object
<dave24>
but you only have limitied information about the object, because several classes could use the trait
<dave24>
so you can only use the thing you know the object must have: the ones also in the same trait
<dave24>
traits don't exist at runtime. So `this` could not possibly be a reference to the trait.
<RandomResearcher>
Indeed, so that's why I found it slightly confusing that a trait could not call a function on the object via "this", but your explanation makes sense. Still it leaves me wondering whether it is possible for a trait to call a function on the composer, since this was a pretty important thing in the original definition of traits
<dave24>
It can call a function on the object, as long as that function is also declared in the trait (It does not need the default implementation like in my example).
<RandomResearcher>
Ahhh so the function in the trait is really a "default implementation" in the true sense of the term
<RandomResearcher>
That makes sense. Thank you very much!
<dave24>
np
<dave24>
Traits are just requirements that classes/actors may satisfy, they are not objects themselves.
<dave24>
Same for interfaces.
vaninwagen_ has joined #ponylang
vaninwagen_ has quit [Ping timeout: 268 seconds]
bimawa has joined #ponylang
bimawa has quit [Ping timeout: 240 seconds]
inara has quit [Quit: Leaving]
jaro has joined #ponylang
inara has joined #ponylang
RandomResearcher has quit [Quit: Page closed]
bimawa has joined #ponylang
bimawa has quit [Ping timeout: 268 seconds]
<vaninwagen>
dave24 great explanation
<SeanTAllen>
There was a lot of discussion of possible changes to traits and interfaces (and talk of mixins) in a recent Pony developer sync. in particular the one from 6/20. https://pony.groups.io/g/dev/files/Pony%20Sync/2018_06_20. You'd need to be a member of the "pony dev" mailing list to access the files: https://pony.groups.io/g/dev
<winksaville>
@SeanTAllen, nice getting 0.24.0 out! I answered dipin's questions, do you have any questions on PR #2812 (https://github.com/ponylang/ponyc/pull/2812) "Add LLVM_BUILD_MODE fix issue #2776"?
<SeanTAllen>
winksaville: havent had a chance to look. probably wont have time to look anytime today
<pzel>
run that, and run netstat -plnt in another terminal
<pzel>
netstat lists it as listening on 0.0.0.0 (what I requested), but the Pony output is 127.0.0.1
<SeanTAllen>
there's multple oututs there
<SeanTAllen>
what output?
<pzel>
> hello external: listening on 127.0.0.1:9001
<pzel>
Is what I'm seeing
<pzel>
and then I do ` nc 192.168.31.102 9001` and i get connected.
<pzel>
So it's not only listening on 127.0.0.1, it's listening on ANY interface, which is not the same as the lo interface
<SeanTAllen>
line numbers would have made that easier btw
<pzel>
line 30
<SeanTAllen>
thank you
<pzel>
29 actually, sorry
<SeanTAllen>
so
<SeanTAllen>
what should it do?
<SeanTAllen>
you are asking for a local address
<SeanTAllen>
0.0.0.0 is not a valid address
<pzel>
yes, but it's a customary representation of INADDR_ANY when listening
<SeanTAllen>
its also useless to end user code though
<pzel>
Okay, that makes sense as rationale, okay.
<SeanTAllen>
its not a rationale
<SeanTAllen>
im making a statement
<SeanTAllen>
and asking what you think the right thing to do is
<SeanTAllen>
0.0.0.0 is pretty much only good for display
<SeanTAllen>
nothing else
<SeanTAllen>
if you wanted to make the argument that local_address should return an array of net addresses, that would make sense to me and then not return 0.0.0.0 and 127.0.0.1 would be one of many
<pzel>
Here's where I went wrong: the pony code calls local_address().name(), and it's the output of name() which is used for display. I'd skipped over the fact that local_address() returns a NetAddr
<pzel>
So I see the point about returning an actual address that the end user could do something with.
<SeanTAllen>
i think you could have the case for a very good RFC that it should be local_addresses and return an array
<SeanTAllen>
without 0.0.0.0 in it
<SeanTAllen>
but all the interfaces that are actually being listened on
<SeanTAllen>
i wouldnt say what it is doing is wrong, much like returning 0.0.0.0 wouldnt be wrong
<SeanTAllen>
i think what it is doing is more useful than 0.0.0.0
<SeanTAllen>
but neither is ideal
<SeanTAllen>
an array makes a lot of sense there for a listener
<SeanTAllen>
because it can be listening on more than 1 address
<SeanTAllen>
same argument for tcp connection as well
<pzel>
What if I start a listener and then a new iface gets added to the system? IDK what the behaviour of INADDR_ANY should be in that case.
<SeanTAllen>
note "" is also "any address" in those classes.
<SeanTAllen>
it will only be listening on the addresses at the time it was started
<pzel>
Okay, so the array returned doesn't become 'stale'. Cool.
<SeanTAllen>
which would make netstat misleading
<pzel>
Right
<SeanTAllen>
0.0.0.0 is... problematic
<SeanTAllen>
i understand why it exists but its... yeah
<SeanTAllen>
not so good
<SeanTAllen>
So, i think you should write up an RFC
<pzel>
Sounds good.
<SeanTAllen>
im not sure what needs to change for implementation on that...
<SeanTAllen>
im not sure if you can look up all the addresses that 0.0.0.0 is on
<pzel>
Okay, last thought: Why not make INADDR_ANY a legal address? As in (simplified) : type Address = (AnyAddress | (N.N.N.N))
<SeanTAllen>
ugh yeah any doesnt let you find out what all of them are
<SeanTAllen>
thats right you can only get 1
<SeanTAllen>
and that's INADDR_ANY
<pzel>
Right, there's only on s_addr on there
<SeanTAllen>
im starting to remember to "we just jammed it in there" nature of the C apis
bimawa has joined #ponylang
<SeanTAllen>
i think you can make a decent argument that it should be 0.0.0.0
<SeanTAllen>
and have something for any address
<SeanTAllen>
that seems like reasonable RFC pzel
<pzel>
Sooo not as cool as acutally enumerating the interfaces, tho :
<pzel>
Okay, I'll sleep on the topic. Thanks for the help SeanTAllen
<SeanTAllen>
yeah cant really enumerate
<SeanTAllen>
easily
<SeanTAllen>
i forgot about that
<SeanTAllen>
its been a while since i mucked with those bits of berkeley sockets