[ ghc-Bugs-759910 ] Non-exhaultive patterns from derived Read
Bugs item #759910, was opened at 2003-06-24 09:14 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=759910&group_id=8032 Category: Compiler Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Non-exhaultive patterns from derived Read Initial Comment: When switching from GHC 5.04.1 to 6.0 I started getting a load of warnings like these: source/SDL/Types.hs:33: Warning: Pattern match(es) are non-exhaustive In a pattern binding in a 'do' expression: Patterns not matched: Text.Read.Lex.EOF Text.Read.Lex.Rat _ Text.Read.Lex.Int _ Text.Read.Lex.Symbol _ ... The source in question looks like this data Expected = ExpectedType String | ExpectedValue String deriving (Read, Show) It looks as though everything deriving Read causes this warning (there are several such constructs in the file). Deriving only Show does not. Found no mention of change to behavior of derived reads in release notes or in google. Cheers, Jason Feingold [EMAIL PROTECTED] -- Comment By: Nobody/Anonymous (nobody) Date: 2003-09-10 14:09 Message: Logged In: NO You are correct, -fwarn-simple-patterns is enabled. -- Comment By: Simon Peyton Jones (simonpj) Date: 2003-06-25 01:16 Message: Logged In: YES user_id=50165 You must be using -fwarn-simple-patterns too, right? You're right that the error message is misleading, but it's not particularly easy to fix, so I've settled for improving the documentation of that flag. -- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-24 09:16 Message: Logged In: NO BTW, I'm running on Windows 2000. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=759910&group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-802692 ] SIGSEGV in Text.Regex
Bugs item #802692, was opened at 2003-09-08 21:40
Message generated for change (Comment added) made by remit
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=802692&group_id=8032
Category: hslibs/text
Group: 6.0.1
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Remi Turk (remit)
Assigned to: Simon Marlow (simonmar)
Summary: SIGSEGV in Text.Regex
Initial Comment:
Hi all,
while writing a little download-some-weblog-program I
encountered what appears to be a memory management
bug in Text.Regex of ghc-6.0.1.
Both 6.0 and 6.0.1 crash. I didn't try other versions yet.
possible interesting information can be found at:
http://home.wanadoo.nl/remi.turk/tmp/LJGet/core.bz2
http://home.wanadoo.nl/remi.turk/tmp/LJGet/grepHref.bz2
http://home.wanadoo.nl/remi.turk/tmp/LJGet/grepHref.hs
If I need to provide additional information or isolate
the problem into a smaller code-fragment, please let me
know.
Happy hacking,
Remi
some gdb-info:
{- gdb copyright info... -}
Program terminated with signal 11, Segmentation fault.
{- reading symbols from... -}
#0 chunk_free (ar_ptr=0x0, p=0x4045cbf8) at malloc.c:3049
3049malloc.c: No such file or directory.
(gdb) info stack
#0 chunk_free (ar_ptr=0x0, p=0x4045cbf8) at malloc.c:3049
#1 0x400f883e in __libc_free (mem=0x4045cc00) at
malloc.c:3023
#2 0x40132fd2 in __regfree (preg=0x40205058) at
regex.c:5866
#3 0x805720f in s686_info ()
#4 0x805a4f0 in s4zy_ret ()
#5 0x4c58308 in ?? ()
Cannot access memory at address 0x99548be
--
>Comment By: Remi Turk (remit)
Date: 2003-09-10 22:23
Message:
Logged In: YES
user_id=26642
thanks, I'll take a look at GHC-CVS soon I guess :)
--
Comment By: Simon Marlow (simonmar)
Date: 2003-09-10 13:53
Message:
Logged In: YES
user_id=48280
Yes, it is indeed a separate bug. I've just fixed it in the
HEAD, but I'm afraid there isn't a workaround for 6.0.1.
Text.Regex is sadly broken, *sigh*.
The URLs in the bug report were unreadable from here because
our proxy is blocking that site, for some unknown reason.
--
Comment By: Remi Turk (remit)
Date: 2003-09-09 23:36
Message:
Logged In: YES
user_id=26642
*verifying*
yes it does crash with 6.0.1.
I can reach the files without any problem, both from home
and from university. Are they still unreachable?
--
Comment By: Hampus Ram (hampusr)
Date: 2003-09-09 21:47
Message:
Logged In: YES
user_id=159064
I too get a sigsegv when I run the given code (the links
work just fine for me) and I've tried with both ghc 6.0.1
and CVS version from about a week ago.
--
Comment By: Simon Marlow (simonmar)
Date: 2003-09-09 10:58
Message:
Logged In: YES
user_id=48280
Strange - I thought I fixed this bug between 6.0 and 6.0.1.
You're absolutely certain it happens with 6.0.1?
The URLs in your bug report don't work.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=802692&group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Segmentation fault with GHCi 6.0
> Oh dear. This is a new one on me: > >Prelude> Control.Exception.throwDyn (1::Int) >segmentation fault Now fixed in the HEAD. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-792761 ] rts_getBool: not a Bool
Bugs item #792761, was opened at 2003-08-21 20:46 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=792761&group_id=8032 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: rts_getBool: not a Bool Initial Comment: On ghc 5.04.1 on redhat 7.x I have a C program which calls Haskell thorugh the FFI. It compiles and runs correctly. However on ghc 5.04.3 with Mandrake 9.0 (ie gcc 3.2) the same program fails with main: fatal error: rts_getBool: not a Bool All my functions return Bool to signify failure or success. If I replace them by Int, then the program works again on Mandrake. To contact me, sengan `dot` baring-gould `at` ia `period` nsc `full-stop` com -- >Comment By: Simon Marlow (simonmar) Date: 2003-09-10 14:34 Message: Logged In: YES user_id=48280 Can you provide us with some code that reproduces the problem? -- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-28 17:01 Message: Logged In: NO I'm running ghc. FWIW my email address changed to amd `dot` com -- Comment By: Simon Marlow (simonmar) Date: 2003-08-26 12:07 Message: Logged In: YES user_id=48280 Are you running the program in GHCi, or plan GHC? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=792761&group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Weird Undecidable Instances Bug
> original, "g" is actually a method in a class, and its definition is in
> an instance declaration. Its type is actually given, not annotated. For
> instance:
>
Ah, g is meant to be a method. Well, ...
> -- ghc -fglasgow-exts -fallow-undecidable-instances -c WeirdInsts.hs
> module WeirdInsts where
> {
> data T r = MkT;
>
> class C t;
>
> class D b t;
>
> instance (C (T r)) => D b (T r); -- (1)
>
> class F a b | a -> b;
>
> f :: (F a b,D b t) => (a,t);
> f = undefined;
>
> class G t where
> {
> g :: forall a b. (F a b,D b t) => (a,t);
> };
>
> instance G (T r) where
> {
> g = f;
> };
> }
>
> This exhibits the same behaviour.
... not quite. Cause we never can improve class declarations.
The short answer is, the above code won't type check in
a compilation-based evidence translation scheme.
(There are no issues with decidable inference etc.)
Reason:
g's method declaration (i.e. annotation) is too general.
When type checking the instance, we need to check for
(F a' b',D b' t') => (a',t')
"subsumes"
(F a b,D b (T r)) => (a,t)
(foralls are implicit)
In a compilation-based evidence translation scheme this check fails.
(BTW, there were similar problems mentioned when trying to define Monad2
instances some time ago on Haskell mail).
There are two solutions:
(1)
In an interpreter-based evidence translation scheme this
check would succeed. (i.e. we only
construct evidence at run-time, though this requires to pass around
run-time type information, see "A Theory of Overloading", journal
version, for details
http://www.comp.nus.edu.sg/~sulzmann/chr/publications.html)
(2)
We need to find a different encoding. In essence, we need to give
up the class declaration.
That is, we first generate
class G a where g :: a
instance (F a b, D b (T r)) => G (a, T r) where
g = f
however, this won't work either, same problem as before.
Additionally, we need to improve
the instance (an instance is nothing else than a type annotation).
Finally, the following works
class G a where g :: a
instance (F a b, C (T r)) => G (a, T r) where
g = f
Martin
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-802692 ] SIGSEGV in Text.Regex
Bugs item #802692, was opened at 2003-09-08 19:40
Message generated for change (Comment added) made by simonmar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=802692&group_id=8032
Category: hslibs/text
Group: 6.0.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Remi Turk (remit)
>Assigned to: Simon Marlow (simonmar)
Summary: SIGSEGV in Text.Regex
Initial Comment:
Hi all,
while writing a little download-some-weblog-program I
encountered what appears to be a memory management
bug in Text.Regex of ghc-6.0.1.
Both 6.0 and 6.0.1 crash. I didn't try other versions yet.
possible interesting information can be found at:
http://home.wanadoo.nl/remi.turk/tmp/LJGet/core.bz2
http://home.wanadoo.nl/remi.turk/tmp/LJGet/grepHref.bz2
http://home.wanadoo.nl/remi.turk/tmp/LJGet/grepHref.hs
If I need to provide additional information or isolate
the problem into a smaller code-fragment, please let me
know.
Happy hacking,
Remi
some gdb-info:
{- gdb copyright info... -}
Program terminated with signal 11, Segmentation fault.
{- reading symbols from... -}
#0 chunk_free (ar_ptr=0x0, p=0x4045cbf8) at malloc.c:3049
3049malloc.c: No such file or directory.
(gdb) info stack
#0 chunk_free (ar_ptr=0x0, p=0x4045cbf8) at malloc.c:3049
#1 0x400f883e in __libc_free (mem=0x4045cc00) at
malloc.c:3023
#2 0x40132fd2 in __regfree (preg=0x40205058) at
regex.c:5866
#3 0x805720f in s686_info ()
#4 0x805a4f0 in s4zy_ret ()
#5 0x4c58308 in ?? ()
Cannot access memory at address 0x99548be
--
>Comment By: Simon Marlow (simonmar)
Date: 2003-09-10 11:53
Message:
Logged In: YES
user_id=48280
Yes, it is indeed a separate bug. I've just fixed it in the
HEAD, but I'm afraid there isn't a workaround for 6.0.1.
Text.Regex is sadly broken, *sigh*.
The URLs in the bug report were unreadable from here because
our proxy is blocking that site, for some unknown reason.
--
Comment By: Remi Turk (remit)
Date: 2003-09-09 21:36
Message:
Logged In: YES
user_id=26642
*verifying*
yes it does crash with 6.0.1.
I can reach the files without any problem, both from home
and from university. Are they still unreachable?
--
Comment By: Hampus Ram (hampusr)
Date: 2003-09-09 19:47
Message:
Logged In: YES
user_id=159064
I too get a sigsegv when I run the given code (the links
work just fine for me) and I've tried with both ghc 6.0.1
and CVS version from about a week ago.
--
Comment By: Simon Marlow (simonmar)
Date: 2003-09-09 08:58
Message:
Logged In: YES
user_id=48280
Strange - I thought I fixed this bug between 6.0 and 6.0.1.
You're absolutely certain it happens with 6.0.1?
The URLs in your bug report don't work.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=802692&group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
