Should record definitions be moved out of impl and into clj-bots.gpio ns?

[metasoarous]

My inclination would have been to do so, and leave only the nuts and bolts functions (fopen, fclose, keyword-to-state, etc) in the impl ns. My thought on this is that it would be nice to have a constructor function which either had an :impl arg, or looked for some *default-implementation* var (along the lines of the core.matrix set-current-implementation function). We could of course keep the gpio lib more bare bones, and leave these sort of niceties to the BBB and Pi specific libraries, but then we'd potentially be implementing the same stuff twice (assuming we or others get to Pi).

Welcome your thoughts on this.

[zeroem]

So, my thinking was that the GPIOPin protocol is what's most important, the SysfsGPIOPin record is there as a means to keep all of the internal workings of the sysfs implementation together. At some point, I'm gonna take a swing at using JNA to bind directly to the C impl of the GPIO code which would get it's own record but impl the same GPIOPin protocol.

Eventually, there will be some sort of function in clj-bots.gpio that will take care of what impl to use, I just haven't gotten around to researching/impling it. I figured I'd get enough done so that I could pop a repl on the BBB and start testing the sysfs impl.

As for BBB/Pi specific stuff, the sysfs gpio code should be the same everywhere, so it should be it's own library. Once that gets ironed out and solidified, I figured there would be a BBB/Pi specific library that gives you all the device specific convenience functions, eg mapping the BBB "header_pin" strings to the actual underlying pin, functions for manipulating specific hardware (eg the onboard LEDs), etc.

the BBB library is what would become "bonejure", with gpio as a dependency. Gotta think of a catchy name for the Pi Library.

[zeroem]

Oh, also, ideally, the end user of the lib will never need to know about SysfsGPIOPin or that it even exists, they would simply say "I want impl x" and they know they get a GPIOPin back.

[zeroem]

AAAAAAND one last thing. Regarding abstracting the underlying implementation. My thoughts were that the reserve and release functions in sysfs would become another protocol in gpio and would serve as the definition of an implementation. as long as the implementation of your choice implements that protocol, and those functions return/take a GPIOPin respectively, all is good.

[metasoarous]

Absolutely agree on keeping separate records implementing the same protocol and having a function that dispatches on which record to use. However, there are problems with circular namespacing in clojure. Currently, the impl code references the protocols in the main API ns, so the API ns can't reference the impl nss. So there is no way for a such a dispatch function to live in the main API ns without moving the record definitions there as well. However, this would still let us hide all the "internal mechanics" fns in the impl nss to be required for the record definitions in the main API ns, which is what's really important.

As for reserve and release, is there any reason they shouldn't just be part of the GPIOPin protocol? I guess it's not a big deal for it to be a separate protocol, but it seems it's something you'd want for any implementation, so makes sense to bundle it in.

[metasoarous]

FWIW, I just pushed up a rough sketch of a bonejure project. It's got an AIN implementation, the [header pin] -> sysfs-pin stuff, and automated release of gpio pins on shutdown set up already. However, it's not building; I seem to be having troubles getting it to load clj-bots.gpio using lein-git-deps for some reason. I'll post about that in a sec. In any case, check it out.