April 2009 - Haskell-Cafe

ghci/i386/dragonfly: unhandled ELF relocation(Rel) type 15
by G.Isenmann 07 Apr '09

07 Apr '09

Hi, I am trying to get a useable ghc on i386 dragonfly2.2.0. My current problem: $ /var/tmp/ghc-6.10.2/bin/ghci GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. ghc: /var/tmp/ghc-6.10.2/lib/ghc-6.10.2/base-4.1.0.0/HSbase-4.1.0.0.o: unhandled ELF relocation(Rel) type 15 Loading package base ... linking ... ghc: unable to load package `base' Looks like HSbase-4.1.0.0.o uses three different relocation types $ objdump -r lib/ghc-6.10.2/base-4.1.0.0/HSbase-4.1.0.0.o \ | awk '{print $2}' | sort -u | grep R_ R_386_32 R_386_PC32 R_386_TLS_IE but the ghc rts/Linker.c only supports two $ grep R_386_ rts/Linker.c # define R_386_32 RELOC_32 # define R_386_PC32 RELOC_PC32 case R_386_32: *pP = value; break; case R_386_PC32: *pP = value - P; break; The third seems to be the access to thread local errno $ objdump -r lib/ghc-6.10.2/base-4.1.0.0/HSbase-4.1.0.0.o \ | grep R_386_TLS_IE 001c2682 R_386_TLS_IE errno 001c2b5b R_386_TLS_IE errno 001c2f36 R_386_TLS_IE errno The difference to linux and freebsd seems to be that the access to the errno location is not hidden inside dragonflys libc but is visible for the caller similar to $ cat t.c static __thread int tls; int *get() { return &tls; } $ gcc -c t.c $ objdump -r t.o t.o: file format elf32-i386 RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 0000000b R_386_TLS_LE tls What would be the best or easiest way to deal with this situation? -- Goetz

1 0

strange performance issue with takusen 0.8.3
by Marko Schütz 07 Apr '09

07 Apr '09

Dear All, I have an application where some simple data extracted from some source files is inserted into a PostgreSQL database. The application uses Takusen and is compiled with GHC 6.8.3. Some (59 in the test data) of the selects take on average 460ms each for a total time for this sample run of 30s. I prepare one select statement at the beginning of the run into which I then bind the specific values for every one of the selects. It does not seem to make a difference whether I do this or whether I just use a new statement for every select. For comparison, I have collected the SQL statements in a file with PREPARE ... and DEALLOCATE for _every_ select and then run this file through psql. This takes 2s! During the run of the GHC-compiled executable the cpu load goes up. In top I see %CPU of above 72%. Any ideas that might enlighten are welcome. Best regards, Marko

2 2

Re: Configuring cabal dependencies at install-time
by John Lato 07 Apr '09

07 Apr '09

> From: Jeff Heard <jefferson.r.heard(a)gmail.com> > > Is there a way to do something like autoconf and configure > dependencies at install time? Building buster, I keep adding > dependencies and I'd like to keep that down to a minimum without the > annoyance of littering Hackage with dozens of packages. For instance, > today I developed an HTTP behaviour and that of course requires > network and http, which were previously not required. I'm about to > put together a haxr XML-RPC behaviour as well, and that of course > would add that much more to the dependency list. HaXml, haxr, and > haxr-th most likely. > > so... any way to do that short of making a bunch of separate packages > with one or two modules apiece? Otherwise I'm thinking of breaking > things up into buster, buster-ui, buster-network, buster-console, and > buster-graphics to start and adding more as I continue along. > I'd be interested in hearing answers to this as well. I'm not a fan of configure-style compile-time conditional compilation, at least for libraries. It makes it much harder to specify dependencies. With this, if package Foo depends on buster and the HTTP behavior, it's no longer enough to specify "build-depends: buster" because that will only work if buster was configured properly on any given system. I think that the proper solution is to break up libraries into separate packages as Jeff suggests (buster, buster-ui, etc.), but then the total packages on hackage would explode. I don't feel great about doing that with my own packages either; is it a problem? If so, maybe there could be just one extra package, e.g. buster and buster-extras. Is there a better solution I'm missing? John Lato

5 6

threadDelay granularity
by Ulrik Rasmussen 07 Apr '09

07 Apr '09

Hello. I am writing a simple game in Haskell as an exercise, and in the rendering loop I want to cap the framerate to 60fps. I had planned to do this with GHC.Conc.threadDelay, but looking at it's documentation, I discovered that it can only delay the thread in time spans that are multiples of 20ms: http://www.haskell.org/ghc/docs/6.4/html/libraries/base/Control.Concurrent.… I need a much finer granularity than that, so I wondered if it is possible to either get a higher resolution for threadDelay, or if there is an alternative to threadDelay? I noticed that the SDL library includes the function "delay", which indeed works with a resolution down to one millisecond. However, since I'm using HOpenGL and GLUT, I think it would be a little overkill to depend on SDL just for this :). Thanks, Ulrik Rasmussen

3 5

advice on space efficient data structure with efficient snoc operation
by Manlio Perillo 07 Apr '09

07 Apr '09

Hi. I'm still working on my Netflix Prize project. For a function I wrote, I really need a data structure that is both space efficient (unboxed elements) and with an efficient snoc operation. I have pasted a self contained module with the definition of the function I'm using: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=3453 The movie ratings are loaded from serialized data, and the result is serialized again, using the binary package: transcodeIO :: IO () transcodeIO = do input <- L.hGetContents stdin let output = encodeZ $ transcode $ decodeZ input L.hPut stdout output (here encodeZ and decodeZ are wrappers around Data.Binary.encode and Data.Binary.decode, with support to gzip compression/decompression) This function (transcodeIO, not transcode) takes, on my Core2 CPU T7200 @ 2.00GHz: real 30m8.794s user 29m30.659s sys 0m10.313s 1068 Mb total memory in use The problem here is with snocU, that requires a lot of copying. I rewrote the transcode function so that the input data set is split in N parts: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=3453#a3456 The mapReduce function is the one defined in the Real World Haskell. The new function takes (using only one thread): real 18m48.039s user 18m30.901s sys 0m6.520s 1351 Mb total memory in use The additional required memory is probably caused by unionsWith, that is not strict. The function takes less time, since array copying is optimized. I still use snocU, but on small arrays. GC time is very high: 54.4% Unfortunately I can not test with more then one thread, since I get segmentation faults (probably a bug with uvector packages). I also got two strange errors (but this may be just the result of the segmentation fault, I'm not able to reproduce them): tpp.c:63: __pthread_tpp_change_priority: Assertion `new_prio == -1 || (new_prio >= __sched_fifo_min_prio && new_prio <= __sched_fifo_max_prio)' failed. internal error: removeThreadFromQueue: not found (GHC version 6.8.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Now the question is: what data structure should I use to optimize the transcode function? IMHO there are two solutions: 1) Use a "lazy" array. Something like ByteString.Lazy, and what is available in storablevector package. Using this data structure, I can avoid the use of appendU. 2) Use an "unboxed" list. Something like: http://mdounin.ru/hg/nginx-vendor-current/file/tip/src/core/ngx_list.h That is: a linked list of unboxed arrays, but unlike the lazy array solution, a snoc operation avoid copying if there is space in the current array. I don't know if this is easy/efficient to implement in Haskell. Any other suggestions? Thanks Manlio Perillo

