September 2008 - Haskell-Cafe

OpenSPARC project applicant chosen
by Duncan Coutts 21 Sep '08

21 Sep '08

I am very pleased to announce that we have chosen Ben Lippmeier for the OpenSPARC project. Congratulations Ben! Ben will spend three months hacking on GHC to make it perform well on the latest multi-core OpenSPARC chips. I would also like to thank the other people who applied. The reviewers were very impressed by the number of strong applications. About the project ----------------- http://haskell.org/opensparc/ It is a joint project between Sun Microsystems and the Haskell.org community. Sun has provided the funding for Ben to work on this full time for three months and has donated a powerful SPARC server for him and the rest of us to use. Ben will be working with Roman Leshchinskiy as a mentor and Darryl Gove as an adviser. Roman works on Data Parallel Haskell at UNSW and Darryl is a senior staff engineer in the SPARC compiler team at Sun. If you want to follow the progress we will be using the existing ghc development mailing list: http://www.haskell.org/mailman/listinfo/cvs-ghc and a corner of the ghc development wiki: http://hackage.haskell.org/trac/ghc/wiki/OpenSPARC Duncan (project coordinator)

4 4

Hugs on the iphone
by Alberto R. Galdo 21 Sep '08

21 Sep '08

Hi, is there any chance of having hugs compile for the iPhone? Cross-compiling? Compiling directly on the iPhone? Greets, Alberto

6 12

Iteratee-based IO
by oleg＠okmij.org 21 Sep '08

21 Sep '08

brian wrote: > I want to use Parsec to parse NNTP data coming to me from a handle I > get from connectTo. > One unworkable approach I tried is to get a lazy String from the > handle with hGetContents. It seems there is another approach, which is neither unsafe nor imperative. It relies neither on lazy IO nor on Handles. The input data can come from a file or from an embedded (e.g., chunk-encoded or encrypted) stream; the depth of embedding is arbitrary. The approach is naturally incremental. It permits IO interleaving without any unsafe operations. The approach is algebraic and declarative. The approach is the topic of the DEFUN08 talk in the morning of September 27. The code is already available http://okmij.org/ftp/Haskell/Iteratee/ The file http://okmij.org/ftp/Haskell/Iteratee/README.dr describes the other files in that directory. The running example is reading lines (terminated by CR, LF or CRLF) from a file descriptor and then from the chunk-encoded body. The main example illustrates multiplexing across two file descriptors and the full IO interleaving. The same line parser is used to process data from the file descriptor stream and from the embedded chunk-encoded stream, which is incrementally decoded. The whole code is Haskell98. It is not optimized at all and has no GHC-specific pragmas and options. The code has been used for the Wc program demonstrated yesterday. Perhaps the code answers the questions posed yesterday by Don. Hopefully one can see several composition modes for the iteratees and enumerators; enumerators are just iteratee transformers and compose as such. Incidentally, the operator ==<< is flipped >>==. Just like =<< (which is flipped >>=), it is like a `call-by-value application'. When a call-by-value language evaluates the application (f e), the argument e and all of its effects are executed first. Because of this analogy, I'm tempted to rename <<== into something like $. or .$ (or perhaps <$>, although the latter is taken).

3 2

Configure bug? Re: SOLVED. Re: [Haskell-cafe] Linker Errors For OpenGL / GLUT 'Hello World' Program.
by Donnie Jones 21 Sep '08

21 Sep '08

Hello Brandon, Maybe this is a bug in the configure script of Haskell OpenGL or GLUT packages? Any suggestion from the package maintainers (or someone more familiar with these packages)? Thanks! :) __ Donnie On Sat, Sep 20, 2008 at 10:13 PM, Brandon S. Allbery KF8NH < allbery(a)ece.cmu.edu> wrote: > On 2008 Sep 20, at 22:10, Donnie Jones wrote: > > ghc -package GLUT -lglut Hello1.hs -o Hello1 --- works! :) > > I'm not sure why I must specify "-package GLUT" and "-lglut" but that > prevents the linker errors. Also, shouldn't configure correctly figure out > how to link the GLUT libraries? Can someone explain? > > > You're overriding the information recorded by ghc-pkg (which is used if you > use ghc --make). > > As for why configure doesn't work, I think you'd have to let someone who > knows the HOpenGL build stuff look at your system. > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery(a)kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery(a)ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > >

1 0

SOLVED. Re: [Haskell-cafe] Linker Errors For OpenGL / GLUT 'Hello World' Program.
by Donnie Jones 21 Sep '08

21 Sep '08

Hello, ghc -package GLUT -lglut Hello1.hs -o Hello1 --- works! :) I'm not sure why I must specify "-package GLUT" and "-lglut" but that prevents the linker errors. Also, shouldn't configure correctly figure out how to link the GLUT libraries? Can someone explain? Thank you. __ Donnie On Sat, Sep 20, 2008 at 9:47 PM, Donnie Jones <donnie(a)darthik.com> wrote: > Hello Clifford, > > Thank you for the quick reply. > I was able to get a test C program that draws a triangle with GLUT to work: > gcc -lglut triangle.o -o triangle.exe > > However, when building the Haskell GLUT 'Hello World' it uses, -lGLU to > link GLUT, but that does not work; however, from the config.log output > configure seems to think that -lGL should work. Is there a way I can change > the build to use -lglut? Maybe with configure I can specify that -lglut is > the correct way to link the GLUT libraries? > > Thank you! > __ > Donnie > > On Sat, Sep 20, 2008 at 3:42 PM, Clifford Beshers < > clifford.beshers(a)gmail.com> wrote: > It works for me. I'm running Ubuntu Hardy with some packages built by us > at SeeReason (see debs.seereason.com) > > It looks like ghc can't find your glut libraries (not the Haskell wrappers, > but the real GLUT libs). Try 'ghc -v --make ' and look at the linking lines > and see what GHC is specifying (mine shows a -lglut). Try compiling an > example C program against GLUT and see if that works. > > My package list looks like this: > beshers@blue:~/haskell$ dpkg -l \*glut\* > Desired=Unknown/Install/ > > Remove/Purge/Hold > | > Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend > |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: > uppercase=bad) > ||/ Name Version Description > > +++-==============-==============-============================================ > un freeglut-dev <none> (no description available) > ii freeglut3 2.4.0-6 OpenGL Utility Toolkit > ii freeglut3-dev 2.4.0-6 OpenGL Utility Toolkit development files > un glut-doc <none> (no description available) > un glutg3 <none> (no description available) > un glutg3-dev <none> (no description available) > ii libghc6-glut-d 2.1.1.1-2+3see Haskell GLUT binding for GHC > un libghc6-glut-d <none> (no description available) > un libghc6-glut-p <none> (no description available) > un libglut <none> (no description available) > un libglut-dev <none> (no description available) > pn libglut3 <none> (no description available) > un libglut3-dev <none> (no description available) > > > > On Sat, Sep 20, 2008 at 1:13 PM, Donnie Jones <donnie(a)darthik.com> wrote: > >> Hello Brandon, >> >> On Sat, Sep 20, 2008 at 1:02 PM, Brandon S. Allbery KF8NH < >> allbery(a)ece.cmu.edu> wrote: >> >>> On 2008 Sep 20, at 12:57, Donnie Jones wrote: >>> >>> checking GL/gl.h usability... yes >>> checking GL/gl.h presence... yes >>> checking for GL/gl.h... yes >>> checking OpenGL/gl.h usability... no >>> checking OpenGL/gl.h presence... no >>> checking for OpenGL/gl.h... no >>> checking GL/glu.h usability... yes >>> checking GL/glu.h presence... yes >>> checking for GL/glu.h... yes >>> checking OpenGL/glu.h usability... no >>> checking OpenGL/glu.h presence... no >>> checking for OpenGL/glu.h... no >>> >>> That looks like to me that the gl.h and glu.h header files were found and >>> are usable (in some cases). I am able to build >>> >>> >>> Yes, you have the header. But it says nothing about whether -lGLU was >>> found, and that's where your problems are. >>> Also, that's configure output, not config.log output (which has a >>> transcript of the tests, not just the summary). >>> >>> >> ### Relevant lines that include "-lGL" or "-lGLU" in config.log ### >> configure:4634: checking for GL library >> configure:4670: gcc -o conftest -g -O2 conftest.c -lGL -lm >&5 >> configure:4676: $? = 0 >> configure:4696: result: -lGL -lm >> configure:4773: checking for GLU library >> configure:4809: gcc -o conftest -g -O2 conftest.c -lglu32 -lGL -lm >> >&5 >> /usr/bin/ld: cannot find -lglu32 >> collect2: ld returned 1 exit status >> configure:4815: $? = 1 >> configure: failed program was: >> | /* confdefs.h. */ >> | #define PACKAGE_NAME "Haskell OpenGL package" >> | #define PACKAGE_TARNAME "OpenGL" >> | #define PACKAGE_VERSION "2.2.1" >> | #define PACKAGE_STRING "Haskell OpenGL package 2.2.1" >> | #define PACKAGE_BUGREPORT "sven.panne(a)aedion.de" >> | /* end confdefs.h. */ >> | #include <GL/glu.h> >> | int >> | main () >> | { >> | gluNewQuadric() >> | ; >> | return 0; >> | } >> configure:4809: gcc -o conftest -g -O2 conftest.c -lGLU -lGL -lm >&5 >> configure:4815: $? = 0 >> configure:4835: result: -lGLU -lGL -lm >> ... >> fp_cv_check_GLU_lib='-lGLU -lGL -lm ' >> fp_cv_check_GL_lib='-lGL -lm ' >> ... >> GLU_LIBS=' -lGLU -lGL -lm ' >> ... >> GL_LIBS=' -lGL -lm ' >> ... >> #define GLU_LIBS "-lGLU" ,"-lGL" ,"-lm" >> ######################################## >> >> It seems like the OpenGL and GLUT libraries are found (after -lglu32 >> fails, I am using Debian Linux). I am not sure what to try now. >> >> Thank you for the help. :) >> __ >> Donnie >> >> >

