Re: [GHC] #285: hp-ux 11.11 binaries
#285: hp-ux 11.11 binaries -+-- Reporter: amyhr| Owner: nobody Type: feature request | Status: assigned Priority: normal | Milestone: _|_ Component: None |Version: None Severity: minor| Resolution: None Keywords: | Difficulty: Unknown Testcase: N/A | Architecture: hppa Os: HPUX | -+-- Comment (by CBa): Additional infos: my ghc: 6.4.2 (Porting GHC is not up-to-date for ghc-6.6). the ghc-inplace segfaults in some cases. But I can get this message: hello.hs:1:0: Failed to load interface for `Prelude': Could not find module `Prelude': use -v to see a list of the files searched for -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/285 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] #285: hp-ux 11.11 binaries
#285: hp-ux 11.11 binaries -+-- Reporter: amyhr| Owner: nobody Type: feature request | Status: assigned Priority: normal | Milestone: _|_ Component: None |Version: None Severity: minor| Resolution: None Keywords: | Difficulty: Unknown Testcase: N/A | Architecture: hppa Os: HPUX | -+-- Comment (by CBa): in ghc/rtc just one file triggers now a segfault of ghc-inplace: PrimOps.cmm. Gdb doesn't help much: (gdb) up warning: Attempting to unwind past bad PC 0x79cff180 #1 0x79ce7340 in __gmpz_mul (w=0x40417798, u=0x2, v=0x77bc2c04) at ../../mpz/mul.c:89 89cy_limb = mpn_mul_1 (wp, PTR(u), usize, PTR(v)[0]); Current language: auto; currently c I build gmp by my own. `make check' succedes. And the given line is in a #if 0 ... #endif block. Any ideas? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/285 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] #1105: Custom Runtimes
#1105: Custom Runtimes -+-- Reporter: humasect | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Runtime System |Version: 6.6 Severity: normal | Resolution: Keywords: runtime custom sdl cocoa init main ghci | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | -+-- Changes (by igloo): * milestone: = _|_ Old description: The ability to build custom runtimes would be useful in many development situations. Like Objective Caml's -custom, one would be able to create a interactive-invokable (GHCi) with a custom main () initialization and finalizer. For things such as SDL applications, Cocoa applications, there is a need for custom run loops as well. This would be an immensely great integration feature for GHC. In these situations it is not possible to work in GHCi on most/all platforms without much work done in a specialized hs-plugins REPL environment. Ideas of Requirements: - specifiable initializer (from main) - specifiable finalizer - specifiable run loop / event handler (light thread) as such: REPL thread 0 - read, eval (send to thread 1), print, loop thread 1 - processing events run loop, check for eval + send result to print stage [the author is developing a Cocoa+GL native application in 100% Haskell sans HOC sans HOpenGL] New description: The ability to build custom runtimes would be useful in many development situations. Like Objective Caml's -custom, one would be able to create a interactive-invokable (GHCi) with a custom main () initialization and finalizer. For things such as SDL applications, Cocoa applications, there is a need for custom run loops as well. This would be an immensely great integration feature for GHC. In these situations it is not possible to work in GHCi on most/all platforms without much work done in a specialized hs-plugins REPL environment. Ideas of Requirements: * specifiable initializer (from main) * specifiable finalizer * specifiable run loop / event handler (light thread) as such: * REPL * thread 0 - read, eval (send to thread 1), print, loop * thread 1 - processing events run loop, check for eval + send result to print stage [the author is developing a Cocoa+GL native application in 100% Haskell sans HOC sans HOpenGL] Comment: I'm a bit unclear on what exactly is wanted here. Does GHC-as-a-library provide it? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1105 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] #1106: During install, network's Typeable.h clobbers base's copy
#1106: During install, network's Typeable.h clobbers base's copy --+- Reporter: bos | Owner: Type: bug | Status: new Priority: normal| Milestone: 6.6.1 Component: Compiler |Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by igloo): * milestone: = 6.6.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1106 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] #1107: Incorrect error message when there is a dot in the package name.
#1107: Incorrect error message when there is a dot in the package name. +--- Reporter: kr.angelov | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: Visual Haskell |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | +--- Changes (by igloo): * milestone: = Not GHC -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1107 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] #1108: -package and -idir in OPTIONS_GHC are ignored, but manual says that they're dynamic
#1108: -package and -idir in OPTIONS_GHC are ignored, but manual says that they're dynamic +--- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler|Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | +--- Changes (by igloo): * milestone: = 6.6.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1108 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] #1109: lockFile: fd out of range
#1109: lockFile: fd out of range
+---
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.6.1
Component: Runtime System |Version: 6.6
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Linux |
+---
Changes (by igloo):
* milestone: = 6.6.1
Old description:
My program was terminated with the following message:
internal error: lockFile: fd out of range
(GHC version 6.6 for i386_unknown_linux)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
The reason appears to be the large number of simultaneously open files.
If I limit the number of open descriptors to 1025 or lower, I get
openFile: resource exhausted (Too many open files instead.
New description:
My program was terminated with the following message:
{{{
internal error: lockFile: fd out of range
(GHC version 6.6 for i386_unknown_linux)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
}}}
The reason appears to be the large number of simultaneously open files. If
I limit the number of open descriptors to 1025 or lower, I get openFile:
resource exhausted (Too many open files instead.
Comment:
Can anyone give us a testcase for this please?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1109
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] #1111: Too-eager variable capture in forall types
#: Too-eager variable capture in forall types
--+-
Reporter: japple| Owner: simonpj
Type: bug | Status: new
Priority: normal| Milestone: 6.6.1
Component: Compiler |Version: 6.6
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Architecture: x86
Os: Linux |
--+-
Changes (by igloo):
* milestone: = 6.6.1
* owner: = simonpj
Comment:
I'm seeing
{{{
interactive: internal error: stg_ap_v_ret
(GHC version 6.6 for x86_64_unknown_linux)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
}}}
for oops/oopsAgain rather than Illegal instruction, and the same CASEFAIL
as the submitter for oopsOnceMore. HEAD is the same.
I'm not quite sure what's going on here. Is the monomorphism restriction
allowing the a to be unified with the x in h?
Sounds like one for you, Simon!
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/
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] #1114: Socket code dies with SIGPIPE
#1114: Socket code dies with SIGPIPE +--- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: hslibs/net |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | +--- Changes (by igloo): * milestone: = 6.6.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1114 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] #1115: GHC concurrency runtime breaks every 497 (and a bit) days
#1115: GHC concurrency runtime breaks every 497 (and a bit) days +--- Reporter: Neil Davies | Owner: Neil Davies Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Runtime System |Version: 6.6 Severity: major | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | +--- Changes (by igloo): * milestone: = 6.6.1 * owner: = Neil Davies Comment: Neil's working on a patch for this. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1115 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] #1117: [2,4..10] is not a good list producer
#1117: [2,4..10] is not a good list producer -+-- Reporter: [EMAIL PROTECTED] | Owner: Type: feature request | Status: new Priority: low | Milestone: 6.6.1 Component: Compiler |Version: 6.6 Severity: normal | Resolution: Keywords: rewrite rules| Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | -+-- Changes (by igloo): * milestone: = 6.6.1 * priority: normal = low Comment: I've set priority to low as we probably don't want to wait for this before releasing 6.6.1, but if it's done by then and looks beneficial then I can't see why it shouldn't go in. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1117 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] #1118: Type check loop on impredicativaty + GADT mix
#1118: Type check loop on impredicativaty + GADT mix +--- Reporter: japple | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler|Version: 6.6 Severity: normal | Resolution: Keywords: impredicativity, GADTs | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | +--- Changes (by igloo): * milestone: = 6.6.1 * owner: = simonpj Comment: Another one for you, Simon. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1118 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] #307: Implicit Parameters and monomorphism
#307: Implicit Parameters and monomorphism
-+--
Reporter: nobody | Owner: nobody
Type: feature request | Status: assigned
Priority: low | Milestone: _|_
Component: None |Version: None
Severity: minor| Resolution: None
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
-+--
Changes (by igloo):
* architecture: = Unknown
* difficulty: = Unknown
* milestone: = _|_
* testcase: =
* os: = Unknown
Old description:
{{{
http://www.haskell.org/pipermail/haskell-cafe/2005-January/008571.html
Notes some oddness with recursive binding of implicit
parameters. Roughly, giving a type signature to a
function with implicit params causes its bindings to
act recursively, despite what section 7.4.5.2 of the
user's guide says.
}}}
New description:
{{{
http://www.haskell.org/pipermail/haskell-cafe/2005-January/008571.html
Notes some oddness with recursive binding of implicit
parameters. Roughly, giving a type signature to a
function with implicit params causes its bindings to
act recursively, despite what section 7.4.5.2 of the
user's guide says.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/307
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] #323: Exponential behaviour with type synonyms
#323: Exponential behaviour with type synonyms -+-- Reporter: simonpj | Owner: simonpj Type: bug | Status: assigned Priority: low | Milestone: _|_ Component: Compiler (Type checker) |Version: 6.4.1 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -+-- Changes (by igloo): * milestone: = _|_ * testcase: = -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/323 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] #408: OpenAL needs -pthread
#408: OpenAL needs -pthread ---+ Reporter: volkersf | Owner: panne Type: bug| Status: new Priority: low| Milestone: Not GHC Component: libraries (other) |Version: 6.4.1 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: FreeBSD| ---+ Changes (by igloo): * milestone: = Not GHC * testcase: = -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/408 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] #490: object code blow up by minor source code change
#490: object code blow up by minor source code change --+- Reporter: c_maeder | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler |Version: 6.4.1 Severity: normal| Resolution: None Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by igloo): * milestone: = _|_ * testcase: = -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/490 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] #565: overlapping instances fundeps broken
#565: overlapping instances fundeps broken
-+--
Reporter: ashley-y | Owner: nobody
Type: bug | Status: assigned
Priority: low | Milestone: _|_
Component: Compiler (Type checker) |Version: 5.00
Severity: normal | Resolution: None
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
-+--
Changes (by igloo):
* architecture: = Unknown
* difficulty: = Unknown
* milestone: = _|_
* testcase: =
* os: = Unknown
Old description:
{{{
Consider this:
--
class X a
instance X Bool
instance (Num a) = X a
--
For as long as instance Num Bool is not declared, the two instances do
not de facto overlap. But that's not immediately obvious to GHC, so it
will
complain, at least by default. But I can stop it complaining by passing
-fallow-overlapping-instances, which I interpret as asking GHC to trust
me
that instances don't actually overlap.
But consider this, with an added dependent argument:
--
class X a b | a - b
instance X Bool Bool
instance (Num a) = X a Char
--
Now GHC will complain even with -fallow-overlapping-instances. I believe
this is inappropriate.
So why have the fundep? Well, GHC can still make use of it, and it can
still
calculate the dependent type:
--
class X a b | a - b where
{
foo :: a - b;
};
instance X Bool Bool where
{
foo a = a;
};
instance (Num a) = X a Char where
{
foo a = 'N';
}
test = foo True;
--
Without the fundep, GHC cannot calculate 'foo True', since 'instance X
Bool
Bool' is not general enough. This is correct. But with the fundep, GHC
will
complain that it can't prove that the two instances don't conflict for
the
fundep, even with -fallow-overlapping-instances.
I submit that GHC with -fallow-overlapping-instances should not complain
in this case.
}}}
New description:
{{{
Consider this:
--
class X a
instance X Bool
instance (Num a) = X a
--
For as long as instance Num Bool is not declared, the two instances do
not de facto overlap. But that's not immediately obvious to GHC, so it
will
complain, at least by default. But I can stop it complaining by passing
-fallow-overlapping-instances, which I interpret as asking GHC to trust me
that instances don't actually overlap.
But consider this, with an added dependent argument:
--
class X a b | a - b
instance X Bool Bool
instance (Num a) = X a Char
--
Now GHC will complain even with -fallow-overlapping-instances. I believe
this is inappropriate.
So why have the fundep? Well, GHC can still make use of it, and it can
still
calculate the dependent type:
--
class X a b | a - b where
{
foo :: a - b;
};
instance X Bool Bool where
{
foo a = a;
};
instance (Num a) = X a Char where
{
foo a = 'N';
}
test = foo True;
--
Without the fundep, GHC cannot calculate 'foo True', since 'instance X
Bool
Bool' is not general enough. This is correct. But with the fundep, GHC
will
complain that it can't prove that the two instances don't conflict for the
fundep, even with -fallow-overlapping-instances.
I submit that GHC with -fallow-overlapping-instances should not complain
in this case.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/565
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] #631: GHCi doesn't work unregisterised
#631: GHCi doesn't work unregisterised -+-- Reporter: [EMAIL PROTECTED] | Owner: igloo Type: bug | Status: new Priority: low | Milestone: 6.6.1 Component: GHCi |Version: 6.4.1 Severity: minor| Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -+-- Changes (by igloo): * milestone: = 6.6.1 * testcase: = -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/631 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] #653: Changeable lexer/parser (like DynFlags.log_action)
#653: Changeable lexer/parser (like DynFlags.log_action) -+-- Reporter: Lemmih | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler |Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Architecture: Multiple Os: Multiple | -+-- Changes (by igloo): * milestone: = _|_ -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/653 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] #670: External Core is broken
#670: External Core is broken
--+-
Reporter: KirstenChevalier | Owner: krc
Type: bug | Status: new
Priority: low | Milestone: 6.6.1
Component: External Core |Version: 6.4.1
Severity: blocker | Resolution:
Keywords:| Difficulty: Moderate (1 day)
Testcase:| Architecture: Multiple
Os: Multiple |
--+-
Changes (by igloo):
* milestone: = 6.6.1
Comment:
6.6 and HEAD both give:
{{{
no location info:
1: Parse error
:
main :: base:GHC.IOBase.IO base:GHC.Base.Z0T =
base:System.IO.putStr
(base:GHC.Base.unpac
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/670
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] #683: RULES for recursive functions don't work properly
#683: RULES for recursive functions don't work properly --+- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 6.8 Component: Compiler |Version: 6.4.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by igloo): * milestone: = 6.8 * testcase: = -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/683 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] #745: GHC should recover better from bad type signatures
#745: GHC should recover better from bad type signatures
--+-
Reporter: simonpj | Owner: simonpj
Type: bug | Status: new
Priority: low | Milestone: 6.8
Component: Compiler |Version: 6.4.2
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Architecture: Unknown
Os: Unknown |
--+-
Changes (by igloo):
* milestone: = 6.8
* testcase: =
Old description:
GHC currently bales out as soon as it finds an ill-kinded top-level type
signature.
It didn't use to... it recovered and found more errors. An example is
test tcfail113 (see diff below). The change is a consequence of some
reorganisation in TcBinds.
Fixing this would be nice, but perhaps not all that important
Simon
*** ./tcfail113.stderr 2003-12-10 14:24:30.0 +
--- ./tcfail113.comp.stderr 2006-03-30 10:05:53.0 +0100
***
*** 1,12
- tcfail113.hs:7:6:
- Kind error: `Maybe' is not applied to enough type arguments
- In the type signature: f :: [Maybe]
-
- tcfail113.hs:10:7:
- Kind error: Expecting kind `* - *', but `Int' has kind `*'
- In the type signature: g :: T Int
-
tcfail113.hs:13:5:
Kind error: `Int' is applied to too many type arguments
In the type signature: h :: Int Int
New description:
GHC currently bales out as soon as it finds an ill-kinded top-level type
signature.
It didn't use to... it recovered and found more errors. An example is test
tcfail113 (see diff below). The change is a consequence of some
reorganisation in TcBinds.
Fixing this would be nice, but perhaps not all that important
Simon
{{{
*** ./tcfail113.stderr 2003-12-10 14:24:30.0 +
--- ./tcfail113.comp.stderr 2006-03-30 10:05:53.0 +0100
***
*** 1,12
- tcfail113.hs:7:6:
- Kind error: `Maybe' is not applied to enough type arguments
- In the type signature: f :: [Maybe]
-
- tcfail113.hs:10:7:
- Kind error: Expecting kind `* - *', but `Int' has kind `*'
- In the type signature: g :: T Int
-
tcfail113.hs:13:5:
Kind error: `Int' is applied to too many type arguments
In the type signature: h :: Int Int
}}}
Comment:
Still happens with 6.6 and HEAD.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/745
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] #784: defining type of returned value
#784: defining type of returned value ---+ Reporter: [EMAIL PROTECTED] | Owner: Type: bug| Status: new Priority: low| Milestone: _|_ Component: Compiler |Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown| ---+ Changes (by igloo): * milestone: = _|_ * testcase: = -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/784 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-6.6 under sparc-sun-solaris
Winfried, could you also try my binary distribution? http://www.haskell.org/ghc/download_ghc_66.html#sparcsolaris Ian, could you remove the out-dated first line from this page? cite NOTE: you must use GCC 2.95 or 3.4+ on Sparc. There is a known bug with GCC versions between 3.0-3.3 which causes incorrect code to be generated. /cite Winfried Kung schrieb: Hello, when trying to build ghc-6.6 under Sparc Solaris (SunOS 5.9), the build fails with /usr/ccs/bin/ld: illegal option -- x I use gcc version 3.4.4 and GNU ld version 2.11.2 (with BFD 2.11.2). My configure recognizes them and sets an ld option -x as expected. But when it comes to make, I get the message: ghc-6.6 can cope with the solaris linker. So if you call ./configure when /usr/ccs/bin is first in your path, this should avoid using the -x option. == make all -wr -f Makefile; in /global/HOME/kung/install/ghc-6.6/libraries/base ../../compiler/ghc-inplace -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc -H16m -O -H16m -O -H16m -O -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict-fields -package-name base-2.0 -O -Rghc-timing -fgenerics -fgenerics -split-objs-c GHC/Base.lhs -o GHC/Base.o -ohi GHC/Base.hi /usr/ccs/bin/ld: illegal option -- x usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s) [-64] enforce a 64-bit link-edit ... ... [-z verbose]generate warnings for suspicious processings collect2: ld returned 1 exit status It seems strange to me that /usr/ccs/bin/ld is called here, instead of /usr/local/bin/ld which I have in my path, but calling ghc-inplace with option -pgml /usr/local/bin/ld did not help either. This seems strange to me, too, sorry. Christian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1019: X11 package puts path to X libraries in ld-options rather than library-dirs, so ghci can't find it
#1019: X11 package puts path to X libraries in ld-options rather than library- dirs, so ghci can't find it ---+ Reporter: wolfgang | Owner: Type: bug| Status: new Priority: low| Milestone: Not GHC Component: libraries (other) |Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown| ---+ Changes (by igloo): * milestone: = Not GHC -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1019 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] #1049: A means of testing whether code is in blocked or unblocked mode
#1049: A means of testing whether code is in blocked or unblocked mode -+-- Reporter: ChrisKuklewicz | Owner: Type: feature request | Status: new Priority: low | Milestone: 6.8 Component: libraries/base |Version: 6.6 Severity: normal | Resolution: Keywords: concurrency | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: Multiple | -+-- Changes (by igloo): * milestone: = 6.8 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1049 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] #1077: documentation error and omission
#1077: documentation error and omission ---+ Reporter: guest | Owner: Type: bug| Status: new Priority: low| Milestone: 6.6.1 Component: Documentation |Version: 6.6 Severity: trivial| Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Multiple | ---+ Changes (by igloo): * milestone: = 6.6.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1077 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] #1095: make boot under includes/ doesn't run make depend
#1095: make boot under includes/ doesn't run make depend --+- Reporter: kirsten | Owner: Type: bug | Status: new Priority: low | Milestone: 6.6.1 Component: Build System |Version: 6.6 Severity: minor | Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by igloo): * milestone: = 6.6.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1095 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] #1096: More make boot / make depend problems
#1096: More make boot / make depend problems --+- Reporter: kirsten | Owner: Type: bug | Status: new Priority: low | Milestone: 6.6.1 Component: Build System |Version: 6.6 Severity: minor | Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by igloo): * milestone: = 6.6.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1096 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] #1098: Broken link in the User's Guide
#1098: Broken link in the User's Guide +--- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: low | Milestone: 6.6.1 Component: Documentation |Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple| +--- Changes (by igloo): * milestone: = 6.6.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1098 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] #1100: Parse error on (#) in .lhs files
#1100: Parse error on (#) in .lhs files +--- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: low | Milestone: 6.8 Component: Compiler (Parser) |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | +--- Changes (by igloo): * milestone: = 6.8 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1100 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] #125: GHCi Usability
#125: GHCi Usability
-+--
Reporter: nobody | Owner: nobody
Type: feature request | Status: assigned
Priority: lowest | Milestone: 6.8
Component: None |Version: None
Severity: minor| Resolution: None
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
-+--
Changes (by igloo):
* architecture: = Unknown
* difficulty: = Unknown
* milestone: = 6.8
* testcase: =
* os: = Unknown
Old description:
{{{
About GHCi
I find that Haskell interpreter is rather difficult to use:
1.f=3 is a legal statement in Haskell, i.e. define f as
a
constant function, but a parse error occurs.
let f=3 is illegal, let and in are used together, but
it works in GHCi.
2. if I happen to print out an infinite list, I don't know how
to interrupt it, when press Ctrl+C, GHCi just quit.
3. I can't use import to import modules. There are
many sub
directories in the imports directory, but I don't know
how to
import libraries in concurrent, win32, util, lang and
objectio
}}}
New description:
{{{
About GHCi
I find that Haskell interpreter is rather difficult to use:
1.f=3 is a legal statement in Haskell, i.e. define f as
a
constant function, but a parse error occurs.
let f=3 is illegal, let and in are used together, but
it works in GHCi.
2. if I happen to print out an infinite list, I don't know how
to interrupt it, when press Ctrl+C, GHCi just quit.
3. I can't use import to import modules. There are
many sub
directories in the imports directory, but I don't know
how to
import libraries in concurrent, win32, util, lang and
objectio
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/125
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] #393: functions without implementations
#393: functions without implementations
-+--
Reporter: c_maeder | Owner: nobody
Type: feature request | Status: assigned
Priority: lowest | Milestone: 6.8
Component: None |Version: None
Severity: minor| Resolution: None
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
-+--
Changes (by igloo):
* architecture: = Unknown
* difficulty: = Unknown
* milestone: = 6.8
* testcase: =
* os: = Unknown
Old description:
{{{
Allow to declare a function by only supplying its type
signature.
This feature shall enhance rapid prototyping by fixing
an interface but leaving some functions unimplemented.
Currently this can be (only) simulated by supplying
dummy implementations, like
f :: ...
f = undefined
Since it is possible to supply dummy data types by
data T (not followed by =), allowing functions
without implementations seems almost to be a logical
consequence. Surely, the compiler should emit warnings
for missing implementations.
It would be nice if such function declarations via type
signatures could be repeated at any position within a
module.
}}}
New description:
{{{
Allow to declare a function by only supplying its type
signature.
This feature shall enhance rapid prototyping by fixing
an interface but leaving some functions unimplemented.
Currently this can be (only) simulated by supplying
dummy implementations, like
f :: ...
f = undefined
Since it is possible to supply dummy data types by
data T (not followed by =), allowing functions
without implementations seems almost to be a logical
consequence. Surely, the compiler should emit warnings
for missing implementations.
It would be nice if such function declarations via type
signatures could be repeated at any position within a
module.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/393
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] #418: unsafeInterleaveIO + Ctrl-C/killThread related segfault
#418: unsafeInterleaveIO + Ctrl-C/killThread related segfault
+---
Reporter: remit | Owner: igloo
Type: bug | Status: new
Priority: lowest | Milestone:
Component: Runtime System |Version: 6.4.1
Severity: normal | Resolution: None
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
+---
Changes (by igloo):
* testcase: =
* status: assigned = new
* owner: nobody = igloo
Old description:
{{{
[copy-pasting my original mail
(http://www.haskell.org/pipermail/glasgow-haskell-bugs/2005-
June/005235.html)]
Good evening,
I just stumbled across a segfault caused when running the
following small program. (During an attempt to implement
single-assignment variables.)
module Main where
import Control.Concurrent
import System.IO.Unsafe (unsafeInterleaveIO)
main = do
v - newEmptyMVar
a - unsafeInterleaveIO (readMVar v)
t - forkIO (print a)
threadDelay (1000*1000)
killThread t
forkIO (print a)
putMVar v ()
The crucial part about it seems to be the interruption
of the
lazy IO. Typing Ctl-c while running the first print a
by hand
from ghci instead of the forkIO+killThread doesn't change
behaviour:
Prelude System.IO.Unsafe Control.Concurrent v -
newEmptyMVar
Prelude System.IO.Unsafe Control.Concurrent a -
unsafeInterleaveIO (readMVar v)
Prelude System.IO.Unsafe Control.Concurrent print a
Interrupted.
Prelude System.IO.Unsafe Control.Concurrent forkIO
(print a)
Prelude System.IO.Unsafe Control.Concurrent putMVar v ()
zsh: segmentation fault (core dumped) ghci
Both 6.4 and 6.2.1 crash when running main from ghci.
When running it as a compiled executable everything is
fine.
Although I'm pretty sure I've seen 6.2.1 crashing
on it when run with -e main, I cannot reproduce it
anymore. 6.4
certainly happily runs it with -e main. (A serious lack
of sleep
the last week may play a role too.. :-/)
Whether the module is compiled before being loaded into
ghci has
no effect.
Core-dumps etc can of course be sent if necessary.
Good night,
Remi
}}}
New description:
[copy-pasting my original mail
(http://www.haskell.org/pipermail/glasgow-haskell-bugs/2005-
June/005235.html)]
Good evening,
I just stumbled across a segfault caused when running the
following small program. (During an attempt to implement
single-assignment variables.)
{{{
module Main where
import Control.Concurrent
import System.IO.Unsafe (unsafeInterleaveIO)
main = do
v - newEmptyMVar
a - unsafeInterleaveIO (readMVar v)
t - forkIO (print a)
threadDelay (1000*1000)
killThread t
forkIO (print a)
putMVar v ()
}}}
The crucial part about it seems to be the interruption
of the
lazy IO. Typing Ctl-c while running the first print a
by hand
from ghci instead of the forkIO+killThread doesn't change
behaviour:
{{{
Prelude System.IO.Unsafe Control.Concurrent v - newEmptyMVar
Prelude System.IO.Unsafe Control.Concurrent a - unsafeInterleaveIO
(readMVar v)
Prelude System.IO.Unsafe Control.Concurrent print a
Interrupted.
Prelude System.IO.Unsafe Control.Concurrent forkIO (print a)
Prelude System.IO.Unsafe Control.Concurrent putMVar v ()
zsh: segmentation fault (core dumped) ghci
}}}
Both 6.4 and 6.2.1 crash when running main from ghci.
When running it as a compiled executable everything is
fine.
Although I'm pretty sure I've seen 6.2.1 crashing
on it when run with -e main, I cannot reproduce it
anymore. 6.4
certainly happily runs it with -e main. (A serious lack
of sleep
the last week may play a role too.. :-/)
Whether the module is compiled before being loaded into
ghci has
no effect.
Core-dumps etc can of course be sent if necessary.
Good night,
Remi
Comment:
This seems to be fixed in 6.6. Leaving it open to remind me to add the
example to the testsuite.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/418
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] #700: Inconsistent typechecking of pattern match in function binding
#700: Inconsistent typechecking of pattern match in function binding --+- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest| Milestone: _|_ Component: Compiler |Version: 6.4.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by igloo): * milestone: = _|_ * testcase: = -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/700 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] #1091: parse error in comment {- | -}
#1091: parse error in comment {- | -}
---+
Reporter: [EMAIL PROTECTED] | Owner: simonmar
Type: bug| Status: new
Priority: normal | Milestone: 6.8
Component: Compiler (Parser) |Version: 6.7
Severity: minor | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown|
---+
Changes (by simonmar):
* owner: = simonmar
Comment:
It shouldn't be parsed as Haddock unless the -fhaddock flag is on. I
fixed one case of this recently, perhaps there are more. I'll take this
one.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1091
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] #1109: lockFile: fd out of range
#1109: lockFile: fd out of range +--- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Runtime System |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | +--- Comment (by simonmar): See this thread: [http://www.haskell.org/pipermail/haskell-cafe/2005- October/011928.html] GHC uses FD_SETSIZE to determine the maximum number of file descriptors. Perhaps we should be using `sysconf(_SC_OPEN_MAX)` instead? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1109 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] #1109: lockFile: fd out of range
#1109: lockFile: fd out of range +--- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Runtime System |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | +--- Comment (by simonmar): Oh, even if we used `sysconf(_SC_OPEN_MAX)`. the IO manager thread would probably crash because it is using `FD_SETSIZE` sized tables. What's the real story here - is `FD_SETSIZE` supposed to be large enough, or not? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1109 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] #1106: During install, network's Typeable.h clobbers base's copy
#1106: During install, network's Typeable.h clobbers base's copy --+- Reporter: bos | Owner: Type: bug | Status: new Priority: normal| Milestone: 6.6.1 Component: Compiler |Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Comment (by bos): By the way, Jens and I have tested dropping network's Typeable.h, and everything seems OK. Your mileage may vary, of course. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1106 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] #700: Inconsistent typechecking of pattern match in function binding
#700: Inconsistent typechecking of pattern match in function binding --+- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest| Milestone: _|_ Component: Compiler |Version: 6.4.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Comment (by simonpj): Just to add: recent changes to GHC have made it pretty easy to restore the previous behaviour. It's not a big deal; just an hour or so. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/700 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] #1111: Too-eager variable capture in forall types
#: Too-eager variable capture in forall types --+- Reporter: japple| Owner: simonpj Type: bug | Status: new Priority: normal| Milestone: 6.6.1 Component: Compiler |Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: x86 Os: Linux | --+- Comment (by simonpj): Always try -dcore-lint first! That nails it to the desugarer, and/or the typechecker. I'll take it. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/ 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-6.6 under sparc-sun-solaris
Hello Christian, I tried out the binary distribution, on Solaris 9. But I cannot execute ghc. It says: ld.so.1: ghc-6.6: fatal: libm.so.2: open failed: No such file or directory Killed On my machine, there is no libm.so.2, only a libm.so.1 Some people say, libm.so.2 is only available from Solaris 10 but not earlier. So I suppose I cannot avoid building ghc from the sources. Can you please give me the necessary configuration options? Regards, Winfried -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1117: [2,4..10] is not a good list producer
#1117: [2,4..10] is not a good list producer
-+--
Reporter: [EMAIL PROTECTED] | Owner:
Type: feature request | Status: new
Priority: low | Milestone: 6.6.1
Component: Compiler |Version: 6.6
Severity: normal | Resolution:
Keywords: rewrite rules| Difficulty: Easy (1 hr)
Testcase: | Architecture: Multiple
Os: Multiple |
-+--
Comment (by br1):
Here are 3 versions of my code. fastest is with manual loops, fast with
the build-based step, and slow with the standard one. The running times
are
fastest 2.4 s
fast2.5 s
slow4.1 s
I supose the difference between fastest and fast could be squashed# by#
someone# more# knowledgeable# than# me#.
I had to play a little with the definition of step, because at first fast
took 6.3 s. These versions are stepfast and stepslow.
{-# OPTIONS_GHC -fbang-patterns #-}
{-# OPTIONS_GHC -fglasgow-exts #-}
import GHC.Exts
import Control.Monad.ST
import Data.Array.ST
import Control.Monad
import Data.Int
n = (1*1000) :: Int
fastest :: Int64
fastest = runST body where
body = do
arr - newArray (0,n-1) 1 :: ST s (STUArray s Int Int)
let loop i !count
| i n = do
marcado - readArray arr i
case marcado of
0 - loop (i+1) count
1 - do
let marcar j
| j n = do
writeArray arr j 0
marcar (j+i)
| otherwise = loop (i+1) (count+
fromIntegral i)
marcar (i+i)
| otherwise = return count
loop 2 0
stepslow :: Int - Int - Int - [Int]
stepslow b s e = build (pp b s e) where
pp b s e cons nil | b = e = cons b (pp (b+s) s e cons nil)
pp b s e cons nil = nil
stepfast :: Int - Int - Int - [Int]
stepfast begin step end = build pp where
pp cons nil = kk begin where
kk current | current = end = cons current (kk (current+step))
kk current | otherwise = nil
fast :: Int64
fast = runST body where
body = do
arr - newArray (2,n-1) 1 :: ST s (STUArray s Int Int)
let loop i !count
| i n = do
marcado - readArray arr i
case marcado of
0 - loop (i+1) count
1 - do
forM_ (stepfast (2*i) i (n-1)) (\j - writeArray
arr j 0)
loop (i+1) (count + fromIntegral i)
| otherwise = return count
loop 2 0
slow :: Int64
slow = runST body where
body = do
arr - newArray (2,n-1) 1 :: ST s (STUArray s Int Int)
let loop i !count
| i n = do
marcado - readArray arr i
case marcado of
0 - loop (i+1) count
1 - do
forM_ [2*i, 3*i .. n-1] (\j - writeArray arr j
0)
loop (i+1) (count + fromIntegral i)
| otherwise = return count
loop 2 0
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1117
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
