I realise he is talking about swift scripts, but I doubt I can debug a swift script. The debugger needs a process to attach to. I don't think attaching to swift will get us the results we want.
Yeah swift-sh support would be a good addition. I know they generate SPM packages in the background.
Compile the script via swiftc and start the result. That's what a script does anyways.
What would be cool is if the editor would not actually invoke swift-sh, but rather detect a swift source w/ the swift-sh hashbang as kind of an alternative, embedded Package.swift (i.e. do similar stuff like swift-sh).
I think we can add something for scripts that does exactly that - matches a .swift file, checks for the hash bang and then compile it and execute it with LLDB.
I'm a little hesitant to build a new swift-sh tool into the extension - it's out of scope for the extension and I'd rather focus effort on improving scripting in Swift itself or SwiftPM for a solution that works cross platform outside of VSCode
I don't necessarily disagree (what was the result of the Swift forum swift-sh clone effort, there was one?), but just want to mention that swift-sh does work cross platform.
It was pitched as a GSoC project by @stevapple here - maybe he can provide an update?
As for swift-sh - I thought you meant reimplement it in the extension. We could add support for it if we can agree as a community that it's the de facto scripting system for swift or if we're going to add it to Swift or SwiftPM directly instead
One of the issues with editing scripts is that they tend to depend on a lot of shell-specific context, such as the current working directory, environment variables, or command-line arguments.
That makes it awkward to have a one-click "Build and Run" action, especially in a graphical editor which is detached from a shell. It just doesn't have that context.
VSCode does have an integrated terminal, though. So if we wanted to offer a better editing experience for scripts, we need to find a way to invoke swift scripts in that terminal (or equivalent context), while still providing things like breakpoints. I could imagine 2 things in particular:
Run & Debug in the context of a given terminal.
A one-click action to execute the script in the integrated terminal, but with full debugging support. So in the following picture, you can see that the working directory in the script is the same as calling pwd because we launch it manually via the integrated terminal. It's important that the script gets that context, but by launching things in this way, no debugger is attached:
(Note: VSCode does have a built-in "Run Active File in Active Terminal" command. Can we hook in to that and attach the debugger?)
Some kind of terminal command which runs the current file with some arguments.
If you need to do something more complex (perhaps passing in some command-line flags), you might still have to launch the script via the integrated terminal rather than a one-click action/keyboard shortcut. Again, we'd want a debugger attached so users could set breakpoints:
user@this-pc tmp % code-run-swift -arg1 -arg2=foo ../arg3
^^^^^^^^^^^^^^
some helper we inject ^
I don't know if this is possible, but that's what I imagine the ideal script editor workflow would look like. Stuff like swift-sh or script-packages would be cool, but we need to start with just the ability to run and debug a script in the context where it is used.
Not really, just implement the dependency declaration parsing and show similar information like w/ a normal Package.swift.
I made a PR to fix the syntax coloring in Visual Studio Code. It has the same syntax coloring backend as Google Colab for languages besides Python (Monaco): [Feature Request] Update Swift language specification to version 5.5 · Issue #2854 · microsoft/monaco-editor · GitHub
How is this related to VS Code? The syntax highlighting for VS Code is here: vscode/swift.tmLanguage.json at main · microsoft/vscode · GitHub
It's auto generated from the TextMate grammar, which unfortunately makes it hard to maintain.
v0.1.1 of the VS Code Swift extension has been released.
This includes a small fix to the CodeLLDB setup while running in a remote container. Previously in many situations it was getting this wrong. It should be correct now.
Maybe it isn’t. I just read online somewhere that VS Code depends on Monaco. Or, the file you showed me could be codegenned from the file I corrected in Monaco.
I took a quick look at what's possible for scripts, and it seems like Microsoft plans to improve terminal/shell support relatively soon:
This additional information enables a lot of possibilities:
[...]
- Potentially exposing a run command extension API which runs within an existing shell session and returns the exit code, additional state could also be exposed via
Terminal.state.- Overall better awareness of what's going on inside the terminal, currently it's mostly a black box and the main ways of detecting things is via scanning all text (eg. tasks) or by listening for certain key presses (eg. current command tracking).
So perhaps great script support isn't even possible right now in VSCode ("currently it's mostly a black box"), but it would be good to keep an eye on how things develop. When a user asks:
I think this is what they're asking for - the ability to run a script in the editor's built-in terminal, and attach a debugger to it for breakpoints etc. Does anybody know of other extensions which can do that today?
In Python that just works. I can open a .py file, set breakpoints and do F5. Works as expected.
Does that actually work like a script you'd launch from the terminal (via the #! shebang line), or is it just running a Python file? For example, does it inherit all environment variables and the current working directory of the active terminal?
This is what it is running for me:
helge@zMBA13 ClipIt % cd /Users/helge/dev/Swift/SwiftBlocksUI/ClipIt ; /usr/bin/env /opt/homebrew/bin/python3 /Users/helge/.vscode/extensions/ms-python.python-2021.12.1559732655/pythonFiles/lib/python/debugpy/launcher 60486 -- /Users/helge/Desktop/hello.py
Blub!
It does seem to inherit the env of the VSCode Terminal, but I didn't check what exactly it does (you can see how it switches to the proper directory and invokes python via env).
It certainly meets my expectations on how I'd like to debug a single source Swift tool.
Works like a charm! You people are amazing, thank you so much for the effort put into making this happen 
BTW: I've tried how well both work out of the box with the Swift extension.
Works pretty well on AppKit: SwiftUI Tools w/ VisualStudio Code.
Also kinda works w/ UIKit, but with a lot of manual intervention (I think it should be possible to fix that, my VSCode is not good enough for that): iOS App w/ VisualStudio Code. Or not?
A major bummer is the missing support for property wrappers and function builders, which I use quite a lot on either client side (SwiftUI) or server side (e.g. SwiftBlocksUI). Presumably an LSP issue?
Awesome job so far! I gave it a try and whoa it caught me unprepared. I've been using Xcode exclusively since v3. And god I loved it back then! But past few years not that much. I shall move to server-side Swift and try other IDEs...
does this use sourcekitd for the syntax highlighting? regex-based grammars do not work well when you always write swift with the type annotations (as i do)…
From the README:
Swift support uses SourceKit LSP for the language server to power code completion and LLDB to enable debugging.
SourceKit LSP has supported syntax highlighting for since August.
