October 2002 - Glasgow-haskell-users

Optimisation
by David Sabel 21 Oct '02

21 Oct '02

What's the standard paper about optimisations and program transformation? Which transformations are used by the GHC, especially which optimisations are applied at optimisation level 0, 1 and 2? David Sabel JWGU Frankfurt

1 0

RE: compiler/doc discrepancy
by Simon Marlow 21 Oct '02

21 Oct '02

> For the profiling -i option, the compiler tells me the value is > microsecond (default 100), while the GHC documentation claims seconds > (default 0.1). > > Apparently, the documentation is correct? Yes, I noticed this one recently, it's been fixed in the tree. Cheers, Simon

1 0

compiler/doc discrepancy
by ketil＠ii.uib.no 21 Oct '02

21 Oct '02

For the profiling -i option, the compiler tells me the value is microsecond (default 100), while the GHC documentation claims seconds (default 0.1). Apparently, the documentation is correct? -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

mergesort. Reply
by Serge D. Mechveliani 21 Oct '02

21 Oct '02

Ketil Z. Malde <ketil(a)ii.uib.no> writes > I'll hereby argue for using a quicksort implementation akin to > >> sortBy' _ [] = [] >> sortBy' pc (x:xs) = let (l,e,g) = part3 (`pc` x) xs >> in sortBy' pc l ++ (x:e) ++ sortBy' pc g >> where >> part3 comp xs = p3 [] [] [] comp xs >> p3 ls es gs _ [] = (ls,es,gs) >> p3 ls es gs comp (x:xs) = case comp x of >> LT -> p3 (x:ls) es gs comp xs >> EQ -> p3 ls (x:es) gs comp xs >> GT -> p3 ls es (x:gs) comp xs > > (hopefully this is fairly bug-free) At least for my data (lots of > values, limited range), it appears to speed things up tremendously. I > haven't measured more general cases in any detail, though. And one > obvious drawback may be that it's not stable, which I think can be > alleviated by a few well placed 'reverse's. > > Comments welcome! But sortBy' (compare) [1 .. n] costs too much, even for n = 11000. It costs (on worst data) many times more than mergeSort. ----------------- Serge Mechveliani mechvel(a)botik.ru

8 11

Sesso ma vero...
by Giada 19 Oct '02

19 Oct '02

http://profondoanale.ok.vg FILMATI, FOTO, VIDEO-ANNUNCI, WEB-CAM con ragazze che potrebbero benissimo essere le tue vicine di casa... CHATTA con le ragazze della rete pi� provocanti http://profondoanale.ok.vg il sito contiene materiale erotico esplicito VIETATISSIMO minori 18 anni per cancellarti dalla news letter scrivi a writeln(a)virgilio.it writeln(a)ciaoweb.it

1 0

INVITO
by Sex Nihgt Show !!! 19 Oct '02

19 Oct '02

http://www.sexnightshow.ok.vg/ Salve, sei invitato all'inaugurazione del primo NIGHT CLUB VIRTUALE DI INTERNET !!!!! Show dal vivo, club priv�, scambiocoppie, live-chat con le nostre belliddime intrattenitrici potrai inoltre vedere le foto e i video dei loro shows http://www.sexnightshow.ok.vg/ Per non ricevere info su futuri aggiornamenti scrivi a: nomail(a)cheapnet.it

1 0

more undecidable instances, but why
by Hal Daume III 18 Oct '02

18 Oct '02

I'm being hit by undecidable instances, but I can't see why. I read and reread the GHC docs on MPTCs, but to no avail. This is what I'm trying to do: newtype S a = S a instance MArray IOUArray a IO => MArray IOUArray (S a) IO where ... the instance declaration is basically just wrapping/unwrapping S and a few castIOArrays. However, GHC complains: /nfs/isd/hdaume/projects/MESumm/Linear2/Linear2.hs:76: Non-type variables in constraint: MArray IOUArray a IO (Use -fallow-undecidable-instances to permit this) In the context: (MArray IOUArray a IO) While checking the context of an instance declaration In the instance declaration for `MArray IOUArray (S a) IO' But I don't see why this is undecidable. As I understand it, undecidable instances basically arise when context reduction might not terminate. Here, it always will (AFAICS). Any thoughts? - Hal

1 0

RE: A run-time problem?
by Simon Marlow 18 Oct '02

18 Oct '02

> I'm occasionally getting an error, when running a compiled program, I > get: > > | fatal error: GetMBlock: misaligned block 0x401fe000 returned when > | allocating 1 megablock(s) at 0xbff00000 > > apparently, this only happens on one computer (Red Hat 7.1), and not > others (Red Hat 7.2), which leads me to suspect it's a library issue. > > This is a known problem, yes? Is it possible to resolve this, apart > from upgrading the OS, or recompiling? It looks like your program is using a *lot* of memory, because the requested address is right near the top of the address space, and is probably running into the stack, hence the failure. Is that the case? I'm looking into fixing one problem that results in the getMBlock failure, but I don't think it'll help much in your case. Cheers, Simon

1 0

A run-time problem?
by ketil＠ii.uib.no 18 Oct '02

18 Oct '02

Hi, I'm occasionally getting an error, when running a compiled program, I get: | fatal error: GetMBlock: misaligned block 0x401fe000 returned when | allocating 1 megablock(s) at 0xbff00000 apparently, this only happens on one computer (Red Hat 7.1), and not others (Red Hat 7.2), which leads me to suspect it's a library issue. This is a known problem, yes? Is it possible to resolve this, apart from upgrading the OS, or recompiling? -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

RE: packages and profiling
by Simon Marlow 18 Oct '02

18 Oct '02

> I've been playing around with the package mechanism in ghc which > is great. > > However it took me quite a while to realise that when I compile > a module (say Foo.hs, for a package) with profiling, the .hi file > must be named Foo.p_hi, and not Foo.hi, when it appears in the > "import_dirs" directory. > > When the interface was called Foo.hi and I tried to use the package > the compiler complained: > > ghc-5.04: can't find module `Foo' (while processing "Main.hs") > > this is with ghc --make Thanks, I've added a note to the docs. Cheers, Simon

1 0