Roadmap for PiPiper

[elmatou]

@jwhitehorn, @zsyed91,
I'm willing to bring some enhancement to the library, I just need to know if we are ok with it !

• Better Licence : use standart licence (was a BSD?), add LICENCE file, add licence reference for the bcm2835 lib
• Add support for PWM
• Spec without a stub for Pin,I2C, ...
• Add support for multiple drivers (kernel module, bcm2835 lib, WiringPi, ...)
• Spec the drivers (how ?!)
• Non-root usage.
• ...

[jwhitehorn]

I'd prefer to stay with a BSD license.

[zsyed91]

Looks like a good plan to me! @elmatou I will review your PWM pr, sorry I have been busy but will get to it today.

I think it would be great if we can remove the stubs drivers somehow.

[elmatou]

@jwhitehorn BSD is a very good choice. I'll add a LICENCE file

[elmatou]

Here are my thoughts for you to comment on how could be implemented the multi drivers thing.

# Platform handle the loaded drivers and the way to load new drivers.
class Platform
  autoload StubDriver, 'blabla.rb'
  autoload SysFs, 'blabla.rb'
  autoload Bcm2835, 'blabla.rb'
  ...

  @@drivers_pool = {}

  def self.link_with_driver(driver_klass)
    unless @@drivers_pool[driver_klass].instance_of? driver_klass
      @@drivers_pool << driver_klass.new
    end
    @@drivers_pool[driver_klass]
  end

  def self.unlink_driver(driver_klass)
    ...
  end

  def self.empty_pool
    ...
  end
end

# StubDriver used to define the standart API, and to stub for testing
class StubDriver
  def initialize
    at_exit { close }
    # or define a finalizer : ObjectSpace.define_finalizer(object, proc)
  end

  def close
    # unexport pin
    # close librairy
    # ...
  end

  def each_public_method(*args)
    # kept empty for test matter
  end
end

# each driver could be in a separate gem (or just not required from start)
class SysFs < StubDriver

  def initialize
    @exported_pins = []
    super
  end

  def close
    @exported_pins.each {|p| unexport_pins(p) }
  end

  # Standart public methods conform to the 'API'
  # Methods prefix with the object they are used for
  def pin_set_...(gpio_number, value)
  end

  def pin_read(gpio_number)
  end

  def spi_poll
  end
  ...

  # private methods are not intended to be called from outside the driver.
private
  def export
  end

end

# Other Drivers could be bcm2835, gordon's wiringPi lib, platform specific lib for beaglebone, ordroid.... 


class Pin
  def initialize(options)
    # driver can be choosed at initialization time. it could be different for each object (in order to gain controle of specific behaviour)
    @options[:driver] = Platform.link__with_driver options[:driver]

    # we vallidate the options by setting them through the driver. Settings cannot be changed later.
    # the driver raise exceptions for invalid arguments
  end

  def close
    # Optional : close procedure/release if we cannot wait for the programm to end or the GC to collect
  end

...

private
# Optional : a way to access the driver directly for driver specific behaviour
  def method_missing(method, *args, &block)
    @options[:driver].send(method, @options[:pin], *args, &block)
  end
end

class Spi
# Same here
private
  def method_missing(method, *args, &block)
    @options[:driver].send(method, @options[:pin], *args, &block)
  end
end

[zsyed91]

I like the idea of having separate driver gems. I think along these lines we could even do the following:

class Driver
  def close
    raise ArgumentError , 'Not Implemented in Driver class -> implement in child class'
  end
end

class StubDriver < Driver
end

class SysFs < Driver
end

Then we can have a basic Driver class that we would ducktype under and have the actual drivers implement the public api methods.

[zsyed91]

@elmatou I have created a placeholder repo under a new organization PiPiper for the bcm2835 library. We can start creating a new gem there. And eventually same with the other drivers.

https://github.com/PiPiper/bcm2835

[elmatou]

Funny, it was precisely the structure of my first draft. Then I asked me, why do we need StubDriver ?
The specs in PR #57 are unit tests, the do not need a driver t mock/mimic behaviour, only some thing to receive de methods call. That's why I proposed a Driver object with methods declarations whithout any code in it. Any how, I think we are in the write way.

[elmatou]

the placeholder, nice !

I see, for me to work on :

• pi_piper
• pi_piper-sysfs
• pi_piper-bcm2835
• pi_piper-wiringpi
  then will be for contributors
• pi_piper-beagle
• pi_piper-cubie
• pi_piper-banana
• pi_piper-.....

[zsyed91]

Yeah I think we can use the StubDriver to make sure method calls are sent and received properly instead of actually testing the code itself. If we use a separate gem for each driver (or really even if we don't) we can stub the driver and unit test the code that goes in the driver separately in that repo to unit test the driver.

[zsyed91]

Yes we can create more placeholders once we get this moving. I am going to go ahead and create a branch off of develop that we can push our structure changes to in the meantime. That way we can still continue to release the gem as needed while we do this work in parallel.

[zsyed91]

Alright, I think we can start pushing any structure changes for this to this branch: gem_structure_changes

https://github.com/jwhitehorn/pi_piper/tree/gem_structure_changes

[zsyed91]

@elmatou I copied over the existing bcm2835 code here https://github.com/PiPiper/bcm2835/tree/dev
I think we can probably add your tests in the spec directory there, and begin to make improvements. And as for your current PR, can you close it and reopen it to gem_structure_changes? That way we can be a little more aggressive in our changes without worrying about affecting near term releases.

[elmatou]

sh.t I was doing it offline... nevermind I'll work on your structure. let's work on gem_structure_changes
branch (or something badass like, reborn or reboot !!)

[elmatou]

I'm currently trying to implement the external driver concept for PiPiper, but it leads me to put arguments validation in the driver, because every drivers do not accept the same set.
eg : sysfs only support rising, falling, both, as bcm2835 offer async trigger and more

but I'm not very comfortable with it, as it will probably not be backward compatible.... any thoughts ?

[zsyed91]

I think having driver specific validations are alright. As you said, if sysfs only supports :rising, :falling, :both but another driver supports only :rising for example then it should throw a validation error. This is the plus side to our gem approach for the drivers since they can all be stand-alone.

I think we don't have to worry about backward compatibility because we can release those changes under 3.0. If people need to keep the old version then that is fine, they will just have to change their gemfile to ~> 2.0 or similar.

We can even create a deprecation warning and auto-detect which driver they want by checking the arguments passed in. And then eventually remove it. RSpec did this approach when changing from monkey patching the .should to expect. The 3.0 release works with .should but spits out a legacy warning. And I believe the 4.0 release will remove it entirely.