nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Make test-mhical pass with BSD yacc.


From: Bob Carragher
Subject: Re: [PATCH] Make test-mhical pass with BSD yacc.
Date: Tue, 22 Sep 2020 02:40:58 -0700

Speaking as an NMH leech-user B-), I think the NMH developers and
maintainers should get to specify what the preferred development
and build dependencies should be.  (Which, of course, has no
direct bearing on a user that's obtaining pre-built binaries via
a package, like I do via Ubuntu.  But it might make development,
or just building, on "limited" systems harder or impossible.)

Making use of a more modern scripting language for testing,
especially if it brings a comprehensive set of testing tools,
seems like it would be a win, if it makes it easier to create
better or more or more rigorous testing.  Would we expect a
theoretical new developer to insist on using only older tools?

                                Bob

On Sun, 20 Sep 2020 19:01:52 -0400 Ken Hornstein <kenh@pobox.com> sez:

> Sigh.  This is one of those tough ones.  It is nice to have a
> minimum dependency set, but ....  I see where you are coming
> from.  If we are voting I'd still rather write a simple C
> program to do what we need here, but I recognize that may be a
> minority view.



On Sun, 20 Sep 2020 18:02:58 -0400 David Levine <levinedl@acm.org> sez:

> And it could probably handle at least some of what's in the
> accessory test programs.  On the other hand, using an LCD of
> POSIX has advantages of portability and minimizing
> dependencies.



On Sun, 20 Sep 2020 16:01:01 -0500 Eric Gillespie <epg@pretzelnet.org> sez:

> If we're going to look at additional requirements imposed on
> developers, I would suggest that imposition would bring far
> more bang for the buck if it were a proper scripting language
> we can write the tests in.  This would not only have made this
> test-mhical problem easier to fix, but also the other one I
> fixed.  As Ralph says, we just don't see a way to have derive
> two different timestamp formats from a single source of truth
> with the tools available to us.  But with Perl or any of its
> competitors, it would be trivial.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]