- Haskell-Cafe - Haskell.org

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 26 Feb '09

26 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

package code duplication
by Louis Wasserman 25 Feb '09

25 Feb '09

There was a question recently about being allowed to get into package internals, and I had a question. I want to use uvector's stream internals in ways that the exposed methods don't permit, but I don't especially want to use another package (e.g. vector, which does expose its internals) or reimplement my own stream fusion. Would it make sense to duplicate uvector's internals, copying licensing information and other stuff of course, inside my package? It's a suboptimal solution, but it seems better than the alternative... >< Louis Wasserman wasserman.louis(a)gmail.com

2 1

Re: [Haskell-cafe] base-4 + gtk2hs-0.10.0 licensing
by Robert Greayer 25 Feb '09

25 Feb '09

Colin Paul Adams wrote: > But IF there is no difference between LGPL and GPL for Haskell > programs, then the licensing of gtk2hs as LGPL is just a smokescreen - > it is effectively GPL, so you have to license your program as GPL. > Which I'm all in favour of :-) I actually don't think this is 100% true. With the LGPL, you can distribute your program with under a non-GPL license, as long as you provide *some mechanism* for replacing the library and recreating the program. Normally this means dynamic linking. But it also allows you (I think) to distribute your program with a GPL-incompatible-but-nevertheless-open-source license, because that provides a mechanism for replacing the library (because you can rebuild the program from source). If you license the library under GPL, you cannot even do that. At least this is my understanding...

1 0