07:03 <bdari> Hi...

07:03 <bdari> any sample about socket programming for push messaging?

13:30 <SeanTAllen> bdari: i'm not sure what you mean by "push messaging".

19:10 <hobomatic> @SeanTAllen: on the 8th I wrote something here about there being no string() on Array[], and no good way of puting a constraint on a type parameter for some rank2 time, like Array[A]. And your response was that "thats because an array might not be stringable". My 4 day later response is: yes, but if you constrained the type variable, like in Arrayt[Stringable], that could not happen. My expectation was that the method would only exist for

19:10 <hobomatic> Array[Stringable], since there would be a constraint on the reciever.

19:11 <hobomatic> the expectation is coming from prior experience with languages with both generics, and methods where the reciever is an explicit parameter

19:12 <SeanTAllen> Pony currently has no way expressing that one a class. You can use a fun on a primitive that takes an Array[Stringable]

19:13 <SeanTAllen> if you would interested, you could open an RFC about syntax for how to add to classes directly

19:13 <hobomatic> yeah, I will probably do that, I just wanted to make sure the idea that lead to the expectation was understood

19:13 <hobomatic> Ok

19:13 <SeanTAllen> Yup. got it.

19:33 <Praetonus> hobomatic: FYI, a part of this is covered by the `iftype` feature, which isn't fully implemented as of now. Here's the associated RFC: https://github.com/ponylang/rfcs/blob/master/text/0026-subtype-checking.md

19:38 <SeanTAllen> I'd forgotten that existed Praetonus

19:41 <hobomatic> yes, specialization was another usecase that was rattling around in my head

19:42 <hobomatic> that seems like a much more interesting way of doing it than I was thinking of.

20:00 <hobomatic> yeah I am starting to sweat just thinking of all of the ambiguity between case functions, iftype and ... what looks like its trying to be dependently typed pattern guards?

20:02 <hobomatic> well, dependently typed guards.. for case functions

20:43 <endformationage> I think I may've found a clue to my strange array behavior. Perhaps it has something to do with how constructors work? Please take a look here:

20:43 <endformationage> https://gist.github.com/patternspandemic/a0f4f3d13881b368729f5470d8917b92#file-system-pony-L13

20:44 <endformationage> See also lldb sessions included in the gist. (Gist made them appear out of order :\)

20:55 <SeanTAllen> sounds like something is stepping on memory

20:58 <SeanTAllen> endformationage: does it seem like something else is getting allocated into the same location as your array?

20:58 <endformationage> I've not been able to reproduce outside my codebase.

20:59 <SeanTAllen> ok

20:59 <SeanTAllen> but

21:00 <SeanTAllen> does it seem like that is what is going on?

21:02 <endformationage> Hmm, I suppose. I guess I don't have the knowledge to know/find out if this is the case.

21:04 <endformationage> If I simply avoid pre-allocating the array in the map in the constructor, it seems to work OK.

21:05 <endformationage> I'll try moving the pre-allocation to the very end of the constructor.

21:07 <endformationage> BTW, the pre-allocation in the actual code base can be found here: https://github.com/patternspandemic/pony-kore/blob/master/kore/system.pony#L147

21:08 <SeanTAllen> so

21:08 <SeanTAllen> moving the allocation would put it in a different memory location