• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Item3564: TWiki should support at least Perl 5.6.1

Item Form Data

AppliesTo: Component: Priority: CurrentState: WaitingFor: TargetRelease ReleasedIn
Engine   Urgent Closed   patch 4.1.2

Edit Form Data

Reported By:
Applies To:
Current State:
Waiting For:
Target Release:
Released In:


This item is to track TWiki:Codev/WhatVersionsOfPerlAreSupported, as a follow-up to Item3476

Goal is to get TWiki 4.1.2 to run on Perl 5.0.3, and if that is not possible without substantial work, support Perl 5.6.5.

This is an urgent release blocker of 4.1.2. We are inevitably losing evaluators with the current requirement on 5.8, e.g. we should release TWiki 4.1.2 within the next 2 weeks.

-- TWiki:Main/PeterThoeny - 05 Feb 2007

I now have a Redhat 7.3 running with Perl 5.6 and TWiki on Apache 1.3.

And the first error I run into is

configure: Argument "" isn't numeric in numeric lt (<) at /var/www/twiki/lib/TWiki/Configure/Checker.pm line 207.

I added some poor mans debugging and found that it stops when it checks File::Find.

It seems that File::Find in older versions does not return a version number. This should not make configure fail but just report that it is unknown version.

To confirm that the old File::Find does not return a version I tried from the command line.

perl -e 'use File::Find; print "$File::Find::VERSION\n";'

And the result is just en empty line. If I write some garbage I get an error message. I guess we need to peel the layers off the onion until it runs. So this is first bug. I am running the Patch04x01 branch on it.

-- TWiki:Main.KennethLavrsen - 13 Feb 2007

I made a quick little fix which I can check in later to overcome the configure error.

Next errors I run into are.

Can't locate Unicode/Normalize.pm in @INC (@INC contains: /var/www/twiki/lib/CPAN/lib//arch /var/www/twiki/lib/CPAN/lib//5.6.1/i386-linux /var/www/twiki/lib/CPAN/lib//5.6.1 /var/www/twiki/lib/CPAN/lib/ /var/www/twiki/lib /usr/lib/perl5/5.6.1/i386-linux /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1/i386-linux /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.6.1/i386-linux /usr/lib/perl5/vendor_perl/5.6.1 /usr/lib/perl5/vendor_perl .) at /var/www/twiki/lib/TWiki/Sandbox.pm line 193.
BEGIN failed--compilation aborted at /var/www/twiki/lib/TWiki/Sandbox.pm line 193.
Compilation failed in require at /var/www/twiki/lib/TWiki.pm line 142.
BEGIN failed--compilation aborted at /var/www/twiki/lib/TWiki.pm line 142.
Compilation failed in require at (eval 71) line 3.

I still need to install some CPAN libs that are required so some of these errors may go away. I just report the errors as I see them in case it inspires someone to give hints.

-- TWiki:Main.KennethLavrsen - 13 Feb 2007

I have checked in the fix for configure for both Patch04x01 and MAIN. Very simple and changes nothing for newer Perls where all libs return versions.

-- TWiki:Main.KennethLavrsen - 13 Feb 2007

I am trying to figure out why the Can't locate Unicode/Normalize.pm occurs??!

In the Sandbox.pm line 190 we have

    if ( $TWiki::cfg{Site}{CharSet} =~ /^iso-?8859-?15?$/i ) {
        if( $] >= 5.008 && eval { require Unicode::Normalize } ) {
            require Encode;
            eval { use Unicode::Normalize };

How come Perl 5.6.1 goes into the if( $] >= 5.008 && eval { require Unicode::Normalize } ) and stil tries to eval { use Unicode::Normalize }; ???

-- TWiki:Main.KennethLavrsen - 13 Feb 2007

I commented out the eval { use Unicode::Normalize }; to continue finding more errors. And my next problem has been seen before:

view: Can't locate object method "generate_id" via package "CGI::Session::ID::" at /usr/lib/perl5/vendor_perl/5.6.1/CGI/Session.pm line 74.

I found out that this was due to a problem with the RPM perl libs I had installed from Dag. I uninstalled the perl-CGI-Session rpm. Upgraded the CPAN itself. And finally installed CGI::Session with CPAN instead. And then it runs. I can view topics in TWiki with Apache 1.3 and Perl 5.6.1.