2 2

CFP: JFP Special Issue on Generic Programming
by Matthew Fluet (ICFP Publicity Chair) 07 Apr '09

07 Apr '09

OPEN CALL FOR PAPERS JFP Special Issue on Generic Programming Deadline: 1 October 2009 http://www.comlab.ox.ac.uk/ralf.hinze/JFP/cfp.html Scope ----- Generic programming is about making programs more adaptable by making them more general. Generic programs often embody non-traditional kinds of polymorphism; ordinary programs are obtained from them by suitably instantiating their parameters. In contrast to normal programs, the parameters of a generic program are often quite rich in structure; for example they may be other programs, types or type constructors, classes, concepts, or even programming paradigms. This special issue aims at documenting state-of-the-art research, new developments and directions for future investigation in the broad field of Generic Programming. It is an outgrowth of the series of Workshops on Generic Programming, which started in 1998 and which continues this year with an ICFP affiliated workshop in Edinburgh. Participants of the workshops are invited to submit a suitably revised and expanded version of their paper to the special issue. The call for papers is, however, open. Other contributions are equally welcome and are, indeed, encouraged. All submitted papers will be subjected to the same quality criteria, meeting the standards of the Journal of Functional Programming. The special issue seeks original contributions on all aspects of generic programming including but not limited to o adaptive object-oriented programming, o aspect-oriented programming, o case studies, o concepts (as in the STL/C++ sense), o component-based programming, o datatype-generic programming, o generic programming with dependent types, o meta-programming, o polytypic programming, and o programming with modules. Submission details ------------------ Manuscripts should be unpublished works and not submitted elsewhere. Revised versions of papers published in conference or workshop proceedings that have not appeared in archival journals are eligible for submission. Deadline for submission: 1 October 2009 Notification of acceptance or rejection: 15 January 2010 Revised version due: 15 March 2010 For submission details, please consult http://www.comlab.ox.ac.uk/ralf.hinze/JFP/cfp.html or see the Journal's web page http://journals.cambridge.org/jfp Guest Editor ------------ Ralf Hinze University of Oxford Computing Laboratory Wolfson Building, Parks Road, Oxford OX1 3QD, UK. Telephone: +44 (1865) 610700 Fax: +44 (1865) 283531 Email: ralf.hinze(a)comlab.ox.ac.uk WWW: http://www.comlab.ox.ac.uk/ralf.hinze/ -------------------------------------------------------------------------------

