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
On Thu, Jun 09, 2005 at 10:29:25AM +0100, Simon Marlow wrote:
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?
Ah, I see: "sequence of natural numbers separated by dots". So, the community needs to consider "ghc-5.02" and "ghc-5.2" as equivalent. As to me, I would not complain. I do not know, people may do. 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) ? ----------------- Serge Mechveliani mechvel@botik.ru
participants (2)
-
Serge D. Mechveliani -
Simon Marlow