Re: [GHC] #3738: Typechecker floats stuff out of INLINE right hand sides

[GHC]

#3738: Typechecker floats stuff out of INLINE right hand sides
-+--
Reporter:  rl|Owner:  igloo  
Type:  bug   |   Status:  new
Priority:  normal|Milestone:  7.0.1  
   Component:  Compiler  |  Version:  6.13   
Keywords:| Testcase: 
   Blockedby:|   Difficulty: 
  Os:  Unknown/Multiple  | Blocking: 
Architecture:  Unknown/Multiple  |  Failure:  Runtime performance bug
-+--
Changes (by simonpj):

  * owner:  => igloo


Comment:

 Ian: could you turn Romans's comment immediately above into a test?  The
 code I get at the moment for 'bar' is
 {{{
 T3738b.bar =
   \ (x_aaz :: GHC.Types.Int) ->
 let {
   a_smr [Dmd=Just L] :: GHC.Types.Int
   [LclId, Str=DmdType]
   a_smr =
 case x_aaz of _ { GHC.Types.I# x1_ajM ->
 GHC.Types.I# (GHC.Prim.+# (GHC.Prim.+# x1_ajM 1) 2)
 } } in
 letrec {
   xs_smt [Occ=LoopBreaker] :: [GHC.Types.Int]
   [LclId, Str=DmdType]
   xs_smt = GHC.Types.: @ GHC.Types.Int a_smr xs_smt; } in
 xs_smt
 }}}
 Note the nice loop for `xs_smt`.

 To test that this stays working, here's a test:
 {{{
 module T3738a where

 foo :: Num a => a -> [a]
 {-# INLINE foo #-}
 foo x = map (+1) (repeat x)

 -
 module Main where

 import T3738a

 bar :: Int -> [Int]
 {-# INLINE bar #-}
 bar x = map (+2) (foo x)

 main = print (bar 2 !! 1)
 }}}
 Running the program with `+RTS -sstderr` I get
 {{{
 -- With ghc 6.12:
 ./T3738 +RTS -sstderr
 5
  953,088 bytes allocated in the heap


 -- With HEAD:
 ./T3738 +RTS -sstderr
 5
   60,368 bytes allocated in the heap
 }}}
 That seems like a big enough difference that the test could spot it.

 Ian, could you add that?  Thanks.

 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

Re: [GHC] #4420: T3851 fails because of untouchable type variables and escaping skolems

[GHC]

#4420: T3851 fails because of untouchable type variables and escaping skolems
--+-
Reporter:  daniel.is.fischer  |Owner:  
Type:  bug|   Status:  new 
Priority:  normal |Milestone:  
   Component:  Test Suite |  Version:  7.1 
Keywords: | Testcase:  
   Blockedby: |   Difficulty:  
  Os:  Unknown/Multiple   | Blocking:  
Architecture:  Unknown/Multiple   |  Failure:  None/Unknown
--+-

Comment(by simonpj):

 Yes. This is the last remaining testsuite failure relating to the type
 checker.  We're on it.

-- 
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] #4419: dph tests fail with panic

[GHC]

#4419: dph tests fail with panic
--+-
Reporter:  daniel.is.fischer  |   Owner:  benl 
Type:  bug|  Status:  new  
Priority:  normal |   Component:  libraries (other)
 Version:  7.1|Keywords:   
Testcase: |   Blockedby:   
  Os:  Unknown/Multiple   |Blocking:   
Architecture:  Unknown/Multiple   | Failure:  None/Unknown 
--+-

Comment(by rl):

 Is it perhaps because of this:

 {{{
 Tue Oct 19 08:45:52 PDT 2010  Ian Lynagh 
  * seq the unfolding in setUnfoldingInfo

 Tue Oct 19 13:15:37 PDT 2010  Ian Lynagh 
  * Define setIdUnfoldingLazily, and use it in Vectorise
  Fixes a loop in the compiler, when running the dph tests
 }}}

 The second patch should have fixed that then.

-- 
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] #2893: Implement "Quantified contexts" proposal

[GHC]

#2893: Implement "Quantified contexts" proposal
-+--
Reporter:  porges|Owner:  
Type:  feature request   |   Status:  new 
Priority:  normal|Milestone:  _|_ 
   Component:  Compiler  |  Version:  6.10.1  
Keywords:  proposal  | Testcase:  
   Blockedby:|   Difficulty:  Unknown 
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--
Changes (by reinerp):

 * cc: reiner.p...@… (added)


-- 
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] #4316: Multiline commands in GHCi (was: Interactive "do" notation in GHCi)

[GHC]

#4316: Multiline commands in GHCi
--+-
  Reporter:  mitar|  Owner:  vivian  
  Type:  feature request  | Status:  patch   
  Priority:  normal   |  Milestone:  7.2.1   
 Component:  GHCi |Version:  6.12.3  
Resolution:   |   Keywords:  
  Testcase:   |  Blockedby:  
Difficulty:   | Os:  Unknown/Multiple
  Blocking:   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown |  
--+-
Changes (by vivian):

  * status:  new => patch


Comment:

 Patch implements multiline commands in GHCi. ({{{do, case, let}}}).

 Patch includes documentation.  The testsuite patch modifies a number of
 GHCi tests that now require an additional blank line after {{{case}}} and
 {{{let}}}.

 #3984 was not modified.

 It would be nice to see this in 7.0.

 The history is not modified as Haskeline would require modification to
 replace the previous n lines with one multiline command.  Also, it might
 be better to allow the user to replay each line at a time, so that an
 error on one line can be changed.  I suppose this depends on whether
 history is used to edit commands or just repeat them.

-- 
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] #4419: dph tests fail with panic

[GHC]

#4419: dph tests fail with panic
--+-
Reporter:  daniel.is.fischer  |   Owner:  benl 
Type:  bug|  Status:  new  
Priority:  normal |   Component:  libraries (other)
 Version:  7.1|Keywords:   
Testcase: |   Blockedby:   
  Os:  Unknown/Multiple   |Blocking:   
Architecture:  Unknown/Multiple   | Failure:  None/Unknown 
--+-
Changes (by chak):

  * owner:  => benl


Comment:

 Thanks for the report.  We are still in the process of adapting DPH to the
 new type checker and use of vector as the underlying sequential array
 substrate.

-- 
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] #2271: floor, ceiling, round :: Double -> Int are awesomely slow

[GHC]

#2271: floor, ceiling, round :: Double -> Int are awesomely slow
--+-
Reporter:  dons   |Owner:  daniel.is.fischer
Type:  bug|   Status:  patch
Priority:  low|Milestone:  7.0.1
   Component:  libraries/base |  Version:  7.1  
Keywords:  performance, math, double  | Testcase:   
   Blockedby: |   Difficulty:  Unknown  
  Os:  Unknown/Multiple   | Blocking:   
Architecture:  Unknown/Multiple   |  Failure:  None/Unknown 
--+-

Comment(by daniel.is.fischer):

 There are a few functions which give different results with and without
 optimisations. It's not nice, but what can one do? You can't change the
 primops to have the non-optimised behaviour (without sacrificing
 performance) and changing the non-optimised functions to match the primops
 is perhaps not always possible (`realToFrac :: Float -> Double` would be
 very hard to make `fromRational . toRational` match `float2Double`) and
 practically always make the non-optimised functions unusably slow.

 Regarding -0.0, since 0.0 == (-0.0), I don't see a strong reason to keep
 the tests just to match prior behaviour in this case.

 Patch for the rewrite rules is at #1434 btw.

-- 
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] #4412: Produce CUDA code

[GHC]

#4412: Produce CUDA code
-+--
 Reporter:  victorusu|  Owner:  
 Type:  feature request  | Status:  closed  
 Priority:  normal   |  Component:  Compiler
  Version:   | Resolution:  invalid 
 Keywords:  CUDA, parallel   |   Testcase:  
Blockedby:   | Os:  Unknown/Multiple
 Blocking:   |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown |  
-+--
Changes (by chak):

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


Comment:

 Unfortunately, compiling Haskell to CUDA is impossible as GPUs do not
 support recursive functions and general function pointers.  You may want
 to have a look at the following paper to see how a ''very restricted
 subset'' of Haskell can be compiled to CUDA:

   http://www.cse.unsw.edu.au/~chak/papers/acc-cuda.pdf

 The library is available on Hackage if you want to try for yourself.  (No
 extension to GHC is required as it is an embedded language in a library.)

-- 
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] #4420: T3851 fails because of untouchable type variables and escaping skolems

[GHC]

#4420: T3851 fails because of untouchable type variables and escaping skolems
--+-
Reporter:  daniel.is.fischer  |   Owner:  
Type:  bug|  Status:  new 
Priority:  normal |   Component:  Test Suite  
 Version:  7.1|Keywords:  
Testcase: |   Blockedby:  
  Os:  Unknown/Multiple   |Blocking:  
