added it to the PATH environment variable, rebooted, and it works - thank you! I'll watch for the next update and see if that can be removed from that PATH after installing it.
One more follow-up about the new Testing framework. Yes, I realize I can the Testing package as a dependency, but is there support for running and debugging those tests in VSCode or just the old XCTests. I'll give it a quick try but I think I tried it before (when I could only run but not debug code) and I got the "import Testing" line to compile, but the tests didn't run. Again, I'm ok with using XCTests but just thought I'd use the new Testing framework if it's supported rather than teach them an old style of testing.
I did get the new Swift Testing package to work now although the first build is extremely time consuming (which isn't surprising) and even after that subsequent builds after new tests are added are slow but it could be related to this laptop only have 4GB of memory (AMD Ryzen 3200U). The XCTest testing builds are much faster.
Can you elaborate on this @dave256 - I managed to get them included as deps. I also found I could get things compiling from command line using: swift test -Xcc -D_ALLOW_COMPILER_AND_STL_VERSION_MISMATCH but I didn't workout how to configure this to happen automatically in VSCode.
But more importantly even when they compile, tests were not "discovered" and as such nothing was tested. Any guidance would be appreciated.
@shapsuk I am using the Swift 6 toolchain and the Visual Studio Swift extension that was released on July 19th. I used swift package init to create the Package/directory structure and then here is the edited Package.swift
// swift-tools-version: 6.0
// The swift-tools-version declares the minimum version of Swift required to build this package.
import PackageDescription
let package = Package(
name: "Version3",
products: [
// Products define the executables and libraries a package produces, making them visible to other packages.
.library(
name: "Version3",
targets: ["Version3"]),
],
dependencies: [
.package(url: "https://github.com/apple/swift-testing.git", from: "0.11.0")
],
targets: [
// Targets are the basic building blocks of a package, defining a module or a test suite.
// Targets can depend on other targets in this package and products from dependencies.
.target(
name: "Version3"),
.testTarget(
name: "Version3Tests",
dependencies: ["Version3",
.product(name: "Testing", package: "swift-testing")
]
),
]
)
Here is a screenshot after right clicking in the code gutter and choosing to debug.
Hmm so I also switched over to Swift 6 and it does compile fine. But I don't seem to have features like background indexing (even after adding the flag for it). The Testing framework resolved fine, and the tests do now get detected which is great. But when I try and run a test I know will fail (1 == 2) nothing happens. Not even a successful result. It seems like its just compiling without running tests at all.
I also don't seem to be able to debug the library itself either.
Would you mind sharing your tasks.json file, perhaps mines wrong somehow. I might also try uninstalling everything including VSCode and starting from scratch.
One note: I am running on the new Surface Pro 11, which is ARM based. I wonder if that's perhaps an issue, although I'd expect other things to go wrong in that case.
So reinstalling everything seems to have done the trick! I now have swift-testing working including all the knobs and whistles I was expecting. Thank you for your reply, gave me hope to try again aha.
One thing I don't know about though, I still can't run and debug the project, I get this message which I guess confirms at least part of my assumption.
Swift-Format seems to be working nicely too. CTRL+Click through to Swift interfaces or my own code works great too, I was really missing that ;)
I noticed "Refactoring" does not work, however I thought that was mentioned as one of the upcoming Swift6 inclusions. Anyone know if this is still expected?
Sounds like you got it working. I don't have a tasks.json file - right clicking in the gutter and choosing run or debug for the tests doesn't seem to need one. I just checked again an #expect check that should fail did fail so I think it's working. It also builds a little faster now than I recall - about 30 seconds when I change one line of code (but again this is an underpowered laptop).
@shapsuk So you can get it to run on your ARM chip? I have Windows 11 installed via Parallels on a M1 Mac but couldn't get it to work there a month or two ago - I assumed it was an architecture issue based on the error message I saw (which I don't recall)
Yeah what I've shown above seems to be working mostly fine on the new ARM Surface. The only issue as I mentioned is that I can't debug or run the app as that's not supported yet. Although, I'm not sure what's throwing that error.
swift run from the command line does indeed run the executableTarget which is great and with Swift-Log/print I've got decent logging to help me debug for now.
As mentioned, refactoring still doesn't work, I get a little hint popup that says nothing can be refactored.
Also regarding times, I feel its pretty slow and that's the biggest annoyance, especially since background indexing doesn't seem to work at all (yet?). This is not an under-powered device I'd say so its pretty surprising. I also noticed while trying to get this whole this working, I chewed through battery life and this machine got uncomfortably hot for the first time since I got it. Not a complaint, just an observation.
For example, if I delete a bracket I'd expect it to immediately show up as an error, and then if I fix the issue, I'd expect the issue to disappear from the "Problems" output view. But actually nothing happens at all, and this is a single file.
I couldn't find a way to build just the current package (I'm not yet familiar enough with VSCode) so I have to keep doing "Build All" which is probably not the best way to do an incremental build.
One huge positive btw, Copilot in VSCode working on a Swift library is pretty cool. I'm loving the productivity boost using it to quickly sketch out functions, implement tests and document my code. Very nice.
Oh I found something in Settings.json under Swift where you can enable "Build on Save" which is a nice time-saver. I also enable auto-save when focus changes, this way I can either save the file or just navigate and the build will trigger. Should help.
@Fritzt thanks for the pointer to that link - after some Googling, I was able to extract the Python3.9 for ARM from the .nupkg file and copy the various files to "C:\Users\dreed\AppData\Local\Programs\Python\Python39-arm64" (made that last directory and copied the all files in the parent directory of DLLs to that directory. I can now right click in the gutter and run tests (XCTest-based - haven't tried new Testing package yet) from a Swift package but if I right click and debug the test, I get "this platform (arm64-win32) is not supported".
It sounds like you've gotten past that. Any suggestions? Thanks.
Sorry, for the late response. Yep, I can debug XCTest-based tests, I didn't try swift testing yet, as it is currently missing some required functionality. The only thing that was required for me, was to also set PYTHONHOME. I only tried the swift-DEVELOPMENT-SNAPSHOT-2024-07-02-a-windows10-arm64 installer.
@Fritzt what did you set PYTHONHOME to?
I just tried setting it to the directory that contains the python39 executable. I also tried setting it to the Libs directory within that directory (rebooting each time I changed the environment variable) and I still get the same error about arm64-win32 not being supported.
It points to the folder where the python executable is stored, the libs folder is within that folder. I just tried again with the current VS-Code extension, works flawlessly to stop at a breakpoint and allow for inspection.
It's a very clean installation of Windows 11 for ARM + Visual Studio Professional 2022 for ARM, Python 3.9 for ARM, Visual Studio Code, Swift-Dev for ARM. PYTHONHOME is set and the Visual Studio Code extension for Swift uses the Debug Adapter from Toolchain.
@Fritzt that's what I set PYTHONHOME to. I have
AppData/LocalPrograms/Python/Python39-arm64 that contains python, python.dll the Libs director and various other directories.
What I'm realizing though is I wonder if I have Visual Studio Professional 2022 for ARM? I bet I don't as I think I copied the instructions from swift.org that have:
I tried changing the .VC.Tools.x86.x64 to VC.Tools.ARM64 but the installer gave me Error Code 1.
Did you install Visual Studio Professional 2022 for ARM yourself vs. running that command? I wonder if there's a winget command I can run or an ARM version for Visual Studio Community as I think you need a license for Visual Studio Professional 2022 and I'm not certain my work has that license.
This isn't a major issue for me since I just needed to get it working on Windows for my students with Windows computers and the students with Macs can use Xcode but I figured I'd give it a try to document the steps for anyone else trying to get it to run in Parallels or with a new Windows ARM laptop (I doubt my students will have that since these are upper level students and they already have computers that most of them bought when they started college).
I was editing the post as you responded to indicate I tried to install an ARM64 version - oh well, I at least got it working on Windows x86 which is what I expect these students will have (or a Mac).
@dave256@Fritzt It may help to try enabling the Use Debug Adapter From Toolchain checkbox in the VS Code Swift Extension settings, if you're using Swift 6 on ARM64 Windows.
The VS Code Swift extension uses the CodeLLDB extension as its default debug adapter which hasn't been updated to support ARM64 Windows. I've had success toggling this checkbox to use the lldb-dap that comes with packaged in Swift 6 toolchains.
@plemarquand@Fritzt Ah yes, I had checked that on the Windows PC but not on the Parallels/Windows installation running on my Mac. That does seem to work! I can't recall which version of Swift 6 I installed - I think I grabbed the main branch development snapshot a week or two ago to try it after reading about some fix for Windows in it. It shows up as 0.0.0+Asserts in the Swift/Toolchains directory.
Thank you for all your help getting this working. Hopefully I've got the steps documented and I can get it to work with the subset of my students who have Windows PCs when classes start in a few weeks.
