The module code you show in your scratchpad starts with:

package Regexp::CharClasses::Thai;
[download]

but your script (above) has:

use RegexpCharClassesThai;  #Regexp-CharClasses-Thai.pm
[download]

There's a naming mismatch. Assuming at least one of those is correct, you should have one of these three combinations:

package Regexp::CharClasses::Thai;
use Regexp::CharClasses::Thai;
# Regexp/CharClasses/Thai.pm

package RegexpCharClassesThai;
use RegexpCharClassesThai;
# RegexpCharClassesThai.pm

package Regexp-CharClasses-Thai;
use Regexp-CharClasses-Thai;
# Regexp-CharClasses-Thai.pm
[download]

Of course, it's possible all of those are incorrect and you should have a fourth combination.

If they really want to load package Regexp::CharClasses::Thai from a file Regexp-CharClasses-Thai.pm, then the following should work:

BEGIN {
    require 'Regexp-CharClasses-Thai.pm'; # resp. ideally use the full
+ path
    Regexp::CharClasses::Thai->import('IsThaiDigit');
}
[download]

(see also use)

Ken,

The "naming mismatch" is simply accounted for: I put the version in my scratchpad which I intended to publish; however, in my own testing, I removed the colons from the name, both in the package, and in the "use" line of my script. So this was not one of the sources of errors (though I sure wish it could have been that simple). I do appreciate that you were alert to the potential issue with a mismatched name.

Blessings,

~Polyglot~

The first thing those error messages tell me is that ModPerl::ROOT::ModPerl::PerlRun::var_www_cgi_test_2dthai_2dmod_2epl is not a typo; so, my guess without seeing any code, was incorrect.

All of the new errors are "Prototype mismatch". Myself, and many others, would generally advise against using prototypes (see the recent thread: "Too many arguments for subroutine"). Probably the best thing to do is just get rid of them; failing that, ensure you call your subroutines such that there is no mismatch with their prototypes.

