- Hugs-Bugs - Haskell.org

Re: toUpper Bug?
by Alastair David Reid 16 Aug '01

16 Aug '01

Unfortunately, I think there's only one person whose _part time_ job is to maintain Hugs - and that person was on vacation in the last few weeks. [Also, I think the money funding Hugs maintenance is due to run out soon.] The rest is all up to individual volunteers and companies like Galois Connections (who are sending a steady trickle of bugfixes into both Hugs and GHC). Maybe we need someone to setup a suitable bugtracking system? GHC's use of sourceforge looks ok - except that half their bug reports still seem to arrive as mail messages instead of as properly filled in bug report forms. Here at Utah, my project uses gnat but I got the impression that setting it up was a bit time consuming since its default configuration was for a different style of organisation from ours. Steinitz, Dominic J <Dominic.J.Steinitz(a)BritishAirways.com> writes: > Alastair, It's good to know someone is doing something with reported > bugs. toUpper being in the wrong library is a minor annoyance so it > doesn't sound like the effort of fixing it is worth it. The other > bug about not behaving properly for i with a circumflex is more > serious and I hope will be fixed. > I'd like to suggest that someone acknowledges receipt of bugs even > if it's just to say no-one has time to fix it at the moment but it's > been put in a list of things to fix and won't get forgotten about. -- Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/

1 0

Bug tracking [was toUpper Bug?]
by Johan Nordlander 16 Aug '01

16 Aug '01

Hi all, As a matter of fact, bugs are currently being fixed in a steady, perhaps even an increasing, tempo. But you're right that there should be some formal system that (1) acknowledges reported bugs, (2) makes it easy to determine who's working on a particular bug fix, and (3) clearly indicates which bugs have been fixed. I.e., what we need is a bug tracking system for Hugs. I've been investigating some alternatives for such a system recently, but haven't yet come to any firm conclusion. The ghc team has recently moved its repository to SourceForge, though, and one of the benefits with such an arrangement is that bug tracking can be handled using the SourceForge Tracking system. From what I've heard that system is really excellent. So I'm posing this question to the interested public: Is it time to consider moving Hugs to SourceForge too? -- Johan On Thursday, August 16, 2001, at 07:57 AM, Steinitz, Dominic J wrote: > Alastair, > > It's good to know someone is doing something with reported > bugs. toUpper being in the wrong library is a minor annoyance > so it doesn't sound like the effort of fixing it is worth it. > The other bug about not behaving properly for i with a > circumflex is more serious and I hope will be fixed. > > I'd like to suggest that someone acknowledges receipt of bugs > even if it's just to say no-one has time to fix it at the > moment but it's been put in a list of things to fix and won't > get forgotten about. > > Dominic. > > > > > > reid(a)cs.utah.edu on 15/08/2001 23:25:00 > To: Dominic Steinitz > cc: hugs-bugs > bcc: > Subject: Re: toUpper Bug? > > > [reply just sent to hugs-bugs] > >> Maybe if this one is going to be fixed, toUpper could be put in the >> correct library as well? > > I'm assuming this is a reference to the fact that toUpper is exported > both from Char (correct) and from Prelude (incorrect)? > > A quick check of Prelude.hs and hugs98/src/*.c reveals no good reason > why this code is in the Prelude. Perhaps some vague code tidiness > argument about keeping related code together? > > So, it could be fixed quite easily but there's a bunch of similar > deviations from the standard which are not easily fixed because the > Prelude (or some part of the Hugs compiler) depends on the function > which, with the current Hugs implementation, implies that there has to > be a copy in the Prelude. > > We don't want to make 2 copies of the same code though (one in the > Prelude but not exported, one in the correct place and exported) > because it leads to code maintenance problems. Suppose that toUpper > had a bug in it - it'd be so easy to fix one copy and forget about the > existence of the second. > > Another fix (the preferred fix) is to improve the Hugs compiler so > that the code can have (almost) the same structure as in the report. > We know how to do this (STG-Hugs had it) but it'll take a bit of time > to figure out again exactly which changes are required because the > special treatment of the Prelude is deeply wired into Hugs. (More > precisely, it'll take me a bit of time to find the time to look > through the relevant archives.) > > -- > Alastair Reid reid(a)cs.utah.edu > http://www.cs.utah.edu/~reid/ > > _______________________________________________ > Hugs-Bugs mailing list > Hugs-Bugs(a)haskell.org > http://www.haskell.org/mailman/listinfo/hugs-bugs > > > > > ------------------------------------------------------------------------------------------------- > 21st century air travel http://www.britishairways.com > > _______________________________________________ > Hugs-Bugs mailing list > Hugs-Bugs(a)haskell.org > http://www.haskell.org/mailman/listinfo/hugs-bugs >

1 0

Re: toUpper Bug?
by cwitty＠newtonlabs.com 16 Aug '01

16 Aug '01

