That is quite silly. See Camel.
--tom
>> > It was the perl module stuff. I can't for the *life* of me get
>> > an answer about what to do about this from the namespace czars.
>I'll run the issue by other czars.
The issues are several.
What is the namespace to use for pod related utilities and
libraries? Should it be som
I suppose one could do something like this:
% perl -e 'system {"perlsub"} qw/perlman -l/'
/usr/local/man/man1/perlsub.1
/usr/local/lib/perl5/5.6.0/pod/perlsub.pod
/home/tchrist/perldoc/bin/perlsub
--tom
>That was why I mentioned a $(LNS) Makefile macro. On unix it's
>LNS= ln -s
>and on VMS it's
>LNS= copy
>I think on NT it is either 'copy' or 'xcopy'
Oh goodness, no! That defeats the whole purpose. First, you have
update issues between binary and module. Secondly
% ls /usr/local
>> OK, I have not yet tested any of the functionality but the first
>> obvious thing is that the tar ball itself is chock full of sym links
>> which are basically unix only (there are analogs on Win NT and Mac OS,
>And now I have tested some of the functionality. perlman.pm apparently
>puts too
In case I wasn't clear, the state of affairs with the tarball
was simply a snapshot of what my current world looked like.
I was simply hoping the programs *ran*. I realize installation
is a different thing.
--tom
>OK, I have not yet tested any of the functionality but the first
>obvious thing is that the tar ball itself is chock full of sym links
>which are basically unix only (there are analogs on Win NT and Mac OS,
>and logical names serve the purpose on VMS but the former do not
>unpack with NT or Mac p
I don't know what you guys use for reading the perldocs, but
there's a snapshot of a new version out there in
http://doriath.perl.com/misc/perlman-alpha0.tar.gz
There are announcements on comp.lang.perl.misc and p5p about it
for more details.
I've only tested it on a couple different syste
>Kind of a pity perl's so late-binding in many ways. Really screws the
>potential of the optimizer. But that's part of perl's charm, I suppose.
That depends. If you are the implementing class, then $a->{fred}
is compile-time resolved (and type checked) into $a->[3] or whatnot
if there's a use f
>No wonder the OO stuff sucks cycles so badly...)
Oh, I bet there are more reasons that that!
--tom
>Pity we've seen such a slowdown in recent perls. I'm hoping efficiency
>hacks are high on the list for 5.7/5.8
I think the bloat is due to Unicode. I think the speeddowns are
because of Larry not really being so into the release process. He
hates slow, and if he noticed, he'd tweak or thwap i
>I have perl 1..4 on some CD's somewhere (from www.cdrom.com) I'd be
>willing to recompile them for a price.
I keep them on my system. That's how I sent those perl1..5 benchmarks
yesterday. It's velly nice to have.
--tom
>Now that this thread is running down, I was hoping to
>hear your motivation for asking these questions.
I'm rewriting the IPC chapter of the 3rd Edition of Programming Perl,
and wanted a feel for how much is generally applicable, and how much
isn't.
--tom
>I thought RMS got in your way if you tried that, for some reason.
No surprise. He's always getting in *somebody's* way. :-)
--tom
>Note that O_EXCL is the default under VMS Perl for all file opens; if you
>want shared access you need to ask specifically (for whcih the routines
>VMS::Stdio::vmsopen() and VMS::Stdio::vmssysopen() are provided).
Um, what does O_EXCL have to do with shared access?
>| >2. Running command in sys
I glanced through perlport and README.vms alike, yet remain unclear
as to how much VMS supports the myriad Unix-style IPCish syscall
facilities and related practices. Is there some other document
that describes this in better detail somewhere?
I was wondering whether VMS supports any of the foll
16 matches
Mail list logo
