[Haskell-cafe] Call to Action - Fay FFI Bindings for AngularJS

I've talked to a lot of people that would like to be able to use Fay with AngularJS, this seems like a great idea! I don't use AngularJS personally, but I would be happy to help out with designing it and making code reviews. Has anyone started working on this already, and do you have any code/thou

Re: [Haskell-cafe] building a FFI library with cabal

With a big help from the community, I've fixed my problem. I had to include the extra-libraries when building the hcholmod library. I'll push a new version later today. Tad On Fri, Oct 4, 2013 at 12:36 PM, Tad Doxsee wrote: > Hi, > > I'm trying to create an FFI lib

[Haskell-cafe] building a FFI library with cabal

Hi, I'm trying to create an FFI library to CHOLMOD ( http://www.cise.ufl.edu/research/sparse/cholmod/) but am having problems. My project is here: github.com/tdox/hcholmod. I can link an executable with the build script in the examples directory (line 4). But line 7 does not work (

Re: [Haskell-cafe] FFI: how to handle external dll crashes

On Mon, 23 Sep 2013 15:32:35 +0200 Miro Karpis wrote: > Thanks for that. I checked forkProcess - which is packed in POSIX > module. I'm building under windows. Do I need to go via cygwin, is > there some other way for creating new OS process? Windows doesn't support fork(), you'll need to either

Re: [Haskell-cafe] FFI: how to handle external dll crashes

Thanks for that. I checked forkProcess - which is packed in POSIX module. I'm building under windows. Do I need to go via cygwin, is there some other way for creating new OS process? m. On Mon, Sep 23, 2013 at 1:46 PM, Niklas Hambüchen wrote: > Hey, > > I don't think any of your code actually

Re: [Haskell-cafe] FFI: how to handle external dll crashes

Hey, I don't think any of your code actually forks of an *OS process*. There three main kinds of threading constructs: * Haskell threads (forkIO) * Operating System threads (forkOS) * Operating System processes (forkProcess, fork() in C) Async uses the first one, you will need last one (which i

Re: [Haskell-cafe] FFI: how to handle external dll crashes

Hi Niklas, I think that I'm doing this in my try2 function with tryAny and catchAny functions. Unfortunately that didn't work. I'm just starting with Haskell so maybe also my implementation of my haskell code is not 100% correct. cheers, m. On Mon, Sep 23, 2013 at 1:36 PM, Niklas Hambüchen wrot

Re: [Haskell-cafe] FFI: how to handle external dll crashes

If you cannot do it with Haskell exceptions, I guess you need to look how you would do it in plain C in do the same. Keep in mind that if something crashes in a C library, that library might have corrupted (or leaked) any memory it had access to. I guess a somewhat reliable way is to fork an OS

[Haskell-cafe] FFI: how to handle external dll crashes

Please, can you help me with following: I have an external dll that I'm importing in my haskell program. In some particular cases the dll crashes. Simplified: first I need to send to dll with MethodA some parameters and then call MethodB to do some calculations on those parameters. If I didn't giv

Re: [Haskell-cafe] [ANNOUNCE] fficxx : haskell-C++ FFI binding generator

