Thank you for taking the time. I am following you well enough, but I'm having trouble applying your advice. I'll use a different function to hopefully simplify the discussion.
typedef VkInstance_T* VkInstance; VkInstance instance; vkCreateInstance(&createInfo, NULL, &instance) // assume createInfo is defined VkInstance_T is private. It's allocated in the implementation of [vkCreateInstance](https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkCreateInstance.html) as a side-effect. In Racket, I want the code to look and behave as much like that as possible, even if it means the instance is not allocated for me, or returned from the wrapper function. As per your advice I changed the wrapper procedure to use (_ptr io ___). However, I did not bind it to an identifier. I'm hoping to maintain the same arity as the C function, declare the instance in client code, and have it populated by side-effect as in the C. (define _VkInstance (_cpointer 'VkInstance_T)) (define-vulkan vkCreateInstance (_fun _VkInstanceCreateInfo-pointer/null _VkAllocationCallbacks-pointer/null (_ptr io _VkInstance) -> (r : _VkResult) -> (begin (check-vkResult r (quote vkCreateInstance))))) And, based on your email, I tried allocating the pointer and assuming that the wrapper procedure would use the address of the pointer for me (That's what I guessed was happening when you passed `0` across (_ptr io _uint32_t) earlier). (define instance (malloc _VkInstance)) (vkCreateInstance instcreateinfo #f instance) But this produces "VkInstance_T->C: argument is not non-null `VkInstance_T' pointer". I reproduce that exact error even if I replace (_ptr io _VkInstance) with just _pointer, and use cpointer-push-tag! What do I have to do to make this example work? If I can just understand that, I can bring that back to the prior example. ~slg ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, October 20, 2019 7:24 PM, Matthew Flatt mfl...@cs.utah.edu wrote: > At Sun, 20 Oct 2019 23:07:58 +0000, Sage Gerard wrote: > >> So if I take the vkEnumerateInstanceLayerProperties/private you showed me >> and change the (_ptr io _uint32_t) to (_cpointer _uint32_t), will it have any >> other noticeable usability differences for someone thinking like a C >> programmer? Do I have to use _ptr at all to do what I intend to do? > > You don't have to use_ptr, but (_cpointer _uint32_t) is awkward, > because it requires that the allocated pointer is tagged using > _uint32_t. Then, instead of just > (malloc _uin32_t) > a client would have to write > (let ([p (malloc _uint32_t)]) > (cpointer-push-tag! p _uint32_t) > p) > To expose the raw API without _ptr, I'd just use _pointer. > If possible, using _ptr is the right way to expose this function > without trying to provide a higher-level interface: > (define-vulkan vkEnumerateInstanceLayerProperties > (_fun (o0 : (_ptr io _uint32_t)) > _pointer > -> (r : _VkResult) > > -> (begin > > (check-vkResult r 'vkEnumerateInstanceLayerProperties) > o0))) > > I don't know if the information you're working with lends itself to > generating that kind of view, though, which would mean describing the > first argument is an in--out uint32_t. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/d0612-WaxmrOnMHAwXebVpKiSYKDomEnyqox2z1yQyY5EVYeLx-0a-shqIrDqHcoAWKoKvpC7QGMhjTU-5tzp5zNCqrRDgb6rAZecHKtBOk%3D%40sagegerard.com.
