On 18.03.24 09:17, Daniel Gustafsson wrote:
On 18 Mar 2024, at 07:27, Peter Eisentraut wrote:
After some pondering, I figured the exclude list is better.
Agreed.
So here is a squashed patch, also with a complete commit message.
Looks good from a read-through. It would have been nice
> On 18 Mar 2024, at 14:18, Dagfinn Ilmari Mannsåker wrote:
> Daniel Gustafsson writes:
>> It would have been nice to standardize on
>> using one of "|| die" and "or die" consistently but that's clearly not for
>> this
>> body of work.
>
> "or die" is generally the preferred form, since ||
Daniel Gustafsson writes:
>> On 18 Mar 2024, at 07:27, Peter Eisentraut wrote:
>
>> After some pondering, I figured the exclude list is better.
>
> Agreed.
>
>> So here is a squashed patch, also with a complete commit message.
>
> Looks good from a read-through. It would have been nice to
> On 18 Mar 2024, at 07:27, Peter Eisentraut wrote:
> After some pondering, I figured the exclude list is better.
Agreed.
> So here is a squashed patch, also with a complete commit message.
Looks good from a read-through. It would have been nice to standardize on
using one of "|| die" and
On Mon, Mar 18, 2024 at 2:28 AM Peter Eisentraut
wrote:
> On 21.02.24 08:26, Peter Eisentraut wrote:
> > On 14.02.24 17:52, Peter Eisentraut wrote:
> >> A gentler way might be to start using some perlcritic policies like
> >> InputOutput::RequireCheckedOpen or the more general
> >>
On 21.02.24 08:26, Peter Eisentraut wrote:
On 14.02.24 17:52, Peter Eisentraut wrote:
A gentler way might be to start using some perlcritic policies like
InputOutput::RequireCheckedOpen or the more general
InputOutput::RequireCheckedSyscalls and add explicit error checking at
the sites it
On 14.02.24 17:52, Peter Eisentraut wrote:
A gentler way might be to start using some perlcritic policies like
InputOutput::RequireCheckedOpen or the more general
InputOutput::RequireCheckedSyscalls and add explicit error checking at
the sites it points out.
Here is a start for that. I
> On 19 Feb 2024, at 01:54, Andrew Dunstan wrote:
> On 2024-02-14 We 11:52, Peter Eisentraut wrote:
>> A gentler way might be to start using some perlcritic policies like
>> InputOutput::RequireCheckedOpen or the more general
>> InputOutput::RequireCheckedSyscalls and add explicit error
On 2024-02-14 We 11:52, Peter Eisentraut wrote:
On 08.02.24 16:53, Tom Lane wrote:
Daniel Gustafsson writes:
On 8 Feb 2024, at 08:01, Peter Eisentraut
wrote:
I suppose we could start using it for completely new scripts.
+1, it would be nice to eventually be able to move to it everywhere
On 08.02.24 16:53, Tom Lane wrote:
Daniel Gustafsson writes:
On 8 Feb 2024, at 08:01, Peter Eisentraut wrote:
I suppose we could start using it for completely new scripts.
+1, it would be nice to eventually be able to move to it everywhere so starting
now with new scripts may make the
Andrew Dunstan writes:
> On 2024-02-08 Th 11:08, Daniel Gustafsson wrote:
>> On 8 Feb 2024, at 16:53, Tom Lane wrote:
>>> 2. Don't wait, migrate them all now. This would mean requiring
>>> Perl 5.10.1 or later to run the TAP tests, even in back branches.
>>> I think #2 might not be all that
On 2024-02-08 Th 11:08, Daniel Gustafsson wrote:
On 8 Feb 2024, at 16:53, Tom Lane wrote:
2. Don't wait, migrate them all now. This would mean requiring
Perl 5.10.1 or later to run the TAP tests, even in back branches.
I think #2 might not be all that radical. We have nothing older
than
Daniel Gustafsson writes:
>> On 8 Feb 2024, at 16:53, Tom Lane wrote:
>
>> 2. Don't wait, migrate them all now. This would mean requiring
>> Perl 5.10.1 or later to run the TAP tests, even in back branches.
>>
>> I think #2 might not be all that radical. We have nothing older
>> than 5.14.0
>
> 2. Don't wait, migrate them all now. This would mean requiring
> Perl 5.10.1 or later to run the TAP tests, even in back branches.
>
#2 please. For context, meson did not even exist in 2009.
Cheers,
Greg
> On 8 Feb 2024, at 16:53, Tom Lane wrote:
> 2. Don't wait, migrate them all now. This would mean requiring
> Perl 5.10.1 or later to run the TAP tests, even in back branches.
>
> I think #2 might not be all that radical. We have nothing older
> than 5.14.0 in the buildfarm, so we don't
Daniel Gustafsson writes:
>> On 8 Feb 2024, at 08:01, Peter Eisentraut wrote:
>> I suppose we could start using it for completely new scripts.
> +1, it would be nice to eventually be able to move to it everywhere so
> starting
> now with new scripts may make the eventual transition smoother.
> On 8 Feb 2024, at 08:01, Peter Eisentraut wrote:
> I suppose we could start using it for completely new scripts.
+1, it would be nice to eventually be able to move to it everywhere so starting
now with new scripts may make the eventual transition smoother.
--
Daniel Gustafsson
On 08.02.24 07:03, Tom Lane wrote:
John Naylor writes:
On Wed, Feb 7, 2024 at 11:52 PM Greg Sabino Mullane wrote:
No drawbacks. I've been using it heavily for many, many years. Came out in
5.10.1,
which should be available everywhere at this point (2009 was the year of
release)
We moved
John Naylor writes:
> On Wed, Feb 7, 2024 at 11:52 PM Greg Sabino Mullane
> wrote:
>> No drawbacks. I've been using it heavily for many, many years. Came out in
>> 5.10.1,
>> which should be available everywhere at this point (2009 was the year of
>> release)
> We moved our minimum to 5.14
On Wed, Feb 7, 2024 at 11:52 PM Greg Sabino Mullane wrote:
>
> No drawbacks. I've been using it heavily for many, many years. Came out in
> 5.10.1,
> which should be available everywhere at this point (2009 was the year of
> release)
We moved our minimum to 5.14 fairly recently, so we're good
On Wed, Feb 7, 2024 at 9:05 AM Peter Eisentraut
wrote:
> I came across the Perl autodie pragma
> (https://perldoc.perl.org/autodie). This seems pretty useful; is this
> something we can use? Any drawbacks? Any minimum Perl version?
Big +1
No drawbacks. I've been using it heavily for many,
I came across the Perl autodie pragma
(https://perldoc.perl.org/autodie). This seems pretty useful; is this
something we can use? Any drawbacks? Any minimum Perl version?
Attached is a sample patch of the kind of thing I'd be interested in.
The existing error handling of file operations in
22 matches
Mail list logo
