May 2015 - Haskell-Cafe

Library design around FFI library
by Marco Zocca 21 May '15

21 May '15

I'm implementing the low-level interface to a large C library (using c2hs). The C functions can be broadly classified by: *) the main datastructure they operate on, e.g. returnType AFunction (A* a, ...); *) creation, modification, read access, destruction operations for each of these datastructures, following a common pattern: ACreate(), ASet1(), ASet2(), .., ARead(), ADestroy(), BCreate(), etc. The library rests on top of MPI, so there are e.g. AScatterBegin(), AScatterEnd() function pairs that account for potentially large delays associated with computing and moving data around. On the Haskell side, the C pointer types are represented as e.g. data Ah = Ah (Ptr Ah) deriving instance Storable Ah and e.g. a Create function returns the representation of the fresh pointer along with the usual integer error code: ahCreate :: MPIComm -> IO (Ah, Err) What abstraction may I use to capture logic such as: *) separate read-only functions from the potentially overwriting ones *) guarantee precedence relations (e.g. computation can only occur after initialization) *) collect or even compose error codes, letting computation go through iff Err==0 (e.g. a n-ary Maybe ?) Sequencing in the IO monad causes all effectful functions to run and return their result and/or error code. All feedback is welcome; Thank you in advance

1 1

NoOO languages
by Harry . 20 May '15

20 May '15

Could we mimic the marketing success of NoSQL databases by branding functional languages as NoOO (or even NoIO)?

8 9

[ANN] codex 0.3
by Alois Cochard 20 May '15

20 May '15

Hello Café, I have released a new version of `codex`[1] (a ctags file generator for cabal project and their dependencies). It should be noted that *this version now fully support the windows operating system*, thanks to a great contribution from Ben James. This new version include: - Tagging of the current project can be turned-off - Fix/Enhance the `emacs` and `sublime` default format - Tags file name is now configurable - Replace `curl` with `wrep` - Misc fixes and portability enhancement Thanks to the contributors (Ben James, Tal Walter, Eyal Lotem). [1] https://github.com/aloiscochard/codex -- *Λ\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard

1 0

glfw demos ?
by briand＠aracnet.com 20 May '15

20 May '15

Hi, Looks like the demos, including the one on the wiki page, and the glfw-b-demo package, are suffering from bit-rot. I was hoping somebody could point me to a small get-started demo. Meanwhile I am working on trying to get the wiki demo running. Thanks, Brian

2 1

text-icu (and FFI in general) on Windows 64 bits
by Yitzchak Gale 20 May '15

20 May '15

I was finally successful in getting text-icu to work on Windows 64 bits. This is probably an indication of what to expect in general for packages requiring FFI on Windows 64 bits. In the past, on 32 bits, the standard Windows binary distribution from the ICU site could be used together with msys/mingw, even though it was officially only for MSVC. This no longer seems to be the case for 64 bits. When I build text-icu in that way with a 64 bit GHC and the Windows 64-bit binary ICU distribution for MSVC, the resulting EXEs segfault as soon as any function from text-icu is called. There is no official ICU download for mingw-w64 binaries. But happily, the MSYS2 project does provide a pre-built ICU binary distribution for mingw-w64. It tends to be quite up-to-date; the current version is ICU 55.1. Note, however, that I was *not* able to use the partial MSYS2 that comes with MinGHC, because pacman seems to be missing. So the solution is: 1. Download and install 64-bit MSYS2, following the instructions on the site: http://msys2.github.io 2. In the MSYS2 shell window, get the ICU package for mingw-w64: pacman -S mingw64/mingw-w64-x86_64-icu 3. Now you can build the Haskell text-icu library using this command: cabal install --extra-lib-dirs="c:\path\to\msys64\mingw64\lib" --extra-include-dirs="c:\path\to\msys64\mingw64\include" text-icu 4. Provide the following DLLs with your EXE that uses text-icu: libicudt55.dll libicuin55.dll libicuuc55.dll libgcc_s_seh-1.dll libstdc++-6.dll Get them from: c:\path\to\msys64\mingw64\bin This not only compiles, but EXEs produced using this library actually run without segfaulting. You can even compile native Windows EXEs from C using ICU this way, with the gcc that is put on your path by the Haskell Platform installer (and probably also MinGHC, but I didn't try that). Just include -L and -I options to gcc with the same paths as above, and make sure to specify -licuuc -licudt etc. as needed. -Yitz

1 1

Automated Differentiation of Matrices (again)
by Florian Hofmann 20 May '15

20 May '15

In [1](this) email thread Edward Kmett and Dominic Steinitz discuss the state of interoperability of `ad` and `hmatric` (or `repa`) with Edward hinting that the 4.0 line of `ad` might improve on the situation. Could someone elaborate on the state of affairs two years later? Florian [1]: https://mail.haskell.org/pipermail/haskell-cafe/2013-April/107561.html

2 2

Naming convention for version branches (Package versioning)
by Alois Cochard 20 May '15

20 May '15

Hi all, I am currently writing a tool to automate the release and version bump of cabal projects. Currently you can call the tool by giving as argument the rank of the branch you want to bump, for example given 0.0.0.0: - `cabal-release 0` bump to `1` - `cabal-release 1` bump to `0.1` - `cabal-release 2` bump to `0.0.1` - `cabal-release 3` bump to `0.0.0.1` As we are not all robots (yet), I thought that in addition to this it would be great if the user could give a human friendly name for the rank. For now, here is what I have for the different rank: 0 == --major 1 == --major-fix 2 == --minor 3 == --minor-fix I'm curious to know what you think of those names? any suggestions or known established convention about that? Thanks -- *Λ\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard

4 6

advanced cabal configuration
by Kazu Yamamoto 19 May '15

19 May '15

Hi, I'm a maintainer of simple-sendfile and need to implement the following is to rescue 32bit Linux: - If the COff size is 8, the following FFI is used: foreign import ccall unsafe "sendfile64" c_sendfile :: Fd -> Fd -> Ptr COff -> CSize -> IO (#type ssize_t) - Otherwise, the following FFI is used: foreign import ccall unsafe "sendfile" c_sendfile :: Fd -> Fd -> Ptr COff -> CSize -> IO (#type ssize_t) How can I implement this? I guess that Setup.hs should evaluate (sizeOf (1 :: COff)) and define a C macro, say LARGE_OFFSET and write the following code. #ifdef LARGE_OFFSET foreign import ccall unsafe "sendfile64" #else foreign import ccall unsafe "sendfile" #endif I have no experience to use Build-Type: other than Simple in cabal files. Would someone explain how to implement it concretely or suggest examples which implement similar things? For more informaion, please read: https://github.com/yesodweb/wai/issues/372 Thanks. --Kazu

5 7

Re: [Haskell-cafe] Request for maintainers
by Fred Ross 19 May '15

19 May '15

Thank you! I've added you to the maintainers list. You might want to go ahead and fork the repository at https://github.com/madhadron/serial, update serial.cabal with your info, and upload a new version. Fred Ross On May 18, 2015, at 11:05 AM, Jose Calderon <jmct(a)cs.york.ac.uk> wrote: > Hello, > > I'll happily take the serial library off your hands. > > My hackage username is jmct. > > Cheers, > > Jose > http://jmct.cc > > > > On 18 May 2015 at 02:34, Fred Ross <madhadron(a)gmail.com> wrote: > I have finally accepted that I won't be part of the Haskell community in any real sense in the foreseeable future. There are three libraries that I am still the maintainer of that I need to hand off. Is there anyone who would take over any of the following? > > hdaemonize - Utilities for writing Unix daemons in Haskell > serial - Serial port access library > hscamwire - FFI bindings to camwire to access IIDC1394 Firewire cameras > > Fred Ross > http://madhadron.com >

1 0

Request for maintainers
by Fred Ross 19 May '15

19 May '15

I have finally accepted that I won't be part of the Haskell community in any real sense in the foreseeable future. There are three libraries that I am still the maintainer of that I need to hand off. Is there anyone who would take over any of the following? hdaemonize - Utilities for writing Unix daemons in Haskell serial - Serial port access library hscamwire - FFI bindings to camwire to access IIDC1394 Firewire cameras Fred Ross http://madhadron.com

2 1