- ghc-tickets - Haskell.org

Re: [GHC] #7359: unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1)
by GHC 23 Apr '13

23 Apr '13

#7359: unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1) -------------------------------+-------------------------------------------- Reporter: AndreasVoellmy | Owner: igloo Type: bug | Status: new Priority: highest | Milestone: 7.6.3 Component: libraries/unix | Version: 7.4.1 Keywords: unix package | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Other Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------------+-------------------------------------------- Comment(by MtnViewMark): Upon further investigation of George's situation, which I suspect is the same as others, this is version of "Cabal hell": George's system had multiple versions of packages, including some newer versions of packages that are supplied with GHC. A line from verbose cabal output tells the story: {{{ rejecting: unix-2.5.1.1/installed-296... (conflict: cairo => bytestring==0.10.0.1/installed-9b0..., unix => bytestring==0.9.2.1/installed-004...) }}} That is, cabal rejected the installed unix-2.5.1.1 because it was compiled against bytestring-0.9.2.1 (both supplied with GHC 7.4.1, and with HP 2012.4.0.0)... and the installed version of cairo it picked (0.12.4) was compiled against bytestring-0.10.0.1 (which was also installed). The only solution cabal could find was to pick unix-2.6.0.1. However, that, as we know (and expect) is incompatible with GHC-7.4.2. So the bug is that unix should have some dependency on ghc, which in turn would cause Cabal to give up in this situation - because the compiler essentially constrains the version of unix to just one. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7359#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7792: unregisterised build broken
by GHC 23 Apr '13

23 Apr '13

#7792: unregisterised build broken ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Unregisterised builds are currently broken: Compiling C calls in CMM files fails with e.g. {{{ error: ‘debugBelch’ undeclared }}} The C call is being translated into {{{ _cH = (W_)&debugBelch; _cG = (W_)&stg_ap_0_ret_str; ((void (*)(void *))_cH)((void *)_cG);; }}} so `pprForeignCall` isn't getting called, and thus doesn't add the prototype for `debugBelch`. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7792> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7824: problem with vector in arm
by GHC 23 Apr '13

23 Apr '13

#7824: problem with vector in arm -------------------------------+-------------------------------------------- Reporter: chemistmail | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.1 | Keywords: Os: Linux | Architecture: arm Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Hello, i try compile my shoutcast server in raspberrypy and have next problem with dependence: cabal install aeson snap-coreResolving dependencies... Configuring vector-0.10.0.1... Building vector-0.10.0.1... Preprocessing library vector-0.10.0.1... [ 1 of 19] Compiling Data.Vector.Storable.Internal ( Data/Vector/Storable/Internal.hs, dist/build/Data/Vector/Storable/Internal.o ) [ 2 of 19] Compiling Data.Vector.Fusion.Util ( Data/Vector/Fusion/Util.hs, dist/build/Data/Vector/Fusion/Util.o ) [ 3 of 19] Compiling Data.Vector.Fusion.Stream.Size ( Data/Vector/Fusion/Stream/Size.hs, dist/build/Data/Vector/Fusion/Stream/Size.o ) Data/Vector/Fusion/Stream/Size.hs:25:10: Warning: No explicit method nor default method for `*' In the instance declaration for `Num Size' Data/Vector/Fusion/Stream/Size.hs:25:10: Warning: No explicit method nor default method for `abs' In the instance declaration for `Num Size' Data/Vector/Fusion/Stream/Size.hs:25:10: Warning: No explicit method nor default method for `signum' In the instance declaration for `Num Size' [ 4 of 19] Compiling Data.Vector.Internal.Check ( Data/Vector/Internal/Check.hs, dist/build/Data/Vector/Internal/Check.o ) [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic ( Data/Vector/Fusion/Stream/Monadic.hs, dist/build/Data/Vector/Fusion/Stream/Monadic.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for arm-unknown-linux): Cant do annotations without GHCi {Data/Vector/Fusion/Stream/Monadic.hs:104:19-33} base:GHC.Exts.ForceSpecConstr{d ra42} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: aeson-0.6.1.0 depends on vector-0.10.0.1 which failed to install. snap-core-0.9.3.1 depends on vector-0.10.0.1 which failed to install. vector-0.10.0.1 failed during the building phase. The exception was: ExitFailure 1 what to do? I can make account in my server, and give access for people who can help with my problem. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7824> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #4244: Use system linker in GHCi to support alpha, ia64, ppc64
by GHC 23 Apr '13

23 Apr '13

