RE: New official language extension tokens for GHC 7.8.1

[Simon Peyton-Jones]

Ian, is there any documentation of what these three things were doing? A wiki 
page?  If not, should we revert them all out again?

We don't want to leave experiments that have no active sponsor in the code.

On the other hand, you are wanting to pursue it, that's great. 

Simon

| -Original Message-
| From: Ian Lynagh [mailto:ig...@earth.li]
| Sent: 03 September 2013 22:16
| To: Simon Peyton-Jones
| Cc: Herbert Valerio Riedel; ghc-devs
| Subject: Re: New official language extension tokens for GHC 7.8.1
| 
| On Mon, Sep 02, 2013 at 07:48:58AM +, Simon Peyton-Jones wrote:
|  | Which of the language extensions listed in
| `expectedGhcOnlyExtensions`
|  | are deemed ready for public consumption in GHC 7.8.1,
| 
|  Good question.  Here's the list with my comments. We need input from
| Ian. on
| 
|  RelaxedLayout
|  AlternativeLayoutRule
|  AlternativeLayoutRuleTransitional
|I have no idea about these three.
| 
| AlternativeLayoutRule* aren't ready. I'm afraid I can't even remember
| what RelaxedLayout does OTTOMH.
| 
| 
| Thanks
| Ian


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

Unicode quotes

[山本和彦]

Hello,

GHCi of GHC 7.7 use Unicode quote marks instead of ASCII quote marks.
Why do you guys decide this behavior change? I'm just curious.

--Kazu

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

Re: New official language extension tokens for GHC 7.8.1

[Herbert Valerio Riedel]

On 2013-09-03 at 23:15:43 +0200, Ian Lynagh wrote:

[...]

 I'm afraid I can't even remember what RelaxedLayout does OTTOMH.

fwiw, here's the commit that introduced it:

http://git.haskell.org/?p=ghc.git;a=commitdiff;h=9a82b1ffa35fa4c3927c66a1037a37d436cf6aac

...and moreover, you disabled it by default in

http://git.haskell.org/?p=ghc.git;a=commitdiff;h=1bed452fb7c3b5c55c734920a26c0e6a35298deb


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

RE: More windows woe

[Edward Z. Yang]

I got my hands on a Windows build box, so I'll also go and see if
I can get a build working on Windows.

Excerpts from Simon Peyton-Jones's message of Tue Sep 03 07:33:32 -0700 2013:
 Simon Marlow: please help!
 At the moment windows builds are hosed, which is a Bad Situation.
 
 Actually it turns out that what want is
 
   debugBelch(Checking whether to unload %S\n, oc-fileName));
 
 That is, use %S rather than %s as format specifier for wide chars.
 
 Sadly, this works on Windows, but not on Linux:
 rts/CheckUnload.c:260:13:
  error: format ‘%S’ expects argument of type ‘wchar_t *’, but argument 2 
 has type ‘pathchar *’ [-Werror=format]
 
 
 So what I need guidance on, please!, is what the approved way to deal with 
 this is.  I suppose that I could identify each use of %s on a filepath and say
 
 #ifdef mingw32_HOST_OS
   debugBelch(Checking whether to unload %S\n, oc-fileName));
 #else
   debugBelch(Checking whether to unload %s\n, oc-fileName));
 #endif
 
 But that seems deeply unsatisfactory doesn't it?
 
 If not that, then what?
 
 
 Simon
 
 | -Original Message-
 | From: Edward Z. Yang [mailto:ezy...@mit.edu]
 | Sent: 28 August 2013 20:59
 | To: Simon Peyton-Jones
 | Cc: ghc-devs@haskell.org
 | Subject: Re: More windows woe
 | 
 | My guess is the printf's need to be replaced with swprintf's.
 | 
 | Edward
 | 
 | Excerpts from Simon Peyton-Jones's message of Wed Aug 28 01:25:26 -0700
 | 2013:
 |  OK, so now my windows build is getting further, but it now falls over
 | here.  This one looks more straightforward!  Can anyone help?
 | 
 |  Simon
 | 
 |  inplace/bin/ghc-stage1.exe -optc-Werror -optc-Wall -optc-Wall -optc-
 | Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-
 | Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-
 | Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-
 | Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-
 | Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-
 | ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-
 | DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -
 | optc-fomit-frame-pointer -optc-fno-omit-frame-pointer -optc-g -optc-O0 -
 | optc-DRtsWay=\rts_debug\ -static -optc-DDEBUG -ticky -DTICKY_TICKY  -
 | H32m -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist -
 | Iincludes/dist-derivedconstants/header -Iincludes/dist-
 | ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name
 | rts -dcmm-lint  -i -irts -irts/dist/build -irts/dist/build/autogen -
 | Irts/dist/build -Irts/dist/build/autogen   -O2 -O0-c
 | rts/CheckUnload.c -o rts/dist/build/CheckUnload.debug_o
 |  cc1.exe: warnings being treated as errors
 |  rts\CheckUnload.c: In function 'checkUnload':
 | 
 |  rts\CheckUnload.c:257:7:
 |   error: format '%s' expects type 'char *', but argument 2 has type
 | 'pathchar *'
 | 
 |  rts\CheckUnload.c:293:11:
 |   error: format '%s' expects type 'char *', but argument 2 has type
 | 'pathchar *'
 | 
 |  rts\CheckUnload.c:297:11:
 |   error: format '%s' expects type 'char *', but argument 2 has type
 | 'pathchar *'
 |  bash-3.1$

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

Re: RE: More windows woe

[Edward Z. Yang]

I think this is reasonable, with the added caveat that
the macros should be placed in includes/rts/Linker.h, because that is
where pathchar is defined.  So how about something like:

diff --git a/includes/rts/Linker.h b/includes/rts/Linker.h
index e900e85..871b8cd 100644
--- a/includes/rts/Linker.h
+++ b/includes/rts/Linker.h
@@ -16,8 +16,10 @@

 #if defined(mingw32_HOST_OS)
 typedef wchar_t pathchar;
+#define FMT_PATH %S
 #else
 typedef charpathchar;
+#define FMT_PATH %s
 #endif

 /* initialize the object linker */
