alternative implementation proposal

[EricPobot]

Hi,

After playing a bit with autogen and templates to learn how they work, I'm still not really convinced of their real benefits.

Having experimented with the whole process of modifying Python binding code, including templates update, my gut feeling is that the gains obtained by automatic multiple languages source generation are not significant enough to compensate the hassles of templates coding. It is pretty tedious to write mixtures of templating code and Python (or whatever language) since both are mixed in a way which makes the result pretty unreadable, added to the fact that no editor or IDE can help you there.

In addition, having cross-language templates for code generation prevents from using features available in some of them only. For instance, Python mixins have no equivalent in Java, and thus cannot be used at class generation level. Depending on the languages, the implementation classes ideal architecture can be different if we want to use the most of what each language has to provide, which autogen mechanism makes quite difficult to achieve, if even possible.

And at the end of the day, it is still required to code a set of templates for each language, and these templates will have to be maintained by hand anyway.

I admit that changes such as device class peudo-files name changes can be propagated automatically when using autogen, but this is not enough for me to consider that the balance is on its side.

BTW I could note that it seems that the templates were not up to date at the time I tested, since the "pilot" file was not in coherence with the current sources organization (recent refactoring as a package). If even the creators bypass it and code directly the generated sources, what sceptical folks like me should think...

So I've made an attempt to completely remove templates and wrote an alternative version of the Python binding, heavily based on the current version of the autogen generated code. It is available at https://github.com/EricPobot/ev3dev-lang-python-alt.

In addition to the library code, the repo contains demonstration programs, including a complete robot for testing the usability from the application developer point of view (as requested some time ago).

I have also done some job at documentation level (adding missing parts, adding method parameter and result types,...).

Please let me know what you think about this work. I'm aware that my "rebel" way of doing could not be at your taste, since it seems that you stick to the autogen method, but I had to do it for making my own opinion ;) If the proposal were not approved to be merged in the official line, I think I'll try to maintain it on my side, keeping it aligned with the common API. Of course, it would be better not to have several parallel tracks ;)

Maybe I'm missing some important point WRT autogen benefits, which bias my evaluation. Please let me know.

Best regards

Eric

[ensonic]

If we feel that the autogen approach is cumbersome, we coudl also consider implementing everything in ev3devkit and use gobject introspection (gir). In the case of python, this would actually not generate python files, but do the bindings on-the-fly. We can use the same for other languages too (e.g. js, lua). We already have gir files for ev3devkit. See https://github.com/ev3dev/ev3dev/issues/373

[ericpascual]

Thanks for your feedback @ensonic . I don't know very much about gir so I can't say.

As I wrote before, this proposal is not an assessment of the global benefits of the autogen approach. Some important points may have not hit my mind, thus biasing the evaluation. This is only the feedback of a newcomer who tries to contribute and has had some difficulties to follow the practices in place.

As an indication of the workload corresponding to a manual maintenance of the binding, it took me only a part of the week-end to produce what I've published, including the demos (the robot one was the longest to polish) and the updated documentation (the original one misses parts such as hints about argument and results types, constants documentation,...).

Said differently, if I had to maintain the binding, I would go with the hand written option (apart if somebody points me to something major I've overlooked). After all, the kernel part is not supposed to change every two days once stabilized and deemed as production level, so the API will not require that much work to be kept in sync at this level. And BTW you have to maintain templates by hand anyway ;)

[ddemidov]

@ensonic, what kind of interface would come out of introspection? Would we have any control over it, or would it be completely automatic? I am afraid Eric would dim it even more un-pythonic :).

@EricPobot,

it took me only a part of the week-end to produce what I've published

I think that is only because you had a good start with already existing code, generated by autogen. Now, imagine a new guy (like @jabrena) decides to create bindings for a new language (like Java). How much time do you think it would take to do this without autogen?

And BTW you have to maintain templates by hand anyway.

There is a difference between maintaining 200 lines of templates and 3000 lines of repetitive code.

In addition, having cross-language templates for code generation prevents from using features available in some of them only

I don't think there is anything language-specific in our specification, or at least there should not be. The spec describes sysfs attributes, and templates for each bindings do the job of translating that into the language.

[ericpascual]

I think that is only because you had a good start with already existing code

For sure it helped, but honestly there are not that many attributes. Even if this is repetitive code, it is written once for most of it.

