On 1 March 2018 at 16:08, Jeff King wrote:
> On Thu, Mar 01, 2018 at 09:28:31AM -0500, Randall S. Becker wrote:
>
>> > It's not clear to me though if we just want to tweak the programs run in
>> > the
>> > test scripts in order to get test_must_fail to stop complaining, or if we
>> > consider the
On Thu, Mar 01, 2018 at 09:28:31AM -0500, Randall S. Becker wrote:
> > It's not clear to me though if we just want to tweak the programs run in the
> > test scripts in order to get test_must_fail to stop complaining, or if we
> > consider the unusual exit codes from our perl-based Git programs to
On March 1, 2018 2:36 AM, Jeff King wrote:
> On Wed, Feb 28, 2018 at 05:51:14PM +0100, demerphq wrote:
>
> > I would look into putting it into a module and then using the PERL5OPT
> > environment var to have it loaded automagically in any of your perl
> > scripts.
> >
> > For instance if you put t
On 1 March 2018 at 08:36, Jeff King wrote:
> On Wed, Feb 28, 2018 at 05:51:14PM +0100, demerphq wrote:
>
>> I would look into putting it into a module and then using the PERL5OPT
>> environment var to have it loaded automagically in any of your perl
>> scripts.
>>
>> For instance if you put that c
On Wed, Feb 28, 2018 at 05:51:14PM +0100, demerphq wrote:
> I would look into putting it into a module and then using the PERL5OPT
> environment var to have it loaded automagically in any of your perl
> scripts.
>
> For instance if you put that code into a module called Git/DieTrap.pm
>
> then y
On Wed, Feb 28, 2018 at 05:46:22PM +0100, demerphq wrote:
> > You're right. I cut down my example too much and dropped the necessary
> > eval magic. Try this:
> >
> > -- >8 --
> > SIG{__DIE__} = sub {
> > CORE::die @_ if $^S || !defined($^S);
> > print STDERR "fatal: @_";
> > exit 128;
> > }
Randall S. Becker wrote:
> The original thread below has details of what the original issue was and
> why. It hit three tests specifically on this platform where die was invoked
> (at least on one of them). Perl was invoked under the covers and the
> completion code of 169 propagated back through
On February 28, 2018 3:04 PM, Jonathan Nieder wrote:
> On February 28, 2018 1:52 PM, Jonathan Nieder wrote:
> > Randall S. Becker wrote:
> > > On February 28, 2018 12:44 PM, Jonathan Nieder wrote:
> > >> Randall S. Becker wrote:
> >
> > >>> The problem is actually in git code in its test suite that
On February 28, 2018 1:52 PM, Jonathan Nieder wrote:
> Randall S. Becker wrote:
> > On February 28, 2018 12:44 PM, Jonathan Nieder wrote:
> >> Randall S. Becker wrote:
>
> >>> The problem is actually in git code in its test suite that uses perl
> >>> inline, not in my test code itself.
> [...]
> >
Randall S. Becker wrote:
> On February 28, 2018 12:44 PM, Jonathan Nieder wrote:
>> Randall S. Becker wrote:
>>> The problem is actually in git code in its test suite that uses perl
>>> inline, not in my test code itself.
[...]
>> Can you elaborate with an example? My understanding was that
>> te
On February 28, 2018 12:44 PM, Jonathan Nieder wrote:
> Randall S. Becker wrote:
>
> > The problem is actually in git code in its test suite that uses perl
> > inline, not in my test code itself. The difficulty I'm having is
> > placing this appropriate so that the signal handler gets used
> > thr
Randall S. Becker wrote:
> The problem is actually in git code in its test suite that uses perl
> inline, not in my test code itself. The difficulty I'm having is
> placing this appropriate so that the signal handler gets used
> throughout the test suite including in the perl -e invocations. This
On February 28, 2018 12:19 PM, demerphq wrote:
> On 28 February 2018 at 18:10, Randall S. Becker
> wrote:
> > On February 28, 2018 11:46 AM, demerphq wrote:
> >> On 28 February 2018 at 08:49, Jeff King wrote:
> >> > On Wed, Feb 28, 2018 at 07:42:51AM +, Eric Wong wrote:
> >> >
> >> >> > > >
On 28 February 2018 at 18:19, demerphq wrote:
> On 28 February 2018 at 18:10, Randall S. Becker
> wrote:
>> On February 28, 2018 11:46 AM, demerphq wrote:
>>> On 28 February 2018 at 08:49, Jeff King wrote:
>>> > On Wed, Feb 28, 2018 at 07:42:51AM +, Eric Wong wrote:
>>> >
>>> >> > > > a) W
On 28 February 2018 at 18:10, Randall S. Becker wrote:
> On February 28, 2018 11:46 AM, demerphq wrote:
>> On 28 February 2018 at 08:49, Jeff King wrote:
>> > On Wed, Feb 28, 2018 at 07:42:51AM +, Eric Wong wrote:
>> >
>> >> > > > a) We could override the meaning of die() in Git.pm. This fe
On February 28, 2018 11:46 AM, demerphq wrote:
> On 28 February 2018 at 08:49, Jeff King wrote:
> > On Wed, Feb 28, 2018 at 07:42:51AM +, Eric Wong wrote:
> >
> >> > > > a) We could override the meaning of die() in Git.pm. This feels
> >> > > > ugly but if it works, it would be a very sm
On 28 February 2018 at 15:55, Randall S. Becker wrote:
> On February 28, 2018 2:49 AM, Peff wrote:
>> On Wed, Feb 28, 2018 at 07:42:51AM +, Eric Wong wrote:
>>
>> > > > > a) We could override the meaning of die() in Git.pm. This feels
>> > > > > ugly but if it works, it would be a very s
On 28 February 2018 at 08:49, Jeff King wrote:
> On Wed, Feb 28, 2018 at 07:42:51AM +, Eric Wong wrote:
>
>> > > > a) We could override the meaning of die() in Git.pm. This feels
>> > > > ugly but if it works, it would be a very small patch.
>> > >
>> > > Unlikely to work since I think w
Jeff King writes:
> You're right. I cut down my example too much and dropped the necessary
> eval magic. Try this:
>
> -- >8 --
> SIG{__DIE__} = sub {
> CORE::die @_ if $^S || !defined($^S);
> print STDERR "fatal: @_";
> exit 128;
> };
>
> eval {
> die "inside eval";
> };
> print "eval st
On February 28, 2018 2:49 AM, Peff wrote:
> On Wed, Feb 28, 2018 at 07:42:51AM +, Eric Wong wrote:
>
> > > > > a) We could override the meaning of die() in Git.pm. This feels
> > > > > ugly but if it works, it would be a very small patch.
> > > >
> > > > Unlikely to work since I think we
On Wed, Feb 28, 2018 at 07:42:51AM +, Eric Wong wrote:
> > > > a) We could override the meaning of die() in Git.pm. This feels
> > > > ugly but if it works, it would be a very small patch.
> > >
> > > Unlikely to work since I think we use eval {} to trap exceptions
> > > from die.
> > >
Jeff King wrote:
> On Wed, Feb 28, 2018 at 04:07:18AM +, Eric Wong wrote:
>
> > > In the rest of git, die() makes a command exit with status 128. The
> > > trouble here is that our code in Perl is assuming the same meaning for
> > > die() but using perl's die builtin instead. That suggests
On Wed, Feb 28, 2018 at 04:07:18AM +, Eric Wong wrote:
> > In the rest of git, die() makes a command exit with status 128. The
> > trouble here is that our code in Perl is assuming the same meaning for
> > die() but using perl's die builtin instead. That suggests a few
> > options:
> >
> >
Jonathan Nieder wrote:
> The fundamental thing is the actual Git commands, not the tests in the
> testsuite, no?
Right. I've never been picky about exit codes; only that a
non-zero happens on errors.
> In the rest of git, die() makes a command exit with status 128. The
> trouble here is that o
Hi,
Randall S. Becker wrote:
> After months of arguing with some platform developers on this subject, the
> perl spec was held over my head repeatedly about a few lines that are
> causing issues. The basic problem is this line (test-lib-functions.sh, line
> 633, still in ffa952497)
>
>>el
Hi all,
After months of arguing with some platform developers on this subject, the
perl spec was held over my head repeatedly about a few lines that are
causing issues. The basic problem is this line (test-lib-functions.sh, line
633, still in ffa952497)
>elif test $exit_code -gt 129 && te
26 matches
Mail list logo
