Hello,
I have forked original bonescript and created OctalBoneScript: https://www.npmjs.com/package/octalbonescript I have worked on it in last 1 year and improved it on many fronts. As a result of it, it has many under the hood stability and feature changes compared to original bonescript. You can see from npmjs stats that the library is quite successful and popular among community.
I am now planning to release v1.0.0 of OctalBoneScript. I have already made the announcement and invited community for feature and bug reports here: https://twitter.com/adityapatadia/status/562875253597429761
v1.0.0 aims to implement all modes of universal cape and make the library stable and robust.
I would love to work on the same this summer through GSoC. Let me know your views.
So you’re distributing your fork under a different name? Are you planning on pushing your changes back to Jason’s Bonescript repo? It seems to me that it would make more sense to just have a single Bonescript, rather than having a separate version than the one that ships with BeagleBones.
That said, working on userspace libraries is certainly one of the possible areas for GSoC. Can you provide an outline of what you’d like to implement and improve upon? i.e. what do you mean by “stable and robust”?
As far as merging is concerned, there is entire discussion here: https://github.com/theoctal/octalbonescript/issues/14 I would happily merge if community wishes to embrace OBS in current form but that task does not seem easy.
For features, I have added a few improvements planned here. https://github.com/theoctal/octalbonescript/milestones/v1.0.0
I am going to add more as I get feature requests from community and as I find myself some areas to improve upon.
So far, there were changes like moving to universal cape and moving away from loading individual pins to CapeManager were done. Bonescript stable version was launched in Jan 2014 and as any user must have experienced, it is not as stable as a production ready library should be.
Many users using OBS will know that the library is very stable with fewer bugs. Also, the bugs are fixed within 2 days of report by user. Carefully analysing github repo and history will reveal the amount of efforts put by me to improve it. I personally feel that if OctalBoneScript is developed this way, the community can get a useful and feature rich library.
OK, I’ve caught up on the Github issue threads.
The problem is that the majority of official BeagleBoard.org documentation and example code depends on Bonescript, so they can’t just abandon their version and start distributing your version on the bbb, as there would be no guarantee that their documentation and examples wouldn’t suddenly become incorrect and broken as you push changes.
In my opinion the best course of action would be to get this merged into the official Bonescript repo before (or perhaps during) GSoC, and then continue to develop and improve from there, making sure that changes are submitted and pulled in discrete steps, and getting involved in the documentation and examples to make sure everything keeps working.
As far as merging goes, I don’t really see the problem with cherry-picking and submitting additions separately. Sure, it’ll be a bit annoying, but it should be completely doable.
I can understand that majority of documentation depends on Bonescript. That is the reason we have made OBS drop-in replacement for Bonescript. It is fully API compatible with Bonescript as of now.
That said, I am planning to introduce BC break in v1.0.0. The biggest reason is that callbacks have a way to handle error in nodejs and first argument passed is error. That is not default behaviour in bonescript and v1.0.0 of OBS will change it. I would love to update bonescript documentation if I am allowed to, if not rest assured, OBS will have its own documentation.
Basically, the changes in OBS are such that it is somewhat not aligned with design philosophy of current maintainer of Bonescript. That’s the reason, merging efforts in past failed. We believe in fast development of library and users generally don’t care about what changes we make under the hood. Arriving at consensus at trifling issues is what hampers pace of development of the library. Still the earlier girhub issue I have pointed had lot of discussion on the same. The person who opened the issue is now fully contributing to OBS and not to Bonescript.
The point is that rather than reviving year old library, let’s switch to a better one. OBS or Bonescript, let’s give community a useful library with “Just Works”.
Any updates on this one? Is anyone ready to offer mentorship for the same?
I can understand that majority of documentation depends on Bonescript. That is the reason we have made OBS drop-in replacement for Bonescript. It is fully API compatible with Bonescript as of now.
That said, I am planning to introduce BC break in v1.0.0. The biggest reason is that callbacks have a way to handle error in nodejs and first argument passed is error. That is not default behaviour in bonescript and v1.0.0 of OBS will change it. I would love to update bonescript documentation if I am allowed to, if not rest assured, OBS will have its own documentation.
Challenge I keep having in moving quickly is continuing to support the synchronous calls. Does OBS support synchronous calls?