-
-
Notifications
You must be signed in to change notification settings - Fork 382
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.
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
Make mill -i
to default under Windows OS
#781
Comments
Mostly fixed in #791 😃 |
Is there any chance of getting some more background as to what the issue here is? |
What if you are not running on WSL for windows. I'm also trying to get this working at a powershell or cmd prompt. Things work with -i , but why is it needed? |
You'll have to investigate and tell us if it's needed or not, and why. |
If I could understand a bit more what Also it should be noted that |
Mill |
Various fixes only shown on Windows, probably also elsewhere. * Fixed string stream writer/reader used for mill client-server communication, by using an explicit charset for byte conversion * Avoid `java.nio.file.Paths.get(url.getFile())` in favour of `java.nio.file.Paths.get(url.toURI())` as the latter handles windows paths with leading drive letters well * Improved CI setup for Windows * Better run/spawn of Java sub-processes by selecting the same Java executable which is used by mill We still have some CI failures on Windows, as we need some of these fixed in mill before we can benefit from it. Expect more PRs. Probably related issues: * #781 * #874 * #646 * #1098 Commits: * CI: Added test on Windows * Try a better handing of windows absolute paths I hope to avoid a error like: Illegal char <:> at index 2: /D:/a/mill/mill/ * Improve string assertion message? * More details in assertion error * Use explicit charset for string-byte conversion * Search java exe in same JAVA_HOME as mill is using * CI: job deps * check for Win * Debug run java process Pull request: #1146
@DamianReeves I did some fixing in #1230 |
Just doing a little more testing (running mill at the same time on two different projects). I didn't look into the "locked pipe" stuff, but I thought each server/worker gets its own directory. Package structure of the workers looks the same in MacOS and Windows anyway.... so I'd guesss each package could have 5 independent servers/workers. |
@sake92 Thanks for your merge! I don't see the error you mentioned 🎉 |
@IdiosApps now we use junixsocket library which supports native Windows10 implementation of UNIX pipes, so it is much more reliable, thankfully. Glad you confirmed everything works! 🥳 Btw, you get at most 5 servers worker per JVM+project_path (if one is busy, another one will be instantiated). |
@sake92 Nice, I'll have a little look into UNIX pipes. I'm not sure what they are in this context - I guess like sockets, from what I've seen. Ah that makes sense, thank you for the explanation and the link! I was curious about worker folders today when looking into this issue I opened. |
Closing this one, as Windows now properly supports client-server-mode. Also Mill in general is able to recover from am failing server connection by running in-process. |
AFAIK, mill under Windows will only work when started with
-i
option. Until someone comes with proper fix it makes much sense to disable mill server mode under Windows.See discussion https://gitter.im/lihaoyi/mill?at=5e5c146fd045e2582509fba4
The text was updated successfully, but these errors were encountered: