I have a style question, being new to CL and StumpWM: should I be
using FFI to invoke the XRandR libraries, or should I be shelling out
to the xrandr CLI tool and parsing the output?
My (strong) gut feel is that it'd be better to use the XRandR
libraries ... but playing devil's advocate there's already a perfectly
workable CLI tool for XRandR, and it seems pretty easy to invoke such
things & parse the output (see e.g.
On Thu, Apr 12, 2012 at 1:34 AM, Duncan Bayne <[hidden email]> wrote:
> I have a style question, being new to CL and StumpWM: should I be
> using FFI to invoke the XRandR libraries, or should I be shelling out
> to the xrandr CLI tool and parsing the output?
It's always better to go FFI rather than parsing command output.
You'll get more precise access to features, better error handling, and
> My (strong) gut feel is that it'd be better to use the XRandR
> libraries ... but playing devil's advocate there's already a perfectly
> workable CLI tool for XRandR, and it seems pretty easy to invoke such
> things & parse the output (see e.g.
If you don't already know cffi or a specific lisp's ffi then it might
seem like writing a ffi program is hard. I have tried calling shell
commands and parsing output and have switched to directly calling
library functions through an ffi every time. Writing foreign function
code is easy--as long as it's a C library. Unless the command line
tool does a bunch of work that you really don't want to rewrite in
lisp there is no reason I can think of that you'd want to parse
another program's output. I guarantee you'll spend at least as long
dicking with regex's or wishing the tool had some switch or option
it's missing. In the end the ffi program will be more robust and give
you greater flexibility. It's worth doing if possible.
That said if your needs are simple maybe just calling the cli tool is easier.
This is a great question and an informative response. Thanks to you
A related question is whether it is better to utilize a DBUS interface
versus FFI or CLI. For example, I have code to control wicd via its DBUS
interface, but I ran into a issues with the existing DBUS library. I
forked a workaround that loads from a local project. It works, but there
seem are idiosyncrasies with the interface such as certain asynchronous
commands delaying several seconds before returning.
I intend to nail down the issue (likely a misuse of iolib), and submit a
proper patch, but even assuming everything runs smoothly and is made
available in quicklisp, there is still the concern of the DBUS library
pulling in many dependencies.
Is DBUS useful enough to provide the impetus for making interfaces
easily accessible from within stumpwm?
> Is DBUS useful enough to provide the impetus for making interfaces
> easily accessible from within stumpwm?
I can't remember why now, but I've recently searched for a CL DBUS
library and the scenario was not very encouraging. There is one in
Quicklisp, but many (maybe every?) source code file has a banner with
the words "DEATH 2010-2011", which I don't know what it means, but it
doesn't sound right.
Many programs on Linux ecosystem use DBUS, and from a distance, I would
say that the numbers are growing. On some systems, you can't even kill
-9 DBUS without it dying a horrible death.
So I guess you can check the box for DBUS importance.
Now, for stumpwm, I guess it depends on how you want to interface with
the cold world outside our cozy REPL.
For me, you gain brownie points every time you let me avoid having to
deal with things other than Lisp.