- Haskell-Cafe - Haskell.org

ANN: OpenCL 1.0.1.3 package
by Luis Cabellos 22 Oct '11

22 Oct '11

Hello, all. I want to show you the OpenCL package. I have done this using Jeff Heard OpenCLRaw package, but I create a new one due the lack of updates of the former. # Where to get it * Hackage page (http://hackage.haskell.org/package/OpenCL) * Repository (https://github.com/zhensydow/opencl) * Bugs (https://github.com/zhensydow/opencl/issues) * Examples (https://github.com/zhensydow/opencl/tree/master/examples) # Things: * I write it's high-level binding to OpenCL libraries, but only because I added more types to hide most of the alloc/free of the API, and hide the enums using c2hs enums. * The worst problem of the OpenCLRaw is the bad types it use, I learn to fix 32/64 bits issues with c2hs, and test it on linux machines. * Tested on Linux + NVidia only. * Jason Dagit is helping with Windows, OSX testing in own fork, also the call-conv fork in github has changes to work on Windows Please, Consider it's on experimental status but it works, I need lots of feedbacks for detect posible errors, Thanks,

4 9

Trying to install hpodder on OS X Lion
by seanh 21 Oct '11

21 Oct '11

I'd really like to get hpodder installed on OS X Lion, I can't find it packaged anywhere (macports, homebrew...) Has anyone got it working? I have the haskell platform installed from the pkg file from haskell.org: http://hackage.haskell.org/platform/mac.html So I tried `cabal install hpodder` but it failed. First I get a lot of warnings like: ld: warning: text reloc in _cZh_str to _stg_ap_pppppp_fast ld: warning: text reloc in _cZh_str to _stg_ap_ppppp_fast ld: warning: text reloc in _cZh_str to _stg_ap_pppp_fast ld: warning: text reloc in _cZh_str to _stg_ap_pppv_fast ld: warning: text reloc in _cZh_str to _stg_ap_ppp_fast ld: warning: text reloc in _cZh_str to _stg_ap_ppv_fast ld: warning: text reloc in _cZh_str to _stg_ap_pp_fast ld: warning: text reloc in _cZh_str to _stg_ap_pv_fast ld: warning: text reloc in _cZh_str to _stg_ap_p_fast ld: warning: text reloc in _cZh_str to _stg_ap_n_fast ld: warning: text reloc in _cZh_str to _stg_ap_l_fast ld: warning: text reloc in _cZh_str to _stg_ap_d_fast ld: warning: text reloc in _cZh_str to _stg_ap_f_fast ld: warning: text reloc in _cZh_str to _stg_ap_v_fast ld: warning: text reloc in _cZh_str to _stg_ap_pppppp_info I get each of those warnings many times in a row. There are some other warning when compiling things as well. Then I eventually get: cabal: Error: some packages failed to install: hpodder-1.1.5 failed during the building phase. The exception was: ExitFailure 1 Here's the error from the compiler before that: Commands/SetStatus.hs:59:33: Ambiguous type variable `e0' in the constraint: (E.Exception e0) arising from a use of `E.catch' Probable fix: add a type signature that fixes these type variable(s) In the expression: E.catch (E.evaluate (read x)) (\ _ -> fail $ "Invalid status supplied; use one of: " ++ possibleStatuses) In a case alternative: Just x -> E.catch (E.evaluate (read x)) (\ _ -> fail $ "Invalid status supplied; use one of: " ++ possibleStatuses) In a stmt of a 'do' expression: newstatus <- case lookup "status" args of { Just x -> E.catch (E.evaluate (read x)) (\ _ -> fail $ "Invalid status supplied; use one of: " ++ possibleStatuses) Nothing -> fail "setstatus: --status required; see hpodder setstatus --help" }

2 3

Functional Programmer required for a Greenfield project in a software house in London.
by Oliver Horncastle 21 Oct '11

21 Oct '11

Ideally from a high performance computing, real-time systems background (OO experience, either java or c++). Get in touch for more details. Oliver Horncastle Madison Maclean Email: Oliver.horncastle(a)madisonmaclean.com<mailto:Oliver.horncastle@madisonmaclean.com> Direct Line: 020 30 30 50 53

1 0

Betfair Opportunity
by James Peters 21 Oct '11

21 Oct '11

Hello, I currently work internally at Betfair and we seek Haskell specialists to join our research teams on a permanent basis in London. Please contact me for more details. Thanks, James C Peters Senior Research and Sourcing Consultant Office: +44 (0) 208 834 8513 http://uk.linkedin.com/in/jamescpeters Check out the Betfair Employee Blog: Betfair views | Home of Betfair's Employee Blog<http://views.betfair.com/> Betfair The #1 Global Online Sports Betting Operator. Please consider the environment before printing this e-mail. Betfair Limited | Winslow Road | Hammersmith Embankment | London | W6 9HP. Registered in England and Wales under company number 5140986. This email (which includes any attachment and any subsequent reply) is sent for and on behalf of one or more operating entities in the Betfair Group, details of which are available here<http://corporate.betfair.com/about-us.aspx>. The information in this e-mail is confidential and may contain legal advice that is subject to legal privilege. As such it is intended only for the named recipient(s). This e-mail may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not a named recipient please notify the sender immediately and delete any copies of this email. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any view or opinions presented are solely those of the author and do not necessarily represent those of the Betfair Group. Betfair(r) and the BETFAIR LOGO are registered trade marks of The Sporting Exchange Limited. ________________________________________________________________________ In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses. ________________________________________________________________________

1 0

Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
by Luis Cabellos 21 Oct '11

21 Oct '11

On Thu, Oct 13, 2011 at 9:13 PM, Martin Dybdal <dybber(a)dybber.dk> wrote: > Hi everyone > > I just found this thread today, as I don't read Haskell-cafe that > often (too bad, I know). I have been working on a set of OpenCL > bindings for the last months myself, which I'm using to implement an > OpenCL backend to the Data.Array.Accelerate library. The work is done > at the HIPERFIT research center, Uni. Copenhagen. > > My bindings are even further from the naming conventions of the OpenCL > library, but I really can't see the problem with that. People which > are used to programming OpenCL from C/C++ might have to learn how the > naming conventions of the Haskell library are, but they only need to > do this once. When the mapping between the old and the new naming > conventions are learned, they will benefit from having a more clean > interface for all future times. (No Haskell hacker should have a > problem with a steep learning curve.) I'll just add, haddock + hoogle has done a lot remove the learn all names necessity. > It is somewhat troubling that we now have five different interfaces to > OpenCL (that I know of), and I think we should join efforts and make > one library that is as stable as possible. The five libraries are: > > * OpenCL > * OpenCLRaw > * HsOpenCL > * hopencl > * The library presented by Benedict Gaster at AMD (yet to be released) > ( http://developer.amd.com/zones/OpenCLZone/publications/assets/MakingOpenCLS… > ) * OpenCLRaw for me is a dead one. The main developer make no reply. * OpenCL, HsOpenCL and hopencl are the packages more suitable tu fuse. I think that the best aproach is to use the OpenCL standard API as it is, and let more libraries that use *opencl* packages decide what high-level API offer. I like the Accelerate approach to show a better API to users. I currently working in the application that need the use of OpenCL. The package that I develop offers all I need for now, so I not upgrading it, only bugs or requested features for users. But in the future I plan for two options: a) change to the *opencl* package that gets mainstream, or b) continue with own OpenCL package because it feels ok. > My own library is available at https://github.com/HIPERFIT/hopencl and > will be released on hackage very soon (next week probably). Please > take a look at it. It is currently tested on x86_64 Linux with both > the AMD x86/x86_64 bindings and NVIDIAs CUDA bindings. They will > probably not work on Windows in their present state, and I don't have > access to a Windows machine to test it on. As Jason Dagit say, I put the stdcall call convention option in OpenCL for windows: https://github.com/zhensydow/opencl/blob/master/OpenCL.cabal Other issues to solve, How to compile in hackage server to generate documentation online? opencl.h isn't in the server so I getting errors. > > -- > Martin Dybdal >

3 4

ANNOUNCE: vector-bytestring-0.0.0.0
by Bas van Dijk 21 Oct '11

21 Oct '11

All your ByteString are belong to us... Hello, I'm pleased to announce the beta release of vector-bytestring. This library provides the type ByteString which is defined as a type synonym for a storable Vector of Word8s (from the vector package): type ByteString = Data.Vector.Storable.Vector Word8 It exports the same API as the bytestring package except that the module names are prefixed with: Data.Vector.Storable.ByteString instead of Data.ByteString. The very ambitious goal of this package is that it will eventually replace our beloved bytestring package. By basing this package on vector, we can benefit from all the optimizations (like stream-fusion!) in that library. We will also have just a single library to test, debug and optimize. TEST-SUITE I ported the bytestring test-suite to vector-bytestring. You can run it using: $ cabal configure --enable-tests; cabal build; cabal test All 54800 tests pass! Only one property doesn't hold: prop_show :: ByteString -> Bool prop_show x = show x == show (unpack x) This is because I don't provide a custom Show instance for ByteStrings but use the one from Vector which shows a vector like "fromList [1,2,3]" instead as "\SOH\STX\ETX" like bytestring does. Hopefully this is not a problem in practice. BENCHMARKS I added a criterion based benchmark-suite to vector-bytestring. It consists of over 600 benchmarks that cover almost every function in the library. Also included are benchmarks which benchmark the fusion capabilities of the library. Run it using: $ cabal configure -fbenchmark; cabal build; $ dist/build/bench/bench --help Unfortunately, bytestring still out performs us in lots of benchmarks. I believe the primary cause of this is that most functions are implemented using stream-fusion. This is highly efficient if you use a composition of these functions because they will all fuse into one single efficient loop. However if your program uses only a single function, the stream based implementation is often less efficient than an implementation that works directly on a mutable vector (like most functions in bytestring). So what we want is to use stream-fusion where possible but use mutable vectors when our program doesn't fuse. Fortunately, Roman Leshchinskiy (author of vector) has an idea how to do this: http://trac.haskell.org/vector/ticket/60 Because we don't beat bytestring in all cases yet you should consider this a beta-release and not use it in production code. INSTALLING $ cabal install vector-bytestring API DOCS http://hackage.haskell.org/package/vector-bytestring-0.0.0.0 DEVELOPING $ git clone https://github.com/basvandijk/vector-bytestring Regards, Bas

18 57

Type constructor variables no longer injective in GHC 7.2.1?
by Daniel Schüssler 21 Oct '11

21 Oct '11

Hello Cafe, say we take these standard definitions: > {-# LANGUAGE GADTs, TypeOperators, TypeFamilies, ScopedTypeVariables #-} > data a :=: b where > Refl :: a :=: a > subst :: a :=: b -> f a -> f b > subst Refl = id Then this doesn't work (error message at the bottom): > inj1 :: forall f a b. f a :=: f b -> a :=: b > inj1 Refl = Refl But one can still construct it with a trick that Oleg used in the context of Leibniz equality: > type family Arg fa > type instance Arg (f a) = a > newtype Helper fa fa' = Helper { runHelper :: Arg fa :=: Arg fa' } > inj2 :: forall f a b. f a :=: f b -> a :=: b > inj2 p = runHelper (subst p (Helper Refl :: Helper (f a) (f a))) So, it seems to me that either rejecting inj1 is a bug (or at least an inconvenience), or GHC is for some reason justified in not assuming type constructor variables to be injective, and accepting inj2 is a bug. I guess it's the former, since type constructor variables can't range over type functions AFAIK. The error message for inj1 is: Could not deduce (a ~ b) from the context (f a ~ f b) bound by a pattern with constructor Refl :: forall a. a :=: a, in an equation for `inj1' at /tmp/inj.lhs:12:8-11 `a' is a rigid type variable bound by the type signature for inj1 :: (f a :=: f b) -> a :=: b at /tmp/inj.lhs:12:3 `b' is a rigid type variable bound by the type signature for inj1 :: (f a :=: f b) -> a :=: b at /tmp/inj.lhs:12:3 Expected type: a :=: b Actual type: a :=: a In the expression: Refl In an equation for `inj1': inj1 Refl = Refl Cheers, Daniel

1 0

ICFP 2012: Call for workshops and co-located events
by Wouter Swierstra 21 Oct '11

21 Oct '11

CALL FOR WORKSHOP AND CO-LOCATED EVENT PROPOSALS ICFP 2012 17th ACM SIGPLAN International Conference on Functional Programming September 9 - 15, 2012 Copenhagen, Denmark http://icfpconference.org/icfp2012/ The 17th ACM SIGPLAN International Conference on Functional Programming will be held in Copenhagen, Denmark on September 9-15, 2012. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for workshops (and other co-located events, such as tutorials) to be affiliated with ICFP 2012 and sponsored by SIGPLAN. These events should be more informal and focused than ICFP itself, include sessions that enable interaction among the attendees, and foster the exchange of new ideas. The preference is for one-day events, but other schedules can also be considered. The workshops are scheduled to occur on September 9 (the day before ICFP) and September 13-15 (the three days after ICFP). ---------------------------------------------------------------------- Submission details Deadline for submission: November 19, 2011 Notification of acceptance: December 17, 2011 Prospective organizers of workshops or other co-located events are invited to submit a completed workshop proposal form in plain text format to the ICFP 2012 workshop co-chairs (Patrik Jansson and Gabriele Keller), via email to icfp12-workshops at cse.unsw.edu.au by November 19, 2011. (For proposals of co-located events other than workshops, please fill in the workshop proposal form and just leave blank any sections that do not apply.) Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by December 17, 2011, and if successful, depending on the event, they will be asked to produce a final report after the event has taken place that is suitable for publication in SIGPLAN Notices. The proposal form is available at: http://www.icfpconference.org/icfp2012/icfp12-workshops-form.txt Further information about SIGPLAN sponsorship is available at: http://acm.org/sigplan/sigplan_workshop_proposal.htm ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2012 organizing committee, together with the members of the SIGPLAN executive committee. Workshop Co-Chair: Gabriele Keller (University of New South Wales) Workshop Co-Chair: Patrik Jansson (Chalmers University of Technology) General Chair : Peter Thiemann (University of Freiburg) Program Chair: Robby Findler (Northwestern University) ---------------------------------------------------------------------- Further information Any queries should be addressed to the workshop co-chairs (Patrik Jansson and Gabriele Keller), via email to icfp12-workshops at cse.unsw.edu.au

1 0

Re: [Haskell-cafe] How to implement a digital filter, using Arrows?
by Captain Freako 21 Oct '11

21 Oct '11

John Lask wrote: >This is literate code. It expounds on your initial question and provides >two solutions based either on the StateArrow or Automaton.... >(Remainder omitted.) John, Thanks so much for your help! I'm going to study your example code and try to understand how the Automaton implicit plumbing is being used. (I'm determined to get my head around this arrow concept, damn it! ;-) ) I wonder if I might pester you for the final piece of the puzzle here: When the processing of the input stream through the filter is complete, I need to pass the final filter state, along with the output stream, back to the calling program. (This is because the calling program is going to split the input signal into conveniently sized chunks, calling my filter routine several times, in order to process the entire input stream. It expects to be able to pass an initial filter state into my routine, which is just the final state of the filter that I passed back to it after the previous call. In this way, we avoid inserting any edge artifacts at the input stream segmentation boundaries.) So, is it possible to `fetch' the final state out of that Automaton, when it's finished processing the input list? Thanks! -db

3 7

Implementing a New primop
by Paul Monday 21 Oct '11

21 Oct '11

Alright, I wandered through some primtype issues, but I'm having another odd problem as I try to define my own primop. I've followed what the various wiki pages have to offer (primarily http://hackage.haskell.org/trac/ghc/wiki/AddingNewPrimitiveOperations and http://hackage.haskell.org/trac/ghc/wiki/Commentary/PrimOps) without success. I even unraveled my PrimOp to be, basically, an exact copy of another PrimOp without luck. The primop I'm attempting to add is now very, very simple and copies FloatAddOp exactly so there must be an additional file I have to modify before the primop is "completely" added. ./compiler/prelude/primops.txt.pp primop FloatVAddOp "plusFloatVec#" Dyadic Float# -> Float# -> Float# with commutable = True ./compiler/codeGen/CgPrimOp.hs translateOp FloatVAddOp = Just (MO_F_Add W32) The compiler error is below. I have the feeling that an interface is not being built somewhere … this must be a simple one but I can't find any references to this error anywhere … has anyone seen this one before????? "inplace/bin/ghc-stage1" -H64m -O0 -fasm -package-name ghc-7.3.20111007 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/../libffi/build/include -Icompiler/stage2 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.11.2 -package array-0.3.0.3 -package base-4.4.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.9.2.0 -package containers-0.4.2.0 -package directory-1.1.0.1 -package filepath-1.2.0.1 -package hoopl-3.8.7.2 -package hpc-0.5.1.0 -package old-time-1.0.0.7 -package process-1.1.0.0 -package template-haskell-2.6.0.0 -package unix-2.5.0.0 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XHaskell98 -XNondecreasingIndentation -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O0 -fasm -no-user-package-conf -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -hisuf hi -osuf o -hcsuf hc -c compiler/iface/BinIface.hs -o compiler/stage2/build/BinIface.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.3.20111007 for x86_64-unknown-linux): applyTypeToArgs ghc-prim:GHC.Prim.sizeofMutableArray#{(w) v 91V} [gid[PrimOp]] @ e{tv i4L2} [tv] ds{v i4Lc} [lid] i#{v i4Lg} [lid] forall a{tv 12} [tv]. ghc-prim:GHC.Prim.MutableArray#{(w) tc 31m} e{tv i4L2} [tv] a{tv 12} [tv] -> ghc-prim:GHC.Prim.Int#{(w) tc 3G} Paul Monday Parallel Scientific, LLC. paul.monday(a)parsci.com

4 5