I do not contest the benefits of automatic code generation in general, but what matters is the overall balance. Believe me, I really tried to stick to the process, for intellectual curiosity's sake (IRL I work as a researcher ;-) ), keeping a priori out of the way. At the end of the day it didn't convince me that the balance was on the right side. Consider the fact that before writing the templates, you have anyway to write it by hand in the targeted language for testing and validating the implementation. Then you'll have to migrate the code in the templates. And afterwards, you'll have to check that the code generation chains produces the exact same code as the one you've validated. These two extra tasks are time consuming, and depending on the volume of code to be maintained, their weight is not guarantied to be counterbalanced.

I don't think there is anything language-specific in our specification

I was not saying this at all.

I was saying that, because the templates must be language agnostic, you cannot use specificities offered by some of the targeted languages. You have to restrict to the intersection of features. I gave the example of mixins as an illustration, since you don't have such a thing in Java for instance. Because of this, you cannot use such an architecture in the class definition templates.

How much time do you think it would take to do this without autogen?

As I said above, he will anyway have to write the resulting code before (even partly) to validate it. I'm not so sure that the extra amount (if any) of repetitive code will justify the efforts to spend with learning how to and writing the templates.

What maybe biases a bit the assessment is that people like you and other contributors used to the autogen method will do this (writing the templates and checking the process) quickly because they are used to it. And this is fine. But things are not the same for people new to this (such as me), and chances are that it will cost them more efforts that you may imagine.

To answer your question, I'm not sure it will take him more than what I spent, because the existing code is there for other languages now, and this can help a lot. A good share of the job can be done by a simple language translation of basic statements. Even by hand, and although not the most passionating thing, this is quite straightforward.

Anyway, what do you think I should do with what I've published ? Even if not autogen based, it contains some enhancements (according to my opinion ;-)), a good share of them at embedded documentation level. I've not ported all the latest modifications done on the mainline (e.g. pseudo files path change, LEDs class evolution,...) but I'll take care of this it this WE.

[jabrena]

I am reading the whole thread.

Yes, I suppose that I will adopt a mixed strategy to develop the first library. (This weekend, Basic motor support) In my case, I will try to use the maximum features from autogen, but I recognize that @ddemidov, @rhempel has several hours of advantage and you have more vision about the usage.

[ddemidov]

Consider the fact that before writing the templates, you have anyway to write it by hand in the targeted language for testing and validating the implementation.

Why does it have to be so convoluted? You can write the templates from the start.

you cannot use specificities offered by some of the targeted languages. You have to restrict to the intersection of features.

I don't see where this is coming from.

Anyway, what do you think I should do with what I've published ?

Well, you don't have any history in that repo, so its hard to see what has really changed. Can you at least point to the places worth attention?

[ddemidov]

Well, you don't have any history in that repo,

I am sorry, it seems I was wrong about this.

[ericpascual]

You can write the templates from the start.

Seriously ?

Even if being a CLI hard core user, I appreciate the comfort of my favorite editor understanding Python, being able to introspect the code and propose completions, displaying signatures of called methods,... When I was editing the templates (which I did during my trial) none of these was possible. I had the feeling being back to the age of good old Vi without any of the language support extensions ;)

I don't see where this is coming from.

I should have missed a point here. For instance, how would you write a class declaration template making use of multiple inheritance for languages which support it while being compatible with the other ones ?

I am sorry, it seems I was wrong about this.

No harm. I admit that my "dual-head" identity (i.e. @ericpascual and @EricPobot) can have created some confusion. When I write from office (like now) my work account is active by default, and switching back and forth is a bit tedious :-/ I've used the same picture for both identities to help understanding that they are the same dude ;-)

[ericpascual]

@jabrena Hi Juan,

Do you plan to port the LeJOS ecosystem to ev3dev ? Having used it a lot at a time (and even contributed a bit) I was about to modestly start working on this task (I planed to start with the Pilot and Navigator family classes).

It would be great to benefit from the LeJOS framework in other languages. I would be interested to know how you plan to do it using the templates. I'm sure this would help me understanding what I'm currently missing on this topic.

[jabrena]

Hi eric, nice news!!!

the main goal of ev3dev-lang-java is the possibility to develop software for robots using Java on EV3Dev: https://github.com/jabrena/ev3dev-lang-java

You know that Local navigation features from LeJOS are great but the package lejos.robotics.* are coupled in a strong way to lejos.hardware.* & lejos.hardware.internals so I think that the idea to port 100% is a bit complex in a first stage.

This weekend, I will continue working in motors. if you like we could work in team to have a Pilot & Navigator. Besides, exist another guy who he said this week, that he wanted to participate in the project so we could be 3 in a small team.

At the moment, I upload from maven the jar to the brick and I have a primitive motor support. Next week I will promote the package to a maven repo to use in the examples.

Do you like the idea to join us in the EV3Dev adventure with Java?

Cheers

[EricPobot]

@jabrena

Do you like the idea to join us in the EV3Dev adventure with Java?

I'm afraid there is some misunderstanding with my intention ;)

The idea is to make LeJOS ecosystem (at least a part of it) available to other languages by porting it while keeping the same architecture (if possible). I enjoyed the way you have designed LeJOS class library, but felt in love with Python since then, and switched to it for nearly all my activities (professional ones included). Rather than creating from scratch yet another library for ev3dev, it seemed more productive to reproduce something already operational and designed by smart people ;-)

[jabrena]

hehehe,

Yes, I have the same idea but I think that in this moment, I will put the focus (hours) in the development of a low Level java library for sensors and actuators (motors). Once the API will be stable, I will try to evolve the package to have more features with a similar LeJOS design, but if you see the interfaces, I didn't see a clear isolation from interface to the final implementation.

Cheers

[ericpascual]

@jabrena This makes sense.

but if you see the interfaces, I didn't see a clear isolation from interface to the final implementation.

I'm not sure to understand the point here

[jabrena]

Yes, I am going to explain.

In last 2 weeks, I was analyzing LeJOS packages to check the easiest way to integrate with EV3Dev. https://github.com/jabrena/ev3dev-lang-java/issues/14 and I noticed that lejos.hardware.* and lejos.internals.* are the abstraction for EV3 Brick on Busybox. The problem with your idea is that the package for navigation: http://www.lejos.org/ev3/docs/lejos/robotics/navigation/DifferentialPilot.html http://www.lejos.org/ev3/docs/lejos/hardware/motor/Motor.html

are pretty coupled with hardware directly, but I think that a good implementation should be independent of hardware and it should be packaged in another jar not in the same jar from low level support. If you explore the class Motor returns a NXTRegulatedMotor objects so I thought to begin with a basic Java support and later, I will try to evolve the code to use a LeJOS way to code but frankly, I think that I have not seen many points to copy directly the classes.

The packages that I think with a easy way to isolate in an application library could be:

lejos.robotics.filter
lejos.robotics.geometry
lejos.robotics.localization
lejos.robotics.pathfinding
lejos.robotics.subsumption

but if observe, the local navigation support which they offer odometry data is coupled with hardware so I return to the first point of view which I said.

If you begin developing local navigation, I would like to help you in Java side or help you in the software engineering topics related with ev3dev. :)

In my case, I suppose that I will have some serious results in some months but I don't have many time in the weekend so, I will use a LEAN approach: http://www.allaboutagile.com/lean-principles-1-eliminate-waste/

But we should think in Factory Design patterns to isolate hardware to utilities to help in navigation issues. http://alvinalexander.com/java/java-factory-pattern-example

Well, I continue with the development :D

[dlech]

If we feel that the autogen approach is cumbersome, we could also consider implementing everything in ev3devkit and use gobject introspection (gir).

This forces the user to learn GLib, so I don't think it is a good choice for an entry-level library. I consider it more for "power users".

As a side note, the Devices part of ev3devKit started out as ev3dev-lang-vala and used the autogen system. The first thing I did when I took it over was ditched the autogen. I find it much more practical to maintain by hand. There are just too many nuances to deal with, both in implementation and documentation.

I've been keeping my opinion on this to my self because there seem to be enough opinions already :wink:, but I've got to say, from my point of view I think that in getting this library off the ground using autogen was very useful. But at this point in time, given that the kernel is relatively stable and that you have so many willing contributors, it seems to me that continuing to use autogen for this particular library at this point in time seems be restricting us more than it is benefiting us.

Also, looking at this from the point of view from a user and not a developer, obviously autogen makes no difference to me, the user. If I see that one library has better IDE support for autocompletion and things like that, on the other hand, I will choose that library because this is what is most important to me. Furthermore, if I am new to open-source software and I get brave enough to try to fix some documentation or maybe even work on some code and I see that the part I want to change is automatically generated, well, I'm not going to touch that and we have lost a potential contributor.