Architecture:  Unknown/Multiple   | Failure:  None/Unknown
--+-
 {{{
 => T3851(normal) 1990 of 2612 [0, 7, 0]
 cd ./indexed-types/should_compile &&
 '/home/dafis/Haskell/Hacking/testTree/bindisttest/install dir/bin/ghc'
 -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-
 conf -rtsopts  -c T3851.hs>T3851.comp.stderr 2>&1
 Wrong exit code (expected 0 , actual 2 )
 Stdout:

 Stderr:

 IndTypesPerfMerge.hs:90:5:
 Couldn't match type `a1' with `UnmergedLeft (MergerType a1 b1)'
 because a1 is untouchable
 inside the constraints (Merger (DiscardRightHead h1 t1 h2 t2),
 t1 ~ UnmergedLeft (MergerType t1 t2),
 t2 ~ UnmergedRight (MergerType t1 t2),
 Mergeable t1 t2,
 Merger (MergerType t1 t2))
   bound at the instance declaration
 In the instance declaration for `Merger
(DiscardRightHead h1 t1 h2 t2)'

 IndTypesPerfMerge.hs:90:5:
 Couldn't match type `b1' with `UnmergedRight (MergerType a1 b1)'
 because b1 is untouchable
 inside the constraints (Merger (DiscardRightHead h1 t1 h2 t2),
 t1 ~ UnmergedLeft (MergerType t1 t2),
 t2 ~ UnmergedRight (MergerType t1 t2),
 Mergeable t1 t2,
 Merger (MergerType t1 t2))
   bound at the instance declaration
 In the instance declaration for `Merger
(DiscardRightHead h1 t1 h2 t2)'

 IndTypesPerfMerge.hs:98:16:
 Couldn't match type `t1' with `UnmergedLeft (MergerType a1 b1)'
   `t1' is a rigid type variable bound by
the instance declaration at IndTypesPerfMerge.hs:90:16
 In the pattern: h1 :* t1
 In an equation for `mkMerge':
 mkMerge _ (h1 :* t1) (h2 :* t2)
   = h1 :* mkMerge (merger t1 t2) t1 t2
 In the instance declaration for `Merger
(DiscardRightHead h1 t1 h2 t2)'

 IndTypesPerfMerge.hs:98:27:
 Couldn't match type `t2' with `UnmergedRight (MergerType a1 b1)'
   `t2' is a rigid type variable bound by
the instance declaration at IndTypesPerfMerge.hs:90:19
 In the pattern: h2 :* t2
 In an equation for `mkMerge':
 mkMerge _ (h1 :* t1) (h2 :* t2)
   = h1 :* mkMerge (merger t1 t2) t1 t2
 In the instance declaration for `Merger
(DiscardRightHead h1 t1 h2 t2)'

 IndTypesPerfMerge.hs:101:5:
 Couldn't match type `a'
with `UnmergedLeft (MergerType a (h2 :* t2))'
   because these skolem type variables would escape: `h2', `t2'
 These skolems are bound by the instance declaration
 In the instance declaration for `Merger
(LeftHeadFirst h1 t1 h2 t2)'

 IndTypesPerfMerge.hs:109:16:
 Couldn't match type `t1'
with `UnmergedLeft (MergerType a (h2 :* t2))'
   `t1' is a rigid type variable bound by
the instance declaration at IndTypesPerfMerge.hs:101:16
 In the pattern: h1 :* t1
 In an equation for `mkMerge':
 mkMerge _ (h1 :* t1) (h2 :* t2)
   = h1 :* mkMerge (merger t1 (h2 :* t2)) t1 (h2 :* t2)
 In the instance declaration for `Merger
(LeftHeadFirst h1 t1 h2 t2)'

 IndTypesPerfMerge.hs:112:5:
 Couldn't match type `b'
with `UnmergedRight (MergerType (h1 :* t1) b)'
   because these skolem type variables would escape: `h1', `t1'
 These skolems are bound by the instance declaration
 In the instance declaration for `Merger
(RightHeadFirst h1 t1 h2 t2)'

 IndTypesPerfMerge.hs:120:27:
 Couldn't match type `t2'
with `UnmergedRight (MergerType (h1 :* t1) b)'
   `t2' is a rigid type variable bound by
the instance declaration at IndTypesPerfMerge.hs:112:27
 In the pattern: h2 :* t2
 In an equation for `mkMerge':
 mkMerge _ (h1 :* t1) (h2 :* t2)
   = h2 :* mkMerge (merger (h1 :* t1) t2) (h1 :* t1) t2
 In the instance declaration for `Merger
(RightHeadFirst h1 t1 h2 t2)'
 gmake[3]: *** [IndTypesPerf] Fehler 1

 

[GHC] #4419: dph tests fail with panic

[GHC]

#4419: dph tests fail with panic
--+-
Reporter:  daniel.is.fischer  |   Owner:   
Type:  bug|  Status:  new  
Priority:  normal |   Component:  libraries (other)
 Version:  7.1|Keywords:   
Testcase: |   Blockedby:   
  Os:  Unknown/Multiple   |Blocking:   
Architecture:  Unknown/Multiple   | Failure:  None/Unknown 
--+-
 I got several panics for dph tests with the latest HEAD:
 {{{
 => dph-words-fast(normal) 1315 of 2612 [0, 2, 0]
 cd ./dph/words &&
 '/home/dafis/Haskell/Hacking/testTree/bindisttest/install dir/bin/ghc'
 -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-
 conf -rtsopts  --make -o dph-words-fast Main  -O -fno-rewrite-rules
 -package dph-par -package dph-prim-par  >dph-words-fast.comp.stderr 2>&1
 Compile failed (status 256) errors were:
 [1 of 2] Compiling WordsVect( WordsVect.hs, WordsVect.o )
 ghc: panic! (the 'impossible' happened)
   (GHC version 7.1.20101019 for i386-unknown-linux):
 <>

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug


 *** unexpected failure for dph-words-fast(normal)
 }}}
 The same panic also for
 {{{
 dph-sumnats(normal)
 dph-quickhull-fast(normal)
 dph-primespj-fast(normal)
 }}}
 quickhull also complained about
 {{{
 on the commandline:
 Warning: -fno-rewrite-rules is deprecated: Use -fno-enable-rewrite-
 rules instead
 }}}

-- 
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] #1434: Missing RULEs for truncate

[GHC]

#1434: Missing RULEs for truncate
--+-
Reporter:  g...@…  |Owner:  
   
Type:  task   |   Status:  patch
  
Priority:  low|Milestone:  7.0.1
  
   Component:  libraries/base |  Version:  6.4.1
  
Keywords:  rules  | Testcase:   
  
   Blockedby: |   Difficulty:  Unknown  
  
  Os:  Unknown/Multiple   | Blocking:   
  
Architecture:  Unknown/Multiple   |  Failure:  Runtime performance 
bug
--+-
Changes (by daniel.is.fischer):

  * status:  new => patch


Comment:

 Patch with rewrite rules for the sized Int and Word types whose ranges are
 contained in Int's range. Unfortunately, we can't have a rule for Word
 here, that would need its own primop to improve much on the default
 implementation. It doesn't depend on #2271, but it will only help with
 truncate without it.

 Please review and merge.

-- 
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] #2396: Default class method not inlined

[GHC]

#2396: Default class method not inlined
--+-
  Reporter:  sedillard|  Owner:  
  Type:  bug  | Status:  closed  
  Priority:  low  |  Milestone:  7.0.1   
 Component:  Compiler |Version:  6.8.3   
Resolution:  fixed|   Keywords:  
  Testcase:   |  Blockedby:  
Difficulty:  Unknown  | Os:  Unknown/Multiple
  Blocking:   |   Architecture:  Unknown/Multiple
   Failure:  Runtime performance bug  |  
--+-
Changes (by reinerp):

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


Comment:

 The given program fails to compile with the 7.0 release candidate, due to
 #4418. Working around this problem by adding the fundep {{{pm -> pv}}} to
 the {{{PackedMat}}} class, it compiles and gives Core essentially the same
 as the 6.12 Core: no unnecessary constructors.

-- 
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] #4418: Superclass functional dependencies are ignored during instance selection

[GHC]

#4418: Superclass functional dependencies are ignored during instance selection
-+--
Reporter:  reinerp   |   Owner:   
Type:  bug   |  Status:  new  
Priority:  normal|   Component:  Compiler (Type checker)  
 Version:  7.1   |Keywords:   
Testcase:|   Blockedby:   
  Os:  Unknown/Multiple  |Blocking:   
Architecture:  Unknown/Multiple  | Failure:  GHC rejects valid program
-+--
 The following example compiles with ghc-6.12.3, but not with
 ghc-7.0.0.20100924:
 {{{
 {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}

 module Ambiguity where

 class C1 a b | b -> a
 class (C1 a b) => C2 a b where
   foo :: b -> b

 data A = A
 data B = B
 instance C1 A B
 instance C2 A B

 -- this is accepted by both 6.12.3 and 7
 runFoo :: C2 a b => b -> b
 runFoo = foo

 -- this is accepted by 6.12.3, but not by 7
 runFoo2 :: B -> B
 runFoo2 = foo
 }}}

 A straightforward fix is to add the {{{b -> a}}} fundep to the {{{C2}}}
 class as well.

-- 
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] #4318: Crash while building HEAD on OS X

[GHC]

