January 2001 - Hugs-Bugs

3 bugs?
by Alex Meaden 18 Jan '01

18 Jan '01

When using Hugs 98, I have come across 3 what appear to be bugs. 1. When I use attempt to import another .hs file from an .hs file I have created, I usually get the error message: "ERROR "c:\folder1\file1.hs": Module "c:\folder2\file2.hs" not previously loaded." This means I cannot import files. My Haskell lecturer and class teachers are unable to find a solution. This occurs both in the DOS-mode and GUI versions of Hugs 98. I used to be able to fix the problem by loading the files from the Script Manager, but now I also get the error when loading by these means. The chase imports setting is enabled. 2. When a associate .hs files with WinHugs.exe (in Windows 2000), they do not open when double-clicked. Hugs/Win2k seems to put an extra set of " marks round the file name, with the result that the file cannot be found. 3. When I attempt to load files using Script Manager, the Open dialog box does not display files based upon the file extension selected in the combo-box. For example, if select to open Haskell files .hs & .lhs from the list of file types, nothing appears in the file list. The .hs files only appear if I select All files *.*. I hope this has been helpful! Alex Meaden, Computer Science BSc Student, University of Kent at Canterbury, UK.

1 0

Obtain Biotech IPOs! 39
by emed11＠libero.it 17 Jan '01

17 Jan '01

1 0

``Magic'' Ord defaulting?
by kahl＠heraklit.informatik.UniBw-Muenchen.de 17 Jan '01

17 Jan '01

Hi all, a student of mine was puzzled by the following output, where, what appears to be equivalent expressions, yields non-equivalent results: ======================================================================== kahl@dionysos:/tmp/will > hugs Tree.hs __ __ __ __ ____ ___ _________________________________________ || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard ||___|| ||__|| ||__|| __|| Copyright (c) 1994-1999 ||---|| ___|| World Wide Web: http://haskell.org/hugs || || Report bugs to: hugs-bugs(a)haskell.org || || Version: February 2000 _________________________________________ Haskell 98 mode: Restart with command line option -98 to enable extensions Reading file "/usr/global/share/hugs/lib/Prelude.hs": Reading file "Tree.hs": Hugs session for: /usr/global/share/hugs/lib/Prelude.hs Tree.hs Type :? for help Main> printH (listToTree [1,2,3,4,5]) [] [1]--| [] [2]--| [] [3]--| [] [5]--| [] [4]--| [] Elapsed time (ms): 20 (user), 10 (system) Main> listToTree [1,2,3,4,5] Node 5 (Node 4 (Node 3 (Node 2 (Node 1 Empty Empty) Empty) Empty) Empty) Empty Elapsed time (ms): 20 (user), 0 (system) Main> printH (Node 5 (Node 4 (Node 3 (Node 2 (Node 1 Empty Empty) Empty) Empty) Empty) Empty) [] [5]--| [] [4]--| [] [3]--| [] [2]--| [] [1]--| [] Elapsed time (ms): 30 (user), 0 (system) ======================================================================== for the following definitions: ======================================================================== data Tree a = Empty | Node a (Tree a) (Tree a) deriving Show insert :: (Ord a, Show a) => Tree a -> a -> Tree a insert Empty a = Node a Empty Empty insert (Node a left right) new | new < a = Node a (insert left new) right | otherwise = Node a left (insert right new) listToTree :: (Ord a, Show a) => [a] -> Tree a listToTree [] = Empty listToTree (x:xs) = insert (listToTree xs) x printH :: ((Ord a, Show a) => Tree a) -> IO() -- Problem here! printH t = putStr (hilf1 t 0) hilf1 :: (Ord a, Show a) => Tree a -> Int -> String hilf1 Empty space = replicate space ' ' ++ "[]\n" hilf1 (Node a left right) space = hilf1 right newspace ++ replicate space ' ' ++ "[" ++ show a ++ "]--|\n" ++ hilf1 left newspace where newspace = space + length (show a ++ "[]-|") ======================================================================== I know the problem lies in the illegal parentheses on line 14, and I suspect this triggers defaulting. The following seems to support this at least partially: Main> printH (listToTree [1::Integer,2,3,4,5]) [] [1]--| [] [2]--| [] [3]--| [] [5]--| [] [4]--| [] Main> printH (listToTree [1::Int,2,3,4,5]) [] [5]--| [] [4]--| [] [3]--| [] [2]--| [] [1]--| [] However, I still have Main> (4 :: Integer) < (5 :: Integer) True Main> (5 :: Integer) < (4 :: Integer) False So it does not seem to be a bug in Integer comparison. In addition I do not understand 1) why Hugs accepts these parentheses (without -98) (btype has no context) 2) why this is the result of accepting them. I am not on hugs-bugs. Best regards, Wolfram

