Simon Marlow:
Claus Reinke wrote:
Yes you need to re-install Haddock if you re-install GHC, but
that's just like any other library (think of Haddock as a
library). I think it's unlikely that anyone will want to have
multiple Haddock installations, but if they do then they'll just
have to
On Thu, Aug 28, 2008 at 10:48:03AM +1000, Manuel M T Chakravarty wrote:
> Ian Lynagh:
> >Given the plan to change the build system, we've decided not to spend
> >time fixing bindist for the current build system, and thus not to
> >fix it
> >for the 6.10 release.
>
> That means that there will be
Ian Lynagh:
Given the plan to change the build system, we've decided not to spend
time fixing bindist for the current build system, and thus not to
fix it
for the 6.10 release.
That means that there will be no Mac OS X installer packages for 6.10
either (it uses the bindist target as part
duncan.coutts:
> On Wed, 2008-08-27 at 12:53 -0700, Don Stewart wrote:
>
> > A draft "meta package" for the platform is here,
> >
> > http://code.haskell.org/haskell-platform/haskell-platform.cabal
> >
> > This would allow us to:
> >
> > cabal install haskell-platform
> >
> > and use c
On Wed, 2008-08-27 at 12:53 -0700, Don Stewart wrote:
> A draft "meta package" for the platform is here,
>
> http://code.haskell.org/haskell-platform/haskell-platform.cabal
>
> This would allow us to:
>
> cabal install haskell-platform
>
> and use cabal to track dependencies.
This now
This is the first time I've looked at (b), so I don't mind it going,
but the syntax info deserves its own section, to be easy to find
without blowing up the flag reference section.
I just wanted to throw in a reference to
http://hackage.haskell.org/trac/ghc/ticket/1880
Unify flag descrip
Hi,
I'm getting the above error message when trying to build HEAD on
OpenBSD. This happens when running cabal-bin ... configure in
./compiler for stage1.
After running cabal-bin ... configure --verbose=3 ..., the problem boils
down to a wrong invocation of /usr/bin/ld:
Configuring ghc-6.9...
Cr
Build description = HEAD on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
Build location= /playpen/simonmar/nightly/HEAD
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx
Nightly build started on cam-02-unx at Wed Aug 27 18:02:06 BST 2008.
checking out
simonpj:
> Don, Duncan
>
> As you know, we're planning to produce GHC 6.10 with "batteries not
> included", relying on the Haskell Platform for the batteries. We are
> working v hard to get 6.10 ready for release-candidate on 19 Sept.
>
> But http://www.haskell.org/haskellwiki/Haskell_Platform s
On Wed, 2008-08-27 at 16:43 +0100, Simon Peyton-Jones wrote:
> | The documentation should also appear in:
> |
> |
> http://hackage.haskell.org/packages/archive/Cabal/1.4.0.1/doc/html/Language-Haskell-Extension.html
> |
> | It might be easier if the information was duplicated there, as then it
> |
Wed Aug 27 10:09:15 PDT 2008 [EMAIL PROTECTED]
* Update output to follow comments
M ./tests/ghc-regress/typecheck/should_fail/T2538.stderr -3 +3
View patch online:
http://darcs.haskell.org/testsuite/_darcs/patches/20080827170915-f1c6d-615e574198450c9d1c39f12ec20151dc6c886428.gz
__
(the patch could also have put a lower bound on the base dep, so that
people trying to install it with an older GHC would get a clearer
error, but that wouldn't help it build with the HEAD)
Another option would have been to put a <4 upper bound on the base dep,
but (a) I don't think base3-compat
Wed Aug 27 08:50:41 PDT 2008 [EMAIL PROTECTED]
* Track error message changes
M ./tests/ghc-regress/indexed-types/should_fail/Simple15.stderr +1
M ./tests/ghc-regress/typecheck/should_fail/tcfail113.stderr +14
M ./tests/ghc-regress/typecheck/should_fail/tcfail127.stderr +1
M ./te
Wed Aug 27 08:50:21 PDT 2008 [EMAIL PROTECTED]
* Test Trac #2538
A ./tests/ghc-regress/typecheck/should_fail/T2538.hs
A ./tests/ghc-regress/typecheck/should_fail/T2538.stderr
M ./tests/ghc-regress/typecheck/should_fail/all.T +1
View patch online:
http://darcs.haskell.org/testsuite/
Wed Aug 27 08:44:31 PDT 2008 [EMAIL PROTECTED]
* Test for Trac #2520
A ./tests/ghc-regress/simplCore/should_compile/T2520.hs
M ./tests/ghc-regress/simplCore/should_compile/all.T +1
View patch online:
http://darcs.haskell.org/testsuite/_darcs/patches/20080827154431-f1c6d-5f56216de3c28dc
Tue Aug 26 05:19:19 PDT 2008 [EMAIL PROTECTED]
* Add test for Trac #2497, #2213, #2494
A ./tests/ghc-regress/typecheck/should_compile/T2497.hs
A ./tests/ghc-regress/typecheck/should_compile/T2497.stderr
M ./tests/ghc-regress/typecheck/should_compile/all.T +1
View patch online:
http
> | It might be easier if the information was duplicated there, as then it
> | would be hoogle-able (although making the GHC manual hoogle-able is on
> | the Hoogle bug list
>
> I don't know how it gets there... GHC might have more extensions than Cabal
> for
> example? Anyway, I'm perhaps-selfi
| The documentation should also appear in:
|
|
http://hackage.haskell.org/packages/archive/Cabal/1.4.0.1/doc/html/Language-Haskell-Extension.html
|
| It might be easier if the information was duplicated there, as then it
| would be hoogle-able (although making the GHC manual hoogle-able is on
| th
Hi
> The documentation for language extensions appears in GHC's user manual in
> *three* places:
>
> (a) The flag summary
> http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id352860
>
> (b) A section at the beginning of Chapter 8:
> http://www.haskell.org/ghc/docs/lat
Wed Aug 27 08:33:22 PDT 2008 [EMAIL PROTECTED]
* Fix Trac #745: improve error recoevery for type signatures
It turns out that fixing Trac #745 is easy using mapAndRecoverM,
and tidies up the code nicely in several places. Hurrah.
M ./compiler/typecheck/TcBinds.lhs -1 +1
M ./c
Wed Aug 27 08:30:51 PDT 2008 [EMAIL PROTECTED]
* Fix Trac #2538: better error messages when validating types
This fix solely concerns error messages, and uses a bit of contextual
information to suggest plausible flags.
It was rather more fiddly to implement than I expected. Oh we
Wed Aug 27 08:27:28 PDT 2008 [EMAIL PROTECTED]
* Fix Trac #2520: duplicate symbols
The problem here was that were were quantifying over an *External* Name,
which causes no end of confusion. See Note [Const rule dicts] in DsBinds.
The fix is very easy, I'm happy to say.
M
Wed Aug 27 08:25:40 PDT 2008 [EMAIL PROTECTED]
* Only specialise on dictionaries that have some interesting structure
I discovered by accident that we were generating utterly useless
specialisations. See Note [Interesting dictionary arguments] in Specialise.
This patch used SimplUti
Wed Aug 27 08:19:26 PDT 2008 [EMAIL PROTECTED]
* Better documentation for -XLiberalTypeSynonyms, and steal forall keyword
In my travels through the front end I discoverd that -XLiberalTypeSynonyms is
rather thinly described. Furthermore, it alleges that you can write a
forall on the
Wed Aug 27 02:14:39 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* update output
M ./tests/ghc-regress/ghci.debugger/scripts/list001.stdout -1 +2
View patch online:
http://darcs.haskell.org/testsuite/_darcs/patches/20080827091439-12142-196b1177ed4dd5eda86c47c668db0cb858ed27fe.gz
Wed Aug 27 02:12:53 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* add test for #2542, #1205
A ./tests/ghc-regress/ghci/prog010/
A ./tests/ghc-regress/ghci/prog010/A.hs
A ./tests/ghc-regress/ghci/prog010/B.hs
A ./tests/ghc-regress/ghci/prog010/ghci.prog010.script
A ./tests/ghc-
Ian, Simon
The documentation for language extensions appears in GHC's user manual in
*three* places:
(a) The flag summary
http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id352860
(b) A section at the beginning of Chapter 8:
http://www.haskell.org/ghc/docs/latest/ht
On Wed, Aug 27, 2008 at 03:14:27PM +0100, Claus Reinke wrote:
> >>|Then, after adding "base < 4" to all extralibs .cabal files, I'm
> >>|treated to a
> >>|
> >>|Network.hs:434:10:
> >>|Couldn't match expected type `Exception.IOException'
> >>| against inferred type `Exception.Exceptio
|Then, after adding "base < 4" to all extralibs .cabal files, I'm
|treated to a
|
|Network.hs:434:10:
|Couldn't match expected type `Exception.IOException'
| against inferred type `Exception.Exception'
| Expected type: Exception.IOException -> IO a
| Inferred type: Exceptio
On Wed, Aug 27, 2008 at 01:59:04PM +0100, Claus Reinke wrote:
> >>In this case, I was told that base3-compat was provided
> >>explicitly to avoid breakage[1], and as I reported, that
> >>doesn't seem to be the case [2].
> >
> >It'll only work for packages that correctly depend on something like:
>
In this case, I was told that base3-compat was provided
explicitly to avoid breakage[1], and as I reported, that
doesn't seem to be the case [2].
It'll only work for packages that correctly depend on something like:
base >= x && < 4
quoting self (again):
|Then, after adding "base < 4" to
On Tue, Aug 26, 2008 at 08:56:31AM +0100, Simon Peyton-Jones wrote:
>
> Unexpected warnings in modules:
> simplCore/Simplify.lhs
> codeGen/CgMonad.lhs
>
> Unexpected Haddock failure ine
> codeGen/CgExpr.lhs
>
> Unexpected testsuite failures in
> tc125
>
> Do you
OK great. In the end we've decided to play safe and commit only after the fork
for 6.10, which will be in September
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Lynagh
| Sent: 23 August 2008 20:45
| To: John Dias
| Cc: cvs-ghc@haskell.o
Wed Aug 27 03:24:14 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* re-fix of #1205, fix #2542
New form of :load in GHCi:
> :load *A
forces A to be loaded as byte-code. See the manual for details. The
previous behaviour for specifying filenames vs. module names on the
command line
On Wed, Aug 27, 2008 at 11:18:46AM +0100, Claus Reinke wrote:
>
> In this case, I was told that base3-compat was provided
> explicitly to avoid breakage[1], and as I reported, that
> doesn't seem to be the case [2].
It'll only work for packages that correctly depend on something like:
base >
Hi all,
This has been a pretty exciting week here, with my desktop PC dieing on
Tuesday. That turned the week upside-down rather, but it has had the
side-effect that since Friday I've had a shiny new 4-core machine, with
space for more GHC trees, and validate running in about 16 minutes.
The Mac
Don, Duncan
As you know, we're planning to produce GHC 6.10 with "batteries not included",
relying on the Haskell Platform for the batteries. We are working v hard to
get 6.10 ready for release-candidate on 19 Sept.
But http://www.haskell.org/haskellwiki/Haskell_Platform seems dormant; it has
On Wed, 2008-08-27 at 11:18 +0100, Claus Reinke wrote:
> In this case, I was told that base3-compat was provided
> explicitly to avoid breakage[1], and as I reported, that
> doesn't seem to be the case [2].
You're right, it should work with base-3.
> [2] http://www.haskell.org/pipermail/cvs-ghc
The non-core libs have not been converted yet. I suggest you build
without those optional libs for the moment. Then it'll almost certainly
build, as that's what everyone checks when they validate.
As I've mentioned, I see those extralibs as a good test of
whether changes to ghc+corelibs are goin
Wed Aug 27 02:05:44 PDT 2008 [EMAIL PROTECTED]
* Improve documentation of MagicHash and primitive types generally (Trac
#2547)
M ./docs/users_guide/flags.xml -1 +1
M ./docs/users_guide/glasgow_exts.xml -38 +63
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/200808270905
Build results:
x86-64 Linux head:fail (failed getsubrepos)
x86 Windows head: fail (failed getsubrepos)
x86 Windows head fast:pass pass pass pass fail (failed getsubrepos)
fail (failed darcs)
fast486 head: pass
gabor head: pass
kgard
Build results:
tnaur PPC OSX stable 2: pass
tnaur x86 Linux stable: pass
x86 Windows stable: fail (failed getsubrepos)
x86 Windows stable fast: pass pass pass pass pass fail (failed darcs) pass
x86-64 Linux stable: fail (failed stage1)
Old unexpected test failures:
TyFamUndec
42 matches
Mail list logo