[rhempel]

OK, back at the keyboard after a couple of days away and this is an interesting discussion.

I would like to ask @jabrena to please open a separate issue to discuss LeJOS related issues so we don't get the two separate issues confused.

I am also of two minds regarding autogen - but I am in favour of keeping it for a couple of reasons:

1. The spec.json file does a pretty good job of specifying the core features that a language binding must provide, and it's possible to autogen the core very easily - sure, not much is changing right now, and we don't have that many fully compliant bindings yet, but ...
2. Having all the language bindings access motors, buttons, etc in more or less similar ways is a good thing, because it helps to demonstrate that the ideas behind robot programming (at least at the update rates we need) are often language agnostic.
3. I am working on a Lua binding and stated down the path with one OOP framework and then switched to another - I really appreciated being able to tweak two templates, press a button, and that was pretty much all I had to do.
4. My method for writing the templates follows @ericpascual's technique of getting the class init and a single getter/setter done, then updating the templates to autogen the rest. I did not find that very convoluted - but someone else might - to each his own.
5. Now that we have the -x flag for autogen (thks @wasabifan) it's easy to see what the binding provider has to write, and what can be autogened

One good point was made regarding contributors being overwhelmed by the autogen system and being reluctant to issue pull requests. I think that's a red herring - we had users submitting PRs completely unaware that there was an autogen system, and the binding maintainers were happy to get these contributions and update the templates and even spec.json to implement these suggestions.

We should update the ev3dev-lang (and possibly the individual binding README) files to include a note to not worry about autogen when making suggestions.

@EricPobot - we appreciate your work on this. If I could ask you to please submit a PR against ev3dev-lang-python that includes just the hand-made changes for ONE class in the binding - I would have a close look to see if it's something we can incorporate into spec.json and/or the templates.

By far the largest users of the library will want it to "just work" - very few will actually be capable or even want to suggest changes. And the more the language bindings follow spec.json the more that ev3dev can be used as a learning platform to contrast the importance of language-specific features such as first class functions, the difference between thinking of everything as a list (lisp) vs everything is a table (lua) vs everything is a cell (Forth). You get the picture...

[EricPobot]

@rhempel

If I could ask you to please submit a PR

I wish I could, but I've progressed on my alternative implementation, and I'm afraid more issues arose.

1. since I don't like modules getting bigger that 1k lines, I've subdivided core into core plus several thematic modules (sensors, motors, sound, display). Since this is a matter of personal taste and since contributors working with templates won't care about this (because not manipulating the generated sources), this could be difficult to manage at a language agnostic level
2. I've refactored a couple of classes, since the autogen mechanism tends to duplicate a lot of code. You'll argue that it does not matter since once again the involved code is not supposed to be manipulated. But I'm not so sure we can overlook this. Firstly, this produces bigger modules, which means consuming more resources at runtime. Secondly, we all know that the best documentation is the source code. Whatever is the amount of care and energy we could put in writing documentation, it will always be insufficient (not always up-to-date, points missing, explanations unclear or not understood the same way by everybody,...). The final resort being the source code, it has to be the most easier to read an analyse. Which is not really the case according to my criteria (cf the inflation of lines of code mentioned above).
3. documentation generation tools (Sphinx, Javadoc,...) use different markups. I've done a quite intensive job cleaning and making existing docstrings conform to Sphinx format, in order to produce something looking better. Since this introduces tags which are not understood by the other tools, we have a problem here. Using the intersection of all autodoc tools is not an option for me, since you'll get low quality results. I do not pretend that my docs are at the top, but if you generate them (fab doc will do the job) and have a look at them, you'll notice that they look not so bad. Using the same doc generator across all the languages is not an option neither, for several reasons. The first one is that Java-ists are used to Javadoc syntax, Python-ists to Sphinx, C/C++-ists to Doxygen,... and I doubt that people will be fan of using a foreign tool. The second one is that these tools heavily rely on introspection, which can be a problem (I don't think that Sphinx can do very much with Java code :)

I do agree with you WRT the fact that providing a uniform public API across languages is important, and that this is currently enforced by spec.json and friends. But we can also think it differently, and rely on the contributors' discipline. Even with my outlaw version, I did my best to stick to the current API, sometimes augmenting it with new methods (e.g. Sound.play_song) which are candidates for general availability anyway. Maintaining this uniformity even when writing a binding by hand is not that terrific, since there are good chances that most of the contributors (if not all) will work on a given binding only and not on several different ones.

