- Glasgow-haskell-users

RE: Profiling and Data.HashTable
by Simon Marlow 14 Oct '05

14 Oct '05

On 14 October 2005 15:17, Ketil Malde wrote: > I have a program that uses hash tables to store word counts. It can > use few, large hash tables, or many small ones. The problem is that > it uses an inordinate amount of time in the latter case, and > profiling/-sstderr shows it is GC that is causing it (accounting for > up to 99% of the time(!)) > > Is there any reason to expect this behavior? > > Heap profiling shows that each hash table seems to incur a memory > overhead of approx 5K, but apart from that, I'm not able to find any > leaks or unexpected space consumption. I'm not certain that this is your problem, but hash tables are by definition mutable objects, and mutable objects don't work too well with generational garbage collection, GHC's in particular. Basically every GC, even the minor ones, will have to scan all the mutable objects. GHC doesn't make any attempt to record which mutable objects have actually been mutated since the last GC. This is a compromise: it makes writing to a mutable object faster, at the expense of GC time later if you have lots of mutable objects. We haven't tried the alternative approach, but it's almost certainly a case of swings and roundabouts: programs with lots of infrequently-mutated data would benefit, programs with a few often-mutated objects would lose. I guess we currently optimise for the "few often-mutated objects" case. Cheers, Simon

2 1

Re: Network Exception
by Arias 14 Oct '05

14 Oct '05

Thanks for the reply. I don't know if the problem is the same, but when I try to run this code: main = withSocketsDo $ do host <- getHostName putStrLn host the getHostName throws this exception: getHostName: failed (Successful WSAStartup not yet performed (WSANOTINITIALISED)) :( I'm using Windows XP Professional Sigbjorn Finne escribió: > Hi, > > that error message is a bit confusing, to say the least: > getProtocolByName identifies itself as getServiceEntry > when failing. In this case, I'm quite sure, your snippet > fails because (getProtocolByName "tcp") isn't successful. > I've no idea why your /etc/protocols doesn't contain an entry > for 'tcp'. > > The error message in said function has now been fixed; thanks > for the report. > > --sigbjorn > > ----- Original Message ----- From: "Arias" <arias(a)elleondeoro.com> > To: <glasgow-haskell-users(a)haskell.org> > Sent: Friday, October 14, 2005 06:47 > Subject: Network Exception > > >> Hi, >> >> I've a problem, I'm using this code on GHC compiler version 6.4.1: >> >> --- BEGIN --- >> module Main where >> import System.IO >> import Network >> >> main = withSocketsDo $ do >> handle <- connectTo "localhost" ( PortNumber 8080 ) >> hSetBuffering handle LineBuffering >> hClose handle >> --- END --- >> >> The problems is that it throws an exception at connectTo, the >> exception is: >> >> getServiceEntry: does not exist (no such service entry) >> >> The server and the port is correct, I have apache listening on port >> 8080 and if I put http://localhost:8080/ on browser it loads a web page. >> >> Do somebody knows what it happens and how to fix it? thanks. >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > >

1 0

Help wanted! Win32 and HGL for GHC on Windows
by Simon Peyton-Jones 14 Oct '05

14 Oct '05

Dear GHC users This is an appeal for help with the libraries/Win32 package [on Windows, obviously] libraries/HGL package [on Windows] Here's the situation: * Win32 provides access to the native Windows API, which is obviously very useful for people writing Haskell on Windows. HGL, the "Haskell Graphics Library", is the graphics package used by Paul Hudak's book "The Haskell School of Expression". * The libraries/Win32 package is supposed to supercede the old hslibs win32 package. Ross Paterson ported the latter to become the former, but the libraries/Win32 package had not received very much testing, and Ross can't do any more himself. We aren't confident that it's reliable. (Sadly, the two packages have the same name (modulo case) which has given rise to much confusion. But that's another matter.) * The libraries/HGL package works fine on Unix, where it sits on top of the libraries/X11 package. But it does not work properly on Windows, where it sits on top of libraries/Win32. It is not clear whether the problem is with the HGL package or the Win32 package. So the current situation is that, for GHC on Windows, the new hierarchical libraries world lacks (a) a reliable Win32 package and (b) a HGL package that works at all. This is sad, especially as we are trying to nuke hsllibs altogether. Question: would anyone be willing to fix the libraries/Win32 package; and (better still) look after it thereafter? We'd be delighted to give commit rights to anyone who was willing to do this. [So far as we know the two libraries/ packages work ok in Hugs, so there probably isn't that much to do.] Many thanks Simon

