March 2001 - Hugs-Bugs

Hugs 2001 release running under Windows 2000
by Jamie Stevenson 01 Mar '01

01 Mar '01

Hello I am trying to run Hugs Feb 2001 release under Windows 2000. File system is NTFS. Hugs is sitting in its own folder (Hugs98) on the my c drive. Can't run it - if you can give me any comments I would be greatly appreciative. e-mail: stevensj(a)dcs.gla.ac.uk Many thanks Jamie Stevenson

1 0

Bug in Hugs 98 MacOS Feb-2001: Crash while Compiling Multiple-Argument Fundep
by Ashley Yakeley 01 Mar '01

01 Mar '01

Product: Hugs 98 MacOS Feb-2001 Hugs Preferences: -98 -h1000000 To Repro: attempt to load a file with this line: class C a b c | a,b -> c where Results: Hugs 98 crashes with a "Type 2 Error" Expected: Is this valid extended Haskell? Compile it or give an error. -- Ashley Yakeley, Seattle WA

1 0

RE: Feb2001 hugs98 on MacOS
by Hans Aberg 01 Mar '01

01 Mar '01

At 02:41 -0800 2001/03/01, Julian Seward (Intl Vendor) wrote: >I tend to sympathise with Alastair/Johan. For us, keeping GHC >working on one platform is not too difficult. Trying to ensure >that it keeps going on all supported platforms without inordinate >amounts of effort, is IMO easily the biggest engineering challenge >we face. Well, as the MacOS implementation, it was developed in small chunks at need, but the Hugs team seemed to not bother to put it in for the last few years. Thus, they now have a large backlog. The MacOS intrusions are not that big: The MacOS (pre-X) is distinctively different from any other platform in that it does not have a shell, and that forces the need of hooks. The MacOS does not provide stack-checks, so that has to be implemented by intrusion into the code. Nor does it have pre-emptive multitasking, only cooperative, which means that one must intrude into the code to release time to other programs. Etc. As Alan said, these things ought really to be a part of the Hugs distribution, as they might be of importance to other platforms. In fact, some of the MacOS stuff was implemented by riding on the code intrusions already made for the MS Windows. It seems me that Johan Nordlander, the first person for a few years bothering about this Mac stuff at all, is new to it, so he has picked out everything that he does not immediately understand. However, he then pretty much breaks everything that makes the MacOS version useful. To fix it up on the course he lays out will take up a lot of time, as Mac programming is very time consuming. (Kevin Hammond spend more time on the Mac GUI than what spent on the Hugs kernel at that time!) On the other hand, there is now a MacOS X, which has existed half-a-year in a beta, and gets public by the end of March. MacOS X does have pre-emptive multitasking, stack-checks, threading (it is built up around a Mach 3 kernel), and the other stuff expected of a modern OS plus some. So much of that special pre-MacOS X will not be needed. So, on the one hand, Johan Nordlander at this late date lays out an extremely time-consuming course for himself, hoping others to join, while on the same time, it looks it is not worth spending any time at it at all as far as pre-MacOS X implementation goes. Some of the stuff may survive if there still are cooperative multitasking platforms under which Hugs may run. Hans Aberg

1 0

RE: Feb2001 hugs98 on MacOS
by Julian Seward (Intl Vendor) 01 Mar '01

01 Mar '01

| Some advice to people submitting changes: | | Back in the days when I was maintaining Hugs, changes were substantially more | likely to be merged into the main base if they were decomposed into a number of | small, independent changes whose impact and consequences could be understood in | isolation from the other changes. The same issue crops up from time to time for the Linux kernel development community, wherein the keepers of the kernel (Torvalds, Cox, et al) are much more likely to accept patches in the form Alastair describes, precisely for the reason he mentions, and those whose large, all-encompassing patches are rejected get hot under the collar. Assimilation of large chunks of code implementing new subsystems (ie, the ReiserFS file system) is slow indeed. So this is not by any means a new problem. I tend to sympathise with Alastair/Johan. For us, keeping GHC working on one platform is not too difficult. Trying to ensure that it keeps going on all supported platforms without inordinate amounts of effort, is IMO easily the biggest engineering challenge we face. </red-herring> J

1 0

AW: "Compiled code too complex" error message - Problem solved.
by Laaser Christian 01 Mar '01

01 Mar '01

Thank you very much for your message. I think the new Feb 2001 distribution doesn't use the large version. Look at the code extract from options.h: #define SMALL_HUGS 0 #define REGULAR_HUGS 0 #define LARGE_HUGS 0 If I understand it correctly LARGE_HUGS should normally be defined as 1 so that the large version is used by default. I can confirm that changing NUM_FIXUPS to 1000 solves my problem because I used Feb 2001 distribution with the modified hugs.exe Karl M. Syring sent me and the interpreter is working fine. Christian > -----Urspr> üngliche Nachricht----- > Von: Alastair Reid [SMTP:reid@cs.utah.edu] > Gesendet am: Montag, 26. Februar 2001 18:22 > An: Laaser Christian; 'Mark P Jones' > Cc: hugs-bugs(a)haskell.org; kort(a)wins.uva.nl; Lescher Christian > Betreff: RE: AW: What does "Compiled code too complex" error message of Hugs mean? > > Laaser Christian writes: > > > 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". > > Almost every machine in existence uses the large version so I'm a bit surprised > by this report. Can you confirm: > > a) That your machine _does not_ use the large version. > (Look at the values of SMALL_HUGS, REGULAR_HUGS and LARGE_HUGS in > hugs98/src/options.h) > > b) That changing NUM_FIXUPS to 1000 fixes your problem. > > If you are indeed using the regular version, is there any reason why you can't > use the large version? > > -- > Alastair Reid

1 0