Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 02 2018 21:22

    soundanalogous on v0.6.2

    (compare)

  • Jun 02 2018 21:21

    soundanalogous on master

    update year in license 0.6.2 (compare)

  • Jun 02 2018 21:14

    soundanalogous on master

    Change setup() builder to avoid… Merge pull request #22 from eth… (compare)

  • Jun 02 2018 21:14
    soundanalogous closed #22
  • May 29 2018 11:02
    ethanjli edited #22
  • May 29 2018 10:51
    ethanjli opened #22
  • Feb 03 2018 23:39
    soundanalogous reopened #21
  • Feb 03 2018 23:38
    soundanalogous commented #21
  • Feb 03 2018 22:05
    verrol commented #21
  • Feb 03 2018 22:05
    verrol closed #21
  • Feb 03 2018 22:02
    verrol opened #21
  • Jan 08 2018 05:01

    soundanalogous on master

    0.6.1 (compare)

  • Jan 08 2018 04:58

    soundanalogous on v0.6.1

    0.6.1 (compare)

  • Jan 08 2018 04:56

    soundanalogous on rc-switch

    (compare)

  • Jan 08 2018 04:56

    soundanalogous on dep-includes

    (compare)

  • Jan 08 2018 04:56

    soundanalogous on master

    separate fields for dependency … fix jshint errors Merge pull request #20 from fir… (compare)

  • Jan 08 2018 04:56
    soundanalogous closed #20
  • Jan 08 2018 04:55
    soundanalogous synchronize #20
  • Jan 08 2018 04:55

    soundanalogous on dep-includes

    fix jshint errors (compare)

  • Jan 08 2018 04:52
    soundanalogous synchronize #20
Jeff Hoefs
@soundanalogous
I'm currently focusing on the builder.js module. This is the core functionality that could be used on the server side in a web application or within a cli utility client side. If anyone has advice on improving builder.js and the overall organization of the project (I don't have a ton of nodejs experience) that would be greatly appreciated. Currently I have a demo.js file that uses the builder module to generate an Arduino .ino file. Perhaps I should move demo.js to an examples directory and provide a separate package.json file for it (issue I currently have is rimraf is declared in package.json but it is not a dependency of builder.js, it's only needed for the demo).
I'm also at a point where I can start adding tests for the builder functionality. I'm familiar with mocha/chai/sinon so I'll likely use those.
Jeff Hoefs
@soundanalogous
One other thing to figure out is how to structure what is currently lib/features.js. This will be a data structure describing all of the available Firmata features. I need to come up with a way that makes it easy for contributors to add new features. With the current features.js file developers could simply submit a pull request to add a new feature's data, but perhaps there is a better approach. The feature structure will also be used to build the UI for the web application (or the UI for a cli application). Additional data such as links to Firmata device libraries (new) and 3rd party dependencies (ie Adafruit libraries, etc) need to be added as well.
ajfisher
@ajfisher
This looks ace Jeff. Ideally submissions would be non-core and could be included in - maybe with something as simple as a firmata add github.com/ajfisher/somelib
and then it goes and grabs that - and we just have a standard for the way those are added in.
Of course, then discovery becomes an issue...
Jacob Rosenthal
@jacobrosenthal
Another interesting possibility is using eeprom to do configuration at runtime
not a replacement but in addition