[Libnifalcon-devel] Coming Soon: New kinematics, new language support, and new beta

[Kyle M. <ky...@no...>]

I've been creating a few new branches lately on the libnifalcon github repo,
with lots of exciting new features:

- barrow_kinematics: Alastair Barrow sent me a new implementation of the RL
Stamper kinematics system this week. It fixes quite a few of the bugs we
were experiencing in the old implementation, while also being a lot less
complex, source-wise. I'm just going to do an in-place switch of the
systems, no outside should need to be changed. Things will just be a lot
more stable. This is mostly done, just needs a little cleanup and
commenting.

- default-device: This branch is rather oddly named for what it turned into.
I finally decided to take the leap into supporting other languages on top of
libnifalcon. The first try is python by way of boost::python and
pyplusplus/pygccxml. This happening by way of a new FalconDeviceDefault
class, which will be changing names to something like "FalconDeviceBridge"
before I merge back in, because default doesn't make much sense. I'm
basically trying to distill down libnifalcon to a single class, derived from
FalconDevice, that removes templates (hence the 'default', it sets the comm
core, kinematics, firmware, and grip behaviors), can run communication,
allow for access to raw input and output (for building kinematics or other
low level interaction in other languages), and also allow usage of the C++
kinematics cores if need be. I got most of this done and checked in today,
and have all of the test in falcon_test_cli running at full speed in python
now. The next goal is building FalconDeviceWhateverIEndUpCallingIt under
SWIG so I can get Ruby and Java going. I'm honestly not sure why anyone
wants direct device access in those languages versus going through an
engine, but I get a lot of requests for them, so I figure if it's not much
work, I'll give it a shot. If anyone has any advice on SWIG, I'm happy to
take it, though I'm hoping it'll just be a case of having to do an include
on the header, and that's it.

- new-build-system: This is more for me than anyone else. Been doing a lot
of work on the build system lately to make it more large project friendly
(started using it at my day job and they're letting me take everything I've
developed there back into my own projects :D ), so I'm working on bringing
all of my projects in line with that.

Once all of these are done, I'll merge them down to master and throw another
email out on the list. Depending on how much testing they get, and how much
documentation I get done, this will either end up as beta 5, or I may just
roll the whole thing as v1.0 and be done with it. I don't really have any
testing in place at the moment, and I'm not sure how much testing happens
per release, and I'd really like to get out of the v1 release period I've
been in for... 11 months now.

BTW, you may've noticed, sourceforge completely yanked the wiki, so all of
the links that used to go to it lead nowhere now. I'm trying to replicate
that information elsewhere, but it's slow going for the moment. I hate
sourceforge so much at the moment, but hopefully we'll be mostly free of
them (outside of file releases, though I'd LOVE to find a different place to
release as sourceforge has been completely unreliable for 2+ months now, and
this mailing list, which I'm debating moving to google groups) soon.

Kyle