- Glasgow-haskell-users

ANNOUNCE: hsclock-0.01.0 release
by Jens-Ulrik Petersen 18 Dec '01

18 Dec '01

I am pleased to announce the initial release of hsclock, another gtk+hs "applet" I've written. hsclock is an accurate multi-zone gtk clock, which can also run in a tty. hsclock uses gtk timeouts to synchronise the time updates to occur on the second or minute "tick" (dependent on the clock format string), making display updates accurate to within milliseconds. More info, source and rpm's are available at: http://www.01.246.ne.jp/~juhp/haskell/hsclock/ As usual feedback and comments welcome. Enjoy, Jens

1 0

GHC 5.02 source RPM
by Arjen P. de Vries 18 Dec '01

18 Dec '01

Hi, does anyone know how to solve the following problem? I build the ghc from the source RPM, and everything goes fine up to creating the binary rpms as final result, but then it does not want to install the created binary rpm, due to dependency on error: failed dependencies: /usr/local/bin/perl is needed by ghc-5.02.1-1 I tried to fix it in the SPEC file, but could not find where the Requirement on /usr/local/bin/perl is specified (it does not seem to be there). BTW, I do have a /usr/local/bin/perl but apparently rpm does not understand; of course, after --nodeps it installs, but I need to solve the dependency problem since I also use apt. Tnx for any clues, Arjen ==================================================================== CWI, room C0.11 Centre for Mathematics and Computer Science Kruislaan 413 Email: Arjen.de.Vries(a)cwi.nl 1098 SJ Amsterdam tel: +31-(0)20-5924306 The Netherlands fax: +31-(0)20-5924312 ===================== http://www.cwi.nl/~arjen/ ====================

2 1

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

17 Dec '01

> if you are using GNU tools there is some magic to make them > garbage-collect all the symbols in your executable before > outputting the > final code. you have to do some tricks with the segment > headers so that > it can GC individual functions but this should fix many of the image > size problems at least in some cases. I agree that the GHC image sizes > are a problem. This is something we'd like to do, but haven't got around to. It's not just a case of adding the correct flags to gcc/ld unfortunately: GHC's assembly mangler needs to be taught how to generate the unique section names for each function. But then it's possible that we could remove the grotty -split-objs stuff that we use to split the libraries into small pieces. Cheers, Simon > John > > On Fri, Dec 14, 2001 at 01:28:20PM +0100, Jan de Wit wrote: > > Hi, > > > > > I just recently starting to use the ghc compiler and am > astonished by the > > > size of the executables. Out of interest, why are they so > large? Is there > > > any work in progress to make the resulting > executable/object somewhat more > > > "normal" in size? > > > > > > I read in the Haskell mailing list archives discussions > relating to > > reducing > > > the barriers to broader acceptance of functional > programming by the > > general > > > programming community (in particular Haskell) - I would > regard this as one > > > of these barriers. > > > > When I want to send compiled Haskell programs by email or > put them on the > > web for distribution, I run 'strip' on them and, if I'm on > Linux or Win32, I > > run UPX on it as well. UPX is an executable packer, see > > http://upx.sourceforge.net/ for details. This routinely > brings programs down > > from over 2 MB to around 250Kb which is small enough for me. > > > > Hope this helps, > > > > Jan de Wit > > > > > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users(a)haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > -- > -------------------------------------------------------------- > ------------- > John Meacham - California Institute of Technology, Alum. - > john(a)repetae.net > -------------------------------------------------------------- > ------------- > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

1 0

ANN: Release 0.1 of Haskell/Java VM Bridge
by Ashley Yakeley 17 Dec '01

17 Dec '01

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: * On-the-fly creation of Java classes with Haskell functions for methods. * Lifted monads which do all the necessary JNI preloading and 'env'-pointer variable handling for you. These can be automatically generated via a tool (MakeJVMModule). * Integration of garbage collectors, type-class based overloading, and a tool (MakeClassModule) which uses Java reflection etc. to generate a Haskell module etc., etc. It is, however, only available for Unix and works only with GHC. 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. Be sure to download the correct .tar.gz file for your Java VM. Simple installation instructions are included in the file. <http://semantic.org/jvm-bridge/haskell-jvm-bridge-1_3.IBM.classic-0.1.i686 .tar.gz> <http://semantic.org/jvm-bridge/haskell-jvm-bridge-1_3.Blackdown.classic.na tive_threads-0.1.i686.tar.gz> SourceForge's file release system is currently broken. When it's fixed, I'll put it there too. Haskell/JVM Bridge and source code is licensed under the GNU Lesser GPL. <http://sourceforge.net/projects/jvm-bridge/> I hope to build an Darwin/OS X version just as soon as there's a port of GHC 5.02 with a working createAdjustor. -- Ashley Yakeley, Seattle WA

