(where

Anon(Platform.darwin)

represents "a new type we just created and memoized for that specific

enum

case")

https://github.com/pantsbuild/pants/issues/7906 <- asked a few questions about how to go about tackling this issue @witty-crayon-22786 @red-balloon-89377

this is more about python and the v1 engine, but i made an issue about how to make sure we can call

super()

methods, which was causing a silly bug in another PR: https://github.com/pantsbuild/pants/issues/8048

also, thanks @witty-crayon-22786 for showing the alternative to the above special syntax:

@rule(Assembler, [NativeToolchain, Platform.Linux])
def select_assembler_linux(native_toolchain, _):
  assembler = yield Get(Assembler, Binutils, native_toolchain._binutils)
  yield assembler

this is much cooler!

(basically, explicitly generating one-shot types for each case of an

enum

, and avoiding any new syntax)

so, while this was probably the right change (suppressing background workunits: https://github.com/pantsbuild/pants/pull/7997), i happened to find those useful for debugging cache insertion issues such as those described in https://github.com/pantsbuild/pants/pull/7860, which is recurring again. would anyone be opposed to me posting a PR which makes that suppression into a boolean option?

@hundreds-father-404: would you be able to schedule a braindumpy session on the token service and next steps for test remoting sometime in the next few weeks? likely with @early-needle-54791, myself, and hopefully someone from Toolchain? cc @happy-kitchen-89482

@enough-analyst-54434 is the right person for this (in general, but esp now since I'm about to go climb mt kenya and be offline for a few days)

(Moving this to DM)

btw, relating ot the v2 UI stuff I've been working on, it looks like the v2 UI is borked when I run it locally on my system

when I run pants with

--v2-ui

I get the ⚡'s on the side of the screen, but it looks like it's miscalculating my terminal size and letting text run off the side of the screen

and maybe not handling newlines correctly

can anyone show me a screenshot of what it's supposed to look like?

i expect you're seeing the right thing. but there is a lot of work still to do

the text being "too long" is due to using

impl Debug

rendering of nodes as their representation... there is some design work to do to decide what we want to replace that with.

@hundreds-breakfast-49010: sidenote: force pushing to a PR doesn't send email, so i didn't see that you had updated that one

sorry!

does clicking the button to take it from draft to ready not trigger an email? I'm not sure what situations github sends it in

neither i think.

@hundreds-father-404: so, given what @early-needle-54791 landed yesterday, if you want to use only remoting, you'll need to disable speculation

@witty-crayon-22786 and I have been DMing about an issue with timeouts when running V2 remoting.

build-support/bin/ci.py --python-tests-v2 --remote-execution-enabled

has both times I’ve tried resulted in a timeout like this:

Exception: Failed to execute process: Exceeded time out of 900s with 900.626410638s for operation projects/pants-remoting-beta/instances/default_instance/operations/EAEaGGZvdW5kcnktOTE2NzI0N2JjNzQ2N2EwNyIGYWN0aW9u, Run pytest for tests/python/pants_test/backend/python/subsystems:python_setup

But when running that test directly, it only takes 15 seconds to run: https://pantsbuild.slack.com/archives/C0D7TNJHL/p1563397967017800?thread_ts=1563397846.017500&amp;cid=C0D7TNJHL We had understood that once the timer starts for an

ExecuteProcessRequest

, it already has a slot in the worker pool and does not ever have to yield its CPU time to other processes. This might not actually be the case?

We had understood that once the timer starts for an

ExecuteProcessRequest

, it already has a slot in the worker pool and does not ever have to yield its CPU time to other processes. This might not actually be the case?

the relevant code is here: https://github.com/pantsbuild/pants/blob/121ec6f78aa8338f101e3dac75b3d52006eed44f/src/rust/engine/process_execution/src/remote.rs#L181-L253

it has definitely started the remote operation by that time

but it is possible that that remote operation is in a state like: "i'm queued to run"

so, two things:

1) how large is our remote worker pool, and should we tune our remote concurrency to be close to our pool size?

2) does the operation have some info in it that would tell us that the work has not started

So I think this mystery is solved? The issue was using 128 remote concurrency but only 1 worker, causing the threads to indeed yield their time to other threads and thus to timeout

well, item 2 probably still deserves a ticket.

but... will snooze a bit.