Re: [GHC] #989: Windows native port

2006-11-10 Thread GHC
#989: Windows native port
--+-
 Reporter:  simonmar  |  Owner:
 Type:  task  | Status:  new   
 Priority:  normal|  Milestone:
Component:  Compiler  |Version:  6.7   
 Severity:  normal| Resolution:
 Keywords:| Difficulty:  Difficult (1 week)
 Testcase:  N/A   |   Architecture:  x86   
   Os:  Windows   |  
--+-
Comment (by simonpj):

 Notes from Peter Tanski

 The only caveat would be that the free version of MASM (an
 add-on to Visual C++ Express) is licensed for non-commercial purposes
 only.  Commercial Windows developers would have to purchase a full
 version of VC++.  The most universal solution would be to restrict
 the syntax from the pretty-printer to use assembler directives and
 macros common to both MASM and IAS (Intel ASsembler), with some
 special attention to linker differences between the two.

 Here are a few notes on Task #989:

  * Task point 1: pretty printing MS/Intel asm syntax

  Most of this seems to be concentrated in compiler/nativeGen/
  PprMach.hs, with a macro added to NCG.h.

  Depending on how much you want to interoperate directly with .NET and
  other non-C languages, the pretty-printer for assembly output may be
  only part of the work: we might add special COFF sections to compiler/
  nativeGen/AsmCodeGen.lhs.

  * Task point 2: compiling via Microsoft's CL compiler

  Fun.  Once we have gotten over point 4 (modifications to driver,
  build system, etc.).

  * Task point 3: drop dependencies on mingw32 functionality in the
 libraries

  Is there a Windows-version of readline, or a Windows-native version
  of readline available?  Even if I don't finish the replacement-GMP
  library before this, if I recall correctly, GMP has a Windows-native
  version (as a DLL, no less).  Are there any other library
  dependencies?  Windows-native versions of Perl are available.

  * Task point 4: modifications to driver, build system, etc.

  driver: DOS batch file or Perl (GHC users will need Perl installed to
  run the mangler anyway); might also be a very small C program
  (especially if you want to have a splash screen when GHC starts up).

  build system: small but pervasive modifications for compiler
  dependencies, etc.; as a general cleanup matter it might be nice to
  organise these sorts of dependencies to add other compilers later.
  The one problem I think people will run into is setting up the paths
  in MSYS to use the Windows tools--not a GHC-support issue, really,
  but many questions will be raised about it so we might head them off
  with lots of build-documentation.

 There are several related points to this project:

 (1) for general Windows interoperability, GHC will need to produce
 DLLs, at least: .NET or other Microsoft languages, such as VB, cannot
 include foreign code from static libraries.

 (2) once GHC may produce more than one type of assembler output,
 would it be too much trouble to give it a cross-compiler option, say
 -arch i386 (compiler/nativeGen/PprMach.hs seems to use
 IF_ARCH_... statements) or the GCC option, -b i386v?  A cross-
 compile option would probably require changing the compiler/utils/
 Outputable.CodeStyle data constructor AsmStyle to contain several
 different sub-styles (Intel, ATnT) and clutter up the code in
 PprMach.hs, at least for i386_TARGET_ARCH.  Of course floatToBytes
 and doubleToBytes (converting endianness to host byte order) would
 also have to change.  (Note: the reference in PprMach.hs:2418 to
 PprAbs seems to refer to an old module, PprAbsC, which is no longer
 used, correct?)

 The easy, host-target-compiler-only solution might be to create a new
 macro, IF_OS_windows(x,y), in NCG.h and a new Ppr section for the
 MASM/Intel syntax in PprMach.hs.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/989
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] #994: add 'unsafeCoerce' to a standard location in the hierarchical libraries

2006-11-10 Thread GHC
#994: add 'unsafeCoerce' to a standard location in the hierarchical libraries
--+-
Reporter:  [EMAIL PROTECTED]  |   Owner: 
Type:  feature request|  Status:  new
Priority:  normal |   Milestone: 
   Component:  libraries/base | Version: 
Severity:  normal |Keywords: 
  Difficulty:  Easy (1 hr)|Testcase: 
Architecture:  Unknown|  Os:  Unknown
--+-
Currently, all implementations provide either the 'unsafeCoerce' or
 'unsafeCoerce#' functions, but they live in implementation-specific
 locations.

 This proposal is to adopt the Haskell'98-compatible name 'unsafeCoerce',
 and to add it to the standard base library package.
 Suggested location:  Data.Function.Unsafe?

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/994
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] #994: add 'unsafeCoerce' to a standard location in the hierarchical libraries

2006-11-10 Thread GHC
#994: add 'unsafeCoerce' to a standard location in the hierarchical libraries
---+
 Reporter:  [EMAIL PROTECTED]  |  Owner: 
 Type:  proposal   | Status:  new
 Priority:  normal |  Milestone: 
Component:  libraries/base |Version: 
 Severity:  normal | Resolution: 
 Keywords: | Difficulty:  Easy (1 hr)
 Testcase: |   Architecture:  Unknown
   Os:  Unknown|  
