Re: [GHC] #6128: ghc 7.4.1 does not work with LDAP-0.6.6

[GHC]

#6128: ghc 7.4.1 does not work with LDAP-0.6.6
---+
Reporter:  magicloud   |   Owner: 
Type:  bug |  Status:  infoneeded 
Priority:  normal  |   Milestone: 
   Component:  Compiler| Version:  7.4.1  
Keywords:  LDAP|  Os:  Linux  
Architecture:  x86_64 (amd64)  | Failure:  Incorrect result at runtime
  Difficulty:  Unknown |Testcase: 
   Blockedby:  |Blocking: 
 Related:  |  
---+

Comment(by magicloud):

 Hi, it is hard to say "easily" since the condition is confusing.
 For me, Debian unstable/stable CentOS 6.1 were all tested with self-
 compiled 7.4.1 (without any extra configuration arguments, all
 gcc/binutils whatsoever came with the OS). All failed.
 For Chris Dornan from haskell-cafe, he used 7.4.1 to make the code work. I
 have compared the .hi/.o files between him and me. Nothing interesting.
 Hoping this helps.

-- 
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] #6149: ghc-7.4.2 tests for profasm seg-fault under solaris

[GHC]

#6149: ghc-7.4.2 tests for profasm seg-fault under solaris
-+--
Reporter:  maeder|   Owner:   
Type:  bug   |  Status:  new  
Priority:  normal|   Milestone:   
   Component:  Compiler  | Version:  7.4.2-rc1
Keywords:|  Os:  Solaris  
Architecture:  x86   | Failure:  Runtime crash
  Difficulty:  Unknown   |Testcase:   
   Blockedby:|Blocking:   
 Related:|  
-+--

Comment(by kgardas):

 Ian, you are right, the builder seems to be stopped now, I'll restart it
 immediately, but on the other hand the last provided build is from May 18
 and its number is 443, see here:
 http://darcs.haskell.org/ghcBuilder/builders/kgardas-opensolaris-x86-head/
 -- also it looks like the index.html in this directory is missing so if
 you click on kgardas-opensolaris-x86-head link on page
 http://darcs.haskell.org/ghcBuilder/builders/ you will get error.
 Anyway, even build 443 is w/o those excess number of errors Christian sees
 on his Solaris.

-- 
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] #4968: openTempFile fails on Windows if a directory exists with the file name it tries

[GHC]

#4968: openTempFile fails on Windows if a directory exists with the file name it
tries
---+
Reporter:  ganesh  |   Owner:  pcapriotti 
Type:  bug |  Status:  merge  
Priority:  high|   Milestone:  7.4.2  
   Component:  libraries/base  | Version:  7.0.1  
Keywords:  |  Os:  Windows
Architecture:  x86_64 (amd64)  | Failure:  Incorrect result at runtime
  Difficulty:  Unknown |Testcase: 
   Blockedby:  |Blocking: 
 Related:  |  
---+
Changes (by pcapriotti):

  * status:  patch => merge


Comment:

 Pushed:

 {{{
 commit 6172212097337923b621be9e12b3542c34cad10e
 Author: Paolo Capriotti 
 Date:   Thu Jun 7 11:18:00 2012 +0100

 Allow openTempFile to retry when it hits a directory (#4968).

 Windows returns an EACCES error instead of EEXIST when a call to
 `open`
 fails due to an existing directory, so add a special case for this
 situation.

 commit cd94cd74527ff3d812a083d903f68c1f9bd571b2
 Author: Paolo Capriotti 
 Date:   Thu Jun 7 10:51:27 2012 +0100

 Refactor findTempName: factor out file creation.

 Add openNewFile function, which creates a new file and returns a file
 descriptor for it.
 }}}

-- 
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] #6149: ghc-7.4.2 tests for profasm seg-fault under solaris

[GHC]

#6149: ghc-7.4.2 tests for profasm seg-fault under solaris
-+--
Reporter:  maeder|   Owner:   
Type:  bug   |  Status:  new  
Priority:  normal|   Milestone:   
   Component:  Compiler  | Version:  7.4.2-rc1
Keywords:|  Os:  Solaris  
Architecture:  x86   | Failure:  Runtime crash
  Difficulty:  Unknown   |Testcase:   
   Blockedby:|Blocking:   
 Related:|  
-+--
Changes (by igloo):

  * difficulty:  => Unknown


Comment:

 Replying to [comment:1 kgardas]:
 > Hello, for some strange reason GHC builder server no longer send emails
 with the status of my open solaris buildbot (I'm using version 1 of the
 builder client still here), but yes, my buildbot is still running and
 provides service. You can see it here:
 http://darcs.haskell.org/ghcBuilder/builders/

 I don't think the builder is currently connected. The old version of the
 builder code doesn't send timestamps, but looking at the "GHC version
 date" in the configure step of the most recent build
 (http://darcs.haskell.org/ghcBuilder/builders/kgardas-
 opensolaris-x86-head/417/8.html) it looks like it last did a build in
 February.

-- 
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] #6149: ghc-7.4.2 tests for profasm seg-fault under solaris

[GHC]

#6149: ghc-7.4.2 tests for profasm seg-fault under solaris
---+
 Reporter:  maeder |  Owner:  
 Type:  bug| Status:  new 
 Priority:  normal |  Component:  Compiler
  Version:  7.4.2-rc1  |   Keywords:  
   Os:  Solaris|   Architecture:  x86 
  Failure:  Runtime crash  |   Testcase:  
Blockedby: |   Blocking:  
  Related: |  
---+
Changes (by kgardas):

 * cc: karel.gardas@… (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] #6149: ghc-7.4.2 tests for profasm seg-fault under solaris

[GHC]

#6149: ghc-7.4.2 tests for profasm seg-fault under solaris
---+
 Reporter:  maeder |  Owner:  
 Type:  bug| Status:  new 
 Priority:  normal |  Component:  Compiler
  Version:  7.4.2-rc1  |   Keywords:  
   Os:  Solaris|   Architecture:  x86 
  Failure:  Runtime crash  |   Testcase:  
Blockedby: |   Blocking:  
  Related: |  
---+

