RE: FFI.lhs
| Some parts of the configuration mechanism changed. Did you invoke | autoheader and autoconf before configure? | I didn't either, I didn't even know about autoheader though I | suppose I should | have worked it out from Makefile.config. Perhaps a README | file that actually | gave correct information would not go amiss . . . To be fair the 'how to build' notes do say "run autoconf first". I don't think autoheader is necessary. (If it is, someone say so, in which case it should get added to the build notes.) It's hard to specify exactly when its necessary to re-run autoconf. Specific suggestions for better documentation always welcome. If they take the form of draft text that's even better. Simon
RE: Problems with the installation notes
My name's Jesse and I'm starting first year computer science this year. Our first language is Haskell, which we study for about 6 weeks. Before classes start I and a few friends are trying to get a handle on haskell. We've each tried using your compiler with no luck. I have some experience running Linux and using shells but I don't claim to be an expert :o) Basically my problem is this- everything works until I try to cat main.hs at which time I get an error 'cat : main.hs : file or directory not found' I thought it was a path error but when I do 'cat --help' I get a viable response, so cat.exe is obviously working. My friends have had the same problem. If I run 'cat' with no options I get a blank prompt which just copies everything I type on a new line. Hi there, It's difficult to deduce the cause of your problem, or indeed whether there is a problem at all, from this description. cat is not part of GHC; it's part of the operating system. "cat main.hs" will just display the file main.hs, which is source code. I guess the error message arose because main.hs was not in the directory you ran cat from. BTW, to compile main.hs, you would do "ghc -c main.hs -o runme" and then just type "runme" to execute it. I highly recommend you avoid GHC until you are more comfortable with UNIX/Linux. Instead use Hugs, which is interactive, smaller, simpler and easier to use. You can download it from: http://www.haskell.org/hugs/ Good luck! --fac
FW: GHC 4.06
[ admin note: forwarding to [EMAIL PROTECTED]: Folks, please
don't use glasgow-haskell-{bugs,users}@dcs.gla.ac.uk. I've asked the
Glasgow admins to either disable or redirect the old lists several times,
but until this happens they continue to be connected to an old version of
the mailing list. ]
Simon Peyton Jones writes:
As the release notes for 4.06 say, the GPH and GranSim
stuff aren't available for 4.06 yet. Hans is working on it.
Simon
| -Original Message-
| From: Raul Henriques C. Lopes [mailto:[EMAIL PROTECTED]]
| Sent: 29 January 2000 15:59
| To: [EMAIL PROTECTED]
| Subject: GHC 4.06
|
|
| Hi!
|
| I've just installed ghc 4.06 on sparc-solaris. I've tried 2
| different tests:
|
| (1) Compiled the small program for printing "Hello World",
that it is
| recommended in the GHC installation page.
|
| It worked fine.
|
| (2) Tried to compile the parfib program that I've downloaded
| from GHC site.
| I've tried the make bot in the directory "parallel" and "gransim".
|
| I received the following message when I tried the "make" in
| the directory
| "parallel"
|
| Main.lhs:3: Could not find valid interface file `Prelude'
|
| Main.lhs:5: Could not find valid interface file `Parallel'
|
| Compilation had errors
|
|
| (3) Do I need any special procedure to install GPH and gransim?
|
| Many thanks,
|
| Raul
|
|
|
RE: ANNOUNCE: GHC 4.06 released
ghc-4.06 distribution lacks the configure script in the ghc subdir. Running autoconf in ghc subdir fixes the problem. I know, I noticed this over the weekend. I'll put up a fixed src dist today, sorry for the inconvenience. Cheers, Simon
RE: Typo in hslibs/util/Memo.lhs:memo_sized
The mentioned function has 1001 hardwired in one place instead of using the size parameter. BTW, why isn't it called in the Haskell convention: memoSized? Thanks; fixed. Cheers, Simon
Re: FFI.lhs
Simon Peyton-Jones wrote: To be fair the 'how to build' notes do say "run autoconf first". I don't think autoheader is necessary. (If it is, someone say so, in which case it should get added to the build notes.) It *was* necessary to run autoheader after I've changed acconfig.h to re-generate mk/config.h.in. It's hard to specify exactly when its necessary to re-run autoconf. Specific suggestions for better documentation always welcome. If they take the form of draft text that's even better. My suggestion is simple: * "Normal" (= sane :-) people don't need autoconf/autoheader, because configure, mk/config.h.in, ... should always match their counterparts configure.in, acconfig.h.in, ... in a source distribution. * People compiling from CVS should always run both autoconf/autoheader in fptools and fptools/ghc. It doesn't hurt if nothing changed and guarantees consistency. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: FFI.lhs
Sven Panne wrote: Simon Peyton-Jones wrote: To be fair the 'how to build' notes do say "run autoconf first". I don't think autoheader is necessary. (If it is, someone say so, in which case it should get added to the build notes.) It *was* necessary to run autoheader after I've changed acconfig.h to re-generate mk/config.h.in. It's hard to specify exactly when its necessary to re-run autoconf. Specific suggestions for better documentation always welcome. If they take the form of draft text that's even better. To protect idiots like me who don't always read through the documentation every time they get something from CVS, I suggest adding something like: all boot :: configure configure :: configure.in echo configure needs to be regenerated. Type echo "make -f Makefile.config ./configure" echo and rerun make. exit 16 near the top of the top Makefile
Re: GHC 4.06
Hi! Thanks for your answer. I must confess I hadn't read the Release Notes for version 4.06. (I was too excited to try GranSim.) However, I had this same problem with version 4.04. I downloaded it, installed it, it work fine for a sequential program, but I couldn't compile the tests in directory "parfib". I received then the same messages that I received for my compilation with 4.06. = ghc -c -parallel -fvia-C -fglasgow-exts -cpp Main.lhs -o Main.o Main.lhs:3: Could not find valid interface file `Prelude' Main.lhs:5: Could not find valid interface file `Parallel' Compilation had errors make: *** [Main.o] Error 1 = I thought it could be related to some mistake of mine during installation. Anyway, I am trying to download now Haskell 3.02. If I can't get around with 4.04, I'll try to use it until you get 4.06 with GPH and GranSim working. Thanks again, Raul
FFI bug ?
Hi, It seems that FFI no longer accepts "ByteArray Int" in ghc 4.06 (it does in ghc 4.04), it looks intentional ? If so, is there another way to pass a String to a C function ? If not, I have attached a small example, to see the result do: tar -xf abc.tar make The result should be: --- gcc -O2 -Wall-c -o at.o at.c rm -f Main.o ghc -O -fglasgow-exts -recomp -dcore-lint -fvia-C -fallow-overlapping-instances -fallow-undecidable-instances -syslib posix -c Main.hs Main.hs:5: Unacceptable argument type in foreign declaration: ByteArray Int When checking declaration: foreign import _ccall "c_test" h_test :: ByteArray Int - IO () Compilation had errors make: *** [Main.o] Error 1 --- My configuration is: (~/project/bug 88) uname -sr SunOS 5.6 (~/project/bug 89) dmesg | grep SUNW cpu0: SUNW,UltraSPARC-IIi (upaid 0 impl 0x12 ver 0x12 clock 270 MHz) SUNW,m64B0 is /pci@1f,0/pci@1,1/SUNW,m64B@2 stdout is /pci@1f,0/pci@1,1/SUNW,m64B@2 major 35 minor 0 SUNW,hme0: CheerIO 2.0 (Rev Id = c1) Found SUNW,hme0 is /pci@1f,0/pci@1,1/network@1,1 SUNW,hme0: Using Internal Transceiver SUNW,hme0: 100 Mbps full-duplex Link Up (~/project/bug 90) cat /etc/release Solaris 2.6 5/98 s297s_hw3smccDesktop_09 SPARC Copyright 1998 Sun Microsystems, Inc. All Rights Reserved. Assembled on 24 April 1998 (~/project/bug 91) ghc --version The Glorious Glasgow Haskell Compilation System, version 4.06 (~/project/bug 92) gcc --version egcs-2.91.66 --- If this is a bug, there is no urgency in fixing it, ghc4.04 works very good too. Regards, Jan abc.tar
RE: FFI.lhs
OK. Simon will implement this shortly. | -Original Message- | From: George Russell [mailto:[EMAIL PROTECTED]] | Sent: 31 January 2000 11:20 | To: Sven Panne | Cc: GHC Bugs | Subject: Re: FFI.lhs | | | Sven Panne wrote: | | Simon Peyton-Jones wrote: | To be fair the 'how to build' notes do say "run autoconf first". | I don't think autoheader is necessary. (If it is, someone say so, | in which case it should get added to the build notes.) | | It *was* necessary to run autoheader after I've changed acconfig.h | to re-generate mk/config.h.in. | | It's hard to specify exactly when its necessary to re-run | autoconf. | | Specific suggestions for better documentation always welcome. | If they take the form of draft text that's even better. | To protect idiots like me who don't always read through the | documentation | every time they get something from CVS, I suggest adding | something like: | | all boot :: configure | configure :: configure.in | echo configure needs to be regenerated. Type | echo "make -f Makefile.config ./configure" | echo and rerun make. | exit 16 | | near the top of the top Makefile |
CVS make all failed: RegAllocInfo
Hello there, A make all from CVS failed because of the following: /usr/local/bin/ghc -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:profiling:parser:usageSP:cprAnalysis:nativeGen -recomp -c nativeGen/RegAllocInfo.lhs -o nativeGen/RegAllocInfo.o -osuf o RegAllocInfo.lhs:565: Variable not in scope: `g1' RegAllocInfo.lhs:565: Variable not in scope: `g2' RegAllocInfo.lhs:565: Variable not in scope: `f14' RegAllocInfo.lhs:565: Variable not in scope: `f15' RegAllocInfo.lhs:565: Variable not in scope: `f16' RegAllocInfo.lhs:565: Variable not in scope: `f18' Compilation had errors make[2]: *** [nativeGen/RegAllocInfo.o] Error 1 make[1]: *** [all] Error 1 make: *** [all] Error 1 I built the same from cvs yesterday. After updating today this failed. Any suggestions on how to fix this will be greatly appreciated. Thanks in advance. Marc van Dongen *** log *** ===fptools== Recursively making `all' in glafp-utils ghc hslibs ... PWD = /newdisk/dongen/cvs/fptools ==fptools== make all -r; in /newdisk/dongen/cvs/fptools/glafp-utils ===fptools== Recursively making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdependC make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/lndir make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/ltx make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/mkdirhier make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/runstdtest make[2]: Nothing to be done for `all'. ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/glafp-utils/sgmlverb make[2]: Nothing to be done for `all'. ===fptools== Finished making `all' in mkdependC lndir ltx mkdirhier runstdtest sgmlverb ... PWD = /newdisk/dongen/cvs/fptools/glafp-utils ==fptools== make all -r; in /newdisk/dongen/cvs/fptools/ghc ===fptools== Recursively making `all' in utils driver includes rts docs compiler lib ... PWD = /newdisk/dongen/cvs/fptools/ghc ==fptools== make all - --no-print-directory -r; in /newdisk/dongen/cvs/fptools/ghc/utils ===fptools== Recursively making `all' in hp2ps hscpp mkdependHS parallel stat2resid unlit ... PWD = /newdisk/dongen/cvs/fptools/ghc/utils ==fptools== make all - --no-print-directory -r; in
RE: FFI bug ?
Sven Panne [EMAIL PROTECTED] writes: [ Cross-mailed to ghc-users, too, because this is not really a bug ] Jan Kort wrote: It seems that FFI no longer accepts "ByteArray Int" in ghc 4.06 (it does in ghc 4.04), it looks intentional ? Even it is unintentional now, it will be omitted in future versions when the new FFI design is finished. Really? 'ByteArray Int' (and its mutable companion) is still available, but only if the user can guarantee that the 'import'ed call does not end up causing a GC, i.e., the following should work foreign import unsafe splat :: ByteArray Int - IO () the "unsafe" bit being the vital piece of info. At least this was the story for 4.045, so unless 4.06 behaves differently (I doubt it), you can still use ByteArrays. --sigbjorn
Re: FFI bug ?
Sigbjorn Finne wrote: Really? 'ByteArray Int' (and its mutable companion) is still available, but only if the user can guarantee that the 'import'ed call does not end up causing a GC, i.e., the following should work foreign import unsafe splat :: ByteArray Int - IO () the "unsafe" bit being the vital piece of info. Ooops, I forgot. :-} There was quite some mail traffic around this topic... At least this was the story for 4.045, so unless 4.06 behaves differently (I doubt it), you can still use ByteArrays. OK, but (Mutable)ByteArrays are so easy to implement given FFI (for creation/access) + Foreign(Obj) (for finalization), that the effort for maintaining, documenting, etc. them is at least a little bit doubtful. "Make it simple!" :-) Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
