[Haskell-cafe] Build regressions due to GHC 7.6

[Erik Hesselink]

Note that this does not work if you want to support multiple versions
of GHC, and might not work in general, since

* The hiding of catch is needed for preludes that still have it, since
otherwise it will probably conflict with the one from
Control.Exception.
* Older versions do not have constructors for the FFI types, leading
to warnings (or errors, I'm not sure).
* Packages might not work with the new bytestring version, since the
API has breaking changes (although they're supposed to be minor).

For the first two, you need to add some CPP, for the last, you need
actual testing.

Erik

On Thu, Aug 30, 2012 at 3:03 PM, Alexander Kjeldaas
<alexander.kjeldaas at gmail.com> wrote:
> This is very unfortunate, but this is crucially a tooling issue.  I am going
> to wave my hands, but..
>
> Ignore the mapreduce in the following video, but look at the use of clang to
> do automatic refactoring of C++.  This is *incredibly* powerful in dealing
> with updates to APIs.
>
> http://www.llvm.org/devmtg/2011-11/videos/Carruth_ClangMapReduce-desktop.mp4
>
> But without all that fancy tech, *just* having all of Hackage source code in
> one repository and using perl/regexps, fixing these types of issues is O(1)
> instead of O(n).
>
> All of the issues you mention seems to be fixable by a few lines of perl *if
> we had the repository*.
>
> [a few hours later]
>
> Actually, I went and downloaded all of hackage, put it into a git repository
> and fixed these issues:
>
> Fix catch
> perl -ni -e 'print unless /import Prelude hiding \(catch\)/' $(git grep
> 'import Prelude hiding (catch)')
>
> Fix CInt constructors (lots of other stuff from Foreign.C.Types not fixed
> though)
> perl -p -i -e 's/^import Foreign.C.Types(.*)CInt([^(])/import
> Foreign.C.Types${1}CInt(..)${1}/g' $(git grep -l '^import.*CInt')
>
> Fix bytestring versioning
> perl -p -i -e 's/bytestring( +)>=([0-9. &]+)<([
> ]*)0.10/bytestring$1>=$2<${3}0.11/g' $(git grep 'bytestring.*< *0\.')
>
> Patch to hackage:
> http://ge.tt/6Cb5ErM/v/0
>
> I understand that this doesn't help anyone, but if there was a way fix,
> upload, and get *consensus* on a few regexps like this, then doing API
> changes wouldn't be such a headache.
>
> Alexander
>
> On 30 August 2012 07:26, Bryan O'Sullivan <bos at serpentine.com> wrote:
>>
>> Since the release of the GHC 7.6 RC, I've been going through my packages
>> and fixing up build problems so that people who upgrade to 7.6 will have a
>> smooth ride.
>>
>> Sad to say, my experience of 7.6 is that it has felt like a particularly
>> rough release for backwards incompatibility. I wanted to quantify the pain,
>> so I did some research, and here's what I found.
>>
>> I maintain 25 open source Haskell packages. Of these, the majority have
>> needed updates due to the GHC 7.6 release:
>>
>> base16-bytestring
>> blaze-textual
>> bloomfilter
>> configurator
>> criterion
>> double-conversion
>> filemanip
>> HDBC-mysql
>> mwc-random
>> pcap
>> pool
>> riak-haskell-client
>> snappy
>> text
>> text-format
>> text-icu
>>
>> That's 16 out of 25 packages I've had to update. I've also either reported
>> bugs on, or had to fix, several other people's packages along the way (maybe
>> four?). So let's say I've run into problems with 20 out of the combined 29
>> packages of mine and my upstreams.
>>
>> The reasons for these problems fall into three bins:
>>
>> Prelude no longer exports catch, so a lot of "import Prelude hiding
>> (catch)" had to change.
>> The FFI now requires constructors to be visible, so "CInt" has to be
>> imported as "CInt(..)".
>> bytestring finally got bumped to 0.10, so many upper bounds had to be
>> relaxed (cf my suggestion that the upper-bounds-by-default policy is
>> destructive).
>>
>> It has been a lot of work to test 29 packages, and then modify, rebuild,
>> and release 20 of them. It has consumed most of my limited free time for
>> almost two weeks. Worse, this has felt like make-work, of no practical
>> benefit to anyone beyond scrambling to restore the status quo ante.
>>
>> If over half of my packages needed fixing, I'm alarmed at the thought of
>> the effects on the rest of Hackage.
>>
>> I'm torn over this. I understand and agree with the impetus to improve the
>> platform by tidying things up, and yet just two seemingly innocuous changes
>> (catch and FFI) have forced me to do a bunch of running to stand still.
>>
>> I don't have any suggestions about what to do; I know that it's hard to
>> estimate the downstream effects of what look like small changes. And so I'm
>> not exactly complaining. Call this an unhappy data point.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>