Ian Lynagh:
On Thu, Aug 28, 2008 at 11:08:04AM +0100, Simon Marlow wrote:
So I think it should all work, and in any case Ian now has a Mac so
we can
verify all this.
I've just tried it (make framework-pkg), and modulo a couple of fixes
for installing with a DESTDIR (which I'll push once I'
Hi
> In fact, one drawback of using a hierarchy is that it does suggest (by way
> of module names) a hierarchy that the code does not have. For example, I
> believe there are going to be cyclic imports between files in different
> subtrees. That may make the situation actually more confusing tha
Thomas Schilling:
I tried to plot GHC's dependency graph but it just became a grey/black
cloud. A hierarchical module space could clean things up a bit.
Compilers are (in)famous for that property. Using a hierarchical
module space is not going to change anything.
In fact, one drawback of
Hi GHC Hackers,
as many of you know, my GSoC project was to improve the GHC API. I'm
not quite sure how useful the result actually is. It brings some
changes for the better, but at quite a big price:
*** All GHC API clients will break ***.
The changes are described in a bit
Thu Aug 28 17:03:31 CEST 2008 [EMAIL PROTECTED]
* Fix linkage on OpenBSD.
New patches:
[Fix linkage on OpenBSD.
[EMAIL PROTECTED] hunk ./compiler/Makefile 153
-COMMON_CONFIGURE_FLAGS += --ld-options="-Xlinker -E"
+COMMON_CONFIGURE_FLAGS += --ld-options=-E
Context:
[Improve documentation of s
It would be good to update the docs on External Core before 6.10 is
released; most importantly, by updating the paper at:
http://www.haskell.org/ghc/docs/papers/core.ps.gz
to point to the current version of the External Core specification,
which can be found in the darcs repo under docs/ext-core.
On Thu, Aug 28, 2008 at 11:08:04AM +0100, Simon Marlow wrote:
>
> So I think it should all work, and in any case Ian now has a Mac so we can
> verify all this.
I've just tried it (make framework-pkg), and modulo a couple of fixes
for installing with a DESTDIR (which I'll push once I've validated
On Aug 28, 2008, at 12:39 PM, Thomas Schilling wrote:
On Thu, Aug 28, 2008 at 7:46 PM, Max Bolingbroke
<[EMAIL PROTECTED]> wrote:
2008/8/28 Ian Lynagh <[EMAIL PROTECTED]>:
The arguments for moving to hierarchical module names were:
* it makes finding modules much easier for people new to the
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 Thu Aug 28 18:02:05 BST 2008.
checking out
On Thu, Aug 28, 2008 at 7:46 PM, Max Bolingbroke
<[EMAIL PROTECTED]> wrote:
> 2008/8/28 Ian Lynagh <[EMAIL PROTECTED]>:
>> The arguments for moving to hierarchical module names were:
>>
>> * it makes finding modules much easier for people new to the code
>> (although tools can help here). For exam
2008/8/25 Ian Lynagh <[EMAIL PROTECTED]>:
> So should this patch be applied or not?
OK, so what I've done here is had another crack at fixing StGit
support, and then merged in the strict package-reading change made to
darcs-all. The resulting patch is available at
http://hackage.haskell.org/trac/g
2008/8/28 Ian Lynagh <[EMAIL PROTECTED]>:
> The arguments for moving to hierarchical module names were:
>
> * it makes finding modules much easier for people new to the code
> (although tools can help here). For example, Neil Mitchell said:
> Yhc moved to heirarchical module names, and it was a
> class Eq a => Eq2 a where eq :: a -> a -> Bool
Based on the runtime representation above, I expect the type of Main.:DEq2 to be
Main.:DEq2 :: GHC.Base.:TEq a -> (a -> a -> Bool) -> Main.:TEq2 a
but GHC tells me, via (fmap dataConRepType . tcLookupDatacon), the following
Main.:DEq2 :: (a ->
Thanks. That's helpful. I've committed a patch that summarises syntactic
changes as a subsection of the "Syntactic extensions" section of the manual.
Maybe it should be x-referenced from elsewhere, but it seems to fit there
Simion
| -Original Message-
| From: Claus Reinke [mailto:[EMA
Thu Aug 28 05:52:11 PDT 2008 [EMAIL PROTECTED]
* Improve documentation of stolen syntax
This patch adds a section that summarises what syntax is stolen by
which flags. The section is at the end of the "syntactic extensions"
section of the manual.
M ./docs/users_guide/glasgo
Thu Aug 28 05:10:06 PDT 2008 [EMAIL PROTECTED]
* Fix Trac #2529: derived read for prefix constructor operators
M ./compiler/typecheck/TcGenDeriv.lhs -10 +14
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20080828121006-1287e-0d6f3ad66ccc2c39b2a0f34179a32b14eb72c69f.gz
Thu Aug 28 05:11:08 PDT 2008 [EMAIL PROTECTED]
* Test for Trac #2529
A ./tests/ghc-regress/deriving/should_run/T2529.hs
A ./tests/ghc-regress/deriving/should_run/T2529.stdout
M ./tests/ghc-regress/deriving/should_run/all.T +1
View patch online:
http://darcs.haskell.org/testsuite/_d
Hi all,
In yesterday's #ghc meeting we discussed whether the GHC library should
use hierarchical module names. We haven't reached any decisions yet, so
please let us know what you think now!
The arguments for moving to hierarchical module names were:
* it makes finding modules much easier for
| 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.
Interesting. Any suggestions about where would be "easy to find"?
Or what the section would look like. Woul
| 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.
|
| The question is on what to include. I'd say, start with the curr
Eric Kow <[EMAIL PROTECTED]> added the comment:
I need a volunteer to do the following:
1. get a copy of libraries/Cabal from darcs.haskell.org
2. identify approximately the patches that would have gone into GHC 6.9.20080816
and 20080807 respectively
3. zip these up for forensics
4. (preflight)
Simon Peyton-Jones wrote:
| > That means that there will be no Mac OS X installer packages for 6.10
| > either (it uses the bindist target as part of the build process). I
|
| Ooops, sorry, braino: bindist will work (and indeed, already does).
|
| What we won't fix is building from HC files, i.e
Simon Peyton-Jones wrote:
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.ha
| > That means that there will be no Mac OS X installer packages for 6.10
| > either (it uses the bindist target as part of the build process). I
|
| Ooops, sorry, braino: bindist will work (and indeed, already does).
|
| What we won't fix is building from HC files, i.e. porting GHC to a new
| arc
On Wed, Aug 27, 2008 at 10:20:10PM +0200, Matthias Kilian wrote:
> ("/usr/bin/ld",["-Xlinker","-E","-x","-r","/tmp/5110.o","-o","/tmp/5111.o"])
> /usr/bin/ld returned ExitFailure 1 with error message:
> /usr/bin/ld: cannot find -linker
> cabal-bin: /tmp/5111.o: removeFile: does not exist (No such f
| 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.
Interesting. Any suggestions about where would be "easy to find"? Or what the
section would look like. Would
Build results:
x86-64 Linux head: fail (failed stage1)
x86 Windows head:fail (failed stage1)
x86 Windows head fast: lost pass pass fail (failed getsubrepos) fail (failed
darcs) pass
tnaur PPC OSX head 2:lost
tnaur x86 Linux head:pass
x86-64 Linux head unreg: fail (failed no
Build results:
fast486 stable: fail (failed darcs)
kgardas stable: fail (failed stage1)
mnemosyne x86-64 Gentoo stable: fail (failed darcs)
tnaur x86 Linux stable: pass
x86 Windows stable: fail (failed stage1)
x86 Windows stable fast:pass
28 matches
Mail list logo