I have not yet tested editing and plugins. But it seems that if we can fix that Unicode::Normalize problem - then we are very far. Unicode::Normalize seems to require Perl 5.8 so we have to make it work so the eval { use does not get parsed by Perl 5.6.

-- TWiki:Main.KennethLavrsen - 14 Feb 2007

Excellent progress, great work Kenneth!

-- TWiki:Main.PeterThoeny - 14 Feb 2007

As far as I can read in my perl book the reason for the error is that eval { BLOCK } is compiled at compile time and not runtime.

eval 'use Unicode::Normalize'; would be evaluated at runtime. What is the reason for the block syntax? And can we just change it? The error goes away in 5.6.1 with the runtime syntax.

-- TWiki:Main.KennethLavrsen - 14 Feb 2007

The purpose of eval with a block is simply to trap fatal runtime errors. An eval with a string is compiled at runtime, which is more flexible, but slower in execution. You need string eval if you want to use variables when constructing the code, or if you fear that the code to be eval ed doesn't compile.

To make the intention of runtime evaluation clear, I'd rather use require:

    eval { require Unicode::Normalize; }
Perl's require is executed at runtime regardless of whether you use it in a block or a string.

-- TWiki:Main.HaraldJoerg - 14 Feb 2007

After having studied the code we use in general we never use the eval BLOCK anywhere else. And I have additionally tested the code with the runtime type eval and it works well. It is working in perl 5.8.5 with the Unicode libs and in 5.6.1 it is ignored as it should be. Checking in this fix.

For the moment I see no other issues playing with Patch04x01 in perl 5.6.1. I am not closing this bug item yet because configure reports that some libs are too old. I doubt this is really the case for all of them.

-- TWiki:Main.KennethLavrsen - 14 Feb 2007

The configure errors that I fear are just too aggresive requirements

  • CGI::Carp - Error: 1.20 installed. Version 1.26 required for for base TWiki. Do we really need 1.26?
  • File::Copy - Error: 2.03 installed. Version 2.06 required for for base TWiki. Do we really need 2.06?
  • File::Find - Error: Unknown version installed. Version 1.05 required for for base TWiki. What is the real minumum version?
  • IO::File - Error: 1.08 installed. Version 1.10 required for for base TWiki. Do we really need v 1.10?
  • Time::Local - Error: Unknown version installed. Version 0 required for for base TWiki. My fix from yesterday needs a little more shine to avoid this bogus error. Easy to fix.

Perhaps the one that added these requirements could enlighten us why the specific versions were chosen? Knowledge that earlier versions fail? Or just a matter of the earlier versions not being tested? (Like with Perl 5.6.X - which I can understand - no blame here). IF it is a matter of testing can I get some guidance what specific TWiki features I should test to verify that the versions I currently have are OK? If they pass I can lower the requirements to being my versions.

-- TWiki:Main.KennethLavrsen - 14 Feb 2007

Looking at CGI::Carp. All this module does is send messages to the httpd error log.

The change history

1.23 ineval() now checks both $^S and inspects the message for the "eval" pattern (hack alert!) in order to accomodate various combinations of Perl and mod_perl.

1.24 Patch from Scott Gifford (sgifford@suspectclassNOSPAM.com): Add support for overriding program name.

1.26 Replaced CORE::GLOBAL::die with the evil $SIG{__DIE__} because the former isn't working in some people's hands. There is no such thing as reliable exception handling in Perl.

Hard to believe that we should really require 1.26. I bet we can use even earlier versions that 1.20. And if we loose something it is messages to error log. As long as the syntax we use is new I am sure we can pick a much older version as requirement. At least 1.20.

I looked at the sources for this module and our use. We use use CGI::Carp qw(fatalsToBrowser); The old sources from 1998 rev 1.13 had this feature.

-- TWiki:Main.KennethLavrsen - 14 Feb 2007

Next I look at is File::Copy. It is modules that comes with standard Perl The version that came with Perl 5.6.1 is 2.03. I have been comparing the sources and the basic features have not changed. Both copy and move were there. But some error handling when copying a file with same source and target name has been added and some handling of filenames on MacOS. But my impression is that we do not really need to worry about the version of File::Copy. If the Perl version is 5.5 you have version 2.03 of File copy so instead of trying to define a version of this module I would just remove it from the DEPENDENCIES file and trust the check for the Perl version to handle this.

-- TWiki:Main.KennethLavrsen - 14 Feb 2007

File::Find is part of Perl 5.6.1 and 5.5.3 but has no revision in any of those versions. Again I am sure all we need to do is remove the check for this specific module and just count on the check for the perl version.

-- TWiki:Main.KennethLavrsen - 14 Feb 2007

Finally looked at IO:File. Another standard perl lib which has been part of Perl since 5.5.3 at least. Anything before that we do not want to care about.

The only place we use it is in Statistics.pm for a simple temporary file. We do not even need to use this module. I would say the risk is nill that the simple use we have would be an issue with the version from Perl 5.5.3. So again I would just remove this from the DEPENDENCIES.


Many of the modules that configure complain about seems to be noise.

The admin will run on a machine with a Perl which we must assume contains the standard Perl modules. The modules listed that the admin should need worry about are those that he needs to install in addition to standard basic Perl. And I find it to be nothing but noise to list those that should be included and should be OK.

So I say - let us remove the check for CGI::Carp, File::Copy, File::Find and IO::File and Time::Local.

They have all been in Perl since 5.5.3 or older.

-- TWiki:Main.KennethLavrsen - 14 Feb 2007

I have now tested all the TestCases cases and all look normal under 5.6.1. So so far it looks very good indeed.

-- TWiki:Main.KennethLavrsen - 14 Feb 2007

Unit tests fails under 5.6.1. And I am sure many of the failures are because the test cases fail and not because the actual code fails. I will start analysing.

First error I see is:

There were 6 errors:
1) /var/www/Patch04x01/test/unit/ConfigureTests.pm:203 - test_resection(ConfigureTests)
Can't locate object method "new" via package "File::Temp" (perhaps you forgot to load "File::Temp"?)
2) /var/www/Patch04x01/test/unit/ConfigureTests.pm:128 - test_loadpluggables(ConfigureTests)
Can't locate object method "new" via package "File::Temp" (perhaps you forgot to load "File::Temp"?)
3) /var/www/Patch04x01/test/unit/ConfigureTests.pm:151 - test_conflict(ConfigureTests)
Can't locate object method "new" via package "File::Temp" (perhaps you forgot to load "File::Temp"?)
4) /var/www/Patch04x01/test/unit/ConfigureTests.pm:24 - test_parseSave(ConfigureTests)
Can't locate object method "new" via package "File::Temp" (perhaps you forgot to load "File::Temp"?)
5) /var/www/Patch04x01/test/unit/ConfigureTests.pm:244 - test_UI(ConfigureTests)
Can't locate object method "new" via package "File::Temp" (perhaps you forgot to load "File::Temp"?)
6) /var/www/Patch04x01/test/unit/ConfigureTests.pm:99 - test_2parse(ConfigureTests)
Can't locate object method "new" via package "File::Temp" (perhaps you forgot to load "File::Temp"?)