Comment(by kgardas):

 Hello, for some strange reason GHC builder server no longer send emails
 with the status of my open solaris buildbot (I'm using version 1 of the
 builder client still here), but yes, my buildbot is still running and
 provides service. You can see it here:
 http://darcs.haskell.org/ghcBuilder/builders/ -- although it is building
 HEAD you can be assured that I've never seen so huge number of failures on
 my open solaris box even in the time 7.4.x branch was HEAD. So my guess is
 you are still using Solaris 10?

-- 
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:  low   |   Milestone:  7.6.1   
   Component:  Compiler  | Version:  6.12.3  
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by lerkok):

 I do want B indeed. The comment you quoted was meant to say "if you don't
 do segmentation, then you might as well remove the whole thing."

 I'll take a shot at implementing it, but my GHC-fu is quite rusty; it's
 been 10 years now that the original version was implemented. I trust GHCHQ
 will help me out if I get stuck.

-- 
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] #6146: Segmentation fault with eager blackholing

[GHC]

#6146: Segmentation fault with eager blackholing
-+--
  Reporter:  emcdowell   |  Owner:  simonmar 
  Type:  bug | Status:  merge
  Priority:  high|  Milestone:  7.4.2
 Component:  Runtime System  |Version:  7.4.1
Resolution:  fixed   |   Keywords:  eager blackholing
Os:  Windows |   Architecture:  x86  
   Failure:  Runtime crash   | Difficulty:  Unknown  
  Testcase:  |  Blockedby:   
  Blocking:  |Related:   
-+--
Changes (by simonmar):

  * status:  closed => merge


Comment:

 duh, keep forgetting to set these to merge, sorry for the spam.

-- 
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] #6146: Segmentation fault with eager blackholing

[GHC]

#6146: Segmentation fault with eager blackholing
-+--
  Reporter:  emcdowell   |  Owner:  simonmar 
  Type:  bug | Status:  closed   
  Priority:  high|  Milestone:  7.4.2
 Component:  Runtime System  |Version:  7.4.1
Resolution:  fixed   |   Keywords:  eager blackholing
Os:  Windows |   Architecture:  x86  
   Failure:  Runtime crash   | Difficulty:  Unknown  
  Testcase:  |  Blockedby:   
  Blocking:  |Related:   
-+--
Changes (by simonmar):

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


Comment:

 Thanks, nice bug.

-- 
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] #6103: Interrupted program cannot produce biographical heap profile

[GHC]

#6103: Interrupted program cannot produce biographical heap profile
+---
  Reporter:  konn   |  Owner:  simonmar  
  Type:  bug| Status:  merge 
  Priority:  high   |  Milestone:  7.4.2 
 Component:  Profiling  |Version:  7.4.1 
Resolution:  fixed  |   Keywords:
Os:  MacOS X|   Architecture:  x86_64 (amd64)
   Failure:  Runtime crash  | Difficulty:  Unknown   
  Testcase: |  Blockedby:
  Blocking: |Related:
+---
Changes (by simonmar):

  * status:  closed => merge


-- 
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] #6103: Interrupted program cannot produce biographical heap profile

[GHC]

#6103: Interrupted program cannot produce biographical heap profile
+---
  Reporter:  konn   |  Owner:  simonmar  
  Type:  bug| Status:  closed
  Priority:  high   |  Milestone:  7.4.2 
 Component:  Profiling  |Version:  7.4.1 
Resolution:  fixed  |   Keywords:
Os:  MacOS X|   Architecture:  x86_64 (amd64)
   Failure:  Runtime crash  | Difficulty:  Unknown   
  Testcase: |  Blockedby:
  Blocking: |Related:
+---
Changes (by simonmar):

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


Comment:

 Punting on a regression test, because it's too hard to make one.

-- 
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] #6103: Interrupted program cannot produce biographical heap profile

[GHC]

#6103: Interrupted program cannot produce biographical heap profile
---+
Reporter:  konn|   Owner:  simonmar 
Type:  bug |  Status:  new  
Priority:  high|   Milestone:  7.4.2
   Component:  Profiling   | Version:  7.4.1
Keywords:  |  Os:  MacOS X  
Architecture:  x86_64 (amd64)  | Failure:  Runtime crash
  Difficulty:  Unknown |Testcase:   
   Blockedby:  |Blocking:   
 Related:  |  
---+

Comment(by marlowsd@…):

 commit 20ba7f1a7a7b05acd81124f1567a3a103bcd0d1b
 {{{
 Author: Simon Marlow 
 Date:   Tue Jun 5 09:05:47 2012 +0100

 throwTo: unlock the MSG_THROWTO object before returning (#6103)

  rts/RaiseAsync.c |   10 --
  1 files changed, 8 insertions(+), 2 deletions(-)
 }}}

-- 
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] #6146: Segmentation fault with eager blackholing

[GHC]

#6146: Segmentation fault with eager blackholing
--+-
Reporter:  emcdowell  |   Owner:  simonmar 
Type:  bug|  Status:  new  
Priority:  high   |   Milestone:  7.4.2
   Component:  Runtime System | Version:  7.4.1
Keywords:  eager blackholing  |  Os:  Windows  
Architecture:  x86| Failure:  Runtime crash
  Difficulty:  Unknown|Testcase:   
   Blockedby: |Blocking:   
 Related: |  
--+-

Comment(by marlowsd@…):

 commit 21a53a1cd5a9784aca7b78cc972f917e71938124
 {{{
 Author: Simon Marlow 
 Date:   Thu Jun 7 15:45:32 2012 +0100

 Fix for earger blackholing of thunks with no free variables (#6146)

 A thunk with no free variables was not getting blackholed when
 -feager-blackholing was on, but we were nevertheless pushing the
 stg_bh_upd_frame version of the update frame that expects to see a
 black hole.

 I fixed this twice for good measure:

  - we now call blackHoleOnEntry when pushing the update frame to check
whether the closure was actually blackholed, and so that we use the
same predicate in both places

  - we now black hole thunks even if they have no free variables.
These only occur when optimisation is off, but presumably if you
 say
-feager-blackholing then that's what you want to happen.

  compiler/codeGen/CgClosure.lhs|7 ---
  compiler/codeGen/ClosureInfo.lhs  |2 +-
  compiler/codeGen/StgCmmBind.hs|   17 ++---
  compiler/codeGen/StgCmmClosure.hs |2 +-
  4 files changed, 16 insertions(+), 12 deletions(-)
 }}}

-- 
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] #5553: sendWakeup error in simple test program with MVars and killThread

