Re: [GHC] #1468: :browse should browse currently loaded module

[Josef Svenningsson]

On 6/28/07, GHC <[EMAIL PROTECTED]> wrote:


#1468: :browse should browse currently loaded module

+---
  Reporter:  [EMAIL PROTECTED]  |  Owner:
  Type:  feature request| Status:  new
  Priority:  low|  Milestone:
Component:  GHCi   |Version:  6.6.1
  Severity:  trivial|   Keywords:
Difficulty:  Easy (1 hr)| Os:  Unknown
  Testcase: |   Architecture:  Unknown

+---
With module Foo loaded, :browse should be equivalent to :browse Foo.



Yes! I've wanted this a thousand times. If there was a voting mechanism on
Trac I would vote for this feature.

Josef


--

Ticket URL: 
GHC 
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #1468: :browse should browse currently loaded module

[GHC]

#1468: :browse should browse currently loaded module
+---
  Reporter:  [EMAIL PROTECTED]  |  Owner: 
  Type:  feature request| Status:  new
  Priority:  low|  Milestone: 
 Component:  GHCi   |Version:  6.6.1  
  Severity:  trivial|   Keywords: 
Difficulty:  Easy (1 hr)| Os:  Unknown
  Testcase: |   Architecture:  Unknown
+---
With module Foo loaded, :browse should be equivalent to :browse Foo.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1437: Build failures on Mac OS X 10.5

[GHC]

#1437: Build failures on Mac OS X 10.5
--+-
Reporter:  [EMAIL PROTECTED]  |Owner: 
Type:  bug|   Status:  new
Priority:  normal |Milestone:  6.8
   Component:  Compiler   |  Version:  6.6.1  
Severity:  normal |   Resolution: 
Keywords: |   Difficulty:  Unknown
  Os:  MacOS X| Testcase: 
