- Glasgow-haskell-users

RE: ghc-5.02.2
by Simon Peyton-Jones 19 Dec '01

19 Dec '01

"in due course" is a native English way of saying "I'm not quite sure" :-) We are planning a release before Christmas. Whether we will actually get it out in the next 3 days remains to be seen, but if not then it'll be early in the new year. Simon | -----Original Message----- | From: Sven Eric Panitz [mailto:sep@softwareag.com] | Sent: 19 December 2001 10:41 | To: glasgow-haskell-users(a)haskell.org | Subject: ghc-5.02.2 | | | | Some time ago Simon Peyton-Jones posted on this list: | 'We will do 5.02.2 in due course' | | Being not a native English speaker, I am not sure about all | subleties of the English language; I wonder what time frame | 'in due course' indicates? Are there any concrete plans, when | ghc-5.02.2 will be available? | | (otherwise I might seek the thrill of compiling ghc from cvs | sources ...) | | | hope this does not sound too much like nagging | | Sven Eric | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0

Re: Optimization and GCC?
by Marcin 'Qrczak' Kowalczyk 19 Dec '01

19 Dec '01

Wed, 19 Dec 2001 09:56:36 +0100, Till Doerges <till(a)doerges.net> pisze: > /u/joe/built/lib/ghc-5.00.2/includes/Regs.h:255: warning: call-clobbered register used for global register variable I don't know about this one. > /tmp/ghc15733.hc:5391: warning: deprecated initialization of zero-length array > /tmp/ghc15733.hc:5391: warning: (near initialization for `Main_main_closure.payload') This is already fixed in CVS. ghc3 is not officially supported yet. Nevertheless I'm using it at home and it can successfully compile almost everything from ghc on ix86. This is my mk/build.mk - I'm compiling three files with gcc-2.95.3: ProjectsToBuild = glafp-utils ghc hslibs happy PrimOps_HC_OPTS = -pgmcgcc-2.95.3 ArrayBase_HC_OPTS = -pgmcgcc-2.95.3 PosixTTY_HC_OPTS = -pgmcgcc-2.95.3 This was for gcc-3.0.1 and ghc a few weeks ago. I'll see if it's better now, with gcc-3.0.2. The problem with PrimOps looked like gcc bug, as if it ignored -fomit-frame-pointer for this file. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ QRCZAK

1 0

ghc-5.02.2
by Sven Eric Panitz 19 Dec '01

19 Dec '01

Some time ago Simon Peyton-Jones posted on this list: 'We will do 5.02.2 in due course' Being not a native English speaker, I am not sure about all subleties of the English language; I wonder what time frame 'in due course' indicates? Are there any concrete plans, when ghc-5.02.2 will be available? (otherwise I might seek the thrill of compiling ghc from cvs sources ...) hope this does not sound too much like nagging Sven Eric

1 0

RE: converting to & from unboxed types
by Simon Marlow 19 Dec '01

19 Dec '01

> > I'm sure this is common knowledge but I can't find it > anywhere in the ghc > docs. How do you take, say, an Integer and "unbox" it and > get an Int# or > something? import GlaExts unbox :: Int -> Int# unbox (I# i) = i box :: Int# -> Int box i = I# i Cheers, Simon

1 0

Re: ghc image size
by Albert Lai 19 Dec '01

19 Dec '01