[GHC]

#5553: sendWakeup error in simple test program with MVars and killThread
--+-
  Reporter:  bit  |  Owner:  tibbe  
  Type:  bug  | Status:  closed 
  Priority:  high |  Milestone:  7.4.2  
 Component:  Runtime System   |Version:  7.2.1  
Resolution:  worksforme   |   Keywords: 
Os:  Linux|   Architecture:  x86
   Failure:  Incorrect result at runtime  | Difficulty:  Unknown
  Testcase:   |  Blockedby: 
  Blocking:   |Related: 
--+-
Changes (by simonmar):

  * status:  new => closed
  * difficulty:  => Unknown
  * resolution:  => worksforme


Comment:

 Replying to [comment:8 bit]:
 > I am the original reporter of this bug.
 >
 > I would just like to report that ghc 7.4.1 seems to have resolved this
 bug, and I am no longer getting the error from the test program.

 Thanks!

-- 
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] #3222: GLFW 0.3 build fails w/ SSE error in 6.10.3, works in 6.10.1

[GHC]

#3222: GLFW 0.3 build fails w/ SSE error in 6.10.3, works in 6.10.1
-+--
  Reporter:  GregFrascadore  |  Owner: 
  Type:  bug | Status:  closed 
  Priority:  lowest  |  Milestone:  7.6.1  
 Component:  Compiler|Version:  6.10.3 
Resolution:  worksforme  |   Keywords: 
Os:  MacOS X |   Architecture:  x86
   Failure:  None/Unknown| Difficulty:  Unknown
  Testcase:  |  Blockedby: 
  Blocking:  |Related: 
-+--
Changes (by simonmar):

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


Comment:

 Thanks altaic.  Let's assume it has been fixed then.

-- 
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] #6125: GHCi crash

[GHC]

#6125: GHCi crash
-+--
  Reporter:  guest   |  Owner:
  Type:  bug | Status:  closed
  Priority:  normal  |  Milestone:
 Component:  GHCi|Version:  7.0.3 
Resolution:  worksforme  |   Keywords:
Os:  Windows |   Architecture:  x86_64 (amd64)
   Failure:  GHCi crash  | Difficulty:  Unknown   
  Testcase:  |  Blockedby:
  Blocking:  |Related:
-+--
Changes (by simonmar):

  * status:  new => closed
  * difficulty:  => Unknown
  * resolution:  => worksforme


Comment:

 either #4245 or #5588, I expect.  Please try with a more recent version of
 GHC and reopen the ticket if the bug still happens.

-- 
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] #6131: -fprof-auto adds cost centers to INLINE functions

[GHC]

#6131: -fprof-auto adds cost centers to INLINE functions
---+
Reporter:  akio|   Owner: 
Type:  bug |  Status:  infoneeded 
Priority:  normal  |   Milestone: 
   Component:  Compiler| Version:  7.4.2-rc1  
Keywords:  |  Os:  Linux  
Architecture:  x86_64 (amd64)  | Failure:  Incorrect result at runtime
  Difficulty:  Unknown |Testcase: 
   Blockedby:  |Blocking: 
 Related:  |  
---+
Changes (by simonmar):

  * status:  new => infoneeded
  * difficulty:  => Unknown


Comment:

 This is indeed a bug, however we are inclined to fix the documentation
 rather than the implementation, i.e. functions with an `INLINE` pragma
 will also get cost centres.  Would this be a problem for you?  What is the
 reason that you didn't want a cost centre on `foo`?

-- 
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] #4968: openTempFile fails on Windows if a directory exists with the file name it tries

[GHC]

#4968: openTempFile fails on Windows if a directory exists with the file name it
tries
---+
Reporter:  ganesh  |   Owner:  pcapriotti 
Type:  bug |  Status:  patch  
Priority:  high|   Milestone:  7.4.2  
   Component:  libraries/base  | Version:  7.0.1  
Keywords:  |  Os:  Windows
Architecture:  x86_64 (amd64)  | Failure:  Incorrect result at runtime
  Difficulty:  Unknown |Testcase: 
   Blockedby:  |Blocking: 
 Related:  |  
---+

Comment(by pcapriotti):

 I wrote this [example program https://gist.github.com/2889480] to check
 whether using the native windows API would make a difference, but
 `CreateFile` has the same problem, and returns EACCES when trying to
 overwrite a directory.

 Anyway, I'll go ahead with the patch for now.

-- 
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] #6128: ghc 7.4.1 does not work with LDAP-0.6.6

[GHC]

#6128: ghc 7.4.1 does not work with LDAP-0.6.6
---+
Reporter:  magicloud   |   Owner: 
Type:  bug |  Status:  infoneeded 
Priority:  normal  |   Milestone: 
   Component:  Compiler| Version:  7.4.1  
Keywords:  LDAP|  Os:  Linux  
Architecture:  x86_64 (amd64)  | Failure:  Incorrect result at runtime
  Difficulty:  Unknown |Testcase: 
   Blockedby:  |Blocking: 
 Related:  |  
---+
Changes (by simonmar):

  * status:  new => infoneeded
  * difficulty:  => Unknown


Comment:

 We'll probably need more information to debug this one.  Is there a way to
 reproduce it easily?

-- 
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] #6127: Build for MIPS N32 host fails due to references to 64-bit support code

[GHC]

#6127: Build for MIPS N32 host fails due to references to 64-bit support code
---+
Reporter:  mtjm|   Owner:  pcapriotti 
Type:  bug |  Status:  patch  
Priority:  normal  |   Milestone:  7.6.1  
   Component:  Runtime System  | Version:  7.5
Keywords:  |  Os:  Linux  
Architecture:  mips| Failure:  Building GHC failed
  Difficulty:  Unknown |Testcase: 
   Blockedby:  |Blocking: 
 Related:  |  
---+
Changes (by simonmar):

  * owner:  => pcapriotti
  * difficulty:  => Unknown
  * milestone:  => 7.6.1


Comment:

 I know nothing about MIPS N32, but the patch shouldn't do any harm.

-- 
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] #6135: Unboxed Booleans

[GHC]