1 0

Re: [Haskell-cafe] threadDelay granularity
by Ulrik Rasmussen 07 Apr '09

07 Apr '09

On Tue, Apr 07, 2009 at 04:01:01PM +0200, Peter Verswyvelen wrote: > Are you on Windows? Because this might be because GHC is not using a high > resolution timer for doing its scheduling, I don't know... No, Ubuntu 8.10. That may very well be, I'm not that much into the details of GHC. I'm thinking about importing a system dependent delay method through the FFI to get more control over the delay interval, but that seems like overkill too. Also, I don't know if that would introduce some nasty problems, again, I'm not that into the inner workings of GHC. For now I'll just allow the application to render as fast as possible, the primary motivation for capping the framerate was to prevent my laptop from getting so hot that I can't have it in my lap :). (I see that I replied to you instead of to the list by accident. I'm CC'ing the message to the list now) /Ulrik > On Tue, Apr 7, 2009 at 3:21 PM, Ulrik Rasmussen <haskell(a)utr.dk> wrote: > > > On Tue, Apr 07, 2009 at 02:53:20PM +0200, Peter Verswyvelen wrote: > > > I think this is an RTS option. > > > > > http://www.haskell.org/ghc/docs/latest/html/users_guide/using-concurrent.ht… > > > > Ahh, I found it now. Seems like the `-C' option didn't work because it > > still limited by the master tick interval. Using `+RTS -V0.001' helps. > > It is a bit inaccurate at that resolution though. > > > > > > > > > > > > > > On Tue, Apr 7, 2009 at 1:41 PM, Ulrik Rasmussen <haskell(a)utr.dk> wrote: > > > > > > > Hello. > > > > > > > > I am writing a simple game in Haskell as an exercise, and in the > > > > rendering loop I want to cap the framerate to 60fps. I had planned to > > do > > > > this with GHC.Conc.threadDelay, but looking at it's documentation, I > > > > discovered that it can only delay the thread in time spans that are > > > > multiples of 20ms: > > > > > > > > > > > > > > http://www.haskell.org/ghc/docs/6.4/html/libraries/base/Control.Concurrent.… > > > > > > > > I need a much finer granularity than that, so I wondered if it is > > > > possible to either get a higher resolution for threadDelay, or if there > > > > is an alternative to threadDelay? > > > > > > > > I noticed that the SDL library includes the function "delay", which > > > > indeed works with a resolution down to one millisecond. However, since > > > > I'm using HOpenGL and GLUT, I think it would be a little overkill to > > > > depend on SDL just for this :). > > > > > > > > > > > > Thanks, > > > > > > > > Ulrik Rasmussen > > > > _______________________________________________ > > > > Haskell-Cafe mailing list > > > > Haskell-Cafe(a)haskell.org > > > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > >

1 0

System.Process.Posix
by Cristiano Paris 07 Apr '09

07 Apr '09

Is it me or the above package is not included in Hoogle? Cristiano

7 8

tail recursion
by Daryoush Mehrtash 07 Apr '09

07 Apr '09

Is the call to "go" in the following code considered as tail recursion? data DList a = DLNode (DList a) a (DList a) mkDList :: [a] -> DList a mkDList [] = error <http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:error> "must have at least one element" mkDList xs = let (first,last <http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:last>) = go last <http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:last> xs first in first where go :: DList a -> [a] -> DList a -> (DList a, DList a) go prev [] next = (next,prev) go prev (x:xs) next = let this = DLNode prev x rest (rest,last <http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:last>) = *go this xs next* in (this,last <http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:last>) Daryoush

2 1

automatically inserting type declarations
by FFT 07 Apr '09

07 Apr '09

I remember hearing about a Haskell mode for Vim, Emacs, Yi or VisualHaskell that inserts type declarations automatically (it's lazier to just check the type than to write it manually), but I can't remember any details. What editor mode / IDE was it? What do most people use with GHC on Linux? I'm more used to Vim than to Emacs. Yi sounds like something I might like. Is it stable enough to solve more problems than it would create? (I hate buggy and broken stuff)

3 2