Please provide Windows binaries #6
Comments
|
+1 |
|
Has anyone tried building on Cygwin in the meantime? Looks like OCaml supports it: https://ocaml.org/docs/install.html#Windows Edit: If I delete the include and the syscall, I'm stumped because I'm on 32-bit Windows and integers overflow all over the place. |
|
Looks like OCPWin might be the way to go. Looking into it. |
|
+1 |
|
There is actually no issue at all with compiling the OCaml part of "flow" on Windows. The following file (copied in |
|
So, porting "flow" is only a matter of porting the 7 files in C... |
|
There really are 3 main pieces of Flow and Hack that are platform specific
This is something we'd like to do sometime in the next year, but if someone wants to take a stab at it we'd be more than happy to take the PR :) |
Maybe we can postpone that for now. We can build manually for now. But at least should do the work (: |
|
From what I saw, there is no need to port part 2. (libelf/mach-o), as "flow" will also look up for "flowlib.tar.gz" in its environment (in the parent dir of its executable...). So, inotify and mmap... already quite some work ! |
|
Yeah, if you don't run the server as daemon, you don't need the file watching. And you can probably just stick the gzip'd libraries next to the binary and with a little hacking you don't need the embedded libraries stuff. The shared memory part is a little trickier, but we've had success working around it for simple in-browser playground sorts of things. For example, the Hack tutorial runs the Hack typechecker in the browser without the shared memory stuff. |
|
+1 |
|
Flow looks like an improvement over TypesScript, would be great if it would run on Windows! |
|
+1 |
|
@gabelevi: any hint on the trick to get rid of the shared memory stuff ? |
|
+1 It would be great to see this as a competitor to TypeScript, but Windows support is necessary for that. |
|
@lefessan So the way Hack compiles to JS is that it replaces a few things with simplified versions. So normally Hack uses sharedMem.ml which calls to external C functions. However, when we compile it to JS, it instead uses a different sharedMem.ml which is greatly simplified and doesn't call into C. |
|
I used ocpwin to compile a very simplified version for Windows. Still a lot of work to do to get a fully working version ! How to use it : On Cygwin (you must use it for now) The server has been removed, so it probably only works with: I hope it is enough to play with Flow on Windows, while waiting for an official Windows version... |
|
@lefessan cool! Thanks, much appreciated. |
|
@lefessan cool +1 |
|
I uploaded a new version: Now, it should behave as the linux/macosx client, but without any multicore support. Works without Cygwin. Feedback welcome ! |
|
+1. I was disappointed I couldn't try out flow. Is there word of an official stance or timeline? is win support a priority? it salads strikes me as odd when any new large web oss project is not cross platform. Why wasn't a tool choosen from the beginning (cough node) that handled what's seems to be fairly simple platform deps? also for a lot Windows devs something a cygwin dep is a complete non-standard. looking forward to trying this out eventually! it would be helpful to know when that might be :P |
|
@jquense: portability is an issue, but writing a type-checker is a much harder issue (don't even think about doing it in Javascript...). So, they chose the best tool (OCaml) for the hardest problem, and they left porting as an easy problem... and indeed, it took us only two days to have a working Windows version (ok, no multicore and persistent state, the code is uggly, and it's not official, but it works !). |
|
@jquense linux or osx share a common root and it is pretty easy to port between them. Windows is always a different beast, same happened with git, node etc. It will take a while, of course you can jump in and try to submit patches to get windows upto speed. |
|
@lefessan @pradeepcodes perhaps i came off as overly whiny, I didn't mean to pout. I mostly just wondering what the official stance is on win support. I realize the nix/osx are an easy port, and that windows if a different animal, i wasn't trying to say that it is easy to build something that meets the needs and is cross platform. My concern is more that when projects don't have cross-platform support as a priority from the beginning, the porting story is usually pretty bad for a long while (node is a good example). I am just wondering what the flow team's position on this is, and whether getting windows support first class is even something they care about. It helps me and my team when we know that flow will eventually be first class on windows, or its always going to be a "if ppl send the prs we'll merge them" sort of a support |
|
From WebStorm 12 Roadmap:
Can't blame them, since the last commit to https://github.com/OCamlPro/flow is now more than half a year ago. Flowtype is an amazing feat of software engineering, the best type inference I've ever seen; but its governance & management is horrible. |
|
As a side note it might be worth to check babel plugin which turns flow type annotations into runtime checks. I know it works different than flow, but idea is quite interesting - https://github.com/codemix/babel-plugin-typecheck. |
|
A lot of activity in twitter about windows support, so an official response from the team would be very appreciated 😃 |
|
|
|
Another weird "workaround" is to rely on this babel plugin https://github.com/codemix/babel-plugin-typecheck to use the flow notation to provide a similar static checking (and also can be done on runtime). Better than nothing. Until Flow has official Windows binaries (and I am seeing someone assigned a few days ago \o/), the best solution seems to use the docker image https://github.com/motiz88/flow-docker since windows bins are tricky and even more out of date than the docker images. |
|
+1 |
|
You can build the latest version directly with OCAML win: https://gist.github.com/oviava/9c7f0a5ec2fdcdc737b0a75239e6546f |
|
@oviava - yep, as you've noticed Windows support is getting closer! It builds and mostly works, but I wouldn't recommend it quite yet. |
|
I successfully build flow on windows too (wasn't able 2 days ago) so there is definetly good stuff coming. |
|
I just published an unofficial Flow Windows binary (based on master branch so sort of ~0.27) https://gist.github.com/MoOx/2eabc75477a80b4dd137d0d8cb16f95d I will try to keep it up to date until this issue is closed. |
|
@MoOx That's great, although you may want to move the download to another site than Sendspace because Windows Defender flagged the zip as a virus :/ |
|
@cecilemuller Any recommendation? I don't usually send zip online :D |
|
@MoOx Dropbox , Google Drive or Github Releases should work :) |
|
I updated the gist with a link to a Google Drive folder where I will push builds :) |
|
Awesome :) |
|
Works a charm 👍 |
|
What @MoOx is doing is awesome However we still really need an official build from @OCamlPro-Bozman or @OCamlPro-Henry so that @sindresorhus will push Windows support into the official NPM stuff. |
|
flow-bin are currently handled by flow team members. That's why I published this unofficial build (I just integrated a team that mostly work on windows and I don't want to wait - I can't live without flow now I tried). |
|
Thanks. That's why I opened the issue, and why I raised it here again today - to make sure that people remember there's still a big goal ahead for serious windows dev |
|
Good news everyone! Windows support is here! Huge props to the OCamlPro team for their great work porting the tricky parts of Flow to Windows! It's my great pleasure to finally close out this issue! If anyone finds bugs in the Windows binary, please create new issues! |
|
@gabelevi - Thank you kindly |
|
@gabelevi thank you so much for the awesome work! You guys and the OCaml team are amazing <3 |
and others
There's a whole lot of Windows developers out there who would love to use this too, and who will contribute based on it.
The text was updated successfully, but these errors were encountered: