From nhc-bugs@haskell.org  Thu May  3 14:14:53 2001
Date: Thu, 3 May 2001 14:14:53 +0100
From: nhc-bugs@haskell.org nhc-bugs@haskell.org
Subject: [nhc-bugs] Re: Nhc-bugs -- confirmation of subscription -- request 451860

<PRE>

</PRE>

From t_hallock@yahoo.com  Tue May  8 06:17:33 2001
Date: Mon, 7 May 2001 22:17:33 -0700 (PDT)
From: Thomas Hallock t_hallock@yahoo.com
Subject: [nhc-bugs] trouble with 'make universe' on darwin (mac os x)

<PRE>this is what happens when I 'make universe' after a
successfull './configure':

[localhost:local/nhc98-1.02/src] root# make universe
cd syntax; make EXE= SYSTEM='-D__NetBSD__'
STATICFLAG='' myinstall
cd ugendir; make EXE=
sh ../../bin/mycc -s main.o gen.o lex.yy.o y.tab.o
id.o tree.o yyerror.o -o ugen
/usr/bin/ld: can't use -s with input files containg
indirect symbols (output file must contain at least
global symbols, for maximum stripping use -x)
make[2]: *** [ugen] Error 1
make[1]: *** [ugen] Error 2
make: *** [myinstall] Error 2


I am not too sure about what to do about this. I am
doing this using Darwin (Mac OS X). Thanks.

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
<A HREF="http://auctions.yahoo.com/">http://auctions.yahoo.com/</A>


</PRE>

From olaf@cs.york.ac.uk  Tue May  8 11:13:55 2001
Date: Tue, 08 May 2001 11:13:55 +0100
From: Olaf Chitil olaf@cs.york.ac.uk
Subject: [nhc-bugs] trouble with 'make universe' on darwin (mac os x)

<PRE>Thomas Hallock wrote:
&gt;<i> 
</I>&gt;<i> this is what happens when I 'make universe' after a
</I>&gt;<i> successfull './configure':
</I>&gt;<i> 
</I>&gt;<i> [localhost:local/nhc98-1.02/src] root# make universe
</I>&gt;<i> cd syntax; make EXE= SYSTEM='-D__NetBSD__'
</I>&gt;<i> STATICFLAG='' myinstall
</I>&gt;<i> cd ugendir; make EXE=
</I>&gt;<i> sh ../../bin/mycc -s main.o gen.o lex.yy.o y.tab.o
</I>&gt;<i> id.o tree.o yyerror.o -o ugen
</I>&gt;<i> /usr/bin/ld: can't use -s with input files containg
</I>&gt;<i> indirect symbols (output file must contain at least
</I>&gt;<i> global symbols, for maximum stripping use -x)
</I>&gt;<i> make[2]: *** [ugen] Error 1
</I>&gt;<i> make[1]: *** [ugen] Error 2
</I>&gt;<i> make: *** [myinstall] Error 2
</I>
lex.yy.o, y.tab.o, ugendir?
This looks very much like ghc and not at all like nhc.

-- 
OLAF CHITIL, 
 Dept. of Computer Science, University of York, York YO10 5DD, UK. 
 URL: <A HREF="http://www.cs.york.ac.uk/~olaf/">http://www.cs.york.ac.uk/~olaf/</A>
 Tel: +44 1904 434756; Fax: +44 1904 432767


</PRE>

From mark@eeter.fi.tartu.ee  Fri May 18 12:43:35 2001
From: mark@eeter.fi.tartu.ee (Mark Tehver)
Date: Fri, 18 May 2001 14:43:35 +0300 (EEST)
Subject: [nhc-bugs] Renaming bug?
Message-ID: <Pine.LNX.4.21.0105181434080.20532-100000@eeter.fi.tartu.ee>

Hello,

I got following error:

====================================
        Error when renaming::
Unbound Identifier a0 at 4:44

... (lots of internal compiler state lines)

under NHC 1.02 cygwin (win2k), although I think the program that caused
this is correct. The program consists of 2 small files:

File Test1.hs:

---

module Test1(fn) where

import Test2

fn :: Test -> Int
fn t@(Test { a0 = a } ) = a0 t + a

---

File Test2.hs:

---

module Test2(Test(..)) where

data Test = Test { a0 :: Int, b0 :: Int }

--

I compiled Test2.hs with "nhc98 -c Test2.hs" and then tried to compile
Test1.hs and got this error.

Best regards,
Mark



From Malcolm.Wallace@cs.york.ac.uk  Fri May 18 16:44:09 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Fri, 18 May 2001 16:44:09 +0100
Subject: [nhc-bugs] Renaming bug?
In-Reply-To: <Pine.LNX.4.21.0105181434080.20532-100000@eeter.fi.tartu.ee>
Message-ID: <zHIAAElDBTtj3wMA@cs.york.ac.uk>

>         Error when renaming::
> Unbound Identifier a0 at 4:44

Thanks for the bug report.  I can verify that this problem is still
present in the latest version of nhc98.  Someone will look into it
next week.

Regards,
    Malcolm


From C.Reinke@ukc.ac.uk  Wed May 23 13:19:53 2001
From: C.Reinke@ukc.ac.uk (C.Reinke)
Date: Wed, 23 May 2001 13:19:53 +0100
Subject: [nhc-bugs] problems installing nhc98-1.04 on cygwin
Message-ID: <E152XcH-00013I-00@myrtle.ukc.ac.uk>

Hi there,

