- Hugs-Bugs - Haskell.org

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 27 Feb '01

27 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 26 Feb '01

26 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 25 Feb '01

25 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

Reading numbers technicality
by George Russell 23 Feb '01

23 Feb '01

I think main = putStrLn(show ((reads "123.")::[(Int,String)])) should print [(123,".")] rather than [] as it does in Hugs (Feb2001). As far as I can work out, from the rather tangled Haskell code in the Prelude, Hugs is at fault, not the Prelude. Glasgow Haskell 4.08.2 agrees with me. Please cc replies to me, as I don't subscribe to this group.

1 0

":load System" in mac version of Hugs Feb 2001
by Kristofer Johannisson 23 Feb '01

23 Feb '01

Hi, the macintosh version of Hugs 98 February 2001 gives me an error when I type ":load System": ----- Prelude> :load System Reading file "System": Parsing ERROR System:1 - Syntax error in declaration (unexpected symbol "d1") ------ Note that it works OK if you type ":load System.hs": ------- Prelude> :load System.hs Reading file "Macintosh HD:Applications (Mac OS 9):hugs98:lib:System.hs": Hugs session for: Macintosh HD:Applications (Mac OS 9):hugs98:lib:Prelude.hs Macintosh HD:Applications (Mac OS 9):hugs98:lib:System.hs -------- You can load other standard things without the ".hs", for instance: -------- List> :load List Reading file "Macintosh HD:Applications (Mac OS 9):hugs98:lib:List.hs": Reading file "Macintosh HD:Applications (Mac OS 9):hugs98:lib:Maybe.hs": Reading file "Macintosh HD:Applications (Mac OS 9):hugs98:lib:List.hs": Hugs session for: Macintosh HD:Applications (Mac OS 9):hugs98:lib:Prelude.hs Macintosh HD:Applications (Mac OS 9):hugs98:lib:Maybe.hs Macintosh HD:Applications (Mac OS 9):hugs98:lib:List.hs ------- / Kristofer Johannisson

2 1

problems after compiling hugs
by Sebastian Schulz 21 Feb '01

21 Feb '01