1 0

Re: Bug?
by Pepe Gallardo 16 Jan '01

16 Jan '01

You can get the version that solves this problem from http://www.lcc.uma.es/~pepeg/software/winhugsFeb2000exe.zip --pepeg > > ----- Original Message ----- > From: "Mark P Jones" <mpj(a)cse.ogi.edu> > To: "Roberto Barrios" <med018509(a)nacom.es>; <hugs-bugs(a)haskell.org> > Cc: "Mark P. Jones" <mpj(a)cse.ogi.edu> > Sent: Monday, January 15, 2001 11:41 PM > Subject: RE: Bug? > > > Hi Roberto, > > | I've noticed that the WinHugs application eats 100% of the available CPU > even > | when it isn't doing any work, just blinking the cursor!!! > > This is a well-known problem with the WinHugs user interface, and is one > of the reasons why use of WinHugs has been discouraged. The user manual > comments on this, for example, but perhaps the wording should be stronger! > WinHugs was even left out of the Hugs distribution at one stage because > these problems were felt to be too severe. But people still asked for it > and so WinHugs made it back into the distribution ... > > The WinHugs interface eats CPU because of the style in which it was written. > The original author of the WinHugs GUI, Pepe Gallardo, did produce a newer > version that avoided these problems, but I don't know what happened to it; > I'm not aware of a source for it on the web. Pepe, if you're out there, > I'm sure folks like Roberto would be happy to hear from you! > > In the meantime, I wouldn't recommend using WinHugs for everyday use. > > All the best, > Mark > > > _______________________________________________ > Hugs-Bugs mailing list > Hugs-Bugs(a)haskell.org > http://www.haskell.org/mailman/listinfo/hugs-bugs > >

1 0

Bug?
by med018509＠nacom.es 15 Jan '01

15 Jan '01

Hi. I'm a computer engineering student and use with Hugs98, which helps me a lot in learning fuctional programming. I've noticed that the WinHugs application eats 100% of the available CPU even when it isn't doing any work, just blinking the cursor!!! I use CPUIddle to cool-down my processor and I saw a noticeable increase in CPU temperature whenever WinHugs was opened, although out of focus and without any task running. This is not a major problem, but if it could be solved easily, overclocked CPUs would not crash under WinHugs and batteries in LapTops would last longer. Thanks !!!!!!!!! Roberto Barrios, Facultad de Informática, Universidad Complutense de Madrid

3 2

RE: Yet more on functional dependencies
by Mark P Jones 15 Jan '01

15 Jan '01

| I am finding functional dependencies confusing. (I suspect I am | not alone.) Should the following code work? | | class HasConverter a b | a -> b where | convert :: a -> b | | instance (HasConverter a b,Show b) => Show a where | show value = show (convert value) It's a separate issue. There's no reason why a system using functional dependencies *should* support this. But it is an attractive and useful extension that such a system would probably *want* to include. (i.e., it's a desirable feature, not a requirement.) I typed your example into Hugs on my machine and it seemed to accept the syntax (which suggests that the implementation is intended to allow this kind of thing). But then it choked on the definition with a curious error message that I suspect is an indication of a bug in Hugs' treatment of functional dependencies. And, for that reason, I'm crossposting this message to hugs-bugs. [Let me take the opportunity to remind good readers of these lists that it is now more than a year since I retired from the joys of maintaining Hugs, so I'm not planning to try and track down the source of this bug myself!] Of course, it could be that my version of Hugs is out of date! All the best, Mark

2 1

hugs compilation error on Debian woody
by William Lee Irwin III 10 Jan '01

10 Jan '01

