[racket] OpenCL module macro errors

From: Tobias Hammer (tobias.hammer at dlr.de)
Date: Mon Aug 26 04:34:38 EDT 2013

I guess you should replace it in the function body too

diff --git a/opencl/c/syntax.rkt b/opencl/c/syntax.rkt
index 909b2c8..3848e1b 100644
--- a/opencl/c/syntax.rkt
+++ b/opencl/c/syntax.rkt
@@ -216,13 +216,13 @@
             (define (id:selector arg_id ... _param_type)
               (case (hash-ref id-selector-map _param_type #f)
                 [(_vtype)
-                (local [(define len (id:length _arg_type ...  
_param_type))]
+                (local [(define len (id:length arg_id ... _param_type))]
                    (if (zero? len)
                        _vtype-default
-                      (id:_vtype _arg_type ... _param_type len)))]
+                      (id:_vtype arg_id ... _param_type len)))]
                 ...
                 [(_ftype)
-                (id:_ftype _arg_type ... _param_type)]
+                (id:_ftype arg_id ... _param_type)]
                 ...
                 [else
                  (error 'id:selector "Invalid parameter: ~e"  
_param_type)]))


On Sun, 25 Aug 2013 04:02:54 +0200, Dane Larsen <dane at larsendt.com> wrote:

