April 2002 - Nhc-bugs

Your message to Cvs-ghc awaits moderator approval
by cvs-ghc-admin＠haskell.org 19 Apr '02

19 Apr '02

Your mail to 'Cvs-ghc' with the subject Cleaning install stubs Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 119731 bytes but there's a limit of 40 KB Either the message will get posted to the list, or you will receive notification of the moderator's decision.

1 0

To all top level windows...
by fsarkar 19 Apr '02

19 Apr '02

1 0

MDaemon Warning - Virus Found
by postmaster＠socrates.america-net.com.br 18 Apr '02

18 Apr '02

The following message had attachment(s) which contained the viruses: >From : bcjang(a)cosmos.kaist.ac.kr To : nhc-bugs(a)haskell.org Subject : Static analysis Date : Thu, 18 Apr 2002 10:55:41 -0300 Message-ID: Attachment Virus name Action taken ------------------------------------------------------------------------------ cf713429859.att Exploit.IFrame.FileDownloadRemoved size.scr I-Worm.Klez.h Removed

1 0

Static analysis
by bcjang 18 Apr '02

18 Apr '02

****************************** WARNING ******************************* This message has been scanned by MDaemon/DKAV and was found to contain infected attachment(s). Please review the list below. Attachment Virus name Action taken ---------------------------------------------------------------------- cf713429859.att Exploit.IFrame.FileDownloadRemoved size.scr I-Worm.Klez.h Removed **********************************************************************

1 0

Your message to Haskell awaits moderator approval
by haskell-admin＠haskell.org 18 Apr '02

18 Apr '02

Your mail to 'Haskell' with the subject Spice girls' vocal concert Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 195906 bytes but there's a limit of 40 KB Either the message will get posted to the list, or you will receive notification of the moderator's decision.

1 0

Problems with System.getEnv when compiling with "-T"
by Matthias Neubauer 17 Apr '02

17 Apr '02

Dear nhc team, when accessing environment variables in a program compiled for tracing, the resulting strings always seem a little bit "too short". Consider the following program "Moo.hs": | import System | main = do host <- getEnv "HOST" | print host When compiled without option "-T", it outputs on my system as expected /tmp> hmake Moo nhc98 -c -o Moo.o Moo.hs nhc98 -o Moo Moo.o /tmp> ./Moo "nakalele" /tmp> whereas, when compiled with "-T", I get: /tmp> hmake -T Moo nhc98 -T -c -o Moo.T.o Moo.hs nhc98 -T -o Moo Moo.T.o /tmp> ./Moo "nakalel" /tmp> This is nhc98-1.12 by the way built from the source distribution on a Suse Linux PC. /tmp> uname -a Linux nakalele 2.2.19 #7 SMP Wed May 23 15:25:41 CEST 2001 i686 unknown Cheers, Matthias -- Matthias Neubauer | Universität Freiburg, Institut für Informatik | tel +49 761 203 8060 Georges-Köhler-Allee 79, 79110 Freiburg i. Br., Germany | fax +49 761 203 8242

2 1

Re: [nhc-bugs] Building nhc98 on Windows 2000
by Sigbjorn Finne 05 Apr '02

05 Apr '02

"Sigbjorn Finne" <sof(a)galois.com> writes: > ... > > Is there a description of what's wrong with the released Windows version > of GHC wrt. compiling up nhc98? > I got curious, so I went to have a look at the nhc-bugs archives -- seems like what's at the root of it all is that the following ghc invocation: ghc -package lang -package posix -c \ -o /tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/QSort.o \ QSort.hs Assembler messages: FATAL: Can't create \ \tmp\nhc98-1.12\targets\ix86-CYGWIN_NT-5.0\obj\hmake\QSort.o This is a known 'usability bug' with GHC - it doesn't check that the directory portion of the '-o' file exists, but just merrily hands it off to the assembler, which barfs with the above unfriendly message. So, for whatever reason, that /tmp/... directory doesn't exist. --sigbjorn

2 4

