March 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

Re: Fran and HGL broken with Feb 2001 Hugs
by C.Reinke 02 Apr '01

02 Apr '01

Alastair wrote: > As you and others have found, my HGL and Conal's Fran both depend on internal > details of Hugs which were changed in the latest release. Dear all (and especially Hugs maintainers), it is not too nice if libraries have to depend on internal details of the Hugs distribution, but I assume they wouldn't if their author's had known any way around this. And, given that several very popular libraries were affected seriously by the latest release of Hugs, may I suggest that those libraries are added to the test-suite for Hugs? It is just too risky to hope that all library authors will test their (in some cases several years old) libraries whenever any of the Haskell implementations gets updated, so this would better be automated (as, I believe, it is for GHC). It cannot be the task of the Hugs maintainers to fix the libraries in the test suite if they break due to a change to Hugs internals (*), but neither should a new release of Hugs come out with all those widely used libraries broken. In other words, new releases of Hugs could be tested against the suite and any problems encountered could be fixed "behind the scenes" before the releases reach the general public. In the worst case, if no easy fixes can be found, a decision would have to be made between breaking all those popular libraries and not introducing some potentially useful new features. In case anyone wonders: here in Canterbury, as soon as the first of us found only one of those libraries broken, a warning went round not to use the new Hugs for the time being, and that early adopter had to try and restore his old Hugs environment..(**) No-one here is using the new release! And I know of other fp places following the same cautious approach, waiting for the situation to stabilize instead of risking their research and teaching (!!!) environments. Just some thoughts of a Hugs+libraries fan, Claus (*) Btw, what was the rationale for that change? Was it really necessary? (**) no, it wasn't me, but I agree. I needed to have a look at the new built-in Observe stuff, and I had been hoping for the new FFI stuff, but not at the risk of so seriously upsetting my Hugs enviroment, so I only downloaded the source release and kept my old Hugs installation.

3 2

Fran broken with Feb 2001 Hugs
by Conal Elliott 02 Apr '01

02 Apr '01

Hi Sean. Some bad news. The Feb'01 Hugs release has a representation change for IO, breaking Fran's Compatibility.safeTry, which I had copied from Alastair Reid's graphics library. I noticed that the graphics library is broken for the same reason. I worked around that problem, but then I get "Program error: no more threads (deadlock?)" on even the most trivial Fran example. That kind of error is usually very hard to track down. Hugs-bugsers: any guesses about the thread deadlock problem? Also, as a possible temp solution for Sean, is the previous version of Hugs still available somewhere? Thanks, - Conal

3 2

Windows registry handling / hugs CVS repository?
by Antony Courtney 02 Apr '01

02 Apr '01

