Re: [GHC] #698: GHC's internal memory allocator never releases memory back to the OS
#698: GHC's internal memory allocator never releases memory back to the OS -+-- Reporter: guest |Owner: igloo Type: bug | Status: new Priority: low |Milestone: 6.12 branch Component: Runtime System| Version: 6.4.1 Severity: normal| Resolution: Keywords:| Difficulty: Moderate (1 day) Testcase: N/A | Os: Linux Architecture: Unknown/Multiple | -+-- Comment (by simonmar): Jeremy - I think what you're describing here is not related to freeing of memory in the RTS. The virtual memory used by the trivial program is mostly shared libraries. Try `cat /proc/pid/maps` - on my x86_64/Linux system here, the trivial program without `-threaded` needs 16MB of VM, and with `-threaded` needs 20MB. The shared library mappings account for most of the 16MB, and the extra 4MB with `-threaded` is due to the OS threads which seem to reserve 2MB each. GHC's RTS has only allocated 1MB in each case, and there is no memory to free back to the OS. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/698#comment:14 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] #3385: Compiling readline 1.0.1.0 on GHC 6.10.3 causes panic
#3385: Compiling readline 1.0.1.0 on GHC 6.10.3 causes panic -+-- Reporter: gparent |Owner: Type: bug | Status: closed Priority: normal|Milestone: Component: Compiler | Version: 6.10.3 Severity: normal| Resolution: invalid Keywords: readline panic truncated | Difficulty: Unknown Testcase:| Os: Linux Architecture: x86 | -+-- Changes (by simonmar): * status: reopened = closed * resolution: = invalid Comment: Replying to [comment:6 gparent]: I'm sorry, I didn't phrase this correctly. The .hi files weren't in the package I downloaded, they were remnants from an earlier compile of the package that I did myself. So what happened is, I compiled readline-1.0.1.0 for version god-knows- what, and then I tried rebuilding it with a newer GHC version, without cleaning, and I ran into those .hi related errors. No 64-bit involved in the entire process. Just different GHC versions after a package upgrade. runhaskell Setup.hs clean (or if that doesn't work, rm -rf dist), then rebuilding, fixed the problem. Ok, then I'm still slightly mystified, as GHC should have detected that the old `.hi` files were from a different GHC version and emitted a suitable error message. Well, in the absence of any evidence we'll have to leave this one closed. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3385#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] #3375: Add a command-line option to the darcs-all script to specify the darcs repository to use
#3375: Add a command-line option to the darcs-all script to specify the darcs
repository to use
-+--
Reporter: seliopou |Owner: seliopou
Type: feature request | Status: assigned
Priority: normal|Milestone:
Component: Build System | Version: 6.10.3
Severity: trivial | Resolution:
Keywords: darcs git | Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Comment (by simonmar):
Sorry, doesn't work for me:
{{{
~/darcs/ghc-testing ./darcs-all pull
== running darcs pull --repodir . /home/simonmar/ghc-HEAD/ghc
darcs failed: Not a repository: /home/simonmar/ghc-HEAD/ghc
(/home/simonmar/ghc-HEAD/ghc/_darcs/inventory: openBinaryFile: does not
exist (No such file or directory))
darcs failed: 512 at ./darcs-all line 87.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3375#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] #3398: Unicode output in GHC
#3398: Unicode output in GHC ---+ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler |Version: 6.11 Severity: normal| Keywords: Difficulty: Unknown | Testcase: 2816 Os: Unknown/Multiple | Architecture: Unknown/Multiple ---+ Unicode output is somewhat broken in GHC as a whole. We should fix it properly. Most output is generated by the Pretty module. Pretty has two ways to output: * `printLeftRender`, which is used when the rendering mode is `LeftMode`. This method uses the `BufWrite` module to speed up output. For `FastStrings`, the output will be in UTF-8, for strings and other characters the output takes the low 8 bits of each character. * `printDoc`, when used in modes other than `LeftMode` (e.g. for things like error messages and `-ddump`), calls `hPutStr` for strings which uses the prevailing encoding on stdout. However, it calls `hPutFS` for `FastStrings`, which always emits UTF-8. * In GHCi, there is an additional layer due to Haskeline, which pipes all the output through its own decoder (or tries to, I think there are cases not covered). This is all a bit of a mess. We should be using the Unicode layer in the IO library for all encoding/decoding now. I suggest that: * we leave `printLeftRender` alone. It is used for printing things like the `.s` file, and never outputs any Unicode characters because everything is Z-encoded. * `printDoc`, instead of `hPutFS`, should use `hPutStr . decodeFS` * We get rid of the Haskeline decoding layer. However, this will introduce a regression on Windows, because the Haskeline encoding layer currently does code-page encoding. Judah has mentioned looking at doing code-page encoding in the GHC IO library, so let's see what happens there. Once this is done, we can do #2507 (quotation characters in error messages). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3398 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] #3114: ghc -shared --make gives panic
#3114: ghc -shared --make gives panic +--- Reporter: Mark_Spezzano|Owner: Type: bug | Status: new Priority: normal |Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: command line option | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | +--- Changes (by phyx): * cc: phyx (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3114#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] #3094: Some GHC.* module should export word size and heap object header size
#3094: Some GHC.* module should export word size and heap object header size --+- Reporter: duncan |Owner: Type: bug| Status: new Priority: normal |Milestone: 6.12.1 Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | --+- Comment (by duncan): Replying to [comment:2 igloo]: Would you be happy with `GHC.Constants` exporting the same things as `Constants` in the `ghc` package? Yep. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3094#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
[GHC] #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy}
#3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy}
-+--
Reporter: iago | Owner:
Type: proposal | Status: new
Priority: normal| Component: libraries/base
Version: 6.10.4| Severity: normal
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-+--
Better (more general) type signatures would be
{{{
deleteBy :: (b - a - Bool) - b - [a] - [a]
deleteFirstsBy :: (b - a - Bool) - [b] - [a] - [a]
}}}
''Example of why it is useful'':
{{{
deleteBy ((==) . fst) 1 [(1,'a'), (2, 'b')]
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3399
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] #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy}
#3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy}
--+-
Reporter: iago | Owner:
Type: proposal | Status: new
Priority: normal| Milestone:
Component: libraries/base|Version: 6.10.4
Severity: normal| Resolution:
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
--+-
Comment (by iago):
Sorry, the example was wrong, it should be
{{{
deleteBy (\x - (x ==) . fst) 1 [(1,'a'), (2, 'b')]
}}}
or
{{{
deleteBy ((==) . fst) (1,'a') [1,2]
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3399#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
[GHC] #3400: OS X: ghc broken on Snow Leopard
#3400: OS X: ghc broken on Snow Leopard
+---
Reporter: bbb | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 6.10.4 | Severity: critical
Keywords: | Testcase:
Os: MacOS X | Architecture: x86
+---
I downloaded GHC-6.10.4-i386.pkg and installed it on a OS X 10.6 Snow
Leopard seed. gcc in Snow Leopard defaults to x86_64. This breaks even
trivial builds with GHC since it passes either no or incompatible flags.
GHC should either produce proper x86_64 assembly or pass -arch i386 to
force a 32-bit build.
An example follows.
== Trivial source: ==
{{{
$ cat Foo.hs
main = do
putStrLn Foo!
}}}
== Direct build broken: ==
{{{
$ ghc --make Foo.hs -v3
Glasgow Haskell Compiler, Version 6.10.4, for Haskell 98, stage 2 booted
by GHC version 6.10.3.20090628
Using package config file:
/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/./package.conf
hiding package base-3.0.3.1 to avoid conflict with later version
base-4.1.0.0
wired-in package ghc-prim mapped to ghc-prim-0.1.0.0
wired-in package integer mapped to integer-0.1.0.1
wired-in package base mapped to base-4.1.0.0
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0.1.0
wired-in package syb mapped to syb-0.1.0.1
wired-in package template-haskell mapped to template-haskell-2.3.0.1
wired-in package dph-seq mapped to dph-seq-0.3
wired-in package dph-par mapped to dph-par-0.3
Hsc static flags: -static
*** Chasing dependencies:
Chasing modules from: *Foo.hs
Stable obj: []
Stable BCO: []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = Fri Jul 24 11:35:52 PDT 2009
ms_mod = main:Main,
ms_imps = []
ms_srcimps = []
}]
compile: input file Foo.hs
Created temporary directory: /var/folders/p5/p5hZ-
IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24470_0
*** Checking old interface for main:Main:
[1 of 1] Compiling Main ( Foo.hs, Foo.o )
*** Parser:
*** Renamer/typechecker:
*** Desugar:
Result size = 10
*** Simplify:
Result size = 8
*** Tidy Core:
Result size = 8
*** CorePrep:
Result size = 10
*** Stg2Stg:
*** CodeGen:
*** CodeOutput:
*** Assembler:
gcc -I. -c /var/folders/p5/p5hZ-
IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24470_0/ghc24470_0.s -o Foo.o
/var/folders/p5/p5hZ-
IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:36:0:
suffix or operands invalid for `push'
/var/folders/p5/p5hZ-
IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:83:0:
suffix or operands invalid for `push'
/var/folders/p5/p5hZ-
IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:130:0:
suffix or operands invalid for `push'
/var/folders/p5/p5hZ-
IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:156:0:
32-bit absolute addressing is not supported for x86-64
/var/folders/p5/p5hZ-
IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:156:0:
cannot do signed 4 byte relocation
/var/folders/p5/p5hZ-
IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:159:0:
32-bit absolute addressing is not supported for x86-64
/var/folders/p5/p5hZ-
IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:159:0:
cannot do signed 4 byte relocation
*** Deleting temp files:
Deleting: /var/folders/p5/p5hZ-
IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24470_0/ghc24470_0.s
*** Deleting temp dirs:
Deleting: /var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24470_0
}}}
== Via-C build broken: ==
{{{
$ ghc --make Foo.hs -v3 -fvia-c
Glasgow Haskell Compiler, Version 6.10.4, for Haskell 98, stage 2 booted
by GHC version 6.10.3.20090628
Using package config file:
/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/./package.conf
hiding package base-3.0.3.1 to avoid conflict with later version
base-4.1.0.0
wired-in package ghc-prim mapped to ghc-prim-0.1.0.0
wired-in package integer mapped to integer-0.1.0.1
wired-in package base mapped to base-4.1.0.0
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0.1.0
wired-in package syb mapped to syb-0.1.0.1
wired-in package template-haskell mapped to template-haskell-2.3.0.1
wired-in package dph-seq mapped to dph-seq-0.3
wired-in package dph-par mapped to dph-par-0.3
Hsc static flags: -static
*** Chasing dependencies:
Chasing modules from: *Foo.hs
Stable obj: []
Stable BCO: []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = Fri Jul 24 11:35:52 PDT 2009
ms_mod = main:Main,
ms_imps = []
ms_srcimps = []
}]
compile: input file Foo.hs
Created temporary directory: /var/folders/p5/p5hZ-
IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0
*** Checking old
[GHC] #3401: unintuitive error message about unbalanced parentheses
#3401: unintuitive error message about unbalanced parentheses +--- Reporter: tinlyx | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple +--- A minimal test case is as follows: testFunc file = do let file1 = file) return file1 If you try to load it, you will get: ...\test.hs:111:2: The last statement in a 'do' construct must be an expression This error message is kind of unfriendly, and probably only GHC authors know how a mismatched parenthesis can lead to such an error message. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3401 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] #3401: unintuitive error message about unbalanced parentheses
#3401: unintuitive error message about unbalanced parentheses --+- Reporter: tinlyx| Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.10.3 Severity: normal| Resolution: Keywords:| Testcase: Os: Windows | Architecture: Unknown/Multiple --+- Comment (by isaacdupree): I'm not such a GHC author, but it's because the closing-parenthesis terminates the do layout (which is a non-error in some cases if there had been an open-parenthesis before the do for example). I guess it reports the error in do-syntax before getting to the mismatched parenthesis error. That said, I'd think that GHC ought to be able to look ahead more. Also for the mismatched parentheses (maybe incorrect indentation?) error. If parentheses, *regardless* of layout, are still mismatched, then that's definitely an error that could be reported as such :-) (implementing that might be more adifficult though.) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3401#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
