Le 25/06/2020 à 06:26, dc...@prosentient.com.au a écrit :
The article is worth a read though. It points out a number of language
aspects that have changed (e.g. bareword file handles, indirect object
notation, etc), and we could actually work on eliminating those in our
current code to bring Ko
I was also reading about Perl 7 last night and the idea of trying to move
our codebase towards it excites me.. it would be great if this was the
prompt to help concentrate our efforts on modernising our codebase.
Wasn't aware of bug 21395, I'll take a look asap.
I like the idea of adding Prohibit
I tried to advocate switching to 5.22 as a minimum a while ago but got
blocked.
At this point.. I'm not entirely sure what upping our minimum beyond what
we actually support would achieve.. if we've got 5.14 features in use in
code then we should advertise 5.14 as the minimum... I would like to se
I doubt we will need to worry about Perl 7 until it's available in Debian.
It's essentially 5.32 with some better defaults ( no need to 'use strict'
for example ). There will also be a migration path from Perl 5 to Perl 7 (
but not from Perl 5 to Perl 8 ). Perl 5 is expected to have about 10 years
Totally agreed! We should work toward Perl 7 compliance as soon as
possible, which I presume is the point when it is available in Debian.
---
http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
Crawford County Fede
I agree with Martin we should be requiring newer versions when we need them
to (say) get better code or results.
And we should be consistent. Right now the minimum should be 5.14 and we
are not making it clear to the users.
External library dependencies might be another reason to shift Perl
versio
Those are good points. Personally, I’d like us to specify the Perl version
minimum based on actual usage as well. I just wonder how best we determine what
the minimum version should be (why 5.14?) and where we specify that.
Should we be using “use 5.14.0” in plack.psgi for instance*? Or are w
Smart matches where used a while back but marked as experimental and we
removed their only uses.
5.10 was required for defined-or, and Julian suggests we need 5.14 because
of the use of /r.
PS is it me or the reply-to on this list puts the author of the previous
message? It should be the list its
That’s awesome, Julian! I hope that gets in soon.
That’s what I was thinking too, Martin. I figure Perl 7 provides a distinct
goal to target.
Kyle, that’s probably right. I guess Debian Testing and then we’ll see it first
in a stable Ubuntu.
Although after reading a pretty harsh cr
Yeah, I remember when we used to use them, but then removed them due them
changing so much.
Ahh. That does sound pretty well thought out then. Yeah, let’s up it to 5.14,
as we definitely require it for
Koha/SearchEngine/Elasticsearch/QueryBuilder.pm, and no one should be running a
Linux sys
Actually, after hacking on Plack::App::CGIBin and Plack::App::WrapCGI in
koha-testing-docker, it looks like I must have misread the source code. Maybe
it is possible to use alternative binaries for Plack Koha…
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2
Hi all,
Tired of going to plack-error.log and getting output for every Plack app
without any timestamps? Not sure if the output is from the Intranet or the
OPAC? Not sure what time it happened?
Well suffer no more! Go to
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16357 and ch
12 matches
Mail list logo
