- Glasgow-haskell-users

RE: Shared Libraries
by Simon Marlow 30 Apr '01

30 Apr '01

> In the windows version of ghc, > there seems to be the possiblity to compile > the libraries as shared 'dll's. Is the > same possible for the unix version? > > The question is because I think the ghc > executables are really blown up. A simple > 'Hello, world' has 358 KBytes and the hello > example of the GTK+ bindings is as big as > 2.2 MBytes, although it is link dynamically > against: 358K looks a bit large: is that stripped? I normally see a 150K-ish minimum. Most of that is the runtime system and garbage collector. To answer your question: we don't currently have a way to make shared libraries for Haskell code on Unix boxes. I've made various attempts at this in the past and didn't have much success - take a look back through the glasgow-haskell-{users,bugs} archives for some more info on the topic. BTW, shared libraries aren't that big a deal. You won't see any memory savings unless you've got several Haskell programs running, and there would certainly be a performance hit. Also, there wouldn't be any of the other "hot-swappable" advantages you normally get with shared libraries, because GHC-compiled Haskell libraries tend to have a much more intimate relationship with each other than C libraries. Cheers, Simon

1 0

RE: haskell.runtime.* ??
by Simon Peyton-Jones 29 Apr '01

29 Apr '01

I'm afraid that no one ever completed the GHC Haskell->Java story. The idea is that the JVM is the runtime, but of course you need to implement the standard libraries somehow, and all the primitive operations GHC uses. Not a trivial task, but one we are undertaking for .NET. Bottom line: the reason you can't find a runtime is because you are supposed to compile the Java with a Java compiler and run that. But you'll need to do more than that to actually run programs Simon | -----Original Message----- | From: Kwanghoon Choi [mailto:khchoi@ruby.kaist.ac.kr] | Sent: 25 April 2001 14:13 | To: glasgow-haskell-users(a)haskell.org | Subject: haskell.runtime.* ?? | | | | Hello, | | I managed to restore an option for GHC 5.00 to produce | java output but I realized that I also need some runtime | system to run the java program produced by GHC. I | examined the GHC source tree and the GHC website but in | vain. Where do I get the runtime system? | | Thanks in advance. | | Kwanghoon | | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

1 0

memory destribution
by S.D.Mechveliani 28 Apr '01

28 Apr '01

Here is another expression of what I wrote recently on the memory destribution. Probbaly, it suffices to have the garbage collection command. For example, Hugs can do Prelude> :gc Garbage collection recovered 240372 cells ... It is clear then, how much the user has for further computation. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

memory distribution in ghci
by S.D.Mechveliani 28 Apr '01

28 Apr '01

To my request > [..] > can ghci provide a command measuring the part of heap taken > by interpreted programs, > by interfaces? > (or, at least, their sum) Simon Marlow <simonmar(a)microsoft.com> writes > Ah, I see now. You'd like to know how much memory your program is > using, compared to GHCi itself? Hmm. Unfortunately I can't see a good > way to do this I'm afraid. In ghci ... +RTS -Mxxxm -RTS xxx sets the volum bound for (1) `real' data + (2) interpreted program + (3) interfaces of pre-compiled loaded .o modules. Please, confirm, whether I understand correct? And many users would like to measure (1) within the ghci loop. The statistic like Prelude> List.sort [1..10] [1,2,3,4,5,6,7,8,9,10] (0.53 secs, 7109100 bytes) includes the number of allocations, which cannot help to detect (1) (can it?) This is a user's wish for the future ghci version. I do not know, whether it is hard to develop. If it is hard, personally, I would not suffer much. Because, getting "heap exhausted", one can run ghci once more, with larger xxx, and performing the same computation to detect approximately which part of xxx is taken by the `real' data. But this looks awkward. Another wish: to document the ghci memory management ------------- which we are discussing now. Because GHC could simply give a reference to the manual section. > However, you can always compile the program > and use profiling... Suppose User demonstrates an Haskell application A to the Listener. Naturally, most of A constitutes its `library' L, and L was compiled to .o files (desirably, gathered in the libL.a archive). ghci invokes, loads the _interpreted_ demonstration code D, much smaller than L, but importing items from L. Naturally, Listener asks something like "and how much memory needs to compute this matrix?". In many other system, the interactive command, say, `:size' gives immediately some interpreter memory map and the sizes taken by `code' and `data'. And you suggest to wait 2 hours to re-compile _everything_ with profiling. The Listener would not wait. >> For, with -O and much in-lining, the interfaces may be very large. > You really don't want to use -O with GHCi (in fact, at the moment you > can't). This may be serious. For example, putStr $ show (sum1 [1..n]) will need a constant memory or O(n) memory depending on the -O possibility. The docs on ghc-5.00 say that it joins "the best of the two worlds" - interpreted code calling for the fast code compiled earlier. Generally, I like only scientifically designed `interpreters' and always advised not to spend efforts to .o compilation. But as nobody agrees with me, as the o-compilation fiesta continues, then, why to spend effort in vain? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Shared Libraries
by Thomas Pasch 27 Apr '01