It seems that File::Temp back in 5.6.1 was not object orientated. In the sources for File::Temp the object method is documented and a note added "not yet implemented". The object method is only used one place. In lib/configure/UIs/Extend.pm. I am sure this could be turned non-object without any loss of anything.

-- TWiki:Main.KennethLavrsen - 14 Feb 2007

InitFormTests.pm fails. But they also fail on perl 5.8. The test case is simply broken.

RegisterTests.pm fails. And also here is the test case broken and needs fixing. Same error on perl 5.8

-- TWiki:Main.KennethLavrsen - 14 Feb 2007

# perl ../bin/TestRunner.pl RenameTests.pm
exporting TWIKI_ASSERTS=1 for extra checking; disable by exporting TWIKI_ASSERTS=0
Assert checking on 1
Time:  2 wallclock secs ( 0.77 usr  1.11 sys +  0.00 cusr  0.76 csys =  2.64 CPU)

Test Results:
Run: 4, Failures: 1, Errors: 0

There was 1 failure:
1) /var/www/Patch04x01/test/unit/RenameTests.pm:343 - test_rename_from_lowercase(RenameTests)
Status: 302 Moved
Set-Cookie: TWIKISID=9ce2a3bc4b3e2fb5480e67e0a6e58f10; path=/
Date: Wed, 14 Feb 2007 23:24:13 GMT
location: /twiki/bin/view/TemporaryRenameOldWeb/UpperCase

 didn't match /(?s-xim:Location:\s+\S+?/view/TemporaryRenameOldWeb/UpperCase)/

Test was not successful.

This test pass on 5.8. But there is something wrong. Try and create using the filesystem a topic which is all lowercase. This was once allowed and we changed TWiki so it renames topics to uppercase first letter. But as code works you cannot open such a topic anymore. This is also an error on 5.8 perl. It will get its own bug topic. Until that is fixed the test case makes no sense.

