Re: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a POSIX way (fixes #8781) (e7563ec)
On 3/23/2014 20:51, Jost Berthold wrote: Hello, With the patch to deriveConstants, a build on an older Windows (32bit Vista, MinGW32 installation, which used to work) now fails with error Can't find STD_HDR_SIZE Same here: Windows 64-bit, MSYS2, nm being called is from binutils 2.24. Kyra ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a POSIX way (fixes #8781) (e7563ec)
Guys, could you be so kind and test attached patch? Thanks! Karel On 03/24/14 07:49 AM, kyra wrote: On 3/23/2014 20:51, Jost Berthold wrote: Hello, With the patch to deriveConstants, a build on an older Windows (32bit Vista, MinGW32 installation, which used to work) now fails with error Can't find STD_HDR_SIZE Same here: Windows 64-bit, MSYS2, nm being called is from binutils 2.24. Kyra ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs diff --git a/utils/deriveConstants/DeriveConstants.hs b/utils/deriveConstants/DeriveConstants.hs index 6344569..93d29b9 100644 --- a/utils/deriveConstants/DeriveConstants.hs +++ b/utils/deriveConstants/DeriveConstants.hs @@ -711,6 +711,7 @@ getWanted verbose tmpdir gccProgram gccFlags nmProgram -- _derivedConstantMAX_Vanilla_REG C b 0 Mac OS X -- derivedConstantMAX_Vanilla_REG C 000b 000b GNU -- derivedConstantMAX_Vanilla_REG D1b Solaris + -- _derivedConstantMAX_Vanilla_REG C 00b MinGW -- and returns (MAX_Vanilla_REG, 11) parseNmLine xs0 = case words xs0 of [x0, x1, x2, x3] - case stripPrefix prefix $ dropWhile (== '_') x0 of @@ -718,6 +719,11 @@ getWanted verbose tmpdir gccProgram gccFlags nmProgram [(size, )] - Just (name, size) _ - Nothing _ - Nothing +[x0, C, x2] - case stripPrefix prefix $ dropWhile (== '_') x0 of + Just name - case readHex x2 of + [(size, )] - Just (name, size) + _ - Nothing + _ - Nothing _ - Nothing -- If an Int value is larger than 2^28 or smaller ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: [commit: ghc] master: Convert haddock into a proper submodule (re #8545) (34b0721)
OK. Some questions. · Where is a good place to get a conceptual understanding of submodules? Concerning https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules · Under Updating an existing source tree clone you say we have to do git submodule update --init. What happens if we forget? Couldn't sync-all do that? (Indeed it now emits a message to that effect bash$ ./sync-all pull --rebase ... From http://git.haskell.org/packages/dph aeef7aa..2984641 master - origin/master 962c999..556e09c ghc-7.8- origin/ghc-7.8 First, rewinding head to replay your work on top of it... Fast-forwarded master to 2984641ae0c4739b168ee1fb956fd54f741f30e7. == running git pull --rebase remote: Counting objects: 581, done. remote: Compressing objects: 100% (276/276), done. remote: Total 420 (delta 327), reused 189 (delta 142) Receiving objects: 100% (420/420), 74.21 KiB, done. Resolving deltas: 100% (327/327), completed with 108 local objects. From http://git.haskell.org/ghc df409de..15b1eb7 master - origin/master abb86ad..a617888 ghc-7.8- origin/ghc-7.8 * [new branch] wip/T8545-ghc-7.8 - origin/wip/T8545-ghc-7.8 * [new branch] wip/recurs-compat - origin/wip/recurs-compat First, rewinding head to replay your work on top of it... Applying: Add missing kind-check for tcEqType on forall-types Applying: Don't export isTcReflCo_maybe (unused) Applying: Comments only Applying: For equalities with incompatible kinds, new IrredCan goes in the inert set, not work list Applying: Debug tracing only Applying: Flattener preserves synonyms, rewriteEvidence can drop buggy optimisation Applying: Implicit parameters should not be allowed in class and instance declarations Applying: Comments only == running git submodule update == Checking for old haddock repo == Checking for old binary repo · Under “Overriding pushurl”, same question. Couldn’t that long “git submodule foreach” command be done by sync-all? · Under “Making changes”, this looks hard to me. Is “base” a submodule? Does that mean we have to remember to do some incantations before we modify base? What if you forget and make the modifications first? Again, could some of this be automated, at least for the common workflow of pull/push? Thanks for working on this Simon · | -Original Message- | From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com] | Sent: 23 March 2014 21:03 | To: Simon Peyton Jones | Cc: ghc-devs@haskell.org | Subject: Re: [commit: ghc] master: Convert haddock into a proper | submodule (re #8545) (34b0721) | | On 2014-03-23 at 19:53:55 +0100, Simon Peyton Jones wrote: | Do us naïve users need to change our workflow with these submodule | changes? | | Probably yes... to some extent at least; that's why only haddock.git has | been converted for now[1]: to find out empirically what's involved | before continuing with the submodule-conversion. | | I've tried to describe one possible workflow (for if you need to publish | a modification to haddock.git) at | | | https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#MakingchangestoGHCsubmodules | MakingchangestoGHCsubmoduleshttps://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#MakingchangestoGHCsubmodules | | I hope it makes a bit of sense :-) | | IMO, it's quite useful to familiarize oneself with the 'git submodule' | family of commands, and especially 'git submodule' and 'git submodule | summary', as those two introspection commands allow one to get a better | picture in which state the currently cloned GHC working tree's | submodules are. | | [1]: OTOH, haddock.git is not the first/only proper Git submodule we | have so far; so, in some way this isn't much of a change... ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a POSIX way (fixes #8781) (e7563ec)
On 03/24/2014 08:39 AM, Karel Gardas wrote:
Guys,
could you be so kind and test attached patch?
The 32-bit Windows machine is at home; I will try your patch at night.
Fairly certain that it works, though. A very similar patch (which I was
just going to propose here) worked for me yesterday night:
_ - Nothing
_ - Nothing
+[('_':x0), C, x1] -
+ do name - stripPrefix prefix x0
+case readHex x1 of
+ [(size, )] - return (name,size)
+ _- fail not a size
_ - Nothing
(using do-notation for Maybe, assuming exactly one _)
/ Jost
Thanks!
Karel
On 03/24/14 07:49 AM, kyra wrote:
On 3/23/2014 20:51, Jost Berthold wrote:
Hello,
With the patch to deriveConstants, a build on an older Windows (32bit
Vista, MinGW32 installation, which used to work) now fails with error
Can't find STD_HDR_SIZE
Same here: Windows 64-bit, MSYS2, nm being called is from binutils 2.24.
Kyra
___
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
7.8.1 RC testsuite failures for 64bit unregisterised builds
(changing Subject to fork this to a separate thread) On 23 March 2014 21:42, Peter Trommler ptromm...@me.com wrote: On 23.03.2014, at 11:44, Jens Petersen peter...@fedoraproject.org wrote: Speaking of ppc64: Do you see ticket #8849 too? Does it show up in the testsuite results too? Yes, in fact I noticed the error in test arith005 and extracted the small test case for #8849. Okay I did a ppc64 build with the testsuite: http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1731757 and reproduced #8849 and (probably) #8819 too. I say probably since my ppc64 testsuite results are littered with Actual stderr output differs from expected: warnings caused by: + +In file included from /usr/include/math.h:26:0: +0, + from /builddir/build/BUILD/ghc-7.8.0.20140228/includes/Stg.h:65, + from /tmp/ghc25682_0/ghc25682_3.hc:3: + +/usr/include/features.h:148:3: + warning: #warning _BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE [-Wcpp] + # warning _BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE + ^ I only see those on ppc64 so far. Perhaps there is some way to ignore those? In #8819 I reported test failures in an unregisterised compiler produced on my x86_64 machine using an unregisterised ghc. Almost all arith tests including arith005 fail and I suspect it might be a data layout issue. I wonder if you can reproduce #8819 on ppc64. #8849 makes me think yes. I reproduced also on s390x: http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1369051 including #8819 unfortunately !! So seems this happens on ppc64, s390x and x86_64 for unregisterised. I know unregisterised may be considered less supported these days but this seems quite serious and I hope it could still be fixed for 7.8.1. Jens ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a POSIX way (fixes #8781) (e7563ec)
On 03/24/14 09:54 AM, Jost Berthold wrote: On 03/24/2014 08:39 AM, Karel Gardas wrote: Guys, could you be so kind and test attached patch? The 32-bit Windows machine is at home; I will try your patch at night. Fairly certain that it works, though. Indeed, it's working on your testing line you have provided. I just would like to know if it works on bootstrap too as I don't have win/ghc machine here. Thanks for testing! Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Convert haddock into a proper submodule (re #8545) (34b0721)
Hello Simon,
On 2014-03-24 at 09:37:32 +0100, Simon Peyton Jones wrote:
OK. Some questions.
· Where is a good place to get a conceptual understanding of
submodules?
There were three links at the top of the Wiki page; I assume you want
something better than that?
Concerning
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules
· Under Updating an existing source tree clone you say we have to do
git submodule update --init. What happens if we forget? Couldn't
sync-all do that? (Indeed it now emits a message to that effect
sync-all can do that of course; at this point, I'm just collecting all
direct `git` commands one would have to enter if there wasn't a sync-all
script -- once everything is in place, a new radically stripped down
`sync-all` can be constructed for the common day-to-day invocations.
The page also aims to make the underlying Git commands more transparent,
with the hope that by explaining what happens under the hood, it may
become less confusing when `sync-all` fails.
bash$ ./sync-all pull --rebase
Yes, sync-all does already call `git submodule update` in some occasions
already, but its current implementation is far more confusing than it
needs to be IMHO :-)
· Under “Overriding pushurl”, same question. Couldn’t that long “git
submodule foreach” command be done by sync-all?
yes, it will
(even though that specific invocation will be taken core by sync-all in
the future, that snippet serves as an example for the versatile 'git
submodule foreach' tool everyone working with submodules should at least
know about -- it's not that far-fetched that one might want to do
something non-standard sync-all doesn't handle)
· Under “Making changes”, this looks hard to me. Is “base” a
submodule?
Does that mean we have to remember to do some incantations before we
modify base?
Actually, we're strongly considering to fold the non-upgradable
GHC-specific packages tied to GHC, namely
- base
- ghc-prim
- integer-{gmp,simple}
- template-haskell
into ghc.git (as was done with testsuite/) as those wouldn't benefit
much from remaining an independent (submodule) repo anyway;
What if you forget and make the modifications first? Again, could
some of this be automated, at least for the common workflow of
pull/push?
for one, if you forget to associate a Git branch before committing on a
detached-HEAD, you can simply 'git push origin HEAD:master'
If you meant about forgetting to update ghc.git to point to the new
commit, then that's actually a feature to avoid *having* to track each
single push/commit to master of a submodule to ghc.git's master branch
as well; For instance, utils/haddock 'master' is currently one rather
unimportant commit[1] ahead of what 'ghc.git' references as its
haddock.git commit right now.
[1]:
http://git.haskell.org/haddock.git/commitdiff/f3c7cd34d066cd40cb4983893165de038974fd95
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a POSIX way (fixes #8781) (e7563ec)
On 24/03/2014 06:49, kyra wrote: On 3/23/2014 20:51, Jost Berthold wrote: Hello, With the patch to deriveConstants, a build on an older Windows (32bit Vista, MinGW32 installation, which used to work) now fails with error Can't find STD_HDR_SIZE Same here: Windows 64-bit, MSYS2, nm being called is from binutils 2.24. I also ran into this when I tried to do a Windows build today, so I've reverted the patch in my local tree. Karel: will you look into this? Note that on Windows, nm is part of the mingw tools that we provide in ghc-tarballs/, so if that needs upgrading we'll need to commit new versions of the tools (for both 32 and 64-bit mingw). Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a POSIX way (fixes #8781) (e7563ec)
Hi,
sorry, I've missed this thread.
Did you just run nm or nm -P on
includes/dist-derivedconstants/header/tmp.o?
The comment should say how the output looks like. For GNU nm (without
option -P) is was:
000b C derivedConstantMAX_Vanilla_REG
if it is now:
_derivedConstantBlaBlah_Blah C 01b
for nm -P on Windows the patch could (and should) be adjusted, easily.
(The 4th word only needs to be present and taken if the second word is
not a C, which is only the case under Solaris.)
HTH Christian
Am 23.03.2014 17:51, schrieb Jost Berthold:
Hello,
With the patch to deriveConstants, a build on an older Windows (32bit
Vista, MinGW32 installation, which used to work) now fails with error
Can't find STD_HDR_SIZE
I ran the nm command manually on the generated o file
(includes/dist-derivedconstants/header/tmp.o) and saw that the output
follows pattern
_derivedConstantBlaBlah_Blah C 01b
so it does not match the four-word pattern in the patch.
Is this a problem with my setup, or does it fail for other people on
Windows as well?
Thanks,
Jost
On 03/23/2014 08:46 AM, ghc-commits-requ...@haskell.org wrote:
Message: 6
Date: Sun, 23 Mar 2014 02:01:50 + (UTC)
From: g...@git.haskell.org
To: ghc-comm...@haskell.org
Subject: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a
POSIX way (fixes #8781) (e7563ec)
Message-ID: 20140323020150.1dce824...@ghc.haskell.org
Content-Type: text/plain; charset=utf-8
Repository : ssh://g...@git.haskell.org/ghc
On branch : ghc-7.8
Link :
http://ghc.haskell.org/trac/ghc/changeset/e7563ec2e03740074903036bf129fc972b623c23/ghc
---
commit e7563ec2e03740074903036bf129fc972b623c23
Author: Karel Gardas karel.gar...@centrum.cz
Date: Sat Mar 22 22:33:05 2014 +0100
change deriveConstants to use nm in a POSIX way (fixes #8781)
The patch provided by Christian Maeder christian.mae...@dfki.de
Signed-off-by: Karel Gardas karel.gar...@centrum.cz
Signed-off-by: Austin Seipp aus...@well-typed.com
(cherry picked from commit 045b28033a33a48d31951240a8cb35f2b78345dc)
---
e7563ec2e03740074903036bf129fc972b623c23
utils/deriveConstants/DeriveConstants.hs | 30
++
1 file changed, 10 insertions(+), 20 deletions(-)
diff --git a/utils/deriveConstants/DeriveConstants.hs
b/utils/deriveConstants/DeriveConstants.hs
index 10df61c..54ee6a1 100644
--- a/utils/deriveConstants/DeriveConstants.hs
+++ b/utils/deriveConstants/DeriveConstants.hs
@@ -638,7 +638,7 @@ getWanted verbose tmpdir gccProgram gccFlags
nmProgram
oFile = tmpdir / tmp.o
writeFile cFile cStuff
execute verbose gccProgram (gccFlags ++ [-c, cFile, -o,
oFile])
- xs - readProcess nmProgram [oFile]
+ xs - readProcess nmProgram [-P, oFile]
let ls = lines xs
ms = map parseNmLine ls
m = Map.fromList $ catMaybes ms
@@ -707,27 +707,17 @@ getWanted verbose tmpdir gccProgram gccFlags
nmProgram
doWanted (ClosurePayloadMacro {}) = []
doWanted (FieldTypeGcptrMacro {}) = []
- -- parseNmLine parses nm output that looks like
- -- 000b C derivedConstantMAX_Vanilla_REG
+ -- parseNmLine parses nm -P output that looks like
+ -- _derivedConstantMAX_Vanilla_REG C b 0 Mac OS X
+ -- derivedConstantMAX_Vanilla_REG C 000b 000b GNU
+ -- derivedConstantMAX_Vanilla_REG D1b
Solaris
-- and returns (MAX_Vanilla_REG, 11)
- parseNmLine xs0 = case break (' ' ==) xs0 of
-(x1, ' ' : xs1) -
-case break (' ' ==) xs1 of
-(x2, ' ' : x3) -
-case readHex x1 of
-[(size, )] -
-case x2 of
-C -
-let x3' = case x3 of
- '_' : rest - rest
- _ - x3
-in case stripPrefix
prefix x3' of
- Just name -
- Just (name, size)
- _ - Nothing
-_ - Nothing
-_ - Nothing
+ parseNmLine xs0 = case words xs0 of
+[x0, x1, x2, x3] - case stripPrefix
prefix $ dropWhile (== '_') x0 of
+ Just name - case readHex $ if x1 ==
C then x2 else x3 of
+[(size, )] - Just (name, size)
_ - Nothing
FW: [commit: ghc] master: Add missing kind-check for tcEqType on forall-types (74894e0)
Austin, this one looks like a bug waiting to happen, so let's merge if time. Simon -Original Message- From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf Of g...@git.haskell.org Sent: 24 March 2014 10:27 To: ghc-comm...@haskell.org Subject: [commit: ghc] master: Add missing kind-check for tcEqType on forall-types (74894e0) Repository : ssh://g...@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/74894e0bc405247092e865b9541f5f18d26aa015/ghc --- commit 74894e0bc405247092e865b9541f5f18d26aa015 Author: Simon Peyton Jones simo...@microsoft.com Date: Fri Mar 21 15:24:49 2014 + Add missing kind-check for tcEqType on forall-types This wasn't showing up as a bug, but it was definitely wrong. --- 74894e0bc405247092e865b9541f5f18d26aa015 compiler/typecheck/TcType.lhs |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/compiler/typecheck/TcType.lhs b/compiler/typecheck/TcType.lhs index 9b58b4c..08c7a62 100644 --- a/compiler/typecheck/TcType.lhs +++ b/compiler/typecheck/TcType.lhs @@ -245,7 +245,6 @@ checking. It's attached to mutable type variables only. It's knot-tied back to Var.lhs. There is no reason in principle why Var.lhs shouldn't actually have the definition, but it belongs here. - Note [Signature skolems] Consider this @@ -1008,7 +1007,8 @@ tcEqType ty1 ty2 | Just t2' - tcView t2 = go env t1 t2' go env (TyVarTy tv1) (TyVarTy tv2) = rnOccL env tv1 == rnOccR env tv2 go _ (LitTy lit1)(LitTy lit2) = lit1 == lit2 -go env (ForAllTy tv1 t1) (ForAllTy tv2 t2) = go (rnBndr2 env tv1 tv2) t1 t2 +go env (ForAllTy tv1 t1) (ForAllTy tv2 t2) = go env (tyVarKind tv1) (tyVarKind tv2) + go (rnBndr2 env tv1 + tv2) t1 t2 go env (AppTy s1 t1) (AppTy s2 t2) = go env s1 s2 go env t1 t2 go env (FunTy s1 t1) (FunTy s2 t2) = go env s1 s2 go env t1 t2 go env (TyConApp tc1 ts1) (TyConApp tc2 ts2) = (tc1 == tc2) gos env ts1 ts2 @@ -1027,7 +1027,8 @@ pickyEqType ty1 ty2 init_env = mkRnEnv2 (mkInScopeSet (tyVarsOfType ty1 `unionVarSet` tyVarsOfType ty2)) go env (TyVarTy tv1) (TyVarTy tv2) = rnOccL env tv1 == rnOccR env tv2 go _ (LitTy lit1)(LitTy lit2) = lit1 == lit2 -go env (ForAllTy tv1 t1) (ForAllTy tv2 t2) = go (rnBndr2 env tv1 tv2) t1 t2 +go env (ForAllTy tv1 t1) (ForAllTy tv2 t2) = go env (tyVarKind tv1) (tyVarKind tv2) + go (rnBndr2 env tv1 + tv2) t1 t2 go env (AppTy s1 t1) (AppTy s2 t2) = go env s1 s2 go env t1 t2 go env (FunTy s1 t1) (FunTy s2 t2) = go env s1 s2 go env t1 t2 go env (TyConApp tc1 ts1) (TyConApp tc2 ts2) = (tc1 == tc2) gos env ts1 ts2 ___ ghc-commits mailing list ghc-comm...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a POSIX way (fixes #8781) (e7563ec)
On 03/24/2014 11:25 AM, Christian Maeder wrote: Hi, sorry, I've missed this thread. Did you just run nm or nm -P on includes/dist-derivedconstants/header/tmp.o? I ran nm -P. The comment should say how the output looks like. For GNU nm (without option -P) is was: 000b C derivedConstantMAX_Vanilla_REG if it is now: _derivedConstantBlaBlah_Blah C 01b for nm -P on Windows the patch could (and should) be adjusted, easily. (The 4th word only needs to be present and taken if the second word is not a C, which is only the case under Solaris.) The output (with option -P) was _derivedConstantBlaBlah_Blah C 01b I agree the code of the previous patch is easy to adjust. While several ways are possible, my own suggestion was to add a new specialised case rather than trying to integrate into the existing code. / Jost ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: help understanding the validate_build_xhtml failure of ./validate for my CPP patch
On 23 Mar 2014, at 20:33, Carter Schonwald wrote: Hey all, I'm trying to get my CPP_Setttings patch to validate, and i'm trying to understand why my validate is failing. At this point im stumped and I really could use some help! This looks like the key information: Building xhtml-3000.2.1... Preprocessing library xhtml-3000.2.1... ghc: could not execute: Ghc is reporting that it could not execute . This suggests the commandline for external preprocessing is incorrectly formed. Regards, Malcolm ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a POSIX way (fixes #8781) (e7563ec)
On 03/24/14 11:06 AM, Simon Marlow wrote: On 24/03/2014 06:49, kyra wrote: On 3/23/2014 20:51, Jost Berthold wrote: Hello, With the patch to deriveConstants, a build on an older Windows (32bit Vista, MinGW32 installation, which used to work) now fails with error Can't find STD_HDR_SIZE Same here: Windows 64-bit, MSYS2, nm being called is from binutils 2.24. I also ran into this when I tried to do a Windows build today, so I've reverted the patch in my local tree. Karel: will you look into this? I already provided a fix for testing on this mailing list. Jost (original reporter) promised to do that during the night on his home machine. If it's working, I'll prepare complete git patch immediately and attach to the #8781 for Austin. Perhaps you can test it too? Thanks! Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: We need to add role annotations for 7.8
When Brandon says “potential bugs/unsafety and all” he means GeneralisedNewtypeDeriving (GND). That already exists, and already allows you to do bad things (Trac #1496 among others). See the thread on https://ghc.haskell.org/trac/ghc/ticket/8827, starting especially at comment 17 for more discussion and some insightful comments. As Edward (on the ticket) and Brandon (here) point out, going to “nominal by default” will be very safe but it’ll break many Haskell packages which use GND. This is really a library/user question, not a GHC one. We can implement whatever default you want. But GHC 7.8 is about to be released and this debate has been going on for some weeks, at high intensity on ghc-devs, plus Richard specifically advertised it to the libraries list back in Novemberhttp://www.haskell.org/pipermail/libraries/2013-November/021707.html, and again a couple of weeks agohttp://www.haskell.org/pipermail/libraries/2014-March/022321.html. I think the status quo is not unreasonable. One question you might want to debate is whether, as Brandon suggests, you want to move to “nominal by default” in due course. Simon From: Libraries [mailto:libraries-boun...@haskell.org] On Behalf Of Brandon Allbery Sent: 24 March 2014 14:28 To: Mark Lentczner Cc: GHC Development Mailing List; librar...@haskell.org Libraries Subject: Re: We need to add role annotations for 7.8 On Mon, Mar 24, 2014 at 10:14 AM, Mark Lentczner mark.lentcz...@gmail.commailto:mark.lentcz...@gmail.com wrote: On Fri, Mar 14, 2014 at 2:36 AM, Johan Tibell johan.tib...@gmail.commailto:johan.tib...@gmail.com wrote: I'm quite worried about this change though. I thought the default role for data type was nominal, as that's the safe default. If the default is representational, every package author will need to be aware of this feature and update their packages. That's quite a high cost. On Fri, Mar 14, 2014 at 6:00 AM, Brandon Allbery allber...@gmail.commailto:allber...@gmail.com wrote: Nominal default breaks everything that uses newtype deriving and doesn't have role annotations, doesn't it? Representational default means things behave in 7.8 as they did in earlier GHCs. Am I reading these pair of statements correctly? It seems to imply to me that every parameterized type that uses a type constraint on a parameter must be reviewed and possibly annotated to work correctly, one way or the other! No; if the default is representational, everything works as it did in earlier versions, potential bugs/unsafety and all. If the default is immediately switched to nominal, *then* every affected type must be reviewed immediately. My counter-proposal was to have 7.8 default to representational to give library maintainers a release cycle to add the necessary annotations, then switch the default to nominal in 7.10 to get the additional safety. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.commailto:allber...@gmail.com ballb...@sinenomine.netmailto:ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: We need to add role annotations for 7.8
Thanks for the pointers, Simon. I appologize for coming to this quite so late... I didn't realize the global impact of this feature. From a meaning perspective, I'm agnostic on the default. From a engineering perspective, I want a default that does a good enough, reasonably safe thing if programmers ignore the feature. The later is subtle as there are different vantage points for different developers. In the Platform, we have many libraries that we are encouraging both end-programmers, and other library authors to make use of and depend on extensively. This means those libraries have to work for both programmers that are ignoring the feature, and those that use it. In that later case, there is the even more subtle distinction of those that use the feature for their own code, and those that use it in libraries they make available. The later case is issue: It seems a real mess if a library author who wanted to use the new feature, had to circumvent a HP library because it didn't annotate. Similar thought experiment: What would be the downside if containers didn't annotate? Would that just make the feature unusable because everything uses containers? To put it more directly: with the satus-quo default of representations, what is the down side if a library, a widely used library, doesn't bother to annotate? What would be the loss if containers didn't annotate? (I know it did, this is the thought experiment... because I've got 30+ libraries in HP that are in this boat.) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: We need to add role annotations for 7.8
Again, sorry for the 11:59 meddling The syntax of role annotations is very heavy weight, and requires lots of CPP where there wasn't need before. Two thoughts: 1) Couldn't we do something like use cue type constraints? For example, assuming the default is representational, and that phantom can just be inferred, all we need is a way to indicate nominal: data (Nominal k) = Map k v = ... This could then probably be easily made to compile in other compilers with some null library implementation of Nominal 2) An alternative to the above. We generally frown on constraints in a data / newtype declaration, but perhaps this is exactly the case for them, whereby we can now do away with the type role syntax: We can infer nominal if there are *any* constraints on a type parameter, *representational* if there are none, and *phantom *if there are no mentions in the right hand side: data (Eq k) = Map k v = ... This seems even nicer and just works with all compilers... but perhaps I'm missing something. (Yes, I imagine there are type constraints that shouldn't force nominal, but perhaps not worth worrying about?) Mind you, this all just about syntax... the issue of what is the implication for libraries of the default being representational is still at hand. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
module ‘free-4.6.1:Main’ is defined in multiple files
Greetings, First of all to people reading this at ghc-devs, I don't expect this to be a direct problem caused by GHC but who knows, so I'm CC'ing it anyway. As you might know, GHC 7.8.1 is scheduled to release Very Soon™ (later today?). We got a report at Haddock Trac few weeks ago about a strange error, see http://trac.haskell.org/haddock/ticket/284. I have asked about this on cabal-devel before and Mikhail said that maybe it's https://github.com/haskell/cabal/pull/1374 but it's unlikely because the changes aren't ran by default. Today I got new reports of this problem and so far everyone on OSX seems to be affected! This suddenly became a big problem. To replicate: 1. Find OSX machine 2. Get GHC 7.8 rc2 package (which includes Haddock at that stage) 3. git clone g...@github.com:ekmett/free.git cd free 4. cabal install --only-dependencies --enable-documentation cabal configure cabal haddock The reason I'm barking up cabal-devel and ghc-devs is because I honestly can not think of anything that has changed since Haddock 2.13.2.1 that could possibly cause this. Does anyone have any idea at all? I think it would be very bad to release now and have everyone on OSX unable to build docs. FYI I get build docs on 32-bit Linux. No idea about Windows. Thanks, I hope to hear back soon. PS: How does one go about downgrading Cabal and cabal-install? If we wanted to check whether cabal is the problem, how? -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Merge CmpNat and CmpSymbol in 7.8
Hi, based on requests from a couple of people I added a couple of type-level functions for type nats and type symbols. Could we get these merged in 7.8? The relevant commits are: In GHC: 5e4bdb5fc5e741522cbb787731422da3f12aa398 Implement ordering comparisons for type-level naturals and symbols. In base: 5edb063688e73ec00fd1f61ac0e8317dd122f44a Comments only. c1d3546420ee482bbbd9f15d45a6e8a26304d419 Add functions for comparing type-level Nats and Symbols. Thanks! -Iavor ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: We need to add role annotations for 7.8
Mark, We're currently planning to retain the existing behavior of GeneralizedNewtypeDeriving with regards to Safe Haskell. That is, Safe Haskell and GND still won't mix in 7.8 due to these same security concerns. I think a key observation with regards to GeneralizedNewtypeDeriving is with representational roles as default the new roles machinery with the representational default lets you write nothing you couldn't write before. No new security vulnerabilities are introduced. They were there all along! We're also disabling the Safe flag on Data.Coerce. In that light, `coerce` then can be viewed as a more friendly but still evil version of unsafeCoerce. It lets you write nothing you couldn't write before with `unsafeCoerce`. I view it as merely an occasional situational improvement over the existing unsafeCoerce in that it at least enforces representational equality. Making the default role annotation nominal comes at a very very real cost. Namely, *all* of generalized newtype deriving anywhere breaks, and everyone forever will have to put annotations in to fix it. The 'backwards' representational default puts the burden on a small minority of library authors. I'm not a huge fan of the representational machinery, in that it hoists us upon this dilemma, but given the choice between everyone paying in perpetuity and a small minority of skilled library authors adding a handful of annotations that for the most part have already been added, and which expose them to no more risk than they'd had before if they forget, I'm definitely in favor of the current solution. -Edward On Mon, Mar 24, 2014 at 11:26 AM, Mark Lentczner mark.lentcz...@gmail.comwrote: Thanks for the pointers, Simon. I appologize for coming to this quite so late... I didn't realize the global impact of this feature. From a meaning perspective, I'm agnostic on the default. From a engineering perspective, I want a default that does a good enough, reasonably safe thing if programmers ignore the feature. The later is subtle as there are different vantage points for different developers. In the Platform, we have many libraries that we are encouraging both end-programmers, and other library authors to make use of and depend on extensively. This means those libraries have to work for both programmers that are ignoring the feature, and those that use it. In that later case, there is the even more subtle distinction of those that use the feature for their own code, and those that use it in libraries they make available. The later case is issue: It seems a real mess if a library author who wanted to use the new feature, had to circumvent a HP library because it didn't annotate. Similar thought experiment: What would be the downside if containers didn't annotate? Would that just make the feature unusable because everything uses containers? To put it more directly: with the satus-quo default of representations, what is the down side if a library, a widely used library, doesn't bother to annotate? What would be the loss if containers didn't annotate? (I know it did, this is the thought experiment... because I've got 30+ libraries in HP that are in this boat.) ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: We need to add role annotations for 7.8
I have a few responses to various themes in this thread, but nothing terribly unexpected: - The introduction of roles is the end of the story that began with the discovery of bug #1496. The alternative would be to do away with GND. `coerce` is just a convenient application of roles, not the reason they were introduced. - The concrete syntax for role ascriptions was debated in public, in bug #8185. There is further discussion of the design choice in the appendix of the extended version of our recent draft paper on the subject: www.cis.upenn.edu/~eir/papers/2014/coercible/coercible-ext.pdf I'm afraid it's too late now to make changes. I don't love what we ended up with, but I believe it's the best syntax that was proposed. - I agree with Simon that `coerce` is quite a bit safer than `unsafeCoerce`. Under the assumption that all libraries are written correctly (that is, with proper role annotations), `coerce` is in fact fully safe. - I surely recognize why and how this causes a Major Pain for Mark, and for other library maintainers. I wish there were an easier solution. However, I will perhaps repeat others in saying that a library that doesn't add role annotations is no more wrong in 7.8 than it was since GND was introduced. The only difference with 7.8 is that, now, there is a way to be right. Richard On Mar 24, 2014, at 9:32 PM, Edward A Kmett wrote: Fair enough. I did try to convey that in the following sentence about how it at least enforces representational equality, but I can see how my statement might be taken as understating the importance of that property. Sent from my iPhone On Mar 24, 2014, at 6:57 PM, Simon Peyton Jones simo...@microsoft.com wrote: In that light, `coerce` then can be viewed as a more friendly but still evil version of unsafeCoerce Coerce embodies one rather compelling improvement: it is type-sound. unsafeCoerce can cause arbitrary seg-faults etc. ‘coerce’ cannot. Call me an old-fashioned “well-typed programs don’t go wrong” man, but I think that’s a big plus. Much more than “an occasional situation improvement”. Granted, “type-sound” doesn’t guarantee “correct”, but then it never did. The role machinery doesn’t exactly hoist us on a dilemma – it merely exposes the dilemma that was there all the time. Simon From: Edward Kmett [mailto:ekm...@gmail.com] Sent: 24 March 2014 19:11 To: Mark Lentczner Cc: Simon Peyton Jones; librar...@haskell.org Libraries; ghc-devs@haskell.org Subject: Re: We need to add role annotations for 7.8 Mark, We're currently planning to retain the existing behavior of GeneralizedNewtypeDeriving with regards to Safe Haskell. That is, Safe Haskell and GND still won't mix in 7.8 due to these same security concerns. I think a key observation with regards to GeneralizedNewtypeDeriving is with representational roles as default the new roles machinery with the representational default lets you write nothing you couldn't write before. No new security vulnerabilities are introduced. They were there all along! We're also disabling the Safe flag on Data.Coerce. In that light, `coerce` then can be viewed as a more friendly but still evil version of unsafeCoerce. It lets you write nothing you couldn't write before with `unsafeCoerce`. I view it as merely an occasional situational improvement over the existing unsafeCoerce in that it at least enforces representational equality. Making the default role annotation nominal comes at a very very real cost. Namely, all of generalized newtype deriving anywhere breaks, and everyone forever will have to put annotations in to fix it. The 'backwards' representational default puts the burden on a small minority of library authors. I'm not a huge fan of the representational machinery, in that it hoists us upon this dilemma, but given the choice between everyone paying in perpetuity and a small minority of skilled library authors adding a handful of annotations that for the most part have already been added, and which expose them to no more risk than they'd had before if they forget, I'm definitely in favor of the current solution. -Edward On Mon, Mar 24, 2014 at 11:26 AM, Mark Lentczner mark.lentcz...@gmail.com wrote: Thanks for the pointers, Simon. I appologize for coming to this quite so late... I didn't realize the global impact of this feature. From a meaning perspective, I'm agnostic on the default. From a engineering perspective, I want a default that does a good enough, reasonably safe thing if programmers ignore the feature. The later is subtle as there are different vantage points for different developers. In the Platform, we have many libraries that we are encouraging both end-programmers, and other library authors to make use of and depend on extensively. This means those libraries have to work for both programmers