#6135: Unboxed Booleans
-+--
Reporter:  benl  |   Owner:  
Type:  feature request   |  Status:  new 
Priority:  normal|   Milestone:  
   Component:  Compiler  | Version:  7.4.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by tibbe):

 If we end up doing something like this, we should consider if it could be
 extended to work for any enumeration (i.e. data type with only nullary
 constructors.)

-- 
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] #4968: openTempFile fails on Windows if a directory exists with the file name it tries

[GHC]

#4968: openTempFile fails on Windows if a directory exists with the file name it
tries
---+
Reporter:  ganesh  |   Owner:  pcapriotti 
Type:  bug |  Status:  patch  
Priority:  high|   Milestone:  7.4.2  
   Component:  libraries/base  | Version:  7.0.1  
Keywords:  |  Os:  Windows
Architecture:  x86_64 (amd64)  | Failure:  Incorrect result at runtime
  Difficulty:  Unknown |Testcase: 
   Blockedby:  |Blocking: 
 Related:  |  
---+

Comment(by simonmar):

 The real problem seems to be that we're using `_open` from the CRT, which
 returns `EACCESS` when opening a directory.  In fact, `System.IO.openFile`
 is behaving incorrectly on Windows when asked to open a file.

 If we used the proper Win32 API we'd be able to handle this more cleanly,
 but that requires a rewrite of the IO layer on Windows.

 I'm ok with the proposed patch as a temporary workaround.

-- 
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] #6145: DataCon do not have location info

[GHC]

#6145: DataCon do not have location info
--+-
  Reporter:  JeanPhilippeMoresmau |  Owner:  
  Type:  bug  | Status:  closed  
  Priority:  normal   |  Milestone:  
 Component:  GHC API  |Version:  7.4.1   
Resolution:  fixed|   Keywords:  
Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
   Failure:  Incorrect result at runtime  | Difficulty:  Unknown 
  Testcase:  ghc-api/T6145|  Blockedby:  
  Blocking:   |Related:  
--+-
Changes (by simonpj):

  * status:  new => closed
  * testcase:  => ghc-api/T6145
  * resolution:  => fixed


Comment:

 OK, with a bit of fiddling I made the test work.

-- 
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] #4968: openTempFile fails on Windows if a directory exists with the file name it tries

[GHC]

#4968: openTempFile fails on Windows if a directory exists with the file name it
tries
---+
Reporter:  ganesh  |   Owner:  pcapriotti 
Type:  bug |  Status:  patch  
Priority:  high|   Milestone:  7.4.2  
   Component:  libraries/base  | Version:  7.0.1  
Keywords:  |  Os:  Windows
Architecture:  x86_64 (amd64)  | Failure:  Incorrect result at runtime
  Difficulty:  Unknown |Testcase: 
   Blockedby:  |Blocking: 
 Related:  |  
---+
Changes (by pcapriotti):

  * status:  new => patch


Comment:

 The attached patches implement the simple solution suggested by fryguybob.
 It is not perfect, but I couldn't think of a better solution, short of
 using Windows temporary file API, which, however, would be too
 restrictive.

-- 
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] #6146: Segmentation fault with eager blackholing

[GHC]

#6146: Segmentation fault with eager blackholing
--+-
Reporter:  emcdowell  |   Owner:  simonmar 
Type:  bug|  Status:  new  
Priority:  high   |   Milestone:  7.4.2
   Component:  Runtime System | Version:  7.4.1
Keywords:  eager blackholing  |  Os:  Windows  
Architecture:  x86| Failure:  Runtime crash
  Difficulty:  Unknown|Testcase:   
   Blockedby: |Blocking:   
 Related: |  
--+-
Changes (by simonmar):

  * owner:  => simonmar
  * difficulty:  => Unknown
  * priority:  normal => high
  * component:  Compiler => Runtime System
  * milestone:  => 7.4.2


-- 
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] #6142: Outdated comment in Directory.hs

[GHC]

#6142: Outdated comment in Directory.hs
+---
Reporter:  mjo  |   Owner:  simonmar 
Type:  bug  |  Status:  new  
Priority:  normal   |   Milestone:  7.6.1
   Component:  libraries/directory  | Version:   
Keywords:   |  Os:  Unknown/Multiple 
Architecture:  Unknown/Multiple | Failure:  Documentation bug
  Difficulty:  Unknown  |Testcase:   
   Blockedby:   |Blocking:   
 Related:   |  
+---
Changes (by simonmar):

  * owner:  => simonmar
  * difficulty:  => Unknown
  * milestone:  => 7.6.1


Comment:

 I'll fix 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] #6140: segfault in OS X GHCi when dealing with infinite integers

[GHC]

#6140: segfault in OS X GHCi when dealing with infinite integers
+---
  Reporter:  olf|  Owner:   
  Type:  bug| Status:  closed   
  Priority:  normal |  Milestone:   
 Component:  GHCi   |Version:  6.10.4   
Resolution:  worksforme |   Keywords:  segfault NaN Infinity
Os:  MacOS X|   Architecture:  x86  
   Failure:  Runtime crash  | Difficulty:  Unknown  
  Testcase: |  Blockedby:   
  Blocking: |Related:   
+---
Changes (by simonmar):

  * status:  new => closed
  * difficulty:  => Unknown
  * resolution:  => worksforme


-- 
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] #5390: Hard-coded /Developer path in Mac ghc

[GHC]

#5390: Hard-coded /Developer path in Mac ghc
-+--
Reporter:  Ahruman   |   Owner:  pumpkin
Type:  bug   |  Status:  new
Priority:  low   |   Milestone:  7.6.1  
   Component:  Compiler  | Version:  7.0.3  
Keywords:  platform  |  Os:  MacOS X
Architecture:  Unknown/Multiple  | Failure:  GHC doesn't work at all
  Difficulty:  Unknown   |Testcase: 
   Blockedby:|Blocking: 
 Related:|  
-+--
Changes (by simonmar):

  * difficulty:  => Unknown


Comment:

 We still have a gcc path in the `settings` file, I believe.

-- 
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] #6135: Unboxed Booleans

[GHC]

#6135: Unboxed Booleans
-+--
Reporter:  benl  |   Owner:  
Type:  feature request   |  Status:  new 
Priority:  normal|   Milestone:  
   Component:  Compiler  | Version:  7.4.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by simonpj):

 Darn.  I'd forgotten about the strictness issue!

-- 
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] #6148: 63-tuples are not rejected when written using (, , , )

