RE: Bug in ghc 1.04 Time module?!
Hi,
Time.diffClockTimes doesn't attempt to normalise the
TimeDiff it returns, that's why you're seeing negative
fields in some cases here. That aside, the values
returned do all seem consistent.
But why not just CPUTime.getCPUTime here? i.e.,
do
start <- getCPUTime
...computation...
end <- getCPUTime
print (end - start)
--sigbjorn
Hermann Oliveira Rodrigues <[EMAIL PROTECTED]> writes:
>
> Hi,
>
> I am getting really strange results using the Time module of ghc
> 4.04 (patchlevel 1) under Solaris/SPARC and Linux/x86.
>
> My application is quite simple. It just retrives the system time
> in two diferent moments during the execution of my code using
> "Time.getClockTime" function. After that, I compute the
> elapsed time using
> the "Time.diffClockTimes". The strange behavior can be seen
> when I try to
> print the result using a show function over the "TimeDiff":
> Sometimes I
> get negative seconds and/or negative picoseconds that does
> not make any
> sense to me. But this is not happening all the time:
> Sometimes, I get the
> correct number of seconds and pico seconds.
>
> Here we have some examples:
>
> --
> Start: Tue Oct 19 14:41:57 EDT 1999
> End: Tue Oct 19 14:41:58 EDT 1999
> Elapsed Time: 0 hours, 0 min, 1 sec, 386300 picosec
>
> Start: Tue Oct 19 14:41:58 EDT 1999
> End: Tue Oct 19 14:41:59 EDT 1999
> Elapsed Time: 0 hours, 0 min, 1 sec, -1609300 picosec
>
> Start: Tue Oct 19 14:41:59 EDT 1999
> End: Tue Oct 19 14:42:00 EDT 1999
> Elapsed Time: 0 hours, 1 min, -59 sec, -593300 picosec
>
> Start: Tue Oct 19 14:42:00 EDT 1999
> End: Tue Oct 19 14:42:01 EDT 1999
> Elapsed Time: 0 hours, 0 min, 1 sec, -30500 picosec
>
> Start: Tue Oct 19 14:42:02 EDT 1999
> End: Tue Oct 19 14:42:02 EDT 1999
> Elapsed Time: 0 hours, 0 min, 0 sec, 95440600 picosec
>
> Start: Tue Oct 19 14:42:03 EDT 1999
> End: Tue Oct 19 14:42:04 EDT 1999
> Elapsed Time: 0 hours, 0 min, 1 sec, 15258200 picosec
> ---
>
> My piece of code can be seen below:
>
> --
> module Main (main) where
>
> import Time
> import CPUTime
>
> infixl 9 >.>
> (>.>) :: (t -> u) -> (u -> v) -> (t -> v)
> f >.> g = g . f
>
> apply :: (t -> u) -> t -> IO u
> apply f a = return (f a)
>
> main :: IO ()
> main = (recall_time []) >>= -- Recall time before
> the computation
>(show_time "Start: ") >>=
>(lost_time 1000) >>= -- Loop about 5 sec
>recall_time >>= -- Recall time after the
> computation
>(show_time "End: ") >>=
>(elapsed_time >.> to_string >.>
>("Elapsed Time: " ++) >.> (++ "\n") >.> putStr)
>
> -- This function loops during n miliseconds at least
> lost_time :: Integer -> ([ClockTime] -> IO [ClockTime])
> lost_time n = \t -> while (getCPUTime >>= apply (<= (n*10)))
> (return ())
> >> return t
>
> -- "while" definition
> while test oper =
> loop
> where loop = test >>= \result ->
> if result then (oper >> loop)
> else return ()
>
> -- Return a function that receives a time list and append to it,
> -- as the first element, the current time
> recall_time :: ([ClockTime] -> IO [ClockTime])
> recall_time =
> \l -> getClockTime >>= apply (:l)
>
> -- Return a function that receives a time list and print the first
> -- element
> show_time :: String -> ([ClockTime] -> IO [ClockTime])
> show_time str =
> \r@(a:x) -> putStr (str ++ (show a) ++ "\n")
> >> return r
>
> -- Return the elapsed time
> elapsed_time :: [ClockTime] -> TimeDiff
> elapsed_time x = diffClockTimes (head x) (last x)
>
>
> -- Return the TimeDiff as a string
> to_string :: TimeDiff -> String
> to_string (TimeDiff year month day hour min sec picosec) =
> show hour ++ " hours, " ++ show min ++ " min, " ++ show sec ++
> " sec, " ++ show picsec ++ " picosec"
>
> --
> -
>
> Can anyone tell me what is wrong with the libraries or
> exists any
> trick to use the Time module?!
>
> Thanks for any help.
>
> ---
> Hermann Oliveira Rodrigues - [EMAIL PROTECTED]
> Computer Science Student at UFMG - Brazil
> ---
> A friend is one who knows all about you and likes you
> anyway.
> Christi Mary Warner
>
>
>
>
RE: ghc-4.03 on cynwin deriving oddity.
It's a bug, which is fixed in 4.04 (a Win32 version of which is due out shortly.) --sigbjorn Alex Ferguson <[EMAIL PROTECTED]> writes: > > Observe: > > > BASH.EXE-2.02$ cat Enum.hs > > enumerate :: (Enum a, Bounded a) => [a] > enumerate = [minBound .. maxBound] > > data Test = Foo | Bar | Blah | Nonsense > deriving (Show, Enum, Bounded) > > main = print (enumerate :: [Test]) > BASH.EXE-2.02$ ghc-4.03 -static Enum.o > BASH.EXE-2.02$ ./a.exe > [Foo,Foo,Foo,Foo] > > > Whereas, with ghc-4.02, under Solaris 2.5: > > yeats.ucc.ie:~/LVO: a.out > [Foo,Bar,Blah,Nonsense] > > > What, as they say, gives? > > Cheers, > Alex. >
RE: GHC installing hits ;; problem.
Thanks, fixed. --sigbjorn > -Original Message- > From: George Russell [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 12, 1999 13:35 > To: [EMAIL PROTECTED] > Subject: GHC installing hits ;; problem. > > > gmake install in fptools complains (on Sparc Solaris): > > ==fptools== gmake install --no-print-directory -r; > in /usr/local/pub-bkb/ghc/fptools/ghc/utils/hp2ps > -- > -- > /bin/sh: syntax error at line 1: `;;' unexpected > > But when I make a small change to mk/targets.mk: > > diff mk/target.mk mk/target.mk.hack > 606c606 > < $(INSTALL_PROGRAM) $(INSTALL_BIN_OPTS) > $$i $(bindir) ;; \ > --- > > $(INSTALL_PROGRAM) $(INSTALL_BIN_OPTS) > $$i $(bindir) ; \ > > the install works flawlessly. > > I am using gmake v3.77. >
RE: WInNT ghc 4.03 and Pretty
Use -syslib misc. hth --sigbjorn > -Original Message- > From: Stephen Eldridge [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 11, 1999 12:59 > To: [EMAIL PROTECTED] > Subject: WInNT ghc 4.03 and Pretty > > > I've set up ghc 4.03 on my Windows NT machine (and similarly > under Windows 95 at home) but, even with the option > -fglasgow-exts, I find that I cannot use the module Pretty. > No valid interface file is found. > What have I done wrong? > > Stephen Eldridge > phone: 0161-200-3352 email: [EMAIL PROTECTED] > Department of Computation, UMIST, Manchester M60 1QD >
RE: HDirect and GHC 4.03 installation and example compile problem s
Mike Thomas <[EMAIL PROTECTED]> writes:
>
> Hi whomever.
>
...
> --
> --
> 1. When I use the Win32 binary installer for HDirect, it
> fails to find the GHC home directory unless GHC (the 4.03
> binary distribution) was installed in the default location.
> This means that the libraries and interfaces have
> to be installed by hand.
>
Hi,
odd - I haven't experienced this here nor can I reproduce it now
(on an NT box). The InstallScript code looks in
HKLM\Software\Haskell\Glasgow Haskell Compiler\ghc-4.03\{bin,lib}dir
for info on where to install the HDirect library and interface files.
Do these point to the GHC install in your case?
> --
> --
> 2. Compiling the comcli example fails because there is no
> stdole interface
> (GHC 4.03 binary distribution):
>
> BASH.EXE-2.02$ make
> ghc -fglasgow-exts -syslib com -fno-warn-missing-methods
> -c Ielabel.hs -o
> Ielabel.o -osuf o
>
> Ielabel.hs:15: Could not find valid interface file `Stdole32'
>
> Compilation had errors
>
Add -fignore-source-interfaces to SRC_IHC_OPTS in Makefile
to make this one go away.
> make: *** [Ielabel.o] Error 1
>
> --
> --
> 3. Compiling the examples using the makefiles provided
> requires changes of references to libhdirect to libHScom.
>
Yep, thanks - fixed this in the current sources.
> --
> --
> 4. A couple of examples that I have compiled crash on execution.
>
> GD - haven't tracked the crash point down
>
>
> listdir - Executed without command line options, crashes
> after printing
> "Usage:" - the v seems to cause the problem. If removed
> from the string concatenation the program doesn't crash.
>
I suspect this all down to the bug which the ghc-4.03 patch
fixes (available via the ghc-win32 pages), i.e., trouble with
using System.{getProgName, getArgs}.
Thanks for the report,
--sigbjorn
RE: Foreign module
Thanks, fixed. --sigbjorn > -Original Message- > From: Sven Panne [mailto:[EMAIL PROTECTED]] > Sent: Sunday, October 10, 1999 18:28 > To: GHC Bugs > Subject: Foreign module > > > Two bugs related to the Foreign module: > >* Foreign does not export the index...OffForeignObj/ > read...OffForeignObj/write...ForeignObj functions. > >* The documentation for Foreign is rather out of sync with the > implementation. > > 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: ghc-4.04, Sun Solaris 2.5.
Alex Ferguson <[EMAIL PROTECTED]> writes:
>
> I wrote:
> > syntax error at ../../ghc/driver/ghc line 1855, near "sub
> runLinker("
> > Execution of ../../ghc/driver/ghc aborted due to compilation errors.
> > gnumake: *** [Adjustor.o] Error 255
>
> Evidently Perl versionitis. 5.001 no like; 5.005 likum plenty fine.
>
> (This seems familiar, but I didn't notice an installation caveats
> beyond using any-old Perl 5.)
>
An unintentional one, it appears that decls of the form
sub foo() {...}
is what 5.001 doesn't like. Assuming that was it, a fix has been
committed :)
--sigbjorn
RE: randomIO causes bus error
"Latest" => bin dist of 4.04pl1? => compiled from current CVS sources? We've (SimonM, really) have been dogged by the pokiness of Linux' current NFS support, something that has been an issue when building on the sparc-solaris box (=> I wouldn't rule out the possibility that the binary dist itself contains broken object codes.) How does the following prog behave with same build? import Time import CPUTime import IO main = do getCPUTime >>= hPrint stderr getClockTime >>= hPrint stderr --sigbjorn > -Original Message- > From: George Russell [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 30, 1999 09:15 > To: [EMAIL PROTECTED] > Subject: randomIO causes bus error > > > With the latest version of GHC, and Sparc/Solaris, the > following program gives > a bus error: > > import Random > main = (randomIO :: IO Int) >>= print >
RE: Program too big to fit in memory under NT
Hi, hard to say what's at the root of this one - a couple of things to check/try out: * undo the rename of ghc-4.03 to ghc-4.03.exe * what does "ghc-4.03 --version" report? Does changing it to "perl ghc-4.03 --version" alter the output? * what does "head -2 < ghc-4.03" say? * what does "ls -l /bin" report? --sigbjorn Andrew Gray <[EMAIL PROTECTED]> writes: > > Hi, > > I'm trying to run the ghc-4.03 compiler under Windows NT 4 > (SP3, 128MB, > CygWin B-20.1). (ghc was installed using the InstallShield > installer). > Whenever I try to execute the compiler I get a message about > the program > being too big to fit in memory. > > bash-2.02$ ./ghc-4.03 > Program too big to fit in memory > > I get the same message using the MSDOS command prompt (after > copying the > ghc-4.03 file to ghc-4.03.exe). > > C:\ghc\ghc-4.03\bin>ghc-4.03.exe > Program too big to fit in memory > > I would imagine that this is a problem with my machine or > cygwin setup, > although nothing else exhibits this problem (including the perl and > hp2ps executables included in the ghc distribution) . Any > suggestions? > > Cheers, > Andrew > >
RE: Installing GHC 4.03 (Win32)
Hi,
couple of things to (double) check for:
* From within Bash, running "ls -l /bin/sh" does indeed
show up "sh.exe" as being parked there.
* If you didn't have perl installed from before, did you
copy it from the bin/ directory of the ghc installation
tree & into /bin? (the installer doesn't do this for you,
I'm afraid.)
hth
--sigbjorn
Michael T. Richter <[EMAIL PROTECTED]> writes:
>
> I followed the instructions and tried the basic test of
> whether or not the
> program was installed. I got the following back from GHC:
>
> bash-2.02$ /ghc/ghc-4.03/bin/ghc-4.03 -o main main.hs
> :0:25: Character literal '{-# LINE 1 "main.hs"
> -}' too long
> :0:25: on input: "'"
>
> The contents of main.hs are:
>
> module Main(main) where
>
> main = putStrLn "Hello, world!"
>
> Please advise as to next step. :-)
>
> --
> Michael T. Richter<[EMAIL PROTECTED]>http://www.igs.net/~mtr/
> PGP Key: http://www.igs.net/~mtr/pgp-key.html
> PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8
>
RE: ghc-4.03 compilation failure
Hi,
couple of things to (double) check for:
* From within Bash, running "ls -l /bin/sh" does indeed
show up "sh.exe" as being parked there.
* If you didn't have perl installed from before, did you
copy it from the bin/ directory of the ghc installation
tree & into /bin? (the installer doesn't do this for you,
I'm afraid.) Notice that using the Win32 port of perl
done by ActiveState won't work -- make sure you use the
perl binary distributed with ghc instead.
hth
--sigbjorn
[EMAIL PROTECTED] writes:
>
> Sirs,
>
> I have just installed the
> ghc-4.03-win32-IS.zip(InstallShield) on my NT box
> and failed to compile the HelloWorld test in cygwin-B20 as follows:
>
> bash$ /ghc/ghc-4.03/bin/ghc-4.03 main.hs
> :0:25: Character literal '{-# LINE 1 "main.hs" -}' too long
> :0:25: on input: "'"
>
>
> bash$ cat main.hs
> module Main( main ) where
>
> main = putStr "Hello, world!"
>
>
> bash$ type gcc
> gcc is /cygnus/CYGWIN~1/H-I586~1/bin/gcc
>
> bash$ gcc --version
> egcs-2.91.57
>
> bash$ echo $PATH
> /ghc/ghc-4.03/bin:/bin:/cygnus/CYGWIN~1/H-I586~1/bin:/WINNT/system32:
> /WINNT:/hugs98
>
> bash$ bash --version
> GNU bash, version 2.02.1(2)-release (i586-pc-cygwin32)
> Copyright 1998 Free Software Foundation, Inc.
>
>
> please help.
>
> Takei
>
>
RE: Message repeats: Alleged WinTel v4.03 bugs?
Alex Ferguson <[EMAIL PROTECTED]> writes: > > I wrote: > > Two oddities I've noticed with ghc-4.03, win+cygnus binary build: > > > > > > The -ansi flag makes gcc go berserk on the generated code. > I stopped. > > > > > > 'getEnv "PATH"' returns, not the value of PATH, but the > whole environment. > > Which is also handy, but not what I understood the report > to specify, > > and not what ghc-4.02 does on this 'ere Sun. > > Can someone comment on (esp.) the second of these? Is this > reproducible, is it the case _only_ on Win32, and, is it/will > it be fixed in 4.04, or thereafter? (In the meantime, I guess > a work-around is fairly obvious.) > Can't reproduce this here with 4.03pl1 (win32). Re: first point, the generated .hc files aren't ANSI conformant, so I'm surprised it has worked in other contexts. Or rather, it is not the .hc file per se that's non-ANSI, but the header files which gets included when an .hc is compiled by the driver. Believe there are plans for fixing/optionally avoiding the use of GCC extensions for those. --sigbjorn
Select.hSelect
FYI to Haskell WishList listeners - I've checked in support for hSelect to the CVS repository. Code in ghc/lib/misc/Select.lhs, documentation in ghc/docs/users_guide/libmisc.vsgml. As always, commits haven't been subject to a testing procedure that satisfies ISO 9001 requirements.. i.e., give it a go, if interested. The need for Select.hSelect should be less now that the IO library is MT friendlier, but it will still serve a useful role in some contexts, I hope. --sigbjorn
RE: make depend
Marc van Dongen <[EMAIL PROTECTED]> writes: > > : Did you try just `ghc-4.04 -M'? If so, you must add .hs > file names after > : the command. > > I did. > > : $ ghc-4.04 -M your.hs haskell.hs source.hs programs.hs > > That doesn't seem to do very much either. > > : You can find dependencies among `.hs' files in the Makefile. > > I think I'll wait until I am refered to some form > of documentation. > Kwanghoon Choi's comments is really all there's to it, but see top of Section 8.1 in the user's guide for more. --sigbjorn
RE: Help with GHC on win nt, doesnt do anything??
Hi, hmm..hard to say what's going wrong. Could you add "-v" to the below command line and reply, including the resulting output? thanks --sigbjorn > -Original Message- > From: Ronald J. Legere [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 13, 1999 21:34 > To: [EMAIL PROTECTED] > Subject: Help with GHC on win nt, doesnt do anything?? > > > > I followed closly the instructions for installing ghc-4.03 on > my win nt machine. In the end however, I tried the test, and > nothing happens! That is: > "bash$ ghc-4.03 -o main main.hs" > returns with no error, and no file created. THis is > also the case if main.hs is full of garbage! On the other hand, > if I try a file not named with the extension .hs, it will > properly complain that it doesnt know what to do. I dont understand > why ghs is not being called, and if the program cant find ghs (Its in > lib), why it doesnt complain or something! > > Please let me know if this is an obvious thing to fix. I tested my > main.hs (THe same as on the installation page) with hugs and it is > fine. > > THanks a million!!! > > > > +++ > Ron Legere > Caltech Quantum Optics > MC 12-33 > Pasadena CA 91125 > 626-395-8343 > FAX: 626-793-9506 > +++ >
RE: (no subject)
Hi,
I think you're OK, but the contents of what
was installed may have confused you. When
using the InstallShield version, you only need
to run the installer - it takes care of the
noodling that "./configure --yadda; make {install,in-place}"
performs.
Please ignore the presence of the configure script
(and Makefile) in the directory tree that the IS
installer produces & have a go with the installed GHC.
hth
--sigbjorn
> -Original Message-
> From: Tim Sauerwein [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 17, 1999 21:14
> To: [EMAIL PROTECTED]
> Subject: (no subject)
>
>
> Hello friends:
>
> Thanks for making GHC available. I regret to report
> the following installation problem.
>
> Yours,
> Tim Sauerwein [EMAIL PROTECTED]
>
> --
>
> Windows 98
> Cygwin B20
> GHC 4.03, Install Shield Version
>
> Everything unpacked successfully.
>
> Configure produced:
>
> creating cache ./config.cache
> checking host system type... i386-unknown-mingw32
> checking target system type... i386-unknown-mingw32
> checking build system type... i386-unknown-mingw32
> Which we'll further canonicalise into: i386-unknown-mingw32
> checking for perl... /BIN/perl
> checking if `#!/BIN/perl' works in shell scripts
> It does!
> checking for a BSD compatible install...
> /CYGNUS/CYGWIN~1/H-I586~1/BIN/install -c
> checking whether ln -s works... yes
> checking for sed... /CYGNUS/CYGWIN~1/H-I586~1/BIN/sed
> checking for gcc... gcc
> checking whether the C compiler (gcc -mno-cygwin ) works... yes
> checking whether the C compiler (gcc -mno-cygwin ) is a
> cross-compiler... no
> checking whether we are using GNU C... yes
> checking whether gcc accepts -g... yes
> checking whether you have an ok gcc... yes
> checking how to run the C preprocessor... gcc -E
> checking how to invoke GNU cpp directly...
> C:/CYGNUS/CYGWIN~1/H-I586~1/BIN/../lib/gcc-lib/i586-cygwin32/e
> gcs-2.91.57/cpp
> -iprefix
> C:/CYGNUS/CYGWIN~1/H-I586~1/BIN/../lib/gcc-lib/i586-cygwin32/e
> gcs-2.91.57/
>
> updating cache ./config.cache
> creating ./config.status
> creating Makefile
>
> Configuration done, ready to either 'make install'
> or 'make in-place', followed by 'make install-docs'.
> (see README and INSTALL files for more info.)
>
>
> make in-place produced:
>
> make --unix config-pkgs
> bindir=/ghc/ghc-4.03/bin/i386-unknown-mingw32/ghc-4.03
> libdir=/ghc/ghc-4.03/lib/i386-unknown-mingw32
> datadir=/ghc/ghc-4.03/share/ghc-4.03
> Configuring ghc, version 4.03, on i386-unknown-mingw32 ...
> Creating a configured version of ghc-4.03 ..
> cannot create bin/i386-unknown-mingw32/ghc-4.03/ghc-4.03: directory
> nonexistent
> make[1]: *** [config-pkgs] Error 2
> make: *** [in-place] Error 2
>
>
>
RE: Windows NT installer works.
It's 4.03 (as advertised.) --sigbjorn > -Original Message- > From: Mircea Draghicescu [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 27, 1999 18:58 > To: [EMAIL PROTECTED] > Subject: Windows NT installer works. > > > Hello again, > > Please disregard my previous message. The installer works - the > problem was with my machine. The other question still > remains: is this 4.03 or 4.04? > > Mircea > >
RE: *** HDirect Hugs support problem ***
Hi,
thanks for the report & fix - not having prototypes in scope
for functions taking or returning doubles is a bad idea.
The reason why you're not seeing the problem on the
ghc side is that it doesn't use AddrBits (it's only there
to make up for the rather incomplete implementation of
Addr that Hugs comes with.)
--sigbjorn
-Original Message-
From: Dominic Verity [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 23, 1999 07:51
To: [EMAIL PROTECTED]
Subject: *** HDirect Hugs support problem ***
In the past week or so I've been playing with HDirect to interface Hugs with
some statistical packages and have encountered a problem with HDirects
support for reference arguments of type double* or float*.
Specifically I have a function with prototype
void cumnor( double* arg, double* result, double* ccum);
which I wanted to interface to hugs/GHC using the following IDL
specification:
> stub_include("cdflib.h")
> module Cdlib {
>
> [pure]void cumnor
> ( [in]double* arg,
> [out]double* result,
> [out]double* ccum );
>
> };
giving a function cumnor :: Double -> (Double, Double) in Haskell.
When compiled using IHC this worked fine for GHC-4.03, however it returned
gobbledegook in Hugs.
In the end I've tracked this down to a problem in the construction of the
support DLL AddrBits.dll as supplied in the Win32 precompiled version of
HaskellDirect 0.15.
To fix the problem, I needed to supply the obvious header file for
AddrBitsPrim.c and include it in the AddrBits.idl file by adding
> stub_include("AddrBitsPrim.h")
to the start of that file.
Now I recompiled using the makefile default compiler flags to generate
AddrBits.c from AddrBits.idl and compile both AddrBits.c and AddrBitsPrim.c
to object code. Finally I linked this all into a DLL using:
> dllwrap -mno-cygwin --target=i386-mingw32 --def HugsMod.def AddrBits.dll_o
AddrBitsPrim.dll_o -o AddrBits.dll
This new dll seems to have solved my problem completely.
Please note: It was not enough to simply recompile AddrBits.dll, the c
compiler (egcs-2.91.66) definately requires the extra help the header file
provided.
All the Very Best (and congratualtions on HDirect)
Dr. Dominic Verity
Director
Categorical Solutions Pty Ltd
Uncertainty Management and Strategy.
Suite 405, 71 Archer Street,
Chatswood, NSW 2067,
Australia.
RE: ghc InstallShield download
Hi, ghc-4.02 is available on the ftp site, but I'd recommend you to pick up 4.03 instead from http://www.dcs.gla.ac.uk/~sof/ghc-win32.html To check, I downloaded the InstallShield-based installer from here just now without any problems. Where did you get the 4.02 link from, btw? --sigbjorn > -Original Message- > From: Andy Tawse [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 19, 1999 20:10 > To: [EMAIL PROTECTED] > Subject: ghc InstallShield download > > > I am having trouble downloading ghc4.02 from your website. I > get a page > cannot be displayed error when I click on the link for the Windows > InstallShield download. Do you have a broken link? > > Andrew Tawse > > > __ > Get Your Private, Free Email at http://www.hotmail.com >
RE: Compile the source code of HaskellDirect.
Hi, add -fglasgow-exts to the defn of SRC_HC_OPTS in src/Makefile. --sigbjorn Mei Qing <[EMAIL PROTECTED]> writes: > > Hi, > > I recently tried to compile HaskellDirect from source code, > intending to > run it on Solaris. I could not find the GHC 4.03 but got GHC 4.04 > (binary version). I make change in config.mk to the right directory > where GHC and happy 1.5 resident. But I failed with parse error when > "make" after "make boot". > > Would you give me some suggestions on how to do it? And is there a > binary version of this package for Solaris? > > Thanks. > > -mq > > This is what my config.mk likes: > > HC=/home/phd/meiqing/ghc4/bin/ghc > > CC=gcc > > MKDEPENDHS=$(HC) > > #TARGETPLATFORM=i386-unknown-mingw32 > #TARGETPLATFORM=sparc-sun-solaris2.5.1 > > HAPPY=/home/phd/meiqing/happy/bin/happy -g > > After "make boot", I tried "make" and always I got the > following error. > > Pretty.lhs:894: Pattern match(es) are non-exhaustive in the > definition of function `lay': > Patterns not matched: > (Beside _ _ _) _ > (Above _ _ _) _ > > < residency > (4 samples), 17M in use, 0.01 INIT (0.04 elapsed), 14.79 MUT (18.06 > elapsed), 3.36 GC (7.21 elapsed) :ghc>> > ghc: module version changed to 1; reason: no old .hi file > /home/phd/meiqing/ghc4/bin/ghc -syslib exts -Rghc-timing -H16m -W > -recomp-c PP.lhs -o PP.o -osuf o > > PP.lhs:86: Warning: Defined but not used: sep > > PP.lhs:169: Warning: Defined but not used: p > < (2 samples), 16M in use, 0.01 INIT (0.03 elapsed), 9.58 MUT (10.38 > elapsed), 1.39 GC (1.68 elapsed) :ghc>> > ghc: module version changed to 1; reason: no old .hi file > /home/phd/meiqing/ghc4/bin/ghc -syslib exts -Rghc-timing -H16m -W > -recomp-c Utils.lhs -o Utils.o -osuf o > Utils.lhs:345: parse error on input `.' > > Compilation had errors > > make[1]: *** [Utils.o] Error 1 > make: *** [all] Error 1 > >
RE: Portability questions of the week :-)
What's the object of this exercise?
sizeof(sizeof(foo)) is equal to sizeof(size_t),
which again is some value of type size_t.
If we're talking ISO/ANSI C (a reasonable assumption
by now, I think), size_t is guaranteed to at least be
unsigned. Converting an unsigned value to a
(signed int) if
sizeof size_t < sizeof (signed int)
isn't a problem. If,
sizeof size_t >= sizeof(signed int)
then the conversion isn't well-defined (but I don't
know of a C compiler that doesn't behave sensibly).
However, in your case the unsigned value that's
returned by the sizeof(sizeof(..)) won't run into
overflow problems when converting, so things would
be cool.
=> For practical purposes, the conversion is sane.
However, to ensure that it kicks in, you need to assign
it to an 'int' first before passing it in the printf
vararg. How a fprintf implementation snarfs elements
off of the 'va_list' is anyone's guess, but a fair one
is that it is format-string driven.
=> The behaviour of your program isn't well defined, but for
the same reason that "printf("%d\n", 1LL);" isn't (ignoring
the minor issue that long-longs really aren't std!)
--sigbjorn
Sven Panne <[EMAIL PROTECTED]> writes:
>
> My questions were:
> > What is the output of:
> >
> >#include
> >int main(void) { printf("%d\n", sizeof(sizeof(int))); return 0; }
> >
> > Is this portable at all?
>
> There was only *one* reply yet (via personal email), and, alas, it
> was not correct... >:-)
>
> Quoting Harbison/Steele's "C: A Reference Manual":
>
> * 7.5.2 sizeof Operator
>[...] In ANSI C the result of sizeof has the unsigned integer
>type size_t defined in the header file stddef.h. Traditional C
>implementations often use int or long as the result type [...].
>
> * 11.2 NULL, ptrdiff_t, size_t, offsetof, wchar_t
>[...] The type size_t is the unsigned integral type of the result
>of the sizeof operator --- probably unsigned long; pre-ANSI
>implementations use the (signed) type int for this purpose. [...]
>
> Especially note the "fun" words like "often" or "probably". The
> program prints 4 on Intel and HP-PA. It prints 8 on Alpha, but this
> only by pure luck: %d expects an int (= 4 bytes) and was passed a
> size_t = unsigned long = 8 bytes. If Alpha had another byte order,
> it would have printed 0.
>
> To make things even more confusing, consider integral promotion:
>
>int i, j;
>i = j * sizeof(...);
>
> You could lose some of your bits during assignment here. I guess we
> will all have much fun when Intel/HP release their Merced processor...
>
> 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: Bug (GHC 3.02)
Carlos Camarão <[EMAIL PROTECTED]> writes: > > > Compiling (under ghc 3.02) and running the following: > > -- > main = seq (putStrLn "xpto") (print "bug") > - > > produces: > > xpto > Segmentation fault caught, address = 8049a14 > Aborted Hi, ghc-n.xx (n < 4) cannot handle 'seq' over function values (which ((putStrLn "xpto"):: IO ()) is.) Fixed in ghc-4.00 and later. --sigbjorn
RE: Compiling HDirect under GHC on Sparc/Solaris
At the (minor) cost of dropping compatibility with 3.03, I've checked in a fix for this. Should appear overnight. --sigbjorn George Russell <[EMAIL PROTECTED]> writes: > > Currently (I have the latest version of everything) if I do > this naively it falls over because the Makefile contains ihc > commands and the code ihc produces contains _stdcall's, which > ghc doesn't seem to understand. If however I modify the ihc > commands to use -g, everything goes swimmingly. Am I doing > something wrong, and if not should the HDirect Makefiles be > fixed? >
RE: `foreign export dynamic' and return values
A 4.02 bug. A couple FFI related bugs were fixed
in the wake of the release of 4.02, and this looks
like it is one of them. Works fine with the current
sources.
--sigbjorn
[EMAIL PROTECTED] writes:
>
> When I return a value from a Haskell function called from C, in
> some cases the program SIGSEGVs. I guess it works when the value is
> "already computed", but fails otherwise. A compiler bug or my error?
> This is ghc-4.02, egcs-1.1.1.
>
> [qrczak ~/haskell]$ cat Main.hs
> {-# OPTIONS -#include "Mc.h" #-}
> module Main (main) where
> import Addr (Addr)
> call_h :: Int -> IO Int
> call_h n = do
> putStrLn $ show n
> return (n + 1) -- Here when I return simply 5 or n, it works!
> -- But it does not help to use seq:
> -- let k = n + 1; k `seq` return k
> main :: IO ()
> main = do
> putStrLn "BEFORE"
> h <- ch call_h
> call_c h
> putStrLn "AFTER"
> foreign import "call_c" call_c :: Addr -> IO ()
> foreign export dynamic ch :: (Int -> IO Int) -> IO Addr
>
> [qrczak ~/haskell]$ cat Mc.h
> void call_c (int (*f)(int));
>
> [qrczak ~/haskell]$ cat Mc.c
> #include
> void call_c (int (*f)(int))
> {
> int x;
> printf ("before\n");
> x = f (6);
> f (x);
> printf ("after\n");
> }
>
> [qrczak ~/haskell]$ ghc -c Main.hs -fglasgow-exts
> ghc: module version changed to 1; reason: no old .hi file
> [qrczak ~/haskell]$ gcc -c Mc.c
> [qrczak ~/haskell]$ ghc Main.o Main_stub.o Mc.o -o M
> [qrczak ~/haskell]$ ./M
> BEFORE
> before
> 6
> Segmentation fault
> [qrczak ~/haskell]$
>
> --
> __(" http://kki.net.pl/qrczak/
> \__/ GCS/M d- s+:-- a22 C+++>+++$ UL++>$ P+++
> L++>$ E-
> ^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++
> Y? PGP->+ t
> QRCZAK 5? X- R tv-- b+>++ DI D- G+ e> h!
> r--%>++ y-
>
RE: Unflushed output?
Thanks for the report - System.exitWith didn't shutdown the RTS in an orderly manner. Fixed. --sigbjorn Andy Gill <[EMAIL PROTECTED]> writes: > > The following program does not print Hello: > > import System > > main = die "Hello\n" > > die :: String -> IO () > die s = putStrLn s >> exitWith (ExitFailure 1) >
RE: Non-exhaustive patterns in HaskellDirect -fomg
George Russell <[EMAIL PROTECTED]> writes:
>
> The attached .tar.gz archive contains a set of IDL files (which I'm
> attempting to construct for PCTE, if you really want to know)
> and a file called "a", which is a script which invokes ihc (in the same
> directory) to compile the IDL files into GHC Haskell stubs.
> Unfortunately when I try to run "a", I get the following message:
> PpCore.lhs:375: Non-exhaustive patterns in function ppType
Missing coverage for couple of OMG IDL types ('any' and 'Object')
caused this, which I've now checked in a fix for.
You're processing Corba interfaces here, something that isn't
supported by HDirect - allthough I am planning to spend this
month hooking up with an ORB (Mico). There's a little bit of
support in there already though, add "--corba" to your HDirect
command line to pick this up.
The generated Haskell code will contain 'import OrbLib' decls
which contain the type and marshallers for a Corba object
reference. You can generate this module from the following
IDL spec:
// Compile as follows: ihc OrbLib.idl -fhs-to-c
[ty_args("a")]
interface Object{};
Of course, there's more to it than that if you want to comfortably
use the generated PCTE stubs from Haskell, but that's all the
support there is at the moment.
btw, I had to fix a couple of bugs in the PCTE specs to
make them compile cleanly - let me know if you want me to
send you the mods.
>
> Apologies if this is the wrong mailing list but unfortunately
> the HaskellDirect home page is still down, so I don't know what
> the right one is.
>
It's the right one (at least for now) - hopefully the /fp/ www
pages at Glasgow will be back up on-line again soon; afaik,
they're still trying to gather up the bits that spilled onto
the floor when they switched over to a new HTTP server.
--sigbjorn
RE: Problems with reading many files
[EMAIL PROTECTED] writes: > > Here is a program: > > import System > import Monad > import Char > import Directory > > main = do > let katalog = "/var/spool/news/articles/pl/rec/hihot" > nazwy <- getDirectoryContents katalog > let posty = map (\s -> katalog++'/':s) $ filter (all > isDigit) nazwy > r <- liftM concat $ mapM readFile $ posty > putStr r > exitWith ExitSuccess > ... > > The first question is how to prevent Haskell from opening all the > files before reading them? Quite - your problem stems from the use of monad combinators: r <- liftM concat $ mapM readFile $ posty mapM applies its first argument to all list elements of its second arg before returning the result - i.e., you need to open all files before you can start to print out the contents of the first one. That's probably not what you want to do here.. To fix, I'd suggest either encoding the recursion explicitly or defining a lazier version of mapM, e.g., interleavedMapM :: (Monad m) => (a -> m b) -> [a] -> m [b] interleavedMapM f [] = return [] interleavedMapM f (x:xs) = do y <- f x ys <- IOExts.unsafeInterleaveIO (interleavedMapM f xs) return (y:ys) > Besides this, there must be a bug in ghc. It shouldn't SIGSEGV. Can't say I disagree - trying to come up with a fix that gracefully handles the situation. Thanks for the report. --sigbjorn
RE: Can't compile HaskellDirect with GHC
Untested, but changing the occurrence of '-syslib exts' to '-fglasgow-exts' in the first setting of SRC_HC_OPTS in src/Makefile may just take you past this one.. --sigbjorn George Russell <[EMAIL PROTECTED]> writes: > > The latest GHC chokes on the latest HaskellDirect file src/Utils.lhs. > Here is a copy of error message and attached is the > src/Utils.lhs file. > It will be seen from the file that ghc is objecting to an explicit > universal quantification. What should I do? > > -- > -- > ===fptools== Recursively making `all' in src lib examples doc ... > PWD = /export/ger/fptools/hdirect > -- > -- > -- > -- > ==fptools== gmake all -r; > in /export/ger/fptools/hdirect/src > -- > -- > ../../ghc/driver/ghc -syslib exts -Rghc-timing -H16m -W > -recomp-O -O2-for-C -H30m -c Utils.lhs -o Utils.o -osuf o > ghc: ignoring heap-size-setting option (-H16m)...not the largest seen > Utils.lhs:345: parse error on input `.' > > Compilation had errors >
RE: Integer -> Int conversion
Andy Gill <[EMAIL PROTECTED]> writes:
>
> "Sigbjorn Finne (Intl Vendor)" wrote:
> >
> > Hi,
> >
> > there's difference in behaviour of how Integers are coerced Ints
> > between Hugs(98) and ghc.
> >
> >Prelude> (0x8000 :: Int)
> >
> >Program error: {primIntegerToInt 2147483648}
> >
> >Prelude> (maxBound::Int) + 1
> >-2147483648
> >Prelude>
> >
> > ghc's conversion of Integers is modulo maxInt, i.e.,
> >
> >(maxBound :: Int) + 1 == (0x8000::Int)
> >
> > is True.
> >
> > That's consistent & handy, but whatever the behaviour used, it'd be
> > oh-so convenient if the two implementations agreed.
>
> I think the current behavior of Hugs is reasonable.
>
If you're saying that non-catchable, run-time exceptions are ok,
I'm not at all sure I agree!
> The question is what should 0x8000 :: Integer
> become when its coerced into an int.
>
> GHC takes the lowest 32 bits.
> Advantage: Equality above maxBound still "works" aka above.
> Disadvantage: 0x + 1 == 0 !
>
> Perhaps constant Int's larger than maxBound (or smaller
> than minBound) should be a compile time error?
>
Int arithmetic is modulo maxBound (at least that's what
ghc and Hugs implements), so making the Integer->Int conversion
fall into line with that, has some merit.
--sigbjorn
RE: Can't compile HaskellDirect with GHC
George Russell <[EMAIL PROTECTED]> writes: > .. > ../../ghc/driver/ghc -fglasgow-exts -Rghc-timing -H16m -W > -recomp-O -O2-for-C -H30m -c Utils.lhs -o Utils.o -osuf o > ghc: ignoring heap-size-setting option (-H16m)...not the largest seen > Utils.lhs:22: parse error on input `(#' > > Compilation had errors > "s|(#|( #|g" - the parser thinks it's the start of an unboxed tuple, which is not the case here. --sigbjorn
RE: haskell-direct compilation problems
> Andrew Betts <[EMAIL PROTECTED]> writes:
>
> I'm having trouble compiling HaskellDirect - is there a Linux binary?
> or alternatively what's wrong here:
...
> /usr/local/bin/ghc -syslib
> exts -Rghc-timing -H16m -W -recomp -cpp
> -DBEGIN_NOT_HASKELL_98='{-' -DEND_N
> OT_HASKELL_98='-}' -DBEGIN_HASKELL_98='-}' -DEND_HASKELL_98='{-' -c
> GetOpt.lhs -o GetOpt.o -osuf o
>
> GetOpt.lhs:73:
> Utils.hi:22 Interface-file parse error;current input =
>
> GetOpt.lhs:73: Could not find valid interface file 'Utils'
>
Hi,
no binaries available, I'm afraid - but compiling from source
shouldn't be too painful.
>From the above, you appear to be either picking up an interface
file that was either produced with a different version of ghc or
it is just ill-formed. What's the version info of the ghc build
you're using?
--sigbjorn
Integer -> Int conversion
Hi,
there's difference in behaviour of how Integers are coerced Ints
between Hugs(98) and ghc.
Prelude> (0x8000 :: Int)
Program error: {primIntegerToInt 2147483648}
Prelude> (maxBound::Int) + 1
-2147483648
Prelude>
ghc's conversion of Integers is modulo maxInt, i.e.,
(maxBound :: Int) + 1 == (0x8000::Int)
is True.
That's consistent & handy, but whatever the behaviour used, it'd be
oh-so convenient if the two implementations agreed.
--sigbjorn
RE: getArgs delivers only emty Lists
Compile with -static if that behaviour bothers you. As is, there's no way to set RTS options from the command-line when you're using it in DLL form. --sigbjorn Meurig Sage <[EMAIL PROTECTED]> writes: > > >Hi, > > > >fix is available from > > > > http://www.dcs.gla.ac.uk/~sof/ghc-win32.html > > > >--sigbjorn > > > > The fix doesn't quite work. > Eg > > running > $ghc-4.03 -o main main.hs > $./main a b +RTS -H20M > ["a","b","+RTS","-H20M"] > > where main.hs is > > module Main where > import System > main = do > as <- getArgs > print as > >
RE: getArgs delivers only emty Lists
Hi,
fix is available from
http://www.dcs.gla.ac.uk/~sof/ghc-win32.html
--sigbjorn
Andreas Marth <[EMAIL PROTECTED]> writes:
>
> Hi,
> some after testing I discovered that the reason for why my program
> didn't anything after compiling it with ghc-4.03 was, that it gets an
> empty list from getArgs.
>
> I am running GHC under NT.
> At least the small program below did return [] no metter what
> arguments
> I passed.
>
> import System (getArgs)
>
> main=do { ps<-getArgs;
> putStr (show ps)}
>
>
> I thing this can also be the reason for the "bus error" from Robin Lee
> Powell.
>
> I hope You can fix this bug as fast as the otherone.
>
RE: Compilation problem with ghc-4.03 win32
Hard to say what's the cause without knowing more. However, combining code that uses the cygwin DLL (your Tcl/Tk installation) with code that doesn't (the ghc-compiled bits), is known to be troublesome in general. You may want to try to pick up another non-cygwin Tcl/Tk Win32 build & give it a go. --sigbjorn Meurig Sage <[EMAIL PROTECTED]> writes: > > > > >Add -mno-cygwin to the gcc command line when compiling any .c's. > > > >--sigbjorn > > > Thanks, that fixed the initial problem but now I've got another one. > Running the program causes it to crash with the application error: > The instruction at "0x77f6ce0c" referenced memory at "0x0010". The > memory could not be "written". > > This happens whether I compile with -static or without. > > To run it I use > ./tclexe ./main > > Where tclexe is the following > > - > #!/bin/sh > > # The root of the cygwin shared libraries. Allowing access to > Tk and Tcl. > > root=/ExtraUtils/cygnus/cygwin-b20/share > > export TK_LIBRARY TCL_LIBRARY > TK_LIBRARY=$root/tk8.0/ > TCL_LIBRARY=$root/tcl8.0/ > > exec "$@" > > --- > Thanks > Meurig > >
RE: Compilation problem with ghc-4.03 win32
Add -mno-cygwin to the gcc command line when compiling any .c's. --sigbjorn Meurig Sage [mailto:[EMAIL PROTECTED]] writes: > > Using the new ghc-4.03 binary snapshot on Windows NT I get > the following > problem compiling a file. > > gcc -c tclhaskell.c > ghc-4.03 -fglasgow-exts '-#include "tclhaskell.h"' -o main.exe Main.hs > tclhaskell.o -ltcl80 -ltk80 > > tclhaskell.o(.text+0x69):tclhaskell.c: undefined reference to > `_impure_ptr' > tclhaskell.o(.text+0x34b):tclhaskell.c: undefined reference > to `_impure_ptr' > tclhaskell.o(.text+0x3f2):tclhaskell.c: undefined reference > to `_impure_ptr' > tclhaskell.o(.text+0x450):tclhaskell.c: undefined reference > to `_impure_ptr' > tclhaskell.o(.text+0x487):tclhaskell.c: undefined reference > to `_impure_ptr' > tclhaskell.o(.text+0x51e):tclhaskell.c: more undefined references to > `_impure_ptr' follow > collect2: ld returned 1 exit status > > I also tried compiling with -static to see if it made any > difference but no > change. > > Compiling with ghc-4.02 works without problem. > > I've enclosed the necessary files. > > Thanks > Meurig > > >
RE: Unable to run main.hs example for win32 distribution
In case others are not having much luck getting cygwin and
ghc-4.03 set up - make sure that the list of files returned
when running 'ls /bin' from within bash, includes sh.exe and
perl.exe (as stated on the installation page).
Without either, the ghc driver script will fail in non-obvious
ways.
--sigbjorn
Erik Meijer <[EMAIL PROTECTED]> writes:
>
> After a smooth installation of GHC, I get an incomprehensible
> error message when trying to compile "Hello Workd!".
>
> ==
>
> bash-2.02$ ghc-4.03 -v -o main main.hs
> The Glorious Glasgow Haskell Compilation System, version
> 4.03, patchlevel 0
>
> Effective command line: -v -o main
>
> Ineffective C pre-processor:
> echo '{-# LINE 1 "main.hs" -}' > /tmp/ghc1026.cpp &&
> cat main.hs >>
> /tmp/ghc1026.cpp
> deleting... /tmp/ghc1026.cpp
>
> rm -f /tmp/ghc1026*
> bash-2.02$
>
> ==
>
> Erik Meijer
>
RE: Random.lhs broken in ghc-4.02?
Hi,
this is a known one - it's fixed in the repository version,
which I've attached to this msg.
hth
--sigbjorn
> Michael Weber [mailto:[EMAIL PROTECTED]] writes:
>
> Hi!
>
> Consider this:
>
> \begin{code}
> import Random
>
> main = do r <- randomRIO (6.0::Double,7.0::Double)
> putStrLn $ "Got " ++ (show r)
> getChar
> main
> \end{code}
> The output is in the interval [6.0..7.0], as expected.
>
> Now take
> \begin{code}
> import Random
>
> main = do r <- randomRIO (6::Integer,7::Integer)
> putStrLn (show r)
> getChar
> main
> \end{code}
>
> Output is in [0,1,2]! (because different type <-> different generator)
>
> This is clearly not, what one expects... :-)
>
> The cause seems to be randomIvalInteger. I didn't try to
> understand what
> _exactly_ it does, but the following fix makes it work more
> like I need it.
>
begin 600 Random.lhs
M)0T*)2`H8RD@5&AE($=205-0+T%154$@4')O:F5C="P@1VQA65R(&-A;&QE9"P@(D5F9FEC
M:65N="!A;F0@4&]R=&%B;&4@0V]M8FEN960-"E)A;F1O;2!.=6UB97(@1V5N
M97)A=&]R65R(&9OV-O9&5]#0IC;&%S
M'0-"B`@5]R96%D('(@;V8-"B`@("`@("!R0%M?72`M/B!R
M#0H@("`@("`@7R`@("T^(%MS=&1&5]R96%D('(@/2!D;PT*("`@("`@("`@*',Q+"!R,2D@/"T@RT-"B!)9B!W92!C86YN;W0@=6YR879E;"!T:&4@4W1D1V5N
M(&9R;VT@82!S=')I;F"`M/B!X("L@,R`J(&$I(#$@*&UA<"!OV-O
M9&5]#0H-"EQB96=I;GMC;V1E?0T*;6M3=&1'96X@.CH@26YT("T^(%-T9$=E
M;B`M+2!W:'D@;F]T($EN=&5G97(@/PT*;6M3=&1'96X@V-O9&5]#0H-"E1H92!C;&%S"QG)RD@/2!R86YD;VT@9PT*#0H@(')A;F1O
M;5)S(#HZ(%)A;F1O;4=E;B!G(#T^("AA+&$I("T^(&<@+3X@6V%=#0H@(')A
M;F1O;5)S(&EV86P@9R`]('@@.B!R86YD;VU2V-O9&5]#0II;G-T86YC92!286YD;VT@26YT('=H97)E#0H@(')A
M;F1O;5(@*&$L8BD@9R`](')A;F1O;4EV86Q);G1E9V5R("AT;TEN=&5G97(@
M82P@=&]);G1E9V5R(&(I(&<-"B`@"QG*2`M/B`H8VAR('@L(&"P@9RD@+3X@*&EN=#)";V]L('@L(&$)O=6YD*2!G#0H@#0II;G-T86YC92!286YD;VT@
M26YT96=E$)O=6YD.CI);G0I
M*2!G#0H-"FEN#HZ26YT*0T*"2`@("!I;@T*"2`@("`H@T*"0EZ("`@(#T@V-O9&5]#0H-"@T*
M7&)E9VEN>V-O9&5]#0IG;&]B86Q?V-O9&5]#0H=
`
end
RE: HaskellDirect-help
Xu Na <[EMAIL PROTECTED]> writes: > > > Dear Sir/Mdm, > > Although it is clearly stated in the ANNOUNCE file that > "To compile up HaskellDirect from source you'll need to > have GHC 4.03 (or later) installed on your machine.", > may I ask you the following questions? > > I have downloaded HaskellDirect (version 1.5). > But GHC 4.03 is not available on my machine. I only > have GHC 4.02 on it. > Do you think I can still use HaskellDirect 1.5 (with > only GHC 4.02)? > > By the way, is GHC 4.03 available at the moment? > It seems that I cannot find it on the web. > Hi, you don't say what platform you're working on, but I'm guessing it is not on a Win32 one (for which there is a 4.03 release). You'll have few problems compiling up the sources for the compiler with 4.02, but the libraries do depend on a couple of post ghc-4.02 changes to work. If you're feeling brave, you may just want to try to workaround them. --sigbjorn
RE: Show and function types in 4.03
Show over (->) is no longer Haskell(98). You need
to define your own, if you need it.
--sigbjorn
> Conal Elliott [mailto:[EMAIL PROTECTED]] writes:
>
>
> Did something change in 4.03 w.r.t. Show and functions? Mag stopped
> compiling:
>
> ghc-4.03 -c -O2 -fvia-C -O2-for-C -H20M UU_Pretty.hs
>
> UU_Pretty.hs:9:
> No instance for `Show (Int -> String -> String)'
> When deriving classes for `Format'
>
> Here's the code:
>
> data Format = Elem { height :: Int
> , last_w :: Int
> , total_w :: Int
> , txtstr :: Int -> String -> String
> }
> deriving Show
>
> - Conal
>
RE: ghc-4.02 picky about trailing whitespaces
[EMAIL PROTECTED] writes:
>
> Hi!
>
> ghc-4.02 seems to be picky about trailing spaces, i.e.
>
> {-# OPTIONS -fglasgow-exts #-}|<- EoLn
>
> is ok, but
>
> {-# OPTIONS -fglasgow-exts #-} |<- EoLn
>
> is not recognized... I don't think, that's a good idea...
>
>
Maybe not, fixed.
--sigbjorn
RE: ghc 4.02 compilation failure (linux i386 glibc)
Giuliano P Procida <[EMAIL PROTECTED]> writes: > > No improvement, I'm afraid. > > On Tue, May 18, 1999 at 01:16:01AM -0700, Sigbjorn Finne > (Intl Vendor) wrote: > > The fflush in shutdownHaskell() should not be required any longer - > > the behaviour it purports to work around is a non-issue to us now. > > > > Removing it and recompiling the RTS you're linking hsc with may > > just be a quicker plan of attack.. > > Easier said than done... it was a while before I realised > that removing the fflush and typing make just wasn't going to > hack it. This is because hsc is linked against the installed > libHSrts (argh! scream!) rather than the one just re-built. > The build remakes the fresh rts lib and re-links against the > old one -- almost certainly not what is intended. > That's the way it should be, really - how do you expect to successfully combine 4.03's RTS with ghc/compiler/ sources that has been compiled with 3.02 (say)? The RTS and the compiled code needs to agree 100% on the layout of heap objects, for example. If they don't, well, then you get crashes such as the one you're now experiencing with 'hsc' ;-) Sorry if this suggestion caused you more work - the opposite was my intention. --sigbjorn
RE: ghc 4.02 compilation failure (linux i386 glibc)
Giuliano P Procida <[EMAIL PROTECTED]> writes: > > On Mon, May 17, 1999 at 12:33:39PM -0700, Sigbjorn Finne > (Intl Vendor) wrote: > > It looks sensible, shutdownHaskell() is the last thing the > > RTS calls before exiting. Could it be that fflush() is failing > > since stdout hasn't been used? Does the following work OK > > They both work without trouble. I'll see what the glibc > maintainer says. > The fflush in shutdownHaskell() should not be required any longer - the behaviour it purports to work around is a non-issue to us now. Removing it and recompiling the RTS you're linking hsc with may just be a quicker plan of attack.. --sigbjorn
RE: ghc 4.02 compilation failure (linux i386 glibc)
Giuliano P Procida <[EMAIL PROTECTED]> writes:
>
...
>
> 08549690 :
> 8549690: e8 4b 26 00 00 call 854bce0
>
> 8549695: e8 26 23 00 00 call 854b9c0
> 854969a: 68 f0 32 5d 08 pushl $0x85d32f0
> 854969f: e8 d0 f9 af ff call 8049074 <_init+0x114>
> 85496a4: 83 c4 04addl $0x4,%esp
> 85496a7: c3 ret
>
> 08048f94 <.plt>:
> 8049074: ff 25 fc 30 5d 08 jmp*0x85d30fc
>
> (gdb) printf "%p\n" , (* 0x85d30fc)
> 0x40086920
>
> plt seems to be the C library's entry table and the address does
> correspond to fflush. I can only assume 0x85d32f0 is supposed to be a
> FILE *. (sfx: installs debugging C lib) Now I just have to look at:
>
> (gdb) bt
> #0 0x40066981 in _IO_fflush (fp=0x85d32f0) at iofflush.c:41
> #1 0x85496a4 in ()
>
> tomorrow. There have been other SEGV problems reported to the
> Debian BTS with regard to IO troubles with glibc2.1 (but that
> was C++). I'll report this as well. Can someone confirm that
> the shutdownHaskell thingum is not being silly?
>
It looks sensible, shutdownHaskell() is the last thing the
RTS calls before exiting. Could it be that fflush() is failing
since stdout hasn't been used? Does the following work OK
#include
int
main()
{
fflush(stdout);
return 0;
}
if it does, what about this
#include
int
main()
{
char msg[]="Hello";
write(1,msg,sizeof(msg)-1);
fflush(stdout);
return 0;
}
hth
--sigbjorn
RE: ghc 4.02 compilation failure (linux i386 glibc)
Giuliano P Procida <[EMAIL PROTECTED]> writes: > ... > This is the compiler in action! Earlier in the strace there is: > write(2, "R", 1)= 1 > write(2, "e", 1)= 1 > This is part of the byte-by-byte output of "** Reader:\n" I thought IO > output had been improved? Or has buffering been turned off altogeter? > You're writing on standard error here, which is unbuffered by default. In general, it's not clear how you could improve on the behaviour you're seeing with the way Haskell represents strings. > Is there much point in trying for a coredump? > > Other details: > > /dev/hda9 1988924 1141915744195 61% /home > /dev/hda6 248847 634235363 0% /tmp > 64M of RAM, 128M of swap > Linux henry 2.2.6 #5 Thu May 6 15:15:49 BST 1999 i686 unknown > GNU Make version 3.77, by Richard Stallman and Roland McGrath. > ldd (GNU libc) 2.1.1 > egcs-2.91.66 (1.1.2 source) > GNU ld 2.9.1 (binutils version) > The Glorious Glasgow Haskell Compilation System, version > 4.02, patchlevel 0 > Happy Version 1.5 Copyright (c) Andy Gill, Simon Marlow 1993-1997 > You're running a fairly bleeding edge kernel there, so that may have something to do with it. Have you run into any Signal13 troubles on that box? Other than that, I'm generally stumped as to why this is happening. You could try to run 'hsc' from within gdb to see where it is failing - compile PrelBase.o with -v to see the (long!) command-line that hsc gets passed. hth --sigbjorn
RE: Bug?
That's right, ghc's parser doesn't accept btypes here just atypes (cf. the report's grammar). Fixed in the new & upcoming parser. --sigbjorn Koen Claessen <[EMAIL PROTECTED]> writes: > > The following program gives errors with GHC-4.01: > > data Def f = String := f String > > I had to put parantheses around "f String": > > data Def f = String := (f String) > > I think this is a bug; Hugs and HBC accept it. > > Koen. > > -- > Koen Claessen, > [EMAIL PROTECTED], > http://www.cs.chalmers.se/~koen, > Chalmers University of Technology. >
RE: threadWaitRead/threadWaitWrite
George Russell <[EMAIL PROTECTED]> writes: > > I have some code which uses threadWaitRead and > threadWaitWrite which I'd like to make more portable. > Is it possible to approximate them in a way > which works for Hugs98 and Haskell 4.02? If not, as they > look fairly useful, could they be added to the standard > Concurrent module? > Support for these two are coming soon for ghc-4.xx. When there's a Hugs release out that also uses the new RTS, then it could quite easily have them too - supporting these prims on top of Hugs' current implementation of Conc. Haskell doesn't appear feasible. --sigbjorn
RE: BEGIN_HASKELL98_SYSTEM ignored?
Hi,
try augmenting your command-line with HASKELL98=YES
hth
--sigbjorn
Michael Weber <[EMAIL PROTECTED]> writes:
>
>
> Hi!
>
> Today I downloaded the green-card (current version) from
> their website and
> tried to compile it. ghc (4.03pre) complained about this fail
> <-> ioError function
> problem, but at the top of LexM.hs the source says:
>
> {- BEGIN_HASKELL98_SYSTEM
> fail = ioError
>END_HASKELL98_SYSTEM -}
>
> I had to explicitly s/fail/ioError/g to make it compile.
>
> Does the preprocessor ignore the BEGIN_HASKELL98_SYSTEM directive?
>
>
> Cheers,
> Michael
RE: GHC 4.02 install problem on Win95
Martin Dorr <[EMAIL PROTECTED]> writes: > > > I just installed GHC 4.02 binaries on Win95 and ran into a > little problem. After selecting 'make install' copying the > binaries errors out on 'hp2ps' not found because the .exe is > missing on the name in the file list (or incorrectly named > in the directory). A simple work-around is to update the > line 'PACKAGE_BINS = hp2ps' to include the .exe extension. > The installation script seems to run fine after this change. > Let me know if I should make additional changes > to get the installation right. > Thanks for the report; a bug allright. Your fix should do the trick - I've made similar modifications to the local sources. thanks, --sigbjorn
RE: green-card problem when using hugs
Nancy Day <[EMAIL PROTECTED]> writes: > > Hi -- > > I've been using green-card 2.0 with hugs version March 1999 (990319). > The .hs file that green-card generates imports the Prelude > qualified but uses the monad combinators (return, >>=) unqualified. > It's pretty easy to work around this problem, but it would be > good to fix it in the distribution. > Hi, I'm guessing you're using GreenCard to process something like the following: foo$ cat sin.gc module Sin where import qualified Prelude import StdDIS %fun sin :: Float -> Float foo$ and it is failing..? Yes, ideally, GreenCard should be able to handle that without incident, but it's a preprocessor and mostly unaware of the facilities of the Haskell module system. I don't propose to fix this, since Haskell98 goes a long way towards solving the underlying problem with its lazy reporting of name clashes, i.e., make the Prelude import unqualified and you *should* be OK...at least if you're using a Haskell98 compliant system. Neither ghc-4.02 nor the hugs98 snapshot (990319) I've got handles this correctly though, i.e., the following isn't accepted module Sin where sin :: Float -> Float sin x = x but should be with my interpretation of the relevant sections of the H98 report - both mentions of 'sin' can be unambiguously resolved. I've fixed this in the development sources for ghc, but, for now, you may just want to use "hiding" instead of "qualified" in your GC spec. Thanks for the (indirect!) bug report. --sigbjorn
RE: fromInteger/hClose bugs in 4.03
Hannah Schroeter <[EMAIL PROTECTED]> writes: > > Hello! > > [older mail] > > On Sun, Feb 21, 1999 at 11:47:40PM -0800, Sigbjorn Finne > (Intl Vendor) wrote: > > > Sven Panne <[EMAIL PROTECTED]> writes: > > > ... > > >* hClose on a semi-closed handle fails (4.02 has this > bug, too): > > > [...] > > > But that's not the case here. By the time you get around to doing > > the 'hClose', you've read to the end of the file and the semi-closed > > handle has been closed for you (cf. report.) > > That means if you have a program like this: > > main = do > h <- openFile ... > c <- hGetContents h > do_something c > hClose h > > You can't know whether the hClose is correct or not, except if it's > statically known whether do_something really uses up the > whole 'c' or not. > You can avoid that problem by ignoring any exceptions that hClose raises (alternatively, in a seq. program, check if the handle hasn't already been closed). However, hClose is baggage that people carry with them from other languages. In the vast majority, its use is unecessary since the garbage collector will properly close it once the handle becomes garbage. So, unless you rely on prompt closing and/or are using handles heavily, just don't use hClose. (Well, OK, the Haskell report doesn't promise you that handles are finalised, so this is ghc specific. Hopefully other implementations will pick this up though; not to have to do explicit handle management is preferable). The implementation of hClose has been changed since this Dark Corner was discovered, so calling hClose on a handle that is already closed is now a nop and not an error. --sigbjorn
RE: createPipe documentation error
Keith Wansbrough <[EMAIL PROTECTED]> writes: > > > I suspect this is a documentation error... > > Posix.createPipe returns two Fds, one for reading and one for > writing. > According to chapter 6 of the User Guide, they are (write,read); > according to the sources and a test program, they are (read,write). > > Just FYI. > But very useful I; thanks, fixed. --sigbjorn
RE: Green Card and Haskell 98 yet again
Hi, it's (still) in the process of being Released To Manifacturing (RTM) :), but http://www.dcs.gla.ac.uk/~sof/gc-2.0.tar.gz does contain the goods you're looking for. --sigbjorn George Russell <[EMAIL PROTECTED]> writes: > > This is getting to be a FAQ, but is anyone working on > upgrading Green Card to work for Haskell 98? Of course it > would be easy to hack it myself, but I'd very much rather be > able to use an official version. I would like to be able to > use Green Card with both GHC 4.02 and Hugs 98. >
RE: Haskell error, (fwd)
Looks like a bug, any chance of you sending us the sources that causes this? thx, --sigbjorn > Antony Bowers <[EMAIL PROTECTED]] writes: > > > OK, this might not be a bug, but could someone explain the > significance of the following runtime error: > > PTE: fatal error: scavenge_stack: UPDATE_FRAME updatee > > This is from an executable built with the ghc 4.03 SPARC binary > release (patchlevel 0) under Solaris 2.5. > > Is this an internal error, or just a general out-of-memory type > of thing? > > Thanks, > >Tony > > Antony Bowers, Department of Computer Science, University of > Bristol, UK. > http://www.cs.bris.ac.uk/~bowers/ > >
RE: Re^2: Extra output lines from trace.
Hi,
changing the default back to what it was wouldn't
be a problem, but would it be the Right Thing? My
take on this is that you can easily enough define
versions of 'trace' *in Haskell* that decorate their
stderr output, if IOExts.trace doesn't do any.
module Utils ( trace ) where
import IOExts as Std ( trace )
trace :: String -> a -> a
trace msg =
Std.trace ("Trace On:\n" ++ msg ++ "\nTrace off.\n")
As it was, you had to resort to overriding some low-level
C hook RTS procedures to get non-decorative trace msgs,
which somehow feels wrong to me - using C as your
extension language.
Hmm..I guess religious wars have been started for less? :)
--sigbjorn
> Marc van Dongen [mailto:[EMAIL PROTECTED]] writes:
>
> Hi there,
>
> This is related to at least two earlier
> messages in this forum which sadly enough I
> only noticed today.
>
> It probably is a feature that since then
> trace doesn't print Trace on/Trace off anymore.
>
> Is there any reason for not doing this
> anymore? In my opinion it makes tracing
> very awkward.
>
> People who don't want Trace on/off could
> always redirect stderr to stdout and use a
> grep -v Trace.
>
> Maybe adding a traceOnOff function?
>
>
> Regards,
>
>
>
> Marc
>
RE: Green Card problems
Zhanyong Wan <[EMAIL PROTECTED]> writes: > > Hello, > > I am compiling gc-v2-190199 with ghc 4.02, and find these problems: > > 1. due to incompitablitity with Haskell 98, LexM.lhs, Process.lhs and > StdDIS.hs won't compile, namely the definition of fail needs to be > modified. > 2. ghc runs out of heap when compiling Proc.lhs (I'm using NT + cygwin > 20b), so I change the line in src/Makefile: > Proc_HC_OPTS += -H8M > to > Proc_HC_OPTS += -H16M > Thanks, I hope to release GreenCard 2.0 over the next couple of days, which should fix these Haskell 98 related problems. If you want to start using it before then, http://www.dcs.gla.ac.uk/~sof/gc-2.0.tar.gz has got the sources (but no pre-generated docs). Let me know of any problems. hth --sigbjorn
RE: Compiling green card with nhc13
Simon Raahauge DeSantis <[EMAIL PROTECTED]> writes:
>
> I'm trying to compile GC with nhc13 on a NetBSD-1.3.2/sparc
> box, but I've run into a problem. Nhc chokes on Fillin.lhs thusly:
> xiamin@ghostpriest ~/gc-v2-190199 % gmake all
> gmake[1]: Entering directory `/home/xiamin/gc-v2-190199/src'
> /usr/local/bin/nhc13 -recomp -O -H8m-c FillIn.lhs -o FillIn.o
> In file ./FillIn.lhs:
> 118:4 Found _where_ expect {-EOF-}
Hi,
nhc only supports "where"s as part of toplevel definitions. That's
not really the issue here though, it looks as if it's getting the
layout rule wrong - decrease the indent of line 118 by three chars
and I think you should be OK.
Watch out for those non-toplevel "where"s when compiling the
rest (i.e., I don't test GreenCard with nhc & I like "where"
clauses :)
If the journey is successful, I'd really appreciate if you could send
me the diffs/list of changes made, and I'll apply them to the main
sources.
thanks,
--sigbjorn
RE: Question about Haskell-Direct
Shane Stephens <[EMAIL PROTECTED]> writes: > > I have an idea (which has probably already been had) - > Haskell seems to be extremely powerful in terms of defining > algorithms, but fairly light-on in terms of graphical output. > > Java, on the other hand, has a very nice OO-based graphical output > system, as well as some handy and easy-to-use networking/file-writing > capabilities. > > What I want to know is - what would be the best way to run a haskell > function as a method in a Java class? (And how would I do this...) > Hi, an alltogether Fine Idea this - the Java Native Interface (JNI) would be one way to go, accessing Haskell code via a native method. Wrapping the Haskell code up inside a COM component is another way (ok, I'm partially showing my colours here :) Employing CORBA is yet another. Claus Reinke has done quite a bit of work on integrating Haskell with Java through the JNI, see http://www.cs.nott.ac.uk/~czr/JNI/ I might be wrong about this, but the emphasis is there to use Java from Haskell, and not the other way around. In any case, there's bound to be lots of useful info/code in there to either build on or use. You probably already have, but to see how you can export Haskell functions to the outside world, have a look at the FFI doc at, http://www.dcs.gla.ac.uk/fp/software/hdirect/ hth --sigbjorn
RE: problem setting up GHC on Win32
Hi, /cygwin doesn't show up in the directory listing below, so I'm guessing it's c: (or wherever you've got Win95 installed). Try creating h:/tmp, and see if that fixes it. --sigbjorn Dion McMurtrie <[EMAIL PROTECTED]> writes: > > I tried this. The directory is there and accessable in > win95, but when I > > run the cygwin bash shell I still get the error message that the /tmp > > directory should be created. If I change directories to the > root directory > > and then try to chang into the tmp directory this happens - > > > > DETLOG.OLDahis.htm > DETLOG.TXTassignment1p95.rtf > Diablobin > Eudoracal98_ge.pdf > Exchange ffastun.ffa > FILE.CHK ffastun.ffl > Fitsh.c ffastun.ffo > IO.SYSffastun0.ffx > IO32.IDX ghc1015.hs > JGLBatchFileSetup.001 ghc1023.hs > MAKEFILE os1981.txt > MOUSE pk250w32.exe > MSDOS.--- single_0.sv > MSDOS.SYS single_1.sv > My Documents tmp > NETLOG.TXTv95i314e.zip > New Microsoft Publisher Document.pub > BASH.EXE-2.02$ pwd > / > BASH.EXE-2.02$ cd tmp > BASH.EXE-2.02$ pwd > / > BASH.EXE-2.02$ ls -l tmp > ls: tmp: No such file or directory > BASH.EXE-2.02$ >
RE: Sample code in User's Guide makes ghc "panic!"
Nobuo Yamashita <[EMAIL PROTECTED]> writes:
>
> (1) My environment
>
> % uname -a
> Linux nob 2.0.36 #6 Mon Mar 22 17:21:10 JST 1999 i686 unknown
>
> (2) My gcc
>
> % gcc --version
> 2.7.2.3
>
> (3) My code (is almost the same one in "The Glasgow Haskell Compiler
> User's Guide, Version 4.02" p51 section 5.4.1)
>
> % cat OldGetEnv.lhs
> > module OldGetEnv (oldGetEnv) where
> >
> > import IO
> > import Addr
> > import CCall
> > import PrelPack
> >
> > oldGetEnv :: String -> IO (Either String String)
> > oldGetEnv name = _casm_ ``%r = getenv((char *) %0);'' name
> >>= \ls@(A# str#)
> >-> return (
> > if (ls == A# ``NULL'') then
> > Left ("Fail:oldGetEnv:" ++ name)
> > else
> > Right (unpackCString# str#)
> > )
>
This is beautiful code! :)
> (4) What I did and what I got
>
> % ghc -v -c OldGetEnv.lhs -fvia-c -fglasgow-exts
> The Glorious Glasgow Haskell Compilation System, version
> 4.02, patchlevel 0
>
...
>
> panic! (the `impossible' happened):
> ERROR: ``literal-literal'' not a single-constructor
> type: NULL; type: PrelGHC.Addrzh{-31,s-}
>
> Please report it as a compiler bug to
> [EMAIL PROTECTED]
>
That's kind of embarrassing :-/ It's a bug (i.e., it should
compile), which I've now fixed in the development sources.
To have this example work with 4.02, I'd suggest rewriting
it as follows:
oldGetEnv :: String -> IO (Either String String)
oldGetEnv name =
_casm_ ``%r = getenv((char *) %0);'' name >>= \ str ->
if (str == nullAddr) then
return (Left ("Fail: oldGetEnv: " ++ name))
else
return (Right (unpackCString str))
Many thanks for reporting this,
--sigbjorn
FW: makefile errors for ghc 2.10 for irix-6.5
First attempt at posting this was unsuccessful, it seems.. --sigbjorn -Original Message- From: Sigbjorn Finne (Intl Vendor) Sent: Friday, March 26, 1999 08:56 To: 'Michelle Lujan' Cc: '[EMAIL PROTECTED]' Subject: RE: makefile errors for ghc 2.10 for irix-6.5 Hi, it looks as if you're using SGIs version of make; the GHC Makefiles uses various GNU make extensions, so you'll need it to compile the sources. hth, --sigbjorn Michelle Lujan <[EMAIL PROTECTED]> writes: > > > > Hi, > > I am trying to install GHC on a SGI running IRIX-6.5. > I am getting errors on my makefile even though I have > applied the patch as recommended on the web page. > These are the errors messages that I am getting when I > try to run the makefile created by the configure > script: > > > make: file `Makefile' line 149: Must be a separator (: or ::) > for rules > (bu39) > make: file `Makefile' line 149: Must be a separator (: or ::) > for rules > (bu39) > make: file `Makefile' line 166: Must be a separator (: or ::) > for rules > (bu39) > make: file `Makefile' line 185: Must be a separator (: or ::) > for rules > (bu39) > make: file `Makefile' line 193: Must be a separator (: or ::) > for rules > (bu39) > make: file `Makefile' line 195: Must be a separator (: or ::) > for rules > (bu39) > make: file `Makefile' line 195: Syntax error > > > I noticed that the errors appear on lines that contain a done; > > Can anyone be of any help? I would really appreciate anyone > who has any ideas. > > Thanks, > Michelle Lujan >
RE: GHC-4.03 heap managemen bug?
The compiler has got a space leak (and it's compiling Happy generated sources - a bad combination); compile ParseIface with -dcore-lint to fight it (for now). hth, --sigbjorn Michael V. Nikolaev <[EMAIL PROTECTED]> writes: > > Hi All, > > I were trying to build GHC-4.03 from the CVS repo (yesterday) > under cygwin on NT4, SP4 (egcs-1.1.2). > When it is built with GHC-4.02 all is OK. But, when I > installed the resulted GHC-4.03 and attempted to build it > again (with itself) the compilation failed as follows: > -- > ghc -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen > -InativeGen -Iparser > -iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSuga > r:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen > :absCSyn:main:reader:profiling:parser:nativeGen -recomp > -Onot -H45m -fno-warn-incomplete-patterns -c > rename/ParseIface.hs -o rename/ParseIface.o -osuf o > GHC's heap exhausted; > while trying to allocate 0 bytes in a 67108864-byte heap; > use the `-H' option to increase the total heap size. > make[2]: *** [rename/ParseIface.o] Error 1 > make[1]: *** [all] Error 1 > make: *** [all] Error 1 > -- > > The same result I had when heap size is increased (up to 60M). > > Perhaps, it is GHC heap management bug? > > Best regards, > Michael >
RE: 4.02: Module name Functorize can't be seen
Patrik Jansson <[EMAIL PROTECTED]> writes: > > A module named Functorize (with any content) is not found > when importing it from other modules. In the .hi file it > is called Functorizze (with two 'z')! Renaming the .hi file > to Functorizze.hi after compilation solves the problem with > compiling Main. Must be some strange name crunching error > somewhere. > Thanks for a fine report; this bug was fixed just after 4.02 went out the door. > The attached .tar.gz.uu file shows the problem well. > > Is there a work-around? It feels silly to have to change the > name of my module! > Why not use a British spelling? > Patrik Jansson > > PS. Your mail server refuses to handle .tar and .tar.gz MIME compliant > attachments, so this is my third try (I had to resort to > uuencode) to send this bug report. Have I done something > wrong or do you need to upgrade your mail server? > Yes, Glasgow does (and will do soon, I believe.) However, the mailing lists will move from Glasgow in the very near future, where these MIME-related bounces will hopefully be a thing of the past.. --Sigbjorn
RE: pragma spelling
[EMAIL PROTECTED] writes:
>
> ghc-4.02 understands {-# SPECIALIZE ... #-}
> and ignores {-# specialize ... #-}
>
> though the Haskell-98 report gives only the second name.
> Maybe, the same would be with `inline', `optimise'.
>
Yes, it could be handled better from a H98 point of view, ghc understands
all upper-case pragmas only - thanks, I've fixed this, i.e., inline,
notInline, speciali[sz]e are now handled, optimi[sz]e is not.
However, I would claim that ghc's non-compliance here is a feature,
not a bug ;) Capitalising your pragmas makes them stand out lexically,
which is a good idea for this sort of magic, IMO.
Idle Q re. {-# optimize .. -#}: is there any system out there supporting
it (or has there been)? ; anyone ever missed it not being supported in
ghc?
> ghc always tended to ingnore silently wrongly spelled pragmas.
> So, instead of fixing a typo, the programmer would think that
> such and such optimisation does not help.
>
Not quite, if the pragmas used follow the convention of being all
capitalised, the front end has warned you since Day 1 about
misspellings/unknowns. It's more liberal now though.
--Sigbjorn
RE: Fixity declaration of =<< missing in 4.03
Just to check this one off in my threaded mail folder...a fix for this was checked in last week (as a result of you reporting it.) Thanks, --Sigbjorn Sven Panne <[EMAIL PROTECTED]> writes: > > Just a small note: GHC-4.03's Prelude does not contain > >infixr 1 =<< > > as the report requires. > > Cheers, >Sven
RE: unsatisfactory diagnostic in GHC
Hmm. What's the version info? Compiles fine here with 4.02 & build
made from current CVS repo sources (as it should, btw.)
> P.S.: The "lookupBindC:no info!"-bug from Feb 22nd is still in
> yesterday's GHC... :-(
Not forgotten, but fixing this is part of a larger compiler change
to better handle enumeration types.
--Sigbjorn
Sven Panne writes:
>
> Anyone who thinks that Hugs' diagnostic messages are unsatisfactory
> should try the following snippet with GHC::-)
>
> ---
> module Foo where
> import Posix(fdToHandle)
> bar = fdToHandle ``0''-- ``0'' should be: (intToFd ``0'')
> ---
> panne@liesl:~ > ghc -fglasgow-exts -syslib posix -c Foo.hs
>
> panic! (the `impossible' happened):
> ERROR: ``literal-literal'' not a single-constructor
> type: 0; type: PosixUtil.Fd{-rD4,j-}
>
> Please report it as a compiler bug to
> [EMAIL PROTECTED]
> ---
>
> In the real program the ``0'' was actually something more complicated,
> of course.
>
> Cheers,
>Sven
>
> P.S.: The "lookupBindC:no info!"-bug from Feb 22nd is still in
> yesterday's GHC... :-(
>
> --
> 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.pms.informatik.uni-muenchen.de/mitarbeiter/panne
>
RE: HaskellDirect
Paul Roe <[EMAIL PROTECTED]> writes:
>
> Hi,
>
> I'm trying to generate an automation interface for Outlook 98 using
> HaskellDirect, but I'm encountering the following error:
>
> C:\HaskellDirect\0.13\proe>..\ihc.exe msoutl85.idl -o
> msoutl85.hs -fcom
> -fno-export-list -fno-gen-enum-marshallers -foleview-input
> -fnogenbinary-interface -ftreat-importlibs-as-imports
> -fcoalesce-methods
> +RTS -H16M
> autoTypeToQName: unknown auto type struct stdole2.idl.TagGUID {
>unsigned long data1;
>unsigned short data2;
>unsigned short data3;
>char[8] data4;
> }
>
> I generated the idl using oleview (v2.10.054 April 11 98) and
> I'm using
> HaskellDirect (snapshot 021298) on Win NT 4.0 sp4. I'm not
> very familiar
> with COM and automation, is there anything which I'm
> obviously doing wrong?
Hi,
I haven't tried to reproduce this with 0.13, but with my dev.
copy, the following
./ihc --tlb '/Program Files/Microsoft Office/Office/msoutl85.olb' \
-fautomation -fno-import-lists -fno-qualified-instance-methods
generates HaskellScript-likeable code.
Maybe that will work with 0.13? If not,
http://www.dcs.gla.ac.uk/~sof/outlook.zip
contains the generated stubs.
> My goal is to drive MS Outlook 98 using hugscript.
Sounds great; good luck.
--Sigbjorn
RE: Mutable arrays
> Sven Panne [mailto:[EMAIL PROTECTED]] writes: > > The types of the mutable array operations are a little bit messy, e.g. > >writeCharArray :: Ix ix => MutableByteArray s ix -> ix -> > Char -> ST s () > > but > >writeWord8Array :: MutableByteArray RealWorld Int -> Int > -> Word8 -> IO () > > The type one expects for the last example would be something like > >writeWord8Array :: Ix ix => MutableByteArray s ix -> ix -> > Word8 -> ST s () > > The user guide states even more confusing types for the Word/Int ops. > It would be nice if all operations were in the same monad (I don't > really care which one, ST or IO) and were indexed in the same way. > The sigs in the user's guide are the intended ones (modulo you replacing ix with Int for the index args), never got around to lifting the Int* and Word* ones into ST. Does anyone actually use these ops?!? --Sigbjorn
RE: Readline in ghc-4.02
> [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] writes: > > Hi! > > The Readline.hi file is missing in the i386-linux-glibc > binary distribution of ghc-4.02pl0. > .. > -- > -- > ==fptools== make way=p all; > PWD = /mnt/sda5/src/fptools/ghc/lib/std > -- > -- > rm -f Array.p_o ; if [ ! -d Array ]; then mkdir Array; else > find Array -name > '*.p_o' -print | xargs rm -f __rm_food ; fi ; > ../../../ghc/driver/ghc -recomp -cpp -fglasgow-exts -fvia-C > -Rghc-timing -O > -split-objs -odir Array -hisuf p_hi -prof -GPrelude -c Array.lhs -o > Array.p_o -osuf p_o > > Array.lhs:41: Could not find valid interface file Ix' > > Array.lhs:42: Could not find valid interface file PrelList' > > Array.lhs:43: Could not find valid interface file PrelArr' > > Array.lhs:44: Could not find valid interface file PrelBase' > > Compilation had errors > > make[1]: *** [Array.p_o] Error 1 > make: *** [all] Error 1 > > > Ix.hi *does* exist! > Yes, but it's looking for Ix.p_hi here! :) To fix, either add GhcLibWays= to your mk/build.mk (it's trying to build profiling libs, which isn't supported in 4.02), or do make depend all hth, --Sigbjorn
RE: bug in Random.lhs
Thanks, fixed. --Sigbjorn > Martin Stein <[EMAIL PROTECTED]> writes: > > Hi, > > there's a little bug in randomIvalInteger of Random.lhs (ghc-4.02): > > | otherwise = case (f n 1 rng) of (v, rng') -> > (fromInteger (v `mod` (k+1)), rng') > where >k = h - l + 1 > > should be something like > > | otherwise = case (f n 1 rng) of (v, rng') -> > (fromInteger (v `mod` (k+1)+l), rng') > where > >k = h - l + 1 > > Martin Stein >
RE: ghc-4.02: Class 'Functor' does not have a method 'map'
Hi, yes - Haskell98 did, see http://haskell.org/definition/ --Sigbjorn > Joachim Schmid [mailto:[EMAIL PROTECTED]] writes: > > I'am using cygwin b20.1 and the binary distribution ghc-4.02 > for Windows > NT. > > Compiling the program > > module Main where > > data D a = D a > > instance Functor D where > map f (D a) = D (f a) > > main :: IO () > main = return () > > leads to the strange error > > > Main.hs:6 > > Warning: No explicit method nor default method for 'fmap' > > in an instance declaration for 'Functor' > > > > Main.hs:6: Class 'Functor' does not have a method 'map' > > Has anybody renamed 'map' to 'fmap'? >
RE: bad html file in doc
Mircea Draghicescu <[EMAIL PROTECTED]> writes: > > users_guide.html is corrupted. I downloaded the NT > InstallShield distribution of 4.02. > Other doc files seem OK. > Yes, not very readable at all :) http://www.dcs.gla.ac.uk/~sof/ghc-win32/users_guide.html contains the version that should have been included, replace it with the one you've got. btw, the title page claims that it is for 4.03, please ignore. Thanks, --Sigbjorn
RE: Problem running ghc-4.02 on Win-NT 4.0
Brian Rogoff <[EMAIL PROTECTED]> writes:
>
> Hi,
> Pentium II box, downloaded the self-extracting archive. Cygnus
> B20.1 bash shell. Perl 5.003_07, located in c:/perl/bin.
>
> Any Haskell code I try to compile yields the error message
>
> :0:25: Character literal '{-# LINE 1 "main.hs" -}' too long
> :0:25: on input: "'"
>
> Any idea why this happens? I followed the install
> instructions exactly.
>
Hi,
what 'kind' of perl are you using? ActiveState's? Try using the
one that comes with ghc binary distribution instead.
[I'm suspecting that the perl binary you're using employs cmd.exe
when performing system() calls. It has a different notion of
quoting to what the driver assumes, hence the error. I could be
wrong about that though..]
--Sigbjorn
RE: .hi problem with existentially quantified type variables
Thanks; fixed. --Sigbjorn Manuel M. T. Chakravarty <[EMAIL PROTECTED]> writes: > > I encountered a problem with existentially quantified type > variables (yes, they can really be useful ;-) when they > appear in a .hi file in GHC 4.01. > > Taking the following module > > module T (T) > where > > data T = forall a. T a (a -> Int) > > which is imported by > > import T > > main = putStr "oops" > > I get > > nomi chak 57 (~/haskell): ghc-4.01 -c T.hs > ghc-4.01: module version changed to 1; reason: no old .hi file > nomi chak 58 (~/haskell): ghc-4.01 -c bug.hs > > bug.hs:1: T.hi:6 Interface-file parse error; toks= [] > > bug.hs:1: Could not find valid interface file `T' > ...
Compiling ghc sources with egcs (was: .hi problem with existentia lly quantified type variables)
I claim that the ghc-4.02 sources and later does now work with
egcs-1.1 and beyond, at least on x86's. I've been happily using
it for about a month. No need for these vile driver hacks any
longer.
--Sigbjorn
> Sven Panne [mailto:[EMAIL PROTECTED]] writes:
>
> [ Aaaargl, 2nd try: The ancient mailer at Glasgow didn't like my
>MIME-attachment. >:-( ]
>
> "Manuel M. T. Chakravarty" wrote:
> > I encountered a problem with existentially quantified type variables
> > [...] I couldn't check whether the problem persists in GHC 4.02,
>
> Alas, it's even in yesterday's ghc-4.03 from CVS.
>
> > as I am still in the middle of compiling it. It seems as if - at
> > least for Linux - the heap size is too small for many of the library
> > modules. Sven, did you have the same problem? (Or can it
> > be a problem that I compiled the compiler proper with 3.02?)
>
> I'm always compiling ghc with the latest installed version, e.g.
> Friday's ghc is compiled with Thursday's. Additionally, hsc
> is compiled
> with -O, so I can't comment on non-optimised builds. My RPM patch file
> is appended. But on Linux you can always use the pre-built RPMS on
>
>ftp://ftp.informatik.uni-muenchen.de/pub/local/pms/
>
> BTW, I'd like to get some feedback from RedHat users: Byron Hale
> reported some problems with the Hugs RPM (the dynamic linker tells
> someting about an undefined symbol __register_frame_info).
> Success/Failure stories are highly welcome.
>
> Cheers,
>Sven
>
> --
> -
> diff -uNr fptools.orig/ghc/driver/ghc.lprl fptools/ghc/driver/ghc.lprl
> --- fptools.orig/ghc/driver/ghc.lprlWed Feb 17 11:48:06 1999
> +++ fptools/ghc/driver/ghc.lprl Tue Feb 23 13:40:19 1999
> @@ -245,6 +245,12 @@
>
> \begin{code}
> $CcRegd= $GHC_OPT_HILEV_ASM;
> +
> +# SUP: SuSE 6.0 uses an egcs/gcc-mix, but ghc is currently
> incompatible with
> +# egcs (the binaries produce segmentation faults
> occasionaly), so we force gcc.
> +$gcc2723dir = "/usr/lib/gcc-lib/i486-linux/2.7.2.3/";
> +$CcRegd .= " -B" . $gcc2723dir if (-x $gcc2723dir . "cc1");
> +
> @CcBoth_flags = ('-S','-Wimplicit'); # flags for *any* C
> compilation
> @CcInjects = ();
>
> diff -uNr fptools.orig/mk/build.mk fptools/mk/build.mk
> --- fptools.orig/mk/build.mkThu Jan 1 01:00:00 1970
> +++ fptools/mk/build.mk Wed Feb 17 15:46:09 1999
> @@ -0,0 +1,3 @@
> +WithGhcHc = ghc
> +SRC_HC_OPTS += -optCrts-M52M -O
> +rename/ParseIface_HC_OPTS += -optCrts-M77M
> --
> -
> --
> 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.pms.informatik.uni-muenchen.de/mitarbeiter/panne
>
RE: ";" after empty implementation
[EMAIL PROTECTED] writes:
>
> ghc-4.02 denies ";" in the program
>
> --
> module M (g) where
> import N
>
> ;
> --
>
> where N is any module exporting g.
>
> This improves when we insert before ";"a Space
> or a line f = 'a'
>
>
Thanks, the behaviour you're seeing boils down to the fact that
the 4.02 parser doesn't actually allow empty declarations on
the left. That is,
decl
is accepted but
;;;decl
isn't. They both should be, and this has now been fixed.
With the fix in, you can now write stuff like
module M where {;;x=let{y=2}in y;;}
--Sigbjorn
RE: fromInteger/hClose bugs in 4.03
Sven Panne <[EMAIL PROTECTED]> writes:
>
...
>* hClose on a semi-closed handle fails (4.02 has this bug, too):
>
> import IO
> main = do
>h <- openFile "/etc/passwd" ReadMode
>c <- hGetContents h
>putStr c
>hClose h
>
> Transcript:
>
> root:x:0:0:root:/root:/bin/bash
> bin:x:1:1:bin:/bin:/bin/bash
> [...]
> Fail: illegal operation
> Action: hClose
> Handle: {closed}
> Reason: handle is closed
>
> According to the library report, closing a semi-closed handle
> should be allowed.
>
But that's not the case here. By the time you get around to doing
the 'hClose', you've read to the end of the file and the semi-closed
handle has been closed for you (cf. report.)
--Sigbjorn
RE: problem with -o and header file names.
> P.C.Callaghan [mailto:[EMAIL PROTECTED]] writes: > > > When compiling with a line like this: > > > ghc-4.03 -syslib posix -syslib exts -dshow-passes -ddump-spec > > -fwarn-incomplete-patterns -fwarn-unused-binds -hi-diffs > -cpp -H60M -K4M > > -Onot -c -o X.o X.a.hs > > - where the intention is that module "X" from file X.a.hs > should be compiled in to X.o, the header file created gets the > wrong name (the module id is duplicated): > > > X.X.hi > Fixed, but what kind of filename for a module is that?!? 1/2 :-) --Sigbjorn
RE: waitQSemN bug
> Michael Hobbs [mailto:[EMAIL PROTECTED]] writes: > > I was browsing through the source for Semaphore.lhs when I > noticed a bug in the implementation for waitQSemN. If I understand > the workings and semantics correctly, the value of 'avail' specifies > how many resources are available and the value of 'sz' specifies > the number of resources requested by the caller. The bug is that > the code only checks to see "if avail > 0" instead of checking > "if avail >= sz" when it decides whether or not to grant access to > the resource. Also, when it updates the value of 'avail', it sets it > to "avail-1" instead of "avail-sz". Yep, spot on; fixed. Here's the version I've got now: waitQSemN :: QSemN -> Int -> IO () waitQSemN (QSemN sem) sz = do (avail,blocked) <- takeMVar sem -- gain ex. access if (avail - sz) > 0 then -- discharging 'sz' still leaves the semaphore -- in an 'unblocked' state. putMVar sem (avail-sz,[]) else do block <- newEmptyMVar putMVar sem (avail, blocked++[(sz,block)]) takeMVar block Thanks, --Sigbjorn
RE: empty export in ghc-4.02
[EMAIL PROTECTED] writes: > > ghc-4.02 -c T.hsyields T.hs:1:11: parse error on input: ")" > > for > - > module T () where > > ng1 x y = negate y > > instance (Num a, Num b) => Num (a,b) > where > negate (a,b) = (ng 'c' a, ng1 'c' b) where ng x y = negate y > - > > This is against Haskell-98, is it? > Yup, fixed. > Further, change this `()' to `(ng1)'. > Then the compiler does not warn of un-used variable x in the `negate' > definition. Setting `-fwarn-unused-matches' does not help. > Though, the ghc-4.02 docs mentions this un-used warning facility. > Thanks, a bug. For now, use '-fwarn-unused-binds -fwarn-unused-matches' to have the compiler produce these warnings. Or -Wall. --Sigbjorn
RE: ghc-4.02 garbage collector problem and others
Thomas Hallgren <[EMAIL PROTECTED]> writes: > ... > I also encoutered another small problem resulting in > compilation errors like > > SizingF.hs:9: Could not find valid interface file `Sizing' > > which seems to happen whenever an imported module has a name > containing the letter 'z'. From looking in the interface files, > it seems that z is used as some kind of escape character... > I managed to work around this by using symbolic links, e.g., > > ln -s Sizing.hi Sizzing.hi > Thanks for the report; fixed. --ZZigbjorn
RE: Couldn't find isAlphaNum
Weird - are you sure it was capitalised as Haskell now prescribes?
sar$ cat x.hs
module X where { import Char (isAlphaNum) ; x = isAlphaNum }
sar$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 4.02, patchlevel 0
sar$ ghc -noC x.hs
sar$
--Sigbjorn
> David Barton [mailto:[EMAIL PROTECTED]] writes:
>
> While running the new 4.02 on a Linux box, I got a "could not find
> isAlphaNum" error. I looked at the .hi file, and it seemed OK;
> however, switching to the definition of the expressions using
> "isAlpha" and "isDigit" solved the problem. Don't know what's wrong,
> but
>
> Dave Barton <*>
> [EMAIL PROTECTED] )0(
> http://www.averstar.com/~dlb
>
RE: Small problem...
Hmm..the configure script tests that are looking for the end markers to the text and data segments are failing, for mysterious reasons. Could you send me the contents of your config.log so that I can have a look? Thanks, --Sigbjorn > Alex Ferguson [mailto:[EMAIL PROTECTED]] writes: > > > As per usual, this is sun-sparc-solaris, and 4.02 (which > didn't _appear_ > to have any trouble compiling its own libraries... > > Slan, > Alex. > __ > > > bowen.ucc.ie:~/LVO: cat hi.hs > .. > Undefined first referenced > symbol in file > dunno_what_it_is > /usr/local/ghc-4.02/lib/libHSrts.a(Schedule.o) > ld: fatal: Symbol referencing errors. No output written to a.out >
RE: Automatic Makefile dependencies
> Michael Hobbs [mailto:[EMAIL PROTECTED]] writes: > > Even with GHC 4.02 I've noticed that 'ghc -M' always adds one too many > newlines into the Makefile. The large gap gets to be pretty > obnoxious if you run 'make depend' several times. > Good point, thanks for reporting this (I normally use a separate .depend file where this isn't a problem). Fixed. --Sigbjorn
RE: A continuing saga: foreign export dynamic
Sven Panne <[EMAIL PROTECTED]> writes: > > Simon Peyton-Jones wrote: > > [ My problems with f. e. d. omitted ] > > This works ok with the current contents of the repository. > > Alas, it does not. with a *really* current ghc I still get > the same panic. > Fixed now, I believe. > Another point: The name mangling for the "profiled way" of compilation > seems broken (in this case for the identifier '..'): > Should compile ok now, but the compiled code is of limited use - profiling under 4.0x is not yet working. > > And a final point: Readline.lhs is still unpatched. > done. --Sigbjorn
RE: Buggy implementation of exististential types?
Thanks for the report - I'm able to repro this one with 4.01, but the bug has subsequently been fixed (seem to remember a bug report going past concerning this a while ago, but I'm unable to locate it right now.) Anyway, fixed in 4.02 (as well.) --Sigbjorn Thomas Hallgren [mailto:[EMAIL PROTECTED]] writes: > > Hi, > > I enclose a small program that crashes with "segmentation fault" when > compiled with ghc 4.01. It makes use of existential quantification in > data types, which I suspect is the cause of the problem. > > I also supply the output from ghc -v. > > The program was compiled and run on a macine with the > following uname -a > output: > > SunOS lips.cs.chalmers.se 5.6 Generic_105181-11 sun4u sparc > SUNW,Ultra-4 > > and gcc -v gives > > Reading specs from > /usr/pd/gnu/lib/ada/3.10p/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2/specs > gcc version 2.8.1 > > This may look a little ad hoc, but when I tried our normal > installation > of gcc, > > Reading specs from > /usr/pd/gnu/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs > gcc version 2.8.1 > > all programs crashed with "bus error"... > > Regards, > Thomas Hallgren >
RE: deriving Enum broken
Thanks; fixed. --Sigbjorn
> Sven Panne [mailto:[EMAIL PROTECTED]] writes:
>
> The following (admittedly rather small :-) fragment from Manuel's
> GTK+-binding fails to compile with ghc-4.02:
>
> -- Foo.hs --
> module Foo where
> data Bar = Baz deriving Enum
>
> panne@liesl:~ > ghc -c Foo.hs
>
> panic! (the `impossible' happened):
> tcLookupValue: PrelBase.zg{-rRR,j-}
>
> Please report it as a compiler bug to
> [EMAIL PROTECTED]
>
>
> Using -O is even more confusing:
>
>
> panne@liesl:~ > ghc -c Foo.hs -O
> Foo.hs:2:
> No instance for `Ord Int' arising from use of `>=' at Foo.hs:2
>
> Foo.hs:2:
> No instance for `Ord Bar' arising from use of `>' at Foo.hs:2
>
>
> The problems vanish if 'deriving Enum' is replaced with 'deriving
> (Eq,Ord,Enum)'. An old ghc-3.02 works, too.
>
> 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.pms.informatik.uni-muenchen.de/mitarbeiter/panne
>
RE: Increasing max. heap size during compilation
Frank A. Christoph <[EMAIL PROTECTED]> writes: > > Since the -M option has been co-opted for other purposes by > the ghc Perl startup script, and you can't pass explicit RTS > options to the compiler itself (why isn't this allowed?), > it's impossible to compile modules which need more than 64MB > of heap space. (64mb is the default maximum for the new > automated heap-growing.) For example, on my Linux > installation, ParseIFace.lhs needs something like 72MB to > compile, so I had to alter the startup script to pass an > extra -M72mb when compiling that file with the 4.02 compiler > itself. (BTW, can we expect the compiler to be a less > memory-intensive when it is released?) > Use -optCrts to feed options to the RTS of the compiler, i.e., -optCrts-M72M --Sigbjorn
RE: What's in a name...
Thanks, fixed ^ 4. (Name mangling + proper derived Show/Read instances for infix constructors.) --Sigbjorn Sven Panne <[EMAIL PROTECTED]> writes: > > The following program prints "ZCze 1 2" (usual setup: Linux, ghc-4.02 > from the repository): > >data Foo = Int := Int deriving Show >main = print (1 := 2) > > Even more strange things go on with names here (file Baz.hs): > >module Baz where >data TheZigAndZagShow = Zig | Zag > > Compilation yields a file Bazz.hi (??) with the content: > >__interface Bazz 1 402 where > > Aversion to singleton z's? :-) > > Cheers, >Sven > --
RE: threadDelay in 4.01?
There's no threadDelay (nor threadWait{Read,Write}) in 4.xx,
I'm afraid - yet to be implemented.
--Sigbjorn
> Tommy Thorn [mailto:[EMAIL PROTECTED]] writes:
>
> I might have overlooked something, but I couldn't find the
> (documented) threadDelay function in GHC 4.01. Could anyone
> enligthen
> me please? I'm trying to compile one of my 3.02 applications that
> make use of it.
>
> Thanks in advance,
> Tommy
>
RE: FiniteMap.lhs
Yes, the changes that's required are minor - the hdirect and green-card sources contain versions of FiniteMap that should be likeable to Hugs. Re: Kevin's Q on why FiniteMap isn't in the common Hugs/GHC libraries - we're (still!) waiting for a Collections library design that Chris Okasaki and Simon PJ was/is working on, which'll supercede current versions of FiniteMap and friends. --Sigbjorn Frank A. Christoph [mailto:[EMAIL PROTECTED]] writes: > > >I wish to use the FiniteMap module, lib/exts/FiniteMap.lhs, but want > >to use it from both GHC and hugs. As it is hugs can't use it because > >it imports PrelBase. (btw, why didn't it make it into the joint > >GHC/Hugs Libraries? - seems v. useful). > > > >As far as I can see this can be fixed by placing the import PrelBase > >in an IF_GHC macro, and moving the definition of the macro above the > >import. Or have I missed something (I haven't got as far as > using the > >finite maps in anger yet, so maybe) > > I'm pretty sure I was able to use FiniteMap with Hugs once > before with one or two simple modifications. I don't know > about PrelBase---I think you can just delete the import---, > but there is no Maybes module in Hugs. FM only uses one > function though, maybeToBool, so you can just add that to the > module and it should compile(provided you preprocess it or > enable the CPP option in Hugs). > > --FC > >
RE: ghc 2.10/HPUX: PerformGC_wrapper unsatisfied symbol
Hmm..that linker error does seem faintly familiar. The
2.10 mangler is to blame; try applying the attached
patch to ghc-asm.prl (you'll probably have to do
this manually rather than with 'patch', but it
should hopefully be clear what changes are required.)
Having done so, you'll need to recompile "stuff".
I can't remember if this bug requires you to
recompile the 2.10 prelude; run 'nm' over the Prelude
archive (libHS.a) looking for the unbound data
section symbols to find out. If not, then you
'only' need to recompile whateve sources that showed up
the problem in the first place.
Perhaps others on this list have more pertinent info on
what to do to get ghc-{2,3,4}xx working successfully under
HPUX? It's been 2 years+ since I last tried to build ghc
on that platform.
--Sigbjorn
Arne Glenstrup <[EMAIL PROTECTED]> writes:
>
> Hi,
>
>
> Running the glorious ghc 2.10 on our glorious hp700pa1ux10, I
> was taken
> aback by the terrible and rather rude words:
>
> collect2: ld returned 1 exit status
> /usr/ccs/bin/ld: Unsatisfied symbols:
>PerformGC_wrapper (data)
>Ind_info (data)
> /usr/ccs/bin/ld: (Warning) Linker features were used that may not be
> supported in future releases. The +vallcompatwarnings option
> can be used
> to display more details, and the ld(1) man page contains additional
> information. This warning can be suppressed with the
> +vnocompatwarnings
> option.
>
> How do I again make my world a glorious place??? :-) :-) :-)
>
> --Arne
begin 600 hpux-2.10-patch
M*BHJ(&=H8R]D#`Y*"XJ*5Q<7%QX,#`G.PT*("`@
M("`@)%1?1$]47U=/4D0)("`@(#T@)UPN=V]R9"<[#0H@("`@("`D5%]$3U1?
M1TQ/0D%,("`@/2`G7EQS*UPN15A03U)4)SL-"BTM+2`Y,"PY-"`M+2TM#0H@
M("`@("`D5%]#3U!97T1)4E93("`@/2`G7EQS*UPN*$E-4$]25'Q%6%!/4E0I
M)SL-"B`@#0HA("`@("`D5%]HC`M.5\N72]:
M6B]G.R`C(%1O1&\Z('!R;W!E2!)1"!H87,@8F5E;B!T=7)N960@:6YT;PT**R`)
M"2,@82!R97!R97-E;G1A8FQE('-Y;6)O;"P@=V4@2!A9F9E8W0@=&AE
M(&-O9&4@;W5T<'5T(&]N(&]T:&5R('!L871F;W)M)%154UM`73]G:&,N*F-?240D5%!/4U1,0DPO)&-O
M;G-I
RE: Interface parse error
Thanks, fixed. (no, this is not a robot replying :) --Sigbjorn
> Sven Panne [mailto:[EMAIL PROTECTED]] writes:
>
> Just when you thought it's weekend: :-)
> Here's another bug in the upcoming 4.02:
>
> -- Argl.hs --
> import System
> main = exitFailure
> -
> panne@fangatau: > ghc-4.02 Argl.hs -O
>
> panic! (the `impossible' happened):
> IdInfo parse failed exitFailure
>
> /mnt/fangatau1/svens-ghc-test/ghc-4.02/lib/ghc-4.02/imports/st
> d/System.hi:59 Interface-file parse error; current input =
>
> Please report it as a compiler bug to
> [EMAIL PROTECTED]
> -
>
> Without -O everything is fine. Just for fun the offending line from
> System.hi:
>
>1 exitFailure :: __forall [a] => PrelIOBase.IO a {-## __A
> 1 __u \ __a a -> __coerce (PrelIOBase.IO a) (\ _115 ::
> (PrelGHC.State# PrelGHC.RealWorld) -> case __ccall_GC exit
> {__a (PrelGHC.State# PrelGHC.RealWorld -> PrelGHC.Int# -> (#
> PrelGHC.State# PrelGHC.RealWorld #)) _115 1} of wild { (# ds
> #) -> __coerce (# PrelGHC.State# PrelGHC.RealWorld, a #)
> (PrelException.ioError __a a _108_118_1084) }) ##-} ;
>
> 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.pms.informatik.uni-muenchen.de/mitarbeiter/panne
>
RE: GHC-4.02 buglets
Sven Panne writes: > > Only some minor things (at least for now >:-) : > >* ghc -cpp -M (i.e. mkdependHS) does not remove the *.i files > Thanks, fixed. >* warnings about unused names are often bogus, e.g. in the > following fragment of a Lx-generated scanner: > This is a known problem - I believe it's being worked on. --Sigbjorn
RE: panic! (the `impossible' happened)
Thanks for the report, fixed in (the upcoming) 4.02
release. For now, stay away from using guards on tuple
patterns.
--Sigbjorn
<[EMAIL PROTECTED]> writes:
>
> Hi,
>
> I received the following error while compiling via:
>
> /usr/local/bin/ghc-4.01 -cpp -syslib posix -syslib misc
> -fglasgow-exts -fvia-C -I. -ilts -iutils -ibasics -iccs
> -imain -ipa -ilogic -ihdirect -inoobj -Rghc-timing -H40m
> -recomp -Iincludes -Iincludes/cbits -pgmcgcc-2.7.2
> -DBEGIN_GHC_ONLY='-}' -DEND_GHC_ONLY='{-'
> -DBEGIN_NOT_FOR_GHC='{-' -DEND_NOT_FOR_GHC='-}'
> -DELSE_FOR_GHC='-}-}' -c main/Main.lhs -o main/Main.o
>
> panic! (the `impossible' happened):
> dsExpr: tuple pattern:
> let { fail = patError __a (IO ()) __string "Main.lhs:540|case"
> } in
> case d7zE of B1 { (nstates, ntrans) ->
> case > nstates a4lL of B1 {
> True -> displaySizeResult outh sty id nstates ntrans;
> False -> fail
> }
> }
>
> Please report it as a compiler bug to
> [EMAIL PROTECTED]
>
> The part around line 540 of Main.lhs is
> size rest menv@(MkMainEnv inh outh sty us penv muenv
> idenv actenv msize pt showt davinci )
> = readId rest menv >>= \ maybe_id ->
> case maybe_id of
> Nothing -> driver_loop menv
> Just id -> forkComputation (do_it id)
> (driver_loop menv)
> where do_it id = case sizeCWB msize penv
> (makeProcFromId id)
> of (nstates, ntrans) | nstates > 0
> -> displaySizeResult outh sty id nstates ntrans
>
> where the line 540 is the line with "where"
>
> What's wrong??
>
> Best regards,
>
> Martin
RE: Again: foreign export trouble
Thanks, fixed. --Sigbjorn Sven Panne <[EMAIL PROTECTED]> writes: > > ... this time with today's ghc-4.02: There is a name clash when > multiple foreign export dynamics are used within a module: > > --- > module Blah where > import Addr > foreign export ccall dynamic mkFooCallback :: IO () -> IO Addr > foreign export ccall dynamic mkBarCallback :: IO () -> IO Addr > --- > panne@liesl: > ghc -fglasgow-exts -recomp -Wall -O -c Blah.hs > ghc: module version changed to 1; reason: no old .hi file > /tmp/ghc31110.hc:215: redefinition of `Blah_ds_closure' > /tmp/ghc31110.hc:115: `Blah_ds_closure' previously defined here > /tmp/ghc31110.hc:289: redefinition of `Blah_ds_info' > /tmp/ghc31110.hc:189: `Blah_ds_info' previously defined here > /tmp/ghc31110.hc:290: redefinition of `Blah_ds_entry' > /tmp/ghc31110.hc:190: `Blah_ds_entry' previously defined here > /tmp/ghc31110.hc:300: redefinition of `Blah_ds_fast1' > /tmp/ghc31110.hc:200: `Blah_ds_fast1' previously defined here > --- > > 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.pms.informatik.uni-muenchen.de/mitarbeiter/panne >
RE: Discrepancy in HDirect Web page?
Byron Hale <[EMAIL PROTECTED]> writes: > > Hi- > > The HDirect Web page says: > > The current version of HaskellDirect is 0.14 (released 6/12/98.) It is > freely available in both source and binary formats: > > > Source dist > Win32 installer," > > but the Win32 installer is marked as 0.13. > > Is this significant? > Hi, the difference between 0.13 and 0.14 is minor, 0.14 fixes a couple of bugs in the compiler's implementation of a dimly lit (if not dark) corner of IDL. I've been meaning to bring the Win32 installer bang up to date, but have instead started working on 0.15, which I hope to have ready soon. --Sigbjorn
RE: Greencard with Hugs
Hi,
many thanks for the useful feedback. I've uploaded a
new Green Card snapshot which tidies up a couple of
the Hugs related problems you were having, at least
I hope so.
I've added a paragraph to the INSTALL notes describing
how to use Green Card together with Hugs only, i.e.,
how to avoid having to install ghc just for the sake
of compiling up the Green Card sources.
The user's manual has been updated in places and the
sources have also been readied for the upcoming Haskell 98.
See Green Card home page for download links
http://www.dcs.gla.ac.uk/fp/software/green-card/
(For those that care, I've also uploaded a new snapshot
of the Win32 API binding that Hugs and GHC uses.)
--Sigbjorn
Mark Utting <[EMAIL PROTECTED]> writes:
>
>
> I previously reported (to the glasgow-haskell-bugs mailing list)
> problems installing Greencard for Hugs.
>
> I have now solved those problems, and have a working interface
> from Hugs to mSQL (a simple SQL-based database client/server system).
> (I'm posting this to the Hugs users list as well, to encourage other
> Hugs users to develop Greencard interfaces.)
>
> Here are the steps that I had to follow to get Greencard
> working with Hugs (under Linux i386). Please include some
> of these comments in the greencard installation guide etc. if
> you think they will help other Hugs-Greencard users.
>
>* install ghc!(it was not obvious at all to me that I had
> to do this. But, perhaps I would not have to if
> the "binary bundles" on the Greencard web page
> were available? Anyway, I think the
> documentation
> should say that you need ghc to build
> greencard).
>
>* make greencard (using ghc)
>1. In greencard's top-level Makefile, I set FOR_SYSTEM=hugs
> and set HC to point to ghc, as the INSTALL
> instructions said.
>2. Then do 'make'
>3. link/copy ./src/green-card into /usr/local/bin (or similar)
>4. In ./lib/hugs, the Makefile says that it is incomplete.
> So, add the following rule to it
> (and add StdDIS.so into the 'all' target):
>
> StdDIS.so: StdDIS.c
> gcc -shared -o StdDIS.so -I
> /usr/local/hugs/src StdDIS.c
>
>5. Also, in ./lib/hugs, StdDIS.gc exports mkForeignObj but
> does not define it. Remove this from the export list.
> (This seems to be a bug in StdDIS.gc ? )
>
>6. Do 'make' in ./lib/hugs.
>
>* set my own Makefile up with the correct include and
> library paths.
> For example, I ran greencard as:
>
> green-card --target hugs --include-dir
> $(GCHOME)/lib/hugs MSQL.gc
>
> and to compile the generated .c files (say MSQL.c), I used:
>
> gcc -shared -o MSQL.so -I /usr/local/hugs/src MSQL.c
>
>
> Just for everyone's entertainment, here is a simple example
> program that uses Hugs-mSQL, and the output that it produces.
>
> --
> -- This takes an SQL 'where' expression (we) and displays the
> -- first_names it produces. It uses the emp_details relation
> -- in the 'testdb' database, on the local server.
>
> query :: String -> IO ()
> query we
> = do sock <- msqlConnect ""
> msqlSelectDB sock "testdb"
> n <- msqlQuery sock ("select first_name from
> emp_details where " ++ we)
> putStrLn (show n ++ " rows returned.")
> res <- msqlStoreResult
> -- we could find out how many columns were returned
> (1 in fact),
> -- but I will output more to show how robust msqlData is.
> putStrLn (unlines [show [msqlData res r c | c <- [0..4]]
> | r <- [0..n-1]])
> --
> TestMSQL> query "emp_id > 500"
> ["David","","","",""]
> ["Mark","","","",""]
> --
>
>
> I must say that in spite of these teething problems, I am
> *very* impressed with Greencard. I am now confident that I
> can go away and interface Hugs to my coffee-maker, my MIDI
> keyboard and anything else that takes my fancy. Hopefully
> my students will enjoy the resulting capabilities of Hugs too!
>
> Thanks!
> Mark.
>
> Dr Mark Utting, Senior Lecturer
> Department of Computer Science
> School of Computing and Mathematical Sciences
> The University of Waikato Tel: +64 7 838 4791
> Private Bag 3105 Fax: +64 7 838 4155
> Hamilton Email: [EMAIL PROTECTED]
> New Zealand Web:
> http://www.cs.waikato.ac.nz/~marku
>
> The highest bandwidth
> output from a human is the notes pouring
> from a concert pianist's fingers.
>
RE: Problem with file path
Thanks - fixed in the next release. If you cannot wait,
change the "if ($Specific_hi_file eq '') { ... } " in
the constructNewHiFile sub in ghc-iface.prl (you'll
find that inside lib/ in a binary dist) to
if ($Specific_hi_file eq '') { # -ohi is used even if module name != stem
of filename.
($hiname = $hifile_target) = $1 if $hifile_target =~
/\/?([^\/\.]+)\.$HiSuffix/;
if ($ModuleName{'new'} ne $hiname) {
($hidir = $hifile_target) =~ s/(.*)$hiname\.$HiSuffix/$1/;
$hifile_target = $hidir . $ModuleName{'new'} . ".$HiSuffix";
}
}
Outlook will probably do its outmost to mess up the above
paragraph, but hopefully it's clear what's changed.
--Sigbjorn
Mircea Draghicescu <[EMAIL PROTECTED]> writes:
>
> See below. Thanks.
> Mircea
>
> ~/temp 87: ghc -o main main.hs
> ghc: module version changed to 1; reason: no old .hi file
> ~/temp 89: mkdir a
> ~/temp 90: mkdir a/b
> ~/temp 91: cp main.hs a/b
> ~/temp 92: ghc -o main a/b/main.hs
> ghc: module version changed to 1; reason: no old .hi file
> cp: cannot create regular file `b/Main.hi': No such file or directory
> ~/temp 93: mkdir b
> ~/temp 94: ghc -o main a/b/main.hs
> ghc: module version changed to 1; reason: no old .hi file
> ~/temp 95: ls b
> Main.hi
> ~/temp 96:
>
RE: GHC 4.01 FFI bugs
Manuel M. T. Chakravarty <[EMAIL PROTECTED]> writes: > > > > --(2) foreign import ccall "" "bar" bar :: IO Int64 > > > > > > > this can be reduced to > > > > foreign import "bar" bar :: IO Int64 > > So, `ccall' is the default? (This is not documented, I think.) > There's been some changes relatively recently, making the calling convention optional and dropping the requirement that a 'foreign import'ed function has got to be an IO action, i.e., you can now write foreign import "sin" my_sin :: Float -> Float I'll see if I can put up a new version of the spec which reflects these changes. > > > main = do > > > foo (intToInt8 8) (intToInt16 16) (intToInt32 32) > > > (intToInt64 64) > > > --(2)_ <- bar > > > return () > > > > > > The first problem is that `Int8', `Int16', and `Int32' are > > > all implemented by the same C data type, namely the one > > > represented by `I_' in the HC file -- this makes all of them > > > 32 bit `signed int' on my Pentium machine. The generated HC > > > code for the call to `foo' is > > > > > > > ghc does not currently make any attempts to provide and use a > > mapping from the Int* Haskell types onto equivalent C types. > > Why? Mainly because an Int8 is just represented as a differently > > boxed Int# - i.e., there's no sized Ints at the level of > > unboxed types. > > > > You may get some warnings when compiling the above "foo", but > > the right coercions will be inserted, no? > > It works with gcc on my Pentium, but I think it is pure > luck. Unfortunately, I don't have a C reference manual at > the moment, but I think to recall that C doesn't do any > coercions during parameter passing -- it *definitely* won't > do any coercions if you don't supply a function prototype. > It works on my box only because gcc on the Pentium always > pushes a full 4-byte word even if you only pass a > character. > The type promotions that apply when passing params in C are those that apply when assigning, i.e., void shorty(short x); short s; int i; s = i; shorty(i); I'm not so sure that it wouldn't work without prototypes, K&R C managed fine without them. However, maybe modern ABIs do now assume the presence of parameter type info to get things right all the time.. > This may prove quite tricky to define in the FFI spec in a > portable manner -- but I guess, you are already aware of > that. > Yes, it probably won't work with a native codegen either. It needs to be addressed at some stage by ghc. > BTW, I saw in some of the extended libraries that the Hugs > code uses ".so" arguments for the external > locations. I was wondering whether it wouldn't be more > portable if the external location could be specified without > the file suffix `.so'. The suffix may depend on the OS; > omitting it in the foreign declaration, would allow the FFI > to add the standard suffix of the OS. Of course, when the > name refers to a standard library, this name is probably > also OS dependent, but in the case where the library is part > of the package that includes the Haskell code, it might be > possible to save some of the ugly preprocessor directives. > Indeed - I believe Alastair faintly agrees with this, just that he didn't get around to implementing it. I'll add something about this to the spec - thanks for bringing it up. --Sigbjorn