-- TWiki:Main.KennethLavrsen - 14 Feb 2007

perl ../bin/TestRunner.pl TOCTests.pm
exporting TWIKI_ASSERTS=1 for extra checking; disable by exporting TWIKI_ASSERTS=0
Assert checking on 1
Time:  0 wallclock secs ( 0.26 usr  0.23 sys +  0.00 cusr  0.04 csys =  0.53 CPU)

Test Results:
Run: 2, Failures: 1, Errors: 0

There was 1 failure:
1) /var/www/Patch04x01/test/unit/TOCTests.pm:132 - test_parameters(TOCTests)
expected '?param2=no%20luck;param1=a%20little%20luck', got '?param1=a%20little%20luck;param2=no%20luck'

Test was not successful.

The test result is actually fully valid. The two URL params are simply swapped in order but it is fully valid. Probably a change in behavour of the way the hash of params is pulled. That is know to be non-reproduceable in Perl. So in fact the test case could pass if modified. So maybe an action on the test case.

-- TWiki:Main.KennethLavrsen - 14 Feb 2007

conclusion on tests

Our Patch04x01 is very ready for being a "tested on 5.6.1" product. There are these actions required:

  • DONE Robustness unit case required perl 5.8. Not needed. Lower requirement to 5.6 for now.
  • DONE I remove the 5 dependencies now.
  • DONE I fix the false error that a module with no version is too old when the required version is 0.
  • DONE Change configure warning from less than 5.8 to less than 5.6. (Note we are still far from 5.5.3 support and may choose not to get there).
  • DONE Configure's use of File::Temp need to be changed to non-object
  • And independently of the 5.6.1 Perl support the broken test cases needs to get fixed.
  • DONE And I need to raise a bug item for the lowercase cannot be viewed problem.

-- TWiki:Main.KennethLavrsen - 14 Feb 2007

I am currently working on the non-object use of File::Temp and I think I have it. Just need to check and test more after todays work. Also found that a method in Archive::Tar is missing in the 0.22 version which came with Perl 5.6.1. Also here I think I have a solution. I am currently testing these but because I have another error not related to my changes I am not sure enough yet to check it in this morning.

I would appreciate a quick review of the patch below which is what I am working with. And I would like someone to give feedback if the unmodified Patch04x01 can download and install VotePlugin from configure without error.

Index: lib/TWiki/Configure/UIs/EXTEND.pm
--- lib/TWiki/Configure/UIs/EXTEND.pm   (revision 12875)
+++ lib/TWiki/Configure/UIs/EXTEND.pm   (working copy)
@@ -102,12 +102,13 @@

     # Save it somewhere it will be cleaned up
-    my $tmp = new File::Temp(SUFFIX => $ext, UNLINK=>1);
+    # my $tmp = new File::Temp(SUFFIX => $ext, UNLINK=>1);
+    my ($tmp, $tmpfilename) = File::Temp::tempfile(SUFFIX => $ext, UNLINK=>1);
     print $tmp $ar;
     print "Unpacking...<br />\n";
-    my $dir = _unpackArchive($tmp->filename());
+    my $dir = _unpackArchive($tmpfilename);

     my @names = _listDir($dir);
     # install the contents
