February 2009 - Haskell-Cafe

Re: [Haskell-cafe] Performance question
by haskell＠kudling.de 26 Feb '09

26 Feb '09

>> But you can remove sqrt from the C++ implementation as well, so it only >> improves the relative performance if the C++ implementation of sqrt is >> worse than its Haskell counterpart. > >Oops, of course I mean, you only improve if Haskell's implementation is >worse than C++'s implementation :) Actually i intend to compare real life performance of comparable algorithms. If sqrt is a problem in GHC/Haskell then this would be a valuable result. I want to know about these problems and not work around them at this point. Thanks, lenny

1 0

popularity context with Cabal
by Manlio Perillo 26 Feb '09

26 Feb '09

Hi. Debian some time ago introduced the popularity context, to find the most installed/used packages: http://popcon.debian.org/ Is it possible to do something similar with Cabal? From popularity-context FAQ: "For each package, popularity-contest looks at the most recently used (based on atime) files, and reports the filename, its last access time (atime) and last change time (ctime). However, some files are not considered, because they have unreliable atime." "A computer 'vote' for a package if according to the data provided in the report, a program provided or depending on the package was used less than thirty days ago. This computation is performed by the popcon server." Manlio Perillo

3 2

Cabal package bug?
by jpaulo＠di.uminho.pt 26 Feb '09

26 Feb '09

hello all, I've used cabal to install package haskell-src-1.0.1.3 under ghc 6.10.1; Apparently, it worked fine! However, function parseModule has been given the type: parseModule :: String -> ParseResult haskell-src-1.0.1.3:Language.Haskell.Syntax.HsModule instead of simply parseModule :: String -> ParseResult HsModule as described in the Language.Haskell.Parser module; This causes conflicting types for all my other modules! Can anyone please help me on this? Any help would be very much appreciated! bests, joao -- João Paulo Fernandes Departamento de Informática Universidade do Minho www.di.uminho.pt/~jpaulo

2 1

Cabal haskell-src-1.0.1.3 package bug?
by jpaulo＠di.uminho.pt 26 Feb '09

26 Feb '09

[now with the name of the package on subject; appologies for multiple emails] hello all, I've used cabal to install package haskell-src-1.0.1.3 under ghc 6.10.1; Apparently, it worked fine! However, function parseModule has been given the type: parseModule :: String -> ParseResult haskell-src-1.0.1.3:Language.Haskell.Syntax.HsModule instead of simply parseModule :: String -> ParseResult HsModule as described in the Language.Haskell.Parser module; This causes conflicting types for all my other modules! Can anyone please help me on this? Any help would be very much appreciated! bests, joao -- João Paulo Fernandes Departamento de Informática Universidade do Minho www.di.uminho.pt/~jpaulo

1 0

Re: Hoogle and Network.Socket
by John Lato 26 Feb '09

26 Feb '09

Brandon Allbery wrote: > On 2009 Feb 21, at 20:47, Jonathan Cast wrote: >> On Sat, 2009-02-21 at 07:25 -0700, John A. De Goes wrote: >>> Not showing platform-specific packages by default *might* make >>> package >>> writers more likely to develop cross-platform packages. We've heard >>> many times someone say, "I don't know if it works on Windows, never >>> really thought of that." >> >> Um, why *should* I think of that? > > I have to second this; I'm a Unix sysadmin, 98% of the time if I'm > writing a program it's for Unix *and* requires POSIX APIxs, and even > if it could apply to Windows the program needed there would be very > significantly different. And we have a Windows group for that. > I completely disagree, for the following reasons: 1. It's often easier (and almost never more difficult) to design for cross-platform support from the beginning than to add it later. 2. As of now, the "Windows Group" seems to be mostly Duncan. And while I greatly appreciate all the time and effort he continues to put into Windows support, he's got a lot to do and could use some help. If you can't help by joining the Windows group, at least you could make your own packages cross-platform. 3. It contributes to the "Avoid success at all costs" mantra often attributed to Haskell. I'm pretty sure that some people prefer this, but many (including myself) consider it at best misguided, and possibly harmful. 4. Cross-platform concerns are something that responsible developers need to consider, just like localization and i18n. I.e., why *shouldn't* you think of that? In some situations, it is true that a project is particularly tied to a Posix (or Windows) feature, and it wouldn't make sense to attempt a cross-platform version. If you're a Unix sysadmin and you use Haskell, that may be true most or all of the time. But for many packages, including most packages on hackage, it should be given consideration. Cheers, John Lato

6 8

speed: ghc vs gcc
by Bulat Ziganshin 25 Feb '09

25 Feb '09

