- Haskell-Cafe - Haskell.org

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

control-timeout with gtk
by Marco Túlio Gontijo e Silva 19 Sep '08

19 Sep '08

Hello, I've written a simple sequencer[0] using gtk2hs and control-timeout[1]. In GHCi it works fine, but when I compile it, the timeouts generated by control-timeout are not executed. Actually, when I use the keyboard a lot, at some time they got executed. I thought it could be that these two packages are incompatible, but the I wondered why they work in GHCi. Any ideas? Greetings. 0: http://marcot.iaaeee.org/capoeira 1: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/control-timeout -- marcot Página: http://marcotmarcot.iaaeee.org/ Blog: http://marcotmarcot.blogspot.com/ Correio: marcot(a)riseup.net XMPP: marcot(a)jabber.org IRC: marcot(a)irc.freenode.net Telefone: 25151920 Celular: 98116720 Endereço: Rua Turfa, 639/701 Prado 30410-370 Belo Horizonte/MG Brasil

6 10

ANNOUNCE: Extensible and Modular Generics for the Masses (EMGM) 0.1
by Sean Leather 19 Sep '08

19 Sep '08

Extensible and Modular Generics for the Masses ============================================== Extensible and Modular Generics for the Masses (EMGM) is a library for generic programming in Haskell using type classes. This is the initial release of a maintained library for EMGM. Other versions have previously existed in various states from various sources. We plan to continue updating and maintaining this version. Visit the home page: http://www.cs.uu.nl/wiki/GenericProgramming/EMGM Features -------- The primary features of EMGM include: * Datatype-generic programming using sum-of-product views * Large collection of ready-to-use generic functions * Included support for standard datatypes: lists, Maybe, tuples * Easy to add support for new datatypes * Type classes make writing new functions straightforward in a structurally inductive style * Generic functions are extensible with ad-hoc cases for arbitrary datatypes * Good performance of generic functions The features of this distribution include: * The API is thoroughly documented with Haddock * Fully tested with QuickCheck and HUnit * Program coverage ensures that all useful code has been touched by tests * Tested on both Mac and Windows systems Requirements ------------ EMGM has the following requirements: * GHC 6.8.1 - It has been tested with versions 6.8.3 and 6.9.20080916. * Cabal library 1.2.1 - It has been tested with versions 1.2.3 and 1.4.0.1. Download & Source ----------------- Use caball-install: cabal install emgm Get the package: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/emgm Get the source: svn checkout https://svn.cs.uu.nl:12443/repos/dgp-haskell/EMGM Examples -------- Check out the examples: https://svn.cs.uu.nl:12443/viewvc/dgp-haskell/EMGM/examples/ Bugs & Support -------------- Report issues or request features: http://code.google.com/p/emgm/ Discuss EMGM with the authors, maintainers, and other interested persons: http://www.haskell.org/mailman/listinfo/generics Credits ------- The research for EMGM originated with Ralf Hinze. It was extended with work by Bruno Oliveira and Andres Löh. More details of the library functionality were explored by Alexey Rodriguez. We are very grateful to all of these people for the foundation on which this library was built. The current authors and maintainers of EMGM are: * Sean Leather * José Pedro Magalhães * Alexey Rodriguez * Andres Löh

2 1

performance of map reduce
by Manlio Perillo 19 Sep '08

19 Sep '08

Hi again. In http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.… there is a map reduce based log parser. I have written an alternative version: http://paste.pocoo.org/show/85699/ but, with a file of 315 MB, I have [1]: 1) map reduce implementation, non parallel real 0m6.643s user 0m6.252s sys 0m0.212s 2) map reduce implementation, parallel with 2 cores real 0m3.840s user 0m6.384s sys 0m0.652s 3) my implementation real 0m8.121s user 0m7.804s sys 0m0.216s What is the reason of the map reduce implementation being faster, even if not parallelized? It is possible to implement a map reduce version that can handle gzipped log files? [1] These tests does not consider the "first run". For the first run (no data in OS cache), I have (not verified): 1) map reduce implementation, parallel with 2 cores real 0m3.735s user 0m6.328s sys 0m0.604s 2) my implementation real 0m13.659s user 0m7.712s sys 0m0.360s Thanks Manlio Perillo

4 5

Hackage and HaXml situation
by John Goerzen 19 Sep '08

19 Sep '08

Hi everyone, We've got a bit of a problem in the community regarding HaXml. This has been brought up before, but never definitively resolved, and it's causing more and more trouble. Over at the HaXml homepage [1], it is stated that 1.13.3 is the most recent stable version of HaXml. I believe that Malcolm Wallace, HaXml maintainer, has confirmed this. Over at the HaXml hackage page [2], it would appear as if 1.19.4 is the most recent stable version of HaXml. There is no provision made to mark some versions as unstable, and to make 1.13.3 the default version downloaded from Hackage. There are API incompatibilities between 1.13.3 and 1.19.4 that make it impossible for my programs to support both. This is becoming a larger and more fragmenting problem. Arch Linux looked at the Hackage package and bundled up 1.19.4. Debian looked at the HaXml website and bundles 1.13.3. So we have a situation where I can write software that builds easily with one or the other, but not both. We really need a fix for this. Some things we could do would be: 1) Make a policy that Hackage is for the "most stable branch" of software only, and remove the 1.19.x series of HaXml. 2) Malcolm could decide to bless 1.19.x as stable, fixing the instant problem, but this would still leave the problem open for the future. 3) Add support to Hackage for labeling branches, and present the stable versions by default. Thoughts? [1] http://www.cs.york.ac.uk/fp/HaXml/ [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HaXml

3 4