At 05:38 PM 3/14/00 -0500, Charles Lane wrote:
>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 :)
Ah, I dunno. You can get that lovely VMS flavor from perl--scalars are just
string descriptors with a funky name, after all. :) (And arguably item list
entries, complete with type, but that's a trickier thing to deal with)
> > 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.
They're retiring the services that take null-terminated strings in favor of
ones that take descriptors. Just got announced today.
Piping and command-line redirection are nice features, and I don't see any
reason (short of the evil that is the DCL source) not to wedge 'em in.
>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.
Yep, you bet. All we need is time. Or an SDL2PM converter, I suppose.
That'd work too.
>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.
Kills some modules outright. mod_perl won't build under 7.1 because of it. :(
>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.
Having just recently used CPAN, I can say I really like it, warts and all.
Very, *very* nice. PPM's nice too, but I like the autorebuild option. (We
could make up PCSI kits for VMS perl once we get the GSMATCH issues
settled, I suppose)
Dan
----------------------------------------------------------------------------
Dan Sugalski General and VMS-specific perl training
[EMAIL PROTECTED]
Mail me for more details