#4318: Crash while building HEAD on OS X
---+
Reporter:  gwright |Owner: 
Type:  bug |   Status:  new
Priority:  normal  |Milestone:  7.0.1  
   Component:  Compiler|  Version:  6.13   
Keywords:  | Testcase: 
   Blockedby:  |   Difficulty: 
  Os:  MacOS X | Blocking: 
Architecture:  x86_64 (amd64)  |  Failure:  Building GHC failed
---+

Comment(by gwright):

 For completeness, the ghc version in the above was 7.1.20101018.

-- 
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] #4318: Crash while building HEAD on OS X

[GHC]

#4318: Crash while building HEAD on OS X
---+
Reporter:  gwright |Owner: 
Type:  bug |   Status:  new
Priority:  normal  |Milestone:  7.0.1  
   Component:  Compiler|  Version:  6.13   
Keywords:  | Testcase: 
   Blockedby:  |   Difficulty: 
  Os:  MacOS X | Blocking: 
Architecture:  x86_64 (amd64)  |  Failure:  Building GHC failed
---+

Comment(by gwright):

 Okay, my changes to Linker.c merged into a fresh pull from 18 Oct 2010 are
 quite encouraging.  Here's the results of the validate script (with stop
 on error disabled in `mk/validate.mk`):
 {{{

 OVERALL SUMMARY for test run started at Tue Oct 19 20:38:56 EDT 2010
 2610 total tests, which gave rise to
 9751 test cases, of which
0 caused framework failures
 7444 were skipped

 2194 expected passes
   79 expected failures
1 unexpected passes
   33 unexpected failures

 Unexpected passes:
simplrun006(optc)

 Unexpected failures:
1372(normal)
1959(normal)
2578(normal)
T1969(normal)
T3007(normal)
T3245(normal)
T3294(normal)
T4059(normal)
break001(ghci)
break006(ghci)
bug1465(normal)
cabal01(normal)
cabal04(normal)
derefnull(normal)
driver062a(normal)
driver062b(normal)
driver062c(normal)
driver062d(normal)
driver062e(normal)
driver081a(normal)
driver081b(normal)
gadt23(normal)
ghcpkg05(normal)
hs-boot(normal)
mod179(normal)
outofmem(normal)
print019(ghci)
prog003(ghci)
recomp004(normal)
rn.prog006(normal)
rtsOpts(normal)
tcfail138(normal)
withRtsOpts(normal)

 ---
 Oops!  Looks like you have some unexpected test results or framework
 failures.
 Please fix them before pushing/sending patches.
 ---
 }}}

 Before the changes to Linker.c, every ghci test ended in a segfault or
 abort trap.

 I'll tidy the debug messages I added and send the patch upstream tomorrow.
 I'll also
 run a full build and the testsuite.

-- 
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] #4316: Interactive "do" notation in GHCi

[GHC]

#4316: Interactive "do" notation in GHCi
--+-
  Reporter:  mitar|  Owner:  vivian  
  Type:  feature request  | Status:  new 
  Priority:  normal   |  Milestone:  7.2.1   
 Component:  GHCi |Version:  6.12.3  
Resolution:   |   Keywords:  
  Testcase:   |  Blockedby:  
Difficulty:   | Os:  Unknown/Multiple
  Blocking:   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown |  
--+-

Comment(by vivian):

 I have a working patch that uses simonmar's idea of checking the lexer
 state in alternative layout mode.

 There are now a couple of questions with respect to the GHCi documentation
 and #3984.

 * First, any open context (basically 'do' and 'let') will trigger
 multiline mode which is terminated by an empty (cf. blank) line.  We can
 also define something with a 'let':
 {{{
 Prelude> let foo = "Hello"
 Prelude|
 Prelude> foo
 "Hello"
 }}}
 which does not have an associated 'in.' In all these cases, an extra empty
 line is required.  Where in the documentation should we put this feature?

 * #3984 uses {{{:{}}} and {{{}:}}} to open and close a 'multiline' mode.
 I think this is now obsolete '''except''' if we want to have a 'where'
 clause.

-- 
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] #2221: Can't use quotations ([| ... |]) insides declaration splices

[GHC]

#2221: Can't use quotations ([| ... |]) insides declaration splices
---+
  Reporter:  m4dc4p|  Owner: 
  Type:  bug   | Status:  closed 
  Priority:  normal|  Milestone: 
 Component:  Template Haskell  |Version:  6.8.2  
Resolution:  duplicate |   Keywords: 
  Testcase:|  Blockedby: 
Difficulty:  Unknown   | Os:  Windows
  Blocking:|   Architecture:  x86
   Failure:  None/Unknown  |  
---+

Comment(by m4dc4p):

 Awesome, thanks for taking a look. Great to know!

-- 
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] #2221: Can't use quotations ([| ... |]) insides declaration splices

[GHC]

#2221: Can't use quotations ([| ... |]) insides declaration splices
---+
  Reporter:  m4dc4p|  Owner: 
  Type:  bug   | Status:  closed 
  Priority:  normal|  Milestone: 
 Component:  Template Haskell  |Version:  6.8.2  
Resolution:  duplicate |   Keywords: 
  Testcase:|  Blockedby: 
Difficulty:  Unknown   | Os:  Windows
  Blocking:|   Architecture:  x86
   Failure:  None/Unknown  |  
---+
Changes (by simonpj):

  * failure:  => None/Unknown


Comment:

 In GHC 6.12 you can splice into types, so the examples here work.

-- 
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] #4342: Review containers changes

[GHC]

#4342: Review containers changes
--+-
Reporter:  igloo  |Owner:  
Type:  bug|   Status:  new 
Priority:  high   |Milestone:  7.2.1   
   Component:  libraries (other)  |  Version:  7.1 
Keywords: | Testcase:  
   Blockedby: |   Difficulty:  
  Os:  Unknown/Multiple   | Blocking:  
Architecture:  Unknown/Multiple   |  Failure:  None/Unknown
--+-

Comment(by milan):

 I am working on it and getting closer, but an illness is slowing me down.

 Cheers,
 Milan

-- 
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] #916: windows installer should play nice with other Haskell tools

[GHC]

#916: windows installer should play nice with other Haskell tools
+---
Reporter:  claus.rei...@…   |Owner:  neil   
   