Hi, I think that the way hugs uses the registry under Windows is dangerous and buggy. This message describes the problems and proposes some alternative designs. I welcome comments and suggestions. "dangerous": In the current design, any options changes made interactively using ":set" from the hugs prompt are ALWAYS saved immediately to the registry. This is all well and good when the user actually made an intended change, but it is an brutally unforgiving of mistakes. Consider the common scenario of someone attempting to add a component to the search path using something like: Prelude> :set -Pc:\my\lib\path Ooops! The user forgot to include a ';' in the search path to append or prepend this path to the existing search path. Thanks to the automatic save-to-registry "feature", there is no way to undo this change. Even if the user quits and restarts hugs, the search path will only contain this one component. The original hugs default search path, as well as any changes made to the search path since hugs was installed on the system, are now GONE FOREVER! In fact, the only way I know of to recover the default search path is to re-install hugs from scratch. "buggy": During a desperate last minute demo preparation recently (for Paul Hudak's class), I had to append a few things to my search path using something like: Prelude> :set -P;c:\some\big\long\hairy\path At some point, I crossed some small magic size limit, and *poof!*: next time I started hugs, all of my path changes since hugs had been installed silently disappeared, and the path reverted to the system default path! If you want to see this bug yourself, simply run the above command a bunch of times (maybe 6 to 10), restart hugs, and do a ":set" to see the bogus value for path. I did a little digging around in the code (from Feb2001 release of hugs), and found the following First, in hugs.c, the implementation of optionsToStr() looks like this: static String local optionsToStr() { static char buffer[2000]; (...bunch of code to add things to buffer, with no buffer overrun checks...) return buffer; } Then, in machdep.c, we have: static Sting local readRegString(...) ... { #if HUGS_FOR_WINDOWS static char buf[2048]; #else static char buf[300]; #endif if (queryValue(...buf, sizeof(buf)) == REG_SZ) { /* success */ return buf; } else { return def; /* system default option settings */ } } Here is my short list of bugs in the above code: 1. Fixed size buffers are a dangerous practice. If you must use them, at least make sure they are large enough to hold the largest conceivable value and then some. In this case, 2048 bytes is a reasonable size; 300 is not. It turns out that the HUGS_FOR_WINDOWS preprocessor symbol is only defined when building the rarely used Windows GUI for hugs, not the ordinary Windows version. I *STRONGLY RECOMMEND* just getting rid of the #if..#endif, and using the larger buffer size. I'm fairly certain this is the cause of the bug I noted above. 2. It's unfortunate that the code in the first function doesn't check for buffer overruns, but at least a 2000 byte buffer is (somewhat) reasonable. 3. Both of these functions return a pointer to automatic (i.e. stack allocated) variables. This is a classic dangling pointer bug, and the behavior of such a program is undefined according to the ANSI C standard. (IF you happen not to have any function calls between where the pointer is returned and where the pointer is used in the calling code, and IF your compiler happens to implement automatic variables using a stack, then you might "get lucky" and your program might behave as intended, but there is no guarantee this will work.) A simple solution is to allocate the buffer in the caller's stack frame and pass a pointer to the callee. ----- My radical alternative design proposal: - Do NOT automatically save settings to the Windows registry. I hope the "dangerous" paragraph above is enough to convince anyone that this is just a bad idea. - As a convenience, after reading HUGSFLAGS from the environment, also read an environment variable HUGSPATH. Allow empty path components to be used to specify the current path (to prepend / append), as we do now. If absolutely necessary, we could provide a ":regsave" command to allow the user to explicitly save changes made to hugs options to the registry. Personally, I don't think this is necessary, but I'd be happy to hear others' opinions. I welcome comments / discussion on this proposal. Using environment variables for such settings is cross-platform, well understood, reasonably standard, and avoids the dangers of this automatic save-to-registry. I volunteer to implement the above changes, if someone would be so kind as to point me towards the hugs CVS repository. -antony -- Antony Courtney Grad. Student, Dept. of Computer Science, Yale University antony(a)apocalypse.org http://www.apocalypse.org/pub/u/antony

2 1

BUGGGGGGGGGGGGGGGGGGGGGGGGGG
by Muhammad Bilal 30 Mar '01

30 Mar '01

HI I HAVE FOUND A NEW BUG IN THE HASKELL THAT IS WE HAVE HEARED THAT THE APPENDER IS OF TWO EQUAL ORDER LIST I-e [[2,3]] ++ [[2,3]] [[2,3]] ++ [[]] BUT NOW ACCORDING TO OUR ASSIGNMENT WE HAVE TO MADE THE CARTESIAN PRODUCT AND I FIND THAT IT IS ALSO WORKING IN APPENDING. from my point of view IT IS A BUG IN HASKELL ACCORDING TO MY LIMITED INFORMATION. PLZ SOLVE THIS [] ++ [[1,2]] [[2,3]] ++ [] BUT WHEN WE PUT THE FULL LIST INSTEAD OF EMPTY THEN IT GIVES THE ERROR BUT IT SHOULD BE POSSIBLE TO GIVE ERROR IN EMPTY LIST. SALAM MUHAMMED BILAL bilalnz(a)yahoo.com

1 0

Re: Parsing error
by Sigbjorn Finne 29 Mar '01

29 Mar '01

Ralf Hinze ralf(a)cs.uu.nl writes: > > the version of hugs in the repository stumbles over the following > program (which the february 2001 version compiles without problems): > .... > > instance Num Dir where > > a + b = toEnum (fromEnum a + fromEnum b) > > a - b = toEnum (fromEnum a - fromEnum b) > > > Parsing > ERROR error.lhs:6 - Syntax error in declaration (unexpected `-') Sorry, my fault - the use of infix (-) was wrongly disallowed as part of the patch which permitted the use of qualified method names in instance decls. My proposed fix is to add the following rule to parser.y qvarop_mipl : QVAROP {$$ = $1;} | '-' {$$ = gc1(varMinus);} | '`' QVARID '`' {$$ = gc3($2);} | varop_mi {$$ = $1;} ; and change the last alternative for the rule 'qfunlhs0' from | var qvarop_mi pat0 {$$ = gc3(ap2($2,$1,$3));} to | var qvarop_mipl pat0 {$$ = gc3(ap2($2,$1,$3));} Many thanks for reporting this, you can get the above code to work if you parenthesise the operator (which is what the Hugs Prelude consistently does, which is why this didn't show up before now.) --sigbjorn

1 0

Parsing error
by Ralf Hinze 29 Mar '01

29 Mar '01

Dear Hugs maintainers, the version of hugs in the repository stumbles over the following program (which the february 2001 version compiles without problems): > data Dir = C | N | NE | E | SE | S | SW | W | NW > deriving (Eq, Read, Show, Enum, Ord) > instance Num Dir where > a + b = toEnum (fromEnum a + fromEnum b) > a - b = toEnum (fromEnum a - fromEnum b) Parsing ERROR error.lhs:6 - Syntax error in declaration (unexpected `-') Just to let you know ... Cheers, Ralf

1 0

Link Exchange !
by Sharonne 27 Mar '01

27 Mar '01

Hi I came across your site and liked your site very much. Incidentally I have a greeting cards site at : http://www.gcards.com/hugsnkiss/index.html Virtual Hugs and Kiss Cards at Gcards.com It would be great if you could exchange links. My button and banner is located at :- http://www.gcards.com/banner/index.html You can also cut and paste the HTML code given below for a small button to appear on your page. With best wishes Sharonne http://www.gcards.com Send a Card in a Flash!!! ========= HTML CODE ============ <div align="center"> <a href="http://www.gcards.com/hugsnkiss/index.html"> <img src="http://www.gcards.com/banner/button1.gif" width="88" height="31" alt="Click to send Gcards to say YOU CARE !" border="0"> </a> </div> ========= HTML CODE ============

1 0

Link Exchange !
by Sharonne 27 Mar '01

27 Mar '01

Hi I came across your site and liked your site very much. Incidentally I have a greeting cards site at : http://www.gcards.com/hugsnkiss/index.html Virtual Hugs and Kiss Cards at Gcards.com It would be great if you could exchange links. My button and banner is located at :- http://www.gcards.com/banner/index.html You can also cut and paste the HTML code given below for a small button to appear on your page. With best wishes Sharonne http://www.gcards.com Send a Card in a Flash!!! ========= HTML CODE ============ <div align="center"> <a href="http://www.gcards.com/hugsnkiss/index.html"> <img src="http://www.gcards.com/banner/button1.gif" width="88" height="31" alt="Click to send Gcards to say YOU CARE !" border="0"> </a> </div> ========= HTML CODE ============

1 0

Link Exchange !
by Sharonne 27 Mar '01

27 Mar '01

Hi I came across your site and liked your site very much. Incidentally I have a greeting cards site at : http://www.gcards.com/hugsnkiss/index.html Virtual Hugs and Kiss Cards at Gcards.com It would be great if you could exchange links. My button and banner is located at :- http://www.gcards.com/banner/index.html You can also cut and paste the HTML code given below for a small button to appear on your page. With best wishes Sharonne http://www.gcards.com Send a Card in a Flash!!! ========= HTML CODE ============ <div align="center"> <a href="http://www.gcards.com/hugsnkiss/index.html"> <img src="http://www.gcards.com/banner/button1.gif" width="88" height="31" alt="Click to send Gcards to say YOU CARE !" border="0"> </a> </div> ========= HTML CODE ============

1 0