Is it possible to offer Windows builds, please?

[ColourGrey]

Looking at the closed issues, it seems that some users had problems building MLton, either because of GMP, or of MinGW. This leads me to asking: would it be possible to offer "official" Windows binaries, together with their Linux and macOS counterparts?

It seems that some volunteers offered such binaries for some past releases, and there is even an official 20200817 Windows binary release, but all these efforts seem to be random and unreliable: sometimes they exist, some other times they don't (for instance, there is no 20210107 Windows binary release).

To top it, the mlton file is a bash script (yes!), therefore impossible to run under Windows (it should have been a .bat file, or any other equivalent in the Windows world).

[MatthewFluet]

Contributions to make MLton work better on Windows (under Cygwin or MinGW) are welcome. But, it is not a platform that I have easy access to (or the time to setup and maintain), which is why there are no recent official Windows binary releases.

[ColourGrey]

I understand, and I was also expecting this answer. It is sad, because MLton is an exceptional piece of work, but it seems to be on its way to a slow, painless death. For historical reasons not relevant to the discussion, SML lost the race (despite being a truly remarkable language). Its hayday seems to have been in the '90s (like for Scheme, Smalltalk or Forth). Most of its creators have retired from the academia, and the industry has moved on. With SML relegated to the corner of the room, not offering its most brilliant compiler on the most deployed and popular platform worldwide (Windows) looks suicidal. (Sigh...)

I cannot not notice that for more than a decade MLton has been a one man effort; SML/NJ a 2-3 men effort; Poly/ML again a 1 man effort. The same is true for MLKit or MoscowML. The fact that all these (few) people are not willing to communicate and join forces around a single implementation, preferring instead to fragment an already tiny community even further around several competing, half-baked, often buggy and poorly maintained implementations, is bad omen for the future of SML. Boy, does it look like the Scheme landscape! (Sigh, again...)

[eatonphil]

For what it's worth, any public Github project can freely use Windows build boxes on Github actions. I set this up on a recent project.

Maybe someone adding Windows to the Mac and Linux CI you've already got on Github Actions would be a good first step.

It doesn't seem like MLton yet uses Github Actions to build and publish the release artifacts but that's something folks could look into too.

[MatthewFluet]

Yes, I just tried out GitHub Actions over the last few days. I'd certainly like to automate more of the release process and including Windows with that would be nice. Pull requests welcome!

[lassik]

Languages based around a standard may look like a good or bad idea any given year, depending on where we are in the fashion cycle, but they are a better long-term bet than languages defined by a single implementation.

This guy looks like a SML-on-Windows expert, but it's not clear whether he still has an active interest in the language.

[ColourGrey]

@lassik Thank you for the link, I have no idea about what web search magic you've done to stumble on a guy with such an exotic CV! Notice, though, that most of the ML links on his site are dead, and that his instructions about building and cross-compiling date from 2002.

[eatonphil]

Now that there's a compile-for-Windows step in CI, feel free to steal from these upload-to-release-page steps: https://github.com/multiprocessio/datastation/blob/master/.github/workflows/releases.yml.

This file gets run only when a Github release is created. It doesn't use any external Github Action dependencies it just curls to upload the artifact to the release page with a token that's always part of Github Actions.

For example:

build-macos:
    runs-on: macos-latest

    steps:
    - uses: actions/checkout@master
      with:
        ref: ${{ github.ref }}

    - run: ./scripts/ci/prepare_macos.sh
    - run: echo "GIT_TAG=`git tag --points-at HEAD`" >> $GITHUB_ENV
    - run: |
        echo "RELEASE_ID=`curl -H 'Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}' https://api.github.com/repos/multiprocessio/datastation/releases/tags/$GIT_TAG | jq '.id'`" >> $GITHUB_ENV
    - run: yarn release-desktop $GIT_TAG
    - name: Upload release
      run: |
        curl --fail \
          -H "Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" \
          -H "Content-Type: application/zip" \
          --data-binary @./releases/darwin-x64-$GIT_TAG.zip \
          "https://uploads.github.com/repos/multiprocessio/datastation/releases/$RELEASE_ID/assets?name=darwin-x64-$GIT_TAG.zip"

But the syntax differs slightly on Windows so that's why I point you at my already working example.

My project supports Linux, Windows, and macOS. Again, please steal from it!

Looking forward to having automated release builds!

[MatthewFluet]

@eatonphil Thanks for the pointers. It's on a TODO to automatically build and upload a release

[mingodad]

I have a github action that also make the build result available to be downloaded here https://github.com/mingodad/picat/actions/runs/1974144875/workflow .

The key lines start here https://github.com/mingodad/picat/actions/runs/1974144875/workflow#L162

# upload artifact, picat binary
    - name: Upload Picat-windows-amd64 binary OnWindows
      uses: actions/upload-artifact@v1
      with:
        name: download picat-windows-amd64.exe (built on windows VM)
        path: picat-windows-amd64.exe

And here https://github.com/mingodad/cyclone/actions/runs/1779440434/workflow I also create a tar file of the build install and upload it.

I hope this can help.