Charles Bailey ([EMAIL PROTECTED]) wrote:
> | > So I think it's a worthwhile goal to get the VMS-specific bits *out*
> | > of the test suite, by making the Perl behave in as standard a fashion
> | > as practicable and useful on VMS. We can now argue the exact
> | > meaning of
> | > "practicable and useful", if anyone wants :-)
> |
> | I completely agree with this goal. Isn't it very ambitious, though?
> | Doesn't this mean, among other things, we'll have to clean up the
> | answers to that list that Tom Christiansen posted the other day?
> I also think this would be a good thing, _except for_ those areas where
> doind so would contravene an established VMS convention (most of these
> occur in spots where Perl interacts with the rest of VMS around process
> management, logicals, etc.). I'm all for making VMS Perl as accomodating
> as possible, but I think it'll be most useful to VMS users writing code if
> it retains the flavor of VMS, rather than trying to recreate a little Unix
> world.
You'll hear rather little praise of Unix from me...I left Unix for VMS
back in 1982, and never looked back :)
And I don't think you can really have the flavor of VMS in any language
like C or Perl...it takes FORTRAN or BLISS or DCL to get that genuine
VMS tanginess :)
> I was uneasy about the current time and proces status stuff, but was
> willing to bullied into it partly because it's mostly hidden and partly because
> the vmsish pragma provided an easy way to back out.
Well, we now have (for VMS 7+) unixish times from the CRTL, including
TZ support; and paths for looking for commands. No doubt more unixish
features will be added (wasn't there some discussion on comp.os.vms
recently about a new system service using 'NUL terminated strings'
instead of descriptors?)....I expect to see piping and i/o redirection
on the command line soon, if it hasn't been added already.
The point is that VMS is inexorably moving towards Unix, both in the
user-visible features and in underlying programming features.
What we *really* need is a more complete set of VMS::* modules for
handling system services....stuff like full-blown handling of
logicals, RMS calls, locking, message fetching (hint hint) etc. I
think that will help Perl be a real part of VMS much more than
currently.
> This is not to imply that mine is in any way the final word on the question,
> but to add another perspective to the discussion.
> | The fullfillment of this goal would mean that almost all of the CPAN
> | riches would be available to VMS users. As it stands now, we often see
> | posted complaints about not getting some important module to work or
> | boasts that they _have_ been able to get some particularly valuable
> | module _to_ work under VMS.
> This remains a problem, I agree. It's actually a bit frustrating because we've
> gone out of our way to include portable ways to do things in the Perl
> distribution, and many of the problems arise because someone didn't take the
> time to use them.
Well CPAN.PM *has* gotten much better WRT using portable utilies...not
because of us, but rather because of Win32 and Mac users. I'm hacking
away at it, and currently the biggest problem is the "8 level directory
depth" limitations.
Whether we can use all of CPAN or not, being able to use CPAN.pm to
manage module installation is a big, big plus. Have you tried the PPM
on Win32? The number of modules available is limited, but its capabilities
and ease of use are impressive.
--
Drexel University \V --Chuck Lane
----------------->--------*------------<[EMAIL PROTECTED]
(215) 895-1545 / \ Particle Physics [EMAIL PROTECTED]
FAX: (215) 895-5934 /~~~~~~~~~~~ [EMAIL PROTECTED]
