Add instructions for Windows. #2
Conversation
|
Thanks @compnerd ! Can you ping me when the instructions/tools are stable enough for me to try out? Also, what editors/IDEs will we be able to recommend for development on Windows? If the Windows build includes SourceKit-LSP, perhaps we can use Visual Studio Code with the SourceKit-LSP extension ? Do you know of any other student-friendly options? |
|
You're welcome. The instructions just need to wait for another snapshot to be built for them to be useable for command line usage. Eventually, VSCode would be the editor that students could use, but that requires a change in flight (otherwise completion is problematic if you use WinSDK). |
|
Okay, the current snapshot (10/22) I believe should be sufficiently new that we can just document the modern instructions, which also means that VSCode usage is nearly possible (it is possible as long as |
|
@compnerd I hope to find some time later this week to try this out. Some first glance questions:
Thanks! |
|
I’ve been trying to play with trying to remove it. The build tools are needed, but it’s a smaller install. I think that it’s best to keep the VS install for now, since otherwise you need to install python, git, build tools, and the MSVC redistributable. But that would avoid the editor. The windows SDK is a hard requirement as foundation et al use it as does system. Most of the basic operations are not part of the C library. The instructions need updating to indicate the 10/24 snapshot as the earliest to try. |
|
@compnerd I was able to complete the installation and run Some questions that came up along the way:
Unfortunately, I wasn't able to run any Swift code:
I recall seeing some of these errors posted on the Swift Forums, so I will check the replies on those topics as well. In any case, I had hoped that the |
|
Installation:
Running:
If I can figure out how to copy |
|
Thanks @compnerd. Let's continue with more feedback and questions 😅
|
Can you be a bit more precise about what the behaviour is that you see?
Sadly, we still need to use the Native Tools command prompt. I need to test the last set of changes I made to devenv. If that now works as I want (
For the copy either works, ideally, I suppose we should just standardize on x64 as the toolchain is a 64-bit toolchain only.
It literally sets a couple of environment variables and gives you a shell with that setup. It just gives a simpler way to get the correct environment that you can get via the "x64 Native Tools for VS2019 Developer Command Prompt".
Have you tried compiling something more interesting than hello world? Once you start doing that, it will quickly fall apart because you need
I suspect that you may have set extra environment variables that are not expected to be set all the time.
Yes, that is expected to work, though not perfectly yet. I know of a few places where it breaks down.
I don't know anything about CodeLLDB so I can't really say what is going on here.
I wonder if that is the error that you see. That sounds like a bug in SPM. Do you have developer mode enabled on Windows? |
Running Running
Running
What are the correct values for these variables? If I run
I'm trying to configure this extension as per https://github.com/vadimcn/vscode-lldb/blob/master/MANUAL.md#alternate-lldb-backends I've tried pointing it to toolchain\usr\lib\liblldb.lib or to toolchain\usr\bin\liblldb.dll but neither work. The error is: On Linux, the correct path is toolchain\usr\lib\liblldb.so.
No. Should I? |
|
I did manage to start a REPL by doing the additional steps mentioned on https://swift.org/getting-started/#using-the-repl, but it crashed on my first command: |
|
Ah, the "extra" stuff is getting Python into the path. That is part of why python is needed. The failure that you are seeing can be worked around (you need to copy the runtime into the toolchian). I haven't had time to look into why lldb is dropping |
There is no one correct answer to that, otherwise the tool would be pointless :) The correct value depends on your machine, time of installation, options selected during installation, method of installation, etc. Note that the release builds do not launch a shell, which makes it useless for setting the environment variable, you would need to build it from source. The values from the developer command prompt is the correct value for your machine at this time (it will also change over time).
The libs are import libraries, they are used for linking only. The runtime component is the dll, which is only used at runtime. Im not sure what pointing CodeLLDB is supposed to accomplish. Again, someone who has time to understand CodeLLDB's code base is probably better suited to figuring that out. For now, I would recommend that you use the command line.
Maybe? Creation of symbolic links is a privileged operation, however, setting into developer mode eases system restrictions (so, technically it is bad for a day-to-day user). If it is a symbolic link creation problem, that would potentially make the build type symlink show up. Also, now that I think about it - the error that you are mentioning might be due to this (that is your user does not have the rights to create the symbolic link and the error information is being lost during the bridging from NSError to Error (which was just recently fixed). |
Switching to developer mode did indeed fix this. I now have the debug symlink an no longer get that error from
I'm now running the latest version of However, I can build both a hello-word package and swift-devenv just fine without running Let me know if there's anything else I can try. If I find the time, I may also send some commits your way to update the instructions with what I've learned so far (so people watching this PR don't have to read this entire conversation). |
Interesting! Okay, that means that the stdout/stderr/stdin handles are in a weird state after the exec. That is rather unfortunate. There is no way to really do something like
Cool - are you using a developer command prompt or a plain command prompt? The former does not need devenv. The latter only needs it if you haven't tweaked your environment to set
That would be amazing! I think that getting someone who isn't as familiar with all the pieces is actually very important to getting documentation that others can use. I feel like every attempt that I've made at documenting this stuff runs into confusion from others. |
I tried both. It would be great if we could avoid the developer prompt all together. In VS Code, I rely on the built-in terminal a lot, so that too would have to support running I also want to avoid the overhead of having to launch VS Code from a shell, but I assume that's a way for VS Code to inherit the LIB and INCLUDE variables from the shell? But once
Yeah writing good documentation (like teaching) is really hard. 😅 |
Agreed, thats why I started devenv. Yes, the VS Developer Command prompt is just the standard command prompt with some scripts. The powershell vs cmd doesn't matter really - I routinely use SwiftPM in PowerShell. It is possible to have that work, its just a matter of configuring the environment variables. |
|
@compnerd Do you have a small code example that I can use to test the environment? That is, code that requires However, I did notice a few issues with console input and output:
I wrote a small snippet to illustrate these issues: In other news: I got the x64 VS Prompt working as the integrated terminal in Visual Studio Code :) The following options take care of that: I assume/hope the location of that vcvars64.bat file is fixed? This configuration could be helpful in running Finally, the version of Git that ships with Visual Studio seems to be outdated. I'm getting a lot of warnings about it, and even got an email from GitHub that this version will stop working after Nov. 13. That's strange, and will definitely confuse new users. |
|
W.r.t launching LLDB from the command line, it also complains about not finding Python37.dll, so I need to execute this first: It's strange that VS doesn't put Python on the |
Without having thought too much about it, I believe that the following program should be sufficient: import ucrt
public var alias = ucrt._readNote that pre-existing module caches might interfere with this. The alias is so ensure that you fail twice, once at compile time, once at link time.
That might be due to the line terminator. I would recommend that you use the "one true" (if I don't make light of the myriad of differences between Windows and Unix I will go insane - and I keep forgetting how many there are; I don't mean to be flippant or insulting) line terminator: "\r\n" rather than the beloved Unix one of "\n".
This is expected as you are printing in UTF-8. You should:
chcp 65001
That sounds really weird, I don't even have a guess as to what might be going on here. I'll try to see if I can manage to find some time to play around with your example. |
Well, that also works for me, even in a regular Command Prompt, without
But there is no explicit BTW: The weird I/O behavior I'm seeing from my apps is very similar (most likely identical) to what I'm getting from the new shell started by
I looked into using the new Windows Terminal instead, but it turns out that's an even bigger mess 😕 It makes a big deal out of emojis in its trailer (https://www.youtube.com/watch?v=8gw0rXPMMPE) but that doesn't even work out of the box and requires even more additional installation steps. Even worse, the Windows Terminal just shows an error upon launch. It only works if you first launch a different terminal, so that's not exactly going to help me... |
|
Hi @compnerd, I've downloaded the new (29/10) snapshot to see if that fixes any of the issues above. Unfortunately, that doesn't appear to be the case. However, I did notice something that may help you debug the I/O issue. I've noticed that this issue does not occur when I run an executable directly. That is: behaves correctly, but BTW: Let me know if I should file any of these issues on bugs.swift.org as well. |
|
I don't think that there's much that would've changed in the snapshot. I'm unable to reproduce the issue locally. But the issue you say only shows up with swift run? That sounds like the spawning isn't setting up the stdin/stdout pipes correctly. The emoji thing I think is that the string literal uses a literal emoji rather than the Unicode code point. The emoji gets converted to UTF-8, but doesn't convert to UTF-16 prior to printing. I think both of these are useful to report to bugs.swift.org for tracking purposes. |
|
FWIW: this is what Im seeing on Windows: The difference is that the console output needs to be put into UTF-8 mode, which perhaps we should do in the runtime. func readBool(question: String) -> Bool {
var answer: String
repeat {
print("\(question) (y/n): ", terminator: "")
answer = readLine()!
} while answer != "y" && answer != "n"
return answer == "y"
}
import WinSDK
_ = SetConsoleOutputCP(UINT(CP_UTF8))
while readBool(question: "Do you feel lucky? 🤨") { } |
|
Thanks @compnerd I've reported the following issues:
I think I have enough information now to start writing some instructions. However, I'm still looking for an example that does not compile without |
|
I believe that the initial WinSDK module compile and any subsequent use of C code should provide that case. Swift/Win32 or swift-nio are good candidate packages that should demonstrate the need for the environment variables. |
|
Well, I can compile code that uses WinSDK to set the code page just fine from a PowerShell without W.r.t. NIO, I'm not sure how I can test that. Which target should I try building? I tried building the NIO target but that failed, even in the x64 VS Prompt. Basically, I'm just trying to figure out what I should put in the installation instructions w.r.t. |
|
@compnerd I've sent a PR over to your fork with an attempt at user-friendly instructions. |
Improved instructions for Windows
|
@compnerd I'm merging this so others can start trying out the instructions. Can you ping me when something changes in Windows land and I should update the instructions? |
|
Also, any retweets for https://twitter.com/pwsacademy/status/1324660121084006401 are welcome, so we can actually get these instructions to people who want to test them 😅 |
2 participants
No description provided.