|
From: Kyle M. <ky...@no...> - 2009-08-23 05:25:47
|
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 |