Type:  bug  |   Status:  patch  
   
Priority:  low  |Milestone:  _|_
   
   Component:  Build System |  Version:  6.4.2  
   
Keywords:   | Testcase:  N/A
   
   Blockedby:   |   Difficulty:  Moderate (less than a 
day)
  Os:  Windows  | Blocking: 
   
Architecture:  Unknown/Multiple |  Failure:  None/Unknown   
   
+---
Changes (by claus):

  * status:  new => patch
  * failure:  => None/Unknown


Comment:

 Ran into this yet again when trying out 7.0 and 7.1 snapshots. This has
 been delayed for so long now that I took a look and would like to suggest
 some changes. These changes do not address all points in this ticket, but:

 - add link to inno setup docs, so readers don't have to guess what ghc.iss
 might be

 - add `Task` section, and associated most Registry actions with separate
 (sub)tasks, so that file associations, default action, and `PATH` setting
 can be optional

 - copy license file into `doc` directory

 - install icon file again, so that `DefaultIcon` is no longer a dangling
 pointer (#4352)

 - only delete `ghc_haskell` key if empty (in case there were other tools
 using it)

 - add versioned `GHCi` to right-click menu (to allow for multiple tool
 installs)

 As I have zero experience with installer builders, you'll need to review.
 I suggest to review the modified `ghc.iss.in`, apply to HEAD and STABLE,
 then leave this ticket open for the remaining issues (such as claiming
 `.hs` for `ghc_haskell`).

-- 
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] #4334: Make lines stricter to fix space leak

[GHC]

#4334: Make lines stricter to fix space leak
--+-
Reporter:  daniel.is.fischer  |Owner: 
Type:  proposal   |   Status:  patch  
Priority:  normal |Milestone:  Not GHC
   Component:  libraries/base |  Version:  6.12.3 
Keywords:  lines, space leak  | Testcase: 
   Blockedby: |   Difficulty: 
  Os:  Unknown/Multiple   | Blocking: 
Architecture:  Unknown/Multiple   |  Failure:  Other  
--+-
Changes (by daniel.is.fischer):

  * status:  new => patch


Comment:

 Discussion thread:
 http://haskell.org/pipermail/libraries/2010-September/014420.html
 There were some strong reservations about making lines stricter, since
 that's against the general spirit of Data.List.[[BR]]
 Nevertheless, there was also support for the original proposal.
 Further, the point was raised that the proposed fix (which no longer
 changes the strictness) may only temporarily work.

 Altogether, it didn't come to an entirely clear conclusion, but since the
 only point that received real opposition is eliminated, I think we should
 apply the patch to (at least for the time being) fix the leak.

 I've added a testcase programme, to be compiled with optimisations and
 given T4334.in as input, criterion for success is maximum resident memory
 less than 100,000 bytes. I don't know how to specify that criterion for
 the test driver, otherwise I'd have made a patch for the testsuite myself.

 Please review.

-- 
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] #4321: Unexpected stack overflow prevented by superfluous type annotation

[GHC]

#4321: Unexpected stack overflow prevented by superfluous type annotation
---+
  Reporter:  bjpop |  Owner:  igloo   
  Type:  bug   | Status:  new 
  Priority:  normal|  Milestone:  
 Component:  Compiler  |Version:  6.13
Resolution:|   Keywords:  
  Testcase:  T4321 |  Blockedby:  
Difficulty:| Os:  Unknown/Multiple
  Blocking:|   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---+

Comment(by daniel.is.fischer):

 I'm on i686, linux (openSUSE 11.1).
 ghc-6.12.3:
 {{{
 da...@linux-mkk1:~/Haskell/Hacking/liststuff/testsuite/tests/ghc-
 regress/perf/should_run> ghc -O -fforce-recomp --make T4321
 [1 of 1] Compiling Main ( T4321.hs, T4321.o )
 Linking T4321 ...
 da...@linux-mkk1:~/Haskell/Hacking/liststuff/testsuite/tests/ghc-
 regress/perf/should_run> ./T4321
 3.1415926535897634
 }}}
 Today's HEAD:
 {{{
 da...@linux-mkk1:~/Haskell/Hacking/liststuff/testsuite/tests/ghc-
 regress/perf/should_run> ~/Haskell/Hacking/liststuff/inplace/bin/ghc-
 stage2 --version
 The Glorious Glasgow Haskell Compilation System, version 7.1.20101019
 da...@linux-mkk1:~/Haskell/Hacking/liststuff/testsuite/tests/ghc-
 regress/perf/should_run> ~/Haskell/Hacking/liststuff/inplace/bin/ghc-
 stage2 -O --make T4321
 [1 of 1] Compiling Main ( T4321.hs, T4321.o )
 Linking T4321 ...
 da...@linux-mkk1:~/Haskell/Hacking/liststuff/testsuite/tests/ghc-
 regress/perf/should_run> ./T4321
 3.1415926535897634
 }}}
 I get the same result with C, via C, with or without excess-precision...

 Platform issue, then. Print it only with 14 places of precision?

-- 
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] #3516: [PATCH] ppc64: broken 'foreign import wrapper'

[GHC]

#3516: [PATCH] ppc64: broken 'foreign import wrapper'
--+-
  Reporter:  slyfox   |  Owner: 
  Type:  bug  | Status:  patch  
  Priority:  high |  Milestone:  6.12.2 
 Component:  Compiler (FFI)   |Version:  7.1
Resolution:   |   Keywords:  ffi, wrapper, patch
  Testcase:  yet  |  Blockedby: 
Difficulty:  Unknown  | Os:  Unknown/Multiple   
  Blocking:   |   Architecture:  powerpc64  
   Failure:  Incorrect result at runtime  |  
--+-
Changes (by igloo):

  * status:  new => patch


-- 
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] #4410: Unable to install GHC on Mac

[GHC]

#4410: Unable to install GHC on Mac
---+
Reporter:  MeineWenigkeit  |Owner:   
Type:  bug |   Status:  new  
Priority:  normal  |Milestone:   
   Component:  None|  Version:  6.12.3   
