Stream: t-compiler/wg-self-profile

Topic: meeting 2019-05-08


Wesley Wiser (May 06 2019 at 15:31, on Zulip):

We're holding a second team meeting in this stream on Wednesday, May 8th at 7:00 AM EDT/13:00 CEST (click for more time zones). We anticipate this meeting to be about 1 hour long.

Proposed meeting agenda:
- Discuss the current state of the tool
- Validate that the next step in the tracking issue (#58967) regarding changes to rustc-perf are correct and still valid.
- Discuss requested features, enhancements, and changes with a focus on beginner level issues to help onboard new contributors.
- Other topics?

All are welcome to attend!

mw (May 07 2019 at 14:20, on Zulip):

:tada:

simulacrum (May 08 2019 at 11:00, on Zulip):

:wave:

Wesley Wiser (May 08 2019 at 11:00, on Zulip):

:wave:

Wesley Wiser (May 08 2019 at 11:00, on Zulip):

Hi everyone!

mw (May 08 2019 at 11:00, on Zulip):

:wave:

Wesley Wiser (May 08 2019 at 11:01, on Zulip):

So the agenda was:

Wesley Wiser (May 08 2019 at 11:01, on Zulip):

Is there anything we should add?

Wesley Wiser (May 08 2019 at 11:01, on Zulip):

No?

Wesley Wiser (May 08 2019 at 11:02, on Zulip):

Ok :)

Wesley Wiser (May 08 2019 at 11:02, on Zulip):

I guess we'll just run down the agenda top to bottom then

Wesley Wiser (May 08 2019 at 11:02, on Zulip):

So status update on the tool

Wesley Wiser (May 08 2019 at 11:03, on Zulip):

We've got a library measureme which provides a fast binary encoding for profiler events.

Wesley Wiser (May 08 2019 at 11:03, on Zulip):

As of ~1 month ago, this got merged into rustc so any recent nightly is using it

Wesley Wiser (May 08 2019 at 11:03, on Zulip):

We also have a few tools utilizing the binary format

mw (May 08 2019 at 11:03, on Zulip):

@Wesley Wiser do you want to give the update?

Wesley Wiser (May 08 2019 at 11:04, on Zulip):

mmview which is basically just cat but for the binary format

Wesley Wiser (May 08 2019 at 11:04, on Zulip):

Yeah, feel free to chime in though :)

Wesley Wiser (May 08 2019 at 11:04, on Zulip):

summarize which gives a more detailed version of the old -Z self-profile output

Wesley Wiser (May 08 2019 at 11:04, on Zulip):

And also provides a json export format

Wesley Wiser (May 08 2019 at 11:05, on Zulip):

And then a few graphical tools

Wesley Wiser (May 08 2019 at 11:05, on Zulip):

collapse-stacks gives query/activity info in a format that the flame graph tools understand

Wesley Wiser (May 08 2019 at 11:05, on Zulip):

crox translates the event dump into the Chrome profiler format

Wesley Wiser (May 08 2019 at 11:06, on Zulip):

We've also had some recent contributions for some documentation and some enhancements from other community members.

Wesley Wiser (May 08 2019 at 11:06, on Zulip):

I think that's the current state

mw (May 08 2019 at 11:07, on Zulip):

yes, maybe some details on the compiler side:

mw (May 08 2019 at 11:07, on Zulip):
mw (May 08 2019 at 11:07, on Zulip):

but we do keep all the data in memory until the process exits (at least on linux)

mw (May 08 2019 at 11:08, on Zulip):

so max-rss information is skewed

simulacrum (May 08 2019 at 11:08, on Zulip):

It doesn't look all that bad: https://perf.rust-lang.org/compare.html?start=e4e032a0ae82d7db4f99872ff98626af2941c4a5&end=5539376de500270af54c7741ff8075316d950caf&stat=max-rss

simulacrum (May 08 2019 at 11:08, on Zulip):

only 2-3% bump which is fine by me

mw (May 08 2019 at 11:09, on Zulip):

yeah, it's not that bad

mw (May 08 2019 at 11:09, on Zulip):

the question is, does it make the collected data less valuable

mw (May 08 2019 at 11:09, on Zulip):

probably not really

mw (May 08 2019 at 11:09, on Zulip):

max-rss is noisy anyway

mw (May 08 2019 at 11:10, on Zulip):

anyway, the compiler side is almost ready for the MVP

