Wasmtime GitHub notifications bot (Mar 04 2020 at 15:33): Wasmtime GitHub notifications bot (Mar 04 2020 at 15:33):alexcrichton commented on Issue #1213:
At least when working on other projects I've never come across the need to isolate the logs of each thread into its own file. When I've done some debugging I've typically found it more useful to have all the output interleaved so I can figure out what else is going on at the same time as well. Otherwise though I figure we could use our own logger which prepends a thread-specific prefix (but doesn't require such intrusive management for us to name all the threads) or the logging would have a prefix you could grep for to see what you're interested in.
Wasmtime GitHub notifications bot (Mar 04 2020 at 19:20):sunfishcode commented on Issue #1213:
Cranelift currently does emit some multi-line log messages, for IR dumps, which aren't very greppable. We could probably rework things so that it emits a log message per line, although if the lines have prefixes it's yet another step developers need to do to get an IR file out that they can test with.
Would it be better if we emitted IR dumps somewhere outside of the logging mechanism?
Wasmtime GitHub notifications bot (Mar 04 2020 at 19:47):alexcrichton commented on Issue #1213:
Hm ok, I figured this'd be an easy cleanup but if it's serving a purpose then it's serving a purpose so it shouldn't be removed. I find the behavior of
RUST_LOG=foo wasmtime foo.wasmspewing a lot of log files too surprising to be comfortable with, but we can figure something else out for that later if someone is motivated enough.
Wasmtime GitHub notifications bot (Mar 04 2020 at 21:48):sunfishcode commented on Issue #1213:
One easy thing we could do would be to get rid of
-dand have wasmtime spew to stderr by default when you give it a RUST_LOG=foo, and have a non-default flag for enabling file-per-thread logging.
Last updated: Nov 22 2024 at 17:03 UTC