Architecture:  x86|  
--+-
Comment (by [EMAIL PROTECTED]):

 When I try to build a distribution with the following `mk/build.mk`
 {{{
 BIN_DIST=1
 Project=Ghc
 SRC_HC_OPTS = -O -fasm -keep-s-files -keep-raw-s-files
 GhcStage1HcOpts = -O -fasm -keep-s-files -keep-raw-s-files
 GhcStage2HcOpts = -O -fasm -keep-s-files -keep-raw-s-files
 GhcLibHcOpts= -O -fasm -keep-s-files -keep-raw-s-files
 }}}

 Making fails with:
 {{{
 make -C compiler stage=2
 ../compiler/stage1/ghc-inplace -O -fasm -keep-s-files -keep-raw-s-files
 -istage
 2/utils  -istage2/basicTypes  -istage2/types  -istage2/hsSyn
 -istage2/prelude
 -istage2/rename  -istage2/typecheck  -istage2/deSugar  -istage2/coreSyn
 -istage
 2/specialise  -istage2/simplCore  -istage2/stranal  -istage2/stgSyn
 -istage2/si
 mplStg  -istage2/codeGen  -istage2/main  -istage2/profiling
 -istage2/parser  -i
 stage2/cprAnalysis  -istage2/ndpFlatten  -istage2/iface  -istage2/cmm
 -istage2/
 nativeGen  -istage2/ghci -Istage2 -DGHCI -DBREAKPOINT -package template-
 haskell
 -threaded -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser
 -package u
 nix -package Cabal -package regex-compat -ignore-package lang -recomp
 -Rghc-timi
 ng -O -fasm -keep-s-files -keep-raw-s-files -H16M '-#include "cutils.h"'
 -packag
 e-name  ghc-6.6.1   -fgenerics-c basicTypes/OccName.lhs-boot -o
 stage2/basic
 Types/OccName.o-boot  -ohi stage2/basicTypes/OccName.hi-boot

 basicTypes/OccName.lhs-boot:1:0:
 Failed to load interface for `Prelude':
   Use -v to see a list of the files searched for.
 <>
 make[2]: *** [stage2/basicTypes/OccName.o-boot] Error 1
 make[1]: *** [stage2] Error 2
 make: *** [bootstrap2] Error 2
 }}}

 What goes wrong here? It works if `GhcLibHcOpts` is not set (it then
 starts compiling the library with the stage1 compiler)

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: -keep-hc-files or -keep-hc-file?

[Christian Maeder]

Christian Maeder schrieb:
> I'm currently confused if it must be plural or singular (or any)
> 
> http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#keeping-intermediates
> 
> shows plural options whereas
>  
> http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id3131928
> 
> shows them in singular (except -keep-tmp-files)

The plural options work! So flag-reference.html should be corrected.

C.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1410: Control.Monad.Reader documentation

[GHC]

#1410: Control.Monad.Reader documentation
--+-
Reporter:  guest  |Owner: 
Type:  proposal   |   Status:  closed 
Priority:  normal |Milestone:  Not GHC
   Component:  libraries (other)  |  Version:  6.6.1  
Severity:  normal |   Resolution:  fixed  
Keywords: |   Difficulty:  Unknown
  Os:  Multiple   | Testcase: 
Architecture:  Multiple   |  
--+-
Changes (by igloo):

  * resolution:  => fixed
  * status:  new => closed

Comment:

 Applied, thanks!

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #1467: GHC API: expose separate compilation stages

[GHC]

#1467: GHC API: expose separate compilation stages
---+
  Reporter:  simonmar  |  Owner: 
  Type:  task  | Status:  new
  Priority:  normal|  Milestone:  6.10   
 Component:  GHC API   |Version:  6.6.1  
  Severity:  normal|   Keywords: 
Difficulty:  Moderate (1 day)  | Os:  Unknown
  Testcase:|   Architecture:  Unknown
---+
The GHC API is currently hard to use for certain things: extracting the
 output from various compilation stages; or "hooking in" to the compilation
 pipeline.  The `checkModule` function works for some uses, but it doesn't
 let you extract Core, for example, and it doesn't complete the compilation
 and inject the result into the `Session`, so the module still has to be
 compiled.

 One way to solve this would be to abstract the compilation pipeline as a
 series of functions, so that the user could script the compiler.  We
 haven't worked out the details, but in principle it should be possible to
 write a GHC API client that invokes the following steps:

  * parse a module
  * rename/typecheck
  * deSugar
  * optimise...
  * generate code

 and can then inject the compilation results back into the `Session` for
 use by future compilations.  Each individual stage should provide a result
 that can be inspected: get the renamed/typechecked code out, get the Core,
 and so on.

 The current `checkModule` could be built on top of such an interface, but
 the interface would allow much more flexibility.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #1466: Stack check for AP_STACK

[GHC]

#1466: Stack check for AP_STACK
---+
  Reporter:  simonmar  |  Owner:  simonmar
  Type:  bug   | Status:  new 
  Priority:  normal|  Milestone:  6.8 
 Component:  Runtime System|Version:  6.6.1   
  Severity:  normal|   Keywords:  
Difficulty:  Moderate (1 day)  | Os:  Unknown 
  Testcase:  concprog001   |   Architecture:  Unknown 
---+
This is a bug I uncovered in the interpreter, that I think is also present
 in the compiler.

 When compiling code for a function or thunk, we aggregate the stack usage
 from case continuations up to the top of the function/thunk and perform a
 single stack check.  This normally works fine: we know the maximum amount
 of stack that will be required in the evaluation of this function/thunk,
 and we check for it up front.

 However, this goes wrong if the evaluation is suspended by an asynchronous
 exception: the stack is broken into chunks and stored in `AP_STACK`
 objects, which may later be resumed.  On resumption, we might not have
 enough stack any more: the code might now be running on another stack
 entirely, even.

 Our proposed solution is as follows:

  * Continuations that require more than a certain amount of stack (say 4k)
do their own stack checks.

  * an AP_STACK object records the amount of stack available at the time it
was suspended, if the amount is <4k.  On resumption of an AP_STACK, we
ensure that at least this amount of stack is available.  (there's a
spare half-word field in AP_STACK that we can use for this).

 The 4k limit is important: it puts a bound on the amount of stack growth
 due to evaluating an AP_STACK.  Essentially the 4k limit is large enough
 that it almost never happens.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1445: implicit parameter not hoisted

[GHC]

#1445: implicit parameter not hoisted
-+--
Reporter:  Ashley Yakeley <[EMAIL PROTECTED]>  |Owner:  simonpj
Type:  bug   |   Status:  closed 
Priority:  normal|Milestone: 
   Component:  Compiler  |  Version:  6.6
Severity:  normal|   Resolution:  fixed  
Keywords:|   Difficulty:  Unknown
  Os:  Unknown   | Testcase:  tc230  
Architecture:  Unknown   |  
-+--
Changes (by simonpj):

  * resolution:  => fixed
  * testcase:  => tc230
  * status:  new => closed

Comment:

 Good report, thank you.  A slip in `TcType.tcSplitFunTy_maybe`, now fixed.

 Simon

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs