That is a good point. I am usually there in #ghc with nickname lemao.
Niklas is nh2 afaik.
On Sat, Sep 7, 2013 at 7:17 AM, Niklas Hambüchen m...@nh2.me wrote:
Would you mind hanging around in #ghc when working on it?
A few people found this interesting, so this might be useful to avoid
I'll be happy to give it a shot!
JP
On Fri, Sep 6, 2013 at 5:23 PM, Niklas Hambüchen m...@nh2.me wrote:
It looks to me that technically it should be easy to split off the part
required by GHC.
Maybe somebody could just try that (currently it does not seem to take
longer than a few hours)
Would you mind hanging around in #ghc when working on it?
A few people found this interesting, so this might be useful to avoid
duplicate effort.
On Sat 07 Sep 2013 18:24:43 JST, JP Moresmau wrote:
I'll be happy to give it a shot!
___
Haskell-Cafe
Hello all,
I have an issue that has been nagging me for a while, and I'd like to make
sure I haven't missed a solution to it.
I'm the maintainer for the buildwrapper package. This package has
dependencies on the Cabal and GHC libraries, and also uses the
cabal-install executable. For example it
I spent some time looking into the touch points between ghc and cabal in
the past, and the first oddity i saw was a direct dependency from ghc to
the cabal sources. After taking a closer look it seems that ghc shares some
common, low level modules with cabal that didnt seem to justify the whole
On Fri 06 Sep 2013 22:13:58 JST, Yuri de Wit wrote:
The right solution, imho, is to review these dependencies and move
the low level ones out into a separate package that is shared by both
ghc and cabal and that will rarely change. The direct side effect of
this is that ghc would not be tied
The right solution for Cabal would be not to know anything about the
GHC's database format at all.
GHC and cabal communicate via a command line interface (`ghc-pkg dump`
in our direction; `ghc-pkg update` in the other). So it would suffice to
have a library which implements parsing and printing
On 2013-09-06 at 15:13:58 +0200, Yuri de Wit wrote:
I spent some time looking into the touch points between ghc and cabal in
the past, and the first oddity i saw was a direct dependency from ghc to
the cabal sources. After taking a closer look it seems that ghc shares some
common, low level
On Fri 06 Sep 2013 22:52:40 JST, Roman Cheplyaka wrote:
The right solution for Cabal would be not to know anything about the
GHC's database format at all.
GHC and cabal communicate via a command line interface (`ghc-pkg dump`
in our direction; `ghc-pkg update` in the other). So it would
Interesting: in the ghc-devs discussion, Duncan talks about a cabal-lib and
a cabal-build-simple split (
http://www.haskell.org/pipermail/ghc-devs/2013-March/000821.html). That
would solve my problem nicely (GHC could depend on cabal-lib only, that
wouldn't have to change as often as
It looks to me that technically it should be easy to split off the part
required by GHC.
Maybe somebody could just try that (currently it does not seem to take
longer than a few hours) so that we have some basic proposal and momentum.
On 07/09/13 00:04, JP Moresmau wrote:
Oh, I'm happy to help
We just had a short discussion on #ghc, I copy-paste:
http://lpaste.net/92639
dcoutts_: nh2: Cabal does not depend on the ghc-pkg format. Cabal
specifies a compiler-independent package registration format. GHC uses
it in its external interface (and internally too). It uses the Cabal lib
for the
Oh, I'm happy to help as well if somebody is needed to do the change, since
I have much to win in the future if EclipseFP can take advantage of a new
version of Cabal without having to wait for a new GHC. The split in two
libraries that Duncan mentions seems the best approach to me, having
I'm willing to help in the process, if some directions were given to me on
how to tackle this problem.
In any case, for me is seems fine to have a dependency from cabal to ghc,
the only problem is the converse: ghc depending on cabal. Is this right?
2013/9/6 Herbert Valerio Riedel h...@gnu.org
Alejandro,
that is correct, as I see it. Duncan has very good points there but it
seems to me that we need a concrete proposal so we can propose solutions to
the problem. The fact is that the current situation is a middle of the
ground that doesn't help Cabal nor Ghc.
On Fri, Sep 6, 2013 at
I have filed a GHC ticket under
http://ghc.haskell.org/trac/ghc/ticket/8244
I hope this way we can find a solution soon.
On 07/09/13 00:04, JP Moresmau wrote:
Oh, I'm happy to help as well if somebody is needed to do the change,
since I have much to win in the future if EclipseFP can take
16 matches
Mail list logo
