GHC | 1 Jul 02:57 2007

[GHC] #1472: undefined reference to `ZCMain_main_CAF_cc'

#1472: undefined reference to `ZCMain_main_CAF_cc'
------------------------+---------------------------------------------------
  Reporter:  greenrd    |          Owner:                
      Type:  bug        |         Status:  new           
  Priority:  normal     |      Milestone:                
 Component:  Profiling  |        Version:  6.7           
  Severity:  normal     |       Keywords:                
Difficulty:  Unknown    |             Os:  Linux         
  Testcase:             |   Architecture:  x86_64 (amd64)
------------------------+---------------------------------------------------
When building my project with profiling, and using a makefile, it works
 OK, until I try to use the -caf-all option:

 {{{
 find build -name '*.o_p'|xargs ghc-darcs -o hcoq -package mtl -package
 filepath -package template-haskell -package frisby -package wl-pprint
 -odirbuild -hidirbuild -fforce-recomp -prof
 build/Main.o_p: In function `ZCMain_main_CAF_cc_ccs':
 : undefined reference to `ZCMain_main_CAF_cc'
 collect2: ld returned 1 exit status
 make: *** [hcoq] Error 123
 }}}

 This happens whether or not I supply -caf-all to the final ghc-darcs
 invocation.

 This is with ghc 6.7.20070618.

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

GHC | 1 Jul 03:40 2007

Re: [GHC] #1268: GHCi reads from stdin do not handle ^D

#1268: GHCi reads from stdin do not handle ^D
-------------------------------------------------+--------------------------
    Reporter:  Stefan O'Rear <stefanor <at> cox.net>  |        Owner:         
        Type:  bug                               |       Status:  new    
    Priority:  normal                            |    Milestone:  6.8    
   Component:  GHCi                              |      Version:  6.7    
    Severity:  normal                            |   Resolution:         
    Keywords:                                    |   Difficulty:  Unknown
          Os:  Linux                             |     Testcase:         
Architecture:  x86                               |  
-------------------------------------------------+--------------------------
Changes (by greenrd):

  * cc:  => greenrd <at> greenrd.org

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1268>
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 Jul 13:12 2007

[GHC] #1473: isSpace is too slow

#1473: isSpace is too slow
-----------------------------+----------------------------------------------
  Reporter:  igloo           |          Owner:         
      Type:  bug             |         Status:  new    
  Priority:  normal          |      Milestone:  _|_    
 Component:  libraries/base  |        Version:  6.6.1  
  Severity:  normal          |       Keywords:         
Difficulty:  Unknown         |             Os:  Unknown
  Testcase:                  |   Architecture:  Unknown
-----------------------------+----------------------------------------------
In the thread starting http://www.haskell.org/pipermail/glasgow-haskell-

 users/2007-May/012608.html
 Neil Mitchell compares the speed is isSpace to C's functions:
 {{{
 C's isspace: 0.375
 C's iswspace: 0.400
 Char.isSpace: 0.672
 }}}
 The thread contains some discussions of possible solutions.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1473>
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
(Continue reading)

GHC | 1 Jul 13:25 2007

[GHC] #1474: With -fglasgow-exts add option to show simpler types.

#1474: With -fglasgow-exts add option to show simpler types.
--------------------------------+-------------------------------------------
  Reporter:  iampure <at> gmail.com  |          Owner:         
      Type:  feature request    |         Status:  new    
  Priority:  normal             |      Milestone:         
 Component:  GHCi               |        Version:  6.6.1  
  Severity:  minor              |       Keywords:         
Difficulty:  Unknown            |             Os:  Unknown
  Testcase:                     |   Architecture:  Unknown
--------------------------------+-------------------------------------------
Instead of showing forall a b c d e f (t1 :: * -> * -> *) (t2 :: * -> *).
 <context> => <some type>, show <context> => <some type> with this option
 enabled when doing :t. The kinds are of no interest to me most of the
 time.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1474>
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 Jul 13:43 2007

[GHC] #1475: Adding imports and exports with Template Haskell

#1475: Adding imports and exports with Template Haskell
-------------------------------+--------------------------------------------
  Reporter:  igloo             |          Owner:         
      Type:  feature request   |         Status:  new    
  Priority:  normal            |      Milestone:  6.8    
 Component:  Template Haskell  |        Version:  6.6.1  
  Severity:  normal            |       Keywords:         
Difficulty:  Unknown           |             Os:  Unknown
  Testcase:                    |   Architecture:  Unknown
