<html><head>
<meta content="text/html; charset=ISO-8859-15" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000">Just to make this clear
it's not my intention to blame anyone or point fingers.<br>
Given the resources at hand I think Phyx and you have done an amazing
job<br>
so far to keep things working!<br>
<br>
The core of the issue is that if someone sits down and installs a
"stable" GHC today he <br>
will either get a version that hangs on any dependency using TH (8.6.3)
or run into weird errors if he tries to profile an executable.<br>
Both of which I would call rather mundane development activities.<br>
<br>
But what I take issue with is not that there is some brokenness.<br>
It's how we deal with that fact from a user perspective.<br>
<br>
Pretty much all distribution channels currently provide 8.6.3 or 8.6.4
as stable.<br>
<br>
Haskell Platform:<br>
"The latest version of the Haskell Platform for Windows
is 8.6.3."<span style="color: rgb(51, 51, 51); font-family: "Source
Sans Pro",Helvetica,Arial,sans-serif; font-size: 16px; font-style:
normal; font-weight: 400; letter-spacing: normal; orphans: 2;
text-align: start; text-indent: 0px; text-transform: none; white-space:
normal; widows: 2; word-spacing: 0px; background-color: rgb(255, 255,
255); display: inline ! important; float: none;"></span><br>
<span style="color: rgb(51, 51, 51); font-family: "Source Sans
Pro",Helvetica,Arial,sans-serif; font-size: 16px; font-style:
normal; font-weight: 400; letter-spacing: normal; orphans: 2;
text-align: start; text-indent: 0px; text-transform: none; white-space:
normal; widows: 2; word-spacing: 0px; background-color: rgb(255, 255,
255); display: inline ! important; float: none;"></span>Stackage:<br>
* <a href="https://stackage.org/lts-13.13" style="color: rgb(0,
136, 204); text-decoration: none;">LTS 13.13 for GHC 8.6.4</a>,
published 3 days ago<br>
* <a href="https://stackage.org/lts-13.11" style="color: rgb(0,
136, 204); text-decoration: none;">LTS 13.11 for GHC 8.6.3</a>,
published a week ago<br>
haskell.org:<br>
Current Stable Release: 8.6.4<br>
<br>
And none of the download pages give any indication of issues. Neither
does the user guide.<br>
How much effort can we really expect from a user to find out something
basic like profiling or TH is simply broken<br>
in a release marked as stable?<br>
<br>
I've actually got hit by both issues despite at least following ghc
development somewhat.<br>
We don't have to be debian. But as a windows user a release being stable
has lost all meaning to me.<br>
<br>
And I imagine it's worse for people not looking behind the curtain.<br>
<br>
<span>Ben Gamari schrieb:</span><br>
<blockquote cite="mid:877eculki9.fsf@smart-cactus.org" type="cite">
<pre wrap="">Phyx <a class="moz-txt-link-rfc2396E" href="mailto:lonetiger@gmail.com"><lonetiger@gmail.com></a> writes:
</pre>
<blockquote type="cite"><pre wrap="">Hi Andreas,
GHC 8.6.4 not supporting profiling libs was the first thing mentioned in
the release email
- A regression resulting in segmentation faults on Windows introduced
by the fix for #16071 backported in 8.6.3. This fix has been reverted,
meaning that 8.6.4 is once again susceptible to #16071. #16071 will
be fixed in GHC 8.8.1.
It was also stated that it would be back in 8.8.1. At this point there
was no way to get profiling libs on 8.6.x without a major backport of
linker changes from master. The choice was made to revert the change
and release 8.6.4 without profiling libraries because of a stack
allocation bug that was dormant for years but completely killed the 32
bit distribution. That said the changelog linked to the wrong issue,
the second two should have been #15934 but that's not hard to figure
out by looking at the ticket.
</pre></blockquote>
<pre wrap=""><!---->I will reiterate that having functional profiling in 8.6.4 was never
in the cards (unless a contributor was willing to step up to backport
Phyx's linker patch).
However, I will also say that the fact that the omission of the
profiling libraries and haddock from the release tarball (#16408) was
not my intention. Rather this was an accidental side-effect of an
oversight in the release CI job. This is something I only realized
rather recently (leading to !516) and thought I would fix after when I
re-spun the Windows tarballs to include an i386 build.
In hindsight I should have advertised this more widely and perhaps even
pulled the bindist. However, in my defense I did not expect it to more
than a few days to get the fixes through CI and have a new set of
bindists ready for release. On the whole I agree that it is not fair to
users to expect them to discover this sort of thing by browsing the
issue tracker. This is something that I will improve on in the future.
In general I'm not sure how to handle signalling of release stability.
Tamar has done an absolutely amazing job keeping the Windows boat afloat
(and even improving it, c.f. his new IO manager), However, I cannot deny
that there are indeed issues, as evidenced by the fact that my patch
making Windows a mandatory-green CI platforms needs to disable quite a
number of flaky or failing tests. Should we be signalling that this is
stable? It's hard to say; many of these cases are rather niche. Needless
to say if there's consensus that this doesn't constitute a production
ready compiler then I will advocate adjusting the priorities of our
efforts at Well-Typed to put more weight on fixing the Windows issues.
Cheers,
- Ben
</pre>
</blockquote>
<br>
</body></html>