---+
Changes (by ross):

  * type:  feature request = proposal

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/994
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] #995: Needless call to fromInteger for literals

2006-11-10 Thread GHC
#995: Needless call to fromInteger for literals
-+--
Reporter:  wolfgang  |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Milestone:  
   Component:  Compiler  | Version:  6.7 
Severity:  minor |Keywords:  
  Difficulty:  Unknown   |Testcase:  
Architecture:  Multiple  |  Os:  Multiple
-+--
For the code below, ghc 6.7 puts the literal 65 in a static closure (S#)
 and calls fromInteger on it.
 {{{
 import Foreign.C ( CChar )

 foreign import ccall putchar :: CChar - IO ()

 main = putchar 65
 }}}

 GHC 6.7 generates the following code; note the static closure Main.lvl and
 the call to fromInteger:
 {{{
  STG syntax: 
 Main.lvl = NO_CCS GHC.Num.S#! [65];
 SRT(Main.lvl): []
 Main.main =
 \u []
 case GHC.Int.fromInteger Main.lvl of ds_sSd {
   GHC.Int.I8# ds1_sS2 -
   let {
 sat_sSf =
 \r [ds2_sS3]
 case __ccall_GC putchar [ds1_sS2 ds2_sS3] of
 wild_sSe {
   (##) ds3_sS7 - (#,#) [ds3_sS7 GHC.Base.()];
 };
   } in  sat_sSf;
 };
 SRT(Main.main): []
 :Main.main =
 \r srt:(0,*bitmap*) [eta_sSc] GHC.TopHandler.runMainIO Main.main
 eta_sSc;
 SRT(:Main.main): [GHC.TopHandler.runMainIO, Main.main]
 }}}

 GHC 6.6 just passes the 65 to putchar as an unboxed constant.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/995
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] #979: Adding on

2006-11-10 Thread GHC
#979: Adding on
+---
 Reporter:  nad |  Owner: 
 Type:  proposal| Status:  closed 
 Priority:  normal  |  Milestone: 
Component:  libraries/base  |Version:  6.6
 Severity:  normal  | Resolution:  fixed  
 Keywords:  | Difficulty:  Unknown
 Testcase:  |   Architecture:  Unknown
   Os:  Unknown |  
+---
Changes (by nad):

  * resolution:  = fixed
  * status:  new = closed

Comment:

 Proposal discussion summary:

  * Consensus was reached that a module containing {{{on}}} plus some
 functions from the prelude should be added.

  * The module name {{{Control.Function}}} was not well received. A bunch
 of other names were suggested, and almost everyone accepted
 {{{Data.Function}}}.

  * It was discussed whether {{{comparing}}} (i.e. {{{on compare}}}) and/or
 {{{equating}}} ({{{on (==)}}}) should also be present in the libraries.
 Consensus was reached that either both or none of them should be there,
 and most people wanted to have them in the libraries. The function
 {{{comparing}}} is already in the libraries, but not {{{equating}}}.
 Complaints were raised about the name {{{equating}}}, though, and no
 consensus was reached about an alternative name. Hence I leave the
 {{{comparing}}}/{{{equating}}} discussion open for another proposal.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/979
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] #349: Strange GADT behaviour

2006-11-10 Thread GHC
#349: Strange GADT behaviour
-+--
 Reporter:  josefs   |  Owner:  simonpj 
 Type:  bug  | Status:  assigned
 Priority:  normal   |  Milestone:  6.8 
Component:  Compiler (Type checker)  |Version:  6.4 
 Severity:  normal   | Resolution:  None
 Keywords:   | Difficulty:  Unknown 
 Testcase:  gadt/josef   |   Architecture:  Unknown 
   Os:  Unknown  |  
-+--
Changes (by simonpj):

  * testcase:  = gadt/josef

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/349
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] #994: add 'unsafeCoerce' to a standard location in the hierarchical libraries

2006-11-10 Thread GHC
#994: add 'unsafeCoerce' to a standard location in the hierarchical libraries
---+
 Reporter:  [EMAIL PROTECTED]  |  Owner: 
 Type:  proposal   | Status:  new
 Priority:  normal |  Milestone: 
Component:  libraries/base |Version: 
 Severity:  normal | Resolution: 
 Keywords: | Difficulty:  Easy (1 hr)
 Testcase: |   Architecture:  Unknown
   Os:  Unknown|  
---+
Changes (by ross):

  * cc:  [EMAIL PROTECTED] = libraries

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/994
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] #993: threaded RTS under pc-solaris does not work

2006-11-10 Thread GHC
#993: threaded RTS under pc-solaris does not work
+---
 Reporter:  [EMAIL PROTECTED]   |  Owner: 
 Type:  bug | Status:  new
 Priority:  normal  |  Milestone:  6.6.1  
Component:  Runtime System  |Version:  6.6
 Severity:  normal  | Resolution: 
 Keywords:  | Difficulty:  Unknown
 Testcase:  |   Architecture:  x86
   Os:  Solaris |  