@@ -313,9 +314,7 @@

         my @members = $tar->list_files();
         foreach my $file ( @members ) {
-            my $target = $file;
-            my $err = $tar->extract_file( $file, $target );
+            my $err = $tar->extract( $file );
             unless ( $err ) {
                 print 'Failed to extract ',$file,' from tar file ',
                   $tar,". Archive may be corrupt.\n";

-- TWiki:Main.KennethLavrsen - 15 Feb 2007

I had to get rid of some other configure extension installer errors before I could test the above. And it is not working yet. I continue working on this.

-- TWiki:Main.KennethLavrsen - 16 Feb 2007

OK. All bugs fixed. And the extension installer no longer uses methods that did not exist in File::Temp in Perl 5.6.1.

Left is to fix the unit test cases.

-- TWiki:Main.KennethLavrsen - 17 Feb 2007

This is amazing work, Kenneth!

-- TWiki:Main.PeterThoeny - 17 Feb 2007

Fixed the unit test cases ConfigureTests so they now pass in Perl 5.6. Again it is the File::Temp that did not have all the object methods implemented yet in the version shipping with Perl 5.6.1. Easy to fix if it shows up else where.

Just replace

my $fh = new File::Temp(UNLINK=>1);
.... $fh->filename()


my ($fh, $filename) = File::Temp::tempfile(unlink=>1);
.... $filename

-- TWiki:Main.KennethLavrsen - 17 Feb 2007

Found the object File::Temp was used in the extension installer template code. Fixed that. Note that some installers already on t.o will fail with perl 5.6.1. That will get fixed with new releases.

-- TWiki:Main.KennethLavrsen - 18 Feb 2007

Fixed a 5.6.1 related item. Gave it its own item as it could also be a bug in 5.8. See Item3656

-- TWiki:Main.KennethLavrsen - 18 Feb 2007

Unit test case status

  • DONE AccessControlTests.pm
  • DONE AttrsTests.pm
  • DONE AutoAttachTests.pm
  • DONE ClientTests.pm
  • DONE ConfigureTests.pm
  • DONE ExampleTests.pm
  • DONE Fn_IF.pm
  • DONE Fn_NOP.pm
  • DONE Fn_SEP.pm
  • DONE FormattingTests.pm
  • DONE FormDefTests.pm
  • DONE FuncTests.pm
  • DONE HierarchicalWebsTests.pm
  • DONE ALERT! InitFormTests.pm - 9 errors are false alarms because the test cases are designed assuming that CGI always delivers parameters for tags in same sequence. Test case needs to get redesigned. Manual inspection shows correct code generated.
  • DONE MergeTests.pm
  • DONE MetaTests.pm
  • DONE PasswordTests.pm (with same warning as when run in Perl 5.8)
  • DONE PrefsTests.pm
  • DONE RcsTests.pm (with the same type of errors as in Perl 5.8 - do they really pass? In 5.8 the warning is illegal seek. In 5.6 it is bad file descriptor)
  • DONE RegisterTests.pm
  • DONE RenameTests.pm
  • DONE RenderFormTests.pm
  • DONE RobustnessTests.pm
  • DONE SaveScriptTests.pm
  • DONE StoreSmokeTests.pm
  • DONE StoreTests.pm
  • DONE TemplatesTests.pm
  • DONE TimeTests.pm
  • DONE ALERT! TOCTests.pm - test says failed but it is the test case which assumes the query parameters never get swapped. Test case needs to be redesigned. Manual inspection shows that the test case result is OK.
  • DONE UsersTests.pm
  • DONE VariableTests.pm
  • DONE ViewParamSectionTests.pm
  • DONE ViewScriptTests.pm
  • DONE CommentPlugin test case

So getting closer.

-- TWiki:Main.KennethLavrsen - 18 Feb 2007

Updated status above. Only Rename case is now having an unexplained failure. That is my next step

Item3666, Item3665, Item3656, Item3655, Item3648, Item3640 have so far been found and fixed as part of this work. Item3639 is opened but not yet fixed. So it has been a good exercise so far.

-- TWiki:Main.KennethLavrsen - 21 Feb 2007

Another one fixed. Rename problem was just a matter of a lowercase "l" in "Location" probably an old typo bug in the CGI module or similar module and has no impact on the browsers that understand the message anyway.

So that is the last 5.6.1 unit test case failure nailed.

I will functionally test some default plugins before I declare TWiki 4.1.2 supported by Perl 5.6.1

-- TWiki:Main.KennethLavrsen - 21 Feb 2007

I have run out of ideas of what to test now so I am closing this bug item declaring:

TWiki 4.1.2 has been tested on RedHat 7.3, Apache 1.3.23, Perl 5.6.1! smile

I only have a few other bugs I want to fix - then I will release 4.1.2. We are talking days till a release, not weeks.

-- TWiki:Main.KennethLavrsen - 24 Feb 2007

Closed with release of 4.1.2


Cleaned "WaitingFor" field.

-- TWiki:Main.GilmarSantosJr - 10 Aug 2008

Summary TWiki should support at least Perl 5.6.1
ReportedBy TWiki:Main.PeterThoeny
Codebase 4.1.0
SVN Range TWiki-4.1.1, Sun, 04 Feb 2007, build 12769
AppliesTo Engine

Priority Urgent
CurrentState Closed

Checkins 12860 12861 12863 12864 12866 12867 12868 12869 12870 12871 12872 12873 12905 12906 12907 12908 12911 12912 12950 12951
TargetRelease patch
ReleasedIn 4.1.2
Edit | Attach | Watch | Print version | History: r56 < r55 < r54 < r53 < r52 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r56 - 2008-08-10 - GilmarSantosJr
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback