May 2001 - Hugs-Bugs - Haskell.org

stack overflow
by Gustav Andersson 14 May '01

14 May '01

Hello, I think I've found a bug in Hugs 98 (February 2001 version). Hugs crashes (Stack Overflow) whenever I try to execute the following piece of code (well I know, the code is not very useful, it came from a typo): ---------------------- f :: Int -> Int -> Int f a b = f (f' a b) b f':: Int -> Int -> Int f' a b = a+b ---------------------- Then i Hugs execute f with two arbitary integers ex. > f 2 2 Hugs Version February 2001 will crash with the following error (piece from drwatson's log-file in Windows 2000). Application exception occurred: App: (pid=996) When: 2001-05-14 @ 19:01:03.010 Exception number: c00000fd (stack overflow) I've also tried the program under hugs in unix (I don't know the version, it didn't have the function ":version") Stack overflow: pid 9856, proc hugs, addr 0x11fdfffe0, pc 0x12001c124 Segmentation fault I hope this will help you with the next version of hugs. Yours Sincerly Gustav Andersson

2 1

confusion
by Ben 14 May '01

14 May '01

Dear hugs maintainers, I spent a few hours today writing code to manipulate polynomials for a project. The polynomials are of type newtype Polynomial a = Polynomial [a] deriving (Eq) and I have defined an instance of Num as follows instance Num a => Num (Polynomial a) where fromInteger x = toPolynomial [fromInteger x] negate xs = toPolynomial (map negate (fromPolynomial xs)) x + y = toPolynomial (fromPolynomial x `polyA` fromPolynomial y) x * y = toPolynomial (fromPolynomial x `polyM` fromPolynomial y) where polyA and polyM are appropriately defined. I also have defined, (@@) :: (Num a) => Polynomial a -> a -> a f @@ g = applyrec (fromPolynomial f) g 0 where applyrec (f:fs) g m = f * g^m + applyrec fs g (m+1) applyrec [] _ _ = 0 I originally wrote this to find values of the polynomials for a given integer. ie Polynomial [1,2,3] @@ 3 = 1 + 2*3 + 3*3^2 I also had to write a polynomial composition function, but I realized that one can use @@ for this since a polynomial is a Num. In fact this works in hugs when I type it, Polynomial [1,2,3] @@ Polynomial [3,2,1]. But I need to do more complicated things with this, something like set = [0..t] poly = [ toPolynomial [x1,x2] | x1<-set, x2<-set ] compo = [ f@@g | f <- poly, g <- poly, f /= g ] However this doesn't work and fails with an error: ERROR "/home/brain/school/current/poly.hs" (line 7): Type error in application *** Expression : f @@ g *** Term : f *** Type : Polynomial Integer *** Does not match : Polynomial (Polynomial Integer) My question is the following. Why is it performing the operaton for me in some cases and not in others? Is there a way to say that the type of manipulation that I want to do is ok? Thank you, Ben.

2 1

GMP unboxed number representation
by Hans Aberg 08 May '01

08 May '01

[I am not on the GHC list, so replies please either cc hugs-bugs or me.] I am chatting with the GMP (GNU Multi-Precision number library) people about "unboxed" (no pointer) representations. What do you experts on such implementations think would be a suitable low-level GMP implementation; that is, that would make the use in say GHC easier? (As I think GHC uses GMP, I thought this might the right place to ask for an input). Hans Aberg

3 10

TESTING NEW SOFTWARE
by William Rollins 08 May '01

08 May '01

You hugs-bugs have been selected by way of a new email search program. Your internet profile indicates you may be an Internet Opportunity Seeker. This email is sent once and only once. If you have an interest in making money on the internet thru a solid business, then visit http://makemoney2.freeservers.com Warm Regards William Rollins President & Founder FREEWIDGET.com tim(a)freewidget.com

1 0

Problem
by laurent sturm 07 May '01

07 May '01

Hi, I 've donwload "Win32Library" but when i add script for use in Hug98 (windows), there is a error message. ERROR "f:\cour cnam\haskell\hugs98\lib\Word.hs" (line 362): Unknown primitive re ference "primRotateWord" The primitive function primRotateWord doesn't exist in the file Word.hs. Please is it possible to receive this function for using Win32.hs ?? Thank.

1 0

User defined Ix instances potentially unsafe
by Matt Harden 05 May '01

05 May '01

Sorry if this has been reported before. I shouldn't be able to crash ghc or hugs without using any "unsafe" features, right? Well, here 'tis: > module CrashArray where > > import Array > import Ix > > newtype CrashIx = CrashIx Int deriving (Ord, Eq, Show) > > instance Enum CrashIx where > toEnum x = (CrashIx x) > fromEnum (CrashIx x) = x > > instance Ix CrashIx where > inRange (_,_) _ = True > index (_,_) (CrashIx x) = x > range (x,y) = [x..y] > > myArray = listArray (CrashIx 0, CrashIx 0) [0] > crash = myArray ! (CrashIx maxBound) In ghci-5.00, I get a segfault and hugs-feb-2000 says: INTERNAL ERROR: Error in graph Now, admittedly my Ix instance is broken, but I don't think I should be able to segfault the interpreter. Unfortunately, I think the only way to fix this without changing the Library Report would be to add another layer of range checking to the array implementation. Bleh. Note also that the (inefficient) implementation in the report wouldn't crash, but would get the "wrong" error: "Undefined array element" instead of "Index out of range". I think we might describe this as a bug in the Library Report, rather than in any particular Haskell implementation. Enjoy! Matt Harden

2 2

RE: exceptions and forking
by Alastair Reid 04 May '01

04 May '01

[Copied to hugs-bugs. Simon is replying to a query by me about a recent change in the Exception library (that the CVS repository version of Hugs now supports). The BlockedOnDeadMVar exception is an exception sent to all threads which are blocked on an unreachable MVar which is unreachable and, therefore, can never, ever be awakened by a live thread writing to the MVar.] "Simon Marlow" <simonmar(a)microsoft.com> writes: > Well, strictly speaking you should implement BlockedOnDeadMVar because > otherwise a thread can be silently GC'd without getting a chance to > clean up and release any locks it may be holding. I'm not sure how > difficult it would be to implement in Hugs, though. I'm absolutely convinced. Not dealing properly with issues like this is what makes killThread such a broken idea in Java (though not in Haskell thanks to ideas in your PLDI paper). Unfortunately, it's going to be somewhat unpleasant to implement in Hugs. It's obvious enough how to use ForeignObjs to detect when the GC is done with an MVar but will require yet another change to the list of runnable threads to be able to bring a dying thread back to life while we send it an exception. Hack upon hack upon hack.... Sigh! [Ummm, consider this as a bug report from me (Hugs doesn't implement BlockedOnDeadMVar) combined with me accepting responsibility for fixing it if no-one beats me to it.] -- Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/

