<adam_>
So much timer weirdness on my system. Set slop to 100 in the example code, and no output timer event firing after 30 minutes of running. 100 should be 100us, yes? Really don't get this.
jemc has joined #ponylang
<SeanTAllen>
adam_: no.
<SeanTAllen>
```
<SeanTAllen>
Create a timer handler with the specified number of slop bits. No slop bits
<SeanTAllen>
resolution.
<SeanTAllen>
microsecond resolution, 20 slop bits is approximately millisecond
<SeanTAllen>
means trying for nanosecond resolution. 10 slop bits is approximately
<SeanTAllen>
So the default as it stands is millisecond resolution at 20 slop bits
<SeanTAllen>
0 would be nanosecond
<SeanTAllen>
100 is really damn long
<SeanTAllen>
so that's not timer weirdness on your system
<SeanTAllen>
the important part to understanding slop is this line in _next() from timers.pony
<jemc>
yeah, I'm not terribly familiar with the slop implementation, but "slop bits" implies to me that you're controlling the precision of what would otherwise be a 64-bit precision, so setting it to 100 is way beyond the maximum that a 64-bit integer can represent
<SeanTAllen>
next = next << _slop.u64()
<SeanTAllen>
that "next" is is nanoseconds for the next one to fire but then, we shift by the number of slop bits
<SeanTAllen>
before returning number of nanos before firing
<SeanTAllen>
you just getting up or not yet gone to sleep jemc?
<jemc>
SeanTAllen: been up for about half an hour so far ;)
<SeanTAllen>
jemc: i think this is asio related. i would expect that a single timer would have 1 asio event fired per usage but that isnt the case.
<SeanTAllen>
im doing one every second and i get 3 asio events per firing
<SeanTAllen>
hmmm
<SeanTAllen>
although at 30 millis, i get 1 event per so, thats interesting but probably not it
<adam_>
SeanTAllen: thanks. I must remember not to interact with the world before enough coffee.
<jemc>
SeanTAllen, adam_: I wonder if we should consider changing `slop: USize` to `slop: U8` - there's no reason to be `USize` when values greater than 63 are nonsensical
<jemc>
I'll see if that breaks anything
<adam_>
jemc: Certainly doing that would have made me properly read the documentation.
<adam_>
One more annoying question, as I have some real work I should be doing:
<adam_>
If I modify the httpget example to connect to a server that sends a continuous, but irregular stream of data (usually at least one chunk a second), the code usually works, but sometimes stops
<adam_>
The finished and cancelled methods are not called. It just exits.
<adam_>
The python code I have to do the same thing has never demonstrated this behaviour.
<adam_>
Greping the net package doesn't reveal any Timers that could be setting a timeout. Does anyone have an idea where I should start digging on this?
<adam_>
Nevermind. Keep_alive setting in tcp connection looks like what I need to inspect
<adam_>
Still would have expected some notification to the client actor if this is what is causing it.
<adam_>
Which is why I hallucinated the behaviour...
Praetonus has joined #ponylang
abeaumont has quit [Ping timeout: 240 seconds]
joncfoo has joined #ponylang
<SeanTAllen>
@adam_ can you open a bug report for that?
vaninwagen has quit [Ping timeout: 240 seconds]
<adam_>
SeanTAllen: done
amclain has joined #ponylang
abeaumont has joined #ponylang
<SeanTAllen>
thanks adam_. i moved it to the ponyc repo as that's the correct repo for docgeneration stuff.
<SeanTAllen>
we found "the cause" but not the cause of the cause.
Matthias247 has joined #ponylang
endformationage has joined #ponylang
acarrico has joined #ponylang
<acarrico>
Listened to podcast of Sylvan Clebsch's talk on Pony, now looking at tutorial. Fascinating.
<jemc>
acarrico: welcome!
<acarrico>
Just an accident that it came up in my queue, but it is a refreshing reminder not to lose track of typed imperative programming (while focused on typed functional programming). I guess Rust isn't the only thing out there.
<jemc>
sylvanc likes to say that Pony is secretly a functional programming language
<acarrico>
As someone who read the lambda papers a long time ago, I never felt very compelled to read about actors. Pony makes them more compelling.
<acarrico>
Also it is wonderful to just install ponyc and go. No month of learning nix + cabal.
<acarrico>
(though I'm wondering if ponyc is in nix)
<acarrico>
I've got the arch linux version here, no problem with it.
<jemc>
we do sometimes have trouble with the prebuilt binaries from time to time - it can be hard to keep up with various platform-specific packaging issues when our main focus is the language/runtime/libraries
<jemc>
but I'm glad to hear that you had a good experience! :)
<acarrico>
Cool, hence the nix question. I often develop out of Nix, regardless of which "native" package manager is around, then it doesn't matter which OS is on the machine where I checkout my repo.
<acarrico>
The only hitch I've had with that is things like OpenGL drivers.
<jemc>
I'm not aware of a pony presence in Nix, though I've heard talk about it before so I wouldn't be surprised if it was in progress (or already done, and I didn't notice)
<jemc>
we seem to have a lot of arch linux users, so I also wouldn't be surprised if there was an AUR entry for it
<endformationage>
acarrico: I am using Pony on NixOS
<SeanTAllen>
Pony is in Nix. Kamil maintains it I believe.
<acarrico>
Thanks guys. I've been methodically doing all the exercises in the Haskell Programming book, but I think I'll stick a little ponylang on the side too. Anyone working on Wayland bindings or something like that?
<jemc>
acarrico: I don't think anyone has mentioned working on Wayland bindings
vaninwagen has quit [Ping timeout: 240 seconds]
vaninwagen has joined #ponylang
<vaninwagen>
hi, i have some strange behaviour when hammering the httpserver example with lots of 'Connection: close' requests. Memory is growing massively, up to 8Gb on my machine. I am not 100% sure what happens, but my first guess is that tcp-connections don't get unregistered from the server fast enough and pile up
<vaninwagen>
is there a decent way to trace or log gc activity or scheduler activity (what runs where for how long) or some other way to inspect what's going on (besides cluttering the code with logs to stdout)?
<vaninwagen>
maybe profiling?
<vaninwagen>
i am starting the httpserver without a connection limit and call it using ``wrk -t 4 -c 1000 -d30s --timeout 2000 -H 'Connection: close' http://localhost:50000``
<SeanTAllen>
vaninwagen: you can use vtune, instruments etc to profile pony programs
vaninwagen has quit [Ping timeout: 268 seconds]
_andre has quit [Quit: leaving]
Matthias247 has quit [Read error: Connection reset by peer]
joncfoo has quit [Ping timeout: 240 seconds]
<endformationage>
The comment about profiling made me curious to run a profiler on my stalled actor example. Letting it run stalled for a short while gives +98% time spent in sweep_small.