Besides, it is not so simple to stick to identical signatures, since languages such as Python allow f.i. omitting arguments on call, providing default values. IMHO this is very important as a feature, since it avoids tedious calls with zillions of args set to the same value most of the time. Since as far as I know not all the targeted languages support this feature, how can we manage this in a uniform way ? Being able to simplify the job of the lib users by reducing the quantity of code they have to type is IMHO a must have for end users' happiness, which goes in the direction you cited (users want it to just work, but they also want it to work with the least possible investment from them, including not typing superfluous code).

As I said in a previous post, I'm afraid we would have to renounce to some key features specific to one or an other language for this. And I'm not sure that users working with the amputated language will like it very much. This is important even for confirmed developers. Being myself a senior SW guy (55 years old and more that 35 years now doing this ;), having coded in dozens of languages, I confess that it would be difficult for me to go back to C/C++ writing style now that I've discovered Python ease and power of expression for instance.

To make a long story short, I confess being a bit embarrassed at this point. On one hand I got addicted to ev3dev and to the Python binding, and have invested quite a significant amount of time these last days ( to check it just have a look at my alternative repo, the documentation in it, the demos, the enhancements and fixes,...). I do want to donate this to the community and would be proud to see my work used by other people. But on the other hand, I'm not that much motivated by investing an extra amount of energy and sleep for conforming to a working method I'm not really convinced by, notwithstanding its merits.

Any comment is welcomed ;)

[WasabiFan]

When I started developing the ev3dev-lang bindings with @fdetro around a year ago (or maybe more), the ev3dev system as a whole was changing fairly rapidly. Every month or so there would be a redesigned motor control paradigm or added properties to various objects. The changes that were being made were definitely improving ev3dev, but nonetheless keeping track of the changes and making sure to implement them was time-consuming and prone to errors.

At first, we were just manually writing getters and setters for each property. This worked, but after only two months or so we found ourselves discovering discrepancies between our code and the kernel. Sometimes we had missed a GitHub notification about a kernel commit which changed certain properties, and sometimes we had mis-typed a property name or replaced a dash with an underscore. On top of that, the time it took to write all the duplicated and monotonous code (which is required) was pretty insane in some cases and (at least for me) it became a significant chore. Nonetheless, I believed that the bindings were useful, so I kept with it. It became clear that we needed a better way to keep up with kernel changes, minimize possibility for human error, and remove the work of duplicating code.

In the end, we settled on the current system; it generated the monotonous bits of code automatically and the effort it took to update our code for a property change became trivially small -- just change a line of JSON and run a command. When we decide that we want to change an internal mechanism inside our library, instead of going through and updating hundreds of lines, we just have to change one or two lines and re-generate. When the kernel documentation changes, it's a simple matter of updating it in the spec and re-generating. If, in the future, we decide that we want to import extra metadata instead of just property docs, that's just as simple. And, because changes are so easy to make, a single person could maintain the whole ev3dev-lang repo if desired with minimally more effort.

As time has progressed, the kernel has stabilized. The rate of change has slowed, but it still does change fairly regularly. I think that the need to be able to rapidly update large chunks of our interfaces has decreased. Nonetheless, it's still there. The kernel changes, and will continue to change, for the foreseeable future (as long as ev3dev is in use, I expect) and that necessitates continued effort from binding maintainers to keep their libraries up-to-date.

Reading through the comments above, I think there is merit to some of your claims, when looking at it with a narrow field of view. Yes, it is more work to update a template than to update a single getter or setter. And yes, the extra step of designing with templating in mind is something that must be considered. But the time it takes to use an autogen system, whether it is making a binding from scratch or maintaining a preexisting one, pales in comparison to the time it takes to write the 1,000s of lines yourself.

As for your assertion that libraries are limited by the capabilities of the common API surface across languages, I think that stems from a mis-understanding of the autogen framework as it currently stands. The spec.json does not enforce a specific interface, nor does it prohibit extra functionality; it details the APIs as set forth by the kernel which we must interface with. It defines the interface that we have access to as programmers writing code to execute on top of ev3dev. So if you decided that, for example, your interface would be a shell script, and you would pass parameters in via environment variable, go ahead -- there's nothing stopping you. The autogen system simply replaces the menial task of re-writing and maintaining 1,000s of lines of repetitive code with the maintenance of tens of lines of templates. It brings the file system structure from the kernel into the domain of your library -- what you do with that control is up to you.

