[Haskell-cafe] Build regressions due to GHC 7.6

[Jay Sulzberger]

On Thu, 30 Aug 2012, 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*.

Better to do this with sexps.

ad repositories: Part of the general problem of managing a
repository is close to the problem of inferring a good type for
(the value of) an expression.  The style of constraints is
similar.  Now the design problem is:

1. Arrange a general system for the specification of the
    constraints.

2. Design a systematic way of giving both advice and direct
    commands to the system.  This subsystem would be used to set
    up the default policy.

3. Choose a constraint solver.

Maybe worth looking at:

   http://en.wikipedia.org/wiki/Nix_package_manager
   [page was last modified on 17 July 2012 at 20:20]

oo--JS.


>
> [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
>>
>>
>