On Mon, May 16, 2016 at 5:59 PM William Hermans <[email protected]> wrote:
> *IF Bonescript was updated in sync with the ongoing kernel changes you >> wouldn't need to modify your code as you do with Nodejs fileSystem object >> code as the file system interface to the GPIO changes, Bonescript would >> automatically handle it. Unfortunately this promise is unfulfilled. * >> > > This is false. If the file system path changes both would need a rewrite. > Otherwise using the Nodejs filesystem object would not need to be > refactored, ever. I can't speak for bonescript, because I have not cared to > look and see what the underlying structure actually *is*. Because using the > fileSystem object is so easy . . . > BoneScript is just a library that provides some abstractions for the Linux sysfs file system interface. It is indeed the promise and I am working on fulfilling it. > > Also, when using a BBB as a production system it would be silly to do any > major updates that could break compatibility with the currently working. So > as far as that goes, at least for me is a moot point. > But many people are just exploring and prototyping. For them, they'd like both reliable instructions as well as being able to take advantage of new examples to give them things to explore. It is worthwhile to try to maintain some layer of compatibility while interfaces underneath change to explore new features. I just haven't had the bandwidth to keep up with all the kernel changes. As more code lands more stably upstream (as it has over the last year), it should be easier for me to catch up. Wally.... thank you very much for your feedback as it is very helpful for me and does save me a notable amount of time as most of the fixes can be pretty minor. Please don't be overly discouraged. > > On Mon, May 16, 2016 at 2:15 PM, Wally Bkg <[email protected]> wrote: > >> On Monday, May 16, 2016 at 2:39:43 PM UTC-5, William Hermans wrote: >> >>> Quite honestly, and with all due respect to Jason. I'm not quite sure of >>> the need for bonescript period. Everything it does can be abstracted using >>> Nodejs + the Nodejs fileSystem object. But I've been saying this for years, >>> and some of you still haven't caught on yet . . . >>> >> >> IF Bonescript was updated in sync with the ongoing kernel changes you >> wouldn't need to modify your code as you do with Nodejs fileSystem object >> code as the file system interface to the GPIO changes, Bonescript would >> automatically handle it. Unfortunately this promise is unfulfilled. >> >> IMHO there is too much of a good thing with kernel development -- do we >> really need four kernel versions under active development with seemingly no >> consideration of how changes break existing code and/or documentation? It >> must be a nightmare for people actually selling capes. >> >> In C a limited set of #define to deal with the path changes and open() >> read() write() close() calls is not too bad, and reasonably clear to >> understand now that newer kernels have made the export and unexport stuff >> unnecessary, I assume something similar works for nodejs. Things like >> universal_io and config-pin are IMHO a giant step forward and reason enough >> alone to move to the 4.1.x kernel series. >> >> Bonescript as I understand it, is just an extension (library?) for nodejs >> to handle the interface to BBX hardware -- I'm not much beyond the "cut and >> paste" playing around stage with nodejs, I find it powerful >> yet infuriating. Much like Python, if there were an openCV interface to >> nodeJS I think I'd like it better than Python for getting an openCV project >> started, but there are so many good openCV tutorials and code samples on >> the Web its a pretty compelling way to get started with openCV. >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beagleboard/9e6a4d5d-e78f-4e1f-ac49-bc1f2d0435b3%40googlegroups.com >> <https://groups.google.com/d/msgid/beagleboard/9e6a4d5d-e78f-4e1f-ac49-bc1f2d0435b3%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/CALHSORqh4CdSvOCO%2BVUewHBD2pS9%3D0qEL27Xu6NGyY8KGs1RYQ%40mail.gmail.com > <https://groups.google.com/d/msgid/beagleboard/CALHSORqh4CdSvOCO%2BVUewHBD2pS9%3D0qEL27Xu6NGyY8KGs1RYQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPn8PvGc0W383KrtoR2YmSvVqFTphgLsNGZp7-3YmjrGHw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