I'm trying to install the results of months of cooperative hacking,
your all new nhc98-1.04, on cygwin (Windows/NT4).  Apart from a missing
"include <errno.h>" in cIOExtras.c, there seems to be a problem with
suffixes, or a missing file, which has stopped me from finishing the
installation.

  [nhc98-1.04, cygwin, NT4; configure +docs; make all]
  Errors encountered so far:
  --
  [missing in nhc98-1.04\src\runtime\Builtin\cIOExtras.c]
  #include <errno.h>


  --
  make[3]: Entering directory `/tmp/nhc98-1.04/src/prelude/Numeric'
  /tmp/nhc98-1.04/script/nhc98 -cpp -T -dbgtrans -trusted -P/tmp/nhc98-1.04/in
  clude -DTRACING -c +CTS -part -redefine -CTS -P../Char -P../PreludeText -P..
  /PreludeList -P../Ratio  -o /dev/null LexDigits.hs
  I/O error (user-defined), call to function `userError':
    Can't open any of:
   ./IsDigit.T.hi
   /tmp/nhc98-1.04/include/IsDigit.T.hi
   ../Char/IsDigit.T.hi
   ../PreludeText/IsDigit.T.hi
   ../PreludeList/IsDigit.T.hi
   ../Ratio/IsDigit.T.hi
   when trying to read IsDigit.

  make[3]: *** [../Numeric/LexDigits.T.hi] Error 1
  make[3]: Leaving directory `/tmp/nhc98-1.04/src/prelude/Numeric'
  make[2]: *** [../Numeric/LexDigits.T.hi] Error 2
  make[2]: Leaving directory `/tmp/nhc98-1.04/src/prelude/Char'
  make[1]: *** [Char.subdir] Error 2
  make[1]: Leaving directory `/tmp/nhc98-1.04/src/prelude'
  make: *** [targets/ix86-CYGWIN_NT-4.0/traceprelude] Error 2

  [../Char/IsDigit.t.hi exists, IsDigit.T.hi doesn't; from the tar-file
  contents, it seems that *.t.hi are generated, whereas *.T.hi come
  with the sources?]


Independent of the actual error (or perhaps not independent?), there is
a problem lurking here. You now rely on being able to distinguish
between *T* and *t* (tracing and timing), right?  Unfortunately, that
might not work on cygwin/windows boxes. From the cygwin FAQ:

  (http://sources.redhat.com/cygwin/faq/faq_4.html#SEC49)
  Are mixed-case filenames possible with Cygwin?

  Several Unix programs expect to be able to use to filenames spelled the
  same way, but with different case. A prime example of this is perl's
  configuration script, which wants Makefile and makefile. WIN32 can't
  tell the difference between files with just different case, so the
  configuration fails.

  In releases prior to beta 16, mount had a special mixed case option
  which renamed files in such a way as to allow mixed case filenames. We
  chose to remove the support when we rewrote the path handling code for
  beta 16. The standard Windows apps -- explorer.exe,
  cmd.exe/command.com, etc. -- do not distinguish filenames that differed
  only in case, resulting in some (very) undesirable behavior.

  Sergey Okhapkin had maintained a mixed-case patch ('coolview') until
  about B20.1, but this has not been updated to recent versions of
  Cygwin.

In case you can't imagine this kind of silly behaviour, and just to
confirm that I'm not hallucinating and that the FAQ is not simply out
of date, here is an example (using cygwin's bash), showing that, while
some tools manage to distinguish case, this can't be relied on:

  touch t.hi T.hi
  ls
    t.hi
  rm T.hi
  ls

  touch T.hi t.hi
  ls
    T.hi
  ls | fgrep 't.hi'

  ls | fgrep 'T.hi'
    T.hi
  rm t.hi
  ls
  
(for more info on this nonsense, see a posting on the cygwin
mailing list, http://cygwin.com/ml/cygwin/2000-07/msg00590.html)

I'm not sure whether this has anything to do with the second bug, but
it is a trap I would like to avoid.  I would simply rename one of the
suffixes, and try again, but the mapping of features to suffixes seems
to be hardwired and distributed all over the place (I couldn't find a
variable TRACINGSUFFIX=T), and I don't want to try and search for all
uses of t, T, tT, and so on.

Unless you can think of any good reason not to, could you please change
your suffix scheme back to something that will also work on
Windows-inhibited cygwin?

Thanks,
Claus



From C.Reinke@ukc.ac.uk  Wed May 23 13:29:33 2001
From: C.Reinke@ukc.ac.uk (C.Reinke)
Date: Wed, 23 May 2001 13:29:33 +0100
Subject: [nhc-bugs] problems installing nhc98-1.04 on cygwin
In-Reply-To: Message from "C.Reinke" <C.Reinke@ukc.ac.uk>
 of "Wed, 23 May 2001 13:19:53 BST." <E152XcH-00013I-00@myrtle.ukc.ac.uk>
Message-ID: <E152Xld-00018A-00@myrtle.ukc.ac.uk>

>   [../Char/IsDigit.t.hi exists, IsDigit.T.hi doesn't; from the tar-file
>   contents, it seems that *.t.hi are generated, whereas *.T.hi come
>   with the sources?]

Correction (to avoid confusion): IsDigit.{c,hi,hs,o,p.o,t.o} exist,
neither IsDigit.t.hi nor IsDigit.T.hi does.

Claus


From Malcolm.Wallace@cs.york.ac.uk  Wed May 23 14:30:57 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Wed, 23 May 2001 14:30:57 +0100
Subject: [nhc-bugs] <Pine.LNX.4.10.10105222334140.24464-100000@90-mia-3.acn.waw.pl>
Message-ID: <JwgAAJG7Czvq9AcA@cs.york.ac.uk>

[ Moved from nhc-users to nhc-bugs ]

Wojciech Moczydlowski, Jr writes:
> The configure script fails to detect ghc-5.00 - due to driver changes.

Oops, yes indeed.  Try the following patch.  I haven't been able to
test it fully, but i think it should work.

Regards,
    Malcolm


---- cut here ----
diff -u -r1.27 confhc
--- script/confhc	2001/03/23 20:36:38	1.27
+++ script/confhc	2001/05/23 13:25:21
@@ -149,12 +149,18 @@
   whichGHC=`which ghc`
   GHCVER=`${whichGHC} --version 2>&1 | sed 's/^.*version[ ]*\([0-9.]*\).*/\1/'`
   GHCSYM=`echo $GHCVER | tr "." " " | ( read x y z; echo $x$y; )`
-  GHCDIR=`grep '^\$libdir=' ${whichGHC} | head -1 | sed 's/^\$libdir=[^/]*\(.*\).;/\1/'`
-  if [ -d $GHCDIR/imports ]
-  then GHCINCDIR=$GHCDIR/imports
-  elif [ -d $GHCDIR/lib/imports ]
-  then GHCINCDIR=$GHCDIR/lib/imports
-  else GHCDIR=""
+  if [ $GHCSYM -lt 500 ]
+  then
+    GHCDIR=`grep '^\$libdir=' ${whichGHC} | head -1 | sed 's/^\$libdir=[^/]*\(.*\).;/\1/'`
+    if [ -d $GHCDIR/imports ]
+    then GHCINCDIR=$GHCDIR/imports
+    elif [ -d $GHCDIR/lib/imports ]
+    then GHCINCDIR=$GHCDIR/lib/imports
+    else GHCDIR=""
+    fi
+  else
+    GHCDIR=`${whichGHC} --show-package std --field import_dirs`
+    GHCINCDIR=`dirname $GHCDIR`
   fi
 fi
 if [ "$GHCDIR" = "" ]
@@ -247,7 +253,8 @@
            2.*)  sed -e "s|^GHC=0$|GHC=3|"  ;;
            3.*)  sed -e "s|^GHC=0$|GHC=4|"  ;;
            4.*)  sed -e "s|^GHC=0$|GHC=5|"  ;;
-           *)    sed -e "s|^GHC=0$|GHC=6|"  ;;
+           5.*)  sed -e "s|^GHC=0$|GHC=6|"  ;;
+           *)    sed -e "s|^GHC=0$|GHC=7|"  ;;
          esac
        )
   fi


From Malcolm.Wallace@cs.york.ac.uk  Wed May 23 14:43:20 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Wed, 23 May 2001 14:43:20 +0100
Subject: [nhc-bugs] nhc -T problem
In-Reply-To: <Pine.LNX.4.10.10105222346150.24464-100000@90-mia-3.acn.waw.pl>
Message-ID: <SQgAAHi+Czt4WAMA@cs.york.ac.uk>

[ Moved from nhc-users to nhc-bugs ]

Wojciech Moczydlowski, Jr writes:
> I've just installed nhc 1.04, and tried to execute: hmake 1 -T
> in a directory containing file 1.hs:
> and I've got the following error message:
> 
> [khaliff@90-mia-3 khaliff]$ hmake 1 -T
> nhc98  -T   -c -o 1.T.o 1.hs
> nhc98  -T   -o 1 1.T.o 
> 1.T.o(.data+0x1a8): undefined reference to N_Prelude_46mkNTId'
> 1.T.o(.data+0x1b0): undefined reference to N_Prelude_46mkSR'
> 1.T.o(.data+0x1b8): undefined reference to N_Prelude_46mkTNm'
> 1.T.o(.data+0x1bc): undefined reference to F_Prelude_46mkTRoot'
> 1.T.o(.data+0x1e8): undefined reference to N_Prelude_46lazySat'
> 1.T.o(.data+0x310): undefined reference to N_Prelude_46mkNTId'
> 1.T.o(.data+0x318): undefined reference to N_Prelude_46mkSR'
> 1.T.o(.data+0x320): undefined reference to N_Prelude_46mkTNm'
> 1.T.o(.data+0x324): undefined reference to F_Prelude_46mkTRoot'
> 1.T.o(.data+0x364): undefined reference to N_Prelude_46lazySat'

We have not been able to reproduce this problem.
Can you identify which processor/OS you are using?

The missing symbol names look suspicious;
  .  they should not have a quote ' character at the end
  .  the N_ prefix should be FN_
  .  the F_ prefix should be CF_ 

It is possible that the problem is due to using a strange linker -
can you tell whether it is Gnu ld (via gcc) or some other linker?

One experiment that might fix the problem is to edit the script/nhc98.inst
shell script.  Line 530 is:

LDLIBS=$MAINROUTINE" "$NHC98LIBDIR/$MACHINE/mutlib$CFG.o" "$NHC98LIBDIR/$MACHINE/mutator$CFG.o" "$NHC98LIBDIR/$MACHINE/Prelude$CFG.a" "$NHC98LIBDIR/$MACHINE/Runtime$CFG.a" "$NHC98LIBDIR/$MACHINE/Prelude$CFG.a" "$NHC98LIBDIR/$MACHINE/libdebug$CFG.a" "$NHC98LIBDIR/$MACHINE/Runtime$CFG.a" "$NHC98LIBDIR/$MACHINE/Prelude$CFG.a" "$NHC98LIBDIR/$MACHINE/Runtime$CFG.a

Try adding another
    " "$NHC98LIBDIR/$MACHINE/Prelude$CFG.a
to the end of this line, and maybe another
    " "$NHC98LIBDIR/$MACHINE/Runtime$CFG.a
also.  Afterwards, you must run ./configure again to re-generate the
actual runnable script/nhc98.

Regards,
    Malcolm


From Malcolm.Wallace@cs.york.ac.uk  Wed May 23 15:03:06 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Wed, 23 May 2001 15:03:06 +0100
Subject: [nhc-bugs] Re: problems installing nhc98-1.04 on cygwin
In-Reply-To: <E152XcH-00013I-00@myrtle.ukc.ac.uk>
Message-ID: <fwgAABrDCzuGnwwA@cs.york.ac.uk>

Claus Reinke writes:

>   [missing in nhc98-1.04\src\runtime\Builtin\cIOExtras.c]
>  #include <errno.h>

Thanks.

> You now rely on being able to distinguish between *T* and *t*
> (tracing and timing), right?

Yes, as we have done for more than three years.  However, we have
only recently added time profiling to the set of things built by
'make all' - previously you had to ask for it specially.

> WIN32 can't tell the difference between files with just different case.

Unbelievable.  Just unbelievable.

> In case you can't imagine this kind of silly behaviour, and just to
> confirm that I'm not hallucinating and that the FAQ is not simply out
> of date, here is an example ...

Ok, ok, I believe you.  So you know already what the fix for this
bug is - get a /real/ operating system, not a toy!  :-)

> I'm not sure whether this has anything to do with the second bug, but
> it is a trap I would like to avoid.

It has everything to do with your reported bug, yes.  Providing you
do not mind losing time profiling, there is an easy workaround:
  .  completely remove the directory targets/ix86-CYGWIN_NT-4.0/objt
  .  in the toplevel Makefile, remove the target 'timeprofile' from
     the dependencies of 'all'
and then 'make all' should work to build the tracing libraries and tools.

> Unless you can think of any good reason not to, could you please
> change your suffix scheme to something that will also work on
> Windows-inhibited cygwin?

Ok, I think you have persuaded us to use one different suffix.
We are currently thinking of changing 't' (for time profiling) to 'z'
in your honour.  (For 'zeit', or perhaps for your middle name Claus?).
It is sad to lose the English mnemonic, but perhaps a German one will
be just as good.  :-)  Complaints, comments, or suggestions for a
different mnemonic, are welcome.

Regards,
    Malcolm


From khaliff@astercity.net  Wed May 23 16:18:15 2001
From: khaliff@astercity.net (Wojciech Moczydlowski, Jr)
Date: Wed, 23 May 2001 17:18:15 +0200 (CEST)
Subject: [nhc-bugs] <Pine.LNX.4.10.10105222334140.24464-100000@90-mia-3.acn.waw.pl>
In-Reply-To: <JwgAAJG7Czvq9AcA@cs.york.ac.uk>
Message-ID: <Pine.LNX.4.10.10105231716090.25060-100000@90-mia-3.acn.waw.pl>

On Wed, 23 May 2001, Malcolm Wallace wrote:

> [ Moved from nhc-users to nhc-bugs ]
> 
> Wojciech Moczydlowski, Jr writes:
> > The configure script fails to detect ghc-5.00 - due to driver changes.
> 
> Oops, yes indeed.  Try the following patch.  I haven't been able to
> test it fully, but i think it should work.
> 
> Regards,
>     Malcolm

Doesn't work either:

First we look for already-installed Haskell compilers:
  Looking for hbc... (not found)
  Looking for ghc... ghc-5.00: unrecognised flag: --show-package
Usage: For basic information, try the --help' option.
dirname: too few arguments
Try 'dirname --help' for more information.
(not found)

BTW, not removing targets/ix86-linux/config.cache and similar files when I
rerun configure script is quite annoying.

Wojciech Moczydlowski, Jr



From Malcolm.Wallace@cs.york.ac.uk  Wed May 23 17:10:51 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Wed, 23 May 2001 17:10:51 +0100
Subject: [nhc-bugs] Re: detecting ghc 5.00
In-Reply-To: <Pine.LNX.4.10.10105231716090.25060-100000@90-mia-3.acn.waw.pl>
Message-ID: <pQsAAAvhCzvMWAgA@cs.york.ac.uk>

Wojciech Moczydlowski, Jr writes:
> First we look for already-installed Haskell compilers:
>   Looking for hbc... (not found)
>   Looking for ghc... ghc-5.00: unrecognised flag: --show-package

Apologies, line 162 in the patched script/confhc which now reads

    GHCDIR=`${whichGHC} --show-package std --field import_dirs`

should be 

    GHCDIR=`ghc-pkg --show-package std --field import_dirs`


> BTW, not removing targets/ix86-linux/config.cache and similar files when I
> rerun configure script is quite annoying.

Could you be more specific about what problems this causes?

Regards,
    Malcolm


From khaliff@astercity.net  Wed May 23 17:36:51 2001
From: khaliff@astercity.net (Wojciech Moczydlowski, Jr)
Date: Wed, 23 May 2001 18:36:51 +0200 (CEST)
Subject: [nhc-bugs] Re: detecting ghc 5.00
In-Reply-To: <pQsAAAvhCzvMWAgA@cs.york.ac.uk>
Message-ID: <Pine.LNX.4.10.10105231834420.522-100000@90-mia-3.acn.waw.pl>

On Wed, 23 May 2001, Malcolm Wallace wrote:

>     GHCDIR=`ghc-pkg --show-package std --field import_dirs`

Works now, thank you.

> > BTW, not removing targets/ix86-linux/config.cache and similar files when I
> > rerun configure script is quite annoying.
> 
> Could you be more specific about what problems this causes?
> 
>     Malcolm

Not any problems, it caused just my minor annoyance - when I reran
configure, I expected it to redecect compilers - yet AFAIR it hadn't. Maybe
I'm wrong.

Wojciech Moczydlowski, Jr



From khaliff@astercity.net  Wed May 23 18:17:51 2001
From: khaliff@astercity.net (Wojciech Moczydlowski, Jr)
Date: Wed, 23 May 2001 19:17:51 +0200 (CEST)
Subject: [nhc-bugs] nhc -T problem
In-Reply-To: <SQgAAHi+Czt4WAMA@cs.york.ac.uk>
Message-ID: <Pine.LNX.4.10.10105231718200.25060-100000@90-mia-3.acn.waw.pl>

On Wed, 23 May 2001, Malcolm Wallace wrote:

> Can you identify which processor/OS you are using?

Celeron 333/Linux

> The missing symbol names look suspicious;
>   .  they should not have a quote ' character at the end
>   .  the N_ prefix should be FN_
>   .  the F_ prefix should be CF_ 

It is FN/CF - it's just that joe interprets ` as an invitation to a special
character.

