Re: [GHC] #4999: build fails on powerpc: error: 'ObjectCode' has no member named 'misalignment'
#4999: build fails on powerpc: error: 'ObjectCode' has no member named 'misalignment' --+- Reporter: nomeata | Owner: Type: bug | Status: new Priority: high | Milestone: 7.2.1 Component: Runtime System |Version: 7.0.2 Resolution: | Keywords: Testcase: | Blockedby: Difficulty: | Os: Linux Blocking: | Architecture: powerpc Failure: Building GHC failed | --+- Comment(by erikd): The patch I just attached (0001-Fix-compiling-on-linux-powerpc.patch) fixes the compile issue in rtc/Linker.c for linux-powerpc. This patch has also been tested on an x86_64-linux system and I ran the full validate script successfully. Validate couldn't run on powerpc-linux because other bugs exist. I would like to see this patch applied and this bug closed so I can raise a bug about then other powerpc-linx bug(s). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4999#comment:13 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] #5014: canonicalizePath throws exception on paths that do not exist
#5014: canonicalizePath throws exception on paths that do not exist +--- Reporter: hesselink|Owner: Type: bug | Status: patch Priority: normal |Milestone: Component: libraries/directory | Version: 7.0.2 Keywords: | Testcase: Blockedby: | Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime crash +--- Comment(by simonmar): Ok, fair enough. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5014#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] #5094: Get rid of hidden modules
#5094: Get rid of hidden modules
-+--
Reporter: mcandre | Owner:
Type: feature request | Status: new
Priority: normal| Component: Compiler
Version: 7.0.3 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: GHC rejects valid program
-+--
I'm writing a Haskell script to automate logging into my university's
authentication system. This problem lends itself to web scraping. Just
request an HTTPS page, fill in the forms with username and password, and
click submit.
The [http://hackage.haskell.org/package/shpider Shpider] package is a
wrapper around the popular C scraping library Curl. While the author went
to some effort to Haskellize the many technical options one can supply to
a Curl operation, he put all the constructors for the options in a hidden
module.
How does this impact a Shpider app? It means the app can't do ordinary
things like specify a useragent string or set a connection timeout. Each
of these is important: Until the app logs the user into the university
portal, he cannot access the Internet. But the app needs to access the
Internet to verify the login portal's SSL certificate. Shpider has an
option for this, but the option's constructor is only available as a
hidden module in the Shpider package.
I could go on about the need to circumvent artificial permissions, but
here the developer isn't even using them correctly. {{{CurlUserAgent}}}
exists, but it's worthless unless it's exposed to code in outer modules.
Please consider dropping support for hidden modules. Coders write around
them anyway, because they need to, because they're an inconvenience.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5094
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] #3977: Support double-byte encodings (Chinese/Japanese/Korean) on Windows
#3977: Support double-byte encodings (Chinese/Japanese/Korean) on Windows -+-- Reporter: shelarcy |Owner: Type: feature request | Status: new Priority: normal|Milestone: 7.2.1 Component: libraries/base| Version: 6.13 Keywords:| Testcase: Blockedby:| Difficulty: Os: Windows | Blocking: Architecture: Unknown/Multiple | Failure: Incorrect result at runtime -+-- Comment(by simonmar): Replying to [comment:7 batterseapower]: I see. Still, having a dog-slow binary chop for these double-byte encodings is better than having no support at all. Maybe. It would be tricky to get working though, and getting the error semantics right might be a pain (if it's possible at all). Are double- byte encodings widely used? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3977#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] #4999: build fails on powerpc: error: 'ObjectCode' has no member named 'misalignment'
#4999: build fails on powerpc: error: 'ObjectCode' has no member named 'misalignment' --+- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.2.1 Component: Runtime System |Version: 7.0.2 Resolution: | Keywords: Testcase: | Blockedby: Difficulty: | Os: Linux Blocking: | Architecture: powerpc Failure: Building GHC failed | --+- Changes (by simonmar): * status: new = patch -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4999#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] #5092: Remove Show instance for GHC.Event.IOCallback
#5092: Remove Show instance for GHC.Event.IOCallback -+-- Reporter: basvandijk| Owner: Type: feature request | Status: new Priority: normal| Component: libraries/base Version: 7.0.3 |Keywords: Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by tibbe): Looks good to me. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5092#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] #5091: Proposal: Retrieving the System Event Manager
#5091: Proposal: Retrieving the System Event Manager -+-- Reporter: basvandijk| Owner: Type: task | Status: new Priority: normal| Component: libraries/base Version: 7.0.3 |Keywords: Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by tibbe): Looks good to me. In the future we might have several system event managers (one per capability). Then this function should return the event manager for the capability the current thread is running on. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5091#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] #3977: Support double-byte encodings (Chinese/Japanese/Korean) on Windows
#3977: Support double-byte encodings (Chinese/Japanese/Korean) on Windows -+-- Reporter: shelarcy |Owner: Type: feature request | Status: new Priority: normal|Milestone: 7.2.1 Component: libraries/base| Version: 6.13 Keywords:| Testcase: Blockedby:| Difficulty: Os: Windows | Blocking: Architecture: Unknown/Multiple | Failure: Incorrect result at runtime -+-- Comment(by batterseapower): IME it is very common for PCs in China to be using one of the double-byte code page settings, since there is still a ton of software out there that uses the legacy Windows APIs. I imagine the situation is the same in Japan/Korea but I have no direct experience. Of course, even if DBCS is commonly used the localeEncoding is not as useful on Windows as it is on *nix in the context of GHC since we will mostly just call into the *W APIs and thus sidestep the locale entirely... which probably makes this ticket a low priority. In particular my upcoming patch set to implement PEP383 behaviour should support CJK without having a double-byte-aware localeEncoding. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3977#comment:9 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] #5095: Incoherent instance for Prelude type class accepted without incoherent instances option
#5095: Incoherent instance for Prelude type class accepted without incoherent
instances option
---+
Reporter: brunosoliveira | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.0.1 |Keywords:
Testcase: | Blockedby:
Os: MacOS X |Blocking:
Architecture: x86 | Failure: GHC accepts invalid program
---+
If we create a new module allowing overlapping instances, flexible
instances and undecidable instances we can define a function that selects
an incoherent instance for a type class defined in the Prelude. Example:
{-# OPTIONS -XFlexibleInstances -XOverlappingInstances
-XUndecidableInstances #-}
module Test where
instance Show a = Eq a where
x == y = length (show x) == length (show y)
f :: Show a = a - a - Bool
f x y = x == y
p = f (3 :: Int) 4
The instance selected here (tested with GHC 7.0 and 6.12) is the one in
this module, even if the instance Eq Int from the Prelude is more
specific. If we try to reproduce a similar example using a module other
than the Prelude, an incoherent instances error is reported. I believe
that, for consistency the same should happen here.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5095
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] #5060: iteratee: epollControl: permission denied (Operation not permitted)
#5060: iteratee: epollControl: permission denied (Operation not permitted) ---+ Reporter: pacak |Owner: Type: bug | Status: new Priority: normal |Milestone: Component: libraries/base | Version: 7.0.3 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime ---+ Changes (by simonmar): * component: Runtime System = libraries/base Comment: The IO manager is part of the base package, not the RTS. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5060#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] #5094: Get rid of hidden modules
#5094: Get rid of hidden modules -+-- Reporter: mcandre |Owner: Type: feature request | Status: new Priority: normal|Milestone: Component: Compiler | Version: 7.0.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: GHC rejects valid program -+-- Changes (by simonmar): * cc: dcoutts (added) Comment: I sympathise, but we're not going to drop support for hidden modules. We could add a flag to allow you to import hidden modules. However, Cabal would have to disallow the use of the option on Hackage; it would only be for local use. Anyone strongly object to that? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5094#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] #4971: All essential C-- transformations in new codegen should have infinite optimization fuel
#4971: All essential C-- transformations in new codegen should have infinite
optimization fuel
---+
Reporter: ezyang| Owner:
Type: bug | Status: closed
Priority: high | Milestone: 7.4.1
Component: Compiler |Version: 7.1
Resolution: fixed | Keywords:
Testcase:| Blockedby:
Difficulty:| Os: Unknown/Multiple
Blocking:| Architecture: Unknown/Multiple
Failure: None/Unknown |
---+
Changes (by ezyang):
* status: new = closed
* resolution: = fixed
Comment:
Fixed.
{{{
commit a28ed19690f2de7eb979d1d75f35071abbf9a102
Author: Edward Z. Yang ezy...@mit.edu
Date: Tue Apr 5 13:10:00 2011 +0100
Give infinite fuel to required C-- transformations. Fixes #4971.
Signed-off-by: Edward Z. Yang ezy...@mit.edu
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4971#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] #3687: Merge _stub.o files back in to the .o file
#3687: Merge _stub.o files back in to the .o file --+- Reporter: NeilMitchell | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.4.1 Component: Compiler |Version: 6.10.4 Resolution: fixed| Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: 706 | Architecture: Unknown/Multiple Failure: None/Unknown | --+- Changes (by simonmar): * status: new = closed * resolution: = fixed Comment: Done: changeset:7b0ff1792d699ff02a604163c9ccf4a98a1ca3eb -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3687#comment:13 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] #4012: Compilation results are not deterministic
#4012: Compilation results are not deterministic ---+ Reporter: kili | Owner: Type: bug | Status: new Priority: normal| Milestone: 7.2.1 Component: Compiler |Version: 6.12.2 Resolution:| Keywords: Testcase:| Blockedby: Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: Other | ---+ Changes (by nomeata): * cc: mail@… (added) Comment: Just a minor comment: This is hurting distributions quite a bit. Is there a chance to at least avoid this particular problem (cBooterVersion vs cProjectVersion) in the next ghc release? Thanks, Joachim -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4012#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1595: duplicate not in scope error when giving multiple vars type-signatures at once
#1595: duplicate not in scope error when giving multiple vars type-signatures at once -+-- Reporter: Isaac Dupree |Owner: michalt Type: bug | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 6.6.1 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by michalt): This might take a bit longer --- it seems that haddock uses `TypeSig` in a few places (like its backends) and I'll probably also wait for your refactoring. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1595#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] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi --+- Reporter: mitar| Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.4.1 Component: GHCi |Version: 7.0.3 Resolution: | Keywords: Testcase: | Blockedby: 4459 Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown | --+- Comment(by simonmar): Replying to [comment:37 daniel.is.fischer]: The test is in 7.0.3's testsuite, but the patch doesn't seem to be in: Just a testsuite bug, I don't think the testsuite was fully cleaned up in the stable branch prior to the release. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:38 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] #4827: Data.Array.IO.hPutArray/hGetArray ignore count argument
#4827: Data.Array.IO.hPutArray/hGetArray ignore count argument
--+-
Reporter: dylex| Owner: batterseapower
Type: bug | Status: closed
Priority: high | Milestone: 7.2.1
Component: libraries (other)|Version: 6.12.3
Resolution: fixed| Keywords:
Testcase: | Blockedby:
Difficulty: | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: Incorrect result at runtime |
--+-
Changes (by batterseapower):
* status: patch = closed
* resolution: = fixed
Comment:
Fixed in:
{{{
commit bdf4ce746aefb2cfb3c767e0f458b653238c1672
Author: Max Bolingbroke batterseapo...@hotmail.com
Date: Tue Apr 5 22:48:26 2011 +0100
Use count argument in hPutArray/hGetArray. Fixes #4827
}}}
{{{
commit 9617477db64e9e2bc3dbf8be4e29bc6233b363ea
Author: Max Bolingbroke batterseapo...@hotmail.com
Date: Tue Apr 5 22:55:35 2011 +0100
Test that hPutArray/hGetArray use count argument: #4827
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4827#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] #4965: 60% performance regression in continuation-heavy code between 6.12 and 7
#4965: 60% performance regression in continuation-heavy code between 6.12 and 7 -+-- Reporter: bos |Owner: Type: bug | Status: new Priority: high |Milestone: 7.2.1 Component: Compiler | Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Comment(by bos): I've attached two heap profile outputs, one generated with 6.12.3 and another with 7.0.3, both 32-bit. For this particular test case (an 8.3MB JSON file), 6.12.3 is about 66% faster than 7.0.3, and uses a little over half the memory. It looks like the 22% performance difference only applies to small inputs. The larger the input, the bigger the advantage that 6.12.3 has. 64-bit GHC 7.0.3 uses almost 300MB of heap here, which is pretty painful. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4965#comment:11 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
