Re: [GHC] #4151: Validate fails with GhcRtsWithPapi = YES

[GHC]

#4151: Validate fails with GhcRtsWithPapi  = YES
-+--
Reporter:  dmp   |   Owner:  dmp 
Type:  bug   |  Status:  merge   
Priority:  normal|   Component:  Build System
 Version:  6.13  |Keywords:  papi
  Os:  Unknown/Multiple  |Testcase:  
Architecture:  Unknown/Multiple  | Failure:  Other   
-+--

Comment(by dmp):

 I accidentally set the status to 'merge' when I think it should be
 'review'. I can not change the status to review now, so I am just putting
 a comment 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] #4152: Add support for collecting native events with PAPI

[GHC]

#4152: Add support for collecting native events with PAPI
-+--
Reporter:  dmp   |   Owner:  dmp   
Type:  feature request   |  Status:  patch 
Priority:  normal|   Component:  Runtime System
 Version:  6.13  |Keywords:  papi  
  Os:  Unknown/Multiple  |Testcase:
Architecture:  Unknown/Multiple  | Failure:  None/Unknown  
-+--

Comment(by dmp):

 Replying to [comment:1 dmp]:
 Messed up the formatting. Trying again.

 Attaching a patch that extends PAPI support to allow users to specify
 native events. The changes included are:
   1) New option (#) for the RTS PAPI flag for native events. For example,
 to collect the native event 0x4000, use {{{./a.out +RTS -a#0x4000
 -sstderr}}}

   2) Update the PAPI_FLAGS struct to store whether the user specified
 event is a papi preset or a native event

   3) Update init_countable_events function to add the native events after
 parsing the event code and decoding the name using PAPI_event_code_to_name

 The patch validates against HEAD. The validation script does not by
 default enable PAPI support so the changes do not really get tested by a
 validate. It also validates after enabling PAPI support, but that requires
 another (unrelated) patch to get validate to work with PAPI enabled (see
 #4151).

-- 
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] #4152: Add support for collecting native events with PAPI

[GHC]

#4152: Add support for collecting native events with PAPI
-+--
Reporter:  dmp   |   Owner:  dmp   
Type:  feature request   |  Status:  patch 
Priority:  normal|   Component:  Runtime System
 Version:  6.13  |Keywords:  papi  
  Os:  Unknown/Multiple  |Testcase:
Architecture:  Unknown/Multiple  | Failure:  None/Unknown  
-+--
Changes (by dmp):

  * status:  new => patch


Comment:

 Attaching a patch that extends PAPI support to allow users to specify
 native events.
  The changes included are:

   1) New option (#) for the RTS PAPI flag for native events. For example,
 to
  collect the native event 0x4000, use {{{./a.out +RTS
 -a#0x4000 -sstderr}}}

   2) Update the PAPI_FLAGS struct to store whether the user specified
 event is a
  papi preset or a native event

   3) Update init_countable_events function to add the native events after
 parsing
  the event code and decoding the name using PAPI_event_code_to_name

 The patch validates against HEAD. The validation script does not by
 default enable PAPI support so the changes do not really get tested by a
 validate. It also validates after enabling PAPI support, but that requires
 another (unrelated) patch to get validate to work with PAPI enabled (see
 #4151).

-- 
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] #4152: Add support for collecting native events with PAPI

[GHC]

#4152: Add support for collecting native events with PAPI
-+--
Reporter:  dmp   |   Owner:  dmp   
Type:  feature request   |  Status:  new   
Priority:  normal|   Component:  Runtime System
 Version:  6.13  |Keywords:  papi  
  Os:  Unknown/Multiple  |Testcase:
Architecture:  Unknown/Multiple  | Failure:  None/Unknown  
-+--
 The PAPI support in the RTS allows users to collect a group of preset PAPI
 events (e.g. {{{PAP_TOT_CYC}}}). However, PAPI can also collect data for
 native events exposed by the hardware beyond the PAPI present events. The
 native events supported on your hardware can found by using the
 {{{papi_native_avail}}} tool. It would be great if the RTS allows users to
 collect native events along with the preset events.

-- 
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] #4151: Validate fails with GhcRtsWithPapi = YES

[GHC]

#4151: Validate fails with GhcRtsWithPapi  = YES
-+--
Reporter:  dmp   |   Owner:  dmp 
Type:  bug   |  Status:  merge   
Priority:  normal|   Component:  Build System
 Version:  6.13  |Keywords:  papi
  Os:  Unknown/Multiple  |Testcase:  
Architecture:  Unknown/Multiple  | Failure:  Other   
-+--
Changes (by dmp):

  * status:  new => merge


Comment:

 Attached a patch that fixes the problem.

 This patch adds a #undef for each symbol before defining it to what is
 needed for GHC. The patch validates with and without PAPI support enabled
 in the runtime.

-- 
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] #4151: Validate fails with GhcRtsWithPapi = YES