The last error you list, which you showed in your earlier post, "Undefined subroutine", is easily fixed: add sub IsThaiLCons { ... whatever it's supposed to do ... } to ModPerl::ROOT::ModPerl::PerlRun::var_www_cgi_test_2dthai_2dmod_2epl.

Ken,

I appreciate your assistance. Regarding "ModPerl::ROOT::ModPerl::PerlRun::var_www_cgi_test_2dthai_2dmod_2epl"...I have no idea what this is. It's obviously related, somehow, to Apache's ModPerl feature. I don't think it has anything to do with Perl, and it most certainly is not anything I created. The "var_www_cgi_test_2dthai_2dmod_2epl" part is a recognizable encoding of some sort for my actual file, i.e. "/var/www/cgi/test-thai-mod.pl". That is the full path of the file...there is no "ModPerl::..." behind it.

Error messages often are most unhelpful. This is just such a case. It was a "ModPerl::ROOT::ModPerl::..." error of some sort that once disappeared after a "service apache2 restart" command (after spending several hours trying to puzzle it out with my code); but I have not been so lucky with this second round. Of course, Googling it gets me nowhere, other than to a realization that, as is often the case, I'm quite unique. I'm actually relatively certain that my code is not the culprit...but things never seem to work like they should for me, so perhaps I'm just oblivious to something I've done wrong.

Blessings,

~Polyglot~

It's more than two decades since I did any serious work with Apache or mod_perl. I'm not in a position to offer any assistance in that area.

— Ken

Also, I have no idea what "prototypes" mean with respect to Perl. If I'm using any, it is in complete ignorance of what they are or what they are called. My previous version of the module, before I changed the subroutine formatting and added the "list" routine, did not generate such an error. It actually ran. So, I'm considering reverting all the work I put into such a nice formatting as I have now, and going back to what I had before. Ugly that works is better than useless beauty--though it could be somewhat less ugly than before.

Blessings,

~Polyglot~

"I have no idea what "prototypes" mean with respect to Perl."

Well, I provided you with a link: "Too many arguments for subroutine". That discusses prototypes, has links to Perl's official documentation as well as other PerlMonks' discussions. It's up to you whether you read it.

— Ken

Looking at those errors, all the Prototype mismatch are for Test::More functions. Are you sure that Test::More is compatible with your mod_perl¹ environment? (I did a brief check that verified Test::More isn't immediately incompatible with a simple CGI² environment. But I have no experience with nor access to mod_perl, so I cannot give more details on mod_perl specifics.)

The Premature end of script headers is often seen when there's an error printed out before you've printed the headers. For that, I might recommend changing the order at the top of your script, and add a 'BEGIN' block to enforce headers before it includes other:

use strict;
use warnings;
BEGIN {
    $|=1;
    print "Content-Type:text/html; charset=utf-8\n";
    print "Content-Language: utf8;\n\n";
}
use lib '/';
use lib '/var/www/lib/';
#push @INC, '/var/www/lib/';
use RegexpCharClassesThai;  #Regexp-CharClasses-Thai.pm
use utf8;
use Test::More;
[download]

Also, if you have access to CGI::Carp², try use CGI::Carp qw(fatalsToBrowser);, which might help by putting more info into the browser rather than buried in error logs.

Based on this sequence from your post (code then error message):

use RegexpCharClassesThai;  #Regexp-CharClasses-Thai.pm
...
my @inthai = &IsThaiLCons;
...
Undefined subroutine &ModPerl::ROOT::ModPerl::PerlRun::var_www_cgi_tes
+t_2d
+thai_2dmod_2epl::IsThaiLCons called at /var/www/cgi/test-thai-mod.pl 
+line 19.
[download]

First, are you sure that RegexpCharClassesThai.pm exists, or is it really at the Regexp-CharClasses-Thai.pm that your comment implies? If the latter, you will need to make sure your use and your module naming match correctly.

Second, if it is loading the module properly, does the module export IsThaiLCons by default, or are you supposed to include it in an export list, like use RegexpCharClassesThai qw/IsThaiLCons/;?

Third: &subname is not the recommended syntax for function calls³. Why not just use my @inthai = IsThaiLCons; -- or, if you are like me and like an indication when something's a function without arguments, my @inthai = IsThaiLCons();?

¹: I assume that having ModPerl in the package hierarchy implies that you're in a mod_perl environment. I could easily be wrong about that.

²: not to be confused with CGI.pm, which I didn't include, nor did you -- this is to head off the people whose knee-jerk reaction to seeing the letters CGI is to say you shouldn't be using that any more.

³: Sorry, I cannot recall a reference for that off the top of my head, and I couldn't find it with a couple minutes of searching. Other monks will be able to point you to the dangers and arguments against calling a subroutine with the &sigil and no argument list.

Thank you. The comment about the filename was just there to remind me that I have renamed it temporarily to avoid having such a deep directory tree as the "Regexp::CharClasses::Thai" would require. I'm just testing, and am not actually "installing" the module on my machine, so the test script must be told where to find the file, and, yes, the file, as named in the test script, exists there.

Regarding the "&IsThaiLCons" versus "IsThaiLCons()" -- I've tried them both, and both produce the same error.

Yes, the module should be exporting that subroutine. I've tweaked that several times, sometimes having it export specifically that one function for testing purposes...and I've even tried commenting out the entire "Exporter" code block to force everything to be available to the calling script by default. Nothing seems to change the irritating log messages. Maybe I should just restart the entire server! The errors/bugs I spend the most time on are the ones I have the least idea where something could even possibly be wrong--as fits this situation. I don't see much wrong with any of the code. When this happens to me, sometimes I end up spending entire days trying to fix the issue.

It reminds me of some years ago when the problem might have been an invisible BOM mark as the first character in the file!

Apache is running the Perl scripts somehow. I guess it does so via the "modperl" feature. Perhaps there is some better way? One begins to wonder.

Blessings,

~Polyglot~

Regarding the "&IsThaiLCons" versus "IsThaiLCons()" -- I've tried them both, and both produce the same error.

In that case it is highly likely that the module isn't exporting a sub by that name. Either modify the module to export the sub or else call it with the full package name in your script.

And don't forget that the first S in SSCCE stands for "Short". The shorter your failing script is, the easier it will be to find the problem.

---

🦛