03:40 <Scramblejams> Is there some minimum emacs version required for flycheck-pony? I'm on emacs 24.5.1, flycheck-20160519.303 and installed flycheck-pony-20160501.1417, but when I add (use-package flycheck-pony) to my .emacs, it very uninformatively barfs on startup. (It gives me the welcome screen.)

03:46 <Scramblejams> Ah, turned out I had two problems: I hadn't installed use-package, and I hadn't added (package-initialize) to the top of my .emacs file.

08:09 <Applejack_> Hi, so I'm still trying to write a generic timeit function that could take any function of any argument(s) and benchmark it, in a similar way to Julia @timeit macro. Since we don't have macros in Pony, is it possible to do that with generics ?

08:10 <doublec> Applejack_: you should be able to have a fun attached to a primitive that does what you want, where it takes a lambda to run and times that.

08:10 <doublec> Applejack_: Problematic in terms of actors though

08:10 <doublec> Applejack_: sync they're async and won't complete during the run

08:54 <Applejack_> doublec: ok, but I had the vague impression that I would have to specify the lambda's type and that would mean limiting the possible functions I could time with regards to number of arguments, type, etc.

08:57 <doublec> Applejack_: I would imagine a lambda that takes no arguments and returns nothing. Within that the provider of the lambda calls whatever with whatever arguments.

08:57 <sylvanc> applejack: or use partial application to reduce the function to no arguments

08:58 <sylvanc> doublec's approach has the benefit of standardising the return type to None

09:01 <Applejack_> doublec: sylvanc: hmm I kind of see what you mean, will try now

10:13 <Applejack_> I have a problem: when I pass my {()} lambda to my timeit(f:{()}), then the loop inside the timeit calls f but apparently because it does nothing it gets optimized away and basically takes zero time. I think this is what happens because if I replace the f() inside the loop with the corresponding real computation, then it takes nonzero time.

10:15 <Applejack_> If I do a side effect print inside the lambda then it works, but then I time the print

10:23 <Applejack_> I managed to make it work by having the lambda modify a captured variable, but is that good ?

10:25 <sylvanc> then you are timing modifying a variable

10:25 <sylvanc> this is the nature of performance testing an optimising compiler

10:26 <sylvanc> if your function does nothing, and the compiler optimises it away, and your test shows it takes no time...

10:26 <sylvanc> ...isn't that correct?

10:26 <sylvanc> since you want to measure the actual speed, post-compilation

10:26 <sylvanc> it's actually a super important compiler optimisation

10:26 <sylvanc> (some languages have a lot of trouble with that kind of optimisation)

10:42 <Applejack_> sylvanc: I meant that my function, which is fib(20), does something but is passed inside a lambda which is {()} so I thought the compiler would just ignore fib(20) inside timeit and detect that because it has no side effect, and doesn't change anything, well, let's just ignore it

10:44 <Applejack_> but if I force the computation by capturing a variable inside the lambda so that I put the result of the computation fib(20) inside it, then it works

10:46 <Applejack_> I agree that my workaround adds to the time of fib(20) the time of modifying a variable, but if I don't modify anything then because I get zero time I imagine the compiler just ignores my fib(20)

10:48 <Applejack_> I guess I should send a piece of code instead of piling up words

13:29 <malthe> sylvanc: ever considered 'is not' instead of 'isnt' - ?

13:44 <Applejack_> doublec: sylvanc: so here's my code that succeeds in timing the fibonacci, but requires modifying a captured variable, otherwise the compiler (I guess) just ignores my loop since it doesn't "do" anything: https://gist.github.com/anonymous/20644f5c866238f9b7f89cedc53e7d4b

13:51 <shepheb> got the HTTP overhaul working. I think I found an existing bug in the HTTP server code, in passing.

13:52 <shepheb> closing the sockets too early in some cases.

13:52 <shepheb> or maybe something else is going on, not sure.

13:58 <Praetonus> Applejack_: I don't really see the problem here. The compiler is free to optimize out any computation with no observable side-effects. Here, the Fibonacci is "hidden" behind your lambdas and the compiler doesn't try to prove that there are no side-effects here (even though it could, in theory), so the computation isn't optimized out. If you call the function directly, the proof is trivial and the call is eliminated

14:08 <Applejack_> Praetonus: I don't see any problem with what the compiler does either (I actually find this elimination cool) I would just like to know how I may just time the fib and not the fact that it changes the captured variable.

14:08 <Applejack_> I mean dont add the variable modification time to the fib timing

14:09 <Applejack_> It's probably relative-wise negligeable, I know, but is there a way to force the computation ?

14:10 <Applejack_> (and thus not have to add the variable change time)

14:10 <Applejack_> I'm trying to emulate Julia's @timeit macro that takes a computation (and some descriptive string) as argument

14:14 <Praetonus> I don't think it is possible right now. Maybe we need a set of "leave my code alone" constructs for the optimizer. Things like that are possible in C with asm volatile blocks. I'll probably make an RFC about this

