<div><br></div>I think you're making this way harder than it really is.<div><br></div><div>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.</div>
<div><br></div><div>Thus for every dependency there is only one possible version - the latest one, and there are only a couple of compilers.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Alexander</div><div><br></div><div><div class="gmail_quote">On 30 August 2012 22:26, Jay Sulzberger <span dir="ltr"><<a href="mailto:jays@panix.com" target="_blank">jays@panix.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
On Thu, 30 Aug 2012, Alexander Kjeldaas <<a href="mailto:alexander.kjeldaas@gmail.com" target="_blank">alexander.kjeldaas@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is very unfortunate, but this is crucially a tooling issue. I am<br>
going to wave my hands, but..<br>
<br>
Ignore the mapreduce in the following video, but look at the use of clang<br>
to do automatic refactoring of C++. This is *incredibly* powerful in<br>
dealing with updates to APIs.<br>
<br>
<a href="http://www.llvm.org/devmtg/2011-11/videos/Carruth_ClangMapReduce-desktop.mp4" target="_blank">http://www.llvm.org/devmtg/<u></u>2011-11/videos/Carruth_<u></u>ClangMapReduce-desktop.mp4</a><br>
<br>
But without all that fancy tech, *just* having all of Hackage source code<br>
in one repository and using perl/regexps, fixing these types of issues is<br>
O(1) instead of O(n).<br>
<br>
All of the issues you mention seems to be fixable by a few lines of perl<br>
*if we had the repository*.<br>
</blockquote>
<br></div>
Better to do this with sexps.<br>
<br>
ad repositories: Part of the general problem of managing a<br>
repository is close to the problem of inferring a good type for<br>
(the value of) an expression. The style of constraints is<br>
similar. Now the design problem is:<br>
<br>
1. Arrange a general system for the specification of the<br>
constraints.<br>
<br>
2. Design a systematic way of giving both advice and direct<br>
commands to the system. This subsystem would be used to set<br>
up the default policy.<br>
<br>
3. Choose a constraint solver.<br>
<br>
Maybe worth looking at:<br>
<br>
<a href="http://en.wikipedia.org/wiki/Nix_package_manager" target="_blank">http://en.wikipedia.org/wiki/<u></u>Nix_package_manager</a><br>
[page was last modified on 17 July 2012 at 20:20]<br>
<br>
oo--JS.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<br>
[a few hours later]<br>
<br>
Actually, I went and downloaded all of hackage, put it into a git<br>
repository and fixed these issues:<br>
<br>
Fix catch<br>
perl -ni -e 'print unless /import Prelude hiding \(catch\)/' $(git grep<br>
'import Prelude hiding (catch)')<br>
<br>
Fix CInt constructors (lots of other stuff from Foreign.C.Types not fixed<br>
though)<br>
perl -p -i -e 's/^import Foreign.C.Types(.*)CInt([^(])/<u></u>import<br>
Foreign.C.Types${1}CInt(..)${<u></u>1}/g' $(git grep -l '^import.*CInt')<br>
<br>
Fix bytestring versioning<br>
perl -p -i -e 's/bytestring( +)>=([0-9. &]+)<([<br>
]*)0.10/bytestring$1>=$2<${3}<u></u>0.11/g' $(git grep 'bytestring.*< *0\.')<br>
<br>
Patch to hackage:<br>
<a href="http://ge.tt/6Cb5ErM/v/0" target="_blank">http://ge.tt/6Cb5ErM/v/0</a><br>
<br>
I understand that this doesn't help anyone, but if there was a way fix,<br>
upload, and get *consensus* on a few regexps like this, then doing API<br>
changes wouldn't be such a headache.<br>
<br>
Alexander<br>
<br>
On 30 August 2012 07:26, Bryan O'Sullivan <<a href="mailto:bos@serpentine.com" target="_blank">bos@serpentine.com</a>> wrote:<br>
<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Since the release of the GHC 7.6 RC, I've been going through my packages<br>
and fixing up build problems so that people who upgrade to 7.6 will have a<br>
smooth ride.<br>
<br>
Sad to say, my experience of 7.6 is that it has felt like a particularly<br>
rough release for backwards incompatibility. I wanted to quantify the pain,<br>
so I did some research, and here's what I found.<br>
<br>
I maintain 25 open source Haskell packages. Of these, the majority have<br>
needed updates due to the GHC 7.6 release:<br>
<br></div></div>
- base16-bytestring<br>
- blaze-textual<br>
- bloomfilter<br>
- configurator<br>
- criterion<br>
- double-conversion<br>
- filemanip<br>
- HDBC-mysql<br>
- mwc-random<br>
- pcap<br>
- pool<br>
- riak-haskell-client<br>
- snappy<br>
- text<br>
- text-format<br>
- text-icu<div class="im"><br>
<br>
That's 16 out of 25 packages I've had to update. I've also either reported<br>
bugs on, or had to fix, several other people's packages along the way<br>
(maybe four?). So let's say I've run into problems with 20 out of the<br>
combined 29 packages of mine and my upstreams.<br>
<br>
The reasons for these problems fall into three bins:<br>
<br></div>
- Prelude no longer exports catch, so a lot of "import Prelude hiding<br>
(catch)" had to change.<br>
- The FFI now requires constructors to be visible, so "CInt" has to be<br>
imported as "CInt(..)".<br>
- bytestring finally got bumped to 0.10, so many upper bounds had to<br>
be relaxed (*cf* my suggestion that the upper-bounds-by-default policy<div class="im"><br>
is destructive).<br>
<br>
It has been a lot of work to test 29 packages, and then modify, rebuild,<br>
and release 20 of them. It has consumed most of my limited free time for<br>
almost two weeks. Worse, this has felt like make-work, of no practical<br>
benefit to anyone beyond scrambling to restore the status quo ante.<br>
<br>
If over half of my packages needed fixing, I'm alarmed at the thought of<br>
the effects on the rest of Hackage.<br>
<br>
I'm torn over this. I understand and agree with the impetus to improve the<br>
platform by tidying things up, and yet just two seemingly innocuous changes<br>
(catch and FFI) have forced me to do a bunch of running to stand still.<br>
<br>
I don't have any suggestions about what to do; I know that it's hard to<br>
estimate the downstream effects of what look like small changes. And so I'm<br>
not exactly complaining. Call this an unhappy data point.<br>
<br>
______________________________<u></u>_________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/haskell-cafe</a><br>
<br>
<br>
</div></blockquote>
<br>
</blockquote><div class="HOEnZb"><div class="h5">
<br>
______________________________<u></u>_________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>