[GHC] #1912: Debug.Trace should add another version of putTraceMsg same as traceShow
#1912: Debug.Trace should add another version of putTraceMsg same as traceShow
-+--
Reporter: guest| Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: libraries/base |Version: 6.8.1
Severity: normal | Keywords:
Testcase: | Architecture: Multiple
Os: Multiple |
-+--
trace function can work on Show using traceShow (#474).
So I think Debug.Trace should also add another version of putTraceMsg same
as traceShow.
{{{
printTraceMsg :: Show a = a - b - IO ()
printTraceMsg = putTraceMsg . show
}}}
I want to use putTraceMsg function and this variation. Because I want to
trace problems in monad and monad transformer codem, on Windows GUI
Application.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1912
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-6.6.1 testsuite on arm eabi: TestStub_stub.h: No such file or directory
Martin Guy wrote: 2007/11/20, Simon Marlow [EMAIL PROTECTED]: Martin Guy wrote: $ .../ghc6-6.6.1/testsuite/tests/ghc-regress$ make stage=2 fast make-fast-stage=2.errs 21 Wrong exit code (expected 0 , actual 2 ) /tmp/ghc27396_0/ghc27396_0.hc:5:27: error: TestStub_stub.h: No such file or directory This could be a difference in how gcc on your platform is finding header files, perhaps. Could you add -v to the GHC command line and send us the output? I find I get the same behaviour in x86 when using -fvia-C, and arm is always via-C so I've decided not to worry about it, but here is the -v output when running the guts of driver035 manually: This is a bug that was fixed in 6.8.1. The testsuite now has extra tests for this case (-stubdir and -fvia-C). Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1819: x86 native codegen implements float2int# incorrectly
#1819: x86 native codegen implements float2int# incorrectly +--- Reporter: simonmar| Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler (NCG) |Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: arith005 (see description) | Architecture: x86 Os: Unknown | +--- Comment (by simonmar): Closing as dup of #1910, which has a patch. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1819#comment:2 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] #1819: x86 native codegen implements float2int# incorrectly
#1819: x86 native codegen implements float2int# incorrectly +--- Reporter: simonmar| Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler (NCG) |Version: 6.8.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: arith005 (see description) | Architecture: x86 Os: Unknown | +--- Changes (by simonmar): * status: new = closed * resolution: = duplicate -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1819#comment:3 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] #1910: Native Code gen miscompiles double2Int# / float2Int# on x86_32
#1910: Native Code gen miscompiles double2Int# / float2Int# on x86_32 +--- Reporter: int-e | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.2 Component: Compiler (NCG) |Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: x86 Os: Multiple| +--- Changes (by simonmar): * owner: = simonmar Comment: I'm testing the patch, thanks! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1910#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
[GHC] #1913: standalone deriving breaks module hiding
#1913: standalone deriving breaks module hiding
-+--
Reporter: duncan| Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 6.8.1
Severity: normal|Keywords:
Difficulty: Unknown |Testcase:
Architecture: Unknown | Os: Unknown
-+--
Foo.hs:
{{{
module Foo ( T, t ) where
data T = T
t = T
}}}
Bar.hs:
{{{
import Foo
deriving instance Eq T
}}}
Then in ghci...
{{{
$ ghci Bar.hs -XStandaloneDeriving
[1 of 2] Compiling Bar ( Bar.hs, interpreted )
[2 of 2] Compiling Main ( Baz.hs, interpreted )
Ok, modules loaded: Bar, Main.
*Main t == t
True
}}}
There is no way that I could implement that instance Eq T manually in
Bar.hs because Foo exports T abstractly.
I see no reason that standalone deriving should have any magic ability
that manual instance declarations do not have. Indeed it breaks module
abstraction.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1913
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] #1911: -w doesn't turn off nullModuleExport
#1911: -w doesn't turn off nullModuleExport
---+
Reporter: AndreaRossato | Owner:
Type: bug| Status: new
Priority: normal | Milestone:
Component: Compiler |Version: 6.8.1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: x86
Os: Linux |
---+
Changes (by simonpj):
* difficulty: = Unknown
Comment:
Indeed. And on inspection there are quite a few other examples. e.g
{{{
module F( T(..) ) where
type T = Int
}}}
yields a warning even with `-w`.
I can see two choices:
* Track down all the exceptions and give them a flag, even if it's
`-Wmisc`. But it may be tiresome to find every warning.
OR
* Make `-w` set a bit that suppresses all warnings from all causes. This
is easier to implement, because it can be done in one place. The trouble
with this is that `-w -fwarn-incomplete-patterns` would not warn of
incomplete patterns (because the suppress-warning bit is set).
How important is this?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1911#comment:1
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] #1913: standalone deriving breaks module hiding
#1913: standalone deriving breaks module hiding +--- Reporter: duncan | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler|Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: drvfail015 | Architecture: Unknown Os: Unknown | +--- Changes (by simonpj): * testcase: = drvfail015 * owner: = igloo * type: bug = merge Comment: Ah how true. Since I've just been fiddling with deriving I fixed this too. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1913#comment:1 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] #1843: ghc 6.8.1 broken on Mac OS X Leopard PPC
#1843: ghc 6.8.1 broken on Mac OS X Leopard PPC --+- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.2 Component: Compiler |Version: 6.8.1 Severity: critical | Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: powerpc Os: MacOS X | --+- Comment (by ChrisKuklewicz): The source code of ld64-77 used by OS X 10.5 shows that it produces the unknown scatter relocation type 4 where the 4 is PPC_RELOC_HI16. Note that ld64-77 seems capable of writing scattered PPC_RELOC_HI16 but not reading them. I am currently reading the binary ABI at http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html to see if it is going to enlighten me on this bug. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1843#comment:12 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] #1867: GHC 6.6.1 and 6.8.1 don't run on Windows NT 4.0
#1867: GHC 6.6.1 and 6.8.1 don't run on Windows NT 4.0 ---+ Reporter: Orphi | Owner: Type: bug| Status: reopened Priority: normal | Milestone: Component: Documentation |Version: 6.8.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows| ---+ Changes (by Orphi): * status: closed = reopened * resolution: fixed = Comment: Sorry to be a pest, but the download page for 6.6.1 is still claiming it works on Windows NT. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1867#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] #474: Debug.Trace.trace should work on Show
#474: Debug.Trace.trace should work on Show -+-- Reporter: jch | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base |Version: None Severity: minor| Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -+-- Changes (by igloo): * priority: lowest = normal * status: reopened = new * owner: nobody = igloo * milestone: 6.6 = 6.10 branch Comment: Looks like we forgot to add it to the export list; sorry! Will be fixed for 6.10. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/474#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
