February 2001 - Hugs-Bugs

OSX
by Michel Schellekens 25 Oct '02

25 Oct '02

After downloading the OSX version, and typing "hugs" to start up the language, I obtain the following error: [schellekens:~] mpcs% hugs dyld: hugs can't open library: /usr/lib/libncurses.5.dylib (No such file or directory, errno = 2) Any suggestions? Michel.

2 1

Feb2001 hugs98 on MacOS
by Richard A. O'Keefe 04 Mar '01

04 Mar '01

The February 2001 release of Hugs 98 unpacked fine and seems to run fine on my PowerMac 7600/120 running Mac OS 8.6 HOWEVER, the characters in the console window are teeny tiny wee characters indeed. What are they, 8 point? I could live with 10 point, but would personally rather have 12 point. So what do I do to change the size of the text in this window? I poked around in the sources, and discovered that the window is a SIOUX console. It appears that Hugs does not set any SIOUX options to control the text size, but I may have missed something. I wanted to try setting SIOUXSettings.fontsize = 12; but unfortunately I have CW Pro 2, not CW Pro 5, so cannot use the XML project file provided, and no instructions for using CW Pro 2 were included. I would strongly recommend adding a "-fontsize" command line option that can be put in the Hugs Preferences file. Come to think of it, a -fontface option so that I can get 'courier' instead of 'monaco' would be nice too.

4 11

RE: please confirm that this is a feature
by Simon Peyton-Jones 01 Mar '01

01 Mar '01

GHC infers the type g :: (Foo [[a]] [b], Foo [[b]] [a]) => [a] -> [b] -> Int As you imply, if GHC used the instance decl to simplify the first constraint to Foo [a] b, for example, then the functional dependency would kick in, and there would be an infinite loop. But GHC's constraint simplification is (now) lazy, unless forced to be eager by supplying a type signature. I think Hugs is the same, and I think that's probably why it terminates. Interesting example! Simon | -----Original Message----- | From: Dominic Duggan [mailto:dduggan@cs.stevens-tech.edu] | Sent: 28 February 2001 16:00 | To: hugs-bugs(a)haskell.org | Subject: please confirm that this is a feature | | | I am finishing up revisions on a paper that | has been accepted to JFP, on type-checking | with multi-parameter type classes. | With the following definitions: | | | class Foo a b | a -> b where foo :: a -> b -> Int | | | | instance Foo Int Float where foo x y = 0 | | | | instance Foo a b => Foo [a] [b] where foo [x] [y] = foo x y | | | | g x y = (foo [x] y) + (foo [y] x) | | In our system type-checking fails to terminate when | type-checking "g", but Hugs 98 (Feb 2001) returns | a type. | | I assume that this is because of a depth bound in the | type-checker, can you confirm this before I submit | the final version of the paper? | | Thanks | --dd |

1 0

please confirm that this is a feature
by Dominic Duggan 01 Mar '01

01 Mar '01

I am finishing up revisions on a paper that has been accepted to JFP, on type-checking with multi-parameter type classes. With the following definitions: | class Foo a b | a -> b where foo :: a -> b -> Int | | instance Foo Int Float where foo x y = 0 | | instance Foo a b => Foo [a] [b] where foo [x] [y] = foo x y | | g x y = (foo [x] y) + (foo [y] x) In our system type-checking fails to terminate when type-checking "g", but Hugs 98 (Feb 2001) returns a type. I assume that this is because of a depth bound in the type-checker, can you confirm this before I submit the final version of the paper? Thanks --dd

1 0

Bug in Hugs 98 MacOS Feb-2001: Can't drop files on application
by Ashley Yakeley 28 Feb '01

28 Feb '01

Product: Hugs 98 MacOS Feb-2001 To Repro: In the Finder, drop a haskell source file on the "Hugs 98" application. Results: Hugs 98 launches, but doesn't read source file. Expected: Hugs 98 to launch, read source file. The worked OK in previous versions of Hugs 98 (although you couldn't drop source files on an already-running app). -- Ashley Yakeley, Seattle WA

1 0

floating literals rounded too soon
by Scott Turner 28 Feb '01

28 Feb '01

With the Feb 2001 Hugs, 0.1 :: Rational evaluates to 13421773 % 134217728 rather than 1 % 10 which would be more useful and portable. -- Scott Turner p.turner(a)computer.org http://www.billygoat.org/pkturner

1 0

hugs & text editor
by Martin Raubal 27 Feb '01

27 Feb '01

Hi there! We have the following problem with the Feb. 2001 version of Hugs: When having an error and linking Hugs with a text editor, such as UEdit, it used to be the case that the cursor in the text editor is automatically set to the line of the error. This does not work with the new version, the cursor is always at the beginning and one needs to search for the line given in Hugs. Any help? cheers, martin Dipl.-Ing. Martin Raubal Institute for Geoinformation TU Vienna Gusshausstr. 27-29, A-1040 Vienna Tel. (+43 1) 588 01-12716 Fax (+ 43 1) 588 01-12799 http://www.geoinfo.tuwien.ac.at/persons/raubal/raubal.html

2 1

AW: AW: What does "Compiled code too complex" error message of Hu gs mean?
by Laaser Christian 27 Feb '01

27 Feb '01

