Re: [commit: ghc] master: Revert Per-thread allocation counters and limits (f0fcc41)
Hello Simon, I'm sorry to disturb you, but I've noticed that your revert patch below contains this change: diff --git a/includes/CodeGen.Platform.hs b/includes/CodeGen.Platform.hs index f3abb3d..3d6dd41 100644 --- a/includes/CodeGen.Platform.hs +++ b/includes/CodeGen.Platform.hs @@ -741,8 +741,10 @@ globalRegMaybe CurrentTSO = Just (RealRegSingle REG_CurrentTSO) # ifdef REG_CurrentNursery globalRegMaybe CurrentNursery = Just (RealRegSingle REG_CurrentNursery) # endif -#endif globalRegMaybe _= Nothing +#else +globalRegMaybe = panic globalRegMaybe not defined for this platform +#endif and I'm not sure if this is intentional or just overlooked addition. The problem with this line is that it causes stage1 panic on unregisterised build on PPC64 platform: http://haskell.inf.elte.hu/builders/linux-ppc64-head/41/10.html and we have not had such panic before the patch: http://haskell.inf.elte.hu/builders/linux-ppc64-head/31/10.html -- well, you see that dll-split segfaults, but at least ghc-stage1 is proved to work well here. Kudos to Gabor Pali who spotted this on PPC64 builder... Thanks! Karel On 05/ 4/14 11:45 PM, g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/f0fcc41d755876a1b02d1c7c79f57515059f6417/ghc --- commit f0fcc41d755876a1b02d1c7c79f57515059f6417 Author: Simon Marlowmarlo...@gmail.com Date: Sun May 4 20:27:42 2014 +0100 Revert Per-thread allocation counters and limits Problems were found on 32-bit platforms, I'll commit again when I have a fix. This reverts the following commits: 54b31f744848da872c7c6366dea840748e01b5cf b0534f78a73f972e279eed4447a5687bd6a8308e --- f0fcc41d755876a1b02d1c7c79f57515059f6417 compiler/cmm/CmmLayoutStack.hs | 9 +- compiler/codeGen/StgCmmForeign.hs | 268 ++--- includes/CodeGen.Platform.hs | 4 +- includes/rts/Constants.h | 6 - includes/rts/Flags.h | 8 - includes/rts/Threads.h | 8 +- includes/rts/storage/TSO.h | 31 +-- libraries/base/Control/Exception.hs| 1 - libraries/base/Control/Exception/Base.hs | 1 - libraries/base/GHC/Conc.lhs| 6 - libraries/base/GHC/Conc/Sync.lhs | 92 +-- libraries/base/GHC/IO/Exception.hs | 21 +- rts/HeapStackCheck.cmm | 4 +- rts/Linker.c | 4 - rts/Prelude.h | 2 - rts/RaiseAsync.c | 54 - rts/RaiseAsync.h | 4 - rts/RtsFlags.c | 10 - rts/RtsStartup.c | 1 - rts/Schedule.c | 19 -- rts/Threads.c | 77 +++--- rts/package.conf.in| 2 - rts/sm/Storage.c | 6 - rts/win32/libHSbase.def| 1 - testsuite/tests/concurrent/should_run/all.T| 7 - .../tests/concurrent/should_run/allocLimit1.hs | 9 - .../tests/concurrent/should_run/allocLimit1.stderr | 1 - .../tests/concurrent/should_run/allocLimit2.hs | 17 -- .../tests/concurrent/should_run/allocLimit3.hs | 15 -- .../tests/concurrent/should_run/allocLimit3.stderr | 1 - .../tests/concurrent/should_run/allocLimit3.stdout | 1 - .../tests/concurrent/should_run/allocLimit4.hs | 31 --- utils/deriveConstants/DeriveConstants.hs | 1 - 33 files changed, 144 insertions(+), 578 deletions(-) Diff suppressed because of size. To see it, use: git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc f0fcc41d755876a1b02d1c7c79f57515059f6417 ___ 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] master: Revert Per-thread allocation counters and limits (f0fcc41)
Hi Karel, This issue is ticket #9055, which also contains a patch. Could we please merge it? Peter On 13.05.2014, at 08:30, Karel Gardas karel.gar...@centrum.cz wrote: Hello Simon, I'm sorry to disturb you, but I've noticed that your revert patch below contains this change: diff --git a/includes/CodeGen.Platform.hs b/includes/CodeGen.Platform.hs index f3abb3d..3d6dd41 100644 --- a/includes/CodeGen.Platform.hs +++ b/includes/CodeGen.Platform.hs @@ -741,8 +741,10 @@ globalRegMaybe CurrentTSO = Just (RealRegSingle REG_CurrentTSO) # ifdef REG_CurrentNursery globalRegMaybe CurrentNursery = Just (RealRegSingle REG_CurrentNursery) # endif -#endif globalRegMaybe _= Nothing +#else +globalRegMaybe = panic globalRegMaybe not defined for this platform +#endif and I'm not sure if this is intentional or just overlooked addition. The problem with this line is that it causes stage1 panic on unregisterised build on PPC64 platform: http://haskell.inf.elte.hu/builders/linux-ppc64-head/41/10.html and we have not had such panic before the patch: http://haskell.inf.elte.hu/builders/linux-ppc64-head/31/10.html -- well, you see that dll-split segfaults, but at least ghc-stage1 is proved to work well here. Kudos to Gabor Pali who spotted this on PPC64 builder... Thanks! Karel On 05/ 4/14 11:45 PM, g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/f0fcc41d755876a1b02d1c7c79f57515059f6417/ghc --- commit f0fcc41d755876a1b02d1c7c79f57515059f6417 Author: Simon Marlowmarlo...@gmail.com Date: Sun May 4 20:27:42 2014 +0100 Revert Per-thread allocation counters and limits Problems were found on 32-bit platforms, I'll commit again when I have a fix. This reverts the following commits: 54b31f744848da872c7c6366dea840748e01b5cf b0534f78a73f972e279eed4447a5687bd6a8308e --- f0fcc41d755876a1b02d1c7c79f57515059f6417 compiler/cmm/CmmLayoutStack.hs | 9 +- compiler/codeGen/StgCmmForeign.hs | 268 ++--- includes/CodeGen.Platform.hs | 4 +- includes/rts/Constants.h | 6 - includes/rts/Flags.h | 8 - includes/rts/Threads.h | 8 +- includes/rts/storage/TSO.h | 31 +-- libraries/base/Control/Exception.hs| 1 - libraries/base/Control/Exception/Base.hs | 1 - libraries/base/GHC/Conc.lhs| 6 - libraries/base/GHC/Conc/Sync.lhs | 92 +-- libraries/base/GHC/IO/Exception.hs | 21 +- rts/HeapStackCheck.cmm | 4 +- rts/Linker.c | 4 - rts/Prelude.h | 2 - rts/RaiseAsync.c | 54 - rts/RaiseAsync.h | 4 - rts/RtsFlags.c | 10 - rts/RtsStartup.c | 1 - rts/Schedule.c | 19 -- rts/Threads.c | 77 +++--- rts/package.conf.in| 2 - rts/sm/Storage.c | 6 - rts/win32/libHSbase.def| 1 - testsuite/tests/concurrent/should_run/all.T| 7 - .../tests/concurrent/should_run/allocLimit1.hs | 9 - .../tests/concurrent/should_run/allocLimit1.stderr | 1 - .../tests/concurrent/should_run/allocLimit2.hs | 17 -- .../tests/concurrent/should_run/allocLimit3.hs | 15 -- .../tests/concurrent/should_run/allocLimit3.stderr | 1 - .../tests/concurrent/should_run/allocLimit3.stdout | 1 - .../tests/concurrent/should_run/allocLimit4.hs | 31 --- utils/deriveConstants/DeriveConstants.hs | 1 - 33 files changed, 144 insertions(+), 578 deletions(-) Diff suppressed because of size. To see it, use: git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc f0fcc41d755876a1b02d1c7c79f57515059f6417 ___ 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Revert Per-thread allocation counters and limits (f0fcc41)
On 05/13/14 10:06 AM, Peter Trommler wrote: Hi Karel, This issue is ticket #9055, which also contains a patch. Could we please merge it? I'm the second petitioner for the merge of your fix! Thanks a lot for pointing this out and providing the patch! Cheers, Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Revert Per-thread allocation counters and limits (f0fcc41)
It looks like I accidentally slipped that fix in with the allocation counters patch, and when the patch was reverted the fix was reverted too. I'll commit the fix from the patch (which is probably better, that's what I intended to do all along). Sorry for the mixup! Simon On 13/05/14 07:30, Karel Gardas wrote: Hello Simon, I'm sorry to disturb you, but I've noticed that your revert patch below contains this change: diff --git a/includes/CodeGen.Platform.hs b/includes/CodeGen.Platform.hs index f3abb3d..3d6dd41 100644 --- a/includes/CodeGen.Platform.hs +++ b/includes/CodeGen.Platform.hs @@ -741,8 +741,10 @@ globalRegMaybe CurrentTSO = Just (RealRegSingle REG_CurrentTSO) # ifdef REG_CurrentNursery globalRegMaybe CurrentNursery = Just (RealRegSingle REG_CurrentNursery) # endif -#endif globalRegMaybe _= Nothing +#else +globalRegMaybe = panic globalRegMaybe not defined for this platform +#endif and I'm not sure if this is intentional or just overlooked addition. The problem with this line is that it causes stage1 panic on unregisterised build on PPC64 platform: http://haskell.inf.elte.hu/builders/linux-ppc64-head/41/10.html and we have not had such panic before the patch: http://haskell.inf.elte.hu/builders/linux-ppc64-head/31/10.html -- well, you see that dll-split segfaults, but at least ghc-stage1 is proved to work well here. Kudos to Gabor Pali who spotted this on PPC64 builder... Thanks! Karel On 05/ 4/14 11:45 PM, g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/f0fcc41d755876a1b02d1c7c79f57515059f6417/ghc --- commit f0fcc41d755876a1b02d1c7c79f57515059f6417 Author: Simon Marlowmarlo...@gmail.com Date: Sun May 4 20:27:42 2014 +0100 Revert Per-thread allocation counters and limits Problems were found on 32-bit platforms, I'll commit again when I have a fix. This reverts the following commits: 54b31f744848da872c7c6366dea840748e01b5cf b0534f78a73f972e279eed4447a5687bd6a8308e --- f0fcc41d755876a1b02d1c7c79f57515059f6417 compiler/cmm/CmmLayoutStack.hs | 9 +- compiler/codeGen/StgCmmForeign.hs | 268 ++--- includes/CodeGen.Platform.hs | 4 +- includes/rts/Constants.h | 6 - includes/rts/Flags.h | 8 - includes/rts/Threads.h | 8 +- includes/rts/storage/TSO.h | 31 +-- libraries/base/Control/Exception.hs| 1 - libraries/base/Control/Exception/Base.hs | 1 - libraries/base/GHC/Conc.lhs| 6 - libraries/base/GHC/Conc/Sync.lhs | 92 +-- libraries/base/GHC/IO/Exception.hs | 21 +- rts/HeapStackCheck.cmm | 4 +- rts/Linker.c | 4 - rts/Prelude.h | 2 - rts/RaiseAsync.c | 54 - rts/RaiseAsync.h | 4 - rts/RtsFlags.c | 10 - rts/RtsStartup.c | 1 - rts/Schedule.c | 19 -- rts/Threads.c | 77 +++--- rts/package.conf.in| 2 - rts/sm/Storage.c | 6 - rts/win32/libHSbase.def| 1 - testsuite/tests/concurrent/should_run/all.T| 7 - .../tests/concurrent/should_run/allocLimit1.hs | 9 - .../tests/concurrent/should_run/allocLimit1.stderr | 1 - .../tests/concurrent/should_run/allocLimit2.hs | 17 -- .../tests/concurrent/should_run/allocLimit3.hs | 15 -- .../tests/concurrent/should_run/allocLimit3.stderr | 1 - .../tests/concurrent/should_run/allocLimit3.stdout | 1 - .../tests/concurrent/should_run/allocLimit4.hs | 31 --- utils/deriveConstants/DeriveConstants.hs | 1 - 33 files changed, 144 insertions(+), 578 deletions(-) Diff suppressed because of size. To see it, use: git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc f0fcc41d755876a1b02d1c7c79f57515059f6417 ___ 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
Many new validate failures, Synonym in TyConAppCo-related
Hi, I suddenly get Unexpected failures: gadt T7294 [exit code non-0] (normal) indexed-types/should_compile GADT1 [exit code non-0] (normal) indexed-types/should_compile GADT11 [exit code non-0] (normal) indexed-types/should_compile GADT3 [exit code non-0] (normal) indexed-types/should_compile IndTypesPerf [bad exit code] (normal) indexed-types/should_compile NonLinearLHS [exit code non-0] (normal) indexed-types/should_compile Numerals [exit code non-0] (normal) indexed-types/should_compile Roman1 [exit code non-0] (normal) indexed-types/should_compile Simple9 [exit code non-0] (normal) indexed-types/should_compile T2219 [exit code non-0] (normal) indexed-types/should_compile T2627 [exit code non-0] (normal) indexed-types/should_compile T3484 [exit code non-0] (normal) indexed-types/should_compile T4935 [exit code non-0] (normal) indexed-types/should_compile T7585 [exit code non-0] (normal) indexed-types/should_fail T2664a [exit code non-0] (normal) polykinds PolyKinds10 [exit code non-0] (normal) polykinds PolyKinds12 [exit code non-0] (normal) polykinds T6002 [exit code non-0] (normal) simplCore/should_compile T5329 [exit code non-0] (normal) simplCore/should_run T5315 [exit code non-0] (optasm) typecheck/should_compile T5490 [exit code non-0] (normal) typecheck/should_compile T7196 [exit code non-0] (normal) after these three changes were pushed: Changes to ghc: commit 214ad2d24cda4aaef541df3e213d5c4845f95c71 Author: Peter Trommler ptromm...@scm.org Date: Wed Apr 30 11:41:51 2014 +0200 Fix globalRegMaybe for unregisterised build. In commit 83a003f globalRegMaybe will be called but panics for unregisterised compilers. In an unregisterised compiler there are no global registers so always return `Nothing`. Fixes #9055. commit 21f17d06aa5c33e639f1b0d37b4bf888b494c441 Author: Simon Peyton Jones simo...@microsoft.com Date: Tue May 13 13:17:19 2014 +0100 Fix invariant in mkAppCoFlexible mkAppCoFlexible was breaking the invariant that the head of a TyConAppCo cannot be a type synonym. This small patch fixes it. commit 4cfc1fae11ec9a5c4b34ac747f0ce50f52423eba Author: Simon Peyton Jones simo...@microsoft.com Date: Tue May 13 13:15:45 2014 +0100 Lint should check that TyConAppCo doesn't have a synonym in the tycon position That is why Lint didn't nail Trac #9102 Full log at https://s3.amazonaws.com/archive.travis-ci.org/jobs/25063931/log.txt. It seems that most, if not all, fail with a Synonym in TyConAppCo lint error. If Lint is correct here, then this may indicate further bugs are around. But in that case the correct thing would be to have a ticket number for that problem and mark all failing test cases as expect_broken – it’s the only sensible way of having an always succeeding test suite in master. So is the Lint check correct and this uncovered one or more bugs here, or is the Lint check actually too restrictive? Greetings, Joachim Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F 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: Many new validate failures, Synonym in TyConAppCo-related
I see that the core-lint patch calls:
-- | Is this a 'TyCon' representing a type synonym (@type@)?
isSynTyCon :: TyCon - Bool
isSynTyCon (SynTyCon {}) = True
isSynTyCon _ = False
And from simon's comments it seems like he only wanted to check for normal
type synonyms.
'isSynTyCon' asserts to 'True' for many more tycons though, which include,
aside from normal type synonyms:
- type family tycons
- dictionary tycons
Most of the core lint errors seem to be due to the fact that 'TyConAppCo' is
applied to a type family tycon.
-- Christiaan
p.s. Regardless, I feel that the documentation for 'isSynTyCon' in misleading
as to what it actually asserts.
On May 13, 2014, at 4:16 PM, Joachim Breitner m...@joachim-breitner.de wrote:
Hi,
I suddenly get
Unexpected failures:
gadt T7294 [exit code non-0] (normal)
indexed-types/should_compile GADT1 [exit code non-0] (normal)
indexed-types/should_compile GADT11 [exit code non-0] (normal)
indexed-types/should_compile GADT3 [exit code non-0] (normal)
indexed-types/should_compile IndTypesPerf [bad exit code] (normal)
indexed-types/should_compile NonLinearLHS [exit code non-0]
(normal)
indexed-types/should_compile Numerals [exit code non-0] (normal)
indexed-types/should_compile Roman1 [exit code non-0] (normal)
indexed-types/should_compile Simple9 [exit code non-0] (normal)
indexed-types/should_compile T2219 [exit code non-0] (normal)
indexed-types/should_compile T2627 [exit code non-0] (normal)
indexed-types/should_compile T3484 [exit code non-0] (normal)
indexed-types/should_compile T4935 [exit code non-0] (normal)
indexed-types/should_compile T7585 [exit code non-0] (normal)
indexed-types/should_fail T2664a [exit code non-0] (normal)
polykinds PolyKinds10 [exit code non-0] (normal)
polykinds PolyKinds12 [exit code non-0] (normal)
polykinds T6002 [exit code non-0] (normal)
simplCore/should_compile T5329 [exit code non-0] (normal)
simplCore/should_run T5315 [exit code non-0] (optasm)
typecheck/should_compile T5490 [exit code non-0] (normal)
typecheck/should_compile T7196 [exit code non-0] (normal)
after these three changes were pushed:
Changes to ghc:
commit 214ad2d24cda4aaef541df3e213d5c4845f95c71
Author: Peter Trommler ptromm...@scm.org
Date: Wed Apr 30 11:41:51 2014 +0200
Fix globalRegMaybe for unregisterised build.
In commit 83a003f globalRegMaybe will be called but panics
for unregisterised compilers.
In an unregisterised compiler there are no global registers
so always return `Nothing`.
Fixes #9055.
commit 21f17d06aa5c33e639f1b0d37b4bf888b494c441
Author: Simon Peyton Jones simo...@microsoft.com
Date: Tue May 13 13:17:19 2014 +0100
Fix invariant in mkAppCoFlexible
mkAppCoFlexible was breaking the invariant that the head of a
TyConAppCo cannot
be a type synonym. This small patch fixes it.
commit 4cfc1fae11ec9a5c4b34ac747f0ce50f52423eba
Author: Simon Peyton Jones simo...@microsoft.com
Date: Tue May 13 13:15:45 2014 +0100
Lint should check that TyConAppCo doesn't have a synonym in the
tycon position
That is why Lint didn't nail Trac #9102
Full log at
https://s3.amazonaws.com/archive.travis-ci.org/jobs/25063931/log.txt. It
seems that most, if not all, fail with a Synonym in TyConAppCo lint
error.
If Lint is correct here, then this may indicate further bugs are around.
But in that case the correct thing would be to have a ticket number for
that problem and mark all failing test cases as expect_broken – it’s the
only sensible way of having an always succeeding test suite in master.
So is the Lint check correct and this uncovered one or more bugs here,
or is the Lint check actually too restrictive?
Greetings,
Joachim
Greetings,
Joachim
--
Joachim “nomeata” Breitner
m...@joachim-breitner.de • http://www.joachim-breitner.de/
Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
Debian Developer: nome...@debian.org
___
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: classP recently deleted from TH.Lib
On 05/13/2014 12:33 AM, Gabor Greif wrote:
On 5/12/14, Richard Eisenberg e...@cis.upenn.edu wrote:
This one was my fault/decision. The TH.Lib functions tend to mirror exactly
the constructors in TH.Syntax. We removed the constructors (for good reason
Hmmm, okay, I see you added `equalityT` which is just a shallow
wrapper around a new constructor.
-- predicates and types really are the same now), so I thought it best to
remove the TH.Lib function, too. In the cases where code had to be updated,
would keeping classP in be enough to prevent the breakage?
Cannot speak for many packages, but adding `classP` back would make
llvm-general-pure compilable again with HEAD. Maybe we could add it
back and mark it as deprecated?
Why not simply patch llvm-general-pure? I have done this with quite a
few packages when the TH change was made and it seems to work. If
anything, it will make the authors realise something changed upstream
and try to find out how.
We could, of course, just leave the functions there with new
implementations, but that feels like it could accumulate legacy functions
over time.
I see no serious drawbacks with an explicitly deprecated API.
Here are some ideas for this, and other similar situations, going forward:
1) Don't remove functions from TH.Lib unless absolutely necessary (which
should probably never happen).
2) Remove functions from TH.Lib, but support some other package
(th-compat) which fills in the compatibility gap. This package would not
be tied in with GHC. It would use CPP to export functions in order to remain
compatible with a range of GHC versions. In this example, the package would
export a fresh classP in 7.9+ but just re-export TH's in 7.8-.
This sounds like a good idea, but the dependent packages would need to
adopt this scheme. I.e. import `classP` from th-compat, and hiding
`classP` from import TH.Lib.
Not sure what the best practices are. Anyway, if this scheme works,
one could remove TH.Lib.classP from GHC 7.12.
3) Do what I've done -- keep TH.Lib parallel with TH.Syntax and leave it to
users to sort it out as they see fit.
This would imply that some packages need to perform preprocessor
conditional compilation to include `classP`. IMHO the worst option, as
it causes duplication.
I think this is a fair solution until TH 2.9 is phased out.
Just my few cents.
Cheers,
Gabor
It is worth noting that a change of this sort in TH.Lib corresponds to a
breaking change in TH.Syntax. But, perhaps most people rely on Lib and not
on Syntax.
I'm happy to follow what the community thinks is best here -- I don't have
any vested opinion.
Thanks -- and sorry for the breakage!
Richard
On May 12, 2014, at 10:35 AM, Johan Tibell johan.tib...@gmail.com wrote:
That would be nice. I had to fix some breakage caused by this in one of
Bryan's libraries.
On Mon, May 12, 2014 at 4:12 PM, Gabor Greif ggr...@gmail.com wrote:
The last two commits from (Apr 9) on
https://github.com/ghc/packages-template-haskell/commits/master/Language/Haskell/TH/Lib.hs
removed a helper to construct applied type class constraints (`classP`).
Some packages (notably `llvm-general-pure`) though, depend on it.
Can we add back something like this:
{{{
classP :: Name - [Q Type] - Q Pred
classP cla tys
= do
tysl - sequence tys
return (foldl' AppT (ConT cla) tysl)
}}}
and export it again? Or is there such a helper with a different name
already?
Cheers,
Gabor
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
--
Mateusz K.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: classP recently deleted from TH.Lib
i'm quite certain BScarlet will accept patches to fix up llvm-general-pure
for ghc head. Hes a very responsive author
On Mon, May 12, 2014 at 6:33 PM, Gabor Greif ggr...@gmail.com wrote:
On 5/12/14, Richard Eisenberg e...@cis.upenn.edu wrote:
This one was my fault/decision. The TH.Lib functions tend to mirror
exactly
the constructors in TH.Syntax. We removed the constructors (for good
reason
Hmmm, okay, I see you added `equalityT` which is just a shallow
wrapper around a new constructor.
-- predicates and types really are the same now), so I thought it best to
remove the TH.Lib function, too. In the cases where code had to be
updated,
would keeping classP in be enough to prevent the breakage?
Cannot speak for many packages, but adding `classP` back would make
llvm-general-pure compilable again with HEAD. Maybe we could add it
back and mark it as deprecated?
We could, of course, just leave the functions there with new
implementations, but that feels like it could accumulate legacy functions
over time.
I see no serious drawbacks with an explicitly deprecated API.
Here are some ideas for this, and other similar situations, going
forward:
1) Don't remove functions from TH.Lib unless absolutely necessary (which
should probably never happen).
2) Remove functions from TH.Lib, but support some other package
(th-compat) which fills in the compatibility gap. This package would
not
be tied in with GHC. It would use CPP to export functions in order to
remain
compatible with a range of GHC versions. In this example, the package
would
export a fresh classP in 7.9+ but just re-export TH's in 7.8-.
This sounds like a good idea, but the dependent packages would need to
adopt this scheme. I.e. import `classP` from th-compat, and hiding
`classP` from import TH.Lib.
Not sure what the best practices are. Anyway, if this scheme works,
one could remove TH.Lib.classP from GHC 7.12.
3) Do what I've done -- keep TH.Lib parallel with TH.Syntax and leave it
to
users to sort it out as they see fit.
This would imply that some packages need to perform preprocessor
conditional compilation to include `classP`. IMHO the worst option, as
it causes duplication.
Just my few cents.
Cheers,
Gabor
It is worth noting that a change of this sort in TH.Lib corresponds to a
breaking change in TH.Syntax. But, perhaps most people rely on Lib and
not
on Syntax.
I'm happy to follow what the community thinks is best here -- I don't
have
any vested opinion.
Thanks -- and sorry for the breakage!
Richard
On May 12, 2014, at 10:35 AM, Johan Tibell johan.tib...@gmail.com
wrote:
That would be nice. I had to fix some breakage caused by this in one of
Bryan's libraries.
On Mon, May 12, 2014 at 4:12 PM, Gabor Greif ggr...@gmail.com wrote:
The last two commits from (Apr 9) on
https://github.com/ghc/packages-template-haskell/commits/master/Language/Haskell/TH/Lib.hs
removed a helper to construct applied type class constraints (`classP`).
Some packages (notably `llvm-general-pure`) though, depend on it.
Can we add back something like this:
{{{
classP :: Name - [Q Type] - Q Pred
classP cla tys
= do
tysl - sequence tys
return (foldl' AppT (ConT cla) tysl)
}}}
and export it again? Or is there such a helper with a different name
already?
Cheers,
Gabor
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Many new validate failures, Synonym in TyConAppCo-related
On 2014-05-13 at 16:16:12 +0200, Joachim Breitner wrote: [...] commit 4cfc1fae11ec9a5c4b34ac747f0ce50f52423eba Author: Simon Peyton Jones simo...@microsoft.com Date: Tue May 13 13:15:45 2014 +0100 Lint should check that TyConAppCo doesn't have a synonym in the tycon position That is why Lint didn't nail Trac #9102 Fyi, this commit actually already breaks an ordinary './validate' run with , | inplace/bin/ghc-stage1 -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0-package-name hoopl-3.10.0.1 -hide-all-packages -i -ilibraries/hoopl/src -ilibraries/hoopl/dist-install/build -ilibraries/hoopl/dist-install/build/autogen -Ilibraries/hoopl/dist-install/build -Ilibraries/hoopl/dist-install/build/autogen -Ilibraries/hoopl/. -optP-include -optPlibraries/hoopl/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package containers-0.5.5.1 -Wall -fno-warn-name-shadowing -XHaskell2010 -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -odir libraries/hoopl/dist-install/build -hidir libraries/hoopl/dist-install/build -stubdir libraries/hoopl/dist-install/build -dynamic-too -c libraries/hoopl/src/Compiler/Hoopl/Block.hs -o libraries/hoopl/dist-install/build/Compiler/Hoopl/Block.o -dyno libraries/hoopl/dist-install/build/Compiler/Hoopl/Block.dyn_o | *** Core Lint errors : in result of Desugar (after optimization) *** | no location info: Warning: | In a case alternative: (Compiler.Hoopl.Block.BlockCO dt_d26X :: e_a16G | GHC.Prim.~# Compiler.Hoopl.Block.C, | dt_d26Y :: x_a16H | GHC.Prim.~# Compiler.Hoopl.Block.O, | f_aJQ :: n_aSy Compiler.Hoopl.Block.C Compiler.Hoopl.Block.O, | b_aJR :: Compiler.Hoopl.Block.Block | n_aSy | Compiler.Hoopl.Block.O | Compiler.Hoopl.Block.O) | Synonym in TyConAppCo: (Compiler.Hoopl.Block.IndexedCO | (Sym dt_d26Y) a_aSz_N b_aSA_N)_R | *** Offending Program *** | Compiler.Hoopl.Block.backBiasBlock | :: forall (n_asZ :: * - * - *) e_at0 x_at1. | Compiler.Hoopl.Block.Block n_asZ e_at0 x_at1 | - Compiler.Hoopl.Block.Block n_asZ e_at0 x_at1 | [...many lines of output follow...] ` ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Many new validate failures, Synonym in TyConAppCo-related
Mea culpa. I thought I'd validated but perhaps I got it wrong -- I was in a hurry because of catching a train. Anyway, Christiaan is spot on... the Lint check should only be for genuine type synonyms, and isSynTyCon is misleadingly named. I'll add a patch for that shortly, and deal with the naming issue later. Apologies Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Joachim | Breitner | Sent: 13 May 2014 15:16 | To: ghc-devs@haskell.org | Subject: Many new validate failures, Synonym in TyConAppCo-related | | Hi, | | I suddenly get | | Unexpected failures: |gadt T7294 [exit code non-0] (normal) |indexed-types/should_compile GADT1 [exit code non-0] (normal) |indexed-types/should_compile GADT11 [exit code non-0] | (normal) |indexed-types/should_compile GADT3 [exit code non-0] (normal) |indexed-types/should_compile IndTypesPerf [bad exit code] | (normal) |indexed-types/should_compile NonLinearLHS [exit code non-0] | (normal) |indexed-types/should_compile Numerals [exit code non-0] | (normal) |indexed-types/should_compile Roman1 [exit code non-0] | (normal) |indexed-types/should_compile Simple9 [exit code non-0] | (normal) |indexed-types/should_compile T2219 [exit code non-0] (normal) |indexed-types/should_compile T2627 [exit code non-0] (normal) |indexed-types/should_compile T3484 [exit code non-0] (normal) |indexed-types/should_compile T4935 [exit code non-0] (normal) |indexed-types/should_compile T7585 [exit code non-0] (normal) |indexed-types/should_fail T2664a [exit code non-0] | (normal) |polykinds PolyKinds10 [exit code non-0] | (normal) |polykinds PolyKinds12 [exit code non-0] | (normal) |polykinds T6002 [exit code non-0] (normal) |simplCore/should_compile T5329 [exit code non-0] (normal) |simplCore/should_run T5315 [exit code non-0] (optasm) |typecheck/should_compile T5490 [exit code non-0] (normal) |typecheck/should_compile T7196 [exit code non-0] (normal) | | after these three changes were pushed: | | Changes to ghc: | commit 214ad2d24cda4aaef541df3e213d5c4845f95c71 | Author: Peter Trommler ptromm...@scm.org | Date: Wed Apr 30 11:41:51 2014 +0200 | | Fix globalRegMaybe for unregisterised build. | | In commit 83a003f globalRegMaybe will be called but panics | for unregisterised compilers. | | In an unregisterised compiler there are no global registers | so always return `Nothing`. | | Fixes #9055. | | commit 21f17d06aa5c33e639f1b0d37b4bf888b494c441 | Author: Simon Peyton Jones simo...@microsoft.com | Date: Tue May 13 13:17:19 2014 +0100 | | Fix invariant in mkAppCoFlexible | | mkAppCoFlexible was breaking the invariant that the head of a | TyConAppCo cannot | be a type synonym. This small patch fixes it. | | commit 4cfc1fae11ec9a5c4b34ac747f0ce50f52423eba | Author: Simon Peyton Jones simo...@microsoft.com | Date: Tue May 13 13:15:45 2014 +0100 | | Lint should check that TyConAppCo doesn't have a synonym in | the tycon position | | That is why Lint didn't nail Trac #9102 | | Full log at | https://s3.amazonaws.com/archive.travis-ci.org/jobs/25063931/log.txt. It | seems that most, if not all, fail with a Synonym in TyConAppCo lint | error. | | | If Lint is correct here, then this may indicate further bugs are around. | But in that case the correct thing would be to have a ticket number for | that problem and mark all failing test cases as expect_broken – it’s the | only sensible way of having an always succeeding test suite in master. | | So is the Lint check correct and this uncovered one or more bugs here, | or is the Lint check actually too restrictive? | | Greetings, | Joachim | | | Greetings, | Joachim | | | | -- | Joachim “nomeata” Breitner | m...@joachim-breitner.de • http://www.joachim-breitner.de/ | Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F | Debian Developer: nome...@debian.org ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
clang warnings
Hi, To test the coming GHC 7.8.3, I started to use the latest ghc-7.8 branch. Unfortunately, on my Mac, I saw many warnings which are not displayed with GHC 7.8.2: clang: warning: argument unused during compilation: '-fno-stack-protector' clang: warning: argument unused during compilation: '-D TABLES_NEXT_TO_CODE' clang: warning: argument unused during compilation: '-I test' clang: warning: argument unused during compilation: '-I dist/build/spec/spec-tmp' clang: warning: argument unused during compilation: '-I dist/build/spec/spec-tmp' clang: warning: argument unused during compilation: '-I dist/build/autogen' clang: warning: argument unused during compilation: '-I dist/build/spec/spec-tmp' Is this a known issue? --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
