Re: [libgpiod][PATCH 1/1] gpio-tools-test.bats: modify delays in toggle test

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Tue, May 30, 2023 at 5:18 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
>
> On Tue, May 30, 2023 at 04:52:36PM +0200, Bartosz Golaszewski wrote:
> > On Tue, May 30, 2023 at 4:24 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> > >
> > > On Tue, May 30, 2023 at 04:13:06PM +0200, Bartosz Golaszewski wrote:
> > > > On Tue, May 30, 2023 at 12:05 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> > > > >
> > > > > On Tue, May 30, 2023 at 11:51:05AM +0200, Bartosz Golaszewski wrote:
> > > > > > On Thu, May 25, 2023 at 11:54 PM Slater, Joseph
> > > > > > <joe.slater@xxxxxxxxxxxxx> wrote:
> > > > > > >
> > > > > > >
> > > > > > > [Slater, Joseph] I'll get rid of the comment and try the test with a shorter toggle time.
> > > > > > > The series of 159 tests takes, maybe, 10-15 minutes for me, so I don't think saving a
> > > > > > > second or two here would make much difference, though.
> > > > > > > Joe
> > > > > > >
> > > > > >
> > > > > > That can't be right, are you running it on a toaster? It takes 26
> > > > > > seconds on my regular lenovo thinkpad laptop which is still longer
> > > > > > than I'd like but quite acceptable for now (though I agree it would be
> > > > > > great to improve it).
> > > > > >
> > > > >
> > > > > Consider yourself blessed.
> > > > > I just got:
> > > > >
> > > > > real    2m25.956s
> > > > >
> > > > > on my test VM.
> > > > > Not sure exactly what the hold up is - it isn't using much CPU, or any
> > > > > other resources AFAICT.
> > > > > Compared to all the other test suites I run, this is far and away the
> > > > > slowest, especially since switching everything over to gpio-sim.
> > > >
> > > > I agree it's too slow - be it 20 seconds or 2 minutes. But similarly
> > > > to you - it's very low on my TODO list as I only run it every once in
> > > > a while. I'd be happy to accept any patches improving the situation of
> > > > course.
> > > >
> > >
> > > Same.  I already had a go at streamlining the tests when I updated them
> > > for v2, so it is somewhat better than it was, but it is still painfully
> > > slow for me.
> > > To improve further I'd have to start digging around to see what bats is
> > > up to.  Speaking of which, do we need to stick with bats?
> > > I've driven similar tests with Python in the past, and I'm sure that
> > > would provide a better experience.
> > > What constraints do we have?
> > >
> >
> > I went with bats because it looked the fastest to write tests in -
> > it's shell after all.
> >
>
> Really?  I wouldn't write anything of consequence in shell if Python was
> an option.
>
> How about Rust?  I've gotten over how spartan the Rust test framework is
> so I wouldn't have a problem writing it in that either.
>

I have a very strong preference for Python. I am quite bad at Rust.
Whatever is in bindings/rust/ is Viresh' jurisdiction and I defer to
him but I would prefer to be able to keep track of what's happening in
tools/ and work on it myself without too much frustration. And writing
anything in rust has been pure frustration so far.

Bartosz

> > But I think that we could potentially package whatever python
> > subprocess code we need into enough helper wrappers that it wouldn't
> > be much more complex than this.
> >
>
> The end result would look similar in terms of test complexity, but
> should be much easier to write and debug.
> Not that that counts for much given we have a functional bats test
> suite.
>
> > We also already have python wrappers for libgpiosim ready.
> >
>
> Exactly.  And Rust bindings too.
>
> > No objections from my side, it's just that I won't have time to
> > rewrite the entire thing in Python anytime soon.
> >
>
> I'll update my todo list.  No promises - it is low priority given the
> only real problem with the bats solution is its performance.
>
> Cheers,
> Kent.
>