Re: utils/perldoc.Com vs utils/perldoc
On Thu, Sep 19, 2013 at 10:29:37PM -0500, Craig A. Berry wrote:
On Sep 19, 2013, at 1:36 PM, Nicholas Clark n...@ccl4.org wrote:
So, my question is, surely that file should be installed as
utils/perldoc.COM not utils/perldoc?
Yes.
Would anyone notice if it wasn't installed as utils/perldoc?
(This might be related to the question below)
And if so, where in ExtUtils::MakeMaker does it need fixing?
Good question. ExtUtils::MakeMaker::MM_Unix::installbin says:
=item installbin (o)
Defines targets to make and to install EXE_FILES.
but I think it's lying. It doesn't seem to make anything at all but mostly
copies files into place after fiddling with the shebang line. I think there
is also some special handling if it finds POD in the file. I suppose the
file copy line in there should append .com if it's not already present.
It seems to. I've just mailed perl5-porters a result of digging some more:
In that, as best I can tell, on all platforms the makefile copies the script
to the $(INST_SCRIPT) directory, and then runs the $(FIXIN) command:
$(INST_SCRIPT)/shasum : shasum $(FIRST_MAKEFILE) $(INST_SCRIPT)$(DFSEP).exists
$(INST_BIN)$(DFSEP).exists
$(NOECHO) $(RM_F) $(INST_SCRIPT)/shasum
$(CP) shasum $(INST_SCRIPT)/shasum
$(FIXIN) $(INST_SCRIPT)/shasum
-$(NOECHO) $(CHMOD) $(PERM_RWX) $(INST_SCRIPT)/shasum
On *nix the FIXIN command is this
FIXIN = $(ABSPERLRUN) -MExtUtils::MY -e 'MY-fixin(shift)' --
and on VMS just the quoting differs:
FIXIN = $(ABSPERLRUN) -MExtUtils::MY -e MY-fixin(shift) --
MY-fixin calls the fixin() method, which uses $Config{startperl} to change
the #! line
However, the filename is unchanged.
On Win32, the FIXIN command appears to be this:
FIXIN = $(PERLRUN) ../../win32/bin/pl2bat.pl
As best I can tell, in the case pl2bat.pl would create a shasum.bat file
within $(INST_SCRIPT)
As far as the perl core goes, I believe that ./installperl will *only*
install shasum.bat
However, if one builds Digest::SHA (or Pod::Perldoc, or anything else) from
a tarball, does it end up with both shasum and shasum.bat being installed?
__END__
So it looks like the FIXIN command would be the correct place to do such a
renaming. Or duplicating.
(Does anyone on VMS actually install modules from CPAN that have scripts?)
Probably rarely. And installing it wouldn't let you run it automatically
anyway unless you happen to put perl_root:[utils] into DCL$PATH. The reason
you had it still looking for perldoc.com even after you deleted that file is
because there is a foreign command for perldoc defined in perl_setup.com
(more or less like an alias as John said).
Yes, I'd spotted that before I mailed. (I didn't say that, sorry)
So it looks like on Win32, both foo and foo.bat are installed, but foo and
foo.bat differ.
Whereas, if I've got VMS figured out, foo and foo.com would be identical,
because $Config{startperl} is this:
$ perl 'f$env(procedure)' ''p1' ''p2' ''p3' ''p4' ''p5' ''p6' ''p
7' ''p8'!
$ exit++ + ++$status!=0 and $exit=$status=undef; while($#ARGV != -1 and $ARGV[$#
ARGV] eq ''){pop @ARGV;}
#!perl
and ALTERNATE_SHEBANG is defined as $, resulting in toke.c skipping over
the first line. The other 2 are valid perl, as B::Deparse demonstrates:
$ perl -MO=Deparse [.perl-58583d21ac03_ROOT.utils]perldoc.com
$exit = $status = undef if $exit++ + ++$status != 0;
while ($#ARGV != -1 and $ARGV[$#ARGV] eq '') {
pop @ARGV;
}
require 5;
sub BEGIN {
$^W = 1 if $ENV{'PERLDOCDEBUG'};
}
use Pod::Perldoc;
exit 'Pod::Perldoc'-run;
So, I guess next VMS question is:
Is it actually necessary to install both (eg) perldoc and perldoc.com?
In that, ignoring backwards compatibility with what people expect
1) We seem to have a discrepancy between what the core installs for perldoc,
and what a CPAN update installs
2) We seem to have a discrepancy between scripts installed by the core
(foo.com) and scripts installed by non-core modules (just bar)
3) It would make the core build process a lot easier if ExtUtils::MakeMaker
did the .com trick, as it's already doing the .bat dance for Win32,
because this would permit a lot of simplification of the utils/ directory.
Nicholas Clark
Re: test.pl runperl() exit oddity
On Wed, Aug 07, 2013 at 01:04:47PM -0500, Craig A. Berry wrote: On Wed, Aug 7, 2013 at 12:18 PM, Nicholas Clark n...@ccl4.org wrote: 2) Why does runperl() in t/test.pl abort on VMS if exit status is wrong? (or is it vmspipe.com aborting?) When you run vms/test.com, it's running t/TEST by default. Isn't bailing out early the normal behavior for TEST (as opposed to harness)? The abort messages are just the usual result of transmogrifying a generic unixy failure exit to a generic VMS failure exit: $ perl -e exit 1; %SYSTEM-F-ABORT, abort Yes, it is. I've got spoiled by t/harness, which doesn't, and failed to realise that t/TEST behaves differently. Nicholas Clark
Re: regression test filesystem assumptions
On Wed, Aug 07, 2013 at 10:03:17PM -0500, Craig A. Berry wrote:
On Aug 7, 2013, at 12:23 PM, Nicholas Clark n...@ccl4.org wrote:
I have this commit pushed to a smoke-me branch. It doesn't cause any test
failures on the HP VMS testdrive system. Am I making bad assumptions?
Specifically, is it filesystem dependant whether this code as-is will pass?
open(H,'run/fresh_perl.t'); # must be in the 't' directory
stat(H);
print ok\n if (-e _ and -f _ and -r _);
I can't think of any reason that would be different on different filesystems.
OK, good. I wasn't totally sure, and wanted to avoid making a mistake that
caused someone else more work.
I infer that it must have failed 12 years ago, because the last line was
corrected to
print ok\n if (-e _ and -f _);
But what changed to cause it to work now?
There have been various fixes to stat as well as to Perl_cando_by_name in
vms/vms.c. None I've managed to stumble on in the archives pops out as
obviously the one, and it would be arduous to do a manual bisect without
git.
OK. I was curious if it was obvious to someone else, and it's not.
commit 219b23a016e4d19b9fc29d2cb6aad7c8f485e7bc
Author: Nicholas Clark n...@ccl4.org
Date: Wed Aug 7 11:57:09 2013 +0200
open TEST, $tmpfile or die Cannot open $tmpfile: $!;
-
-# VMS adjustments
-if( $is_vms ) {
-$prog =~ s#/dev/null#NL:#;
-
-# VMS file locking
-$prog =~ s{if \(-e _ and -f _ and -r _\)}
- {if (-e _ and -f _)}
-}
-
print TEST $prog;
close TEST or die Cannot close $tmpfile: $!;
I think these changes are sane. Once upon a time, the CRTL did not support
/dev/null as an alias for the native _NLA0:. I forget when /dev/null became
supported; possibly v7.0, which was about 1995 or so. I remember Chuck Lane,
who wrote the misc.t patch, saying at some point that he was running v6.2,
which was already somewhat old at the time. I explicitly removed support for
pre-7.0 VMS systems in Perl 5.16.x, so the /dev/null workaround seems safe to
remove.
I think I disagree about whether these belonged in the test runner; that
actually was the general place to solve a general problem, even if there
weren't other extant tests that exercised the problem. But those problems
don't seem to be there now, so thanks for cleaning up after us.
Yes, to be fair I'm in two minds about the /dev/null one, as it might show
up in other places. But it was bugging me that it's only VMS - surely other
platforms need similar fixes? But as George Greer observed, Win32 has a
special case:
DllExport FILE *
win32_freopen(const char *path, const char *mode, FILE *stream)
{
dTHXa(NULL);
if (stricmp(path, /dev/null)==0)
path = NUL;
aTHXa(PERL_GET_THX);
return freopen(PerlDir_mapA(path), mode, stream);
}
(and similar code in 2 other places)
But I think that the pattern match for qr/if \(-e _ and -f _ and -r _\)/ was
so specific that it was only ever going to match one test.
Nicholas Clark
Re: test.pl runperl() exit oddity
On Wed, Aug 07, 2013 at 12:50:55PM -0500, Craig A. Berry wrote: $ sh -c 'pstree -p $$ | cat' sh(13261)-+-cat(13263) `-pstree(13262) $ ksh -c 'pstree -p $$ | cat' cat(13349)---pstree(13350) The root cause of the problem on VMS is that command-line redirection is done by Perl and not by the shell. Tony's addition of the stdin parameter to runperl gives us the equivalent of: $ perl -e exit 2; | perl -e exit 0; %NONAME-E-NOMSG, Message number 0002 $ show symbol $status $STATUS == %X0002 The Perl process with an exit value of 0 is a child of the one that has an exit value of 2 so the final status we see in runperl is the exit value of the parent, not of the child. But the child is actually the test program whose exit value we're interested in and we don't get it this way. I *think* on *nix both perl invocations are subprocesses of the shell, or in any case $? is 0 when all is said and done, i.e., the exit status from the second Perl invocation. Well, it turns out to differ between /bin/sh and /bin/ksh (which was the cause of the AIX bug), but whether it's (ksh) child | parent or (sh) child | child, either way the exit status of the pipeline is that of the *last* command. (This has turned out to be dangerous in the *nix Makefile. There were one or two rules which were some_command ... | sort output and if some_command failed, it wasn't noticed, because make picked up the exit status of the sort, which was 0. I refactored things to avoid the need for pipelines.) This sort of means that the VMS pipeline setup is the wrong way round. At least, it's the wrong way round if it wanted to be consistent with Unix. Even if it's possible to change, I doubt that it would be a good idea. I have a working patch that fixes it by doing a piped open and writing to the pipe that provides the stdin of the child, then capturing the child's exit and passing it along. It's ugly and makes the VMS code in t/test.pl even more different than it already is. I've been sitting on it for a bit hoping to think of something better, but it looks like you've now done that. If /dev/null has portability problems on Win32, simply lifting the platform-specific code from File::Spec::dev_null should provide the solution in a very small amount of additional code. Well, I sort of worked round it by not using a pipeline. But it achieves the end goal. Nicholas Clark
test.pl runperl() exit oddity
Direct I/O count: 1686033 Peak virtual size: 224288 Page faults: 1735612 Mounted volumes:0 Images activated:4218 Elapsed CPU time: 0 00:07:36.68 Connect time: 48 19:32:41.25 %SYSTEM-F-ABORT, abort Note 1) All three fail on the first program which has an expected nonzero EXIT STATUS 2) For all three, the test script aborts at that point When I change t/test.pl to use the generated backticks redirecting from /dev/null instead of using a pipeline, all 3 pass again. (This is currently on smoke-me/nicholas/runperl-empty-STDIN and I will merge it to blead when results come in for Win32 and a couple of other systems) Questions 1) Why does using a pipeline in backticks change the exit status? 2) Why does runperl() in t/test.pl abort on VMS if exit status is wrong? (or is it vmspipe.com aborting?) *nix doesn't abort on the first test, and I don't think that Win32 does either. Nicholas Clark
regression test filesystem assumptions
I have this commit pushed to a smoke-me branch. It doesn't cause any test
failures on the HP VMS testdrive system. Am I making bad assumptions?
Specifically, is it filesystem dependant whether this code as-is will pass?
open(H,'run/fresh_perl.t'); # must be in the 't' directory
stat(H);
print ok\n if (-e _ and -f _ and -r _);
I infer that it must have failed 12 years ago, because the last line was
corrected to
print ok\n if (-e _ and -f _);
But what changed to cause it to work now?
Nicholas Clark
commit 219b23a016e4d19b9fc29d2cb6aad7c8f485e7bc
Author: Nicholas Clark n...@ccl4.org
Date: Wed Aug 7 11:57:09 2013 +0200
Remove the two VMS adjustments from test.pl's _fresh_perl
These were added by commit ed6b3797850720f7 (make t/op/misc.t work on VMS)
in Jan 2001 back when the relevant code was in t/op/misc.t
The two adjustments each only applied to one test.
Was:system './perl -ne print if eof /dev/null'
Became: system './perl -ne print if eof NL:'
Was:print ok\n if (-e _ and -f _ and -r _);
Became: print ok\n if (-e _ and -f _);
The latter had the comment VMS file locking.
It seems that neither is needed now. Perl will recognise /dev/null as
the null device, and -r returns true on a file opened for reading.
The adjustments, particularly the second, should have been done all along
in the code for the test itself, not by complicating the test runner.
diff --git a/t/test.pl b/t/test.pl
index 89c1d4d..3662aa6 100644
--- a/t/test.pl
+++ b/t/test.pl
@@ -848,16 +848,6 @@ sub _fresh_perl {
$runperl_args-{stderr} = 1 unless exists $runperl_args-{stderr};
open TEST, $tmpfile or die Cannot open $tmpfile: $!;
-
-# VMS adjustments
-if( $is_vms ) {
-$prog =~ s#/dev/null#NL:#;
-
-# VMS file locking
-$prog =~ s{if \(-e _ and -f _ and -r _\)}
- {if (-e _ and -f _)}
-}
-
print TEST $prog;
close TEST or die Cannot close $tmpfile: $!;
Re: test.pl runperl() exit oddity
On Wed, Aug 07, 2013 at 06:29:26PM +0100, Steve Hay wrote: Nicholas Clark wrote on 2013-08-07: It turns out that this causes fun on AIX with two tests, because on AIX /bin/sh is actually ksh, and ksh does pipes differently (with one less process). With sh, for the latter command line the sh process forks two children, which use exec to start the two perl processes. The parent shell process persists for the duration of the pipeline, and the second perl process starts with no children. With ksh (and zsh), the shell saves a process by forking a child for just the first perl process, and execing itself to start the second. This means that the second perl process starts with one child which it didn't create. This breaks the tests assume that wait (or waitpid) will only return information about processes started within the test. One can replicate this is on Linux: $ sh -c 'pstree -p $$ | cat' sh(13261)-+-cat(13263) `-pstree(13262) $ ksh -c 'pstree -p $$ | cat' cat(13349)---pstree(13350) I thought about fixing the tests to make them immune to unexpected extra child processes, but then realised that it was probably easier to change the generated backtick command to be `./perl /dev/null -Ilib -e ...` And the commit message for reads: Fortuitously it seems that the string /dev/null is portable enough to work with the command line parsing code on VMS and Win32 too. Yes, I asked on #win32 and didn't get a useful answer. Thanks for spotting this. What command line parsing code are you talking about here? I'm not aware of /dev/null being valid on Windows in general; I've always used the device called nul instead: D:\tempperl /dev/null -e1 The system cannot find the path specified. D:\tempperl nul -e1 Does perl nul.txt -e1 work too? (ie it's still compatible with MS/DOS and earlier) My assumption was based on what seem to be several regression tests that opened /dev/null and aren't failing on Win32. Starting with this in t/base/term.t: open(try, /dev/null) || open(try,nla0:) || (die Can't open /dev/null.); also t/lib/warnings/pp_sys has # pp_sys.c [pp_leavewrite] use warnings 'io' ; format STDOUT_TOP = abc . format STDOUT = def ghi . $= = 1 ; $- =1 ; open STDOUT, .($^O eq 'VMS'? 'NL:' : '/dev/null') ; write ; no warnings 'io' ; write ; EXPECT page overflow at - line 13. and t/lib/warnings/sv contains open F, .($^O eq 'VMS'? 'NL:' : '/dev/null') ; Is it that /dev/null works from within perl, but not on the command line? If so, the fix would seem to be to change the new code to $runperl = $runperl . ($is_mswin ? ' nul' : ' /dev/null'); Does this make t/op/fork.t test 16 pass again on Win32? That now seems to be failing, and I don't know why. Nicholas Clark
Re: mms case sensitivity build failures (was Re: HP hobbyist license)
On Wed, May 16, 2012 at 10:36:54AM -0600, Mark Berryman wrote: Some answers: 6: How do I deal with filenames with ^. (etc) in them from DCL? Without resorting to bash? Is it really the only option to rename directory names to remove the .s? I don't follow this question. For the first part: Issue the command $ SET PROCESS/PARSE_STYLE=EXTENDED to be able to use filenames with ^ in them. I recommend putting this command in your LOGIN.COM file (let me know if this needs further explaining). If the filename in question is a directory reference you must type the filename as is, including the ^ characters, e.g. [.perl-5^.14^.2] If the filename is a regular file, you can type it in with or without the ^ characters, e.g. file^.c.orig or file.c.orig. I don't know what the .s refers to. Can you provide an example? Sorry, wasn't clear. By .s I meant the periods in the filenames The problem was that I didn't have SET PROCESS/PARSE_STYLE=EXTENDED I do now. I've also found that I can avoid most of the problems in the first place by generating my perl tarball on Linux like this: commit=`git rev-parse --short=12 HEAD`; tar cf perl-$commit.tar --files-from (sed -e 's/[ ].*//' MANIFEST) --transform 's!^!perl-'$commit'/!' from within a checkout, which gets me a tar with a clean name such as perl-247d6b204efe.tar with the internal pathnames prefixed with perl-247d6b204efe, and all the files nicely read-write. It looks like current *BSD tar can do the same trick, but the options have different names. This might need more knowledge of the machine than the above -v and -V reveal 7: How do I actually use the libraries of that installed perl 5.8.6? The directory tree where perl is installed will be pointed to by the logical name PERL_ROOT. Try $ DIR PERL_ROOT:[LIB] as a starter. The perl sharable image that one must link to will be pointed to by the logical name PERLSHR. Simply use the name PERLSHR in any link procedure to link to that library. It seems that the system setup wasn't correct. They've fixed it now - the system installed perl 5.8.6 now works. I bought my system directly from Compaq/HP, with licenses, so I have no problem doing any form of development. If it will help, you are welcome to an account here. Thanks for the offer. I think (for now) it's much easier if I stick to the HP porting system, as it's a known quantity. In particular, it's known to John E. Malmberg, which means that he's mostly already worked out how to fix or work around the causes underlying the problems I describe. Nicholas Clark
Re: HP hobbyist license
On Tue, May 15, 2012 at 04:11:32PM +, Craig A. Berry wrote: I believe you can still get an account on an HP server for purposes of open source porting. See (Which of course is what I'm now using) In that case HP would be the license holder. Also, it might be something slightly less ancient than the old alpha the deathrow folks have. George Greer started down this path to set up a smoker and got tangled up at how different it is from anything he's used to, but he did get as far as a relatively clean build of 5.14.1. It would be *very* useful to have a VMS smoker automatically processing smoke-me branches. I've not looked at the smoke testing code, but the biggest concerns I'd have are 0: Can the machine cope with it? I suspect that smoke-testing is a full time job. 1: Are HP happy with it? :-) 2: Presumably the smoker process fires off with cron, or somesuch. I don't know any VMS sysadmin type stuff to translate how things are done from Unix. Nicholas Clark
Re: scp to VMS
On Sat, Jun 02, 2012 at 12:13:26PM -0500, John E. Malmberg wrote: VMS Engineering has given us some feedback on SCP: The pscp program from Linux putty tools package will work with the VMS SCP program. I tested this and it work. I already seem to have it installed on the local Ubuntu machine. (Side effect of playing with pterm, after getting fed up with Gnome terminal) This package does not appear to be available for Mac OS-X, so I do not have a solution there. It all builds from source, once I remove the -Werror (It finds the Gtk I have installed from macports, and one of the putty programs is using functions which this version of Gtk has marked as deprecated) Thanks for finding this. Nicholas Clark
Re: scp to VMS (Re: mms case sensitivity build failures (was Re: HP hobbyist license))
On Fri, May 18, 2012 at 09:48:43AM +0200, martin.zin...@eurexchange.com wrote: Hello, a.) Agree with Craig on scp . If this is fixed either it is extremely recent (doesn't work with 5.7 ECO 3) or it needs some additional magic. b.) In case you just need to move around Perl source files, which are not terribly secret, you could use FTP instead of scp. On the VMS side of the house, the easiest way to do so is The source files aren't terribly secret, but any password I need to log into the remote server I'm getting them from is. :-( (Although therefore I could just serve them up over HTTP and solve it that way) Nicholas Clark
Re: scp to VMS (Re: mms case sensitivity build failures (was Re: HP hobbyist license))
On Thu, May 17, 2012 at 12:16:14PM -0500, Craig A. Berry wrote: On May 17, 2012, at 5:49 AM, Thomas Pfau wrote: I understand this problem is fixed with the new ssh that comes with OpenVMS 8.4. Prior to this, scp does not work to openssh systems. It seems not, actually. With a server that looks like: $ tcpip show vers HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.7 - ECO 2 on an HP rx2600 (1.50GHz/6.0MB) running OpenVMS V8.4 coming from an OS X client (with remote address changed to protect the guilty): So while I probably had the nomenclature and version numbers confused in my previous post, there is definitely something still wrong with agreeing on a mutually acceptable version of something. It looks like it's a very old problem for servers that do not support multiple protocols: http://www.snailbook.com/faq/scp-ossh-to-ssh2.auto.html. Yes, this is the fun, and why it turns out that scp from VMS out to *nix works, but not the other way. Pretty much every *nix is using OpenSSH, whereas the VMS ssh is commercial ssh. OpenSSH has the original scp command, which I think is actually the source code of rcp with some edits. The rcp design is to have the same binary able to act as client and server. OpenSSH also provides sftp. What then happened was that the commercial ssh tools were re-written, with scp2 being a new version, command-line compatible with the existing scp, but implemented completely differently. Instead of using ssh to start another instance of the scp program on the remote host, it uses the sftp subsystem. This is why one can run scp on VMS to talk to a *nix system, but not the other way. (Been ill for the past couple of days, hence why I've not replied to any e-mail. Or done much else, either, for that matter) Nicholas Clark
RC2 on the HP Opensource cluser
: Bad plan. You planned 21 tests but ran 14. ../cpan/Module-Build/t/perl_mb_opt.t(Wstat: 1024 Tes ts: 8 Failed: 2) Failed tests: 4, 8 Non-zero exit status: 4 ../cpan/Module-Build/t/PL_files.t (Wstat: 1024 Tes ts: 0 Failed: 0) Non-zero exit status: 4 Parse errors: Bad plan. You planned 8 tests but ran 0. ../cpan/Module-Build/t/runthrough.t (Wstat: 1024 Tes ts: 29 Failed: 2) Failed tests: 11, 13 Non-zero exit status: 4 ../cpan/Module-Build/t/script_dist.t(Wstat: 1024 Tes ts: 7 Failed: 0) Non-zero exit status: 4 ../cpan/Module-Build/t/test_file_exts.t (Wstat: 1024 Tes ts: 3 Failed: 2) Failed tests: 2-3 Non-zero exit status: 4 ../cpan/Module-Build/t/test_types.t (Wstat: 1024 Tes ts: 25 Failed: 21) Failed tests: 2-3, 5-13, 15-16, 18-25 Non-zero exit status: 4 ../cpan/Module-Build/t/tilde.t (Wstat: 1024 Tes ts: 16 Failed: 1) Failed test: 16 Non-zero exit status: 4 ../cpan/Module-Build/t/use_tap_harness.t(Wstat: 1024 Tes ts: 9 Failed: 4) Failed tests: 2-3, 6, 9 Non-zero exit status: 4 ../cpan/Module-Build/t/properties/dist_suffix.t (Wstat: 1024 Tes ts: 2 Failed: 1) Failed test: 2 Non-zero exit status: 4 ../cpan/Module-Build/t/properties/share_dir.t (Wstat: 1024 Tes ts: 14 Failed: 0) Non-zero exit status: 4 Parse errors: Bad plan. You planned 21 tests but ran 14. ../cpan/Test-Harness/t/source_handler.t (Wstat: 1024 Tes ts: 79 Failed: 4) Failed tests: 19-20, 23-24 Non-zero exit status: 4 ../cpan/Test-Harness/t/testargs.t (Wstat: 1024 Tes ts: 8 Failed: 0) Non-zero exit status: 4 Parse errors: Bad plan. You planned 21 tests but ran 8. ../cpan/Time-HiRes/t/HiRes.t(Wstat: 0 Tests: 48 Failed: 4) Failed tests: 41, 44-45, 48 ../lib/File/Copy.t (Wstat: 0 Tests: 463 Failed: 0) TODO passed: 53 Files=2080, Tests=430164, 6710 wallclock secs (180.04 usr + 0.00 sys = 180.04 C PU) Result: FAIL I haven't investigated to see whether the different test numbers reported are actually the same underlying tests failing. Also, I've not investigated whether the new failures are totally new test scripts. (Been pretty grotty for the past 2 days, and not got anything done. About to go away for the weekend, offline, hence this rather rushed message) Nicholas Clark
mms case sensitivity build failures (was Re: HP hobbyist license)
Questions for my new blockers at the end. On Tue, May 15, 2012 at 06:30:16PM -0500, John E. Malmberg wrote: On 5/15/2012 12:52 PM, Carl Friedberg wrote: At this very moment, all 3 of my VMS servers are unreachable, but normally they are accessible. I have two (pretty ancient) AlphaServer 800's, single 500mhz processor, 2 Gb memory, running recent VMS with hobbyist licenses. I also have an Itanium RX2600 dual-core box running OpenVMS 8.4 (similar to the one Craig uses, I suspect). All of these are available to perl developers. Send me an e-mail and I will set up an account for you. Thanks for this offer (and to the person who mailed me privately earlier and set me up an account on a machine, who may not want to be publicly named. The problem is that as Nicholas Clark is being paid for this work, it may not be legal to do it on a system licensed with Hobby licenses. This is precisely the problem. It's a grey area. I'm being paid. Whilst I'm being paid by a US 501(c)(3) non-profit, I'm not an employee of *it* - effectively I'm a consultant, albeit at very non-consultant rates. As part of an offline conversation, Nicholas Clark is getting access to the HP Open Source cluster, which should cover the licensing issue. HP have (re)enabled the account on the server which dates from 2010, but I was unable to get working then. (Strangely, I did have a different ssh host key for both IPs in known_hosts on one of my shell accounts, so I don't really know what the history of this is. I don't mind. Access works now) I have solved *one* question I had - it's commercial SSH, key *filenames* go in [.ssh2]authorization and keys (converted from OpenSSH format) go into that directory. But as it's commercial SSH, scp doesn't work from any Unix system. Even HP-UX ssh: OpenSSH_5.3p1+sftpfilecontrol-v1.3-hpn13v5, OpenSSL 0.9.8l 5 Nov 2009 HP-UX Secure Shell-A.05.30.008, HP-UX Secure Shell version Left hand, meet right hand please. So I'm left with sftp, which is functional, but not as automatable. The banner on each machine says that many things are installed, including Perl, but I can't even work out how to invoke them natively, and even from bash, I can't figure out how to The clocks are wrong on the machines. The time*zone* seems to be set up correctly for Indian Standard Time, but right now it thinks it's: Wed May 16 09:08:35 IST 2012 whereas the time really is Wed 16 May 2012 14:23:59 BST I need to report this and request it to be fixed, as the future times on incoming files cause repeated builds. Which I can only work around painfully by force-touching files to a different datestamp before building. So, general questions 1: Is there any easy way to get an scp2 client for Unix, so that I can scp to them? (And use editors remotely) 2: Does rsync exist for VMS? 3: Does ccache exist for VMS? 4: What is the ls command, and how do I escape from it when I run it accidentally? 5: What's the DCL equivalent of rm -rf? Is it really a Perl 1-liner with File::Path::remove_tree()? 6: How do I deal with filenames with ^. (etc) in them from DCL? Without resorting to bash? Is it really the only option to rename directory names to remove the .s? This might need more knowledge of the machine than the above -v and -V reveal 7: How do I actually use the libraries of that installed perl 5.8.6? Actual build problems: 8: The Alpha machine fails the build because the target is converted to uppercase. How come no-one else has this problem? ptac$dka0:[nclark.a.perl5160-rc2]miniperl.exe;2 -I../../lib Makefile.PL INS T_LIB=[--.lib] INST_ARCHLIB=[--.lib] PERL_CORE=1 Writing Descrip.MMS for Pod::Simple %MMS-F-BADTARG, Specified target (CONFIG) does not exist in the description file . %MMS-F-BADTARG, Specified target (CONFIG) does not exist in the description file . MMS config /DESCRIPTION=descrip.mms /MACRO=(PERL_CORE=1) failed, continuing a nyway... Making all in cpan/Pod-Simple MMS all /DESCRIPTION=descrip.mms /MACRO=(PERL_CORE=1) %MMS-F-BADTARG, Specified target (ALL) does not exist in the description file. %MMS-F-BADTARG, Specified target (ALL) does not exist in the description file. Unsuccessful make(cpan/Pod-Simple): code=1024 at make_ext.pl line 466. %MMS-F-NOMSG, Message number 00EE826C %MMS-F-ABORT, For target nonxsext, CLI returned abort status: %X00EE826C. -MMS-F-BADTARG, Specified target (!AS) does not exist in the description file. MMS says: $ mms/ident %MMS-I-IDENT, MMS V3.8 © Copyright 2007 Hewlett-Packard Development Company, L.P . I think I can see how to fix it in make_ext.pl by using quotes, but what else will it break? And how come no-one else has this problem. 9: The IA64 machine *initially* fails like this: MCR PTAC$DKA0:[NCLARK.I.perl5160-RC2]miniperl.exe -I[--.lib] -I[--.lib] -ME xtUtils::Command -e cp -- DYNALOADER.OPT [--.LIB.AUTO.DYNALOADER]DYNALOADER .OPT %MMS-F-GWKNOACTS, Actions to update DL_VMS.C are unknown. %MMS-F-GWKNOACTS
Re: mms case sensitivity build failures (was HP hobbyist license)
On Wed, May 16, 2012 at 04:34:18PM +, Craig A. Berry wrote: [snip useful answers which aren't directly blocking] 8: The Alpha machine fails the build because the target is converted to uppercase. How come no-one else has this problem? I'm going to punt on the MMS issues for the moment. The short answer is you cannot build Perl with MMS currently but must use MMK, available here: http://www.kednos.com/kednos/Open_Source/MMK. In which case, README.vms needs some updating :-) I've downloaded it, built it and installed it by copying to PTAC$DKA0:[NCLARK.bin]mmk (This probably isn't the best idea, as that directory is on the cluster, hence common to the IA64 and alpha machines, so really I'm going to need to figure out a better way of keeping binaries from the two architectures segregated.) In turn, I configure.com, I can't specify MCR PTAC$DKA0:[NCLARK.bin]mmk as my make utility, because this ends up with configure.com bombing out with the current directory as [.UU], having produced a Descrip.MMS which is (IIRC) solely 2 lines of errors about files it can't open. Nor does specifying make work (GNU make 3.78.something is installed) If I specify mmk then configure.com does build a Descrip.MMS correctly. However, just running MRC PTAC$DKA0:[NCLARK.bin]mmk soon fails to build further. Doing *this* gets me a lot further: MMK := mcr PTAC$DKA0:[NCLARK.bin]mmk However, the build fails at a subdirectory of Encode: Making all in cpan/Digest-MD5 MMK all /DESCRIPTION=descrip.mms /MACRO=(PERL_CORE=1) Making Digest::SHA (all) Making all in cpan/Digest-SHA MMK all /DESCRIPTION=descrip.mms /MACRO=(PERL_CORE=1) Making Encode (all) Making all in cpan/Encode MMK all /DESCRIPTION=descrip.mms /MACRO=(PERL_CORE=1) Set Default [.byte] MMK/DESCRIPTION=DESCRIP.MMS/MACRO=(PERL_CORE=1) /Descrip= Descrip.MMS all %DCL-W-IVVERB, unrecognized command verb - check validity and spelling \MMK\ %MMK-F-ERRUPD, error status %X00038090 occurred when updating target SUBDIRS %MMK-F-ERRUPD, error status %X00038090 occurred when updating target SUBDIRS Unsuccessful make(cpan/Encode): code=1024 at make_ext.pl line 466. %NONAME-F-NOMSG, Message number 0C14803C %MMK-F-ERRUPD, error status %X0C14803C occurred when updating target DYNEXT This seems to have a lot to do with Encode having subdirectories that also contain FMakefile.PLs. In that, if I try to build SDBM_File: $ mcr []miniperl.exe -Ilib make_ext.pl MAKE=mmk SDBM_File Making SDBM_File (all) Running Makefile.PL in ext/SDBM_File ptac$dka0:[nclark.i.perl5160-rc2-mmk]miniperl.exe;1 -I../../lib Makefile.PL INST_LIB=[--.lib] INST_ARCHLIB=[--.lib] PERL_CORE=1 Writing Descrip.MMS for sdbm Writing Descrip.MMS for SDBM_File Making all in ext/SDBM_File mmk all /DESCRIPTION=descrip.mms /MACRO=(PERL_CORE=1) cp sdbm_file.pm [--.lib]sdbm_file.pm set def [.sdbm] MMK all %DCL-W-IVVERB, unrecognized command verb - check validity and spelling \MMK\ %MMK-F-ERRUPD, error status %X00038090 occurred when updating target [.SDBM]LIBS DBM.OLB %MMK-F-ERRUPD, error status %X00038090 occurred when updating target [.SDBM]LIBS DBM.OLB Unsuccessful make(ext/SDBM_File): code=1024 at make_ext.pl line 466. %NONAME-F-NOMSG, Message number 0C14803C Same failure. The logical mmk is getting forgotten by the time the outer Descrip.MMS is attempting to recurse to the inner Descrip.MMS So, I'm a bit stuck again. When I last build on VMS (back on Testdrive. I liked Testdrive) IIRC it worked fairly smoothly. Or at least, I got it to a point of reliably working. Maybe I forgot the speed bumps on the way. Nicholas Clark PS The above already proves one simplification I can make mcr []miniperl.exe -Ilib make_ext.pl works No need for -I[.dist.Cwd] -I[.dist.Cwd.lib] too. This is why I'm keen to get myself building VMS longer term. Shorter term, it would be nice to verify the perl-5.16.0 release candidate: http://www.cpan.org/src/5.0/perl-5.16.0-RC2.tar.gz
HP hobbyist license
I would find it really useful to have ssh access to a VMS system for testing perl. Specifically, I'm keen to be able to be able to test tweaks the build system on all of *nix, VMS and Windows so that I don't break anything. *nix isn't a problem as I have access to pretty much everything interesting (except Solaris on Sparc, and arguably Tru64, but they generally don't cause build problems). Win32 is already covered by smoke-me smokers. This leaves VMS. It seems that one can get free ssh accounts on for VMS on the Deathrow cluster - see http://gein.vistech.net/ However, they state that one can only use it to do things acceptable under the Hobbyist License, because that's the terms of their licence from DEC, er Compaq, er HP to run VMS. It's unclear to me whether what I'm doing would be hobbyist, given that I'm being paid. This distinction *is* relevant, because I know that being paid disqualifies one from getting free licences to use Intel's icc, even when one is being paid to work on Open Source. So I'd like to check. But, I can't find the terms of the Hobbyist License *anywhere*. Does anyone have or can point me to a copy that I can read? Nicholas Clark
Re: what was VMS do here? (was [perl #79960] Setting $/ to read fixed records can corrupt valid UTF-8 input)
On Thu, Mar 01, 2012 at 05:17:27PM -0600, Craig A. Berry wrote:
On Mar 1, 2012, at 12:30 PM, Nicholas Clark wrote:
On Thu, Mar 01, 2012 at 10:13:15AM -0800, Karl Williamson via RT wrote:
I can't find my proposal in the record of this ticket, nor anyone
responding to it. The documentation says that $/ gives the *maximum*
record size. So why not return as many whole characters as will fit in
$/ bytes?
I think that would require making :utf8 into its own layer with its own
buffer, which has been discussed over in [perl #100058].
Specifically, the code is emulated on everything else, but intended to
do something real and useful on VMS:
#ifdef VMS
/* VMS wants read instead of fread, because fread doesn't respect */
/* RMS record boundaries. This is not necessarily a good thing to be */
/* doing, but we've got no other real choice - except avoid stdio
as implementation - perhaps write a :vms layer ?
*/
fd = PerlIO_fileno(fp);
if (fd != -1) {
bytesread = PerlLIO_read(fd, buffer, recsize);
}
else /* in-memory file from PerlIO::Scalar */
#endif
I don't think this code is as meaningful as it used to be since unix I/O is
the bottom layer for PerlIO now. Which means that PerlLIO_read and
PerlIO_read (differing only by the L) are really the same thing, i.e.,
both boil down to read(). I guess we can't simplify this code until and
unless using stdio as the bottom layer is truly deprecated and expunged.
I don't think you're correct on that one. read() is not stdio. It's (at least
on Unix) a syscall. fread() is stdio, and loops on read() until it gets enough
octets. So the code for VMS (if I'm following it correctly) is still grabbing
a single record.
On Fri, Mar 02, 2012 at 08:11:10AM -0600, Craig A. Berry wrote:
On Mar 2, 2012, at 3:07 AM, Eric Brine wrote:
On Thu, Mar 1, 2012 at 6:17 PM, Craig A. Berry craigbe...@mac.com wrote:
What happens on Unix when you have a pipe buffer that is 8192 bytes and you
set $/ to 8193 and read a record containing UTF-8 data through the pipe?
You mean set $/ to \8193
Perl requests 8K (formerly 4K) chunks until it has received enough. It
requests 8K even if it only needs 1 byte.
I think you're thinking of the PerlIO buffer that I increased from 4K to the
larger of 8K and BUFSIZ in 5.14, and which only applies to the perlio layer.
But S_sv_gets_read_record calls PerlIO_read, which just retrieves the base
layer (formerly stdio, currently unix) and calls its Read method, which is
just read(). So there is no buffering under Perl's control.
I was thinking of a situation where something external to Perl limits how
much data you can get in one read and thus gives you less than the full
amount requested by $/. I'm pretty sure you'll get mangled UTF-8 if you
happen to be mid-character when you hit the end of the device buffer. To
test this, you'd need to know something about the internals of your system's
pipe implementation (or other device with a fixed buffer).
I don't think that discussing this in terms of what non-VMS does with $/ set
to a reference to an integer is necessarily that useful. I think it's really
only been added as this feature can't be VMS only (all added in commit
http://perl5.git.perl.org/perl.git/commitdiff/5b2b9c687790241e85aa7b76
)
In that, the whole bug report is about what *should* this do? because what
it currently does is badly broken.
The reason I'm specifically asking what does a VMS programmer *want*? is
because the fixed size records feature was put in for VMS, with non-VMS an
afterthought. So
1) is there a sane VMS native interpretation of UTF-8 coming from a fixed
record file ?
and only when that's answered is there
2) what do we fake on other platforms?
[and I think it's also premature to consider whether this needs :utf8 as a
real layer to implement. I'd like to get a feeling for what the Perl space
behaviour, if any, should be]
The possibly useful analogy is what happens with a :utf8 layer on sysread?
which is, well, summed up with:
goto more_bytes;
ie - it's actually a different behaviour. It makes multiple syscalls. Blech.
[and, thinking about it now, about 14 years later, possibly that non-VMS
code in sv_gets() should have been using read(), not fread(), so that it
would be useful on a datagram socket. But that's a bit late to fix]
Nicholas Clark
what was VMS do here? (was [perl #79960] Setting $/ to read fixed records can corrupt valid UTF-8 input)
On Thu, Mar 01, 2012 at 10:13:15AM -0800, Karl Williamson via RT wrote:
I can't find my proposal in the record of this ticket, nor anyone
responding to it. The documentation says that $/ gives the *maximum*
record size. So why not return as many whole characters as will fit in
$/ bytes?
Specifically, the code is emulated on everything else, but intended to
do something real and useful on VMS:
#ifdef VMS
/* VMS wants read instead of fread, because fread doesn't respect */
/* RMS record boundaries. This is not necessarily a good thing to be */
/* doing, but we've got no other real choice - except avoid stdio
as implementation - perhaps write a :vms layer ?
*/
fd = PerlIO_fileno(fp);
if (fd != -1) {
bytesread = PerlLIO_read(fd, buffer, recsize);
}
else /* in-memory file from PerlIO::Scalar */
#endif
perlvar.pod says:
On VMS, record reads are done with the equivalent of Csysread,
so it's best not to mix record and non-record reads on the same
file. (This is unlikely to be a problem, because any file you'd
want to read in record mode is probably unusable in line mode.)
Non-VMS systems do normal I/O, so it's safe to mix record and
non-record reads of a file.
I think we need to do something on this for 5.16. At the minimum, we
could emit a warning when a variable length encoded file is opened under
a fixed-length $/.
If even that isn't acceptable, we could add this to the
intend-to-deprecate section in perldelta.
So I'd like to know, if a programmer on VMS sets $/ to read records, but on
a file handle marked with :utf8, what do they want?
(and if the answer is their head examining, that's actually useful, as it
means that the least insane thing to implement is what we get)
Nicholas Clark
Re: RFC: UTF-8 perl (not Perl) source code
On Sun, Aug 07, 2011 at 01:44:23PM -0700, Father Chrysostomos wrote: If I change the quotes at the top of the *.c files in the perl source code to use UTF-8 instead of Latin-1, would anyone object? I have my text editor set to use UTF-8 by default, so it complains whenever I open those files. I have a vague memory (possibly wrong) that there was a VMS editor that choked (in some fashion) on UTF-8. [And if so, I guess because it assumes that source code is ISO-8859-1, and no C1 control characters] Nicholas Clark
ExtUtils::Miniperl (was Re: [perl.git] branch blead, updated. v5.13.7-168-gfbcaf61)
On Sun, Nov 28, 2010 at 06:34:14PM +0100, Nicholas Clark wrote: In perl.git, the branch blead has been updated http://perl5.git.perl.org/perl.git/commitdiff/fbcaf61123069fe46010699dd41ca5f60f448361?hp=603928ea21886dfb891e73164afc6b81c2793547 - Log - commit fbcaf61123069fe46010699dd41ca5f60f448361 Author: Nicholas Clark n...@ccl4.org Date: Sun Nov 28 17:15:58 2010 + Generate perlmain.c using ExtUtils::Miniperl, instead of writemain.SH. This allows writemain.SH to be removed. This also has the side effect of testing that ExtUtils::Miniperl actually works. :-) --- Summary of changes: MANIFEST |1 - Makefile.SH |8 ++-- Porting/exec-bit.txt |1 - pod/perlhack.pod |2 +- diff --git a/Makefile.SH b/Makefile.SH index 557f4f8..5315793 100755 --- a/Makefile.SH +++ b/Makefile.SH The important bit: -perlmain.c: miniperlmain.c config.sh $(FIRSTMAKEFILE) - sh writemain $(DYNALOADER) $(static_ext) perlmain.c +perlmain.c: $(MINIPERL_EXE) lib/ExtUtils/Miniperl.pm + $(MINIPERL) -Ilib -MExtUtils::Miniperl -e 'writemain(@ARGV)' DynaLoader $(static_ext) perlmain.c perlmain$(OBJ_EXT): perlmain.c $(CCCMD) $(PLDLFLAGS) $*.c Previously *nix was using a shell script writemain to generate perlmain.c from miniperlmain.c and the list of extensions. However, that functionality is duplicated in lib/ExtUtils/Miniperl.pm, generated by minimod.pl vms/writemain.pl also duplicates this functionality. The comment in it about create a linker options file seems to be spurious - as best I can tell it never did. (The comment was added in 5.001, but not the functionality) Can vms/writemain.pl go the way of writemain.SH, and be replaced with a call to ExtUtils::Miniperl ? (This would mean that VMS is using more of the same code as everyone else, which makes maintenance easier) Nicholas Clark
Re: Requst for VMS testing help
On Thu, Oct 07, 2010 at 02:01:13PM -0500, Craig A. Berry wrote:
I corrected this with:
commit 9ed9b795caa408a925999e1d90f9932e35b3ab10
Author: Craig A. Berry craigbe...@mac.com
Date: Wed Oct 6 19:19:33 2010 -0500
No distinction between .PL and .pl if case is not preserved.
Follow-up to 13b5e8d8173af2197798ae78b4520ece8cb1151c.
On VMS, the CRTL downcases filenames by default, so pod2foo.PL
comes through as pod2foo.pl. We need to match that so we paste
on the right extension for the generated command procedure.
Thanks.
It doesn't generate anything per se. It copies [.scripts]cpan as
distributed with the module to [.blib.script]cpan, then runs
Extutils::MakeMaker::MM_Unix-fixin on the result, which (incorrectly
on VMS) pastes a shebang line on the beginning, replacing any shebang
line already there. This based on building CPAN 1.94_61 just now.
Thanks for testing this.
In the core, utils/cpan.PL is simply a wrapper that sucks in cpan/CPAN/
scripts/cpan, puts $Config{startperl} at the beginning, and writes it
back out. There are a bunch of these that all have identical code
except for the name of the utility, so one obvious rationalization
would be to put that code in one script and have it work through a
list of utilities to be generated.
Agree. But
1: I remember having to alter those paths when modules moved from ext/ to
dist/ or cpan/, and it felt like makework, so I wanted to kill it properly
2: When building these modules from a CPAN download, ExtUtils::MakeMaker
already has to do all this extraction work , shebang rewriting, running
pl2bat, so surely it could do it when the modules are in the core
which, I felt, would remove even more code from core :-)
[Clearly this doesn't work if it hasn unresolved a bug in this area for VMS]
With the pod*PL extractors, by moving them all out of pod/ (including creating
ext/Pod-HTML for Pod::Html, which isn't dual-life), it let me remove several
rules from the various Makefiles. It might be that if we can move all of
utils/ into its modules, or into ext/utils, we can further simplify the top
level Makefiles, and let make_ext.pl and ExtUtils::MakeMaker do the work.
fixin() and the various *.PL scripts in utils have two different
understandings of what $Config{startperl} is and how to use it.
The .PL scripts have it right as far as VMS is concerned, so it looks
like we need to fix fixin().
This would be useful.
Side note: this extraction process in the core is a bit strange on
Unix. You end up with two shebang lines in the utilities distributed
with the core:
#!/usr/local/bin/perl
eval 'exec /usr/local/bin/perl -S $0 ${1+$@}'
if $running_under_some_shell;
#!/usr/local/bin/perl
. . .
I assume the first one takes precedence since the second one will
never be seen by the shell.
I assume this too.
Nicholas Clark
Re: Requst for VMS testing help
On Wed, Oct 06, 2010 at 07:36:56AM -0500, Craig A. Berry wrote: I grabbed a snapshot of this branch as of 467132B and it issues the following warnings during the build: Thanks. Making all in cpan/Pod-LaTeX MMK all /DESCRIPTION=descrip.mms /MACRO=(PERL_CORE=1) %MMK-W-CIRCDEP, circular dependency found for target POD2LATEX.PL %MMK-W-CIRCDEP, circular dependency found for target POD2LATEX.PL %MMK-W-CONNEXION, target POD2LATEX.PL found in circular dependency %MMK-W-CONNEXION, target POD2LATEX.PL found in circular dependency %MMK-W-CONNEXION, target [.BLIB.SCRIPT]POD2LATEX.PL found in circular dependency %MMK-W-CONNEXION, target [.BLIB.SCRIPT]POD2LATEX.PL found in circular dependency %MMK-W-CONNEXION, target PURE_ALL found in circular dependency %MMK-W-CONNEXION, target PURE_ALL found in circular dependency %MMK-W-CONNEXION, target ALL found in circular dependency %MMK-W-CONNEXION, target ALL found in circular dependency similar for Pod::Parser and Pod::HTML.The build proceeds so I'm not sure how much (if any) damage that's actually doing. Have to run so haven't looked into it yet. As you may have seen, I jumped the gun and have merged it into trunk. Partly because it passed tests on Win32, and partly because it unblocks some things seemingly unrelated that I want to fix (in Config, DynaLoader and XSLoader). Forewarned is forearmed - to my mind the next logical thing is to migrate building of CPAN-supplied scripts from utils/*.PL into their cpan/ (etc) builds. Currently I can see that (say) utils/cpan.PL extracts to cpan.com on VMS. Does MakeMaker do the same thing - does building from the CPAN source tarball generate [blib.scripts]cpan.com ? Or does it generate [blib.scripts]cpan ? Nicholas Clark
Re: Requst for VMS testing help
On Sun, Oct 03, 2010 at 09:51:25PM +0100, Nicholas Clark wrote: Thanks for digging into this, and supplying a corrected Makefile.PL I hope that this means that I can get something pretty much correct first time. Right. I'm hoping that the branch nicholas/migrate-Pod-converters will work on VMS. I decided to adapt make_ext.pl to do the dirty work for pod*.PL, rather than attempting to import and fix the various distributions' Makefile.PLs (That's http://perl5.git.perl.org/perl.git/snapshot/d3bc6aa63a6a5b0e.tar.gz for anyone who wants to play along, but doesn't have git installed) Nicholas Clark
Re: Requst for VMS testing help
On Sat, Oct 02, 2010 at 04:01:15PM -0500, Craig A. Berry wrote:
On Oct 1, 2010, at 10:37 AM, Nicholas Clark wrote:
I don't have access to a VMS system.
I'd like to rearrange some of the build system for core perl, but I
don't want
to break VMS in the process.
I'm guessing you want to take the pod2xxx.PL utility generators out of
pod/ and put them under cpan/ with the modules they belong to?
Yes. It will make
1: dual life module maintenance easier
2: the various top level makefiles simpler
3: allow an optimisation of XSLoader that would currently be rather tricky
Would someone be able to test install 3 Pod related modules on VMS:
None of them will even build on VMS, details below. In two cases they
seem unaware that the command-line utility being built will have
a .com extension, and in the other case (Pod::Parser) it knows it
wants podselect.com but doesn't know how to generate it.
Pod::Parser seemed closest to workable so I fiddled with it a bit. I
got it to build by this tweak to Makefile.PL:
$ gdiff -pu Makefile.PL;-0 Makefile.PL
--- Makefile.PL;-0 2009-02-05 09:26:23 -0600
+++ Makefile.PL 2010-10-02 15:31:32 -0500
@@ -38,13 +38,8 @@ $DISTMOD = 'Pod::Parser'; ## The tit
pod2usage
);
sub script($) { File::Spec-catfile ('scripts', @_) }
-my @EXE_FILES = ();
-if ( $^O eq 'VMS' ) {
- @EXE_FILES = map { script $_.com } @SCRIPTS;
-}
-else {
- @EXE_FILES = map { script $_ } @SCRIPTS;
-}
+my $script_ext = $^O eq 'VMS' ? '.com' : '';
+my @EXE_FILES = map { script $_$script_ext } @SCRIPTS;
## The test-script to execute regression tests (note that the
## 'xtra' directory might not exist for some installations)
@@ -75,7 +70,7 @@ WriteMakefile(
DISTNAME = $DISTNAME,
VERSION = '1.38',
INSTALLDIRS = ($] = 5.006 ? 'perl' : 'site'),
-PL_FILES = { map { (script($_.PL) = script($_)) }
@SCRIPTS },
+PL_FILES = { map { (script($_.PL) = script($_
$script_ext)) } @SCRIPTS },
EXE_FILES= [ @EXE_FILES ],
dist = { COMPRESS = 'gzip', SUFFIX = 'gz' },
clean= { FILES = @EXE_FILES },
[end]
Thanks. That's useful to know.
I think it might be simplest to teach make_ext.pl how to do the above.
but installing did not do anything with any of the generated .com
files. This could be MakeMaker's fault; I don't think I've ever built
a module that installed a standalone program outside the core, so that
capability may never have been tested (or may have gotten broken).
Aha. This isn't actually a problem, as core perl install is done by
installperl, using utils.lst to find things. I believe that all I need to do
is change the pathnames in there.
Specifically, I believe that the perl core currently installs to the
same
location as the perl binary, 6 perl scripts suitably wrapped for
VMS, as
pod2latex.com
pod2man.com
pod2text.com
pod2usage.com
podchecker.com
podselect.com
The current core build installs them to perl_root:[utils] .
Aha right.
Thanks for digging into this, and supplying a corrected Makefile.PL
I hope that this means that I can get something pretty much correct first time.
Nicholas Clark
Requst for VMS testing help
I don't have access to a VMS system. I'd like to rearrange some of the build system for core perl, but I don't want to break VMS in the process. Would someone be able to test install 3 Pod related modules on VMS: http://www.cpan.org/modules/by-authors/id/T/TJ/TJENNESS/Pod-LaTeX-0.58.tar.gz http://www.cpan.org/modules/by-authors/id/M/MA/MAREKR/Pod-Parser-1.38.tar.gz http://www.cpan.org/modules/by-authors/id/R/RR/RRA/podlators-2.3.1.tar.gz Specifically, I believe that the perl core currently installs to the same location as the perl binary, 6 perl scripts suitably wrapped for VMS, as pod2latex.com pod2man.com pod2text.com pod2usage.com podchecker.com podselect.com (pod2html.com comes from Pod::HTML, which is not a distribution on CPAN) Do the above 3 modules correctly install their respective scripts when built on VMS? From looking at Makefile.PL in each, I'm not convinced that all correctly get the install part right. Nicholas Clark
Re: VMS test status on blead@v5.11.2-182-gb417843
On Fri, Dec 18, 2009 at 10:35:13PM -0600, Craig A. Berry wrote:
dist/base/t/fields-5.6.0...FAILED--
no leader found
dist/base/t/fields-5.8.0...FAILED--
no leader found
These are failing because they are invoked via Cdo file which uses
Perl_pp_require, which on VMS cannot, by default, handle Unix-style
filenames with multiple dots. We used to be protected from this
because t/TEST used to convert to native syntax before running a test
file. The easiest solution would be to simply remove these files from
core since the tests in them are skipped on Perls later than 5.6 and
5.8, respectively.
Except that (I think) that the plan with distributions in dist/ is that
the perl 5 repository is the master copy for the CPAN distribution. So
removing them from blead would, um, mess that up.
Whilst they wouldn't be as pretty, is there a problem with renaming them
to dist/base/t/fields-5-6-0.t and fields-5-8-0.t ?
t/porting/diag.FAILED--
unexpected output at test 0
$ perl [.porting]diag.t
# blead/av.c
Can't open blead/av.c: no such file or directory at [.porting]diag.t
line 53, $diagfh line 5129.
1..0
The home-grown glob does not properly handle relative paths containing
C../. So, for example, glob('../*') from the t/ directory gives
blead/av.c rather than ../av.c as it should. Fixing that is some
moderate intensity C work in Perl_trim_unixpath in vms/vms.c. It's a
genuine bug but has nothing to do with what this test is testing.
Will it pass if it's changed like this?
diff --git a/t/porting/diag.t b/t/porting/diag.t
index 14c2f84..0241a12 100644
--- a/t/porting/diag.t
+++ b/t/porting/diag.t
@@ -10,8 +10,10 @@ $|=1;
my $make_exceptions_list = ($ARGV[0]||'') eq '--make-exceptions-list';
-open my $diagfh, , ../pod/perldiag.pod
- or die Can't open ../pod/perldiag.pod: $!;
+chdir '..' or die Can't chdir ..: $!;
+
+open my $diagfh, , pod/perldiag.pod
+ or die Can't open pod/perldiag.pod: $!;
my %entries;
while (DATA) {
@@ -32,12 +34,12 @@ while ($diagfh) {
}
}
-my @todo = ('..');
+my @todo = *;
while (@todo) {
my $todo = shift @todo;
- next if $todo ~~ ['../t', '../lib', '../ext', '../dist', '../cpan'];
+ next if $todo ~~ ['t', 'lib', 'ext', 'dist', 'cpan'];
# opmini.c is just a copy of op.c, so there's no need to check again.
- next if $todo eq '../opmini.c';
+ next if $todo eq 'opmini.c';
if (-d $todo) {
push @todo, glob $todo/*;
} elsif ($todo =~ m/\.[ch]$/) {
Nicholas Clark
extensions/known_extensions and insanity (was Re: VMS, configure.com and nonxs_ext)
On Tue, Sep 08, 2009 at 10:33:02AM +0100, Nicholas Clark wrote:
On Mon, Sep 07, 2009 at 05:15:51PM -0500, Craig A. Berry wrote:
There's also dynamic_ext, right? Shouldn't dynamic_ext plus
nonxs_extensions equal known_extensions?
Well, probably it should, but what actually happens is:
$ cat extensions.pl
#!perl -w
use strict;
use Config;
printf %-24s, 'extensions';
my @types = qw(static_ext dynamic_ext nonxs_ext known_extensions);
my %lookup;
my %short;
foreach (@types) {
my $short = $_;
$short =~ s/_.*//;
$short{$_} = $short;
printf %-8s, $short;
$lookup{$_} = {map {$_, 1} split/ /, $Config{$_}};
}
print \n\n;
foreach my $ext (sort split / /, $Config{extensions}) {
printf %-24s, $ext;
foreach (@types) {
printf %-8s, $lookup{$_}{$ext} ? $short{$_} : '';
}
print \n;
}
__END__
extensions is everything.
known_extensions = static_ext + dynamic_ext
extensions = nonxs_ext + known_extensions
which isn't logical, but I suspect is due to something historical.
Oops. I'm not correct.
I *think I am here:
0: DynaLoader doesn't count as an extension
1: known_extensions are all known XS extensions
2: static_ext, dynamic_ext and nonxs_ext are actually what they say they are,
assuming you were thinking about extensions we have configured here
3: extensions is the sum of the 3 immediately above
Hence if you have not built some XS extensions on your platform (which, I
think, is always true, as you can't build both VMS and Win32 extensions
anywhere), there will always be something in known_extensions that is not
in extensions.
Likewise, if you *have* build something nonxs (which you have do, as you can't
build DynaLoader without (at least) ExtUtils::ParseXS), there will always be
something in extensions that isn't in known_extensions.
Good, eh?
As an encore, the Unix Configure script teases you with -Dnoextensions
to disable extensions, but only actually honours it for XS extensions.
Right know it assumes that all nonxs extensions will work everywhere.
Nicholas Clark
Re: extensions/known_extensions and insanity (was Re: VMS, configure.com and nonxs_ext)
On Sun, Sep 27, 2009 at 03:04:38PM -0500, Craig A. Berry wrote: On Sep 27, 2009, at 1:26 PM, Nicholas Clark wrote: I *think I am here: 0: DynaLoader doesn't count as an extension 1: known_extensions are all known XS extensions 2: static_ext, dynamic_ext and nonxs_ext are actually what they say they are, assuming you were thinking about extensions we have configured here 3: extensions is the sum of the 3 immediately above I think we are now accurately imitating this on VMS except that DynaLoader is not currently listed in extensions. No, that's quite correct: $ grep Dyna config.sh $ As an encore, the Unix Configure script teases you with -Dnoextensions to disable extensions, but only actually honours it for XS extensions. Right know it assumes that all nonxs extensions will work everywhere. Most likely that's because once upon a time, saying XS extension was redundant and saying non-XS extension was a non-sequitur. And while we might expect Camel 3 and Extending and Embedding Perl to be out-of- date when they exclusively use the word extension to talk about extending Perl with C code, the current discussions in perlxs and perlxstut do the same thing. perlfaq7 gets even more explicit and says, =head2 What's an extension? An extension is a way of calling compiled C code from Perl. Reading Lperlxstut is a good place to learn more about extensions. Thanks for that analysis. I wasn't aware of that. With that definition of what an extension is, choosing -Dnoextensions to skip just the XS modules makes perfect sense. So I think one of the places where we went wrong was in introducing nonxs_ext for pure-Perl modules that are not properly called extensions. Maybe it should have been built_modules or built_pm or similar, and extensions would have been modules (though further distinctions between built modules and included modules might be necessary). This may be of purely hysterical interest as changing %Config entries now would probably cause more trouble than it would avoid, but hopefully it helps explain why we have some of the oddities that we do. Yes, that's pretty much my view now. We can also add new ones, or a whole new scheme, but really we need ot think it through carefully, and assume we have exactly this chance to get it right. Forever. Or until the special biologist word catches up with us. Nicholas Clark
Re: VMS, configure.com and nonxs_ext
On Mon, Sep 07, 2009 at 05:15:51PM -0500, Craig A. Berry wrote:
On Sep 7, 2009, at 4:46 PM, Nicholas Clark wrote:
On Mon, Sep 07, 2009 at 08:55:29PM +0100, Nicholas Clark wrote:
This might be rather a big favour request.
This might be easier than I first thought
It occurred to me we ought to revisit this after getting vms/ext into
ext. I don't think it will be huge, but it does involve grokking some
DCL that has to work rather hard to do what it's doing. I'll take a
look.
Would it be possible to augment the configure.com code that finds
extensions
to correctly partition nonxs_extensions from known_extensions?
(being the rather bonkers way that Configure partitions XS and non-XS
extensions)
There's also dynamic_ext, right? Shouldn't dynamic_ext plus
nonxs_extensions equal known_extensions?
Well, probably it should, but what actually happens is:
$ cat extensions.pl
#!perl -w
use strict;
use Config;
printf %-24s, 'extensions';
my @types = qw(static_ext dynamic_ext nonxs_ext known_extensions);
my %lookup;
my %short;
foreach (@types) {
my $short = $_;
$short =~ s/_.*//;
$short{$_} = $short;
printf %-8s, $short;
$lookup{$_} = {map {$_, 1} split/ /, $Config{$_}};
}
print \n\n;
foreach my $ext (sort split / /, $Config{extensions}) {
printf %-24s, $ext;
foreach (@types) {
printf %-8s, $lookup{$_}{$ext} ? $short{$_} : '';
}
print \n;
}
__END__
$ ./perl -Ilib extensions.pl
extensions static dynamic nonxs known
Archive/Extract nonxs
Archive/Tar nonxs
Attribute/Handlers nonxs
B dynamic known
B/Debug nonxs
B/Deparse nonxs
B/Lint nonxs
CGI nonxs
CPANPLUSnonxs
CPANPLUS/Dist/Build nonxs
Compress/Raw/Bzip2 dynamic known
Compress/Raw/Zlib dynamic known
Cwd dynamic known
DB_File dynamic known
Data/Dumper dynamic known
Devel/DProf dynamic known
Devel/PPPortdynamic known
Devel/Peek dynamic known
Devel/SelfStubber nonxs
Digest nonxs
Digest/MD5 dynamic known
Digest/SHA dynamic known
Encode dynamic known
Errno nonxs
Fcntl dynamic known
File/Fetch nonxs
File/Glob dynamic known
FileCache nonxs
Filter/Simple nonxs
Filter/Util/Calldynamic known
Hash/Util dynamic known
Hash/Util/FieldHash dynamic known
I18N/LangTags nonxs
I18N/Langinfo dynamic known
IO dynamic known
IO/Compress dynamic known
IO/Zlib nonxs
IPC/Cmd nonxs
IPC/Open2 nonxs
IPC/Open3 nonxs
IPC/SysVdynamic known
List/Util dynamic known
Log/Message nonxs
Log/Message/Simple nonxs
MIME/Base64 dynamic known
Math/BigInt/FastCalcdynamic known
Module/CoreList nonxs
Module/Load nonxs
Module/Load/Conditional nonxs
Module/Loaded nonxs
Module/Pluggablenonxs
Net/Pingnonxs
Object/Accessor nonxs
Opcode dynamic known
POSIX dynamic known
Package/Constants nonxs
Params/Checknonxs
Parse/CPAN/Meta nonxs
PerlIO/encoding dynamic known
PerlIO/scalar dynamic known
PerlIO/via dynamic
Re: VMS, configure.com and nonxs_ext
On Mon, Sep 07, 2009 at 08:55:29PM +0100, Nicholas Clark wrote: (I'm not sure why the Configure shell code contains tests for .c too - historical reasons? No, recent reasons. Building Win32CORE on Cygwin: http://perl5.git.perl.org/perl.git/commit/fefb2940d28bc57fa38371e2 Nicholas Clark
VMS, configure.com and nonxs_ext
This might be rather a big favour request.
Would it be possible to augment the configure.com code that finds extensions
to correctly partition nonxs_extensions from known_extensions?
(being the rather bonkers way that Configure partitions XS and non-XS
extensions)
To properly split out dual life modules into ext, I think it's going to be
necessary to add a Makefile.SH/Makefile/makefile.mk/descrip_mms.template
rule to have mkppport run after the nonxs_ext are built, but in turn, it needs
to run before dynamic_ext are built, hence the need for a split.
I'm not sure how easy this is, because right now Configure does it this way:
$ls -1 $xxx $$.tmp;
if $contains \.xs$ $$.tmp /dev/null 21; then
known_extensions=$known_extensions $this_ext;
elif $contains \.c$ $$.tmp /dev/null 21; then
known_extensions=$known_extensions $this_ext;
elif $test $this_ext = IO/Compress; then
known_extensions=$known_extensions $this_ext;
elif $test -d $xxx; then
nonxs_extensions=$nonxs_extensions $this_ext;
fi;
$rm -f $$.tmp;
using file globbing in ext/, whereas configure.com does it by text processing
MANIFEST:
$ known_extensions =
$ xxx =
$ OPEN/READ CONFIG 'manifestfound'
$ext_loop:
$ READ/END_OF_FILE=end_ext/ERROR=end_ext CONFIG line
$ IF F$EXTRACT(0,4,line) .NES. ext/ .AND. -
F$EXTRACT(0,8,line) .NES. vms/ext/ THEN goto ext_loop
$ line = F$EDIT(line,COMPRESS)
$ line = F$ELEMENT(0, ,line)
$ IF F$EXTRACT(0,4,line) .EQS. ext/
$ THEN
$ xxx = F$ELEMENT(1,/,line)
$ IF F$SEARCH([-.ext]''xxx'.DIR;1) .EQS. THEN GOTO ext_loop
$ ENDIF
$ IF F$EXTRACT(0,8,line) .EQS. vms/ext/
$ THEN
$ xxx = F$ELEMENT(2,/,line)
$ IF F$SEARCH([-.vms.ext]''xxx'.DIR;1) .EQS. THEN GOTO ext_loop
$ xxx = VMS/ + xxx
$ ENDIF
$ IF xxx .EQS. DynaLoader THEN goto ext_loop ! omit
$!
$! (extspec = xxx) =~ tr!-!/!
$ extspec =
$ idx = 0
$ replace_dash_with_slash:
$ before = F$ELEMENT(idx, -, xxx)
$ IF before .EQS. - THEN goto end_replace_dash_with_slash
$ IF extspec .NES.
$ THEN
$ extspec = extspec + /
$ ENDIF
$ extspec = extspec + before
$ idx = idx + 1
$ goto replace_dash_with_slash
$
$ end_replace_dash_with_slash:
$
$ xxx = known_extensions
$ may_already_have_extension:
$ idx = F$LOCATE(extspec, xxx)
$ extlen = F$LENGTH(xxx)
$ IF idx .EQ. extlen THEN goto found_new_extension
$! But Flirble may just be part of Acme-Flirble
$ IF idx .GT. 0 .AND. F$EXTRACT(idx - 1, 1, xxx) .NES.
$ THEN
$ xxx = F$EXTRACT(idx + F$LENGTH(extspec) + 1, extlen, xxx)
$ GOTO may_already_have_extension
$ ENDIF
$! But Foo may just be part of Foo-Bar so check for equality.
$ xxx = F$EXTRACT(idx, extlen - idx, xxx)
$ IF F$ELEMENT(0, , xxx) .EQS. extspec
$ THEN
$ GOTO ext_loop
$ ELSE
$ xxx = F$EXTRACT(F$LENGTH(extspec) + 1, extlen, xxx)
GOTO may_already_have_extension
$ ENDIF
$!
$ found_new_extension:
$ known_extensions = known_extensions + ''extspec'
$ goto ext_loop
$end_ext:
$ close CONFIG
$ DELETE/SYMBOL xxx
$ DELETE/SYMBOL idx
$ DELETE/SYMBOL extspec
$ DELETE/SYMBOL extlen
$ known_extensions = F$EDIT(known_extensions,TRIM,COMPRESS)
If it were possible to make the above into a function, then partitioning
nonxs from XS would seem to be as simple as
Feed the function the equivalent of `grep \.xs MANIFEST` to find the XS
extensions
Feed the function MANIFEST to find all extensions
Iterate over the list of all extensions - everything that isn't an XS
extension, you put into nonxs_extensions
But I don't know if functions are possible. And I can't see an easy way to
fit any sort of does this contain the substring '.xs' logic cleanly into
the above code, without wholesale copy-paste of may_already_have_extension
into one that does lines containing '.xs', and one that does not.
(I'm not sure why the Configure shell code contains tests for .c too -
historical reasons?
Also, it looks like some code can go from the above, now that there are
no directories with XS code in vms/ext)
If VMS does partition into nonxs_extensions correctly, I think that this tweak
would be needed:
diff --git a/make_ext.pl b/make_ext.pl
index 507f047..cfc12c2 100644
--- a/make_ext.pl
+++ b/make_ext.pl
@@ -179,6 +179,7 @@ elsif ($is_VMS) {
$perl = $^X;
push @extspec, (split ' ', $Config{static_ext}) if $static;
push @extspec, (split ' ', $Config{dynamic_ext}) if $dynamic;
+push @extspec, (split ' ', $Config{nonxs_ext}) if $dynamic;
}
foreach my $spec (@extspec) {
Nicholas Clark
Re: VMS, configure.com and nonxs_ext
On Mon, Sep 07, 2009 at 08:55:29PM +0100, Nicholas Clark wrote: This might be rather a big favour request. This might be easier than I first thought Would it be possible to augment the configure.com code that finds extensions to correctly partition nonxs_extensions from known_extensions? (being the rather bonkers way that Configure partitions XS and non-XS extensions) To properly split out dual life modules into ext, I think it's going to be necessary to add a Makefile.SH/Makefile/makefile.mk/descrip_mms.template rule to have mkppport run after the nonxs_ext are built, but in turn, it needs to run before dynamic_ext are built, hence the need for a split. I'm not sure how easy this is, because right now Configure does it this way: using file globbing in ext/, whereas configure.com does it by text processing MANIFEST: If it were possible to make the above into a function, then partitioning nonxs from XS would seem to be as simple as Feed the function the equivalent of `grep \.xs MANIFEST` to find the XS extensions I think that every XS extension has exactly one file named *.xs in it. Try running perl -nlwe 'print $1 if m!^(ext/[^\/]+/\S+\.xs\b)!' MANIFEST exclude from the output ext/DynaLoader (which is already a special case in configure.com) and lines matching 'fallback/constants.xs' and one has the list of all XS extensions. I hope that this algorithm is easy to encode in DCL. Feed the function MANIFEST to find all extensions Iterate over the list of all extensions - everything that isn't an XS extension, you put into nonxs_extensions At which point the existing code in configure.com can be changed around $ may_already_have_extension: to exclude any new extensions that are already in the list of XS extension generated above, and tweak it to replace $ known_extensions = known_extensions + ''extspec' with $ nonxs_extensions = nonxs_extensions + ''extspec' Nicholas Clark
extensions in vms/ext
Would it be possible to move vms/ext/DCLsym to ext/VMS-DCLsym, and vms/ext/Stdio to ext/VMS-Stdio, with conditional (not) building analogous to how ext/Win32* are only built on Windows? I think that would make my plans for refactoring make_ext.pl simpler. (to allow moving dual-life modules modules involved with Makefile.PLs into ext too). Right now ext/$foo and vms/ext/$bar are at different depths. Nicholas Clark
Re: VMS and Unix pathnames
On Mon, Aug 24, 2009 at 09:48:17PM -0500, Craig A. Berry wrote: But the bottom line is, get the t/TEST change into blead -- it doesn't significantly change the number of minor mysteries that need investigating and fixing. Thanks for checking this. It's in blead as of 7ebf5c89e8918d77e1798303430ceccf, and I think that your smoker has already smoked it. Nicholas Clark
VMS and Unix pathnames
Currently the core uses File::Spec inside the test running script, t/TEST,
that VMS uses. If I understand perlvms.pod correctly, perl on VMS can
understand Unix-like pathnames directly.
I'd like to remove File::Spec from t/TEST, as it's something complex run too
early in testing. Would the appended change work on VMS? It assumes that
1: relative pathnames, Unix style, work
2: readdir returns '.', '..' and directories in Unix format
Is that assuming to much? Would a subdirectory foo actually be returned as
foo. or foo.DIR?
(I've also attached the entire file TEST, if anyone wants to try, and doesn't
have a patch tool on VMS. You can get a snapshot of blead from
http://perl5.git.perl.org/perl.git/snapshot/HEAD.tar.gz )
I'm not subscribed to the vmsperl list, so please Cc: me on responses.
Nicholas Clark
diff --git a/t/TEST b/t/TEST
index 2634485..511aac1 100755
--- a/t/TEST
+++ b/t/TEST
@@ -68,23 +68,30 @@ $ENV{EMXSHELL} = 'sh';# For OS/2
# Roll your own File::Find!
use TestInit;
-use File::Spec;
if ($show_elapsed_time) { require Time::HiRes }
-my $curdir = File::Spec-curdir;
-my $updir = File::Spec-updir;
+
+my %skip = (
+ '.' = 1,
+ '..' = 1,
+ 'CVS' = 1,
+ 'RCS' = 1,
+ 'SCCS' = 1,
+ '.svn' = 1,
+ );
sub _find_tests {
my($dir) = @_;
opendir DIR, $dir or die Trouble opening $dir: $!;
foreach my $f (sort { $a cmp $b } readdir DIR) {
- next if $f eq $curdir or $f eq $updir or
- $f =~ /^(?:CVS|RCS|SCCS|\.svn)$/;
+ next if $skip{$f};
- my $fullpath = File::Spec-catfile($dir, $f);
+ my $fullpath = $dir/$f;
- _find_tests($fullpath) if -d $fullpath;
- $fullpath = VMS::Filespec::unixify($fullpath) if $^O eq 'VMS';
- push @ARGV, $fullpath if $f =~ /\.t$/;
+ if (-d $fullpath) {
+ _find_tests($fullpath);
+ } elsif ($f =~ /\.t$/) {
+ push @ARGV, $fullpath;
+ }
}
}
@@ -113,7 +120,7 @@ unless (@ARGV) {
# Config.pm may be broken for make minitest. And this is only a refinement
# for skipping tests on non-default builds, so it is allowed to fail.
# What we want to to is make a list of extensions which we did not build.
-my $configsh = File::Spec-catfile($updir, config.sh);
+my $configsh = '../config.sh';
my %skip;
if (-f $configsh) {
my (%extensions, %known_extensions);
@@ -140,7 +147,7 @@ unless (@ARGV) {
warn No extensions line found in $configsh;
}
}
-my $mani = File::Spec-catfile($updir, MANIFEST);
+my $mani = '../MANIFEST';
if (open(MANI, $mani)) {
while (MANI) { # similar code in t/harness
if
(m!^(ext/(\S+)/+(?:[^/\s]+\.t|test\.pl)|lib/\S+?(?:\.t|test\.pl))\s!) {
@@ -156,7 +163,7 @@ unless (@ARGV) {
$flat_extension =~ s!-!/!g;
next if $skip{$flat_extension}; # Foo/Bar may live in
Foo-Bar
}
- my $path = File::Spec-catfile($updir, $t);
+ my $path = ../$t;
push @ARGV, $path;
$::path_to_name{$path} = $t;
}
@@ -221,8 +228,7 @@ EOT
foreach my $t (@tests) {
unless (exists $::path_to_name{$t}) {
- my $tname = File::Spec-catfile('t',$t);
- $tname = VMS::Filespec::unixify($tname) if $^O eq 'VMS';
+ my $tname = t/$t;
$::path_to_name{$t} = $tname;
}
}
Re: VMS and Unix pathnames
On Mon, Aug 24, 2009 at 08:40:44AM -0500, John E. Malmberg wrote:
Nicholas Clark wrote:
Currently the core uses File::Spec inside the test running script, t/TEST,
that VMS uses. If I understand perlvms.pod correctly, perl on VMS can
understand Unix-like pathnames directly.
I'd like to remove File::Spec from t/TEST, as it's something complex run
too
early in testing. Would the appended change work on VMS? It assumes that
As the current t/TEST is used now, I think it is passed the starting
file specification in VMS format. So on VMS you still need a
VMS::Filespec::unixify to convert the input path parameter(s) to the test.
If I understand vms/test.com enough:
$ If PERL_TEST_DRIVER .eqs. minitest
$ Then
$ MCR Sys$Disk:[]Perl'exe' TEST. -minitest base/*.t comp/*.t
cmd/*.t run/*.t io/*.t op/*.t uni/*.t
$ Else
$ MCR Sys$Disk:[]Perl'exe' -I[-.lib] 'PERL_TEST_DRIVER' ''p3' ''p4'
''p5' ''p6' ''p7'
$ EndIf
and vms/descrip_mms.template
test : all [.t.lib]vmsfspec.t [.t.lib]vms_dclsym.t [.t.lib]vms_stdio.t
unpack_files
@ PERL_TEST_DRIVER == TEST.
- @[.vms]test.com $(E) $(__DEBUG__)
@ $(MINIPERL) -e print Ran tests; [.t]rantests.
then under minitest, it's being passed Unix-style globs, and under test,
nothing. So it is already expecting Unix-style names.
1: relative pathnames, Unix style, work
Those mostly work. Testing would be needed to verify that these work
for the pathnames that show up for t/TEST.
OK
2: readdir returns '.', '..' and directories in Unix format
I think we would need to verify that also. I have been mostly focused
on making Perl work with Unix file specifications using the Extended
Character set.
In the default/traditional mode of Perl on VMS, it was deemed acceptable
for routines to return VMS format paths on output even when given Unix
format paths on input. With the new Unix compatible mode, that should
not happen.
Is that assuming to much? Would a subdirectory foo actually be returned
as
foo. or foo.DIR?
In the default/traditional mode of Perl on VMS, subdirectory foo will
be returned as foo.dir when readdir() or glob operation is given a
UNIX format path.
It is a bug that we can not remove because there may be existing perl
modules that depend on it being present.
That's OK. Nothing in MANIFEST is named .dir, so an unconditional s/\.dir$//i
will solve it
Also in the default/traditional mode of Perl on VMS, file specifications
are converted to lower case. The older file system on VMS only stores
file names in uppercase, and code in VMS.c would convert them to
lowercase for better Unix compatibility.
I think that this doesn't matter, as all this is doing is building pathnames
to open them for reading.
(I've also attached the entire file TEST, if anyone wants to try, and
doesn't
have a patch tool on VMS. You can get a snapshot of blead from
http://perl5.git.perl.org/perl.git/snapshot/HEAD.tar.gz )
No attachment showed up.
PEBKAC, I suspect.
I will try to do a build of blead sometime early this week to see how it
works on VMS/Alpha.
Thanks
I'm (still) not subscribed to the vmsperl list, so please Cc: me on responses.
Nicholas Clark
#!./perl
# This is written in a peculiar style, since we're trying to avoid
# most of the constructs we'll be testing for. (This comment is
# probably obsolete on the avoidance side, though still currrent
# on the peculiarity side.)
$| = 1;
# for testing TEST only
#BEGIN { require '../lib/strict.pm'; strict-import() };
#BEGIN { require '../lib/warnings.pm'; warnings-import() };
# Let tests know they're running in the perl core. Useful for modules
# which live dual lives on CPAN.
$ENV{PERL_CORE} = 1;
delete $ENV{PERL5LIB};
# remove empty elements due to insertion of empty symbols via ''p1' syntax
@ARGV = grep($_,@ARGV) if $^O eq 'VMS';
our $show_elapsed_time = $ENV{HARNESS_TIMER} || 0;
# Cheesy version of Getopt::Std. Maybe we should replace it with that.
{
my @argv = ();
foreach my $idx (0..$#ARGV) {
push( @argv, $ARGV[$idx] ), next unless $ARGV[$idx] =~ /^-(\S+)$/;
$::benchmark = 1 if $1 eq 'benchmark';
$::core= 1 if $1 eq 'core';
$::verbose = 1 if $1 eq 'v';
$::torture = 1 if $1 eq 'torture';
$::with_utf8 = 1 if $1 eq 'utf8';
$::with_utf16 = 1 if $1 eq 'utf16';
$::taintwarn = 1 if $1 eq 'taintwarn';
$ENV{PERL_CORE_MINITEST} = 1 if $1 eq 'minitest';
if ($1 =~ /^deparse(,.+)?$/) {
$::deparse = 1;
$::deparse_opts = $1;
}
}
@ARGV = @argv;
}
chdir 't' if -f 't/TEST';
die You need to run \make test\ first to set things up.\n
unless -e 'perl' or -e 'perl.exe' or -e 'perl.pm';
if ($ENV{PERL_3LOG}) { # Tru64 third(1) tool, see perlhack
unless (-x 'perl.third') {
unless (-x '../perl.third') {
die You need to run \make perl.third first.\n;
}
else
Re: smoking VMS (was Re: maint-5.10 status on VMS)
On Fri, Jul 24, 2009 at 06:38:58PM -0500, John E. Malmberg wrote: Craig A. Berry wrote: Oh, and you used the word automatically, which still needs some work. I'm currently running rsync on Mac OS X in order to get the .patch file so we know what we're smoking, then generating a zipball and moving it to ~/Sites, then kicking off a job on the VMS side that uses curl to pull it across and run the smoke test. When a tuit or two present themselves, there are lots of different approaches to coordinating and automating all of this. I can supply you with a GIT program that can clone a repository. I can not get the other functions working for a while due to limitations in the GNV ports of several utilities and some other problems. If you (or anyone else) wishes to pursue that, drop a mail on the vms-perl list and I will respond with the details. I do not know if the clone function can pull down a specific branch. It is also pretty slow. It takes at least 1/2 for the git clone to pull down Perl on my DS-10. blead, maint-5.10 and maint-5.8 (at least) are still available via rsync. Does that help? If anyone else on the VMSperl list has the time and enthusiasm to pursue this, and get a VMS machine smoking regularly, that would be a great benefit to us non-VMS users. Nicholas Clark
smoking VMS (was Re: maint-5.10 status on VMS)
On Fri, Jul 24, 2009 at 03:35:33PM -0500, Craig A. Berry wrote: I've finally got Test::Smoke mostly working on VMS except for my local mail configuration, thus the manual attachment here. It shows the Ooh. ooh. ooh. ooh. What will it take to get the mail bit sorted, so that it can run automatically? And run automatically on blead too? Nicholas Clark
Re: Data overrun in Perl_magic_get '?' (Was: Access violation in SV.C new_body_inline())
On Wed, May 20, 2009 at 07:23:32PM -0500, Craig A. Berry wrote:
On May 19, 2009, at 8:31 AM, Nicholas Clark wrote:
That code rings a bell. The only thing I can find that I did near it
was:
http://perl5.git.perl.org/perl.git/commit/35f998ddd1e1665f7d0899ae3e50f9262c59d848
However I had a suspicion that I also did something that restricted
the upgrade
to the minimal case.
Maybe you were thinking of this:
http://www.nntp.perl.org/group/perl.perl5.changes/2008/09/msg22279.html
Yes, it was exactly that one. Thanks.
If this is the cause, I'm not sure whether the correct fix is to make
mg_localize generally upgrade the new scalar to the type of the
existing
scalar, or special case it for $?.
Thanks for the analysis. I don't really know the implications of the
alternatives you propose. I assume a general change is more risky and
potentially adds unnecessary processing to hot code. To me the least
risky thing would be to add the following by analogy with what's
already going on in gv.c:
--- mg.c;-0 2009-04-27 02:42:10 -0500
+++ mg.c2009-05-20 19:11:11 -0500
@@ -974,6 +974,7 @@ Perl_magic_get(pTHX_ SV *sv, MAGIC *mg)
{
sv_setiv(sv, (IV)STATUS_CURRENT);
#ifdef COMPLEX_STATUS
+ SvUPGRADE(sv, SVt_PVLV);
LvTARGOFF(sv) = PL_statusvalue;
LvTARGLEN(sv) = PL_statusvalue_vms;
#endif
[end]
Does that make sense?
This does fix the memory error that started this thread. I'm now
starting a complete test run to make sure nothing else goes pear-shaped.
Presumably an upgrade check is also needed at any point that tries to read
the complex status, as right now it could be using LvTARGOFF() or LvTARGLEN()
on a localised $? that is only PVMG, not PVLV.
Nicholas Clark
Re: Data overrun in Perl_magic_get '?' (Was: Access violation in SV.C new_body_inline())
On Tue, May 19, 2009 at 08:18:17AM -0500, John E. Malmberg wrote:
Craig A. Berry wrote:
So you're saying that these lines in Perl_magic_get in mg.c:
case '?':
{
sv_setiv(sv, (IV)STATUS_CURRENT);
#ifdef COMPLEX_STATUS
LvTARGOFF(sv) = PL_statusvalue;
LvTARGLEN(sv) = PL_statusvalue_vms;
#endif
}
are where the damage occurs? So it looks like the SV in question does
not even have the relevant slots (xlv_targlen) we're trying to update
here.
Yes.
I wonder if it's because IPC::Cmd declares $? as local. Maybe we
are assuming $? is always lexical but it's not?
I do not know.
That code rings a bell. The only thing I can find that I did near it was:
http://perl5.git.perl.org/perl.git/commit/35f998ddd1e1665f7d0899ae3e50f9262c59d848
However I had a suspicion that I also did something that restricted the upgrade
to the minimal case.
I don't think that lexical has anything to do with it - I suspect that the
bug is because IPC::Cmd localises $?, and the new scalar is created like this:
STATIC SV *
S_save_scalar_at(pTHX_ SV **sptr, const U32 flags)
{
dVAR;
SV * const osv = *sptr;
register SV * const sv = *sptr = newSV(0);
PERL_ARGS_ASSERT_SAVE_SCALAR_AT;
if (SvTYPE(osv) = SVt_PVMG SvMAGIC(osv) SvTYPE(osv) != SVt_PVGV) {
if (SvGMAGICAL(osv)) {
const bool oldtainted = PL_tainted;
SvFLAGS(osv) |= (SvFLAGS(osv)
(SVp_IOK|SVp_NOK|SVp_POK)) PRIVSHIFT;
PL_tainted = oldtainted;
}
mg_localize(osv, sv, (flags SAVEf_SETMAGIC) != 0);
}
return sv;
}
where that call to mg_localize() will upgrade it to PVMG, but not PVLV.
If this is the cause, I'm not sure whether the correct fix is to make
mg_localize generally upgrade the new scalar to the type of the existing
scalar, or special case it for $?.
Nicholas Clark
Re: Access violation in SV.C new_body_inline()
On Mon, Apr 27, 2009 at 12:27:02AM -0500, John E. Malmberg wrote:
I just started looking into a failure of 19_CPANPLUS-Dist. I have not
determined what exactly is wrong, and am out of time for the moment.
I will try to get some more information later.
It is failing from an access violation in SV.C.
ok 57 -Perl version not high enough
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=002C, PC=000F9AB8, PS=001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
imagemoduleroutine line rel PC
abs PC
DBGPERLSHR SV Perl_sv_upgrade73671 1F58
000F9AB8
DBGPERLSHR SV Perl_sv_setsv_flags76204 AC88
001027E8
EAGLE search [-]sv.lis/window=10 73671
2 73667 /* We always allocated the full length item
with PURIFY.
To do this
2 73668we fake things so that arena is false for
all 16 type
s.. */
3 73669 if(new_type_details-arena) {
3 73670 /* This points to the start of the
allocated area.
*/
3 73671 new_body_inline(new_body, new_type);
#define new_body_inline(xpv, sv_type) \
STMT_START { \
void ** const r3wt = PL_body_roots[sv_type]; \
xpv = (PTR_TBL_ENT_t*) (*((void **)(r3wt)) \
? *((void **)(r3wt)) : more_bodies(sv_type)); \
*(r3wt) = *(void**)(xpv); \
} STMT_END
I'm curious what the value of sv_type is. It's the second (real) parameter:
void
Perl_sv_upgrade(pTHX_ register SV *const sv, svtype new_type)
Nicholas Clark
Re: moving perlvms.pod from vms/ to pod/
On Sun, Apr 19, 2009 at 04:00:39PM -0500, Craig A. Berry wrote: On Apr 19, 2009, at 5:03 AM, Nicholas Clark wrote: Is there any reason *not* to mv vms/perlvms.pod pod/perlvms.pod ? It's already installed on every platform, as every platform's makefile(s) has special-case logic to copy it to pod/perlvms.pod as part of the build. So why not just move it, and simplify a lot of things? Makes sense to me. I'm sure it's been where it is since before other platforms knew it existed. Done with dd0cfdaa8f18412a5bea90a5dd33b46569dea1c5 Nicholas Clark
moving perlvms.pod from vms/ to pod/
Is there any reason *not* to mv vms/perlvms.pod pod/perlvms.pod ? It's already installed on every platform, as every platform's makefile(s) has special-case logic to copy it to pod/perlvms.pod as part of the build. So why not just move it, and simplify a lot of things? Nicholas Clark
Re: Time64 needs to call VMS.C gmtime() and localtime() always.
On Sat, Feb 21, 2009 at 04:00:28PM -0600, Craig A. Berry wrote: On Feb 19, 2009, at 8:55 AM, John Malmberg wrote: Malmberg wrote: Thomas Pfau wrote: Current definition from Compaq C V6.4-005 on OpenVMS VAX V7.3: typedef unsigned long int __time_t; So VMS Perl should be good to 2106 if just use the wrapper routines in VMS.C. That's better than failing in 2038, but if you were doing calculations for a 99-year lease you'd already be in trouble today. The time64 code takes things to a somewhat silly extreme by insisting on using a 64-bit integer for year as well as for time_t, thus moving the year limit beyond the 2 billion point. I have no idea what the practical application of that is, but there are advantages to extending the range by centuries rather than decades. Date Time calculations beyond the range of 2**53 seconds are meaningless. The actual useful range is way less than that: First, consider times backwards. Daylight saving time has been around for less than 0x8000 seconds before 1970, and the introduction was not clean cut. It seems that in the UK it was first introduced in 1916 as an aggregate 80 minute clock shift, done in 4 parts: http://www.webexhibits.org/daylightsaving/c.html yet the timezone database on this 64 bit machine doesn't seem to agree: $ ./perl -le 'print scalar localtime -169000' Mon Jun 12 20:33:20 1916 $ ./perl -le 'print scalar gmtime -169000' Mon Jun 12 19:33:20 1916 thinking that it's only an hour. Which, it seems, is because the timezone database is buggy: $ ./perl -le 'print scalar gmtime -181000' Fri Aug 23 22:13:20 1912 $ ./perl -le 'print scalar localtime -181000' Fri Aug 23 23:13:20 1912 Willet died in 1915, and his idea was not introduced in his lifetime. So historical timezone data is bogus, and we're already into garbage in, garbage out. Summertime data stops being of use. Go back a centaury further, and clocks weren't even synchronised within the countries we now treat as consistent timezones. Bristol time was 12 minutes behind London time, because noon was determined (locally) by the sun being overhead. [And no, I'm not sure whether that was at a particular time of year, or whether the clocks tracked the difference across the year between solar time and mean time: http://en.wikipedia.org/wiki/Equation_of_time ]. It was only the coming of the railways that standardised time across the country. So conversion of an epoch time to a time string with any resolution better than an hour stops being of use. Go back a centaury further: $ cal 9 1752 September 1752 Su Mo Tu We Th Fr Sa 1 2 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 So, the UK and its dominions adopted the Gregorian calendar, 200 years after the Roman Catholic world. So, I'd expect this to differ: $ LC_ALL=it_IT cal 9 1752 Settembre 1752 Do Lu Ma Me Gi Ve Sa 1 2 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Eh? What's up? What's up is that we don't even have data on when a given timezone swapped calendars. So we can't even usefully say what day of the week it is. Now, consider times forwards. $ TZ=GMT perl -le 'print scalar localtime 2**53' Mon Nov 12 07:36:32 285428751 $ TZ=US/Pacific perl -le 'print scalar localtime 2**53' Sun Nov 11 23:36:32 285428751 What's the world going to be like 285 million years from now? Well, it's not clear that it's going to be a Sunday night/Monday morning. The Earth's rotation is slowing. Wikipedia suggests that a day was 21.9±4 hours 620 million years ago*, and whilst the slowdown is not actually linear, a linear first stab would put the day as being 25 hours long. So any day information we calculate is useless. It's not even clear that it's going to be the right timezone any more. Iceland is currently spreading at (IIRC) 20mm/year, so if that continues for 285 million years, Iceland would be 5700km wider, and hence the Pacific coast of the US would be (roughly) 5700km further from Greenwich, about 3 timezones further. So localtime is completely bogus by then too. So, really, there's not very much that useful we can say about 2**53 seconds after 1970, apart from the fact that it's roughly 285422900AD, which we could do without needing a computer, let alone a timezone database. So doubles are perfectly good for this job. Nicholas Clark * http://en.wikipedia.org/wiki/Tidal_acceleration
Re: [patch@35050] replace pathify_dirspec in VMS with new version
On Sun, Dec 07, 2008 at 08:46:52AM -0600, John E. Malmberg wrote: An additional note, this patch may cause some tests in vmsfspec.t to fail. That is because the old behavior of pathfiy_dirspec() was inconsistent with vmsify(). On Sun, Dec 07, 2008 at 10:15:39AM -0600, John E. Malmberg wrote: This is all needed for me to proceed with the testing of VMS perl in a UNIX compatible mode. Currently most of the tests are passing. My view (and on matters VMS specific I'm going to defer to Craig, if he differs) is that if a needed change temporarily makes a known subset of tests fail, then it should include a patch to make exactly those tests TODO tests. Else, whoever wants to apply it, or look at the code afterwards, has no idea whether the tests they see failing are expected or unexpected. If they don't know that tests are expected to fail, they waste time reporting things that are actually known to be that way (temporarily) And if they do know that tests are expected to fail, then they don't report failures even if they are in unrelated areas. Hence why I'd much prefer the list of these are expected to fail, and that list to be supplied in code form. Nicholas Clark
Re: ANNOUNCE ExtUtils::MakeMaker 6.47_02
On Thu, Oct 16, 2008 at 04:18:45PM -0700, Michael G Schwern wrote: http://schwern.org/src/ExtUtils-MakeMaker-6.47_02.tar.gz Cutting a new release to fix some VMS issues on the new MIN_PERL_VERSION tests. In blead with change 34498. I noticed that ExtUtils/MM_Darwin.pm doesn't have a $VERSION. Nicholas Clark
Re: PathTools CPAN vs. blead (was Re: [patch@32376] VMS symbolic links part 4 of 4 - Final part)
On Sat, Nov 24, 2007 at 09:28:12PM -0600, Ken Williams wrote: On Nov 24, 2007, at 6:04 PM, Craig A. Berry wrote: I'll let John check on whether his Cwd change look good, but I see two VMS -related patches to PathTools in blead that are not in your svn repository: http://public.activestate.com/cgi-bin/perlbrowse/p/31431 http://public.activestate.com/cgi-bin/perlbrowse/p/31432 Thanks, I've applied them now. Regarding the second patch, it seems like we should find a way to make the test actually happen on VMS; the point of the test is to make sure we don't muddle with %ENV, something it would seem like we should be doubly vigilant on VMS about. Is it permissible on VMS for us to at least check that the actual keys of %ENV haven't changed before after the call? I never saw an answer to this question. Did this issue get resolved? Nicholas Clark
Re: Perl @ http://www.ccl4.org/~nick/P/perl-33444.tar.bz2
On Wed, Mar 05, 2008 at 08:11:59PM -0600, Craig A. Berry wrote: At 11:52 PM + 3/5/08, Nicholas Clark wrote: I've made another 5.8.x snapshot. http://www.ccl4.org/~nick/P/perl-33444.tar.bz2 (or http://www.ccl4.org/~nick/P/perl-33444.tar.gz ) It's closing in on what 5.8.9 is going to be, give or take breakage, late interesting bug fixes, and resolution of some things that aren't quite there yet Aside from -Dodgy.pm on VOS, what is still broken that wasn't broken in 5.8.8? At 33430 (always just a bit behind you) on VMS I see: t/op/threadsFAILED--expected 10 tests, saw 9 ext/threads/shared/t/stress.FAILED at test 1 ext/threads/t/blocksFAILED--expected 5 tests, saw 4 lib/ExtUtils/t/cd...FAILED at test 1 lib/ExtUtils/t/eu_command...FAILED at test 21 lib/ExtUtils/t/xs...FAILED--non-zero wait status: 1024 Failed 6 tests out of 1080, 99.44% okay. Obviously that's a threaded build. The threads failures are access violations; I'll check whether 33436 does us any good there. Did these fail that way on 5.8.8? I'd be surprised if anything that changed recently changed threaded behaviour. For the MakeMaker failures, eu_command.t and xs.t behaved after upgrading to 6.43_01. cd.t I just patched last night: https://rt.cpan.org/Ticket/Display.html?id=33813 If there are no further integrations of MakeMaker in the cards (I think 6.44 is out), I can mark tests as TODO or otherwise patch the tests if you wish. I'm not sure what to do here. Is MakeMaker in blead passing everywhere? There are still patches outstanding in ExtUtils::Install, aren't there? Nicholas Clark
Perl @ http://www.ccl4.org/~nick/P/perl-33444.tar.bz2
I've made another 5.8.x snapshot. http://www.ccl4.org/~nick/P/perl-33444.tar.bz2 (or http://www.ccl4.org/~nick/P/perl-33444.tar.gz ) It's closing in on what 5.8.9 is going to be, give or take breakage, late interesting bug fixes, and resolution of some things that aren't quite there yet Aside from -Dodgy.pm on VOS, what is still broken that wasn't broken in 5.8.8? Nicholas Clark
Re: Perl @ 33218
On Tue, Feb 05, 2008 at 11:08:37PM +, var Arnfjr Bjarmason wrote: On 2/2/08, Nicholas Clark [EMAIL PROTECTED] wrote: What else did I forget? The unpack/potentially rx related segfault mauke reported a while back which I did some initial analysis of still hasn't been solved in 5.8.x or 5.10.x. It would be nice if yourself or someone with more optree It wasn't solved in 5.8.8 so it's not a regression. tuits would take a look at it. Maybe it's trivial to fix and if so it The optree is not my strong point at all. would be a shame if we shipped a perl with known segfaults, especially as those might always be potential security issues. $ perl -le 'split //, unpack((B)*, ab)' Segmentation fault Curiously, the (I believe) functionally equivalent non-grouping version is fine: $ perl -le 'split //, unpack(B*, ab)' $ Andreas, is your binary search able to work out when this problem appeared? Nicholas Clark
Re: Perl @ 33218
On Tue, Feb 05, 2008 at 11:28:02PM +, Nicholas Clark wrote: On Tue, Feb 05, 2008 at 11:08:37PM +, var Arnfjr Bjarmason wrote: The unpack/potentially rx related segfault mauke reported a while back which I did some initial analysis of still hasn't been solved in 5.8.x or 5.10.x. It would be nice if yourself or someone with more optree It wasn't solved in 5.8.8 so it's not a regression. tuits would take a look at it. Maybe it's trivial to fix and if so it The optree is not my strong point at all. would be a shame if we shipped a perl with known segfaults, especially as those might always be potential security issues. $ perl -le 'split //, unpack((B)*, ab)' Segmentation fault Curiously, the (I believe) functionally equivalent non-grouping version is fine: $ perl -le 'split //, unpack(B*, ab)' $ No, *this*, BB, is the functionally equivalent, I think. And as *it* works it means that it can't be the optree. So, single stepping in the debugger good: 4676Copy(LvTARGOFF(POPs), pm, 1, PMOP*); (gdb) 4680if (!pm || !s) (gdb) 4682rx = PM_GETRE(pm); (gdb) p pm $8 = (PMOP *) 0x8c25b0 vs bad: 4676Copy(LvTARGOFF(POPs), pm, 1, PMOP*); (gdb) 4680if (!pm || !s) (gdb) 4682rx = PM_GETRE(pm); (gdb) p pm $7 = (PMOP *) 0x8 so, it's stacks. $ ./perl -Ds -le 'split //, unpack(BB, ab)' EXECUTING... = = = = PVLV() = PVLV() PV(BB\0) = PVLV() PV(BB\0) PV(ab\0) = PVLV() PV(0\0) = PVLV() PV(0\0) IV(0) = IV(1) $ ./perl -Ds -le 'split //, unpack((B)*, ab)' EXECUTING... = = = = PVLV() = PVLV() PV((B)*\0) = PVLV() PV((B)*\0) PV(ab\0) = PVLV() PV(0\0) PV(0\0) = PVLV() PV(0\0) PV(0\0) IV(0) Segmentation fault anyone familiar enough with the code or stacks to know why it's leaving too much on the stack? And why it only happens with split? For example list assignment (and print, and foreach) are identical for BB and (B)* (and why the split // case puts IV(0) on the stack, whereas the others put a PV of 0) $ ./perl -Dts -le '@a = unpack(BB, ab)' EXECUTING... = (-e:0) enter = (-e:0) nextstate = (-e:1) pushmark = * (-e:1) const(PV(BB\0)) = * PV(BB\0) (-e:1) const(PV(ab\0)) = * PV(BB\0) PV(ab\0) (-e:1) unpack = * PV(0\0) PV(0\0) (-e:1) pushmark = * PV(0\0) PV(0\0) * (-e:1) gv(main::a) = * PV(0\0) PV(0\0) * GV() (-e:1) rv2av = * PV(0\0) PV(0\0) * AV() (-e:1) aassign = (-e:1) leave $ ./perl -Dts -le '@a = unpack((B)*, ab)' EXECUTING... = (-e:0) enter = (-e:0) nextstate = (-e:1) pushmark = * (-e:1) const(PV((B)*\0)) = * PV((B)*\0) (-e:1) const(PV(ab\0)) = * PV((B)*\0) PV(ab\0) (-e:1) unpack = * PV(0\0) PV(0\0) (-e:1) pushmark = * PV(0\0) PV(0\0) * (-e:1) gv(main::a) = * PV(0\0) PV(0\0) * GV() (-e:1) rv2av = * PV(0\0) PV(0\0) * AV() (-e:1) aassign = (-e:1) leave Nicholas Clark
Perl @ 33218
I've made another 5.8.x snapshot. http://www.ccl4.org/~nick/P/perl-33218.tar.bz2 (or http://www.ccl4.org/~nick/P/perl-33218.tar.gz ) It's roughly what 5.8.9 is going to be, give or take breakage, late interesting bug fixes, and resolution of some things that aren't quite there yet (eg SysV::IPC vs C++ compilers, core headers vs Irix C compilers, File::Spec vs MakeMaker on Win32, cflags.SH and -fstack-protector) I'm curious how it fares on VMS, and which changes I've not integrated that I should do to fix problems on VMS, Win32, or other platforms I don't understand that well. In particular 1: Craig Berry says that the VMS diffs between 5.8.8 and 5.10 are 8000 lines. People have been busy (particularly John E. Malmberg) That's going to be too big to merge. In particular it (and 5.10) contains symlink support for VMS. I doubt that that should go in. But in turn John E. Malmberg made several VMS changes to File::Find, which I think related to symlinks, but I'm not sure. They're not in. Does it break things if they go in? 2: For some reason ext/B/t/lint.t, lib/Math/Complex.t and lib/Math/Trig.t have just blown up with Borland on Win32, despite seemingly being stable in 5.11 for a while. I hope that this is easy to fix 3: Jerry Hedden spotted that a change merged causes a gcc warning on Cygwin. I've yet tracked down what other change is not merged that would silence this. (It seemed more important to get everything else done, as it wasn't a build failure) 4: There are patches to Cygwin's README that I've not merged. I don't know what is relevant, and what relates to things that aren't merged What else did I forget? It's still Saturday, and I claim that I'm in time for this week's summary :-) [And currently I have the last 65 changes in a row: http://public.activestate.com/cgi-bin/perlbrowse?top=show_recent=Show+Change+Log Is there anyone (else) out there? :-) ] Nicholas Clark
Re: Perl @ 33218
On Sun, Feb 03, 2008 at 12:27:56AM +, Andy Armstrong wrote: On 2 Feb 2008, at 23:35, Nicholas Clark wrote: I've made another 5.8.x snapshot. http://www.ccl4.org/~nick/P/perl-33218.tar.bz2 (or http://www.ccl4.org/~nick/P/perl-33218.tar.gz ) It's roughly what 5.8.9 is going to be, give or take breakage, late interesting bug fixes, and resolution of some things that aren't quite there yet (eg SysV::IPC vs C++ compilers, core headers vs Irix C compilers, File::Spec vs MakeMaker on Win32, cflags.SH and -fstack-protector) I'm getting: ext/B/t/lint# Failed at ../ext/B/t/ lint.t line 32 # got 'Implicit scalar context for array in shift at ../lib/B.pm line 124 # Implicit scalar context for array in shift at ../lib/B.pm line 80 # Implicit scalar context for array in shift at ../lib/B.pm line 279 # Implicit scalar context for array in shift at ../lib/B.pm line 271 # Implicit scalar context for array in shift at ../lib/B.pm line 272 # Use of $_ at ../lib/B.pm line 272 # Use of $_ at ../lib/B.pm line 273 # Implicit scalar context for array in shift at ../lib/B.pm line 284 # Implicit scalar context for array in shift at ../lib/B.pm line 294 # Use of $_ at ../lib/B.pm line 305 # Use of $_ at ../lib/B.pm line 306 # Use of $_ at ../lib/B.pm line 312 # Implicit scalar context for array in shift at ../lib/B.pm line 289 # Implicit scalar context for array in shift at ../lib/B.pm line 177 # Implicit scalar context for array in shift at ../lib/B.pm line 114 # ' # expected '' # Failed at ../ext/B/t/lint.t line 32 # got 'Implicit scalar context for array in shift at ../lib/B.pm line 124 # Implicit scalar context for array in shift at ../lib/B.pm line 80 # Implicit scalar context for array in shift at ../lib/B.pm line 279 # Implicit scalar context for array in shift at ../lib/B.pm line 271 # Implicit scalar context for array in shift at ../lib/B.pm line 272 # Use of $_ at ../lib/B.pm line 272 # Use of $_ at ../lib/B.pm line 273 # Implicit scalar context for array in shift at ../lib/B.pm line 284 # Implicit scalar context for array in shift at ../lib/B.pm line 294 # Use of $_ at ../lib/B.pm line 305 # Use of $_ at ../lib/B.pm line 306 # Use of $_ at ../lib/B.pm line 312 # Implicit scalar context for array in shift at ../lib/B.pm line 289 # Implicit scalar context for array in shift at ../lib/B.pm line 177 # Implicit scalar context for array in shift at ../lib/B.pm line 114 # ' # expected '' FAILED at test 15 Strange. It doesn't do that for me on FreeBSD on Linux. and ext/threads/t/free2.FAILED--expected 78 tests, saw 73 On Mac OS 10.5. Expected? Not expected. Blead doesn't do that? That looks like a SEGV or some fairly serious abort. But I can run it under valgrind here on Linux no problem. And FreeBSD is happy. And d'you want DTrace support? I have a patch that works against that snapshot if you do. I'm not sure. Presumably yes, if 5.10.1 has it too. But I assume that I can just integrate the changes from maint-5.10, if it gets it. Nicholas Clark
Re: Perl @ 33218
On Sat, Feb 02, 2008 at 06:32:50PM -0600, Craig A. Berry wrote: At 11:35 PM + 2/2/08, Nicholas Clark wrote: I'm curious how it fares on VMS, and which changes I've not integrated that I should do to fix problems on VMS, As of 33210 (I can't do builds as fast as you can integrate), with HP C V7.3-009 on OpenVMS Alpha V8.3 I get: I had two machines on the case at one point. :-) But that can get confusing. lib/ExtUtils/t/xs fails like so: $ perl [-.lib.extutils.t]xs.t 1..0 # Skip ExtUtils::CBuilder not installed or couldn't find a compiler %SYSTEM-F-ABORT, abort If we aren't going to have CBuilder in 5.8.x, maybe xs.t should not even be in the distribution, though it's curious that Cplan skip_all causes a failure exit condition. Yes, strange. On FreeBSD: $ PERL_CORE=1 ./perl lib/ExtUtils/t/xs.t ech1..0 # Skip ExtUtils::CBuilder not installed or couldn't find a compiler $ echo $? 0 What does the VMS equivalent of this 1 liner give? $ ./perl -Ilib -e 'use Test::More; plan skip_all = Testing' 1..0 # Skip Testing $ echo $? 0 I thought that it was being tested: lib/Test/Simple/t/plan_skip_all.t lib/Test/Simple/t/skipall.t eu_command.t passes when run outside of the test suite. The others need more investigation, but I think I'll synch up with latest first. John E. Malmberg made several VMS changes to File::Find, which I think related to symlinks, but I'm not sure. They're not in. Does it break things if they go in? Good question. I'll look them up and see what they are. Thanks. Nicholas Clark
Re: Perl @ 32984
On Thu, Jan 17, 2008 at 09:31:00AM -0600, Craig A. Berry wrote:
At 4:10 PM + 1/16/08, Nicholas Clark wrote:
I've made a 5.8.x snapshot.
http://www.ccl4.org/~nick/P/perl-32984.tar.bz2
(or http://www.ccl4.org/~nick/P/perl-32984.tar.gz )
I'm particularly curious how it fares on VMS,
@32985, here's what a default build gives me:
t/io/fs.FAILED at test 5
lib/ExtUtils/t/cd...FAILED at test 1
lib/ExtUtils/t/eu_command...FAILED at test 21
lib/Test/Harness/t/failure..FAILED--expected test 3, saw test
2
lib/Test/Harness/t/strap-analyzeFAILED at test 37
lib/Test/Harness/t/test-harness.FAILED at test 46
Failed 6 tests out of 1029, 99.42% okay.
If there are upgrades from CPAN in the pipeline for EU::MM and
Test::Harness, that will likely get us squared away with those. I'll
see what I can figure out with io/fs.t.
Yes, there were. Now should be identical to 5.10 (apart from a $VERSION tweak)
$ diff -u t/io/fs.t ../../perl/t/io/fs.t
--- t/io/fs.t Sat Nov 17 20:18:43 2007
+++ ../../perl/t/io/fs.tWed Sep 26 15:54:56 2007
@@ -58,6 +58,7 @@
}
elsif ($^O eq 'VMS') {
`if f\$search([.tmp]*.*) .nes. then delete/nolog/noconfirm
[.tmp]*.*.*`;
+`if f\$search(tmp.dir) .nes. then set file/prot=o:rwed tmp.dir;`;
`if f\$search(tmp.dir) .nes. then delete/nolog/noconfirm tmp.dir;`;
`create/directory [.tmp]`;
}
That line is part of this, which I guess at the time I decided wasn't a
good thing to integrate to maint. (Right or wrong?)
Change 27239 by [EMAIL PROTECTED] on 2006/02/20 09:31:03
Subject: [EMAIL PROTECTED] vms glob/readdir/chdir EFS/long filename
support
From: John E. Malmberg [EMAIL PROTECTED]
Date: Feb 20, 2006 3:43 AM
Message-ID: [EMAIL PROTECTED]
Affected files ...
... //depot/perl/doio.c#322 edit
... //depot/perl/t/io/fs.t#59 edit
... //depot/perl/vms/vms.c#162 edit
Is the change to t/io/fs.t unrelated to the rest?
http://public.activestate.com/cgi-bin/perlbrowse/p/27239
Nicholas Clark
Perl @ 32984
I've made a 5.8.x snapshot. http://www.ccl4.org/~nick/P/perl-32984.tar.bz2 (or http://www.ccl4.org/~nick/P/perl-32984.tar.gz ) I'm particularly curious how it fares on VMS, and which changes I've not integrated that I should do to fix problems on VMS, Win32, or other platforms I don't understand that well. (I know that Win32 isn't on fire because of Steve Hay's regular-as-clockwork smoke tests) I'd like to get to 5.8.9 soon. Preferably before a: The German Perl Workshop b: 5.10.1 c: Christmas although I don't actually control the timing of any of those events. Nicholas Clark
Re: patch@23206 Always expose vms_realpath and vms_case_tolerant routines.
On Fri, Nov 16, 2007 at 05:51:41PM -0600, John E. Malmberg wrote: What I do not know how to do is have Cwd.pm detect if the new routines are present. XS subroutines will appear defined once they exist: $ perl -lwe 'print defined Socket::inet_ntoa' $ perl -MSocket -lwe 'print defined Socket::inet_ntoa' 1 There's already quite a lot of logic with defined on subroutines in Cwd.pm Nicholas Clark
Re: [patch@31988] Revised Module::Build fixes for VMS.
On Sat, Sep 29, 2007 at 10:44:34AM -0500, Ken Williams wrote: On Sep 28, 2007, at 11:42 PM, Craig A. Berry wrote: It applied cleanly against blead, where I've checked it in as 31995. I wonder if we've had some drift between blead and the independent version. Indeed we have, here are the VMS-related outstanding differences. Could someone verify that the blead version is correct, and let me know who to assign credit to in the Changes file? I can't answer on the first, but on the second I used Show Annotated File on http://public.activestate.com/cgi-bin/perlbrowse to work out that the first two chunks are this change: http://public.activestate.com/cgi-bin/perlbrowse/p/31156 and the rest seems to be this change: http://public.activestate.com/cgi-bin/perlbrowse/p/31619 Nicholas Clark
Re: Module::Load::Conditional 0.18 wannabe
On Mon, Sep 10, 2007 at 08:53:56PM -0500, John E. Malmberg wrote: It is still possible to get modules loaded multiple times, as the only way to prevent that would be if %INC tracked devices and inodes instead of pathnames. That is a generic Perl issue though. One can't rely on having inodes. I think it will need to remain documented behaviour. Nicholas Clark
Re: UTF8 help/review of possible implementation on VMS
On Tue, Apr 11, 2006 at 11:30:41AM -0400, John E. Malmberg wrote:
What I would like to know is if I have figured out this patch fragment
correct for getting the UTF8 attribute passed back and forth.
Specifically, when I am returning a UTF8 encoded string back to Perl, do
I need to run it through sv_utf8_upgrade(), or is there a better method?
Sorry, missed this question, which I knew the answer to.
+ if (rslt != NULL) [
+sv_usepvn(ST(0),rslt,strlen(rslt));
+if (fs_utf8) {
+ sv_utf8_upgrade(ST(0));
+}
+ }
No, sv_utf8_upgrade is for converting an SV holding a sequence of bytes that
are ISO-8859-1 characters into an SV holding a (longer) sequence of bytes
that are those same characters encoded in UTF-8.
What I think you need here is
ST(0) = sv_newmortal();
- if (rslt != NULL) sv_usepvn(ST(0),rslt,strlen(rslt));
+ if (rslt != NULL) [
+sv_usepvn(ST(0),rslt,strlen(rslt));
+if (fs_utf8) {
+ SvUTF8_on(ST(0));
+}
+ }
because you need to signal to the internals that the sequence of bytes in
the SV is in UTF-8.
(I'm assuming that the sequence of bytes in rslt was in ISO-8859-1 if fs_utf8
was false, and UTF-8 if fs_utf8 was true. If not, I misunderstood something)
If you're re-using an existing SV (rather than the new one created here by
sv_newmortal()), I'd add an else block with SvUTF8_off(...), as there have
been bugs in the core caused by scalars getting SvUTF8(...) turned on, but
then never turned on, so it leaks through on scalar re-use.
Nicholas Clark
Re: Change 27768: First stab at using the pad to store the serialised hints data.
On Tue, Apr 11, 2006 at 10:34:13PM -0400, John E. Malmberg wrote: This breaks the VMS build because the transfer vectors are still being generated from somewhere. %LINK-W-NUDFSYMS, 2 undefined symbols: %LINK-I-UDFSYM, PERL_REFCOUNTED_HE_COPY %LINK-I-UDFSYM, PERL_REFCOUNTED_HE_DUP %LINK-W-USEUNDEFSYMV, undefined symbol PERL_REFCOUNTED_HE_COPY referenced in symbol vector option %LINK-W-USEUNDEFSYMV, undefined symbol PERL_REFCOUNTED_HE_DUP referenced in symbol vector option Oops. That's because I didn't remove them from embed.fnc. They should be gone with change 27775 Nicholas Clark
Re: bug@27746 sv.c will not compile on VMS.
On Sun, Apr 09, 2006 at 11:43:31AM -0400, John E. Malmberg wrote: Sorry for a quick note, but this is all I have time for at the moment. Yes, but it's completely sufficient to identify and describe the problem, so I see no need to apologise. SV compile fails at this point: TOPPTR(nss,ix) = sv_dup_inc(av, param); .^ %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value av is struct av, which is not compatible with const struct sv. at line number 10399 in file PERL_BUILD_ROOT:[00]sv.c;1 My mistake. Fixed in change 27752 Nicholas Clark
Re: RFC: UTF8 file specifications on VMS
On Thu, Apr 06, 2006 at 10:42:13PM -0400, John E. Malmberg wrote: My plan would be to first modify the routines to accept the needed parameters, create the new macros and make sure that everything still works. Then to start making the routines actually use the parameters. The usual way we've doing this in the past it to rename the routine when changing it to take extra parameters, then add a wrapper version with the original name that simply calls the new name with new parameters suitably zeroed. This approach means that existing code that expects the old name will still link. Of course, it has the downside of more functions. Nicholas Clark
Re: Threads and safesysfree?
On Tue, Mar 07, 2006 at 10:50:45PM -0500, John E. Malmberg wrote: Since normally the header-interpreter value is not poisoned when memory is free, if something else mallocs the memory right after a free operation, and then incorrectly calls Perl_safesysfree() to free it, this will not be detected by Perl_safesysfree. I just hit this condition because of a bug I introduced into my test vms/vms.c, where Perl_safesysfree(free) successfully freed memory that was allocated by malloc(). I would recommend that the header-interpreter value always be poisoned so that this condition can be better detected. I didn't write that part of the that code, so I'm not confident what other side effects this change would have, and whether it will conceal alternate forms of bugs that as-is it reveals. Nicholas Clark
Re: Threads and safesysfree?
On Thu, Mar 09, 2006 at 10:01:52AM +, Dave Mitchell wrote: On Tue, Mar 07, 2006 at 10:50:45PM -0500, John E. Malmberg wrote: In util.c the routines Perl_safesysmalloc and friends are updating a linked list. There does not seem to be any protection from a different thread also updating the same linked list at the same time, especially on a multi-processor system. They are updating a per-thread linked list, so I think it's thread-safe. Which is what I was thinking but I hadn't replied yet. The other bit I was thinking was unless things have got very buggy but I'm not sure how many defences one puts in against the sky falling. Nicholas Clark
Re: Change 27228: To make arithmetic on tainted dualvars work properly requires that
On Sun, Feb 19, 2006 at 07:49:06PM -0500, John E. Malmberg wrote: Nicholas Clark wrote: Change 27228 by [EMAIL PROTECTED] on 2006/02/19 18:57:35 To make arithmetic on tainted dualvars work properly requires that sv_2nv uses SvIVX in preference to SvPVX, if SVp_IOK is true. Is this test supposed to work on VMS? Yes. not ok 246 - Arithmetic on tainted dualvars works # Failed at [-.t.op]taint.t line 1159 # got '5' # expected '8' I have no idea why it's not. Devel::Peek::Dump or Perl_sv_dump on the arguments might reveal something that differs from Unix and Win32. Nicholas Clark
Re: Change 27228: To make arithmetic on tainted dualvars work properly requires that
On Mon, Feb 20, 2006 at 10:12:33AM -0500, John E. Malmberg wrote: Extracted program: EAGLE type [-.t.op]taint.t2 use strict; use Config; use File::Spec::Functions; use Devel::Peek; my $got_dualvar; eval 'use Scalar::Util dualvar; $got_dualvar++'; #skip No Scalar::Util::dualvar unless $got_dualvar; my $a = Scalar::Util::dualvar(3, $^X); Dump $a; print STDERR a = $a\n; my $b = $a + 5; print STDERR b = $b, should be 8\n; #is ($b, 8, Arithmetic on tainted dualvars works); Run first with out tainting, output looks good: EAGLE mcr [-]ndbgperl -I[-.lib] [-.t.op]taint.t2 SV = PVNV(0x36d1d8) at 0x2e9788 REFCNT = 1 FLAGS = (PADMY,IOK,POK,pIOK,pPOK) IV = 3 NV = 0 PV = 0x3121f8 eagle$dqa0:[project_root.][perl-blead]ndbgperl.exe;3\0 CUR = 52 LEN = 56 a = eagle$dqa0:[project_root.][perl-blead]ndbgperl.exe;3 b = 8, should be 8 That all looks good Run a second time with tainting, and fails. EAGLE mcr [-]ndbgperl -T -I[-.lib] [-.t.op]taint.t2 SV = PVMG(0x2c6d00) at 0x2e9740 REFCNT = 1 FLAGS = (PADMY,GMG,SMG,pPOK) IV = 0 NV = 0 PV = 0x339ce0 eagle$dqa0:[project_root.][perl-blead]ndbgperl.exe;3\0 CUR = 52 LEN = 56 MAGIC = 0x2f7850 MG_VIRTUAL = PL_vtbl_taint MG_TYPE = PERL_MAGIC_taint(t) MG_LEN = 1 a = eagle$dqa0:[project_root.][perl-blead]ndbgperl.exe;3 b = 5, should be 8 If Scalar::Util is dynamically loaded, I will have a hard time setting a breakpoint in it to debug it at C level to see what is going on. It is. The output should look like this under taint mode: SV = PVMG(0x822c85c) at 0x821927c REFCNT = 1 FLAGS = (GMG,SMG,pIOK,pPOK) IV = 3 NV = 0 PV = 0x826730c /home/nick/p4perl/perl/perl\0 CUR = 27 LEN = 28 MAGIC = 0x826734c MG_VIRTUAL = PL_vtbl_taint MG_TYPE = PERL_MAGIC_taint(t) MG_LEN = 1 ie the FLAGS line reads (PADMY,GMG,SMG,pIOK,pPOK) Your FLAGS line doesn't have pIOK. For me, the input is $^X SV = PVMG(0x822c044) at 0x82192fc REFCNT = 1 FLAGS = (GMG,SMG,pPOK) IV = 0 NV = 0 PV = 0x8216e8c /home/nick/p4perl/perl/perl\0 CUR = 27 LEN = 28 MAGIC = 0x8216ecc MG_VIRTUAL = PL_vtbl_taint MG_TYPE = PERL_MAGIC_taint(t) MG_LEN = 1 and SV = IV(0x8219fa8) at 0x8219fac REFCNT = 1 FLAGS = (PADTMP,IOK,READONLY,pIOK) IV = 3 I assume that $^X is tainted on VMS? Of course I do not really understand what I am looking at :-) Well, there should be both pPOK and pIOK flags on the the value, with IV = 3 and PV being the string for $^X If you change your print STDERR a = $a\n; to printf STDERR a = '%s', %d\n, $a, $a; you should see the two values of the dualvar. Assuming that input, the bug I was actually trying to fix was that when you put this tainted dual valued scalar into an arithmetic expression, the string got used for its numeric value, rather than the integer. Hence 0 rather than 3 in this case. In addition, the program that creates .C modules from .XS modules is placing #line directives in the .C source. This badly breaks the OpenVMS debugger, because it does not know how to map the binary code to the .XS module lines. I need to find out how to get that program to make those #line directives comments on VMS and not preprocessor directives. I think adding -nolinenumbers to the flags passed to xsubpp should do it. Although that might mean hacking descrip.mms after it's been generated from Makefile.PL Nicholas Clark
Re: Smoke [5.8.8] 26944 FAIL(F) openvms V8.2 (Alpha/1 cpu)
On Thu, Jan 26, 2006 at 06:45:58PM -0600, Craig A. Berry wrote: [-.lib.File]Copy.t..FAILED 20 #26396 (a VMS-only TODO) io/crlf_through.t...FAILED 4-6 13-14 17 #26857 (VMS-only skip) io/fs.t.FAILED 5 possibly 25951, though I'm not sure io/through.tFAILED 4-6 13-14 17 #26857 (VMS-only skip) op/cmp.tFAILED 43-7854 Don't know -- the test itself hasn't changed in years. op/goto.t...FAILED 53-54 #26396 (small test tweak) pod/pod2usage2.tFAILED 2-3 5-13 15 #26710 (adding VMS to the skip already there for Win32) I've integrated 26396, 26710 and 26857. 25951 all looks rather involved. Nicholas Clark
Re: Module::Build on VMS?
On Thu, Jan 19, 2006 at 05:10:08PM -0500, John E. Malmberg wrote: Execute access with out read access allows a program to be run, but no copies to be made or displayed. This can not currently be done with Perl scripts on OpenVMS. Doing so would require some changes in Perl and require that Perl be installed as a trusted image with READALL privilege to use to get around the file permissions blocking the script from being read. An interesting concept, perl scripts that can be run, but not viewed, copied, or debugged. I am not sure that there would be much demand for that feature. Sounds like something that B::Deparse could still retrieve. Nicholas Clark
Re: patch@26561 earlier - buffer overrun in VMS.C
On Mon, Jan 02, 2006 at 01:24:00PM -0600, Craig A. Berry wrote: At 2:05 PM -0500 1/2/06, John E. Malmberg wrote: This buffer overrun bug in vms.c/mp_do_fileify_dirspec has been there for a while and was made more visible by the recent changes to allow support of longer file names. Thanks, applied to blead as #26581. This patch should also be applied to the maint and upcoming 5.8 streams. I agree. Should be in now. Nicholas Clark
Re: Upgrade MakeMaker in maint
On Tue, Sep 20, 2005 at 05:29:10PM +0100, Nicholas Clark wrote: On Mon, Sep 19, 2005 at 05:56:50PM -0700, Michael G Schwern wrote: Maint is still using MakeMaker 6.17 which is now TWO YEARS OLD! Last I checked there was some VMS failure or another possibly tied to File::Find but I don't have details. I really rather 5.8.8 not go out with 6.17 again, 6.30 is good and stable. Can we just take the plunge, put 6.30 into maintperl and work out the glitches? The last thing that I remember was that there was some fun with make distclean on VMS in blead and SDBM_File. Or at least something with SDBM_File I was going to look last week to see if you're most recent version had cured it, but it was the day after testdrive went down for 2 weeks. OK. 6.30 is in maint. What breaks? What breaks in maint that is non-broken in blead? Nicholas Clark
Re: blead on VMS on testdrive
On Sat, Oct 15, 2005 at 12:25:35PM +0200, Abe Timmerman wrote: It looks like you have the same problems I had before. I installed MMK locally on spe180 and with that, blead now builds up to Compress::Zlib. I haven't tried maint yet, but will try during the weekend. Dunno if there is a way of sharing my user5:[abeltje] directory on spe180 with you; if so be my guest! Well, for the past 3 days I've been unable even to log into that machine. I was hoping that I could use your copy of mmk to build my source tree, to save me figuring out how ti install mmk. Nicholas Clark
Re: blead on VMS on testdrive
On Mon, Oct 10, 2005 at 10:11:32AM -0400, Peter Prymmer wrote: I presume you wanted to test out a recently created tar kit. Correct I recommend that instead of extracting filename.tar with this: tar -xvf filename.tar that you do the following: tar /extract/verbose/date=none filename.tar so that the /date_policy does not get confused about the extracted file or directory timestamps. I did this (after deleting the previous tree), and see the same failures. The problem seems to be down to created files. Which smells much like the problems I know I've seen building over NFS on Unix with mismatched clocks. I mailed the testdrive support folks, and they say that they don't attempt to synchronise the clocks on the VMS clusters. Their simpler recommendation was to not build across the cluster, which means that I need to work out which (if any) machines have filespace accessible to me that is on the local machine. Nicholas Clark
blead on VMS on testdrive
Oops. I can't remember the list name. - Forwarded message from Nicholas Clark [EMAIL PROTECTED] - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk list-help: mailto:[EMAIL PROTECTED] list-unsubscribe: mailto:[EMAIL PROTECTED] list-post: mailto:perl5-porters@perl.org X-List-Archive: http://nntp.perl.org/group/perl.perl5.porters/105379 List-Id: perl5-porters.perl.org Delivered-To: mailing list perl5-porters@perl.org Delivered-To: perl5-porters@perl.org X-Spam-Status: No, hits=-1.3 required=8.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS,UPPERCASE_25_50,WEIRD_QUOTING X-Spam-Check-By: la.mx.develooper.com Date: Sat, 8 Oct 2005 17:55:53 +0100 From: Nicholas Clark [EMAIL PROTECTED] To: [EMAIL PROTECTED], perl5-porters@perl.org Subject: blead on VMS on testdrive Mail-Followup-To: [EMAIL PROTECTED], perl5-porters@perl.org User-Agent: Mutt/1.3.25i X-Organisation: Tetrachloromethane X-Keywords: X-UID: 266 I'm trying to build blead on VMS testdrive. It seems to be going wrong here: Making B (dynamic) %MMS-W-GMFUTURE, Time for [--.LIB].EXISTS is in the future: 8-OCT-2005 13:46:42 .00 %MMS-W-GMFUTURE, Time for [--.LIB.AUTO.B].EXISTS is in the future: 8-OCT-2005 1 3:46:55.00 %MMS-W-GMFUTURE, Time for [.BLIB.BIN].EXISTS is in the future: 8-OCT-2005 13:46 :55.00 %MMS-W-GMFUTURE, Time for [.BLIB.SCRIPT].EXISTS is in the future: 8-OCT-2005 13 :46:56.00 %MMS-W-GMFUTURE, Time for [.BLIB.MAN1].EXISTS is in the future: 8-OCT-2005 13:4 6:57.00 %MMS-W-GMFUTURE, Time for [.BLIB.MAN3].EXISTS is in the future: 8-OCT-2005 13:4 6:57.00 %MMS-W-GMFUTURE, Time for PM_TO_BLIB.TS is in the future: 8-OCT-2005 13:47:04.0 0 Set Default [.c] MMS /Descrip= Descrip.MMS all %MMS-W-GMFUTURE, Time for [---.LIB.B].EXISTS is in the future: 8-OCT-2005 13:47 :05.00 %MMS-W-GMFUTURE, Time for [---.LIB].EXISTS is in the future: 8-OCT-2005 13:46:4 2.00 %MMS-W-GMFUTURE, Time for [---.LIB.AUTO.B.C].EXISTS is in the future: 8-OCT-200 5 13:47:07.00 %MMS-W-GMFUTURE, Time for [-.BLIB.BIN].EXISTS is in the future: 8-OCT-2005 13:4 6:55.00 %MMS-W-GMFUTURE, Time for [-.BLIB.SCRIPT].EXISTS is in the future: 8-OCT-2005 1 3:46:56.00 %MMS-W-GMFUTURE, Time for [-.BLIB.MAN1].EXISTS is in the future: 8-OCT-2005 13: 46:57.00 %MMS-W-GMFUTURE, Time for [-.BLIB.MAN3].EXISTS is in the future: 8-OCT-2005 13: 46:57.00 %MMS-W-GMFUTURE, Time for PM_TO_BLIB.TS is in the future: 8-OCT-2005 13:47:07.0 0 CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj /NOANSI_ALIAS/floa t=ieee/ieee=denorm/Define=(VERSION=1.04,XS_VERSION=1.04)/Include=([- --])/NoList C.c If F$Search([---.LIB.AUTO.B.C]C.OLB).eqs. Then Library/Object/Create [---.LI B.AUTO.B.C]C.OLB Library/Object/Replace [---.LIB.AUTO.B.C]C.OLB C.OBJ If F$TrnLNm(PerlShr).eqs. Then Define/NoLog/User PerlShr Sys$Share:PerlShr.e xe Link /NoTrace/NoMap /Shareable=[---.LIB.AUTO.B.C]PL_B__C.EXE C.opt/Option,[---]p erlshr_attr.opt/Option Running Mkbootstrap for B::C () MCR $1$DKC300:[NWC10.25712]miniperl.exe -I[---.lib] -I[---.lib] -MExtUtils: :Command -e chmod 644 C.BS MCR $1$DKC300:[NWC10.25712]miniperl.exe -I[---.lib] -I[---.lib] -MExtUtils: :Command -e cp C.bs [---.LIB.AUTO.B.C]C.BS MCR $1$DKC300:[NWC10.25712]miniperl.exe -I[---.lib] -I[---.lib] -MExtUtils: :Command -e chmod 644 [---.LIB.AUTO.B.C]C.BS %MMS-F-ABORT, For target SUBDIRS, CLI returned abort status: %X10EE8180. %MMS-F-ABORT, For target DYNEXT, CLI returned abort status: %X10EE8034. bash$ uname -a OpenVMS TD182 0 V8.2 AlphaServer_ES40 Alpha Am I doing something daft here? Or is that machine confused as to what the time is, so it's not my fault? I've no idea if my home directory is a network mount, which is often a cause of fun on Unix. Nicholas Clark - End forwarded message -
maint on testdrive
I'm trying to hammer out the problems with maint on VMS using testdrive. I've hit a problem that i can't solve: $ mms pp_sys.obj CC/DECC/NOANSI_ALIAS /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/NoLis t/float=ieee/ieee=denorm/Define=PERL_CORE PP_SYS.C PUSHi( PerlDir_chdir(tmps) = 0 ); ^ %CC-W-NOTCONSTQUAL, In this statement, the referenced type of the pointer value ((tmps)) is const, but the referenced type of the target of this assignment is not. at line number 3500 in file USER1:[NWC10.25714]PP_SYS.C;1 SETi( PerlDir_mkdir(tmps, mode) = 0 ); ^ %CC-W-NOTCONSTQUAL, In this statement, the referenced type of the pointer value ((tmps)) is const, but the referenced type of the target of this assignment is not. at line number 3771 in file USER1:[NWC10.25714]PP_SYS.C;1 SETi( PerlDir_rmdir(tmps) = 0 ); ^ %CC-W-NOTCONSTQUAL, In this statement, the referenced type of the pointer value (tmps) is const, but the referenced type of the target of this assignment is n ot. at line number 3793 in file USER1:[NWC10.25714]PP_SYS.C;1 %MMS-F-ABORT, For target PP_SYS.OBJ, CLI returned abort status: %X10B91260. I can't work out what those lines are expanding to. How do I run just the C pre-processor? The mm description doesn't seem to have a rule to do this. Nicholas Clark
Re: Upgrade MakeMaker in maint
On Mon, Sep 19, 2005 at 05:56:50PM -0700, Michael G Schwern wrote: Maint is still using MakeMaker 6.17 which is now TWO YEARS OLD! Last I checked there was some VMS failure or another possibly tied to File::Find but I don't have details. I really rather 5.8.8 not go out with 6.17 again, 6.30 is good and stable. Can we just take the plunge, put 6.30 into maintperl and work out the glitches? The last thing that I remember was that there was some fun with make distclean on VMS in blead and SDBM_File. Or at least something with SDBM_File I was going to look last week to see if you're most recent version had cured it, but it was the day after testdrive went down for 2 weeks. Is the current version happy on VMS with SDBM_File? Nicholas Clark
odd corruption seen previously with hashes on VMS
With respect to the odd corruption seen previously on VMS, but now no longer
visible, might this patch have had something to do with it? I believe that
the change I made was correct. If so, then because it removed a large over-
allocation, it will show up any other code that failed to allocate sufficient
space, hence revealing latent bugs elsewhere.
Nicholas Clark
- Forwarded message from Nicholas Clark [EMAIL PROTECTED] -
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
List-Post: mailto:perl5-changes@perl.org
List-Help: mailto:[EMAIL PROTECTED]
List-Unsubscribe: mailto:[EMAIL PROTECTED]
List-Subscribe: mailto:[EMAIL PROTECTED]
List-Id: perl5-changes.perl.org
Delivered-To: mailing list perl5-changes@perl.org
Delivered-To: perl5-changes@perl.org
X-Spam-Status: No, hits=-2.6 required=8.0
tests=BAYES_00,UPPERCASE_25_50
X-Spam-Check-By: la.mx.develooper.com
Date: Wed, 1 Jun 2005 08:43:38 -0700
From: Nicholas Clark [EMAIL PROTECTED]
To: Anybody And Everybody perl5-changes@perl.org
Subject: Change 24661: As PERL_HV_ARRAY_ALLOC_BYTES is bytes, not items, the
type should be
Change 24661 by [EMAIL PROTECTED] on 2005/06/01 15:08:02
As PERL_HV_ARRAY_ALLOC_BYTES is bytes, not items, the type should be
char rather than HE *. Bug was harmless, overallocating by a factor
of sizeof(HE *)
Affected files ...
... //depot/perl/hv.c#221 edit
Differences ...
//depot/perl/hv.c#221 (text)
Index: perl/hv.c
--- perl/hv.c#220~24660~Wed Jun 1 07:33:14 2005
+++ perl/hv.c Wed Jun 1 08:08:02 2005
@@ -603,10 +603,13 @@
#ifdef DYNAMIC_ENV_FETCH /* if it's an %ENV lookup, we may get it on the fly
*/
|| (SvRMAGICAL((SV*)hv) mg_find((SV*)hv, PERL_MAGIC_env))
#endif
- )
- Newz(503, HvARRAY(hv),
+ ) {
+ char *array;
+ Newz(503, array,
PERL_HV_ARRAY_ALLOC_BYTES(xhv-xhv_max+1 /* HvMAX(hv)+1 */),
-HE*);
+char);
+ HvARRAY(hv) = (HE**)array;
+ }
#ifdef DYNAMIC_ENV_FETCH
else if (action HV_FETCH_ISEXISTS) {
/* for an %ENV exists, if we do an insert it's by a recursive
@@ -773,9 +776,11 @@
/* Not sure if we can get here. I think the only case of oentry being
NULL is for %ENV with dynamic env fetch. But that should disappear
with magic in the previous code. */
- Newz(503, HvARRAY(hv),
+ char *array;
+ Newz(503, array,
PERL_HV_ARRAY_ALLOC_BYTES(xhv-xhv_max+1 /* HvMAX(hv)+1 */),
-HE*);
+char);
+ HvARRAY(hv) = (HE**)array;
}
oentry = (HvARRAY(hv))[hash (I32) xhv-xhv_max];
End of Patch.
- End forwarded message -
Re: Need help debugging blead on VMS - keys(%ENV)
On Mon, Aug 22, 2005 at 10:35:54PM -0400, John E. Malmberg wrote: On every blead perl I have seen, the following bug is present on VMS and is causing the script t/op/magic.t to fail at test 7. In the Perl debugger, before running any script if you issue the command 'x keys(%ENV), the entry for index 0, also shows up as index 1. DB1 x keys(%ENV) 0 'SYS$TIMEZONE_DAYLIGHT_SAVING' 1 'SYS$TIMEZONE_DAYLIGHT_SAVING' 2 'CDE$DETACHED_LOGICALS' 3 'MOP$NAMED_LOAD' 4 'BUILD_ROOT' On all subsequent calls, you get the expected results: DB2 x keys(%ENV) 0 'SYS$TIMEZONE_DAYLIGHT_SAVING' 1 'CDE$DETACHED_LOGICALS' 2 'MOP$NAMED_LOAD' 3 'BUILD_ROOT' 4 'SMBSRVSHR_TV' IIRC %ENV on VMS is special, in that it's the only platform and only hash that uses the DYNAMIC_ENV_FETCH code. It's quite possible that there's a strange, unnoticed bug in that. Nicholas Clark
Re: [patch@25305] lib/ExtUtils/t/Constant.t VMS fixes
On Sun, Aug 21, 2005 at 12:31:17AM -0400, John E. Malmberg wrote: Fix for correct names for the descrip.mms file used with MMS/MMK on VMS. Per review of Andy Lester, also fixed the error message from failed renames. Also preparation for use of other make programs on VMS with the assumption that no there will be no port of MMK to other platforms even though it is open source. Seems a reasonable assumption. Thanks, applied (25310) Nicholas Clark
Re: Data corruption - blead@25226 - PERL_HV_ARRAY_ALLOC_BYTES?
On Sat, Aug 20, 2005 at 01:08:07AM -0400, John E. Malmberg wrote: Nicholas Clark wrote: I can only reproduce this on one instance of one test, but on that test it can be reproduced every time. In your previous messages I couldn't spot whether you said which test. Is there some quick way that I can turn on the DEBUG_m function once I start reproducing the problem? It would be interesting to see if that gave any more clues. Yes, good idea. You can do this by setting the bit values in $^D at runtime. So setting $^D to 128 just for the section you're interested in would be the same as -Dm on the command line, only locally. There's a table of letters and values in perlrun.pod. Nicholas Clark
Re: Data corruption - blead@25226 - PERL_HV_ARRAY_ALLOC_BYTES?
On Sat, Aug 20, 2005 at 05:25:02PM -0400, John E. Malmberg wrote: Nicholas Clark wrote: On Sat, Aug 20, 2005 at 01:08:07AM -0400, John E. Malmberg wrote: Nicholas Clark wrote: I can only reproduce this on one instance of one test, but on that test it can be reproduced every time. As of [EMAIL PROTECTED], I can not reproduce the corruption anymore. Bah. If you still have the build tree for the version that reliably shows it, what happens if you apply just patch 25297 to it, and recompile: http://public.activestate.com/cgi-bin/perlbrowse?patch=25297 (I assume that the MMS template is similar to the Unix Makefile and can build the target perl, rather than all, which would save waiting for all the dynamic extensions to rebuild) I'm wondering if it was something about the screwy amount of casting as was in HvARRAY() that was the cause of the problem. Nicholas Clark
Re: Data corruption - blead@25226 - PERL_HV_ARRAY_ALLOC_BYTES?
Sorry about the delay in replying. I've had a lot on, and wanted to find
the time to confirm my suspicions.
On Sat, Jul 30, 2005 at 09:50:40PM -0400, John E. Malmberg wrote:
What I have found is that in this case is that the allocation size for
the sv_u.svu_array member appears to be too small.
I don't believe this conclusion to be correct.
I refactored the hash code about 2 months ago and introduced the xpvhv_aux
structure. Prior to this, the malloc()ed region pointed to by the
sv_u.svu_array member was only used for the HE*s. For the case of no the
xpvhv_aux structure, the part of the code that calculates the size to allocate
has not changed.
The size of the allocated or reallocated array is controlled by the
xhv_max member.
DBG exam hv-sv_any-xhv_max
HV\Perl_hv_iternext_flags\hv-sv_any-xhv_max: 7
The actual calculation is for the array size =
PERL_HV_ARRAY_ALLOC_BYTES(HvMAX(hv) + 1) + sizeof(struct xpvfhv_aux)
HvMAX(hv) = 7 from above.
So PERL_HV_ARRAY_ALLOC_BYTES results in:
(8 * sizeof(HE*) + sizeof(struct xpvfhv_aux)
The size of a Pointer type on VMS is 4 bytes. And the size of the
struct xpvfhv is 12 bytes. This results in (8 * 4) + 12 or 48 bytes.
A pointer to the xpvfhv is then stored in hv-sv_u.svu_array[8].
The size of the svu_array type is 12, so the offset is 12 * (8-1) is 84
which is a bit beyond the 48 bytes that was allocated.
It appears to me that macro PERL_HV_ARRAY_ALLOC_BYTES should be using
the size of the HE structure instead of the size of a pointer to that
structure.
The memory that is allocated is used to store an array of HE * pointers.
Not HE structures. The code isn't clear, and when I started trying to
investigate I realised that I could add another member to the sv_u
union, of type HE **, to make things much clearer.
Had the calculation been wrong in the past, we would also have been allocating
4*n bytes on many systems, yet using 12*n bytes, for every hash, which should
have shown up with memory checking tools (and random corruption) left right
and centre.
So I'm assuming that the problem is in or related to the changes I made to
tag a xpvhv_aux structure on the end, but not all the time. Hence I suspect
that it's my fault and been trying to confirm where, and nail the cause, if
not find the solution. But I admit that I have to give up. I don't know
where. Even if I try this change to make the xpvhv_aux structure rather
larger:
//depot/perl/hv.h#76 - /home/nick/p4perl/perl/hv.h
--- /tmp/tmp.89859.0Fri Aug 19 21:38:03 2005
+++ /home/nick/p4perl/perl/hv.h Wed Aug 17 13:54:08 2005
@@ -37,10 +37,14 @@ struct shared_he {
Don't access this directly.
*/
struct xpvhv_aux {
+char splat1[1];
HEK*xhv_name; /* name, if a symbol table */
HE *xhv_eiter; /* current entry of iterator */
I32xhv_riter; /* current root of iterator */
+char splat2[1];
};
+
+#define SPLAT(hv) memset(HvAUX(hv)-splat1, 0xFE, 1);
memset(HvAUX(hv)-splat2, 0xFE, 1);
/* hash structure: */
/* This structure must match the beginning of struct xpvmg in sv.h. */
and put calls to SPLAT everywhere that the members of xpvhv_aux are written
to, I can't trigger the corruption on x86 Linux.
The xpvhv_aux structure is placed in memory directly after the array of
pointers to HE*s. However, memory to hold it is not always allocated.
My assumption is that either
1: There's a code path that starts writing to the location it should be in,
without first calling realloc() to allocate memory for it.
2: There's an error in the code that works out the offset of the xpvhv_aux
structure given the pointer accessed via the macro HvARRAY()
but I can't find it by inspection, and I can't reproduce it, even by tweaking
the code to try to provoke the problem. Running regression tests under
valgrind doesn't find anything amiss either. I'm stuck. But I'm confident
that it's not a three-fold error in the calculation for the size of memory to
allocate for the array of HE **s.
Nicholas Clark
Re: Data corruption - blead@25226 on VMS.
On Sat, Jul 30, 2005 at 12:27:43AM -0400, John E. Malmberg wrote: The address 10439704 was already a part of the structure that Perl_hv_iternext_flags() had pointed a variable named iter at. DBG exam *iter *HV\Perl_hv_iternext_flags\iter xhv_name: 1162633044 xhv_eiter: 4998486 xhv_riter: -256 DBG eval/addr iter-xhv_riter 10439704 It appears to me that one of these structures was not allocated large enough for the data that is being put in it. As the xpvhv_aux structure is a fixed size structure, my suspicion is that the problem is the above code somewhere since this is where the HEK struct is allocated just before *iter got corrupted. However the xpvhv_aux structure is allocated by extending the HV's array of linked list heads, and using space after it. So there is the possibility that there is a code path where the extending realloc() didn't take place, and the memory is being used out-of-bounds. What is the value of sv_flags in the hash? (struct hv, defined in sv.h, typdef'd to HV) Specifically is bit 0x0020 set? It should be, where xpvhv_aux is in use (See the comment near SVf_OOK in sv.h) I'm about to set off to the US for OSCON, so I'm unlikely to be in a position to read mail, let alone respond to it, for over 24 hours. (travel + sleep) Nicholas Clark
Re: blead@25210 on OpenVMS (not good)
On Sat, Jul 23, 2005 at 03:36:39PM -0400, John E. Malmberg wrote: How do I reproduce this? I pulled down perl-5.9.2 and started a build and it fails with: CC/DECC/NOANSI_ALIAS /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/List #$d_sitecustomize USE_SITECUSTOMIZE /**/ .^ %CC-W-BADDIRECTIVE, $d_sitecustomize is an invalid preprocessor directive, an at line number 3462 in file PERL_BUILD_ROOT:[00]config.h;1 %MMK-F-ERRUPD, error status %X10B91260 occurred when updating target MINIPERLMA 23-JUL-2005 15:28:53 The perl 5.9.2 release is now somewhat out of date. That bug has been fixed. And new ones introduced instead :-( The best way to get the current source is with rsync. The master source repository is in perforce, and there isn't anonymous access to that. We don't tend to make snapshots, I think partly because everyone actively developing is very happy with rsync, and partly because snapshots seem to generate near zero feedback, suggesting the time is better spent elsewhere. (I suspect that the widespread use of rsync helps explain the lack of interest in specific snapshots. In effect every commit gets treated like a snapshot) There are a few paragraphs on what can be got with rsync in perlhack.pod: http://search.cpan.org/~rgarcia/perl-5.9.2/pod/perlhack.pod#Keeping_in_sync but most simply if you run rsync -avz rsync://ftp.linux.activestate.com/perl-current/ perl/ you will get a local directory perl/ containing the current development sources. If you build that you should see the same problems as Abe is reporting. Nicholas Clark
Re: [PATCH] blead help for VMS
On Sun, Jul 24, 2005 at 03:31:55PM -0500, Craig A. Berry wrote: The attached patch (plus one additional step) gets bleadperl building on VMS again. The additional step is renaming the directory ext/Compress/Zlib/zlib-src-1.2.3 to ext/Compress/Zlib/zlib-src which I assume needs to be done in Perforce. The related changes to $ p4 help rename rename -- How to rename files p4 integrate from to p4 delete from p4 submit Perforce does not support a single 'rename' command, but files can be renamed by branching one file into another and then deleting the original file. The 'from' and 'to' file arguments may include wildcards as long as they are matched. Integrating from files require read access to the files, but deleting them requires write access. For further information, see the help for the individual commands. And what it doesn't state explicitly is that you're renaming files, not directories, so you then have to use perforce wildcards, ie: $ cd ext/Compress/Zlib/ $ p4 integrate zlib-src-1.2.3/... zlib-src/... $ p4 delete zlib-src-1.2.3/... Thanks, applied (25217) Nicholas Clark
Re: [PATCH] Re: blead@25210 on OpenVMS (not good)
On Sun, Jul 24, 2005 at 05:47:26PM -0500, Craig A. Berry wrote: And this should take care of it. Accidentally left out of my patch of two hours ago. Thanks applied (25218) Nicholas Clark
Re: MM 6.25_12 on VMS status (was Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_10)
On Sun, Mar 20, 2005 at 04:08:38PM -0600, Craig A. Berry wrote: At 11:20 AM -0800 3/17/05, Michael G Schwern wrote: How does it fare actually installing modules? Using 6.25_12 (Revision: 2339) on OpenVMS Alpha v7.3-1, Perl 5.8.4, I had no trouble building, testings, and installing DBI 1.48. Compress::Zlib 1.34 worked fine also, though it did give me the following warning: Does it build SDBM_File? That was always the biggest problem in core. I guess the easiest answer is if someone integrates it into core PDQ I'm afraid that I doubt I'll have time tonight, as I'm trying to clear up some work stuff before the morning. Nicholas Clark
Re: [PATCH] t/op/split.t #11 nit on VMS
On Sun, Jan 09, 2005 at 05:46:41PM -0600, Craig A. Berry wrote: Because of a longstanding pipe bug, the debugging output const(IV(3)) might have a newline in the middle of it when read through a pipe (as of course it does in the test suite), so this patch modifies the pattern to match the newline when present. While I was there, I thought we should let runperl worry about how to run perl. Thanks, applied (23779) Nicholas Clark
Re: [PATCH] randbits and randfunc for VMS
On Fri, Dec 31, 2004 at 09:31:11AM -0600, Craig A. Berry wrote: We were not setting randbits appropriately when using drand48(), and that was causing 64-bit builds to fail. We were not setting randfunc at all. The attached patch to configure.com corrects these omissions. Thanks, applied (23715) Nicholas Clark
Re: [PATCH] configure.com: no more CONFIG=true
On Thu, Dec 02, 2004 at 03:23:06PM -0600, Craig A. Berry wrote: Nick's new lib/Config.t test caught the fact that we had both CONFIG and PERL_CONFIG_SH in our config.sh, but should only have the latter. In the The curious thing is that the test in question is not new, and not written by me. I've added more to that test file, but not changed the particular test that was failing. ensuing discussion I noticed we were not writing out perl_patchlevel, nor were we using the value in .patch to override the value in patchlevel.h if necessary. The attached patch corrects both of these issues and gets lib/Config.t passing. Thanks, applied as 23601 Nicholas Clark
Re: [PATCH] Detecting strlcat() and strlcpy() in Configure
On Mon, Nov 01, 2004 at 04:57:00PM -0500, [EMAIL PROTECTED] wrote: $ cc /ver Compaq C S6.5-002 on OpenVMS Alpha V7.3-2 and it does not have any strl* functions in it's CRTL. But they may be added at some time. We could add tests to configure.com and that might help with the extraction of config.h from config_h.SH, but I have to admit to not having built bleed on VMS in quite a while, so if Craig Berry chimes in with something it superseded what I've said here. I'll see about syncing out the latest bleed How little does it take to make VMS build a config.h that reports that they don't exist? (Not doing any probing, just decree that they aren't there) Nicholas Clark
Re: maintperl@23335 on VMS
On Sat, Oct 23, 2004 at 11:44:17PM -0500, Craig A. Berry wrote: Here's what I'm seeing with a default configuration using Compaq C V6.5-001 on OpenVMS Alpha V7.3-1. Several tests fail, but about half of them have already been fixed in blead. I will try to work up fuller reports and/or fixes for the others. This is rather bad timing. 23335 dates from 23rd September. I had a big session of integrating starting on 19th October. I fear that this has made a lot of your careful documentation of problems obsolete. t/uni/class...FAILED at test 2959 fixed in blead by #23343 already integrated. t/lib/vmsfspecFAILED at test 134 fixed in blead by #23346 already integrated ext/B/t/optree_conciseFAILED at test 12 ext/B/t/optree_sort...FAILED at test 3 ext/B/t/optree_specials...FAILED at test 2 ext/B/t/optree_varinitFAILED at test 6 These do not fail in blead. Curious ext/Devel/PPPort/t/ppphtest...FAILED at test 2 fixed in blead by #23367 already integrated lib/Carp..FAILED at test 10 Also fails in blead. lib/ExtUtils/t/basic..FAILED at test 62 Hmm. Looks like maint is still using MM 6.17, so something it depends on must have changed. I don't intend to touch MakeMaker in maint until a new stable release comes out on CPAN. Unfortunately every stable release subsequent to 6.17 has issues somewhere with core perl on one or other platform. Nicholas Clark
Re: [PATCH] prime_env_iter and zero-length values on VMS
On Wed, Jul 14, 2004 at 04:43:09PM -0500, Craig Berry wrote: On Wednesday, July 14, 2004, at 03:53PM, Nicholas Clark [EMAIL PROTECTED] wrote: Given that this patch is entirely in the VMS code, I don't mind putting it into 5.8.5, because it can't affect anything other than VMS, and you have a much better idea of what's sane for VMS than I do. [Plus I can point at you if it goes wrong :-)] So should it go in? Yes, please. Can I point at you if anything other than this goes wrong? ;-) Everyone else will, so I don't see why you shouldn't. Nicholas Clark
Re: [PATCH] prime_env_iter and zero-length values on VMS
On Thu, Jul 08, 2004 at 11:19:05PM -0500, Craig A. Berry wrote: The attached patch against blead fixes the bug and causes no new test failures. The bug was causing a failure in lib/I18N/LangTags/t/80_all_env.t in both blead and maint for reasons that had only to do with the %ENV infrastructure described above and nothing at all to do with I18N::LangTags (thanks to Sean Burke for patiently wading through a red herring bug report). --- vms/vms.c;-0 Tue Jul 6 23:12:33 2004 +++ vms/vms.c Thu Jul 8 09:01:34 2004 Given that this patch is entirely in the VMS code, I don't mind putting it into 5.8.5, because it can't affect anything other than VMS, and you have a much better idea of what's sane for VMS than I do. [Plus I can point at you if it goes wrong :-)] So should it go in? Nicholas Clark
Re: [PATCH RC1] install reentr.(inc|h) on VMS with non-threaded Perl
On Thu, Apr 08, 2004 at 08:46:36PM -0500, Craig A. Berry wrote: I've tested extension building against an installed copy of the release candidate in a non-threaded configuration and it fails because reentr.inc is included unconditionally even when threads are not enabled: #include reentr.inc .^ %CC-F-NOINCLFILEF, Cannot find file reentr.inc specified in #include directive. at line number 3600 in file PERL_ROOT:[LIB.VMS_AXP.5_8_4.CORE]perl.h;1 I'm pretty sure this is different from how it used to be, but in any case the attached patch unconditionally copies both reentr.inc and reentr.h to the archcore directory, from whence installperl will pick them up and install them. Thanks, applied 22683 I assume that with this correction everything passed as expect on VMS, given that you made no comment to the contrary? This is only for maint; blead will need something different as it appears there is no longer a reentr.inc there. Yes, it's not needed on blead. I forget the details, but it was more that the reentr.inc was needed on maint to keep binary compatibility. Blead has more freedom. Nicholas Clark
Re: [PATCH] OpenVMS I64 support
On Fri, Dec 19, 2003 at 12:01:43AM -0500, [EMAIL PROTECTED] wrote: Craig A. Berry [EMAIL PROTECTED] wrote on 12/18/2003 07:19:43 PM: Earlier today HP released the OpenVMS v8.1 evaluation kit. This is the second early adopter's kit of VMS on Itanium but the first one to include native compilers. I'm pleased to say that with the attached patch to bleadperl, Perl has already assimilated this new platform. All* your platforms are belong to us. An impressively small patch. It looks good. Thanks applied as 21933 By the way pod/perlport.pod (er, I mean [.POD]PERLPORT.POD;1 of course :-) mentions the VMS_VAX vs. VMS_AXP archname strings and might be in need of some modification to incorporate the new port to VMS_IA64. Patches welcome as the saying goes, because I suspect that you are the only two subscribers to p5p who could correctly make such a modification. Nicholas Clark * Except AmigaOS. Which reminds me, I discovered a potential victim^Wvolunteer.
Re: [PATCH] configure.com: sig_num, etc.
On Mon, Mar 17, 2003 at 10:52:02AM +0100, A . Bergman wrote: On fredag, mar 14, 2003, at 04:38 Europe/Stockholm, Craig A. Berry wrote: -- removed false impression that we support readdir_r in threaded builds. The C run-time supports it but we are using a home-grown version of readdir. Can the home-grown version be made threadsafe? Is it threadsafe? (Does anyone care?) We're talking about VMS here, aren't we? I thought that they cared deeply about threads. (because spawning a process is not cheap on VMS (or on son-of-VMS)) Nicholas Clark
Re: A couple of patches for perl@18376
On Thu, Jan 02, 2003 at 01:29:23PM -0800, Michael G Schwern wrote: ExtUtils::Constant is not part of the ExtUtils::MakeMaker distribution. That's Nick Clark's baby. And on a CPAN near you... 6.06 won't be going into bleadperl until Win32 dmake and VMS work, no point in breaking all of perl when we can do it as a module. Its currently blocked waiting for VMS fixes. Special, limited time offer: Download this module to break your perl. Act now before a bug fix becomes available, and spoils all your fun. Except that something tells me that some valiant soul will need to download the module, break perl locally, and create the bugfix. Nicholas Clark
Re: [PATCH] pp.c:pp_pow() -- quit when you're done
On Sat, Jun 15, 2002 at 06:56:12PM -0500, Craig A. Berry wrote: A for loop in pp_pow is constructed in such a way that it squares the base again even after it's iterated through all the bits of the exponent. This could be a problem on any system where floating overflow causes an exception; I noticed it with the D_FLOAT format on OpenVMS Alpha, where it was causing Perl to blow up when running p/op/pow.t. The patch below fixes it by exiting the loop as soon as we know we can. If someone strongly objects to having this test inside the loop, I can ifdef it. Not really. I wasn't too worried about tweaking the performance of the integer bits of the pp_pow loop once it was working (in log(n) time). Having looked at how GNU bc does the calculation, I realised that there was at least one way of rewriting it (sorry, I forget how offhand) that would use slightly less calculation each iteration. For information (which I don't think has reached p5p) the reason for having messy loops in pp_pow rather than using pow() or log(), exp() and a multiply is that on Irix with longdoubles, 2**31 was giving a floating point value slightly *less* than 131, which was really screwing up some tests. (and by implication (nearly) every perl programmer's assumption that 2**n is an integer) Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Cracked! - Re: ext/Encode/t/perlio on VMS (was Re: perl@16539)
On Wed, May 22, 2002 at 09:17:07PM +0100, Nick Ing-Simmons wrote: All in all not one of my better bits of code. EINSUFFICIENTPARANOIA? Remember, just because you don't believe that everyone is out to get you, it doesn't actually mean that they are not. Whatever you may think of your code, thanks for it. It's a lot better than no code, and it because it is being maintained it is getting better. Nicholas Clark PS ispell knows its stuff. To quote: PARANOIA is correct -- Even better than the real thing:http://nms-cgi.sourceforge.net/
