November 2012 - Haskell-Cafe

OpenAL - compiling problem
by Gary Klindt 28 Nov '12

28 Nov '12

Dear Haskell Cafe, I tried installing the haskell openal library via cabal install openal I get the following error: ... [ 7 of 30] Compiling Sound.OpenAL.ALC.QueryUtils ( Sound/OpenAL/ALC/QueryUtils.hs, dist/build/Sound/OpenAL/ALC/QueryUtils.o ) Sound/OpenAL/ALC/QueryUtils.hs:66:1: Unacceptable argument type in foreign declaration: ALCdevice When checking declaration: foreign import ccall unsafe "static alcGetString" alcGetString :: ALCdevice -> ALCenum -> IO (Ptr ALCchar) Sound/OpenAL/ALC/QueryUtils.hs:102:1: Unacceptable argument type in foreign declaration: ALCdevice When checking declaration: foreign import ccall unsafe "static alcGetIntegerv" alcGetIntegerv :: ALCdevice -> ALCenum -> ALCsizei -> Ptr ALCint -> IO () Sound/OpenAL/ALC/QueryUtils.hs:120:1: Unacceptable argument type in foreign declaration: ALCdevice When checking declaration: foreign import ccall unsafe "static alcIsExtensionPresent" alcIsExtensionPresent_ :: ALCdevice -> Ptr ALCchar -> IO ALCboolean Failed to install OpenAL-1.4.0.1 cabal: Error: some packages failed to install: OpenAL-1.4.0.1 failed during the building phase. The exception was: ExitFailure 1 The version of my openal installation is 1.14-1. I also tried to install via darcs, but the error is the same. Any ideas? Greets Gary

2 3

Equality test between types that returns type-level Bool ?
by Takayuki Muranushi 28 Nov '12

28 Nov '12

Is it possible to write type family SameType a b :: Bool which returns True if a and b are the same type, and False otherwise? I encountered this problem when I was practicing promoted lists and tuples in ghc-7.6.1. One of my goal for practice is to write more "modular" version of extensible-dimensional calculations, and to understand whether ghc-7.6.1 is capable of it. http://hackage.haskell.org/packages/archive/dimensional/0.10.2/doc/html/Num… Some of my attempts: https://github.com/nushio3/dimensional-tf/blob/master/attic/list-02.hs This fails because :==: is not an equality test between a and b, but is a equality test within a (promoted) kind. https://github.com/nushio3/dimensional-tf/blob/master/attic/list-03.hs This fails because type instance declarations are not read from top to bottom. (not like function declarations.) https://github.com/nushio3/dimensional-tf/blob/master/attic/map-03.hs I could define a lookup using class constraints, but when I use it, results in overlapping instances. So, will somebody teach me which of the following is correct? * We can write a type family SameType a b :: Bool * We cannot do that because of theoretical reason (that leads to non-termination etc.) * We cannot write SameType, but there are ways to write functions like 'filter' and 'merge' , over type-level lists, without using SameType. Always grateful to your help, -- Takayuki MURANUSHI The Hakubi Center for Advanced Research, Kyoto University http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html

3 4

Conduit and pipelined protocol processing using a threadpool
by Nicolas Trangez 28 Nov '12

28 Nov '12

All, I've written a library to implement servers for some protocol using Conduit (I'll announce more details later). The protocol supports pipelining, i.e. a client can send a 'command' which contains some opaque 'handle' chosen by the client, the server processes this command, then returns some reply which contains this handle. The client is free to send other commands before receiving a reply for any previous request, and the server can process these commands in any order, sequential or concurrently. The library is based on network-conduit's "Application" style [1], as such now I write code like (OTOH) > application :: AppData IO -> IO () > application client = appSource client $= handler $$ appSink client > where > handler = do > negotiateResult <- MyLib.negotiate > liftIO $ validateNegotiateResult negotiateResult > MyLib.sendInformation 123 > loop > > loop = do > command <- MyLib.getCommand > case command of > CommandA handle arg -> do > result <- liftIO $ doComplexProcessingA arg > MyLib.sendReply handle result > loop > Disconnect -> return () This approach handles commands in-order, sequentially. Since command processing can involve quite some IO operations to disk or network, I've been trying to support pipelining on the server-side, but as of now I was unable to get things working. The idea would be to have a pool of worker threads, which receive work items from some channel, then return any result on some other channel, which should then be returned to the client. This means inside "loop" I would have 2 sources: commands coming from the client (using 'MyLib.getCommand :: MonadIO m => Pipe ByteString ByteString o u m Command'), as well as command results coming from the worker threads through the result channel. Whenever the first source produces something, it should be pushed onto the work queue, and whenever the second on yields some result it should be sent to the client using 'MyLib.sendReply :: Monad m => Handle -> Result -> Pipe l i ByteString u m ()' I've been fighting this for a while and haven't managed to get something sensible working. Maybe the design of my library is flawed, or maybe I'm approaching the problem incorrectly, or ... Has this ever been done before, or would anyone have some pointers how to tackle this? Thanks, Nicolas [1] http://hackage.haskell.org/packages/archive/network-conduit/0.6.1.1/doc/htm…

2 4

ANNOUNCE: language-java 0.2.0
by Vincent Hanquez 27 Nov '12

27 Nov '12

Hi Cafe, with the approval of Niklas, the original author and maintainer, i'll be maintaining language-java for now. I've uploaded a new version on hackage [1] with some minor improvements and the repository is now hosted on github [2]. Thanks Niklas for language-java ! [1] http://hackage.haskell.org/package/language-java [2] http://github.com/vincenthz/language-java/ -- Vincent

3 3

Real-time code in Haskell (Was: Can a GC delay TCP connection formation?)
by Mike Meyer 27 Nov '12

27 Nov '12

On Tue, Nov 27, 2012 at 3:45 AM, Gregory Collins <greg(a)gregorycollins.net> wrote: > If you have a hard real-time requirement then a garbage-collected > language may not be appropriate for you. This is a common meme, but frankly, it isn't true. When writing real-time code, you just need to make sure that everything that happens takes a known maximum amount of time. Then, you can sum up the maximums and verify that you do indeed finish in the real-time window of the task. GC is a problem because it's not predictable, and may not have a maximum. However, it's no worse than a modern version of the C function malloc. Some of those even do garbage collection internally before doing an OS call if they're out of memory. The solution is the same in both cases - make sure you don't do GC (or call malloc) in the critical region. Both require knowing implementation details of everything you call, but it isn't impossible, or even particularly difficult. Lazyness, on the other hand ... I haven't thought about. I suspect you need to force the evaluation of everything you're going to need before you start the critical region, but I wonder if that's enough? Has anyone out there investigated this? Thanks, <mike

4 3

Re: [Haskell-cafe] Portability of Safe Haskell packages
by Roman Cheplyaka 27 Nov '12

27 Nov '12

* Herbert Valerio Riedel <hvr(a)gnu.org> [2012-11-24 00:06:44+0100] > Roman Cheplyaka <roma(a)ro-che.info> writes: > > It has been pointed out before that in order for Safe Haskell to be > > useful, libraries (especially core libraries) should be annotated > > properly with Safe Haskell LANGUAGE pragmas. > > > > However, that would make these libraries unusable with alternative > > Haskell implementations, even if otherwise they these libraries are > > Haskell2010. > > > > To quote the standard: > > > > If a Haskell implementation does not recognize or support a particular > > language feature that a source file requests (or cannot support the > > combination of language features requested), any attempt to compile or > > otherwise use that file with that Haskell implementation must fail > > with an error. > > > > Should it be advised to surround safe annotations with CPP #ifs? > > Or does anyone see a better way out of this contradiction? > > ...but IIRC CPP isn't part of Haskell2010, or is it? It isn't indeed. But: 1) it's a very basic extension which is supported by (almost?) all existing implementations; or 2) if you want to be 100% Haskell2010, you can name your file *.cpphs and let Cabal do preprocessing. 1) is a compromise and 2) is not very practical, so I'm eager to hear other alternatives. Roman

2 1

Problem with benchmarking FFI calls with Criterion
by Janek S. 27 Nov '12

27 Nov '12

I am using Criterion library to benchmark C code called via FFI bindings and I've ran into a problem that looks like a bug. The first benchmark that uses FFI runs correctly, but subsequent benchmarks run much longer. I created demo code (about 50 lines, available at github: https://gist.github.com/4135698 ) in which C function copies a vector of doubles. I benchmark that function a couple of times. First run results in avarage time of about 17us, subsequent runs take about 45us. In my real code additional time was about 15us and it seemed to be a constant factor, not relative to "correct" run time. The surprising thing is that if my C function only allocates memory and does no copying: double* c_copy( double* inArr, int arrLen ) { double* outArr = malloc( arrLen * sizeof( double ) ); return outArr; } then all is well - all runs take similar amount of time. I also noticed that sometimes in my demo code all runs take about 45us, but this does not seem to happen in my real code - first run is always shorter. Does anyone have an idea what is going on? Janek

5 11

1st São Paulo Haskell Meeting [1° Encontro de Haskellers em São Paulo]
by Felipe Almeida Lessa 27 Nov '12

27 Nov '12

Hey! I'd like to invite you to the 1st São Paulo Haskell Meeting! It's going to be something simple, we just want to meet each other and talk about Haskell =). We already have 9 people confirmed on the Google+ event [1], so come join us already! Cheers, PS: We still didn't set the place yet. [1] https://plus.google.com/events/cng3rcv1tjl84g2juddk1i36icg -- Felipe.

1 0

Re: [Haskell-cafe] Executables got bigger using dynamic link.
by Magicloud Magiclouds 26 Nov '12

26 Nov '12

Sorry, I left the profiling option on, which seems to suppress the dynamic options. On Mon, Oct 29, 2012 at 1:29 PM, Magicloud Magiclouds <magicloud.magiclouds(a)gmail.com> wrote: > Hi, > I set "shared: True" in ~/.cabal/config, and using ghc 7.6.1. Then > clear user space hackages and reinstall them. > First of all, I think comparing to static link, dynamic linked > executables file should be smaller. And the libraries (.so) could > benefits from caching to save memory usage. > > Well, I installed cabal-install and alex. I got this: > cabal 9.9M -> 24M > alex 2.7M -> 5.1M > Is this correct? > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > > And for G+, please use magiclouds#gmail.com. -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

2 1

Compilers: Why do we need a core language?
by citb＠lavabit.com 26 Nov '12

26 Nov '12

Hello, I know nothing about compilers and interpreters. I checked several books, but none of them explained why we have to translate a high-level language into a small (core) language. Is it impossible (very hard) to directly translate high-level language into machine code?

10 10