Re: [GHC] #1838: do not use getEnv HOME, use System.Directory.getHomeDirectory
#1838: do not use getEnv HOME, use System.Directory.getHomeDirectory -+-- Reporter: guest| Owner: igloo Type: bug | Status: reopened Priority: high | Milestone: 6.8.3 Component: GHCi |Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -+-- Changes (by simonmar): * priority: normal = high Comment: We definitely need to resolve this for 6.8.3. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1838#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] #955: more object-code blow-up in ghc-6.6 vs. ghc-6.4.2 (both with optimization)
#955: more object-code blow-up in ghc-6.6 vs. ghc-6.4.2 (both with optimization) --+- Reporter: [EMAIL PROTECTED] | Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler |Version: 6.6 Severity: normal| Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase:| Architecture: Multiple Os: Multiple | --+- Changes (by simonmar): * type: bug = run-time performance bug -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/955#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] #1136: High memory use when compiling many let bindings.
#1136: High memory use when compiling many let bindings. --+- Reporter: igloo | Owner: Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler |Version: 6.6 Severity: normal| Resolution: Keywords: performance | Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by simonmar): * type: bug = compile-time performance bug -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1136#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] #1818: Code size increase vs. 6.6.1
#1818: Code size increase vs. 6.6.1 --+- Reporter: simonmar | Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler |Version: 6.8.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by simonmar): * type: bug = run-time performance bug -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1818#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] #1889: Regression in concurrency performance from ghc 6.6 to 6.8
#1889: Regression in concurrency performance from ghc 6.6 to 6.8 ---+ Reporter: dons | Owner: simonmar Type: run-time performance bug | Status: new Priority: high | Milestone: 6.8.3 Component: Runtime System |Version: 6.8.1 Severity: normal | Resolution: Keywords: threads, concurrency, performance | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---+ Changes (by simonmar): * type: bug = run-time performance bug -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1889#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
Re: [GHC] #149: missed CSE opportunity
#149: missed CSE opportunity --+- Reporter: nobody| Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler |Version: 5.04.2 Severity: normal| Resolution: None Keywords: optimisations | Difficulty: Unknown Testcase: simplrun006 | Architecture: Unknown Os: Unknown | --+- Changes (by simonmar): * type: bug = run-time performance bug -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/149#comment:8 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] #1890: Regression in mandelbrot benchmark due to inlining
#1890: Regression in mandelbrot benchmark due to inlining --+- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler (NCG)|Version: 6.8.1 Severity: normal| Resolution: Keywords: asm, double | Difficulty: Unknown Testcase:| Architecture: x86_64 (amd64) Os: Unknown | --+- Changes (by simonmar): * type: bug = run-time performance bug -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1890#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] #2002: problems with very large (list) literals
#2002: problems with very large (list) literals --+- Reporter: Isaac Dupree | Owner: Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler |Version: 6.8.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: x86 Os: Linux | --+- Changes (by simonmar): * type: bug = compile-time performance bug -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2002#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] #783: performance problem compiling large file
#783: performance problem compiling large file --+- Reporter: guest | Owner: Type: compile-time performance bug | Status: new Priority: normal| Milestone: 6.8.3 Component: Compiler |Version: 6.4.2 Severity: normal| Resolution: Keywords: performance | Difficulty: Unknown Testcase:| Architecture: Multiple Os: Multiple | --+- Changes (by simonmar): * type: bug = compile-time performance bug -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/783#comment:10 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] #1969: enormous compile times
#1969: enormous compile times --+- Reporter: duncan| Owner: Type: compile-time performance bug | Status: new Priority: normal| Milestone: 6.8.3 Component: Compiler |Version: 6.8.1 Severity: normal| Resolution: Keywords: performance | Difficulty: Difficult (1 week) Testcase:| Architecture: Multiple Os: Multiple | --+- Changes (by simonmar): * type: bug = compile-time performance bug -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1969#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] #1875: Compiling with -O is 30 times slower than with -Onot
#1875: Compiling with -O is 30 times slower than with -Onot --+- Reporter: simonpj | Owner: Type: compile-time performance bug | Status: new Priority: normal| Milestone: 6.8.3 Component: Compiler |Version: 6.8.1 Severity: normal| Resolution: Keywords: performance | Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by simonmar): * type: bug = compile-time performance bug -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1875#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] #1747: debugger: :trace is wasting time
#1747: debugger: :trace is wasting time --+- Reporter: simonmar | Owner: Type: compile-time performance bug | Status: new Priority: low | Milestone: 6.8.3 Component: GHCi |Version: 6.6.1 Severity: minor | Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by simonmar): * type: bug = compile-time performance bug -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1747#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: haskell package installation problem
Brian Park wrote: Hi, I was installing various haskell packages from hackage. When I was installing HaXml, I think it was complaining about Text.PrettyPrint.HughesPJ not installed or something. (can't remember the specific message and I can't reproduce now...) HaXml-1.13.2 needs pretty and containers as additional build-depends in HaXml.cabal for ghc-6.8.x (HaXml-1.13.3 should work). I don't know about http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HaXml-1.19.1 So I installed pretty-1.0.0.0 package as well. bad move, Cabal itself depends on (this) pretty (package). Reinstalling pretty failed and spoiled you're installation. Maybe such kind of (re-)installation should be prohibited somehow. Cheers Christian Ever since then, when I try to install other haskell packages, I get the following error message: [EMAIL PROTECTED]:~/Download/mtl-1.1.0.0$ runghc Setup.hs configure interactive: /usr/local/lib/ghc-6.8.2/lib/Cabal-1.2.3.0/HSCabal-1.2.3.0.o http://1.2.3.0/HSCabal-1.2.3.0.o: unknown symbol `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl18_closure' ghc-6.8.2: unable to load package `Cabal-1.2.3.0 http://1.2.3.0' Does anyone know what the problem is? Currently installed packages are: = /usr/local/lib/ghc-6.8.2/package.conf: Cabal-1.2.3.0, HTTP-3001.0.4, HUnit-1.2.0.0, X11-1.4.1, array-0.1.0.0, base-3.0.1.0, bytestring-0.9.0.1, containers-0.1.0.1, directory-1.0.0.0, filepath-1.1.0.0, (ghc-6.8.2), haskell98-1.0.1.0 , hpc-0.5.0.0, hxt-7.4, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, packedstring-0.1.0.0, parsec-2.1.0.0, polyparse-1.1, pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, readline-1.0.1.0 , rts-1.0, template-haskell-2.2.0.0, unix-2.3.0.0, xmonad-0.5, xmonad-contrib-0.5 = Thank you, - Brian ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
#1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0 --+- Reporter: wb.kloke | Owner: Type: bug | Status: new Priority: normal| Milestone: 6.8.3 Component: Compiler |Version: 6.8.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: x86_64 (amd64) Os: FreeBSD | --+- Comment (by simonmar): While I'm happy that you've tracked down the problem, I don't fully understand your explanation. The compat library is linked into the stage1 compiler, and hence it should be compiled by the same compiler you use to build stage1, i.e. the bootstrap compiler. compat isn't linked into any program that the stage1 compiler builds, including `arith003`. So I'm not sure how the compat library could contribute to this problem you observed. The only reason to rebuild compat after building stage1, is in order to build the programs in `utils/` using the stage1 compiler, and in fact we do this when building distributions (see the `binary-dist` target in the top-level `Makefile`). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1989#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] #1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
#1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0 --+- Reporter: wb.kloke | Owner: Type: bug | Status: new Priority: normal| Milestone: 6.8.3 Component: Compiler |Version: 6.8.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: x86_64 (amd64) Os: FreeBSD | --+- Comment (by wb.kloke): Thinking again about this, I agree that my former idea where the bug may have hibernated is too short-sighted. Though, the utils may have been the place. The only other place is the rts, where I used the stage2 generated files with only the ostensibly bad StgStdThunks.o and StgMisc...o replaced by those compiled with the stage1 cross compiler from i386. I don't know whether this is really worth to tracked down further. This type of failure should only happen in the special case of systems which allow to use both 64bit and 32bit applications and the 32bit system is used to bootstrap the 64bit compiler. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1989#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] #1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
#1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0 --+- Reporter: wb.kloke | Owner: Type: bug | Status: closed Priority: normal| Milestone: 6.8.3 Component: Compiler |Version: 6.8.2 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Testcase:| Architecture: x86_64 (amd64) Os: FreeBSD | --+- Changes (by simonmar): * status: new = closed * resolution: = fixed Comment: Ok, closing the bug. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1989#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] #2021: let ghc find framework header files and link with frameworks located in $HOME/Library/Frameworks
#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
+---
Reporter: maeder | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.8.2
Severity: normal |Keywords:
Difficulty: Easy (1 hr) |Testcase:
Architecture: Multiple | Os: MacOS X
+---
As described in ticket #1395 I want ghc to be able to work with my local
frameworks. Therefore I've extended the file
`compiler/main/DriverPipeline.hs`.
In my latest (attached) version I've also removed a few duplications.
I've considered to check if the directory `$HOME/Library/Frameworks`
exists using `doesDirectoryExist`, but that's done anyway by gcc and ld on
mac. I've also considered to only pass
`-F$HOME/Library/Frameworks` if there are `-framework` flags on the
command line at all, but this did not work for `HsReadline_cbits.c`:
{{{
../../compiler/stage1/ghc-inplace -Iinclude -package base-3.0.1.0 -package
process-1.0.0.0 -optc-O2 -odir dist/build -c HsReadline_cbits.c -o
dist/build/HsReadline_cbits.o
In file included from HsReadline_cbits.c:1:0:
include/HsReadline.h:7:43:
error: GNUreadline/readline/readline.h: No such file or directory
include/HsReadline.h:8:42:
error: GNUreadline/readline/history.h: No such file or directory
HsReadline_cbits.c: In function 'hs_rl_message':
HsReadline_cbits.c:5:0:
warning: implicit declaration of function 'rl_message'
make[2]: *** [dist/build/HsReadline_cbits.o] Error 1
make[1]: *** [make.library.readline] Error 2
make: *** [stage1] Error 2
}}}
This (single) case may be fixed by passing `-F$HOME/Library/Frameworks`
manually, but what is the risk of passing `-F$HOME/Library/Frameworks`
always? Well, someone may have spoiled frameworks there, but even that is
no problem as long as they are not used, because dylibs are used instead.
Of course other C-compilers may not like the -F flag (in fact that is a
problem if ghc is used as C-compiler and was actually bad for hsc2hs
#1395).
Maybe configure should check if gcc understands -F on macs? What do others
think? Would you commit my `DriverPipeline.hs` changes?
A `diff -u -w` currently looks as follows:
{{{
+++ compiler/main/DriverPipeline.hs 2008-01-07 14:39:12.0
+0100
@@ -822,6 +822,9 @@
let include_paths = foldr (\ x xs - -I : x : xs) []
(cmdline_include_paths ++ pkg_include_dirs)
+#ifdef darwin_TARGET_OS
+framework_path_opts - getFrameworkPathOpts dflags pkgs
+#endif
let (md_c_flags, md_regd_c_flags) = machdepCCOpts dflags
gcc_extra_viac_flags - getExtraViaCOpts dflags
let pic_c_flags = picCCOpts dflags
@@ -905,6 +908,9 @@
++ cc_opts
++ split_opt
++ include_paths
+#ifdef darwin_TARGET_OS
+ ++ framework_path_opts
+#endif
++ pkg_extra_cc_opts
))
@@ -1199,17 +1205,10 @@
pkg_link_opts - getPackageLinkOpts dflags dep_packages
#ifdef darwin_TARGET_OS
-pkg_framework_paths - getPackageFrameworkPath dflags dep_packages
-let pkg_framework_path_opts = map (-F++) pkg_framework_paths
-
-let framework_paths = frameworkPaths dflags
-framework_path_opts = map (-F++) framework_paths
-
+framework_path_opts - getFrameworkPathOpts dflags dep_packages
pkg_frameworks - getPackageFrameworks dflags dep_packages
-let pkg_framework_opts = concat [ [-framework, fw] | fw -
pkg_frameworks ]
-
-let frameworks = cmdlineFrameworks dflags
-framework_opts = concat [ [-framework, fw] | fw - reverse
frameworks ]
+let framework_opts = concat [ [-framework, fw]
+ | fw - pkg_frameworks ++ reverse (cmdlineFrameworks dflags) ]
-- reverse because they're added in reverse order from the cmd
line
#endif
@@ -1264,10 +1263,6 @@
#endif
++ pkg_lib_path_opts
++ pkg_link_opts
-#ifdef darwin_TARGET_OS
- ++ pkg_framework_path_opts
- ++ pkg_framework_opts
-#endif
++ debug_opts
++ thread_opts
))
@@ -1278,6 +1273,15 @@
if success then return ()
else throwDyn (InstallationError (cannot move
binary to PVM dir)))
+-- options to pass to gcc and ld on macs only
+getFrameworkPathOpts :: DynFlags - [PackageId] - IO [String]
+getFrameworkPathOpts dflags pkgs = do
+ ps - getPackageFrameworkPath dflags pkgs
+ let fps = ps ++
Re: [GHC] #1395: let ./configure check for a GNUreadline framework
#1395: let ./configure check for a GNUreadline framework -+-- Reporter: [EMAIL PROTECTED]| Owner: Type: feature request | Status: reopened Priority: normal | Milestone: 6.8 branch Component: Build System |Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: MacOS X | -+-- Comment (by maeder): I've created #2021 for the `DriverPipeline.hs` issue. The subject of this ticket can be settled by committing `libraries/readline/configure.ac` and `libraries/Makefile` afterwards. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1395#comment:29 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] #2022: DLL support broken
#2022: DLL support broken -+-- Reporter: mte | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 6.8.2 Severity: normal|Keywords: Difficulty: Unknown |Testcase: Architecture: x86 | Os: Windows -+-- Creating a DLL using the -shared option does not work for me: 1. ghc tries to create a static library (foobar.dll.a). 2. The linker complains about missing symbols. Building an executable from the same project works fine and the resulting executable runs all unit tests without errors. With 6.6 and the --mk-dll option, the DLL was built without problems. /vol/c/ghc/ghc-6.8.2/bin/ghc.exe \ -fglasgow-exts -odir ../targets/i686-CYGWIN_NT-5.1/plain -hidir ../targets/i686-CYGWIN_NT-5.1/plain -i../targets/i686-CYGWIN_NT-5.1/plain +RTS -M64m -RTS \ -shared \ -o ../targets/i686-CYGWIN_NT-5.1/plain/foobar.dll \ foobar.def \ ../targets/i686-CYGWIN_NT-5.1/plain/*.o Creating library file: ..\targets\i686-CYGWIN_NT-5.1\plain\foobar.dll.a ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1696):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x44c3):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_zdf3_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x7e6d):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xf392):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xf3f6):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_insert_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xf8e3):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xf933):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_sizze_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xffae):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x10012):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_insert_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x10076):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x100c7):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x101ef):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_null_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x125e7):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_toAscList_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x133e2):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1c91f):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1ca0f):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_sizze_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1cecb):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_sizze_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1cfb0):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1f3ec):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_singleton_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1fdd5):fake: undefined reference to `__stginit_arrayzm0zi1zi0zi0_DataziArray_' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1fdf3):fake: undefined reference to `__stginit_containerszm0zi1zi0zi1_DataziSet_' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1fdfd):fake: undefined reference to `__stginit_haskell98_List_' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1fe07):fake: undefined reference to `__stginit_haskell98_Maybe_' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x124):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x3dc):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_zdf3_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x4a8):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xdc0):fake: undefined
[GHC] #2023: Packages.lhs:mungePackagePaths doesn't handle haddock-html haddock-interfaces
#2023: Packages.lhs:mungePackagePaths doesn't handle haddock-html haddock- interfaces +--- Reporter: guest| Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal |Keywords: packages Difficulty: Easy (1 hr) |Testcase: Architecture: Unknown | Os: Unknown +--- Substitution for $topdir et al should be done for haddock-html and haddock-interfaces as well. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2023 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
hs-boot types in 6.8.2
Dear GHC developers, This is about possibile bug in ghc-6.8.2 related to types in hs-boot. I have a project with module import loop, in which the module Split imports the source of Reduce. Now, I changed the type of the function Reduce.evaluate_c and forgotten to change it in Reduce.hs-boot. When GHC `makes' this project (under Cabal), it first processes Reduce[boot], and then gets to Split.hs: -- [16 of 45] Compiling Dumatel.Reduce[boot] ( Dumatel/Reduce.hs-boot, dist/build/Dumatel/Reduce.o-boot ) [17 of 45] Compiling Split( Split.hs, dist/build/Split.o ) Split.hs:393:58: Couldn't match expected type `Term' against inferred type `[a]' In the third argument of `evaluate_c', namely `[]' ... - -- and it only reports of several type mismatches in Split.hs. If the user guesses to fix the type in Reduce.hs-boot, the `make' improves. In many situations, GHC reports first what namely is the type disagreement between *.hs and *.hs-boot. But not in this situation. And here the report is misleading: the user looks into Reduce.hs and Splis.hs, and wonders what is wrong with types. Can this be fixed ? If you ask me, I would provide the source on www. Thank you in advance for your explanation. - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: hs-boot types in 6.8.2
Hi Serge, On Mon, Jan 07, 2008 at 06:56:13PM +0300, Serge D. Mechveliani wrote: In many situations, GHC reports first what namely is the type disagreement between *.hs and *.hs-boot. We can't look for differences between Reduce.hs-boot and Reduce.hs until we have typechecked Reduce.hs, and we can't do that until we have compiled Split.hs. Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1907: HPC and Template Haskell don't mix
#1907: HPC and Template Haskell don't mix ---+ Reporter: guest | Owner: AndyGill Type: bug| Status: new Priority: normal | Milestone: 6.10 branch Component: Code Coverage |Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown| ---+ Changes (by AndyGill): * owner: [EMAIL PROTECTED] = AndyGill -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1907#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] #2019: GADT record with polytype argument causes irrefutable pattern failure in basicTypes/MkId.lhs
#2019: GADT record with polytype argument causes irrefutable pattern failure in
basicTypes/MkId.lhs
-+--
Reporter: japple | Owner: igloo
Type: merge| Status: new
Priority: normal | Milestone: 6.8.3
Component: Compiler |Version: 6.8.2
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: tcfail195, tcfail196, tcfail197 | Architecture: x86
Os: Linux|
-+--
Changes (by simonpj):
* testcase: = tcfail195, tcfail196, tcfail197
* owner: = igloo
* type: bug = merge
Comment:
Shouldn't be valid; in general equality constraints can't involve
polytypes. I'm adding a test in the code, and some testsuite cases.
Thanks for pointing this out.
Ian can you merge this:
{{{
Mon Jan 7 12:53:22 GMT 2008 [EMAIL PROTECTED]
* Add tests for type signature validity (cf Trac 2019)
}}}
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2019#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] #2017: Normal Guards are internally spliced as Pattern Guards causing compiler warnings
#2017: Normal Guards are internally spliced as Pattern Guards causing compiler
warnings
--+-
Reporter: fons | Owner: igloo
Type: merge | Status: new
Priority: normal| Milestone:
Component: Template Haskell |Version: 6.8.2
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase: TH_spliceGuard| Architecture: Unknown
Os: Unknown |
--+-
Changes (by simonpj):
* testcase: = TH_spliceGuard
* owner: = igloo
* type: bug = merge
Comment:
Good point. The fix is trivial, and makes the code simpler. I'm not at
all sure why it was the way it was.
Please merge this patch
{{{
Mon Jan 7 12:58:19 GMT 2008 [EMAIL PROTECTED]
* Fix Trac #2017
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2017#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: hs-boot types in 6.8.2
On Mon, Jan 07, 2008 at 04:37:16PM +, Ian Lynagh wrote: Hi Serge, On Mon, Jan 07, 2008 at 06:56:13PM +0300, Serge D. Mechveliani wrote: In many situations, GHC reports first what namely is the type disagreement between *.hs and *.hs-boot. We can't look for differences between Reduce.hs-boot and Reduce.hs until we have typechecked Reduce.hs, and we can't do that until we have compiled Split.hs. I see. Thank you. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2020: configure script shipped with ghc is built by broken version of autoconf
#2020: configure script shipped with ghc is built by broken version of autoconf --+- Reporter: bos | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.8.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Comment (by bos): Unfortunately, rebuilding ghc after rebuilding the configure scripts was not in itself enough to fix the problem. Even when I configure with --docdir=/usr/share/doc/ghc-6.8.2, the package.conf file still contains directories of the form /usr/share/doc/ghc. I'm adding --htmldir=/usr/share/doc/ghc-6.8.2 to the configure line to see if that helps. The turnaround time for these tests is long, because they're run on the distro's main build servers, in clean source trees :-) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2020#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] #2021: let ghc find framework header files and link with frameworks located in $HOME/Library/Frameworks
#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-+--
Reporter: maeder | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler |Version: 6.8.2
Severity: normal | Resolution:
Keywords: | Difficulty: Easy (1 hr)
Testcase: | Architecture: Multiple
Os: MacOS X |
-+--
Comment (by thorkilnaur):
I have not been able to find any mention in Apple documentation (man gcc,
man ld,
http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/BPFrameworks.pdf)
that $HOME/Library/Frameworks is to be searched automatically. In fact,
the latter document says
{{{
Applications that link to frameworks in other directories, such as
~/Library/Frameworks or /Network/Library/Frameworks, must specify the
exact path to the framework at build time so that the dynamic linker can
find it.
}}}
I do not believe that GHC should provide such an additional service: In
some cases, it will cause confusion and additional work.
If the problem is that GHC is not able to pass enough framework-related
parameters to gcc, ld, and possibly other programs, then that is the
problem to be solved. That would also allow someone to store local
frameworks in any desired location, in addition to
$HOME/Library/Frameworks.
As I have mentioned elsewhere (http://haskell.org/pipermail/glasgow-
haskell-users/2008-January/014022.html), I see a need to figure out a
comprehensive solution to this framework-related matter. I do not
presently see such a comprehensive solution. Until I do, I am unable to
tell whether any particular step goes in the right direction or is merely
a temporary hack to get out of a tight spot.
Best regards
Thorkil
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2021#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] #2020: configure script shipped with ghc is built by broken version of autoconf
#2020: configure script shipped with ghc is built by broken version of autoconf --+- Reporter: bos | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.8.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Comment (by bos): Adding --htmldir does not help, either. I conclude that docdir and htmldir are somehow going missing. If you'd like to see the output from a build that verifies that docdir and htmldir are being used properly, please take a look here: http://koji.fedoraproject.org/koji/getfile?taskID=331547name=build.log -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2020#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] #2020: configure script shipped with ghc is built by broken version of autoconf
#2020: configure script shipped with ghc is built by broken version of autoconf
--+-
Reporter: bos | Owner:
Type: bug | Status: closed
Priority: normal| Milestone:
Component: Compiler |Version: 6.8.2
Severity: normal| Resolution: wontfix
Keywords:| Difficulty: Unknown
Testcase:| Architecture: Unknown
Os: Unknown |
--+-
Changes (by igloo):
* status: new = closed
* resolution: = wontfix
Comment:
We still want to be able to build on machines with older autoreconf's (as
some of the nightly builders, and probably some of the developer's
machines, still have it). That means that we can't rely on the docdir flag
existing, so we ignore its value.
You can specify docdir by setting the variable in `mk/build.mk`.
Unfortunately, this doesn't modify htmldir etc in the way that you would
expect. When building the Debian packages we put these lines in
`mk/build.mk`:
{{{
docdir := $(datarootdir)/doc/ghc6-doc
htmldir := $(docdir)
dvidir := $(docdir)
pdfdir := $(docdir)
psdir := $(docdir)
}}}
This code is due to be rewritten in 6.10 so that only the first line is
necessary: see #1924.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2020#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] #2021: let ghc find framework header files and link with frameworks located in $HOME/Library/Frameworks
#2021: let ghc find framework header files and link with frameworks located in $HOME/Library/Frameworks -+-- Reporter: maeder | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler |Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: MacOS X | -+-- Comment (by guest): Replying to [comment:1 thorkilnaur]: If the problem is that GHC is not able to pass enough framework-related parameters to gcc, ld, and possibly other programs, then that is the problem to be solved. That would also allow someone to store local frameworks in any desired location, in addition to $HOME/Library/Frameworks. GHC can pass -F (the only relevant parameter, I believe) to `gcc` and `ld` just fine. The problem IMHO is that there's no way to run the build of ghc+libraries as a whole against an extra framework directory without editing several different `Makefile` and/or `.cabal` files. I think this problem will be solved when at most one change is required to, for example, link the build against a version of `GNUreadline.framework` which is in a nonstandard location. That change could be one of (but not limited to): editing `mk/build.mk` or `readline.cabal`, or passing a configure flag. Incidentally, the above was my reason for proposing the following Cabal enhancement: http://hackage.haskell.org/trac/hackage/ticket/189 -Judah -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2021#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
[GHC] #2024: Template Haskell doesn't work well with Lexically Scoped Type Variables
#2024: Template Haskell doesn't work well with Lexically Scoped Type Variables
-+--
Reporter: fons | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Template Haskell | Version: 6.8.2
Severity: normal|Keywords:
Difficulty: Unknown |Testcase:
Architecture: Unknown | Os: Unknown
-+--
I don't know if TH is meant to work properly with LSTV. I don't personally
need it and I run into this bug by chance, but at least I think that the
error should be friendlier in any case. See this (pretty stupid, sorry)
example.
Foo.hs
{{{
{-# LANGUAGE TemplateHaskell, ScopedTypeVariables #-}
module Foo where
myid :: forall a . a - a
myid = $([| (\x - x) :: (a - a) |])
}}}
Ghci shows this user-unfriendly error:
{{{
$ ghci Foo.hs
GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
[1 of 1] Compiling Foo ( Foo.hs, interpreted )
Foo.hs:6:12:
DsMeta: failed binder lookup when desugaring a TH bracket: a
Failed, modules loaded: none.
Prelude
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2024
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] #1599: testsuite timeout doesn't kill subprocesses on Windows
#1599: testsuite timeout doesn't kill subprocesses on Windows
+---
Reporter: simonmar| Owner: igloo
Type: bug | Status: new
Priority: normal | Milestone: 6.8 branch
Component: Test Suite |Version: 6.6.1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: x86
Os: Windows |
+---
Comment (by igloo):
Using this python program:
{{{
#!/usr/bin/python
from killableprocess import *
from sys import argv
p = Popen(args=argv[1])
r = p.wait(timeout=1)
print r
}}}
and this Haskell program:
{{{
import Foreign.C
import System.Cmd
import System.IO
main :: IO ()
main = do hSetBuffering stdout NoBuffering
putStrLn start main
-- rawSystem c:/cygwin/bin/sh
-- [-c, echo wibble; sleep 3; echo flibble]
-- system sh -c \echo wibble; sleep 3; echo flibble\
withCString sh -c \echo wibble; sleep 3; echo flibble\ s
putStrLn end main
foreign import ccall stdlib.h system s :: CString - IO CInt
}}}
it doesn't seem to work (the flibble on the last line is printed after
the command has terminated):
{{{
$ ghc --make Foo -fffi
[1 of 1] Compiling Main ( Foo.hs, Foo.o )
Linking Foo.exe ...
$ ./ptimeout.py ./Foo
start main
wibble
-9
$ flibble
}}}
Even with this C program:
{{{
#include stdio.h
#include stdlib.h
int main(void) {
printf(start main\n);
system(sh -c \echo wibble; sleep 3; echo flibble\);
printf(end main\n);
}
}}}
it doesn't seem to work right:
{{{
$ gcc c.c -o c
$ ./ptimeout.py ./c
start main
wibble
flibble
-9
$ ./ptimeout.py ./c
start main
wibble
-9
end main
$ ./ptimeout.py ./c
start main
wibble
-9
}}}
The C++ program that is linked to also doesn't work for me:
{{{
$ Debug/killableprocess.exe ./c
start main
end main
$
}}}
I'll try to investigate further.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1599#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] #2021: let ghc find framework header files and link with frameworks located in $HOME/Library/Frameworks
#2021: let ghc find framework header files and link with frameworks located in $HOME/Library/Frameworks -+-- Reporter: maeder | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler |Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: MacOS X | -+-- Comment (by thorkilnaur): This sounds like a problem in the GHC build process, then. Not something that should necessarily involve changes to GHC (as proposed in the present ticket). Nor to Cabal, for that matter (http://hackage.haskell.org/trac/hackage/ticket/189). I still believe that we must start out by figuring out what the total problem is. So in this case, I would expect to start out with a detailed list of changes, under the present circumstances, needed to add whatever framework-related parameters are needed in whatever phase of the GHC/libraries build process they are needed, to introduce a new framework. And then, in terms of the GHC/libraries build process, figure out a way to become able to, as you say, introduce the framework in just one place. It may very well turn out that we find, in this process, that some other component, GHC, Cabal, some utility program, also needs to be extended: hsc2hs has been discussed, the Haskell CPP implementation comes to mind as another place where changes might be needed. But without the total view, it is difficult to decide whether any particular proposed change makes sense. Best regards Thorkil -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2021#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
