[nightly] 13-Nov-2007 build of STABLE on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com)

Build description = STABLE on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com) Build location= /playpen/ghc/nightly/STABLE-cam-02-unx Build config file = /home/simonmar/nightly/site/msrc/conf-STABLE-cam-02-unx Nightly build started on cam-02-unx at Tue Nov 13 19:00:00 GMT 2007.

Re: validate breaks!

Claus Reinke: Validating the HEAD today on Mac OS X gives me Unexpected failures: ghci024(ghci) This is probably related to the new debugger-related patches from yesterday. It'd be good to keep validate *break free* (or is this an OS issue)? ghci now has the ability to show dynamic fla

Re: patch applied (ghc): Turn -fprint-bind-result off by default

Sat Nov 10 16:11:26 PST 2007 Ian Lynagh <[EMAIL PROTECTED]> * Turn -fprint-bind-result off by default M ./compiler/main/DynFlags.hs -17 +15 M ./docs/users_guide/flags.xml -3 +3 M ./docs/users_guide/ghci.xml -9 +4 Sun Nov 11 14:38:35 PST 2007 Ian Lynagh <[EMAIL PROTECTED]> * Update

Re: buildbots oddity: kahl G5 Gentoo Linux stable

is it just me, or is this buildbot remarkably unpertubed by issues that lead to failing tests in other stable buildbots running in the same time period? seems to have caught up now? would it be possible to add the summary for the last few patches in each repo to the darcs/darcs-all buildbot lo

Re: validate breaks!

Validating the HEAD today on Mac OS X gives me Unexpected failures: ghci024(ghci) This is probably related to the new debugger-related patches from yesterday. It'd be good to keep validate *break free* (or is this an OS issue)? ghci now has the ability to show dynamic flag settings and

validate breaks!

Validating the HEAD today on Mac OS X gives me Unexpected failures: ghci024(ghci) This is probably related to the new debugger-related patches from yesterday. It'd be good to keep validate *break free* (or is this an OS issue)? Manuel (aka "The Validator")

[nightly] 13-Nov-2007 build of HEAD on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com)

Build description = HEAD on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com) Build location= /playpen/ghc/nightly/HEAD-cam-02-unx Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx Nightly build started on cam-02-unx at Tue Nov 13 19:30:01 GMT 2007. checki

buildbots oddity: kahl G5 Gentoo Linux stable

is it just me, or is this buildbot remarkably unpertubed by issues that lead to failing tests in other stable buildbots running in the same time period? claus ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

patch applied (ghc): GHCi debugger: added a new flag, -fno-print-binding-contents

Tue Nov 13 09:45:39 PST 2007 Pepe Iborra <[EMAIL PROTECTED]> * GHCi debugger: added a new flag, -fno-print-binding-contents The contents of bindings show at breakpoints and by :show bindings is rendered using the same printer that :print uses. But sometimes the output it gives spans ove

patch applied (testsuite): Add a test for #1827 (:print panicswith overloaded values))

Tue Nov 13 09:20:48 PST 2007 Pepe Iborra <[EMAIL PROTECTED]> * Add a test for #1827 (:print panicswith overloaded values)) M ./tests/ghc-regress/ghci.debugger/scripts/all.T +1 A ./tests/ghc-regress/ghci.debugger/scripts/print027.script A ./tests/ghc-regress/ghci.debugger/scripts/pri

patch applied (ghc): Fix Trac 1865: GHCi debugger crashes with :print

Tue Nov 13 09:01:13 PST 2007 Pepe Iborra <[EMAIL PROTECTED]> * Fix Trac 1865: GHCi debugger crashes with :print M ./compiler/ghci/Debugger.hs -1 +1 M ./compiler/ghci/RtClosureInspect.hs -7 +11 M ./compiler/main/InteractiveEval.hs -1 +1 M ./compiler/types/Type.lhs -11 +13 __

patch applied (ghc): Replaced two uses of head b explicit pattern matching

Sat Oct 13 04:31:36 PDT 2007 Pepe Iborra <[EMAIL PROTECTED]> * Replaced two uses of head b explicit pattern matching M ./compiler/ghci/RtClosureInspect.hs -2 +2 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/

patch applied (ghc): Print binding contents in :show bindings

Sat Oct 6 05:39:52 PDT 2007 Pepe Iborra <[EMAIL PROTECTED]> * Print binding contents in :show bindings M ./compiler/ghci/InteractiveUI.hs -17 +18 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

