{"action":"created","issue":{"url":"https://api.github.com/repos/acowley/CLUtil/issues/4","repository_url":"https://api.github.com/repos/acowley/CLUtil","labels_url":"https://api.github.com/repos/acowley/CLUtil/issues/4/labels{/name}","comments_url":"https://api.github.com/repos/acowley/CLUtil/issues/4/comments","events_url":"https://api.github.com/repos/acowley/CLUtil/issues/4/events","html_url":"https://github.com/acowley/CLUtil/issues/4","id":273887882,"number":4,"title":"I'd like to help develop and maintain this library.","user":{"login":"biglambda","id":1103482,"avatar_url":"https://avatars0.githubusercontent.com/u/1103482?v=4","gravatar_id":"","url":"https://api.github.com/users/biglambda","html_url":"https://github.com/biglambda","followers_url":"https://api.github.com/users/biglambda/followers","following_url":"https://api.github.com/users/biglambda/following{/other_user}","gists_url":"https://api.github.com/users/biglambda/gists{/gist_id}","starred_url":"https://api.github.com/users/biglambda/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/biglambda/subscriptions","organizations_url":"https://api.github.com/users/biglambda/orgs","repos_url":"https://api.github.com/users/biglambda/repos","events_url":"https://api.github.com/users/biglambda/events{/privacy}","received_events_url":"https://api.github.com/users/biglambda/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2017-11-14T18:01:36Z","updated_at":"2017-11-15T01:32:34Z","closed_at":null,"author_association":"NONE","body":"I turns out to be really useful for my work. I'm in the process of replacing some of my own OpenCL helper code with this library. Can you give me some idea of what future development you are working on or considering?"},"comment":{"url":"https://api.github.com/repos/acowley/CLUtil/issues/comments/344457132","html_url":"https://github.com/acowley/CLUtil/issues/4#issuecomment-344457132","issue_url":"https://api.github.com/repos/acowley/CLUtil/issues/4","id":344457132,"user":{"login":"acowley","id":124545,"avatar_url":"https://avatars0.githubusercontent.com/u/124545?v=4","gravatar_id":"","url":"https://api.github.com/users/acowley","html_url":"https://github.com/acowley","followers_url":"https://api.github.com/users/acowley/followers","following_url":"https://api.github.com/users/acowley/following{/other_user}","gists_url":"https://api.github.com/users/acowley/gists{/gist_id}","starred_url":"https://api.github.com/users/acowley/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/acowley/subscriptions","organizations_url":"https://api.github.com/users/acowley/orgs","repos_url":"https://api.github.com/users/acowley/repos","events_url":"https://api.github.com/users/acowley/events{/privacy}","received_events_url":"https://api.github.com/users/acowley/received_events","type":"User","site_admin":false},"created_at":"2017-11-15T01:32:34Z","updated_at":"2017-11-15T01:32:34Z","author_association":"OWNER","body":"I'm really glad to hear you'd like to help! Something I started on with a feature branch is an attempt to alleviate a friction point I sometimes encounter when using OpenCL:\r\n\r\nIf you write a bunch of OpenCL kernel functions in some source file, you then have code that wants to use that kernel, and can address it by something like a `(sourceFile, kernelName)` tuple. But the mechanics of loading and compiling the program source end up inducing a kind of coupling over your code. For instance, in C/C++, you might pass a `cl_program` through all your code so each piece can create an appropriate kernel. And if you have a commonly useful kernel, you might then end up wanting a set of `cl_kernel` values to be part of your application's shared state.\r\n\r\nI thought it would be good to encapsulate that shared state, and free user code from worrying about who was responsible for creating a `cl_program`, etc. So I have [this module](https://github.com/acowley/CLUtil/blob/revolution/src/CLUtil/ProgramCache.hs) that is an attempt at such an API.\r\n\r\nI'm still not 100% sure this is a good idea when all is said and done, but I think I still like it, so I'd be interested in your thoughts on that bit of API surface.\r\n\r\nThis was also planned to dovetail into another effort that I have in pieces for providing a kind of reference counted memory pool for OpenGL and OpenCL objects. My thinking is this: I often explicitly carry around temporary images and buffers for ping-pong type kernels (where you read from one and write to the other, then swap and repeat), or sundry other reasons. I'd prefer to not make carrying those temporary objects around part of each program component's state. Instead, I'd like to pretend I can cheaply allocate images and buffers for temporary use.\r\n\r\nThinking along these lines, the kind of use I make of these temporary objects is repetitive: I may frequently want images of a particular resolution, for example. So the idea is to provide an object pool that hangs on to images and buffers and offers them for re-use when possible. We can explicitly call the GC when asked for a new object, and put some reference counting logic in a finalizer, and then offer up the object for re-use.\r\n\r\nI don't think the repository where I started work on that is on GitHub (the package is called `memoriam` in case there are references in the `CLUtil` code), but it's an area I think could work really nicely. I'd really like to offer a functional API to OpenCL-using libraries, so we need a way to return objects to client code, but re-use them if the client isn't hanging onto them.\r\n\r\nI don't think I made the leap of having `CLUtil` itself return such pool objects, and I'm not sure if that should live in yet another package. My preference is to have the memory pool package as a standalone thing, and then have `CLUtil` use that, but maybe that'd be putting too many layers into `CLUtil`. \r\n\r\nOn that note, that feature branch is also where I'm hoping to do some cleanup of parts of `CLUtil` that I haven't found useful. The duplication between the synchronous and asynchronous interfaces is awful, and I'd really like to resolve that but didn't figure out how when I was working on it."}}
{"actor":{"display_login":"acowley"}}