libera/#commonlisp - IRC Chatlog

3:03:59 Bubblegumdrop How do I convert a lisp array for use as a C array? is there somewhere I can read more about this? http://paste.debian.net/1328263/

3:34:05 kanuba You'd have to allocate the array of rects with cffi, or build one from the fields of the rect struct of the rects in that list. CL lists and CFFI don't match very well

3:34:57 kanuba If you had a vector of the proper numerical elements, and they weren't boxed, you could pin the array, or use cffi:with-pointer-to-vector-data

3:36:54 aeth bilingual Lisp vectors + C arrays are https://github.com/sionescu/static-vectors

3:38:14 aeth vectors, not lists

3:40:09 aeth even if you start out with a list or a non-static-vector adjustable vector, using REPLACE on a static-vector may be more convenient than doing it the CFFI way

3:40:15 kanuba static-vectors will allow you to allocate a foreign array with a lisp interface for manipulating it, but getting a pointer to an existing lisp data structure is different.

3:43:05 kanuba cffi:with-pointer-to-vector-data is handy for wrapping the foreign sdl api, for things like creating a surface from a simple-array of pixels

3:43:53 Bubblegumdrop I think that's what I want, thanks...

3:43:53 kanuba autowrap adds a whole new complexity though, as I see you're using cl-sdl2. it uses objects that wrap pointers, rather than pointers.

3:44:09 Bubblegumdrop I did this once before with libpng but honestly have no idea what I did to get it right...

3:44:25 aeth wrapped pointers (as in cl-sdl2/autowrap) are not a good idea

3:44:36 aeth I think they exist because cl-sdl2 used to have finalizers, which got removed because they are not a good idea?

3:45:08 aeth you really want the C stuff in unwind-protect instead of random magic happening in places

3:45:34 Bubblegumdrop I'm using sdl2kit, I think it wraps the ,@body in unwind-protect

3:46:43 aeth iirc, sdl2kit is just added magic on top of cl-sdl2, of the wrong kind of magic

3:46:52 kanuba Note that you will have to ship libsdl2-compat in addition to libsdl2 soon if not wrapping sdl yourself

3:47:16 kanuba (sdl3 is finalized and will be hitting distribution package managers relatively shortly)

3:47:28 kanuba it has a fairly different API, and shaders

3:47:40 kanuba the compat will allow sdl2 apps to run on sdl3

3:47:50 aeth good opportunity for something to finally replace cl-sdl2, though

3:48:01 aeth which most people still seem to use

3:48:50 Bubblegumdrop well I'd like to be using trial but it's just too fancy for me

3:50:00 kanuba I like to keep things simple and use my own sdl2 bindings (which do not include the software rendering api functions that you are using, so it wouldn't be of much use).

3:50:29 Bubblegumdrop I really ought to spend more time looking at gilberth's ffi thingy

3:50:34 Bubblegumdrop It's probably a lot simpler

3:51:00 aeth cl-sdl2 (and to some extent autowrap) has some really bizarre design decisions, which you will encounter if you encounter bugs or incomplete parts of cl-sdl2, which you will, because its author afaik stopped using Lisp 7 or so years ago

3:51:29 aeth though cl-sdl2 does get some bug fixes

3:52:24 kanuba as the former maintainer of cl-sdl2, i concur. currently it is maintainer-less.

3:52:32 aeth it was supposed to be higher level than a mere SDL2 wrapper (unlike e.g. cl-opengl and OpenGL), which means that there's a lot of performance-affecting, buggy, incomplete, undocumented, hard-to-explore stuff added on top

3:52:52 aeth as opposed, again, to cl-opengl where you can just take C OpenGL references/tutorials and basically just translate them into CL

3:54:05 aeth for an example of hard-to-explore, there's iirc a macrolet inside of a macro, so just a completely magical (form) that just exists inside of a macro body

3:56:15 kanuba cl-sdl2 is also full of memory leaks and unimplemented (often needed) functions, some of which are not even caught by the low level bindings package, because autowrap can't parse C preprocessor macro decorations

3:58:14 aeth a macrolet inside of a macro isn't M-.able in Emacs (to find the reference) so it will lead you down a several day wild goose chase. I don't care how fancy your macros are. Implement an entire language if you must. But somehow find a way to make M-. resolve for everything.

3:58:15 Bubblegumdrop currently what I'm battling

3:58:18 Bubblegumdrop thanks for the help everyone

4:00:21 kanuba Luckily there are not very many of them, and most of them should be implemented in pure lisp anyway: https://github.com/libsdl-org/SDL/blob/b233beca47c0ab1dd00df041134726f7f2ccb6da/include/SDL3/SDL_rect.h#L155

4:04:00 kanuba The real problem with sdl2 (or 3) is its api, particularly its automatic memory management functionality, is poorly documented (it does reference counting and automatic freeing of some things)

4:04:52 kanuba wrapping it can be tricky and double free corruption will haunt you (cl-sdl2) even does things wrong and causes leaks or corruption in cases)

4:05:11 kanuba a testament that autowrap is not a cure, even a magical one

4:05:28 aeth I wasn't aware of this. Is this the 2D API?

4:05:34 kanuba It's everywhere

4:08:31 kanuba SDL subsystem initializations are ref-counted. surfaces have an internal refcount slot, etc.

4:08:52 kanuba SDL_GetNumAllocations() is exposed to show the number of allocations it tracks

4:09:31 kanuba Which can be useful when trying to wrap things correctly, if you are insane enough to play that trial and error game across the kitchen sink

4:13:20 kanuba some things are not meant to be manually freed, like pixelformat objects, but only in certain cases when they are not constructed automatically. It's really a mess.

8:12:05 kamafam1 ** NICK kamafam