> Hmm. I think I almost have it, but there's one error I can't seem to  
> track down.
>
> Switching from _arg_type to arg_id seems to have almost worked, but now  
> I'm stuck. When I try to run my context sharing test program  
> (https://github.com/larsendt/cl-gl-context-sharing/) I get the following:
>
> vector-length: contract violation
>    expected: vector?
>    given: #<ctype>
>    context...:
>   
> /home/dane/chematox/local/racket-5.90.0.6/collects/ffi/unsafe.rkt:27:27:  
> vector->cblock
>     /home/dane/git/opencl/opencl/c/syntax.rkt:160:13
>     /home/dane/git/opencl/opencl/c/syntax.rkt:216:11:  
> clGetGLContextInfoKHR:generic
>     /home/dane/git/opencl/opencl/sinemesh/sinemesh-gl.rkt:30:6
>     /home/dane/git/opencl/opencl/sinemesh/sinemesh-gl.rkt:18:2
>   
> /home/dane/chematox/local/racket-5.90.0.6/collects/racket/private/class-internal.rkt:4070:0:  
> continue-make-object
>   
> /home/dane/chematox/local/racket-5.90.0.6/collects/racket/private/class-internal.rkt:4051:0:  
> do-make-object
>     /home/dane/git/opencl/opencl/sinemesh/sinemesh-gl.rkt: [running body]
>
> It looks like the error is happening in the definition of _vector, which  
> calls vector->cblock. I assumed that would be in the conversion of the  
> input 'properties' vector  
> (https://github.com/larsendt/cl-gl-context-sharing/blob/master/sinemesh-gl.rkt#L46),  
> but that's definitely a vector, not a ctype. There aren't any other  
> inputs being passed to _vector, so I honestly have no idea what's  
> causing it.
>
> I put up my fork of the opencl module with the changes at  
> https://github.com/larsendt/opencl/. The definition of  
> clGetGLContextInfoKHR lives at  
> https://github.com/larsendt/opencl/blob/master/opencl/c/9-7.rkt#L19.
>
> Thanks for the help so far. I'm still getting my bearings in  
> macro-world, and it's definitely showing today.
>
> Dane
>
>
> On 08/23/2013 09:29 AM, Jay McCarthy wrote:
>> Hi Dane,
>>
>> Thanks for working on this.
>>
>> If you look at line 106 of the definition of define-opencl-info, it
>> uses the _arg_type as the name of the selector's arguments. I think
>> you could safely replace that with arg_id, if not, then you would want
>> to create new ids with generate-temporaries, but try arg_id first.
>>
>> Since this looks like a simple change, try it on your end and we can
>> just include it in the pull request/patch you send me.
>>
>> Jay
>>
>>
>> On Thu, Aug 22, 2013 at 7:54 PM, Dane Larsen <dane at larsendt.com> wrote:
>>> Hi all,
>>>
>>> I'm a little new to Racket (and Lispy languages in general). I'm  
>>> working on
>>> extending the OpenCL module to add support for OpenGL context sharing.
>>>
>>> My questions are somewhat specific to the OpenCL module, but hopefully  
>>> I can
>>> provide enough context to minimize that.
>>>
>>> Right now I'm working on clGetGLContextInfoKHR in, and it's been a bit  
>>> more
>>> challenging than I anticipated. It's a CL extension function, so  
>>> get-ffi-obj
>>> fails to find it. This hasn't been a huge problem. I ended up creating  
>>> an
>>> alternate version of define-opencl (
>>> https://github.com/jeapostrophe/opencl/blob/master/opencl/c/lib.rkt#L17)
>>> which I've called define-opencl-extension. Rather than calling  
>>> get-ffi-obj,
>>> it calls clGetExtensionFunctionAddress. That part works great.
>>>
>>> The big problem that I'm having right now is with define-opencl-info (
>>> https://github.com/jeapostrophe/opencl/blob/master/opencl/c/syntax.rkt#L18),
>>> which essentially provides a convenient interface for the clGet*Info
>>> functions (which all have similar arguments). clGetGLContextInfoKHR  
>>> follows
>>> that pattern with one exception. It's primary input argument takes a  
>>> vector
>>> of values, rather than a single value.
>>>
>>> A call to define-opencl-info looks like this:
>>> https://github.com/jeapostrophe/opencl/blob/master/opencl/c/5-3.rkt#L76
>>>
>>> I thought I had the correct syntax by essentially replacing line 79  
>>> with the
>>> following:
>>>
>>> (args [properties : (_vector i _cl_context_properties)
>>> _cl_context_properties_vector/c])
>>>
>>> (I've also replaced the other types and argument names and whatnot,  
>>> but that
>>> all seems to work).
>>> Anyway, with the (_vector ...) call, I get the following error:
>>>
>>> ; c/9-7.rkt:26:22: define: not an identifier, identifier with default,  
>>> or
>>> ;   keyword for procedure argument
>>> ;   at: (_vector i _cl_context_properties)
>>> ;   in: (define (clGetGLContextInfoKHR:generic (_vector i
>>> ;     _cl_context_properties) _cl_gl_context_info) (case (hash-ref
>>> ;     id-selector-map _cl_gl_context_info #f) ((_cl_device_id*) (local
>>> ((define
>>> ;     len (clGetGLContextInfoKHR:length (_vector i
>>> _cl_context_properties)...
>>> ; [,bt for context]
>>>
>>> I'm not sure what that error is referring to, or how to fix it.
>>> Here's the backtrack, but it's not terribly helpful (that I can see,
>>> anyway):
>>>
>>> ; c/9-7.rkt:26:22: define: not an identifier, identifier with default,  
>>> or
>>> keyword for procedure argument
>>> ;   at: (_vector i _cl_context_properties)
>>> ;   in: (define (clGetGLContextInfoKHR:generic (_vector i
>>> _cl_context_properties) _cl_gl_context_info) (case (hash-ref  
>>> id-selector-map
>>> _cl_gl_context_info #f) ((_cl_device_id*) (local ((define len
>>> (clGetGLContextInfoKHR:length (_vector i _cl_context_properties)...
>>> ;   context...:
>>> ;
>>> /home/dane/encrypted/work/chematox/local/racket-5.90.0.6/collects/racket/private/norm-define.rkt:46:33:
>>> simple-proto
>>> ;
>>> /home/dane/encrypted/work/chematox/local/racket-5.90.0.6/collects/racket/private/norm-define.rkt:134:33:
>>> general-proto
>>> ;    try-next
>>> ;
>>> /home/dane/encrypted/work/chematox/local/racket-5.90.0.6/collects/racket/private/kw.rkt:804:2
>>> ;
>>> /home/dane/encrypted/work/chematox/local/racket-5.90.0.6/collects/racket/private/modbeg.rkt:46:4
>>> ;
>>> /home/dane/encrypted/work/chematox/local/racket-5.90.0.6/share/pkgs/xrepl-lib/xrepl/xrepl.rkt:1346:0
>>> ;    standard-module-name-resolver
>>> ;
>>> /home/dane/encrypted/work/chematox/local/racket-5.90.0.6/share/pkgs/xrepl-lib/xrepl/xrepl.rkt:1346:0
>>> ;    standard-module-name-resolver
>>> ;
>>> /home/dane/encrypted/work/chematox/local/racket-5.90.0.6/share/pkgs/xrepl-lib/xrepl/xrepl.rkt:1346:0
>>> ;    standard-module-name-resolver
>>> ;
>>> /home/dane/encrypted/work/chematox/local/racket-5.90.0.6/share/pkgs/xrepl-lib/xrepl/xrepl.rkt:1346:0
>>> ;
>>> /home/dane/encrypted/work/chematox/local/racket-5.90.0.6/collects/racket/private/misc.rkt:87:7
>>>
>>> In addition, when I replace the (_vector ...) stuff with a plain old
>>> _cl_context_properties, everything works fine (but the contract fails  
>>> when I
>>> actually try to call clGetGLContextInfoKHR, as expected).
>>>
>>> What am I doing wrong? It looks like (_vector i  
>>> _cl_context_properties) is
>>> just as much of a ctype as _cl_context_properties, so why does it fail  
>>> when
>>> I make it a vector?
>>>
>>> Thanks a ton,
>>> Dane Larsen
>>>
>>> ____________________
>>>    Racket Users list:
>>>    http://lists.racket-lang.org/users
>>>
>>
>>
>>
>
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users


-- 
---------------------------------------------------------
Tobias Hammer
DLR / Robotics and Mechatronics Center (RMC)
Muenchner Str. 20, D-82234 Wessling
Tel.: 08153/28-1487
Mail: tobias.hammer at dlr.de

Posted on the users mailing list.