GHC | 1 Jun 09:59 2007

Re: [GHC] #1361: When trying to run yi, it fails to compile main, and exits with an error

#1361: When trying to run yi, it fails to compile main, and exits with an error
-------------------------+--------------------------------------------------
    Reporter:  guest     |        Owner:         
        Type:  bug       |       Status:  new    
    Priority:  normal    |    Milestone:  6.8    
   Component:  Compiler  |      Version:  6.6.1  
    Severity:  normal    |   Resolution:         
    Keywords:            |   Difficulty:  Unknown
          Os:  Linux     |     Testcase:         
Architecture:  x86       |  
-------------------------+--------------------------------------------------
Comment (by guest):

 I have a similar setup and a similar problem. It manifests itself slightly
 differently. I have a gentoo system with my own ebuilds for ghc-6.6.1
 (simply renaming the 6.6 ebuild from the haskell overlay) and
 cabal-1.1.6.2 (likewise).
 When I try to install yi (using the 0.2 ebuild from the overlay)
 everything goes (apparently) fine until the linking stage when the
 following output ensues:
 {{{
 1 of 4] Compiling Yi.Kernel        ( Yi/Kernel.hs, dist/build/yi/yi-
 tmp/Yi/Kernel.o )
 [2 of 4] Compiling Yi.Debug         ( Yi/Debug.hs, dist/build/yi/yi-
 tmp/Yi/Debug.o )
 [3 of 4] Compiling Yi.Boot          ( Yi/Boot.hs, dist/build/yi/yi-
 tmp/Yi/Boot.o )
 [4 of 4] Compiling Main             ( Main.hs, dist/build/yi/yi-tmp/Main.o
 )
 Linking dist/build/yi/yi ...
(Continue reading)

GHC | 1 Jun 10:21 2007

Re: [GHC] #1400: :set +r doesn't work for interpreted modules

#1400: :set +r doesn't work for interpreted modules
----------------------------------+-----------------------------------------
    Reporter:  iampure <at> gmail.com  |        Owner:                  
        Type:  bug                |       Status:  new             
    Priority:  normal             |    Milestone:  6.10            
   Component:  GHCi               |      Version:  6.7             
    Severity:  normal             |   Resolution:                  
    Keywords:                     |   Difficulty:  Moderate (1 day)
          Os:  Unknown            |     Testcase:                  
Architecture:  Unknown            |  
----------------------------------+-----------------------------------------
Changes (by simonmar):

  * difficulty:  Unknown => Moderate (1 day)
  * component:  Compiler => GHCi
  * milestone:  => 6.10
  * priority:  high => normal
  * summary:  Incoherent cache behaviour ghci in combination with
              Debug.trace => :set +r doesn't work for
              interpreted modules

Comment:

 `:set +r` is supposed to do what you want, but it has never worked for
 interpreted code, only compiled code (and of course, the debugger only
 works for interpreted code, so that doesn't really help).  I've changed
 the subject of the bug to reflect this.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1400>
(Continue reading)

GHC | 1 Jun 16:30 2007

Re: [GHC] #393: functions without implementations

#393: functions without implementations
----------------------------------------+-----------------------------------
    Reporter:  c_maeder                 |        Owner:  simonpj    
        Type:  feature request          |       Status:  new        
    Priority:  normal                   |    Milestone:  6.8        
   Component:  Compiler (Type checker)  |      Version:  None       
    Severity:  normal                   |   Resolution:  None       
    Keywords:                           |   Difficulty:  Easy (1 hr)
          Os:  Multiple                 |     Testcase:             
Architecture:  Multiple                 |  
----------------------------------------+-----------------------------------
Changes (by maeder <at> tzi.de):

  * architecture:  Unknown => Multiple
  * difficulty:  Unknown => Easy (1 hr)
  * component:  None => Compiler (Type checker)
  * priority:  lowest => normal
  * severity:  minor => normal
  * status:  assigned => new
  * owner:  nobody => simonpj
  * os:  Unknown => Multiple

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/393>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs <at> haskell.org
(Continue reading)

GHC | 1 Jun 16:37 2007

[GHC] #1401: otherwise ambiguous field names shouldn’t be treated as ambiguous when the data constructor is known

#1401: otherwise ambiguous field names shouldn’t be treated as ambiguous when
the data constructor is known
-----------------------------------------+----------------------------------
  Reporter:  g9ks157k <at> acme.softbase.org  |          Owner:         
      Type:  feature request             |         Status:  new    
  Priority:  normal                      |      Milestone:         
 Component:  Compiler                    |        Version:  6.6.1  
  Severity:  normal                      |       Keywords:         
Difficulty:  Unknown                     |             Os:  Unknown
  Testcase:                              |   Architecture:  Unknown
-----------------------------------------+----------------------------------
Consider these three module definitions:
 {{{
 module A where
     data A = A { label :: Char }
 }}}
 {{{
 module B where
     data B = B { label :: Char }
 }}}
 {{{
 module X where
     import A
     import B

     a = A { label = 'a' }

     b = B { label = 'b' }

     f (A { label = a }) (B { label = b }) = (a,b)
(Continue reading)

Wolfgang Jeltsch | 1 Jun 16:43 2007

Re: [Haskell] ambiguous record field names which actually aren’t ambigious

Am Dienstag, 29. Mai 2007 18:46 schrieb Simon Peyton-Jones:
> | But wouldn’t it be worthwhile to allow this kind of stuff as a language
> | extension?  It would make life easier in a couple of situations.  I don’t
> | like the idea of using advanced record implemenations based on contended
> | language extensions (undecidable instances, etc.), thereby probably
> | loosing pattern matching, just to get rid of the need to qualify field
> | names. :-(
>
> By all means!  Make a feature request for GHC, as precisely stated as
> possible.

Done. :-) 

> (Better still, implement it.)

I might try if I find the time.  However, it would be the first time that I 
hack on GHC.  So could anyone give me some hints about at which places of the 
code I would have approximately to do what in order to implement this 
feature?

> Remember that you don't always get rid of the need to qualify field names,
> just in cases (a) and (b). 

Of course.

> S

Best wishes,
Wolfgang
(Continue reading)

GHC | 1 Jun 18:35 2007

[GHC] #1402: panic in GHC when building QuickCheck with optimization

#1402: panic in GHC when building QuickCheck with optimization
-----------------------+----------------------------------------------------
  Reporter:  guest     |          Owner:       
      Type:  bug       |         Status:  new  
  Priority:  normal    |      Milestone:       
 Component:  Compiler  |        Version:  6.7  
  Severity:  normal    |       Keywords:       
Difficulty:  Unknown   |             Os:  Linux
  Testcase:            |   Architecture:  x86  
-----------------------+----------------------------------------------------
When building QuickCheck, I get:

 {{{
 cdsmith <at> devtools:~/tmp/QuickCheck$ runhaskell Setup build
 Preprocessing library QuickCheck-2.0...
 Building QuickCheck-2.0...
 Glasgow Haskell Compiler, Version 6.7.20070529, for Haskell 98, compiled
 by GHC
 version 6.7.20070529
 Using package config file: /usr/local/lib/ghc-6.7.20070529/package.conf
 wired-in package base mapped to base-2.1
 wired-in package rts mapped to rts-1.0
 wired-in package haskell98 mapped to haskell98-1.0
 wired-in package template-haskell mapped to template-haskell-0.1
 Hsc static flags: -static
 *** Chasing dependencies:
 Chasing modules from:
 Test.QuickCheck,Test.QuickCheck.Arbitrary,Test.QuickCheck.
 Function,Test.QuickCheck.Gen,Test.QuickCheck.Monadic,Test.QuickCheck.Property,Te
 st.QuickCheck.Test,Test.QuickCheck.Exception,Test.QuickCheck.Text
(Continue reading)

GHC | 1 Jun 20:32 2007

[GHC] #1403: System.Posix.Types.UserID and others missing from Windows distribution

#1403: System.Posix.Types.UserID and others missing from Windows distribution
---------------------------------+------------------------------------------
  Reporter:  jgbailey <at> gmail.com  |          Owner:         
      Type:  bug                 |         Status:  new    
  Priority:  normal              |      Milestone:         
 Component:  Compiler            |        Version:  6.6.1  
  Severity:  normal              |       Keywords:         
Difficulty:  Unknown             |             Os:  Windows
  Testcase:                      |   Architecture:  x86    
---------------------------------+------------------------------------------
I have installed the binary package of GHC 6.6.1 prepared by Sigbjorn
 Finne. It's System.Posix.Types module does not export the UserID or
 GroupID data types. This breaks the unix-compat package (version 0.1),
 which depends on those types.

 Is this an intentional omission or is it a bug?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1403>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
GHC | 1 Jun 21:55 2007

[GHC] #1404: allow more type signatures

#1404: allow more type signatures
------------------------------+---------------------------------------------
  Reporter:  Isaac Dupree     |          Owner:         
      Type:  feature request  |         Status:  new    
  Priority:  normal           |      Milestone:         
 Component:  Compiler         |        Version:  6.6.1  
  Severity:  normal           |       Keywords:         
Difficulty:  Unknown          |             Os:  Unknown
  Testcase:                   |   Architecture:  Unknown
------------------------------+---------------------------------------------
(idea triggered by #393)

 Allow multiple copies of a type-signature in a module, such that it is an
 error if they're not equivalent, but they don't have to be syntactically
 equal (
 {{{f :: ShowS}}}
 {{{f :: String -> String}}}
 is okay).

 It would also be nice to allow any name in scope at top-level (even if
 imported) to be given a type signature.  But that raises a question: can
 these type signatures give a more specific type than that of the raw
 imported function, the way normal function type signatures can with
 regards to their implementation?

 Use cases: (1. making sure multiple implementations give the same
 interface, generally varying by #ifdef) (2. asserting that something's
 type can be specified in two different weird ways).  I don't really want
 to abandon having a type-signature right above every function definition
 even if it is a duplicate.
(Continue reading)

GHC | 1 Jun 23:04 2007

[GHC] #1405: Make ghc (stage1) be compilable by non-GHC

#1405: Make ghc (stage1) be compilable by non-GHC
---------------------------+------------------------------------------------
  Reporter:  Isaac Dupree  |          Owner:         
      Type:  task          |         Status:  new    
  Priority:  normal        |      Milestone:  _|_    
 Component:  Compiler      |        Version:  6.6.1  
  Severity:  normal        |       Keywords:         
Difficulty:  Unknown       |             Os:  Unknown
  Testcase:                |   Architecture:  Unknown
---------------------------+------------------------------------------------
This depends a bit on the existence of a good-enough non-GHC compiler.
 Possibility to do recursively dependent modules (I think) presently rules
 out everything except JHC, which is not entirely working yet.  Also
 pattern guards might need to be implemented in that compiler.  Maybe for
 testing, a ghc that doesn't define __GLASGOW_HASKELL__ (and doesn't use
 ghc-specific flags ??) could be used too.

 See http://thread.gmane.org/gmane.comp.lang.haskell.cvs.ghc/20962 ... GHC
 also uses things like IORefs, (unsafeCoerce? only in stage2 I think) that
 everyone provides, but would still be good to document.

 I'm working on this now, we'll see how far I get --Isaac

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1405>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
(Continue reading)

GHC | 2 Jun 01:57 2007

Re: [GHC] #1197: Windows: conc023.exe: getMBlocks: VirtualAlloc MEM_RESERVE 1 blocks failed: Not enough storage is available to process this command.

#1197: Windows: conc023.exe: getMBlocks: VirtualAlloc MEM_RESERVE 1 blocks failed:
Not enough storage is available to process this command.
-------------------------+--------------------------------------------------
    Reporter:  igloo     |        Owner:         
        Type:  bug       |       Status:  new    
    Priority:  normal    |    Milestone:  6.6.2  
   Component:  Compiler  |      Version:  6.6    
    Severity:  normal    |   Resolution:         
    Keywords:            |   Difficulty:  Unknown
          Os:  Windows   |     Testcase:  conc023
Architecture:  Unknown   |  
-------------------------+--------------------------------------------------
Comment (by mwassell <at> bigpond.net.au):

 From Mark (mwassell <at> bigpond.net.au)
 I am getting similar when running my program inside GHCi (6.6.1). When the
 program is compiled to a exe then it doesn't occur. Also under 6.6.0 it
 runs fine in GHCi.

 The program is HJS and occurs when parsing (parse built on parsec) a very
 simple statement *and* when the parse function is wrapped in a case
 statement. If I call the parse function directly there is no problem.

 So
        case parseProgram fn s of
              Right r -> Just r
              _ ->

 cases the problem whilst
        parseProgram fn s
(Continue reading)


Gmane