14:19 <Applejack_> Ok, so would you consider this as a reasonable implementation "time an arbitrary function to which is passed (a) specific argument(s) by running it multiple times in a loop" ?

14:20 <Applejack_> (doublec suggested the lambda approach to me earlier here)

14:20 <Applejack_> (sylvanc suggested something else based on partial applicationwhich I haven't tried to understand yet)

14:25 <jemc> Applejack_: you could use a type parameter to specify the return value type of your lambda, then return that result value from the outer function

14:26 <jemc> for example, `let result: U64 = time_it[U64](my_lambda_that_returns_a_u64)`

14:28 <jemc> then you can be sure that you are "observing" the outcome of the computation so it won't be optimized out, but you're not jumping through any hoops in your lambda to keep it as a side effect

14:29 <jemc> this also has the benefit that you can drop the time_it function inline in a large computation to measure just part of it but let the other parts use the result of the measured part

14:31 <jemc> as doublec mentioned though, this construct won't work for measuring async computations - for those you'd need another strategy, like finishing the timing when a promise is fulfilled, for example

14:35 <Praetonus> Applejack_: Actually I'm thinking about really low level constructs like the ones described here: https://youtu.be/nXaxk27zwlk?t=40m40s LLVM support seems really straightforward so it will be easy to add to Pony as functions

14:39 <shepheb> seems like this HTTP server hack is working.

14:40 <shepheb> jemc: is the RFC process written down anywhere? and should I start with the JSON library or the HTTP overhaul? the latter is a breaking change.

14:40 <jemc> shepheb: it sure is, check out the ponylang/rfcs repo on github

14:40 <shepheb> both are ready to go, except for the optional-but-probably-good port of the existing JSON API on top of the new streaming parser.

14:41 <jemc> regarding which one to start with, seems like you could have them go through the process concurrently, unless one depends on the other (it seems like they don't)

14:42 <shepheb> no, they're unrelated. I meant from a manpower point of view - which one is more likely to be serve as a good shakedown for me writing RFCs and the community reviewing them.

14:42 <shepheb> I think the non-breaking nature of the JSON one might make it the best to start with.

14:43 <jemc> I think the JSON one might get more community feedback, so might be a good one to test out the process

14:43 <jemc> given that more people have had direct pain points with JSON

14:47 <shepheb> alright, will do.

14:53 <shepheb> I'm going to proceed thus: (1) fork ponyc (2) add the new API as the json/stream package (3) port the existing JSON parsing code to use the streaming API (4) test vigorously (5) push to my fork (6) write up an RFC (7) send the RFC PR.

14:53 <shepheb> so it'll be a while, I guess.

14:54 <shepheb> I won't send a PR for the ponyc changes until the RFC is active.

14:55 <jemc> FYI, in general the RFC process is sort of intended to go the other way around - suggest your design, get feedback, *then* do the work of implementing and polishing it - the idea is to prevent people from getting really invested in an implementation before there is community support for the design

14:55 <jemc> though I realize its often important to implement a bit of it to test feasibility, tec

14:55 <jemc> *etc

14:58 <shepheb> that's more or less what I have done.

14:59 <shepheb> the first design here definitely didn't work.

14:59 <jemc> yeah, I know that you've done a lot of playing with different ideas, testing performance, etc, and I think that's great

14:59 <shepheb> and since actually achieving solid performance here influences the design, I had to test it for real.

14:59 <jemc> definitely will make for a better RFC

15:00 <shepheb> I watch people at work making decisions on behalf of other developers, with almost no experience of how those developers actually work.

15:00 <shepheb> it's a frustrating position to be in. I'm not going to decide what I think the right design is without battle testing it to some extent.

15:01 <shepheb> that's more of a personal bias, though.

15:04 <shepheb> I'm not going to be upset if the decision on the RFC is to not merge it, or to overhaul the design. so long as the performance goal is achieved in the end, I'll be happy

15:04 <shepheb> if it doesn't get merged, I can toss it up on Github as a third-party package and use it in my project, no problem.

15:04 <shepheb> but I doubt that will actually happen.

15:18 <malthe> shepheb: fwiw i'm looking into rewriting the http server

15:19 <malthe> there are some architectural problems with the existing code and it would be good to leverage some of the knowledge out there on high-performance implementations, i.e. as demonstrated by lwan for instance.

15:19 <malthe> https://lwan.ws/

15:39 <shepheb> malthe: I've got a port of the existing code to fix a bad API pain point for me.

15:40 <shepheb> it mostly works the same way as before, but now a handler gets a Request val and Response iso. it can resp.add_chunk and then (consume resp).send(), as an example.

15:40 <shepheb> but I haven't made its performance any better or whatever.

15:41 <shepheb> I'm interested in any improvements to the API.

15:55 <SeanTAllen> Pony stickers now available via Stickermule: https://www.stickermule.com/marketplace/12903-main and https://www.stickermule.com/marketplace/12904-pony-logo

16:01 <darach> Nice!

19:22 <SeanTAllen> Pony Virtual Users' Group meetup #2 starts in a little over 5 minutes => https://zoom.us/j/705615780