- Glasgow-haskell-users

RE: impressions on ghc-6.4
by Simon Marlow 09 Jun '05

09 Jun '05

On 09 June 2005 11:47, Serge D. Mechveliani wrote: > On memory expense > ----------------- > >> A difference of 2.5Mb is really very small. If you could show that >> the space usage is linear in one case and flat in another, then we >> have a problem. > > But a ratio 2600 K / 200 K for n = 55000 is not so small. > > I never tested this, but what if in this mergeSort-like example the > space sizes are > space.6.4(n) = 13*space.5.02(n) > > (which has the above ratio for n = 55000) > ? If you can demonstrate that GHC 6.4 uses 13 times more space than 5.02 on your example, then that's a performance bug - but all you showed so far is that 6.4 uses 2.5Mb more space. i.e. you need to do a few more measurements for different values of n. Cheers, Simon

1 0

setup clean in 6.4 Cabal
by Serge D. Mechveliani 09 Jun '05

09 Jun '05

The Cabal documentation for ghc-6.4 writes 3.8. setup clean ... configure or build steps Does this mean the command runghc Setup.hs clean ? I run such, and it cleans dist/*. All right. Now, what is a similar easy command for un-installing (remove .../lib/*) ? Currently, I apply rm -rf $(myPackageInstallDir)/*, but, maybe, there should be something similar to the `clean' command? ----------------- Serge Mechveliani mechvel(a)botik.ru

2 2

-O looks all right
by Serge D. Mechveliani 09 Jun '05

09 Jun '05

Forget, please, of what I wrote recently about -O doubt in ghc-6.4. I re-built the Dumatel package, and now the full test for -O shows 2 times speed up, as expected. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: impressions on ghc-6.4
by Simon Marlow 09 Jun '05

09 Jun '05

On 08 June 2005 12:27, Serge D. Mechveliani wrote: > Cabal > ----- > > It looks good. Thanks to developers. > Long ago I asked for the building tool in GHC which would allow to > avoid composing Makefile-s, with their difficult syntax and > odd-looking system commands: `ar', `ld', and such. > Now, Cabal does what I asked for. Glad you like it. See, we do listen sometimes! :-) > Remarks: > * maybe, `version' should not be mandatory in the package > specification? > * " version: 5.02 " (imagine "ghc-5.02") converts to "5.0.2" . > Could it allow digit sequences separated by period? 5.02 is parsed as 5.2 by the Version parser: > readP_to_S parseVersion "5.02" [(Version {versionBranch = [5], versionTags = []},".02"),(Version {versionBranch = [5,2], versionTags = []},"")] so I'm not sure what you're referring to here. Could you give a concrete example? > -O, memory management > --------------------- > > In ghc-6.2.2 the test for dumatel-1.02 > runs 2 times faster when Dumatel is built under -O. > And in ghc-6.4, the time does not differ. > > Then, I tried the benchmark with certain mixture of list operations: > user-written maximum and mergeSort, `reverse' and `zip' of GHC > -- find enclosed the source. > > -O is 1.3 faster than -Onot. > The speed looks like in ghc-5.02 (I think, this is all right). > 5.02 was able to run `main' for n = 55000 in 200 Kb memory. > 6.4 needs 2600 Kb. > Probably, 5.02 is distinguished among other versions in memory > management. A difference of 2.5Mb is really very small. If you could show that the space usage is linear in one case and flat in another, then we have a problem. Cheers, Simon

2 1

RE: How to open device as a IO Handle
by Simon Marlow 09 Jun '05

09 Jun '05

On 09 June 2005 02:47, Lei Pan wrote: > Could anyone tell me how to open a block device (e.g., /dev/hda1) > into a > IO Handle by using GHC (version > 5.0)? I want to open a block/char > device and return a handle. Apparently, openFile function can't do the > job. It will be very appreciated if someone could give me a hint. > > An earlier post pointed out the problem, but got no reply. > http://www.haskell.org/pipermail/glasgow-haskell-users/2001-November/002 624.html > > Something I played in GHCI-6.2.2 > > *Main> openFile "/dev/hdb2" ReadMode >>= \hin -> hGetPosn hin >>= > \pos -> print pos > > *** Exception: /dev/hdb2: openFile: unsupported operation (unknown > file type) > > (I already set /dev/hdb2 globally read/write) I'll look into fixing this. In the meantime, you should be able to use the System.Posix library to open the file directly, and then convert the FD to a Handle using GHC.Handle.openFd (I don't think fdToHandle will work in this case, because it checks the file type). Bear in mind that GHC.Handle.openFd is an internal undocumented interface, so may change in the future. Cheers, Simon

1 0

`tested-with' in package
by Serge D. Mechveliani 09 Jun '05

09 Jun '05

Who knows, please, what is the matter with the `tested-with' field in a package specification in ghc-6.4 ? Among the attempts tested-with: ghc-6.4, 5.02 tested-with: ghc-6.4 tested-with: GHC-6.4 tested-with: "GHC-6.4" tested-with: ghc tested-with: GHC only the last one satisfies the `configure' command runghc Setup.hs configire --ghc Other variants yield " Line 12: Parse of field 'tested-with' failed. " Thank you in advance for explanation. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

How to open device as a IO Handle
by Lei Pan 09 Jun '05

09 Jun '05

Hi, there, Could anyone tell me how to open a block device (e.g., /dev/hda1) into a IO Handle by using GHC (version > 5.0)? I want to open a block/char device and return a handle. Apparently, openFile function can't do the job. It will be very appreciated if someone could give me a hint. An earlier post pointed out the problem, but got no reply. http://www.haskell.org/pipermail/glasgow-haskell-users/2001-November/002624… Something I played in GHCI-6.2.2 *Main> openFile "/dev/hdb2" ReadMode >>= \hin -> hGetPosn hin >>= \pos -> print pos *** Exception: /dev/hdb2: openFile: unsupported operation (unknown file type) (I already set /dev/hdb2 globally read/write) Cheers, Lei

1 0

impressions on ghc-6.4
by Serge D. Mechveliani 08 Jun '05

08 Jun '05

Dear GHC developers and users, Here are some impressions on ghc-6.4. Cabal ----- It looks good. Thanks to developers. Long ago I asked for the building tool in GHC which would allow to avoid composing Makefile-s, with their difficult syntax and odd-looking system commands: `ar', `ld', and such. Now, Cabal does what I asked for. Remarks: * maybe, `version' should not be mandatory in the package specification? * " version: 5.02 " (imagine "ghc-5.02") converts to "5.0.2" . Could it allow digit sequences separated by period? -O, memory management --------------------- In ghc-6.2.2 the test for dumatel-1.02 runs 2 times faster when Dumatel is built under -O. And in ghc-6.4, the time does not differ. Then, I tried the benchmark with certain mixture of list operations: user-written maximum and mergeSort, `reverse' and `zip' of GHC -- find enclosed the source. -O is 1.3 faster than -Onot. The speed looks like in ghc-5.02 (I think, this is all right). 5.02 was able to run `main' for n = 55000 in 200 Kb memory. 6.4 needs 2600 Kb. Probably, 5.02 is distinguished among other versions in memory management. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru *************************************************************** -- the result of `main' must be n-1. main = putStr $ shows (test 55000 ) "\n" -- n -- to edit test :: Int -> Int test n = max' $ sort' $ zipWith (-) (reverse xs) xs where xs = [1..n] max' :: Ord a => [a] -> a max' [x] = x max' (x:y:xs) = case compare x y of LT -> max' (y:xs) _ -> max' (x:xs) sort' :: Ord a => [a] -> [a] sort' xs = s $ mergePairs [[x] | x <- xs] where s [] = [] s [xs] = xs s xss = s $ mergePairs xss mergePairs (xs:ys:zss) = (merge xs ys):(mergePairs zss) mergePairs xss = xss merge :: Ord a => [a] -> [a] -> [a] merge [] ys = ys merge xs [] = xs merge (x:xs) (y:ys) = case compare x y of GT -> y:(merge (x:xs) ys) _ -> x:(merge xs (y:ys))

1 0

RE: GHC hang
by Simon Peyton-Jones 07 Jun '05

07 Jun '05

There is definitely a performance bug somewhere in GHC, and we're collecting cases that show it up. It'd be ideal if you, or someone else, could snip out a standalone module or two that demonstrates the problem, rather than all of WASH. If not, we'll try to tackle it directly. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of John Goerzen | Sent: 06 June 2005 21:21 | To: glasgow-haskell-users(a)haskell.org | Subject: Re: GHC hang | | On 2005-06-06, Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: | > Lots of people seem to have had problems compiling Wash with GHC 6.4. | | Another person told me, perhaps in private, that it just takes GHC 15 | minutes to compile the specific file in question on amd64. It turns out | that there is not a hang bug with this. | | There were various other bugs with Wash, and I think I have got it to at | least a buildable state. See my announcement on that topic in this list | for more. | | -- John | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

3 2

RE: ghc-pkg, recompilation check
by Simon Marlow 07 Jun '05

07 Jun '05

On 06 June 2005 15:42, Serge D. Mechveliani wrote: > And in 6.4, make dm > reports > ... > " Reading package info from stdin... done. > ghc-pkg: invalid package identifier: > " The syntax of package descriptions has changed. Documentation for the new format is here: http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html#in stalled-pkg-info > Packages always were difficult. And in 6.4 they are changed again ... I'd urge you to look at using Cabal for your library, I think it'll simplify things for you a lot. In particular, you won't have to deal with ghc-pkg and you won't have to write any Makefiles. Cabal is specifically designed to make life easier for people like you! I know changes are painful, but in this case they weren't gratuitous. All the changes were to support Cabal, and we believe this is the right direction to go. If it all pans out, we won't need to make any big changes again in the future. > Question 2: recompilation > ------------------------- > > Why does it recompile both modules when after the first make dm > we remove the .a library and repeat make dm > ? > This recompilation bites when there are many modules. Unfortunately your use of -ddump-hi-diffs has forced recompilation. This is a bug: we changed it so that all -ddump-* flags forced recompilation because in most cases some intermediate output has been requested. However, -ddump-hi-diffs should be an exception. Thanks for the report - just turn off -ddump-hi-diffs. Cheers, Simon

1 0