Apropos nothing in particular I did a quick check on the perf of the manifest as CBOR using cbor2 vs json. The file size is about half, but the load time seems to be nearly the same. CBOR seems to write much faster, although seeing the benefit requires me to drop the (unnecessary?) copy of the data structures we are doing when writing (I think this is safe because we drop the dict once it's written and

don't mutate the manifest in the interim)

(this all requires py3, otherwise the CBOR lib is pure python which erases any wins)

TIL about CBOR

Standardized messagepack, huh

I feel company-obliged to mention protobuf :p (I jest!)

Well the advantage of CBOR is it's schemaless so it's a drop-in replacement

well schemaless and a JSON superset in terms of data model

In that it has a data model? :D

But yeah, sounds cool... once we get py3

Certainly I'd expect to do better with one of the N binary formats that requires upfront schemas

Yeah, this was "my real job is fixing a broken docker image so how can I procrastinate" rather than a serious attempt to add the feature

Oof, yeo

*yep

(people were discussing artifact storage and I was thinking about cases where gecko is using JSON because no one thought about it rather than because it's good, and I was taken to try the experiment)

Its ok, I'm just sinking further into the pagination sinkhole. My first attempt at handling the paginated github APIs in wpt.fyi had an off-by-one-error -_-

I swear, I'm an experienced engineer

Who works on testing infrastructure

... I should write more tests.

jgraham: any suggestions for what I can look into next for given servo/servo #27223#issuecomment-656433950 ?

jdm: Hmm, the testss_root of / seems suspicious

jdm: LoadManifest in sync.py doens't seem to be passing in the tests_root

smcgruer_[EST]: Yeah, it wasn't a serious review, just commented since I was looking at it. And I was looking at it because I'm so excited to see that land :)

Sadly I think its not going to be that easy for lint; I suspect the output might be hard to read not wrapped in a code-block in markdown

But hey, I've already found one Taskcluster bug :D

Heh

The stability jobs are nearly producing the right format since they were previously having their output written to a comment; that might be a simpler place to start from that point of view

And probably similar importance too, its what most failing-Chromium exports hit. I foolishly thought lint would be easy :)

Getting good human-readable output is a surprisingly hard problem!

I hope eventually for some of the jobs we can have some process that picks out the log lines that look like errors and just presents those rather than the whole log

Notably for all the pytest stuff; the actual test runnign benefits from something more custom

100%, I think we want to do much better than just dump the logs

But hey, output: web-platform-tests/wpt #24556/checks?check_run_id=858217231

Ooh, that's not too bad

I mean it's too verbose, but not totally unreadable or anything

woohoo!

yet another unplanned power outage (sad)

I was going to push smcgruer's fix to prod

although arguably I should really try a daily run this time...

I'm going to investigate the failures in python unit tests on Azure

yeah I suggest we leave it in staging till epochs/daily runs

They have been training me into force-merging and hence missing real failures

Thanks, I've been hoping to look at those but havent found hte time

You shouldn't need to force-merge for those (but maybe you mean for the chromium sync, which I suppose could be checking for all green, rather than just required green)

Oh you're absolutely right... I was confused yesterday

regardless, training people to ignore errors isn't great

Agreed; it's easy to assume that any azure failure is unimportant when it could also be real breakage on non-Linux

(it's a draft right now as I intend to fix the Azure failures together in this PR)

jgraham: thanks for the tip on the manifest. servo/servo #27230 fixes the issue for me locally, so I'd like your eyes on it.

Urgh, why does the Linux on pixelbook have such old packages -_-

git 2.11.0 ...

That was release in Nov 2016 -_-

Do you also have to fire up the boiler several hours before you build up enough steam for it to boot? :p

Lol

I can't even easily update it, it relies on a bunch more packages at newer versions than the ChromeOS Linux subsystem has

So you'd acutualy be better off if you were running WSL?

smcgruer_[EST]: can you nest a Docker inside Linux in ChromeOS?

... I mean, yes.

`datetime.datetime.strptime(reference, '%Y-%m-%dT%H:%M:%S.%fZ')` throws a KeyError on Windows

KeyError: '_strptime'

presumably from here github.com/python/cpython/blob/3367…974593fbbbe84/Lib/datetime.py#L1944

feel like taking a crazy pill...

hopefully I'm not looking at a bug in python stdlib?

jgraham: I followed your suggestion and did the load+update->load_and_update transformation

Hexcles: pyexcel/pyexcel #180 ?

yeah but that seems very wrong...

I mean `import _strptime`

Another python3 issue: web-platform-tests/wpt #24451

Python 3 reduced the number of maximum headers allowed in http.server to 100

which does not (AFAIK) violate any spec

but we have stress tests in WPT with 256 headers which are now broken in py3

I don't suppose we can just reach in and change the constant?

Total hack, buttttt

We should either change the constant or stop using the stdlib here, that's just not a limitation we can have

How would I use step_wait to test that an event is never fired?

web-platform-tests.org/writing-test…s/testharness-api.html#eventwatcher might work?

I want *zero* events though...

Maybe I'll just go back to step_timeout and someone can correct me on review

Right, at which point the only way the test can verify that is via timeout. Unless there's some other event (or condition) after which you are satisfied that the event could definitely not happen.

But otherwise, what happens if the browser fires your bad event 10s later?

Although maybe we could have a way to say "this event shouldn't fire, and if the test reaches the timeout without that happening this test passes"

jgraham: gsnedders thoughts on ^ ? (Maybe there already is a way I'm forgetting?)

There isn't a better way. "this thing that can happen an unbounded amount of time in the future should in fact never happen" is strictly impossible to test

But of course practically we often just add a time limit

Right, the only thing we could do as infra writers that test authors can't do, is we know when a test has timed out and so could provide a hook to say "thats actually a pass for this test".

Whereas test authors have to guess how long they can set_timeout that will make it likely that the browser won't ever fire the event, but not too long such that they get a failing (or flaky failing!) TIMEOUT result on some browser/CI