I just have built Perl 5.8.3 on OpenVMS Alpha 7.3-2.
When running the tests, the vmsish test failed.
lib/vars.ok
lib/vmsish...FAILED at test 25
lib/warnings.ok
The same build on OpenVMS VAX 7.3 failed 8 tests.
PYTHON
I just have built Perl 5.8.3 on OpenVMS Alpha 7.3-2.
When running the tests, the vmsish test failed.
lib/vars.ok
lib/vmsish...FAILED at test 25
lib/warnings.ok
The same build on OpenVMS VAX 7.3 failed 8 tests.
PYTHON
Craig A. Berry wrote:
At 9:14 PM -0400 4/4/04, John E. Malmberg wrote:
I just have built Perl 5.8.3 on OpenVMS Alpha 7.3-2.
When running the tests, the vmsish test failed.
lib/vmsish...FAILED at test 25
That was patched here:
http://public.activestate.com/cgi-bin
Craig A. Berry wrote:
At 11:00 PM -0400 4/6/04, John E. Malmberg wrote:
Assorted other issues snipped (I may get back to comment on them at
some point, but no promises).
No problems.
If there is a discrepancy between your current offset from UTC and
your timezone rule, then something
It appears that the configure -s option is incompatible with having the
configure script being run from a wrapper command file with the output
redirected to a log file.
Removing the -s option results in prompts to continue.
For example for a command file:
$!
$if
Craig A. Berry wrote:
At 12:12 AM -0400 4/9/04, John E. Malmberg wrote:
It appears that the configure -s option is incompatible with having
the configure script being run from a wrapper command file with the
output redirected to a log file.
Removing the -s option results in prompts to continue
To bring this list up to date, Craig Berry and I have been discussing
patches needed to use Perl to build the GTK+ package as part of Mozilla.
I was giving a set of patches that were used for the last build, and
Craig has also given me a patch that addressed some more issues.
I have since
IvorW wrote:
There's an interesting issue with module names that has been raised
on Perlmonks:
http://perlmonks.org/index.pl?node_id=345472
A good article.
There are actually a couple of ways that OpenVMS can work around this issue.
With OpenVMS 7.3-1, On ODS-5 disks, and application can request
John Peacock wrote:
Black, Andrew wrote:
I would have thought the problem was more widespread than VMS, in
particular Windows would be affected (at least as far as I can see).
All windows versions I have come across regard File.pm file.pm
FILE.pm as the same file.
The NTFS file system considers
Douglas B Rupp wrote:
Very interesting. So gcc on VMS is under active development?
Absolutely. My company is working on the IA64 VMS port of GNAT under
contract to HP. GNAT as you may know, is the Gnu Ada compiler and Gnu C is
required to build the backend. I don't really recommend Gnu C for
Douglas B Rupp wrote:
For example this command:
system $m4 --help /dev/null 21 | grep reload-state /dev/null;
writes the help output to the screen, when it should be going to
/dev/null.
That may need to be handled by GNV, or HP C RTL folks as the redirection
is being handled by m4, presumably a
Craig A. Berry wrote:
The way I see the problem is that we are running the command under
the wrong shell (DCL instead of bash). One possibility here would be
to have Perl detect whether it is running under bash and if it is,
then prepend bash to the command for system(), exec(), and backtick
Craig A. Berry wrote:
At 2:58 PM -0400 4/25/04, John E. Malmberg wrote:
Indeed. So Perl is able to build itself and all the core extensions
with your modifications?
It seems so. The intent was that unless the C features were enabled,
that they would not be visible.
I do not have any feature
Craig A. Berry wrote:
Read the instructions in README.vms :-).
. where it will tell you
$ @[.vms]test .exe -v [-.lib.extutils.t]basic.t
though the second argument should be ndbg instead of empty if
you've got a VMS debug build.
The test failed with a file not found error, so I tried to run
John E. Malmberg wrote:
A Debug build and test of Perl 5.8.4 RC1 on OpenVMS VAX 7.3 has produced
the following information:
PYTHON dir [...]*.*;/size/grand
Grand total of 452 directories, 5179 files, 604207 blocks.
The bulk of the original message apparently got truncated by Mozilla
John E. Malmberg wrote:
Failed 225 test scripts out of 625, 64.00% ok
I am starting to look at the failures.
A spot check of the majority of the failures seem to be about handling
multi-byte character sets, particularly the Japanese set.
-John
[EMAIL PROTECTED]
Personal Opinion Only
Here are the gdiff files for the changes that I have made that should
allow the DECC feature logicals to modify perl's behavior to build GTK+.
It still will probably need a modified spec.pm.
With these changes, and then built with:
$ @'build_disk'['root']configure.com -Dunlink_all_versions -de
Craig A. Berry wrote:
However, there is no indication of how or in what layer this is done. Is
this something in C that is a drop-in replacement for the CRTL's popen
and friends? Or is it in pure Java? Either way, does anyone here know
more about how it's done and/or have an opinion about whether
Craig A. Berry wrote:
At 12:19 AM -0400 6/7/04, John Malmberg wrote:
Craig A. Berry wrote:
To compile Perl directly, you need to interface to a back end code
generator.
True, but we need to define code here. For Perl, it generally
means bytecode that is run on the Perl bytecode engine, which is
Richard Levitte - VMS Whacker wrote:
Hmm, I found a small bug. A file spec. []FOO wasn't reduced to FOO by
my changes. The attached patch contains one more line that takes care
of that particular thing.
I'm going through the rest of File::Spec::VMS right now, finding more
things that aren't at
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Thu, 22 Jul 2004 20:38:49 -0400,
John E. Malmberg [EMAIL PROTECTED] said:
I've yet to be able to build 5.8.4 on my VAX (VMS 7.2, DEC C 6.2-003,
anyone been able to build on that combination?), but I'll try it out
on the Alphas I
Craig Berry wrote:
On Monday, July 26, 2004, at 03:15PM, Dr. Martin P.J. Zinser
[EMAIL PROTECTED] wrote:
I've got one failiure during mmk test:
t/uni/class...FAILED at test 2959
Yeah, I knew about this, but didn't (and still haven't) gotten around
to doing anything
Craig Berry wrote:
Having said all this, I would be happy to see an up-to-date and
useable GCC port on OpenVMS just for the niftiness factor if nothing
else. It might bring with it some other capabilities, like Objective
C, that are otherwise unavailable. But given the lack of a business
case,
Henderson, Jordan (Contractor) (DAASC) wrote:
HP might have a need to have this supported. A case could certainly be made to
have Gnu C/C++ available for the OpenVMS platform to enhance the viability of
the platform, I would think.
It can get a bit more interesting, as OpenVMS on Itanium uses ELF
Craig A. Berry wrote:
There's also a configure-time option in Perl to delete all versions
of a file, but it's currently not working. John Malmberg submitted a
patch that makes it work, but I'm afraid I have sat on it for a
while, though I have not forgotten it and hope to get to it soon.
IIRC: As
Craig Berry wrote:
There is now one of the DECC$* logicals that specifies whether or not
a version number is allowed in unix syntax file specifications passed
to the CRTL, but that's not pertinent here. There is a
configure-time option to Perl that is not (quite yet) implemented
that will
Mark Berryman wrote:
My own experience disagrees with the assessment given in the 1st quoted
message. While it is true that the DECC compiler generates better code
than the GNU C compiler (this is evident even on Linux), there are a
number of features in the GNU C compiler that do not exist in
[Only sent to [EMAIL PROTECTED]
Craig A. Berry wrote:
There has for some time been latent support in the Perl sources to make
unlink() delete all versions of a file on versioning file systems when
Perl has been configured to do so. It is rather odd given the fact that
we say we have this
Willem Grooters wrote:
I would like to add the shops that use VMS-native compilers (Fortran,
Cobol, Pascal, etc). If GCC delivers a non-VMS object format, it is of
no use at all. Even if it did - what would be the benefit (except the
cost)?
GCC delivers a VMS object format. With IA64, OpenVMS
Note: I think I only get mail on the [EMAIL PROTECTED] list.
Nicholas Clark wrote:
On Mon, Nov 29, 2004 at 01:58:52PM -0600, Craig Berry wrote:
I'm not sure. I was trying to keep Config's AUTOLOAD as simple as possible.
Then again, using %INC shouldn't be that hard.
For the Unix Makefile I hit
Michael G Schwern wrote:
Thank you all. Now I have the set. I've posted them up here so I don't
lose them again. http://www.makemaker.org/make_docs/
Unless you get written permission from HP to serve a copy of their
documentation, you are in violation of their copyright.
I would recommend
Carlos Elias Alves wrote:
Hello, my name Carlos. I´m from Brazil.
I have problem with station Digital 21164.
I would recommend that you post on the comp.os.vms newsgroup to get more
precise information, as this list is for discussing issues with the Perl
language on OpenVMS.
They will also
Michael G Schwern wrote:
On Fri, Dec 17, 2004 at 07:24:06PM -0500, John E. Malmberg wrote:
Thank you all. Now I have the set. I've posted them up here so I don't
lose them again. http://www.makemaker.org/make_docs/
Unless you get written permission from HP to serve a copy
[I am only monitoring [EMAIL PROTECTED]
Michael G Schwern wrote:
On Mon, Jan 03, 2005 at 12:53:03PM -0500, [EMAIL PROTECTED] wrote:
Probably the directory target issue on older MMS' that Craig pointed out.
Probably. My version of MMS is older than Craig's and is
even less informative about the
Somehow the vmsperl mailing list got into the spamcop.net list.
(reason: 530 5.7.1 Blocked -
see http://www.spamcop.net/bl.shtml?63.238.179.181:
Since this is a closed list, the only possibilities are:
1. The host had a security problem.
(I really do not think that is likely)
2.
Craig A. Berry wrote:
At 9:31 AM -0500 1/29/05, John E. Malmberg wrote:
Somehow the vmsperl mailing list got into the spamcop.net list.
(reason: 530 5.7.1 Blocked -
see http://www.spamcop.net/bl.shtml?63.238.179.181:
This has happened from time to time, but the address you show here
Craig A. Berry wrote:
It does look like the entire ISP is listed by blackholes.us:
http://openrbl.org/zones/@ISP?63.251.223.163
but I'm not at all sure I know how to read that page. If this is
causing problems for anyone, please write to the list owner.
All that listing means is that the server
I notice that a lot of the tests here are on Perl 5.8.4, yet CPAN shows
that the current version of Perl is 5.8.6.
I am looking at building a version that supports the upcoming symlink
support in OpenVMS, and wanted to know which base level of Perl I should
start with.
Also which baselevel
On Mon, 31 Jan 2005, Craig A. Berry wrote:
At 7:07 AM -0500 1/31/05, John E. Malmberg wrote:
I am looking at building a version that supports the upcoming symlink
support in OpenVMS, and wanted to know which base level of Perl I
should start with.
New development should be done against
It appears that only a handful of files have multiple dots in them, and
as near as I can tell, on OpenVMS, these files are only referenced by the
CONFIGURE.COM script.
It should not be to hard to change the configure script to be able to
automatically on Alpha/I64 if those files like
The configure tests for largefile support is based on if the integer type
is native 64 bits.
On VMS, the off_t type becomes 64 bits if the _LARGEFILE macro is defined
in the test program.
Which means logically the support for largefile on VMS should be based on
the presences of off_t being
It appears that the perl source wants HAS_SOCKETPAIR defined if the host
supports SOCKETPAIR, but the configure script only knows how to define it
if d_sockpair='define'. A bit inconsistent and confusing.
Perl seems to know about the standard C routine fstatvfs() and the
non-standard fstatfs().
Craig A. Berry wrote:
At 5:38 PM -0600 1/31/05, John E. Malmberg wrote:
It appears that the perl source wants HAS_SOCKETPAIR defined if the host
supports SOCKETPAIR, but the configure script only knows how to define it
if d_sockpair='define'. A bit inconsistent and confusing.
It does seem there's
On Mon, 31 Jan 2005, Craig Berry wrote:
On Monday, January 31, 2005, John E. Malmberg wrote:
The configure tests for largefile support is based on if the integer type
is native 64 bits.
I believe 64-bit integers and large file support now work correctly
(and independently) in bleadperl
Craig A. Berry wrote:
At 12:36 PM -0600 2/1/05, John E. Malmberg wrote:
On Mon, 31 Jan 2005, Craig Berry wrote:
I believe 64-bit integers and large file support now work correctly
(and independently) in bleadperl and those changes should make it
into 5.8.7.
I do not have bleadperl
I notice that Perl is checking if the stat is being done on the NULL
device, and generating a fake stat structure.
Is there a specific version of stat() on OpenVMS that does not return
the correct data for stat?
stat() should return the correct information from either a filespec of
NLA0: or NL:
On Thu, 3 Feb 2005, Craig A. Berry wrote:
At 11:29 AM -0600 2/3/05, John E. Malmberg wrote:
On Wed, 2 Feb 2005, Craig A. Berry wrote:
At 2:41 PM -0600 2/2/05, John E. Malmberg wrote:
With OpenVMS 8.2 and when using the standard compliant stat structure,
the code handling the NULL device
On Thu, 3 Feb 2005, John E. Malmberg wrote:
I am chasing down my next problem now.
@make_ext Sys$Disk:[]miniperl.exe MMS
Making attrs (dynamic)
Descrip.MMS out-of-date with respect to MAKEFILE.PL, [--.LIB]CONFIG.PM,
[--]CONFIG.H
Cleaning current config before rebuilding
Craig A. Berry wrote:
At 3:52 PM -0600 2/3/05, John E. Malmberg wrote:
I'm pretty sure this is an MMS bug. I've never been able to whittle
it down to a really simple reproducer, but removing MMS from the
equation or removing mixed-case filenames from the equation has
always solved the problem
Craig A. Berry wrote:
When GNV gets to the point where we can use Configure rather than
configure.com and stop maintaining a separate behemoth configuration
script, that's the point where we will need to update support for GNU
make.
There are people looking at getting GNV so that it can handle
[Only subsribed to vmsperl]
On Mon, 7 Feb 2005, Michael G Schwern wrote:
On Sat, Jan 29, 2005 at 05:44:20PM -0600, Craig A. Berry wrote:
That was my first theory as well, but that's not it. It's the result of
the fact that I have a logical name bin defined, so it looks for
bin/foo there
On Sun, 6 Feb 2005, Craig A. Berry wrote:
At 7:30 PM -0500 2/4/05, John E. Malmberg wrote:
Craig A. Berry wrote:
When GNV gets to the point where we can use Configure rather than
configure.com and stop maintaining a separate behemoth configuration
script, that's the point where we
On Wed, 9 Feb 2005, Atkinson, Robert wrote:
I'm using TXT2PDF from Sanface Software. We've converted some of our disks to
ODS-5, but now find that the files generated from uppercase filenames are
created in lower case.
The user process has the PARSE_STYLE parameter set to TRADITIONAL, so
On Wed, 9 Feb 2005, Atkinson, Robert wrote:
No joy, I'm afraid!
This is the code :-
$output.=$out;
$verbose and print Changing to uppercase\n;
$output=uc($out);
open (OUT, $output) || die $producer1: couldn't open output
file $output\n;
Can you produce a
Is there some documentation on how much disk space is needed to build
and test Perl normally or in debug?
The debug build appears to be very large, this mainly seems to be from
the listing files. A debug build with out the listing files might be
easier to manage.
Also can some guidance be
Michael G Schwern wrote:
On Wed, Feb 09, 2005 at 10:30:04PM -0500, John E. Malmberg wrote:
Except won't that number change based on compiler and architecture not to
mention keeping it up to date with each version of Perl?
Is disk really that expensive?
I had to dedicate an RF72 on my VAX 4000-500
On Sun, 6 Feb 2005, Craig A. Berry wrote:
We'll have to explicitly test for lstat in configure.com, including
some sort of test that it not only is present in the CRTL but
actually works, i.e., has the underlying OS support.
According to the new features documentation for 7.3-1, link()
On Thu, 10 Feb 2005, Michael G Schwern wrote:
On Thu, Feb 10, 2005 at 07:27:43AM -0500, John E. Malmberg wrote:
I had to dedicate an RF72 on my VAX 4000-500 in order to do a debug
build. I can not afford to add more disks to my hobby system, as all
three DSSI bays are full, and I do
It appears that the VMS specific file name behavior is tied to many perl
scripts that are checking the ^O for 'VMS'.
What I would like to investigate is having a option where a symbol or
logical name could be used by the init and pre-init code in VMS.C
to change the ^O to report 'GNV'. That same
On Tue, 15 Feb 2005 [EMAIL PROTECTED] wrote:
John E. Malmberg [EMAIL PROTECTED] wrote on 02/15/2005
03:21:01 PM:
If anyone has any suggestions on an easy way to do this, please let me
know.
I'd recommend rewriting config.h before you compile perl under GNV, later
you could modify
On Tue, 15 Feb 2005, Craig Berry wrote:
On Tuesday, February 15, 2005, at 03:21PM, John E. Malmberg wrote:
I am noticing on a previous build that a number of the tests are failing
when you build with the VMS DEBUG option, and the tests use PERLSHR
instead of DBGPERLSHR. When the tests
On Tue, 15 Feb 2005, Craig Berry wrote:
On Tuesday, February 15, 2005, at 02:21PM, John E. Malmberg [EMAIL
PROTECTED] wrote:
It appears that the VMS specific file name behavior is tied to many perl
scripts that are checking the ^O for 'VMS'.
What I would like to investigate is having
Craig A. Berry wrote:
At 5:14 PM -0600 2/15/05, John E. Malmberg wrote:
On Tue, 15 Feb 2005, Craig Berry wrote:
The global PL_osname is set in S_init_predump_symbols in perl.c, which is
called from S_parse_body when a Perl script is compiled. If you put in
your own value in start-up code, I'm
Craig A. Berry wrote:
At 12:32 AM -0500 2/16/05, John E. Malmberg wrote:
$ search/exact *.c OSNAME
**
D0:[CRAIG.PERL-5_8]perl.c;1
PL_osname = savepv(OSNAME);
Some how I must have missed that one. The help of this mailing list has
been of great assistance
Craig A. Berry wrote:
At 6:21 PM -0500 2/18/05, John E. Malmberg wrote:
I am still working on getting the symlink support going but there
are significant implications to using symbolic links on OpenVMS
once the ECO kit is available.
Perl is affected by this, so here is a preview:
Symbolic links
If you chose IEEE float, the build scripts do not set everything needed to
build in IEEE floating point mode.
Unless before running MMS/MMK before running Perl you have the equivalent
of the CC command below set:
$cc :== CC/FLOAT=IEEE/IEEE=DENORM
Most of perl will be built for the default
I am trying to chase down some bugs in my last few test builds of perl.
The test [.lib.extutils.t.basic] is failing because:
ok 1 - chdir'd to Big-Dummy
Can't locate ExtUtils/MM.pm in @INC
(@INC contains: BFD_TEST_ROOT:lib ../lib lib) at
lib/MakeMaker/Test/Utils.pm line 249.
Now it appears to
The perl hack to produce a consistent dev_t st_dev will proably not work
on symbolic links and mount points.
So to support them I will have to make sure that the modules are built
with the correct structure sizes.
As the _USE_STD_STAT is likely to have the same order issues as _LARGEFILE
did, it
On Mon, 28 Feb 2005, Craig Berry wrote:
On Monday, February 28, 2005, at 02:42PM, John E. Malmberg wrote:
I am trying to chase down some bugs in my last few test builds of perl.
The test [.lib.extutils.t.basic] is failing because:
ok 1 - chdir'd to Big-Dummy
Can't locate ExtUtils/MM.pm
On Mon, 28 Feb 2005, Craig Berry wrote:
On Monday, February 28, 2005, at 02:16PM, John E. Malmberg wrote:
If you chose IEEE float, the build scripts do not set everything needed to
build in IEEE floating point mode.
Yes, they do, but you don't need to choose anything. IEEE is the default
Craig Berry wrote:
On Monday, February 28, 2005, at 02:58PM, John E. Malmberg wrote:
The perl hack to produce a consistent dev_t st_dev will proably not work
on symbolic links and mount points.
So to support them I will have to make sure that the modules are built
with the correct structure
On Tue, 1 Mar 2005, Craig A. Berry wrote:
At 4:31 PM -0600 2/23/05, John E. Malmberg wrote:
To be more precise,
The test [.t.io]fs.t will only pass when hard links {d_link} if you set
the default RMS protections to be (O:RW, G:RW, W:RW).
I think that it is a cross platform bug where
On Mon, 28 Feb 2005, Craig Berry wrote:
I think CCDEFINES might be a better name, and I would prefer to make it
a variable substitution on [.vms]descrip_mms.template rather than
producing a long, complicated macro string that someone has to pass
exactly right to MM(S|K).
If you modify the
Craig A. Berry wrote:
At 8:26 AM -0600 3/3/05, John E. Malmberg wrote:
It turns out though, that I will only have one define, as _USE_STD_STAT
implies _LARGEFILE and 32 bit GIDs, and symlinks will require _USE_STD_STAT.
Based on your other post, I am modifying my copy of CONFIGURE.COM
Craig A. Berry wrote:
At 11:40 PM -0500 3/3/05, John E. Malmberg wrote:
Building an on-the-fly program, usually called try.c, is the standard
way to go. There are quite a few examples in configure.com. There
is no reason to even run the test on VAX or on non-VAX prior to
v7.3-1.
I will see
Ken Williams wrote:
Care to try 0.09_01, which is now hitting CPAN? I've split out the
generation of command-line switches so it can easily be overridden for
VMS. So compile() might work now. link() and friends haven't been
touched, though.
When Perl is run in the GNV environment, it is
It appears that the file t/lib/vmsfspec.t is missing from the manifest.
file.
Is there a perl script that will identify all files that are present in
the unpacked directory except for the ones in the manifest or where
generated by the build procedure?
Also it appears that magic.t is leaving a
On Wed, 16 Mar 2005, John E. Malmberg wrote:
Craig A. Berry wrote:
I believe what he's done is taken Perl 5.8.6, merged PathTools 3.05
into it and run the core test suite. The before and after results
he's showing are the core test suite results before and after
upgrading PathTools
On Thu, 17 Mar 2005, Michael G Schwern wrote:
On Thu, Mar 17, 2005 at 10:37:11AM -0600, John E. Malmberg wrote:
The is_deeply test when I run it by it self is passing all 22 tests,
however one test is generating some text explaining that it succeeded.
That explanation is not being
On Thu, 17 Mar 2005, Michael G Schwern wrote:
On Thu, Mar 17, 2005 at 01:45:31PM -0600, John E. Malmberg wrote:
You'll notice that was in PathTool's [.t.lib] directory which does NOT
normally get installed. It is there so that PathTools users do not have
to upgrade or even install Test
[Only monitoring vmsperl@perl.org for replies]
Michael G Schwern wrote:
On Sat, Mar 26, 2005 at 09:35:10AM -0600, Craig A. Berry wrote:
2.) Use '_author' instead of '.author' when on VMS since a dot in a
directory name is usually invalid and always awkward.
Really? I've yet to see a problem
[Replies set to vmsperl@perl.org, as it is the only list I am subscribed to]
Michael G Schwern wrote:
On Tue, Mar 29, 2005 at 02:43:42PM -0500, [EMAIL PROTECTED] wrote:
But in any case the tests all pass on VMS with or without that patch in place.
Now that's unexpected. VMS works but Solaris
In MM_VMS.PM, there is a comment that unixify will sometimes return a
string with an off-by-one trailing null.
And what does that mean? More than one null terminator?
Do you have a reproducer for that problem?
Thanks,
-John
[EMAIL PROTECTED]
Personal Opinion Only
[only monitoring vmsperl list]
Abe Timmerman wrote:
Hi,
I still can't build bleadperl on the VAX (without /ignore=warning):
CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=GLOBALS.obj/NoList/
Define=PERL_CORE GLOBALS.C
%VCG-W-BADPSECT, The program section(psect) specified by this
On Wed, 27 Apr 2005, Craig A. Berry wrote:
At 12:58 AM -0400 4/27/05, John E. Malmberg wrote:
[only monitoring vmsperl list]
Abe Timmerman wrote:
Hi,
I still can't build bleadperl on the VAX (without /ignore=warning):
CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=GLOBALS.obj
Michael G Schwern wrote:
I'm examining the feasibility of making VMS::Filespec available to all
installations (makes testing File::Spec::VMS a whole lot easier) and
ran vms/ext/filespec.t on my OS X box. I got some failures but none
of them seem to be related to my running on Unix. They all
Michael G Schwern wrote:
On Fri, Jul 08, 2005 at 08:31:59PM -0400, [EMAIL PROTECTED] wrote:
I just ran it on IA64 with a perl 5.8.7 kit and it went ok:
Hmm. Here's the easiest of my failures to analyze:
not ok 52 - vmsify('.../'): '[]'
# Failed at ../vms/ext/filespec.t line 24
#
Michael G Schwern wrote:
On Sat, Jul 09, 2005 at 01:53:36AM -0400, John E. Malmberg wrote:
Hmm. Here's the easiest of my failures to analyze:
not ok 52 - vmsify('.../'): '[]'
# Failed at ../vms/ext/filespec.t line 24
# got '[]'
# expected '[...]'
It also should be expected
At 1:42 AM -0400 7/9/05, John E. Malmberg wrote:
Is anyone on this list using the test RMS Symbolic links SDK?
That's 8.2 only, right? I don't have any 8.2 systems, so unless it's
on the testdrive I don't have anything available to experiment with.
The SDK is for 8.2 only. It should only
These two files c2ph.pl and s2p.pl need to be updated for hard link
support before you can build perl on VMS for hard link support.
These files may be the only reason that building Perl on VMS with hard
link support requires it to be built on a disk with hard link support
enabled.
If a
This configure.com tests to see if hard links are enabled on the build
disk, and if so enables hard link support in the build.
This test is only done on 8.2 even though hard links have been available
since 7.3-1.
1. I only have been able to test with 8.2 and later at this time.
2. The dcl
This descrip_mms.template mainly has changes that Craig Berry gave me
for support of ODS-5 file specifications.
I also changed the behavior of a DEBUG build to produce more useful
listing files.
The listing options should really be separated from the DEBUG option as
a listing with machine code
This draft documentation is taylored for a perl to specifically go with
the RMS Symbolic link test SDK, so may need some changes for other purposes.
The specific information on about the Posix Compliant mode may change
with the eventual VMS release that implements it.
The Perl for the RMS
This draft documentation is taylored for a perl to specifically go with
the RMS Symbolic link test SDK, so may need some changes for other purposes.
The specific information on about the Posix Compliant mode may change
with the eventual VMS release that implements it.
The Perl for the RMS
Craig A. Berry wrote:
John,
Thanks for all your good work on this. I've sprinkled in a few
comments below, but it shouldn't be too tough to get this work
incorporated into the authoritative sources, though I can't make any
promises about when that will happen.
There are a few projects that
Craig A. Berry wrote:
At 6:43 PM -0400 7/11/05, John Malmberg wrote:
Perl_setup.com is optionally built such that it defines perl_root
based on the directory it currently resides in, as a step toward
being able to build a binary distribution kit that does not require
editing it.
It has
Craig A. Berry wrote:
At 6:48 PM -0400 7/11/05, John Malmberg wrote:
This descrip_mms.template mainly has changes that Craig Berry gave
me for support of ODS-5 file specifications.
I believe you mean files over 2GB via the _LARGEFILE definition, and
unless I'm even dottier than I think I
This difference listing shows how I am checking the DECC feature
logicals to so that the Perl script will handle pathnames in the same
way that the CRTL has been told to.
It is against the 5.8.7 perl as I had to install the pathtool patch on
Perl 5.8.6 which is now part of 5.8.7.
Use of some
These diffs are against 5.8.7.
Essentially allow these test to be run in a UNIX emulation mode.
For the 64 bit OpenVMS, what really needs to be done is that all the
test scripts need to be run in the default mode, and then in a UNIX
REPORT mode, and when the future VMS comes out with the
[EMAIL PROTECTED] wrote:
At 6:43 PM -0400 7/11/05, John Malmberg wrote:
Perl_setup.com is optionally built such that it defines perl_root based
on the directory it currently resides in, as a step toward being able to
build a binary distribution kit that does not require editing it.
I'd
1 - 100 of 663 matches
Mail list logo
