Re: [GHC] #1186: GHC as a library panic on loading second module
#1186: GHC as a library panic on loading second module
--+-
Reporter: ArthurVanLeeuwen | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: GHC API |Version: 6.6
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Architecture: powerpc
Os: Unknown |
--+-
Comment (by ArthurVanLeeuwen):
Just to check my sanity (the bugreport was an attempted pare-down of the
original problem):
{{{
harlan:~/Werk/dss/software/ghclib arthurvl$ uname -a
Darwin harlan.cs.uu.nl 8.8.0 Darwin Kernel Version 8.8.0: Fri Sep 8
17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/RELEASE_PPC Power Macintosh
powerpc
harlan:~/Werk/dss/software/ghclib arthurvl$ echo setupsession =
loadsession | ghci -package ghc ghclibtest.hs
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package base ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package readline-1.0 ... linking ... done.
Loading package unix-1.0 ... linking ... done.
Loading package Cabal-1.1.6 ... linking ... done.
Loading package regex-base-0.71 ... linking ... done.
Loading package regex-posix-0.71 ... linking ... done.
Loading package regex-compat-0.71 ... linking ... done.
Loading package haskell98 ... linking ... done.
Loading package ghc-6.6 ... linking ... done.
[1 of 2] Compiling OtherModule ( OtherModule.hs, interpreted )
[2 of 2] Compiling GHCLibTest ( ghclibtest.hs, interpreted )
Ok, modules loaded: OtherModule, GHCLibTest.
*GHCLibTest ghc-6.6: panic! (the 'impossible' happened)
(GHC version 6.6 for powerpc-apple-darwin):
lookup_dfun main:OtherModule.$f1{v r5x8} [lid]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
*GHCLibTest Leaving GHCi.
harlan:~/Werk/dss/software/ghclib arthurvl$ lsOtherModule.hs
ghclibtest.hs
harlan:~/Werk/dss/software/ghclib arthurvl$ cat OtherModule.hs
module OtherModule where
import Data.List
type Nummer = String
data Beademing = HFO | CPAP | IPPV | Geen
deriving (Show, Read, Eq)
data Bloeddruk = Hypertensie | Hypotensie | TensieNormaal
deriving (Show, Read, Eq)
data Partus = PartusTeVroeg | PartusNormaal
deriving (Show, Read, Eq)
harlan:~/Werk/dss/software/ghclib arthurvl$ cat ghclibtest.hs
module GHCLibTest (setupsession,loadsession) where
import GHC
import PackageConfig
import DynFlags
import OtherModule
main = setupsession = loadsession
setupsession =
do session - newSession JustTypecheck (Just /usr/local/lib/ghc-6.6)
f - getSessionDynFlags session
f' - parseDynamicFlags f [-package ghc]
setSessionDynFlags session (fst f'){hscTarget = HscInterpreted}
let preludeModule = mkModule (stringToPackageId base)
(mkModuleName Prelude)
setContext session [] [preludeModule]
t - guessTarget ghclibtest.hs Nothing
addTarget session t
return session
loadsession session = load session LoadAllTargets
other = 12
}}}
I did note however, that *compiling* this does not seem to evoke the bug:
{{{
harlan:~/Werk/dss/software/ghclib arthurvl$ ghc -package ghc --make -main-
is GHCLibTest.main ghclibtest.hs
[1 of 2] Compiling OtherModule ( OtherModule.hs, OtherModule.o )
[2 of 2] Compiling GHCLibTest ( ghclibtest.hs, ghclibtest.o )
Linking ghclibtest ...
harlan:~/Werk/dss/software/ghclib arthurvl$ ./ghclibtest
harlan:~/Werk/dss/software/ghclib arthurvl$ ls
OtherModule.hi OtherModule.o ghclibtest.hi ghclibtest.o
OtherModule.hs ghclibtest ghclibtest.hs
}}}
And then using the compiled modules with ghci doesn't break things anymore
either!
{{{
harlan:~/Werk/dss/software/ghclib arthurvl$ echo setupsession =
loadsession | ghci -package ghc ghclibtest.hs
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package base ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package readline-1.0 ... linking ... done.
Loading package unix-1.0 ... linking ... done.
Loading package Cabal-1.1.6 ... linking ... done.
Loading package regex-base-0.71 ... linking ... done.
Loading package regex-posix-0.71 ... linking ... done.
Loading package regex-compat-0.71 ... linking ... done.
Loading package haskell98 ... linking ... done.
Loading package ghc-6.6 ...
Re: [GHC] #1187: GHC.Conc.prodServiceThread can deadlock
#1187: GHC.Conc.prodServiceThread can deadlock +--- Reporter: ms43| Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: libraries/base |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple| +--- Changes (by simonmar): * milestone: = 6.6.1 * owner: = simonmar Comment: The patch isn't completely correct; it should be using modifyMVar, which uses block/unblock internally (there's a still a race between takeMVar and catchException otherwise). However, modifyMVar isn't available yet, so we'd have to define a local copy of it. Instead it might be better to use atomicModifyIORef. Anyway, I'll look at this. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1187 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] #1093: Windows: haddock-html fields are wrong in package.conf
#1093: Windows: haddock-html fields are wrong in package.conf
--+-
Reporter: simonmar | Owner: igloo
Type: bug | Status: closed
Priority: normal| Milestone: 6.6.1
Component: Build System |Version: 6.6
Severity: normal| Resolution: fixed
Keywords:| Difficulty: Easy (1 hr)
Testcase:| Architecture: Unknown
Os: Windows |
--+-
Changes (by igloo):
* resolution: = fixed
* status: new = closed
Comment:
The filename problems turns out to be this:
The haddock-html field is ultimately printed out by:
{{{
showFilePath :: FilePath - Doc
showFilePath = showToken
showToken :: String - Doc
showToken str
| not (any dodgy str)
not (null str) = text str
| otherwise= text (show str)
where dodgy c = isSpace c || c == ','
}}}
Thus when haddock asks ghc-pkg for the haddock-html field and the path
contains spaces, it doesn't get a plain path back like it expects. It then
checks to see if the mangled path exists, which it doesn't.
I think the right way to fix this would be to have a ghc-pkg flag that
gives more machine understandable output. However, as I assume haddock-ghc
will not have this problem I'm going to close this bug; we might want to
open a new one for a machine-understandable flag to ghc-pkg anyway.
I've opened bugs in Cabal for a couple of issues that came up:
http://hackage.haskell.org/trac/hackage/ticket/115
http://hackage.haskell.org/trac/hackage/ticket/116
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1093
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] #1195: Build error on MacOSX (Intel) 10.4.8 for HEAD from 2007-03-05 when compiling with ghc-6.6
#1195: Build error on MacOSX (Intel) 10.4.8 for HEAD from 2007-03-05 when compiling with ghc-6.6 ---+ Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.7 Severity: normal |Keywords: Difficulty: Unknown |Testcase: Architecture: x86 | Os: MacOS X ---+ make on MacOSX does not seem to stop when built errors occur. The first error message is: /tmp/ghc23705_0/ghc23705_0.split__38.s:unknown:missing indirect symbols for section (__TEXT,__symbol_stub) which happens after build step: == make all -r -f Makefile; in /Users/nominolo/Devel/Haskell/ghc/libraries/base ../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict-fields -package-name base-2.0 -O -Rghc-timing -fgenerics -fgenerics -split-objs-c GHC/Float.lhs -o GHC/Float.o -ohi GHC/Float.hi All following files consequently fail to build with the error message: File.hs:1:0: Failed to load interface for `Prelude': Use -v to see a list of the files searched for. I was building with: $ uname -a Darwin hostname 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386 $ gcc -v Using built-in specs. Target: i686-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform- name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5250) $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1195 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] #957: No way to use -lgmp from a non-standard location
#957: No way to use -lgmp from a non-standard location --+- Reporter: [EMAIL PROTECTED] | Owner: igloo Type: bug | Status: new Priority: normal| Milestone: 6.6.1 Component: Build System |Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase: N/A | Architecture: x86 Os: FreeBSD | --+- Changes (by igloo): * owner: = igloo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/957 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] #1110: Setting PATH needed in Windows Vista
#1110: Setting PATH needed in Windows Vista -+-- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: high | Milestone: 6.6.1 Component: Driver |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Windows | -+-- Comment (by simonmar): It's a bug in MinGW (and/or gcc). Here's the latest thread I could find: [http://thread.gmane.org/gmane.comp.gnu.mingw.user/21709/focus=21711] it doesn't look like the MinGW folks have a fix checked in yet. So we could be hosed. One temporary fix could be to set the `GCC_EXEC_PREFIX` env var from GHC, I'll try that here and see if it works. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1110 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] #1196: Cabal on Windows doesn't like the in-place GHCs
#1196: Cabal on Windows doesn't like the in-place GHCs
-+--
Reporter: igloo | Owner:
Type: bug | Status: new
Priority: normal| Milestone: _|_
Component: Compiler | Version: 6.6
Severity: normal|Keywords:
Difficulty: Unknown |Testcase: cabal01
Architecture: Unknown | Os: Windows
-+--
From e.g. a cmd prompt, Windows doesn't like the in-place GHCs:
{{{
C:\C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace
'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace' is
not recognized as an internal or external command, operable program or
batch file.
C:\cat C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-
inplace
#!/bin/sh
exec C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage2/ghc
-BC:cygwinhomeianghc6.6-branchbuild $@
}}}
which means the cabal01 test fails thus:
{{{
$ ./setup configure --prefix=`pwd`/install --with-
compiler=C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage1/ghc-
inplace --with-hc-pkg=../../../../../utils/ghc-pkg/ghc-pkg-inplace
--enable-library-profiling
setup.exe: Warning: Package is copyright All Rights Reserved
setup.exe: Warning: No license-file field.
'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage1\ghc-inplace' is
not recognized as an internal or external command,
operable program or batch file.
Configuring test-1.0...
}}}
(the odd output order is due to buffering)
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1196
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] #1196: Cabal on Windows doesn't like the in-place GHCs
#1196: Cabal on Windows doesn't like the in-place GHCs --+- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal| Milestone: _|_ Component: Compiler |Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase: cabal01, cabal02 | Architecture: Unknown Os: Windows | --+- Changes (by igloo): * testcase: cabal01 = cabal01, cabal02 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1196 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] #1197: Windows: conc023.exe: getMBlocks: VirtualAlloc MEM_RESERVE 1 blocks failed: Not enough storage is available to process this command.
#1197: Windows: conc023.exe: getMBlocks: VirtualAlloc MEM_RESERVE 1 blocks
failed:
Not enough storage is available to process this command.
-+--
Reporter: igloo | Owner:
Type: bug | Status: new
Priority: normal| Milestone: 6.6.2
Component: Compiler | Version: 6.6
Severity: normal|Keywords:
Difficulty: Unknown |Testcase: conc023
Architecture: Unknown | Os: Windows
-+--
When running conc023 in the 6.6 branch the normal way on Windows I get:
{{{
$ ./conc023
conc023.exe: getMBlocks: VirtualAlloc MEM_RESERVE 1 blocks failed: Not
enough storage is available to process this command.
}}}
All other ways work.
The 6.6 release also exhibits the bug (and may be worse - the opt way
seems to sometimes break too).
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1197
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] #1176: Infinite loop when printing error message
#1176: Infinite loop when printing error message ---+ Reporter: [EMAIL PROTECTED] | Owner: thorkilnaur Type: bug| Status: new Priority: low| Milestone: _|_ Component: Compiler |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: tcfail177 | Architecture: Multiple Os: Multiple | ---+ Changes (by thorkilnaur): * owner: = thorkilnaur -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1176 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] #1186: GHC as a library panic on loading second module
#1186: GHC as a library panic on loading second module --+- Reporter: ArthurVanLeeuwen | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: GHC API |Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: powerpc Os: Unknown | --+- Comment (by thorkilnaur): Thanks a lot, I can repeat it now. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1186 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] #1198: readwrite002.exe: readwrite002.inout: hWaitForInput: invalid argument (Invalid argument)
#1198: readwrite002.exe: readwrite002.inout: hWaitForInput: invalid argument
(Invalid argument)
---+
Reporter: igloo | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.6.2
Component: libraries/base | Version: 6.6
Severity: normal |Keywords:
Difficulty: Unknown |Testcase: readwrite002
Architecture: Unknown | Os: Windows
---+
On Windows, readwrite002 is failing with
{{{
readwrite002.exe: readwrite002.inout: hWaitForInput: invalid argument
(Invalid argument)
}}}
The error is being generated by
{{{
rc = PeekNamedPipe( hFile, NULL, 0, NULL, avail, NULL );
}}}
in the `inputReady` function in `cbits/inputReady.c`, during a call to
`hReady`.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1198
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] #1196: Cabal on Windows doesn't like the in-place GHCs
#1196: Cabal on Windows doesn't like the in-place GHCs --+- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal| Milestone: _|_ Component: Compiler |Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase: cabal01, cabal02 | Architecture: Unknown Os: Windows | --+- Comment (by simonmar): Yes, I got halfway to fixing this and didn't finish it. Basically I was planning to do away with the ghc-inplace scripts on Windows, and instead have the GHC binary figure out whether it was in a build tree or not by inspecting the binary pathname. ghc-inplace causes problems for the testsuite driver too, IIRC. Unfortunately similar changes would also be required to ghc-pkg (doing away with ghc-pkg-inplace on Windows), since there's no way to pass extra arguments to ghc-pkg via Cabal (perhaps there should be?). Better ideas welcome... -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1196 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] #1167: mangler makes global symbol disappear on linux-ppc
#1167: mangler makes global symbol disappear on linux-ppc
-+--
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.6.1
Component: Compiler |Version: 6.6
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: powerpc
Os: Linux|
-+--
Changes (by igloo):
* milestone: = 6.6.1
Old description:
Enviroment: linux-ppc, very fresh software, upcoming gcc 4.2, ghc 6.6. I
was trying to build alex software which ended with:
GNU ld version 2.17.50.0.12 20070128
Supported emulations:
elf32ppclinux
elf32ppc
elf32ppcsim
ghc3729_0.hc:(.text+0x104a): undefined reference to
`ParseMonad_alexStartPos_closure'
ghc3729_0.hc:(.text+0x104e): undefined reference to
`ParseMonad_alexStartPos_closure'
dist/build/alex/alex-tmp/Info.o: In function `shII_info':
ghc3729_0.hc:(.text+0x106e): undefined reference to `Util_lvl1_closure'
ghc3729_0.hc:(.text+0x1072): undefined reference to `Util_lvl1_closure'
ghc3729_0.hc:(.text+0x107a): undefined reference to `Util_lvl1_closure'
dist/build/alex/alex-tmp/Info.o:(.rodata+0x40): undefined reference to
`Util_lvl1_closure'
The problem is that these symbol disappear after going through mangler
(so problem is visible only when -O2 is used)
In short the problem is that:
.globl ParseMonad_alexStartPos_closure
disappears.
New description:
Enviroment: linux-ppc, very fresh software, upcoming gcc 4.2, ghc 6.6. I
was trying to build alex software which ended with:
{{{
GNU ld version 2.17.50.0.12 20070128
Supported emulations:
elf32ppclinux
elf32ppc
elf32ppcsim
ghc3729_0.hc:(.text+0x104a): undefined reference to
`ParseMonad_alexStartPos_closure'
ghc3729_0.hc:(.text+0x104e): undefined reference to
`ParseMonad_alexStartPos_closure'
dist/build/alex/alex-tmp/Info.o: In function `shII_info':
ghc3729_0.hc:(.text+0x106e): undefined reference to `Util_lvl1_closure'
ghc3729_0.hc:(.text+0x1072): undefined reference to `Util_lvl1_closure'
ghc3729_0.hc:(.text+0x107a): undefined reference to `Util_lvl1_closure'
dist/build/alex/alex-tmp/Info.o:(.rodata+0x40): undefined reference to
`Util_lvl1_closure'
}}}
The problem is that these symbol disappear after going through mangler (so
problem is visible only when -O2 is used)
In short the problem is that:
{{{
.globl ParseMonad_alexStartPos_closure
}}}
disappears.
Comment:
I'm putting this in the 6.6.1 milestone for now as it looks pretty bad if
it bites often, but I'm not sure if anyone's actively working on the
registerised Linux/PPC port, so we might well end up punting on it.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1167
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] #1174: Impredicative type-class context causes stack overflow or non-termination in type checker
#1174: Impredicative type-class context causes stack overflow or non-termination in type checker --+- Reporter: ccshan| Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Compiler |Version: 6.6 Severity: normal| Resolution: duplicate Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by igloo): * resolution: = duplicate * status: new = closed Comment: Thanks for the report. This is a duplicate of #940, fixed in the 6.6 branch and the HEAD. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1174 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] #1199: Type variables in DataD do not match up:
#1199: Type variables in DataD do not match up:
-+--
Reporter: wolfgang | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Template Haskell | Version: 6.7
Severity: normal|Keywords:
Difficulty: Unknown |Testcase:
Architecture: Multiple | Os: Multiple
-+--
When reigying an ADT, the type variables listed on the left side are
different from those used on the right side:
{{{
Prelude Language.Haskell.TH $(reify ''Maybe = stringE . show)
TyConI (DataD [] Data.Maybe.Maybe [a_1627391676] [NormalC
Data.Maybe.Nothing [],NormalC Data.Maybe.Just [(NotStrict,VarT
a_1627391681)]] [])
}}}
The type variables do match up when we look just at the constructor:
{{{
Prelude Language.Haskell.TH $(reify 'Just = stringE . show)
DataConI Data.Maybe.Just (ForallT [a_1627391681] [] (AppT (AppT ArrowT
(VarT a_1627391681)) (AppT (ConT Data.Maybe.Maybe) (VarT a_1627391681
Data.Maybe.Maybe (Fixity 9 InfixL)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1199
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] #1182: splitAt does not implement H98 report behaviour, it is too strict in 'n'
#1182: splitAt does not implement H98 report behaviour, it is too strict in 'n' -+-- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: libraries/haskell98 |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | -+-- Changes (by igloo): * milestone: = 6.8 Comment: I've opened a Haskell' bug at http://hackage.haskell.org/trac/haskell-prime/ticket/119 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1182 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] #1184: Hasktags misses symbol
#1184: Hasktags misses symbol
-+--
Reporter: newsham | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.6.2
Component: None |Version: 6.6
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Windows |
-+--
Changes (by igloo):
* milestone: = 6.6.2
Old description:
(not sure I filed this bug appropriately. I belive hasktags came as part
of the ghc-6.6 binary package. Please advise if there's a better place)
Hasktags is missing an obvious symbol.
$ darcs get --partial http://happs.org/HAppS
$ cd HAppS/src
$ hasktags -c `find . -name '*.hs' |grep -v _darcs`
$ grep boolM# - not found
$ grep boolM `find . -name '*.hs' |grep -v _darcs` # - found
New description:
(not sure I filed this bug appropriately. I belive hasktags came as part
of the ghc-6.6 binary package. Please advise if there's a better place)
Hasktags is missing an obvious symbol.
{{{
$ darcs get --partial http://happs.org/HAppS
$ cd HAppS/src
$ hasktags -c `find . -name '*.hs' |grep -v _darcs`
$ grep boolM# - not found
$ grep boolM `find . -name '*.hs' |grep -v _darcs` # - found
}}}
Comment:
This is the right place.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1184
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] #1188: STM.c:stmCommitNestedTransaction bogosity
#1188: STM.c:stmCommitNestedTransaction bogosity +--- Reporter: ms43| Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System |Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple| +--- Changes (by igloo): * resolution: = fixed * status: new = closed Comment: I've applied this fix to the 6.6 branch (it turns out it was already in the HEAD); thanks! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1188 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] #1199: Type variables in DataD do not match up:
#1199: Type variables in DataD do not match up: --+- Reporter: wolfgang | Owner: igloo Type: merge | Status: new Priority: normal| Milestone: Component: Template Haskell |Version: 6.7 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Multiple Os: Multiple | --+- Changes (by simonpj): * owner: = igloo * type: bug = merge Comment: Ah yes, good point. Now fixed. Pls merge: Tue Mar 6 06:56:41 GMT Standard Time 2007 [EMAIL PROTECTED] * Simple fix for Trac #1199 (pls merge to branch) Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1199 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] #1200: ghci scripts ending in printf lines fail with Exception: Prelude.undefined
#1200: ghci scripts ending in printf lines fail with Exception:
Prelude.undefined
+---
Reporter: dons | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: GHCi | Version: 6.6
Severity: normal |Keywords:
Difficulty: Unknown |Testcase:
Architecture: Unknown | Os: Unknown
+---
There appears to be some differences in runhaskell/ghci and ghc when it
comes to printf.
Consider this program:
{{{
import Text.Printf
import System.Environment
main = do
[who] - getArgs
printf hello, %s\n who
}}}
when compiled:
{{{
$ ghc A.hs
$ ./A world
hello, world
}}}
When run in GHci:
{{{
$ ghci A.hs
Prelude Main :set args world
Prelude Main main
hello, world
*** Exception: Prelude.undefined
}}}
Hmm! And in runhaskell:
{{{
$ runhaskell A.hs world
hello, world
*** Exception: Prelude.undefined
}}}
An ugly 'return ()' seems to help:
{{{
import Text.Printf
import System.Environment
main = do
[who] - getArgs
printf hello, %s\n who
return ()
}}}
which produces:
{{{
$ runhaskell A.hs world
hello, world
}}}
As does an explicit annotation:
{{{
$ cat A.hs
import Text.Printf
import System.Environment
main = do
[who] - getArgs
printf hello, %s\n who :: IO ()
}}}
So some defaulting is coming into play?
{{{
$ ghci
Prelude :l A.hs
*Main :t main
main :: IO t
*Main :set args world
*Main main :: IO ()
hello, world
*Main main :: IO String
hello, world
*** Exception: Prelude.undefined
}}}
Is GHCi/runhaskell giving an overly generous type to 'main'? I note the
following
is also valid runhaskell programs:
{{{
$ cat A.hs
main = return hello, world
$ runhaskell A.hs
hello, world
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1200
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