-------------------------------+--------------------------------------------
(wished for by Adrian Hey in http://www.haskell.org/pipermail/template-

 haskell/2007-June/000598.html)

 It would be useful to be able to add module exports with TH, although I'm
 not sure exactly how it would be done. Perhaps something like
 {{{
 $( do n <- newName "foo"
       let d = funD n ...
       addExport (varE n)
       return [d]
 }}}
 but at the point we call `addExport` the typechecker doesn't know that
 there will be a declaration for the name.

 Less useful, as TH names include the package and module of the name's
 definition, is the ability to add module imports. However, this can still
 be used to get a kind of dynamic binding effect, either with `mkName`'s
 names or plain Haskell code, e.g.:
 {{{
 $( addImport (if ... then '''Data.ByteString else '''Data.ByteString.Lazy)
(Continue reading)

GHC | 1 Jul 13:53 2007

[GHC] #1476: Template Haskell: splicing types and patterns

#1476: Template Haskell: splicing types and patterns
-------------------------------+--------------------------------------------
  Reporter:  igloo             |          Owner:         
      Type:  bug               |         Status:  new    
  Priority:  normal            |      Milestone:  6.10   
 Component:  Template Haskell  |        Version:  6.6.1  
  Severity:  normal            |       Keywords:         
Difficulty:  Unknown           |             Os:  Unknown
  Testcase:                    |   Architecture:  Unknown
-------------------------------+--------------------------------------------
In http://www.haskell.org/pipermail/template-haskell/2003-

 February/000021.html Simon Peyton Jones writes:
 {{{
 We claim to allow you to write splices in (a) types and (b) patterns.
 I'm very dubious about (b). Consider]
     x = 4

     y :: Patt
     y = [p| ... |]

     f $y = x

 Question: where is x bound?  It looks as though x can be bound by the
 spliced-in pattern or by the top-level binding.  You can't tell without
 knowing what $y expands to.  We argue in our paper against non-top-level
 declaration splices because that would lead to ambiguity of exactly this
 sort.

 It turns out that it's very inconvenient to implement pattern splices in
 GHC, for exactly this reason.  We can't figure out the binding structure
(Continue reading)

GHC | 1 Jul 15:09 2007

[GHC] #1477: ghci shouldn't link entire package

#1477: ghci shouldn't link entire package
------------------------------+---------------------------------------------
  Reporter:  igloo            |          Owner:         
      Type:  feature request  |         Status:  new    
  Priority:  normal           |      Milestone:  6.8    
 Component:  GHCi             |        Version:  6.6.1  
  Severity:  normal           |       Keywords:         
Difficulty:  Unknown          |             Os:  Unknown
  Testcase:                   |   Architecture:  Unknown
------------------------------+---------------------------------------------
In this thread: http://www.haskell.org/pipermail/glasgow-haskell-users

 /2007-January/011839.html
 Alistair Bayley requests that ghci only link against parts of a package
 that are actually needed (like ld does) as:
 {{{
 With Takusen, all modules, including the DBMS-specific modules, are
 compiled into a single library. At present we have 3 DBMS's: Sqlite,
 Oracle, and PostgreSQL. For example, suppose you had just the Oracle
 DBMS client libraries installed, and you write a program which only uses
 the Oracle modules from Takusen. When you link, the gnu ld program
 attempts to resolve the symbols in only the modules that you've used.
 You don't need to have PostgreSQL or Sqlite installed, and the linker
 ignores these modules from the package archive. This is quite nice,
 because we can distribute the entire library as a single package, and it
 will work even if the user does not have all of the DBMS client
 libraries installed.

 In contrast, when ghci (or runhaskell) attempts to link it tries to
 resolve all of the symbols in the PostgreSQL and Sqlite modules, and
 fails because you don't have them installed.
(Continue reading)

GHC | 1 Jul 15:52 2007

[GHC] #1478: Flag to get information about the compiler and RTS

#1478: Flag to get information about the compiler and RTS
------------------------------+---------------------------------------------
  Reporter:  igloo            |          Owner:         
      Type:  feature request  |         Status:  new    
  Priority:  high             |      Milestone:  6.8    
 Component:  Compiler         |        Version:  6.6.1  
  Severity:  normal           |       Keywords:         
Difficulty:  Unknown          |             Os:  Unknown
  Testcase:                   |   Architecture:  Unknown
------------------------------+---------------------------------------------
There should be a flag `+RTS -foo` that prints info including:
  * The version of GHC used to compile the program
  * The sort of RTS linked against

 There should also be a flag that can be given to the compiler that prints
 info including:
  * Whether it has a NCG
  * Whether or not it is registerised
  * Whether it supports ghci/ghc -e
  * What RTSs it has
  * Whether it supports SMP

 Ideally this would all be easily machine-parseable.

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

GHC | 1 Jul 17:42 2007

http://darcs.haskell.org/hsc2hs

#1479: Merge GHC's hsc2hs with http://darcs.haskell.org/hsc2hs

----------------------+-----------------------------------------------------
  Reporter:  igloo    |          Owner:         
      Type:  task     |         Status:  new    
  Priority:  normal   |      Milestone:  6.8    
 Component:  hsc2hs   |        Version:  6.6.1  
  Severity:  normal   |       Keywords:         
Difficulty:  Unknown  |             Os:  Unknown
  Testcase:           |   Architecture:  Unknown
----------------------+-----------------------------------------------------
GHC's hsc2hs should be merged with http://darcs.haskell.org/hsc2hs, and
 that repo should then be used when building GHC.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1479>
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 Jul 20:43 2007

[GHC] #1480: Template Haskell should allow reification of modules

#1480: Template Haskell should allow reification of modules
-------------------------------+--------------------------------------------
  Reporter:  igloo             |          Owner:         
      Type:  feature request   |         Status:  new    
  Priority:  normal            |      Milestone:  6.8    
 Component:  Template Haskell  |        Version:  6.6.1  
  Severity:  normal            |       Keywords:         
Difficulty:  Unknown           |             Os:  Unknown
  Testcase:                    |   Architecture:  Unknown
-------------------------------+--------------------------------------------
It should be possible to reify a module from a splice. If the module is
 thisModule then it would only tell you about things above the current
 splice.

 This comes up quite often; for example:

 In http://www.haskell.org/pipermail/haskell-cafe/2007-June/027205.html

 Brent Yorgey wants to get a list of top-level functions names prop_* in
 order to build a runQuickCheckProps function.

 In http://www.haskell.org/pipermail/haskell-cafe/2007-June/026493.html

 Neil Mitchell wants to get all the data/newtype declarations in a module
 in order to declare Typeable and Data instances for them.

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


Gmane