speaking as the principle mentor on the relevant GSOC project (Ian is also co monetoring, so he can correct me if i'm wrong anywhere) The QT binding project is a *subproject* of the *gsoc project* whose principal focus for the summer is making a swig + fficxx based C++ ffi wrapper for ha

Re: [Haskell-cafe] [ANNOUNCE] fficxx : haskell-C++ FFI binding generator

; > fficxx is a haskell Foreign Function Interface (FFI) generator to C++. > This tool automatically generates > haskell FFI package for a given C++ class structure. It has been used > for generating my haskell binding to the ROOT library [1] called HROOT > [2]. Now I made it as a sepa

[Haskell-cafe] [ANNOUNCE] fficxx : haskell-C++ FFI binding generator

Dear Haskellers, Hello. I am very happy to announce the first version of fficxx (http://ianwookim.org/fficxx, also, please look at http://github.com/wavewave/fficxx ) fficxx is a haskell Foreign Function Interface (FFI) generator to C++. This tool automatically generates haskell FFI package for

Re: [Haskell-cafe] How to write a pure String to String function in Haskell FFI to C++

On Sun, Jun 2, 2013 at 10:19 PM, Ting Lei wrote: > Thanks for your answers so far. > > It seems that the laziness of String or [char] is the problem. > > My question boils then down to this. There are plenty of Haskell FFI > examples where simple things like sin/cos in ca

Re: [Haskell-cafe] How to write a pure String to String function in Haskell FFI to C++

would be very very very subtle to do correctly, and also just be really really complicated and hard. Likewise, for writing a "pure" looking ffi function, a good example is in the lz4hs lib, where all the allocation occurs on the haskell side, and the ffi is only mutating freshly alloca

Re: [Haskell-cafe] How to write a pure String to String function in Haskell FFI to C++

l>. On another note, if you really care about performance, you should use the `bytestring` and `text` packages instead of String. They are implemented in terms of byte arrays, instead of linked lists, hence are both faster and more FFI-friendly. > > > > On Sun, Jun 2, 2013 at 8:08 P

Re: [Haskell-cafe] How to write a pure String to String function in Haskell FFI to C++

Thanks for your answers so far. It seems that the laziness of String or [char] is the problem. My question boils then down to this. There are plenty of Haskell FFI examples where simple things like sin/cos in can be imported into Haskell as pure functions. Is there a way to extend that to

Re: [Haskell-cafe] How to write a pure String to String function in Haskell FFI to C++

> I'm not convinced that that's "obvious" – though it certainly requires > functions (that go through the FFI) to grab each character at a time. > I think you underestimate the complexity of the Haskell runtime and the interactions between it and the FFI. Admittedly

Re: [Haskell-cafe] How to write a pure String to String function in Haskell FFI to C++

sary. > All examples involing > > Anything that comes into or goes out of a Haskell program is in IO, period. > If you have an FFI function which is guaranteed to not change anything but > its parameters and those only in a pure way, then you can use > unsafeLocalState to "hide&q

Re: [Haskell-cafe] How to write a pure String to String function in Haskell FFI to C++

or goes out of a Haskell program is in IO, period. If you have an FFI function which is guaranteed to not change anything but its parameters and those only in a pure way, then you can use unsafeLocalState to "hide" the IO; but claiming that when it's not true can lead to problems ran

[Haskell-cafe] How to write a pure String to String function in Haskell FFI to C++

Hi, I want to implement a function in C++ via Haskell FFI, which should have the (final) type of String -> String. Say, is it possible to re-implement the following function in C++ with the exact same signature? import Data.Char toUppers:: String -> String toUppers s = map toUpper sente

Re: [Haskell-cafe] FFI - Approaches to C/C++

I followed dmwit's guide on threaded gtk2hs, all GUI interaction is in the main thread, which is always bounded. This shouldn't really impact the lag, as soon as gtk2hs calls back to haskell, nothing stops the RTS from delaying main thread's peaceful return to C-land for arbitrary amount of time.

Re: [Haskell-cafe] FFI - Approaches to C/C++

I used gtk2hs, because I couldn't find a free software design tool that was at least as good as glade3. Last time I tried to compile wxHaskell, wxc produced an enormous dynamic library which also linked to every wxWidgets library out there(e.g. wxwebkit), so that the resulting mess couldn't be reas

Re: [Haskell-cafe] FFI - Approaches to C/C++

kudah wrote: > I'd object to your implication that Haskell is completely ready for > use in general soft real-time systems. I was unable to implement a > multi-threaded application which does a some IO-work in background > threads in a way so that its GUI won't die. Worker threads simply > starve

Re: [Haskell-cafe] FFI - Approaches to C/C++

On Tue, Feb 5, 2013 at 1:56 PM, kudah wrote: > I'd object to your implication that Haskell is completely ready for > use in general soft real-time systems. I was unable to implement a > multi-threaded application which does a some IO-work in background > threads in a way so that its GUI won't die

Re: [Haskell-cafe] FFI - Approaches to C/C++

I'd object to your implication that Haskell is completely ready for use in general soft real-time systems. I was unable to implement a multi-threaded application which does a some IO-work in background threads in a way so that its GUI won't die. Worker threads simply starve the GUI, because Haskell

Re: [Haskell-cafe] FFI - Approaches to C/C++

On Thu, Jan 31, 2013 at 11:11 AM, Casey Basichis wrote: > Hi, > > I'm working on a project in Haskell and C++ where the former is the brains > and the latter is for UI, interaction etc. > > I've read this > http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ and > a number of oth

Re: [Haskell-cafe] FFI - Approaches to C/C++

has little performance implications between Haskell and C++, consider not using the FFI directly, but a higher-level abstraction such as protocol buffers for this part of your API. Alexander On Thu, Jan 31, 2013 at 9:53 AM, Casey Basichis wrote: > Hi Ertugrul, > > Thank you for the de

Re: [Haskell-cafe] FFI - Approaches to C/C++

Hi Ertugrul, Thank you for the detailed reply. From what you wrote, partial FFI still seems like the way to go. Unfortunately Ogre isn't the only large library I'm using, so "difficult" several times over sounds like a good way to handicap the project early on. I'

Re: [Haskell-cafe] FFI - Approaches to C/C++

Quoth Casey Basichis , ... > I am using several other C++ libraries for which there are no existing > bindings and no Haskell alternative packages that are even remotely > close. > > Are you suggesting it would be better to write all my own FFI bindings > for all th

Re: [Haskell-cafe] FFI - Approaches to C/C++

much you value being able to write code in Haskell (or > how allergic to C++ you are)." > > I'm on iOS so I imagine those difficulties are compounded. > > I am using several other C++ libraries for which there are no existing > bindings and no Haskell alternative packages

Re: [Haskell-cafe] FFI - Approaches to C/C++

ou are)." I'm on iOS so I imagine those difficulties are compounded. I am using several other C++ libraries for which there are no existing bindings and no Haskell alternative packages that are even remotely close. Are you suggesting it would be better to write all my own FFI bindings for all

Re: [Haskell-cafe] FFI - Approaches to C/C++

Casey Basichis wrote: > I'm working on a project in Haskell and C++ where the former is the > brains and the latter is for UI, interaction etc. That's a rather odd choice. Not exactly answering your question, but questioning your project decisions, why would you do UI and interaction in C++? Y

[Haskell-cafe] FFI - Approaches to C/C++

Hi, I'm working on a project in Haskell and C++ where the former is the brains and the latter is for UI, interaction etc. I've read this http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ and a number of other haskell posts suggesting the OOP is not the way to go. Without tryi

Re: [Haskell-cafe] Feedback on FFI bindings for C++ library

The simplest way generally is to make make a C binding and then bind Haskell from there. You may indeed want to take a look at wxWidgets' binding or SFML's (https://github.com/jeannekamikaze/SFML). On Fri, Jan 18, 2013 at 1:05 AM, kudah wrote: > I'd suggest to first look at how other C++-bindin

Re: [Haskell-cafe] Feedback on FFI bindings for C++ library

I'd suggest to first look at how other C++-bindings for haskell are implemented. e.g. wxHaskell is the most mature Haskell C++ binding out there. hogre tries to generate bindings from headers. And a number of (rather minimal) bindings to some libs were made as part of Nikki and the Robots. On Thu,

Re: [Haskell-cafe] Feedback on FFI bindings for C++ library

I'd suggest to first look at how other C++-bindings for haskell are implemented. e.g. wxHaskell is the most mature Haskell C++ binding out there. hogre tries to generate bindings from headers. And a number of (rather minimal) bindings to some libs were made as part of Nikki and the Robots. On Thu,

[Haskell-cafe] Feedback on FFI bindings for C++ library

Hey, I would like to write FII bindings in haskell for cocos2d-x (http://www.cocos2d-x.org/), which is a C++ library. Since I have little experience with this, I would like some feedback before I discover that concept is bad half way. In cocos2d there is a base class with much functionality: CCN

Re: [Haskell-cafe] GHCi + FFI + global C variables

On Tue, Dec 11, 2012 at 5:57 AM, Francisco Vieira de Souza < vieira.u...@gmail.com> wrote: > Hi Simon! Is it not necessary to show the type of igraph_bool_t > igraphhaskell_initialized like > > "int igraph_bool_t igraphhaskell_initialized = 0"? > "igraph_bool_t" uses the _t suffix convention for

Re: [Haskell-cafe] GHCi + FFI + global C variables

On Tue, Dec 11, 2012 at 12:57 PM, Francisco Vieira de Souza wrote: > Hi Simon! Is it not necessary to show the type of igraph_bool_t > igraphhaskell_initialized like > > "int igraph_bool_t igraphhaskell_initialized = 0"? "igraphhaskell_initialized" is the name of the variable, "igraph_boot_t" is

Re: [Haskell-cafe] GHCi + FFI + global C variables

Hi Simon! Is it not necessary to show the type of igraph_bool_t igraphhaskell_initialized like "int igraph_bool_t igraphhaskell_initialized = 0"? Success! Vieira 2012/12/11 Simon Marlow : > On 10/12/12 00:11, Nils wrote: >> >> I'm currently working with a C library that needs to use/modify globa

Re: [Haskell-cafe] GHCi + FFI + global C variables

On 10/12/12 00:11, Nils wrote: I'm currently working with a C library that needs to use/modify global C variables, for example: igraph_bool_t igraphhaskell_initialized = 0; int igraphhaskell_initialize() { if (igraphhaskell_initialized != 0) { printf("C: Not init

[Haskell-cafe] GHCi + FFI + global C variables

I'm currently working with a C library that needs to use/modify global C variables, for example: igraph_bool_t igraphhaskell_initialized = 0; int igraphhaskell_initialize() { if (igraphhaskell_initialized != 0) { printf("C: Not initializing. igraphhaskell_initialized =

Re: [Haskell-cafe] Problem with benchmarking FFI calls with Criterion

t;> On Nov 27, 2012 7:23 AM, "Janek S." wrote: > >> > I tested the same code on my second machine - Debian Squeeze (kernel > >> > 2.6.32) with GHC 7.4.1 - and > >> > the results are extremely surprising. At first I was unable to > >> > reprod

Re: [Haskell-cafe] Problem with benchmarking FFI calls with Criterion

t; > 2.6.32) with GHC 7.4.1 - and >> > the results are extremely surprising. At first I was unable to reproduce >> > the problem and got >> > consistent runtimes of about 107us: >> > >> > benchmarking FFI/C binding >> > mean: 107.3837 us, l

Re: [Haskell-cafe] Problem with benchmarking FFI calls with Criterion

I tested the same code on my second machine - Debian Squeeze (kernel > > 2.6.32) with GHC 7.4.1 - and > > the results are extremely surprising. At first I was unable to reproduce > > the problem and got > > consistent runtimes of about 107us: > > > > benchmarking

Re: [Haskell-cafe] Problem with benchmarking FFI calls with Criterion

hine - Debian Squeeze (kernel > 2.6.32) with GHC 7.4.1 - and > the results are extremely surprising. At first I was unable to reproduce > the problem and got > consistent runtimes of about 107us: > > benchmarking FFI/C binding > mean: 107.3837 us, lb 107.2013 us, ub 107.5862 us, c

Re: [Haskell-cafe] Problem with benchmarking FFI calls with Criterion

I tested the same code on my second machine - Debian Squeeze (kernel 2.6.32) with GHC 7.4.1 - and the results are extremely surprising. At first I was unable to reproduce the problem and got consistent runtimes of about 107us: benchmarking FFI/C binding mean: 107.3837 us, lb 107.2013 us, ub

Re: [Haskell-cafe] Problem with benchmarking FFI calls with Criterion

gnal) > > > > > > > > I see no difference - one benchmark runs fast, remaining ones run > > > > slow. > > > > > > > > Janek > > > > > > > > > Excerpts from Janek S.'s message of Fri Nov 23 10:44:15 -0500 2012: &

Re: [Haskell-cafe] Problem with benchmarking FFI calls with Criterion

to have type Vector Double -> IO > > > (Vector Double) and modified benchmarks like this: > > > > > > bench "C binding" $ whnfIO (copy signal) > > > > > > I see no difference - one benchmark runs fast, remaining ones run sl

Re: [Haskell-cafe] Problem with benchmarking FFI calls with Criterion

d modified benchmarks like this: > > > > bench "C binding" $ whnfIO (copy signal) > > > > I see no difference - one benchmark runs fast, remaining ones run slow. > > > > Janek > > > > > Excerpts from Janek S.'s message of Fri Nov 23 10:

Re: [Haskell-cafe] Problem with benchmarking FFI calls with Criterion

> Janek > > > > > Excerpts from Janek S.'s message of Fri Nov 23 10:44:15 -0500 2012: > > > 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. > > > > > > T

Re: [Haskell-cafe] Problem with benchmarking FFI calls with Criterion

fast, remaining ones run slow. Janek > > Excerpts from Janek S.'s message of Fri Nov 23 10:44:15 -0500 2012: > > 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 firs

Re: [Haskell-cafe] Problem with benchmarking FFI calls with Criterion

Hello Janek, What happens if you do the benchmark without unsafePerformIO involved? Edward Excerpts from Janek S.'s message of Fri Nov 23 10:44:15 -0500 2012: > I am using Criterion library to benchmark C code called via FFI bindings and > I've ran into a > problem th

[Haskell-cafe] Problem with benchmarking FFI calls with Criterion

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:

Re: [Haskell-cafe] vector, alignment and SIMD through FFI

On Fri, 2012-07-06 at 13:43 -0700, Thomas DuBuisson wrote: > On Fri, Jul 6, 2012 at 1:06 PM, Nicolas Trangez wrote: > > -- This fails: > > -- Ambiguous type variable `a0' in the constraint: > > -- (Storable a0) arising from a use of `sizeOf' > > Here you can either tie a type knot u

Re: [Haskell-cafe] vector, alignment and SIMD through FFI

On Fri, Jul 6, 2012 at 1:43 PM, Thomas DuBuisson wrote: > The block of memory is sufficiently aligned for any of the basic > foreign types that fits into a memory block of the allocated size. > That's not the same thing as a guarantee of 16-byte alignment, note, as none of the standard foreign t

Re: [Haskell-cafe] vector, alignment and SIMD through FFI

On Fri, Jul 6, 2012 at 1:06 PM, Nicolas Trangez wrote: > -- This fails: > -- Ambiguous type variable `a0' in the constraint: > -- (Storable a0) arising from a use of `sizeOf' Here you can either tie a type knot using proxy types or you can use the scoped type variable language exten

[Haskell-cafe] vector, alignment and SIMD through FFI

Hello Cafe, Recently I've been playing with the implementation of an algorithm, for which we already have highly-optimized implementations available (in plain C/C++ as well as OCaml with calls to C through FFI). The algorithm works on buffers/arrays/vectors/whatever you want to call it,

Re: [Haskell-cafe] Regarding Haskell FFI

Thank you very much for the quick reply. Regards, Rajendra On Wed, Mar 28, 2012 at 2:35 PM, Simon Marlow wrote: > I think the fix eventually made its way into 7.4.1. This is the patch: > > http://hackage.haskell.org/**trac/ghc/changeset/** > d146fdbbf8941a8344f0ec300e79db**eabc08d1ea

Re: [Haskell-cafe] Regarding Haskell FFI

I think the fix eventually made its way into 7.4.1. This is the patch: http://hackage.haskell.org/trac/ghc/changeset/d146fdbbf8941a8344f0ec300e79dbeabc08d1ea Cheers, Simon On 28/03/2012 09:57, rajendra prasad wrote: Hi, I am using GHC version 7.0.4. Thanks, Rajendra On Wed, Mar

Re: [Haskell-cafe] Regarding Haskell FFI

Hi, I am using GHC version 7.0.4. Thanks, Rajendra On Wed, Mar 28, 2012 at 2:09 PM, Simon Marlow wrote: > On 27/03/2012 08:56, rajendra prasad wrote: > >> Hi, >> >> I am trying to load the DLL(Wrapper.dll) in my code(Main.hs). When I am >> placing the dll in local directory, I am able to lo

Re: [Haskell-cafe] Regarding Haskell FFI

On 27/03/2012 08:56, rajendra prasad wrote: Hi, I am trying to load the DLL(Wrapper.dll) in my code(Main.hs). When I am placing the dll in local directory, I am able to load it through following command: ghci Main.hs -L. -lWrapper But, I am not able to load it if I am putting it in some other

[Haskell-cafe] Regarding Haskell FFI

Hi, I am trying to load the DLL(Wrapper.dll) in my code(Main.hs). When I am placing the dll in local directory, I am able to load it through following command: ghci Main.hs -L. -lWrapper But, I am not able to load it if I am putting it in some other directory(../../bin). I used the following co

Re: [Haskell-cafe] Regarding Haskell FFI for C/C++ (Passing of String)

tml >> ) >> Hope that helps. >> >> Le 22 mars 2012 15:10, rajendra prasad a >> écrit : >> >>> Hi, >>> >>> I have just started learning Haskell FFI. I am trying to send a string >>> from hastell to a C function. For this, I