3 3

RE: Default name of target executable
by Simon Marlow 14 Oct '05

14 Oct '05

On 13 October 2005 18:57, Tomasz Zielonka wrote: > On 10/11/05, Tomasz Zielonka <tomasz.zielonka(a)gmail.com> wrote: >> On 10/11/05, Simon Marlow <simonmar(a)microsoft.com> wrote: >>> Ok, let's close this bikeshed. Someone want to send us a patch? >> >> I will try to do this > > On which branch of GHC should I be working? > There are some differences between HEAD and STABLE > in the relevant areas. We always work on HEAD first, and port changes to STABLE if appropriate. Cheers, Simon

1 0

RE: Default name of target executable
by Simon Marlow 13 Oct '05

13 Oct '05

On 11 October 2005 11:04, Duncan Coutts wrote: > I'd tend to agree. > > It'd mean one less magic incantation to tell students when teaching > practicals (and one less thing for them to get wrong) if they can do: > > ghc --make Main.hs > > rather than > > ghc --make Main.hs -o Main > > (that's one advantage of ghci for teaching students, that 'ghci > Blah.hs' "Just Works"tm) Ok, let's close this bikeshed. Someone want to send us a patch? Cheers, Simon

2 2

RE: GHC-6.4.1 on FreeBSD-amd64 still not ported
by Simon Marlow 12 Oct '05

12 Oct '05

On 25 September 2005 18:54, Wilhelm B. Kloke wrote: > Though I have reported some sort of success on this in the last days, > I was too early. The ghc-inplace does not work on the target system. > It compiled because I have been too lax in following the instructions. > Here is the report, where the crossport fails on the i386host system: > > tar czf ghc-6.4.1-x86_64-unknown-freebsd-hc.tar.gz `cat > hc-files-to-go` > tar: ghc-6.4.1/ghc/rts/PrimOps.hc: Cannot stat: No such file or > directory > tar: ghc-6.4.1/ghc/rts/StgStartup.hc: Cannot stat: No such file or > directory > tar: ghc-6.4.1/ghc/rts/StgStdThunks.hc: Cannot stat: No such file or > directory > tar: ghc-6.4.1/ghc/rts/Updates.hc: Cannot stat: No such file or > directory > tar: ghc-6.4.1/ghc/rts/Apply.hc: Cannot stat: No such file or > directory > tar: ghc-6.4.1/ghc/rts/Exception.hc: Cannot stat: No such file or > directory > tar: ghc-6.4.1/ghc/rts/HeapStackCheck.hc: Cannot stat: No such file > or directory > tar: ghc-6.4.1/ghc/rts/StgMiscClosures.hc: Cannot stat: No such file > or directory > tar: ghc-6.4.1/libraries/haskell-src/Language/Haskell/Parser.hs: > Cannot stat: No such file or directory > gmake: *** [hc-file-bundle] Fehler 1 > > bash-2.05b$ (cd ghc/rts; gmake PrimOps.o ) > ../../ghc/compiler/ghc-inplace -H16m -O -H32m -keep-hc-files -static > -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h > -#include RtsUtils.h -#include StgRun.h -#include Schedule.h > -#include Printer.h -#include Sanity.h -#include STM.h -#include > Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h > -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h > -#include Apply.h -fvia-C -dcmm-lint -c PrimOps.cmm -o PrimOps.o > In file included from PrimOps.cmm:28: > /home/wb/Haskell/fptools-i386amd64/ghc-6.4.1/ghc/includes/Cmm.h:288:2: > #error mp_limb_t != StgWord: assumptions in PrimOps.cmm are now false > gmake: *** [PrimOps.o] Fehler 1 > > Similar messages for attemps to make other of the failing .hc files. > Perhaps crossporting from a 64bit system is easier. I presume that > once a working ghc is available, life is much easier, as Fedora > Linux-64 does not report problems. GHC is correctly generating the .hc file from the .cmm file, and then attempting to compile the .hc file using gcc. This latter step fails, as expected, because the .hc code is intended to be compiled on the target system. We just need to get those .hc files and take them to the target. Just doing 'make -k' in ghc/rts should leave all the .hc files behind, because you already have the -keep-hc-files flag in your command line, so GHC won't delete the intermediate .hc files even when the subsequent compilation stage fails. Cheers, Simon

2 1

Default name of target executable
by Tomasz Zielonka 12 Oct '05

12 Oct '05

Hello! When I work on a program which is going to be named LongProgramName, I usually put the Main module in file LongProgramName.hs. It would be nice if I could build it with --make like this: $ ghc --make LongProgramName instead of $ ghc --make LongProgramName -o LongProgramName Does anyone rely on the first one producing a.out? Because of this long syntax and comand-line completion I've even once lost the source code. I forgot to remove the .hs at the end of line: $ ghc --make Prog -o Prog.hs Best regards Tomasz

8 15

RE: How to make Data.Set.Set a Functor
by Simon Marlow 12 Oct '05

12 Oct '05

On 11 October 2005 17:16, Lajos Nagy wrote: > While working on a toy compiler I realized that Data.Set.Set (Set) is > not an instance of the Functor class. In other words: 'fmap' is not > defined on it. I tried various ways of defining an instance but I > failed. The reason is quite interesting: Set is a type constructor > (* -> *) so it should qualify it for being a Functor. (In a sense it > is very similar to a Map or a list.) However, most Set functions > require the elements of the Set to be an instance of Ord. The > problem is that this constraint cannot be deduced from the instance > declaration for Functor: > > instance Functor Data.Set.Set where > fmap f s = Data.Set.map f s A nice way to do this would be: data FSet a where FSet :: Ord a => Set a -> FSet a instance Functor FSet where ... if only GADTs worked with type classes :-) Cheers, Simon