Hello haskell-cafe, since there are no objective tests comparing ghc to gcc, i made my own one. these are 3 programs, calculating sum in c++ and haskell: main = print $ sum[1..10^9::Int] main = print $ sum0 (10^9) 0 sum0 :: Int -> Int -> Int sum0 0 !acc = acc sum0 !x !acc = sum0 (x-1) (acc+x) main() { int sum=0; //for(int j=0; j<100;j++) for(int i=0; i<1000*1000*1000;i++) sum += i; return sum; } execution times: sum: ghc 6.6.1 -O2 : 12.433 secs ghc 6.10.1 -O2 : 12.792 secs sum-fast: ghc 6.6.1 -O2 : 1.919 secs ghc 6.10.1 -O2 : 1.856 secs ghc 6.10.1 -O2 -fvia-C : 1.966 secs C++: gcc 3.4.5 -O3 -funroll-loops: 0.062 secs -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

30 111

MapReduce reverse engineered
by Galchin, Vasili 25 Feb '09

25 Feb '09

Hello, Here is an interesting paper of Google's MapReduce reverse engineered into Haskell. I apologize if already posted ..... http://www.cs.vu.nl/~ralf/MapReduce/ Kind regards, Vasili

6 7

forall & ST monad
by Peter Verswyvelen 25 Feb '09

25 Feb '09

I'm having trouble understanding the explanation of the meaning of the signature of runST at http://en.wikibooks.org/wiki/Haskell/Existentially_quantified_types I could try to read the article a couple of times again, but are there any other good readings about these existentially quantified types and how the ST monad works? I'm currently only using forall in combination with type classes, as in data MVC m v = forall c. Controller c => MVC m v c However - as the article mentions - forall can also be used to constrain the scope of type variables, but I don't get it yet. Thanks!

11 28

Re: [Haskell-cafe] MapReduce reverse engineered
by Alberto G. Corona 25 Feb '09

25 Feb '09

2009/2/25 Alberto G. Corona <agocorona(a)gmail.com> > And it would solve a lot of problem: scalability, system re-configuraition > and installation: just by adding or removing nodes at runtime.. heavy > numerical computations are also good candidates. > > 2009/2/25 Rick R <rick.richardson(a)gmail.com> > > I agree. A distributed database could be made as usable as a standard >> RDBMS by offering an interface by which you supply a map/reduce pair >> of functions and a list (range?) of keys. >> >> This could be easily implemented with a database such as Scalaris, in >> which the Chord algorithm is responsible for placing and finding the >> data among nodes. >> >> The user would interface with any node in the distributed database, >> supplying a map and reduce function. It would distribute the map >> function to nodes of its choosing (weighted by some metrics such as >> idle cpu), retrieve the intermediate sets and run reduce if supplied. >> >> >> 2009/2/25 Alberto G. Corona <agocorona(a)gmail.com>: >> > Galchin, >> > >> > Maybe you are asking not only about remote execution, but also mobility >> of >> > code. This is a problem that is previous to mapReduce, since mapReduce >> > assumes that all the code (and the data) is in place in the respective >> > nodes. In fact, the distribution of resources in order to efficiently >> use >> > mapReduce is a design problem that the google people has done by hand. >> > But my intuition says that there are a general algorithm for >> distribution >> > of code, data, bandwidth and resources in general that moves around at >> > execution time to achieve better and better performance for a given grid >> of >> > nodes and for any task, for example, a mapReduce task. I would be very >> > interesting to read something about this. >> > I know that some efforts have been carried out the past , for example >> mobile >> > haskell >> > >> http://homepages.inf.ed.ac.uk/stg/workshops/TFP/book/DuBois/duboismhaskell/… >> > which is a first step for this goal but I this has been discontinued and >> the >> > source code is not available. >> > >> > 2009/2/25 Galchin, Vasili <vigalchin(a)gmail.com> >> >> >> >> Hello, >> >> >> >> Here is an interesting paper of Google's MapReduce reverse >> engineered >> >> into Haskell. I apologize if already posted ..... >> >> http://www.cs.vu.nl/~ralf/MapReduce/ >> >> >> >> Kind regards, Vasili >> >> >> >> _______________________________________________ >> >> Haskell-Cafe mailing list >> >> Haskell-Cafe(a)haskell.org >> >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >> > >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe(a)haskell.org >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >> > >> >> >> >> -- >> We can't solve problems by using the same kind of thinking we used >> when we created them. >> - A. Einstein >> > >

1 0

cabal install profiling and documentation
by Ben 25 Feb '09

25 Feb '09

i've gone and cabal installed a lot of packages, but now i want to go back and install their profiling libraries and documentation. is there an easy way of doing this, short of reinstalling all of them (in the proper dependency order)? ben

1 0