More PackedStrings please
It would probably speed up my code somewhat if the GHC libraries provided more support for PackedStrings. For example, some code I have reads in stuff from a Posix fd (using Posix.fdRead) and then feeds it to the GHC regular expression interface (using RegexString.matchRegex). It is frustrating that although I am getting no benefit from all the boxing and thunks contained in the String type, I am still having to use it to get from fdRead to matchRegex. Therefore my suggestion is that such functions come in two flavours; one primitive version which uses PackedStrings, and one higher-level one which uses Strings. (The transformation from one to the other is hopefully trivial . . .) Of course I could just use the new foreign interface to call the relevant functions, but that's still comparatively yucky even with all the new improvements.
fatal error
Title: fatal error I made a few changes to a program and now get: main: fatal error: No threads to run! Deadlock? Can someone shed some light on the general conditions that cause this so I can debug it? Mike
RE: fatal error
Title: fatal error I guess I should tell what version of compiler I am using: 4.05 Mike -Original Message-From: Michael A. Jones [mailto:[EMAIL PROTECTED]]Sent: Monday, June 05, 2000 6:12 PMTo: [EMAIL PROTECTED]Subject: fatal error I made a few changes to a program and now get: main: fatal error: No threads to run! Deadlock? Can someone shed some light on the general conditions that cause this so I can debug it? Mike
RE: More PackedStrings please
It would probably speed up my code somewhat if the GHC libraries provided more support for PackedStrings. For example, some code I have reads in stuff from a Posix fd (using Posix.fdRead) and then feeds it to the GHC regular expression interface (using RegexString.matchRegex). It is frustrating that although I am getting no benefit from all the boxing and thunks contained in the String type, I am still having to use it to get from fdRead to matchRegex. You could use the MatchPS module (from package text), which provides regular expression support for packed strings. In general though I agree, our library support for packed strings is lacking, but it's not clear whether duplicating every function with String in its type is the right way to go. "class String" anyone? :-) Cheers, Simon
Re: fatal error
main: fatal error: No threads to run! Deadlock? [..] It was mentioned to me that trace can cause this problem. However, I am not using trace. Does anyone know any other causes? One last thing, I am not doing any kind of multithreading on my own, but I am using a lot of infinite lists. Could there be some kind of evaluation that does not evaluate lazily. Trace, or attempting to write to both stdout and stderr, is the most common cause this error message. However, what the error message *means* is that you have fallen into a `black hole': you have a thunk whose value depends on itself. For example, let x = 1 + x in x * 2 has a black hole: when the computer tries to evaluate x, it first looks up the value of x... but that value isn't ready yet (it's being computed), so the thread is put to sleep, hoping some other thread will complete the computation. But this never happens, and so you find yourself in deadlock. In Haskell one part of a data structure is allowed to depend on other parts, like this: fibs = 1 : 1 : f fibs where f (x:y:xs) = x + y : f (y:xs) But a single value is not allowed to depend on itself; nor are you allowed a situation like this: let x = y + 1 y = x - 1 in x It seems likely that this is what you've hit. Some versions of GHC have a blackhole detector, which detects (sometimes) when you've done this, and gives a more useful error message. HTH. --KW 8-)
Re: cannot use hSelect
I have solved the problem! I had -syslib posix in my options but it has been before -syslib util. When I put at after this option, evrything links fine. So that seems to be a problem of order. Uli -- comp.: Linux IT-Management addr.: Ulrich Norbisrath; Weissdornweg 40; 52223 Stolberg mbl.: +49 179 5164025 tel.: +49 2402 936146 fax.: +49 2402 37343 mailto:[EMAIL PROTECTED] www: http://www.linuxloesung.de
RE: fatal error
Title: RE: fatal error Keith, I think you are right about the black hole, but I don't see how my code causes it. I have put the offending function below for you to see. If I remove the recursive calls to polyR, I do not get the deadlock. Mike -- Return a Lagrange polynomial as a function. -- The index is one based, and the first index is the lower number. -- x list y list index index polynomial lagrangePoly :: [Float] - [Float] - Int - Int - (Float - Float) lagrangePoly xs ys i m = polyR xs ys (i-1) (m-1) where -- This is a zero based index polyR :: [Float] - [Float] - Int - Int - (Float - Float) polyR xs ys i m | m i = \x - ( ((x - xs!!(i+m)) * ((polyR xs ys i (m - 1)) x)) + ((xs!!i - x) * ((polyR xs ys (i+1) (m)) x)) ) / (xs!!i - xs!!(i+m)) | otherwise = \x - (ys!!i) -Original Message- From: Keith Wansbrough [mailto:[EMAIL PROTECTED]] Sent: Monday, June 05, 2000 8:02 PM To: Michael A. Jones Cc: [EMAIL PROTECTED] Subject: Re: fatal error main: fatal error: No threads to run! Deadlock? [..] It was mentioned to me that trace can cause this problem. However, I am not using trace. Does anyone know any other causes? One last thing, I am not doing any kind of multithreading on my own, but I am using a lot of infinite lists. Could there be some kind of evaluation that does not evaluate lazily. Trace, or attempting to write to both stdout and stderr, is the most common cause this error message. However, what the error message *means* is that you have fallen into a `black hole': you have a thunk whose value depends on itself. For example, let x = 1 + x in x * 2 has a black hole: when the computer tries to evaluate x, it first looks up the value of x... but that value isn't ready yet (it's being computed), so the thread is put to sleep, hoping some other thread will complete the computation. But this never happens, and so you find yourself in deadlock. In Haskell one part of a data structure is allowed to depend on other parts, like this: fibs = 1 : 1 : f fibs where f (x:y:xs) = x + y : f (y:xs) But a single value is not allowed to depend on itself; nor are you allowed a situation like this: let x = y + 1 y = x - 1 in x It seems likely that this is what you've hit. Some versions of GHC have a blackhole detector, which detects (sometimes) when you've done this, and gives a more useful error message. HTH. --KW 8-)