I installed the new Feb 2001 distribution and I saw that NUM_FIXUPS with value 1000 is only possible for large version of hugs interpreter. It would be great if I could get this version because the standard interpreter only has a NUM_FIXUPS of 400 and so I get the error message "Compiled code too complex". Thank you very much. Christian > -----Urspr> üngliche Nachricht----- > Von: Mark P Jones [SMTP:mpj@cse.ogi.edu] > Gesendet am: Montag, 12. Februar 2001 20:07 > An: kort(a)wins.uva.nl; Laaser Christian > Cc: hugs-bugs(a)haskell.org > Betreff: RE: AW: What does "Compiled code too complex" error message of Hugs mean? > > I know this is more than a week old, but I've been away ... and > now that I'm back, I'd like to clear up a possible misunderstanding > that began with an exchange along the following lines: > > | > > When loading some Haskell files with Hugs, I get the error > | > > message "Compiled code too complex". However, the compilation > | > > with GHC 4.08.1 succeeds. > | > > What does this message mean? What can I do about it? > | ... > | > You can grep for that sentence in "hugs98/src", it will point to the > | > file "machine.c". There you will see it says "if nextLab>=NUM_FIXUPS) ...". > | > So grep for "NUM_FIXUPS" it will point to the file "prelude.h". I > | > think the default value is 400, you should increase it to 1000 or so. > | > I have it at 10000, but that's probably not necesary in your case > | > and if you increase constants too much starting up Hugs will become > | > slower. > > First of all, an explanation. Inside Hugs, the code for Haskell > functions is translated into a low-level, abstract machine language. > (In today's environment, the way that Java programs are translated > into JVM bytecode is probably a good analogy.) As the machine > language code is generated, the compiler sometimes needs to insert > "jump" instructions to addresses that are not yet known. In this > situation, it instead inserts a dummy address, but adds an entry to > a simple table of "fixups" that will later be filled in with the > correct address. Once the complete section of code has been generated, > Hugs scans over it once again and replaces each unknown address with > the correct value from the fixups table. This process is also quite > commonly described as "back-patching". > > The fixups table can contain at most NUM_FIXUPS entries, which, in the > current distribution, is set to 400. Programs that require more entries > than this in a single block of code will lead to the "Compiled code too > complex" error message that you have seen. There is not particular > reason for the choice of 400; this is just a number that seemed to work > ok for most practical purposes. If you get a compiled code too complex > message, it is perhaps a sign that you would benefit from looking at > ways to break your code down into smaller, simpler, and more > understandable pieces. More likely, however, you will see this error > with code that was generated automatically, in response to a "deriving" > request on a datatype, or by a tool like a parser generator. In this > case, changing the Haskell code that is generated is not an option. > > Increasing the standard setting for NUM_FIXUPS is certainly an option > here. You would have to increase it a great deal for there to be any > impact on the speed with which Hugs starts. In comparison to the > standard heap sizes that people use, the fixups table is a drop in the > ocean. I think Johan has already increased the size for the Feb 2001 > distribution that will be out in a couple of days. > > The fixups table could be allocated dynamically, and expand on demand. > To understand why Hugs doesn't do it that way already, you need to go > back more than a decade to Gofer, the system from which Hugs was > derived, which was designed to work on an 8086 with segmented memory> > and a maximum of 640K. Back in those days, when loading the prelude > took 30 seconds (and it was much smaller then too!), a statically > allocated table made sense because it was slightly faster and because > there wasn't any spare memory for it to expand into anyway, even if > you went to the trouble of dynamically allocating it. > > Historical note: If you'd like to see the heart of the machine that > ran those original versions of Gofer, come visit me; it's sitting > here on the desk lamp in my office :-) > > All the best, > Mark

2 1

Lo mejor de Internet aqu�
by promocionesdosmiluno＠yahoo.es 26 Feb '01

26 Feb '01

Visita esta web http://MundoEspanya.redireccion.com

1 0

Buffer overrun bug in typeClassDefn() in type.c
by Julian Seward 25 Feb '01

25 Feb '01

Greetings, earthlings. Implausible as it seems, I believe I've found a buffer overrun in typeClassDefn() in type.c, in the latest (Feb 2001) Hugs. The problem happens under normal operation -- loading the Prelude is enough to make it happen. The problem occurs in the loop beginning for (; nonNull(mems); mems=tl(mems)) { Lines 2233 through 2239 are intended to assign to buf the value "default_" ++ textToStr(name(hd(mems)).text), so to speak. Unfortunately they only do this correctly on the first iteration of this loop, because i and j are set to zero at the start of the function, whereas they should be zeroed at the start of each trip round the loop. To show that something is way wrong, try putting printf("buf is `%s'\n", buf) immediately after buf[i+j] = '\0'; and watch ever-longer junk strings being printed out. I propose adding simply i = j = 0; at line 2234. Hugs still seems to load the Prelude correctly, and, in addition, the buf printouts now seem correct. How could Hugs ever have worked with this bug? * The size of buf, FILENAME_MAX, is quite large. This loop processes default methods for classes; presumably you'd need a class with a lot of default methods before buf got extended beyond FILENAME_MAX ? * The string generated into buf[] is hashed, and that hash value is used, indirectly, as a unique name for the default method, so it doesn't actually matter that the wrong-ish string has been hashed. J

1 0