melpomene: make tracing feature flags additive
#1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently, the `tracing` behavior in Melpomene is controlled by a pair of feature flags, "trace-modality" and "trace-fmt". These select between emitting traces to stdout using `tracing_subscriber::fmt`, and emitting to Modality using the `tracing-modality` crate. However, these feature flags are not additive. If they are both enabled, the code will not compile, since there are two implementations of the `setup_tracing` function, which are conditionally compiled based on whether those feature flags are enabled. If both are enabled, both functions will be present, resulting in a compiler error. This commit changes this code so that there is a single implementation of the `setup_tracing` function, which will construct a `tracing` subscriber that includes either `fmt`, Modality, or _both_, depending on the feature combination. Now, Melpomene should build even with `--all-features` or similar. Now that the `fmt` layer is built manually rather than using `fmt::init()` "easy mode" helper, I've also changed the filter environment variable from "RUST_LOG" to "MELPOMENE_TRACE". I thought this was nicer, but we can continue using the default env var if that's preferable.
hawkw
added a commit
that referenced
this pull request
Jul 7, 2022
This branch makes the tracing configuration slightly nicer (IMO). Depends on #1.
|
Tested this works with both subscribers! Thanks :) |
jamesmunns
added a commit
that referenced
this pull request
Jun 4, 2023
Add `fmt` trait impls for heap containers
jamesmunns
added a commit
that referenced
this pull request
Jun 4, 2023
Merge commit. Introduce async variant of the vm. Intended to be used for cases where the host can provide non-blocking words, which by yielding with async, can avoid busy loops in environments without threading/preemptive multitasking. Original commits: * refactor: use `Poll` rather than `Done` enum * rough implementation of async execution * sickos YES * Rework to handle dispatch more like builtins (but defer exec) * Introduce a dedicated AsyncBuiltinEntry type * Restore test * Write a test, fix some bugs * allow async builtin futures to borrow `Forth` This way, the async builtin can mutate the forth stacks when it completes, which is necessary to actually return values from async builtins. * fully feature-flag async stuff * add a separate `AsyncForth` API type This introduces some unfortunate code duplication, but it lets us statically prevent errors resulting from async steps performed by non-async VMs and vice versa. It also lets us enforce that the same async dispatcher is used for the whole lifetime of the VM, which will prevent potential bugs from calling a step with an async dispatcher that doesn't know the set of builtins registered by the VM. * make the dispatcher provide the list of builtins * document async builtins * document sync builtins * rm unused dep --------- Co-authored-by: James Munns <james@onevariable.com>
jamesmunns
added
platform: melpomene
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, the
tracingbehavior in Melpomene is controlled by a pairof feature flags, "trace-modality" and "trace-fmt". These select between
emitting traces to stdout using
tracing_subscriber::fmt, and emittingto Modality using the
tracing-modalitycrate. However, these featureflags are not additive. If they are both enabled, the code will not
compile, since there are two implementations of the
setup_tracingfunction, which are conditionally compiled based on whether those
feature flags are enabled. If both are enabled, both functions will be
present, resulting in a compiler error.
This commit changes this code so that there is a single implementation
of the
setup_tracingfunction, which will construct atracingsubscriber that includes either
fmt, Modality, or both, depending onthe feature combination. Now, Melpomene should build even with
--all-featuresor similar.Now that the
fmtlayer is built manually rather than usingfmt::init()"easy mode" helper, I've also changed the filterenvironment variable from "RUST_LOG" to "MELPOMENE_TRACE". I thought
this was nicer, but we can continue using the default env var if that's
preferable.