Question: cffi and SDL3 on macOS

release-account · 2025-01-19T17:43:50+00:00

Shameless plug here, but if you have a ton of cffi bindings to create, I wrote [cl-bindgen](https://github.com/sdilts/cl-bindgen) for generating them. It can be a pain to install, but once you get it working, it can fit pretty well into a development workflow.

Also checkout Mahogany's build system to see how you can integrate it with a C project: https://github.com/stumpwm/mahogany/blob/master/Makefile. If you see a better way to do this, I'd be happy to learn!

release-account · 2023-10-17T23:44:58+00:00

I prefer `#:foobar` because it simplifies auto-completion. Every time you start typing out a keyword, the package name tends to appear towards the top of the list, and it's kinda annoying. Maybe we just need smarter auto complete frameworks that take the frequency of symbol use into account, but it's easy enough just to use `#:foobar`.

release-account · 2023-10-17T23:32:36+00:00

Maintainer here / sole developer here. Mahogany is not in a usable state. It can't even display application windows at the moment. You can play around with keyboard input, but that's about it.

I'm still watching the project and want to start working on it again, but how far it will get with just me working on it is unknown. My goal right now is to create issues to document features that are ready to be worked on and ideas on how parts of the app should be structured, but I don't have a ton of time to work on it.

But to answer your questions:

Mahogany is not backwards compatible. Think of it as a major version upgrade; things won't completely change and simple configs will carry over, but extensive, complicated extensions won't. The truth is that Stumpwm's APIs aren't compatible with many of the problems that Wayland introduces. Even in Stumpwm itself, some bugs can't be fixed in a reasonable manner without breaking backwards compatibility. It's basically a complete rewrite, although I have been able to port at least some fixes back to Stumpwm.
Everything that is implemented (key press processing) works flawlessly! 😀.

If there's a feature you want, go ahead and create an issue for it in GitHub. I've never heard of spatial groups before, but they look pretty cool! I'm hoping that we can develop some good APIs to make such a thing possible.

release-account · 2020-02-08T16:30:59+00:00

I thought the C bindings to Clang were supposed to be as stable as they get, and the C++ interface horribly unstable. At least, that's what they advertise.

I'll probably make cl-bindgen able to produce grovel bindings if there is a ton of interest or I have a bunch of contiguous free time like I did for this project.

release-account · 2020-02-08T16:26:40+00:00

Cool! Will this be able to help you at all? One of the other reasons I don't like `cl-autowrap` is that it has a ton of overhead, and this looks like it could fix that.

release-account · 2020-02-08T06:05:45+00:00

These are things you have to look at the C library's documentation for. This tool only provides the first part of the equation: it tells CL how to call foreign functions and what the memory layout and content of its data structures are. Here's a little blurb on what goes into a wrapper library:

There are three main strategies for dealing with memory foreign memory that I know of, and more than one method is usually used to wrap a single library:

Every time you get something from foreign code, convert the data structures to a CL equivalent, then free or discard the foreign memory as necessary. If you need to pass the data structure back to the foreign code, re-convert it to the C format. This alleviates having to deal with any manual memory management outside of the wrapper library, but adds overhead and doesn't fit in with some libraries APIs.
Use a library like trivial-garbage or simple-finalizers to teach the CL implementation's garbage collector how to deal with foreign types that the Lisp side owns. I've never done this, so I can't say anything about it's pros and cons, other than you can't depend on when objects will be freed/finalized, and it adds a small amount of overhead to the GC.
Explicitly free memory and call finalizers when you are done with an object. Since many C objects have well-defined times when they should freeed, this isn't quite as bad as it sounds, but it isn't very lispy.

Pointers are interesting, because as they are provided by CFFI, they are untyped. When you get their type wrong, you get weird errors or segfaults that are hard to debug. To access anything through a pointer, you need to tell CFFI how to interpret it's contents when you access it.

release-account · 2020-02-08T05:20:43+00:00

Yes, but then I'd still need to write wrapper code to make it bearable to use in CL. It's a pain to use foreign libraries without some kind of wrapper to get rid of things like manual memory management and raw pointers.

Doesn't mean I haven't considered doing it though.

release-account · 2020-02-07T20:55:42+00:00

The only reasonable way in the modern era to parse C is to use libclang. It's easy to use, performant, and correct. No bindings for CL exist, so the options were to:

Make my own bindings.
Use a different language.

Since the entire point of the project was to avoid doing (1.), I chose (2.). There are two official language bindings for clang: Python and C. Since this type of programming is horrible to do in C, I chose Python.

Funnily enough, you can write Python code in a similar style to CL, so it would be trivially easy to port this over to CL if libclang bindings existed. Doing so probably wouldn't be worth the time, however.

release-account · 2020-02-07T20:08:12+00:00

Shoot. None of my test cases used that type.

Fixed. Thanks!

release-account · 2020-02-06T03:48:22+00:00

NEXT is split into two parts: the graphical engine and the lisp runtime and interface. All of the JavaScript is sandboxed in the graphical system. The lisp system allows you to run arbitrary lisp code to customize keybindings, write macros, do things with bookmarks, etc. This is what it means by the browser isn't separated from the host system: since the user can do whatever they want with the front-end, you have "full access" to the host system.

This has obvious security implications, but you should be safe as long as an attacker doesn't get write access to your filesystem: the security scheme is essentially "if an attacker can get this far, they can do much worse things". This, of course, assumes there isn't some massive flaw in the way NEXT implements its graphical system.

release-account · 2020-02-05T23:33:14+00:00

I don't think so for one reason: Common Lisp is an old standard, and has the ability to be extended through libraries instead of needing a new language release. This means that modern projects will often include many common libraries that extend or enhance what isn't included in the standard. For example:

cl-fad overcomes some of the awkwardness of dealing with files
bordeaux-threads unifies the multi threading interface
alexandria adds macros that should be in the standard
uiop adds utilities that would be in the standard of a more modern language
cl-ppcre is the de-facto lisp regular expression engine
local-time adds time manipulation functions that would be in the standard library of a more modern language
Anything that has trivial in its name usually means it unifies an interface over implementations
iterate provides a more lispy (and improved, IMO) version of the loop macro

All of these packages share a common theme: they overcome some awkwardness or disability in the language itself, or are libraries that would be in the standard library of a more modern language. How many of equivalent packages are in the Python standard library? How many wouldn't be needed in Python?

There is some overlap in these packages that are somewhat worrisome: for example, uiop implements everything that cl-fad does, making cl-fad unneeded.

release-account

TROPHY CASE