Windows breakage

2014-06-11 Thread Simon Peyton Jones
Stefan, Guys
This commit breaks the Windows build (ie my laptop)

commit 9fd507e5758f4141ac2619f0db57136bcab035c6

Author: Sergei Trofimovich sly...@gentoo.org

Date:   Fri May 23 23:58:06 2014 +0300



Raise exceptions when blocked in bad FDs (fixes Trac #4934)
The breakage is this:

C:/code/HEAD/rts/dist/build/libHSrts.a(RtsStartup.o):RtsStartup.c:(.text+0x2aa):
 undefined reference to `base_GHCziEventziThread_blockedOnBadFD_closure'
The reason is, I think that that this line in RtsStartup.c should be inside the 
guard #ifndef mingw32_HOST_OS

getStablePtr((StgPtr)blockedOnBadFD_closure);
I'd do that myself but I am not confident that the fix is correct; and I would 
like to add a comment to explain why the getStablePtr is non-windows-only.
Can someone do this, please?
Thanks
Simon

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


Re: HEADS-UP: diagrams does not compile with HEAD (regressions)

2014-06-11 Thread Gabor Greif
Hello Jan,

thanks for clarifying this! As it is biting various libraries, it
would warrant to add some blurb into the release notes. Or does an
entry exist already?

Cheers,

Gabor

On 6/10/14, Jan Stolarek jan.stola...@p.lodz.pl wrote:
 Reid is correct. This is a result of fixing #8883. I agree that printing the
 inferred signature
 sounds like a good idea.

 Janek

 Dnia wtorek, 10 czerwca 2014, Reid Barton napisał:
 I expect this is a result of
 https://ghc.haskell.org/trac/ghc/ticket/8883,
 but even so it's not clear to me whether the error is correct. It would
 be
 nice if GHC printed the type it inferred for succ' in this kind of
 situation.

 Regards,
 Reid Barton

 On Tue, Jun 10, 2014 at 7:55 AM, Gabor Greif ggr...@gmail.com wrote:
  Devs,
 
  as of recently GHC HEAD stopped building the diagrams library. Several
  prerequisite libs also fail to compile. A specific error message
  appears in an attoparsec issue
  https://github.com/bos/attoparsec/issues/67, for which I have
  submitted a workaround. But as Herbert cautiously points out, this
  could be a recent GHC bug surfacing.
 
  The symptoms of the bug seem to be that GHC complains about the usage
  of (~) type equality operation, but there is no reference to that type
  operator in the source code. To work around the problem it suffices to
  add -XGADTs or -XTypeFamilies.
 
  Does this ring any bells? Can automatized tests catch such things in
  the
  future?
 
  Cheers,
 
  Gabor
  ___
  ghc-devs mailing list
  ghc-devs@haskell.org
  http://www.haskell.org/mailman/listinfo/ghc-devs



___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


Re: HEADS-UP: diagrams does not compile with HEAD (regressions)

2014-06-11 Thread Jan Stolarek
No, there is no mention of it in the release notes. My bad. I'm putting it on 
my TODO list.

Janek

Dnia środa, 11 czerwca 2014, Gabor Greif napisał:
 Hello Jan,

 thanks for clarifying this! As it is biting various libraries, it
 would warrant to add some blurb into the release notes. Or does an
 entry exist already?

 Cheers,

 Gabor

 On 6/10/14, Jan Stolarek jan.stola...@p.lodz.pl wrote:
  Reid is correct. This is a result of fixing #8883. I agree that printing
  the inferred signature
  sounds like a good idea.
 
  Janek
 
  Dnia wtorek, 10 czerwca 2014, Reid Barton napisał:
  I expect this is a result of
  https://ghc.haskell.org/trac/ghc/ticket/8883,
  but even so it's not clear to me whether the error is correct. It would
  be
  nice if GHC printed the type it inferred for succ' in this kind of
  situation.
 
  Regards,
  Reid Barton
 
  On Tue, Jun 10, 2014 at 7:55 AM, Gabor Greif ggr...@gmail.com wrote:
   Devs,
  
   as of recently GHC HEAD stopped building the diagrams library. Several
   prerequisite libs also fail to compile. A specific error message
   appears in an attoparsec issue
   https://github.com/bos/attoparsec/issues/67, for which I have
   submitted a workaround. But as Herbert cautiously points out, this
   could be a recent GHC bug surfacing.
  
   The symptoms of the bug seem to be that GHC complains about the usage
   of (~) type equality operation, but there is no reference to that type
   operator in the source code. To work around the problem it suffices to
   add -XGADTs or -XTypeFamilies.
  
   Does this ring any bells? Can automatized tests catch such things in
   the
   future?
  
   Cheers,
  
   Gabor
   ___
   ghc-devs mailing list
   ghc-devs@haskell.org
   http://www.haskell.org/mailman/listinfo/ghc-devs


___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


Re: Windows breakage (+patch)

2014-06-11 Thread Sergei Trofimovich
On Wed, 11 Jun 2014 21:35:57 +0300
Sergei Trofimovich sly...@gentoo.org wrote:

 On Wed, 11 Jun 2014 08:18:30 +
 Simon Peyton Jones simo...@microsoft.com wrote:
 
  Stefan, Guys
  This commit breaks the Windows build (ie my laptop)
  
  commit 9fd507e5758f4141ac2619f0db57136bcab035c6
  
  Author: Sergei Trofimovich sly...@gentoo.org
  
  Date:   Fri May 23 23:58:06 2014 +0300
  
  
  
  Raise exceptions when blocked in bad FDs (fixes Trac #4934)
  The breakage is this:
  
  C:/code/HEAD/rts/dist/build/libHSrts.a(RtsStartup.o):RtsStartup.c:(.text+0x2aa):
   undefined reference to `base_GHCziEventziThread_blockedOnBadFD_closure'
  The reason is, I think that that this line in RtsStartup.c should be inside 
  the guard #ifndef mingw32_HOST_OS
  
  getStablePtr((StgPtr)blockedOnBadFD_closure);
  I'd do that myself but I am not confident that the fix is correct; and I 
  would like to add a comment to explain why the getStablePtr is 
  non-windows-only.
  Can someone do this, please?
 
 Oh, I've missed the fact GHC.Event.Thread in a non-windows thing.
 The whole patch was for posix-only platform, but i tried to export
 that exception for all platforms.
 
 CCed Simon M.
 
 There is 2 routes:
 a) move an exception a common module to all platforms.
 For example to Foreign.C.Error (I've started to prepare a patch)

To avoid import loops and make things clear I've moved it to
GHC.Exception.RTS
(other from-rts exceptions can be pushded there as well)

Patch is in attach. Please review.

Thank you!

-- 

  Sergei
From 9fd22821be997c5b75b84c3528351e8dc678882f Mon Sep 17 00:00:00 2001
From: Sergei Trofimovich sly...@gentoo.org
Date: Wed, 11 Jun 2014 22:18:41 +0300
Subject: [PATCH] rts: fix linkage on windows (missing blockedOnBadFD_closure)

commit 9fd507e5758f4141ac2619f0db57136bcab035c6 declared
to RTS exception object, but defined it in UNIX-specific
module GHC.Event.Thread.

It led to linkage error:
C:/code/HEAD/rts/dist/build/libHSrts.a(RtsStartup.o):RtsStartup.c:(.text+0x2aa):
undefined reference to `base_GHCziEventziThread_blockedOnBadFD_closure'

Fixed by moving exception object to separate module GHC.Exception.RTS.

Reported-by: Simon Peyton Jones simo...@microsoft.com
Signed-off-by: Sergei Trofimovich sly...@gentoo.org
---
 libraries/base/GHC/Event/Thread.hs  |  7 +--
 libraries/base/GHC/Exception/RTS.hs | 25 +
 libraries/base/base.cabal   |  1 +
 rts/Prelude.h   |  4 ++--
 rts/package.conf.in |  4 ++--
 rts/win32/libHSbase.def |  2 +-
 6 files changed, 32 insertions(+), 11 deletions(-)
 create mode 100644 libraries/base/GHC/Exception/RTS.hs

diff --git a/libraries/base/GHC/Event/Thread.hs b/libraries/base/GHC/Event/Thread.hs
index 6e991bf..eb6b6c7 100644
--- a/libraries/base/GHC/Event/Thread.hs
+++ b/libraries/base/GHC/Event/Thread.hs
@@ -12,10 +12,9 @@ module GHC.Event.Thread
 , closeFdWith
 , threadDelay
 , registerDelay
-, blockedOnBadFD -- used by RTS
 ) where
 
-import Control.Exception (finally, SomeException, toException)
+import Control.Exception (finally)
 import Control.Monad (forM, forM_, sequence_, zipWithM, when)
 import Data.IORef (IORef, newIORef, readIORef, writeIORef)
 import Data.List (zipWith3)
@@ -116,10 +115,6 @@ threadWait evt fd = mask_ $ do
 then ioError $ errnoToIOError threadWait eBADF Nothing Nothing
 else return ()
 
--- used at least by RTS in 'select()' IO manager backend
-blockedOnBadFD :: SomeException
-blockedOnBadFD = toException $ errnoToIOError awaitEvent eBADF Nothing Nothing
-
 threadWaitSTM :: Event - Fd - IO (STM (), IO ())
 threadWaitSTM evt fd = mask_ $ do
   m - newTVarIO Nothing
diff --git a/libraries/base/GHC/Exception/RTS.hs b/libraries/base/GHC/Exception/RTS.hs
new file mode 100644
index 000..9892e6e
--- /dev/null
+++ b/libraries/base/GHC/Exception/RTS.hs
@@ -0,0 +1,25 @@
+-
+-- |
+-- Module  :  GHC.Exception
+-- Copyright   :  (c) The University of Glasgow, 1998-2002
+-- License :  see libraries/base/LICENSE
+-- 
+-- Maintainer  :  cvs-...@haskell.org
+-- Stability   :  internal
+-- Portability :  non-portable (GHC extensions)
+--
+-- Exceptions thrown by C RTS code.
+--
+-
+
+module GHC.Exception.RTS
+(
+blockedOnBadFD
+) where
+
+import Control.Exception
+import Foreign.C.Error
+
+-- used at least by RTS in 'select()' IO manager backend
+blockedOnBadFD :: SomeException
+blockedOnBadFD = toException $ errnoToIOError awaitEvent eBADF Nothing Nothing
diff --git a/libraries/base/base.cabal b/libraries/base/base.cabal
index e56724c..8537843 100644
--- a/libraries/base/base.cabal
+++ b/libraries/base/base.cabal
@@ -276,6 +276,7 @@ Library
 Control.Monad.ST.Imp
 Control.Monad.ST.Lazy.Imp
 Foreign.ForeignPtr.Imp
+