00:15 <jemc> emilbayes: my general naming strategy for github/bitbucket repo names is ${language}-${project}

00:16 <jemc> so you could see my pony repos by going to https://github.com/jemc?tab=repositories and starting to type `pony-` in the find box

00:17 <jemc> a word of warning, though, that some of them are a bit out of date with respect to ponyc master syntax and APIs, as I don't always get a chance to update them regularly

00:18 <jemc> emilbayes: some people use the `-pony` suffix for repo names - for example, aturley does: https://github.com/aturley?tab=repositories

00:35 <emilbayes> jemc: Thanks! Will have a look at both :)

00:41 <doublec> emilbayes: I have a couple too https://github.com/search?utf8=%E2%9C%93&q=user%3Adoublec+pony&type=Repositories&ref=searchresults

01:04 <emilbayes> jemc: I see that you're a member of the zmq group. Did you contribute to zmq?

01:04 <emilbayes> s/group/org/

05:31 <jemc> emilbayes: yes, although I contributed mainly to czmq, zproto, and zproject

05:31 <jemc> (which are specific projects in the zeromq org)

05:32 <emilbayes> jemc: Cool! I'm reading the zmq book atm! :)

05:33 <jemc> awesome!

05:33 <jemc> actually, I would say that my work with czmq probably did the most for preparing me to be in the right mindset to approach pony

05:34 <emilbayes> jemc: I see a lot of patterns too, though I have a bit of erlang and lots of node.js experience

05:34 <emilbayes> jemc: Do you know anything about the distributed pony project mentioned in one of the talks on the ponylang page?

05:34 <jemc> the czmq library and programs that use it have a very actor- and object-oriented feel to them, and they share information by message passing over zeromq inproc sockets

05:35 <jemc> emilbayes: I haven't been much involved with the distributed pony work, though I can tell you that the implementation is still ongoing

05:36 <emilbayes> jemc: Is it part of ponyc? I couldn't seem to find it anywhere

05:38 <jemc> it's being developed separately, though it will be merged into the ponyc repo when ready - I think the idea is to avoid having something half-baked out there in the main repo, giving people a false impression that it's ready

05:38 <emilbayes> arr ok, so it's done in private somewhere?

05:40 <jemc> some bits and pieces of related work have been merged in, though, when they make sense and can stand alone (like preliminary (de)serialisation of objects between distinct runtimes)

05:41 <jemc> right, yeah, it's being worked on in private and I don't have access to it either ;)

05:42 <emilbayes> No worries! That's one thing I'm eager to see how is being solved, whether it will be explicit such as zmq or implicit as in erlang

05:43 <jemc> yeah, I'm interested to see the details too

05:50 <jemc> I think it will largely be implicit/transparent, but there will have to be some visible aspects - for example, if you want to be able to read and write a local file that exists only on one of the distributed machines, you'd want some way to "pin" that actor to that machine

05:51 <jemc> and other analogus examples, like persistent socket connections, where the actor has to stay with the open file descriptor

05:53 <doublec> yeah it'll be interesting to see how they handle such things

05:54 <doublec> I've used the distributed features of Oz and I'm looking forward to seeing how Pony will work

12:42 <Guest23179> Hi

20:09 <gsteed> stupid question: why do recover blocks have a capability on them (e.g. recover val or recover iso^)?

20:29 <jemc> gsteed: as I understand, the main purpose of using the optional cap on the recover blocks is to make sure the type on the left-hand-side is inferred from the block

20:30 <jemc> inferred correctly, that is

20:31 <jemc> because `let x = recover val MyTypeName(...) end` is more succinct and less repetitous than `let x: MyTypeName val = recover MyTypeName(...) end`

20:48 <gsteed> makes sense, that was the only thing i could think of and just wondered if it was anything more than that :)