Alastair David Reid <reid(a)cs.utah.edu> writes: > We don't want to make 2 copies of the same code though (one in the > Prelude but not exported, one in the correct place and exported) > because it leads to code maintenance problems. Suppose that toUpper > had a bug in it - it'd be so easy to fix one copy and forget about the > existence of the second. How about making the Prelude export (and use) __prelude_toUpper; then Char would have toUpper = __prelude_toUpper > Another fix (the preferred fix) is to improve the Hugs compiler so > that the code can have (almost) the same structure as in the report. > We know how to do this (STG-Hugs had it) but it'll take a bit of time > to figure out again exactly which changes are required because the > special treatment of the Prelude is deeply wired into Hugs. (More > precisely, it'll take me a bit of time to find the time to look > through the relevant archives.) Of course, that would be better. Carl Witty

1 0

Re: toUpper Bug?
by Steinitz, Dominic J 16 Aug '01

16 Aug '01

Alastair, It's good to know someone is doing something with reported bugs. toUpper being in the wrong library is a minor annoyance so it doesn't sound like the effort of fixing it is worth it. The other bug about not behaving properly for i with a circumflex is more serious and I hope will be fixed. I'd like to suggest that someone acknowledges receipt of bugs even if it's just to say no-one has time to fix it at the moment but it's been put in a list of things to fix and won't get forgotten about. Dominic. reid(a)cs.utah.edu on 15/08/2001 23:25:00 To: Dominic Steinitz cc: hugs-bugs bcc: Subject: Re: toUpper Bug? [reply just sent to hugs-bugs] > Maybe if this one is going to be fixed, toUpper could be put in the > correct library as well? I'm assuming this is a reference to the fact that toUpper is exported both from Char (correct) and from Prelude (incorrect)? A quick check of Prelude.hs and hugs98/src/*.c reveals no good reason why this code is in the Prelude. Perhaps some vague code tidiness argument about keeping related code together? So, it could be fixed quite easily but there's a bunch of similar deviations from the standard which are not easily fixed because the Prelude (or some part of the Hugs compiler) depends on the function which, with the current Hugs implementation, implies that there has to be a copy in the Prelude. We don't want to make 2 copies of the same code though (one in the Prelude but not exported, one in the correct place and exported) because it leads to code maintenance problems. Suppose that toUpper had a bug in it - it'd be so easy to fix one copy and forget about the existence of the second. Another fix (the preferred fix) is to improve the Hugs compiler so that the code can have (almost) the same structure as in the report. We know how to do this (STG-Hugs had it) but it'll take a bit of time to figure out again exactly which changes are required because the special treatment of the Prelude is deeply wired into Hugs. (More precisely, it'll take me a bit of time to find the time to look through the relevant archives.) -- Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/ _______________________________________________ Hugs-Bugs mailing list Hugs-Bugs(a)haskell.org http://www.haskell.org/mailman/listinfo/hugs-bugs ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

Re: toUpper Bug?
by Alastair David Reid 15 Aug '01

15 Aug '01

[reply just sent to hugs-bugs] > Maybe if this one is going to be fixed, toUpper could be put in the > correct library as well? I'm assuming this is a reference to the fact that toUpper is exported both from Char (correct) and from Prelude (incorrect)? A quick check of Prelude.hs and hugs98/src/*.c reveals no good reason why this code is in the Prelude. Perhaps some vague code tidiness argument about keeping related code together? So, it could be fixed quite easily but there's a bunch of similar deviations from the standard which are not easily fixed because the Prelude (or some part of the Hugs compiler) depends on the function which, with the current Hugs implementation, implies that there has to be a copy in the Prelude. We don't want to make 2 copies of the same code though (one in the Prelude but not exported, one in the correct place and exported) because it leads to code maintenance problems. Suppose that toUpper had a bug in it - it'd be so easy to fix one copy and forget about the existence of the second. Another fix (the preferred fix) is to improve the Hugs compiler so that the code can have (almost) the same structure as in the report. We know how to do this (STG-Hugs had it) but it'll take a bit of time to figure out again exactly which changes are required because the special treatment of the Prelude is deeply wired into Hugs. (More precisely, it'll take me a bit of time to find the time to look through the relevant archives.) -- Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/

1 0

== operator freeze
by mario 10 Aug '01

10 Aug '01

Import the attached file from hugs and evaluate the following expression: get ((AttributeLeaf (MyLabel "x") 4)::Env1) (MyLabel "x") The result should be Just 4. But if you replace the operator =?= with the builtin operator == on line 31 and then retry the same expression, the evaluation diverges. The =?= operator is defined as l =?= l' = l == l' Since I have found this workaround (after two days of looking for bugs in my code) the matter is no longer urgent to me, but I'd like to know if and when you fix it. Thank you.

1 0

Win32 help files busted?
by hethcoa＠attglobal.net 09 Aug '01

09 Aug '01

I downloaded the help file for Win32 (hugs.hlp) and I am getting a warning that this file is corrupted or not in the correct format. Do I have to do something special, or is it in fact corrupted? Could someone check into this? Thanks. Charles Hethcoat

2 1

"numerator" and "denominator"
by Iain McNaughton 09 Aug '01

09 Aug '01

