[Haskell-cafe] Build regressions due to GHC 7.6
Alexander Kjeldaas
alexander.kjeldaas at gmail.com
Thu Aug 30 15:03:05 CEST 2012
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120830/023005f5/attachment.htm>
More information about the Haskell-Cafe
mailing list