RE: [nhc-bugs] Building nhc98 on Windows 2000
by Simon Peyton-Jones 05 Apr '02

05 Apr '02

| > > /tmp/... directory *does* exist, but the \tmp\... directory does | > > not. (And indeed, why should it, since the invocation | didn't ask for | > > it?) | > | > Notice that both GHC and the mingw system calls (the MS provided C | > runtime functions, really) are capable of understanding paths that | > contain either "/" or "\" as directory separators, so | you're reading | > too much into the slashes being reversed in that output message. | | So am I right in thinking that if GHC did no internal | filepath mangling whatsoever, everything file-related would just work? GHC does mangle '/' into '\' on Windows. That is jolly convenient, and we certainly rely on it when using GHC (e.g to build GHC). I don't know why doing so should be a problem; after all, it's Windows. Simon

2 1

Re: [nhc-bugs] Building nhc98 on Windows 2000
by C.Reinke 04 Apr '02

04 Apr '02

> > > The file-removal assumes the unix-like property that you can unlink a > > > file while it still has a (lazy) reader attached to it, and the file > > > contents will stick around until the reader has finished with it. > > > It is perfectly possible to create a new (different) file with the > > > same name as the old one whilst the old one is still being read. > > > > Ah, I had almost forgotten about that old magic:) > > Old wizards used to say: don't use magic for ordinary tasks. > > Magic? It's just data-structure persistence and automatic garbage > collection, both of which are ideas we love in functional programming. > Should I avoid higher-order functions and laziness, since many > imperative programmers regard them as magic too? "Any sufficiently advanced technology is indistinguishable from magic." Sir Arthur C., I think;-) > > It may be cute that it works on real systems, but it isn't really > > needed here, so why not go for the ordinary, boring way? > > Working out a decent way of forcing exactly the right degree of > evaluation to match the broken operating system is much harder than > doing it the natural lazy way! One of the author's of the three additions to Asimov's Foundation series managed to let one of the characters paraphrase the above: "Any technology distinguishable from magic is insufficiently advanced." Seems to fit some overblown window-managers.. But wouldn't it be possible to imitate the unix behaviour by making temporary copies (using tmpnam & system cp, if neccessary), at least for readFile & hGetContents, and omitting that indirection step on "real" oss (which do all that behind the scenes)? > Btw, thanks for your help in tracking down these issues, Claus. It > never fails to surprise me how many seemingly-small incompatibilities > there are between Cygwin and real Unix, and how easy it is to trip > over them. You're welcome. I wouldn't want you to give up on including windows in portability considerations:-) And without Cygwin&co., I couldn't survive for long on windows systems (imagine having to buy each and every tool, starting from compilers..). Often, I wait until others find and fix the new-release bugs; this time, it's my turn to help.. Cheers, Claus

1 0

Re: [nhc-bugs] Building nhc98 on Windows 2000
by C.Reinke 04 Apr '02

04 Apr '02

> > c:/cygwin/tmp/nhc... > > That'll work, or just create a toplevel /tmp -- I always seem to end > up doing so. Haven't had to fiddle with the cygwin-mounts for a while now, and I like the idea of keeping in-cygwin software restricted to the c:/cygwin/tmp & co (instead of separate c:/tmp et.al.). > So, provided nhc98 can avoid depending on 'posix', don't just give up > on using GHC for compiling nhc98 under win32 just yet. Only postponed (pending no-posix version of nhc), not burried. (meanwhile, the nhc-build with gcc is making progress) Would that eliminate the reason for your ghc/cygwin binary? Intuitively, I dislike the idea of GHC giving up the chance of posix compatibility, if others (cygwin) have already put so much work into making it possible. nhc is probably not the only piece of Haskell that would like to use posix. Why would the posix package have made it into the hslibs otherwise? Perhaps those would be questions for the Haskell list: - who uses the posix package for what purposes? - who is affected by the current lack of posix support, now? - which uses of posix are envisioned that could be better served by Haskell-specific abstraction layers that may be easier to port than posix itself? Cheers, Claus

1 0