Display the flashing progress in some form

[bugadani]

Maybe I'm just missing where it should be, but as far as I can tell, there is currently no way for the user to see the current status of the flashing progress.

[noppej]

It is not always obvious, but it is there .... possibly requires some documentation to clarify. A couple of notes here ...

• The extension uses the VSCode DAP API events ( progressStart/End/Update) to report progress.
• VSCode displays these in the bottom right-hand part of the status bar.
• VSCode uses a 'subtle' mechanism to display this, but if you click on it while in progress, you can pop it out to be more obvious (there might be a VSCode setting to do this for you, but I've never looked).
• If the flashing happens really fast, VSCode won't bother showing it (you can probably slow down your connection speed if you want to force it for validation purposes).

Let me know if this helps. If not, I will do a little screen grab video to demonstrate.

[bugadani]

Thanks, I have seen the progress reported in a notification popup once now. I suspect some weirdness still, I'll keep my eyes (and this issue) open in case I manage to find out more.

[noppej]

Also make sure that nothing else that is active is already using the progress update in the status bar. For instance, if rust analyzer is busy doing stuff when I start flashing, I find VSCode does not show my flashing progress.

[bugadani]

So my confusion came from flashingEnabled. The extension thinks its default value is true, but I don't think it sets that value - I need to manually add "flashingEnabled": true to my launch config to make it take effect. This suggests that probe-rs's default false is the actual default value when the option is not passed. This also suggests that the extensions default values are largely ignored for anything except documentation purposes.

My uneducated guess is that the following part is not implemented, leaving unset variables (so that they'll get filled by probe-rs & serde):

A launch configuration can be resolved (or modified) before it is used to start a new debug session. This allows for filling in default values based on information available in the workspace. Two resolve methods exist: resolveDebugConfiguration is called before variables are substituted in the launch configuration, resolveDebugConfigurationWithSubstitutedVariables is called after all variables have been substituted. The former must be used if the validation logic inserts additional variables into the debug configuration. The latter must be used if the validation logic needs access to the final values of all debug configuration attributes.

[noppej]

Hmmm ... I think you you're right. That leaves us with two options: 1) Implement the missing resolveXXXXX methods, and apply default values for the extension. 2) Remove default behaviour from the extension, and rely on probe-rs implementation defaults.

My first instinct is to go with option 2, because it promotes consistency in the various binary uses of probe-rs.

@bugadani , @Yatekii , @Tiwalun ... what do you think?

[bugadani]

I'm fine with option 2, all we need is to change the defaults here to their actual values - so that they still are hinted at:

[noppej]

I agree.

That said, it is a bit(LOT) of a pain to manually synchronize the list of config options and their defaults and allowed values between the extension and the app. I live in optimistic hope that one day someone will feel inspired to replace the static entries in package.json with a DebugConfigurationProvider that queries probe-rs executable for valid config and options 🤔

[bugadani]

I don't yet understand what the extensions can do. it looks like DebugConfigurationProvider can either provide an initial launch config, or send one dynamically to probe-rs, but what we would need here is a third option: to generate a launch config schema, and I'm not sure how to do that.

[Yatekii]

Yeah the docs on the VSCode API are not great imo. everytime I check it's like a real hassle ^^

I think synchronizing with probe-rs defaults is the sane choice here :)

[noppej]

Thanks. If the DebugConfigurationProvider can't do it, then perhaps a simple script to convert the Rust struct values from probe-rs, and generate the appropriate json might do it. As I typed this, I realize it is probably easier just to synch them manually, as long as we remember to update the docs also 😱