[GHC] #3719: Literate code with #

2009-12-03 Thread GHC
#3719: Literate code with #
-+--
Reporter:  zenzike   |   Owner:   
Type:  bug   |  Status:  new  
Priority:  normal|   Component:  Compiler (Parser)
 Version:  6.10.4|Keywords:   
  Os:  Unknown/Multiple  |Testcase:   
Architecture:  Unknown/Multiple  | Failure:  GHC rejects valid program
-+--
 Any literate script where the hash symbol # is in the first column of a
 file does not compile in ghc.

 For example,
 {{{
  foo = 1 + 2

 #
 }}}
 will give rise to the following error:
 {{{
 lexical error at character '\n'
 }}}

 This is rather annoying, since # is used in markup languages as a heading
 delimiter. The example compiles fine using hugs.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3719
GHC http://www.haskell.org/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] #3719: Literate code with #

2009-12-03 Thread GHC
#3719: Literate code with #
+---
  Reporter:  zenzike|  Owner:  
  Type:  bug| Status:  new 
  Priority:  normal |  Milestone:  
 Component:  Compiler (Parser)  |Version:  6.10.4  
Resolution: |   Keywords:  
Difficulty: | Os:  Unknown/Multiple
  Testcase: |   Architecture:  Unknown/Multiple
   Failure:  GHC rejects valid program  |  
+---
Changes (by duncan):

  * difficulty:  =

Comment:

 Note that the `#` makes it though the unlit into the .hspp code. Then of
 course it's not valid Haskell.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3719#comment:1
GHC http://www.haskell.org/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] #2401: aborting an STM transaction should throw an exception

2009-12-03 Thread GHC
#2401: aborting an STM transaction should throw an exception
--+-
  Reporter:  sclv |  Owner:  
  Type:  bug  | Status:  reopened
  Priority:  normal   |  Milestone:  6.14.1  
 Component:  Runtime System   |Version:  6.8.3   
Resolution:   |   Keywords:  
Difficulty:  Unknown  | Os:  Unknown/Multiple
  Testcase:   |   Architecture:  Unknown/Multiple
   Failure:  Incorrect result at runtime  |  
--+-
Changes (by simonmar):

  * failure:  None/Unknown = Incorrect result at runtime
  * summary:  unsafeIOToSTM discards exception handlers. = aborting an STM
  transaction should throw an exception
  * milestone:  6.10.1 = 6.14.1

Comment:

 (changing the bug title to reflect the underlying problem)

 Summary:

  * the STM transaction might be in the middle of an `unsafePerformIO` when
it is aborted.  The user has no control over this, since transactions
can be aborted by the RTS, and the use of `unsafePerformIO` might be in
a library somewhere.

  * The IO in the library expects to be able to catch exceptions and clean
 up
if it is interrupted, otherwise it might leave locks in place.  Imagine
pulling on some lazy I/O during an STM transaction, for example.

 As @sclv pointed out, we also need to fix

 [[TicketQuery(id=2558|)]]

 otherwise when the IO operation re-throws the abort exception, it will
 throw it synchronously.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2401#comment:10
GHC http://www.haskell.org/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] #3715: GHC API no longer exports location information for error/warning messages

2009-12-03 Thread GHC
#3715: GHC API no longer exports location information for error/warning messages
--+-
  Reporter:  greenrd  |  Owner:  igloo   
  Type:  bug  | Status:  new 
  Priority:  normal   |  Milestone:  
 Component:  GHC API  |Version:  6.12.1 RC1  
Resolution:   |   Keywords:  
Difficulty:  Easy (less than 1 hour)  | Os:  Unknown/Multiple
  Testcase:   |   Architecture:  Unknown/Multiple
   Failure:  Other|  