27 Apr '01

Hello, In the windows version of ghc, there seems to be the possiblity to compile the libraries as shared 'dll's. Is the same possible for the unix version? The question is because I think the ghc executables are really blown up. A simple 'Hello, world' has 358 KBytes and the hello example of the GTK+ bindings is as big as 2.2 MBytes, although it is link dynamically against: > ldd hello libgthread-1.2.so.0 => /usr/lib/libgthread-1.2.so.0 (0x40025000) libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x40028000) libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x40155000) libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x4018a000) libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x4018d000) libdl.so.2 => /lib/libdl.so.2 (0x401b1000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x401b4000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x401bc000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401cb000) libm.so.6 => /lib/libm.so.6 (0x402ae000) libgmp.so.3 => /usr/lib/libgmp.so.3 (0x402cc000) libc.so.6 => /lib/libc.so.6 (0x402ed000) libpthread.so.0 => /lib/libpthread.so.0 (0x40400000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Best regards, Thomas

1 0

GHC and the Lazy Functional State Threads Paper
by Thomas Pasch 27 Apr '01

27 Apr '01

Hello, to get a better understanding I tried to get the code from 'Lazy Functional State Thread' to work. But I encounter some error messages that I don't fully understand. > module Lfs where > > import PrelGHC > import GlaExts > import ST > import qualified MArray > import qualified Array > > newArr = newSTArray > readArr = readSTArray > writeArr = writeSTArray > -- Error: Ambiguous type variable(s) `ix' in the constraint `Ix ix' > freezeArr = freezeSTArray > > thenST_ a b = a `thenST` \_ -> b > > accumArray bnds f z ivs > = runST > (newArr bnds z `thenST` \a -> > fill a f ivs `thenST_` > freezeArr a) > > fill a f [] = returnST () > fill a f ((i,v):ivs) > = readArr a i `thenST` \x -> > writeArr a i (f x v) `thenST_` > fill a f ivs > > -- in GlaExts: seqST = (>>) > seqST2 = foldr thenST_ (returnST ()) > > accumArray2 bnds f z ivs > = runST > (newArr bnds z `thenST` \a -> > seqST2 (map (update a f) ivs) `thenST_` > freezeArr a) > > update a f (i,v) > = readArr a i `thenST` \x -> > writeArr a i (f x v) > > putString [] = returnST () > -- Error: Couldn't match `ST s a' against `IO ()' > putString (c:cs) = putChar c `thenST_` > putString cs > > -- Error: Couldn't match `ST s a' against `[b]' > putString2 cs = seqST (map putChar cs) > > main = putStrLn "Hello, world" > How to change the code to get it to work? Why is there a different definition of seqST in GlaExts? Best regards, Thomas PS: When I change the definition of the mutable Array to > newArr = MArray.newArray > readArr = MArray.readArray > writeArr = MArray.writeArray > freezeArr = MArray.freeze I get Error in accumArray and accumArray2. I guess this is because of the fact that a STArray is only one possible MArray and there are other possiblities, right?

2 1

The (Interactive) Glasgow Haskell Compiler -- version 5.00
by Julian Seward (Intl Vendor) 27 Apr '01

27 Apr '01

[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 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 glasgow-haskell-bugs(a)haskell.org; GHC users hang out on glasgow-haskell-users(a)haskell.org. Bleeding edge CVS users party on cvs-ghc(a)haskell.org.

4 7

Businesses For Sale
by info＠businessesforsale.com 27 Apr '01

27 Apr '01

Search over 12,000 businesses for sale at: http://www.BusinessesForSale.com The leading global website for businesses for sale - everything from bars and hotels to pet shops and newsagents. Regards The BusinessesForSale.com team. -------------------------------------------------------------------------- To be removed from this mailing list please reply with the word remove in the email and ensure it contains the original text. glasgow-haskell-users(a)dcs.gla.ac.uk Ref: Biz-Opp-A2-20010427

1 0

RE: memory distribution in ghci
by Simon Marlow 27 Apr '01

27 Apr '01

> It looks, there remains a questions on memory distribution in > ghc-5.00 -interpreted : > > can ghci provide a command measuring the part of heap taken > by interpreted programs, > by interfaces? > (or, at least, their sum) Ah, I see now. You'd like to know how much memory your program is using, compared to GHCi itself? Hmm. Unfortunately I can't see a good way to do this I'm afraid. However, you can always compile the program and use profiling... > For, with -O and much in-lining, the interfaces may be very large. You really don't want to use -O with GHCi (in fact, at the moment you can't). Cheers, Simon

1 0

memory distribution in ghci
by S.D.Mechveliani 27 Apr '01

27 Apr '01

It looks, there remains a questions on memory distribution in ghc-5.00 -interpreted : can ghci provide a command measuring the part of heap taken by interpreted programs, by interfaces? (or, at least, their sum) For, with -O and much in-lining, the interfaces may be very large. Also compare it to the _batch_ mode: commanding ghc -o run Foo.o ./run +RTS -MXXm -RTS the user is sure that XX Mb is only for the `real' computation data. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0