| Message ID | 20230614035426.15097-1-warthog618@gmail.com |
|---|---|
| Headers | show |
| Series | dedicated examples | expand |
On Wed, Jun 14, 2023 at 5:54 AM Kent Gibson <warthog618@gmail.com> wrote: > > This series forms the basis of a proposal to rework the libgpiod > examples. > > IMHO, the examples have a number of issues including: > - no C examples other than the tools - which have become too complicated > to be fit for that purpose. > - bindings examples focus on simplifications of the tools rather than > demonstrating typical use cases. > - being more complex than necessary to demonstrate a particular use case. > - naming that does not help new users identify the example that > demonstrates a particular use case. > > To address these issues I propose adding a set of dedicated examples, > each of which demonstrates one primary use case with as little > additional fat as possible. Each example should be named after the use > case it demonstrates. Each examples should be implemented for all > supported languages, to provide examples for users considering > language choice and for developers to compare the APIs and identify > areas for improvement. > > The examples are explicitly intended to answer "how do I use libgpiod to > do xxx" questions, with as few distractions as possible. > > The examples may demonstrate ancillary features, as long as that is > relevant to the primary use case. e.g. the watch_line_value examples > set the line bias and debounce. > > The examples should hard code input parameters, not pull them from the > command line or environment, as that is distracting and frequently more > complicated than the example itself. > > The examples should be standalone - they should not share code. Large > chunks of shared code are an indicator that libgpiod probably needs to > provide additional functionality to simplify use cases. > > The examples are not intended to be distributed in binary form, but > could be incorporated into the documentation. > > The set of examples provided is a starter set that answer the following > questions: > - how do you get the value of a line? > - how do you set the value of a line? > - how do you watch for edge events on a line? > - how do you watch for edge events asynchronously (e.g. using poll())? > > I didn't add the latter in Rust as that should be done using one of the > many available async reactors and I didn't want to pick one or pull in > any dependencies. > > I expect that this proposal may be contraversial, and that is one of the > reasons I've kept the starter set small. > > Cheers, > Kent. > > Kent Gibson (4): > core: examples: add dedicated examples > bindings: cxx: examples: add dedicated examples > bindings: python: examples: add dedicated examples > bindings: rust: examples: add dedicated examples > > Makefile.am | 6 + > bindings/cxx/examples/.gitignore | 4 + > bindings/cxx/examples/Makefile.am | 14 +- > .../cxx/examples/async_watch_line_value.cpp | 78 ++++++++++ > bindings/cxx/examples/get_line_value.cpp | 29 ++++ > bindings/cxx/examples/toggle_line_value.cpp | 45 ++++++ > bindings/cxx/examples/watch_line_value.cpp | 62 ++++++++ > .../python/examples/async_watch_line_value.py | 47 ++++++ > bindings/python/examples/get_line_value.py | 26 ++++ > bindings/python/examples/toggle_line_value.py | 47 ++++++ > bindings/python/examples/watch_line_value.py | 42 ++++++ > .../rust/libgpiod/examples/get_line_value.rs | 28 ++++ > .../libgpiod/examples/toggle_line_value.rs | 43 ++++++ > .../libgpiod/examples/watch_line_value.rs | 50 +++++++ > configure.ac | 1 + > examples/.gitignore | 7 + > examples/Makefile.am | 17 +++ > examples/async_watch_line_value.c | 136 ++++++++++++++++++ > examples/get_line_value.c | 97 +++++++++++++ > examples/toggle_line_value.c | 106 ++++++++++++++ > examples/watch_line_value.c | 127 ++++++++++++++++ > 21 files changed, 1011 insertions(+), 1 deletion(-) > create mode 100644 bindings/cxx/examples/async_watch_line_value.cpp > create mode 100644 bindings/cxx/examples/get_line_value.cpp > create mode 100644 bindings/cxx/examples/toggle_line_value.cpp > create mode 100644 bindings/cxx/examples/watch_line_value.cpp > create mode 100755 bindings/python/examples/async_watch_line_value.py > create mode 100755 bindings/python/examples/get_line_value.py > create mode 100755 bindings/python/examples/toggle_line_value.py > create mode 100755 bindings/python/examples/watch_line_value.py > create mode 100644 bindings/rust/libgpiod/examples/get_line_value.rs > create mode 100644 bindings/rust/libgpiod/examples/toggle_line_value.rs > create mode 100644 bindings/rust/libgpiod/examples/watch_line_value.rs > create mode 100644 examples/.gitignore > create mode 100644 examples/Makefile.am > create mode 100644 examples/async_watch_line_value.c > create mode 100644 examples/get_line_value.c > create mode 100644 examples/toggle_line_value.c > create mode 100644 examples/watch_line_value.c > > -- > 2.40.1 > Great idea! I applied patches 1-3 with some tweaks (coding style, C++ comments, statify functions, put local functions into anonymous namespaces for C++, apply black to python code etc. etc.). You can respin the rust patch separately. Thanks Bart
On Wed, Jun 14, 2023 at 03:03:51PM +0200, Bartosz Golaszewski wrote: > > > > Great idea! I applied patches 1-3 with some tweaks (coding style, C++ > comments, statify functions, put local functions into anonymous > namespaces for C++, apply black to python code etc. etc.). > Ok. Would've been nice to get review comments before having changes pulled straight in, but whatever. Requiring C style comments in C++ is just weird. > You can respin the rust patch separately. > And what would you like respun there? Cheers, Kent.
On Wed, Jun 14, 2023 at 3:21 PM Kent Gibson <warthog618@gmail.com> wrote: > > On Wed, Jun 14, 2023 at 03:03:51PM +0200, Bartosz Golaszewski wrote: > > > > > > > Great idea! I applied patches 1-3 with some tweaks (coding style, C++ > > comments, statify functions, put local functions into anonymous > > namespaces for C++, apply black to python code etc. etc.). > > > > Ok. Would've been nice to get review comments before having changes > pulled straight in, but whatever. > No functional changes. I wanted to avoid bikeshedding over coding style etc. > Requiring C style comments in C++ is just weird. > > > You can respin the rust patch separately. > > > > And what would you like respun there? > I saw comments from Erik and though you'd need a v2 but as it's mostly a matter of taste, I'll apply it as is. Bart > Cheers, > Kent.
On Wed, Jun 14, 2023 at 03:26:54PM +0200, Bartosz Golaszewski wrote: > On Wed, Jun 14, 2023 at 3:21 PM Kent Gibson <warthog618@gmail.com> wrote: > > > > On Wed, Jun 14, 2023 at 03:03:51PM +0200, Bartosz Golaszewski wrote: > > > > > > > > > > Great idea! I applied patches 1-3 with some tweaks (coding style, C++ > > > comments, statify functions, put local functions into anonymous > > > namespaces for C++, apply black to python code etc. etc.). > > > Any opinions on where to go next? Other use cases to add - e.g. multi-line versions? Convert the tool examples to use case examples? Or do you still want to distribute the binaries for those? Any functionality to add to libgpiod? Cheers, Kent.
On Wed, Jun 14, 2023 at 3:57 PM Kent Gibson <warthog618@gmail.com> wrote: > > On Wed, Jun 14, 2023 at 03:26:54PM +0200, Bartosz Golaszewski wrote: > > On Wed, Jun 14, 2023 at 3:21 PM Kent Gibson <warthog618@gmail.com> wrote: > > > > > > On Wed, Jun 14, 2023 at 03:03:51PM +0200, Bartosz Golaszewski wrote: > > > > > > > > > > > > > Great idea! I applied patches 1-3 with some tweaks (coding style, C++ > > > > comments, statify functions, put local functions into anonymous > > > > namespaces for C++, apply black to python code etc. etc.). > > > > > > > Any opinions on where to go next? > Other use cases to add - e.g. multi-line versions? Sure, I don't see why not. > Convert the tool examples to use case examples? Or do you still want > to distribute the binaries for those? No, the examples are built but not installed. And yes, if you have the time and will to convert them to something more useful, please do! > Any functionality to add to libgpiod? > I don't think so at the moment. Do you see anything obvious? I know, we spoke about putting the line resolver into libgpiod but I'm not sure we really want it. At least in the core library anyway. The GLib layer on top of libgpiod is a place that would be a good target for such a functionality IMO. Other than that, I think libgpiod now has everything it needs to cover all use-cases for the uAPI. Bart > Cheers, > Kent.
On Wed, Jun 14, 2023 at 05:11:32PM +0200, Bartosz Golaszewski wrote: > On Wed, Jun 14, 2023 at 3:57 PM Kent Gibson <warthog618@gmail.com> wrote: > > > > Any functionality to add to libgpiod? > > > > I don't think so at the moment. Do you see anything obvious? I know, > we spoke about putting the line resolver into libgpiod but I'm not > sure we really want it. At least in the core library anyway. The GLib > layer on top of libgpiod is a place that would be a good target for > such a functionality IMO. > Yeah, making the line resolver generally available is a can of worms. Not prepared to take that one on at the moment. I'm reasonably content to leave that to the user - as long as they can readily iterate over the chips and lines themselves. Maybe provide an iterator for all the lines in the system available to the user? > Other than that, I think libgpiod now has everything it needs to cover > all use-cases for the uAPI. > The point isn't that coverage is missing, it is to find ways to make common tasks simpler. The ones that spring to mind so far are: - C: requesting a single line as output - C: requesting a single line as input - providing a toggle function for line_value, as it is an enum which is a bit awkward. - the chip iterator in the python tools helpers.py - streaming operators for the enums where they are not automatically provided The C ones are specifically for simple sysfs-like equivalence, as telling users they need to replace a single write to a file with ~100 lines of C is really hard to sell. The config options would be as minimal as possible. I was going to suggest the user could always reconfigure the line later if they need extra features, but there is no function to return the existing line config :-(. Cheers, Kent.
On Wed, Jun 14, 2023 at 6:00 PM Kent Gibson <warthog618@gmail.com> wrote: > > On Wed, Jun 14, 2023 at 05:11:32PM +0200, Bartosz Golaszewski wrote: > > On Wed, Jun 14, 2023 at 3:57 PM Kent Gibson <warthog618@gmail.com> wrote: > > > > > > Any functionality to add to libgpiod? > > > > > > > I don't think so at the moment. Do you see anything obvious? I know, > > we spoke about putting the line resolver into libgpiod but I'm not > > sure we really want it. At least in the core library anyway. The GLib > > layer on top of libgpiod is a place that would be a good target for > > such a functionality IMO. > > > > Yeah, making the line resolver generally available is a can of worms. > Not prepared to take that one on at the moment. > I'm reasonably content to leave that to the user - as long as they can > readily iterate over the chips and lines themselves. > Maybe provide an iterator for all the lines in the system > available to the user? > > > Other than that, I think libgpiod now has everything it needs to cover > > all use-cases for the uAPI. > > > > The point isn't that coverage is missing, it is to find ways to make > common tasks simpler. > > The ones that spring to mind so far are: > - C: requesting a single line as output > - C: requesting a single line as input > - providing a toggle function for line_value, as it is an enum which is > a bit awkward. > - the chip iterator in the python tools helpers.py > - streaming operators for the enums where they are not automatically > provided > > > The C ones are specifically for simple sysfs-like equivalence, as telling > users they need to replace a single write to a file with ~100 lines of C > is really hard to sell. You don't really need 100 LOC for a trivial request in C (it's a bit over-dramatic :) ) but my thinking is: whether it's 5 lines or 10 or 100 - it doesn't change the fact that it is a fundamental change from sysfs in that you need to write the code, compile it, link it against the right libraries etc. etc. It will be so much more work no matter how much you simplify the API and that is already enough to scare away a lot of folks used to just writing to a bunch of files. This is why I'm proposing the DBus API as a way of replacing several features of sysfs that are so beloved by users: central authority over GPIOs, easy to use from shell scripts (just replace "echo 223 > export; echo output > 223/direction" etc. with "gdbus call --system --dest io.gpiod1 --object-path /io/gpiod1/gpiochip2 --method io.gpiod1.Chip.RequestLines <args>" which is just a tiny bit more verbose but achieves the same goal and exposes all uAPI v2 features) and only requires including the dbus daemon in your system which would be packaged by most distros shipping libgpiod eventually. DBus has the advantage of being usable from any language you fancy and still being relatively fast. In other words, I'm thinking that packing a lot of "helper" features into libgpiod will only lead to feature creep but not achieve the goal of pulling people away from sysfs. Bart > The config options would be as minimal as possible. > I was going to suggest the user could always reconfigure the line later > if they need extra features, but there is no function to return the > existing line config :-(. > > Cheers, > Kent.
On Thu, Jun 15, 2023 at 05:16:04PM +0200, Bartosz Golaszewski wrote: > On Wed, Jun 14, 2023 at 6:00 PM Kent Gibson <warthog618@gmail.com> wrote: > > > > The C ones are specifically for simple sysfs-like equivalence, as telling > > users they need to replace a single write to a file with ~100 lines of C > > is really hard to sell. > > You don't really need 100 LOC for a trivial request in C (it's a bit > over-dramatic :) ) but my thinking is: whether it's 5 lines or 10 or > 100 - it doesn't change the fact that it is a fundamental change from > sysfs in that you need to write the code, compile it, link it against > the right libraries etc. etc. It will be so much more work no matter > how much you simplify the API and that is already enough to scare away > a lot of folks used to just writing to a bunch of files. > Sure - those using scripts would probably go for Python anyway. But no one in their right mind would elect to use the C API given the alternatives, which makes it basically pointless. > This is why I'm proposing the DBus API as a way of replacing several > features of sysfs that are so beloved by users: central authority over > GPIOs, easy to use from shell scripts (just replace "echo 223 > > export; echo output > 223/direction" etc. with "gdbus call --system > --dest io.gpiod1 --object-path /io/gpiod1/gpiochip2 --method > io.gpiod1.Chip.RequestLines <args>" which is just a tiny bit more > verbose but achieves the same goal and exposes all uAPI v2 features) > and only requires including the dbus daemon in your system which would > be packaged by most distros shipping libgpiod eventually. DBus has the > advantage of being usable from any language you fancy and still being > relatively fast. > > In other words, I'm thinking that packing a lot of "helper" features > into libgpiod will only lead to feature creep but not achieve the goal > of pulling people away from sysfs. > And you think I'm exaggerating. Removing a few pain points is not "packing a lot of "helper" features". Cheers, Kent.