Re: [Haskell-cafe] Regarding Haskell FFI for C/C++ (Passing of String)

.1045720.n5.nabble.com/Quickest-way-to-pass-Text-to-C-code-td5582223.html > ) > Hope that helps. > > Le 22 mars 2012 15:10, rajendra prasad a > écrit : > >> Hi, >> >> I have just started learning Haskell FFI. I am trying to send a string >> from hastell to

Re: [Haskell-cafe] Regarding Haskell FFI for C/C++ (Passing of String)

This joins the question I asked two days ago here. (See http://haskell.1045720.n5.nabble.com/Quickest-way-to-pass-Text-to-C-code-td5582223.html ) Hope that helps. Le 22 mars 2012 15:10, rajendra prasad a écrit : > Hi, > > I have just started learning Haskell FFI. I am trying to send

[Haskell-cafe] Regarding Haskell FFI for C/C++ (Passing of String)

Hi, I have just started learning Haskell FFI. I am trying to send a string from hastell to a C function. For this, I am required to convert the haskell string to byte string. I have two methods to achieve this task. Both are listed below: 1) import Foreign.C.String let arg1 = map

Re: [Haskell-cafe] Unable to call function from DLL using FFI

7:43 PM > Subject: Re: [Haskell-cafe] Unable to call function from DLL using FFI > To: haskell-cafe@haskell.org > > > On 14/03/12 14:01, rajendra prasad wrote: > >> My c++ code(HelloWorld.cpp) looks like this: >> > > Try adding extern "C" { ... } to use