[GHC]

#6148: 63-tuples are not rejected when written using (,,,)
--+-
  Reporter:  guest|  Owner:  
  Type:  bug  | Status:  closed  
  Priority:  normal   |  Milestone:  
 Component:  Compiler |Version:  7.4.1   
Resolution:  fixed|   Keywords:  
Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
   Failure:  GHC accepts invalid program  | Difficulty:  Unknown 
  Testcase:  rename/should_fail/T6148 |  Blockedby:  
  Blocking:   |Related:  
--+-
Changes (by simonpj):

  * status:  new => closed
  * difficulty:  => Unknown
  * resolution:  => fixed
  * testcase:  => rename/should_fail/T6148


Comment:

 Thanks!

-- 
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] #6129: Failure when using promoted data family instances, again

[GHC]

#6129: Failure when using promoted data family instances, again
---+
  Reporter:  dreixel   |  Owner:  
  Type:  bug   | Status:  closed  
  Priority:  normal|  Milestone:  
 Component:  Compiler  |Version:  7.5 
Resolution:  fixed |   Keywords:  PolyKinds   
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:  polykinds/T6129   |  Blockedby:  
  Blocking:|Related:  
---+
Changes (by simonpj):

  * status:  new => closed
  * difficulty:  => Unknown
  * resolution:  => fixed
  * testcase:  => polykinds/T6129


-- 
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] #6137: Different behaviour between a GADT and a data family with regards to kind unification

[GHC]

#6137: Different behaviour between a GADT and a data family with regards to kind
unification
--+-
  Reporter:  dreixel  |  Owner:  
  Type:  bug  | Status:  closed  
  Priority:  normal   |  Milestone:  
 Component:  Compiler (Type checker)  |Version:  7.5 
Resolution:  fixed|   Keywords:  PolyKinds   
Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown | Difficulty:  Unknown 
  Testcase:  polykinds/T6137  |  Blockedby:  
  Blocking:   |Related:  
--+-
Changes (by simonpj):

  * status:  new => closed
  * difficulty:  => Unknown
  * resolution:  => fixed
  * testcase:  => polykinds/T6137


-- 
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] #6049: Kind variable generalization error in GADTs

[GHC]

#6049: Kind variable generalization error in GADTs
+---
  Reporter:  goldfire   |  Owner:  
  Type:  bug| Status:  closed  
  Priority:  normal |  Milestone:  
 Component:  Compiler (Type checker)|Version:  7.5 
Resolution:  fixed  |   Keywords:  PolyKinds   
Os:  Unknown/Multiple   |   Architecture:  Unknown/Multiple
   Failure:  GHC rejects valid program  | Difficulty:  Unknown 
  Testcase:  polykinds/T6049|  Blockedby:  
  Blocking: |Related:  
+---
Changes (by simonpj):

  * status:  new => closed
  * testcase:  => polykinds/T6049
  * resolution:  => fixed


-- 
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] #6093: Kind polymorphism fails with recursive type definition using different kind

[GHC]

#6093: Kind polymorphism fails with recursive type definition using different 
kind
+---
  Reporter:  Ashley Yakeley |  Owner:  
  Type:  bug| Status:  closed  
  Priority:  normal |  Milestone:  
 Component:  Compiler (Type checker)|Version:  7.4.1   
Resolution:  fixed  |   Keywords:  
Os:  Unknown/Multiple   |   Architecture:  Unknown/Multiple
   Failure:  GHC rejects valid program  | Difficulty:  Unknown 
  Testcase:  polykinds/T6093|  Blockedby:  
  Blocking: |Related:  
+---
Changes (by simonpj):

  * status:  new => closed
  * testcase:  => polykinds/T6093
  * resolution:  => fixed


-- 
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] #6135: Unboxed Booleans

[GHC]

#6135: Unboxed Booleans
-+--
Reporter:  benl  |   Owner:  
Type:  feature request   |  Status:  new 
Priority:  normal|   Milestone:  
   Component:  Compiler  | Version:  7.4.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by rl):

 Simon, your `&&` is strict in both arguments so it doesn't work.

 In general, I don't really think there is a lot to be gained here. You
 have to make sure that you (a) don't change the semantics of a program and
 (b) don't do too much unnecessary work. Let's take Ben's two examples:

 {{{
 case  x <# 0# || x >=# aWidth
 || y <# 0# || y >=# aHeight of
   True  -> ...
   False -> ...
 }}}

 {{{
 casex .<# 0# .||# x .>=# aWidth
.||# y .<# 0# .||# y .>=# aHeight of
  True#  -> ...
  False# -> ...
 }}}

 It is impossible to tell which of the two will be faster. If we expect `x
 <# 0` to hold most of the time, then the second one will be slower since
 it will be doing three unnecessary comparisons in most iterations for no
 benefit. On the other hand, if the condition doesn't hold most of the
 time, then the second one might be slightly faster.

 I fully agree that join points etc. can be very annoying, 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] #6049: Kind variable generalization error in GADTs

[GHC]

#6049: Kind variable generalization error in GADTs
+---
Reporter:  goldfire |   Owner:  
 
Type:  bug  |  Status:  new 
 
Priority:  normal   |   Milestone:  
 
   Component:  Compiler (Type checker)  | Version:  7.5 
 
Keywords:  PolyKinds|  Os:  Unknown/Multiple
 
Architecture:  Unknown/Multiple | Failure:  GHC rejects valid 
program
  Difficulty:  Unknown  |Testcase:  
 
   Blockedby:   |Blocking:  
 
 Related:   |  
+---

