| > 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. 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.
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. As we find better ways to absorb these sorts of one-off
Unixisms, I'm all for 'em. Failing that, I'm for making the modules more
portable. In some spots we're stuck (e.g. fork-dependent stuff), so we'll
have to do things VMSishly in parallel.
Regards,
Charles Bailey [EMAIL PROTECTED]
