01:08 <SeanTAllen> was there not one kulibali? that would explain the lack of GH activity emails. work has been very busy for me lately and i havent been able to attend.

01:09 <kulibali> theo and i hung around for a while, but no one else showed up

01:17 <TwoNotes> Package level doc strings look like just the thing for http. What happens if more than one file in the package has them?

12:43 <zevlg> hey guys! I'm very new to pony .. I'm quite astonished that there is no Exception type to dispatch on in order to find out what was going wrong inside try

12:44 <zevlg> is there any ways to do this? maybe write exception-less code ?

14:24 <Candle> zevlg: The pattern is to make only one thing raise for only one reason. If there are multiple possible, then passing in an error handling interface (see the TCP Listeners) is the way to go.

14:28 <zevlg> that makes sense, however I'm looking into json_doc.pony right now and it has some workarounds: storing error state inside object before rising error - it might work for me that way

15:38 <TwoNotes> I continue to work out details for the HTTP streaming RFC

17:40 <SeanTAllen> if you can have more than 1 type of error zevlg then using a union type that indicates the error makes sense

17:40 <SeanTAllen> type MyResult is (Success | Failure)

17:40 <SeanTAllen> type Failure is (Reason1 | Reason2 | Reason3)

17:42 <zevlg> yes, but in this case you have to handle errors every time you call stuff, you can't just jump-out to some error handler as with raising exception

17:43 <zevlg> you are talking about exception-less style, it does work of course .. but kind of boilerplates the code

17:43 <SeanTAllen> you get some boilerplate in return for more safety. exception have lots of terrifying edge cases that arent so edge.

17:44 <SeanTAllen> jemc: i'm using something that looks like the access pattern and i've run into a testing issue of getting a ref to the enclosing actor for testing without spinning up that actor (that might in turn have a ton of other dependencies), have you found a good way to address that?

17:45 <Praetonus> I've been thinking about an extension to the exception system that would allow programmers to emulate a dynamic exception system (as in C++ or Java) while keeping the safety and (relative) speed of the current system in the default cases where you're not interested in the type of the exception

17:46 <Praetonus> I'll have to make a RFC about that

17:46 <SeanTAllen> jemc: in particular, we arent taking in a lambda, its an actor handing this to another class that needs to be setup for testing

17:47 <SeanTAllen> hmmm actually i see a way to do this

17:49 <SeanTAllen> its just really painful

17:55 <jemc> SeanTAllen: you could also use a modified form of the access pattern which passes a ref to an interface type instead of a ref to the concrete actor type

17:56 <jemc> with the actor being a subtype of that interface

17:56 <jemc> then you could also have a test fixture class that also fulfills the interface

18:05 <SeanTAllen> yeah that is what I had

18:05 <SeanTAllen> and the last step is what I am doing

18:05 <SeanTAllen> i wanted to be able to test the logic without spinning up the actor but thats not possible

18:06 <SeanTAllen> thanks for confirmation on my current strategy though

18:19 <SeanTAllen> jemc: and then john mumm swooped in with a better solution

18:26 <SeanTAllen> jemc: stubbed it out with a class that can be a ref using fun tag for the behaviors... https://gist.github.com/SeanTAllen/4f66cad5d37e1d2e0a1511d46b6cbee9

18:42 <jemc> ah yes, I forgot that `fun tag` can mock `be`

18:50 <SeanTAllen> me too

21:29 <SeanTAllen> jemc: do you have any idea what the perf it is in terms of lost performance calling through an interface instead of directly on a class? i've seen some optimization that Benoit did that only apply when not going through an interface but didn't pay much attention to them at the time.

21:33 <jemc> I haven't done work in Pony that is as deeply perf critical as yours, so I can't really quantify the magnitude of the effect for you, but I can suggest an approach that should completely avoid the overhead while retaining that flexibility for testing

21:33 <jemc> that is, make the accessed type be a type parameter *constrained by* the interface instead of making it literally the interfacre

21:33 <jemc> for example

21:34 <jemc> `be access[T: MyInterface ref = MyConcreteActor](fn: {(T)} val) =>`

21:35 <jemc> so by default there is no interface overhead, as the concrete actor type is used when you don't pass a type parameter

21:36 <jemc> or rather:

21:36 <jemc> `be access[T: MyInterface ref = MyConcreteActor ref](fn: {(T)} val) =>`

21:37 <jemc> in your tests would be the only type you pass an explicit type argument - for example: `mock.access[MyMocktype]({(m: MyMockType) => ... })`

21:38 <jemc> you could leave out the default if that creates problems for you, but then you also have to include the type argument in your production code:

21:38 <jemc> `be access[T: MyInterface ref](fn: {(T)} val) =>`

22:04 <SeanTAllen> huh

22:06 <jemc> if you use a type parameter you can specify the concrete type as the type used in compilation, so that the overhead of the interface can be avoided at runtime - the interface is only used as a constraint at compile time

22:12 <SeanTAllen> when my brain isnt melted, i'm going to have to go back and read this more and understand it

22:12 <SeanTAllen> thanks jemc

22:13 <SeanTAllen> unrelated but I found a way to get `fun tag` to segfault

22:13 <SeanTAllen> which might work in general

22:13 <SeanTAllen> im going to have to dig into it ore

22:13 <SeanTAllen> im going to have to dig into it more

23:50 <PonyLover> Hai