diff --git a/rts/CheckUnload.c b/rts/CheckUnload.c
index a758b06..8dc8fdc 100644
--- a/rts/CheckUnload.c
+++ b/rts/CheckUnload.c
@@ -254,7 +254,7 @@ void checkUnload (StgClosure *static_objects)

   // Mark every unloadable object as unreferenced initially
   for (oc = unloaded_objects; oc; oc = oc-next) {
-  IF_DEBUG(linker, debugBelch(Checking whether to unload %s\n,
+  IF_DEBUG(linker, debugBelch(Checking whether to unload  FMT_PATH \n,
   oc-fileName));
   oc-referenced = rtsFalse;
   }
@@ -290,11 +290,11 @@ void checkUnload (StgClosure *static_objects)
   } else {
   prev-next = oc-next;
   }
-  IF_DEBUG(linker, debugBelch(Unloading object file %s\n,
+  IF_DEBUG(linker, debugBelch(Unloading object file  FMT_PATH \n,
   oc-fileName));
   freeObjectCode(oc);
   } else {
-  IF_DEBUG(linker, debugBelch(Object file still in use: %s\n,
+  IF_DEBUG(linker, debugBelch(Object file still in use:  FMT_PATH 
\n,
   oc-fileName));
   }
   }
diff --git a/rts/Linker.c b/rts/Linker.c
index 6490242..4f0a1c4 100644
--- a/rts/Linker.c
+++ b/rts/Linker.c
@@ -2790,7 +2790,7 @@ unloadObj( pathchar *path )

 initLinker();

-IF_DEBUG(linker, debugBelch(unloadObj: %s\n, path));
+IF_DEBUG(linker, debugBelch(unloadObj:  FMT_PATH \n, path));

 prev = NULL;
 for (oc = objects; oc; prev = oc, oc = next) {

Excerpts from Jost Berthold's message of Tue Sep 03 12:56:03 -0700 2013:
  From: Simon Peyton-Jones simo...@microsoft.com
  To: Edward Z. Yang ezy...@mit.edu, Simon Marlow
  marlo...@gmail.com
  Cc: ghc-devs@haskell.org ghc-devs@haskell.org
  Subject: RE: More windows woe
  Message-ID:
  
  59543203684b2244980d7e4057d5fbc1485bb...@db3ex14mbxc308.europe.corp.microsoft.com
  
  Content-Type: text/plain; charset=utf-8
 
  Simon Marlow: please help!
  At the moment windows builds are hosed, which is a Bad Situation.
 
  Actually it turns out that what want is
 
 debugBelch(Checking whether to unload %S\n, oc-fileName));
 
  That is, use %S rather than %s as format specifier for wide chars.
 
  Sadly, this works on Windows, but not on Linux:
  rts/CheckUnload.c:260:13:
error: format ?%S? expects argument of type ?wchar_t *?, but argument 
  2 has type ?pathchar *? [-Werror=format]
 
 
  So what I need guidance on, please!, is what the approved way to deal with 
  this is.  I suppose that I could identify each use of %s on a filepath and 
  say
 
  #ifdef mingw32_HOST_OS
 debugBelch(Checking whether to unload %S\n, oc-fileName));
  #else
 debugBelch(Checking whether to unload %s\n, oc-fileName));
  #endif
 
  But that seems deeply unsatisfactory doesn't it?
 
  If not that, then what?
 
 
  Simon
 
 Similar code is in place to distinguish between 32-bit and 64-bit StgWords:
 
   grep -r -e FMT_Word includes/
 includes/stg/Types.h:#define FMT_Word32u
 includes/stg/Types.h:#define FMT_Word32lu
 includes/stg/Types.h:#define FMT_Word64lu
 includes/stg/Types.h:#define FMT_Word64llu
 includes/stg/Types.h:#define FMT_Word FMT_Word64
 includes/stg/Types.h:#define FMT_Word FMT_Word32
 
 and format strings like blabla  FMT_Word  ..blabla are used inside 
 rts/. One could do the same for FMT_Path and introduce it where required.
 
 Maybe this would be acceptable?
 
 / Jost
 

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

Re: Unicode quotes

[Gabor Greif]

On 9/4/13, Kazu Yamamoto k...@iij.ad.jp wrote:
 Hello,

 GHCi of GHC 7.7 use Unicode quote marks instead of ASCII quote marks.
 Why do you guys decide this behavior change? I'm just curious.

Maybe because kind promotion causes some types to be written with
a leading apostrophe? I do not really know it, but I've seen those
unicode characters being swallowed on my console until I set
LC_ALL to en_US.

Cheers,

Gabor


 --Kazu

 ___
 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: RE: More windows woe

[Simon Peyton-Jones]

 IF_DEBUG(linker, debugBelch(Checking whether to unload  FMT_PATH \n,

doesn't that expand to 

 IF_DEBUG(linker, debugBelch(Checking whether to unload  %S \n,

What does the C compiler make of three strings in a row?  Does it automatically 
concatenate them? Is that ANSI C?

S

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Edward
| Z. Yang
| Sent: 04 September 2013 10:15
| To: Jost Berthold
| Cc: ghc-devs
| Subject: Re: RE: More windows woe
| 
| I think this is reasonable, with the added caveat that
| the macros should be placed in includes/rts/Linker.h, because that is
| where pathchar is defined.  So how about something like:
| 
| diff --git a/includes/rts/Linker.h b/includes/rts/Linker.h
| index e900e85..871b8cd 100644
| --- a/includes/rts/Linker.h
| +++ b/includes/rts/Linker.h
| @@ -16,8 +16,10 @@
| 
|  #if defined(mingw32_HOST_OS)
|  typedef wchar_t pathchar;
| +#define FMT_PATH %S
|  #else
|  typedef charpathchar;
| +#define FMT_PATH %s
|  #endif
| 
|  /* initialize the object linker */
| diff --git a/rts/CheckUnload.c b/rts/CheckUnload.c
| index a758b06..8dc8fdc 100644
| --- a/rts/CheckUnload.c
| +++ b/rts/CheckUnload.c
| @@ -254,7 +254,7 @@ void checkUnload (StgClosure *static_objects)
| 
|// Mark every unloadable object as unreferenced initially
|for (oc = unloaded_objects; oc; oc = oc-next) {
| -  IF_DEBUG(linker, debugBelch(Checking whether to unload %s\n,
| +  IF_DEBUG(linker, debugBelch(Checking whether to unload 
| FMT_PATH \n,
|oc-fileName));
|oc-referenced = rtsFalse;
|}
| @@ -290,11 +290,11 @@ void checkUnload (StgClosure *static_objects)
|} else {
|prev-next = oc-next;
|}
| -  IF_DEBUG(linker, debugBelch(Unloading object file %s\n,
| +  IF_DEBUG(linker, debugBelch(Unloading object file  FMT_PATH
| \n,
|oc-fileName));
|freeObjectCode(oc);
|} else {
| -  IF_DEBUG(linker, debugBelch(Object file still in use: %s\n,
| +  IF_DEBUG(linker, debugBelch(Object file still in use: 
| FMT_PATH \n,
|oc-fileName));
|}
|}
| diff --git a/rts/Linker.c b/rts/Linker.c
| index 6490242..4f0a1c4 100644
| --- a/rts/Linker.c
| +++ b/rts/Linker.c
| @@ -2790,7 +2790,7 @@ unloadObj( pathchar *path )
| 
|  initLinker();
| 
| -IF_DEBUG(linker, debugBelch(unloadObj: %s\n, path));
| +IF_DEBUG(linker, debugBelch(unloadObj:  FMT_PATH \n, path));
| 
|  prev = NULL;
|  for (oc = objects; oc; prev = oc, oc = next) {
| 
| Excerpts from Jost Berthold's message of Tue Sep 03 12:56:03 -0700 2013:
|   From: Simon Peyton-Jones simo...@microsoft.com
|   To: Edward Z. Yang ezy...@mit.edu, Simon Marlow
|   marlo...@gmail.com
|   Cc: ghc-devs@haskell.org ghc-devs@haskell.org
|   Subject: RE: More windows woe
|   Message-ID:
|  
| 59543203684b2244980d7e4057d5fbc1485bb...@db3ex14mbxc308.europe.corp.mic
| rosoft.com
|  
|   Content-Type: text/plain; charset=utf-8
|  
|   Simon Marlow: please help!
|   At the moment windows builds are hosed, which is a Bad Situation.
|  
|   Actually it turns out that what want is
|  
|  debugBelch(Checking whether to unload %S\n, oc-fileName));
|  
|   That is, use %S rather than %s as format specifier for wide
| chars.
|  
|   Sadly, this works on Windows, but not on Linux:
|   rts/CheckUnload.c:260:13:
| error: format ?%S? expects argument of type ?wchar_t *?, but
| argument 2 has type ?pathchar *? [-Werror=format]
|  
|  
|   So what I need guidance on, please!, is what the approved way to
| deal with this is.  I suppose that I could identify each use of %s on a
| filepath and say
|  
|   #ifdef mingw32_HOST_OS
|  debugBelch(Checking whether to unload %S\n, oc-fileName));
|   #else
|  debugBelch(Checking whether to unload %s\n, oc-fileName));
|   #endif
|  
|   But that seems deeply unsatisfactory doesn't it?
|  
|   If not that, then what?
|  
|  
|   Simon
| 
|  Similar code is in place to distinguish between 32-bit and 64-bit
| StgWords:
| 
|grep -r -e FMT_Word includes/
|  includes/stg/Types.h:#define FMT_Word32u
|  includes/stg/Types.h:#define FMT_Word32lu
|  includes/stg/Types.h:#define FMT_Word64lu
|  includes/stg/Types.h:#define FMT_Word64llu
|  includes/stg/Types.h:#define FMT_Word FMT_Word64
|  includes/stg/Types.h:#define FMT_Word FMT_Word32
| 
|  and format strings like blabla  FMT_Word  ..blabla are used inside
|  rts/. One could do the same for FMT_Path and introduce it where
| required.
| 
|  Maybe this would be acceptable?
| 
|  / Jost
| 
| 
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org

RE: RE: More windows woe

[Edward Z. Yang]

Yep, it's string concatenation, and it's ANSI C as per 5.1.1.2.  We use this
idiom in other parts of the RTS.

Cheers,
Edward

Excerpts from Simon Peyton-Jones's message of Wed Sep 04 02:22:48 -0700 2013:
  IF_DEBUG(linker, debugBelch(Checking whether to unload  FMT_PATH \n,
 
 doesn't that expand to 
 
  IF_DEBUG(linker, debugBelch(Checking whether to unload  %S \n,
 
 What does the C compiler make of three strings in a row?  Does it 
 automatically concatenate them? Is that ANSI C?
 
 S
 
 | -Original Message-
 | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Edward
 | Z. Yang
 | Sent: 04 September 2013 10:15
 | To: Jost Berthold
 | Cc: ghc-devs
 | Subject: Re: RE: More windows woe
 | 
 | I think this is reasonable, with the added caveat that
 | the macros should be placed in includes/rts/Linker.h, because that is
 | where pathchar is defined.  So how about something like:
 | 
 | diff --git a/includes/rts/Linker.h b/includes/rts/Linker.h
 | index e900e85..871b8cd 100644
 | --- a/includes/rts/Linker.h
 | +++ b/includes/rts/Linker.h
 | @@ -16,8 +16,10 @@
 | 
 |  #if defined(mingw32_HOST_OS)
 |  typedef wchar_t pathchar;
 | +#define FMT_PATH %S
 |  #else
 |  typedef charpathchar;
 | +#define FMT_PATH %s
 |  #endif
 | 
 |  /* initialize the object linker */
 | diff --git a/rts/CheckUnload.c b/rts/CheckUnload.c
 | index a758b06..8dc8fdc 100644
 | --- a/rts/CheckUnload.c
 | +++ b/rts/CheckUnload.c
 | @@ -254,7 +254,7 @@ void checkUnload (StgClosure *static_objects)
 | 
 |// Mark every unloadable object as unreferenced initially
 |for (oc = unloaded_objects; oc; oc = oc-next) {
 | -  IF_DEBUG(linker, debugBelch(Checking whether to unload %s\n,
 | +  IF_DEBUG(linker, debugBelch(Checking whether to unload 
 | FMT_PATH \n,
 |oc-fileName));
 |oc-referenced = rtsFalse;
 |}
 | @@ -290,11 +290,11 @@ void checkUnload (StgClosure *static_objects)
 |} else {
 |prev-next = oc-next;
 |}
 | -  IF_DEBUG(linker, debugBelch(Unloading object file %s\n,
 | +  IF_DEBUG(linker, debugBelch(Unloading object file  FMT_PATH
 | \n,
 |oc-fileName));
 |freeObjectCode(oc);
 |} else {
 | -  IF_DEBUG(linker, debugBelch(Object file still in use: %s\n,
 | +  IF_DEBUG(linker, debugBelch(Object file still in use: 
 | FMT_PATH \n,
 |oc-fileName));
 |}
 |}
 | diff --git a/rts/Linker.c b/rts/Linker.c
 | index 6490242..4f0a1c4 100644
 | --- a/rts/Linker.c
 | +++ b/rts/Linker.c
 | @@ -2790,7 +2790,7 @@ unloadObj( pathchar *path )
 | 
 |  initLinker();
 | 
 | -IF_DEBUG(linker, debugBelch(unloadObj: %s\n, path));
 | +IF_DEBUG(linker, debugBelch(unloadObj:  FMT_PATH \n, path));
 | 
 |  prev = NULL;
 |  for (oc = objects; oc; prev = oc, oc = next) {
 | 
 | Excerpts from Jost Berthold's message of Tue Sep 03 12:56:03 -0700 2013:
 |   From: Simon Peyton-Jones simo...@microsoft.com
 |   To: Edward Z. Yang ezy...@mit.edu, Simon Marlow
 |   marlo...@gmail.com
 |   Cc: ghc-devs@haskell.org ghc-devs@haskell.org
 |   Subject: RE: More windows woe
 |   Message-ID:
 |  
 | 59543203684b2244980d7e4057d5fbc1485bb...@db3ex14mbxc308.europe.corp.mic
 | rosoft.com
 |  
 |   Content-Type: text/plain; charset=utf-8
 |  
 |   Simon Marlow: please help!
 |   At the moment windows builds are hosed, which is a Bad Situation.
 |  
 |   Actually it turns out that what want is
 |  
 |  debugBelch(Checking whether to unload %S\n, oc-fileName));
 |  
 |   That is, use %S rather than %s as format specifier for wide
 | chars.
 |  
 |   Sadly, this works on Windows, but not on Linux:
 |   rts/CheckUnload.c:260:13:
 | error: format ?%S? expects argument of type ?wchar_t *?, but
 | argument 2 has type ?pathchar *? [-Werror=format]
 |  
 |  
 |   So what I need guidance on, please!, is what the approved way to
 | deal with this is.  I suppose that I could identify each use of %s on a
 | filepath and say
 |  
 |   #ifdef mingw32_HOST_OS
 |  debugBelch(Checking whether to unload %S\n, oc-fileName));
 |   #else
 |  debugBelch(Checking whether to unload %s\n, oc-fileName));
 |   #endif
 |  
 |   But that seems deeply unsatisfactory doesn't it?
 |  
 |   If not that, then what?
 |  
 |  
 |   Simon
 | 
 |  Similar code is in place to distinguish between 32-bit and 64-bit
 | StgWords:
 | 
 |grep -r -e FMT_Word includes/
 |  includes/stg/Types.h:#define FMT_Word32u
 |  includes/stg/Types.h:#define FMT_Word32lu
 |  includes/stg/Types.h:#define FMT_Word64lu
 |  includes/stg/Types.h:#define FMT_Word64llu
 |  includes/stg/Types.h:#define FMT_Word FMT_Word64
 |  includes/stg/Types.h:#define FMT_Word FMT_Word32
 | 
 |  and format strings like blabla  FMT_Word  ..blabla are used inside
 |  rts/. One could do the same for FMT_Path and introduce it 

RE: RE: More windows woe

[Kyle Van Berendonck]

A quick search reveals that this is valid ANSI C.

Regards,

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

Re: RE: More windows woe

[naur]

Hello cvs-devs,

On a relatively recent Linux, man sprintf says S [conversion specifier] (Not 
in C99, but in SUSv2.) Synonym for ls. Don't use., so perhaps %ls is better 
than %S.

Best regards
Thorkil

- Original meddelelse -
 Fra: Edward Z. Yang ezy...@mit.edu
 Til: Jost Berthold berth...@mathematik.uni-marburg.de
 Cc: ghc-devs ghc-devs@haskell.org
 Dato: Ons, 04. sep 2013 11:15
 Emne: Re: RE: More windows woe
 
 I think this is reasonable, with the added caveat that
 the macros should be placed in includes/rts/Linker.h, because that
 is
 where pathchar is defined.  So how about something like:
 
 diff --git a/includes/rts/Linker.h b/includes/rts/Linker.h
 index e900e85..871b8cd 100644
 --- a/includes/rts/Linker.h
 +++ b/includes/rts/Linker.h
 @@ -16,8 +16,10 @@
 
  #if defined(mingw32_HOST_OS)
  typedef wchar_t pathchar;
 +#define FMT_PATH %S
  #else
  typedef charpathchar;
 +#define FMT_PATH %s
  #endif
 
  /* initialize the object linker */
 diff --git a/rts/CheckUnload.c b/rts/CheckUnload.c
 index a758b06..8dc8fdc 100644
 --- a/rts/CheckUnload.c
 +++ b/rts/CheckUnload.c
 @@ -254,7 +254,7 @@ void checkUnload (StgClosure *static_objects)
 
// Mark every unloadable object as unreferenced initially
for (oc = unloaded_objects; oc; oc = oc-next) {
 -  IF_DEBUG(linker, debugBelch(Checking whether to unload
 %s\n,
 +  IF_DEBUG(linker, debugBelch(Checking whether to unload 
 FMT_PATH \n,
oc-fileName));
oc-referenced = rtsFalse;
}
 @@ -290,11 +290,11 @@ void checkUnload (StgClosure *static_objects)
} else {
prev-next = oc-next;
}
 -  IF_DEBUG(linker, debugBelch(Unloading object file
 %s\n,
 +  IF_DEBUG(linker, debugBelch(Unloading object file 
 FMT_PATH \n,
oc-fileName));
freeObjectCode(oc);
} else {
 -  IF_DEBUG(linker, debugBelch(Object file still in use:
 %s\n,
 +  IF_DEBUG(linker, debugBelch(Object file still in use: 
 FMT_PATH \n,
oc-fileName));
}
}
 diff --git a/rts/Linker.c b/rts/Linker.c
 index 6490242..4f0a1c4 100644
 --- a/rts/Linker.c
 +++ b/rts/Linker.c
 @@ -2790,7 +2790,7 @@ unloadObj( pathchar *path )
 
  initLinker();
 
 -IF_DEBUG(linker, debugBelch(unloadObj: %s\n, path));
 +IF_DEBUG(linker, debugBelch(unloadObj:  FMT_PATH \n,
 path));
 
  prev = NULL;
  for (oc = objects; oc; prev = oc, oc = next) {
 
 Excerpts from Jost Berthold's message of Tue Sep 03 12:56:03 -0700
 2013:
   From: Simon Peyton-Jones simo...@microsoft.com
   To: Edward Z. Yang ezy...@mit.edu, Simon Marlow
   marlo...@gmail.com
   Cc: ghc-devs@haskell.org ghc-devs@haskell.org
   Subject: RE: More windows woe
   Message-ID:
  
 59543203684b2244980d7e4057d5fbc1485bb...@db3ex14mbxc308.europe.corp
 .microsoft.com
   
   Content-Type: text/plain; charset=utf-8
  
   Simon Marlow: please help!
   At the moment windows builds are hosed, which is a Bad
 Situation.
  
   Actually it turns out that what want is
  
  debugBelch(Checking whether to unload %S\n,
 oc-fileName));
  
   That is, use %S rather than %s as format specifier for wide
 chars.
  
   Sadly, this works on Windows, but not on Linux:
   rts/CheckUnload.c:260:13:
 error: format ?%S? expects argument of type ?wchar_t *?,
 but argument 2 has type ?pathchar *? [-Werror=format]
  
  
   So what I need guidance on, please!, is what the approved way to
 deal with this is.  I suppose that I could identify each use of %s
 on a filepath and say
  
   #ifdef mingw32_HOST_OS
  debugBelch(Checking whether to unload %S\n,
 oc-fileName));
   #else
  debugBelch(Checking whether to unload %s\n,
 oc-fileName));
   #endif
  
   But that seems deeply unsatisfactory doesn't it?
  
   If not that, then what?
  
  
   Simon
  
  Similar code is in place to distinguish between 32-bit and 64-bit
 StgWords:
  
grep -r -e FMT_Word includes/
  includes/stg/Types.h:#define FMT_Word32u
  includes/stg/Types.h:#define FMT_Word32lu
  includes/stg/Types.h:#define FMT_Word64lu
  includes/stg/Types.h:#define FMT_Word64llu
  includes/stg/Types.h:#define FMT_Word FMT_Word64
  includes/stg/Types.h:#define FMT_Word FMT_Word32
  
  and format strings like blabla  FMT_Word  ..blabla are used
 inside 
  rts/. One could do the same for FMT_Path and introduce it where
 required.
  
  Maybe this would be acceptable?
  
  / Jost
  
 
 ___
 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: More windows woe

[Edward Z. Yang]

My latest error:

librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:432:47:
Ambiguous occurrence `Handler'
It could refer to either `System.Console.Haskeline.Backend.Win32.Handler',
 defined at 
librarieshaskelineSystemConsoleHaskelineBackendWin32.hs
c:430:6   
  or `System.Console.Haskeline.Monads.Handler',
 imported from `System.Console.Haskeline.Monads' at 
librarieshaskel
ineSystemConsoleHaskelineBackendWin32.hsc:20:1-38
 (and originally defined in 
`System.Console.Haskeline.MonadExceptio
n')   
  
librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:432:69:
Ambiguous occurrence `Handler'
It could refer to either `System.Console.Haskeline.Backend.Win32.Handler',
 defined at 
librarieshaskelineSystemConsoleHaskelineBackendWin32.hs
c:430:6   
  or `System.Console.Haskeline.Monads.Handler',
 imported from `System.Console.Haskeline.Monads' at 
librarieshaskel
ineSystemConsoleHaskelineBackendWin32.hsc:20:1-38   

   
 (and originally defined in 
`System.Console.Haskeline.MonadExceptio 
   
n') 

   


   
librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:435:15:

   
Ambiguous occurrence `Handler'  

   
It could refer to either `System.Console.Haskeline.Backend.Win32.Handler',  

   
 defined at 
librarieshaskelineSystemConsoleHaskelineBackendWin32.hs 
   
c:430:6 

   
  or `System.Console.Haskeline.Monads.Handler', 

   
 imported from `System.Console.Haskeline.Monads' at 
librarieshaskel 
   
ineSystemConsoleHaskelineBackendWin32.hsc:20:1-38   

   
 (and originally defined in 
`System.Console.Haskeline.MonadExceptio 
   
n') 

   
make[1]: *** 
[libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o]

 
Error 1 

   
make: *** [all] Error 2

Excerpts from Simon Marlow's message of Wed Sep 04 02:44:18 -0700 2013:
 Sorry about that; I'm on it, fix coming soon.
 
 Cheers,
 Simon
 
 On 03/09/13 15:33, Simon Peyton-Jones wrote:
  Simon Marlow: please help!
  At the moment windows builds are hosed, which is a Bad Situation.
 
  Actually it turns out that what want is
 
 debugBelch(Checking whether to unload %S\n, oc-fileName));
 
  That is, use %S rather than %s as format specifier for wide chars.
 
  Sadly, this works on Windows, but not on Linux:
  rts/CheckUnload.c:260:13:
error: format ‘%S’ expects argument of type ‘wchar_t *’, but argument 
  2 has type ‘pathchar *’ [-Werror=format]
 
 
  So what I need guidance on, please!, is what the approved way to deal with 
  this is.  I suppose 

Re: Building on Windows with msys

[Simon Marlow]

Nice catch!

On 28/08/13 09:08, Simon Peyton-Jones wrote:

Friends

My Windows build (new laptop) got stuck again, but this time I managed
to work out what is going on.  This email is just to record the issue;
I’ll add something to the wiki.

*tl;dr:* a MSYS build will fail in a deeply strange way if your MSYS bin
directory doesn’t take priority over the windows/system32 director.

*Symptom*: “sh libtool” hangs indefinitely.  The process manager shows
an extant “cmd” and “sed”, but nothing else.  libtool is a shell script
that comes from a tarball, and is unpacked into
libraries/integer-gmp/gmp/gmpbuild/libtool

*Cause*: libtool invokes the following command line (in the function
func_convert_coer_msys_to_w32:

  cmd /c “echo blah”

and pipes the result to sed. /But MSYS mangles the command line to turn
slashes into backslashes./  So the actual command line is more like

  cmd \c “echo blah”

which does something entirely different, and indeed hangs waiting for
input on stdin.

*Solution*: So how did this ever work on any MSYS installation?  Because

·msys/1.0/bin has a little script “cmd” which hands off to the real
c:/windows/system32/cmd

·MSYS does not mangle the command-line for programs in msys/1.0/bin

·/On my old laptop, msys/1.0/bin was in my path before
c:/windows/system32/.  So plain “cmd” gets the script, and MSYS does not
mangle the command line. The script passes arguments on unchanged to the
real cmd.

·NB: c:/windows/system32 is in the “system” path, which precedes the
“user” path.  So no amount of fiddling with the “user” path will fix
this.  There are two solutions:

oModify the system path

oUse a .bashrc file to prepend the stuff you need

This is pretty subtle stuff.

Simon

/Microsoft Research Limited (company number 03369488) is registered in
England and Wales /

/Registered office is at 21 Station Road, Cambridge, CB1 2FB/



___
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: Anyone else failing to validate on 'linker_unload'?

[Simon Marlow]

That's the bug.  Fix coming!

Simon

On 02/09/13 05:46, Austin Seipp wrote:

I (think) I see the problem, but maybe I'm just tired and shooting in the dark.

The only time checkUnload really iteratively calls free is in
CheckUnload.c (I say 'iteratively', because the fact you're
touching/freeing blocks inside already free blocks make me
suspicious.) The relevant code is:

---
   // Look through the unloadable objects, and any object that is still
   // marked as unreferenced can be physically unloaded, because we
   // have no references to it.
   prev = NULL;
   for (oc = unloaded_objects; oc; prev = oc, oc = oc-next) {
   if (oc-referenced == 0) {
   if (prev == NULL) {
   unloaded_objects = oc-next;
   } else {
   prev-next = oc-next;
   }
   IF_DEBUG(linker, debugBelch(Unloading object file %s\n,
   oc-fileName));
   freeObjectCode(oc);
   } else {
   IF_DEBUG(linker, debugBelch(Object file still in use: %s\n,
   oc-fileName));
   }
   }
---

Note that we iterate over oc-next in order to check every unloadable
object. If the object can be unloaded, we call freeObjectCode:

---
void freeObjectCode (ObjectCode *oc)
{
 
 stgFree(oc-fileName);
 stgFree(oc-archiveMemberName);
 stgFree(oc);
}
---

So it would seem we free the object we point to during each traversal.
This is probably bad and could lead to very weird behavior probably.

Ryan, can you do one final thing? When you run that program, be sure
to specify `+RTS -Dl` (must be linked with -debug.) This will enable
all the debug output where the linker is concerned. There will be a
few hundred lines just for initialization (based on my machine.) If my
theory is correct, you'll probably see stuff like 'Unloading object
file ...' right as the invalid read/segfault occurs.


On Sun, Sep 1, 2013 at 11:28 PM, Ryan Newton rrnew...@gmail.com wrote:

Ah, yes I see.  Well, giving it the proper arguments when running via
valgrind puts me back to an Invalid read segfault.  I confirmed that the
linker_unload executable itself is 64 bit:

$ file linker_unload
linker_unload: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

==72103== Command: ./linker_unload
/home/beehive/ryan_scratch/ghc-working/libraries/base/dist-install/build/libHSbase-4.7.0.0.a
/home/beehive/ryan_scratch/ghc-working/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0.a
/home/beehive/ryan_scratch/ghc-working/libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0.a
==72103==
==72103== Invalid read of size 8
==72103==at 0x479F9F: checkUnload (in
/home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload)
==72103==by 0x4689DA: GarbageCollect (in
/home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload)
==72103==by 0x4621F0: scheduleDoGC (in
/home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload)
==72103==by 0x462314: performGC_ (in
/home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload)
==72103==by 0x403341: main (in
/home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload)
==72103==  Address 0xf45ed70 is 80 bytes inside a block of size 120 free'd
==72103==at 0x4A063F0: free (vg_replace_malloc.c:446)
==72103==by 0x479F9E: checkUnload (in
/home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload)
==72103==by 0x4689DA: GarbageCollect (in
/home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload)
==72103==by 0x4621F0: scheduleDoGC (in
/home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload)
==72103==by 0x462314: performGC_ (in
/home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload)
==72103==by 0x403341: main (in
/home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload)
==72103==




On Sun, Sep 1, 2013 at 11:01 PM, Austin Seipp ase...@pobox.com wrote:


Oops, should have said this: if you checkout the Makefile for
testsuite/tests/rts - at the very bottom - you'll see the
linker_unload target. When run, the executable needs some arguments so
it knows what to try and load:

---
./linker_unload $(BASE) $(GHC_PRIM) $(INTEGER_GMP)
---

So you also need to provide the right arguments. Sorry about that!

On Sun, Sep 1, 2013 at 9:54 PM, Ryan Newton rrnew...@gmail.com wrote:

Hi Austin,

Should have said -- this is 64-bit RHEL 6 (my academic departments
standardized configuration).

  $ uname -a
  Linux  2.6.32-358.14.1.el6.x86_64 #1 SMP Mon Jun 17 

Re: More windows woe

[Edward Z. Yang]

Easy to fix: just tack a 'hiding (Handler)' onto the relevant import.

Excerpts from Edward Z. Yang's message of Wed Sep 04 02:56:38 -0700 2013:
 My latest error:
 
 librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:432:47:
 Ambiguous occurrence `Handler'
 It could refer to either `System.Console.Haskeline.Backend.Win32.Handler',
  defined at 
 librarieshaskelineSystemConsoleHaskelineBackendWin32.hs
 c:430:6   
   or `System.Console.Haskeline.Monads.Handler',
  imported from `System.Console.Haskeline.Monads' 
 at librarieshaskel
 ineSystemConsoleHaskelineBackendWin32.hsc:20:1-38
  (and originally defined in 
 `System.Console.Haskeline.MonadExceptio
 n')   
   
 librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:432:69:
 Ambiguous occurrence `Handler'
 It could refer to either `System.Console.Haskeline.Backend.Win32.Handler',
  defined at 
 librarieshaskelineSystemConsoleHaskelineBackendWin32.hs
 c:430:6   
   or `System.Console.Haskeline.Monads.Handler',
  imported from `System.Console.Haskeline.Monads' 
 at librarieshaskel
 ineSystemConsoleHaskelineBackendWin32.hsc:20:1-38 
   

  (and originally defined in 
 `System.Console.Haskeline.MonadExceptio   
  
 n')   
   

   
   

 librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:435:15:  
   

 Ambiguous occurrence `Handler'
   

 It could refer to either 
 `System.Console.Haskeline.Backend.Win32.Handler', 
   
   
  defined at 
 librarieshaskelineSystemConsoleHaskelineBackendWin32.hs   
  
 c:430:6   
   

   or `System.Console.Haskeline.Monads.Handler',   
   

  imported from `System.Console.Haskeline.Monads' 
 at librarieshaskel
 
 ineSystemConsoleHaskelineBackendWin32.hsc:20:1-38 
   

  (and originally defined in 
 `System.Console.Haskeline.MonadExceptio   
  
 n')   
   

 make[1]: *** 
 [libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o]
   

 Error 1   
   

 make: *** [all] Error 2
 
 Excerpts from Simon Marlow's message of Wed Sep 04 02:44:18 -0700 2013:
  Sorry about that; I'm on it, fix coming soon.
  
  Cheers,
  Simon
  
  On 03/09/13 15:33, Simon Peyton-Jones wrote:
   Simon Marlow: please help!
   At the moment windows builds are hosed, which is a Bad Situation.
  
   Actually it turns out that what want is
  
  debugBelch(Checking whether to unload %S\n, oc-fileName));
  
   That is, use %S rather than %s as format specifier for wide chars.
  
   Sadly, this works on Windows, but not on Linux:
   

Re: Unicode quotes

[山本和彦]

Hi,

One guy suggested this ticket.

http://ghc.haskell.org/trac/ghc/ticket/2507

--Kazu

From: Gabor Greif ggr...@gmail.com
Subject: Re: Unicode quotes

 On 9/4/13, Kazu Yamamoto k...@iij.ad.jp wrote:
 Hello,

 GHCi of GHC 7.7 use Unicode quote marks instead of ASCII quote marks.
 Why do you guys decide this behavior change? I'm just curious.
 
 Maybe because kind promotion causes some types to be written with
 a leading apostrophe? I do not really know it, but I've seen those
 unicode characters being swallowed on my console until I set
 LC_ALL to en_US.
 
 Cheers,
 
 Gabor
 

 --Kazu

 ___
 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: cvs-ghc archives

[Simon Marlow]

On 30/08/13 23:04, Austin Seipp wrote:

I believe they simply weren't regenerated. The mailing lists are a bit
off right now and I haven't had time to sit down and deal with them
for a few hours yet.

Just regenerating cvs-ghc on the main server should be easy enough though.


I'd be really grateful if they could be regenerated with the same 
numbering that we had before.  There are a lot of dangling pointers on 
the interweb now...


Cheers,
Simon



On Fri, Aug 30, 2013 at 4:56 PM, Edward Z. Yang ezy...@mit.edu wrote:

Seconding; there was a lot of useful information in those archives
and it would be pretty suboptimal if it was lost.

Edward

Excerpts from Simon Peyton-Jones's message of Thu Aug 29 09:49:19 -0700 2013:

Links like this one fail to work.  Is this permanent?  Thanks!
http://www.haskell.org/pipermail/cvs-ghc/2007-July/036496.html

Microsoft Research Limited (company number 03369488) is registered in England 
and Wales
Registered office is at 21 Station Road, Cambridge, CB1 2FB


___
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: A bug of multicore IO manager

[Simon Marlow]

On 03/09/13 22:57, Johan Tibell wrote:

Hi Kazu,

On Tue, Sep 3, 2013 at 2:52 PM, Kazu Yamamoto k...@iij.ad.jp
mailto:k...@iij.ad.jp wrote:

Hi,

As I said before, I started running HTTP server using Mio in the real
world. Unfortunately, the daemon is not stable.

After one day or so, the server cannot accept any HTTP requests.  No
error messages from the server.

The server is alive. To terminate the server (running in a screen
terminal), single Ctrl-c is not enough. Typing Ctrl-c again terminates
the server.


Could you run an strace on the process in this state so we can get an
idea what it's doing?

After several tests, I'm getting convinced that this occurs only when
+RTS -Nx is specified (where x = 2). The server runs well if +RTS
-Nx is not specified.


That indicates that the problem is with the threaded RTS and perhaps
with the IO manager.

My question: if the program complied with GHC needs double Ctrl-c to
terminate, what is the situation of the program?


If Ctrl+C generates an exception (does it?) there could be an
overzealous exception catcher somewhere that catches all exceptions,
including your Ctrl+C.


The first Ctrl-C is sent as an Interrupted exception to the main thread. 
 The second Ctrl-C sends a SIGINT as usual, which tends to kill the 
process.


If you need two Ctrl-Cs to kill the program, it probably means that it 
deadlocked somewhere, maybe in the RTS.  Kazu: if you can attach to the 
deadlocked process with gdb and get stack traces of all the threads, 
that might help.


Cheers,
Simon



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

RE: AMP (#8004) almost finished, review would be nice

[Simon Peyton-Jones]

| GHC/Base.lhs:1:1:
| GHC internal error: ‛GHC.Base.Monad’ is not in scope during type
| checking, but it passed the renamer tcl_env of environment: []

I don't understand this.  The message comes from TcEnv.notFound, presumably 
from tcLookupGlobal.  But the latter only calls notFound for an internal name 
(which this is not), or when compiling the very same module (GHC.Base in this 
case). But I think you are saying this message

So something mysterious is going on.  Can you try the obvious thing again and 
let's look at it?  

(I suppose you could commit as-is (when you've unravelled the validation 
questions) so that I can see it too.)

Simon

| 
| (and the full build errored with missing interfaces for GHC.Base). The
| maybe business fixed this. (Subject of the discussion: Cannot make
| ghc: Failed to load interface for GHC.Base)
| 
| Also note that the Prelude is not necessarily imported, so I think the
| lookups here can fail regardless of the issue mentioned before.
| 
| 
| 
|  I don't see any documentation.
| 
| In what sense? More comments, longer function headers? I thought the
| names used were clear, with comments giving an overview over longer
| sections. (If you're talking about Haddock: the AMP functions are not
| exported, hence no HTML docs. tcAmpWarn is called from inside
| tcTopSrcDecls in the same module.)
| 
| 
| 
|  I don't know about this validation stuff; maybe others can help.
|  Why not *not* add -fno-warn-amp to GcStage1HcOpts?
| 
| The flag is mysteriously passed to the existing GHC, i.e. it appears
| when building phase 1. However, the current compiler doesn't know about
| the flag and fails. (This was my initial attempt.)
| 
| 
| 
| Thanks for the advice,
| David/quchen
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: newtype coercion wrapping status

[Nicolas Trangez]

On Wed, 2013-09-04 at 11:55 +, Simon Peyton-Jones wrote:
 Joachim, 
 
 How do I get your code?
 
 bash$  git clone https://github.com/nomeata/ghc/compare/ntclass-clean 
 newtype-wrappers
 Cloning into 'newtype-wrappers'...
 fatal: https://github.com/nomeata/ghc/compare/ntclass-clean/info/refs not 
 found: did you run git update-server-info on the server?

git clone -b ntclass-clean https://github.com/nomeata/ghc.git

should do the job.

Nicolas


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

Re: newtype coercion wrapping status

[Joachim Breitner]

Hi,

Am Mittwoch, den 04.09.2013, 11:55 + schrieb Simon Peyton-Jones:
 Joachim, 
 
 How do I get your code?
 
 bash$  git clone https://github.com/nomeata/ghc/compare/ntclass-clean 
 newtype-wrappers
 Cloning into 'newtype-wrappers'...
 fatal: https://github.com/nomeata/ghc/compare/ntclass-clean/info/refs not 
 found: did you run git update-server-info on the server?

The command
$ git clone -b ntclass-clean https://github.com/nomeata/ghc/ 
should work, or alternatively
$ git fetch  https://github.com/nomeata/ghc/ ntclass-clean:ntclass-clean
inside a working copy to just add this branch (without adding an
explicit remote).

Greetings,
Joachim


-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0x4743206C
  Debian Developer: nome...@debian.org


signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: RE: More windows woe

[Edward Z. Yang]

I've gotten GHC to build on Windows, but the test suite is finicky. Here
is an error I am getting:

= T5267(normal) 50 of 3724 [0, 0, 0]   
  
cd ./arrows/should_compile  
'c:/Users/ezyang/Dev/ghc-validate/bindisttest/install   dir/bin/ghc.exe'
 -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db 
-rtsopts -fno-ghci-histor
y -c T5267.hsT5267.comp.stderr 21
  
Compile failed (status 256) errors were:
  

  
T5267.hs:11:15: 
  
tee: standard output: Permission denied  

It consistently fails on this test, and when I look at the process
list I see:

I103215481548   4064  con  500 14:54:08 /usr/bin/tee

I was seeing something similar when I used parallel make, apparently
there is a known deadlock when running make -j2 (or higher). But I
don't know why tee would be deadlocking.

Edward

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

Haskeline 0.7.0.4

[Edward Z. Yang]

Hey Judah,

We're gearing up for another GHC release, and there a small number of
patches which are still in GHC's tree which have not made it into
the upstream haskeline repository:

commit 495b00b4f125c0b4e7f1e966cd961eae89cffdc0
Author: Herbert Valerio Riedel h...@gnu.org
Date:   Sat Aug 31 10:31:52 2013 +0200

Avoid shadowing `handlers` variable in `catches`

commit 40bcd6ac30577d1d240166674d1e328ac52c1fd5
Author: Ian Lynagh i...@well-typed.com
Date:   Tue Jul 2 16:46:53 2013 +0100

Fix build on Win64

commit 3a92ddd63d4edc622ad4af044c5b664aa64c3dd4
Author: Ian Lynagh i...@well-typed.com
Date:   Sun Feb 17 20:25:10 2013 +

Follow unix's version bump

Additionally, I have one more patch for the Windows build, attached below:

commit 80f2fafe39cbc86205afb2eac8d4f60a1ce2684e
Author: Edward Z. Yang ezy...@mit.edu
Date:   Wed Sep 4 17:45:37 2013 -0700

Avoid Handler identifier conflict in Windows.

Signed-off-by: Edward Z. Yang ezy...@mit.edu

diff --git a/System/Console/Haskeline/Backend/Win32.hsc 
b/System/Console/Haskeline/Backend/Win32.hsc
index d54df2c..4447519 100644
--- a/System/Console/Haskeline/Backend/Win32.hsc
+++ b/System/Console/Haskeline/Backend/Win32.hsc
@@ -17,7 +17,7 @@ import Data.Maybe(mapMaybe)
 import Control.Monad
 
 import System.Console.Haskeline.Key
-import System.Console.Haskeline.Monads
+import System.Console.Haskeline.Monads hiding (Handler)
 import System.Console.Haskeline.LineState
 import System.Console.Haskeline.Term
 import System.Console.Haskeline.Backend.WCWidth

Thanks,
Edward

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

Re: RE: More windows woe

[Edward Z. Yang]

I manually removed the tee from the validate script, and sallied on.
Here's the next error.

= cabal01(normal) 81 of 3724 [0, 0, 0]
cd ./cabal/cabal01  $MAKE -s --no-print-directory cabal01 
VANILLA=--enable-library-vanilla PR
OF=--disable-library-profiling DYN=--enable-shared CLEANUP=1/dev/null 
cabal01.run.stdout
2cabal01.run.stderr
Wrong exit code (expected 0 , actual 2 )
Stdout:

Stderr:
Creating library file: dist\build\libHStest-1.0-ghc7.7.20130904.dll.a
setup.exe: Error: Could not find module: A with any suffix: [dyn_hi] in the
search path: [dist\\build]
make[3]: *** [cabal01] Error 1

*** unexpected failure for cabal01(normal)

Cheers,
Edward

Excerpts from Edward Z. Yang's message of Wed Sep 04 14:56:30 -0700 2013:
 I've gotten GHC to build on Windows, but the test suite is finicky. Here
 is an error I am getting:
 
 = T5267(normal) 50 of 3724 [0, 0, 0] 
 
 cd ./arrows/should_compile  
 'c:/Users/ezyang/Dev/ghc-validate/bindisttest/install   dir/bin/ghc.exe'
  -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db 
 -rtsopts -fno-ghci-histor
 y -c T5267.hsT5267.comp.stderr 21  
 
 Compile failed (status 256) errors were:  
 
   
 
 T5267.hs:11:15:   
 
 tee: standard output: Permission denied  
 
 It consistently fails on this test, and when I look at the process
 list I see:
 
 I103215481548   4064  con  500 14:54:08 /usr/bin/tee
 
 I was seeing something similar when I used parallel make, apparently
 there is a known deadlock when running make -j2 (or higher). But I
 don't know why tee would be deadlocking.
 
 Edward

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

Re: GHC 7.8 release status

[Luke Iannini]

Hi Luite,

Would we be able to adapt this to get generalized Template Haskell support
for GHC iOS/cross compilation?

Cheers
Luke


On Wed, Sep 4, 2013 at 6:09 PM, Luite Stegeman stege...@gmail.com wrote:

 I've updated the wiki page, expanding the descriptions and adding code
 from the actual implementation:
 http://ghc.haskell.org/trac/ghc/wiki/Ghc/Hooks
 An demo program that uses all hooks here:
 https://gist.github.com/luite/6444273
 (I've listed the users (or proposers) of every hook, and how they use it,
 Thomas / Edsko, can you check that they indeed do what you need?)
 The patch is here:

 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks.patch

 In addition to defining the heterogeneous map and the hooks themselves,
 extra exports have been added to make it possible for users to actually
 make a hook implementation without copying most of the module's source
 code. The demo program implements all hooks to check this.

 Also the GHCJS patch is here:


 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch

 It adds the following:
 - in DynFlags an extra WayCustom constructor to add a custom 'tag' to
 generated files (GHCJS builds multiple architectures to support Template
 Haskell among other things, one with the 'js' tag)
 - in ForeignCall the JavaScriptCallConv calling convention
 - in Platform an ArchJavaScript architecture
 - `foreign import javascript' support in the parser and lexer
 - The JavaScriptFFI extension that enables the `foreign import javascript'
 syntax, only supported on ArchJavaScript (So using it on a regular GHC
 would always result in a compile error saying that it's unsupported on the
 user's platform)

 luite


 On Thu, Sep 5, 2013 at 12:17 AM, Thomas Schilling nomin...@googlemail.com
  wrote:

 I started a wiki page at: http://ghc.haskell.org/trac/ghc/wiki/Ghc/Hooks

 Luite: could you please fill in the hooks that your latest patch defines?


 On 4 Sep 2013, at 19:40, Simon Peyton-Jones simo...@microsoft.com
 wrote:

  I do need more than a patch, please, please.  A wiki page explaining
 the design, as seen by the user (of the GHC API), the problems it solves,
 and the use-cases it enables, would be most helpful.
 
  Simon
 
  | -Original Message-
  | From: Thomas Schilling [mailto:nomin...@googlemail.com]
  | Sent: 04 September 2013 17:26
  | To: Simon Peyton-Jones; Luite Stegeman
  | Cc: Nicolas Frisby; Pedro Magalhães (drei...@gmail.com); Richard
  | Eisenberg (e...@cis.upenn.edu); Geoffrey Mainland
  | (mainl...@cs.drexel.edu); Iavor Diatchki; Austin Seipp; Edsko de
 Vries;
  | Ryan Newton (rrnew...@gmail.com); David Luposchainsky; ghc-
  | d...@haskell.org
  | Subject: Re: GHC 7.8 release status
  |
  |
  | On 4 Sep 2013, at 15:52, Simon Peyton-Jones simo...@microsoft.com
  | wrote:
  |
  |   Edsko/Thomas/Luite: if you want anything for 7.8 it'll have to be
  | jolly soon.  At the moment I don't even know the motivation or design,
  | let alone implementation.  Could you make a wiki page explaining the
  | proposed design?  Is it really important to do this for 7.8?
  |
  | Yes, it is quite important to get this into 7.8.  Not having these
  | features in GHC makes it very difficult for people to adopt GHCJS.
  One
  | could argue that GHCJS is not yet production-ready anyway and users
 that
  | want to try it can figure out building GHC from source to use it, but
  | this doesn't quite apply.
  |
  |  1. GHCJS targets a wider audience than users brave enough to compile
  | GHC from source. In addition, the next chance to get these features
 into
  | GHC is in a year from now, so when GHCJS becomes more mature then this
  | will be a major hurdle for adoption.
  |
  |  2. These changes are also required for IDE tools which really mustn't
  | require users to build a custom version of GHC.
  |
  |
  | Luite's design is actually very flexible.  It simply allows GHC API
  | users to provide functions that are called instead of (or in addition
  | to) existing functions in GHC.  Instead of calling, say,
 genHardCode,
  | the driver now looks up whether the user has specified a hook for
  | genHardCode and calls that instead.
  |
  | Currently we only specify a small number of hooks that are sufficient
  | for our use cases.  Future releases of GHC can be extended to include
  | more hooks, if that is needed.
  |
  | Hooks are stored as an untyped map inside the DynFlags (to avoid
 issues
  | with circular dependencies).  Each hook is looked up using a single-
  | constructor type and type families are used to make this type safe.
  | There is one use of unsafeCoerce to avoid having to make every hook
  | function an instance of Typeable.
  |
  | Unlike CorePlugins, it is only a GHC API feature, and users cannot
  | specify plugins to be added via command line options.  If we can come
 up
  | with a good design, then we could add this in GHC 7.10, but it is not
  | necessary at this point.
  |
  | Luite: Do you have a 

Status of Windows validate

[Edward Z. Yang]

A lot of failures:



Unexpected results from:
TEST=T5313 registry001 cabal01 dynamicToo002 dynHelloWorld T1969 T5030 T3294 
T7797 T7850 haddock.Cabal haddock.compiler haddock.base linker_unload derefnull 
T4850 divbyzero T8172 ghci058 prog002 prog003 ImpSafeOnly08 safePkg01 
ImpSafeOnly02 ImpSafeOnly03 ImpSafeOnly01 ImpSafeOnly06 ImpSafeOnly07 
ImpSafeOnly04 ImpSafeOnly05 ImpSafeOnly09 ImpSafeOnly10

OVERALL SUMMARY for test run started at now
3724 total tests, which gave rise to
   12242 test cases, of which
8869 were skipped

  27 had missing libraries
3248 expected passes
  61 expected failures

  18 caused framework failures
   1 unexpected passes
  31 unexpected failures

Unexpected passes:
   driver  T5313 (normal)

Unexpected failures:
   ../../libraries/Win32/tests  registry001 [bad exit code] (normal)
   cabal/cabal01cabal01 [bad exit code] (normal)
   driver   dynHelloWorld [bad exit code] (dyn)
   driver/dynamicToo/dynamicToo002  dynamicToo002 [bad stdout] (normal)
   ghci/prog002 prog002 [bad exit code] (ghci)
   ghci/prog003 prog003 [bad exit code] (ghci)
   ghci/scripts T8172 [bad stdout] (ghci)
   ghci/scripts ghci058 [bad exit code] (ghci)
   perf/compilerT1969 [stat not good enough] (normal)
   perf/compilerT5030 [stat too good] (normal)
   perf/haddock haddock.Cabal [stat not good enough] 
(normal)
   perf/haddock haddock.base [stat not good enough] (normal)
   perf/haddock haddock.compiler [stat too good] (normal)
   perf/should_run  T7797 [stat too good] (normal)
   perf/should_run  T7850 [stat too good] (normal)
   rts  T4850 [bad stdout] (normal)
   rts  derefnull [bad exit code] (normal)
   rts  divbyzero [bad exit code] (normal)
   rts  linker_unload [bad exit code] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly01 [exit code non-0] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly02 [exit code non-0] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly03 [stderr mismatch] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly04 [exit code non-0] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly05 [stderr mismatch] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly06 [exit code non-0] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly07 [stderr mismatch] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly08 [stderr mismatch] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly09 [stderr mismatch] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly10 [exit code non-0] (normal)
   safeHaskell/check/pkg01  safePkg01 [bad exit code] (normal)

Cheers,
Edward

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

Re: Haskeline 0.7.0.4

[Judah Jacobson]

Hi Edward,

Thanks for the heads up.  Unfortunately my laptop is being repaired so I
probably won't be able to sync everything until the beginning of next week.
 If that's going to cause problems with getting the release rolled out,
please let me know and I'll try to get it done sooner.

Best,
-Judah



On Wed, Sep 4, 2013 at 5:54 PM, Edward Z. Yang ezy...@mit.edu wrote:

 Hey Judah,

 We're gearing up for another GHC release, and there a small number of
 patches which are still in GHC's tree which have not made it into
 the upstream haskeline repository:

 commit 495b00b4f125c0b4e7f1e966cd961eae89cffdc0
 Author: Herbert Valerio Riedel h...@gnu.org
 Date:   Sat Aug 31 10:31:52 2013 +0200

 Avoid shadowing `handlers` variable in `catches`

 commit 40bcd6ac30577d1d240166674d1e328ac52c1fd5
 Author: Ian Lynagh i...@well-typed.com
 Date:   Tue Jul 2 16:46:53 2013 +0100

 Fix build on Win64

 commit 3a92ddd63d4edc622ad4af044c5b664aa64c3dd4
 Author: Ian Lynagh i...@well-typed.com
 Date:   Sun Feb 17 20:25:10 2013 +

 Follow unix's version bump

 Additionally, I have one more patch for the Windows build, attached below:

 commit 80f2fafe39cbc86205afb2eac8d4f60a1ce2684e
 Author: Edward Z. Yang ezy...@mit.edu
 Date:   Wed Sep 4 17:45:37 2013 -0700

 Avoid Handler identifier conflict in Windows.

 Signed-off-by: Edward Z. Yang ezy...@mit.edu

 diff --git a/System/Console/Haskeline/Backend/Win32.hsc
 b/System/Console/Haskeline/Backend/Win32.hsc
 index d54df2c..4447519 100644
 --- a/System/Console/Haskeline/Backend/Win32.hsc
 +++ b/System/Console/Haskeline/Backend/Win32.hsc
 @@ -17,7 +17,7 @@ import Data.Maybe(mapMaybe)
  import Control.Monad

  import System.Console.Haskeline.Key
 -import System.Console.Haskeline.Monads
 +import System.Console.Haskeline.Monads hiding (Handler)
  import System.Console.Haskeline.LineState
  import System.Console.Haskeline.Term
  import System.Console.Haskeline.Backend.WCWidth

 Thanks,
 Edward

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