Hi there! I've just downloaded the sourcepackage of the Feb2001 version. I need to change the NUM_INSTS variable in the <prelude.h> file, so I did it before running the ./configure script (in src/unix/ , I'm using SuseLinux 7.1). After running the script and installing with "make install" hugs startet without problems, BUT: there is no commandline history!! When typing the up-arrow, there appear only cryptic characters on the sreen. What is missing? I've attached the outprint of the ./configure script, not seeing where the problem is... thanks sebastian bash-2.04# ./configure creating cache ./config.cache checking for bison... bison -y checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking how to run the C preprocessor... gcc -E checking for perl... perl checking whether make sets ${MAKE}... yes checking for hp2ps... 1 checking for diff... /usr/bin/diff checking whether to use diff -c1 or diff -C 1... /usr/bin/diff -C 1 checking for function_dlopen... no checking for library_dl... yes checking for function_shl_load... no checking for library_dld... no checking for function_atan... no checking for library_m... yes checking for ANSI C header files... yes checking for sys/wait.h that is POSIX.1 compatible... yes checking for stdarg.h... yes checking for stdlib.h... yes checking for unistd.h... yes checking for assert.h... yes checking for ctype.h... yes checking for string.h... yes checking for fcntl.h... yes checking for sgtty.h... yes checking for termio.h... yes checking for termios.h... yes checking for signal.h... yes checking for sys/stat.h... yes checking for sys/types.h... yes checking for sys/ioctl.h... yes checking for sys/resource.h... yes checking for sys/param.h... yes checking for console.h... no checking for pascal.h... no checking for Files.h... no checking for errno.h... yes checking for stat.h... no checking for nlist.h... no checking for ftw.h... yes checking whether time.h and sys/time.h may both be included... yes checking for time.h... yes checking for sys/time.h... yes checking for float.h... yes checking for values.h... yes checking for dos.h... no checking for conio.h... no checking for io.h... no checking for std.h... no checking for windows.h... no checking for dlfcn.h... yes checking for dl.h... no checking for alloc.h... no checking for malloc.h... yes checking for valloc... yes checking for strcasecmp... yes checking for _stricmp... no checking for stricmp... no checking for strcmpi... no checking for strcmp... yes checking for realpath... yes checking for _fullpath... no checking for PBHSetVolSync... no checking for macsystem... no checking for fgetpos... yes checking for fsetpos... yes checking for fseek... yes checking for ftell... yes checking for vsnprintf... yes checking for _vsnprintf... no checking for snprintf... yes checking for _snprintf... no checking for popen... yes checking for _popen... no checking for pclose... yes checking for _pclose... no checking for sigprocmask... yes checking for working alloca.h... yes checking for alloca... yes checking for _alloca... no checking for stime... yes checking for poly... no checking for working const... yes checking prototypes... yes checking for arrays of jmp_bufs... yes checking labels as values... yes checking whether struct tm is in sys/time.h or time.h... time.h checking return type of signal handlers... void checking whether gcc needs -traditional... no checking for a leading underscore in symbol names checking for ld... ld checking size of int... 4 checking size of float... 4 checking size of double... 8 checking size of int*... 4 building large hugs updating cache ./config.cache creating ./config.status creating ../Makefile creating ../../docs/Makefile creating ../../docs/hugs.1 creating ../config.h creating ../options.h ************************************************ *** NOW DO: cd .. followed by make install ************************************************ bash-2.04# cd .. bash-2.04# make install gcc -c -g -O2 hugs.c gcc -c -g -O2 storage.c gcc -c -g -O2 input.c gcc -c -g static.c gcc -c -g type.c gcc -c -g -O2 subst.c gcc -c -g compiler.c gcc -c -g -O2 plugin.c gcc -c -g -O2 builtin.c gcc -c -g -O2 machine.c gcc -c -g -O2 output.c gcc -c -g -O2 ffi.c gcc hugs.o storage.o input.o static.o type.o subst.o compiler.o plugin.o builtin.o machine.o output.o ffi.o -lm -ldl -o hugs gcc -c -g -O2 runhugs.c gcc -c -g -O2 server.c gcc runhugs.o server.o storage.o input.o static.o type.o subst.o compiler.o plugin.o builtin.o machine.o output.o ffi.o -lm -ldl -o runhugs unix/install-sh -d /usr/local/bin unix/install-sh hugs /usr/local/bin unix/install-sh runhugs /usr/local/bin unix/install-sh -d /usr/local/share/hugs/lib /bin/cp ../lib/*.* /usr/local/share/hugs/lib unix/install-sh -d /usr/local/share/hugs/lib/hugs /bin/cp ../lib/hugs/*.* /usr/local/share/hugs/lib/hugs unix/install-sh -d /usr/local/share/hugs/lib/exts /bin/cp ../lib/exts/*.* /usr/local/share/hugs/lib/exts unix/install-sh -d /usr/local/share/hugs/demos unix/install-sh -d /usr/local/share/hugs/demos/prolog /bin/cp ../demos/*.* /usr/local/share/hugs/demos /bin/cp ../demos/prolog/*.* /usr/local/share/hugs/demos/prolog /bin/cp ../demos/prolog/readme /usr/local/share/hugs/demos/prolog /bin/cp ../demos/prolog/stdlib /usr/local/share/hugs/demos/prolog unix/install-sh -d /usr/local/man/man1 /bin/cp ../docs/hugs.1 /usr/local/man/man1

2 1

Corrupted files?
by Paul Johnson 20 Feb '01

20 Feb '01

I've been trying to download and install Hugs 98. However the .msi and .hlp files are reported as corrupt. I'm downloading using Netscape 4.7 and installing on NT 4 SR 6 using the installer version 1.2 that you point to for installing .msi files. Paul. -- Paul Johnson | Marconi plc is not responsible for my opinions. | +44 1245 242244 +-----------+-----------------------------------------+ Work: <paul.johnson(a)marconi.com> | You are lost in a twisty maze of little Home: <Paul(a)treetop.demon.co.uk> | standards, all different.

2 2