Comment(by simonpj@…):

 commit c91172004f2a5a6bf201b418c32c2d640ee34049
 {{{
 Author: Simon Peyton Jones 
 Date:   Thu Jun 7 12:09:22 2012 +0100

 Support polymorphic kind recursion

 This is (I hope) the last major patch for kind polymorphism.
 The big new feature is polymorphic kind recursion when you
 supply a complete kind signature for a type constructor.
 (I've documented it in the user manual too.)

 This fixes Trac #6137, #6093, #6049.

 The patch also makes type/data families less polymorphic by default.
data family T a
 now defaults to T :: * -> *
 If you want T :: forall k. k -> *, use
data family T (a :: k)

 This defaulting to * is done whenever there is a
 "complete, user-specified kind signature", something that is
 carefully defined in the user manual.

 Hurrah!

  compiler/typecheck/TcBinds.lhs  |3 +-
  compiler/typecheck/TcClassDcl.lhs   |   49 
  compiler/typecheck/TcHsType.lhs |   50 ++--
  compiler/typecheck/TcInstDcls.lhs   |  106 +
  compiler/typecheck/TcRnDriver.lhs   |   66 ---
  compiler/typecheck/TcRnTypes.lhs|   31 ++
  compiler/typecheck/TcSplice.lhs |3 +-
  compiler/typecheck/TcTyClsDecls.lhs |  204
 ++-
  docs/users_guide/flags.xml  |5 +-
  docs/users_guide/glasgow_exts.xml   |  228
 ++-
  10 files changed, 400 insertions(+), 345 deletions(-)
 }}}

-- 
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] #6093: Kind polymorphism fails with recursive type definition using different kind

[GHC]

#6093: Kind polymorphism fails with recursive type definition using different 
kind
+---
Reporter:  Ashley Yakeley   |   Owner:  
 
Type:  bug  |  Status:  new 
 
Priority:  normal   |   Milestone:  
 
   Component:  Compiler (Type checker)  | Version:  7.4.1   
 
Keywords:   |  Os:  Unknown/Multiple
 
Architecture:  Unknown/Multiple | Failure:  GHC rejects valid 
program
  Difficulty:  Unknown  |Testcase:  
 
   Blockedby:   |Blocking:  
 
 Related:   |  
+---

Comment(by simonpj@…):

 commit c91172004f2a5a6bf201b418c32c2d640ee34049
 {{{
 Author: Simon Peyton Jones 
 Date:   Thu Jun 7 12:09:22 2012 +0100

 Support polymorphic kind recursion

 This is (I hope) the last major patch for kind polymorphism.
 The big new feature is polymorphic kind recursion when you
 supply a complete kind signature for a type constructor.
 (I've documented it in the user manual too.)

 This fixes Trac #6137, #6093, #6049.

 The patch also makes type/data families less polymorphic by default.
data family T a
 now defaults to T :: * -> *
 If you want T :: forall k. k -> *, use
data family T (a :: k)

 This defaulting to * is done whenever there is a
 "complete, user-specified kind signature", something that is
 carefully defined in the user manual.

 Hurrah!

  compiler/typecheck/TcBinds.lhs  |3 +-
  compiler/typecheck/TcClassDcl.lhs   |   49 
  compiler/typecheck/TcHsType.lhs |   50 ++--
  compiler/typecheck/TcInstDcls.lhs   |  106 +
  compiler/typecheck/TcRnDriver.lhs   |   66 ---
  compiler/typecheck/TcRnTypes.lhs|   31 ++
  compiler/typecheck/TcSplice.lhs |3 +-
  compiler/typecheck/TcTyClsDecls.lhs |  204
 ++-
  docs/users_guide/flags.xml  |5 +-
  docs/users_guide/glasgow_exts.xml   |  228
 ++-
  10 files changed, 400 insertions(+), 345 deletions(-)
 }}}

-- 
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] #6137: Different behaviour between a GADT and a data family with regards to kind unification

[GHC]

#6137: Different behaviour between a GADT and a data family with regards to kind
unification
--+-
 Reporter:  dreixel   |  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Component:  Compiler (Type checker)
  Version:  7.5   |   Keywords:  PolyKinds  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple   
  Failure:  None/Unknown  |   Testcase: 
Blockedby:|   Blocking: 
  Related:|  
--+-

Comment(by simonpj@…):

 commit c91172004f2a5a6bf201b418c32c2d640ee34049
 {{{
 Author: Simon Peyton Jones 
 Date:   Thu Jun 7 12:09:22 2012 +0100

 Support polymorphic kind recursion

 This is (I hope) the last major patch for kind polymorphism.
 The big new feature is polymorphic kind recursion when you
 supply a complete kind signature for a type constructor.
 (I've documented it in the user manual too.)

 This fixes Trac #6137, #6093, #6049.

 The patch also makes type/data families less polymorphic by default.
data family T a
 now defaults to T :: * -> *
 If you want T :: forall k. k -> *, use
data family T (a :: k)

 This defaulting to * is done whenever there is a
 "complete, user-specified kind signature", something that is
 carefully defined in the user manual.

 Hurrah!

  compiler/typecheck/TcBinds.lhs  |3 +-
  compiler/typecheck/TcClassDcl.lhs   |   49 
  compiler/typecheck/TcHsType.lhs |   50 ++--
  compiler/typecheck/TcInstDcls.lhs   |  106 +
  compiler/typecheck/TcRnDriver.lhs   |   66 ---
  compiler/typecheck/TcRnTypes.lhs|   31 ++
  compiler/typecheck/TcSplice.lhs |3 +-
  compiler/typecheck/TcTyClsDecls.lhs |  204
 ++-
  docs/users_guide/flags.xml  |5 +-
  docs/users_guide/glasgow_exts.xml   |  228
 ++-
  10 files changed, 400 insertions(+), 345 deletions(-)
 }}}

-- 
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] #6148: 63-tuples are not rejected when written using (, , , )

[GHC]

#6148: 63-tuples are not rejected when written using (,,,)
-+--
 Reporter:  guest|  Owner:  
 Type:  bug  | Status:  new 
 Priority:  normal   |  Component:  Compiler
  Version:  7.4.1|   Keywords:  
   Os:  Unknown/Multiple |   Architecture:  Unknown/Multiple
  Failure:  GHC accepts invalid program  |   Testcase:  
Blockedby:   |   Blocking:  
  Related:   |  
-+--

Comment(by simonpj@…):

 commit fe0ae8d546ec91dab29d1456db269d9e7b010971
 {{{
 Author: Simon Peyton Jones 
 Date:   Thu Jun 7 14:04:20 2012 +0100

 Complain if we use a tuple tycon or data-con that is too big

 Previously (Trac #6148) we were only complaining for the
 distfix syntax (a,b,c).

  compiler/rename/RnEnv.lhs |   25 +++--
  compiler/rename/RnPat.lhs |   10 --
  2 files changed, 23 insertions(+), 12 deletions(-)
 }}}

-- 
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] #6135: Unboxed Booleans

[GHC]

