Re: panic initC: srt_lbl on 6.10.3
On 28/06/2009 05:39, Conal Elliott wrote: I'm getting panic! (the 'impossible' happened) / initC: srt_lbl in ghc 6.10.3. Does anyone have an educated guess about initC: srt_lbl ? Oddly, ghci doesn't throw the panic. When I comment out some GADT code, the panic goes away. It's a pretty generic failure. -dcore-lint might trigger a failure earlier, but that probably won't help you. We need to reproduce the bug. Can you tell us how? (don't worry if the code depends on external packages, but ideally keep the dependencies to a minimum if you can). Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3334: Strange closure type error on macports GHC 6.10.1
#3334: Strange closure type error on macports GHC 6.10.1 -+-- Reporter: crutcher |Owner: Type: bug | Status: new Priority: normal|Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: MacOS X Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * difficulty: = Unknown * milestone: = 6.12.1 Comment: Not reproducible here with 6.10.3 on x86-Linux or x86-64-Linux. Could you try upgrading GHC? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3334#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] #635: Replace use of select() in the I/O manager with epoll/kqueue/etc.
#635: Replace use of select() in the I/O manager with epoll/kqueue/etc. -+-- Reporter: simonmar |Owner: Type: task | Status: new Priority: normal|Milestone: _|_ Component: libraries/base| Version: 6.4.1 Severity: normal| Resolution: Keywords:| Difficulty: Difficult (1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by hajile): * cc: elijah.epifa...@gmail.com (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/635#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
[GHC] #3335: make some Applicative functions into methods, and split off Data.Functor
#3335: make some Applicative functions into methods, and split off Data.Functor
-+--
Reporter: ross | Owner:
Type: proposal | Status: new
Priority: normal| Component: libraries/base
Version:| Severity: normal
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-+--
The following functions
{{{
($) :: Functor f = a - f b - f a
(*) :: Applicative f = f a - f b - f b
(*) :: Applicative f = f a - f b - f a
some :: Alternative f = f a - f [a]
many :: Alternative f = f a - f [a]
}}}
are moved into the corresponding classes, with the existing
implementations as default definitions. This gives people creating
instances the option of defining specialized implementations of these
functions, though they should be equivalent to the default definitions.
Although ($) is now a method of the Functor class, it is hidden in the
re-export by the Prelude, Control.Monad and Monad. The new module
Data.Functor exposes the full class, plus the function ($). These are
also re-exported by Control.Applicative.
Discussion on librar...@haskell.org to 20th July 2009.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3335
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] #3336: Following gcc behaviour with regards to calling conventions on x86_64
#3336: Following gcc behaviour with regards to calling conventions on x86_64 +--- Reporter: JeffersonHeard | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: calling convention, stdcall | Testcase: Os: Linux| Architecture: x86_64 (amd64) +--- http://blogs.msdn.com/freik/archive/2005/03/17/398200.aspx Right now, if anything other than ccall is given to ghc on x86_64 architectures, ghc errors out with the complaint that the calling convention is not supported on this architecture. gcc on the other hand, handles this situation gracefully, ignoring the calling convention attribute. My thought is that ghc should do this as well. Currently, I get this: TerraHS/TerraLib/TePoint.hs:121:0: calling convention not supported on this architecture: stdcall When checking declaration: foreign import stdcall unsafe static c_tepoint_setobjectid tepoint_setobjectid :: TePointPtr - CString - IO () I think I should instead get a warning saying that the calling convention is being ignored. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3336 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] #3082: Unclear warning message: Attempting to re-export hidden constructors
#3082: Unclear warning message: Attempting to re-export hidden constructors -+-- Reporter: ksf |Owner: Type: feature request | Status: new Priority: normal|Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by ross): * type: proposal = feature request -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3082#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] #3072: considerations for management of shared libs
#3072: considerations for management of shared libs -+-- Reporter: duncan|Owner: Type: feature request | Status: new Priority: normal|Milestone: 6.12.1 Component: Package system| Version: 6.10.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Linux Architecture: Unknown/Multiple | -+-- Changes (by ross): * type: proposal = feature request -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3072#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] #2254: have Control.Arrow re-export () and ()
#2254: have Control.Arrow re-export () and () -+-- Reporter: ross |Owner: Type: proposal | Status: closed Priority: normal|Milestone: Not GHC Component: libraries/base| Version: 6.8.2 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by ross): * status: new = closed * resolution: = fixed Comment: fait accompli -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2254#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] #2813: Create a utf8 bytestring-a-like
#2813: Create a utf8 bytestring-a-like --+- Reporter: igloo |Owner: Type: bug| Status: new Priority: high |Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | --+- Changes (by PHO): * cc: p...@cielonegro.org (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2813#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
