develooper Front page | perl.perl5.porters | Postings from September 2016

Re: [perl #127885] [patches] enhance to test same perlunder different options/args

Thread Previous
Jim Cromie
September 28, 2016 16:16
Re: [perl #127885] [patches] enhance to test same perlunder different options/args
Message ID:
On Tue, Sep 27, 2016 at 9:02 AM, Dave Mitchell via RT <> wrote:

> On Tue, Apr 12, 2016 at 09:35:31AM -0700, Jim Cromie wrote:
> > Porting/ has 2 interrelated shortcomings:
> >
> > 1- it stores cachegrind results using {$testname}{$perlname}.
> >    This means that if the same $perlname is used 2x, the 2nd results
> >    overwrite the 1st.
> >
> > 2- it cannot pass different options/args to each Perl-Under-Test.
> >
> > This patchset corrects those problems, allowing to test the same perl
> > under different runtime conditions, as caused by the use of different
> > -M<foo> etc options.  It was motivated by my desire to test the
> > runtime cost of using -DPERL_TRACE_OPS.
> >
> > example 0:
> >
> >    $] perl Porting/ --jobs=2 --verbose \
> >         --tests=/loop::for::my/ \
> >         --perlargs='-MDevel::Peek' \
> >         -- \
> >         perl5.24.0=+off      -e'"BEGIN{runops_debug(0)}"' \
> >         perl5.24.0=+traceops -e'"BEGIN{runops_debug(1)}"'
> I'm not entirely happy with this new syntax and implementation.
> Firstly, the documentation doesn't make it clear what are perls and
> what are perl args, and to which perl they apply. Is it the intention
> that all non-perls following a perl (up to but not including the next
> perl) are args of the previous perl? i.e.
>     perlA -perlA_arg1 -perlA_arg2    perlB -perlB_arg1 -perlB_arg2
yes, that is the intent.
I vacillated on how to describe it, was reluctant to add glossary terms,
decided example invocations would be brief and communicative.

It may be that those examples are in the unapplied 2nd batch of patches.
Also, the 1st 2 patches are fixups, their bugs may be responsible for
the misbehaviors youre seeing.

Secondly it introduces a bug whereby a misspelled perl executable
> name is now just silently ignored: this
>     $ Porting/ nosuchperl perl5240
quite happily benchmarks just perl5240 with no warnings.

OK. thats probably due to handling the perl-args in reverse order,
and may be best correctable by un-reversing the arg/perl scan.

Also, note that the bare '--' arg is needed to terminate the Getopt::Long
option scan.  I added that into the synopsis and examples,
but didnt otherwize note it.

> Third, the determination of what is a perl executable and what is an arg
> seems a bit haphazard. It seems to be: if it starts with a dash, assume
> its an arg, else try and execute it, and if it doesn't execute ok, assume
> its an arg? I don't like this at all.

Ack - after reversing the post '--' arg-scan, I added the -dash check
to prevent the $^X check from emitting a bash option error, which was
fairly obscure.

> I'd much prefer it to be
> deterministic based on the command line's syntax, although I'm not sure
> what syntax. Perhaps args to perl should be part of the same arg as the
> executable name, e.g.
>     Porting/  \
>         'perlA+foo -perlA_arg1 -perlA_arg2' \
>         'perlB+bar -perlB_arg1 -perlB_arg2'
> although I guess that could run afoul of executable pathnames with spaces
> in them.

Aristotle's suggestion to use prove syntax may provide a way forward

> --
> Dave's first rule of Opera:
> If something needs saying, say it: don't warble it.
> :-)  I wonder if you have any rules about 10 minute drum solos

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About