Obviously, for someone like @dlech, the task of keeping up with kernel changes is no issue; he has a view of ev3dev that makes it an easy task to make a change in an extra place when he updates the kernel. But we can't attempt to make him do all the work for ev3dev -- others of us must put in the effort to maintain our parts, to make sure that his great work can be utilized by people of any coding ability, whether they understand GObject introspection or are just starting out with learning Python.

Finally, the notion that contributors are scared away or barred from contributing is a real one; seeing comments that obviously have a special meaning without knowing what they do is troubling. But I think that the monolithic size of the code that we maintain is even more daunting than that. So yes, it can be scary; and we haven't done a very good job of explaining what it does to newcomers. But the simple solution makes it much more manageable for all of us, new contributors and code maintainers alike: "If you want to contribute, feel free! We'd love the help. Make the change as you see fit, in the first instance of the code that you see, and through the magic of autogen we will make that change for you in the hundreds of other places that it appears, without you having to lift a finger."

[rhempel]

Breaking up the API implementation into separate files is fine - and there's nothing in autogen that prevents it. The documentation point is a good one - I am now trying to figure out how to create the API docs for the Lua binding like we do today for Python - the Sphinx system integrates quite nicely with Python - other languages will be tricky - but we're all smart guys.

I'm 53 years old and have re-energized my love of learning new scripting languages with this project.

As some of you may know, I've been rewriting firmware for MINDSTORMS bricks since the RCX days, and I am really impressed by the work of so many dedicated contributors to this project. Thankfully, @dlech helped out a lot in the early days and has basically taken over the kernel side of things. That's good because he knows a lot more about it than I ever will.

[EricPobot]

Thanks @WasabiFan for your detailed feedback and explanation.

All this makes sense of course, and it could hardly be different since this has been designed by smart people and is used since long now. I do agree with the motivations and don't contest the benefits it had brought in the early ages of ev3dev.

But as you said, the situation is getting more stable now, even if not at stop at all. And this is my concern as you may have understood. When I have studied the Python templates, I could see there a mixture of templating markup intermixed with Python code. In addition when considering now a whole generated class, it is spread over several templates. All this does not make the implementation task easy when it comes to distribute the code you've validated over all the involved templates.

I started to experiment by retrofitting minor changes (they were only code formatting issues at that time) to educate myself. Even such trivial tasks turned to be tricky, but let's say it's normal since I was discovering.

Having read all the reactions, I am considering again having a look to back porting my hand written code in templates. But I confess being a bit perplex about how to achieve it and produce the same code as hand written. This is important for me : if it cannot generate something identical to the current version, due to some constraint of the process, I will not be happy with this.

However, something is still unclear for me. You mentioned the fact that autogen process makes it a breeze to keep bindings up-to-date with kernel changes for instance. Fine, this sounds nice. But how is it really possible if the changes involve modifying the logic ? It is not just a matter of updating the json specs, right ? How does this work ? Chances are that the templates will have to be modified, and this is the point which scratches me a bit. Modifying Python code with the help of good tools can be easy and fast, but modifying the templates 100% by hand since you can't expect any help from the IDE or editor is another story. I'm surely misunderstanding something here, but can't see what.

@rhempel Good to know you better ;) I'm happy to see that I'm not the only old adult being still playing with LEGOs :D

OK, I'll give it another chance, trying to adapt my hand coded stuff to autogen. I hope not being defeated by the beast once again.

[rhempel]

Sometimes it helps to tackle smaller parts of the problem - even if you submit a comment here that proposes a change in the API function formatting, we can try to change the templates to get closer to what you're looking for,

I see you are using mixins - which are helpful if the language supports it. Maybe we can consider adding to spec.json some kind of generic method of specifying which properties or methods can be considered for mixin support if supported by the language

[EricPobot]

I spent some time again studying the tool chain, starting with spec.json and here is a first question.

Since this file is shared for all the targeted languages, it means that the class organisation for instance will be identical for all of them. It happens that I made some changes at this level in my Python version, for factoring things in order to reduce the total amount of LOCs. The way I did it may be inadequate for other languages (f.i. introducing mixins). And perhaps the way I've restructured the code, including some renaming of intermediate internal classes, may not be at the taste of everybody (and vice versa).

