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: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by YitzGale): * cc: g...@sefer.org (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/698#comment:23 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] #3400: OS X: ghc broken on Snow Leopard
#3400: OS X: ghc broken on Snow Leopard -+-- Reporter: bbb |Owner: igloo Type: bug | Status: closed Priority: high |Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: blocker | Resolution: fixed Keywords:| Difficulty: Unknown Testcase:| Os: MacOS X Architecture: x86 | -+-- Comment (by chak): Replying to [comment:17 guest]: It doesn't seem to allow linking with 64-bit OSX libraries like XLib (e.g. for xmonad). Am I right ? The libraries on Snow Leopard are shipped as universal binaries containing code for PPC, i386, and x86_64. When a 32-bit GHC invokes the linker, it will automatically pick the 32-bit version of the library. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3400#comment:18 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] #3618: memory-leak detector in +RTS -DS fails to track allocations in constructors
#3618: memory-leak detector in +RTS -DS fails to track allocations in constructors ---+ Reporter: guest |Owner: Type: bug | Status: new Priority: normal |Milestone: _|_ Component: Runtime System | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | ---+ Comment (by augustss): I find it highly dubious to leave this unfixed. The ghc rts is called before it has been initialized, so I'd say that if it works it's more of a fluke than by design. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3618#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] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions
#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
--+-
Reporter: eflister | Owner:
Type: feature request | Status:
new
Priority: normal| Milestone:
Component: Compiler (Parser) |Version:
6.10.4
Severity: trivial | Resolution:
Keywords: language pragma extensions error message warning | Testcase:
Os: Unknown/Multiple | Architecture:
Unknown/Multiple
--+-
Comment (by duncan):
By all means improve the error message but please do not extend the
LANGUAGE pragma syntax. It means every other compiler and tool that has to
know about the pragma must also be extended (and in a rather quirky way).
Standards are a good thing! :-)
Perhaps we can get ghc's error messages to suggest LANGUAGE pragmas rather
than the ghc -XBlah style.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3647#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] #3643: building heliumeditor
#3643: building heliumeditor -+-- Reporter: cyberpuff |Owner: Type: bug | Status: closed Priority: normal|Milestone: Component: Compiler | Version: 6.10.4 Severity: normal| Resolution: invalid Keywords:| Difficulty: Unknown Testcase:| Os: Linux Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * status: new = closed * difficulty: = Unknown * resolution: = invalid Comment: This happens when the package author leaves some `.hi` files in the package. I believe GHC 6.12.1 should just ignore the invalid `.hi` files instead of giving this panic. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3643#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] #3618: memory-leak detector in +RTS -DS fails to track allocations in constructors
#3618: memory-leak detector in +RTS -DS fails to track allocations in constructors ---+ Reporter: guest |Owner: Type: bug | Status: new Priority: normal |Milestone: _|_ Component: Runtime System | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | ---+ Comment (by simonmar): Replying to [comment:3 augustss]: I find it highly dubious to leave this unfixed. The ghc rts is called before it has been initialized, so I'd say that if it works it's more of a fluke than by design. I'm sure it's safe: we're only calling the RTS in one way, `getStablePtr`, and we're careful to ensure that can be called before the RTS is initialised. It is also thread-safe. I just looked back through the commit logs and it seems that we switched to using constructors for registering foreign exports for binary size reasons (to eliminate the __stginit functions in the common case), but then we reinstated __stginit later. So perhaps the constructors aren't really helping. However, if we're going to redesign things here, I think we should look for a way to eliminate the need to call `hs_add_root` when initialising the RTS, which is both non-standard and annoying. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3618#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] #3441: readProcess ... (exit 11): failed
#3441: readProcess ... (exit 11): failed +--- Reporter: Andriy |Owner: simonmar Type: bug | Status: new Priority: normal |Milestone: 6.12.1 Component: libraries/process| Version: 6.10.3 Severity: major| Resolution: Keywords: readProcess exit 11 | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | +--- Comment (by Andriy): You can download the core dump from http://www.4shared.com/file/149063065/6989f63d/core9885.html Yes, I use the 6.10.3 x86/Linux binary distribution I downloaded and set up manually. Unfortunately I could not find a reproducable test case. I did experiment with a toy long-running processes - no luck. After I submitted the bug report the problem started to happen very infrequently. This may something to do with the changes I made to the program. I'll update to a more recent version of ghc. compile your program with -debug I run the program with runghc, without compiling it. I'll start passing -debug to GHC if I see the problem with the latest GHC. Andriy -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3441#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
[GHC] #3649: inconsistent exception between unix/windows for running non-existant program
#3649: inconsistent exception between unix/windows for running non-existant
program
-+--
Reporter: duncan| Owner:
Type: bug | Status: new
Priority: normal| Component: libraries/process
Version: 6.10.4| Severity: normal
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-+--
{{{
handle (print . isDoesNotExistError) $ do
(_,_,_,hnd) - createProcess (proc foobar [])
print = waitForProcess hnd
}}}
On Windows this prints `True` since it throws a does not exists kind of
IOException. On Unix instead the createProcess call succeeds and then
waiting on the process claims it terminated with an exit code of 127.
It is annoying that we need two different error handling mechanisms in
this case. For example Cabal wants to know when it tries to run a program
that cannot be found (eg when it tries to run sh.exe on Windows).
It would be better if the behaviour was consistent. The behaviour on
Windows seems to be the more sensible one. We should be able to make the
Unix behaviour the same since the exceve call does indeed return an error
code when loading the new executable image fails.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3649
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] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions
#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
--+-
Reporter: eflister | Owner:
Type: feature request | Status:
new
Priority: normal| Milestone:
Component: Compiler (Parser) |Version:
6.10.4
Severity: trivial | Resolution:
Keywords: language pragma extensions error message warning | Testcase:
Os: Unknown/Multiple | Architecture:
Unknown/Multiple
--+-
Comment (by eflister):
not to be annoying, but i don't understand why it's not ok for ghc to
accept (with a warning) a SUPERSET of the official syntax. that doesn't
change the standard and it doesn't imply that any other compiler has to do
anything different. a warning would be the best user interaction -- i
know what you meant to say, and i'm doing it, you should just know that
what you said isn't portable, and here's how to fix it. would you like me
to fix it for you?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3647#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] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions
#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
--+-
Reporter: eflister | Owner:
Type: feature request | Status:
new
Priority: normal| Milestone:
Component: Compiler (Parser) |Version:
6.10.4
Severity: trivial | Resolution:
Keywords: language pragma extensions error message warning | Testcase:
Os: Unknown/Multiple | Architecture:
Unknown/Multiple
--+-
Comment (by duncan):
Replying to [comment:2 eflister]:
not to be annoying, but i don't understand why it's not ok for ghc to
accept (with a warning) a SUPERSET of the official syntax.
At first you'd expect that accepting a superset would not cause any
problems. However what happens is that people will start using that new
syntax and then suddenly those packages/programs cannot be used with the
tools that stick to the official syntax.
that doesn't change the standard and it doesn't imply that any other
compiler has to do anything different.
It doesn't change the official standard but it does change the de-facto
standard, and other compilers and tools will have to change to keep up so
that they can continue to process all code that people write.
a warning would be the best user interaction -- i know what you meant
to say, and i'm doing it, you should just know that what you said isn't
portable, and here's how to fix it. would you like me to fix it for you?
Certainly a nice error message is good however I would suggest that it be
i know what you meant to say, here's how to fix it. (and perhaps an IDE
could also do would you like me to fix it for you?). Also accepting the
program has a low benefit and a non-trivial cost.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3647#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] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -+-- Reporter: Isaac Dupree |Owner: Type: feature request | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 6.10.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by lambda_belka): * cc: lambda-be...@yandex.ru (added) Comment: This restriction was a very unpleasant surprise. Double maintenance problem. It's hard to believe, that the feature is so hard to enable. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1409#comment:33 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] #3650: Add a Natural number type to the pre-defined basic types.
#3650: Add a Natural number type to the pre-defined basic types. -+-- Reporter: JohnD | Owner: Type: proposal | Status: new Priority: normal| Component: Compiler (Type checker) Version:| Severity: normal Keywords:| Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -+-- See [http://hackage.haskell.org/trac/haskell-prime/wiki/Natural] concerning Add a Natural number type to the pre-defined basic types. I will add a link from that page to this one. That was the Haskell prime wiki which is my understanding concerns discussions concerning the Haskell language in general. It seems conceivable that GHC may be uniquely positioned to address this problem. Haskell was designed to explorer a problem that is of academic interest. Why else is the language lazy and statically typed? It's all about purity. To provide a synopsis it dates back to the discovery that untyped lambda calculus is a model of computation and not that of logic. At first blush one might conclude that there is good reason why there is no natural number type. Natural numbers are problematic. For example, you can add them, but you cannot in general subtract them. In the general case subtraction yields an integer type, not a natural number type. This problem could be solved through duck typing, but that isn't what Haskell or ML is about. With duck typing you can compare two values at runtime to ensure that the result yields a natural number thus upholding the type system. Though duck typing is useful it is naturally off the table. A natural number type could be included in the language, but such an addition without the benefit of duck typing might be looked upon as ad hoc. You get the nat type for abbreviated natural number in proof assistants. Some proof assistants are built using the Haskell language in fact. It is my impression that ML has been around longer than Haskell; consequently, most proof assistants are built on ML and not Haskell. I recall that GHC has moved from System F to a subset of dependent types and can therefore handle some problems involving dependent types. Nat seems to me to potentially be such a problem. Dependent types and proof assistants are like bread and butter. You prove by semi-automated methods at compile time that one number is necessarily not less than another and thereby prove that the difference at runtime cannot be negative. A natural number is an integer that depends on a number, a lower bound, namely zero. As such it seems likely that natural numbers are a dependent type. I am not sufficiently familiar with GHC at the present time to assess whether or not if the natural number dependent type can be resolved automatically by GHC. It is, however, something I have wondered about and may be something worth considering. With the inclusion of a natural number type if it proves feasible suggests that interval types may also be possible. The Ada language has an interval type in that array bounds are made explicit. The point is there are special cases where such types can be resolved at compile time. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3650 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] #1496: Newtypes and type families combine to produce inconsistent FC(X) axiom sets
#1496: Newtypes and type families combine to produce inconsistent FC(X) axiom sets +--- Reporter: sorear |Owner: simonpj Type: bug | Status: new Priority: normal |Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.7 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | +--- Changes (by BenMoseley): * cc: b...@moseley.name (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1496#comment:25 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