--+-
Comment (by simonmar):

 Replying to [comment:5 simonpj]:

  We should think about how to avoid this in future.  That is, a way to
 answer the question does this function form part of the advertised GHC
 API?.

 If this stuff is used by a client, then we should export it from GHC.
 Roughly speaking, we should look at clients from time to time to see what
 they're using that isn't exported from GHC, and decide whether (a) we want
 to put it there, or (b) we want to expose something else nicer.
 Eventually the GHC module will be useful enough on its own that we can
 start hiding the other modules in the GHC package.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3715#comment:7
GHC http://www.haskell.org/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] #2797: ghci stack overflows when ghc does not

2009-12-03 Thread GHC
#2797: ghci stack overflows when ghc does not
--+-
  Reporter:  TristanAllwood   |  Owner:  
  Type:  bug  | Status:  new 
  Priority:  normal   |  Milestone:  6.12.2  
 Component:  GHCi |Version:  6.11
Resolution:   |   Keywords:  
Difficulty:  Unknown  | Os:  Unknown/Multiple
  Testcase:   |   Architecture:  Unknown/Multiple
   Failure:  Runtime performance bug  |  
--+-
Changes (by fasta):

 * cc: fasta (added)

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2797#comment:8
GHC http://www.haskell.org/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] #3100: GHC Panic reifyType PredTy in HAppS.Data.IxSet.inferIxSet

2009-12-03 Thread GHC
#3100: GHC Panic reifyType PredTy in HAppS.Data.IxSet.inferIxSet
---+
  Reporter:  mightybyte|  Owner:  igloo   
  Type:  merge | Status:  new 
  Priority:  normal|  Milestone:  6.12 branch 
 Component:  Compiler  |Version:  6.10.1  
Resolution:|   Keywords:  
Difficulty:  Unknown   | Os:  Unknown/Multiple
  Testcase:  th/T3100  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---+
Changes (by simonpj):

  * testcase:  = th/T3100
  * owner:  = igloo
  * type:  bug = merge

Comment:

 Fixed I think
 {{{
 Mon Nov 30 09:52:04 PST 2009  simo...@microsoft.com
   * Fix Trac #3100: reifyType

   A type without any leading foralls may still have constraints
  eg:  ?x::Int = Int - Int

   But reifyType was failing in this case.

   Merge to 6.12.

 M ./compiler/typecheck/TcSplice.lhs -7 +12
 }}}
 Ian please merge

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3100#comment:9
GHC http://www.haskell.org/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] #3102: The impossible happened with implicit parameters

2009-12-03 Thread GHC
#3102: The impossible happened with implicit parameters
--+-
  Reporter:  Ashley Yakeley   |  Owner:  igloo   
  Type:  merge| Status:  new 
  Priority:  normal   |  Milestone:  6.12.1  
 Component:  Compiler (Type checker)  |Version:  6.10.1  
Resolution:   |   Keywords:  
Difficulty:  Unknown  | Os:  Linux   
  Testcase:  tyepcheck/should_fail/T3102  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown |  
--+-
Changes (by simonpj):

  * testcase:  = tyepcheck/should_fail/T3102
  * status:  reopened = new
  * type:  bug = merge
  * owner:  chak = igloo

Comment:

 You're right.  There was another bug lurking.
 {{{
 Mon Nov 30 09:44:41 PST 2009  simo...@microsoft.com
   * Fix Trac #3102: pre-matching polytypes

   When *pre-matching* two types
forall a. C1 = t1  ~  forall a. C2 = t2
   we were matching t1~t2, but totally ignoring C1,C2
   That's utterly wrong when pre-matching
  (?p::Int) = String  ~  a
   because we emerge with a:=String!

   All this is part of the impredicative story, which is about
   to go away, but still.

   Worth merging this to 6.12

 M ./compiler/typecheck/TcUnify.lhs -2 +3
 }}}
 Merge if possible to 6.12.

 Thanks for being persistent.

 Simon

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3102#comment:6
GHC http://www.haskell.org/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] #3654: Mach-O GHCi linker lacks support for a range of relocation entries

