Re: [GHC] #476: HUnit treats failures as errors
#476: HUnit treats failures as errors
+---
Reporter: stefanheimann | Owner: RichardG
Type: bug| Status: closed
Priority: normal | Milestone: Not GHC
Component: libraries (other) |Version: 6.4.1
Resolution: invalid| Keywords: hunit
Difficulty: Unknown| Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: None/Unknown | Patch: 0
+---
Changes (by RichardG):
* patch: = 0
Comment:
Tested HUnit 1.2.2.1 on Mac OS X 10.6 with GHC 6.12.1 (Haskell Platform
2010.1); did not encounter issue. Appears to be working as expected.
{{{
Prelude import Test.HUnit
Prelude Test.HUnit let f = TestCase (assertBool foo True)
Loading package HUnit-1.2.2.1 ... linking ... done.
Prelude Test.HUnit runTestTT f
Cases: 1 Tried: 1 Errors: 0 Failures: 0
Counts {cases = 1, tried = 1, errors = 0, failures = 0}
Prelude Test.HUnit let g = TestCase (assertBool foo False)
Prelude Test.HUnit runTestTT g
### Failure:
foo
Cases: 1 Tried: 1 Errors: 0 Failures: 1
Counts {cases = 1, tried = 1, errors = 0, failures = 1}
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/476#comment:9
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4012: Different stage2 results depending on the version of the bootstrapping compiler
#4012: Different stage2 results depending on the version of the bootstrapping compiler ---+ Reporter: kili | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Build System |Version: 6.12.2 Resolution: invalid | Keywords: Difficulty:| Os: OpenBSD Testcase:| Architecture: Unknown/Multiple Failure: Other | Patch: 0 ---+ Comment(by kili): Replying to [comment:2 simonmar]: In a sense it's not a bug, in that we know interfaces are not stable. Of course we'd prefer it if interfaces were stable, and moving towards stability has been a goal of mine over the past year or so. I don't think it'll help to have a bug open on this right now, though. But this means if two people build packages, where one used a different bootstrapper for ghc than the other, they can't use each other's packages. I'd consider that a bug. (Actually, the OpenBSD port has a knob for using an already installed ghc-6.12.2 for bootstrapping instead of the prebuilt bindist I provide, but I'll better remove that knob for now) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4012#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #4013: build fails on OS X: Invalid Mach-O file:Address out of bounds while relocating object file
#4013: build fails on OS X: Invalid Mach-O file:Address out of bounds while
relocating object file
-+--
Reporter: igloo |Owner:
Type: bug | Status: new
Priority: highest |Milestone: 6.14.1
Component: Compiler | Version: 6.12.2
Keywords:| Difficulty:
Os: MacOS X | Testcase:
Architecture: Unknown/Multiple | Failure: Building GHC failed
Patch: 0 |
-+--
Validate goes through on OS X, but a normal build (such as that done by
the nightly builder) fails with:
{{{
inplace/bin/ghc-stage2 -H32m -O-package-name dph-seq-0.4.0 -hide-
all-packages -i -ilibraries/dph/dph-seq/../dph-common -ilibraries/dph/dph-
seq/dist-install/build -ilibraries/dph/dph-seq/dist-install/build/autogen
-Ilibraries/dph/dph-seq/dist-install/build -Ilibraries/dph/dph-seq/dist-
install/build/autogen -Ilibraries/dph/dph-seq/.-optP-include
-optPlibraries/dph/dph-seq/dist-install/build/autogen/cabal_macros.h
-package array-0.3.0.0 -package base-4.2.0.0 -package dph-base-0.4.0
-package dph-prim-seq-0.4.0 -package ghc-6.13.20100425 -package ghc-
prim-0.2.0.0 -package random-1.0.0.2 -package template-haskell-2.4.0.0
-Odph -funbox-strict-fields -haddock -fcpr-off -fdph-this -package-name
dph-seq -XTypeFamilies -XGADTs -XRankNTypes -XBangPatterns -XMagicHash
-XUnboxedTuples -XTypeOperators -O2 -XGenerics -fno-warn-deprecated-flags
-Wwarn -odir libraries/dph/dph-seq/dist-install/build -hidir
libraries/dph/dph-seq/dist-install/build -stubdir libraries/dph/dph-seq
/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/dph/dph-seq
/../dph-common/Data/Array/Parallel/Lifted/PArray.hs -o libraries/dph/dph-
seq/dist-install/build/Data/Array/Parallel/Lifted/PArray.o
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.3.0.0 ... linking ... done.
Loading package containers-0.3.0.0 ... linking ... done.
Loading package filepath-1.1.0.4 ... linking ... done.
Loading package old-locale-1.0.0.2 ... linking ... done.
Loading package old-time-1.0.0.4 ... linking ... done.
Loading package unix-2.4.0.1 ... linking ... done.
ghc-stage2: internal error: Invalid Mach-O file:Address out of bounds
while relocating object file
(GHC version 6.13.20100425 for i386_apple_darwin)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
make[1]: *** [libraries/dph/dph-seq/dist-
install/build/Data/Array/Parallel/Lifted/PArray.o] Abort trap
make: *** [all] Error 2
}}}
This one passed:
http://darcs.haskell.org/ghcBuilder/builders/tn23/8.html
This one failed:
http://darcs.haskell.org/ghcBuilder/builders/tn23/9.html
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4013
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4012: Compilation results are not deterministic (was: Different stage2 results depending on the version of the bootstrapping compiler)
#4012: Compilation results are not deterministic ---+ Reporter: kili | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.12.2 Resolution:| Keywords: Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase:| Architecture: Unknown/Multiple Failure: Other | Patch: 0 ---+ Changes (by simonmar): * status: closed = new * os: OpenBSD = Unknown/Multiple * component: Build System = Compiler * difficulty: = Difficult (2-5 days) * resolution: invalid = Comment: Replying to [comment:4 kili]: But this means if two people build packages, where one used a different bootstrapper for ghc than the other, they can't use each other's packages. I'd consider that a bug. The bootstrapping GHC is a red herring, as I mentioned - the fact is that compilation results aren't deterministic. They never have been, in fact. Even if compilation results were deterministic, under what circumstances would you want to have two systems use each others packages, when they're both using a GHC independently built from source? If they independently build GHC from source, why wouldn't they build packages from source too? Note that packages are registered with an MD5 hash of the interface, so the package system will spot if you try to register an incompatible package. Anyway, I do agree that having deterministic compilation results is a desirable thing, so on second thoughts I've re-opened the bug and retitled it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4012#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3931: extensible-exceptions 0.1.1.1 fails to build on GHC 6.8 (Cabal 1.2)
#3931: extensible-exceptions 0.1.1.1 fails to build on GHC 6.8 (Cabal 1.2)
+---
Reporter: andersk| Owner:
Type: proposal | Status: closed
Priority: normal | Milestone:
Component: libraries (other) |Version: 6.8.2
Resolution: fixed | Keywords:
Difficulty: | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: None/Unknown | Patch: 0
+---
Changes (by igloo):
* status: new = closed
* resolution: = fixed
* patch: = 0
Comment:
Done:
{{{
Sun Apr 25 12:02:45 PDT 2010 Ian Lynagh ig...@earth.li
* Revert changes that require Cabal-1.6 or later; fixes GHC trac #3931
We want to remain compatible with older compilers, with older Cabals,
for now.
}}}
and 0.1.1.2 is on hackage.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3931#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4012: Compilation results are not deterministic
#4012: Compilation results are not deterministic ---+ Reporter: kili | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.12.2 Resolution:| Keywords: Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase:| Architecture: Unknown/Multiple Failure: Other | Patch: 0 ---+ Comment(by kili): Replying to [comment:5 simonmar]: The bootstrapping GHC is a red herring, as I mentioned - the fact is that compilation results aren't deterministic. They never have been, in fact. And it's good that the problems are detected now with the hashes. Even if compilation results were deterministic, under what circumstances would you want to have two systems use each others packages, when they're both using a GHC independently built from source? If they independently build GHC from source, why wouldn't they build packages from source too? For example, if two persons are working on a ghc package for their operating system, and also on updates for all the stuff that needs ghc (xmonad, alex, happy, monadius, to mention the most important ones), it's a pity if they're not able to exchange packages. You mentioned that even a `make clean; make' may change the interfaces. Indeed, I remember at least one case where ghc segfailted during the build (this doesn't happen often, only every 20th or 30th build) and I just restarted the build -- and got interface changes. Note that packages are registered with an MD5 hash of the interface, so the package system will spot if you try to register an incompatible package. And that's good, but it's just a workaround, UMHO. Anyway, I do agree that having deterministic compilation results is a desirable thing, so on second thoughts I've re-opened the bug and retitled it. Thanks. But is this really *one* Bug? There are the problems with non- determinisms, but I think that the CSE on inlined constants (like cBooterVersion and cProjectVersion) is a separate problem. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4012#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4012: Compilation results are not deterministic
#4012: Compilation results are not deterministic ---+ Reporter: kili | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.12.2 Resolution:| Keywords: Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase:| Architecture: Unknown/Multiple Failure: Other | Patch: 0 ---+ Comment(by igloo): Replying to [comment:6 kili]: Thanks. But is this really *one* Bug? There are the problems with non- determinisms, but I think that the CSE on inlined constants (like cBooterVersion and cProjectVersion) is a separate problem. I don't think that's a bug at all. You are compiling different source code, so it's entirely reasonable that the ABI should be different. If the ABI was otherwise stable then it might be worth trying to work around `cBooterVersion`'s value affecting the ABI, though. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4012#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #4014: hsc2hs cannot open custom template file
#4014: hsc2hs cannot open custom template file -+-- Reporter: golubovsky| Owner: Type: bug | Status: new Priority: normal| Component: hsc2hs Version: 6.12.2|Keywords: Os: Unknown/Multiple |Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown Patch: 0 | -+-- Note: this happens to hsc2hs which comes with binary ghc-6.12.2. hsc2hs from darcs.haskell.org seems to not have this issue When invoking hsc2hs like this: hsc2hs -t /dev/null HS_GLFW_H.hsc (or any other filename with -t, the hsc file has its own template), the output follows: hsc2hs: : openBinaryFile: does not exist (No such file or directory) Note the second colon: filename should be there, and it is empty. strace log shows that there is an attempt to open a file with empty name (ca. line 534): open(, O_RDONLY|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = -1 ENOENT (No such file or directory) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4014 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
