00:58 <autodidaddict> Hmm.. I think I might be able to accomplish this by doing something like let promise = Promise[String] promise.next[None](collector.~collect()) where collector is an actor holding an array of strings, every time collect gets called it adds to the list of strings. When I'm done, I can tell collector send its collection somewhere

00:59 <autodidaddict> I feel like there's got to be a simpler way to achieve this pattern

01:55 <SeanTAllen> SimonJF: that's already been updated but the documentation only gets updated there on release. If you check the source, you'll see its been updated. Thanks for noticing though. In general, YES! to PRs. For documentation that is the ponyc repo. The documentation is generated from the docstrings in the source in packages. Also welcome SimonJF.

01:57 <SeanTAllen> autodidaddict: I don't have a good pattern for you. sorry. I haven't needed to work out anything for that. If you come up with something good, can I suggest doing a new entry in patterns.ponylang.org ?

13:18 <SeanTAllen> A new "Last Week in Pony" is out: https://www.ponylang.org/blog/2017/07/last-week-in-pony---july-23-2017/

15:04 <SeanTAllen> Are you cross compiling Pony? We have a sorry lack of documentation on that front. If you could assist in putting some together, let me know.

15:40 <SimonJF> SeanTAllen: thanks very much! :)

19:45 <cquinn> @SeanTAllen related to doc, I plan on chipping in there a bit. One question I had was around the voice used in method comments. In Java, method commends are in a descriptive (3rd person) voice vs a prescriptive (2nd person) voice. http://www.oracle.com/technetwork/articles/java/index-137868.html

19:46 <cquinn> Pony seems to be a bit of a mix. Should we choose a style and follow that when cleaning up and fleshing out the pony doc?

19:55 <cquinn> OK, unrelated question: Is it possible to execute a subprocess in Pony and block for the resulting streams and return code? I saw that @jemc spawns git using @system in pony-stable, but I need more control over env and capturing stdout. I could use the process package, but then I'll have to restructure my logic to be actors and state machines all the way down... any other ideas?

19:58 <jemc> > execute a subprocess in Pony and block

19:59 <jemc> cquinn: the "and block" part is something you're not going to find in an idiomatic pony package

19:59 <cquinn> ha, ok, that's what I've been looking for.

20:00 <jemc> blocking is an anti-pattern in pony

20:00 <jemc> I'd really suggest doing the refactoring to allow the response to arrive asynchronously

20:00 <cquinn> Yeah, true. But for cli tools it is very convenient.

20:01 <cquinn> I am trying to decide whether to hack in a blocking exec wrapper, or rethink my logic to be async.

20:01 <jemc> I'm not sure what's driving your notion that "state machines all the way down" would become a requirement if you did the async route

20:02 <jemc> if you want to talk about specifics, I'd be happy to help you brainstorm

20:03 <cquinn> well, for example, I'd like to port over a VCS library from Golang that is used by Glide to manage retrieving Go packages from repos like git and hg.

20:03 <cquinn> That library is here: https://github.com/Masterminds/vcs

20:04 <cquinn> so, for example, it makes sync calls to git to find out things about the repo and then operates on the things returned in stdout.

20:06 <cquinn> It seems to me that an object like that would need to be an actor to receive the result of the git call async. And then it would have to be a state machine in effect to perform multiple operations in sequence.

20:06 <cquinn> Or, use something like Promises.

20:06 <jemc> without talking about specific situations it's hard to be sure what the best pattern to suggest is, but I suspect that all of those synchronous return values could be refactored to deal in callbacks and/or promises

20:06 <jemc> yeah, why not promises? :)

20:06 <jemc> they should become a great deal less verbose / cumbersome once this RFC lands: https://github.com/ponylang/rfcs/pull/96

20:08 <cquinn> oh, yes. I like that RFC. You're right that Promises are probably the right way to do this. I'll look at them some more and get my head around them.

20:20 <SeanTAllen> cquinn: i'm not sure i understand your doc question. is there context that i'm missing?

20:21 <SeanTAllen> i think you are responding to my cross compiling question but that isnt method docs so i'm slightly at a loss to interpret your question.

