Paul Evans

Hi I'm here. I couldn't see a question about it. It looked like a long list of statements. I'm not sure what to do with these facts.

> I've tried to create a libvterm test out of this, but the testsuite is completely undocumented. Brief 30second summary: * `SHOUTY` things in column 1 are commands to tell...

> How do I scroll up to the first line? How do I scroll down the last line? "scrolling" isn't a concept within libvterm (currently). At the moment, any of...

What sort of input are you looking for? In an ideal world Every Single Terminal would encode as the 0x07 byte (BS), as DEL (0x7f), and as CSI 2~. It...

No. Terminfo files describe the behaviour of a terminal. There isn't "one canonical correct" one any more than there is "one canonical correct" terminal. The TI file should match the...

Here's a screenshot showing how a graph would look when using this function:  This graph was generated by just plotting the raw counter value on the righthand axis to...

@darshanime > can you use something like this? I don't believe so. That would report, at every time in the query range, the total increase over the preceding (in your...

I'm aware of the history in https://github.com/prometheus/prometheus/issues/1335 which covered much of the same ground, except the key difference here is the explicit "since timestamp" parameter, which solves the outstanding design...

@colega > sum_over_time( > increase((up{} unless timestamp(up{}) < 123456)[1m:])[10h:] > ) I'm having some success with this. For short time ranges (e.g. up to a couple of days), I can...

Or maybe, can we allow a `[since TIMESTAMP]` notation instead of a fixed duration? Then we could simply plot e.g.: `increase(weather:rainfall:mm[since 1234567000])` the number being filled in by grafana.