- Haskell-Cafe - Haskell.org

lhs2tex build failure
by Permjacov Evgeniy 15 Dec '10

15 Dec '10

Hello! I use ghc-7.0.1 and cabal 1.10.0 . When tried to install lhs2tex-1.16 I got error in Setup.lhs: =============================== Setup.hs:294:46: `programArgs' is not a (visible) field of constructor `ConfiguredProgram' Setup.hs:296:46: `programArgs' is not a (visible) field of constructor `ConfiguredProgram' =============================== s/programArgs/programDefaultArgs/ resolves error (cabal changed ConfiguredProgram definition) however, later I had another problem when compiling: =============================== [16 of 19] Compiling MathPoly ( MathPoly.lhs, dist/build/lhs2TeX/lhs2TeX-tmp/MathPoly.o ) MathPoly.lhs:361:39: Ambiguous type variable `tok' in the constraint: (CToken tok) arising from a use of `mkFromTo' Probable fix: add a type signature that fixes these type variable(s) In the expression: mkFromTo fstack rn n rc [fromToken $ TeX False (indent (rn, rc) (n, c))] p ls In the expression: let rstack = dropWhile (\ (rc, _) -> rc >= c) stack (rn, rc) = findrel (n, c) rstack fstack = (c, l) : rstack in mkFromTo fstack rn n rc [fromToken $ TeX False (indent (rn, rc) (n, c))] p ls In a case alternative: Poly p@(((n, c), ts, ind) : rs) | first -> let rstack = dropWhile (\ (rc, _) -> ...) stack (rn, rc) = findrel ... rstack .... in mkFromTo fstack rn n rc [fromToken $ TeX False (indent (rn, rc) (n, c))] p ls | c `elem` z -> mkFromTo stack n (n ++ "E") c ts rs ls =============================== I cannot fix it on my own. Any suggestions ? Sorry, by I do not want downgrade, if possible.

2 1

Re: [Haskell-cafe] Functor => Applicative => Monad
by Max Bolingbroke 15 Dec '10

15 Dec '10

3, John Smith <voldermort(a)hotmail.com> wrote: > I would like to formally propose that Monad become a subclass of > Applicative I'm not in favour of this change because of the code breakage issue. However, I think that an acceptable plan (mentioned elsewhere on the list, but doesn't seem to have had any subsequent discussion) would be to introduce a GHC warning for such cases: "Warning: you are declaring a Monad instance for MyMonad without a corresponding Applicative instance. This will be an error in GHC 7.2" Then in 7.2 you can remove the warning and change the class hierarchy. (Substitute 7.4 for 7.2 if you think we need more time for library authors to update, or if you add the warning only to the 7.2 series). Cheers, Max

1 0

Iteratee-like
by Permjacov Evgeniy 15 Dec '10

15 Dec '10

Ok, I think, I made it right now. I wrote two versions of the very same module with roughly the same interface. It is minimalistic framework for producing, transforming, zipping and folding streaming data (a sample code that does file IO provided, but it is not well tested yet). One version abuses CPS-style, requires rank2types, but should be slightly faster and has cleaner code. Other version is plain haskell-98 and should be reasonable portable, but is tricky at some plases and still uses CPS for specifing stream processors. I want to add many things, but currently I want to document code properly so it be easy to read (BTW, has someone any article, produced from *.lhs with good typesetting and with *.lhs itself avaible? ) current links https://github.com/permeakra/Rank2Iteratee https://github.com/permeakra/PassiveIteratee The main difference from 'original' iteratees I read about is that both do not use 'chunks' and pass data one-by-one. So, what I wrote may be slower, but should be easier to maintain and more transparent for ghc optimising facilities. I wanted as clean and simple code as possible, but it is still very, very messy at some places and I want it cleaner. Any suggestions? I also want to check, how good ghc does its work with this messy modules. They may become interesting benchmarks.

1 0

Taking the TLS package for a spin ... and failing
by Mads Lindstrøm 14 Dec '10

14 Dec '10

Hi Haskellers, I am trying to connect a Java client to a Haskell server using the Haskell tls package, and things are not working out for me. There is a lot of steps involved and I do not know what I am doing wrong, so this is a long message. But first I create a private/public key-pair: > openssl genrsa -out privkey.pem 2048 then I make a self-signed certificate: > openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095 > Country Name (2 letter code) [AU]: > State or Province Name (full name) [Some-State]: > Locality Name (eg, city) []: > Organization Name (eg, company) [Internet Widgits Pty Ltd]: > Organizational Unit Name (eg, section) []: > Common Name (eg, YOUR name) []:192.168.1.6 > Email Address []: then I convert the certificate to DER format and stuff it into a Java keystore: > openssl x509 -in cacert.pem -out cert.der -outform DER > keytool -keystore myKeystore.store -importcert -storepass foobar -keypass foobar -file cert.der now I start the Haskell server: > ghc -hide-package monads-tf Server.hs -e main and then the Java client: > javac Client.java > java -Djavax.net.debug=all -Djavax.net.ssl.trustStore=myKeystore.store -Djavax.net.ssl.trustStorePassword=foobar Client >JavaClientOutput.txt 2>&1 The server output is: > <interactive>: user error (unexpected type received. expecting handshake ++ Left (Error_Packet "invalid type")) and not "Hello world" as expected. The client output is very long, but the most interesting part is properly: > main, received EOFException: error > main, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake > main, SEND TLSv1 ALERT: fatal, description = handshake_failure I have attached the Haskell server, the Java client and the full java output. Hope somebody can help figure out what I do wrong. I am using the Haskell tsl package version 0.3.1. And I run Debian Linux. I also tried connecting a Java client to a Java server. First create server keystore: > openssl pkcs8 -topk8 -nocrypt -in privkey.pem -inform PEM -out privkey.der -outform DER > java -Dkeystore=myServerKeystore.store ImportKey privkey.der cert.der ImportKey.java can be found here http://www.agentbob.info/agentbob/79-AB.html . then start Java server: > javac JavaServer.java > java -Djavax.net.ssl.keyStore=myServerKeystore.store -Djavax.net.ssl.keyStorePassword=importkey JavaServer and run the client again: > java -Djavax.net.debug=all -Djavax.net.ssl.trustStore=myKeystore.store -Djavax.net.ssl.trustStorePassword=foobar Client and the server outputs: > Hello world as expected. Thus I think the certificates are fine, and the Java client is fine. But what am I doing wrong in the Haskell server? I have attached JavaServer.java. Regards, Mads Lindstrøm

3 7

CBRef, a wrapper around IORef with callbacks
by Dmitry V'yal 14 Dec '10

14 Dec '10

Hello, while building GUIs using Gtk2HS I always struggled with the following question: how to sync the state of the GUI with the state of the rest application. I usually make several IORefs store the state there. But it's quite easy to forget to update relevant parts of GUI when state changes, especially then it's done in several places, say, by user's request and by some internal event. Some time ago I realized a pattern which proved to be useful for me several times. I wrapped IORef in a type: data CBRef a = CBRef {v_ref :: IORef a, callbacks :: IORef [a -> IO()] } now I add callbacks using addCB :: CBRef a -> (a -> IO()) -> IO () addCB r cb = modifyIORef (callbacks r) (++[cb]) which fires then the value is changed: writeCBRef :: CBRef a -> a -> IO () writeCBRef r v = do writeIORef (v_ref r) v cbs <- readIORef (callbacks r) mapM_ ($ v) cbs all the remaining IORef-like interface is present too. By using these callbacks for updating GUI I can be sure all it's parts are in sync. I suspect it's a special case of more general idea. Can anyone give a hint? Also, do you think it's useful enough to be uploaded to Hackage? Or maybe something similar is already there? How do you organize your GUI applications? Best wishes, Dmitry

1 0

Re: [Haskell-cafe] Conditional compilation for different versions of GHC?
by Brandon S Allbery KF8NH 14 Dec '10

14 Dec '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/7/10 06:00 , Henning Thielemann wrote: > Brandon S Allbery KF8NH wrote: >> Since the base package is (with good reason) part of the compiler, anyone >> smart enough to get that to work is smart enough to edit the cabal file. > > There are good reasons for not only bundling 'ghc' package with GHC, but > 'base', too? I assumed it is intended to untangle 'base' and GHC in future, > such that 'base' can be used with JHC, UHC, Hugs. I seem to recall that the logistics of that change have been proving a bit difficult in practice, and as such it's probably not going to happen very soon. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery(a)kf8nh.com system administrator [openafs,heimdal,too many hats] allbery(a)ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz+9HYACgkQIn7hlCsL25XXPQCfa/x9ZyhUmN88vu3/EPv8Tjhq +5EAniBq3G9gto/IC8kyYFP2rAjTxB/4 =LnDx -----END PGP SIGNATURE-----

3 2

Re: [Haskell-cafe] [Haskell] Functor => Applicative => Monad
by Conor McBride 14 Dec '10

14 Dec '10

[switching to cafe] On 14 Dec 2010, at 08:59, Sittampalam, Ganesh wrote: > John Smith wrote: >> I would like to formally propose that Monad become a subclass of >> Applicative, with a call for consensus by 1 February. > > I would prefer that we have some proposal like class aliases > implemented > before we start fundamental restructuring of basic type classes. This > would help to limit the disruption these changes cause, which will be > substantial. I'm inclined to agree. What's even more galling than not having Functor and Applicative instances for Monads is having to write them! At the very least, can we open this particular vessel of vermicular splendidity and verify that the inmates are still grinning with persistence? If I recall, the class alias proposal was rather more ambitious than necessary to solve this problem (though that is no crime), but still a little wrinkled in the corners. Looking at the relevant webpages, I see the proposal has lots of attractive motivational examples, but less by way of definition. But perhaps, somewhere, it has been defined enough for a prototype? It's surely worth looking at some way to define default instances for superclasses, provided they can be overridden or switched off. Where did this train of though leave the rails, again? Cheers Conor