2009-12-03 Thread GHC
#3654: Mach-O GHCi linker lacks support for a range of relocation entries
-+--
  Reporter:  chak|  Owner:  
  Type:  bug | Status:  new 
  Priority:  normal  |  Milestone:  6.12 branch 
 Component:  Runtime System  |Version:  6.13
Resolution:  |   Keywords:  
Difficulty:  Unknown | Os:  MacOS X 
  Testcase:  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown|  
-+--
Comment (by simonmar):

 Replying to [comment:6 morrow]:
  What are the things that would need changing or doing to move ghci to
 exclusively use the system dynamic linker? What are the really problematic
 things (given the current implementation) that would need sorting out with
 respect to this?

 See [http://www.haskell.org/pipermail/cvs-ghc/2009-November/051196.html]
 and Manuel's reply.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3654#comment:8
GHC http://www.haskell.org/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] #3718: Can not bootstrap using 6.12.1-rc2

2009-12-03 Thread GHC
#3718: Can not bootstrap using 6.12.1-rc2
-+--
Reporter:  masao |   Owner: 
Type:  bug   |  Status:  new
Priority:  normal|   Milestone: 
   Component:  Build System  | Version:  6.12.1 RC1 
  Resolution:|Keywords: 
  Os:  Unknown/Multiple  |Testcase: 
Architecture:  Unknown/Multiple  | Failure:  Building GHC failed
-+--
Comment (by maeder):

 You need a working ghc to build a new ghc from sources.
 You may try to install
 http://www.haskell.org/ghc/dist/6.12.1-rc2/ghc-6.12.0.20091121-i386
 -unknown-linux-n.tar.bz2 first (or an older ghc version).

 With this ghc (or an older ghc) you should be able compile the sources
 http://www.haskell.org/ghc/dist/6.12.1-rc2/ghc-6.12.0.20091121-src.tar.bz2

 No porting should be necessary for your platform (and .hc are not
 available).

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3718#comment:1
GHC http://www.haskell.org/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] #3709: Data.Either.partitionEithers is not lazy enough

2009-12-03 Thread Simon Marlow

On 03/12/2009 14:12, Henning Thielemann wrote:


On Thu, 3 Dec 2009, Malcolm Wallace wrote:


#3709: Data.Either.partitionEithers is not lazy enough

This is a behavioural change, e.g.:
Main case partitionEithers1 [Left 'a', error Not me] of (x : _, _)
- x
Program error: Not me
Main case partitionEithers2 [Left 'a', error Not me] of (x : _, _)
- x
'a'


Yes, and isn't that the point of the bugfix? No non-bottoming program
has changed, but fewer programs fail now. I find it hard to imagine
that anyone could have been relying on getting a crash here.


Making something more lazy can cause a memory leak.


and a time leak, or a stack overflow.  People might complain if we made 
foldl' more lazy :-)


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


Re: [GHC] #414: GHC does not eforce that Main exports main

2009-12-03 Thread GHC
#414: GHC does not eforce that Main exports main
---+
  Reporter:  simonpj   |  Owner:  igloo   
  Type:  merge | Status:  new 
  Priority:  lowest|  Milestone:  6.12.2  
 Component:  Compiler  |Version:  6.10.4  
Resolution:  None  |   Keywords:  
Difficulty:  Unknown   | Os:  Unknown/Multiple
  Testcase:  mod174|   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---+
Comment (by igloo):

 {{{
 Mon Nov 30 04:04:04 PST 2009  Simon Marlow marlo...@gmail.com
   * add a test for #414
 }}}

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/414#comment:10
GHC http://www.haskell.org/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] #3677: Optimizer creates stack overflow on filtered CAF

2009-12-03 Thread GHC
#3677: Optimizer creates stack overflow on filtered CAF
+---
  Reporter:  jpet   |  Owner:  simonpj
  Type:  bug| Status:  new
  Priority:  normal |  Milestone:  6.12.2 
 Component:  Compiler   |Version:  6.10.4 
Resolution: |   Keywords: 
Difficulty: | Os:  Windows
  Testcase: |   Architecture:  x86
   Failure:  Runtime crash  |  
+---
Comment (by igloo):

 {{{
 Mon Nov 30 03:25:08 PST 2009  Simon Marlow marlo...@gmail.com
   * add a test for #3677
 }}}

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3677#comment:6
GHC http://www.haskell.org/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] #3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when loading module

2009-12-03 Thread GHC
#3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when loading module
-+--
Reporter:  fasta |   Owner:   
Type:  bug   |  Status:  new  
Priority:  normal|   Component:  GHCi 
 Version:  6.10.4|Keywords:   
  Os:  Unknown/Multiple  |Testcase:   
Architecture:  Unknown/Multiple  | Failure:  Other
-+--
 I get the following, which is caused by a bug in ghci, which probably
 results from ghci reusing .o files when it should not.

 Util.hs is a user-defined file on which the module which is currently
 being loaded (Main.hs) depends.

 {{{interactive: ./Util.o: unknown symbol `_GLOBAL_OFFSET_TABLE_'}}}

 If I remove all the .o files, the module happily loads in ghci.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3720
GHC http://www.haskell.org/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] #3721: Can't install base-4.0.0.0 !!

2009-12-03 Thread GHC
#3721: Can't install base-4.0.0.0 !!
-+--
Reporter:  guest |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Component:  Compiler
 Version:  6.10.4|Keywords:  
  Os:  Unknown/Multiple  |Testcase:  
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
-+--
 mozh...@mozhgan-kch:~/Desktop/base-4.0.0.0$ runhaskell Setup.hs configure
 --ghc

 interactive:1:22:
 attempting to use module `System.IO' (System/IO.hs) which is not
 loaded

 interactive:1:22: Not in scope: `System.IO.stderr'

 interactive:1:22: Not in scope: `System.IO.stdin'
 ghc-6.8.2: panic! (the 'impossible' happened)
   (GHC version 6.8.2 for i386-unknown-linux):
 interactiveUI:setBuffering

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3721
GHC http://www.haskell.org/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] #3658: Dynamically link GHCi on platforms that support it

2009-12-03 Thread GHC
#3658: Dynamically link GHCi on platforms that support it
---+
  Reporter:  simonmar  |  Owner:  
  Type:  task  | Status:  new 
  Priority:  high  |  Milestone:  6.14.1  
 Component:  GHCi  |Version:  6.10.4  
Resolution:|   Keywords:  
Difficulty:  Unknown   | Os:  Unknown/Multiple
  Testcase:|   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---+
Changes (by hgolden):

 * cc: howard_b_gol...@yahoo.com (added)

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3658#comment:2
GHC http://www.haskell.org/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] #2615: ghci doesn't play nice with linker scripts

2009-12-03 Thread GHC
#2615: ghci doesn't play nice with linker scripts
--+-
  Reporter:  AlecBerryman |  Owner:  hgolden

  Type:  bug  | Status:  new

  Priority:  normal   |  Milestone:  6.14.1 

 Component:  GHCi |Version:  6.10.1 

Resolution:   |   Keywords:  dlopen, dynamic 
linking
Difficulty:  Unknown  | Os:  Linux  

  Testcase:   |   Architecture:  Unknown/Multiple   

   Failure:  Incorrect result at runtime  |  
--+-
Changes (by hgolden):

  * keywords:  = dlopen, dynamic linking
  * failure:  None/Unknown = Incorrect result at runtime
  * owner:  = hgolden

Comment:

 I have been testing a patch which has been reviewed by Simon M. and Duncan
 C. I am now incorporating the changes they requested and preparing a test
 case. I expect to have this completed by December 14, 2009.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2615#comment:15
GHC http://www.haskell.org/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] #3722: Haskeline Iconv needs HAVE_LANGINFO_H

2009-12-03 Thread GHC
#3722: Haskeline Iconv needs HAVE_LANGINFO_H
---+
Reporter:  donn|   Owner:  
Type:  bug |  Status:  new 
Priority:  normal  |   Component:  Compiler
 Version:  6.12.1 RC1  |Keywords:  
  Os:  Other   |Testcase:  
Architecture:  x86 | Failure:  None/Unknown
---+
 per libraries/base/GHC/IO/Encoding/Iconv.hs,
 libraries/haskeline/System/Console/Haskeline/Backend/Iconv.hsc should test
 for HAVE_LANGINFO_H, and default codeset to  in its absence.  (No
 langinfo.h on Haiku.)

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3722
GHC http://www.haskell.org/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] #3722: Haskeline Iconv needs HAVE_LANGINFO_H

2009-12-03 Thread GHC
#3722: Haskeline Iconv needs HAVE_LANGINFO_H
-+--
Reporter:  donn  |   Owner: 
Type:  bug   |  Status:  new
Priority:  normal|   Milestone: 
   Component:  Compiler  | Version:  6.12.1 RC1 
  Resolution:|Keywords: 
  Os:  Other |Testcase: 
Architecture:  x86   | Failure:  Building GHC failed
-+--
Changes (by donn):

  * failure:  None/Unknown = Building GHC failed

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3722#comment:1
GHC http://www.haskell.org/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] #3723: SharedMem.hsc should include fcntl.h, not sys/fcntl.h

2009-12-03 Thread GHC
#3723: SharedMem.hsc should include fcntl.h, not sys/fcntl.h
---+
Reporter:  donn|   Owner: 
Type:  bug |  Status:  new
Priority:  normal  |   Component:  Compiler   
 Version:  6.12.1 RC1  |Keywords: 
  Os:  Other   |Testcase: 
Architecture:  x86 | Failure:  Building GHC failed
---+
 libraries/unix/System/Posix/SharedMem.hsc should include fcntl.h, per
 POSIX 1003.1 I believe, not sys/fcntl.h

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3723
GHC http://www.haskell.org/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] #3724: rts/package.conf.d specifies -lm for all platforms

2009-12-03 Thread GHC
#3724: rts/package.conf.d specifies -lm for all platforms
---+
Reporter:  donn|   Owner: 
Type:  bug |  Status:  new
Priority:  normal  |   Component:  Compiler   
 Version:  6.12.1 RC1  |Keywords: 
  Os:  Other   |Testcase: 
Architecture:  x86 | Failure:  Building GHC failed
---+
 rts/package.conf.d:  extra-libraries  m  ... requires -lm on all
 platforms, but Haiku and presumably others don't need it or support it.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3724
GHC http://www.haskell.org/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] #3725: Annotations not written to interface files

2009-12-03 Thread GHC
#3725: Annotations not written to interface files
-+--
Reporter:  rl|   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Component:  Compiler
 Version:  6.13  |Keywords:  
  Os:  Unknown/Multiple  |Testcase:  
Architecture:  Unknown/Multiple  | Failure:  Other   
-+--
 Small example:
 {{{
 module C where

 data T a = T a
 }}}
 Compile it:
 {{{
 newbie:tests rl$ ~/projects/ndp/ghc/inplace/bin/ghc-stage2 -O2 -c C.hs
 newbie:tests rl$ ls -l C.hi
 -rw-r--r--  1 rl  rl  485  4 Dec 12:53 C.hi
 }}}
 Add an annotation: `{-# ANN type T () #-}`. Compile:
 {{{
 newbie:tests rl$ ~/projects/ndp/ghc/inplace/bin/ghc-stage2 -O2 -c C.hs
 Loading package ghc-prim ... linking ... done.
 Loading package integer-gmp ... linking ... done.
 Loading package base ... linking ... done.
 Loading package ffi-1.0 ... linking ... done.
 newbie:tests rl$ ls -l C.hi
 -rw-r--r--  1 rl  rl  485  4 Dec 12:53 C.hi
 }}}
 Note that the interface file hasn't been updated. Remove `C.hi` and
 recompile:
 {{{
 newbie:tests rl$ rm C.hi
 newbie:tests rl$ ~/projects/ndp/ghc/inplace/bin/ghc-stage2 -O2 -c C.hs
 Loading package ghc-prim ... linking ... done.
 Loading package integer-gmp ... linking ... done.
 Loading package base ... linking ... done.
 Loading package ffi-1.0 ... linking ... done.
 newbie:tests rl$ ls -l C.hi
 -rw-r--r--  1 rl  rl  507  4 Dec 12:54 C.hi
 }}}
 Only now has the annotation been written to `C.hi`.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3725
GHC http://www.haskell.org/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] #3710: WriteFile: invalid argument (The handle is invalid.)

2009-12-03 Thread GHC
#3710: WriteFile: invalid argument (The handle is invalid.)
---+
Reporter:  dherington  |   Owner: 
Type:  bug |  Status:  closed 
Priority:  normal  |   Milestone: 
   Component:  Runtime System  | Version:  6.10.4 
  Resolution:  invalid |Keywords:  garbage collector  
  Os:  Windows |Testcase: 
Architecture:  x86 | Failure:  Incorrect result at runtime
---+
Changes (by dherington):

  * status:  new = closed
  * resolution:  = invalid

Comment:

 I have discovered that my failure to zero the hEvent member of the
 OVERLAPPED structure was causing the reported failures in writeFile.  So
 I'm invalidating this ticket.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3710#comment:1
GHC http://www.haskell.org/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] #3726: Internal error compiling ghc-syb-0.1.2.1

2009-12-03 Thread GHC
#3726: Internal error compiling ghc-syb-0.1.2.1
-+--
Reporter:  DavidHalperin |   Owner:
Type:  bug   |  Status:  new   
Priority:  normal|   Component:  Compiler  
 Version:  6.10.4|Keywords:
  Os:  Unknown/Multiple  |Testcase:
Architecture:  Unknown/Multiple  | Failure:  Compile-time crash
-+--
 On Ubuntu Karmic x86_64 (installed from the apt repo), when I try to
 compile the ghc-syb-0.1.2.1 package I get the following output:

 Building ghc-syb-0.1.2.1...[[BR]]
 [1 of 2] Compiling GHC.SYB.Instances ( src/GHC/SYB/Instances.hs,
 dist/build/GHC/SYB/Instances.o )[[BR]]
 ghc: internal error: evacuate: strange closure type 13771848
 (GHC version 6.10.4 for x86_64_unknown_linux)
 Please report this as a GHC bug:
 http://www.haskell.org/ghc/reportabug

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3726
GHC http://www.haskell.org/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] #3727: several Haiku platform defs

2009-12-03 Thread GHC
#3727: several Haiku platform defs
---+
Reporter:  donn|   Owner: 
Type:  bug |  Status:  new
Priority:  normal  |   Component:  Compiler   
 Version:  6.12.1 RC1  |Keywords: 
  Os:  Other   |Testcase: 
Architecture:  x86 | Failure:  Building GHC failed
---+
 Attached diffs support the Haiku OS in several places where there are
 already platform tests.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3727
GHC http://www.haskell.org/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] #3728: configure should omit full path in unistd.h, stdlib.h return type tests

2009-12-03 Thread GHC
#3728: configure should omit full path in unistd.h, stdlib.h return type tests
---+
Reporter:  donn|   Owner: 
Type:  bug |  Status:  new
Priority:  normal  |   Component:  Compiler   
 Version:  6.12.1 RC1  |Keywords: 
  Os:  Other   |Testcase: 
Architecture:  x86 | Failure:  Building GHC failed
---+
 autoconf AC_EGREP_HEADER actually uses the C preprocessor, so include file
 names will be resolved properly and should not specify full (potentially
 wrong) path.  (Wrong path on Haiku.)

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