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: New member, and a patch for File::Spec::VMS
At 12:15 AM +0200 7/23/04, Richard Levitte - VMS Whacker wrote: Hello, Welcome back. [ File::Spec-splitpath problems snipped ] As can be seen, there are things that don't really happen, like [BAR.COOKIE.BANANA.--] only got changed to [BAR.COOKIE.-], not [BAR] (basically, the current VMS.pm doesn't handle multiple dashes very well). Also, I noticed that things like FOO.00] would be converted to FOO], which I think is an absolute no-no (you CAN have a 00.DIR), only [00.][, .][00] and [00. should be reduced. While I'm at it, and should be changed to [ and ]. My patch (attached as VMD.pm.diff, produced with diff -u) makes the above errors go away. I've based the things I do on a decade of experience with VMS, having hacked similar things a long time ago in GNU emacs and so on. Excellent. I've long thought that section of code looked crufty and needed an overhaul. Just for the record, what version of Perl are you using? Did you rerun the entire test suite after your patch and see any failures? I will run some tests in any case just to make sure nothing is depending on the broken behavior. -- Craig A. Berry mailto:[EMAIL PROTECTED] ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
Anyone still using OpenVMS/VAX 6.2?
At work, our application still runs on VMS 6.2 on VAX systems. I installed perl 5.8.0 last year and don't remember having any problems. Alas, I must have deleted the source tree after a successful build because I can't find them or any traces of the build other than the PERL_ROOT directory tree. Anyway, I recently found SIMH (http://simh.trailing-edge.com/) and decided to give it a workout. I figured I'd install 6.2 first since that's the version I'm familiar with and maybe later I could move to 7.3. A new VMS install needs a new perl install so I figured I'd try to build 5.8.4. I hit errors during the build on both SIMH and the real VAXen at work. The first problem I hit during the build was an attempt to use ioctl(SIOCATMARK). VMS 6.2 doesn't support ioctl(). I ended up writing a vms_siocatmark() function using a QIO to plug into [.ext.io]io.xs. The second problem was with Time::HiRes. Although VMS 6.2 does not have many (if any) of the functions needed by this module, it's included in the default list of modules to build. I reconfigured without this module but the test phase still tried to reference it. Lastly, several tests failed. MMS TEST doesn't reveal much information about failures so I tried using harness. There were several things along the lines of 'unrecognized command verb \ECHO\' but also some real failures. op/pack failed with what appears to be a floating point overflow. Several Tie::File, Math::BigInt and Math::BigRat tests failed. I can post the errors from the build logs if anyone is interested. Does anyone know if any of these errors are serious? Are they worth looking into or am I the last diehard still trying to use perl on VAX/VMS 6.2?
Re: New member, and a patch for File::Spec::VMS
In message [EMAIL PROTECTED] on Thu, 22 Jul 2004 17:51:41 -0500, Craig A. Berry [EMAIL PROTECTED] said: craigberry At 12:15 AM +0200 7/23/04, Richard Levitte - VMS Whacker wrote: craigberry Hello, craigberry craigberry Welcome back. back? Was I ever on this list before? Or oh, do you mean to the VMS world? Been there the whole time, just been silent for a while :-). craigberry Excellent. I've long thought that section of code looked craigberry crufty and needed an overhaul. Just for the record, what craigberry version of Perl are you using? 5.8.1 (the one that comes with the VMS Freeware CD 6.0). craigberry Did you rerun the entire test suite after your patch and craigberry see any failures? I will run some tests in any case just craigberry to make sure nothing is depending on the broken behavior. Uhmm, *cough*, I didn't run the Perl tests, actually... heh. I'm an oldie when it comes to VMS, but when it comes to hacking Perl internals and the proper procedures thereoff, I'm a bit new... I'll see what I can do, but I'd rather avoid a rebuild if possible... - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte | http://richard.levitte.org/ | Tunnlandsv. 52 Levitte Programming | http://www.lp.se/ | S-168 36 Bromma T: +46-708-26 53 44 | | SWEDEN Price, performance, quality... choose the two you like
Re: New member, and a newer patch for File::Spec::VMS
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 all consistent with proper directory mangling on
VMS. There will be more patches, one for each function I correct...
Cheers,
Richard
-
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
--
Richard Levitte | http://richard.levitte.org/ | Tunnlandsv. 52
Levitte Programming | http://www.lp.se/ | S-168 36 Bromma
T: +46-708-26 53 44 | | SWEDEN
Price, performance, quality... choose the two you like
--- /usr/share/perl/5.8.4/File/Spec/VMS.pm 2004-05-11 16:59:22.0 +0200
+++ VMS.pm 2004-07-23 01:58:24.0 +0200
@@ -155,16 +155,35 @@
else { return vmsify($path); }
}
else {
- $path =~ s/([\[])00\./$1/g; # [00.foo == [foo
- $path =~ s/([^-]+)\.(\]\[|)?00([\]\])/$1$3/g; # foo.00] == foo]
- $path =~ s-\]\[--g; $path =~ s///g;# foo.][bar == foo.bar
- 1 while $path =~ s{([\[-])\.-}{$1-}; # [.-.- == [--
- $path =~ s/\.[^\[\.]+\.-([\]\])/$1/;# bar.foo.-] == bar]
- $path =~ s/([\[])(-+)/$1 . \cx x length($2)/e; # encode leading '-'s
- $path =~ s/([\[\.])([^\[\.\cx]+)\.-\.?/$1/g;# bar.-.foo == foo
- $path =~ s/([\[])(\cx+)/$1 . '-' x length($2)/e; # then decode
- $path =~ s/^[\[\]]{2}//;# []foo == foo
- return $path;
+ $path =~ tr//[]/; # and== [ and ]
+ $path =~ s/\]\[\./\.\]\[/g; # ][. == .][
+ $path =~ s/\[00\.\]\[/\[/g; # [00.][== [
+ $path =~ s/\[00\./\[/g; # [00. == [
+ $path =~ s/\.\]\[00\]/\]/g; # .][00]== ]
+ $path =~ s/\.\]\[/\./g; # foo.][bar == foo.bar
+ while ($path =~ s/([\[\.])(-+)\.(-+)([\.\]])/$1$2$3$4/) {}
+ # That loop does the following
+ # with any amount of dashes:
+ # .-.-. == .--.
+ # [-.-. == [--.
+ # .-.-] == .--]
+ # [-.-] == [--]
+ while ($path =~ s/([\[\.])[^\]\.]+\.-(-+)([\]\.])/$1$2$3/) {}
+ # That loop does the following
+ # with any amount (minimum 2)
+ # of dashes:
+ # .foo.--. == .-.
+ # .foo.--] == .-]
+ # [foo.--. == [-.
+ # [foo.--] == [-]
+ #
+ # And then, the remaining cases
+ $path =~ s/\.[^\]\.]+\.-\./\./g;# .foo.-. == .
+ $path =~ s/\[[^\]\.]+\.-\./\[/g;# [foo.-. == [
+ $path =~ s/\.[^\]\.]+\.-\]/\]/g;# .foo.-] == ]
+ $path =~ s/\[[^\]\.]+\.-\]/\[\]/g; # [foo.-] == []
+ $path =~ s/\[\]//; # []==
+ return $path;
}
}
Re: New member, and a newer patch for File::Spec::VMS
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 all consistent with proper directory mangling on VMS. There will be more patches, one for each function I correct... While you are in the area, I submitted a patch to 5.8.4 release candidate that gets Perl to almost honor the C feature logicals. This is apparently needed to build the version of GTK+ that is used for Mozilla. To make the patch complete, the File::Spec::VMS needs to also be modified to look at what the C feature logicals were before Perl started, and and if they were the set to (IIRC) DECC$FILENAME_UNIX_ONLY or DECC$FILENAME_REPORT_UNIX, do the parse like it was UNIX, and display the filespec as if it were UNIX. I do not know enough about Perl programming to make those changes myself. -John [EMAIL PROTECTED] Personal Opinion Only
Re: New member, and a newer patch for File::Spec::VMS
In message [EMAIL PROTECTED] on Thu, 22 Jul 2004 20:38:49 -0400, John E. Malmberg [EMAIL PROTECTED] said: wb8tyw Richard Levitte - VMS Whacker wrote: wb8tyw Hmm, I found a small bug. A file spec. []FOO wasn't reduced wb8tyw to FOO by my changes. The attached patch contains one more wb8tyw line that takes care of that particular thing. wb8tyw wb8tyw I'm going through the rest of File::Spec::VMS right now, wb8tyw finding more things that aren't at all consistent with wb8tyw proper directory mangling on VMS. There will be more wb8tyw patches, one for each function I correct... wb8tyw wb8tyw While you are in the area, I submitted a patch to 5.8.4 release wb8tyw candidate that gets Perl to almost honor the C feature wb8tyw logicals. 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 have access to when I got a little more time. wb8tyw This is apparently needed to build the version of GTK+ that is wb8tyw used for Mozilla. wb8tyw wb8tyw To make the patch complete, the File::Spec::VMS needs to also wb8tyw be modified to look at what the C feature logicals were before wb8tyw Perl started, and and if they were the set to (IIRC) wb8tyw DECC$FILENAME_UNIX_ONLY or DECC$FILENAME_REPORT_UNIX, do the wb8tyw parse like it was UNIX, and display the filespec as if it were wb8tyw UNIX. Oh... Hmm, feels a bit hairy, but can probably be done by calling some appropriate function in the proper places... I've got other things on my platter right now, and all I'm currently after is to have File::Spec::VMS behave properly with VMSy file specs. wb8tyw I do not know enough about Perl programming to make those wb8tyw changes myself. Hmm, if I'm gonna get involved at a deeper level, it will take some monetary contribution. I currently live on bare minimums (the consulting business is harsch right now), so I only spend time on my needs... Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte | http://richard.levitte.org/ | Tunnlandsv. 52 Levitte Programming | http://www.lp.se/ | S-168 36 Bromma T: +46-708-26 53 44 | | SWEDEN Price, performance, quality... choose the two you like
Quick patch for File::Spec::VMS::splitdir
The following script gave quite ugly results. Some perfectly legal
names got split up badly. I admit that the test was very specially
targeted to the things I could see *would* go wrong.
-- SPLITDIR-TEST.PL --
use File::Spec;
foreach my $d (
FOO.BAR,
[FOO.BAR],
FOO-.--BAR,
FOO---.-.BAR,
FOO.---.BAR,
FOO---BAR,
FOO.][00.BAR],
) {
print splitdir(,$d,) == (, join(, ,File::Spec-splitdir($d)),)\n;
}
--
$ perl splitdir-test.pl
splitdir(FOO.BAR) == (FOO, BAR)
splitdir([FOO.BAR]) == (FOO, BAR)
splitdir(FOO-.--BAR) == (FOO-, -, -BAR)
splitdir(FOO---.-.BAR) == (FOO-, --, -, BAR)
splitdir(FOO.---.BAR) == (FOO, -, --, BAR)
splitdir(FOO---BAR) == (FOO-, --BAR)
splitdir(FOO.][00.BAR]) == (FOO, 00, BAR])
--
Yup, dashes that are parts of names (like FOO---) get (incompletely,
for what was intended) split up, and .---. didn't get entirely split
up. Also, in the last split, 00 should not be there.
The attached patch fixes those problems, and possibly more. The
result is much more what I would expect:
--
$ perl -IUSER:[LEVITTE.WRK.PERL-HACKS] splitdir-test.pl
splitdir(FOO.BAR) == (FOO, BAR)
splitdir([FOO.BAR]) == (FOO, BAR)
splitdir(FOO-.--BAR) == (FOO-, --BAR)
splitdir(FOO---.-.BAR) == (FOO---, -, BAR)
splitdir(FOO.---.BAR) == (FOO, -, -, -, BAR)
splitdir(FOO---BAR) == (FOO---BAR)
splitdir(FOO.][00.BAR]) == (FOO, BAR])
--
Cheers,
Richard
-
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
--
Richard Levitte | http://richard.levitte.org/ | Tunnlandsv. 52
Levitte Programming | http://www.lp.se/ | S-168 36 Bromma
T: +46-708-26 53 44 | | SWEDEN
Price, performance, quality... choose the two you like
--- File/Spec/VMS.pm2004-07-23 02:41:53.0 +0200
+++ VMS.pm 2004-07-23 02:41:15.0 +0200
@@ -370,7 +370,19 @@
sub splitdir {
my($self,$dirspec) = @_;
-$dirspec =~ s/\]\[//g; $dirspec =~ s/\-\-/-.-/g;
+$dirspec =~ tr//[]/; # and== [ and ]
+$dirspec =~ s/\]\[\./\.\]\[/g; # ][. == .][
+$dirspec =~ s/\[00\.\]\[/\[/g; # [00.][== [
+$dirspec =~ s/\[00\./\[/g; # [00. == [
+$dirspec =~ s/\.\]\[00\]/\]/g; # .][00]== ]
+$dirspec =~ s/\.\]\[/\./g; # foo.][bar == foo.bar
+while ($dirspec =~ s/(^|[\[\\.])\-(\-+)($|[\]\\.])/$1-.$2$3/g) {}
+ # That loop does the following
+ # with any amount of dashes:
+ # .--. == .-.-.
+ # [--. == [-.-.
+ # .--] == .-.-]
+ # [--] == [-.-]
$dirspec = [$dirspec] unless $dirspec =~ /[\[]/; # make legal
my(@dirs) = split('\.', vmspath($dirspec));
$dirs[0] =~ s/^[\[]//s; $dirs[-1] =~ s/[\]]\Z(?!\n)//s;
Re: Quick patch for File::Spec::VMS::splitdir
All right, that concludes what I had enough energy for tonight. The rest looks like it will take some more thinking to check, and honestly, at 3am, I'm not up for it. I'll be back :-). Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte | http://richard.levitte.org/ | Tunnlandsv. 52 Levitte Programming | http://www.lp.se/ | S-168 36 Bromma T: +46-708-26 53 44 | | SWEDEN Price, performance, quality... choose the two you like
Re: New member, and a newer patch for File::Spec::VMS
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 have access to when I got a little more time. DEC C V6.4-005 is the current C compiler. Perl 5.8.4 will build on VAX 7.3, but IIRC will only pass about 68% of the tests. It looks like a lot of the problems are in multi-byte character support. wb8tyw I do not know enough about Perl programming to make those wb8tyw changes myself. Hmm, if I'm gonna get involved at a deeper level, it will take some monetary contribution. I currently live on bare minimums (the consulting business is harsch right now), so I only spend time on my needs... I have a work-a-round, a hacked version of a different .pm file and changing a logical name for the perl libraries to find it before it finds the Perl ones. My main motivation is that I am trying to find time to build Mozilla from sources, and discovered that a hacked version of Perl was previously needed. I have not yet had time to try to build GTK+ with Perl 5.8.4. I have also started working again on getting rsync to run on OpenVMS. It requires replacing a few fork()ing things with some threads. At this point I have a barely functional client that can pull down the daily rsync updates. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. Hope the consulting business picks up over there. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Anyone still using OpenVMS/VAX 6.2?
At 7:10 PM -0400 7/22/04, Thomas Pfau wrote:
At work, our application still runs on VMS 6.2 on VAX systems. I installed perl
5.8.0 last year and don't remember having any problems. Alas, I must have deleted
the source tree after a successful build because I can't find them or any traces of
the build other than the PERL_ROOT directory tree.
Anyway, I recently found SIMH (http://simh.trailing-edge.com/) and decided to give it
a workout. I figured I'd install 6.2 first since that's the version I'm familiar
with and maybe later I could move to 7.3. A new VMS install needs a new perl install
so I figured I'd try to build 5.8.4. I hit errors during the build on both SIMH and
the real VAXen at work.
5.8.5 came out a couple of days ago but is unlikely to help with your
situation as no recent testing I'm aware of has been done on VAX or
on pre 7.x VMS.
The first problem I hit during the build was an attempt to use ioctl(SIOCATMARK).
VMS 6.2 doesn't support ioctl(). I ended up writing a vms_siocatmark() function
using a QIO to plug into [.ext.io]io.xs.
Good golly. That sounds like a seriously useful bit of backporting
for folks in a similar situation. It shouldn't be too hard to
determine from the appropriate appendix to the CRTL manual what
particular #ifdefs should go around this code to get it into the
sources.
The second problem was with Time::HiRes. Although VMS 6.2 does not have many (if
any) of the functions needed by this module, it's included in the default list of
modules to build. I reconfigured without this module but the test phase still tried
to reference it.
That should be a simple matter of adding lines similar to the
following in the BEGIN block of the test:
require Config; import Config;
if ($Config{'extensions'} !~ /\bTime\/HiRes\b/) {
print 1..0 # Skip: Time::HiRes was not built\n;
exit 0;
}
Lastly, several tests failed. MMS TEST doesn't reveal much information about
failures so I tried using harness.
harness is the canonical unixy way to get more details. The
idiomatic VMS way (documented in README.vms) is, for example:
$ @[.vms]test .exe -v [.op]pack.t
I hope they haven't broken harness on VMS since the last time I tried it.
There were several things along the lines of 'unrecognized command verb \ECHO\' but
also some real failures. op/pack failed with what appears to be a floating point
overflow. Several Tie::File, Math::BigInt and Math::BigRat tests failed. I can post
the errors from the build logs if anyone is interested.
Does anyone know if any of these errors are serious? Are they worth looking into or
am I the last diehard still trying to use perl on VAX/VMS 6.2?
Tie::File is heavily dependent on POSIX-compliant seek()
functionality in the CRTL. It's totally unsurprising that this
doesn't work in a version of VMS that is, what, 10 or 12 years old
and long since off the vendor's support matrix. As far as I know, no
other core packages depend on Tie::File, so if you don't intend to use it
explicitly, you should be fine.
The various math-related problems most likely come from D_FLOAT not
representing the floating point ranges that tests expect. Whether
this will cause you problems really depends on what sort of floating
point work you may be doing. You can try configuring with G_FLOAT
(instructions in README.vms) and see if that makes a difference. I
believe I was supposed to make G_FLOAT the default on VAX, but I
either got busy, forgot, decided I shouldn't without the ability to
test it, or all of the above.
--
Craig A. Berry
mailto:[EMAIL PROTECTED]
... getting out of a sonnet is much more
difficult than getting in.
Brad Leithauser
Re: Anyone still using OpenVMS/VAX 6.2?
Craig A. Berry wrote:
At 7:10 PM -0400 7/22/04, Thomas Pfau wrote:
At work, our application still runs on VMS 6.2 on VAX systems. I installed perl 5.8.0
last year and don't remember having any problems. Alas, I must have deleted the
source tree after a successful build because I can't find them or any traces of the
build other than the PERL_ROOT directory tree.
Anyway, I recently found SIMH (http://simh.trailing-edge.com/) and decided to give it a workout. I figured I'd install 6.2 first since that's the version I'm familiar with and maybe later I could move to 7.3. A new VMS install needs a new perl install so I figured I'd try to build 5.8.4. I hit errors during the build on both SIMH and the real VAXen at work.
5.8.5 came out a couple of days ago but is unlikely to help with your
situation as no recent testing I'm aware of has been done on VAX or
on pre 7.x VMS.
That's what I was afraid of. I'm really surprised it built and tested
as clean as it did.
The first problem I hit during the build was an attempt to use ioctl(SIOCATMARK). VMS 6.2 doesn't support ioctl(). I ended up writing a vms_siocatmark() function using a QIO to plug into [.ext.io]io.xs.
Good golly. That sounds like a seriously useful bit of backporting
for folks in a similar situation. It shouldn't be too hard to
determine from the appropriate appendix to the CRTL manual what
particular #ifdefs should go around this code to get it into the
sources.
As far as I can tell, none of the tests exercise this function. All I
know is it compiled clean. I've never used out-of-band data on a TCP
socket before so I don't know if I can come up with a good test for
this. It might be better to just make the routine unsupported on VMS
pre-7.x unless someone needs it and can write a good test.
The second problem was with Time::HiRes. Although VMS 6.2 does not have many (if any) of the functions needed by this module, it's included in the default list of modules to build. I reconfigured without this module but the test phase still tried to reference it.
That should be a simple matter of adding lines similar to the
following in the BEGIN block of the test:
require Config; import Config;
if ($Config{'extensions'} !~ /\bTime\/HiRes\b/) {
print 1..0 # Skip: Time::HiRes was not built\n;
exit 0;
}
I'll plug that in and see if it works.
Lastly, several tests failed. MMS TEST doesn't reveal much information about failures so I tried using harness.
harness is the canonical unixy way to get more details. The
idiomatic VMS way (documented in README.vms) is, for example:
$ @[.vms]test .exe -v [.op]pack.t
I hope they haven't broken harness on VMS since the last time I tried it.
It seemed to be spitting out some errors where MMK TEST would just say
'FAILED'.
There were several things along the lines of 'unrecognized command verb \ECHO\' but
also some real failures. op/pack failed with what appears to be a floating point
overflow. Several Tie::File, Math::BigInt and Math::BigRat tests failed. I can post
the errors from the build logs if anyone is interested.
Does anyone know if any of these errors are serious? Are they worth looking into or am I the last diehard still trying to use perl on VAX/VMS 6.2?
Tie::File is heavily dependent on POSIX-compliant seek()
functionality in the CRTL. It's totally unsurprising that this
doesn't work in a version of VMS that is, what, 10 or 12 years old
and long since off the vendor's support matrix. As far as I know, no
other core packages depend on Tie::File, so if you don't intend to use it
explicitly, you should be fine.
I think VMS 6.2 is 11 years old (good guess!). Last year we went
looking into this and found it was 10 so it's at least nearing 11.
The various math-related problems most likely come from D_FLOAT not
representing the floating point ranges that tests expect. Whether
this will cause you problems really depends on what sort of floating
point work you may be doing. You can try configuring with G_FLOAT
(instructions in README.vms) and see if that makes a difference. I
believe I was supposed to make G_FLOAT the default on VAX, but I
either got busy, forgot, decided I shouldn't without the ability to
test it, or all of the above.
I think some of the harness output seems to support this. Maybe I'll
leave a G_FLOAT build running over the weekend and see what happens.
I'll dig into the pack problem a little and see what I can come up
with. That one's pretty important to me.
Re: Anyone still using OpenVMS/VAX 6.2?
At 10:43 PM -0400 7/22/04, Thomas Pfau wrote: I'll dig into the pack problem a little and see what I can come up with. That one's pretty important to me. There's a high probability the pack problem is floating point related as well. -- Craig A. Berry mailto:[EMAIL PROTECTED] ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
Re: New member, and a patch for File::Spec::VMS
At 1:27 AM +0200 7/23/04, Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Thu, 22 Jul 2004 17:51:41 -0500, Craig A. Berry [EMAIL PROTECTED] said: craigberry Welcome back. back? Was I ever on this list before? Or oh, do you mean to the VMS world? Been there the whole time, just been silent for a while :-). There are a number of posts from you from the archive in the 1998-2000 time frame. If you were hoping to reappear incognito, sorry to blow your cover. None of the other Richard Levittes I know are VMS Whackers, so it must be you ;-). craigberry Did you rerun the entire test suite after your patch and craigberry see any failures? Uhmm, *cough*, I didn't run the Perl tests, actually... heh. I'm an oldie when it comes to VMS, but when it comes to hacking Perl internals and the proper procedures thereoff, I'm a bit new... I'll see what I can do, but I'd rather avoid a rebuild if possible... If you still have your build directory, MMS TEST should not rebuild anything but will rerun the entire test suite, no internals hacking involved. At 2:02 AM +0200 7/23/04, Richard Levitte - VMS Whacker wrote: I'm going through the rest of File::Spec::VMS right now, finding more things that aren't at all consistent with proper directory mangling on VMS. There will be more patches, one for each function I correct... This is goodness. If it's possible at the end of your development cycle to do a final diff -pu on the whole thing, it will make testing and integration easier. At 2:49 AM +0200 7/23/04, Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Thu, 22 Jul 2004 20:38:49 -0400, John E. Malmberg [EMAIL PROTECTED] said: wb8tyw While you are in the area, I submitted a patch to 5.8.4 release wb8tyw candidate that gets Perl to almost honor the C feature wb8tyw logicals. 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 have access to when I got a little more time. Detailed bug reports and (especially) patches are always welcome. I don't have access to any VAXen, and whenever I think about getting an emulator up and running I think of about 30 other things I should be doing instead. The result is that VAX builds don't (and probably never will) get tested unless someone other than me does it. wb8tyw To make the patch complete, the File::Spec::VMS needs to also wb8tyw be modified to look at what the C feature logicals were before wb8tyw Perl started, and and if they were the set to (IIRC) wb8tyw DECC$FILENAME_UNIX_ONLY or DECC$FILENAME_REPORT_UNIX, do the wb8tyw parse like it was UNIX, and display the filespec as if it were wb8tyw UNIX. Oh... Hmm, feels a bit hairy, but can probably be done by calling some appropriate function in the proper places... Or not calling them as the case may be. I think this would mostly be handled by not calling VMS::Filespec::vmsify so that filespecs remain in unix format. I have a feeling there is quite a bit more to this. The assumption for the last 10 years of Perl on VMS is that filespecs in unix format may cause problems, but filespecs in VMS format are always safe, so when in doubt convert to VMS format. I think that when we start trying to preserve unix format we are going to break some things inherent in those old assumptions. Nothing insurmountable, just some work to do, which I hope someone finds time and motivation for. wb8tyw I do not know enough about Perl programming to make those wb8tyw changes myself. Hmm, if I'm gonna get involved at a deeper level, it will take some monetary contribution. My contributions to open source come in the form of patches, not dollars, but I do wish you well. In case anyone doesn't know, Richard was porting GNU utilities to VMS for years before the GNV project was even thought of. I do wish hp would hire him to accelerate what's going on at http://sourceforge.net/projects/gnv. - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Craig A. Berry mailto:[EMAIL PROTECTED] ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