Mike Gunter <m(a)ryangunter.com> writes: > Why is executable size a barrier? 1.64 megabytes (that's the size of > the executable I built with GHC most recently) of disk space costs less > than half a cent. I don't like this argument. Can I go to a computer store, pay a cent, and get a hard disk with space 1.64 megabytes or more? Until then, I can't believe that 1.64 megabytes of disk space costs less than half a cent. When a compiler does not perform as good as other compilers (e.g., in terms of generated code size), it is important to ask: Why does it happen? Is there anything we can do to improve it? Being critical is the first step towards progress. (Of course these questions should be asked in a constructive rather than whining way.) Why would anyone optimize code for time --- a second of electricity and labour cost less than a cent...

3 2

RE: ghc image size
by Simon Marlow 19 Dec '01

19 Dec '01

> Mike Gunter <m(a)ryangunter.com> writes: > > > Why is executable size a barrier? 1.64 megabytes (that's > the size of > > the executable I built with GHC most recently) of disk > space costs less > > than half a cent. > > I don't like this argument. Can I go to a computer store, pay a cent, > and get a hard disk with space 1.64 megabytes or more? Until then, I > can't believe that 1.64 megabytes of disk space costs less than half a > cent. > > When a compiler does not perform as good as other compilers (e.g., in > terms of generated code size), it is important to ask: Why does it > happen? Is there anything we can do to improve it? Being critical is > the first step towards progress. (Of course these questions should be > asked in a constructive rather than whining way.) Why would anyone > optimize code for time --- a second of electricity and labour cost > less than a cent... Of course, we're always looking for ways to reduce the size of binaries. But the situation might not be as bad as you think; firstly, don't forget to strip the binary if you're worried about disk space, since the symbol table in a GHC-generated binary can be quite large (it doesn't affect the runtime or anything else, though). The subject of shared libraries has come up several times in the past - take a look through the archives for some of the previous discussions. The upshot is that shared libraries wouldn't really buy much unless you really need to save the disk space: in all other considerations, static linking comes out better. Unfortunately GHC-compiled libraries are very tightly coupled, which means it's unlikely you'd be able to swap out a shared library for a newer version unless it was compiled with *exactly* the same compiler and set of libraries as the old version. Cheers, Simon

1 0

Optimization and GCC?
by Till Doerges 19 Dec '01

19 Dec '01

Hello everybody, I've got some trouble compiling haskell-code on a sparc system. As soon as I use the option '-O', ghc starts spilling messages like these: --- snip --- [...] /u/joe/built/lib/ghc-5.00.2/includes/Regs.h:255: warning: call-clobbered register used for global register variable [...] /tmp/ghc15733.hc:5391: warning: deprecated initialization of zero-length array /tmp/ghc15733.hc:5391: warning: (near initialization for `Main_main_closure.payload') [...] --- snap --- The 2nd type occurs way more often, but it doesn't look really bad. What I'm more worried about is the first. To use an already used register? Perhaps anyone could explain these messages to me? It seems, however, that the code produced is okay. Things get worse, if I try to use gcc for code-generation. The messages *seem* to remain the same. Invocation of ghc is basically the same as above, w/ '-fvia-C -O2-for-C' added: --- snip --- mai00dqr@userv1:~/Diplom/cls/src> make /u/joe/built/bin/ghc-5.00.2 -O -fvia-C -O2-for-C -cpp -DBEGIN_GHC_ONLY='-}' -DEND_GHC_ONLY='{-' -DBEGIN_HUGS_ONLY='{-' -DEND_HUGS_ONLY='-}' -package text -package util -i../lib/parsec-250101 -i/u/joe/built/lib/ghc-5.00.2/imports -lncurses --make Main -o cls ghc-5.00.2: chasing modules from: Main [...] --- snap --- The code generated now definitely is not okay: --- snip --- mai00dqr@userv1:~/Diplom/cls/src> ./cls Segmentation Fault --- snap --- Here's what I'm using: --- snip --- mai00dqr@userv1:~> gcc --version 3.0.2 mai00dqr@userv1:~> uname -a SunOS userv1 5.8 Generic_108528-12 sun4u sparc SUNW,Ultra-80 --- snap --- Is the segmentation fault perhaps related to an interoperability between ghc and the latest gcc-versions? On a Linux-machine using the same ghc-version but gcc-2.96 '-O -fvia-C -O2-for-C' doesn't cause any problems (neither does it cause any messages like the above ones). If it is a problem related to the version of gcc, how do I tell ghc which version to use? I only know how to do that on the commandline. Any hints would be greatly appreciated. Bye -- Till -- e-mail: reverse(net dot doerges at till) | ENCRYPTED | pgp/gpg: keys via keyserver or my homepage | MAIL IS | www: http://www.doerges.net | WELCOME! |

1 0

ANN (bis): Release 0.1 of Haskell/Java VM Bridge
by Ashley Yakeley 19 Dec '01

19 Dec '01

OK, the SourceForge file release system bug has been fixed, so I put the release files up there. Please download from there rather than from semantic.org. <http://sourceforge.net/project/showfiles.php?group_id=32318&release_id=654 34> Revised, expanded announcement... ------- The first release, 0.1, of Haskell/Java VM Bridge is now available. Haskell/Java VM Bridge allows Haskell programs access to the Java Virtual Machine. Features include: * Calling of Java methods, access to fields, array-handling; * Integration of garbage collectors; * Reconciliation of exception models; * Reconciliation of thread models, including 'synchronized' monitor support and the ability to fork Haskell actions as Java threads; * Strong typing for Java classes and method argument lists (as tuples), and use of Haskell lists as arrays; * Creation of Java classes 'on the fly' (using DefineClass and the Java Class File Format) that can have Haskell callback methods; * Lifted monads which do all the necessary JNI class and method/field ID preloading and 'JNIEnv'-pointer variable handling for you -- these can be automatically generated via a tool (MakeJVMModule); * Layered design includes lower-level IO-based interface; * Automatic generation of modules for Java API classes; * All relevant imports, flags and libraries etc. handled by a single GHC package 'javavm'; * No 'unsafe' Haskell calls or pure function FFI anywhere. This release should be 'beta' quality, but has undergone little testing. You will need: * An x86 machine running some form of Unix; * GHC 5.02 or later; * The appropriate JVM, installed in the appropriate place: - IBM JDK/JRE 1.3 for x86, installed in /usr/lib/ibm-java/IBMJava2-13/ - Blackdown Port of Sun's JRE 1.3/Sun JDK 1.3 for x86, installed in /usr/lib/j2sdk1.3/ and /usr/lib/j2re1.3/ No documentation is currently available, sorry. Two examples have been included: a trivial "hello world" program, and a program that shows a Java Frame containing an instance of a Haskell-defined subclass of Canvas that has a Haskell 'paint' method that draws an oval. You should be able to figure out most of it from that... and of course the source is available from SourceForge CVS. <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jvm-bridge/source/> Be sure to download the correct .tar.gz file for your Java VM. Simple installation instructions are included in the file. <http://sourceforge.net/project/showfiles.php?group_id=32318&release_id=654 34> Haskell/JVM Bridge and source code is licensed under the GNU Lesser GPL. <http://sourceforge.net/projects/jvm-bridge/> Future plans: * documentation * port to Cygwin * port to Darwin/OS X (waiting on GHC) * use of Java 1.4 API (waiting on Sun, though use of beta versions is possible) -- Ashley Yakeley, Seattle WA

1 0

converting to & from unboxed types
by Hal Daume III 18 Dec '01

18 Dec '01

I'm sure this is common knowledge but I can't find it anywhere in the ghc docs. How do you take, say, an Integer and "unbox" it and get an Int# or something? - Hal

1 0

RE: ghc-5.02 refuses to open a device file
by Simon Marlow 18 Dec '01

18 Dec '01

> I guess it's a [mis]feature, since 5.00 worked, but can hardly > imagine anybody could need it. > > ======= > Prelude> h<-IO.openFile "/dev/zero" IO.ReadMode > *** Exception: unsupported operation > Action: openFile > Reason: unknown file type > File: /dev/rtf0 > Prelude> Leaving GHCi. > max@max$cat /dev/zero > <C-C> > ======= Thanks; will be fixed in 5.02.2. Cheers, Simon

1 0