May 2001 - Nhc-bugs - Haskell.org

cygwin, java and cygpath (and some arithmetic)
by C.Reinke 01 Jun '01

01 Jun '01

[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(a)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)

2 1

RE: [nhc-bugs] hi Problems
by Brent Fulgham 01 Jun '01

01 Jun '01

> 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

2 1

RE: [nhc-bugs] hi Problems
by Brent Fulgham 31 May '01

31 May '01

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

1 0

hi Problems
by Brent A. Fulgham 31 May '01

31 May '01

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(a)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(a)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

2 1

RE: [nhc-bugs] Nit: File Parsing Error Messages
by Brent Fulgham 30 May '01

30 May '01

> 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

1 0

Nit: File Parsing Error Messages
by Brent Fulgham 30 May '01

30 May '01

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

2 1

RE: [nhc-bugs] hmake Problem
by Brent Fulgham 30 May '01

30 May '01

> 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

1 0

hmake Problem
by Brent Fulgham 30 May '01

30 May '01

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

2 1

Re: [nhc-bugs] problems installing nhc98-1.04 on cygwin
by C.Reinke 29 May '01

29 May '01

> | 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

1 0

Re: [nhc-bugs] Re: problems installing nhc98-1.04 on cygwin
by C.Reinke 29 May '01

29 May '01

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

2 1