> > *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 . . . 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. 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. For more options, visit https://groups.google.com/d/optout.