Hi ! In the Haskell 98 Library Report it says: "The functions numerator and denominator extract the components of a ratio; these are in reduced form with a positive denominator". However, when I try to use these functions on WinHugs, I get results like: numerator 1.3 = 5452595 denominator 1.3 = 4194304 This strikes me as strange, as what I was expecting was: numerator 1.3 = 13 denominator 1.3 = 10 What's particularly strange is that Hugs' answers aren't even of the form ( 13n, 10n ), and 5452595/4194304 is not equal to 1.3 in real life ( though it apparently is in Hugs ! ). I'd appreciate any comments you may have on this, as it kind of looks like a bug to me ( or am I just being dumb ! ). Thanks for your help with this. Sincerely, Iain McNaughton. -- Iain McNaughton

2 1

maybe it's a feature
by Stan Szpakowicz 08 Aug '01

08 Aug '01

Hello. I downloaded the Mac version of Hugs with the intention of using the precompiled Hugs 98. It opens and then immediately quits. I have an iMac (classic) with 160M memory. I wonder what I am doing wrong -- or what Hugs 98 dislikes about my computer. Thanks! -- Dr. Stan Szpakowicz, Professor http://www.site.uottawa.ca/~szpak School of Information Technology & Engineering szpak(a)site.uottawa.ca University of Ottawa tel +613-562-5800/6687 fax +613-562-5187

3 2

Patch for buildings hugs with pthreads
by Antony Courtney 31 Jul '01

31 Jul '01

Hi, As I mentioned on the Haskell mailing list a few days ago, a few of us at Yale are developing a system that allows Haskell code to invoke Java methods via GreenCard and the Java Native Interface. The system works quite reliably at this point, including integration of the Java and Haskell garbage collectors, and we have succesfully run a number of interesting test programs under Hugs98 on both Windows and Linux. We are currently working on a novel mechanism for mapping Java method names to Haskell function names; when that is complete, we plan to make this system available to the community. However, because the Java VM is multi-threaded, I had to rebuild Hugs from sources under Linux to use the multi-threaded version of the C library. The changes were very minor: - Pass the -D_REENTRANT flag to CC - Add -lpthread to LIBS for linking - #define DONT_PANIC to avoid catching signals used by the user-space LinuxThreads implementation. To make it as painless as possible for users to be able to use the Java/Haskell bridge, whilst minimizing the impact on others, I have made modified my local copy of hugs so that the above changes only take effect if the --with-pthreads option is given to configure. Attached is a patch with the mods. to src/Makefile.in and src/unix/configure.in to add the --with-pthreads option. Since this change is completely invisible unless hugs is built from sources using --with-pthreads, I hope that you won't object to including this in the hugs distribution. The patch is in unified diff format. If you have any problems applying the patch from the diff. file or there is anything I can do to make this patch more acceptable, please let me know. Thanks! -Antony Courtney -- Antony Courtney Grad. Student, Dept. of Computer Science, Yale University antony(a)apocalypse.org http://www.apocalypse.org/pub/u/antony diff -u -r src/Makefile.in /usr/local/src/hugs98-Feb2001-MT/hugs98-Feb2001/src/Makefile.in --- src/Makefile.in Tue Jan 30 21:52:13 2001 +++ /usr/local/src/hugs98-Feb2001-MT/hugs98-Feb2001/src/Makefile.in Sat Jul 7 16:35:19 2001 @@ -25,7 +25,7 @@ default :: hugs@EXE@ runhugs@EXE@ CC = @CC@ -CFLAGS = @CFLAGS@ @DEBUGFLAGS@ +CFLAGS = @CFLAGS@ @DEBUGFLAGS@ @MTCFLAGS@ OPTFLAGS = @OPTFLAGS@ LD = @LD@ diff -u -r src/unix/configure.in /usr/local/src/hugs98-Feb2001-MT/hugs98-Feb2001/src/unix/configure.in --- src/unix/configure.in Wed Jan 17 18:30:36 2001 +++ /usr/local/src/hugs98-Feb2001-MT/hugs98-Feb2001/src/unix/configure.in Sat Jul 7 16:51:57 2001 @@ -240,6 +240,7 @@ AC_ARG_ENABLE(tag-checks, [ --enable-tag-checks runtime tag checking (for debugging use)],AC_DEFINE(CHECK_TAGS)) AC_ARG_ENABLE(lint, [ --enable-lint enable "lint" flags (for debugging use)]) AC_ARG_ENABLE(only98, [ --enable-only98 make Hugs Haskell 98 only], AC_DEFINE(HASKELL_98_ONLY)) +AC_ARG_WITH(pthreads, [ --with-pthreads build Hugs using pthreads C library], AC_DEFINE(DONT_PANIC) MTCFLAGS="-D_REENTRANT"; LIBS="$LIBS -lpthread") dnl Disabled for now because the plugin-code can't handle the change. dnl If you're not using plugins, you could turn this on manually @@ -343,6 +344,7 @@ AC_SUBST(OPTFLAGS) AC_SUBST(DEBUGFLAGS) AC_SUBST(LDDEBUGFLAGS) +AC_SUBST(MTCFLAGS) dnl Figure out sizes of objects and decide which version of Hugs to build

3 2