1 0

Re: [Haskell-cafe] Offer to mirror Hackage
by Brandon Moore 14 Dec '10

14 Dec '10

On Dec 13, 2010, at 6:15 PM, wren ng thornton <wren(a)freegeek.org> wrote: On 12/13/10 8:25 AM, Paul Sargent wrote: How about, as a cheep and cheerful method to get up running. If the premise is that the original server is trustworthy and the mirrors aren't, then: 1) Hash all packages on the original server. 2) Hash goes into a side car file (e.g.<packagename>.sha) that lives next to the package If hashed are added to the package information "cabal update" downloads, installing packages from mirrors will continue to work during a central outage. I still contend that we shouldn't have to trust the central server either. The hash can be created alongside the sdist on the maintainer's computer, and then both are uploaded to central. Thus, the maintainer can verify that the hash on central matches their own, which ensures that: For now, it's enough to find a simple scheme where adding untrusted mirrors is no worse than the current situation. Hashes seem to work for that: 1. cabal update always reads from the central server (if uploads are impossible when the central server is down, the package lit won't even get stale) 2. The package descriptions are extended with hashes 3. Cabal may download packages from mirrors, but checks the hash. Your proposal doesn't narrow trust to the maintainers (which is currently open to the public anyway), because an adversary as described could return the correct hash and package for the maintainer, and the corrupted version to others. Brandon

2 1

[ANNOUNCE] haskell-mpi-1.0.0
by Dmitry Astapov 14 Dec '10

14 Dec '10

Dear Haskellers, We are pleased to announce the release of haskell-mpi-1.0.0, a suite of Haskell bindings to the C MPI library and convenience APIs on top of it. About MPI --------- MPI, the Message Passing Interface, is a popular communications protocol for distributed parallel computing (http://www.mpi-forum.org/) MPI applications consist of independent computing processes which share information by message passing. It supports both point-to-point and collective communication operators, and manages much of the mundane aspects of message delivery. There are several high-quality implementations of MPI available, all of which conform to the standard API specification (the latest version of which is 2.2). The MPI specification defines interfaces for C, C++ and Fortran, and bindings are available for many other programming languages. About Haskell-MPI ----------------- As the name suggests, Haskell-MPI provides a Haskell interface to MPI, and thus facilitates distributed parallel programming in Haskell. It is implemented on top of the C API via Haskell's foreign function interface. Haskell-MPI provides three different ways to access MPI's functionality: * A direct binding to the C interface (see Control.Parallel.MPI.Internal). * A convenient interface for sending arbitrary serializable Haskell data values as messages (see Control.Parallel.MPI.Simple). * A high-performance interface for working with (possibly mutable) arrays of storable Haskell data types (see Control.Parallel.MPI.Fast). We do not currently provide exhaustive coverage of all the functions and types defined by MPI 2.2, although we do provide bindings to the most commonly used parts. In future we plan to extend coverage based on the needs of projects which use the library. The package is available from http://hackage.haskell.org/package/haskell-mpi. Examples and comprehensive testsuite are included in the source distribution. Code was tested on 32- and 64-bit platforms, with MPICH2 and OpenMPI. The Fast API shows performance comparable to C, and the Simple API is generally 2-7 time slower due to (de)serialization overhead and necessity to issue additional MPI requests behind the curtains in some cases. Bernie Pope started this project as a rewrite of hMPI which was written by Michael Weber and Hal Daume III. He was later joined by Dmitry Astapov, working on the library as part of Well-Typed LLP's Parallel Haskell Project. Development is happening on GitHub, in git://github.com/bjpop/haskell-mpi. Please join in! Sincerely yours, Dmitry Astapov, Bernie Pope -- Dmitry Astapov Well-Typed LLP, http://www.well-typed.com/

3 2

Re: [Haskell-cafe] admission to graduate program in CS
by Johann Bach 14 Dec '10

14 Dec '10

Can I get some recommendations for CS textbooks to study for the CS GRE? Note that I am already fluent in C++ and Python (and getting better at Haskell), so I don't need hand-holding in learning the very basics... however, I do need to review the standard theory. For example, if the GRE asks: "What are the fundamental elements of OO?" I'm actually not sure what the answer is. (There's a difference between using an OO language, and talking about the theory behind it. In garden-variety programming we never talk about the theory.) I assume that any textbook is going to include the basics---I can skim through those parts. But I would be curious if there is a textbook that quickly gets into the deep stuff (and is particularly relevant to the GRE). Thanks, J

2 1