Quantcast

ANN: OpenCL 1.0.1.3 package

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ANN: OpenCL 1.0.1.3 package

Luis Cabellos-2
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


# 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ANN: OpenCL 1.0.1.3 package

Jason Dagit-3
On Mon, Oct 3, 2011 at 3:56 AM, Luis Cabellos <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ANN: OpenCL 1.0.1.3 package

Jason Dagit-3
On Mon, Oct 3, 2011 at 9:04 AM, Jason Dagit <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ANN: OpenCL 1.0.1.3 package

Luis Cabellos-2
In reply to this post by Jason Dagit-3
On Mon, Oct 3, 2011 at 6:04 PM, Jason Dagit <[hidden email]> wrote:
On Mon, Oct 3, 2011 at 3:56 AM, Luis Cabellos <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ANN: OpenCL 1.0.1.3 package

Ketil Malde-5
Luis Cabellos <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ANN: OpenCL 1.0.1.3 package

Jason Dagit-3
In reply to this post by Luis Cabellos-2
On Tue, Oct 4, 2011 at 12:54 AM, Luis Cabellos <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ANN: OpenCL 1.0.1.3 package

Luis Cabellos-2
On Tue, Oct 4, 2011 at 7:46 PM, Jason Dagit <[hidden email]> wrote:
On Tue, Oct 4, 2011 at 12:54 AM, Luis Cabellos <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ANN: OpenCL 1.0.1.3 package

Martin Dybdal
In reply to this post by Luis Cabellos-2
On 3 October 2011 12:56, Luis Cabellos <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ANN: OpenCL 1.0.1.3 package

Jason Dagit-3
On Thu, Oct 13, 2011 at 12:34 PM, Martin Dybdal <[hidden email]> wrote:

> On 3 October 2011 12:56, Luis Cabellos <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ANN: OpenCL 1.0.1.3 package

Luis Cabellos-2
In reply to this post by Luis Cabellos-2
On Thu, Oct 13, 2011 at 9:13 PM, Martin Dybdal <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ANN: OpenCL 1.0.1.3 package

Martin Dybdal
On 17 October 2011 11:56, Luis Cabellos <[hidden email]> wrote:

> On Thu, Oct 13, 2011 at 9:13 PM, Martin Dybdal <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ANN: OpenCL 1.0.1.3 package

Judah Jacobson
In reply to this post by Luis Cabellos-2
On Mon, Oct 17, 2011 at 2:56 AM, Luis Cabellos <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ANN: OpenCL 1.0.1.3 package

Martin Dybdal
In reply to this post by Luis Cabellos-2
On 17 October 2011 11:56, Luis Cabellos <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ANN: OpenCL 1.0.1.3 package

Martin Dybdal
In reply to this post by Judah Jacobson
On 17 October 2011 22:47, Judah Jacobson <[hidden email]> wrote:

> On Mon, Oct 17, 2011 at 2:56 AM, Luis Cabellos <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ANN: OpenCL 1.0.1.3 package

Jason Dagit-3
In reply to this post by Martin Dybdal
On Thu, Oct 13, 2011 at 12:34 PM, Martin Dybdal <[hidden email]> wrote:

> On 3 October 2011 12:56, Luis Cabellos <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Loading...