mw (May 08 2019 at 11:10, on Zulip):

still lots of future improvements possible of course :)

mw (May 08 2019 at 11:11, on Zulip):

I think that's all my additions to the status update

Wesley Wiser (May 08 2019 at 11:11, on Zulip):

Ah, yes. I forgot about the output directory discussion. I'll push up a PR for that this week.

Wesley Wiser (May 08 2019 at 11:11, on Zulip):

Does the filename need to be "predictable" as well?

Wesley Wiser (May 08 2019 at 11:12, on Zulip):

Currently it's like pid-{nnnn}

mw (May 08 2019 at 11:12, on Zulip):

I don't think so

simulacrum (May 08 2019 at 11:12, on Zulip):

For perf.r-l.o, we need to be able to find it

mw (May 08 2019 at 11:12, on Zulip):

it should include the crate name for readability

mw (May 08 2019 at 11:13, on Zulip):

for perf.rlo I'd expect there to be a new temp directory for each invocation

mw (May 08 2019 at 11:13, on Zulip):

there'll be 3 files anyway

simulacrum (May 08 2019 at 11:14, on Zulip):

sure, seems reasonable-ish (I don't _think_ we have temp dirs today but I could imagine doing that, I think)

Wesley Wiser (May 08 2019 at 11:14, on Zulip):

Ok. I can make those changes this week.

mw (May 08 2019 at 11:14, on Zulip):

(ideally the temp dir would be in a RAM drive, to keep disk IO at a minimum)

simulacrum (May 08 2019 at 11:15, on Zulip):

we can probably do that, the current machine is 32GB ram iirc

mw (May 08 2019 at 11:15, on Zulip):

but we can discuss this in more detail later, if this seems too complicated for perf.rlo

simulacrum (May 08 2019 at 11:15, on Zulip):

sounds good

simulacrum (May 08 2019 at 11:16, on Zulip):

I'd need to investigate to be sure, will ping folks

Wesley Wiser (May 08 2019 at 11:17, on Zulip):

So I guess the next question is, can we just turn on -Z self-profile for per.rlo runs as we were hoping to?

Wesley Wiser (May 08 2019 at 11:17, on Zulip):

Or is the overhead still too high?

Wesley Wiser (May 08 2019 at 11:17, on Zulip):

niko asked about this yesterday and had some thoughts in this stream as well https://rust-lang.zulipchat.com/#narrow/stream/187831-t-compiler.2Fwg-self-profile/topic/overhead

simulacrum (May 08 2019 at 11:17, on Zulip):

I think so, yes -- looking at wall time the biggest differences are a second or two

mw (May 08 2019 at 11:18, on Zulip):

one thing to consider: this is "virtual" overhead anyway

mw (May 08 2019 at 11:18, on Zulip):

the user won't see it

mw (May 08 2019 at 11:18, on Zulip):

i.e. it's not a performance regression

simulacrum (May 08 2019 at 11:18, on Zulip):

right, yeah -- that's part of why I'm not too concerned

mw (May 08 2019 at 11:19, on Zulip):

the main question is: will it somehow skew the results?

mw (May 08 2019 at 11:19, on Zulip):

i.e. will it make our measurements inaccurate in some way

mw (May 08 2019 at 11:19, on Zulip):

by favoring big benchmarks for example

simulacrum (May 08 2019 at 11:19, on Zulip):

I would say no. Any cost that measureme imposes is approximately linear I think with respect to "work"

mw (May 08 2019 at 11:19, on Zulip):

or certain test cases

mw (May 08 2019 at 11:20, on Zulip):

I think so too

mw (May 08 2019 at 11:20, on Zulip):

we do write a lot of data to the disk though

simulacrum (May 08 2019 at 11:20, on Zulip):

(it certainly hurts large test cases more than small ones, but that's consistent with that theory)

mw (May 08 2019 at 11:20, on Zulip):

so we might be more I/O bound?

simulacrum (May 08 2019 at 11:21, on Zulip):

if we're writing at the end of the session on linux then that's not a problem

Wesley Wiser (May 08 2019 at 11:21, on Zulip):

There's probably some overhead which isn't equal over recording every event. For example, when we reach the end of one of the mmap'd pages and the OS has to allocate another. But that's still "constant" skew over the entire run

mw (May 08 2019 at 11:21, on Zulip):

yes

mw (May 08 2019 at 11:21, on Zulip):

so, I'd also say that the data is as useful as it is now

Wesley Wiser (May 08 2019 at 11:22, on Zulip):

And again, it would scale linearly with the total number of events recorded

mw (May 08 2019 at 11:22, on Zulip):

one downside might be that we never measure what the user actually executes

mw (May 08 2019 at 11:22, on Zulip):

but that's fine

simulacrum (May 08 2019 at 11:22, on Zulip):

we don't ... really do that today anyway, for the most part

mw (May 08 2019 at 11:23, on Zulip):

our data isn't super accurate anyway because it's exactly one machine on one platform :)

mw (May 08 2019 at 11:24, on Zulip):

alright, it sounds like we agree that turning on by default is what we want?

Wesley Wiser (May 08 2019 at 11:24, on Zulip):

So, I think I'm seeing consensus that we should enable it on perf.rlo and that the overhead is within acceptable margins?

Wesley Wiser (May 08 2019 at 11:24, on Zulip):

Yeah

simulacrum (May 08 2019 at 11:24, on Zulip):

how large are the artifacts being produced?

simulacrum (May 08 2019 at 11:24, on Zulip):

e.g. for librustc would we expect 1GB, 10GB, or what for the profile data?

mw (May 08 2019 at 11:24, on Zulip):

tens to hundreds of MBs, I think

simulacrum (May 08 2019 at 11:25, on Zulip):

ah, okay, so actually not that big -- that sounds good.

mw (May 08 2019 at 11:25, on Zulip):

@Wesley Wiser do you have numbers around?

Wesley Wiser (May 08 2019 at 11:25, on Zulip):

I don't think we've actually measured librustc

Wesley Wiser (May 08 2019 at 11:25, on Zulip):

I've mostly just been playing with the regex crate

mw (May 08 2019 at 11:25, on Zulip):

script-servo would be interesting as an extreme case

Wesley Wiser (May 08 2019 at 11:25, on Zulip):

Which is ~10mb I believe

simulacrum (May 08 2019 at 11:26, on Zulip):

I'm relatively unconcerned then

Wesley Wiser (May 08 2019 at 11:26, on Zulip):

I've got rustc-perf configured on my desktop here, I can do a test run and see how big the artifacts are

mw (May 08 2019 at 11:26, on Zulip):

should we make an action item to gather some data here?

mw (May 08 2019 at 11:26, on Zulip):

@Wesley Wiser yes, please

simulacrum (May 08 2019 at 11:27, on Zulip):

I think that'd be good (it sort of ties in to some questions I have on the next few bullet points)

Wesley Wiser (May 08 2019 at 11:27, on Zulip):

Ok. I'll also do that hopefully this week

Wesley Wiser (May 08 2019 at 11:28, on Zulip):

@simulacrum Do you want to go over those questions now?

simulacrum (May 08 2019 at 11:28, on Zulip):

sure, yeah

simulacrum (May 08 2019 at 11:28, on Zulip):

Is the profile data itself useful beyond running tooling over it locally? That is, would it make sense to want to keep it around (uploading it to S3, for example)?

mw (May 08 2019 at 11:29, on Zulip):

I'd say: no

mw (May 08 2019 at 11:29, on Zulip):

it does compress rather well, otoh

mw (May 08 2019 at 11:30, on Zulip):

but still, I'd say, do all the post-processing locally and only keep around the results of that

simulacrum (May 08 2019 at 11:30, on Zulip):

The reason I ask is that if the answer is no then we'd presumably want to run tools on the perf server, which might not be ideal (i.e., need to run N tools and upload N results vs. just local data)

Wesley Wiser (May 08 2019 at 11:30, on Zulip):

I guess it depends how much functionality we want to expose from perf.rlo

Wesley Wiser (May 08 2019 at 11:31, on Zulip):

summarize's output is minuscule and that's what the MVP has in it

mw (May 08 2019 at 11:31, on Zulip):

we could also upload the entire data, but only keep it around for a few days

Wesley Wiser (May 08 2019 at 11:31, on Zulip):

collapse-stacks output is also very small and pretty useful IMO

Wesley Wiser (May 08 2019 at 11:31, on Zulip):

So that would be very nice to have available

simulacrum (May 08 2019 at 11:31, on Zulip):

the other reason I ask is that I suspect it might be far easier to implement blindly uploading these artifacts than trying to figure out other ways to expose it

mw (May 08 2019 at 11:33, on Zulip):

my initial vision was: run benchmarks -> post-process data -> upload post-processing artifacts -> delete all local data

mw (May 08 2019 at 11:33, on Zulip):

where post-processing is just running a few of the measureme tools

Wesley Wiser (May 08 2019 at 11:33, on Zulip):

If there were an easy way to retrieve the artifacts, then I could see people using it. If not, then it might not be that important to keep around.

simulacrum (May 08 2019 at 11:33, on Zulip):

hm, okay -- how long does it take to run the measureme tools?

Wesley Wiser (May 08 2019 at 11:33, on Zulip):

< 1 second each

simulacrum (May 08 2019 at 11:34, on Zulip):

okay, so that's not a problem then -- I ask because perf script takes minutes on big crates' perf record dump

mw (May 08 2019 at 11:34, on Zulip):

it depends on the data size

Wesley Wiser (May 08 2019 at 11:34, on Zulip):

(in --release mode :laughing: )

mw (May 08 2019 at 11:34, on Zulip):

@Wesley Wiser can you collect some data on that as well?

Wesley Wiser (May 08 2019 at 11:34, on Zulip):

Even for a massive crate, I'd image it's < 10 seconds

Wesley Wiser (May 08 2019 at 11:34, on Zulip):

Sure

Wesley Wiser (May 08 2019 at 11:35, on Zulip):

I'll just test the largest output from rustc-perf

simulacrum (May 08 2019 at 11:35, on Zulip):

So long as it's less than a minute I'm not too worried, I don't want to be spending an additional half hour per run though just running measureme tooling :)

mw (May 08 2019 at 11:35, on Zulip):

like, just making sure it's not more than a few seconds for script-servo would be enough

mw (May 08 2019 at 11:35, on Zulip):

how parallelizable is this?

simulacrum (May 08 2019 at 11:36, on Zulip):

you mean running N tools simultaneously?

mw (May 08 2019 at 11:36, on Zulip):

i.e. if we did it all at the end, then wall-time would be lower

mw (May 08 2019 at 11:36, on Zulip):

yeah

mw (May 08 2019 at 11:36, on Zulip):

or yes, if we have N different tools, we can do that too

mw (May 08 2019 at 11:36, on Zulip):

that would be the easiest thing to do

simulacrum (May 08 2019 at 11:37, on Zulip):

let's wait on @Wesley Wiser's results and decide then

mw (May 08 2019 at 11:37, on Zulip):

so here's another interesting thing:

mw (May 08 2019 at 11:37, on Zulip):

most benchmarks are run through N iterations, right?

mw (May 08 2019 at 11:37, on Zulip):

we somehow need to combine that data

simulacrum (May 08 2019 at 11:37, on Zulip):

yes, then min is taken for measurements today

mw (May 08 2019 at 11:38, on Zulip):

ok, so we'd only combine (via min) the summarize report

simulacrum (May 08 2019 at 11:38, on Zulip):

historically my thought has been to just use one run's data to start with

mw (May 08 2019 at 11:38, on Zulip):

for flamegraph etc, we just take the shortest one, maybe?

Wesley Wiser (May 08 2019 at 11:39, on Zulip):

We could just use whichever run was the MIN's results

simulacrum (May 08 2019 at 11:39, on Zulip):

well, we do it per statistic... which is maybe not great but

simulacrum (May 08 2019 at 11:39, on Zulip):

so like max-rss might be a different run than walltime

Wesley Wiser (May 08 2019 at 11:39, on Zulip):

Oh I see

simulacrum (May 08 2019 at 11:39, on Zulip):

(currently)

mw (May 08 2019 at 11:40, on Zulip):

ok, sticking to the current behavior seems fine to me

simulacrum (May 08 2019 at 11:41, on Zulip):

is the summary output text? JSON? csv?

mw (May 08 2019 at 11:41, on Zulip):

json

mw (May 08 2019 at 11:41, on Zulip):

(right?)

simulacrum (May 08 2019 at 11:41, on Zulip):

okay, that's nice

Wesley Wiser (May 08 2019 at 11:41, on Zulip):

Yeah, we have json

Wesley Wiser (May 08 2019 at 11:42, on Zulip):

We're also going to support outputting a JSON diff as well

Wesley Wiser (May 08 2019 at 11:42, on Zulip):

Between two different runs

mw (May 08 2019 at 11:42, on Zulip):

yeah, I've been thinking: that's not so useful for perf.rlo

simulacrum (May 08 2019 at 11:43, on Zulip):

compare view?

mw (May 08 2019 at 11:43, on Zulip):

because the user can ask for the diff between arbitrary commits

mw (May 08 2019 at 11:43, on Zulip):

so the diffing has to be done on the fly

mw (May 08 2019 at 11:43, on Zulip):

probably in javascript?

mw (May 08 2019 at 11:43, on Zulip):

in the browser I mean

simulacrum (May 08 2019 at 11:43, on Zulip):

ah, we send the data for all compare pages from Rust so I don't see why it'd be client side

simulacrum (May 08 2019 at 11:44, on Zulip):

I guess it could be

mw (May 08 2019 at 11:44, on Zulip):

ah, ok, so you have a webservice implemented in Rust for that?

simulacrum (May 08 2019 at 11:45, on Zulip):

yeah, perf has a raw hyper backend that serves all the pages and data

simulacrum (May 08 2019 at 11:45, on Zulip):

(this runs separately from the collection infrastructure)

mw (May 08 2019 at 11:45, on Zulip):

ok

mw (May 08 2019 at 11:46, on Zulip):

anyway, it's probably more important what we want the result to look like

simulacrum (May 08 2019 at 11:46, on Zulip):

yeah -- I think that result is clickable links on every benchmark run

mw (May 08 2019 at 11:46, on Zulip):

I had something like this in mind: https://hackmd.io/s/rkERN4lnE

mw (May 08 2019 at 11:47, on Zulip):

with tables sortable by column, maybe?

mw (May 08 2019 at 11:47, on Zulip):

and a separate comparison table for each thing we measure

simulacrum (May 08 2019 at 11:48, on Zulip):

seems feasible -- this might also be too much data, though, not sure

mw (May 08 2019 at 11:48, on Zulip):

too cluttered, you mean?

simulacrum (May 08 2019 at 11:48, on Zulip):

yeah

mw (May 08 2019 at 11:49, on Zulip):

we could only show lines above a certain threshold by default

simulacrum (May 08 2019 at 11:49, on Zulip):

makes sense to me

mw (May 08 2019 at 11:50, on Zulip):

@Wesley Wiser how does that sound to you?

Wesley Wiser (May 08 2019 at 11:50, on Zulip):

I agree

Wesley Wiser (May 08 2019 at 11:50, on Zulip):

There was similar discussion actually about the default summarize output

Wesley Wiser (May 08 2019 at 11:50, on Zulip):

Whatever value we decide probably makes sense to apply there as well

mw (May 08 2019 at 11:51, on Zulip):

maybe we don't need to show all tables

simulacrum (May 08 2019 at 11:51, on Zulip):

we will want the summarize output to include everything inside perf and then filter (maybe client side) for perf.r-l.o

Wesley Wiser (May 08 2019 at 11:51, on Zulip):

Yeah, absolutely

Wesley Wiser (May 08 2019 at 11:51, on Zulip):

--json returns all the data

Wesley Wiser (May 08 2019 at 11:51, on Zulip):

The other options are just for the stdout display

simulacrum (May 08 2019 at 11:52, on Zulip):

sounds good

simulacrum (May 08 2019 at 11:52, on Zulip):

I think I'm happy then wrt to a plan for perf -- I should also have more time after tomorrow to maybe start looking into an implementation

mw (May 08 2019 at 11:53, on Zulip):

cool

mw (May 08 2019 at 11:53, on Zulip):

one more thing:

Wesley Wiser (May 08 2019 at 11:53, on Zulip):

@simulacrum Feel free to ping me with work items. I'm happy to work on them

mw (May 08 2019 at 11:53, on Zulip):

the postprocessing tools and the compiler must be in sync, kind of

mw (May 08 2019 at 11:53, on Zulip):

how do we make sure they are?

mw (May 08 2019 at 11:54, on Zulip):

does perf.rlo use rustup or something like that?

simulacrum (May 08 2019 at 11:54, on Zulip):

we use... well, proto rustup

simulacrum (May 08 2019 at 11:54, on Zulip):

(read: download artifacts from CI ourselves)

mw (May 08 2019 at 11:55, on Zulip):

I think it would make sense to have measureme tools be a rustup component anyway

simulacrum (May 08 2019 at 11:55, on Zulip):

but that doesn't contain cargo.lock or anything we could use to check for equal versions; I think there was some discussion of the tools "knowing" that they should not run or otherwise erroring out

mw (May 08 2019 at 11:55, on Zulip):

would that help here too?

simulacrum (May 08 2019 at 11:55, on Zulip):

in theory, yes, in practice it's likely more work than just installing them because we don't actually support components today

simulacrum (May 08 2019 at 11:55, on Zulip):

though we do want to (windows check builds for winapi being a prominent use case)

Wesley Wiser (May 08 2019 at 11:56, on Zulip):

Should we try to migrate to using rustup then? Or is that too big a project to block on?

simulacrum (May 08 2019 at 11:56, on Zulip):

I'd not block on it

mw (May 08 2019 at 11:57, on Zulip):

we probably shouldn't block, yeah

simulacrum (May 08 2019 at 11:57, on Zulip):

presumably for now we can just depend on the right version which seems easy enough

Wesley Wiser (May 08 2019 at 11:57, on Zulip):

I guess we could add a flag to rustc to have it tell us what version of measureme it's using?

simulacrum (May 08 2019 at 11:57, on Zulip):

(are these tools all CLI or cargo-deps?)

mw (May 08 2019 at 11:57, on Zulip):

yeah, the format shouldn't change too often

Wesley Wiser (May 08 2019 at 11:57, on Zulip):

I'm not sure what you mean by cargo-deps

simulacrum (May 08 2019 at 11:58, on Zulip):

crates for Cargo.toml

Wesley Wiser (May 08 2019 at 11:58, on Zulip):

They're separate crates in the measureme repo/Cargo workspace

Wesley Wiser (May 08 2019 at 11:58, on Zulip):

But they're not uploaded to crates.io

simulacrum (May 08 2019 at 11:59, on Zulip):

right, but libraries vs. binaries is the distinction I'm asking about

Wesley Wiser (May 08 2019 at 11:59, on Zulip):

Oh sorry

Wesley Wiser (May 08 2019 at 11:59, on Zulip):

Yeah they're all binaries

simulacrum (May 08 2019 at 11:59, on Zulip):

okay, sounds good -- I wouldn't worry then about versioning anything just yet as a blocking bit

simulacrum (May 08 2019 at 11:59, on Zulip):

we can update as needed

mw (May 08 2019 at 12:00, on Zulip):

ok

mw (May 08 2019 at 12:00, on Zulip):

let's try to add the version header to the file format asap, so we know when somethings wrong

simulacrum (May 08 2019 at 12:01, on Zulip):

I will try to get some issues or something opened on perf over the next weekish to assign to @Wesley Wiser

simulacrum (May 08 2019 at 12:01, on Zulip):

(or, well, anyone in the community if we want to diversify)

Wesley Wiser (May 08 2019 at 12:02, on Zulip):

Sounds good!

mw (May 08 2019 at 12:03, on Zulip):

alright, we should make a list of action items and add them to the tracking issue

mw (May 08 2019 at 12:03, on Zulip):

(or make existing points there more concrete)

mw (May 08 2019 at 12:03, on Zulip):
mw (May 08 2019 at 12:04, on Zulip):
mw (May 08 2019 at 12:04, on Zulip):
mw (May 08 2019 at 12:06, on Zulip):
Wesley Wiser (May 08 2019 at 12:09, on Zulip):

I think that's it?

simulacrum (May 08 2019 at 12:11, on Zulip):

nothing else I can think of

Wesley Wiser (May 08 2019 at 12:13, on Zulip):

Since we're over time, lets call this meeting unless @mw has anything to add?

Wesley Wiser (May 08 2019 at 12:14, on Zulip):

(They seem to have dropped off)

simulacrum (May 08 2019 at 12:15, on Zulip):

happy to call the meeting, yes

Wesley Wiser (May 08 2019 at 12:15, on Zulip):

Sounds good

simulacrum (May 08 2019 at 12:15, on Zulip):

Thanks all! \o

Wesley Wiser (May 08 2019 at 12:15, on Zulip):

:wave:

mw (May 08 2019 at 13:06, on Zulip):

Sorry, yes, I was actually late to the next meeting already :)

mw (May 08 2019 at 13:06, on Zulip):

:wave:

Last update: Nov 17 2019 at 08:20UTC