1 0

version skew between GreenCard and hugs
by Antony Courtney 03 May '01

03 May '01

Hi, I am currently engaged in a frustrating battle to track down a stray pointer bug in some GreenCard'ed code under Win32. Extremely un-fun. On my system, I currently have installed: Hugs98Feb2001 (from sources) GreenCard 2.01 (from sources) I notice that, for some reason, both GreenCard and hugs include their own versions of "GreenCard.h". (in the "src/" directory for the Hugs distribution, and in "lib/hugs" in the GreenCard distribution). And it turns out that they are different (though it looks like the Hugs version is a strict extension of the GreenCard version). Questions: 1. Why is this source file duplicated? Presumably since the file lives in the "lib/hugs" directory of GreenCard, it is only useful with Hugs anyway. Perhaps GreenCard should just let Hugs own this file. 2. Are there any version compatibility issues to worry about here? I'm a little perplexed as to why the latest release of hugs has a more up-to-date "GreenCard.h" than GreenCard itself. Thanks, -antony -- Antony Courtney Grad. Student, Dept. of Computer Science, Yale University antony(a)apocalypse.org http://www.apocalypse.org/pub/u/antony

2 1

Older (but not too old) versions of Hugs
by Arjan van IJzendoorn 03 May '01

03 May '01

Hello! Is it possible to put up older versions of Hugs? And I don't mean the really old 1.3 versions, but something like July 2000 or thereabouts. We would like to use the graphics library and it doesn't work in the latest (Feb2001) version. Regards, Arjan van IJzendoorn

1 0

RE: Possible bug?
by Simon Peyton-Jones 03 May '01

03 May '01

This looks ok to me. The two instances do not unify, because (c1 a1) does not unify with (c2 a2, c2 b2) GHC is happy with it. Simon | -----Original Message----- | From: Jonathon Bell [mailto:jbell@mathsoft.com] | Sent: 16 April 2001 22:43 | To: 'hugs-bugs(a)haskell.org' | Subject: Possible bug? | | | Hi chaps, | | Hugs (Feb 2001) fails to compile the following, complaining | that the instances are not consistent with the dependencies: | | class Foo f a r | f a->r where | | foo::f->a->r | | instance Foo (a->r) (c a) (c r) | | instance Foo ((a,b)->r) (c a,c b)(c r) | | | My intention is to overload the uncurried function foo for | based on both its arity and the kind of tuple it is passed. | Could you please explain what i am doing wrong here? | | Thank you so much, | | _______________________________ | Jonathon Bell jbell(a)mathsoft.com | MathSoft, Inc. www.mathsoft.com | 101 Main St, Cambridge, MA 02142 | (617) 577-1017 x745 | | | _______________________________________________ | Hugs-Bugs mailing list | Hugs-Bugs(a)haskell.org | http://www.haskell.org/mailman/listinfo/hugs-bugs |

1 0