1 0

Re: ghc image size
by Krasimir Angelov 15 Dec '01

15 Dec '01

Executables are smaller when build them with dynamic libraries. Unfortunately dynamic libraries are supported only from ghc-4.08.X for Windows. I am not sure for ghc-5.02.1 __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com

2 1

(no subject)
by mailer.daemon＠server1.home4.com 14 Dec '01

14 Dec '01

1 0

ghc image size
by Vorin, Michael 14 Dec '01

14 Dec '01

I just recently starting to use the ghc compiler and am astonished by the size of the executables. Out of interest, why are they so large? Is there any work in progress to make the resulting executable/object somewhat more "normal" in size? I read in the Haskell mailing list archives discussions relating to reducing the barriers to broader acceptance of functional programming by the general programming community (in particular Haskell) - I would regard this as one of these barriers.

3 2

Re: ghc image size
by Mike Gunter 14 Dec '01

14 Dec '01

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. The total cost of the storage will be higher (backup, installing the drive, etc.) but I don't think it will be important. Are there other reasons that size matters? mike > I just recently starting to use the ghc compiler and am astonished by the > size of the executables. Out of interest, why are they so large? Is there > any work in progress to make the resulting executable/object somewhat more > "normal" in size? > > I read in the Haskell mailing list archives discussions relating to reducing > the barriers to broader acceptance of functional programming by the general > programming community (in particular Haskell) - I would regard this as one > of these barriers.

1 0

ANN: GHC 5.02.1 RPMs including xlib and HGL packages
by Manuel M. T. Chakravarty 12 Dec '01

12 Dec '01

The following might be of special interest to people who are using Paul Hudak's Haskell textbook for teaching and or study and would like to run the SOE graphics examples with GHC - or if you simply want to have an X-based graphics library for an application. GHC's source distribution contains the two library packages `xlib' and `HGL' (Alastair Reid's Haskell Graphics Library) as part of hslibs, which are not by default built and installed. For our local teaching needs at the University of New South Wales, we have produced a patched version of GHC 5.02.1 that includes the aforementioned libraries in a working form. Haskell modules can be compiled or linked against these libraries, by providing the command line options `-package xlib' and `-package HGL', respectively (or you can specify them using the :s command in the interpreter). RPM packages for x86 GNU/Linux based on glibc 2.2 (eg, RedHat 7.x) containing GHC 5.02.1 including the xlib and HGL packages are available as ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-5.02.1-graphics.1.i386.rpm ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-prof-5.02.1-graphics.1.i386.rpm ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-doc-5.02.1-graphics.1.i386.rpm with the source RPM at ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/ghc-5.02.1-graphics.1.src.rpm The source RPM contains a patched source tar ball and build instructions in the form of an RPM .spec that may be used to build the packages for other Linux distributions and on other Unix systems. (NB: GreenCard need not be installed to build this package, as a throw-away version of GreenCard is included in the tar ball - ie, it is used in the build process, but not installed.) Cheers, Manuel

1 0

RE: Questions about sharing
by Simon Marlow 10 Dec '01

10 Dec '01

> My understanding is that GHC tries to have it both ways. Here's my > understanding of how it works (implementors should probably chime in > if my memory is faulty or out of date): > > 1) There is a single, canonical copy of every nullary constructor. > This canonical copy is used wherever possible---just like a > top-level constant. > > 2) Updating a thunk with an indirection makes it expensive to obtain > the thunk's value. The extra indirection does not require > allocation---the only reason we need indirections at all is to > overwrite memory that previously held a thunk. The real problem is > that it takes time to chase down indirections once they exist. > > Therefore when a thunk evaluates to a nullary constructor, it is > overwritten directly. This effectively creates another copy of the > nullary constructor. > > 3) When the GC runs, instead of copying these newly-created nullary > constructors, it replaces them with the canonical copy. > > [The GC also eliminates indirections, and thus helps us no matter > what we do in 2) above] Actually we don't do (2) and (3) - update in place only happens in very limited conditions nowadays, namely when we know we're returning to an update frame and the constructor being returned is not nullary and also has no pointer fields (the latter restriction is to avoid complications due to generational GC). In The Olden Days (<= 3.02) we used a return-in-registers policy to avoid heap-allocating return values when they were about to be used once and thrown away, and this also enabled update-in-place in certain circumstances. However the whole thing was terribly complicated to implement, so now we have standard heap returns but we also do analysis (previously CPR analysis, now incorporated into the new demand analysis) to discover when a value can be returned on the stack instead of the heap. Cheers, Simon

1 0