On Mon, Oct 3, 2011 at 6:04 PM, Jason Dagit wrote:

On Mon, Oct 3, 2011 at 3:56 AM, Luis Cabellos wrote:Your bindings are a higher quality than the the OpenCLRaw bindings and you're doing good technical work, but I stopped using your bindings for a couple reasons: * The main reason is that I'm not comfortable with the license you're using. The original code by Jeff Heard was BSD3 with an additional copyright notice. Your code is AGPL3. The GPL is known to cause problems with Haskell code due to cross module inlining. I don't know how the "A" in AGPL changes things.

I understand your point. I didn't know the problems with cross module inlining that Haskell suffers. I learned the BSD3, I think is a good and I'll change it on github and I'll put in the next release.

* Some of the exposed function names have been changed from the original name in the OpenCL specification. This is the same thing that was done with the OpenGL bindings and it is very confusing for people who come to the Haskell bindings from the official documentation. I realize that some of the API functions require some bit of name mangling, but I think the current way is not the right way. For example with this function:

http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/clGetDeviceInfo.ht...

I use the pattern get[Type]Info -> to get[Type][specificInfo] where specificInfo is the OpenCL name of an enumerate. I don't know if your proposal, I open a ticket on github to think about.

We could have a different version of the function for each return type, clGetDeviceInfo_FPConfig, clGetDeviceInfo_AddressBits, etc. It's a great naming convention but it has the property that someone searching the bindings or the bindings' haddocks for clGetDeviceInfo will find those functions. I think this is better than naming it clGetDeviceExtensions, which is not in the OpenCL specification.

I'd still be willing to test the changes you have, I just don't want to contribute to your bindings due to the license. I currently thinking of starting my own bindings (Jeff's bindings contain too many small bugs and if I'm going to change most lines of code then I might as well start from scratch so that it can have a standard BSD3 license).

Jason

I'll change the License to BSD3, Please, keep testing the code and merge back your changes. I thank for your help. Thanks for the feedback. Luis

On Tue, Oct 4, 2011 at 12:54 AM, Luis Cabellos wrote:

I understand your point. I didn't know the problems with cross module inlining that Haskell suffers. I learned the BSD3, I think is a good  and I'll change it on github and I'll put in the next release.

Oh cool. Thanks! I think that's for the best. Someone sent me a link to this offline: https://github.com/judah/HsOpenCL Maybe the two implementations can be merged into one super implementation :)

...

http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/clGetDeviceInfo.ht...

I use the pattern get[Type]Info -> to get[Type][specificInfo] where specificInfo is the OpenCL name of an enumerate. I don't know if your proposal, I open a ticket on github to think about.

I see. My experience with the OpenGL bindings is that it can still be confusing for users of the library. The reason is simple, there are good docs for using the API from C and those docs tend to match the official specification. So people who are new to the Haskell bindings will need some documentation that explains how to go from the C API to the Haskell API. Otherwise users will need to read the source code directly to figure out where the function they need to call is located. Good haddocks help, but that's just one part of the solution. Being able to search for the function by name is also useful, so that's why I proposed adding something on to the end of the function name. So that people using search in their browser on the haddocks or using grep at the command line would find the function(s) they are looking for and (hopefully) minimize time spent searching. It's a shame because, if we had dependent types we could encode the C API directly into Haskell. Thanks and I'll probably look at it some more this weekend. I have a test program I'm working on but I would need to port it to your bindings. Also, if you use the #fun macro from c2hs to create the foreign imports you will need to use at least version 0.16.4 as previous versions do not honor stdcall. Jason

On Thu, Oct 13, 2011 at 12:34 PM, Martin Dybdal wrote:

On 3 October 2011 12:56, Luis Cabellos wrote:

...

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,

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.

I think it's important to distinguish between being a new API and being a faithful binding to an established API. In reality it ends up as a continuum because an exact one to one mapping is not possible between idiomatic C and idiomatic Haskell. If someone is renaming things or changing the API when not strictly necessary then I would say person is making a new API based on the the old API. My desire is to have a binding which is faithful to the C API and then letting people build new abstractions on top of that.

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 have to disagree here, based largely on my experience with learning other Haskell bindings (for example OpenGL, which I knew from C). If I were to twist your words I could use this to say that we should make Haskell hard to learn. I doubt that's what you meant but it seems dangerously close to me. Probably we have very different goals. You want to make a nice OpenCL-based API for parallel programming and I want a binding that matches the OpenCL api very closely, but not to the point of using Ptr () in many places.

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:

I agree that having so many implementations of the binding is odd. I wonder if it's because they cater to different needs. In the case of OpenCLRaw we could reasonably remove it from the list because it's unmaintained and incomplete. And yes, it would be nice to merge efforts. Jason