also @witty-crayon-22786 i'm not sure how much this has been previously developed yet, but it seems more obvious to me now after talking about logging for quelea executions yesterday that we might want the v2 equivalent of workunit output to be ~tied to process executions (like in v1), and that instead of either side of the spectrum of "i want a Console to do with as i please" to "only process executions can log to the console" we might be able to extend or wrap

ExecuteProcessRequest

("similar" to how we extend it to

FallibleExecuteProcessRequest

) to cover logging in a way that's more declarative than "write what you want to the console" but less than "you can only write tagged raw strings". i'm thinking in this case we could have something like (and this might be code that just lives in quelea at first): EDIT: see below snippet the below snippet was just made up on the spot so if it doesn't make sense that's my fault, might like @red-balloon-89377 @average-vr-56795 @salmon-summer-38098's thoughts too

i also need to get back the PRs on

stable_json_hash()

, datatype collection type checking, and definitely datatype default values, which are a great way to procrastinate writing this parsing method (i reduced it from SAT the other day but i'm waiting on apple to send the ipad keyboard wrapper so i don't scratch it up like i do every other device, i think delaying it is a plot by apple, but not in a john nash way)

also is there no way to ask slack to highlight code snippets as a certain language? i guess i could use the code snippet functionality, hold on

Untitled.py

i believe this is what the kids call word of mouth https://twitter.com/manishearth/status/1084320106522411008?s=21

and it’s one way to implement pants support for rust/cargo (buildgen, or something)

dumping the above into an issue

amazing it makes even more sense now https://github.com/pantsbuild/pants/issues/7071

i didn't have time to think about this a lot more right now so i dumped thoughts about how to interact with persistent subprocesses into https://github.com/pantsbuild/pants/issues/7079

see this? this is what the kids call hype https://twitter.com/clacke/status/1084641753456504833?s=21

cosmicexplorer

69 commits 16,267 ++ 6,230 --

nice

also this was cool (forcing

Instant::now()

to be monotonic) https://github.com/rust-lang/rust/pull/56988

@aloof-angle-91616 On the logging execute process request thing - yeah, I definitely agree that some kind of wokunit-like concept, and an option to implicitly tee failures’ stdout/stderr to the command line, could be super useful… I definitely wouldn’t want the abbreviated LHS-less yield thing… `ExecuteProcessRequest`s already have a description which we can use as the description… I think ideally we’d want something a little more concise than your example, but it’s a great start to be going from 🙂

https://github.com/pantsbuild/pants/issues/7079 is pretty interesting 🙂

^keen to hear any opposing thoughts

was going to look at turning Rule

output_constraint

into

output_type

as per https://github.com/pantsbuild/pants/issues/4535#issuecomment-455735882 (before implementing

@union_rule

and

@union_member_rule

) but going to look into collection typing first https://github.com/pantsbuild/pants/issues/6936

it looks contradictory but i'm thinking we can keep `TypeConstraint`s for checking

datatype

ctors while moving to using `TypeId`s in the engine

that actually dovetails honestly

because collection type checking expands what `TypeConstraint`s are able to do, and we have the capability to more cleanly do things like that when we can decouple it from engine stuff

that would imply working on them in the opposite order i guess

thread panicked while processing panic. aborting.

i knew this would happen

i think it has to do exactly with the line referred to at https://github.com/pantsbuild/pants/issues/4535#issuecomment-455735882 (the line with the comment referring to #4005)

i'm VERY dumb

ok maybe it's not that easy

but i did figure out that i was creating a

TypeId

from a `Key`s

.id()

, not its

.type_id()

hmmmm. how likely is it that the panic is being caused by.....a

panic!()

statement

ok, the issue was in the

panic!()

statement, which makes sense

except that fixing the

panic!()

is now a hang

but that's fine