In file included from builtin.c:1431: iomonad.c: In function `primHGetPosn': iomonad.c:715: aggregate value used where an integer was expected iomonad.c: In function `primHSetPosn': iomonad.c:730: invalid initializer iomonad.c:736: incompatible types in assignment is the error I'm encountering. It seems to be that the semantics of fgetpos and fsetpos in glibc have changed. What I've come up with is a hack, but it appears to restore hugs to a state where it can compile. A unified diff which appears to repair these errors follows: diff -urN --exclude=*.in --exclude=configure --exclude=*.h --exclude=hugs.* hugs98/src/iomonad.c hugs98-98.200002/src/iomonad.c --- hugs98/src/iomonad.c Tue Feb 29 02:29:00 2000 +++ hugs98-98.200002/src/iomonad.c Wed Jan 10 19:10:05 2001 @@ -709,7 +709,7 @@ Int h; HandleArg(h,3); if (handles[h].hmode!=HCLOSED) { -#if HAVE_FGETPOS +#if HAVE_FGETPOS && !defined(__linux__) fpos_t pos; if (fgetpos(handles[h].hfp,&pos)) { IOReturn(mkInt((Int)pos)); @@ -726,7 +726,7 @@ } primFun(primHSetPosn) { /* Set file position */ -#if HAVE_FSETPOS +#if HAVE_FSETPOS && !defined(__linux__) fpos_t pos = 0; #elif HAVE_FSEEK long pos = 0; @@ -735,7 +735,7 @@ HandleArg(h,3); IntArg(pos,4); if (handles[h].hmode!=HCLOSED) { -#if HAVE_FSETPOS +#if HAVE_FSETPOS && !defined(__linux__) if (fsetpos(handles[h].hfp,&pos)) { IOReturn(nameUnit); }

1 0

Re: No runhugs for Macintosh?
by Jussi Piitulainen 09 Jan '01

09 Jan '01

Hans Aberg <haberg(a)matematik.su.se> writes: > At 18:00 +0200 1-01-08, Jussi Piitulainen wrote: >> I would like to run a completed program without the need to talk to >> it: just click a script that launches Hugs with one program after >> another, and I'd go away for a while or at [...] > There is an experimental MacHugs implementation that can accept and > send arbitrary AppleEvent's. This sounds very good. [...] > This MacHugs version is experimental, because the Hugs kernel isn't > thread safe, so if it receives several ApppleEvent's to be executed > in parallel or while it is already computing something, something > might break. In your case, I think it would work OK, but know you > know of it. Is it otherwise stable? It seems like it should be sufficient. I'd only need to send it one event - gotta learn about that anyway, but an example or two would be nice - and perhaps there's a way for the sender to wait for the recipient to finish or something. > If you want, I can send you the sources or a binary (but you will > have to do the AppleScript programming yourself). Can I have a binary, please, and I'll struggle with AppleScript by myself. I've already been able to start Hugs from a script. This is an iMac, I have Stuffit Expander, mail comes to a Unix machine, and I'm a bit confused but usually lucky about moving things between here and there. Thanks a lot, -- Jussi

2 1

No runhugs for Macintosh?
by Jussi Piitulainen 08 Jan '01

08 Jan '01

Hello, not really a bug, but either there is an omission on a Macintosh, or I failed to find the way. I would like to run a completed program without the need to talk to it: just click a script that launches Hugs with one program after another, and I'd go away for a while or at least take my fingers off the keyboard and mouse. There doesn't seem to be an option to run a main function automatically. When I open Hugs with Control or Command, I can tell it to read its standard input from a file, which would be fine, if I didn't need to be in the loop myself. A separate application like the runhugs in unixen might be best. An option to run a main function or to read commands from a file might be second best. Well, the best would be to learn that I just overlooked something and it can already be done. Help? By the way <http://www.haskell.org/implementations> still doesn't mention Macintosh. -- Jussi

2 1

Re: GHC/Happy on MacOS X/Darwin
by Hans Aberg 03 Jan '01

03 Jan '01

[Replies please cc me or the hugs-bugs list, as I currently is not on the Haskell list.] At 11:05 +0100 1-01-03, Atze Dijkstra wrote: >On http://www.cs.uu.nl/~atze/Programming/index.html a version of ghc >(4.08.1) and happy (still 1.8) for MacOS X/Darwin can be downloaded. >However, a few remarks do apply: this version of ghc is not a completely >ported version but built with generic settings and meant as a >bootstrapping compiler. It also is distributed as binaries for a specific >location (/usr/local/{ghc,happy}) in the UNIX directory structure. The >main reasons for distributing it in this unfinished form are: >- The MacOS X cc (c compiler) has some (blocking) bugs (for example, >problems with asm statements) which hinder progress. Isn't this related to the "munging" that GHC makes use of on other platforms? >- I consider 'unfinished' availability now of greater importance than >'perfect' availability later, so people can play with it. >- The compiler seems to run ok, that is, after minimal testing (compiling >ghc libraries and a local AG + parsercombinator system). Otherwise it sounds great: As no-one before has been able to port anything of GHC to MacOS (as far as I know), any kind of progress is important. (I do not have access to MacOS X right now, so unfortunatley I cannot try out your port.) Hans Aberg

2 2