-
-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new/missing defmt log format options #90
Conversation
@@ -318,6 +326,20 @@ | |||
], | |||
"default": "String" | |||
}, | |||
"mode": { | |||
"type": "string", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm just hoping here that omitting this will result in None
on the Rust side...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, omitting will result in a None
on the rust side.
Some observations:
- It feels odd to have
defmtLogFormat
as a peer torttChannelFormats
. Can we not somehow incorporate it into `rttChannelFormats.dataFormat ... or something sane? - Why is
channelName
anumber
?
Copy-paste-forget bug, sorry
This is a side effect of what cargo embed does: there is an outer option, that serves as a default for unconfigured channels, and inner ones have the same option to override this default. This is probably excessive... |
@bugadani I just remembered ... we used to have a channel name, and then removed it, because it can be specified in the target application when the channels are configured. Since we would have to arbitrarily choose which one takes priority, it seemed to make more sense to just let the naming happen on the rust side, and then name the client channels based on that. |
@bugadani I'm not sure I like having the outer and inner option. It adds code complexity and maintenance, for something that the user configures once in a Does it really add value to have both? |
Honestly I don't know, but the option is there in Rust - with the same question attached. I guess we can sack it from |
I don't want to propose changing cargo-embed ... it will impact existing users. I am just suggesting that we don't bring the unnecessary complexity to the dap-server. Especially since there can only be one defmt channel, what is the point of having an outer setting? Either set it for the one channel you have, or don't. Or am I missing something? |
Well then I just added a bunch of code to delete it :)
|
package.json
Outdated
@@ -488,6 +520,10 @@ | |||
"type": "boolean", | |||
"default": true, | |||
"description": "Enable the inclusion of Defmt location information in the RTT output for `dataFormat=Defmt`." | |||
}, | |||
"defmtLogFormat": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bugadani The probe-rs
CLI, uses
--log-format <LOG_FORMAT>
The default format string to use for decoding defmt logs
Does it make sense for us to be consistent in the naming of these options?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depends on where probe-rs/probe-rs#2442 ends up at, I'm not opposed.
3c76db7
to
f20a764
Compare
Last commit enables squigglies on typos: Relevant (but not really helpful?) docs: https://json-schema.org/draft/2020-12/json-schema-core#section-10.3.2.3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are my hero!!! Thank you for always going the extra mile and making things so much better.
Source is https://github.com/probe-rs/probe-rs/blob/08cc1456dd54e8df7a7afe34b0ba0f8345506752/probe-rs/src/bin/probe-rs/util/rtt.rs#L124-L145
This PR depends on a 0.24 release