RE: problem with source 5.03
| There seems to be a problem with the source tar.bz2 | distribution of the | 5.03 snapshot. The web page claims it's 5.3M, but the actualy file is | only 4117517 bytes and doesn't untar properly: | | x ghc-5.03.20020204/ghc/InstallShield/Setup Files/Compressed Files, 0 | bytes, 0 tape blocks | x ghc-5.03.20020204/ghc/InstallShield/Setup Files/Compressed | Files/Language Independent, 0 bytes, 0 tape blocks | tar: directory checksum error | | I was able to grab a CVS image, but someone should probably fix this. The web page is wrong. The file is OK. haskell:~/website/dist/5.03.20020204$ ls -l ghc-5.03.20020204-src.tar.bz2 -rw-rw-r--1 sewardj sewardj 4117517 Feb 5 09:17 ghc-5.03.20020204-src.tar.bz2 haskell:~/website/dist/5.03.20020204$ bzip2 -tv ghc-5.03.20020204-src.tar.bz2 ghc-5.03.20020204-src.tar.bz2: ok and I guess you are untarring it on solaris, using the solaris tar? If so try GNU tar? J ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: efficiency question
The transformations that the compiler does, especially with -O, are sufficiently complex that trying to second-guess the performance effects of source changes is difficult. You'd get a much better handle on this by reading the post-optimised program, which you can get with -ddump-simpl. Good luck! This is not for the faint of heart. J | -Original Message- | From: Jorge Adriano [mailto:[EMAIL PROTECTED]] | Sent: Sunday, February 10, 2002 7:18 PM | To: [EMAIL PROTECTED] | Subject: Re: efficiency question | | | On Sunday 10 February 2002 18:48, Kirsten Chevalier wrote: | I'd guess that it's not just that you have to apply the (,) | constructor -- | it also has to do with the fact that the tuples it's | constructing here are | boxed. | | could you elaborate a little more on that (boxed / unboxed) | or provide a link | on the subject? | | thanks | J.A. | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: inscrutable warning
The warning says that the interpreter has ignored a
polymorphic case, since it's hard to implement. Your program
should still behave the same, although possibly less strictly
than you intended.
What really mystifies us is why there is such a thing in the
program in the first place. Using -ddump-sat we can see that
there is indeed a
case ... of { DEFAULT - ... }
but how it came to be, I do not know.
We may investigate further.
J
| Can someone explain the following warning?
|
| ---
| module Warning where
|
| type A = IO ()
|
| class CA t
|where a :: t - A
| instance CA ()
|where a = return
| instance (CA t) = CA (IO t)
|where a = (= a)
|
| data B = B A
|
| class CB t
|where b :: t - B
| instance (CA t) = CB (IO t)
|where b = B . a
| ---
|
| % ghci Warning.hs
|___ ___ _
| / _ \ /\ /\/ __(_)
| / /_\// /_/ / / | | GHC Interactive, version 5.02.2,
| for Haskell
| 98.
| / /_\\/ __ / /___| | http://www.haskell.org/ghc/
| \/\/ /_/\/|_| Type :? for help.
|
| Loading package std ... linking ... done.
| Compiling Warning ( Warning.hs, interpreted )
| WARNING: ignoring polymorphic case in interpreted mode.
|Possibly due to strict polymorphic/functional constructor args.
|Your program may leak space unexpectedly.
|
| Ok, modules loaded: Warning.
| Warning
|
| ___
| Glasgow-haskell-users mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Binary Compatibility
| -Original Message- | From: Sigbjorn Finne [mailto:[EMAIL PROTECTED]] | Sent: Wednesday, February 06, 2002 1:27 AM | To: Ashley Yakeley | Cc: GHC List | Subject: Re: Binary Compatibility | | | Apologies if this has been covered before. What | compatibility is there | between code compiled in different versions of GHC? | | | As a rule, none. Always recompile your code for every new | release. Yes, even patchlevel ones. For your specific case we know for sure that the code produced by 5.02 is incompatible with both 5.02.2 and 5.03. J ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC version 5.02.2 is available
The (Interactive) Glasgow Haskell Compiler -- version 5.02.2
==
We are pleased to announce a new patchlevel release of the Glasgow
Haskell Compiler (GHC), version 5.02.2. The source distribution is
freely available via the World-Wide Web, under a BSD-style license.
See below for download details. Pre-built packages for Linux,
FreeBSD, Solaris, Alpha(OSF) and Win32 are also available, or will
appear shortly.
Haskell is a standard lazy functional programming language; the
current language version is Haskell 98, agreed in December 1998.
GHC is a state-of-the-art programming suite for Haskell. Included is
an optimising compiler generating good code for a variety of
platforms, together with an interactive system for convenient, quick
development. The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces (C, C++, whatever).
A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page at
http://www.haskell.org/
GHC's Web page lives at
http://www.haskell.org/ghc/
What's new in 5.02.2
==
Some important bugfixes:
- fix for the long-standing oversize heap-check bug
- networking library fixes: now works on Windows again
- GHC's memory requirements should be improved over 5.02.1,
especially when using --make.
and many other minor fixes.
How to get it
===
The easy way is to go to the WWW page, which should be
self-explanatory:
http://www.haskell.org/ghc/
We supply binary builds in the native package format for various
flavours of Linux and BSD, and in InstallShield form for Windows
folks. Everybody else gets a .tar.gz which can be installed where you
want.
Once you have the distribution, please follow the pointers in the
README file to find all of the documentation about this release.
On-line GHC-related resources
===
Relevant URLs on the World-Wide Web:
GHC home page http://www.haskell.org/ghc/
Haskell home page http://www.haskell.org/
comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html
System requirements
=
To compile programs with GHC, you need a machine with 64+MB memory, GNU
C
and perl. This release is known to work on the following platforms:
* i386-unknown-{linux,freebsd,mingw32}
* sparc-sun-solaris2
* alpha-dec-osf3
Ports to the following platforms should be relatively easy (for a
wunderhacker), but haven't been tested due to lack of time/hardware:
* hppa1.1-hp-hpux{9,10}
* i386-unknown-solaris2
* mips-sgi-irix{5,6}
* {rs6000,powerpc}-ibm-aix
The builder's guide included in distribution gives a complete
run-down of what ports work; an on-line version can be found at
http://www.haskell.org/ghc/docs/latest/building/building-guide.html
Mailing lists
===
We run mailing lists for GHC users and bug reports; to subscribe, use
the web interfaces at
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
There are several other haskell and ghc-related mailing lists on
www.haskell.org; for the full list, see
http://www.haskell.org/mailman/listinfo/
Please report bugs using our SourceForge page at
http://sourceforge.net/projects/ghc/
or send them to [EMAIL PROTECTED]
GHC users hang out on [EMAIL PROTECTED] Bleeding
edge CVS users party on [EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Strange fatal error
Title: Message We fixed some obscure GC-related bugs in 5.02. The fixes are in 5.02.1. When you try it with 5.02.1, does the problem still happen? J -Original Message-From: Andre W B Furtado [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 7:41 PMTo: [EMAIL PROTECTED]Cc: [EMAIL PROTECTED]Subject: Strange fatal error Can anyone explain me the following error? fatal error: scavenge: unimplemented/strange closure type 0 @ 08C03FD0 (this happened with a program that reads and do some manipulations in a 3MB bitmap file, using HOpenGL-1.01 and GHC-5.02under Windows 98 + Cygwin) Thanks, -- Andre
RE: enormous executable
| OTOH when you start using and reusing larger libraries, like | Gtk+, the waste accumulates, and it's possibly you don't need | to run too many GTK+HS programs before you see performance decrease | due to memory exhaustion. On Linux and probably most Unixes, the text and data segments of the executable are loaded page-by-page into memory on demand. So having a lot of unused junk in the executable doesn't necessarily increase the memory used, either real memory or swap space. I think it's basically harmless providing you're only running one instance of the program on the machine. J ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
More GHC 5.02 binaries available
The web site (http://www.haskell.org/ghc) now has final binary builds for x86-Linux sparc-solaris Windows NT/2K/XP and allegedly 95/98/ME Additionally, the final source tarball is now on the web page. I claim (and earnestly hope) it is suitable for building other binary builds of 5.02. $ md5sum -b ghc-5.02-src-2.tar.bz2 0bf8b670759240032c317fec6b02f59d *ghc-5.02-src-2.tar.bz2 J ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 5.02 is released
The (Interactive) Glasgow Haskell Compiler -- version 5.02 We are pleased to announce a new major release of the Glasgow Haskell Compiler (GHC), version 5.02. This is the first version of GHC that has all of the following: * An interactive read-eval-print loop, similar to Hugs. You can load a mixture of compiled and interpreted modules; in particular, you automatically use the precompiled libraries, so your interpreted programs often run pretty fast. * Works solidly on Windows platforms. Installation is simple (Installshield); you don't have to install anything else; and GHC does not get confused if you also happen to have (say) Cygwin installed. * Implements the changes adopted for the (now almost finalised) Revised Haskell 98 Language and Library Reports. * The ability to emit External Core, a documented typed intermediate language, suitable for slurping up into other tools. [Andrew Tolmach's work.] * A particularly thorough pre-release test programme. Some releases are more solid than others; this one is at the solid end of the spectrum. We fondly hope. So if you have been waiting to upgrade your GHC 4.08, this is the moment. How to get it ~ The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for various flavours of Linux and BSD, and in InstallShield form for Windows folks. Everybody else gets a .tar.gz which can be installed where you want. Once you have the distribution, please follow the pointers in the README file to find all of the documentation about this release. The source distribution is freely available via the World-Wide Web, under a BSD-style license. See below for download details. Pre-built packages for Linux, FreeBSD, Solaris and Win32 are also available. More details about what's new ~ 5.02 incorporates many small refinements and bug fixes over the previous stable release (5.00.2). There are no major language changes. - Implements Haskell 98 (revised) - Ability to emit External Core. GHC can't read External Core back in. Yet. - Much improved support for Windows platforms. Binary builds are now entirely freestanding. There's no need to install Cygwin or Mingwin to use it. It's a one-click-install-and-off-you-go story now. - Several small changes to bring GHC into line with the newest Haskell 98 report. - GHCi (the interactive system) now works on Windows. - Partial FFI support in GHCi. At the moment, foreign import (both static and dynamic) is supported on x86 and sparc platforms. - A compacting garbage collector, to try and reduce space use. - Ability to disconnect built-in numeric syntax from the supplied Prelude. This allows you to define your own arithmetic packages, which Haskell98 doesn't quite support. - Experimental: partial support for hierarchical module names. - Experimental: following heroic hacking by Ken Shan, 5.02 now works on Alpha (Tru64 only). Many 64-bit bugs have been shaken out. At the moment only the batch-mode compiler works -- no GHCi or native code generator yet. We've found and fixed more bugs than you could possibly imagine. A big thank-you to all those who reported bugs in the 5.00.X series. We claim to have fixed almost all reported bugs. In general we've spent a large amount of effort trying to improve the stability of the system relative to 5.00.X. (Famous last words ...) For full details see the release notes: http://www.haskell.org/ghc/docs/5.02/set/release-5-02.html Background ~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page at http://www.haskell.org/ GHC's Web page lives at http://www.haskell.org/ghc/ On-line GHC-related resources ~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/
RE: GHC FFI Return Type Bug
| Speaking of 5.02 . Could someone enlighten us that are not on | the CVS mailing list about the state of things? When can we | expect the release? If I'm feeling optimistic, late this week; otherwise, sometime next week. We've had some stability problems, but I hope these are now solved. Another part of the delay stems from the fact that we're trying to get our new glorious automated test system to run with zero failures on all supported platforms. The upside of all this is that 5.02, when it eventually appears, should be pretty darn stable. (Famous last words ...) J ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: adding isWHNF primop to 5.00.2 native code generator
| In all the cases I tried, the info pointer in the closure | header pointed to the end of the info table. Although a | comment in ghc/includes/ClosureMacros.h worries me: | |info pointerThe first word of the closure. Might point | to either the end or the beginning of the | info table, depending on whether we're using | the mini interpretter or not. GET_INFO(c) | retrieves the info pointer of a closure. | | Can someone please clarify when the info pointer will point | to the beginning or end of the table? Normally, the info pointer points at the first word following the info table. This word is the start of the closure's entry code. That means that, given an info pointer, we can either evaluate the closure by executing from that address, or look up info about it by indexing backward from it into the info table proper. However, for portable (-unreg) compilation, we can't control the relative placement of code and data. In this case the first word of the itbl points to the entry code. For nativeGen hacking you only need to consider the fast (pointer to end) case. | My problem is that this is a dodgy assumption since the design of the | info table may change in the future, and you get a nasty | unchecked dependency between the primops in the NCG and the | design of the rts. This is a major design problem (IMO) with the NCG. It afflicts every single macro and structure layout which the NCG has to deal with, and has already cost us some hours tracing bugs to do with divergences between the two implementations. I had a plan to derive all the structure layouts and macro defs from a single source to avoid this kind of breakage, but I don't know if it will ever be implemented. | It seems hard to get the kind of automatic offset calculation in the | NCG as you get with the C version of primops. My current idea | is to make some C primops that do the structure and array | indexing for me, and then use them in the NCG. i.e. primops | that essentially export 'closure_flags[type]' and | 'get_itbl(c)-type' to the NCG. It's a problem. StIndex is sometimes helpful, particularly since you can specify a PrimRep which indicates how the index should be scaled. Exactly like adding an integer to a pointer in C. J ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC FFI Return Type Bug
Sigbjorn
Am confused by your answer.
| char fooble ( ... )
| {
| return 'z';
| }
|
| on an x86, 'z' will be returned at the lowest 8 bits in %eax. What I
| don't know is, is the C compiler obliged to clear the upper 24 bits
of
| %eax, or does that onus fall on the callee?
|
| Yes, the callee is required to narrow expr in 'return
| expr;' to fit that of the specified return type -- see 9.8
| of Harbison and Steele. So, a C compiler that cause f() to
| return 0x7fff for the following,
|
| unsigned char g()
| {
| return 0x7fff;
| }
|
| unsigned int f()
| {
| return g();
| }
|
| is in the wrong. [Notice that narrowing for signed integral
| types is undefined in ISO C, but most current-day compilers
| implement such narrowing ops the same way, i.e., by masking
| off excess bits.]
So we don't need to worry about doing the masking on the
Haskell side, right?
| Also, I don't even know where to look for the specification
| of details
| of the C calling conventions. Anyone got a clue?
|
|
| Harbison Steele Chapters 6 and 9 cover the conversion rules
| that apply to functions (and other expressions). As you no
| doubt already know, lower-level details are the domain of a
| platform's ABI.
|
| Sounds to me like unboxed sized Words and Ints is the
| (unavoidable) way to go.
Why would we need these unless we *did* need to worry about
masking on the Haskell side?
Pls clarify.
J
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: help needed for adding isWHNF primop to 5.00.2
| I would like to add a primitive to GHC 5.00.2 of the form: | | isWHNF :: a - Bool One might be inclined to ask what for? Such a primitive is probably difficult to implement, given the variety of GHC's closures, and is potentially dangerous -- you could conceivably break referential transparency (?) I can also imagine it could interact badly with the complexities of GHC's simplifer. What would you hope to gain from such a thing? Perhaps you have some wider purpose which could be achieved some other way? J ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: linking with c++ libraries
| To reliably link with C++, you need to compile both the code | which invokes C++ (i.e. whatever uses the C++ library) and | main (that is, ghc/rts/Main.c, not main.hs) with a C++ compiler. | | So, in summary: | | - Compile any code which may call the C++ library (and keep | inter-module inlining in mind; probably safest to compile | all of your code this way) via C, and compile the C with g++. | | - Re-compile the run-time system (at least Main.c) with | g++, too. | | That may not fix your specific core dump, but you'll need to | do this anyway. After some discussion in the GHC office, we're unsure about why you need to compile Main.c with a C++ compiler for this to work. Pls can you clarify? J ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RPMs for: GHC version 5.00.2 is available
Thanks once again to Tom and Manuel for building RH6.2 and RH7.x RPMs of ghc-5.00.2. I'll shortly put these RPMs at the usual place, the download pages at http://www.haskell.org/ghc, so you can get them from there too. Note also that a build for Solaris 2.7 (sparc) is also now available. J | -Original Message- | From: Manuel M. T. Chakravarty [mailto:[EMAIL PROTECTED]] | Sent: Thursday, June 21, 2001 3:02 AM | To: Julian Seward (Intl Vendor) | Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] | Subject: Re: GHC version 5.00.2 is available | | | Julian Seward (Intl Vendor) [EMAIL PROTECTED] wrote, | | The (Interactive) Glasgow Haskell Compiler -- version 5.00.2 |== | | We are pleased to announce a new patchlevel release of the Glasgow | Haskell Compiler (GHC), version 5.00.2. | | For your installation pleasure, RPM packages built on RedHat | are now available. Binary packages built for RedHat 7.x are at | ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-5.00.2-1.i38 6.rpm ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-prof-5.00.2- 1.i386.rpm and those for RedHat 6.2 are at ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-5.00.2 -1.i386.rpm ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-prof-5 .00.2-1.i386.rpm The ghc-prof-* packages contain optional libraries for profiling. The packages for 6.2 are courtesy of Tom Moertel. The source rpm used to built the above binaries is at ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/ghc-5.00.2-1.src. rpm If you build from the source rpm using an older version of GHC, note that you have to build the system twice if you like to use the interactive environment. The second build should use the compiler generated in the first. Manuel ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: passing Strings with FFI
| I want to pass a String to a function which is imported from C code:
| foreign import pass prim_pass :: String - String
| The declaration above gives me an error from ghc like String
| type not
| supported for imported functions.
| I thought that String being [Char] should be supported
| (somehow like a
| definition with newtype keyword).
| Can you tell me how can I pass strings to and from C code, as
| simple as
| possible (I know about HDirect, but I couldn't make it work
| for me: red-hat
| 7.1, ghc 5.00)?
First of all, upgrade to 5.00.2, since it is significantly less
buggy than 5.00.
int fooble ( char* str, int n )
{
fprintf(stderr, fooble called: %s %d\n, str, n );
return 42;
}
import PrelByteArr
import PrelPack (packString)
foreign import fooble fooble
fooble :: PackedString - Int - IO Int
type PackedString = ByteArray Int
main = do n - fooble (packString hello, C world) 99
putStrLn (Returned value is ++ show n)
For more examples read the compiler sources, at
fptools/ghc/compiler/ghci/Linker.lhs.
J
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: -optCrts-M28m
| 2. I applied -optCrts-G3 -optCrts-F1.5 -optCrts-M28m | | to compile certain large module on 32Mb RAM machine. | Now, what to apply for this with ghc-5.00 ? +RTS -G3 -F1.5 -M28m -RTS J ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: sgml
The documentation should be supplied in .html and .ps files, at least in the .tar.bz2 binary build I did, and, I presume in the RedHat 6.2/7.0 RPMs. Are you saying this is not the case? J | -Original Message- | From: S.D.Mechveliani [mailto:[EMAIL PROTECTED]] | Sent: Tuesday, April 17, 2001 1:08 PM | To: [EMAIL PROTECTED] | Subject: sgml | | | Hello, | | I want to install GHC-5.00 (from binaries, on Linux). | But the installation guide, as most documentation, is in the .sgml | format. I can read ASCII, .dvi, .ps, .tex, html texts. | But what to do with .sgml, please? | | - | Serge Mechveliani | [EMAIL PROTECTED] | | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
The (Interactive) Glasgow Haskell Compiler -- version 5.00
[Binary builds for x86-linux and sparc-solaris are now
available. We're still working on the Windows version. -- J]
The (Interactive) Glasgow Haskell Compiler -- version 5.00
We are pleased to announce a new major release of the Glasgow Haskell
Compiler (GHC), version 5.00. The source distribution is freely
available via the World-Wide Web and through anon. FTP, under a
BSD-style license. See below for download details. Pre-built
packages for Linux, FreeBSD, Solaris and Win32 are also available.
Haskell is a standard lazy functional programming language; the
current language version is Haskell 98, agreed in December 1998.
GHC is a state-of-the-art programming suite for Haskell. Included is
an optimising compiler generating good code for a variety of
platforms, together with an interactive system for convenient, quick
development. The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces (C, C++, whatever).
A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page at
http://www.haskell.org/
GHC's Web page lives at
http://www.haskell.org/ghc/
What's new
5.00 has been majorly revamped since the previous stable version,
4.08.2.
This should be a stable release. Major changes since 4.08.2 are:
- An interactive system, similar in style to Hugs. You can
interactively
load and unload modules, run expressions, ask the types of things.
Module dependencies are tracked and chased automatically.
Combinations of compiled and interpreted modules may be used.
All the GHC libraries are available in interactive mode, as are
most of the Glasgow extensions to Haskell 98. Compilation in
interactive mode (to bytecode) is about three times faster than
compiling to object code.
- Batch compilation of multiple modules at once, with automatic
dependency chasing. For large programs this can halve compilation
times, and removes the need for Makefiles.
- Enhanced package (library) management system. Packages may be
installed and removed from an installation using the ghc-pkg tool.
- Initial Unicode support - the Char type is now 31 bits.
- Sparc native code generator, giving much faster compilation on
sparcs.
(Native code generation for x86s has been available for a while).
- Improved heap profiling - you can restrict heap profiles
by type, closure description, cost centre, and module.
- Support for the latest Foreign Function Interface (FFI)
proposals. Marcin Kowalczyk's hsc2hs tool is included.
- Language extensions: parallel list comprehensions and functional
dependencies.
- The usual huge collection of bug fixes. Most reported bugs have
been fixed.
For full details see the release notes:
http://www.haskell.org/ghc/docs/5.00/set/release-5-00.html
How to get it
===
The easy way is to go to the WWW page, which should be
self-explanatory:
http://www.haskell.org/ghc/
We supply binary builds in .rpm/.deb form for all you Linux junkies
out there, and in InstallShield form for Windows folks. Everybody
else gets a .tar.gz which can be installed where you want.
Once you have the distribution, please follow the pointers in the
README file to find all of the documentation about this release.
On-line GHC-related resources
===
Relevant URLs on the World-Wide Web:
GHC home page http://www.haskell.org/ghc/
Haskell home page http://www.haskell.org/
comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html
System requirements
=
To compile programs with GHC, you need a machine with 32+MB memory, GNU
C
and perl. This release is known to work on the following platforms:
* i386-unknown-{linux,freebsd,mingw32}
* sparc-sun-solaris2
Ports to the following platforms should be relatively easy (for a
wunderhacker), but haven't been tested due to lack of time/hardware:
* hppa1.1-hp-hpux{9,10}
* i386-unknown-solaris2
* alpha-dec-osf{2,3}
* mips-sgi-irix{5,6}
* {rs6000,powerpc}-ibm-aix
The builder's guide included in distribution gives a complete
run-down of what ports work; an on-line version can be found at
http://www.haskell.org/ghc/docs/5.00/building/building-guide.html
Mailing lists
===
We run mailing lists for GHC users and bug reports; to subscribe, use
the web interfaces at
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
There are several other haskell and
RE: How to box/unbox values?
| -Original Message- | From: Thomas Pasch [mailto:[EMAIL PROTECTED]] | Sent: Tuesday, April 10, 2001 12:55 AM | To: [EMAIL PROTECTED] | Subject: How to box/unbox values? | | | Hello, | | is there an easy way to box/unbox Types. | I need this for Int's, so is there | a function that does: | | Int# - Int | Int - Int# import GlaExts ( Int(..) ) iBox x = I# x iUnbox (I# x) = x ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC HQ are looking for a Linux-IA64 box
[Apologies if you get multiple copies of this msg.] Folks, Following a recent discussion about future development directions for GHC, it seems one thing we want to start thinking about is support for the IA64 architecture. Does any kind person have an IA64 box, running Linux, on which we could have an account? The extent of the work would be to make GHC's runtime-support system work again on a 64-bit platform (it used to), and possibly to build an IA64 native code generator. This work would be spread across a couple of months, I imagine. Basic requirements are: * IA64 Linux box, with development tools (gcc, perl, autoconf, gdb, etc -- all the usual Linux/Unix stuff). * As many spare processor cycles as possible. GHC building/debugging tends to CPU intensive. Also, probably at least 256MB of memory would be necessary to keep us out of trouble. * At a bare minimum, 300 MB of free disk space; 1 GB would be preferable, since it would allow more thorough testing of the system. * Decent, permanent, reliable internet connection from so that we can work remotely (obviously) and so that we can talk to our CVS server. I'd say at a bare minimum a 128 kb/sec connection. Preferably as few as possible network hops from Cambridge, UK. This work is likely to be on-and-off (not all the time) over a couple of months, I'd guess. We probably won't be ready to start on it for at least a month, so some time around the start of May would be when we'd really want to start moving on this. Availability of such a machine would be a useful contribution to the GHC development effort, so we'd be grateful if any of you could point us in the right direction. J (speaking for the GHC crew as a whole) ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: The Glasgow Haskell Compiler -- version 4.08.2
The Glasgow Haskell Compiler -- version 4.08.2
We are pleased to announce a new release of the Glasgow Haskell
Compiler (GHC), version 4.08.2. The source distribution is freely
available via the World-Wide Web and through anon. FTP, under a
BSD-style license. See below for download details. Pre-built
packages for Linux, FreeBSD, Solaris and Win32 are also available.
Haskell is "the" standard lazy functional programming language; the
current language version is Haskell 98, agreed in December 1998.
GHC is a state-of-the-art optimising compiler for Haskell, generating
good code for a variety of platforms. The distribution includes space
and time profiling facilities, a large collection of libraries, and
support for various language extensions, including concurrency,
exceptions, and foreign language interfaces (C, C++, whatever).
A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page at
http://www.haskell.org/
GHC's Web page lives at
http://www.haskell.org/ghc/
+ What's new in 4.08.2
===
No new features, just a few minor bug fixes.
+ What's new in 4.08
=
This should be a stable release. There have been many enhancements
since 4.06, and shed-loads of bug-fixes (one shed (imperial) ~ one ton
(US)).
There are the following changes
- New profiling subsystem, based on cost-centre stacks.
- Working x86 native code generator: now it works properly, runs
about twice as fast as compiling via C, and is on a par for
run-time speed (except in FP-intensive programs).
- Implicit parameters (i.e. dynamic scoping without the pain).
- DEPRECATED pragma for marking obsolescent interfaces.
- In the wake of hslibs, a new package system for
libraries. -package should now be used instead of -syslib.
- Result type signatures work.
- Many tiresome long-standing bugs and problems (e.g. the trace
problem) have been fixed.
- Many error messages have been made more helpful and/or
accurate.
For full details see the release notes:
http://www.haskell.org/ghc/docs/4.08/users_guide/release-4-08.html
+ Important Info For Win32 users
=
ALERT: For reasons as yet not understood, as of January 2001 Cygwin's
mingw package has a problem that causes GHC-compiled binaries to be
built incorrectly. The fix is to ensure that your mingw package is
dated 2000 (you can set this in the Cygwin installer). See the
installation guide for more details.
+ Mailing lists
We run mailing lists for GHC users and bug reports; to subscribe, use
the web interfaces at
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
There are several other haskell and ghc-related mailing lists on
www.haskell.org; for the full list, see
http://www.haskell.org/mailman/listinfo/
Please send bug reports about GHC to [EMAIL PROTECTED];
GHC users hang out on [EMAIL PROTECTED] Bleeding
edge CVS users party on [EMAIL PROTECTED]
+ On-line GHC-related resources
Relevant URLs on the World-Wide Web:
GHC home page http://www.haskell.org/ghc/
Haskell home page http://www.haskell.org/
comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html
+ How to get it
The easy way is to go to the WWW page, which should be
self-explanatory:
http://www.haskell.org/ghc/
Once you have the distribution, please follow the pointers in the
README file to find all of the documentation about this release. NB:
preserve modification times when un-tarring the files (no `m' option
for tar, please)!
+ System requirements
==
To compile the sources, you need a machine with 32+MB memory, GNU C
(`gcc'), `perl' plus a version of GHC installed (3.02 at least). This
release is known to work on the following platforms:
* i386-unknown-{linux,freebsd,netbsd,cygwin32,mingw32}
* sparc-sun-solaris2
* hppa1.1-hp-hpux{9,10}
Ports to the following platforms should be relatively easy (for a
wunderhacker), but haven't been tested due to lack of time/hardware:
* i386-unknown-solaris2
* alpha-dec-osf{2,3}
* mips-sgi-irix{5,6}
* {rs6000,powerpc}-ibm-aix
The builder's guide included in distribution gives a complete
run-down of what ports work; an on-line version can be found at
http://www.haskell.org/ghc/docs/4.08/building/building-guide.html
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc-4.xx Alpha port?
| Hi guys. Has anyone been so rash as to try this? Any indications | as to the likely "degree of difficulty"? I'd have a go myself, but | I'm rather busy with teaching. (Which is ironic, since teaching is | what I want it for...) | | Degree of difficulty is likely to be less than a starting completely | non-existent port (eg. IA64), but still significant. The | 64-bitness is | likely to be more of an issue than the Alpha-specific stuff, though. Getting it working on Alphas would also be of benefit in the sense that it gets the 64-bitness working again. That gives one less thing to worry about when porting to IA64, if/when that should happen. J ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Using Haskell code in VBA (MS Access)?
| What is the best way to call functions implemented in Haskell from | Visual Basic for Applications (MS Access)? | I suppose I will have to build a DLL with GHC + Cygwin, but | up to now I | didn't manage to do so. I there a "How to"? This isn't directly what you wanted, but: I packaged up Stg Hugs as a DLL which you can call from VB. You can ask it to load a Haskell module, and run functions in that module, passing results back and forth to VB. Building DLLs with Cygwin which can be called from the native MS tools seems to be somewhere between difficult and impossible, depending on who you ask. I never managed it. A much better bet is to use the Mingw32 toolchain to build DLLs -- that's how I did the abovementioned experiment. I think GHC supports generating Mingw32-ised DLLs, so you might be in luck there. Unfortunately our Windows expert (Reuben Thomas) is away until Monday, and he knows much more than I do. J
RE: can't compile ghc from cvs
I think it's a legitimate problem with the new driver. I hit it myself on Friday. I think that the _Capitalised entity naming scheme is being misinterpreted by pre-4.07 ghc's. ... and I see that Sven has already fixed it. Cool. J
RE: Portable C code
| Anybody knows how to generate a portable C code through GHC ? It depends what you mean by portable. GHC can produce C code which you can compile with gcc, without special support -- we call this "unregisterised" code. This code needs some GNU extensions -- named initialisers, zero length arrays and (I think) support for 64-bit arithmetic. So it is not strict ANSI C89 code, although it looks all 3 extensions will be the ANSI C9X standard. I also believe (not sure, tho) that you'd still need to configure GHC's runtime for word size (32 vs 64 bits) and endiannness, although that isn't a problem. So it's possible, but a bit tricky. This is how GHC is ported to new platforms. What is it you want to achieve? If you tell us this, we might be able to be more specific. J
RE: Quicker compilation for GHC users running x86-Linux
When I have an -fasm-x86 and an -fvia-C in the command line, which one is supposed to take precedence? Shouldn't (at the moment) -fvia-C always take precedence, because it can't hurt to compile via C? I agree -fvia-C should take precedence. I'm not sure what happens at the moment -- when compiling the compiler, -fvia-C and -fasm-x86 together did cause compilation to go via C, but that might just be because -fvia-C appeared second in the command line. Needs looking into. GhcLibHcOpts = -O -H24m -split-objs -fasm-x86 to my `build.mk' to make ghc compile its libraries with the native code generator. For `ST.lhs' this effectively leads to the call panic! (the `impossible' happened): getRegister(x86,dyadic primop) (Prim sameMutVarzh P_IntReg(1) P_[(Sp +P_ (0))]) I wouldn't recommend building libraries with the native code generator, since, as you can see, we haven't implemented all the primops -- in this case sameMutVar#. I'm amazed that you got as far as ST; I didn't even bother to try compiling the Prelude with it because I assumed the Prelude would be loaded with primops which haven't been implemented. This might get fixed, but it isn't high priority; the main aim is to compile application code quickly. Is the FFI supported by the native code generator? Certainly it can compile calls to C. I imagine that means at least part of the FFI works; not sure about foreign export yet. Sigbjorn asked the same question, so I might look into it. J
Quicker compilation for GHC users running x86-Linux
Folks, The adventurous among you may like to try an innovation which in some cases nearly doubles the speed at which ghc compiles programs. This innovation is our native code generator, which has long been in the GHC source tree, but has only just been made to work for x86. It reduces compilation time by avoiding gcc (and perl) entirely, and directly emitting x86 assembly code. * Only x86 Linux is currently working. I guess it should not be too much trouble to emit x86 code for Win32. GHC also used to be able to emit Sparc and Alpha code, but these currently do not work. Brave/foolhardy :-) souls may like to have a go resurrecting them; we will advise and supply debugging tips. Or even writing new ports; IA64, anyone? * This functionality is only available from the current CVS development branch. It is NOT available in the standard 4.06 distribution, unfortunately. In order to use it, build ghc from the CVS repository. Then you only need to add -fasm-x86 to your command lines to use it. * Stability: all of the nofib suite runs, and the compiler can compile itself via the native-code route. This means it works well enough to be useful. The generated code is 5-10% slower than the standard route, but that's fine for debugging/development work. Regard this as beta-release functionality. It works pretty well, but there are known issues which need to be resolved before full-scale use (see ghc/compiler/nativeGen/NOTES). If stability/reliability are important to you, stick with the recently released 4.06 version. * Please try it out! I would be pleased to get feedback on it. J
RE: Searching for the gcc-2.95 problem
I want to try to localize the problems occurring when using a gcc-2.95 compiled ghc-4.04. As I stated in a recent mail, the bug seems to be somewhere in the runtime system/libraries. [...] Speculation gcc-2.95 has more aggressive alias analysis than previous egcs or gcc versions. As a result, some programs don't compile correctly with 2.95 because they break ANSI C's aliasing rules in subtle ways, which didn't matter with previous gcc/egcs-s, but does now. A couple of examples which come to mind are: the Linux 2.2 and 2.3 series kernels, and the Wine windows-on-Linux-library. Perhaps the same is happening with GHC's RTS. You can ask gcc-2.95 to be less aggressive by using -fno-strict-aliasing (I think; consult the documentation). I'd be interested to hear if this makes any difference. /Speculation J