More important, this kind of architecture change (class tree modification) implies that every binding (its templates and the not auto-generated parts of the sources) must be updated to match. Chances are that it will not be welcomed by the maintainers of the other languages.

How is this kind of situation supposed to be managed ?

[rhempel]

The functions that are, in fact, common to most motor types can be handled as mixins, or they can be associated with a superclass - and spec.json does not really handle this well right now. Actually, it kind of does if we specify a generic motor class that has the common mixins and then derive the specific classes from the generic motor class. Or we could consider having a section in a class specification that provides hints for properties so that mixins are easier to implement. Let me see what happens with the Lua binding I'm working on. On the other hand, maybe worrying about LOC is something we don't need to do right now...

[EricPobot]

On the other hand, maybe worrying about LOC is something we don't need to do right now..

This is not the LOC per se which is a problem (it can become one if the size of the modules gets out of control, but as you said we can look at this later, when the problem will arise) but the readability of the resulting code. Even if the average end user will not go into it (are we sure of this ?) the maintainer(s) will.

If I took some time to rework such aspects, it was because I've had some difficulties at the beginning to assimilate the original code, because of the size, the repeated definitions which were good candidate to be pulled up into super classes,...

[rhempel]

To some extent, this can be mitigated by breaking up the source into smaller files, one per major class or whatever is reasonable. That makes sense - right now core.py has everything - we could have leds.py and dc-motor.py etc...

[EricPobot]

The breakdown you propose is already done in my version (see leds.py, motors.py,...).

But I don't understand how it would solve the problem of inheritance tree differences between bindings.

[rhempel]

Well, that where the magic of compromise comes int -while we may not be able to create an optimal inheritance tree for each language binding - the goal should (I think) be to create a "good enough" tree for a large variety of languages.

For now, I think we'll wait for a few more bindings to be created before optimizing the tree.

[EricPobot]

You confirm what I had in mind. We have to find some kind of common denominator, and this implies renouncing to some possibilities.

For the moment, I think I'll continue to maintain my version by hand, and invest the time I could spare in extending the binding (I'm currently working on concepts coming from LeJOS).

I'll be able then to assess on a real base what is the real cost of keeping it up-to-date with the kernel evolutions, knowing that, as you said before, such evolutions will tend to be less frequent as the architecture stabilizes.

I'll just need to be aware of these evolutions (I could note the name changes of some of the pseudo files, but I can't apply them since it will not work with the kernel I work with on the brick). What is the best way to be notified of them efficiently ?

What so you think about all this ?

[dlech]

What is the best way to be notified of them efficiently ?

I do my best to document important changes in both the announcements at http://www.ev3dev.org/news/ (you can subscribe via rss) and the kernel changelogs at https://github.com/ev3dev/ev3dev-kpkg/ev3dev-*/changelog (you can watch this repository on GitHub).

[EricPobot]

Thanks @dlech for the pointers. I'll subscribe to theses sources.

[dwalton76]

Am scrubing open issues tonight....anything else to be done with this one or can we close?

[EricPobot]

Hi Ralph

I unfortunately had to put my ev3dev activities aside for some time and have not worked significantly on them since a while.

From my point of view you can close the thread since there are good chances that the current version of ev3dev makes some of the points no more relevant.

I'll be back in ev3dev some day for sure, but I can't say when for the moment.

Best regards - Eric

-------- Original Message -------- From:Daniel Walton notifications@github.com Sent:Wed, 14 Sep 2016 05:17:37 +0200 To:rhempel/ev3dev-lang-python ev3dev-lang-python@noreply.github.com Cc:Eric PASCUAL eric.pascual@aliceadsl.fr,Mention mention@noreply.github.com Subject:Re: [rhempel/ev3dev-lang-python] alternative implementation proposal (#91)

Am scrubing open issues tonight....anything else to be done with this one or can we close?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/rhempel/ev3dev-lang-python","title":"rhempel/ev3dev-lang-python","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/rhempel/ev3dev-lang-python"}},"updates":{"snippets":[{"icon":"PERSON","message":"@dwalton76 in #91: Am scrubing open issues tonight....anything else to be done with this one or can we close?"}],"action":{"name":"View Issue","url":"https://github.com/rhempel/ev3dev-lang-python/issues/91#issuecomment-246894533"}}}