sg-wireless / pymakr-vsc

GNU General Public License v3.0
97 stars 25 forks source link

Open device in File Explorer fails (on windows) - techpreview #205

Closed Josverl closed 2 years ago

Josverl commented 2 years ago

What are the steps to reproduce this issue?

  1. install pymakr v2.x
  2. connect to a board :⚡
  3. Open device in File Explorer 📁

What happens?

  1. File Explorer shows a device : serial:/COM4, with an !
  2. hover over the ! shows \flash * unable to retrieve workspace folder

What were you expecting to happen?

list of files on the device

Any logs, error output, etc?

developer log shows

[Extension Host] listening on 5364
console.ts:137 [Extension Host] PyMakr > updated config: Object
console.ts:137 [Extension Host] PyMakr > Device: Silicon Labs CP210x USB to UART Bridge (COM4) > connecting...
console.ts:137 [Extension Host] PyMakr > Device: Silicon Labs CP210x USB to UART Bridge (COM4) > connected.
log.ts:313   ERR No file system provider found for resource 'serial://com4/flash': ENOPRO: No file system provider found for resource 'serial://com4/flash'
    at p.withProvider (vscode-file://vscode-app/c:/Users/josverl/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:610:27776)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async p.exists (vscode-file://vscode-app/c:/Users/josverl/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:610:30371)
    at async Promise.all (index 1)
    at async vscode-file://vscode-app/c:/Users/josverl/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2110:2110
mainThreadExtensionService.ts:107 Activating extension 'vscode.npm' failed: No file system provider found for resource 'serial://com4/flash'.
$onExtensionActivationError @ mainThreadExtensionService.ts:107
console.ts:137 [Extension Host] rejected promise not handled within 1 second: Error: ENOENT: no such file or directory, scandir 'C:\flash'
D @ console.ts:137
console.ts:137 [Extension Host] stack trace: Error: ENOENT: no such file or directory, scandir 'C:\flash'
D @ console.ts:137
log.ts:313   ERR ENOENT: no such file or directory, scandir 'C:\flash': Error: ENOENT: no such file or directory, scandir 'C:\flash'
log.ts:313   ERR [Extension Host] (node:8856) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.

Any other comments?

I noticed that https://github.com/pycom/pymakr-vsc/issues/202 also mentions a path issue that is likely related.

What versions of software are you using?

Window: 11

VSCode: Version: 1.66.0 (user setup) Commit: e18005f0f1b33c29e81d732535d8c0e47cafb0b5 Date: 2022-03-30T05:50:14.623Z Electron: 17.2.0 Chromium: 98.0.4758.109 Node.js: 16.13.0 V8: 9.8.177.11-electron.0 OS: Windows_NT x64 10.0.22572

Pymakr version: 2.8.4

jakobrosenberg commented 2 years ago

I haven't been able to solve this one yet. I get the same behavior, but for some reason it still works.

Josverl commented 2 years ago

I think this is related to the MCU root As discussed in https://github.com/pycom/pymakr-vsc/discussions/224

Arcadia197 commented 2 years ago

I'm experiencing the same issues on Linux / Ubuntu 20.04 for displaying the files as well as uploading any code at all. Root system for an ESP32 is not detected and it tries to work with "/flash" which doesn't exist. I also believe that this is linked to #224.

jakobrosenberg commented 2 years ago

From what I can tell, whenever a folder is mounted on a new protocol, like serial://, VSCode restarts. It happens subtly and is easy to miss.

I had a look at VSCode's official memfs example last week and it seems this always happens on the first mount.

I'll see if I can allocate some more time for it this week.

@Arcadia197 I suspect the /flash path is a different, but related issue. I've added it to the todo list.

Josverl commented 2 years ago

I had a look at VSCode's official memfs example last week and it seems this always happens on the first mount. you you refer to :

jakobrosenberg commented 2 years ago

Hi @Josverl, you can see the samples here. It's the fsprovider-sample.

Granted my observations are correct, I think the restart is by design.

EDIT: You beat me to it 😅

Josverl commented 2 years ago

thanks , ill have a look later this week to see if I can reproduce

jakobrosenberg commented 2 years ago

I think I've narrowed down the issue. It's not related to first time use of a protocol after all.

VSCode restarts when the primary workspace (1st) is changed and/or when the workspace change from single to multi.

I'll see if I can find a solution / workaround.

jakobrosenberg commented 2 years ago

Just tried this in the memfs example:

context.subscriptions.push(vscode.commands.registerCommand('memfs.workspaceInit', _ => {
    vscode.workspace.updateWorkspaceFolders(1, 0, { uri: vscode.Uri.parse('memfs:/foo'), name: "MemFS - Sample" });
}));

Got the following

rejected promise not handled within 1 second: Error: ENOENT: no such file or directory, scandir 'C:\foo'
c:\Users\jakob\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:102
stack trace: Error: ENOENT: no such file or directory, scandir 'C:\foo'

Seems that any unresolved path is interpreted as a local filepath.

Josverl commented 2 years ago

I indeed see a correlation between the existence of a local folder C:\flash and better behavior But that folder should not need to be created, so perhaps some of the functionality does not use the virtual file system but the actual. I also found that log.warn does not log warnings, so we may be missing some telltales. Raised a separate issue for that

jakobrosenberg commented 2 years ago

Sorry. I completely forgot to follow up on this. The issue is caused by VSCode restarting whenever the primary workspace changes or when the workspace changes from single to multi.

I also tried this path in the memfs example: memfs:/foo and got an error about c:\foo missing. It seems this issue is caused by VSCode wrongly normalizing the error on Windows machines.

Josverl commented 2 years ago

I think this is now mostly solved by (manually) changing the root path configuration to match the device and other changes one think that remains confusing for first time users is that pymakr signals that the MCU is not responding and offers to restart it in safe mode (only possible on some hardware / firmwares)

In my testing this seems occurs every time when mounting a device creates a new workspace, and then the tendecy is to click that [safe-boot] button , and in my case that always makes the problem bigger as I do not have a device that supports safe-boot

I'll do some more testing , and if needed create a issue to tackle that behaviour

jakobrosenberg commented 2 years ago

I have considered changing the root path, but I'm not sure if there are any downsides. For instance what happens if the user has both /flash and /sd. Then again, that might actually be a case for leaving / as the root path instead.