[Haskell-cafe] Build regressions due to GHC 7.6

[Alexander Kjeldaas]

I think you're making this way harder than it really is.

What 99% of people need is that hackage packages builds with the latest
haskell platform, and/or with bleeding edge ghc, and with the latest
versions of its dependencies.

Thus for every dependency there is only one possible version - the latest
one, and there are only a couple of compilers.

Having "special interest groups" for ghc 6.12 support and old versions of
text is fine, but I think it is a pretty uninteresting problem to solve.

Likewise, supporting/fixing packages where the author for some reason
*requires* use of a non-current version of some other package is also quite
uninteresting (or at least outside the scope of my needs).   Such a package
is basically just a relic.

Alexander

On 30 August 2012 22:26, Jay Sulzberger <jays at panix.com> wrote:

>
>
> 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<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<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<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<http://www.haskell.org/mailman/listinfo/haskell-cafe>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120831/49fed9cd/attachment.htm>