Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
On 17 October 2011 22:47, Judah Jacobson judah.jacob...@gmail.com wrote: On Mon, Oct 17, 2011 at 2:56 AM, Luis Cabellos cabel...@ifca.unican.es wrote: 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. In my experience, the nicest way to work around this problem is to just generate the documentation manually and host it somewhere off of Hackage. http://community.haskell.org/admin/ is a decent place to host something like this; you end up with a URL http://projects.haskell.org/yourproject which you can link to from the .cabal file description. That is an acceptable solution. The documentation of hopencl is now hosted at http://projects.haskell.org/hopencl/ Thanks for the pointer. -- Martin Dybdal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
On Thu, Oct 13, 2011 at 12:34 PM, Martin Dybdal dyb...@dybber.dk wrote: On 3 October 2011 12:56, Luis Cabellos cabel...@ifca.unican.es 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
On 17 October 2011 11:56, Luis Cabellos cabel...@ifca.unican.es wrote: 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 Thanks. I have implemented the same thing in my library now. I would be happy if someone could test that it compiles, and the unit tests runs on a Windows installation. -- Martin Dybdal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
On Thu, Oct 13, 2011 at 9:13 PM, Martin Dybdal dyb...@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/MakingOpenCLSimplewithHaskell.pdf ) * 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
On 17 October 2011 11:56, Luis Cabellos cabel...@ifca.unican.es wrote: On Thu, Oct 13, 2011 at 9:13 PM, Martin Dybdal dyb...@dybber.dk wrote: 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. For now I have bundled the OpenCL header files with my package. That is not the right way either, as the header files can contain some platform specific information, for instance information about the calling conventions, which would be a way to handle the problem above (and the only way possible with c2hs, as far as I know). -- Martin Dybdal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
On Mon, Oct 17, 2011 at 2:56 AM, Luis Cabellos cabel...@ifca.unican.es wrote: 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. In my experience, the nicest way to work around this problem is to just generate the documentation manually and host it somewhere off of Hackage. http://community.haskell.org/admin/ is a decent place to host something like this; you end up with a URL http://projects.haskell.org/yourproject which you can link to from the .cabal file description. Best, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
On 3 October 2011 12:56, Luis Cabellos cabel...@ifca.unican.es 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. 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.) 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/MakingOpenCLSimplewithHaskell.pdf ) 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. -- Martin Dybdal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
On Thu, Oct 13, 2011 at 12:34 PM, Martin Dybdal dyb...@dybber.dk wrote: On 3 October 2011 12:56, Luis Cabellos cabel...@ifca.unican.es 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. 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.) 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/MakingOpenCLSimplewithHaskell.pdf ) 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. Windows uses stdcall instead of ccall. If you get that right, your bindings are likely to just work. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
On Tue, Oct 4, 2011 at 7:46 PM, Jason Dagit dag...@gmail.com wrote: On Tue, Oct 4, 2011 at 12:54 AM, Luis Cabellos cabel...@ifca.unican.es 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 :) Thanks for the hint. It appears to be a good source (great source, far better than OpenCL), It's worth to follow it. 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. I'll think about, i put it in the issue. 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. Thank again, :) 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
On Mon, Oct 3, 2011 at 6:04 PM, Jason Dagit dag...@gmail.com wrote: On Mon, Oct 3, 2011 at 3:56 AM, Luis Cabellos cabel...@ifca.unican.es 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.html 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
Luis Cabellos cabel...@ifca.unican.es writes: * 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 don't think inlining matters in this case. If you distribute a work incorporating GPL code, you must allow the recipient to redistribute it (including all sources) under the GPL. Clearly, GPL code is not suitable when you wish to redistribute it along with proprietary code, but it should be unproblematic for most open source projects. For *L*GPL code, the intention is that it can apply to a library, distributed as a separate unit, and allowing it to be *used* as such, also by proprietary applications. Inlining through static linking may affect this, as it incorporates actual code from the LGPL library in a program that is then distributed as a propietary, binary object. 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. If you are happy with BSD3, that license is the one which will make your code most generally useful. The intent behind the GPL family is to make the code useful to those who reciprocate the sentiment, and less useful to those who don't. In practice, it is rare that BSD3 licensed libraries are made proprietary, it is often to everybody's benefit that thinks are maintained in the open. The general sentiment in the Haskell community is a preference for BSD. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
On Tue, Oct 4, 2011 at 12:54 AM, Luis Cabellos cabel...@ifca.unican.es 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.html 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: OpenCL 1.0.1.3 package
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, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
On Mon, Oct 3, 2011 at 9:04 AM, Jason Dagit dag...@gmail.com wrote: 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 meant to say, It's NOT a great naming convention ... Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
On Mon, Oct 3, 2011 at 3:56 AM, Luis Cabellos cabel...@ifca.unican.es 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 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. * 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.html 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
