Skip to content
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.

Sign up for GitHub

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

Jump to bottom

feat: expose the Arduino state to VS Code extensions #2071

Closed
wants to merge 3 commits into from
Closed

feat: expose the Arduino state to VS Code extensions #2071

wants to merge 3 commits into from

Conversation

dankeboy36
Copy link
Contributor

@dankeboy36 dankeboy36 commented May 21, 2023 •
edited
Loading

Motivation

To provide a way to implement external tools for the Arduino IDE without modifying the IDE codebase. See #58.

This PR introduces a tiny layer of code to listen to Arduino context-related changes and set it on the VS Code workspaceState. Other VS Code extensions can import this new VSIX API and retrieve context information from the Arduino IDE—information such as the sketch path, FQBN of the currently selected board, etc. See https://github.com/dankeboy36/vscode-arduino-api for more details.

I have an ongoing reference re-implementation of the ESP exception decoder. It works in the Arduino IDE. I did the reference implementation in Code and noticed that Theia has a few bugs, so the final implementation comes a bit later:

espDecoder.mp4

Change description

Other information

Reviewer checklist

  • PR addresses a single concern.
  • The PR has no duplicates (please search among the Pull Requests before creating one)
  • PR title and description are properly filled.
  • Docs have been added / updated (for bug fixes / features)

@me-no-dev
Copy link

Hi @dankeboy36 ! This looks like a great idea! My question is wether the extensions can have access to all board properties defined in boards.txt and possibly the ones in platform.txt.?

I checked your code for the Exception Decoder and it seems that it's going through the installed tools and is searching for executable ending on gdb. While such thing would work for ESP8266 installed through the board manager, it would need modification to work when platform is installed from git and would not at all work correctly on ESP32 platform, which needs to know what chip is being used, in order to pick up the correct GDB package and path.

An amazing thing would be to be able to listen on the Serial Monitor and print exceptions directly inline, much like idf.py monitor, or create custom Plotter, etc.

@dankeboy36
Copy link
Contributor Author

dankeboy36 commented May 22, 2023 •
edited
Loading

I checked your code for the Exception Decoder, and it seems that it's going through the installed tools and is searching for executable ending on gdb.

Thanks for taking the time and looking into the PR. I also checked your original Java implementation quite a lot recently 😄 The current GDB lookup is a hack. It will be resolved soon using only the boardDetails from the CLI.

My question is wether the extensions can have access to all board properties defined in boards.txt and possibly the ones in platform.txt.?

On the spot. This is precisely the idea. It's not yet available from the IDE, but the CLI can print the build_properties for a board, so it will be possible to get build.tarch=xtensa or different with arduino/arduino-cli#2151.

I do not know much about the platform.txt, but if required, I hope the CLI maintainers can help us.

@me-no-dev
Copy link

I do not know much about the platform.txt, but if required, I hope the CLI maintainers can help us.

with access to all build variables in platform.txt, you could get the location of GDB by just getting the value of debug.toolchain.path or compiler.path (depending on the chip). Same goes for esptool and other necessary things to get file system uploads working, etc.

@dankeboy36
Copy link
Contributor Author

dankeboy36 commented May 23, 2023 •
edited
Loading

with access to all build variables in platform.txt, you could get the location of GDB by just getting the value of debug.toolchain.path or compiler.path (depending on the chip). Same goes for esptool and other necessary things to get file system uploads working, etc.

I appreciate your input! The tool paths can be inferred from the combination of the boardDetails#requiredTools and the dataDirPath using the currently proposed API. At this point, I do not see the necessity to expose the platform.txt content. It might change in the future. For now, I want to focus on enabling the API for tool developers and reimplementing one or two existing tools as VS Code extensions so that others can understand how to do it. If there is a need for it from the community, I am sure the CLI team can help us.

@me-no-dev
Copy link

At this point, I do not see the necessity to expose the platform.txt content.

required tools will show only for installation from Board Manager and not when installed from git. For ESP32 platform all tools for all chips will be there (when installed from board manager), so you can not really figure out what is needed and what is where without having all build variables available. For single chip/architecture platform this might work fine, but not for ESP32 for sure.

@per1234 per1234 added type: enhancement Proposed improvement topic: code Related to content of the project itself labels May 24, 2023
@dankeboy36
Copy link
Contributor Author

when installed from git.

Could you share the procedure for how to do such an installation?

@per1234
Copy link
Contributor

per1234 commented May 24, 2023

with access to all build variables in platform.txt, you could get the location of GDB by just getting the value of debug.toolchain.path or compiler.path

The build properties mentioned by @dankeboy36 include those set in platform.txt. This includes the debug.toolchain.path and compiler.path properties.

@per1234
Copy link
Contributor

per1234 commented May 24, 2023

Could you share the procedure for how to do such an installation?

Here it is @dankeboy36:

https://docs.espressif.com/projects/arduino-esp32/en/latest/installing.html#windows-manual-installation

There are sets of manual installation instructions for Windows, Linux, and macOS, I linked to the Windows section simply because that is the first set of instructions. Scroll down on the page for the others.

@dankeboy36
Copy link
Contributor Author

Depends on arduino/arduino-cli#2184. I have pinned the CLI version for the time being.

@dankeboy36 dankeboy36 mentioned this pull request May 24, 2023
Merged
@dankeboy36 dankeboy36 force-pushed the set-arduino-context branch 2 times, most recently from 258f174 to e42d271 Compare May 29, 2023 15:23
chore(cli): Bumped the CLI version 0.33.0-rc1
0285936 
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
@kittaakos
Copy link
Contributor

Depends on arduino/arduino-cli#2184. I have pinned the CLI version for the time being.

There is a separate PR with the CLI version update. Rebasing from it should reduce the outgoing changes of this PR: #2083.

@kittaakos
Copy link
Contributor

set it on the VS Code workspaceState.

@dankeboy36 dankeboy36 changed the title feat: set the Arduino context as workspaceState feat: expose the Arduino state to VS Code extensions May 31, 2023
@dankeboy36 dankeboy36 changed the base branch from main to cli-0.33.0-rc1 May 31, 2023 17:12
@dankeboy36
feat: set the Arduino context as workspaceState
58cfdfa 
Set the VS Code `workspaceState` on fqbn, port, and sketch path changes.
VS Code extensions can read this cached state.

Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
@dankeboy36
fix: force plugin activation order
9518fdf 
api plugin must start before any tool VSIX without explicitly updating
the `extensionDependencies` with the API.

Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
@dankeboy36 dankeboy36 mentioned this pull request Jun 1, 2023
Closed
3 tasks
@dankeboy36
Copy link
Contributor Author

Bocked by arduino/arduino-cli#2197.

@kittaakos kittaakos deleted the branch arduino:cli-0.33.0-rc1 June 6, 2023 11:03
@kittaakos kittaakos closed this Jun 6, 2023
@dankeboy36 dankeboy36 mentioned this pull request Jun 21, 2023
Merged
4 tasks
@kittaakos
Copy link
Contributor

Duplicate of #2110

@kittaakos kittaakos marked this as a duplicate of #2110 Jun 21, 2023
@kittaakos kittaakos added the conclusion: duplicate Has already been submitted label Jun 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@kittaakos kittaakos Awaiting requested review from kittaakos

@AlbyIanna AlbyIanna Awaiting requested review from AlbyIanna

Assignees
No one assigned
Labels
conclusion: duplicate Has already been submitted topic: code Related to content of the project itself type: enhancement Proposed improvement
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@dankeboy36 @me-no-dev @per1234 @kittaakos