Re: [Haskell-cafe] Unable to call function from DLL using FFI

On 14/03/12 14:01, rajendra prasad wrote: My c++ code(HelloWorld.cpp) looks like this: Try adding extern "C" { ... } to use the C ABI instead of a C++ ABI (which usually features symbol name mangling to add type information, among other things). (This may not solve the entire problem, but is

[Haskell-cafe] Unable to call function from DLL using FFI

Hi, I am new to Haskell and I need to call a c function by loading dynamic link library in Haskell. I started with very simple code to create a dll in visual studio 2008 and then trying to load it in haskell. I am listing here the steps I follwed to achieve this: *Step 1: * My c++ code(HelloWorld

Re: [Haskell-cafe] FFI: Overhead of foreign unsafe imports

) > foreign import unsafe "h" h :: Thing -> Foo -> Stuff -> Bar -> IO () > > Are > doStuff = f x y >> g z w > and > doStuff = h x y z w > equivalent, or is there an overhead (e.g. due to IO monad, or due to the > way the FFI does the calls) w

Re: [Haskell-cafe] FFI: Overhead of foreign unsafe imports

> foreign import unsafe "h" h :: Thing -> Foo -> Stuff -> Bar -> IO () > > Are > doStuff = f x y >> g z w > and > doStuff = h x y z w > equivalent, or is there an overhead (e.g. due to IO monad, or due to the way > the FFI does the calls) when co

[Haskell-cafe] FFI: Overhead of foreign unsafe imports

e*: foreign import unsafe "f" f :: Thing -> Foo -> IO () foreign import unsafe "g" g :: Stuff -> Bar -> IO () foreign import unsafe "h" h :: Thing -> Foo -> Stuff -> Bar -> IO () Are doStuff = f x y >> g z w and doStuff = h x y z w equi

Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?

Hi Axel, When do you expect to publish an updated version of gtk2hs on hackage? On Thu, Nov 3, 2011 at 1:02 PM, Eugene Kirpichov wrote: > Hi, > The actual thanks for tracking this down go to Vincent Hanquez for finding > that we're doing a lot of gmp calls (and for making me aware of ltrace), an

Re: [Haskell-cafe] FFI / enums

On Mon, Nov 7, 2011 at 13:44, Johannes Waldmann < waldm...@imn.htwk-leipzig.de> wrote: > Does this work with "ghc -XForeignFunctionInterface" ? > http://en.wikibooks.org/wiki/Haskell/FFI#Enumerations > > I am getting a syntax error right after "#{". >

[Haskell-cafe] FFI / enums

Does this work with "ghc -XForeignFunctionInterface" ? http://en.wikibooks.org/wiki/Haskell/FFI#Enumerations I am getting a syntax error right after "#{". But then, the description is for "hsc2hs" (not ghc). And it mentions macros, while C meanwhile has "

Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?

Hi, The actual thanks for tracking this down go to Vincent Hanquez for finding that we're doing a lot of gmp calls (and for making me aware of ltrace), and to Felipe Lessa for finding that this is caused by poor code generated for cFloatConv :) Your changes look identical to those that I made in

Re: [Haskell-cafe] Fwd: Ridiculously slow FFI, or cairo binding?

Thanks! I'll definitely consider your library in the future, but for now, as we can see, there's no necessity in rewriting cFloatConv at all - {-# INLINE #-} suffices :) On Thu, Nov 3, 2011 at 3:30 AM, wren ng thornton wrote: > On 11/2/11 7:14 AM, Eugene Kirpichov wrote: > >> I rewrote cFloatCon

Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?

On 11/2/11 9:24 AM, Jean-Marie Gaillourdet wrote: Hi Eugene, did you try using the SPECIALIZE pragma? It is part of the Haskell 98 and Haskell 2010 specifications. The problem with SPECIALIZE is that you still have to give a parametric definition for the function, whereas the whole point of

Re: [Haskell-cafe] Fwd: Ridiculously slow FFI, or cairo binding?

On 11/2/11 7:14 AM, Eugene Kirpichov wrote: I rewrote cFloatConv like this: import GHC.Float class (RealFloat a, RealFloat b) => CFloatConv a b where cFloatConv :: a -> b cFloatConv = realToFrac instance CFloatConv Double Double where cFloatConv = id instance CFloatConv Double CDouble i

Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?

Heh. Guess what! A simple {-# INLINE cFloatConv #-} helped to the same extent! Axel, I think this change should be pretty easy to incorporate, and it probably makes sense to inline all other functions in Types.chs too. Would you like me to send the trivial darcs patch or the gtk2hs team will tak

Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?

On Wed, Nov 2, 2011 at 11:24 AM, Jean-Marie Gaillourdet wrote: > Hi Eugene, > > did you try using the SPECIALIZE pragma? It is part of the Haskell 98 and > Haskell 2010 specifications. I don't think it's going to make any difference, as the core already have an specialized poor version. See my

Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?

Hi, No, I didn't, as I read in the GHC docs that it is deprecated in favor of the RULES pragma (I wanted to replace specifically with floatToDouble and doubleToFloat). On Wed, Nov 2, 2011 at 5:24 PM, Jean-Marie Gaillourdet wrote: > Hi Eugene, > > did you try using the SPECIALIZE pragma? It is pa

Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?

Hi Eugene, did you try using the SPECIALIZE pragma? It is part of the Haskell 98 and Haskell 2010 specifications. On 02.11.2011, at 12:14, Eugene Kirpichov wrote: > Yay!!! > > I made a small change in Types.chs and got my original cairo-binding-based > program to be just as blazing fast. The

Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?

On Wednesday 02 November 2011, 10:19:08, Eugene Kirpichov wrote: > I forgot to specify my environment. > > Windows Server 2008 R2 x64, ghc 7.0.3. > > However, I observed the same speed differences on a 64-bit ubuntu with > ghc 6.12 - I profiled my application with cairo-trace, and > cairo-perf-tr

Re: [Haskell-cafe] Fwd: Ridiculously slow FFI, or cairo binding?

Thanks a lot for this. I've been developing a Graphic Adventure IDE in haskell that I'm about to release. It uses Cairo to draw game-state diagrams and this will sure solve my speed issues. 2011/11/2 Felipe Almeida Lessa : > On Wed, Nov 2, 2011 at 9:14 AM, Eugene Kirpichov wrote: >> Yay!!! >> I m

Re: [Haskell-cafe] Fwd: Ridiculously slow FFI, or cairo binding?

On Wed, Nov 2, 2011 at 9:14 AM, Eugene Kirpichov wrote: > Yay!!! > I made a small change in Types.chs and got my original cairo-binding-based > program to be just as blazing fast. The only problem I have with this is > that I used multiparameter type classes. Nice! Looking forward to it being in

Re: [Haskell-cafe] Fwd: Ridiculously slow FFI, or cairo binding?

Sorry for re-sending, my previous attempt got ignored by gtk2hs-devel mailing list as I wasn't subscribed. Now I am. On Wed, Nov 2, 2011 at 3:14 PM, Eugene Kirpichov wrote: > Yay!!! > > I made a small change in Types.chs and got my original cairo-binding-based > program to be just as blazing fast

Re: [Haskell-cafe] Fwd: Ridiculously slow FFI, or cairo binding?

Yay!!! I made a small change in Types.chs and got my original cairo-binding-based program to be just as blazing fast. The only problem I have with this is that I used multiparameter type classes. Dear gtk2hs team! Is it possible to incorporate my changes? I'm pretty sure people will be happy by a

[Haskell-cafe] Fwd: Ridiculously slow FFI, or cairo binding?

+gtk2hs-devel On Wed, Nov 2, 2011 at 8:15 AM, Eugene Kirpichov wrote: > Any idea how to debug why all the GMP calls? > I'm looking at even the auto-generated source for cairo bindings, but I > don't see anything at all that could lead to *thousands* of them. Found them.  Look at the Types module

Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?

On Wed, Nov 2, 2011 at 8:15 AM, Eugene Kirpichov wrote: > Any idea how to debug why all the GMP calls? > I'm looking at even the auto-generated source for cairo bindings, but I > don't see anything at all that could lead to *thousands* of them. Found them. Look at the Types module and you'll see

Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?

Any idea how to debug why all the GMP calls? I'm looking at even the auto-generated source for cairo bindings, but I don't see anything at all that could lead to *thousands* of them. On Wed, Nov 2, 2011 at 2:14 PM, Vincent Hanquez wrote: > On 11/02/2011 10:10 AM, Eugene Kirpichov wrote: > >> Oh.

Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?

On 11/02/2011 10:10 AM, Eugene Kirpichov wrote: Oh. This is pretty crazy, I wonder what they're doing with GMP so much... I modified the Haskell program to use cairo directly, even with safe calls, and it now takes the same time as the C program. yep, i ended up doing the exact same thing fo

Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?

t; >> On 11/02/2011 09:51 AM, Eugene Kirpichov wrote: >> >>> Hi Claude, >>> >>> I suspected that the issue could be about unsafe foreign imports - all >>> imports in the cairo bindings are "safe". >>> I compiled myself a version of cairo

Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?

1:58 PM, Vincent Hanquez wrote: > On 11/02/2011 09:51 AM, Eugene Kirpichov wrote: > >> Hi Claude, >> >> I suspected that the issue could be about unsafe foreign imports - all >> imports in the cairo bindings are "safe". >> I compiled myself a versi

Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?

ked as unsafe. Unfortunately that didn't help the case at all, even though the core changed FFI calls from "__pkg_ccall_GC" to "__pkg_ccall". The performance stayed the same; the overhead is elsewhere. doing a ltrace, i think the reason is pretty obvious, ther

Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?

lp the case at all, even though the core changed FFI calls from "__pkg_ccall_GC" to "__pkg_ccall". The performance stayed the same; the overhead is elsewhere. On Wed, Nov 2, 2011 at 1:31 PM, Claude Heiland-Allen wrote: > On 02/11/11 09:17, Eugene Kirpichov wrote: > >&

Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?

in a fraction of a second, the Haskell program takes about 7-8 seconds to run. They produce exactly the same output. What could be at fault here? Why are the cairo bindings working so slow? (I suppose there isn't too much cairo-specific stuff here, perhaps it's a general FFI question?)

Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?

isn't too much cairo-specific stuff here, perhaps it's a > general FFI question?) > > #include "cairo.h" > int main() { >cairo_surface_t *surface = > cairo_image_surface_create(CAIRO_FORMAT_ARGB32, 1024, 768); >cairo_t *cr = cairo_create(surface); >

[Haskell-cafe] Ridiculously slow FFI, or cairo binding?

takes about 7-8 seconds to run. They produce exactly the same output. What could be at fault here? Why are the cairo bindings working so slow? (I suppose there isn't too much cairo-specific stuff here, perhaps it's a general FFI question?) #include "cairo.h" int main() {

  1   2   3   4   5   6   7   8   >