tm-exa has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
DanC_ has quit [Quit: ubuntu maintenance]
jemc has quit [Ping timeout: 255 seconds]
dynarr has quit [Quit: A merry Christmas to all, and to all a good night!]
<kushalp>
Yeah, I went last year and thought the whole vibe was really good. Hence why I'm attending again this year 😁
dynarr has joined #ponylang
dynarr has quit [Client Quit]
montanonic has quit [Quit: My laptop is sleeping.]
montanonic has joined #ponylang
mrkishi has quit [Ping timeout: 265 seconds]
jemc has joined #ponylang
rosstuck has quit [Ping timeout: 265 seconds]
k0nsl has quit [Ping timeout: 240 seconds]
k0nsl has joined #ponylang
k0nsl has quit [Changing host]
k0nsl has joined #ponylang
amclain has quit [Quit: Leaving]
rosstuck has joined #ponylang
montanonic has quit [Ping timeout: 244 seconds]
montanonic has joined #ponylang
kulibali has quit [Ping timeout: 265 seconds]
dinfuehr has quit [Quit: ZNC 1.6.3+deb1 - http://znc.in]
dinfuehr has joined #ponylang
montanonic has quit [Ping timeout: 260 seconds]
tm-exa_ has joined #ponylang
montanonic has joined #ponylang
dinfuehr has quit [Ping timeout: 244 seconds]
dinfuehr has joined #ponylang
shelajev has joined #ponylang
montanonic has quit [Ping timeout: 255 seconds]
mrkishi has joined #ponylang
<kushalp>
Is there a repo or something that shows off some Pony concurrency patterns? I'd like to show equivalent implementations for things that Rubyists commonly do and how they can be handled in Pony
<SeanTAllen>
there isn't at this time.
<SeanTAllen>
what sort of "concurrency patterns"?
shelajev_ has joined #ponylang
shelajev has quit [Read error: Connection reset by peer]
shelajev has joined #ponylang
shelajev_ has quit [Ping timeout: 250 seconds]
<kushalp>
I think the three that I'm thinking of (in Ruby) are:
<kushalp>
3. a future/promise abstraction -- I think I might use Maybe[T] for this instead
<kushalp>
2. expiry timers -- sends an event when a time is reached to a single queue
<kushalp>
1. a single queue, with multiple threads reading from it, and adding the result to another queue
<kushalp>
They're interesting in Ruby as they need you to define the critical section or use a mutex to make things thread safe. I thought they'd be nice to contrast with Pony
<SeanTAllen>
1 doesnt exist in pony. you dont have access to threads.
<SeanTAllen>
kushalp: 1 doesnt make sense in an actor model system. what you might have in that case is an actor sending work to different actors or if you want to keep it balanced in terms of time, you could have actors requesting work for another actor that is queueing that work. when the request is made, they are sent additional work.
<SeanTAllen>
people tend to think of actors as a unit of parallelism but that can lead to bad patterns
<SeanTAllen>
in the end, actors are more about data access
<SeanTAllen>
so in this case, you have a queue that you want to share
<SeanTAllen>
that queue should be held by an actor
<SeanTAllen>
in order to interact with that shared resource, you need to deal with that actor
<SeanTAllen>
so "multiple threads reading from it" means... actors communicating with the "queue" actor and requesting the next item from the queue.
<SeanTAllen>
"adding the result to another queue" means sending a message with work product to another instance of "queue actor"
<SeanTAllen>
related to item 3: Maybe[T] is for ffi pointers. there's no "Maybe" type in Pony. Its a union type (T | None)
pyon has quit [Quit: Fix config.]
pyon has joined #ponylang
trapped has joined #ponylang
mrkishi has quit [Remote host closed the connection]
jemc has quit [Ping timeout: 265 seconds]
<kushalp>
Totally! I wasn't suggesting implementing things identically. Just that these are things Ruby folks will know and can build common ground from
shelajev has quit [Remote host closed the connection]
jemc has joined #ponylang
shelajev has joined #ponylang
shelajev has quit [Remote host closed the connection]
shelajev has joined #ponylang
tm-exa_ has quit [Ping timeout: 255 seconds]
trapped has quit [Read error: Connection reset by peer]
trapped has joined #ponylang
rosstuck has quit [Remote host closed the connection]
trapped has quit [Read error: Connection reset by peer]
trapped has joined #ponylang
amclain has joined #ponylang
amclain has quit [Quit: Leaving]
TwoNotes has joined #ponylang
amclain has joined #ponylang
dynarr has joined #ponylang
TwoNotes has quit [Quit: Leaving.]
dynarr has quit [Quit: A merry Christmas to all, and to all a good night!]
shelajev has quit []
dynarr has joined #ponylang
runehog has quit [Remote host closed the connection]
dynarr has quit [Quit: A merry Christmas to all, and to all a good night!]
dynarr has joined #ponylang
runehog has joined #ponylang
montanonic has joined #ponylang
polypus74 has joined #ponylang
dynarr has quit [Quit: A merry Christmas to all, and to all a good night!]
<polypus74>
what is the use case for constructors on primitives?
<polypus74>
why can you specify an rcap for an actor method receiver type? isn't it always tag?
dynarr has quit [Quit: A merry Christmas to all, and to all a good night!]
runehog has quit [Remote host closed the connection]
runehog has joined #ponylang
<jemc>
polypus74: actor *behaviours* may only be tag, but actor methods may be any rcap
<jemc>
though the only useful ones are likely ref, box, and tag
<polypus74>
in what situation would you have a ref or box to an actor?
<jemc>
sorry, I mispoke a bit, so I'll backtrack quickly - behaviours are essentially `ref`, but are callable on `tag` receivers due to the async message passing paradigm
<jemc>
so `this` inside a behaviour is a `MyActor ref`
<jemc>
if you want to break up actor behaviours into logical units of methods (that are only callable from the "inside"), then you can do so by defining methods on the actor
<jemc>
if you want to mutate the state of the actor, it must be a `fun ref`, whereas if you don't need to mutate state, use `fun box`
<jemc>
for a real-world example of having a `ref` reference to an actor, see `TCPConnectionNotify`, which receives a `TCPConnection ref` for every method in it (and `TCPConnection` is an actor)
<jemc>
this can work, because the `TCPConnectionNotify` methods are only invoked from inside the `TCPConnection` actor, and it passes its `ref` view of itself as the first argument
<polypus74>
ok. thanks. i'll have a look at all of that
<kushalp>
Would appreciate any feedback and I'll try to take care of amendments this week whilst at the conference
<kushalp>
If you'd prefer these be submitted in some other format (Google Docs?) just let me know and I'll close those PRs
<polypus74>
i'm writing up a tutorial on rcaps. as much to learn myself as to teach others. would the following be an accurate thing to say then:
<polypus74>
Behaviours are a bit strange in that from the caller's point of view the rcap of the receiver is immaterial, but inside the body of the behaviour `this` is always `ref`
<SeanTAllen>
you got mentioned a couple times malthe
<SeanTAllen>
o wait malthe that is last weeks, i have uploaded this week's yet
<SeanTAllen>
i just didnt upload last week's til today because of a hand off problem between sylvan and i
<malthe>
oh hah ok
<malthe>
I have been too busy lately to keep up.
<malthe>
summer time ...
<jemc>
I unfortunately had to miss today's sync call (and forgot to give notice) - sorry, I've been pretty bogged down in work this week
<malthe>
polypus74: I kind of feel that what would be more helpful is to have language-specific (i.e. Python, Ruby) annotations to the tutorial.
<malthe>
the tutorial right now skips over some important bits which is bad in its own right, but it could also add bits that are more important to users that are familiar to some language(s).
<malthe>
like, for Python and Ruby users, that's mostly all the dynamic parts which you won't get in a statically compiled language.
<malthe>
I don't think saying that Python is "simple" and Pony "simple" is very helpful.
<malthe>
Basic is simple.
<malthe>
Pony is arguably pretty complex because of its memory model and its actor model.
<malthe>
It's a powerful language because it's built on these powerful models.
<malthe>
Python's built on powerful dynamics such as being able to create types programatically and change a lot of their behavior.
<malthe>
e.g. you can override the __mro__ (method resolution order).
<malthe>
But why and how should a Python developer pick up Pony? That's a good question. There is currently no gateway drug.
<polypus74>
malthe: i've programmed in dynamic and statically typed languages both functional and imperative and actor based (erlang/elixir). so since writing up the tutorial is a learning exercise for me as much as anything else, it is really rcaps which are the only truly novel thing.
<polypus74>
and i agree that tutorial need a great deal of work. after i've learned enough i might just work on it some
montanonic has quit [Ping timeout: 248 seconds]
<malthe>
I think actor model is pretty novel to a Python programmer too.
<polypus74>
definitely
<malthe>
as opposed to promises or callback.
<malthe>
don't mean to be a party killer :-)
<polypus74>
no worries :)
<malthe>
I just worry about sprawling documentation
<polypus74>
yeah. legitimate worry
<malthe>
I really think annotations are great for any documentation and language-specific ones could work really well here.
<polypus74>
annotations?
<malthe>
not sure about the infrastructure for that vis-a-vis the current doc format
<malthe>
polypus74: for example, an annotation to the tutorial chapter on actors in a Python context could be "blah blah, Python has threads as well as greenlet support through library x, y, z. but actors are more than that ... also ties into memory model"
<malthe>
this would be shown in a box, or a side-panel, or whatever
<malthe>
doublec: you should contribute to the tutorial
<malthe>
your articles are like the only documentation on some concepts :-)
<polypus74>
the problem with the official tut right now is that it doesn't give enough detail, or enough exampe code, imo. so for example in the section on substitutablity, there is no example of exactly what is meant.
<malthe>
polypus74: totally. it's really weak on examples.
<polypus74>
yeah, second that on doublec. blog posts as well as mailing list answers are clearer than tuts for most part
<malthe>
but the tut should be great.
<doublec>
malthe: I have in places. I added stuff on lambda and generics.
<doublec>
malthe: I plan to do others but time's been short lately unfortunately
<doublec>
I find writing for the tutorial quite difficult. In a mailing list post I can assume knowledge but in a tutorial it's hard to explain something without introducing concepts that haven't been covered.
<doublec>
So it generally takes quite a bit more work to write something for it
<SeanTAllen>
PRs to the tutorial are welcome. Just remember its a tutorial and that a lot of content might belong elsewhere like the Pony for X series and Pony Patterns. The tutorial should aim to be "Pony for the impatient". We very much welcome PRs. I'd suggest bringing up ideas on pony+dev before you invest a ton of time and get feedback.
<doublec>
In a blog post I can just ramble :)
<SeanTAllen>
you can do it doublec
<SeanTAllen>
;)
<doublec>
:)
<malthe>
I guess the tut could link to doublec's ramblings.
<polypus74>
doublec. yeah that is another problem with tut. it's kind of scattered and disorganized. hope i'm not stepping on anybodies toes. what is perhaps needed is a meta-map which clearly deliniates where concepts are introduced, and then also expounded upon, so that, they don't get repeated, and they don't get used prior to being explained
<malthe>
ya, like "with" is covered under exceptions.
<malthe>
it's maybe natural, but you can't find it through just scanning the left pane.
<polypus74>
meaning it's hard to update it, because you don't really know where you are in the flow
<polypus74>
what people already know
<malthe>
would be cool to have a 3-5 day long pony sprint at some venue
<malthe>
such as an austrian skiing resort or a deserted island.
<malthe>
to just really get going on a lot of these developments.
<SeanTAllen>
polypus74: complaining is fine as long as its backed up by PRs. I suggest bringing this up on the pony+dev list.
<doublec>
malthe: I wrote a ton of ATS documentation while on a remote pacific island a few years back - good idea
<doublec>
If 5 of us go to Pitcairn Island and hack on documentation we'd be 10% of the population
<malthe>
I actually did the skiing thing a couple of times; it's a lot of fun and being able to step out and "up" really helps make it a fun experience.
<polypus74>
SeanTAllen: don't mean to complain. am planning on contributing. just not ready yet. that's the vicious circle of a very young language. difficult to contribute to because dificult to learn because...
<polypus74>
doublec: i've always been fascinated by pitcairn, and other isolated islands
<SeanTAllen>
polypus74: if you get stuck on something where IRC or email isnt helping, drop me a line and we can do a email/call exchange to see if I can help.
<jemc>
you can assume whatever level of competence is appropriate, and treat a specific subject in detail
<doublec>
polypus74: It's a great place, I loved it there.
<SeanTAllen>
thanks for reminding me i have an open PR for a pattern to finish jemc
<malthe>
SeanTAllen: is the pon'for "for the impatient" a valid concern?
<malthe>
s/pon'for/pony
<malthe>
I think the tutorial needs to quickly (for the impatient) sell you on investigating the language further, but being impatient is not going to qualify you well for learning pony I think.
<SeanTAllen>
malthe: its a guide. this is for people who already know another language are looking to learn this new languages concepts as quickly as possible without skipping things
<malthe>
and impatient programmer should probably just pick up javascript and live happily.
<polypus74>
doublec: my dream is actually to live on the azores one day
<SeanTAllen>
does anyone have an OSX mavericks install?
<malthe>
SeanTAllen: oh definitely, but that's not about patience, it's just about being to the point.
<malthe>
ok sure, whatever, it's total bullshit to learn a language in x minutes unless x is a very high number.
<malthe>
just look at the rcaps table, it's like german grammar.
<doublec>
Sure. that's why they say on the site that they are "whirlwind tours" of the languages. I find them useful for getting a feel for a language.
<malthe>
there's such more to disagree on. I think the "quick intro" attitude misses the point which is that programming is not about syntax.
<malthe>
s/more/much
<jemc>
I really find the X in Y minutes series to be tremendously useful in terms of 1) being part of my decision to judge whether I want to spend the significant amount of time it takes to learn a given language or 2) brush up on a language I kinda learned a while ago but am really rusty on
<polypus74>
most books and tuts start with a quick toor, which is fine. it's the hook. it just needs to be followed by some meat
<malthe>
I think pony's docs could have more personality like that and say hey this is how you're supposed to think about it.
<malthe>
this is how you write good software.
<SeanTAllen>
personal voice of that sort is going to get lost in something like the tutorial because of # of contributors. a book/series of blog posts from someone like doublec or perhaps you would be much more likely to achieve that
runehog has joined #ponylang
dynarr has joined #ponylang
<malthe>
SeanTAllen: -re- mavericks, I think it needs gcc 4.8 installed
<malthe>
e.g. $ brew tap homebrew/versions; brew install --enable-cxx gcc48
Matthias247 has joined #ponylang
Matthias247 has quit [Read error: Connection reset by peer]