20:21 <cquinn> just context in my head :). That response just reminded me that I wanted to ask this question

20:21 <cquinn> Let me find an example.

20:22 <cquinn> OK, like Array.create: """Create an array with zero elements, but space for len elements."""

20:23 <cquinn> But a descriptive approach would say "Creates an array..."

20:24 <cquinn> in the cli package I used a descriptive voice. Like """Adds an additional child command to this parent command."""

20:25 <SeanTAllen> Given our lack of documentation overall, I'm happy for new documentation that is clear and helpful regardless of voice

20:25 <SeanTAllen> Voice is not something that is a concern to me right now

20:25 <cquinn> OK, sure. If I add doc I'll tend to do it with a descriptive voice, and might "fix" other doc in the same source to match.

20:26 <SeanTAllen> I'm not a fan of "fixing"

20:26 <SeanTAllen> If we want to have a discussion on voice, we can do that

20:26 <SeanTAllen> but it should be a discussion

20:26 <SeanTAllen> there is no "fix"

20:26 <SeanTAllen> going through and making tons of voice changes without a discussion is bad form imo

20:27 <SeanTAllen> unless its some large percentage in one voice compared to another

20:27 <cquinn> sure, I agree. So I would like to bring it up to have the conversation at some point.

20:27 <SeanTAllen> if you want to bring it up, you can

20:27 <cquinn> I guess I'll then match the voice already used in each file.

20:27 <cquinn> in the mean time that is

20:27 <cquinn> ok

20:27 <SeanTAllen> personally i'd rather see the effort go to adding missing documentation

20:27 <SeanTAllen> i think matching voice is reasonable

20:28 <SeanTAllen> if there's a dominant voice, we should certainly use it

20:28 <SeanTAllen> i dont believe there is at the moment

20:28 <cquinn> True. I was just thinking that having a guideline would make it easier to contribute.

20:28 <SeanTAllen> sadly i dont think that is keeping people from contributing docs

20:28 <SeanTAllen> i wish it was

20:29 <SeanTAllen> and we could fix that and people would start contributing documentation

20:29 <SeanTAllen> ive spent over a year trying to get folks to want to contribute docs and other less "sexy" stuff and made very little progress

20:30 <SeanTAllen> this could be because im a bad messenger or a general problem with getting folks to want to work on documentation or both

20:30 <jemc> cquinn: for whatever it's worth, I don't prefer "the descriptive voice" you're mentioning - I prefer "Create an array" over "Creates an array"

20:30 <SeanTAllen> descriptive voice is verboten in the greenspace!

20:31 <cquinn> greenspace?

20:31 <jemc> it's the pony sync call joke name for my homestead here in washington - a play on the term "whitespace"

20:35 <cquinn> ha, ok :)

20:37 <cquinn> I don't have a string opinion, but I do like consistency. The prescriptive voice reads well in the comments inline with the code, but I think descriptive reads better in the generated doc. More user-focused.

20:38 <cquinn> I guess it is quite easy to clean up the voice later if we end up with a lot of doc without a consistent voice. I will not stress about it for now :)

20:39 <jemc> > More user-focused.

20:39 <jemc> see I was just thinking that the other voice was more user-focused :D

20:40 <jemc> it finishes the sentence "call this method when you (as a user) want to..."

20:40 <cquinn> Q:"what does this function do?" A:"It creates a foo and returns the result"

20:40 <cquinn> ah, but I see your point

20:40 <jemc> yeah, so for this other voice, the question is "what do *you* want to do?"

20:41 <jemc> it's definitely a small point :)

20:41 <cquinn> I could get behind that too :)

20:42 <SeanTAllen> i hope the greenspace is neither than it is here in brooklyn jemc. its another disgusting summer in nyc.

20:43 <cquinn> It's in the mid 80's here in silicon valley. but not humid at least.

23:00 <cquinn> How does one set the working dir when running a process under ProcessMonitor?

23:33 <cquinn> Hm. It seems like ProcessMonitor._child() would have to call @chdir() before @execve()