patch applied (ghc): Leftovers from the 1st GHCi debugger prototype

Thu Oct 4 13:47:18 PDT 2007 Pepe Iborra <[EMAIL PROTECTED]> * Leftovers from the 1st GHCi debugger prototype M ./compiler/main/DynFlags.hs -2 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

patch applied (ghc): Following an indirection doesn't count as a RTTI step

Fri Sep 28 02:19:41 PDT 2007 Pepe Iborra <[EMAIL PROTECTED]> * Following an indirection doesn't count as a RTTI step M ./compiler/ghci/RtClosureInspect.hs -1 +1 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/

patch applied (ghc): FIX #1653 (partially): add -X flags to completion for :set

Tue Nov 13 07:32:57 PST 2007 Simon Marlow <[EMAIL PROTECTED]> * FIX #1653 (partially): add -X flags to completion for :set M ./compiler/main/DynFlags.hs -1 +4 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cv

Re: should haddock.ghc be a sub-repo of ghc?

It's a very attractive approach, but comments can appear absolutely anywhere in the concrete syntax, between any two tokens. How do we decide where to attach these comments to the AST? Allowing them anywhere but not ignoring them needs some thought for how to parse them without going insane and c

patch applied (testsuite): Remove some tabs in break020.hs

Tue Nov 13 08:39:12 PST 2007 Pepe Iborra <[EMAIL PROTECTED]> * Remove some tabs in break020.hs M ./tests/ghc-regress/ghci.debugger/scripts/break020.hs -2 M ./tests/ghc-regress/ghci.debugger/scripts/break020.stdout -3 +1 M ./tests/ghc-regress/ghci.debugger/scripts/break021.stdout -5

patch applied (testsuite): Accept output

Tue Nov 13 08:34:51 PST 2007 Pepe Iborra <[EMAIL PROTECTED]> * Accept output M ./tests/ghc-regress/ghci.debugger/scripts/break001.stdout -2 +2 M ./tests/ghc-regress/ghci.debugger/scripts/break006.stdout -10 +10 M ./tests/ghc-regress/ghci.debugger/scripts/break011.stdout -2 +2 M

Re: should haddock.ghc be a sub-repo of ghc?

Duncan wrote: > Why not the other way around. haddock could use functions from the GHC > API to ask the renamer to resolve a bunch of names. > > So in this hypothetical system, haddock uses the GHC API to get at the > comments in the AST, it somehow figures out which comments are in > locations th

Re: should haddock.ghc be a sub-repo of ghc?

On Tue, 2007-11-13 at 16:24 +0100, David Waern wrote: > Well, Haddock comments can refer to Haskell identifiers. So when the > contents of a Haddock comment has been parsed, the result can contain > 'RdrName's which is GHC-lingo for an identifier with a yet-unidentified > original definition site.

Re: should haddock.ghc be a sub-repo of ghc?

>> The abstract syntax contains the Haddock documentation. There are >> alternatives to this, but I couldn't think of an attractive alternative, >> perhaps you can. > > i'm not sure about attractive, but since every haddock comment > is by design also a comment, and many ghci api clients would be

Re: should haddock.ghc be a sub-repo of ghc?

On Tue, 2007-11-13 at 14:12 +, Claus Reinke wrote: > less integration, but more modularity - haddock.ghc would > still have the advantage of being able to parse anything that > ghc can handle by sharing its frontend, but ghc would not > need to handle anything haddock-related in any special

Re: should haddock.ghc be a sub-repo of ghc?

The abstract syntax contains the Haddock documentation. There are alternatives to this, but I couldn't think of an attractive alternative, perhaps you can. i'm not sure about attractive, but since every haddock comment is by design also a comment, and many ghci api clients would be interested

Re: should haddock.ghc be a sub-repo of ghc?

>> Believe me, we're aware that it's not ideal. >> >> Perhaps a better solution would be to represent the documentation by >> Dynamics in GHC's abstract syntax, and to pass in the functions that >> parse >> and rename the documentation annotations, perhaps in the DynFlags. That >> would let us ext

Re: should haddock.ghc be a sub-repo of ghc?

