#apache #archlinux #asterisk #centos #debian #gentoo #haskell #kde #kubuntu #lisp #math #mysql #perl #python #ruby-lang #rubyonrails #suse #ubuntu #vim #wikipedia 0 1 2 3 4 5 6 7 8 9
Top Prev 3420 3421 3422 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3438 Next
#haskell
<TSC> That might help (:
<TSC> It seems like it would be pretty simple to split the file up
<TSC> I don't think there are (m)any dependencies
<sorear> especially with Data.Graph
<sorear> dependency analysis is as easy as "sccs (concatMap extractDep graph)"
<araujo> Haskell ftw!
<araujo> http://dev.gentoo.org/~araujo/lasthimerge.png
<sjanssen> TSC: I've managed to make it to the linking stage
<TSC> How big is the object file?
<sjanssen> 22MB
<TSC> Hmm
<sjanssen> ghc's memory use capped around 900MB, and ld used 100MB or so
<sjanssen> and the ambient temperature in this room increased a bit :)
<TSC> Ha (:
<JohnMeacham> dons sorear: I'll take a look, jhc is in an unstable state at the moment due to using the opprotunity of switch to Data.Binary to revamp the whole ho and library file infrastructure.
<metaperl> can someone get nomaware.com up and running? I want to read the monad tutorial there
<dons> JohnMeacham: yep. understood. ping me when you've got it in a state to run over the benchmarks
<JohnMeacham> I will likely switch to using them for internal testing anyway, I knew if I waited long enough someone would do the work of writing such a suite. :)
<sorear> JohnMeacham: we're not using darcs current
<sorear> JohnMeacham: the failures are with ejthecnar
<sorear> @remember JohnMeacham [on nobench failing jhc] I will likely switch to using them for internal testing anyway, I knew if I waited long enough someone would do the work of writing such a [test] suite. :)
<lambdabot> Done.
<sorear> JohnMeacham: the good news is on my test of the nop benchmark jhc was infinitely faster than any other compiler, and I mean that quite literally
<dons> looks like its caught some issues with ghc 6.6 too (there's a stack oflow that doesn't happen in 6.4.2)
<dons> the numbers are updating here as I speak, http://www.cse.unsw.edu.au/~dons/nobench/results.html
<lambdabot> Title: nobench: Haskell implementation shootout
<sorear> within time resolution, jhc 0.00, yhc/ghc/ghc-6.4.2 0.20, ghci 0.65
<JohnMeacham> it does 'nop' well. it has been my standard benchmark so far. :)
<dons> hehe
<sorear> nop doesn a good job of shaming its slowest compiler IMO
<sorear> ghci
<sorear> I've complained for months about ghci startup time
<sorear> now, by patching nobench, I can..
<slowriot> the latest version of yampa is not compatible with ghc 6.6. This is because certain modules define functions with the same name as functions which are imported from other modules. Any calls made to those functions are ambiguous. Any ideas about how I would go about fixing this?
<sorear> import OtherModule hiding (badName)
<sorear> -or-
<slowriot> sweet. thanks
<slowriot> or...
<sorear> ... ThisModule.badName ...
<slowriot> I tried ThisModule.badName
<sorear> oh wel.
<slowriot> I still got ambiguous errors
<sorear> dons: lookie here: spectral calendar 0.78 0.89 0.77 Compile error 0.45 0.02 19.25
<sorear> note nhc98 time
<dons> calendar is bogus
<dons> nhc98 is miscompiling itto a program that does somethin gelse
<JohnMeacham> did none of the 'real' benchmarks make it in? those seem to be the most important in a lot of ways.
<sorear> JohnMeacham: two did
<dons> those are on their way. 2 are in so far, they update last
<sorear> JohnMeacham: rsa and meteor
Previous Page Next Page