RE: Haskell Support on Windows (Simon Peyton Jones)
I've been meaning to start contributing to ghc for windows for years but never got around to it since I don't know what I could contribute with. I've compiled various 6.x and early 7.x versions before and mostly did small modifications for my own testing. I've been away from Haskell for a few months, but I've been meaning to come back and I'm willing to contribute with what I can :) -- From: Carter Schonwald carter.schonw...@gmail.com Sent: 01/04/2014 15:26 To: Simon Peyton Jones simo...@microsoft.com Cc: ghc-devs@haskell.org; Kyle Van Berendonck kvanberendo...@gmail.com Subject: Re: Haskell Support on Windows (Simon Peyton Jones) Kyle, we need you to help us with windows support! :-) On Tuesday, April 1, 2014, Simon Peyton Jones simo...@microsoft.com wrote: A couple of poor assumptions are made here. I'm not sure where here is. In my email I specifically said exactly what you are saying (only I was not as eloquent as you). What we need is some developers who are willing to give some love and support to the Windows version of GHC. And *they* really are thin on the ground, unfortunately. Simon *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.orgjavascript:_e(%7B%7D,'cvml','ghc-devs-boun...@haskell.org');] *On Behalf Of *Kyle Van Berendonck *Sent:* 01 April 2014 13:54 *To:* ghc-devs@haskell.orgjavascript:_e(%7B%7D,'cvml','ghc-devs@haskell.org'); *Subject:* Re: Haskell Support on Windows (Simon Peyton Jones) A couple of poor assumptions are made here. The first is that the userbase of GHC on Windows is poor. This is false. In fact, the poor state of Windows is mentioned on #haskell more frequently as of late. In the last week I've talked almost every day to (different) people who have had Windows woes with using GHC. The hacker-base isn't here at the moment - I agree, but the user-base most certainly is. Could this be a problem with the demographic, or could it just be that Windows development isn't inviting? The build system and default test failures in-particular are a source of discouragement. The second assumption is that GHC/Haskell will be worth a dime in the RealWorld without Windows as a primary tier platform. I'm going to put a crude guess that given the overwhelming magnitude of C#/F# coming up on my local careers portal that there's far more industry on Windows than on OSX or Linux. Those are all the businesses where the probability that they will ever touch Haskell goes from `probably not right now` to `impossible`. Let me also remind you that Windows still holds 89.2% of operating system market share ie the people that hackers and developers actually have to deploy their applications to. Sorry to sound fumey, but there's all this suggesting that everyone would have a better day if we dropped Windows (let's be honest, if it wasn't a primary tier platform nobody would have fixed it for 7.8), but I doubt few of the people who think it's a great idea or sslt have actually thought through whether it's the best thing for Haskell or just the best thing to get 7.8 into their hands a couple weeks sooner. Regards. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Windows build broken
Can someone fix this? This is breakage on Windows. It was fine yesterday. Simon cc1.exe: warnings being treated as errors rts\Linker.c: In function 'loadArchive': rts\Linker.c:2631:17: error: passing argument 1 of 'strlen' from incompatible pointer type c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:49:40: note: expected 'const char *' but argument is of type 'pathchar *' rts\Linker.c:2632:17: error: passing argument 2 of 'strcpy' from incompatible pointer type c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:45:39: note: expected 'const char *' but argument is of type 'pathchar *' rts\Linker.c:2638:21: error: passing argument 1 of 'strlen' from incompatible pointer type c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:49:40: note: expected 'const char *' but argument is of type 'pathchar *' rts\Linker.c:2643:17: error: passing argument 1 of '_wfopen' from incompatible pointer type c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/stdio.h:593:39: note: expected 'const wchar_t *' but argument is of type 'char *' rts/ghc.mk:233: recipe for target 'rts/dist/build/Linker.o' failed make[1]: *** [rts/dist/build/Linker.o] Error 1 make[1]: *** Waiting for unfinished jobs Makefile:64: recipe for target 'all' failed make: *** [all] Error 2 HEAD (master)$ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows build broken
Looks like 5d7f59018703b94ebfe96cbef5574ec396a1c051 is the culprit. Simon M, perhaps you can look at this? I'm tied up in the 7.8 branch at the moment, but I can revert it temporarily at least (I imagine the fix is easy enough - if you can't get to it soon, I'll revert and fix it when I get a chance). On Fri, Apr 4, 2014 at 10:14 AM, Simon Peyton Jones simo...@microsoft.com wrote: Can someone fix this? This is breakage on Windows. It was fine yesterday. Simon cc1.exe: warnings being treated as errors rts\Linker.c: In function 'loadArchive': rts\Linker.c:2631:17: error: passing argument 1 of 'strlen' from incompatible pointer type c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:49:40: note: expected 'const char *' but argument is of type 'pathchar *' rts\Linker.c:2632:17: error: passing argument 2 of 'strcpy' from incompatible pointer type c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:45:39: note: expected 'const char *' but argument is of type 'pathchar *' rts\Linker.c:2638:21: error: passing argument 1 of 'strlen' from incompatible pointer type c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:49:40: note: expected 'const char *' but argument is of type 'pathchar *' rts\Linker.c:2643:17: error: passing argument 1 of '_wfopen' from incompatible pointer type c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/stdio.h:593:39: note: expected 'const wchar_t *' but argument is of type 'char *' rts/ghc.mk:233: recipe for target 'rts/dist/build/Linker.o' failed make[1]: *** [rts/dist/build/Linker.o] Error 1 make[1]: *** Waiting for unfinished jobs Makefile:64: recipe for target 'all' failed make: *** [all] Error 2 HEAD (master)$ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows build broken
Sorry, probably my fault. I've attached a patch that should fix it,
which should get you going while I validate.
Cheers,
Simon
On 04/04/2014 16:14, Simon Peyton Jones wrote:
Can someone fix this? This is breakage on Windows. It was fine yesterday.
Simon
cc1.exe: warnings being treated as errors
rts\Linker.c: In function 'loadArchive':
rts\Linker.c:2631:17:
error: passing argument 1 of 'strlen' from incompatible pointer type
c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:49:40:
note: expected 'const char *' but argument is of type 'pathchar *'
rts\Linker.c:2632:17:
error: passing argument 2 of 'strcpy' from incompatible pointer type
c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:45:39:
note: expected 'const char *' but argument is of type 'pathchar *'
rts\Linker.c:2638:21:
error: passing argument 1 of 'strlen' from incompatible pointer type
c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:49:40:
note: expected 'const char *' but argument is of type 'pathchar *'
rts\Linker.c:2643:17:
error: passing argument 1 of '_wfopen' from incompatible pointer type
c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/stdio.h:593:39:
note: expected 'const wchar_t *' but argument is of type 'char *'
rts/ghc.mk:233: recipe for target 'rts/dist/build/Linker.o' failed
make[1]: *** [rts/dist/build/Linker.o] Error 1
make[1]: *** Waiting for unfinished jobs
Makefile:64: recipe for target 'all' failed
make: *** [all] Error 2
HEAD (master)$
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
From f65e9fe435a72ac3de1487a3e5a24b347c1a809b Mon Sep 17 00:00:00 2001
From: Simon Marlow marlo...@gmail.com
Date: Fri, 4 Apr 2014 17:02:20 +0100
Subject: [PATCH] Disable thin archive support on Windows
---
rts/Linker.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/rts/Linker.c b/rts/Linker.c
index 38d7c39..bed5496 100644
--- a/rts/Linker.c
+++ b/rts/Linker.c
@@ -2379,9 +2379,12 @@ loadArchive( pathchar *path )
if (n != 8)
barf(loadArchive: Failed reading header from `%s', path);
if (strncmp(tmp, !arch\n, 8) == 0) {}
+#if !defined(mingw32_HOST_OS)
+/* See Note [thin archives on Windows] */
else if (strncmp(tmp, !thin\n, 8) == 0) {
isThin = 1;
}
+#endif
#if defined(darwin_HOST_OS)
/* Not a standard archive, look for a fat archive magic number: */
else if (ntohl(*(uint32_t *)tmp) == FAT_MAGIC) {
@@ -2622,6 +2625,14 @@ loadArchive( pathchar *path )
image = stgMallocBytes(memberSize, loadArchive(image));
#endif
+#if !defined(mingw32_HOST_OS)
+/*
+ * Note [thin archives on Windows]
+ * This doesn't compile on Windows because it assumes
+ * char* pathnames, and we use wchar_t* on Windows. It's
+ * not trivial to fix, so I'm leaving it disabled on
+ * Windows for now --SDM
+ */
if (isThin) {
FILE *member;
char *pathCopy, *dirName, *memberPath;
@@ -2653,7 +2664,9 @@ loadArchive( pathchar *path )
stgFree(memberPath);
stgFree(pathCopy);
}
-else {
+else
+#endif
+{
n = fread ( image, 1, memberSize, f );
if (n != memberSize) {
barf(loadArchive: error whilst reading `%s', path);
--
1.7.9.5
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-citeproc / highlighting-kate
Sergei
SpecConstr is too aggressive: it sometimes blows up the program badly and we
have no good solution. See Trac #7898, #7068, #7944, #5550, #8836.
I notice that the latter three are actually fixed in 7.8, so worth trying that.
If it still fails, do add instructions to reproduce to one of the above open
tickets, or make a new one.
Amos Robinson (cc'd) was working on this problem, but I have not heard anything
recently.
It surely ought to be possible to throttle it a bit so that it stops before
generating too vast a program.
Meanwhile you can use -fno-spec-constr to simply switch it off for offending
modules. That should get you going.
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
| Sergei Trofimovich
| Sent: 03 April 2014 21:20
| To: ghc-devs@haskell.org
| Subject: Re: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-
| citeproc / highlighting-kate
|
| On Sat, 22 Mar 2014 22:21:42 +0300
| Sergei Trofimovich sly...@gmail.com wrote:
|
| Hello!
|
| I have noticed the problem in ghc-7.6.3 first when tried to build all
| haskell userland with -O2 opt level.
|
| It led to amazing bugs!
|
| Here is one of those (highlighting-kate hackage package):
| [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp (
| highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs,
| highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o )
| stack overflow: use +RTS -Ksize to increase it
|
| How to reproduce it:
| 1. Download a bundled file (6.6MB):
|
| http://code.haskell.org/~slyfox/selfcontained-eater-ghc-7.8-
| rc2.tar.gz
| 2. Unpack and run there:
|./mk.sh
|
| The script is designed to plug any built ghc version w/o external
| depends.
|
| Command will fail as:
| $ ./mk.sh
| ...
| [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp (
| highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs,
| highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o )
| stack overflow: use +RTS -Ksize to increase it
|
| On ghc-7.6.3 it will progress a bit more: down to 452 file and will
| crash there similar way.
|
| I've 'cabal unpack'-ed all sources and configured/de-.hsc-ed them
| manually/added needed -DWhatever / added {-# LANGUAGE CPP #-} around.
| Nothing else.
|
| It's very hard to shrink such large thing manually down to 2-3 files.
| Would be cool if ghc (and cabal) would be able to spit something
| self-sufficient (like 'gcc -i' does) for devs to reproduce.
|
| Adding '-v' shows such log:
| ...
| *** Simplifier:
| Result size of Simplifier iteration=1
|= {terms: 21,973, types: 21,838, coercions: 1,842}
| Result size of Simplifier iteration=2
|= {terms: 21,952, types: 21,819, coercions: 1,842}
| Result size of Simplifier
|= {terms: 21,950, types: 21,817, coercions: 1,842}
| *** SpecConstr:
| Result size of SpecConstr***CRASH
|
| Nobody interested? Is it too scary?
|
| Such inliner blowups are hard to shrink down from real examples down to
| toy ones. I could try to but I need a bit of guidance.
|
| Maybe you need only an intermediate core step right before an OOM,
| whatever?
|
| Thanks!
|
| --
|
| Sergei
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
core lint warnings when doing perf build of 7.8 tip
should i be concerned about these?
*** Core Lint warnings : in result of Simplifier ***
{-# LINE 139 compiler/deSugar/Check.lhs #-}: Warning:
[RHS of Check.untidy :: Check.NeedPars
- Check.WarningPat - Check.WarningPat]
INLINE binder is (non-rule) loop breaker: Check.untidy
*** Core Lint warnings : in result of Simplifier ***
{-# LINE 139 compiler/deSugar/Check.lhs #-}: Warning:
[RHS of Check.untidy :: Check.NeedPars
- Check.WarningPat - Check.WarningPat]
INLINE binder is (non-rule) loop breaker: Check.untidy
*** Core Lint warnings : in result of Simplifier ***
{-# LINE 139 compiler/deSugar/Check.lhs #-}: Warning:
[RHS of Check.untidy :: Check.NeedPars
- Check.WarningPat - Check.WarningPat]
INLINE binder is (non-rule) loop breaker: Check.untidy
*** Core Lint warnings : in result of Simplifier ***
{-# LINE 139 compiler/deSugar/Check.lhs #-}: Warning:
[RHS of Check.untidy :: Check.NeedPars
- Check.WarningPat - Check.WarningPat]
INLINE binder is (non-rule) loop breaker: Check.untidy
*** Core Lint warnings : in result of Simplifier ***
{-# LINE 139 compiler/deSugar/Check.lhs #-}: Warning:
[RHS of Check.untidy :: Check.NeedPars
- Check.WarningPat - Check.WarningPat]
INLINE binder is (non-rule) loop breaker: Check.untidy
*** Core Lint warnings : in result of Tidy Core ***
{-# LINE 139 compiler/deSugar/Check.lhs #-}: Warning:
[RHS of Check.untidy :: Check.NeedPars
- Check.WarningPat - Check.WarningPat]
INLINE binder is (non-rule) loop breaker: Check.untidy
*** Core Lint warnings : in result of CorePrep ***
{-# LINE 139 compiler/deSugar/Check.lhs #-}: Warning:
[RHS of Check.untidy :: Check.NeedPars
- Check.WarningPat - Check.WarningPat]
INLINE binder is (non-rule) loop breaker: Check.untidy
*** Core Lint warnings : in result of CorePrep ***
{-# LINE 139 compiler/deSugar/Check.lhs #-}: Warning:
[RHS of Check.untidy :: Check.NeedPars
- Check.WarningPat - Check.WarningPat]
INLINE binder is (non-rule) loop breaker: Check.untidy
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
GHC HQ on Launchpad
Hello all, I've created a GHC team on Launchpad to manage the code imports and build recipes https://launchpad.net/~ghc Why? I recently was playing around with Launchpad's build recipes service, and realized that this could be another helpful source of builds for GHC (resulting in proper Ubuntu packages which then can be directly installed by installing a PPA). If you're not interested, you can just ignore (or remove yourself) from the group. Conversely, if I didn't find your Launchpad identifier, please ask to be added. Cheers, Edward ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: core lint warnings when doing perf build of 7.8 tip
No. It’s just an infelicity I have never gotten around to removing
Simon
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Carter
Schonwald
Sent: 04 April 2014 21:43
To: ghc-devs@haskell.org
Subject: core lint warnings when doing perf build of 7.8 tip
should i be concerned about these?
*** Core Lint warnings : in result of Simplifier ***
{-# LINE 139 compiler/deSugar/Check.lhs #-}: Warning:
[RHS of Check.untidy :: Check.NeedPars
- Check.WarningPat - Check.WarningPat]
INLINE binder is (non-rule) loop breaker: Check.untidy
*** Core Lint warnings : in result of Simplifier ***
{-# LINE 139 compiler/deSugar/Check.lhs #-}: Warning:
[RHS of Check.untidy :: Check.NeedPars
- Check.WarningPat - Check.WarningPat]
INLINE binder is (non-rule) loop breaker: Check.untidy
*** Core Lint warnings : in result of Simplifier ***
{-# LINE 139 compiler/deSugar/Check.lhs #-}: Warning:
[RHS of Check.untidy :: Check.NeedPars
- Check.WarningPat - Check.WarningPat]
INLINE binder is (non-rule) loop breaker: Check.untidy
*** Core Lint warnings : in result of Simplifier ***
{-# LINE 139 compiler/deSugar/Check.lhs #-}: Warning:
[RHS of Check.untidy :: Check.NeedPars
- Check.WarningPat - Check.WarningPat]
INLINE binder is (non-rule) loop breaker: Check.untidy
*** Core Lint warnings : in result of Simplifier ***
{-# LINE 139 compiler/deSugar/Check.lhs #-}: Warning:
[RHS of Check.untidy :: Check.NeedPars
- Check.WarningPat - Check.WarningPat]
INLINE binder is (non-rule) loop breaker: Check.untidy
*** Core Lint warnings : in result of Tidy Core ***
{-# LINE 139 compiler/deSugar/Check.lhs #-}: Warning:
[RHS of Check.untidy :: Check.NeedPars
- Check.WarningPat - Check.WarningPat]
INLINE binder is (non-rule) loop breaker: Check.untidy
*** Core Lint warnings : in result of CorePrep ***
{-# LINE 139 compiler/deSugar/Check.lhs #-}: Warning:
[RHS of Check.untidy :: Check.NeedPars
- Check.WarningPat - Check.WarningPat]
INLINE binder is (non-rule) loop breaker: Check.untidy
*** Core Lint warnings : in result of CorePrep ***
{-# LINE 139 compiler/deSugar/Check.lhs #-}: Warning:
[RHS of Check.untidy :: Check.NeedPars
- Check.WarningPat - Check.WarningPat]
INLINE binder is (non-rule) loop breaker: Check.untidy
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
