Thanks again for the detailed reply Ben.
I guess the other dream of mine is to give GHC a .NET backend. For my
problem it would be the ideal solution, but it looks like other attempts in
this regard (e.g. Eta, GHCJS etc) seem to have difficulty keeping up with
updates to GHC. So I'm sure it's not
Clinton Mead writes:
> Thanks all for your replies. Just going through what Ben has said step by
> step:
>
> My sense is that if you don't need the threaded runtime system it would
>> probably be easiest to just try to make a modern GHC run on Windows XP.
>>
>
> Happy to run non-threaded runtime.
Clinton Mead writes:
> Another gotcha that I didn't think of. The machines I'm targeting often
> have 32 bit versions of Windows, which it looks like isn't supported after
> GHC 8.6.
>
> Does this move it into the too hard basket?
Ooph, yeah, this makes matters a bit worse. The reason we
ultimat
Thanks for this update! Glad to know this effort is going well.
One quick question: suppose I am editing something in `base`. My understanding
is that my edit will be linted. How can I run hlint locally so that I can
easily respond to trouble before CI takes a crack? And where would I learn this
Another gotcha that I didn't think of. The machines I'm targeting often
have 32 bit versions of Windows, which it looks like isn't supported after
GHC 8.6.
Does this move it into the too hard basket?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://
Hello fellow devs,
this email is an activity report on the integration of the HLint[0] tool
in the Continuous Integration (CI) pipelines.
On Jul. 5, 2020 I opened a discussion ticket[1] on the topic of code
linting in the several components of the GHC code-base. It has served as
a reference