[GHC]

#4151: Validate fails with GhcRtsWithPapi  = YES
-+--
Reporter:  dmp   |   Owner:  dmp 
Type:  bug   |  Status:  new 
Priority:  normal|   Component:  Build System
 Version:  6.13  |Keywords:  papi
  Os:  Unknown/Multiple  |Testcase:  
Architecture:  Unknown/Multiple  | Failure:  Other   
-+--
 Validation fails when validating with PAPI support (i.e. GhcRtsWithPapi  =
 YES
   in validate.mk).  The problem is that the posix symbols are defined by a
 header
   included from papi.h. Compilation then fails because these symbols are
   redefined in PosixSource.h. This patch adds a #undef for each symbol
 before
   defining it to what is needed for GHC. For some reason this is only
 triggered
   by a validate run, not a normal compilation.

-- 
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] #3389: CPP strips out C-style comments

[GHC]

#3389: CPP strips out C-style comments
--+-
  Reporter:  nominolo |  Owner:  igloo   
  Type:  feature request  | Status:  new 
  Priority:  normal   |  Milestone:  6.14.1  
 Component:  Driver   |Version:  6.10.2  
Resolution:   |   Keywords:  
Difficulty:  Unknown  | Os:  Unknown/Multiple
  Testcase:   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown |  
--+-

Comment(by duncan):

 Replying to [comment:6 igloo]:

 > They could be switched to use Haskell comments, but I don't know if
 being able to include them in C files is also important; Duncan?

 The `cabal_macros.h` file can be included by C code and it'd be useful to
 do so. I guess if we ever switch to cpphs we would have the same problem.

 Note that the `cabal_macros.h` is not the only problem. Other packages
 #include header files that contain no C code but only macros and comments.

 Hmm.

-- 
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] #3449: Unavoidable "unused bindings" warnings in boot files

[GHC]

#3449: Unavoidable "unused bindings" warnings in boot files
-+--
Reporter:  heatsink  |Owner:  igloo   
Type:  bug   |   Status:  new 
Priority:  normal|Milestone:  6.14.1  
   Component:  Compiler  |  Version:  6.10.4  
Keywords:|   Difficulty:  Unknown 
  Os:  Unknown/Multiple  | Testcase:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--
Changes (by igloo):

  * owner:  => igloo
  * failure:  => None/Unknown


-- 
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] #4150: CPP+QuasiQuotes confuses compilation errors' line numbers

[GHC]

#4150: CPP+QuasiQuotes confuses compilation errors' line numbers
+---
Reporter:  yairchu  |   Owner:   
Type:  bug  |  Status:  new  
Priority:  normal   |   Component:  Compiler 
 Version:  6.12.1   |Keywords:   
  Os:  MacOS X  |Testcase:   
Architecture:  x86  | Failure:  Incorrect warning at compile-time
+---
 doing an #include of multi-line files inside QuasiQuotes makes GHC report
 wrong line numbers on errors occurring in normal code which is after the
 said #include.

 {{{
 myHtmlsTemplate = [$multiLineStr|
 #include "template.html"
 |]

 somethingElse :: NoSuchType
 somethingElse = 7
 }}}

 The example code will fail compiling with: {{{Not in scope: type
 constructor or class `NoSuchType'}}}, but will not report the correct line
 number of the error.

-- 
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] #2362: allow full import syntax in GHCi

[GHC]

#2362: allow full import syntax in GHCi
-+--
Reporter:  Isaac Dupree  |Owner:  igloo   
Type:  feature request   |   Status:  new 
Priority:  high  |Milestone:  6.14.1  
   Component:  Compiler  |  Version:  6.8.2   
Keywords:  ghci, import  |   Difficulty:  Unknown 
  Os:  Unknown/Multiple  | Testcase:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by SamAnklesaria):

 Thanks for the comments. `parseName` relies internally on a function from
 HscMain that does just that: name parsing.  I don't think it can handle
 import declarations, which is why I wrote `hscImport`.  As I removed the
 "import" from the string the user entered (saving all the import parts in
 a `remembered_ctx` seems redundant), it needs to be prepended or the
 parser won't understand it. Importing twice with different import lists is
 handled like in source files. Any ":m" commands will overwrite import
 declarations for the same module. The problem with representing an import
 in a `CtxCmd` is that it has a completely different syntax, so storing it
 in the same structure seems awkward.  A new patch should be up soon.

-- 
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] #2362: allow full import syntax in GHCi

[GHC]

#2362: allow full import syntax in GHCi
-+--
Reporter:  Isaac Dupree  |Owner:  igloo   
Type:  feature request   |   Status:  new 
Priority:  high  |Milestone:  6.14.1  
   Component:  Compiler  |  Version:  6.8.2   
Keywords:  ghci, import  |   Difficulty:  Unknown 
  Os:  Unknown/Multiple  | Testcase:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by simonmar):

 Oh, one more thing: we should have test cases for the new features,
 including the tricky cases like multiple imports and combinations of
 imports and `:m`, and re-loading of source files to trigger the replay
 functionality.

-- 
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] #2839: Integer not documented in latest docs

[GHC]

#2839: Integer not documented in latest docs
-+--
  Reporter:  TristanAllwood  |  Owner:  
  Type:  bug | Status:  closed  
  Priority:  low |  Milestone:  6.14.1  
 Component:  Documentation   |Version:  6.10.1  
Resolution:  fixed   |   Keywords:  
Difficulty:  Unknown | Os:  Unknown/Multiple
  Testcase:  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown|  
-+--
Changes (by igloo):

  * status:  new => closed
  * failure:  => None/Unknown
  * resolution:  => fixed


Comment:

 The haddock bug is now fixed, and I've re-hidden `GHC.Integer` from
 haddock.

-- 
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] #2362: allow full import syntax in GHCi

[GHC]

#2362: allow full import syntax in GHCi
-+--
Reporter:  Isaac Dupree  |Owner:  igloo   
Type:  feature request   |   Status:  new 
Priority:  high  |Milestone:  6.14.1  
   Component:  Compiler  |  Version:  6.8.2   
Keywords:  ghci, import  |   Difficulty:  Unknown 
  Os:  Unknown/Multiple  | Testcase:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by simonmar):

 Many thanks for the patch!  I've done a patch review, there are a few
 things that need fixing, but nothing fatal.

 {{{
  -> throwOneError (mkPlainErrMsg noSrcSpan (ptext (sLit "No module
 speficied for import")))
 }}}

 typo in the error message, and perhaps the message should say something
 like "parse error in import declaration"?

 {{{
 +   -- 'ic_toplev_scope', 'ic_exports'
 and 'ic_imports'
 }}}

 did that sneak in by mistake?  I don't see `ic_imports` anywhere

 {{{
 +getImportDecl :: GhcMonad m => String ->  m (ImportDecl RdrName)
 +getImportDecl expr = withSession $ \hsc_env -> hscImport hsc_env
 ("import"++expr)
 }}}

 Did you really want `"import"++expr`, with no space between?  I'd drop the
 `"import"++` bit entirely, I think, and call the function
 `parseImportDecl` (we already have `parseName`, which is similar).

 {{{
 - | ["import", mod] <- words stmt= keepGoing' setContext ('+':mod)
 + | ('i':'m':'p':'o':'r':'t':mod) <- stmt= keepGoing' (importContext
 True) mod
 }}}

 check for a space after "import", otherwise you'll catch "imported" etc.

 What happens if the user imports the same module twice, with different
 import lists?  They should accumulate, as in a source file, right?  Does
 it work that way?  What happens if you import a module multiple times with
 "import", and then say ":m -M"?

 In `setContext` and `remembered_ctx` it feels to me like an import decl
 should be a different kind of `CtxtCmd`, rather than dealing with them
 separately at a higher level.  I'm not sure about the interactions of
 having multiple `:m` and `import` commands here, it would be simpler if
 they were all dealt with together in `playCtxtCmd`.  I realise this means
 changing the types a bit more radically, though.

-- 
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] #1338: base package breakup

[GHC]

#1338: base package breakup
-+--
  Reporter:  simonmar|  Owner:  
  Type:  task| Status:  closed  
  Priority:  low |  Milestone:  6.14.1  
 Component:  libraries/base  |Version:  6.6.1   
Resolution:  fixed   |   Keywords:  
Difficulty:  Unknown | Os:  Unknown/Multiple
  Testcase:  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown|  
-+--
Changes (by igloo):

  * status:  new => closed
  * failure:  => None/Unknown
  * resolution:  => fixed


Comment:

 I don't think any more will happen on this without someone making
 [http://www.haskell.org/haskellwiki/Library_submissions library
 proposals].

-- 
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] #3445: ":show modules" Panic

[GHC]

#3445: ":show modules" Panic
---+
  Reporter:  sfjohnso  |  Owner:  
  Type:  bug   | Status:  closed  
  Priority:  normal|  Milestone:  6.14.1  
 Component:  GHCi  |Version:  6.6 
Resolution:  invalid   |   Keywords:  impossible  
Difficulty:  Unknown   | Os:  Windows 
  Testcase:|   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---+
Changes (by igloo):

  * status:  new => closed
  * failure:  => None/Unknown
  * resolution:  => invalid


Comment:

 No response from submitter.

-- 
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] #3394: Make Permissions type abstract

[GHC]

#3394: Make Permissions type abstract
--+-
  Reporter:  igloo|  Owner:  
  Type:  task | Status:  closed  
  Priority:  normal   |  Milestone:  6.14.1  
 Component:  libraries/directory  |Version:  6.10.4  
Resolution:  fixed|   Keywords:  
Difficulty:  Unknown  | Os:  Unknown/Multiple
  Testcase:   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown |  
--+-
Changes (by igloo):

  * status:  new => closed
  * failure:  => None/Unknown
  * resolution:  => fixed


Comment:

 Done: #4149.

-- 
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] #4149: Make Permissions type abstract

[GHC]

#4149: Make Permissions type abstract
+---
Reporter:  igloo|Owner:  
Type:  proposal |   Status:  new 
Priority:  normal   |Milestone:  Not GHC 
   Component:  libraries/directory  |  Version:  6.12.3  
Keywords:   |   Difficulty:  
  Os:  Unknown/Multiple | Testcase:  
Architecture:  Unknown/Multiple |  Failure:  None/Unknown
+---

Comment(by igloo):

 Thread starts here:
 http://www.haskell.org/pipermail/libraries/2010-June/013757.html

-- 
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] #4149: Make Permissions type abstract

[GHC]

#4149: Make Permissions type abstract
+---
Reporter:  igloo|Owner:  
Type:  proposal |   Status:  new 
Priority:  normal   |Milestone:  Not GHC 
   Component:  libraries/directory  |  Version:  6.12.3  
Keywords:   |   Difficulty:  
  Os:  Unknown/Multiple | Testcase:  
Architecture:  Unknown/Multiple |  Failure:  None/Unknown
+---
 The `Permissions` type in `System.Directory` aims to be a lowest-common-
 denominator type. This makes it unsuitable for some tasks. For example, a
 `copyPermissions` primitive had to be implemented, as it is not possible
 to use the `getPermissions` and `setPermissions` functions to copy the
 permissions from one file to another:
 {{{
 $ ls -l foo*
 -rwxr-x-wx 1 ian ian 0 Jun 23 21:27 foo1
 -- 1 ian ian 0 Jun 23 21:27 foo2
 -- 1 ian ian 0 Jun 23 21:27 foo3
 $ hd -e 'System.Directory.copyPermissions "foo1" "foo2"'
 $ hd -e 'System.Directory.getPermissions "foo1" >>=
 System.Directory.setPermissions "foo3"'
 $ ls -l foo*
 -rwxr-x-wx 1 ian ian 0 Jun 23 21:27 foo1
 -rwxr-x-wx 1 ian ian 0 Jun 23 21:27 foo2
 -rwx-- 1 ian ian 0 Jun 23 21:27 foo3
 }}}

 I think we would be better served by the `Permissions` type being abstract
 in `System.Directory`, with the `unix` and `Win32` packages providing the
 real definition, and some system-specific functions on it. This would
 allow the generic get/set functions to implement `copyPermissions`.

 This proposal just does the step which has most potential to cause
 problems for packages that use the type: It makes the type abstract in
 `System.Directory` (and adds explicit setter functions, so no
 functionality is lost).

 The type is also exported in Haskell 98's `Directory` module. I think this
 should get its own copy of the type.

 Suggested discussion deadline: 9 July 2010.

-- 
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] #2362: allow full import syntax in GHCi

[GHC]

#2362: allow full import syntax in GHCi
-+--
Reporter:  Isaac Dupree  |Owner:  igloo   
Type:  feature request   |   Status:  new 
Priority:  high  |Milestone:  6.14.1  
   Component:  Compiler  |  Version:  6.8.2   
Keywords:  ghci, import  |   Difficulty:  Unknown 
  Os:  Unknown/Multiple  | Testcase:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--
Changes (by SamAnklesaria):

  * owner:  SamAnklesaria => igloo


Comment:

 My patch separates ghci 'import' syntax from ':module' syntax: while
 ':module' behaves the same way it always has (not allowing full import
 syntax), 'import' now acts like the full haskell98 'import'. This means,
 however, that starred module name imports (that is, full top levels) are
 now not supported by 'import'. With ':module' still supporting this,
 though, I don't think this is a problem.

 Because import commands are represented by ImportDecls, I modified the
 "ic_exports" field of InteractiveContext to take both modules and their
 corresponding import declarations, if any.  Along with this change comes a
 modification of getContext, which must use the different "ic_exports"
 type.

-- 
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] #3389: CPP strips out C-style comments

[GHC]

#3389: CPP strips out C-style comments
--+-
  Reporter:  nominolo |  Owner:  igloo   
  Type:  feature request  | Status:  new 
  Priority:  normal   |  Milestone:  6.14.1  
 Component:  Driver   |Version:  6.10.2  
Resolution:   |   Keywords:  
Difficulty:  Unknown  | Os:  Unknown/Multiple
  Testcase:   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown |  
--+-

Comment(by igloo):

 Thanks Malcolm, quite right. I've attached a patch to fix this.

 However, the build breaks when compiling dph, as dph uses the Cabal auto-
 generated header files in Haskell files, which end up containing something
 like
 {{{
 /* DO NOT EDIT: This file is automatically generated by Cabal */
 /* package array-0.3.0.0 */
 /* package base-4.3.0.0 */
 /* package dph-base-0.4.0 */
 module Data.Array.Parallel.Lifted.Instances
 }}}
 They could be switched to use Haskell comments, but I don't know if being
 able to include them in C files is also important; Duncan?

 The fix to this will be easy, once we work out what the desired behaviour
 is...

-- 
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] #3389: CPP strips out C-style comments

[GHC]

#3389: CPP strips out C-style comments
--+-
  Reporter:  nominolo |  Owner:  igloo   
  Type:  feature request  | Status:  new 
  Priority:  normal   |  Milestone:  6.14.1  
 Component:  Driver   |Version:  6.10.2  
Resolution:   |   Keywords:  
Difficulty:  Unknown  | Os:  Unknown/Multiple
  Testcase:   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown |  
--+-
Changes (by igloo):

  * owner:  => igloo
  * failure:  => None/Unknown


-- 
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] #3276: FilePath.addTrailingPathSeparator "" = "/"

[GHC]

#3276: FilePath.addTrailingPathSeparator "" = "/"
+---
  Reporter:  duncan |  Owner:  
  Type:  bug| Status:  closed  
  Priority:  normal |  Milestone:  6.14.1  
 Component:  libraries (other)  |Version:  6.10.2  
Resolution:  wontfix|   Keywords:  
Difficulty:  Unknown| Os:  Unknown/Multiple
  Testcase: |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown   |  
+---
Changes (by igloo):

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


Comment:

 I think we'll need a
 [http://www.haskell.org/haskellwiki/Library_submissions library proposal]
 to make progress on this.

-- 
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] #4148: improve new recursive do syntax

[GHC]

#4148: improve new recursive do syntax
-+--
Reporter:  guest |Owner:  
Type:  feature request   |   Status:  new 
Priority:  normal|Milestone:  
   Component:  Compiler  |  Version:  6.12.3  
Keywords:|   Difficulty:  
  Os:  Unknown/Multiple  | Testcase:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--
Changes (by simonpj):

 * cc: r...@…, iavor.diatc...@… (added)


Comment:

 Last comment from me:
  * I don't have a strong opinion about any of this recursive-do stuff. But
 I'd like  it to be as easy to use, and as predicatable, as possible.
  * I am totally snowed under for the next few weeks
  * If anyone is willing to take change of driving this issue to a
 consensus, I'd gladly help implement the result.

 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] #4148: improve new recursive do syntax

[GHC]

#4148: improve new recursive do syntax
-+--
Reporter:  guest |Owner:  
Type:  feature request   |   Status:  new 
Priority:  normal|Milestone:  
   Component:  Compiler  |  Version:  6.12.3  
Keywords:|   Difficulty:  
  Os:  Unknown/Multiple  | Testcase:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by simonpj):

 I'm adding Ross's recent email to this ticket since it is relevant.
 http://www.haskell.org/pipermail/glasgow-haskell-
 users/2010-June/018944.html
 Here it is verbatim.

 There's also an underlying semantic issue, which is not yet resolved.

 The GHC implementation of mdo (following Levent and John's paper) performs
 a dependency analysis on the statements in the mdo to apply mfix to the
 shortest possible subsegments of statements.  For example,
 {{{
   mdo
 a <- f b
 b <- g b
 c <- h b
 d <- k d
 return d
 }}}
 is translated to the equivalent of
 {{{
   do
 (a,b) <- mfix $ \ (a,b) -> do
a <- f b
b <- g b
return (a,b)
 c <- h b
 d <- mfix $ \ d ->
d <- k d
return d
 return d
 }}}
 As the User's Guide notes, the choice of segments can change the semantics
 with some monads.

 When rec was added to GHC, the implementation used the same code and thus
 also did automatic segmentation.  The original idea of rec (in arrow
 notation) was that it would give the programmer direct control over these
 segments: the loop/mfix combinators would go wherever the programmer put a
 rec, but I didn't realize Simon had done it the other way until he
 mentioned it last October.  So:

  * if rec is to continue to do automatic segmentation, it might as well
be a modifier on the do keyword (though this would break backward
compatibility of arrow notation),

  * but I want to argue against automatic segmentation, because I don't
think the compiler should be making subtle changes to the program's
semantics on its own.  It would simplify the compiler a bit 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] #4148: improve new recursive do syntax

[GHC]

#4148: improve new recursive do syntax
-+--
Reporter:  guest |Owner:  
Type:  feature request   |   Status:  new 
Priority:  normal|Milestone:  
   Component:  Compiler  |  Version:  6.12.3  
Keywords:|   Difficulty:  
  Os:  Unknown/Multiple  | Testcase:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by simonpj):

 Well, at the moment a `rec {...}` block can't be the last statement in a
 `do`. But after talking to Simon I realise that we could change that, by
 adopting the following translation:
 {{{
  do { ...; rec { ...; e } }
 ==>
  do { ...; rec { ...; res <- e }; return res }
 }}}
 Now if the initial "..." was empty we could write
 {{{
   do rec {...}
 }}}
 as "guest" (Jack, perhaps) wants.

 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] #2717: Add nubWith, nubOrd

[GHC]

#2717: Add nubWith, nubOrd
-+--
  Reporter:  Bart Massey |  Owner:  
  Type:  proposal| Status:  new 
  Priority:  normal  |  Milestone:  Not GHC 
 Component:  libraries/base  |Version:  
Resolution:  |   Keywords:  
Difficulty:  Unknown | Os:  Unknown/Multiple
  Testcase:  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown|  
-+--

Comment(by igloo):

 Replying to [comment:5 YitzGale]:
 > Replying to [comment:4 igloo]:
 > > Looks like an abandoned proposal
 >
 > Why?

 Because the discussion and consensus was not summarised in the ticket. See
 [http://www.haskell.org/haskellwiki/Library_submissions the library
 submissions process], "At the end of the discussion period".

-- 
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] #4147: 'withFilePath' not in scope, windows build, using base 4.1.0.0

[GHC]

#4147: 'withFilePath' not in scope, windows build, using base 4.1.0.0
+---
Reporter:  lcasburn |Owner:  igloo 
Type:  bug  |   Status:  new   
Priority:  normal   |Milestone:
   Component:  libraries/directory  |  Version:  6.10.4
Keywords:   |   Difficulty:
  Os:  Windows  | Testcase:
Architecture:  Unknown/Multiple |  Failure:  Compile-time crash
+---
Changes (by simonmar):

  * owner:  => igloo


Comment:

 I've updated the build-depends:

 {{{
 Wed Jun 23 11:43:44 BST 2010  Simon Marlow 
   * require base-4.2; the Windows code needs withFilePath (#4147)
 }}}

 Ian, we should upload a new version of directory to Hackage.  Could you
 take care of that please?

-- 
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] #4148: improve new recursive do syntax

[GHC]

#4148: improve new recursive do syntax
-+--
Reporter:  guest |Owner:  
Type:  feature request   |   Status:  new 
Priority:  normal|Milestone:  
   Component:  Compiler  |  Version:  6.12.3  
Keywords:|   Difficulty:  
  Os:  Unknown/Multiple  | Testcase:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by simonmar):

 Replying to [comment:1 simonpj]:
 > The change was in fact explicitly highlighted in my email to the ghc-
 users list http://www.mail-archive.com/glasgow-haskell-
 us...@haskell.org/msg17406.html.
 >
 > The difficulty I see with your suggestion is that it requires arbitrary
 lookahead to resolve the ambiguity.

 Perhaps I'm being stupid, but I can't see how it needs arbitrary
 lookahead.  Could you explain that?

 > And in any case, you can always use 'mdo', right?  What's wrong with
 doing that?

 well, we deprecated the `mdo` notation.

-- 
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] #2717: Add nubWith, nubOrd

[GHC]

#2717: Add nubWith, nubOrd
-+--
  Reporter:  Bart Massey |  Owner:  
  Type:  proposal| Status:  new 
  Priority:  normal  |  Milestone:  Not GHC 
 Component:  libraries/base  |Version:  
Resolution:  |   Keywords:  
Difficulty:  Unknown | Os:  Unknown/Multiple
  Testcase:  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown|  
-+--
Changes (by YitzGale):

 * cc: g...@… (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] #2717: Add nubWith, nubOrd

[GHC]

#2717: Add nubWith, nubOrd
-+--
  Reporter:  Bart Massey |  Owner:  
  Type:  proposal| Status:  new 
  Priority:  normal  |  Milestone:  Not GHC 
 Component:  libraries/base  |Version:  
Resolution:  |   Keywords:  
Difficulty:  Unknown | Os:  Unknown/Multiple
  Testcase:  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown|  
-+--
Changes (by YitzGale):

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


Comment:

 Replying to [comment:4 igloo]:
 > Looks like an abandoned proposal

 Why? This is a good patch, long needed, with strong consensus on the list.

 After the request for a final round of patch review, there were no further
 comments. I think the poster just forgot the last step of formally
 requesting that the patches be applied.

 I think this should be applied.

-- 
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] #4141: Inconsistant .hi or .hi-boot compilation error

[GHC]

#4141: Inconsistant .hi or .hi-boot compilation error
-+--
Reporter:  odj   |Owner:  
Type:  bug   |   Status:  new 
Priority:  normal|Milestone:  
   Component:  Compiler  |  Version:  6.12.1  
Keywords:|   Difficulty:  
  Os:  MacOS X   | Testcase:  
Architecture:  x86   |  Failure:  None/Unknown
-+--

Comment(by simonpj):

 The `` means there is a GHC bug.   If you can send instructions for
 how to reproduce it I'll have a look.

 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] #4148: improve new recursive do syntax

[GHC]

#4148: improve new recursive do syntax
-+--
Reporter:  guest |Owner:  
Type:  feature request   |   Status:  new 
Priority:  normal|Milestone:  
   Component:  Compiler  |  Version:  6.12.3  
Keywords:|   Difficulty:  
  Os:  Unknown/Multiple  | Testcase:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by simonpj):

 The change was in fact explicitly highlighted in my email to the ghc-users
 list http://www.mail-archive.com/glasgow-haskell-
 us...@haskell.org/msg17406.html.

 The difficulty I see with your suggestion is that it requires arbitrary
 lookahead to resolve the ambiguity.  And in any case, you can always use
 'mdo', right?  What's wrong with doing that?

 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