Keywords:  | Testcase:   
   Blockedby:  |   Difficulty:   
  Os:  MacOS X | Blocking:   
Architecture:  x86_64 (amd64)  |  Failure:  Installing GHC failed
---+

Comment(by igloo):

 Hmm, I have `Xcode 3.1.4` (according to `xcodebuild -version`).

 Do any OS X people know what's going on?

-- 
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] #4321: Unexpected stack overflow prevented by superfluous type annotation

[GHC]

#4321: Unexpected stack overflow prevented by superfluous type annotation
---+
  Reporter:  bjpop |  Owner:  igloo   
  Type:  bug   | Status:  new 
  Priority:  normal|  Milestone:  
 Component:  Compiler  |Version:  6.13
Resolution:|   Keywords:  
  Testcase:  T4321 |  Blockedby:  
Difficulty:| Os:  Unknown/Multiple
  Blocking:|   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---+

Comment(by igloo):

 Daniel, what platform are you on?

 It looks right here:
 {{{
 $ '/home/ian/ghc/7.0-branch/ghc/inplace/bin/ghc-stage2' -fforce-recomp
 -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts
 -o T4321 T4321.hs  -O
 $ ./T4321
 3.1415926535897643
 $ cat T4321.stdout
 3.1415926535897643
 }}}
 (and similarly passes all ways), and is run the "normal" way as part of
 validate, so I imagine works on the other common platforms too.

-- 
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] #2271: floor, ceiling, round :: Double -> Int are awesomely slow

[GHC]

#2271: floor, ceiling, round :: Double -> Int are awesomely slow
--+-
Reporter:  dons   |Owner:  daniel.is.fischer
Type:  bug|   Status:  patch
Priority:  low|Milestone:  7.0.1
   Component:  libraries/base |  Version:  7.1  
Keywords:  performance, math, double  | Testcase:   
   Blockedby: |   Difficulty:  Unknown  
  Os:  Unknown/Multiple   | Blocking:   
Architecture:  Unknown/Multiple   |  Failure:  None/Unknown 
--+-

Comment(by michalt):

 I've built GHC with the new patch on x86_64 and it doesn't introduce any
 failures in the testsuite. :)

 As for the negative zero I have absolutely no idea whether it's really
 important. Though functions having different results with and without
 optimisations make me feel uneasy.

-- 
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] #2965: GHC on OS X does not compile 64-bit

[GHC]

#2965: GHC on OS X does not compile 64-bit
+---
Reporter:  Axman6   |Owner:  igloo
Type:  feature request  |   Status:  new  
Priority:  normal   |Milestone:  7.0.1
   Component:  Compiler |  Version:   
Keywords:  64bit| Testcase:   
   Blockedby:   |   Difficulty:  Unknown  
  Os:  MacOS X  | Blocking:   
Architecture:  x86_64 (amd64)   |  Failure:  Installing GHC failed
+---
Changes (by agerdes):

 * cc: a...@… (removed)


-- 
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] #2965: GHC on OS X does not compile 64-bit

[GHC]

#2965: GHC on OS X does not compile 64-bit
+---
Reporter:  Axman6   |Owner:  igloo
Type:  feature request  |   Status:  new  
Priority:  normal   |Milestone:  7.0.1
   Component:  Compiler |  Version:   
Keywords:  64bit| Testcase:   
   Blockedby:   |   Difficulty:  Unknown  
  Os:  MacOS X  | Blocking:   
Architecture:  x86_64 (amd64)   |  Failure:  Installing GHC failed
+---
Changes (by sekl):

 * cc: skl...@… (removed)


-- 
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] #1058: Highlight matching parantheses in Visual Studio

[GHC]

#1058: Highlight matching parantheses in Visual Studio
--+-
  Reporter:  m4dc4p   |  Owner:  
  Type:  feature request  | Status:  closed  
  Priority:  normal   |  Milestone:  Not GHC 
 Component:  Visual Haskell   |Version:  6.6 
Resolution:  wontfix  |   Keywords:  
  Testcase:   |  Blockedby:  
Difficulty:  Unknown  | Os:  Unknown/Multiple
  Blocking:   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown |  
--+-

Comment(by michalt):

 Oh, I see. Thanks for info. :)

-- 
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] #1058: Highlight matching parantheses in Visual Studio

[GHC]

#1058: Highlight matching parantheses in Visual Studio
--+-
  Reporter:  m4dc4p   |  Owner:  
  Type:  feature request  | Status:  closed  
  Priority:  normal   |  Milestone:  Not GHC 
 Component:  Visual Haskell   |Version:  6.6 
Resolution:  wontfix  |   Keywords:  
  Testcase:   |  Blockedby:  
Difficulty:  Unknown  | Os:  Unknown/Multiple
  Blocking:   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown |  
--+-

Comment(by m4dc4p):

 The component is "visual haskell", which was an VS extension released some
 years ago. Long, long out of date.

 But that's why the bug is here.

-- 
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] #1058: Highlight matching parantheses in Visual Studio

[GHC]

#1058: Highlight matching parantheses in Visual Studio
--+-
  Reporter:  m4dc4p   |  Owner:  
  Type:  feature request  | Status:  closed  
  Priority:  normal   |  Milestone:  Not GHC 
 Component:  Visual Haskell   |Version:  6.6 
Resolution:  wontfix  |   Keywords:  
  Testcase:   |  Blockedby:  
Difficulty:  Unknown  | Os:  Unknown/Multiple
  Blocking:   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown |  
--+-
Changes (by michalt):

 * cc: michal.terep...@… (added)
  * failure:  => None/Unknown
  * status:  new => closed
  * resolution:  => wontfix


Comment:

 Unless I'm missing something, this is not something that can be fixed
 in/by GHC..

-- 
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] #1499: Visual Haskell installer issue(s)

[GHC]

#1499: Visual Haskell installer issue(s)
-+--
  Reporter:  simonmar|  Owner: 
  Type:  bug | Status:  closed 
  Priority:  normal  |  Milestone:  Not GHC
 Component:  Visual Haskell  |Version:  6.6.1  
Resolution:  wontfix |   Keywords: 
  Testcase:  |  Blockedby: 
