Dominick Pham

You actually just need to export the header once. In the ready callback, run dq.set(0, function(){ dq.set(1, function(){ cb(dq.value); }); }); I'm on my iPad so it's a bit hard...

@vicary the bottleneck is probably the fact that we're using node's filesystem to write header values. I bet if we wrote a node c++ module that wraps the wiringPi library,...

@makeros thanks for sharing, I'll consider using gpioMock for this. Looks like that library can also resolve #40. Also related to #51.

Hmm the gpio-admin tool looks pretty interesting. I've been meaning to add pullup/pulldown support for a while. I'll probably take a look sometime next week.

Hi there. This project is no longer maintained and the pullup/pulldown support was never implemented.

I think we should hold off merging this until we figure out a consistent way to define support for various boards as well as features outside of the standard read/write...

You're referring to the voltage cycle example? Did both pins have trouble unexporting or was there only an issue with one? Also, are you using [RPi.GPIO](https://pypi.python.org/pypi/RPi.GPIO)? I can run some...

Regardless of the API change, the internal function to close/unexport is the same. I'll write some tests for this - we can validate the success of the close/unexport call by...

In this library, unexport (and now close) exists both in the module exports (which expects a pin number) and as an instance method (without pin number). What I meant was...

Sorry, poor communication on my part. That's actually how it works in the _v1_ branch to adhere to the Samsung IoTjs API (except for _write_ method call which is not...