Bleadperl v5.19.3-651-gb29f65f breaks MLEHMANN/AnyEvent-Fork-1.2.tar.gz

p5pRT commented 10 years ago

Migrated from rt.perl.org#121970 (status was 'resolved')

Searchable as RT121970$

p5pRT commented 10 years ago

From @andk

git bisect

commit b29f65fce68bc99d0924f63f8d8bbbe70dc63890 Author: Brian Fraser \fraserbn@gmail\.com Date: Sun Sep 1 10:21:52 2013 -0300

[perl #119123] disallow literal control character variables
This introduces a deprecation warning on things like $^T\, where ^T is a literal control character in the source code.

Note 1: I could not compile v5.19.3-651-gb29f65f itself but its successor and the diagnostics indicate this change is the threshold.

Note 2: Even when the change can be regarded as well documented and that we can push it down on the world without hesitation\, I want all such breakages be documented in perl tickets at least as a reference.

Note 3: I personally regret we did not find this earlier:(

diagnostics

http://www.cpantesters.org/cpan/report/a7e2adf4-2618-11e3-949b-5deea0a565e3

perl -V

Summary of my perl5 (revision 5 version 19 subversion 4) configuration: Commit id: 388a7a89010010e899c2e3a9707478167adad606 Platform: osname=linux\, osvers=3.10-2-amd64\, archname=x86_64-linux-ld uname='linux k83 3.10-2-amd64 #1 smp debian 3.10.7-1 (2013-08-17) x86_64 gnulinux ' config_args='-Dprefix=/home/sand/src/perl/repoperls/installed-perls/perl/v5.19.4/127e -Dmyhostname=k83 -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Ui_db -Uuseithreads -Duselongdouble -DDEBUGGING=-g' hint=recommended\, useposix=true\, d_sigaction=define useithreads=undef\, usemultiplicity=undef useperlio=define\, d_sfio=undef\, uselargefiles=define\, usesocks=undef use64bitint=define\, use64bitall=define\, uselongdouble=define usemymalloc=n\, bincompat5005=undef Compiler: cc='cc'\, ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'\, optimize='-O2 -g'\, cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion=''\, gccversion='4.8.1'\, gccosandvers='' intsize=4\, longsize=8\, ptrsize=8\, doublesize=8\, byteorder=12345678 d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=16 ivtype='long'\, ivsize=8\, nvtype='long double'\, nvsize=16\, Off_t='off_t'\, lseeksize=8 alignbytes=16\, prototype=define Linker and Libraries: ld='cc'\, ldflags =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=\, so=so\, useshrplib=false\, libperl=libperl.a gnulibc_version='2.17' Dynamic Linking: dlsrc=dl_dlopen.xs\, dlext=so\, d_dlsymun=undef\, ccdlflags='-Wl\,-E' cccdlflags='-fPIC'\, lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_MALLOC_WRAP PERL_NEW_COPY_ON_WRITE PERL_PRESERVE_IVUV PERL_USE_DEVEL USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LONG_DOUBLE USE_PERLIO USE_PERL_ATOF Built under linux Compiled at Sep 20 2013 21:49:27 %ENV: PERL5LIB="" PERL5OPT="" PERL5_CPANPLUS_IS_RUNNING="15858" PERL5_CPAN_IS_RUNNING="15858" PERL_MM_USE_DEFAULT="1" @INC: /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.4/127e/lib/site_perl/5.19.4/x86_64-linux-ld /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.4/127e/lib/site_perl/5.19.4 /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.4/127e/lib/5.19.4/x86_64-linux-ld /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.4/127e/lib/5.19.4 .

-- andreas

p5pRT commented 10 years ago

From @jkeenan

On Tue May 27 23:41:43 2014\, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:

git bisect ---------- commit b29f65fce68bc99d0924f63f8d8bbbe70dc63890 Author: Brian Fraser \fraserbn@gmail\.com Date: Sun Sep 1 10:21:52 2013 -0300

[perl #119123] disallow literal control character variables

This introduces a deprecation warning on things like $^T\, where ^T is a literal control character in the source code.

Note 1: I could not compile v5.19.3-651-gb29f65f itself but its successor and the diagnostics indicate this change is the threshold.

Note 2: Even when the change can be regarded as well documented and that we can push it down on the world without hesitation\, I want all such breakages be documented in perl tickets at least as a reference.

Note 3: I personally regret we did not find this earlier:(

diagnostics ----------- http://www.cpantesters.org/cpan/report/a7e2adf4-2618-11e3-949b- 5deea0a565e3

Andreas\,

Can you tell me whether\, in evaluating a failure report like this\, the following is a legitimate and useful procedure?

My current perl is 5.20.0. I used 'cpanm' to test this distribution as follows:

##### $ cpanm --test-only AnyEvent::Fork

[snip boilerplate]

--> Working on AnyEvent::Fork Fetching http://www.cpan.org/authors/id/M/ML/MLEHMANN/AnyEvent-Fork-1.2.tar.gz ... OK Configuring AnyEvent-Fork-1.2 ... OK ==> Found dependencies: common::sense\, IO::FDPass\, Proc::FastSpawn\, AnyEvent --> Working on common::sense Fetching http://www.cpan.org/authors/id/M/ML/MLEHMANN/common-sense-3.72.tar.gz ... OK Configuring common-sense-3.72 ... OK Building and testing common-sense-3.72 ... OK Successfully tested common-sense-3.72 --> Working on IO::FDPass Fetching http://www.cpan.org/authors/id/M/ML/MLEHMANN/IO-FDPass-1.0.tar.gz ... OK Configuring IO-FDPass-1.0 ... OK Building and testing IO-FDPass-1.0 ... OK Successfully tested IO-FDPass-1.0 --> Working on Proc::FastSpawn Fetching http://www.cpan.org/authors/id/M/ML/MLEHMANN/Proc-FastSpawn-1.2.tar.gz ... OK Configuring Proc-FastSpawn-1.2 ... OK Building and testing Proc-FastSpawn-1.2 ... OK Successfully tested Proc-FastSpawn-1.2 --> Working on AnyEvent Fetching http://www.cpan.org/authors/id/M/ML/MLEHMANN/AnyEvent-7.07.tar.gz ... OK Configuring AnyEvent-7.07 ... OK Building and testing AnyEvent-7.07 ... OK Successfully tested AnyEvent-7.07 Building and testing AnyEvent-Fork-1.2 ... OK Successfully tested AnyEvent-Fork-1.2 #####

Notes: (1) I'm relatively new to use of 'cpanm'\, so I may be using it naively. (2) I'm assuming that 5.20.0 provides a better current diagnosis than the earlier commit which generated the failure report.

Thank you very much. Jim Keenan

p5pRT commented 10 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 10 years ago

From @andk

"James E Keenan via RT" \perlbug\-followup@perl\.org writes:

Andreas\,

Can you tell me whether\, in evaluating a failure report like this\, the following is a legitimate and useful procedure?

My current perl is 5.20.0. I used 'cpanm' to test this distribution as follows:

##### $ cpanm --test-only AnyEvent::Fork

[snip boilerplate]

--> Working on AnyEvent::Fork Fetching http://www.cpan.org/authors/id/M/ML/MLEHMANN/AnyEvent-Fork-1.2.tar.gz ... OK Configuring AnyEvent-Fork-1.2 ... OK ==> Found dependencies: common::sense\, IO::FDPass\, Proc::FastSpawn\, AnyEvent --> Working on common::sense Fetching http://www.cpan.org/authors/id/M/ML/MLEHMANN/common-sense-3.72.tar.gz ... OK Configuring common-sense-3.72 ... OK Building and testing common-sense-3.72 ... OK Successfully tested common-sense-3.72 --> Working on IO::FDPass Fetching http://www.cpan.org/authors/id/M/ML/MLEHMANN/IO-FDPass-1.0.tar.gz ... OK Configuring IO-FDPass-1.0 ... OK Building and testing IO-FDPass-1.0 ... OK Successfully tested IO-FDPass-1.0 --> Working on Proc::FastSpawn Fetching http://www.cpan.org/authors/id/M/ML/MLEHMANN/Proc-FastSpawn-1.2.tar.gz ... OK Configuring Proc-FastSpawn-1.2 ... OK Building and testing Proc-FastSpawn-1.2 ... OK Successfully tested Proc-FastSpawn-1.2 --> Working on AnyEvent Fetching http://www.cpan.org/authors/id/M/ML/MLEHMANN/AnyEvent-7.07.tar.gz ... OK Configuring AnyEvent-7.07 ... OK Building and testing AnyEvent-7.07 ... OK Successfully tested AnyEvent-7.07 Building and testing AnyEvent-Fork-1.2 ... OK Successfully tested AnyEvent-Fork-1.2 #####

Notes: (1) I'm relatively new to use of 'cpanm'\, so I may be using it naively. (2) I'm assuming that 5.20.0 provides a better current diagnosis than the earlier commit which generated the failure report.

I'm impressed you can generate a PASS for AE:F. I find the output of cpanm not helpful\, it does not show for example that tests have actually been running or maybe have been skipped. Also no 'perl -V'.

I don't believe that cpanm can be configured to run full blown cpantesters reports but I may have missed a posting about it and the wiki page http://wiki.cpantesters.org/wiki/SmokeTesting does not mention it. Maybe ask on cpan-testers-discuss@perl.org ?

One thing that should be noted is that CPAN.pm and CPAN::Reporter can be used to generate and send reports without doing all the steps described on the wiki page. Let me know if you's like to have a minimum-impact howto.

-- andreas

p5pRT commented 10 years ago

From @ap

Hi Andreas\,

* Andreas Koenig \andreas\.koenig\.7os6VVqR@franz\.ak\.mind\.de [2014-05-29 06:55]:

I find the output of cpanm not helpful\, it does not show for example that tests have actually been running or maybe have been skipped.

a CPAN.pm-style verbose log is stored in ~/.cpanm/work/*/build.log (with one work subdirectory created per install run)\, and the latest build.log and work subdir are symlinked as ~/.cpanm/build.log and .../latest-build respectively.

I don't believe that cpanm can be configured to run full blown cpantesters reports but I may have missed a posting about it

https://metacpan.org/release/App-cpanminus-reporter

Regards\, -- Aristotle Pagaltzis // \<http://plasmasturm.org/>

p5pRT commented 10 years ago

From @jkeenan

On Wed May 28 22:35:21 2014\, aristotle wrote:

a CPAN.pm-style verbose log is stored in ~/.cpanm/work/*/build.log (with one work subdirectory created per install run)\, and the latest build.log and work subdir are symlinked as ~/.cpanm/build.log and .../latest- build respectively.

Please find attached the build log from my PASS on AnyEvent::Fork using 'cpanm'. Thanks\, Aristotle\, for that suggestion.

p5pRT commented 10 years ago

From @jkeenan

cpanm (App::cpanminus) 1.7001 on perl 5.018002 built for x86_64-linux-gnu-thread-multi Work directory is /home/jkeenan/.cpanm/work/1401285330.32304 You have make /usr/bin/make You have /usr/bin/wget You have /bin/tar: tar (GNU tar) 1.27.1 Copyright (C) 2013 Free Software Foundation\, Inc. License GPLv3+: GNU GPL version 3 or later \<http://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY\, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason. You have /usr/bin/unzip ! ! Can't write to /usr/local/share/perl/5.18.2 and /usr/local/bin: Installing modules to /home/jkeenan/perl5 ! To turn off this warning\, you have to do one of the following: ! - run me as a root or with --sudo option (to install to /usr/local/share/perl/5.18.2 and /usr/local/bin) ! - Configure local::lib your existing local::lib in this shell to set PERL_MM_OPT etc. ! - Install local::lib by running the following commands ! ! cpanm --local-lib=~/perl5 local::lib && eval $(perl -I ~/perl5/lib/perl5/ -Mlocal::lib) ! Checking if you have ExtUtils::MakeMaker 6.31 ... Yes (6.98) Checking if you have ExtUtils::Install 1.46 ... Yes (1.59) Searching AnyEvent::Fork on cpanmetadb ... --> Working on AnyEvent::Fork Fetching http://www.cpan.org/authors/id/M/ML/MLEHMANN/AnyEvent-Fork-1.2.tar.gz -> OK Unpacking AnyEvent-Fork-1.2.tar.gz Entering AnyEvent-Fork-1.2 Checking configure dependencies from META.json Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.98) Configuring AnyEvent-Fork-1.2 Running Makefile.PL Warning: prerequisite AnyEvent 6 not found. Warning: prerequisite IO::FDPass 0.2 not found. Warning: prerequisite Proc::FastSpawn 0.1 not found. Warning: prerequisite common::sense 3.6 not found. Checking if your kit is complete... Looks good Generating a Unix-style Makefile Writing Makefile for AnyEvent::Fork Writing MYMETA.yml and MYMETA.json -> OK Checking dependencies from MYMETA.json ... Checking if you have common::sense 3.6 ... No Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.98) Checking if you have IO::FDPass 0.2 ... No Checking if you have Proc::FastSpawn 0.1 ... No Checking if you have AnyEvent 6 ... No ==> Found dependencies: common::sense\, IO::FDPass\, Proc::FastSpawn\, AnyEvent Searching common::sense on cpanmetadb ... --> Working on common::sense Fetching http://www.cpan.org/authors/id/M/ML/MLEHMANN/common-sense-3.72.tar.gz -> OK Unpacking common-sense-3.72.tar.gz Entering common-sense-3.72 Checking configure dependencies from META.json Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.98) Configuring common-sense-3.72 Running Makefile.PL Checking if your kit is complete... Looks good Generating a Unix-style Makefile Writing Makefile for common::sense Writing MYMETA.yml and MYMETA.json -> OK Checking dependencies from MYMETA.json ... Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.98) Building and testing common-sense-3.72 /usr/bin/perl sense.pm.PL sense.pm cp sense.pm blib/arch/common/sense.pm cp sense.pod blib/lib/common/sense.pod Manifying blib/man3/common::sense.3pm PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0\, 'blib/lib'\, 'blib/arch')" t/*.t t/00_load.t .. ok t/01_arch.t .. ok All tests successful. Files=2\, Tests=2\, 0 wallclock secs ( 0.02 usr + 0.00 sys = 0.02 CPU) Result: PASS Files found in blib/arch: installing files in blib/lib into architecture dependent library tree Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/common/sense.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/common/sense.pod Installing /home/jkeenan/perl5/man/man3/common::sense.3pm Appending installation info to /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/perllocal.pod -> OK Successfully tested common-sense-3.72 Searching IO::FDPass on cpanmetadb ... --> Working on IO::FDPass Fetching http://www.cpan.org/authors/id/M/ML/MLEHMANN/IO-FDPass-1.0.tar.gz -> OK Unpacking IO-FDPass-1.0.tar.gz Entering IO-FDPass-1.0 Checking configure dependencies from META.json Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.98) Configuring IO-FDPass-1.0 Running Makefile.PL Checking if your kit is complete... Looks good Generating a Unix-style Makefile Writing Makefile for IO::FDPass Writing MYMETA.yml and MYMETA.json -> OK Checking dependencies from MYMETA.json ... Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.98) Building and testing IO-FDPass-1.0 cp FDPass.pm blib/lib/IO/FDPass.pm Running Mkbootstrap for IO::FDPass () chmod 644 FDPass.bs /usr/bin/perl /usr/share/perl/5.18/ExtUtils/xsubpp -typemap /usr/share/perl/5.18/ExtUtils/typemap FDPass.xs > FDPass.xsc && mv FDPass.xsc FDPass.c cc -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fstack-protector -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -DVERSION=\"1.0\" -DXS_VERSION=\"1.0\" -fPIC "-I/usr/lib/perl/5.18/CORE" FDPass.c rm -f blib/arch/auto/IO/FDPass/FDPass.so cc -shared -L/usr/local/lib -fstack-protector FDPass.o -o blib/arch/auto/IO/FDPass/FDPass.so \ \
chmod 755 blib/arch/auto/IO/FDPass/FDPass.so /usr/bin/perl -MExtUtils::Command::MM -e 'cp_nonempty' -- FDPass.bs blib/arch/auto/IO/FDPass/FDPass.bs 644 Manifying blib/man3/IO::FDPass.3pm Running Mkbootstrap for IO::FDPass () chmod 644 FDPass.bs PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0\, 'blib/lib'\, 'blib/arch')" t/*.t t/00_load.t ... ok t/01_basic.t .. ok All tests successful. Files=2\, Tests=8\, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.01 cusr 0.00 csys = 0.03 CPU) Result: PASS Files found in blib/arch: installing files in blib/lib into architecture dependent library tree Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/auto/IO/FDPass/FDPass.so Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/IO/FDPass.pm Installing /home/jkeenan/perl5/man/man3/IO::FDPass.3pm Appending installation info to /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/perllocal.pod -> OK Successfully tested IO-FDPass-1.0 Searching Proc::FastSpawn on cpanmetadb ... --> Working on Proc::FastSpawn Fetching http://www.cpan.org/authors/id/M/ML/MLEHMANN/Proc-FastSpawn-1.2.tar.gz -> OK Unpacking Proc-FastSpawn-1.2.tar.gz Entering Proc-FastSpawn-1.2 Checking configure dependencies from META.json Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.98) Configuring Proc-FastSpawn-1.2 Running Makefile.PL Checking if your kit is complete... Looks good Generating a Unix-style Makefile Writing Makefile for Proc::FastSpawn Writing MYMETA.yml and MYMETA.json -> OK Checking dependencies from MYMETA.json ... Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.98) Building and testing Proc-FastSpawn-1.2 cp FastSpawn.pm blib/lib/Proc/FastSpawn.pm Running Mkbootstrap for Proc::FastSpawn () chmod 644 FastSpawn.bs /usr/bin/perl /usr/share/perl/5.18/ExtUtils/xsubpp -typemap /usr/share/perl/5.18/ExtUtils/typemap FastSpawn.xs > FastSpawn.xsc && mv FastSpawn.xsc FastSpawn.c cc -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fstack-protector -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -DVERSION=\"1.2\" -DXS_VERSION=\"1.2\" -fPIC "-I/usr/lib/perl/5.18/CORE" FastSpawn.c rm -f blib/arch/auto/Proc/FastSpawn/FastSpawn.so cc -shared -L/usr/local/lib -fstack-protector FastSpawn.o -o blib/arch/auto/Proc/FastSpawn/FastSpawn.so \ \
chmod 755 blib/arch/auto/Proc/FastSpawn/FastSpawn.so /usr/bin/perl -MExtUtils::Command::MM -e 'cp_nonempty' -- FastSpawn.bs blib/arch/auto/Proc/FastSpawn/FastSpawn.bs 644 Manifying blib/man3/Proc::FastSpawn.3pm Running Mkbootstrap for Proc::FastSpawn () chmod 644 FastSpawn.bs PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0\, 'blib/lib'\, 'blib/arch')" t/*.t t/00_load.t ..... ok t/01_basic.t .... ok t/02_inherit.t .. ok All tests successful. Files=3\, Tests=16\, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.02 cusr 0.00 csys = 0.04 CPU) Result: PASS Files found in blib/arch: installing files in blib/lib into architecture dependent library tree Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/auto/Proc/FastSpawn/FastSpawn.so Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/Proc/FastSpawn.pm Installing /home/jkeenan/perl5/man/man3/Proc::FastSpawn.3pm Appending installation info to /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/perllocal.pod -> OK Successfully tested Proc-FastSpawn-1.2 Searching AnyEvent on cpanmetadb ... --> Working on AnyEvent Fetching http://www.cpan.org/authors/id/M/ML/MLEHMANN/AnyEvent-7.07.tar.gz -> OK Unpacking AnyEvent-7.07.tar.gz Entering AnyEvent-7.07 Checking configure dependencies from META.json Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.98) Configuring AnyEvent-7.07 Running Makefile.PL

*** *** The EV module is recommended for even better performance\, unless you *** have to use one of the other adaptors (Event\, Glib\, Tk\, etc.). *** The Async::Interrupt module is highly recommended to efficiently avoid *** race conditions in/with other event loops. *** *** This module does not have ANY dependencies\, even if it might look *** otherwise. If you are building a distribution package or have *** difficulties installing this package due to dependencies\, report this *** to the packager as a bug. *** *** This module is guaranteed to stay 100% pure-perl\, full-featured *** and performant\, even without any of the optional modules. ***

Checking if your kit is complete... Looks good Generating a Unix-style Makefile Writing Makefile for AnyEvent Writing MYMETA.yml and MYMETA.json -> OK Checking dependencies from MYMETA.json ... Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.98) Building and testing AnyEvent-7.07 cp lib/AnyEvent/Impl/Irssi.pm blib/lib/AnyEvent/Impl/Irssi.pm cp lib/AnyEvent/Impl/EventLib.pm blib/lib/AnyEvent/Impl/EventLib.pm cp lib/AnyEvent/constants.pl blib/arch/AnyEvent/constants.pl cp lib/AnyEvent/Impl/POE.pm blib/lib/AnyEvent/Impl/POE.pm cp lib/AnyEvent/Log.pm blib/lib/AnyEvent/Log.pm cp lib/AnyEvent/IO.pm blib/lib/AnyEvent/IO.pm cp lib/AnyEvent/Impl/Glib.pm blib/lib/AnyEvent/Impl/Glib.pm cp lib/AE.pm blib/lib/AE.pm cp lib/AnyEvent/Impl/Tk.pm blib/lib/AnyEvent/Impl/Tk.pm cp lib/AnyEvent/Intro.pod blib/lib/AnyEvent/Intro.pod cp lib/AnyEvent/FAQ.pod blib/lib/AnyEvent/FAQ.pod cp lib/AnyEvent/Handle.pm blib/lib/AnyEvent/Handle.pm cp lib/AnyEvent/Util.pm blib/lib/AnyEvent/Util.pm cp lib/AnyEvent/IO/IOAIO.pm blib/lib/AnyEvent/IO/IOAIO.pm cp lib/AnyEvent/Util/uts46data.pl blib/lib/AnyEvent/Util/uts46data.pl cp lib/AnyEvent/Socket.pm blib/lib/AnyEvent/Socket.pm cp lib/AnyEvent/Impl/FLTK.pm blib/lib/AnyEvent/Impl/FLTK.pm cp lib/AnyEvent/Util/idna.pl blib/lib/AnyEvent/Util/idna.pl cp lib/AnyEvent/Impl/Event.pm blib/lib/AnyEvent/Impl/Event.pm cp lib/AnyEvent/Strict.pm blib/lib/AnyEvent/Strict.pm cp lib/AnyEvent/Debug.pm blib/lib/AnyEvent/Debug.pm cp lib/AnyEvent/Impl/IOAsync.pm blib/lib/AnyEvent/Impl/IOAsync.pm cp lib/AnyEvent/TLS.pm blib/lib/AnyEvent/TLS.pm cp lib/AnyEvent/Impl/EV.pm blib/lib/AnyEvent/Impl/EV.pm cp lib/AnyEvent/Impl/Qt.pm blib/lib/AnyEvent/Impl/Qt.pm cp lib/AnyEvent/Impl/Perl.pm blib/lib/AnyEvent/Impl/Perl.pm cp lib/AnyEvent/Loop.pm blib/lib/AnyEvent/Loop.pm cp lib/AnyEvent/IO/Perl.pm blib/lib/AnyEvent/IO/Perl.pm cp lib/AnyEvent/DNS.pm blib/lib/AnyEvent/DNS.pm cp lib/AnyEvent.pm blib/lib/AnyEvent.pm cp lib/AnyEvent/Impl/Cocoa.pm blib/lib/AnyEvent/Impl/Cocoa.pm Manifying blib/man3/AE.3pm Manifying blib/man3/AnyEvent.3pm Manifying blib/man3/AnyEvent::DNS.3pm Manifying blib/man3/AnyEvent::Debug.3pm Manifying blib/man3/AnyEvent::FAQ.3pm Manifying blib/man3/AnyEvent::Handle.3pm Manifying blib/man3/AnyEvent::IO.3pm Manifying blib/man3/AnyEvent::IO::IOAIO.3pm Manifying blib/man3/AnyEvent::IO::Perl.3pm Manifying blib/man3/AnyEvent::Impl::Cocoa.3pm Manifying blib/man3/AnyEvent::Impl::EV.3pm Manifying blib/man3/AnyEvent::Impl::Event.3pm Manifying blib/man3/AnyEvent::Impl::EventLib.3pm Manifying blib/man3/AnyEvent::Impl::FLTK.3pm Manifying blib/man3/AnyEvent::Impl::Glib.3pm Manifying blib/man3/AnyEvent::Impl::IOAsync.3pm Manifying blib/man3/AnyEvent::Impl::Irssi.3pm Manifying blib/man3/AnyEvent::Impl::POE.3pm Manifying blib/man3/AnyEvent::Impl::Perl.3pm Manifying blib/man3/AnyEvent::Impl::Qt.3pm Manifying blib/man3/AnyEvent::Impl::Tk.3pm Manifying blib/man3/AnyEvent::Intro.3pm Manifying blib/man3/AnyEvent::Log.3pm Manifying blib/man3/AnyEvent::Loop.3pm Manifying blib/man3/AnyEvent::Socket.3pm Manifying blib/man3/AnyEvent::Strict.3pm Manifying blib/man3/AnyEvent::TLS.3pm Manifying blib/man3/AnyEvent::Util.3pm /usr/bin/perl "-Iblib/arch" "-Iblib/lib" constants.pl.PL constants.pl Skip blib/lib/AnyEvent/Intro.pod (unchanged) Skip blib/lib/AnyEvent/Impl/Glib.pm (unchanged) Skip blib/lib/AnyEvent/FAQ.pod (unchanged) Skip blib/lib/AnyEvent/Impl/POE.pm (unchanged) Skip blib/lib/AnyEvent/Debug.pm (unchanged) Skip blib/lib/AnyEvent/Util.pm (unchanged) Skip blib/lib/AnyEvent/TLS.pm (unchanged) Skip blib/lib/AnyEvent/Log.pm (unchanged) Skip blib/lib/AnyEvent/Handle.pm (unchanged) Skip blib/lib/AnyEvent/Impl/Perl.pm (unchanged) Skip blib/lib/AE.pm (unchanged) Skip blib/lib/AnyEvent/IO.pm (unchanged) Skip blib/lib/AnyEvent/Strict.pm (unchanged) Skip blib/lib/AnyEvent/Impl/EV.pm (unchanged) Skip blib/lib/AnyEvent/Impl/Event.pm (unchanged) Skip blib/lib/AnyEvent/IO/Perl.pm (unchanged) Skip blib/lib/AnyEvent/Impl/IOAsync.pm (unchanged) Skip blib/lib/AnyEvent/Impl/Irssi.pm (unchanged) Skip blib/lib/AnyEvent/Impl/Tk.pm (unchanged) cp lib/AnyEvent/constants.pl blib/arch/AnyEvent/constants.pl Skip blib/lib/AnyEvent/Impl/FLTK.pm (unchanged) Skip blib/lib/AnyEvent/Impl/Cocoa.pm (unchanged) Skip blib/lib/AnyEvent/IO/IOAIO.pm (unchanged) Skip blib/lib/AnyEvent/DNS.pm (unchanged) Skip blib/lib/AnyEvent/Impl/Qt.pm (unchanged) Skip blib/lib/AnyEvent/Loop.pm (unchanged) Skip blib/lib/AnyEvent/Impl/EventLib.pm (unchanged) Skip blib/lib/AnyEvent/Util/uts46data.pl (unchanged) Skip blib/lib/AnyEvent/Socket.pm (unchanged) Skip blib/lib/AnyEvent/Util/idna.pl (unchanged) Skip blib/lib/AnyEvent.pm (unchanged) PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0\, 'blib/lib'\, 'blib/arch')" t/*.t t/handle/*.t t/00_load.t ................ ok t/01_basic.t ............... ok t/02_signals.t ............. ok t/03_child.t ............... ok t/04_condvar.t ............. ok t/05_dns.t ................. ok t/06_socket.t .............. ok t/07_io.t .................. ok t/08_idna.t ................ ok t/09_multi.t ............... ok t/10_loadall.t ............. ok t/11_io_perl.t ............. ok t/12_io_ioaio.t ............ skipped: AnyEvent::IO::IOAIO not loadable t/61_fltk_01_basic.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/61_fltk_02_signals.t ..... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/61_fltk_03_child.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/61_fltk_04_condvar.t ..... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/61_fltk_05_dns.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/61_fltk_07_io.t .......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/61_fltk_09_multi.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/62_cocoa_01_basic.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/62_cocoa_02_signals.t .... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/62_cocoa_03_child.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/62_cocoa_04_condvar.t .... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/62_cocoa_05_dns.t ........ skipped: PERL_ANYEVENT_LOOP_TESTS not true t/62_cocoa_07_io.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/62_cocoa_09_multi.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/64_glib_01_basic.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/64_glib_02_signals.t ..... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/64_glib_03_child.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/64_glib_04_condvar.t ..... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/64_glib_05_dns.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/64_glib_07_io.t .......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/64_glib_09_multi.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/65_event_01_basic.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/65_event_02_signals.t .... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/65_event_03_child.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/65_event_04_condvar.t .... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/65_event_05_dns.t ........ skipped: PERL_ANYEVENT_LOOP_TESTS not true t/65_event_07_io.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/65_event_09_multi.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/66_ioasync_01_basic.t .... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/66_ioasync_02_signals.t .. skipped: PERL_ANYEVENT_LOOP_TESTS not true t/66_ioasync_03_child.t .... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/66_ioasync_04_condvar.t .. skipped: PERL_ANYEVENT_LOOP_TESTS not true t/66_ioasync_05_dns.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/66_ioasync_07_io.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/66_ioasync_09_multi.t .... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/67_tk_01_basic.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/67_tk_02_signals.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/67_tk_03_child.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/67_tk_04_condvar.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/67_tk_05_dns.t ........... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/67_tk_07_io.t ............ skipped: PERL_ANYEVENT_LOOP_TESTS not true t/67_tk_09_multi.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/68_poe_01_basic.t ........ skipped: PERL_ANYEVENT_LOOP_TESTS not true t/68_poe_02_signals.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/68_poe_03_child.t ........ skipped: PERL_ANYEVENT_LOOP_TESTS not true t/68_poe_04_condvar.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/68_poe_05_dns.t .......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/68_poe_07_io.t ........... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/68_poe_09_multi.t ........ skipped: PERL_ANYEVENT_LOOP_TESTS not true t/69_ev_01_basic.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/69_ev_02_signals.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/69_ev_03_child.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/69_ev_04_condvar.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/69_ev_05_dns.t ........... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/69_ev_07_io.t ............ skipped: PERL_ANYEVENT_LOOP_TESTS not true t/69_ev_09_multi.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/80_ssltest.t ............. ok t/81_hosts.t ............... ok t/handle/01_readline.t ..... ok t/handle/02_write.t ........ ok t/handle/03_http_req.t ..... skipped: PERL_ANYEVENT_NET_TESTS environment variable not set t/handle/04_listen.t ....... ok All tests successful. Files=75\, Tests=665\, 8 wallclock secs ( 0.23 usr 0.04 sys + 1.14 cusr 0.18 csys = 1.59 CPU) Result: PASS /usr/bin/perl "-Iblib/arch" "-Iblib/lib" constants.pl.PL constants.pl Files found in blib/arch: installing files in blib/lib into architecture dependent library tree Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/constants.pl Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AE.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Socket.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/IO.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Log.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Handle.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Intro.pod Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Strict.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Debug.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Util.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/TLS.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/DNS.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Loop.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/FAQ.pod Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/IO/Perl.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/IO/IOAIO.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Util/idna.pl Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Util/uts46data.pl Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Impl/Tk.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Impl/Qt.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Impl/FLTK.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Impl/EventLib.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Impl/Irssi.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Impl/Perl.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Impl/POE.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Impl/EV.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Impl/Cocoa.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Impl/Event.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Impl/Glib.pm Installing /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/AnyEvent/Impl/IOAsync.pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Log.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Impl::Cocoa.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Impl::Event.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Intro.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Handle.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::IO::Perl.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::FAQ.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Impl::Glib.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::TLS.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Impl::Irssi.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Impl::EV.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::IO::IOAIO.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::DNS.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Strict.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::IO.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Socket.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Impl::Perl.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Util.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Impl::Qt.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Impl::IOAsync.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Impl::Tk.3pm Installing /home/jkeenan/perl5/man/man3/AE.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Impl::POE.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Impl::EventLib.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Impl::FLTK.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Loop.3pm Installing /home/jkeenan/perl5/man/man3/AnyEvent::Debug.3pm Appending installation info to /home/jkeenan/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/perllocal.pod -> OK Successfully tested AnyEvent-7.07 Building and testing AnyEvent-Fork-1.2 cp Fork/Early.pm blib/lib/AnyEvent/Fork/Early.pm cp Fork/Template.pm blib/lib/AnyEvent/Fork/Template.pm cp Fork.pm blib/lib/AnyEvent/Fork.pm cp Fork/Serve.pm blib/lib/AnyEvent/Fork/Serve.pm Manifying blib/man3/AnyEvent::Fork.3pm Manifying blib/man3/AnyEvent::Fork::Early.3pm Manifying blib/man3/AnyEvent::Fork::Template.3pm PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0\, 'blib/lib'\, 'blib/arch')" t/*.t t/00_load.t ...... ok t/01_early.t ..... ok t/02_template.t .. ok t/03_new.t ....... ok t/04_tofrom.t .... ok All tests successful. Files=5\, Tests=34\, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.10 cusr 0.01 csys = 0.13 CPU) Result: PASS -> OK Successfully tested AnyEvent-Fork-1.2 Expiring 4 work directories.

p5pRT commented 10 years ago

From @Hugmeir

On Thu\, May 29\, 2014 at 2:53 PM\, James E Keenan via RT \perlbug\-followup@perl\.org wrote:

On Wed May 28 22:35:21 2014\, aristotle wrote:

a CPAN.pm-style verbose log is stored in ~/.cpanm/work/*/build.log (with one work subdirectory created per install run)\, and the latest build.log and work subdir are symlinked as ~/.cpanm/build.log and .../latest- build respectively.

Please find attached the build log from my PASS on AnyEvent::Fork using 'cpanm'. Thanks\, Aristotle\, for that suggestion.

--- via perlbug: queue: perl5 status: open https://rt-archive.perl.org/perl5/Ticket/Display.html?id=121970

cpanm (App::cpanminus) 1.7001 on perl 5.018002 built for x86_64-linux-gnu-thread-multi

There's the problem. cpanm is using 5.18\, not 5.20.

In any case. I can reproduce this. The problem is this line:

https://metacpan.org/source/MLEHMANN/AnyEvent-Fork-1.2/Fork.pm#L630

which is using the deprecated construct that now warns; Something else (common::sense?) is turning on fatalized warnings. Fix would be to actually use $^X instead of a literal \30

p5pRT commented 10 years ago

From schmorp@schmorp.de

[If anybody wnats to reply and wants my attention\, please CC: me in any replies\, as otherwise I might not see it]

On Thu\, May 29\, 2014 at 03:01:48PM +0200\, Brian Fraser \fraserbn@gmail\.com wrote:

which is using the deprecated construct that now warns; Something else (common::sense?) is turning on fatalized warnings. Fix would be to actually use $^X instead of a literal \30

Thanks to Andreas for bringing this to my attention.

So\, again perl5porters break perl for no good reason.

First of all\, this is documented syntax in 5.18\, and I don't see it deprecated anywhere in perlvar (which documents this variable name syntax). Secondly\, I don't see why an existing warning category is changed\, again\, in a backwards-incompatible way.

Sure\, it's often easy to fix these _perl_ bugs in my modules (and in fact\, this has already been changed in the CVS version of that module for a while)\, but the point is\, I simply shouldn't have to in the first place!

Lately\, ignoring or actively opposing compatibility with earlier versions of Perl has come into vogue.

Down this road lies madness.

Requiring end-user programmers to change just a few language constructs\, even language constructs which no well-educated developer would ever intentionally use is tantamount to saying "you should not upgrade to a new release of Perl unless you have 100% test coverage and can do a full manual audit of your codebase."

-- The choice of a Deliantra\, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_\,_/ /_/\_\

p5pRT commented 10 years ago

From @Hugmeir

On Sat\, May 31\, 2014 at 8:52 PM\, Marc Lehmann \schmorp@schmorp\.de wrote:

[If anybody wnats to reply and wants my attention\, please CC: me in any replies\, as otherwise I might not see it]

On Thu\, May 29\, 2014 at 03:01:48PM +0200\, Brian Fraser \fraserbn@gmail\.com wrote:

which is using the deprecated construct that now warns; Something else (common::sense?) is turning on fatalized warnings. Fix would be to actually use $^X instead of a literal \30

Thanks to Andreas for bringing this to my attention.

So\, again perl5porters break perl for no good reason.

First of all\, this is documented syntax in 5.18\, and I don't see it deprecated anywhere in perlvar (which documents this variable name syntax).

perldata\, under "Identifier parsing". perldelta as well.

Secondly\, I don't see why an existing warning category is changed\, again\, in a backwards-incompatible way.

I don't follow. It's a new deprecation warning under the 'deprecated' category. Are you saying that p5p shouldn't add new warnings to existing categories? Or add new default categories..?

Sure\, it's often easy to fix these _perl_ bugs in my modules (and in fact\, this has already been changed in the CVS version of that module for a while)\, but the point is\, I simply shouldn't have to in the first place!

Lately\, ignoring or actively opposing compatibility with earlier versions of Perl has come into vogue.

Reasoning for this deprecation is here: https://rt.perl.org/Public/Bug/Display.html?id=119123

p5pRT commented 10 years ago

From schmorp@schmorp.de

On Sat\, May 31\, 2014 at 09:54:50PM +0200\, Brian Fraser \fraserbn@gmail\.com wrote:

First of all\, this is documented syntax in 5.18\, and I don't see it deprecated anywhere in perlvar (which documents this variable name syntax).

perldata\, under "Identifier parsing".

Hmm\, it doesn't seem to be in my version of that manpage. In fact\, perldata says\, in that section:

A sigil\, followed by either a caret and a single POSIX uppercase letter\, like $^V or $^W\, or a sigil followed by a literal control character matching the "\p{POSIX_Cntrl}" property.

In any case\, perldata is entirely the wrong manpage (it's about perl data types - variable names are not a data type. If anywhere\, it should be in perlsyn\, and certainly perlvar needs to be updated).

Secondly\, I don't see why an existing warning category is changed\, again\, in a backwards-incompatible way.

I don't follow. It's a new deprecation warning under the 'deprecated' category. Are you saying that p5p shouldn't add new warnings to existing categories? Or add new default categories..?

I think p5p should follow the official policy on backwards compatibility\, or change the policy to be more honest\, as in "we do not care about compatibility anymore"\, which\, while not entirely correct\, matches reality far better than the current wording.

I can provide a patch for the wording. At least\, people would then know they can't rely on perl keeping backwards compatibility and the mentioned madness has finally caught on.

As for the actual deprecation\, obviously this syntax shouldn't be deprecated in the first place\, as it doesn't hurt anybody and there is no demonstrated need for change (so it's the worst change possible). The reasonable and backwards-compatible way would be to add a new warning category for this\, as is done with other language constructs that can be potential pitfalls to some people (such as use of "undef"\, which fortunately isn't deprecated either).

Lately\, ignoring or actively opposing compatibility with earlier versions of Perl has come into vogue.

Reasoning for this deprecation is here: https://rt.perl.org/Public/Bug/Display.html?id=119123

Well\, if you read through it\, it seems this worked in 5.12.4 and broke in 5.17 (according to the original report).

I don't see any sensible arguments or reasoning in there\, either. The original report basically argues that\, since EBCDIC has a different idea of literal control characters\, it should be broken for non-EBCDIC platforms as well\, which is clearly unreasonable.

It goes on like this:

Fully support that deprecation. +1 +1 This will break one of my programs. I say go for it :-) +1

and so on\, followed by discussion on how to break it best.

Infact\, this is the perfect illustration of the mindset at work here: it breaks existing scripts\, go for it\, other arguments not required! There are absolutely zero arguments for deprecating this feature in there (as oppposed to e.g. ading a new warning for it\, as e.g. done for undef).

If anything\, this actually reinforces what I wrote and quoted before.

-- The choice of a Deliantra\, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_\,_/ /_/\_\

p5pRT commented 10 years ago

From @khwilliamson

I do not believe that having a non-printable character in open source code is defensible. It serves no purpose other than obfuscation\, making the code needlessly harder to decipher.

I also believe that Perl need not try very hard to maintain backwards compatibility for indefensible practices.

p5pRT commented 10 years ago

From schmorp@schmorp.de

On Sat\, May 31\, 2014 at 03:14:09PM -0600\, Karl Williamson \public@khwilliamson\.com wrote:

I do not believe that having a non-printable character in open source code is defensible. It serves no purpose other than obfuscation\, making the code needlessly harder to decipher.

I also believe that Perl need not try very hard to maintain backwards compatibility for indefensible practices.

You are entitled to your beliefs\, of course\, but the problem persists that this is against official policy. If p5p feels that backwards compatibility is no longer important\, then the policy needs updating.

I did offer to create a patch for it.

It is very jarring to read the policy\, and then\, when reporting a bug\, finding out it's really just a lie\, as happened to me many times in the past.

I know that the policy wasn't a lie when it was written\, but clearly\, the new p5pers have silently adopted a different one. If p5p really thinks the policy is to be changed\, then it must be changed. It doesn't perl do any good to make sweeping claims about backwards compatibility when its maintainers have no intention to actually act accordingly.

My personal opinion is that breaking compatibility with CPAN because you think it isn't defensible isn't a worthy position to have\, as the problem is not whether it is defensible\, the problem here is that it breaks existing code without any need.

As such\, you are completely missing the point - so far\, nobody "defended" that feature.

-- The choice of a Deliantra\, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_\,_/ /_/\_\

p5pRT commented 10 years ago

From @ikegami

On Sat\, May 31\, 2014 at 2:52 PM\, Marc Lehmann \schmorp@schmorp\.de wrote:

[If anybody wnats to reply and wants my attention\, please CC: me in any replies\, as otherwise I might not see it]

On Thu\, May 29\, 2014 at 03:01:48PM +0200\, Brian Fraser \fraserbn@gmail\.com wrote:

which is using the deprecated construct that now warns; Something else (common::sense?) is turning on fatalized warnings. Fix would be to actually use $^X instead of a literal \30

Thanks to Andreas for bringing this to my attention.

So\, again perl5porters break perl for no good reason.

First of all\, this is documented syntax in 5.18\, and I don't see it deprecated anywhere in perlvar (which documents this variable name syntax).

What do you mean by that? All 5.20 did was to deprecate it. Are you saying it should have been done in 5.18 instead???

Secondly\, I don't see why an existing warning category is changed\, again\, in a backwards-incompatible way.

It's a new warning. It didn't have a category to change. Or are you saying that each time a warning is added\, a new category should be created for it.

Sure\, it's often easy to fix these _perl_ bugs in my modules (and in fact\, this has already been changed in the CVS version of that module for a while)\, but the point is\, I simply shouldn't have to in the first place!

Except you just said it should have been deprecated in 5.18\, so why are you complaining about it getting deprecated in 5.20?!

Requiring end-user programmers to change just a few language constructs\,

even language constructs which no well-educated developer would ever intentionally use is tantamount to saying "you should not upgrade to a new release of Perl unless you have 100% test coverage and can do a full manual audit of your codebase."

What? It's a compile-time warning.

p5pRT commented 10 years ago

From @khwilliamson

On 05/31/2014 03:40 PM\, Marc Lehmann wrote:

My personal opinion is that breaking compatibility with CPAN because you think it isn't defensible isn't a worthy position to have\, as the problem is not whether it is defensible\, the problem here is that it breaks existing code without any need.

As such\, you are completely missing the point - so far\, nobody "defended" that feature.

My response is that it is you who are completely missing the point. If this (mis)feature hadn't caused us any problems\, nobody would have realized that we supported something that is indefensible\, and it would have remained unchanged. The ticket that Brian gave you gave reasons for why this is causing us problems.

What is unstated in that ticket is that underlying those problems is the change we made earlier so that now a Vertical Tab is considered white space. This change was made to make Perl compatible with the Unicode standard\, which we purport to support.

So what it comes down to is a conflict with being Unicode compatible and breaking something that is extremely rarely used and which is poor practice to begin with. It is clear to me that we made the right choice\, and I believe that a poll of CPAN authors would overwhelmingly concur.

Perl will not be 100% backward compatible as we move forward. We will not knowingly break existing modules unless the benefits greatly outweigh the costs.

Coincidentally\, today I happened across a response that you wrote in https://rt-archive.perl.org/perl5/Ticket/Display.html?id=120386 It sounds to me like you are advocating deprecating av_len() because we have come up with more honest names about what it returns. But we didn't deprecate it because there are a lot of CPAN modules that use it. Your position seems inconsistent\, while p5p's seems consistent to me

p5pRT commented 10 years ago

From @andk

"karl williamson via RT" \perlbug\-followup@perl\.org writes:

My response is that it is you who are completely missing the point.

Are we in a competition about who is missing the point more than the other? I do not think so. What's at stake is Perl\, not p5p vs. schmorp.

If this (mis)feature hadn't caused us any problems\, nobody would have realized that we supported something that is indefensible\, and it would have remained unchanged. The ticket that Brian gave you gave reasons for why this is causing us problems.

What is unstated in that ticket is that underlying those problems is the change we made earlier so that now a Vertical Tab is considered white space. This change was made to make Perl compatible with the Unicode standard\, which we purport to support.

You're stating sloppiness in the ticket. This is what needs to be overcome. Sloppiness in the argumentation in tickets is unacceptable. We need to perform better in this regard. There's nothing to defend here. If the argumentation in a ticket is insufficient then the one that loses is Perl.

I have some plans how to improve the detection of "Bleadperl breaks CPAN" cases in the future so that the misses that came up so late this year will be minimized in the future. But I have no chances whatsoever to fix sloppiness in the argumentation in the tickets themselves.

-- andreas

p5pRT commented 10 years ago

From schmorp@schmorp.de

First of all\, this is documented syntax in 5.18\, and I don't see it deprecated anywhere in perlvar (which documents this variable name syntax).

What do you mean by that? All 5.20 did was to deprecate it. Are you saying it should have been done in 5.18 instead???

It breaks existing code\, and is yet another non-backwards compatible change\, is against perlpolicy\, and was done for no comprehensible reason.

Secondly\, I don't see why an existing warning category is changed\, again\, in a backwards-incompatible way.

It's a new warning. It didn't have a category to change. Or are you saying that each time a warning is added\, a new category should be created for it.

I would actually greatly prefer that\, but that's not really relevant\, so I don't want to go too deeply into this.

Except you just said it should have been deprecated in 5.18\, so why are you complaining about it getting deprecated in 5.20?!

Actually\, it is you who said that\, not me. I am clearly complaining about backwards compatibility\, and don't think it should be deprecated at all (since there are no reasons to deprecate it\, as opposed to e.g. adding a new warning category).

Requiring end-user programmers to change just a few language constructs\,

even language constructs which no well-educated developer would ever intentionally use is tantamount to saying "you should not upgrade to a new release of Perl unless you have 100% test coverage and can do a full manual audit of your codebase."

What? It's a compile-time warning.

Yes\, it is a compile time warning. You seem to think that changes something - what?

-- The choice of a Deliantra\, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_\,_/ /_/\_\

p5pRT commented 10 years ago

From @jkeenan

On Thu May 29 06:02:16 2014\, Hugmeir wrote:

There's the problem. cpanm is using 5.18\, not 5.20.

In any case. I can reproduce this. The problem is this line:

https://metacpan.org/source/MLEHMANN/AnyEvent-Fork-1.2/Fork.pm#L630

which is using the deprecated construct that now warns; Something else (common::sense?) is turning on fatalized warnings. Fix would be to actually use $^X instead of a literal \30

Today I used a series of shell programs given to me several months ago by khw to test CPAN modules against blead\, using cpanm to locate the modules.

*Assuming* I am correctly using khw's programs\, I find that AnyEvent::Fork is passing all its tests against blead.

##### $ /home/jkeenan/testing/blead/bin/perl -v This is perl 5\, version 21\, subversion 1 (v5.21.1 (v5.21.0-220-g0ed2b00)) built for x86_64-linux

$ pwd /home/jkeenan/.cpanm/work/1401577598.15363/AnyEvent-Fork-1.2

$ /home/jkeenan/testing/blead/bin/perl Makefile.PL Checking if your kit is complete... Looks good Generating a Unix-style Makefile Writing Makefile for AnyEvent::Fork Writing MYMETA.yml and MYMETA.json

$ make cp Fork/Template.pm blib/lib/AnyEvent/Fork/Template.pm cp Fork/Serve.pm blib/lib/AnyEvent/Fork/Serve.pm cp Fork/Early.pm blib/lib/AnyEvent/Fork/Early.pm cp Fork.pm blib/lib/AnyEvent/Fork.pm

$ make test PERL_DL_NONLAZY=1 /home/jkeenan/testing/blead/bin/perl "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0\, 'blib/lib'\, 'blib/arch')" t/*.t t/00_load.t ...... ok
t/01_early.t ..... ok
t/02_template.t .. ok
t/03_new.t ....... ok
t/04_tofrom.t .... ok
All tests successful. Files=5\, Tests=34\, 1 wallclock secs ( 0.06 usr 0.01 sys + 0.21 cusr 0.04 csys = 0.32 CPU) Result: PASS

p5pRT commented 10 years ago

From schmorp@schmorp.de

On Sat\, May 31\, 2014 at 04:46:04PM -0600\, Karl Williamson \public@khwilliamson\.com wrote:

As such\, you are completely missing the point - so far\, nobody "defended" that feature.

My response is that it is you who are completely missing the point. If this (mis)feature hadn't caused us any problems\, nobody would have realized that we supported something that is indefensible

It's quite scary to hear from the people maintaining p5p that they have no clue what perl actually implements.

I am sorry\, but if _really_ nobody realised that before\, why the heck do you think you can make decisions regarding perl *at all*? Shouldn't you know your subject before deciding it's future?

For the record\, I was well aware of this feature\, even though I never consciously used it anywhere. But then\, I am doing perl for quite a while now\, and actually did read its documentation in the beginning.

Anyway\, this is about ignoring existing policy and breaking backwards compatibility. Your attempt to change the topic to whether something is defensible or not completely misses the point.

would have remained unchanged. The ticket that Brian gave you gave reasons for why this is causing us problems.

I actually analysed the ticket\, and found no such reasons. Can you point them out to me?

What is unstated in that ticket is that underlying those problems is the change we made earlier so that now a Vertical Tab is considered white space. This change was made to make Perl compatible with the Unicode standard\, which we purport to support.

Ok\, so you admit that this was a change introduced earlier. So far\, so good.

However\, your argument is\, sorry to be so blunt\, bullshit you just made up: nothing in the Unicode standard forces you to treat vertical tab as whitespace in Perl.

If you disagree\, you surely can point me to the section in the unicode standard that requires that?

Do you really claim that 5.20 is the first perl version that supports unicode? Because of this change? Or no versions of Perl support unicode\, because they don't have this change?

So what it comes down to is a conflict with being Unicode compatible

There is no such conflict. The unicode standard doesn't require specific syntax for computer languages (such as not allowing whitespace in identifiers)\, plain and simple.

and breaking something that is extremely rarely used and which is poor practice to begin with.

Again\, this is completely missing the point. Perl policy doesn't allow you to break compatibility without need\, whether a feature is rarely used or not.

In fact\, it's quite scary that you argue that rarely used features in Perl deserve no backwards compatibility.

But then\, if that opinion is indeed the majority or ruling opinion\, then please update the policy to something more honest. Admit it. Don't claim you care\, when you clearly don't.

It is clear to me that we made the right choice\, and I believe that a poll of CPAN authors would overwhelmingly concur.

Religion-like statements will not bring any solution to this - I can make up statistics as good as you\, but that doesn't make them true either.

I am also not sure what a majority opinion of CPAN authors should mean - so backwards compatibility is not important because you "believe" that the majority of CPAN authors do not want it? What kind of argument is this supposed to be?

Perl will not be 100% backward compatible as we move forward. We will not knowingly break existing modules unless the benefits greatly outweigh the costs.

The benefits clearly don't outweigh the costs - there are no benefits (as opposed to more reasonable changes that I have pointed out). And now you know that it breaks existing modules\, so this is the time to act.

Nobody complains that you get it wrong some of the time. I (and others) complain that you get it wrong and then refuse to fix or revert it\, while making up bullshit arguments to rationalise it as you go.

Also\, I wonder\, do you only care for modules? You didn't mention other perl code\, which\, IMnsHO\, is quite as important as well.

Coincidentally\, today I happened across a response that you wrote in https://rt-archive.perl.org/perl5/Ticket/Display.html?id=120386 It sounds to me like you are advocating deprecating av_len() because

You obviously didn't care to read it closely then (your former self commenting in that bug report clearly understood that this was about the documentation).

Nowhere in there did I even come close to advocating it. The closest I came was this conditional:

"If the idea is to deprecate it's use (which these changes kind of seem to want)\, why not simply document that..."

And:

"It's only my opinion\, but introducing two extra names without deprecating (not: removing!)"

Neither of these advocate deprecating it\, they just point out that if you cna only chose between two wrongs\, that's the lesser of the two.

It's especially interesting that this change also doesn't break any backwards compatibility\, which makes me wonder if you even understand the issue at hand.

we have come up with more honest names about what it returns. But we didn't deprecate it because there are a lot of CPAN modules that use it. Your position seems inconsistent\, while p5p's seems consistent to me

My position is absolutely consistent\, and consistent with existing perl policy\, as long as you don't try to twist what I wrote in that bugreport. And since then you clearly understood that this is about documentation. I cannot stop myself from finding you disingenous now.

I do\, however\, agree that p5p's position seems to be consistent\, too\, at least in recent years: perl policy doesn't matter\, backwards-compatibility breaking changes are fine\, regardless of the costs\, changes do not need rational motivation\, beliefs are enough.

What isn't consistent is the documented perl policy and the p5p position though\, something I keep pointing out and you keep ignoring (why?).

I argue that backwards compatibility is enourmously important\, something the authors of the perl policy clearly acknowledge\, in no uncertain words (have you bothered to read it?)\, and that this is not reflected by the behaviour of p5p in recent years\, which doesn't care for breaking lots of code\, and when confronted\, fails to come with a rational explanation.

So yes\, the p5p position is internally consistent\, but not consistent with perl itself. The fact that so many p5pers freely admit that a) they don't know perl well enough in certain areas and b) still think they are entitled to making decisions in those areas is just scary - you are clearly not in a position to do so\, and that is clearly not what a reasonable person should do.

-- The choice of a Deliantra\, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_\,_/ /_/\_\

p5pRT commented 10 years ago

From @ikegami

On Sat\, May 31\, 2014 at 7:36 PM\, Marc Lehmann \schmorp@schmorp\.de wrote:

First of all\, this is documented syntax in 5.18\, and I don't see it deprecated anywhere in perlvar (which documents this variable name syntax).

What do you mean by that? All 5.20 did was to deprecate it. Are you saying it should have been done in 5.18 instead???

It breaks existing code and is yet another non-backwards compatible

change\, is against perlpolicy\, and was done for no comprehensible reason.

Wow. Wrong\, wrong and wrong!

1. It didn't break any code. Your code successfully threw an error on deprecations as requested. If you don't want deprecations to throw an error\, don't ask Perl to do it!

2. Non-backwards compatible changes are not against policy.

3. It was done for a very easy to comprehend reason.

Requiring end-user programmers to change just a few language constructs\,

even language constructs which no well-educated developer would ever intentionally use is tantamount to saying "you should not upgrade to a new release of Perl unless you have 100% test coverage and can do a full manual audit of your codebase."

What? It's a compile-time warning.

Yes\, it is a compile time warning. You seem to think that changes something - what?

It doesn't takes 100% coverage to find a compile-time warning. In fact\, it requires absolutely no coverage.

p5pRT commented 10 years ago

From schmorp@schmorp.de

It breaks existing code and is yet another non-backwards compatible

change\, is against perlpolicy\, and was done for no comprehensible reason.

Wow. Wrong\, wrong and wrong!

1. It didn't break any code. Your code successfully threw an error on deprecations as requested. If you don't want deprecations to throw an error\, don't ask Perl to do it!

That's a non-sequitur: the breakage here is the extra warning\, not the fact that it is made fatal. In environments which check for empty stderr to check for errors\, this breaks any script that uses warnings non-fatally.

Fatality is not breaking backwards compatibility further.

Furthermore\, deprecating something is not done to warn people about dangerous constructs\, it's done to remove functionality later\, which is then another backwards compatible change.

2. Non-backwards compatible changes are not against policy.

I agree - Of course\, the goal of deprecating things is to remove them later\, so no matter what\, this is about breaking backwards compatibility.

A backwards compatible change would be a new warning category that users can enable\, and not deprecating this feature at all.

3. It was done for a very easy to comprehend reason.

Maybe\, but the requirement is for the reason to be rational and strong enough to outweigh the breakage\, which is clearly not the case here.

For example\, Lukas Mai gave "This will break one of my programs." as reason. This is easy to understand\, but without any merit\, of course.

What? It's a compile-time warning.

Yes\, it is a compile time warning. You seem to think that changes something - what?

It doesn't takes 100% coverage to find a compile-time warning. In fact\, it requires absolutely no coverage.

I am not sure you understand Perl well enough here - Perl doesn't compile all code before running your program (it is impossible)\, so you do need 100% coverage - code that isn't compiled\, will not be tested.

Besides\, you are ignoring the other arguments I quoted\, as well as other parts in perlpolicy I haven't quoted\, for example:

Existing syntax and semantics should only be marked for destruction in very limited circumstances. If a given language feature's continued inclusion in the language will cause significant harm to the language or prevent us from making needed changes to the runtime\, then it may be considered for deprecation.

Where is the signifcant harm caused by this feature? This change is just a political change: some p5pers don't like the syntax\, so it has to go\, whether it causes signifcant harm or not doesn't matter.

Moreso:

Any language change which breaks backward-compatibility should be able to be enabled or disabled lexically. Unless code at a given scope declares that it wants the new behavior\, that new behavior should be disabled.

That should be easily possible here. Also\, the documented standard is much higher than you and others assume:

Historically\, we've held ourselves to a far higher standard than backward-compatibility -- bugward-compatibility. Any accident of implementation or unintentional side-effect of running some bit of code has been considered to be a feature of the language to be defended with the same zeal as any other feature or functionality. No matter how frustrating these unintentional features may be to us as we continue to improve Perl\, these unintentional features often deserve our protection. It is very important that existing software written in Perl continue to work correctly. If end-user developers have adopted a bug as a feature\, we need to treat it as such.

I haven't seen you addressing these discrepancies at all.

-- The choice of a Deliantra\, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_\,_/ /_/\_\

p5pRT commented 10 years ago

From @greerga

On Sun\, 1 Jun 2014\, Marc Lehmann wrote:

It breaks existing code and is yet another non-backwards compatible

change\, is against perlpolicy\, and was done for no comprehensible reason.

Wow. Wrong\, wrong and wrong!

1. It didn't break any code. Your code successfully threw an error on deprecations as requested. If you don't want deprecations to throw an error\, don't ask Perl to do it!

That's a non-sequitur: the breakage here is the extra warning\, not the fact that it is made fatal. In environments which check for empty stderr to check for errors\, this breaks any script that uses warnings non-fatally.

The pumpking stated on January 27th that: "I do not consider introducing new warnings to be breaking backward compatibility in code that has specifically requested that all warnings be turned on. Instead\, it is forward compatibility: your code does not need to be altered to get new warnings."

http://grokbase.com/t/perl/perl5-porters/141t1s3z4c/perl-121085-stat-dies-on-valid-filename-not-existing#20140127hwjetculzqmqlxj5ahrtm2a7oa

The circumstance you are considering has explicitly not been considered part of the backward-compatibility guarantee. If you're going to that level of warnings-paranoia then you are on your own.

-- George Greer

p5pRT commented 10 years ago

From @greerga

On Sat\, 31 May 2014\, Marc Lehmann wrote:

[If anybody wnats to reply and wants my attention\, please CC: me in any replies\, as otherwise I might not see it]

On Thu\, May 29\, 2014 at 03:01:48PM +0200\, Brian Fraser \fraserbn@gmail\.com wrote:

which is using the deprecated construct that now warns; Something else (common::sense?) is turning on fatalized warnings. Fix would be to actually use $^X instead of a literal \30

Thanks to Andreas for bringing this to my attention.

So\, again perl5porters break perl for no good reason.

First of all\, this is documented syntax in 5.18\, and I don't see it deprecated anywhere in perlvar (which documents this variable name syntax). Secondly\, I don't see why an existing warning category is changed\, again\, in a backwards-incompatible way.

Depending on interpretation of 'perlvar'\, while the variable names internally contain a control character the actual representation documented for your program is the caret form\, not the literal control character. As such the documentation does not guarantee what you think it does.

-- George Greer

p5pRT commented 10 years ago

From @andk

"James E Keenan via RT" \perlbug\-followup@perl\.org writes:

On Thu May 29 06:02:16 2014\, Hugmeir wrote:

There's the problem. cpanm is using 5.18\, not 5.20. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

James\, did you miss this line? Please take note and fix your usage of cpanm.

-- andreas

p5pRT commented 10 years ago

From @ikegami

On Sat\, May 31\, 2014 at 9:22 PM\, Marc Lehmann \schmorp@schmorp\.de wrote:

It breaks existing code and is yet another non-backwards compatible

change\, is against perlpolicy\, and was done for no comprehensible reason.

Wow. Wrong\, wrong and wrong!

1. It didn't break any code. Your code successfully threw an error on deprecations as requested. If you don't want deprecations to throw an error\, don't ask Perl to do it!

That's a non-sequitur: the breakage here is the extra warning\, not the fact that it is made fatal. In environments which check for empty stderr to check

for errors\, this breaks any script that uses warnings non-fatally.

Same thing. Whether you are warned about deprecations or not is also a choice.

Furthermore\, deprecating something is not done to warn people about dangerous constructs\, it's done to remove functionality later\, which is then another backwards compatible change.

I agree. There's a *forthcoming* backward compatible change.

2. Non-backwards compatible changes are not against policy.

I agree - Of course\, the goal of deprecating things is to remove them later\, so no matter what\, this is about breaking backwards compatibility.

Yes. perlpolicy explains which making no such changes is untenable.

3. It was done for a very easy to comprehend reason.

Maybe\, but the requirement is for the reason to be rational and strong enough to outweigh the breakage\, which is clearly not the case here.

I wouldn't say that. To paraphrase what you said\, it only affects those who know they are using a hack. That doesn't carry much weight.

For example\, Lukas Mai gave "This will break one of my programs." as

reason. This is easy to understand\, but without any merit\, of course.

He's saying he's willing to face the consequences for doing something he knew he shouldn't have been doing. He might also be saying that others in the same boat should too.

Any language change which breaks backward-compatibility should be able

to be enabled or disabled lexically. Unless code at a given scope declares that it wants the new behavior\, that new behavior should be disabled.

That should be easily possible here. Also\, the documented standard is much higher than you and others assume:

Quite the opposite. Whether the change is to simplify the language or reduce the complexity of the internals\, making it a feature would make the problem worse.

- Eric

p5pRT commented 10 years ago

From @b2gills

First off having variables with a non-printable character in its name should have never been added to the language. Or at the very least been deprecated immediately in Perl 5.0.0. ( There is a reason Perl6 didn't copy this )

This feature only makes sense as a shell script replacement\, which is likely why it was added in the first place. It does not make sense in a general purpose programming language.

It especially doesn't make any sense to use it on any package on CPAN as not all editors will cope with it correctly. Which goes against a core principle of Open Source software\, the ability to change it.

The main reason it wasn't deprecated earlier was that nobody thought about it. Likely because the few people who even knew it worked wouldn't have used it anyway.

As to backward compatibility\, it is quite likely impossible to change the internals without breaking at least some code. Most of the time it is only XS code which breaks. ( We need a better API ) Sometimes the code that gets broken was actually already subtly broken. ( As happened with the hash key randomization in 5.18 )

So we are **NOT** going for 100% compatibility for 100% of the code in the wild. We are really going for more like 98%+ compatibility ( which is likely better than other languages in our same niche ).

(If you use any of the hairier areas of the language you increase the chances that you are in the ~2% that gets broken.)

That being said\, we do try very hard to not break any code without a good reason. ( Which we have in this case without even counting my response above ) Just because you don't agree with the reasoning\, doesn't mean it isn't a good reason. ( I only see one person disagreeing with the "official" reason. )

Any response to this message should really start a new thread on P5P as it is already getting far-afield of the original topic.

I believe I have said my piece\, and will likely not respond further.

p5pRT commented 10 years ago

From @tux

On Sat\, 31 May 2014 23:40:42 +0200\, Marc Lehmann \schmorp@schmorp\.de wrote:

On Sat\, May 31\, 2014 at 03:14:09PM -0600\, Karl Williamson \public@khwilliamson\.com wrote:

I do not believe that having a non-printable character in open source code is defensible. It serves no purpose other than obfuscation\, making the code needlessly harder to decipher.

I also believe that Perl need not try very hard to maintain backwards compatibility for indefensible practices.

You are entitled to your beliefs\, of course\, but the problem persists that this is against official policy. If p5p feels that backwards compatibility is no longer important\, then the policy needs updating.

I did offer to create a patch for it.

Many have offered *you* patches to *your* modules in the past. Some were only a few character changes\, to make your code compliant with what the rest of the perl5 developers have decided to be undeprecated perl code. You have rejected those telling the people they were wrong. Now you are using the same arguments the other way around.

It is very jarring to read the policy\, and then\, when reporting a bug\, finding out it's really just a lie\, as happened to me many times in the past.

I know that the policy wasn't a lie when it was written\, but clearly\, the new p5pers have silently adopted a different one. If p5p really thinks the policy is to be changed\, then it must be changed. It doesn't perl do any good to make sweeping claims about backwards compatibility when its maintainers have no intention to actually act accordingly.

My personal opinion is that breaking compatibility with CPAN because you think it isn't defensible isn't a worthy position to have\, as the problem is not whether it is defensible\, the problem here is that it breaks existing code without any need.

I agree with all the perl5 developers that participated int this discussion: there was *NO* backward compat breaking issue.

As such\, you are completely missing the point - so far\, nobody "defended" that feature.

-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.19 porting perl5 on HP-UX\, AIX\, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

p5pRT commented 10 years ago

From @rjbs

* Marc Lehmann \schmorp@schmorp\.de [2014-05-31T17:40:42]

On Sat\, May 31\, 2014 at 03:14:09PM -0600\, Karl Williamson \public@khwilliamson\.com wrote:

[...]

You are entitled to your beliefs\, of course\, but the problem persists that this is against official policy. If p5p feels that backwards compatibility is no longer important\, then the policy needs updating.

I did offer to create a patch for it.

I would be interested to read such a patch\, with the proviso that I will lose my mind\, tear my hair out\, and collapse in the corner if it includes text like\, "p5p doesn't care about backward compatibility." To the extent that there is an "us\," we really do.

It is very jarring to read the policy\, and then\, when reporting a bug\, finding out it's really just a lie\, as happened to me many times in the past.

I know that the policy wasn't a lie when it was written\, but clearly\, the new p5pers have silently adopted a different one.

I think the real problem is that you and (for example) I have a different reading of certain parts of this document.

For example\, there's this bit:

PP> Existing syntax and semantics should only be marked for destruction in PP> very limited circumstances. If a given language feature's continued PP> inclusion in the language will cause significant harm to the language PP> or prevent us from making needed changes to the runtime\, then it may be PP> considered for deprecation.

There's a lot of room for judgement calls\, here. "very limited" and "significant harm" and "needed changes\," for example. What changes do we *need* to make? What is the arbiter of necessity?

Is it simply "to keep compiling?" If so\, then removing support for literal control variables is obviously nonsense.

On the other hand\, I have a more liberal view — obviously. I think\, that to keep improvements viable\, we need to continue to simplify the language in places where its specifics introduce a maintenance or implementation burden that greatly outweighs the benefits. Backward-compatibility is a benefit. We weigh it *very* *very* heavily in considering changes. That doesn't always mean that it wins out.

As someone else pointed out\, I also won't put the addition of a deprecation warning into the bucket of "incompatible change\," but I believe it was you who correctly responded that the warning is not necessarily the problematic change\, but the future removal of the deprecated feature! Just so. I just want to get on record that if we start viewing the deprecation warnings themselves as incompatible changes\, we're headed for heartache. We'll update perlpolicy to make this explicit.

perlpolicy goes on:

PP> Any language change which breaks backward-compatibility should be able PP> to be enabled or disabled lexically. Unless code at a given scope PP> declares that it wants the new behavior\, that new behavior should be PP> disabled. Which backward-incompatible changes are controlled PP> implicitly by a 'use v5.x.y' is a decision which should be made by the PP> pumpking in consultation with the community. PP> PP> When a backward-incompatible change can't be toggled lexically\, the PP> decision to change the language must be considered very\, very PP> carefully. If it's possible to move the old syntax or semantics out of PP> the core language and into XS-land\, that XS module should be enabled by PP> default unless the user declares that they want a newer revision of PP> Perl.

I have a problem with this language\, because it uses one of my least favorite policy words: should. perlpolicy doesn't claim to use RFC 2119 language\, but let's quote from RFC 2119 anyway:

2119> 3. SHOULD This word\, or the adjective "RECOMMENDED"\, mean that there 2119> may exist valid reasons in particular circumstances to 2119> ignore a particular item\, but the full implications must be 2119> understood and carefully weighed before choosing a different 2119> course.

So\, did we follow this policy? I think so\, because to my mind the reason for the deprecation was to enable the simplification and unification of portions of the grammar. Enabling a lexically-scoped switch would have undermined the whole point. At that point\, the question is: is the removal really worth not just changing the default behavior\, but making it unavailable? Given the *extremely* low value that we felt backward compatibility for this little syntactic horror would have\, I felt that it was.

...but "should" stinks. When I come to "should" in an RFC\, I know that the practical impact will be that there will be a dozen different interpretations of whether and why the action of the "should" will be taken. How can we improve that language? We can add guidance for how to choose. I think that beyond that\, there isn't a lot of improvement to be made. It's a human issue that will be poorly managed by hard and fixed rules\, I think.

-- rjbs

p5pRT commented 10 years ago

From schmorp@schmorp.de

I would wish random people would actually invest a bit more time into actually reading what has already been mentioned. It doesn't help this discussion when random people like you without any clue chime in and say "you are wrong" when in fact they are just too lazy or otherwise incapable to read the documentation. Just stay out of this discussion if you are unable to add something of value.

On Sat\, May 31\, 2014 at 10:09:47PM -0400\, George Greer \perl@greerga\.m\-l\.org wrote:

Depending on interpretation of 'perlvar'\, while the variable names

The section explicitly documents the syntax of variable names\, i.e. the actual representation.

In fact\, it explicitly contradicts your wrong interpretation: "Perl variable names may be alphanumeric strings that begin with control characters (or better yet\, a caret)."

If the section would only be about "internal" names\, then the part about the caret would be wrong (${^X} and $^X are different variables\, so one cannot be "better" than the other).

Your interpretation is wishful thinking that isn't consistent with the documentation.

Of course\, if you had closely read this thread\, you could have seen that perlvar isn't the only place where this is documented\, as been pointed out multiple times. In perldata\, you can read that an identifier can be represented as "a sigil followed by a literal control character matching the "\p{POSIX_Cntrl}" property".

By your refusal to actually verify things you write before you send them you just waste my (and other people's) time. Maybe that is your goal?

As such the documentation does not guarantee what you think it does.

Well\, it obviously does\, it's you who cannot understand it\, or didn't read through it closely.

Of course\, the documentation isn't the holy grail either\, it could be wrong (and often is). What is clear is that the intent of the original authors.

Nothing of that is of relevance to this discussion at all\, as even if the documentation wouldn't document this syntax\, perl policy still virtually guarantees it's support.

-- The choice of a Deliantra\, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_\,_/ /_/\_\

p5pRT commented 10 years ago

From schmorp@schmorp.de

On Sat\, May 31\, 2014 at 10:02:28PM -0400\, George Greer \perl@greerga\.m\-l\.org wrote:

The pumpking stated on January 27th that: "I do not consider introducing new warnings to be breaking backward compatibility in code that has specifically requested that all warnings be turned on. Instead\, it is forward compatibility: your code does not need to be altered to get new warnings."

Well\, if he woulc consider the earth to be flat that still wouldn't make it so. Backwards compatibility isn't defined by what he says it is\, it means that code that worked before still works\, plain and simple.

This weird attempt at redefining what backwards compatibility means can at best be a dishonest attempt to confuse people by claiming to keep bakcwards compatibility\, when no such intent is given.

Besides\, we already know that the pumpkin allows other forms of backwards compatibility breakage that have nothing to do with warnings.

Maybe he also considers warn not worthy of backwards compatibility. Or hash order. Or given/when\, or ...

The circumstance you are considering has explicitly not been considered part of the backward-compatibility guarantee.

The important point to understand is that the perl pumpkin is not in a position to redefine terms such as backwards compatibility to mean "existing programs break at any time for no signifcant reason".

going to that level of warnings-paranoia then you are on your own.

I am "on my own" only because p5p give a shit about perl policy\, in this and in many other cases. They cleary don't care about backwards compatibility in any case\, this case is just a minor example.

In fact\, I am certainly not on my own in this respect. I am on my own only on this list\, because older perl maintainers have given up trying to stop the current p5pers from breaking perl.

-- The choice of a Deliantra\, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_\,_/ /_/\_\

p5pRT commented 10 years ago

From schmorp@schmorp.de

First of all\, your mail formatting is rather broken\, and that makes it ratehr hard to reply to your mails\, because I have to guess what you wrote and I wrote. Please fix your quoting.

On Sun\, Jun 01\, 2014 at 01:55:44AM -0400\, Eric Brine \ikegami@adaelis\.com wrote:

That's a non-sequitur: the breakage here is the extra warning\, not the fact that it is made fatal. In environments which check for empty stderr to check

for errors\, this breaks any script that uses warnings non-fatally.

Same thing. Whether you are warned about deprecations or not is also a choice.

That's true\, a choice that I made because perl policy guarentees that features such as that aren't going to be deprecated without very good reasons\, and backwards and bugwards compatibility is kept at even high cost. No such reasons have been provided\, up to the point where p5pers make up wrong claims about unicode forcing them to deprecate this feature. Which would behilarious if it wouldn't be so sad.

Sure\, things would be bad for perl if p5pers would honestly document that their policy has changed from backwards compatibility to only superficial or occasional compatibility\, but at least that would allow people to make more informed decisions.

If I had known the the perl policy isn't worth anything\, I might not have enabled warnings at all\, as they are a guarantee of breakage with future perl versions. Which incidentally makes them absolutely useless if that means my programs break every 6 months.

Furthermore\, deprecating something is not done to warn people about dangerous constructs\, it's done to remove functionality later\, which is then another backwards compatible change.

I agree. There's a *forthcoming* backward compatible change.

One that is ruled out by existing policy\, and therefore it's a bug.

I agree - Of course\, the goal of deprecating things is to remove them later\, so no matter what\, this is about breaking backwards compatibility.

Yes. perlpolicy explains which making no such changes is untenable.

Yes\, which is why this regression is clearly a bug and breaks backwards compatibility.

3. It was done for a very easy to comprehend reason.

Maybe\, but the requirement is for the reason to be rational and strong enough to outweigh the breakage\, which is clearly not the case here.

I wouldn't say that. To paraphrase what you said\, it only affects those who know they are using a hack. That doesn't carry much weight.

That's clearly not what I said\, nor meant. It's obvious\, because I didn't know I am such "a hack" in my code\, and I still used it\, which proves you are wrong here.

For example\, Lukas Mai gave "This will break one of my programs." as reason. This is easy to understand\, but without any merit\, of course.

He's saying he's willing to face the consequences for doing something he

That might be what he was *meaning*. What he was said is what I quoted\, mind you.

knew he shouldn't have been doing. He might also be saying that others in the same boat should too.

Sure\, but you completely missed my point: that statement isn't a reason that is even remotely strong enough to thwart perl policy. It's literally a joke.

However\, it's the only visible reason brought forward in this bug report.

That should be easily possible here. Also\, the documented standard is much higher than you and others assume:

Quite the opposite. Whether the change is to simplify the language or reduce the complexity of the internals\, making it a feature would make the problem worse.

That's just bullshitting around the meaning of "feature". It's a pretty well documented feature of the perl syntax (being documented in at least two places\, which is quite rare - mayn features are not documented at all\, or weren't for many years\, such as ::-quoting)\, so nobody even needs to "make it a feature"\, it already is one.

Even worse\, again\, you miss the point: It doesn't matter whether it is made a feature or not\, even if it is a bug\, perl policy explicitly guarantees that future versions of perl won't change the semantics of existing code\, at least not unless it signifcantly harms the language or is otherwise a needed change\, which is obviously not the case for this feature\, when it went undetected (or even condoned) by p5pers for over two decades.

It's perfectly fine to have the code fail with an "use 5.20" active. It's absolutely against policy to make older code fail that couldn't even know what things 5.20 will break (again).

-- The choice of a Deliantra\, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_\,_/ /_/\_\

p5pRT commented 10 years ago

From schmorp@schmorp.de

On Sun\, Jun 01\, 2014 at 01:10:36AM -0500\, Brad Gilbert \b2gills@gmail\.com wrote:

First off having variables with a non-printable character in its name should have never been added to the language. Or at the very least been deprecated immediately in Perl 5.0.0.

Well\, you are invited to play with the python/... folks if it bothers you. This is Perl\, and control-character variables are in very active use for decades\, so any lament in this area is pointless.

This feature only makes sense as a shell script replacement\, which is

I am not aware of shells having such a feature - can you elaborate which shells use control characters as variable names\, and even allow them to be used literally? The bourne shell and variants do not\, for example.

It especially doesn't make any sense to use it on any package on CPAN as not all editors will cope with it correctly. Which goes against a core principle of Open Source software\, the ability to change it.

Well\, not everybody subscribes to open source movement\, some people just want to create free software (that includes me).

Also\, do you have a reference that supporting every single editor is a core principle of open source? I ask because I don't think it is\, and I think you just made this up on the spot to sound cool.

The main reason it wasn't deprecated earlier was that nobody thought about it.

If that is true\, that just reinforces the problem I point out: just thinking of a feature doesn't allow you to deprecate it. Just because you dislike a feature doesn't allow you to break other people's code.

It just means perlpolicy doesn't mean a thing.

As to backward compatibility\, it is quite likely impossible to change the internals without breaking at least some code.

It's actually very easy to change internals without breaking any code. It's done many many times before every perl release. By far the vast majority of changes do not break code.

However\, you are not even talking about the issue at hand\, which is changing "externals" rather than internals. And the porblem isn't that something was changed\, the problem is that somethign was deliberately changed to make it incompatible with earlier perl versions\, with the intent of braking more in the future\, without giving a thought about backwards compatibility.

Most of the time it is only XS code which breaks. ( We need a better API )

Well\, given that you are wrong (and it's reasonably easy to check\, just count the number of check-ins between perl releases that change code and compare that to the actual breakage resulting from it)\, your conclusions are not valid.

Sometimes the code that gets broken was actually already subtly broken. ( As happened with the hash key randomization in 5.18 )

Again\, a documented feature that was broken for no reason: the change broke 100+ modules on CPAN\, without actually fixing the security issue (it wasn't necessary to break the guarantees at all/has too low entropy/is predictable).

At least\, in this case\, there was a semblance of actual reason: "oh my god\, panic\, somebody says there is a security bug in perl\, we need to do somethign that looks as if it's fixign something".

So we are **NOT** going for 100% compatibility for 100% of the code in the wild.

I fully agree. perlpolicy doesn't claim so. incidentally\, have you actually read it?

We are really going for more like 98%+ compatibility ( which is likely better than other languages in our same niche ).

perlpolicy doesn't give actual percentages\, but it's hard to imagine that 2% of the language is causing signifcant harm to the rest\, or that 2% of the features need to be changed incompatibly in every release. If the compatibility would only be 98%+ then up to 600 CPAN modules would be broken on every release. Oh my god\, it's fortunately not _that_ bad\, at all.

If every perl release broke 600 CPAN modules\, perl would die.

I think you just made up some numbers to look cool again.

(If you use any of the hairier areas of the language you increase the chances that you are in the ~2% that gets broken.)

Again\, this is exactly opposite of what the documented policy guarantees. If it were true\, that would mske the policy a rather big lie.

That being said\, we do try very hard to not break any code without a good reason.

Keep in mind that "we" includes me (as one of the perl AUTHORS)\, and you are certainly not speaking for me.

I think you just replaced the "I" by "we" to sound more cool. Do you have evidence that the perl authors all agree to breaking up to 600 perl modules just because they dislike a language feature? Seriously?

( I only see one person disagreeing with the "official" reason. )

I am asking and asking\, but nobody provides me with the "official" reason for this deprecating that would hold up against perl policy. Or an actual reason at all that isn't "I belief/wish/want it so"\, which isn't a reason.

I suspect really there isn't any reason\, which kind of makes it hard to disagree with it.

I believe I have said my piece\, and will likely not respond further.

That's good\, the amount of made-up "facts" that you added to this thread in just one mail is staggering.

-- The choice of a Deliantra\, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_\,_/ /_/\_\

p5pRT commented 10 years ago

From @greerga

On Sun\, 1 Jun 2014\, Marc Lehmann wrote:

On Sat\, May 31\, 2014 at 10:02:28PM -0400\, George Greer \perl@greerga\.m\-l\.org wrote:

The pumpking stated on January 27th that: "I do not consider introducing new warnings to be breaking backward compatibility in code that has specifically requested that all warnings be turned on. Instead\, it is forward compatibility: your code does not need to be altered to get new warnings."

Well\, if he woulc consider the earth to be flat that still wouldn't make it so. Backwards compatibility isn't defined by what he says it is\, it means that code that worked before still works\, plain and simple.

The current maintainers believe that anyone asking for fatalized warnings (or fatally tracking there are no warnings) is taking on more responsibility than the maintainers offer in the policy.

If you're not willing to accept that responsibility\, don't fatalize warnings.

If you want a 100% perfect in every possible circumstance backward compatibility then you need to either not upgrade or fork the code.

If you're not willing to do any of the above\, maybe you should re-evaluate your expectations for what volunteers will provide to you in return for your verbal (textual?) abuse.

-- George Greer

p5pRT commented 10 years ago

From schmorp@schmorp.de

On Sun\, Jun 01\, 2014 at 08:34:49AM -0400\, Ricardo Signes \perl\.p5p@rjbs\.manxome\.org wrote:

I would be interested to read such a patch\, with the proviso that I will lose my mind\, tear my hair out\, and collapse in the corner if it includes text like\, "p5p doesn't care about backward compatibility." To the extent that there is an "us\," we really do.

Actions speak louder than words. Just a few mails ago I heard that the perl pumpkin (hello..) redefines backwards compatibility to not being compatible to old programs. Furthermore\, I see from the actions that perl features are being changed incomptibly widely without either making the change dependent on a "use version" or otherwise following documented policy.

(This has changed in around 5.12\, and has sped up considerably since then\, as can be seen easily by the amount of breakage every release causes on CPAN. I certainly don't look forward to new perl release\, as in recent years\, that has only meant more work\, more features that will be removed in later releases again\, and not much to actually want to upgrade for).

I wouldn't write "p5p doesn't care about backwards compatibility". It would be more like: "we care\, but if we dislike a feature\, or think the language should change\, we will change it without providing bakcwards compatibility. If that means you have to actively maintain your modules every few months to keep up with Perl\, so be it." Maybe I can spice up the formulation to be nicer. If you want to know\, tell me and I will send a patch.

Which is what describes not just the actual situation\, but also what many of the people who you probably would include in that "us" have said\, namely that disliking a feature is enough to break it\, bigger reasons not required.

Putting these changes thta reflect reality into perlpolicy would also jsut reinforce that "care" for backwards compatibility is a relative term: you surely care\, but in practise that doesn't keep new perl releases from breaking features without any reaso whatsoever.

I remember the proposal in the last discussion about this change that\, to avoid this breakage\, you need more volunteers to clean up after the volunteers that broke stuff.

It much simpler\, all that is needed is a conscience - meet me: I can tell where things break needlessly\, and I duly report (and have done so in the past)\, when backwards compatibility has been broken without a real need.

All that would be needed to show care for bakcwards compatibility would be to not reply "shut up\, I made this change\, and therefore it is good" as does happen\, but instead revert the patch until a better solution is found.

I think the real problem is that you and (for example) I have a different reading of certain parts of this document.

No.

PP> Existing syntax and semantics should only be marked for destruction in PP> very limited circumstances. If a given language feature's continued PP> inclusion in the language will cause significant harm to the language PP> or prevent us from making needed changes to the runtime\, then it may be PP> considered for deprecation.

There's a lot of room for judgement calls\, here. "very limited" and "significant harm" and "needed changes\," for example. What changes do we *need* to make? What is the arbiter of necessity?

I read this exactly as you do. Your mail would be much more interesting if you actually provided the "significant harm" that this specific feature (and probably the warn change) does to the language.

Fact is\, the only explciit reason I was given for the deprecation is that the unicode standard forces perl identifier syntax not to include some control chars\, which is of course phony.

If the fetaure causes signifcant harm\, surely it would be possible to say what this signficant harm is? (Or alternatively\, what other changes in the future are needed and can only be done by removing this feature?).

On the other hand\, I have a more liberal view — obviously. I think\, that to keep improvements viable\, we need to continue to simplify the language in places where its specifics introduce a maintenance or implementation burden that greatly outweighs the benefits.

Again\, it would be much more interesting to know the maintainance burden that greatly outweighs the benefits in this case\, or the warn case.

Backward-compatibility is a benefit. We weigh it *very* *very* heavily in considering changes.

I can't see it\, sorry. And nobody seems to be able to explain the very very heavy outweighing factors.

I question whether they exist.

But yes\, if ti were as you describe\, I surely could follow. I am doing perl for more than 20 years now\, doing perl modules for almost that long\, have a very good understanding of msot parts of the internals of perl\, and am very reasonable\, if people try to talk reaosnably with me.

Don't you think that those very very heavily outweighing considerations should be understandable by me?

What I am arguing here is not strongly necessary changes. I am talking about changes done for no obvious reason\, where even the combined might of p5p cannot come up with better reasons than "I belief this feature should be removed".

As someone else pointed out\, I also won't put the addition of a deprecation warning into the bucket of "incompatible change\," but I believe it was you who

Yes\, because breaking existing code isn't considered an incomaptible change by you. I heard it\, but we will just have to disagree\, with me strongly saying that you are not entitled to make obviusly nonsensical redefinitions such as that without being called out by me.

It's easy to care strongly about backwards compatibility if you redefine it to not include all the breakage you are actually doing. Costs no effort at all.

correctly responded that the warning is not necessarily the problematic change\, but the future removal of the deprecated feature!

Yes. Although perlpolicy indicates that the warning should be dependent on programs requesting it (use v5.20)\, as surely is possible (Unless code at a given scope declares that it wants the new behavior\, that new behavior should be disabled.").

Of course\, it helps your argumentation that you simply exclude breakage from backwards compatibility\, but then\, the perlpolicy becomes pretty meaningless if you cna just exclude whatever you like from it and still claim you care for backwards compatibility.

I have a problem with this language\, because it uses one of my least favorite policy words: should. perlpolicy doesn't claim to use RFC 2119 language\, but let's quote from RFC 2119 anyway:

(I happily agree on rfc 2119 definitions).

2119> 3. SHOULD This word\, or the adjective "RECOMMENDED"\, mean that there 2119> may exist valid reasons in particular circumstances to 2119> ignore a particular item\, but the full implications must be 2119> understood and carefully weighed before choosing a different 2119> course.

So\, did we follow this policy? I think so\, because to my mind the reason for the deprecation was to enable the simplification and unification of portions of the grammar.

rfc 2119 is typically misunderstood to mean "make up some reason\, go ahead"\, but that's not what it says. Where is the careful weighing\, and what does it mean to fully understand the implications if everybody is suddenly so surprised that it breaks stuff?

Where is the careful consideration in the case of warn? I tried to find out and was prepared (actually\, I did) explain why such reasoning does not exist\, but again\, nobody cared.

Enabling a lexically-scoped switch would have undermined the whole point.

How so? "use v5.20" already exists for just that purpose\, namely to tell perl to use the 5.20 language variant.

At that point\, the question is: is the removal really worth not just changing the default behavior\, but making it unavailable? Given the *extremely* low value that we felt backward compatibility for this little syntactic horror would have\, I felt that it was.

Do you really propose that "understanding the full implications" (rfc 2119) is consistent with you acting on a feeling?

If yes\, then I certainly understand why things are as they are.

...but "should" stinks. When I come to "should" in an RFC\, I know that the practical impact will be that there will be a dozen different interpretations of whether and why the action of the "should" will be taken. How can we improve that language?

If you goal is to "improve" the language to allow for breakage based on feelings or beliefs\, then\, I am afraid\, no such improvement exists.

Pampering over the fatc that backwards compatibility isn't important by saying "it is very important\, except when we feel we don't care" is dishonest\, not more\, and not less.

Nobody will understand perlpolicy the way you want it to. Saying clearly that you don't care very much would be much more honest (even if that was a simplification).

Needless to say\, the current course of perl steers straight down the cliff by making morre and more fo CPAN obsolete by increasing the maintainance burden of module authors\, as well as increasing the maintainance burdne of sysadmins more and more\, to the point where every release needs the 100% test coverage that the current policy tries to avoid.

We can add guidance for how to choose. I think that beyond that\, there isn't a lot of improvement to be made. It's a human issue that will be poorly managed by hard and fixed rules\, I think.

Stating more or less the opposite of reality doesn't help either. I was always skeptical of warnings that are introduced at a whim and break all my cron scripts or so (in fact\, they frequently do break cron scripts that I haven't written\, leading to me to remove "use warnings" from many scripts I actually haven't written in the past to get them working properly again).

It's not my choice to make\, but if I could chose\, I would chose to keep CPAN and perl alive\, rather than to make it a moving target. Sure\, the biggfest reason is personal: I frankly have a hard time keeping up with even the changes that I can rationalise as reasonable (such as the AV placeholder value change)\, and the needless breakage changes are slowly driving me beyond my limits\, especially as it isn't fun to work around bugs introduced by newer perl versions by somebody who didn't give the feature much thought.

-- The choice of a Deliantra\, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_\,_/ /_/\_\

p5pRT commented 10 years ago

From schmorp@schmorp.de

On Sun\, Jun 01\, 2014 at 12:46:29PM -0400\, George Greer \perl@greerga\.m\-l\.org wrote:

The current maintainers believe that anyone asking for fatalized warnings (or fatally tracking there are no warnings) is taking on more responsibility than the maintainers offer in the policy.

"believe"\, "feel"... It's sad that perl seems to be maintained on religious\, rathere than on factual grounds\, these days.

If you're not willing to accept that responsibility\, don't fatalize warnings.

Sure\, and jesus will give you the chance to accept him even if you live in the jungle and never hear of christianity ever.

To be able to be "not willing" I would at least have to have the chance of "knowing". perlpolicy is quite explciit\, and quite strongly worded\, in this respect.

What you really say is "if you are stupid enough to rely on whats officially documented\, then it's your fault alone".

I am not convinced by your argument.

If you want a 100% perfect in every possible circumstance backward compatibility then you need to either not upgrade or fork the code.

I don't want that. Or rather\, I don't insist on it\, although I would want it.

But\, as it seems to escape you\, I didn't ask for 100% perfect in every possible circumstance backward compatibility - you are the one who made up this term. perlpolicy doesn't ask for that\, and I never asked for more than what perlpolicy provides.

Even in this case I can be swayed by actually learning what the signifcant harmto the language is that is caused by that\, or what changes are needed to require this breakage.

You don't provide the reasons\, and nobody else does. Makes me reasonably sure that nobody even knows them\, because they don't exist.

All I hear is that a belief or a feeling is enough to break backwards comaptibility. That's a far way off from perlpolcy\, and an separated by an abyss by the strawman you just made up.

If you're not willing to do any of the above\, maybe you should re-evaluate your expectations for what volunteers will provide to you in return for your verbal (textual?) abuse.

Asking for maintainers to follow their own policy and be reasonable is abuse? Are you trying to be funny?

-- The choice of a Deliantra\, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_\,_/ /_/\_\

p5pRT commented 10 years ago

From schmorp@schmorp.de

(Not a reply to you personally\, Ricardo).

I have said what I wanted to say\, and\, as usual\, got about 80% useless responses by people who didn't even bother to read through the material\, and about 20% responses that were trying to engange the argument. I wish to thank those.

Those replies have made it clear to me that backwards compatibility doesn't have the meaning it has in other parts of IT\, that it doesn't have a high priority (feelings are enough to break it)\, that the dislike of a feature is enough to break it\, and that making up phony reasons is likewise enough to rationale a breakage.

I don't have anything to add\, and I feel that I simply have to disagree with this policy\, and further arguing will not sway the obvious majority opinion of the (verbal part of) p5p. Bakcwars comaptibility RIP.

I will therefore not reply further is this thread - if you really really think that I can provide some information that I haven't provided already\, feel free to ping me and I will decide whether thats the case\, otherwise\, just refer to my earlier mails.

If ricardo wants my patch suggestion for perlpolicy\, I will of course provide one with "nice" language that reflects what ricardo and others have said. Anything is better than the current state\, which is completely misleading\, although in my opinion it describes the wodnerful state of perl in the past\, which had no "use version" feature but still managed to provide less breakage while providing features that are still with us\, as opposed to features thta mostly will be removed a few releases later\, or are not even useful even if the were stable.

-- The choice of a Deliantra\, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_\,_/ /_/\_\

p5pRT commented 10 years ago

From @karenetheridge

On Thu\, May 29\, 2014 at 06:52:12AM +0200\, Andreas Koenig wrote:

I'm impressed you can generate a PASS for AE:F. I find the output of cpanm not helpful\, it does not show for example that tests have actually been running or maybe have been skipped. Also no 'perl -V'.

You'll get more useful information with cpanm --verbose.

I don't believe that cpanm can be configured to run full blown cpantesters reports but I may have missed a posting about it and the wiki page http://wiki.cpantesters.org/wiki/SmokeTesting does not mention it. Maybe ask on cpan-testers-discuss@perl.org ?

Whenever I install a new perl (with perlbrew)\, the first thing I install is App::cpanminus::reporter\, and then I run cpanm using a bash function that always invokes 'cpanm-reporter' after 'cpanm'\, to send test reports for everything I install.

p5pRT commented 10 years ago

From @jkeenan

On Sun Jun 01 10:22:31 2014\, schmorp@schmorp.de wrote:

(Not a reply to you personally\, Ricardo).

[snip]

I don't have anything to add\, and I feel that I simply have to disagree with this policy\, and further arguing will not sway the obvious majority opinion of the (verbal part of) p5p. Bakcwars comaptibility RIP.

I will therefore not reply further is this thread

[snip]

On that basis\, I am going to mark this RT ticket as closed. I recommend that if anyone wishes to continue the discussion about policy\, s/he write P5P in a new thread.

Thank you very much. Jim Keenan

p5pRT commented 10 years ago

@jkeenan - Status changed from 'open' to 'resolved'

p5pRT commented 10 years ago

From @ilmari

Marc Lehmann \schmorp@schmorp\.de writes:

This is Perl\, and control-character variables are in very active use for decades\, so any lament in this area is pointless.

I wondered just how widely used it was\, so I unpacked my local minicpan (http://grep.cpan.me/ was giving Internal Server Error on the pattern) and searched for .pm\, .pl and .t files that match /\$[\x01-\x08\x0b\x0c\x0e-\x1f]/ outside the __DATA__ section\, and manually filtered out false positives (comments\, string literals\, regex delimiters)\, and got this short list:

AnyEvent-Fork/Fork.pm Business-SEDOL/t/01-acc.t CGI-Out/lib/CGI/Out.pm DBIx-XMLServer/XMLServer.pm Data-TDMA/t/00_day.t Devel-Command/lib/Devel/Command/DBSub/DB_5_10.pm Devel-Command/lib/Devel/Command/DBSub/DB_5_6.pm Devel-Command/lib/Devel/Command/DBSub/DB_5_8_5.pm Devel-Command/lib/Devel/Command/DBSub/DB_5_8_6.pm Net-SMTP-Receive/Receive.pm Net-TDMA/t/00_day.t PDL/t/pptest.t Passwd-DB/DB.pm Tk-FileDialog/FileDialog.pm Tk-JFileDialog/lib/Tk/JFileDialog.pm WWW-BBSWatch/BBSWatch.pm ptkFAQ/etc/FileDialog.pm

That hardly counts as "very active use" in my book.

-- "I use RMS as a guide in the same way that a boat captain would use a lighthouse. It's good to know where it is\, but you generally don't want to find yourself in the same spot." - Tollef Fog Heen

p5pRT commented 10 years ago

From @tux

On Mon\, 02 Jun 2014 14:00:43 +0200\, ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) wrote:

Marc Lehmann \schmorp@schmorp\.de writes:

This is Perl\, and control-character variables are in very active use for decades\, so any lament in this area is pointless.

I wondered just how widely used it was\, so I unpacked my local minicpan (http://grep.cpan.me/ was giving Internal Server Error on the pattern) and searched for .pm\, .pl and .t files that match /\$[\x01-\x08\x0b\x0c\x0e-\x1f]/ outside the __DATA__ section\, and manually filtered out false positives (comments\, string literals\, regex delimiters)\, and got this short list:

Where did you miss on JE?

.cpan/build/JE-0.060-inaa5P $ ack '\cW|\cT' | cat -v lib/JE/Code.pm:16:use constant T => ${^TAINT}; # perl doesnM-bM-^@M-^Yt optimise if(${^TAINT}) away lib/JE/LValue.pm:39: $val = eval 'BEGIN{${^WARNING_BITS} = $bits}' lib/JE/LValue.pm:46: = eval "BEGIN{\${^WARNING_BITS} = \$bits}$symbol \$self";

AnyEvent-Fork/Fork.pm Business-SEDOL/t/01-acc.t CGI-Out/lib/CGI/Out.pm DBIx-XMLServer/XMLServer.pm Data-TDMA/t/00_day.t Devel-Command/lib/Devel/Command/DBSub/DB_5_10.pm Devel-Command/lib/Devel/Command/DBSub/DB_5_6.pm Devel-Command/lib/Devel/Command/DBSub/DB_5_8_5.pm Devel-Command/lib/Devel/Command/DBSub/DB_5_8_6.pm Net-SMTP-Receive/Receive.pm Net-TDMA/t/00_day.t PDL/t/pptest.t Passwd-DB/DB.pm Tk-FileDialog/FileDialog.pm Tk-JFileDialog/lib/Tk/JFileDialog.pm WWW-BBSWatch/BBSWatch.pm ptkFAQ/etc/FileDialog.pm

That hardly counts as "very active use" in my book.

Agree. Also given that the "fix" is so easy.

-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.19 porting perl5 on HP-UX\, AIX\, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

p5pRT commented 10 years ago

From @rjbs

* Marc Lehmann \schmorp@schmorp\.de [2014-06-01T13:22:07]

If ricardo wants my patch suggestion for perlpolicy\, I will of course provide one with "nice" language that reflects what ricardo and others have said.

If you provided the text that you think would be useful there\, I would be interested to read it and possibly steal some nonzero amount of it in an update of the document. Obviously I can't say much more than that without seeing it\, and you may feel your time woudl be wasted writing it without an assurance of use. So: my interest is genuine\, and I would be pleased to see it\, but not discouraged should you choose to decline.

-- rjbs

p5pRT commented 10 years ago

From @rjbs

* Marc Lehmann \schmorp@schmorp\.de [2014-06-01T11:48:19]

The important point to understand is that the perl pumpkin is not in a position to redefine terms such as backwards compatibility to mean "existing programs break at any time for no signifcant reason".

Everything else aside\, I will issue the significant correction that the sort of breakages being discussed do not occur "at any time\," but only "when upgrading between major versions."

-- rjbs

p5pRT commented 10 years ago

From @ilmari

"H.Merijn Brand" \h\.m\.brand@xs4all\.nl writes:

On Mon\, 02 Jun 2014 14:00:43 +0200\, ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) wrote:

Marc Lehmann \schmorp@schmorp\.de writes:

This is Perl\, and control-character variables are in very active use for decades\, so any lament in this area is pointless.

I wondered just how widely used it was\, so I unpacked my local minicpan (http://grep.cpan.me/ was giving Internal Server Error on the pattern) and searched for .pm\, .pl and .t files that match /\$[\x01-\x08\x0b\x0c\x0e-\x1f]/ outside the __DATA__ section\, and manually filtered out false positives (comments\, string literals\, regex delimiters)\, and got this short list:

Where did you miss on JE?

.cpan/build/JE-0.060-inaa5P $ ack '\cW|\cT' | cat -v lib/JE/Code.pm:16:use constant T => ${^TAINT}; # perl doesnM-bM-^@M-^Yt optimise if(${^TAINT}) away lib/JE/LValue.pm:39: $val = eval 'BEGIN{${^WARNING_BITS} = $bits}' lib/JE/LValue.pm:46: = eval "BEGIN{\${^WARNING_BITS} = \$bits}$symbol \$self";

Because I forgot to allow { between the $ and the control character. That adds the following files:

JE/lib/JE/Code.pm JE/lib/JE/LValue.pm MoneyWorks-pm/lib/MoneyWorks.pm

Still not "very active use" by any stretch of the definition.

AnyEvent-Fork/Fork.pm Business-SEDOL/t/01-acc.t CGI-Out/lib/CGI/Out.pm DBIx-XMLServer/XMLServer.pm Data-TDMA/t/00_day.t Devel-Command/lib/Devel/Command/DBSub/DB_5_10.pm Devel-Command/lib/Devel/Command/DBSub/DB_5_6.pm Devel-Command/lib/Devel/Command/DBSub/DB_5_8_5.pm Devel-Command/lib/Devel/Command/DBSub/DB_5_8_6.pm Net-SMTP-Receive/Receive.pm Net-TDMA/t/00_day.t PDL/t/pptest.t Passwd-DB/DB.pm Tk-FileDialog/FileDialog.pm Tk-JFileDialog/lib/Tk/JFileDialog.pm WWW-BBSWatch/BBSWatch.pm ptkFAQ/etc/FileDialog.pm

That hardly counts as "very active use" in my book.

Agree. Also given that the "fix" is so easy.

-- "The surreality of the universe tends towards a maximum" -- Skud's Law "Never formulate a law or axiom that you're not prepared to live with the consequences of." -- Skud's Meta-Law

p5pRT commented 10 years ago

From schmorp@schmorp.de

On Sun\, Jun 01\, 2014 at 10:16:33AM +0200\, "H.Merijn Brand" \h\.m\.brand@xs4all\.nl wrote:

I did offer to create a patch for it.

Many have offered *you* patches to *your* modules in the past.

I am thankful for that\, even if those patches were only a tiny part of the work needed to work around breakage intorduced by those or other people.

While I am happy for every single instance\, I am not happy with the overall situation\, such as the refusal of maintainers to fix breakage they introduced earlier.

Some were only a few character changes\,

Everybody has her own standards for releases. Mine are apperently quite high\, which means the effort to release a module with a few character changes are much higher than changing those few characters.

You have rejected those telling the people they were wrong. Now you are using the same arguments the other way around.

Thats bullshit - in every single case\, I give sufficient reason for why they were wrong. I also offer to explain anything that is unclear. In no case were my arguments the same as for other cases\, in each case my arguments were tailored to the case or cases at hand.

(And in fact\, given that you are obviously not above making up things and then pretend they are true\, I suspect you just made this statement up as well\, without any evidence - certainly there isn't any\, right?).

The fact is\, in most cases\, my arguments are simply ignored.

Just look at this very thread. Look at the number of people who claim that there is a good/simple/obvious reason for this change. If asked for thise reasons\, most people suddenly go on a diving course. If I do get a reaosn\, it's obvious that they are bullshit made up on the spot. My favourite is the argument that the unicode standard required perl identfier syntax to be changed.

In all such cases\, when asked to back up these claims\, people suddenly become very quiet.

The sad part is that this doesn't just apply to the obvious trolls\, but also to people like Ricardo\, who make sweeping statements\, but can't be bothered to back them up.

No\, I am not using the same arguments the other way round. I actually _use_ _arguments_.

I agree with all the perl5 developers that participated int this discussion: there was *NO* backward compat breaking issue.

This is the style of arguing I expect: make up bullshit (like the obviously wrong statement that all p5 devs participiating agree with that)\, then agree with it. Well done.

I can't take you seriously if you can't even be bothered to play fair or reasonable. Do you really expect me to blindly believe you when you make obviously false statements like that?

Of course\, as always\, you will simply drop this topic and pretend it never happened.

-- The choice of a Deliantra\, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_\,_/ /_/\_\

p5pRT commented 10 years ago

From schmorp@schmorp.de

On Tue\, Jun 03\, 2014 at 05:11:49PM +0200\, Marc Lehmann \schmorp@schmorp\.de wrote:

Just look at this very thread. Look at the number of people who claim that there is a good/simple/obvious reason for this change. If asked for thise reasons\, most people suddenly go on a diving course. If I do get a reaosn\, it's obvious that they are bullshit made up on the spot. My favourite is the argument that the unicode standard required perl identfier syntax to be changed.

Not to mention\, I forgot to add\, that most of these people disagree on what the obvious reason is\, which in my book shows that it isn't obvious at all.

-- The choice of a Deliantra\, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_\,_/ /_/\_\

p5pRT commented 10 years ago

From @demerphq

On 3 June 2014 17:11\, Marc Lehmann \schmorp@schmorp\.de wrote:

This is the style of arguing I expect: make up bullshit (like the obviously wrong statement that all p5 devs participiating agree with that)\, then agree with it. Well done.

I see you do this all the time. The hash changes for instance. Not one thing you have had to say on the subject has in any way been correct.

People go silent when you rant because you don't read what they say\, you are gratuitously insulting and rude\, and you don't even remotely start from a position that allows any compromise to develop.

I could go through the mails you wrote in this thread and find numerous examples of you doing exactly what you accuse others of doing. Yet when I look at the details what I see is you projecting your own behaviour on others.

I can't take you seriously if you can't even be bothered to play fair or reasonable. Do you really expect me to blindly believe you when you make obviously false statements like that?

Again you project. You say things that are totally unfair and unreasonable\, and patently false. And then you expect us all to agree with you.

If you don't like maintaining your modules hand them over to someone who does and stop bothering the rest of us with your outrageously bad manners.

And I say this as someone who started off reading this thread with a sympathetic view of your concerns\, but I end up as someone totally exhausted with your feigned outrage and histrionics.

There are many who would be willing to take over support of your modules should you wish to exit the stage. If not then either learn to communicate politely or dont bother to communicate with us at all.

Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT commented 10 years ago

From schmorp@schmorp.de

First of all\, I was a bit delayed by having to clean up after the most recent major release.

Second\, Ricardo\, I must critically remark that you\, too\, made claims that good reasons for the breakages I mentioned exist\, but when asked for details\, miraculously fell silent on that topic\, as does everybody else.

I am strongly convinced that these details don't exist.

On Mon\, Jun 02\, 2014 at 10:35:38AM -0400\, Ricardo Signes \perl\.p5p@rjbs\.manxome\.org wrote:

If you provided the text that you think would be useful there\, I would be interested to read it and possibly steal some nonzero amount of it in an update

It's attached\, as pod fragment for easier reading. If a patch is required for technical reasons\, I will provide it\, but I highly doubt it.

of the document. Obviously I can't say much more than that without seeing it\, and you may feel your time woudl be wasted writing it without an assurance of use. So: my interest is genuine\, and I would be pleased to see it\, but not discouraged should you choose to decline.

I doubt you will agree with much of it. One thing I ask of you though: Every single point in this new policy directly reflects what a perl5porter (and I suspect\, a perl author) has states here. When you strongly disagree\, please consider that this policy reflects the actual state of opinions on the matter by those participating in this or similar discussions on this list.

I think it also reflects the reality of recent perl releases\, which makes perfect sense.

Grammatical problems\, bad style and so on are entirely my own faults of course.

So\, just consider that\, when you disagree\, you disagree with other perl5porters\, and you disagree with the actual reality of what is being delivered.

I say that because I hope you don't fall into the trap of trying to document what you wish to be true\, instead of trying to document what actually happens. I have been burned by the belief that perl5porters care strongly for backwards compatibility (because of past experiences and the stated policy)\, and I think it does great harm to state a policy that is quite obviously not implemented\, because the people who are supposed to implement it effectively ignore it.

-- The choice of a Deliantra\, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_\,_/ /_/\_\

p5pRT commented 10 years ago

From schmorp@schmorp.de

=head1 BACKWARD COMPATIBILITY AND DEPRECATION

Historically\, this section described the very strict backwards compatibility policy used for maintaining Perl. This policy was strict to the point where even unintended bugs had to be cared for in the same way as documented features.

This policy is no longer in effect\, as the Perl 5 Porters feel that it was not useful anymore. The following is a condensed summary of what Perl 5 Porters had to say on how they will maintain Perl\, and thus is expected to reflect the state of thinking on this when this policy was written.

This policy only applies to major version releases\, for minor patch releases\, the standards are still much higher.

While backwards compatibility is still an important goal and should be kept unless there are overriding reasons\, the bar for changes is low enough to give the Perl maintainers freedom to implement the changes they need.

CPAN authors need to expect incompatibilities and have to deal with them in new major releases themselves. The Perl 5 maintainers are not expected to monitor CPAN\, or keep older modules working. A module author is expected to be active enough to keep up with the release cycle. This is notwithstanding the fact that some people actively do monitor CPAN for breakage before release and make major efforts to help upgrade at least the more popular modules.

This applies to other Perl users\, but since nobody is forced to upgrade unless they want security support\, so the importance for private modules and scripts is reduced\, and obviously nobody can monitor code for breakage that they don't even know exists

In many cases\, backwards (and bug) compatibility\, isn't achievable or reasonable. For example\, reported security problems need to be fixed with priority\, and it is better to have a bad patch that breaks some features then wait for a better patch and have the problem persist.

There are many more cases where backwards compatibility isn't required. For Perl maintainers\, any of the following considerations can weigh stronger than backwards compatibility:

=over 4

=item a feature is only rarely used on CPAN

If a change simplifies maintenance\, and the corresponding feature is only rarely used\, you can consider the impact to be low enough for compatibility to not matter (certainly\, 10 broken modules on CPAN isn't worth the effort if the required change is small).

=item the change is easy to work around

If a Perl change only requires a small effort when updating existing code\, backwards compatibility should not be a concern.

=item code breaks because of a new warning in an existing category

Warnings and deprecations are not even considered to be part of any backwards compatibility policy. If a change merely deprecates a feature\, or introduces a new warning\, there is no need to consider possible implications.

=item a feature is incompatible with a published third party standard

It is better to ensure compatibility then have a potential incompatibility. The bar is not very high here\, if you think a 3rd party standard disagrees with Perl\, fix Perl.

=item the change only affects XS code

XS has has never been part of the Perl language\, and has never been covered by any backwards compatibility policy. If a change makes sense (improves speed or clarity for example)\, then it should be fine.

This includes documented interface which subtly change semantics - perlapi is only a guideline\, and old code written before it existed is not worthy of preservation.

=item a feature is an ugly thing of the past

Perl is full of features that were thought to be useful in the 1980s\, but don't hold up to modern scrutiny or development standards. If a feature is particularly ugly\, doesn't make sense or should have never been in the language in the first place\, and removing or changing it improves maintenance\, backwards compatibility is not relevant.

=item code breaks that saw it coming

If a programmer used documented syntax in a weird way\, or tried to exploit the darker corners of the language\, it's not up to the Perl 5 maintainers to keep her code working. Perl users are expected to write reasonable code\, and\, failing that\, to keep it updated. It is not the job of the Perl 5 maintainers to keep exotic features working.

=item breakage is caused by a patch that adds new functionality

New functionality trumps backwards compatibility. While gratuitously breaking code is still unacceptable\, nobody can be forced to fix patches that accidentally break things.

=back

A partial reason for this new policy is lack of volunteers - while there are enough volunteers to add interesting features to the language\, there are simply too few that can invest time into lengthy investigations of compatibility issues. Help is always appreciated\, and without doubt\, backwards compatibility can be improved by having more volunteers that can clean up problems that were accidentally introduced.

Again\, due to the volunteer nature of Perl development\, this policy is only a guideline. Nobody should be kept from subjecting himself to higher standards.

Specifically\, the pumpkin can impose higher standards for a release\, especially if a lot\, say\, 20 or more\, of CPAN distributions are affected.

This policy was written by summarising the publicly stated positions of the following people: Zefram\, Aristotle Pagaltzis\, Eric Brine\, George Greer\, Ricardo Signes\, Brad Gilbert\, Dagfinn Ilmari Mannsåker\, H.Merijn Brand and Karl Williamson\, in no particular order.

p5pRT commented 10 years ago

From schmorp@schmorp.de

On Tue\, Jun 03\, 2014 at 05:33:48PM +0200\, demerphq \demerphq@gmail\.com wrote:

I see you do this all the time. The hash changes for instance. Not one thing you have had to say on the subject has in any way been correct.

Not anything of relevance you have said on that subject has in any way been correct.

Did I win this spectacular now?

People go silent when you rant because you don't read what they say\,

I make a habit of logically and reasonably destroying any argument that I reply to and I disagree. Saying I don't read what they say\, when I explicitly argue against their arguments is an obcious lie\, sorry.

Cite just one case where I replied to an argument without having considered it by showing what is wrong with it.

are gratuitously insulting and rude\, and you don't even remotely start from a position that allows any compromise to develop.

Obviously\, because I started from the point of logic and reasoning. It's impossible for me to compromise with people who make up false statement that they cannot back up to win an argument.

(That doesn't mean it is impossible to compromise\, I only state I cannot compromise with people who are irrational and resort to manufacturing evidence as they go along).

I could go through the mails you wrote in this thread and find numerous examples of you doing exactly what you accuse others of doing.

Yes\, and when I ask you to give just a few such examples\, you will be silent\, as always.

It's just so much simpler for you to go directly to an ad hominem to try to subvert other people's positions\, without ever backing up any reasonable arguments.

look at the details what I see is you projecting your own behaviour on others.

Oh god.

What you are probably seeing is that I lower my standards to the standards of others when they try to "discuss" things in their own twisted way. While desperately trying to keep my own standards\, which is _hard_. What I try to do is adapt

What you are doing here is confusing cause with effect: If some people refuse to even attempt a sensible conversation I do not feel particulalry bound to invest a lot into it myself.

Seriously\, if you only tried to actually give reasonable and fair arguments\, I guarantee I will do the same.

I can't take you seriously if you can't even be bothered to play fair or reasonable. Do you really expect me to blindly believe you when you make obviously false statements like that?

Again you project.

Ah\, so all perl 5 developers agree with him? The fact that at least some disagree is a projection of mine?

When he states that all agree with him\, which is verifiablly (and easily so) wrong\, then I am unfair?

Do you even realise that this is utter nonsense?

You say things that are totally unfair and unreasonable\, and patently false. And then you expect us all to agree with you.

As I have made amply clear\, I expect people to agree with the existing perl policy. This obviously isn't the case\, which is why I have offered (and done the effort) to write a new one\, which is almost diametrically opposed to my own opinion but reflects the opinion of others.

These are the "totally unfair and unreasonable" things I have said and expected others to agree with.

Keep in mind that the existing policy was not written by me\, and doubtlessly at one point reflected the opinion of p5p.

This is what you call "totally unfair and unreasonable".

Allow me to simply disagree with your assesment.

If you don't like maintaining your modules hand them over to someone who does and stop bothering the rest of us with your outrageously bad manners.

Well\, if you don't like beating your wife and children\, you can stop anytime as well. It hurts them a lot less.

And I say this as someone who started off reading this thread with a sympathetic view of your concerns\, but I end up as someone totally exhausted with your feigned outrage and histrionics.

You can hopefully understand that I cannot believe you.

There are many who would be willing to take over support of your modules should you wish to exit the stage.

What is many\, can you name five of them even remotely capable of the job (e.g. excluding your dead ancestors for example)?

I fully suspect this to be yet another made-up statement.

If not then either learn to communicate politely or dont bother to communicate with us at all.

If you would learn to actually communicate in a constructive way\, I am Sure the situation would be improved a lot.

(That still doesn't fix the problem of clueless people chiming in\, demonstrating their total lack of understanding\, but that's only a few).

-- The choice of a Deliantra\, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_\,_/ /_/\_\

Perl / perl5