Difficulty:  Unknown | Os:  Windows
  Blocking:  |   Architecture:  x86
   Failure:  None/Unknown|  
-+--
Changes (by michalt):

 * cc: michal.terep...@… (added)
  * failure:  => None/Unknown
  * status:  new => closed
  * resolution:  => wontfix


Comment:

 All the links in the bug description are dead. And looking at above
 comments, I guess there's no point in keeping this open.

-- 
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] #4417: Quasiquoting without bloating

[GHC]

#4417: Quasiquoting without bloating
-+--
Reporter:  rrnewton  |Owner:  
Type:  feature request   |   Status:  new 
Priority:  high  |Milestone:  
   Component:  Compiler  |  Version:  6.13
Keywords:  executable size   | Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--
Changes (by rrnewton):

 * cc: rrnew...@… (added)
  * keywords:  => executable size


-- 
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] #4417: Quasiquoting without bloating

[GHC]

#4417: Quasiquoting without bloating
-+--
Reporter:  rrnewton  |Owner:  
Type:  feature request   |   Status:  new 
Priority:  high  |Milestone:  
   Component:  Compiler  |  Version:  6.13
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--
Changes (by simonpj):

  * priority:  normal => high


-- 
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] #4417: Quasiquoting without bloating

[GHC]

#4417: Quasiquoting without bloating
-+--
Reporter:  rrnewton  |Owner:  
Type:  feature request   |   Status:  new 
Priority:  normal|Milestone:  
   Component:  Compiler  |  Version:  6.13
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by simonpj):

 Indeed.  See #4387 for discussion of the issue.  Needs thought for 7.2.

 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

Re: [GHC] #4387: Huge executables with GHC 7

[GHC]

#4387: Huge executables with GHC 7
--+-
Reporter:  daniel.is.fischer  |Owner:   
Type:  bug|   Status:  merge
Priority:  normal |Milestone:  7.0.1
   Component:  Compiler   |  Version:  7.1  
Keywords:  executable size| Testcase:   
   Blockedby: |   Difficulty:   
  Os:  Linux  | Blocking:   
Architecture:  x86|  Failure:  Other
--+-

Comment(by simonpj):

 After merting, please close this ticket, since we've solved the immediate
 problem with 'vector'.  Meanwhile, #4417 keeps open the more general
 question of linking only what we need for runtime.

 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

Re: [GHC] #4338: weird discrepancies between TFs and FDs in GHC7

[GHC]

#4338: weird discrepancies between TFs and FDs in GHC7
+---
Reporter:  illissius|Owner:
Type:  bug  |   Status:  new   
Priority:  highest  |Milestone:  7.0.1 
   Component:  Compiler (Type checker)  |  Version:  6.13  
Keywords:   | Testcase:
   Blockedby:   |   Difficulty:
  Os:  Linux| Blocking:
Architecture:  x86  |  Failure:  Compile-time crash
+---

Comment(by simonpj):

 I'm afraid GHC 7.0 won't handle superclass equalities.  We just ran out of
 time.  Sorry.  Thanks for the nice example though.

 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

Re: [GHC] #4405: tcfail138 compiles but shouldn't

[GHC]

#4405: tcfail138 compiles but shouldn't
+---
  Reporter:  daniel.is.fischer  |  Owner:  
  Type:  bug| Status:  closed  
  Priority:  normal |  Milestone:  
 Component:  Test Suite |Version:  7.1 
Resolution:  fixed  |   Keywords:  
  Testcase: |  Blockedby:  
Difficulty: | Os:  Unknown/Multiple
  Blocking: |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown   |  
+---
Changes (by simonpj):

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


Comment:

 Done

-- 
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] #4395: T1735(ghci) failing with core-lint error

[GHC]

#4395: T1735(ghci) failing with core-lint error
--+-
  Reporter:  simonmar |  Owner:  
  Type:  bug  | Status:  closed  
  Priority:  highest  |  Milestone:  7.0.1   
 Component:  Compiler (Type checker)  |Version:  6.12.3  
Resolution:  fixed|   Keywords:  
  Testcase:   |  Blockedby:  
Difficulty:   | Os:  Unknown/Multiple
  Blocking:   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown |  
--+-
Changes (by simonpj):

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


Comment:

 Fixed.

-- 
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] #4394: IPRun failure

[GHC]

#4394: IPRun failure
--+-
  Reporter:  simonmar |  Owner:  
  Type:  bug  | Status:  closed  
  Priority:  highest  |  Milestone:  7.0.1   
 Component:  Compiler (Type checker)  |Version:  6.12.3  
Resolution:  fixed|   Keywords:  
  Testcase:   |  Blockedby:  
Difficulty:   | Os:  Unknown/Multiple
  Blocking:   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown |  
--+-
Changes (by simonpj):

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


Comment:

 Fixed.

-- 
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] #3651: GADT type checking too liberal

[GHC]

#3651: GADT type checking too liberal
--+-
  Reporter:  MartijnVanSteenbergen|  Owner:  simonpj 
  Type:  bug  | Status:  closed  
  Priority:  normal   |  Milestone:  7.0.1   
 Component:  Compiler (Type checker)  |Version:  6.10.4  
Resolution:  fixed|   Keywords:  
  Testcase:  T3651|  Blockedby:  
Difficulty:   | Os:  Unknown/Multiple
  Blocking:   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown |  
--+-
Changes (by simonpj):

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


Comment:

 Fixed.  We now get all three errors.

 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

Re: [GHC] #4389: Unexpcted failure, ambiguous type variable defaulted (ghci)

[GHC]

#4389: Unexpcted failure, ambiguous type variable defaulted (ghci)
--+-
Reporter:  daniel.is.fischer  |Owner: 
Type:  bug|   Status:  new
Priority:  highest|Milestone:  7.0.1  
   Component:  Test Suite |  Version:  7.1
Keywords: | Testcase: 
   Blockedby: |   Difficulty: 
  Os:  Unknown/Multiple   | Blocking: 
Architecture:  Unknown/Multiple   |  Failure:  Incorrect result at runtime
--+-

Comment(by simonpj):

 Fixed

-- 
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] #4392: tcrun020 failure

[GHC]

