New mailing list: haskell-i18n (was: RE: Yet more text pedantry)
tis 2002-08-13 klockan 11.57 skrev Simon Marlow: Can't we make a mailing list for these issues? [EMAIL PROTECTED] is my proposal, who can create such a list? I'll set up the list. Anyone wish to volunteer to moderate it? Does it have to be moderated? This will make things progress more slowly. Not necessarily fully moderated, but there needs to be a list admin ([EMAIL PROTECTED]) who is responsible for dealing with the messages that Mailman flags for auto-moderation, and user queries, etc. I'm already the admin for way too many lists on haskell.org, otherwise I'd volunteer myself :-) Thanks everyone who volunteered to admin the list. We now have an admin, and the haskell-i18n list has been created. Please go to http://www.haskell.org/mailman/listinfo/haskell-i18n to join. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
ANNOUNCE: HaXml-1.07
HaXml-1.07 -- http://www.haskell.org/HaXml/ Yes, hot on the heels of HaXml-1.06, another new release, 1.07. Only two days between releases. Why? * We got the location in the hierarchical namespace wrong! It should be Text.XML.HaXml, not Text.Xml.HaXml. We felt it was better to correct this as soon as possible before anyone gets too familiar with the incorrect module names. * The HaXml package now also works in GHCi (but only for ghci-5.02.3 and later). This was a simple oversight in 1.06. Regards, Malcolm ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Analyzing Efficiency
Shawn P. Garbett [EMAIL PROTECTED] writes: I've come up with three different methods of approach to solve the same problem in haskell. I would like to compare the three in terms of reductions, memory usage, and overall big O complexity. What's the quickest way to gather these stats? I don't know about quickest, but if you haven't yet tried GHC's profiling, this might be a good time to do so. Build your project, using e.g. ghc --make -prof -auto-all ... (I like to add '-hisuf p.hi -osuf p.o' in order to keep files apart from non-profiling builds, since linking with both kinds will crash your program) Then run it with ./a.out (or whatever) +RTS -p -RTS and look at the resulting file a.out.prof. Replace -p with -h to do heap profiling. Have a look at the online GHC documentation for all the details, it's pretty comprehensive and readable, IMO. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Analyzing Efficiency
I've come up with three different methods of approach to solve the same problem in haskell. I would like to compare the three in terms of reductions, memory usage, and overall big O complexity. What's the quickest way to gather these stats? I usually use the ghc compiler, but also have hugs installed. The big O complexity probably has to be done by hand, but maybe there's a tool out there to do it automagically. Apart from the normal ways (profiling, Unix 'time', GHC's +RTS -sstderr), here's another one I've been using recently: cachegrind. It's the wonderful cache profiling extension by Nick Nethercote that comes with Julian Seward's Valgrind. The great thing is that you don't even need to recompile the program - you just do 'cachegrind program', and it runs (very slowly) and outputs reliable cache statistics including how many instructions were executed. Get it from http://developer.kde.org/~sewardj/ Oh, it only works on Linux BTW. Cheers, Simon ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