> It is possible that the problem is due to using a strange linker -
> can you tell whether it is Gnu ld (via gcc) or some other linker?

I don't know - I just run hmake -T. Though I suppose it's ld for my
configuration is rather standard.

> Try adding another
>     " "$NHC98LIBDIR/$MACHINE/Prelude$CFG.a
> to the end of this line, and maybe another
>     " "$NHC98LIBDIR/$MACHINE/Runtime$CFG.a
> also.  Afterwards, you must run ./configure again to re-generate the

>     Malcolm

But I've already got those libraries included. 
I've looked inside Prelude.a and PreludeT.a and I haven't found 
FN_Prelude_46mkSR there. So maybe the trouble is in the generated code?

Wojciech Moczydlowski, Jr





From qrczak@knm.org.pl  Wed May 23 18:41:27 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Wed, 23 May 2001 19:41:27 +0200
Subject: [nhc-bugs] nhc -T problem
In-Reply-To: <SQgAAHi+Czt4WAMA@cs.york.ac.uk>; from Malcolm.Wallace@cs.york.ac.uk on Wed, May 23, 2001 at 02:43:20PM +0100
References: <Pine.LNX.4.10.10105222346150.24464-100000@90-mia-3.acn.waw.pl> <SQgAAHi+Czt4WAMA@cs.york.ac.uk>
Message-ID: <20010523194126.A22636@qrnik.zagroda>