#4392: tcrun020 failure
--+-
  Reporter:  simonmar |  Owner:  
  Type:  bug  | Status:  closed  
  Priority:  highest  |  Milestone:  7.0.1   
 Component:  Compiler (Type checker)  |Version:  6.12.3  
Resolution:  fixed|   Keywords:  
  Testcase:   |  Blockedby:  
Difficulty:   | Os:  Unknown/Multiple
  Blocking:   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown |  
--+-
Changes (by simonpj):

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


Comment:

 Now fixed

-- 
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] #4401: Functional dependencies regression

[GHC]

#4401: Functional dependencies regression
---+
  Reporter:  rl|  Owner:  simonpj 
  Type:  bug   | Status:  closed  
  Priority:  highest   |  Milestone:  7.0.1   
 Component:  Compiler  |Version:  7.1 
Resolution:  fixed |   Keywords:  
  Testcase:  T4401 |  Blockedby:  
Difficulty:| Os:  Unknown/Multiple
  Blocking:|   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---+
Changes (by simonpj):

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


Comment:

 This is fixed now.  Test is in place.

-- 
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] #4097: Runtime segfaults on +RTS -hr

[GHC]

#4097: Runtime segfaults on +RTS -hr
-+--
  Reporter:  mightybyte  |  Owner:
  Type:  bug | Status:  closed
  Priority:  normal  |  Milestone:  7.0.1 
 Component:  Runtime System  |Version:  6.12.1
Resolution:  fixed   |   Keywords:
  Testcase:  |  Blockedby:
Difficulty:  | Os:  Linux 
  Blocking:  |   Architecture:  x86_64 (amd64)
   Failure:  Runtime crash   |  
-+--
Changes (by igloo):

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


Comment:

 I've just fixed a retainer profiling segfault, and retainer profiling of
 GHC now works. The patch will be in the second 7.0.1 release candidate:
 {{{
 Tue Oct 19 14:27:27 BST 2010  Ian Lynagh 
   * Fix a retainer profiling segfault
   The bitmap type wasn't big enough to hold large bitmaps on 64 bit
   platforms. Profiling GHC was segfaulting when retainStack was handling a
   size 33 bitmap.
 }}}
 I'm optimistically assuming this will fix your segfault too; please reopen
 if not.

-- 
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: #4316: Getting the lexer state to check for "AlternativeLayoutMode"

[Simon Marlow]

On 18/10/2010 05:53, Vivian McPhail wrote:



On 18 October 2010 15:37, Vivian McPhail
mailto:haskell.vivian.mcph...@gmail.com>> wrote:

Hi,

In attempting to use the lexer to see whether we are within an
alternative layout context:

[..]


I have a function which tells us if there is layout going on:

activeContext :: P Bool
activeContext = do
   ctxt <- getALRContext
   expc <- getAlrExpectingOCurly
   impt <- implicitTokenPending
   case (ctxt,expc) of
 ([],Nothing) -> return impt
 _other   -> return True


Okay, this function is doing the right thing.  I also tried counting
curly brackets, which also doesn't work for the same reason:

In "AlternativeLayoutMode," when an EOF is encountered and there is an
outstanding context, the context is removed  and a closing curly is inserted

  (ITeof, ALRLayout _ _ : ls, _) ->
  do setALRContext ls
 setNextToken t
 return (L thisLoc ITccurly)

So as it stands, if we simply lex the ghci command line, we will never
be inside a layout context once we see the EOF token.


Right, so you need to lex up to the end of the line, but without letting 
the lexer see the EOF token, presumably?


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

Re: [GHC] #4416: Quasiquoting without bloating

[GHC]

#4416: Quasiquoting without bloating
--+-
  Reporter:  rrnewton |  Owner:  
  Type:  feature request  | Status:  closed  
  Priority:  normal   |  Milestone:  
 Component:  Compiler |Version:  6.13
Resolution:  duplicate|   Keywords:  
  Testcase:   |  Blockedby:  
Difficulty:   | Os:  Unknown/Multiple
  Blocking:   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown |  
--+-
Changes (by simonpj):

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


Comment:

 Dup of #4417

-- 
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] #4417: Quasiquoting without bloating

[GHC]

#4417: Quasiquoting without bloating
-+--
Reporter:  rrnewton  |   Owner:  
Type:  feature request   |  Status:  new 
Priority:  normal|   Component:  Compiler
 Version:  6.13  |Keywords:  
Testcase:|   Blockedby:  
  Os:  Unknown/Multiple  |Blocking:  
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
-+--
 Quasiquoting is a compile-time feature, and sometimes can be useful for
 purposes as modest as multiline strings (see Hackage packages such as
 interpolatedstring-perl6).

 However, I found that using quasiquoting would add about twelve megabytes
 to final executable size (on 6.12.1 and 6.13.20090607).  It seems GHC
 links all of the libraries used at compile time into the final executable
 as well.  Could GHC prune these?

 Note: you can reproduce this effect with a simple hello world program like
 below:

 {{{
 import Text.InterpolatedString.Perl6 (q)
 foo :: String
 foo = [$q|
Well here is a
multi-line string!
 |]
 main = putStrLn 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

[GHC] #4416: Quasiquoting without bloating

[GHC]

#4416: Quasiquoting without bloating
-+--
Reporter:  rrnewton  |   Owner:  
Type:  feature request   |  Status:  new 
Priority:  normal|   Component:  Compiler
 Version:  6.13  |Keywords:  
Testcase:|   Blockedby:  
  Os:  Unknown/Multiple  |Blocking:  
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
-+--
 Quasiquoting is a compile-time feature, and sometimes can be useful for
 purposes as modest as multiline strings (see Hackage packages such as
 interpolatedstring-perl6).

 However, I found that using quasiquoting would add about twelve megabytes
 to final executable size (on 6.12.1 and 6.13.20090607).  It seems GHC
 links all of the libraries used at compile time into the final executable
 as well.  Could GHC prune these?

 Note: you can reproduce this effect with a simple hello world program like
 below:

 {{{
 import Text.InterpolatedString.Perl6 (q)
 foo :: String
 foo = [$q|
Well here is a
multi-line string!
 |]
 main = putStrLn 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