Transferring all bindings to the auto-generation system about ev3dev-lang HOT 20 CLOSED

re python bindings: I think I figured how to deal with the autogeneration system, but since the python bindings are based on the C++ bindings, I was waiting for @fdetro to finish the transition first. Btw, I think I could also help with the C++ bindings if @fdetro is too busy.

from ev3dev-lang.

Now that ev3dev has hit a fairly stable milestone, I think I'd like to make the final changes to keep in sync with the recent driver updates and then make a release.

This means that:

• I will probably make some changes to the spec, maybe add new properties.
• I will be performing some various housekeeping tasks (update submodules, clean up README, etc.).
• We should all make sure that our bindings are up-to-date, which means that they support the latest kernel and that they have generally implemented the features of each device.

As part of this, I'd like to know the state of each binding in this repo. As I understand it, the C++ and Python bindings have been updated, but the Lua and R bindings have not. What I'd like to know is:

• For Lua, is there anyone that is able and willing to update it? I understand that people have actual lives, so I understand if you can't do it. If there isn't anyone that can do it and I can't get it transitioned to the autogen system myself, we might just have to leave it with a notice saying that it isn't compatible with the latest kernel.
• The same goes for @bmegli's R binding: Do you have some time to update it, and maybe convert it to the autogen system? I can try, but again I'm not sure how much success I will have.

I'll look through the kernel changelog tonight and make the changes that are required.

from ev3dev-lang.

The latest kernel upgrade breaks tacho motor support in cpp/python bindings. Apparently its more than just driver name change, so I am waiting for @WasabiFan to update the specification. After that I'll try to update the bindings.

from ev3dev-lang.

Yes, the motor changes were quite significant. See ev3dev/ev3dev#282 and http://www.ev3dev.org/docs/tutorials/tacho-motors/ to get a feel for how things are supposed to work.

from ev3dev-lang.

@ddemidov I went through the docs and updated our spec. Are you saying that the CPP bindings don't work after they are regenerated, or that you just haven't regenerated them yet?

from ev3dev-lang.

@WasabiFan, I did not regenerate the bindings yet, will try to do this tomorrow. I hope that the only changes that would be needed outside of generated source are driver names here. By the way, is it possible to make driver names a part of specification?

from ev3dev-lang.

The driver names are already available in json files here. Ports and sensors are automatically generated from the source code, but motors are still maintained by hand (so may contain mistakes).

For example, to get the motor driver names that @ddemidov is looking for, you would need to filter motors.json on "device_type" == "legoev3-motor" and then get the "name" values.

from ev3dev-lang.

Although, now that I am thinking about this, it is not quite that simple. When using the NxtMMX, the driver_name attribute will return ms-nxtmmx. Not sure how that could be automated at this point.

from ev3dev-lang.

@ddemidov With our current system, it isn't very easy to include data from our spec directly, but I'm currently in the process of adding a way to do this. But the data is there already, just not accessible.

from ev3dev-lang.

@ddemidov I just remembered that there's one more thing that I still need to do before the new spec will work: I need to change the defined motor constructor to use the driver name instead of the type. I'll post back once I have fixed this.

from ev3dev-lang.

Updating the bindings to work with the new kernel was actually an easy task (almost trivial thanks to the autogeneration system). What is more interesting is making demos both in cpp and python work again, since those were based on the previous API. I think I'll manage to update python examples in the following couple of days.

The changes I had to make to cpp and python are here and here. I can make a PR for cpp bindings, but that would be incomplete and broken without updating demos first. @fdetro, if you don't have time for this, I can try to update the cpp demos on the next weekend.

from ev3dev-lang.

What is more interesting is making demos both in cpp and python work again, since those were based on the previous API.

I'm having the same problem. My library now works (as far as I can manually test it), but the demos that I usually use to confirm that are broken.

P.S. I forgot to post here to say that i had updated the spec again. It seems like you already saw it, but if you didn't I'd recommend that you look at the diffs for my last two commits. It's mostly minor stuff. If you find any issues with the updates that I made, let me know.

from ev3dev-lang.

@ddemidov As I am looking at the autogen definitions, I'm noticing that there's no entry for ev3dev.cpp -- which means it's never generated. Are you just generating the one for Python and using that for both bindings? I'm just curious about how it's configured.

P.S. I updated the spec again -- mostly just the power supply API. Just wanted to let you know.

from ev3dev-lang.

ev3dev.cpp contains the code that deals with /sys/class nodes: reading/writing of attributes, finding specific nodes by patterns, etc. The API is implemented in ev3dev.h in form of inline methods. Hence the latter file is the only one touched by autogen.

I use the same ev3dev.{cpp,h} for generation of python bindings that come with cpp bindings.

from ev3dev-lang.

Ahhhh I see. I was expecting that it was something like this, but I wasn't sure. Thanks for explaining!

P.S. I really need to learn C++ 😉

from ev3dev-lang.

As I have moved some weeks ago, I had very little time to maintain the lua binding. I will try to adjust the code to the autogen system within the next weeks.

Thanks to @ddemidov for taking over the cpp maintenance.

from ev3dev-lang.

@fdetro You pushed a branch that seems to have the lua bindings auto-generated -- is it just a matter of making the demo/test app work before that is ready-to-go?

Assuming no more changes to the kernel, my plan is to release within the next week. Any bindings that aren't up-to-date currently should be either updated soon or a note should be added to their readme explaining that the binding is old.

@bmegli You have a few commits from a while ago in your fork of the repo, but other than that you don't seem to have updated R bindings for any of the more recent kernels. Do you want to update them within the next few days, or should I just mark the folder in this repo as outdated (or remove it)?

from ev3dev-lang.

Yes, right. I need some more time for the demos, I hope to find some within the next days.

from ev3dev-lang.

I have finished the work on the lua autogen stuff and fixed the motor APIs / test program. I haven't changed the drive example as the motor API changes force a complete rewrite of the code.

I think we can close this issue now, right?

from ev3dev-lang.

I'd say we can.

As I understand it, this brings us to a state where all of our bindings are ready. I'll tag the release today, unless I see any objections.

from ev3dev-lang.