On Wed, May 23, 2001 at 02:43:20PM +0100, Malcolm Wallace wrote:

> The missing symbol names look suspicious;
>   .  they should not have a quote ' character at the end
>   .  the N_ prefix should be FN_
>   .  the F_ prefix should be CF_ 

They should have ` at the beginning instead of control characters.
Pasting into joe kills ` characters because by default `F in joe
means to insert literal Ctrl-F into the text. It's not the first time
I see Wojciech doing harm to ` characters :-)

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK


From brent.fulgham@xpsystems.com  Wed May 23 22:56:19 2001
From: brent.fulgham@xpsystems.com (Brent Fulgham)
Date: Wed, 23 May 2001 14:56:19 -0700
Subject: [nhc-bugs] Cygwin Build Bug (Probably Affects other GNU GLIBC Builds)
Message-ID: <EDFD2A95EE7DD31187350090279C676701D63EF7@thresher.corp.xpsystems.com>

For thread-safety reasons, the GNU C Library (2.2+) defines "errno"
as a macro that calls a function to get the errno of the current thread.
Consequently, the source file "src/runtime/Builtin/cIOExtras.c" needs
to include the <errno.h> header file, rather than declaring an extern
variable.

Diff:
==========================================================================

*** cIOExtras.old.c	Wed May 23 14:54:58 2001
--- cIOExtras.c	Wed May 23 14:26:54 2001
***************
*** 1,10 ****
  /* basic unsafe utilities, defined in IOExtras */
  #include "cinterface.h"
  #include "mk.h"
  
  void   performGC         ()                     { C_GC(0); }
  int    unsafePtrEq       (void* a, void* b)     { return (a==b); }
  
  /* basic error handling via C's errno */
! extern int errno;
  int	getErrNo	(void)			{ return errno; }
--- 1,11 ----
  /* basic unsafe utilities, defined in IOExtras */
  #include "cinterface.h"
  #include "mk.h"
+ #include "errno.h"
  
  void   performGC         ()                     { C_GC(0); }
  int    unsafePtrEq       (void* a, void* b)     { return (a==b); }
  
  /* basic error handling via C's errno */
! /*extern int errno;*/
  int	getErrNo	(void)			{ return errno; }


From Malcolm.Wallace@cs.york.ac.uk  Thu May 24 10:39:43 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Thu, 24 May 2001 10:39:43 +0100
Subject: [nhc-bugs] Re: Cygwin Build Bug (Probably Affects other GNU GLIBC Builds)
In-Reply-To: <EDFD2A95EE7DD31187350090279C676701D63EF7@thresher.corp.xpsystems.com>
Message-ID: <SxIAAN/WDDt4Ew4A@cs.york.ac.uk>

Brent Fulgham writes:
> For thread-safety reasons, the GNU C Library (2.2+) defines "errno"
> as a macro that calls a function to get the errno of the current thread.
> Consequently, the source file "src/runtime/Builtin/cIOExtras.c" needs
> to include the <errno.h> header file, rather than declaring an extern
> variable.

Thanks for the useful information.  Your suggested patch is now
listed on the nhc98 download page.

Regards,
    Malcolm


From Malcolm.Wallace@cs.york.ac.uk  Thu May 24 11:02:27 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Thu, 24 May 2001 11:02:27 +0100
Subject: [nhc-bugs] Re: detecting ghc 5.00
In-Reply-To: <Pine.LNX.4.10.10105231834420.522-100000@90-mia-3.acn.waw.pl>
Message-ID: <bBMAADPcDDvh5wAA@cs.york.ac.uk>

> > > BTW, not removing targets/ix86-linux/config.cache and similar files when I
> > > rerun configure script is quite annoying.
> > 
> > Could you be more specific about what problems this causes?
> 
> Not any problems, it caused just my minor annoyance - when I reran
> configure, I expected it to redecect compilers - yet AFAIR it hadn't. Maybe
> I'm wrong.

Yes, existing Haskell compilers are detected once only, but everything
else configuration-related can be altered at any time by re-running
the script.  Compiler detection is mainly for the benefit of 'hmake',
and I am becoming convinced that our current scheme is thoroughly
inadequate anyway.  For instance, some people have more than one
version of ghc installed, and want hmake to work properly with both.
Eventually, I hope to completely redesign this mechanism for hmake.

Regards,
    Malcolm


From Malcolm.Wallace@cs.york.ac.uk  Thu May 24 11:16:45 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Thu, 24 May 2001 11:16:45 +0100
Subject: [nhc-bugs] nhc -T problem
In-Reply-To: <Pine.LNX.4.10.10105231718200.25060-100000@90-mia-3.acn.waw.pl>
Message-ID: <nhMAAI3fDDvBCgYA@cs.york.ac.uk>

> > It is possible that the problem is due to using a strange linker -
> > can you tell whether it is Gnu ld (via gcc) or some other linker?
> 
> I don't know - I just run hmake -T.

Try   gcc -v   and   ld -v   for the version numbers.

> > Try adding another
> >     " "$NHC98LIBDIR/$MACHINE/Prelude$CFG.a
> 
> But I've already got those libraries included. 

The linker determines dependencies by processing the link archives
sequentially, but there are many long-chain cross-dependencies between
Prelude.T.a and Runtime.T.a.  Thus we need to add numerous copies
of both archives to the sequence, to ensure the dependencies can be
followed right to the end of the chain.

> I've looked inside Prelude.a and PreludeT.a and I haven't found 
> FN_Prelude_46mkSR there. So maybe the trouble is in the generated code?

Using 'nm PreludeT.a', you should find that FN_Prelude_46mkSR is defined
in HatArchive.T.o.  If it is not, can you check whether HatArchive.T.o
is included in the archive at all?

Regards,
    Malcolm


From khaliff@astercity.net  Fri May 25 08:23:34 2001
From: khaliff@astercity.net (Wojciech Moczydlowski, Jr)
Date: Fri, 25 May 2001 09:23:34 +0200 (CEST)
Subject: [nhc-bugs] nhc -T problem
In-Reply-To: <nhMAAI3fDDvBCgYA@cs.york.ac.uk>
Message-ID: <Pine.LNX.4.10.10105250910170.25206-100000@90-mia-3.acn.waw.pl>

> > I've looked inside Prelude.a and PreludeT.a and I haven't found 
> > FN_Prelude_46mkSR there. So maybe the trouble is in the generated code?
> 
> Using 'nm PreludeT.a', you should find that FN_Prelude_46mkSR is defined
> in HatArchive.T.o.  If it is not, can you check whether HatArchive.T.o
> is included in the archive at all?

It's not. And I've just discovered that PreludeT.a hasn't been
built at all - this was PreludeT.a from my previous installation. Looks like
it was all my fault - I followed the configure/make/make install pattern
instead of configure/make all/make install. Sorry for wasting your time. 
Though the existence of the difference between make and make all surprised
me.  Maybe the 'all' option should be default instead of 'basic'? 

>     Malcolm

Wojciech Moczydlowski, Jr



From C.Reinke@ukc.ac.uk  Tue May 29 15:37:57 2001
From: C.Reinke@ukc.ac.uk (C.Reinke)
Date: Tue, 29 May 2001 15:37:57 +0100
Subject: [nhc-bugs] Re: problems installing nhc98-1.04 on cygwin
In-Reply-To: Message from Malcolm Wallace <Malcolm.Wallace@cs.york.ac.uk>
 of "Wed, 23 May 2001 15:03:06 BST." <fwgAABrDCzuGnwwA@cs.york.ac.uk>
Message-ID: <E154kdB-0001ys-00@myrtle.ukc.ac.uk>

Hi Malcolm,

[Win32 fun with case-sensitive filenames deleted]
> > In case you can't imagine this kind of silly behaviour, and just to
> > confirm that I'm not hallucinating and that the FAQ is not simply out
> > of date, here is an example ...
> 
> Ok, ok, I believe you.  So you know already what the fix for this
> bug is - get a /real/ operating system, not a toy!  :-)

Hmm, standard disclaimers aside, NT4 was getting so close to a really
operating system that I still have some hope that its successors might
some day reach the quality of its *nixish predecessors.. 

Moreover, cygwin took on a red hat a while ago, and cygwin on NT is not
a bad compromise (in this particular case, if you followed the
reference I gave, cases are preserved in the file system, but too many
windows tools don't know what to do with them, so the cygwin developers
considered it too dangerous to encourage case-sensitive file names).
Still, I was afraid of spreading misinformation when I first saw those
comments, hence all the references and experiments:-)

> Ok, I think you have persuaded us to use one different suffix.
> We are currently thinking of changing 't' (for time profiling) to 'z'
> in your honour.  (For 'zeit', or perhaps for your middle name Claus?).

Thank you, your honour.

I'm not aware of having a middle name (a certain cs-support team at 
an unnamed English university was once unable to cope with this idea
and decided to add a z to my then-email-address;-). But as we use time
profiling when our programs seem to go to sleep (zzzz...), that suffix
seems appropriate.


Back to bugs:

- The tar-file still seems (not) to contain a spurious file:

  $ tar xvzf //e/archive/software/nhc98src-1.04.tar.gz >tar.log
  tar: nhc98-1.04/src/prelude/Numeric/Makefile?: Could not create file: 
  No such file or directory
  tar: Error exit delayed from previous errors

- There seems to be a disagreement about the order in which libraries
  are processed during linking. Old gcc man page says: 

	" The linker handles an archive file by scanning  through  it
	  for  members which define symbols that have so far been
	  referenced but not defined. "

  In other words, adding -lncurses as *the very first flag* in a
  call to gcc ain't going to help anyone. In src/tracer/hat/Makefile:

  LINKFLAGS= -lncurses -g

  This is used just after $(CC) in the targets.. Two of the targets
  also use a variable $(ncurses), which doesn't seem to be defined.

  Suggested fix (seems to work for me):
    - define ncurses as -lncurses (and remove -lncurses from LINKFLAGS)
    - add $(ncurses) to end of hat-detect target
    - for consistency, NCURSES would make more sense

And finally, a question:

I was under the impression that nhc supported addFinalizer, but I can't
seem to find it anywhere. Is it supported, and if so, where do I find it?

Cheers,
Claus


From Malcolm.Wallace@cs.york.ac.uk  Tue May 29 16:25:33 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Tue, 29 May 2001 16:25:33 +0100
Subject: [nhc-bugs] problems installing nhc98-1.04 on cygwin
In-Reply-To: <E154kdB-0001ys-00@myrtle.ukc.ac.uk>
Message-ID: <NW0AAG2/EzvQlgsA@cs.york.ac.uk>

| > Ok, I think you have persuaded us to use one different suffix.
| > We are currently thinking of changing 't' (for time profiling) to 'z'
| > in your honour.  (For 'zeit', or perhaps for your middle name Claus?).
| 
| I'm not aware of having a middle name (a certain cs-support team at 
| an unnamed English university was once unable to cope with this idea
| and decided to add a z to my then-email-address;-).

Aha.  I was always puzzled by that.

| But as we use time
| profiling when our programs seem to go to sleep (zzzz...), that suffix
| seems appropriate.

I have not heard any objections fro elsewhere, so I think we'll settle on z.

| - The tar-file still seems (not) to contain a spurious file:
|   tar: nhc98-1.04/src/prelude/Numeric/Makefile?: Could not create file: 

Ok, it seems I still failed to remove this spurious `Makefile?' from
the tree I use to prepare the distribution.  It is now removed,
and future distribution packages will not contain it.

| - There seems to be a disagreement about the order in which libraries
|   are processed during linking.
|     ....
|   In other words, adding -lncurses as *the very first flag* in a
|   call to gcc ain't going to help anyone. In src/tracer/hat/Makefile:
|       LINKFLAGS= -lncurses -g

Yes, I guess this looks a little strange - but it works here.  Are you
saying it doesn't work in Cygwin?  Nevertheless, you are right, we ought
to change it.

| And finally, a question:
| 
| I was under the impression that nhc supported addFinalizer, but I can't
| seem to find it anywhere. Is it supported, and if so, where do I find it?

We do not support any operation called addFinalizer.  However, we
do have

     FFI.newForeignObj  :: FFI.Addr -> IO () -> IO FFI.ForeignObj

Is this sufficient for your purposes?

Regards,
    Malcolm


From C.Reinke@ukc.ac.uk  Tue May 29 18:10:27 2001
From: C.Reinke@ukc.ac.uk (C.Reinke)
Date: Tue, 29 May 2001 18:10:27 +0100
Subject: [nhc-bugs] problems installing nhc98-1.04 on cygwin
In-Reply-To: Message from Malcolm Wallace <Malcolm.Wallace@cs.york.ac.uk>
 of "Tue, 29 May 2001 16:25:33 BST." <NW0AAG2/EzvQlgsA@cs.york.ac.uk>
Message-ID: <E154n0l-0003nc-00@myrtle.ukc.ac.uk>

> |   In other words, adding -lncurses as *the very first flag* in a
> |   call to gcc ain't going to help anyone. In src/tracer/hat/Makefile:
> |       LINKFLAGS= -lncurses -g
> 
> Yes, I guess this looks a little strange - but it works here.  Are you
> saying it doesn't work in Cygwin?  Nevertheless, you are right, we ought
> to change it.

The fragment of man-page I was quoting (search archives as they occur,
for currently outstanding references only) actually stems from our gcc
on Solaris installation, but it looks the same for the gcc on cygwin
version, and for the Solaris ld version, and I assume it would be
standard behaviour.

To answer your question, cygwin's gcc failed on the linking operation
in question when lncurses was given at the start, and succeeded when it
was given at the end.  Perhaps (some) Linuxes support a more convenient
behaviour for simple cases? That would be a nice trap for portable
development..

> We do not support any operation called addFinalizer.  However, we
> do have
> 
>      FFI.newForeignObj  :: FFI.Addr -> IO () -> IO FFI.ForeignObj
> 
> Is this sufficient for your purposes?

Unfortunately not. The idea, as mentioned briefly in our meeting, a few
weeks ago, was to use the (older?) addFinalizer as a hook into the
memory management, enabling GHood to show when parts of an observed
data structure get garbage collected.

Hugs and GHC support (supported?) such an operation, built around weak
pointers, but both implement optimisations that tend to move data
around, causing finalizers for anything but foreign addresses to be run
at completely unsuitable moments. I had already given up on this idea,
but Colin suggested that I might have more luck with nhc, as you have
to be more careful with such things, to support some of your profiling
tools.

Well, it was not meant to be, and accepting finalizers only for those
objects for which they will actually be run at the "right" moment is
probably the more honest approach. Would have been nice and really
useful, though..

Regards,
Claus



From brent.fulgham@xpsystems.com  Wed May 30 00:56:21 2001
From: brent.fulgham@xpsystems.com (Brent Fulgham)
Date: Tue, 29 May 2001 16:56:21 -0700
Subject: [nhc-bugs] hmake Problem
Message-ID: <EDFD2A95EE7DD31187350090279C676701DB270F@thresher.corp.xpsystems.com>

This is probably bad configuration on my part, but I can't seem to build
the one example program (in docs/examples/ZooQuiz.hs).

For example, if I try something like:

$ hmake ZooQuiz
nhc98    -c -o ZooQuiz.o ZooQuiz.hs

====================================
        Error when renaming::
Identifier Binary.<< used at 9:25 is not defined. (in overlap resolution)
Identifier Binary.getBitsF used at 9:25 is not defined. (in overlap
resolution)
Identifier Binary.getF used at 9:25 is not defined. (in overlap resolution)
Identifier Binary.sizeOf used at 9:25 is not defined. (in overlap
resolution)
Identifier Binary.getBits used at 9:25 is not defined. (in overlap
resolution)
Identifier Binary.putBits used at 9:25 is not defined. (in overlap
resolution)
Identifier Binary.get used at 9:25 is not defined. (in overlap resolution)
Identifier Binary.put used at 9:25 is not defined. (in overlap resolution)
Type class Binary.Binary used at 9:25 is not defined. (in overlap
resolution)

Which doesn't work.  I believe Binary to be a non-standard module, so
maybe some flag has to be activated to inform hmake where to find it.
But I thought hmake was supposed to take some of the guesswork out!  :-)

Any clues?

Thanks,

-Brent


From Malcolm.Wallace@cs.york.ac.uk  Wed May 30 10:41:32 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Wed, 30 May 2001 10:41:32 +0100
Subject: [nhc-bugs] hmake Problem
In-Reply-To: <EDFD2A95EE7DD31187350090279C676701DB270F@thresher.corp.xpsystems.com>
Message-ID: <tF4AAEzAFDuO+QYA@cs.york.ac.uk>

> This is probably bad configuration on my part, but I can't seem to build
> the one example program (in docs/examples/ZooQuiz.hs).

Actually, *cough*, that is my fault.  At some point in our transition
of nhc between Haskell 1.3 and Haskell 98, the automatic internal
qualified import of the Binary library (required for 'deriving Binary')
got removed from the compiler.

To work around this, you need to have *both* of the following imports:

    import Binary
    import qualified Binary

at the top of the ZooQuiz program.   Sorry about that.

Regards,
    Malcolm


From brent.fulgham@xpsystems.com  Wed May 30 18:13:16 2001
From: brent.fulgham@xpsystems.com (Brent Fulgham)
Date: Wed, 30 May 2001 10:13:16 -0700
Subject: [nhc-bugs] hmake Problem
Message-ID: <EDFD2A95EE7DD31187350090279C676701E0A510@thresher.corp.xpsystems.com>

> To work around this, you need to have *both* of the following imports:
> 
>     import Binary
>     import qualified Binary
> 
> at the top of the ZooQuiz program.   Sorry about that.

Great!  That fixed it.

-Brent


From brent.fulgham@xpsystems.com  Wed May 30 19:26:18 2001
From: brent.fulgham@xpsystems.com (Brent Fulgham)
Date: Wed, 30 May 2001 11:26:18 -0700
Subject: [nhc-bugs] Nit:  File Parsing Error Messages
Message-ID: <EDFD2A95EE7DD31187350090279C676701E0A58B@thresher.corp.xpsystems.com>

Under the Cygwin build, a poorly-indented source file:

--
--  Note indention at line #8
--
module Main where

import IO

add :: Integer -> Integer -> Integer
add x y = x + y

  inc   = add 1
-- ^^^ Indented two spaces

main = do
  putStrLn ("Hello, World.")

--
-- End program
--

This results in the somewhat confusing error message:

$ hmake test
nhc98    -c -o test.o test.hs
In file ./test.hs:
8:9 Found = but expected a {-EOF-}

It might be better if it indicated the indentation was at issue.

Correcting the indentation results in a successful compile.

I have not verified this on a "real" system (Linux/BSD/etc.),
so it's possible it's limited to Cygwin's environment.

Thanks,

-Brent


From olaf@cs.york.ac.uk  Wed May 30 20:21:12 2001
From: olaf@cs.york.ac.uk (Olaf Chitil)
Date: Wed, 30 May 2001 20:21:12 +0100
Subject: [nhc-bugs] Nit:  File Parsing Error Messages
References: <EDFD2A95EE7DD31187350090279C676701E0A58B@thresher.corp.xpsystems.com>
Message-ID: <3B154828.93AB25A4@cs.york.ac.uk>

Brent Fulgham wrote:
> 

> add :: Integer -> Integer -> Integer
> add x y = x + y
> 
>   inc   = add 1
> -- ^^^ Indented two spaces


> 8:9 Found = but expected a {-EOF-}

This error message is independent of the operating system, you get it on
any system.

The error message is definitely rather terse (I guess {- EOF -} means
end of file although end of function definition would be more
appropriate).

Nonetheless, the message makes sense: because `inc' is indented, nhc
thinks that it belongs to the right hand side of the previous
definition. Basically it reads it as if you had written

