- Nhc-bugs - Haskell.org

Possible bug in include handling
by D. Tweed 06 Nov '01

06 Nov '01

Hi, I'm not sure what the expected behaviour ought to be so this may not be a bug... Given a Haskell script with a line like import "/home/PRG_DEV/SRC/SCRIPTS/HASKELL/MAKEFILE_GENERATOR/LdfsWrapper.hs" hi, hmake, etc (version "Version: 2.02 (2001-02-08)") all report Fail: Can't find module "/home/PRG_DEV/SRC/SCRIPTS/HASKELL/MAKEFILE_GENERATOR/LdfsWrapper.hs" in . . Or in standard libraries at /usr/local/include/nhc98 Asked for by: makeMakefile.hs [Check settings of -I or -P flags?] I'd have thought it would be allowable to use unix absolute paths (certainly gcc allows absolute paths so I presume it's not some obscure security risk). (In case anyone wants to know, the full paths are there because some of these files are used in runhugs scripts, which are themselves invoked via symlinks, so it's easier to have all imports absolute.) ___cheers,_dave________________________________________________________ www.cs.bris.ac.uk/~tweed/pi.htm |tweed's law: however many computers email: tweed(a)cs.bris.ac.uk | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish.

2 1

Error: No match in _dropJust
by Ralf Hinze 01 Nov '01

01 Nov '01

When I compile frown with the brand-new 1.10 I get ... LR/Frown> hmake -nhc98 -98 -ILib -PLib Main.lhs WARNING: hmake built with hbc-0.9999.5b gets timestamps wrong. nhc98 -98 -ILib -PLib -c -o Lib/Prettier.o Lib/Prettier.lhs nhc98 -98 -ILib -PLib -c -o Atom.o Atom.lhs nhc98 -98 -ILib -PLib -c -o Base.o Base.lhs nhc98 -98 -ILib -PLib -c -o Lib/GetOpt.o Lib/GetOpt.lhs nhc98 -98 -ILib -PLib -c -o Options.o Options.lhs nhc98 -98 -ILib -PLib -c -o Lexer2.o Lexer2.lhs nhc98 -98 -ILib -PLib -c -o Haskell.o Haskell.lhs nhc98 -98 -ILib -PLib -c -o Grammar.o Grammar.lhs nhc98 -98 -ILib -PLib -c -o GParser2.o GParser2.hs /home/ralf/Lang//lib/nhc98/ix86-Linux/nhc98comp: Error: No match in _dropJust I can send you the bundle if you want me to. Cheers, Ralf

2 4

RE: [nhc-bugs] confhc does not recognize ghc 5.*
by Simon Marlow 29 Oct '01

29 Oct '01

> Here is the essential part of the patch: > > - GHCDIR=`grep '^libdir' ${whichGHC} | head -1 | sed > 's/^libdir=.$.*$./\1/'` > + GHCDIR=`grep '^TOPDIROPT' ${whichGHC} | head -1 | sed > 's/^TOPDIROPT="*-B$[^";]*$.*/\1/'` > > However, this does not work on my (Slackware Linux) machine. In the > driver script for ghc-5.02, I see the following two lines: > > libdir='/usr/malcolm/local/lib/ghc-5.02' > TOPDIROPT="-B$libdir"; > > which means that the original confhc gives the correct path > (/usr/malcolm/local/lib/ghc-5.02), but the patched confhc gives an > incorrect path symbol ($libdir). > > Can someone at ghc central confirm whether this part of the ghc-5.02 > driver script differs, depending on package and platform? And if so, > what is the best way to detect which variation applies? It differs depending on whether you installed GHC from a binary distribution, via make install, or from an RPM. I've just added the --print-libdir option to GHC, and I'll try to sneak it into 5.02.1. Cheers, Simon

1 0

nhc 1.10 bugs
by Lennart Augustsson 26 Oct '01

26 Oct '01

Here are some Time related bugs and fixes. tdPicosec misspelled, diffClockTimes and addClockTimes not implemeted -- Lennart ------ module Time where data TimeDiff = TimeDiff { tdYear, tdMonth, tdDay, tdHour, tdMin, tdSec :: Int, tdPicosec :: Integer } deriving (Eq, Ord, Read, Show) ------ module Time where import DClockTime import DTimeDiff diffClockTimes :: ClockTime -> ClockTime -> TimeDiff diffClockTimes (CT t) (CT t') = TimeDiff { tdYear = 0, tdMon = 0, tdDay = dd, tdHour = dh, tdMin = dm, tdSec = ds, tdPicosec = 0 } where ts = t-t' (tm, ds) = quotRem ts 60 (th, dm) = quotRem tm 60 (dd, dh) = quotRem th 24 -- tdMon and tdYear make no sense, so ignore them ----- module Time where import DTimeDiff import DClockTime addToClockTime :: TimeDiff -> ClockTime -> ClockTime addToClockTime td (CT i) = CT (i+d) -- tdYear and tdMonth make no sense, ignore them where d = ((tdDay td * 24 + tdHour td) * 60 + tdMin td) * 60 + tdSec td ------

2 1

Error compiling nhc98-1.10 in Linux
by José Romildo Malaquias 23 Oct '01

23 Oct '01

Hello. When compiling nhc98-1.10 on my Red Hat Linux 7.2 box with ghc-5.02 (after applying the patch that enables the detection of ghc) compilation stops with an error message: $ ./configure --prefix=/usr --mandir=/usr/share/man/man1 --docdir=docs_/docs +docs --buildwith=ghc --buildopts=-O [...] $ make 'OPT=-O2 -march=i386 -mcpu=i686' all [...] /home/romildo/rpms/BUILD/nhc98-1.10/script/hmake -nhc98 -K10M +CTS -H20M -CTS Hatobserve /home/romildo/rpms/BUILD/nhc98-1.10/targets/ix86-Linux/obj/hat/hatlib.a -d/home/romildo/rpms/BUILD/nhc98-1.10/targets/ix86-Linux/obj/hat hmake: Sorry, I do not know about your installation of nhc98 make[1]: *** [/home/romildo/rpms/BUILD/nhc98-1.10/lib/ix86-Linux/hat-observe] Error 1 make[1]: Leaving directory `/home/romildo/rpms/BUILD/nhc98-1.10/src/tracer/hat' make: *** [lib/ix86-Linux/hat-stack] Error 2 Any clues? Romildo -- Prof. José Romildo Malaquias Departamento de Computação Universidade Federal de Ouro Preto Brasil http://iceb.ufop.br/~romildo romildo(a)iceb.ufop.br romildo(a)uber.com.br

2 1

confhc does not recognize ghc 5.*
by Malcolm Wallace 23 Oct '01

23 Oct '01

Mieszko Lis <elf(a)sandburst.com> writes: > i ran into a compiler-detection bug in building nhc98 (the 1.10 tarball, > but the same bug seems to be in cvs and earlier versions): the build > process fails to detect the default ghc 5.02 installation on my debian > linux machine as well as the ghc 5.00.2 installation on a redhat 7.1 box > nearby. > > the problem turns out to be that script/confhc looks through the ghc > executable for the wrong stuff (at least in the installations i > mentioned above). i attached a patch (against the cvs tree) to fix > this at least on these debian and redhat installations. Here is the essential part of the patch: - GHCDIR=`grep '^libdir' ${whichGHC} | head -1 | sed 's/^libdir=.$.*$./\1/'` + GHCDIR=`grep '^TOPDIROPT' ${whichGHC} | head -1 | sed 's/^TOPDIROPT="*-B$[^";]*$.*/\1/'` However, this does not work on my (Slackware Linux) machine. In the driver script for ghc-5.02, I see the following two lines: libdir='/usr/malcolm/local/lib/ghc-5.02' TOPDIROPT="-B$libdir"; which means that the original confhc gives the correct path (/usr/malcolm/local/lib/ghc-5.02), but the patched confhc gives an incorrect path symbol ($libdir). Can someone at ghc central confirm whether this part of the ghc-5.02 driver script differs, depending on package and platform? And if so, what is the best way to detect which variation applies? Regards, Malcolm

2 1

confhc does not recognize ghc 5.*
by Mieszko Lis 22 Oct '01

22 Oct '01

hello, i ran into a compiler-detection bug in building nhc98 (the 1.10 tarball, but the same bug seems to be in cvs and earlier versions): the build process fails to detect the default ghc 5.02 installation on my debian linux machine as well as the ghc 5.00.2 installation on a redhat 7.1 box nearby. the problem turns out to be that script/confhc looks through the ghc executable for the wrong stuff (at least in the installations i mentioned above). i attached a patch (against the cvs tree) to fix this at least on these debian and redhat installations. cheers, -- mieszko Index: script/confhc =================================================================== RCS file: /cvs/nhc/script/confhc,v retrieving revision 1.29 diff -c -r1.29 confhc *** script/confhc 2001/10/02 14:49:02 1.29 --- script/confhc 2001/10/22 21:15:09 *************** *** 161,167 **** else #GHCDIR=`ghc-pkg --show-package std --field import_dirs` #GHCINCDIR=`dirname $GHCDIR` ! GHCDIR=`grep '^libdir' ${whichGHC} | head -1 | sed 's/^libdir=.$.*$./\1/'` if [ -d $GHCDIR/imports ] then GHCINCDIR=$GHCDIR/imports else GHCDIR="" --- 161,167 ---- else #GHCDIR=`ghc-pkg --show-package std --field import_dirs` #GHCINCDIR=`dirname $GHCDIR` ! GHCDIR=`grep '^TOPDIROPT' ${whichGHC} | head -1 | sed 's/^TOPDIROPT="*-B$[^";]*$.*/\1/'` if [ -d $GHCDIR/imports ] then GHCINCDIR=$GHCDIR/imports else GHCDIR=""

1 0

profiling
by Saswat Anand 19 Oct '01

19 Oct '01

Hi, I am using linux binaries on red hat 7.1. Compiling for time profiling I get undefined reference to `FN_Char_46intToDigit' Compiling for heap profiling has no problem, but seg faults on run. What is wrong? IS there a RPM for redhat? Thanks, Saswat [saswat@cf-plslab9 Oct17]$ nhc98 -98 Types.hs Operators.hs Mutables.hs Primitives.hs Pattern.hs CPL.hs Main.hs -o Main -t /usr/local/lib/nhc98/ix86-Linux/Numeric.z.a(ShowIntBase.z.o)(.data+0x12c): undefined reference to `FN_Char_46intToDigit' collect2: ld returned 1 exit status [saswat@cf-plslab9 Oct17]$ rm *.o *.hi -f [saswat@cf-plslab9 Oct17]$ nhc98 -98 Types.hs Operators.hs Mutables.hs Primitives.hs Pattern.hs CPL.hs Main.hs -o Main -p [saswat@cf-plslab9 Oct17]$ ./Main +RTS -H4M -p -RTS 82853 32974.9531 Segmentation fault (core dumped)

2 1

Re: [nhc-users] hat-observe message
by Malcolm Wallace 17 Oct '01

17 Oct '01

> Why do I get the following message from hat-observe? There is enough > output for hat-trail to work ok. > > [ajc99@pcburum hier]$ hat-observe countAssocs HierLearn > FUNCTION TABLE EMPTY > Closing file 0 Is the module containing `countAssocs' written as a literate file? Or maybe using an indentation style where top-level identifiers are indented by one character or more? If so, then I guess this is probably a known problem that we have already fixed for the forthcoming release 1.10 (due approximately at the end of this week). Essentially, hat-observe can only sensibly report information about top-level functions, i.e. not locally-defined functions. In currently-released versions, it checks for top-level-ness of an identifier by the column position of its definition, which is rather a hack and pretty error-prone. From the next release, the top-level information will be generated correctly by the compiler itself. Regards, Malcolm

2 2

Unimplemented
by Lennart Augustsson 15 Oct '01

15 Oct '01

I'm getting this message, which is quite annoying... WARNING!! Time.diffClockTimes: not implementedsorry, can't continue. -- Lennart

1 0