1 0

RE: Default name of target executable
by Simon Marlow 12 Oct '05

12 Oct '05

On 10 October 2005 14:12, Wolfgang Jeltsch wrote: > Am Montag, 10. Oktober 2005 11:55 schrieb Niklas Broberg: >> [...] > >> Using a shell script is a possible work-around, but certainly not >> *the* solution. If there is no real reason for ghc to spit out a.out >> files, then surely choosing the exe name from the main input file >> would simplify a programmer's life. And for applications that >> desperately want a.out, well, there's still the -o flag, right? > > Maybe the makers of GHC wanted GHC to be "GCC compatible". There's no really deep reason for this choice, other than it being what GHC does normally - i.e. the default binary has always been a.out (main.exe on Windows) unless -o is given. I don't see enough of a compelling reason to change it, sorry. It's not broken, just slightly inconvenient. Cheers, Simon

3 2

RE: GADT question
by Simon Peyton-Jones 11 Oct '05

11 Oct '05

| > I plan to tackle it in the next couple of months. | | Would this also address how plain old Algebraic Data Types and type | classes work together? The issues seems related. Well that's specified by Haskell 98, so I don't want to change it. Instead, I propose to behave sensibly (i.e. uniformly) when a data type is declared using GADT-style syntax, but leave H98 unchanged. S

1 0