add x y = x + y inc = add 1

Hence complaining about `=' makes sense.

Producing better error messages by guessing what the programmer meant is
always prone to error and may lead to even more confusion. So for
example you could also have meant to write

add x y = x + y
  where
  inc = add 1

This seems unlikely, because `inc' is not used on the right hand side of
the definition of `add'. But what if it had been used there?

However, you are certainly right in that we should try to improve nhc's
error messages.

Cheers,
Olaf


-- 
OLAF CHITIL, 
 Dept. of Computer Science, University of York, York YO10 5DD, UK. 
 URL: http://www.cs.york.ac.uk/~olaf/
 Tel: +44 1904 434756; Fax: +44 1904 432767


From brent.fulgham@xpsystems.com  Wed May 30 22:06:23 2001
From: brent.fulgham@xpsystems.com (Brent Fulgham)
Date: Wed, 30 May 2001 14:06:23 -0700
Subject: [nhc-bugs] Nit:  File Parsing Error Messages
Message-ID: <EDFD2A95EE7DD31187350090279C676701E0A70B@thresher.corp.xpsystems.com>

> The error message is definitely rather terse (I guess {- EOF -} means
> end of file although end of function definition would be more
> appropriate).
> 

Agreed!  I kept monkeying with the file types (there are often end-of-line
issues when working with Unix-based tools under Cygwin) to see if I might
just be missing a valid EOF character, etc.

I think 'End of Function' would make things much clearer.

Of course, once I actually bothered *looking* at things, it made sense.
But of course that would require generally more discipline than I typically
possess on an ongoing basis ;-)

Thanks,

-Brent


From bfulgham@debian.org  Thu May 31 03:16:30 2001
From: bfulgham@debian.org (Brent A. Fulgham)
Date: Wed, 30 May 2001 19:16:30 -0700
Subject: [nhc-bugs] hi Problems
Message-ID: <20010530191630.A521@pacbell.net>

For a change of pace, I thought I would whine about
problems with Linux.

I built nhc98 under Debian GNU/Linux (I have a package
available if anyone is interested), and noticed that I
see the same problem that I do under Cygnus (which I
assumed was due to Cygwin's hackish nature).

Unforunately, the behavior is the same under Linux:

bfulgham@hopper:~$ hi
__   __                 __             _____________________________________
||   ||  ______    ___  || _  ____     hmake interactive (hi):
||___|| || || ||  ___|| ||/  ||__||      Copyright (c) May 2000
||---|| || || || ||__|| ||\_ ||__        http://www.cs.york.ac.uk/fp/hmake/
||   ||                                Report bugs to: malcolm@cs.york.ac.uk
||   || Version: 2.02 (2001-02-08)     -------------------------------------
                                           ... Using compiler nhc98 ...

Type :? for help
[Std   module... /usr/include/nhc98/Prelude.hi]
Prelude> ord 'a'
[Compiling...Segmentation fault
bfulgham@hopper:~$ 

Under Cygwin this was failing in run(), but in Linux I fail under
a log() routine, which may be part of the C runtime.

I suspect this would better be studied using hat or something, but
unfortunatley I am too unfamiliar with these tools (currently)
to delve further.

Am I just using 'hi' completely incorrectly?  I must shamefully
point out that hugs handles this case correctly:

bfulgham@hopper:~$ hugs
__   __ __  __  ____   ___      _________________________________________
||   || ||  || ||  || ||__      Hugs 98: Based on the Haskell 98 standard
||___|| ||__|| ||__||  __||     Copyright (c) 1994-1999
||---||         ___||           World Wide Web: http://haskell.org/hugs
||   ||                         Report bugs to: hugs-bugs@haskell.org
||   || Version: February 2000  _________________________________________

Haskell 98 mode: Restart with command line option -98 to enable extensions

Reading file "/usr/share/hugs98/lib/Prelude.hs":
                   
Hugs session for:
/usr/share/hugs98/lib/Prelude.hs
Type :? for help
Prelude> ord 'a'
97
Prelude> 
		   
Thanks!

-Brent

					   


From Malcolm.Wallace@cs.york.ac.uk  Thu May 31 10:44:21 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Thu, 31 May 2001 10:44:21 +0100
Subject: [nhc-bugs] hi Problems
In-Reply-To: <20010530191630.A521@pacbell.net>
Message-ID: <UQoAAHUSFjsnLAsA@cs.york.ac.uk>

> __   __                 __             _____________________________________
> ||   ||  ______    ___  || _  ____     hmake interactive (hi):
> ||___|| || || ||  ___|| ||/  ||__||      Copyright (c) May 2000
> ||---|| || || || ||__|| ||\_ ||__        http://www.cs.york.ac.uk/fp/hmake/
> ||   ||                                Report bugs to: malcolm@cs.york.ac.uk
> ||   || Version: 2.02 (2001-02-08)     -------------------------------------
>                                            ... Using compiler nhc98 ...
> 
> Type :? for help
> [Std   module... /usr/include/nhc98/Prelude.hi]
> Prelude> ord 'a'
> [Compiling...Segmentation fault
> bfulgham@hopper:~$ 

Hmmm.  Segfaults are really difficult to track down - I can't reproduce
this problem on my Linux machine.  Here's what I get:

> Prelude> ord 'a'
> [Compiling...
> ====================================
> 	Error when renaming::
> Identifier ord used at 10:21 is not defined. (in overlap resolution)
> ...failed]
> Prelude>

And this highlights a side issue - you should note that Hugs is
naughty to accept the expression at all - ord is not in the Prelude.
For true Haskell'98 behaviour, you should :load Char first.

> Prelude> :load Char
> [Std   module...  /usr/local/include/nhc98/Prelude.hi]
> [Std   module...  /usr/local/include/nhc98/Char.hi]
> Char> ord 'a'
> 97           
> Char>

But of course this doesn't help you.  You said that you get the
segfault under both Cygwin and Linux right?  That suggests a fault
in the code, rather than an environment issue.  Can you tell me what
compiler you used to build nhc98 etc with, under both Cygwin and Linux?

Regards,
    Malcolm


From brent.fulgham@xpsystems.com  Thu May 31 17:55:45 2001
From: brent.fulgham@xpsystems.com (Brent Fulgham)
Date: Thu, 31 May 2001 09:55:45 -0700
Subject: [nhc-bugs] hi Problems
Message-ID: <EDFD2A95EE7DD31187350090279C676701E0AB17@thresher.corp.xpsystems.com>

Hi Malcom,

> > Type :? for help
> > [Std   module... /usr/include/nhc98/Prelude.hi]
> > Prelude> ord 'a'
> > [Compiling...Segmentation fault
> > bfulgham@hopper:~$ 
> 
> Hmmm.  Segfaults are really difficult to track down - I can't 
> reproduce this problem on my Linux machine.  Here's what I get:
>

[ ... snip ... ]
 
> > Prelude> :load Char
> > [Std   module...  /usr/local/include/nhc98/Prelude.hi]
> > [Std   module...  /usr/local/include/nhc98/Char.hi]
> > Char> ord 'a'
> > 97           
> > Char>
> 
> But of course this doesn't help you.  You said that you get the
> segfault under both Cygwin and Linux right?  That suggests a fault
> in the code, rather than an environment issue.  Can you tell me what
> compiler you used to build nhc98 etc with, under both Cygwin 
> and Linux?
> 

My compilation procedeed like so (on both architectures):

1.  Both builds were done using the "gcc" target, since I only had ghc5 and
the configuration utility (at that time) did not know how to recognize it.

2.  Did a make all/make install.

It would be interesting to see what happens if I recompile using nhc98 to
bootstrap itself.  Perhaps the generated C code in the distribution has some
subtle problem with respect to byte alignment or some similar minutia that
causes the compilation to fail when compiled for HInterpreter.

I'll try that and report back.

-Brent 


From C.Reinke@ukc.ac.uk  Thu May 31 21:16:04 2001
From: C.Reinke@ukc.ac.uk (C.Reinke)
Date: Thu, 31 May 2001 21:16:04 +0100
Subject: [nhc-bugs] cygwin, java and cygpath (and some arithmetic)
Message-ID: <E155YrU-0003uG-00@myrtle.ukc.ac.uk>

[nhc98-1.04, built with gcc on cygwin/NT4]

1. Unless java has been compiled with cygwin (not the standard case:-),
  java on windows seems to need its paths translated from cygwin's unix
  world to plain windows world.

2. I do not understand the order in which nhc-compiled code evaluates
  arithmetic expressions.

3. Has anyone had success using hi under cygwin?

Regards,
Claus

1. ------------------------- I think I've reported this before:

cygwin gives a unix-like environment on top of windows, including
unix-style paths. However, the unix-style directory structure is
embedded in the usual Windows directory tree. Programs running 
"inside" cygwin happily see /tmp, /usr/local/bin, etc., but 
programs not running "inside" cygwin, *such as Sun's java*, see
only the windows paths. They don't know what to do with cygwin's
unix-style paths, because /tmp might actually be C:\cygwin\tmp
or such, depending on your installation.

This affects the driver scripts for the java tools in nhc98
(e.g., hood and hat). Example:

  $ CLASSPATH=/usr/local/lib/nhc98/hood.jar;export CLASSPATH

  $ echo $CLASSPATH
  /usr/local/lib/nhc98/hood.jar

  $ java Hood observe.xml
  Exception in thread "main" java.lang.NoClassDefFoundError: Hood

The workaround is simple, as cygwin provides a tool for the
filename conversion, cygpath:

  $ CLASSPATH=`cygpath -w -p /usr/local/lib/nhc98/hood.jar`;export CLASSPATH

  $ echo $CLASSPATH
  C:\cygwin\usr\local\lib\nhc98\hood.jar

  $ java Hood observe.xml
  Message: file:/C:/cygwin/tmp/observe.xml
  ..

(I think Sun recommends to use "java -cp <classpath>" instead of $CLASSPATH)

For reference:

  $ cygpath -h
  Usage: cygpath [-p|--path] (-u|--unix)|(-w|--windows [-s|--short-name]) filename
    -a|--absolute         output absolute path
    -c|--close handle     close handle (for use in captured process)
    -f|--file file        read file for path information
    -u|--unix             print Unix form of filename
    -w|--windows          print Windows form of filename
    -s|--short-name       print Windows short form of filename
    -W|--windir           print `Windows' directory
    -S|--sysdir           print `system' directory
    -p|--path             filename argument is a path
    -i|--ignore           ignore missing argument


2. ------------------------- what exactly is going on here?

  f = print $   (error "a") + (error "b")
  g = print $ (((error "a") + (error "b"))::Integer)
  h = print $ (((error "a") + (error "b"))::Double)
  i = print $ (((error "a") + (error "b"))::Int)

  main = f   => output: a
  main = g   => output: a
  main = h   => output: b
  main = i   => output: b

I would have expected a in all cases (which hugs gives me), but Haskell
probably doesn't specify order of evaluation, not even consistent order
of evaluation.  Is this effect intensional?

(sigh) It is disappointing that our beloved, semantically beautiful
functional language Haskell actually has less of a semantics than Java,
(not to mention SML, Lisp, ..).

3. ---------------------- btw

While playing with 2, I accidentally remembered a tool named hi, but
that crashes on me even with the simplest expressions:

  $ hi
  __   __                 __             _____________________________________

  ||   ||  ______    ___  || _  ____     hmake interactive (hi):
  ||___|| || || ||  ___|| ||/  ||__||      Copyright (c) May 2000
  ||---|| || || || ||__|| ||\_ ||__        http://www.cs.york.ac.uk/fp/hmake/
  ||   ||                                Report bugs to: malcolm@cs.york.ac.uk

  ||   || Version: 2.02 (2001-02-08)     -------------------------------------

                                             ... Using compiler nhc98 ...

  Type :? for help
  [Std   module... /usr/local/include/nhc98/Prelude.hi]
  Prelude> 42
  [Compiling...      0 [main] HInteractive 378 open_stackdumpfile: Dumping sta
  ck trace to HInteractive.exe.stackdump
  Segmentation fault (core dumped)



From brent.fulgham@xpsystems.com  Thu May 31 23:11:34 2001
From: brent.fulgham@xpsystems.com (Brent Fulgham)
Date: Thu, 31 May 2001 15:11:34 -0700
Subject: [nhc-bugs] hi Problems
Message-ID: <EDFD2A95EE7DD31187350090279C676701E0AD91@thresher.corp.xpsystems.com>

> Hmmm.  Segfaults are really difficult to track down - I can't 
> reproduce this problem on my Linux machine.  Here's what I get:
> 
> > Prelude> ord 'a'
> > [Compiling...
> > ====================================
> > 	Error when renaming::
> > Identifier ord used at 10:21 is not defined. (in overlap resolution)
> > ...failed]
> > Prelude>
>

I'm pleased to report that rebuilding (using the nhc98 I had previously
built with gcc) created a working executable.

You might need to modify the build rules such that hi does not function
unless built with a true Haskell compiler.  This is probably due to some
kind of interaction between the version of gcc, libc, etc., on the
system.

I'll verify on Linux, but I suspect the result will be the same.
 
> And this highlights a side issue - you should note that Hugs is
> naughty to accept the expression at all - ord is not in the Prelude.
> For true Haskell'98 behaviour, you should :load Char first.
> 
> > Prelude> :load Char
> > [Std   module...  /usr/local/include/nhc98/Prelude.hi]
> > [Std   module...  /usr/local/include/nhc98/Char.hi]
> > Char> ord 'a'
> > 97           
> > Char>
> 

And this works as well.

> But of course this doesn't help you.  You said that you get the
> segfault under both Cygwin and Linux right?  That suggests a fault
> in the code, rather than an environment issue.  Can you tell me what
> compiler you used to build nhc98 etc with, under both Cygwin 
> and Linux?
>

I built both copies using the included 'C' code from the tarball
(the gcc target) under gcc 2.95.3

Successful build was achieved by building nhc98 with the C sources,
then rebuilding with nhc98 to bootstrap itself.

Not sure why this was required, but that works.

Thanks,

-Brent