#6135: Unboxed Booleans
-+--
Reporter:  benl  |   Owner:  
Type:  feature request   |  Status:  new 
Priority:  normal|   Milestone:  
   Component:  Compiler  | Version:  7.4.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by simonpj):

  * difficulty:  => Unknown


Comment:

 Good point.  I had not fully grokked that reason for having unboxed
 `Bool#`.  See also #605.

 However I don't think it would be a good plan to define
 {{{
 data Bool = B# Bool#
 }}}
 For one thing, the definition of `Bool` is in the language spec.  Well I
 suppose we could define
 {{{
 fromBool :: Bool -> Bool#
 toBool   :: Bool# -> Bool
 }}}
 (Actually these already exist, more or less, in the form of `tagToEnum#`
 and `dataToTag#`.)

 I suppose we could then define `not`, `(&&)` etc thus:
 {{{
 not :: Bool -> Bool
 not b = toBool (not# (fromBool b))

 (&&) :: Bool -> Bool -> Bool
 a && b = toBool (and# (fromBool a) (fromBool b))
 }}}
 What would happen to optimisations?  As thing stand we get
 {{{
 not (not x)

 = { inline not, twice }
   case (case x of { T -> F; F -> T }) of { T -> F; F -> T }

 = { case of case transformation }
   case x of
  T -> case F of { T -> F; F -> T }
  F -> case T of { T -> F; F -> T }

 = { simplify cases }
   case x of
  T -> T
  F -> F

 = { case of identity }
   x
 }}}
 (And then we simplify to just `x`, but that's a separate matter.)  To get
 this behaviour with the new stuff we would presumably say:
 {{{
 not (not x)

 = { inline not, twice }
   toBool (not# (fromBool (toBool (not# (fromBool x)

 = { RULE fromBool (toBool v) = v }
   toBool (not# (not# (fromBool x)))

 = { RULE not# (not# v) = v }
   toBool (fromBool x)

 = { RULE fromBool (toBool v) = v }
   x
 }}}
 If anything this seems simpler.  We'd also need constant folding stuff
 like
 {{{
case x of
  True -> (fromBool x)
 ===>
case x of
  True -> True#
 }}}
 but that should not be hard.

 I was not optimistic when I started writing this, but now I've got this
 far it does actually look plausible.  It is certainly true that
 conditionals with a lot of conditions can generate an absolute rats-nest
 of join points -- and that in turn can inhibt inlining.  So the change
 would help that too.

 I suppose that `Bool#` might be better spelt `Word1#`.

 Can anyone think of any other wrinkles to consider?

 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

[GHC] #6149: ghc-7.4.2 tests for profasm seg-fault under solaris

[GHC]

#6149: ghc-7.4.2 tests for profasm seg-fault under solaris
---+
 Reporter:  maeder |  Owner:  
 Type:  bug| Status:  new 
 Priority:  normal |  Component:  Compiler
  Version:  7.4.2-rc1  |   Keywords:  
   Os:  Solaris|   Architecture:  x86 
  Failure:  Runtime crash  |   Testcase:  
Blockedby: |   Blocking:  
  Related: |  
---+
 I've compiled
 http://www.haskell.org/ghc/dist/stable/dist/ghc-7.4.2-src.tar.bz2 from
 05-Jun-2012 under x86 solaris.

 The results of running the testsuite will be attached.
 Can these failures be observed on kgardas-opensolaris-x86-head, 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] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8

[GHC]

#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
-+--
  Reporter:  dylukes |  Owner:  
  
  Type:  bug | Status:  closed  
  
  Priority:  high|  Milestone:  7.4.2   
  
 Component:  Runtime System  |Version:  7.4.1   
  
Resolution:  worksforme  |   Keywords:  rts, strange closure, internal 
error, os x
Os:  MacOS X |   Architecture:  x86_64 (amd64)  
  
   Failure:  Runtime crash   | Difficulty:  Unknown 
  
  Testcase:  |  Blockedby:  
  
  Blocking:  |Related:  
  
-+--
Changes (by simonmar):

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


Comment:

 I just did a validate using an existing installation of GHC 7.0.3 on OS X
 10.8 DP3 with XCode 4.4 DP5.  There are a few test failures that need to
 be cleaned up, but the crashes now seem to be gone.

 So I presume this was a bug in the linker after all, and Apple fixed it.

-- 
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] #5527: mkTopLevEnv: not interpreted

[GHC]

#5527: mkTopLevEnv: not interpreted
---+
  Reporter:  cdsmith   |  Owner:  pcapriotti
  Type:  bug   | Status:  closed
  Priority:  normal|  Milestone:  7.6.1 
 Component:  GHC API   |Version:  7.3   
Resolution:  fixed |   Keywords:
Os:  Linux |   Architecture:  x86   
   Failure:  None/Unknown  | Difficulty:  Unknown   
  Testcase:|  Blockedby:
  Blocking:|Related:
---+
Changes (by pcapriotti):

  * status:  patch => closed
  * resolution:  => fixed


-- 
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] #5527: mkTopLevEnv: not interpreted

[GHC]

#5527: mkTopLevEnv: not interpreted
+---
Reporter:  cdsmith  |   Owner:  pcapriotti  
Type:  bug  |  Status:  patch   
Priority:  normal   |   Milestone:  7.6.1   
   Component:  GHC API  | Version:  7.3 
Keywords:   |  Os:  Linux   
Architecture:  x86  | Failure:  None/Unknown
  Difficulty:  Unknown  |Testcase:  
   Blockedby:   |Blocking:  
 Related:   |  
+---

Comment(by p.capriotti@…):

 commit b8e0074794e085fdc2271f39aec92a0b472c6b46
 {{{
 Author: Paolo Capriotti 
 Date:   Wed Jun 6 15:24:21 2012 +0100

 Better error messages for setContext (#5527).

 Make InteractiveEval.setContext throw a clearer exception when it is
 asked to add an IIModule which is not a home module or is not
 interpreted.

  compiler/main/InteractiveEval.hs |   35
 +++
  1 files changed, 23 insertions(+), 12 deletions(-)
 }}}

-- 
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] #4968: openTempFile fails on Windows if a directory exists with the file name it tries

[GHC]

#4968: openTempFile fails on Windows if a directory exists with the file name it
tries
---+
Reporter:  ganesh  |   Owner:  pcapriotti 
Type:  bug |  Status:  new
Priority:  high|   Milestone:  7.4.2  
   Component:  libraries/base  | Version:  7.0.1  
Keywords:  |  Os:  Windows
Architecture:  x86_64 (amd64)  | Failure:  Incorrect result at runtime
  Difficulty:  Unknown |Testcase: 
   Blockedby:  |Blocking: 
 Related:  |  
---+
Changes (by pcapriotti):

  * owner:  bos => pcapriotti


-- 
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] #5527: mkTopLevEnv: not interpreted

[GHC]

#5527: mkTopLevEnv: not interpreted
+---
Reporter:  cdsmith  |   Owner:  pcapriotti  
Type:  bug  |  Status:  patch   
Priority:  normal   |   Milestone:  7.6.1   
   Component:  GHC API  | Version:  7.3 
Keywords:   |  Os:  Linux   
Architecture:  x86  | Failure:  None/Unknown
  Difficulty:  Unknown  |Testcase:  
   Blockedby:   |Blocking:  
 Related:   |  
+---

Comment(by simonmar):

 pcapriotti: your patch looks ok to me, go ahead.

-- 
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:  low   |   Milestone:  7.6.1   
   Component:  Compiler  | Version:  6.12.3  
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by simonpj):

 Levent, you said:

 > However, to put things in perspective, removal of `mdo` isn't really
 going to impact a lot of folks. Those who need it can clearly work around
 the issues. So, maybe Ross has the right wisdom in suggesting to go with
 maximal simplicity.

 That sounds like (C) or (D).  But now you say (B) which is what I thought
 you wanted.  Fine!

 I don't care much whether or not `rec` is rejected inside `mdo`.  I don't
 see a compelling reason for doing so, and it's more work.

 Would you like to implement it?

-- 
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:  low   |   Milestone:  7.6.1   
   Component:  Compiler  | Version:  6.12.3  
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by lerkok):

 Simon: Regarding your question why segmentation was ever implemented in
 the first place, here's a concrete example that'll hopefully demonstrate
 why segmentation is an essential part of monadic recursion.

 Consider the following simple function:

 {{{
 produce :: [Int] -> IO [Int]
 produce xs = return $ take 10 [1+x | x <- xs]
 }}}

 Clearly `produce` doesn't need to be in the IO monad, but that's besides
 the point. The crucial thing is
 that it represents some function doing IO before returning a result. (In a
 more realistic instance, for
 example, it can read the constant `10` it uses in the call to `take` from
 a configuration file; or perform
 some other similar IO action to implement some other behavior.)

 Let's also imagine a caller to this function, of the following form:

 {{{
 run :: IO [Int]
 run = do rec xs <- produce (1:xs)
  return xs
 }}}

 For instance, `run` can be used to implement a recurrence based algorithm,
 by passing a variant of its
 result to itself. (Think Fibonacci, Hamming codes, etc; for example, where
 the computation of the "next"
 element requires some monadic action.)

 The above code will work just as expected today in GHC, with `run`
 evaluating to the list `[2..11]`. So far, everything is just fine.

 Now, consider the following version of `run`, which simply prints the
 length of the list before
 returning its result, but it is otherwise equivalent to `run` above:

 {{{
 run2 :: IO [Int]
 run2 = do rec xs <- produce (1:xs)
   print $ length xs
   return xs
 }}}

 For instance, I could imagine adding that `print` statement as part of
 debugging my code; or doing some
 other useful computation based on the result of the call to `produce`. If
 you execute `run2` today in
 GHC, you'll find that it'll work just as you expect: It'll first print
 `10`, and then return the
 list `[2..11]`.

 '''Here's the problem:''' If you change the translation of `rec` so that
 it no longer performs segmentation, then
 `run2` will *diverge*. Why? Because the trailing computation in printing
 the length of the final list
 will interfere with the recursive computation. In more fancy terms, since
 the `mfix` for the IO monad (the good old fixIO) does not satisfy the
 right-shrinking law, the non-recursive computation in the `mfix` loop
 cannot be lifted out. This is a fundamental limitation of the IO monad:
 There's no `mfix` for it that satisfies the right-shrinking law. (Of
 course, IO is just one example, many other monads have the same issue.)

 So, what does this mean? In my mind, it really means two things:

   * The promised correspondence that

  {{{
mdo ...
e
  }}}

   is the same as

  {{{
 do rec ...
e
  }}}

   only holds provided the `rec` translation performs segmentation. If we
 don't do segmentation, then the correspondence is no longer valid as
 exemplified above.

* Segmentation is really an essential part of the `mdo` (or `do` `rec`)
 semantics, if I write

 {{{
do rec xs <- produce (1:xs)
   print $ length xs
   return xs
 }}}
  Whether I keep the `print` in there or not should change anything. But if
 you do not do segmentation, the presence of `print` '''will''' change the
 semantics, causing it to diverge. (Imagine how awkward it would be to
 insert a "debugging" printf inside your `mdo` or `do` `rec` block, only to
 have it diverge all of a sudden.)

 I'm hoping the above example will convince us that segmentation is an
 essential feature of recursive monadic bindings.  Based on this, I think
 proposal B provides a good compromise since it brings back `mdo` with its
 original intent, while keeping `rec` simple.

 To summarize, I'd humbly suggest we should do a minor variant of your
 proposal B:

* Bring back `mdo` with segmentation (as was originally implemented in
 GHC)
* Change `rec` so it does ''not'' do segmentation
* Furthermore, allow `rec` only inside an immediately enclosing `do`
 block; syntactically rejecting it inside an `mdo`.

 I think this proposal is in the spirit of the original work on recursive
 monadic bindings, while also keeping `rec` quite simp

Re: [GHC] #4148: improve new recursive do syntax

[GHC]

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

Comment(by simonpj):

 Now I really am confused.  Here's the design space
 {{{
  mdo recrec
 (with  without  with
  segmentation)segmentationsegmentation   What
   --
   --   YES   (A) GHC now
  YES  YES  - (B) SPJ proposal
   -   YES  - (C) Ross proposal?
   --   - (D) Levent proposal?
 }}}
 I proposed (B). Have I understood Ross and Levent's propsals aright?  I
 thought segmentation was important?  Why did we write all that code to put
 it in if it's hardly useful?

-- 
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