> ok, it seems the consensus on the subject question is "no" > (fine by me), that ghc api users are on their own with trying > to follow the api (hmm, ok, i guess), but that ghc api users > should help with its design (good idea, though i've long had > my doubts about the "users suggest a good desi

Re: should haddock.ghc be a sub-repo of ghc?

Claus Reinke wrote: Perhaps a better solution would be to represent the documentation by Dynamics in GHC's abstract syntax, and to pass in the functions that parse and rename the documentation annotations, perhaps in the DynFlags. Good idea. Sounds like it would work to me. just curious: wha

Re: should haddock.ghc be a sub-repo of ghc?

>> Stefan O'Rear wrote: >>> On Tue, Nov 13, 2007 at 04:34:30AM +0100, David Waern wrote: You are right, it's not the most modular solution. Nevertheless, we now have the ability to generate documentation from all kinds of GHC-specific source code - pretty cool. Ou

Re: should haddock.ghc be a sub-repo of ghc?

Out of curiosity: Do you have a better solution for Haddock, if the requirement is to be able to understand GHC-specific code? Perhaps one could avoid having to modify the parser, and instead try to match Haddock-comments/declarations by their SrcLocs. naively, i'd think that haddock adds functi

Re: should haddock.ghc be a sub-repo of ghc?

ok, it seems the consensus on the subject question is "no" (fine by me), that ghc api users are on their own with trying to follow the api (hmm, ok, i guess), but that ghc api users should help with its design (good idea, though i've long had my doubts about the "users suggest a good design" part;

Re: should haddock.ghc be a sub-repo of ghc?

> Stefan O'Rear wrote: >> On Tue, Nov 13, 2007 at 04:34:30AM +0100, David Waern wrote: >>> You are right, it's not the most modular solution. Nevertheless, we now >>> have the ability to generate documentation from all kinds of >>> GHC-specific >>> source code - pretty cool. >>> >>> Out of curiosit

patch applied (testsuite): add test for #1603

Thu Nov 8 08:40:56 PST 2007 Simon Marlow <[EMAIL PROTECTED]> * add test for #1603 A ./tests/ghc-regress/numeric/should_run/1603.hs A ./tests/ghc-regress/numeric/should_run/1603.stdout M ./tests/ghc-regress/numeric/should_run/all.T +2 ___

patch applied (testsuite): FIX ghci024 for unregisterised, powerpc_apple_darwin, and ghc-6.8

Sun Nov 11 14:40:38 PST 2007 [EMAIL PROTECTED] * FIX ghci024 for unregisterised, powerpc_apple_darwin, and ghc-6.8 - for unregisterised platforms, default is '-fno-asm-mangling' - powerpc_apple_darwin fails on ':set -package ghc' (#1845) - for ghc 6.8, -fno-run-cps and -fno-convert-

patch applied (testsuite): add test for #1852

Thu Nov 8 06:35:33 PST 2007 Simon Marlow <[EMAIL PROTECTED]> * add test for #1852 A ./tests/ghc-regress/codeGen/should_run/1852.hs A ./tests/ghc-regress/codeGen/should_run/1852.stdout M ./tests/ghc-regress/codeGen/should_run/all.T +2 ___

RE: should haddock.ghc be a sub-repo of ghc?

| > the point is that haddock.ghc is using the ghc api, which is | > (a) an internal api, or at least an api to ghc's internals and | > (b) still under rapid development. | | It's an exported, stable, documented and supported API - or at least I | believe that is the eventual intention. | ... | Hop

Re: should haddock.ghc be a sub-repo of ghc?

Stefan O'Rear wrote: On Tue, Nov 13, 2007 at 04:34:30AM +0100, David Waern wrote: You are right, it's not the most modular solution. Nevertheless, we now have the ability to generate documentation from all kinds of GHC-specific source code - pretty cool. Out of curiosity: Do you have a better s

Daily report for head

Build results: x86-64 Linux head:pass x86 Windows head: pass x86 Windows head fast:pass pass pass pass pass pass gabor head: pass kahl G5 Gentoo Linux head:pass mnemosyne x86-64 Gentoo head: pass phil Intel OSX head: pass tnaur PPC OSX

Daily report for stable

Build results: kahl G5 Gentoo Linux stable: pass tnaur PPC OSX stable:pass x86 Windows stable: pass x86 Windows stable fast: pass pass pass pass pass pass x86-64 Linux stable: fail (failed darcs) New unexpected test failures: conc068 1 x86 Windows stable Fixed