#4244: Use system linker in GHCi to support alpha, ia64, ppc64 -------------------------------+-------------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: closed Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 6.13 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: 7824 | Related: -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: This now works, with `DYNAMIC_GHC_PROGRAMS="YES"` (which is the case on all non-Windows platforms in HEAD): {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 7.7.20130423: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> 5+6 11 Prelude> (System.Info.os, System.Info.arch) ("linux","s390") }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4244#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4244: Use system linker in GHCi to support alpha, ia64, ppc64
by GHC 23 Apr '13

23 Apr '13

#4244: Use system linker in GHCi to support alpha, ia64, ppc64 ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 6.13 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: 7824 Related: | ---------------------------------+------------------------------------------ Changes (by igloo): * blockedby: 3658 => -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4244#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7650: can't use combining characters in identifiers
by GHC 23 Apr '13

23 Apr '13

#7650: can't use combining characters in identifiers -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Linux | Architecture: x86 Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- ghc doesn't let me use combining characters in unicode identifiers. Here's a test case with U+308 (COMBINING DIAERESIS) but it affects all accents: {{{ % cat comb.hs main = print spın̈alTap where spın̈alTap = 11 }}} {{{ % ghc comb.hs [1 of 1] Compiling Main ( comb.hs, comb.o ) comb.hs:1:18: lexical error at character '\776' }}} (This is actually with ghc 7.6.2 but the `Version` drop-down only goes up to 7.6.1.) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7650> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7853: UTF encodings do not detect overlong forms
by GHC 23 Apr '13

23 Apr '13

#7853: UTF encodings do not detect overlong forms ----------------------------------------+----------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- Overlong UTF-{8,16} sequences can have security implications (http://www.cl.cam.ac.uk/~mgk25/unicode.html) Decoders for these encodings should detect them and flag them as invalid characters. GHC's implementations of these decoders do not do so! This problem has additional implications for GHC since as we are not rejecting overlong sequences, trying to roundtrip 0xC0 0xB1 through UTF-8//ROUNDTRIP results in 0x31 rather than the expected sequence. The roundtripping fails because the overlong sequence is not flagged up by the UTF-8 encoder and so the surrogate escape mechanism never gets a chance to work. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7853> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #3977: Support double-byte encodings (Chinese/Japanese/Korean) on Windows
by GHC 23 Apr '13

23 Apr '13

#3977: Support double-byte encodings (Chinese/Japanese/Korean) on Windows ---------------------------------+------------------------------------------ Reporter: shelarcy | Owner: batterseapower Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: libraries/base | Version: 6.13 Keywords: | Os: Windows Architecture: Unknown/Multiple | Failure: Incorrect result at runtime Difficulty: | Testcase: Blockedby: | Blocking: Related: #5754 | ---------------------------------+------------------------------------------ Changes (by batterseapower): * owner: => batterseapower Comment: Fixed on the dbcs branch of the base library. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3977#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2648: Report out of date interface files robustly
by GHC 23 Apr '13

23 Apr '13

#2648: Report out of date interface files robustly ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: GHCi | Version: 7.6.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHCi crash Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by liyang): I'm not entirely sure if what I'm seeing is due to out-of-date interface files, but see the details below: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: <<details unavailable>> }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2648#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7662: Improve GC of mutable objects
by GHC 23 Apr '13

23 Apr '13

#7662: Improve GC of mutable objects -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Haskell is a purely functional language at its core, but it can be also used for workloads involving mutation; it is for these workloads that our GC can be pretty poorly tuned (historically, we’ve fixed these issues case-by-case when they were causing problems for users, e.g. #650). Fortunately, the question of generational garbage collection in the face of lots of mutability is a well-studied one (c.f. the JVM) so this bug asks whether or not we can systematically appropriate any of the machinery developed here for GHC. Some ideas include: * Utilizing card marking at the page level for write barriers, instead of our current mutable lists, * Separating mutable and immutable (and lazy) data on the heaps, to make the previous scheme more likely to work well, * Organizing our generations in different pages, so that checking the generation of any object is as simple as a pointer comparison, * Figure out if we can do better than permanently keeping all mutable arrays permanently on the mutable list (which is really killer when you have lots of tiny mutable arrays), * More mutable closure types to remove the indirection that would normally result from an IORef (actually, you can UNPACK these, and I’m not 100% what happens in that case; it depends on how MutVar#s are represented) There’s probably more things but this is just a start to get things rolling. Test cases and benchmarks also appreciated! -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7662> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5