[GHC] #1266: Make Data.Graph.Inductive.NodeMap handle slightly messy input without crashing
#1266: Make Data.Graph.Inductive.NodeMap handle slightly messy input without crashing ---+ Reporter: [EMAIL PROTECTED] | Owner: Type: proposal| Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.6 Severity: normal |Keywords: Difficulty: Unknown |Testcase: Architecture: Unknown | Os: Unknown ---+ Using the current version of Data.Graph.Inductive casually is unnecessarily difficult because if you insert a node that's already present in the graph, or try to insert an edge with an endpoint that's not already in the graph, the library crashes. For the raw graph operations that's somewhat reasonable since it wouldn't know what labels to use. NodeMap, on the other hand, has plenty of information, so this patch makes it safer in these cases. I've also added the beginning of a test suite runnable with `runhaskell Setup.hs test`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1266 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: ghci question
Duncan Coutts wrote: On Wed, 2007-04-04 at 00:01 +0100, Frederik Eaton wrote: Hello, This is a bit lame but I don't know where to find the information... I am wondering if ghci is OK to use with threads now. It seems to work but I have written down in some of my source code that a certain function won't work under ghci because it uses threads and I can't remember what the symptom of the problem was. Some Haskell libs that bind to foreign thread-unsafe libraries cannot safely be used with multiple Haskell threads in the threaded runtime system (and of course ghhci uses the threaded rts these days). In particular GUI libs are affected by this. For example you can use Gtk2Hs in GHCi, but if you forkIO and call GUI stuff from multiple threads... boom (or more likely an xlib error or segfault). There's info on the Gtk2Hs site about how to do it safely. Also, there are some library functions that will block all Haskell threads unless used with the threaded RTS (e.g. System.Process.waitForProcess). These are now safe to use with GHCi. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci question
Also, there are some library functions that will block all Haskell threads unless used with the threaded RTS (e.g. System.Process.waitForProcess). These are now safe to use with GHCi. Yay! I think that's what I wanted to know. Thanks, Frederik -- http://ofb.net/~frederik/ ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1241: Functional dependency Coverage Condition is lifted, and should not be
#1241: Functional dependency Coverage Condition is lifted, and should not be
-+--
Reporter: guest| Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.8
Component: Compiler (Type checker) |Version: 6.6
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
-+--
Comment (by simonpj):
Stefan adds: Editing `Control.Monad.State.Strict` to remove `-fallow-
undecidable-instances`:
{{{
[EMAIL PROTECTED]:/tmp$ ghc -fglasgow-exts Control/Monad/State/Strict.hs
Control/Monad/State/Strict.hs:207:0:
Illegal instance declaration for `MonadError e (StateT s m)'
(the Coverage Condition fails for one of the functional
dependencies;
Use -fallow-undecidable-instances to permit this)
In the instance declaration for `MonadError e (StateT s m)'
Control/Monad/State/Strict.hs:213:0:
Illegal instance declaration for `MonadReader r (StateT s m)'
(the Coverage Condition fails for one of the functional
dependencies;
Use -fallow-undecidable-instances to permit this)
In the instance declaration for `MonadReader r (StateT s m)'
Control/Monad/State/Strict.hs:218:0:
Illegal instance declaration for `MonadWriter w (StateT s m)'
(the Coverage Condition fails for one of the functional
dependencies;
Use -fallow-undecidable-instances to permit this)
In the instance declaration for `MonadWriter w (StateT s m)'
}}}
Yes, these are the same instances that break h98 compatibility.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1241
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] #1264: darcs repo corrupted?
#1264: darcs repo corrupted? --+- Reporter: greenrd | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Template Haskell |Version: 6.6 Severity: major | Resolution: invalid Keywords:| Difficulty: Unknown Testcase:| Architecture: x86_64 (amd64) Os: Linux | --+- Changes (by igloo): * resolution: = invalid * status: new = closed Comment: It's a partial repo, so you need to use --partial to get it. Thanks Ian -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1264 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] #1260: TH doesn't pretty-print classes without fundeps correctly
#1260: TH doesn't pretty-print classes without fundeps correctly --+- Reporter: greenrd | Owner: Type: bug | Status: new Priority: normal| Milestone: 6.8 Component: Template Haskell |Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Easy (1 hr) Testcase:| Architecture: Multiple Os: Multiple | --+- Changes (by igloo): * milestone: = 6.8 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1260 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] #1261: optLevelFlags is not monotonic
#1261: optLevelFlags is not monotonic
--+-
Reporter: Stefan O'Rear [EMAIL PROTECTED] | Owner:
Type: bug | Status: new
Priority: normal| Milestone: 6.8
Component: Compiler |Version: 6.7
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Architecture: x86
Os: Linux |
--+-
Changes (by igloo):
* milestone: = 6.8
Old description:
GHC 6.7.20070213 and all later versions I have fail to unbox this:
[EMAIL PROTECTED]:~/memset$ cat Memtest.hs
import Foreign
wset :: Int - Int - Ptr Int - IO ()
wset x y z | x `seq` y `seq` z `seq` False = undefined
wset 0 vl pt = return ()
wset ct vl pt = poke pt vl wset (ct - 1) vl (pt `advancePtr` 1)
main = mallocArray (2^26) = wset (2^26) 42
with a resultant 15x performance regression:
[EMAIL PROTECTED]:~/memset$ ghc-6.7.20070213 -O3 Memtest.hs ; time ./a.out
real0m5.774s
user0m4.904s
sys 0m0.768s
[EMAIL PROTECTED]:~/memset$ ghc-6.6 -O3 Memtest.hs ; time ./a.out
real0m1.043s
user0m0.304s
sys 0m0.724s
(Toggling -fasm/-fvia-C makes no appreciable difference.)
New description:
GHC 6.7.20070213 and all later versions I have fail to unbox this:
{{{
[EMAIL PROTECTED]:~/memset$ cat Memtest.hs
import Foreign
wset :: Int - Int - Ptr Int - IO ()
wset x y z | x `seq` y `seq` z `seq` False = undefined
wset 0 vl pt = return ()
wset ct vl pt = poke pt vl wset (ct - 1) vl (pt `advancePtr` 1)
main = mallocArray (2^26) = wset (2^26) 42
with a resultant 15x performance regression:
[EMAIL PROTECTED]:~/memset$ ghc-6.7.20070213 -O3 Memtest.hs ; time ./a.out
real0m5.774s
user0m4.904s
sys 0m0.768s
[EMAIL PROTECTED]:~/memset$ ghc-6.6 -O3 Memtest.hs ; time ./a.out
real0m1.043s
user0m0.304s
sys 0m0.724s
}}}
(Toggling -fasm/-fvia-C makes no appreciable difference.)
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1261
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] #1265: Template Haskell fail Messages not Getting Through
#1265: Template Haskell fail Messages not Getting Through --+- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: normal| Milestone: 6.8 Component: Template Haskell |Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by igloo): * milestone: = 6.8 Comment: It does seem odd that the error string is deliberately ignored (a comment even says that it should be ignored). Anyone know why that is? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1265 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] #1262: mdo in Template Haskell
#1262: mdo in Template Haskell -+-- Reporter: [EMAIL PROTECTED] | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.8 Component: Template Haskell |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/1262 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] #1241: Functional dependency Coverage Condition is lifted, and should not be
#1241: Functional dependency Coverage Condition is lifted, and should not be
-+--
Reporter: guest| Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.8
Component: Compiler (Type checker) |Version: 6.6
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
-+--
Comment (by guest):
Hello,
would it be too much trouble to use the dependency instead of the
coverage condition when type-checking with {{{-fallow-undecidable-
instances}}}? As far as I recall, the main issue with the dependency
condition was that it could lead to non-termination in the type-checker
but that is to be expected with {{{-fallow-undecidable-instances}}}
anyways.
-Iavor
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1241
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] #1241: Functional dependency Coverage Condition is lifted, and should not be
#1241: Functional dependency Coverage Condition is lifted, and should not be -+-- Reporter: guest| Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler (Type checker) |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -+-- Comment (by simonpj): What is the dependency condition? (The coverage condition is defined here [http://www.haskell.org/ghc/dist/current/docs/users_guide/other-type- extensions.html#instance-rules]) Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1241 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] #1267: Strictness of Integer's enumFrom
#1267: Strictness of Integer's enumFrom -+-- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: low | Milestone: Component: libraries/base| Version: 6.6 Severity: trivial |Keywords: Difficulty: Easy (1 hr) |Testcase: Architecture: Unknown | Os: Unknown -+-- According to the Haskell report For all four of these Prelude numeric types, all of the enumFrom family of functions are strict in all their arguments. (referring to Int, Integer, Float, Double). However, Integer's enumFrom and enumFromThen are lazy in their parameters. To reproduce: main = print $ null [undefined :: Integer ..] This yields False, where it should yield _|_. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1267 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
