08:49 <SeanTAllen> @Praetonus do you have a simple reproduction case for the String.reserve bug?

09:00 <Praetonus> SeanTAllen: Yes, https://gist.github.com/Praetonus/0da89a246eaa75dbd2c8393425523848

09:01 <Praetonus> This will eventually segfault in the loop from accessing random memory

09:01 <Praetonus> Also the same bug exists for String.create

09:10 <SeanTAllen> Can you open an issue for that praetonus and i'll take a shot at it while i am polyconf'ing today (although i might not get through it before i start vacation).

09:11 <SeanTAllen> Pony 0.15.0 has been released. Upgrading as soon as possible is recommended: https://www.ponylang.org/blog/2017/07/0.15.0-released/

09:11 <Praetonus> SeanTAllen: Will do

09:15 <SeanTAllen> thanks

09:30 <SeanTAllen> i spent the last 3 hours working on release notes and 0.15.0 release. there was a lot to cover.

18:09 <tj800x> I'm working on an article, possibly a book about learning pony. I'd like to share an analogy and get some feedback.

18:09 <tj800x> What is is central, and so-far unique, to the Pony programming language is the idea that it provides a way to write highly concurrent programs without requiring the programmer to manage locking critical resources like shared memory. Whenever two independent threads access the same shared mutable memory there is a danger that update-timing might conflict with read-timing, resulting in one or both threads having invalid data. The stan

18:10 <tj800x> he standard solution to this problem is to have locking mechanisms that only allow reading of data when no updating is occurring, and to only allow writing of data when no reads are occuring. Pony's solution is to structure the language in such a way as to allow the compiler to detect and enforce the two basic rules.

18:10 <tj800x> The Two Basic Rules of Concurrency

18:11 <tj800x> 1. When reading shared memory, no other thread must be allowed to read or write to that shared memory.

18:11 <tj800x> 2. When writing to shared memory, no other thread may read from that shared memory.

18:11 <tj800x> ## Six Memory Access Mechanisms Pony adheres to these two rules through the use of six different mechanisms to access memory. Those mechanisms are isolated memory access, transition memory access, reference memory access, immutable memory access, opaque memory access, and box memory access.

18:11 <tj800x> Since Pony's way of managing shared memory is so new and unique it is often hard to imagine how this might work, especially at compile-time.

18:12 <tj800x> ## A Dancing Analogy Modern Western Square Dancing is a form of dance involving multiple partners where the dancers move through time and space and interactive in predetermined ways.

18:13 <tj800x> Much like the way square dancers follow a series of steps as to avoid running into each other, the Pony compiler uses the Six Memory Access Mechanisms to ensure that data collisions access collisions do not take place.

18:13 <tj800x> The difference is that instead of physical space, potential conflicts exist in memory space. Individual actors, operating separately are capable of of managing memory without conflicts.

18:13 <tj800x> An immutable memory read could be thought of as viewing a tile on the floor. Multiple dancers (actors) can examine the state without conflict.

18:13 <tj800x> An isolated memory read can be thought of as stepping onto a particular tile. Only one actor may perform this action at a time and once the actor steps onto the tile "they own it" until they decide to release the exclusive access to that tile.

18:14 <tj800x> Reference memory access is like two dancing partners surrounding a tile. These dancing partners are akin to multiple memory aliases withing the same actor.

18:15 <tj800x> These aliases, because they are part of a dance partnership ("An actor") are capable of coordinated activity.

18:16 <tj800x> The analogy can be extended in that the dance partners allow others to "look around their feet" to determine the status of the tile ("memory")

18:18 <tj800x> Opaque memory access is the equivalent of calling out the coordinates of the tile within the dance floor. It is information that can be freely shared among dancers (actors) without actually revealing any information about the tile's content.

18:19 <tj800x> I'm not sure how to describe transitive memory access.

18:19 <tj800x> Thoughts?

18:19 <cquinn> I think you have #1 and #2 mixed up a bit. I'd say it: 1. When writing shared memory, all other threads must be prevented from reading or writing to that memory. 2. When reading from shared memory, all other threads must be prevented from writing to that memory.

18:20 <tj800x> Ahhh...yes. I need to go back and fix that.

18:21 <tj800x> Oh and I skipped box. I've got to figure that one out too.

18:22 <cquinn> the dancing analogy is interesting. But I don't see how you can describe multiple references within one actor vs across actors.

18:22 <tj800x> I was thinking aliases are dance partners.

18:22 <cquinn> but coming up with a good analogy will be a big win

18:24 <tj800x> I'm no dancer myself, but my understanding is that dance partners work together. Within a single actor my understanding is that aliases are coordinated and that is why two refs aliases can read and write to the memory space.

18:25 <tj800x> All analogies break down of course, but I'm trying to take something concepts that I found absolutely foreign and make them a bit more accessible.

18:26 <tj800x> I've used this analogy to my non-techie family to explain how Pony is different than traditional programming...which I have described as more of a mosh pit.

18:27 <tj800x> That is probably not giving traditional lock-based programming its full due, but the idea of 1000 people crashing around in a mosh pit versus a 1000 people doing fancy square dancing makes an impact.

18:30 <tj800x> I will pull all this together and send it out on the mailing list. That is probably a better forum.

21:15 <SeanTAllen> tj800x: "When writing to shared memory, no other thread may read from that shared memory." <-- you dont want 2 threads writing to the same memory either

21:15 <SeanTAllen> ah i see you already covered that with cquinn

22:18 <mikeyhew> Are there docs for the standard library somewhere?

22:18 <mikeyhew> never mind, I found them

22:18 <mikeyhew> https://stdlib.ponylang.org/

22:19 <SeanTAllen> they are automatically extracted from the source mikeyhew, so you can also view the src in packages/ as well for all docs. there's an open bug at the moment for constructor doc strings not appearing in the generated documentation.

22:21 <mikeyhew> Thanks Sean

22:34 <mikeyhew> Is the #read syntax that is used here documented somewhere? https://github.com/ponylang/ponyc/blob/07763fa168439217adadf00f0f939bf4488af165/packages/builtin/compare.pony#L22

23:05 <mikeyhew> I found it: https://tutorial.ponylang.org/generics/generic-constraints.html

23:58 <autodidaddict> quick question.. if I'm maintaining an array of TCPConnection tags of clients connected to my server ... when I get the closed() notification for a given TCPConnection, how do I figure out _which_ TCP connection to remove from my array?

23:59 <autodidaddict> is there a UUID on the connection, or does the actor by virtue of being a tag automatically have uniqueness where I can do an equality check?