+---
Comment (by [EMAIL PROTECTED]):

 I've linked the stage2 compiler of the HEAD with:
 {{{ -threaded -debug -optl-L/usr/local/lib -optl-lbfd -optl-liberty -optl-
 lintl }}}

 and gdb showed the following location:

 {{{
 [New LWP 1]
 [New LWP 2]
 ghc-6.7: missing -Bdir option
 [New LWP 3]

 Program received signal SIGILL, Illegal instruction.
 0x08ca8dc7 in scheduleDoGC (cap=0x0, task=0x8e275b8, force_major=rtsFalse)
 at ../includes/SMP.h:105
 105 __asm__ __volatile__ (
 }}}

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/993
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] #349: Strange GADT behaviour

2006-11-10 Thread GHC
#349: Strange GADT behaviour
-+--
 Reporter:  josefs   |  Owner:  simonpj
 Type:  bug  | Status:  closed 
 Priority:  normal   |  Milestone:  6.8
Component:  Compiler (Type checker)  |Version:  6.4
 Severity:  normal   | Resolution:  fixed  
 Keywords:   | Difficulty:  Unknown
 Testcase:  gadt/josef   |   Architecture:  Unknown
   Os:  Unknown  |  
-+--
Changes (by simonpj):

  * resolution:  None = fixed
  * status:  assigned = closed

Comment:

 This bug is fixed, now that I have added implication constraints to GHC.
 At least, the test program works fine in the HEAD.

 Simon

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/349
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] #345: GADT - fundep interaction

2006-11-10 Thread GHC
#345: GADT - fundep interaction
-+--
 Reporter:  bring|  Owner:  simonpj 
 Type:  bug  | Status:  assigned
 Priority:  normal   |  Milestone:  6.8 
Component:  Compiler (Type checker)  |Version:  6.4 
 Severity:  normal   | Resolution:  None
 Keywords:   | Difficulty:  Unknown 
 Testcase:  gadt-fd  |   Architecture:  Unknown 
   Os:  Unknown  |  
-+--
Comment (by simonpj):

 This one still doesn't work, even with the new implication-constraint
 machinery.  It's a good example of the need for full-on equality
 constraints.

 Simon

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/345
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] #289: class context restrictions in GADT types not assumed

2006-11-10 Thread GHC
#289: class context restrictions in GADT types not assumed
-+--
 Reporter:  ashley-y |  Owner:  simonpj
 Type:  bug  | Status:  closed 
 Priority:  normal   |  Milestone:  6.8
Component:  Compiler (Type checker)  |Version:  6.4
 Severity:  normal   | Resolution:  fixed  
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  Unknown
   Os:  Unknown  |  
-+--
Changes (by simonpj):

  * resolution:  None = fixed
  * testcase:  =
  * status:  assigned = closed

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/289
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] #993: threaded RTS under pc-solaris does not work

2006-11-10 Thread GHC
#993: threaded RTS under pc-solaris does not work
+---
 Reporter:  [EMAIL PROTECTED]   |  Owner: 
 Type:  bug | Status:  new
 Priority:  normal  |  Milestone:  6.6.1  
Component:  Runtime System  |Version:  6.6
 Severity:  normal  | Resolution: 
 Keywords:  | Difficulty:  Unknown
 Testcase:  |   Architecture:  x86
   Os:  Solaris |  
+---
Comment (by [EMAIL PROTECTED]):

 commenting out (actually renaming) {{{i386_HOST_ARCH}}} in
 {{{includes/SMP.h}}} fixes the illegal instruction problem! The first test
 cases of the test-suite look good.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/993
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] #996: Add ranged sets

2006-11-10 Thread GHC
#996: Add ranged sets
---+
Reporter:  pauljohnson |   Owner: 
Type:  proposal|  Status:  new
Priority:  normal  |   Milestone: 
   Component:  libraries/base  | Version:  6.6
Severity:  normal  |Keywords: 
  Difficulty:  Unknown |Testcase: 
Architecture:  Unknown |  Os:  Unknown
---+
Ranged sets represent sets of ordered values as lists of ranges.  Each
 range has a lower and
 upper boundary, and for any value and boundary the value is either above
 or below the boundary:
 no value can ever sit on a boundary.  There are also boundaries for +/-
 infinity (BoundaryBelowAll and BoundaryAboveAll).

 The upshot is that you can represent a set of reals such as

[ 2.0  x = 3.4, 6.7  x]

 or a couple of encyclopedia volumes as:

[a = x  blob, goo = x  hun]


 The usual set operators are provided.  The library also does the Right
 Thing with adjacent values:

[2  x = 3] Union [4 = x  5]  == [2  x  5]

[2.0  x = 3.0] Union [4.0 = x  5.0]  == [2.0  x = 3.0, 4.0 = x 
 5.0]

 I've needed something like this more than once over the years, in various
 languages.  Haskell
 is the first one that can actually do the Right Thing efficiently for a
 polymorphic type.

 The source contains Haddock comments and a comprehensive set of QuickCheck
 properties.  I've integrated these into the documentation.  So far I've
 tested this on GHC 6.4.1, although this patch is against the HEAD of the
 current libraries.

 If this patch is accepted I'll also add patches for ranged sets of times
 (e.g. the set of all times within the first Tuesday of each month), and to
 filter finite maps against ranged sets.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/996
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