2 1

Re: Ropes
by Rafael Gustavo da Cunha Pereira Pinto 20 Sep '08

20 Sep '08

I have been told that you could pretty much literally implement the > algorithms > from the problem specification with Seq from Data.Sequence and achieve > acceptable speed (IIRC ~ one minute for generating a whole picture). > Yes, it is straightforward to implement the algorithm when using sequences. > > Are you sure that there is no unintentional bug in your implementation that > slows things down? > The test cases on the problem definition all worked, but they touch very little of the code. I added some "trace" calls, but could not see any trouble. I also did some runs "by hand" and it seemed ok. If only Gödel was wrong... :-) -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc.

1 0

ANNOUNCE: protocol-buffers-0.2.9 for Haskell is ready
by ChrisK 20 Sep '08

20 Sep '08

Hello one and all, Amid much rejoicing, my Haskell version of protocol-buffer is now released (version 0.2.9). What is this for? What does it do? Why? Shorter answer: It generates Haskell data types that can be converted back and forth to lazy ByteStrings that interoperate with Google's generated code in C++/Java/python. It is a pure Haskell re-implementation of the Google code at http://code.Google.com/apis/protocolbuffers/docs/overview.html which is "...a language-neutral, platform-neutral, extensible way of serializing structured data for use in communications protocols, data storage, and more." Google's project produces C++, Java, and Python code. This one produces Haskell code. The release tarball (with 3 Haskell packages inside, see README in source) is at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers The darcs repository has moved to http://darcs.haskell.org/packages/protocol-buffers2/ You will also need a recent ghc compiler, the "binary" package and the "utf8-string" package from hackage.haskell.org (same site as mentioned above). The source compiles to 3 things: 1) the package "protocol-buffers" with the library API 2) the package "protocol-buffers-descriptor" with the descriptor.proto code 3) The 'hprotoc' executable which is a command line program similar to 'protoc'. The "examples" sub-directory in the code has the Haskell version of the "addressbook.proto" example and is compatible with Google's similar example code. The code generated from unittest.proto (and unittest_import.proto) includes messages TestAllTypes and TestAllExtensions which have been extensively tested by QuickCheck to ensure they can be wire encoded and decoded (see the "tests" sub-directory in the code). The user API, as exported by Text.ProtocolBuffers, allows for converting messages back and forth to the lazy ByteString type. And such messages can be merged, and the defaults accessed via the MessageAPI type class. The messages in Haskell as just regular data types and are thus immutable. Required types are simple record fields, optional types are Maybe, and repeated types are Seq (from Data.Sequence). Extensions are supported via Key data that allows access to the extension fields. Extensible messages contain an opaque ext'field entry of type ExtField that contains the map data structure to contain the extension field values. The User API allows for serializing messages as the usual series of fields. It also provides for a length prefix to be written to create delimited messages. It also provides to write a wire tag with any field number before the length and message data. This last form looks like a field on the wire, and there is a special api call to read back just the one message and its field number. This last API is similar to the one that is part of the C# API. No benchmarks have been run yet. Any suggestions? Unsupported for the moment is loading and storing "unknown" fields. It can be added sooner if someone has a use for this. Unsupported indefinitely is code generation for Services and Methods. I have yet to look into how this is presented in the other languages. The API to read a single message field, as mentioned above, might be extended to read any type instead of just messages. optional clever_quote { <autrijus> Perl: "Easy things are easy, hard things are possible" <autrijus> Haskell: "Hard things are easy, the impossible just happened" } Cheers! Chris Kuklewicz

1 0

[ANN] panda blog engine
by Jinjing Wang 20 Sep '08

20 Sep '08

For some time, I wanted a blog engine that I can * use plain text * never lose my data * configurable at ease * write in any format I want * never care about database schema * them-able without caring about programming logic panda doesn't do all of it, and is worse at these: * no web interface, except for comments * requires a virtual host, or at least be able to start a lighttpd instance * need to : troubleshoot fcgi processes ( kill them ); use SCM to manage resources; don't hate OOP (for hacking, sorry about that) those being said, * demo: http://jinjing.blog.easymic.com * code: http://github.com/nfjinjing/panda/tree/master Cheers, - jinjing

1 0

Library design question
by Andre Nathan 20 Sep '08

20 Sep '08

Hello I'm trying to write a simple graph library for a project of mine (actually, I'm porting it from OCaml) but I've got a design question right in the beginning. My Graph type is the following. data Graph a b = Graph { adjacencies :: Map Int (a, (Map Int b)) , numVertices :: Int , numEdges :: Int } Types "a" and "b" refer to vertex and edge labels (I know it's kind of weird to use a Map of Maps to represent a graph, but it helps me removing vertices later, which is something I'll need to do.) Creating an empty graph is trivial: empty :: Graph a b empty = Graph Map.empty 0 0 The issue I hit was when writing the function to add a vertex to the graph. Since I need to update the vertex counter, I've used the state monad: addVertex :: Int -> a -> State (Graph a b) () addVertex vertex label = do g <- get let adj = Map.insert vertex (label, Map.empty) (adjacencies g) put $ g { adjacencies = adj, numVertices = numVertices g + 1 } That works fine, but from the point of view of a user of the library, the addVertex function should take a "Graph a b" as its first argument, as one would expect to be able to say which graph is going to be modified. So I'm confused right now about how I should proceed. Any hints regarding that? Best regards, Andre

8 16

Ropes
by Rafael Gustavo da Cunha Pereira Pinto 20 Sep '08

20 Sep '08

On Fri, Sep 19, 2008 at 23:18, Don Stewart <dons(a)galois.com> wrote: > RafaelGCPP.Linux: > > Hi all, > > > > Is there any implementation of the rope data structure in Haskell? > > > > I couldn't find any on Hackage, and I am intending to implement it. > > There's no mature rope implementation. Can you write a bytestring-rope > that outperforms lazy bytestrings please :) > I'll give it a try, but cannot promise anything on the "outperform" part! :-) -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc.

1 0