Peter Prymmer wrote:
: Much (not all) of this information sounds like it might do better
: to reside in a non pragmatic module with a name like VMS::Config
: or VMS::FeatureSet; rather than the pragmatic module intended to
: alter run time behavior of a script and its loaded modules.
It also needs to always be a part of the VMS Perl distribution after
it gets created.
These are needed to fix things that are "broken" now and being worked
around.
I have a lot of "fixes" that depend on a few Perl scripts and a few
tests having access to a subset of this information.
It is just simply just as easy to expose close to the "raw" interface as
to allow access to only the values that I need for the next set of
changes that I have in my queue.
There are applications now that are starting to use a modified VMS Perl
5.8.6 that already have my changes in them to support UNIX compatibility
mode and ODS-5 volumes., and what I am trying to do is get those changes
into blead Perl so that those of you that understand Perl much better
than I do can help with the maintenance and enhancements, and that I do
not have to re-apply all those changes to a future version of Perl.
I have a lot of irons in the fire right now, and I am trying to get this
to a point where I can move it to the backburner.
Right now, I am basically redoing the functional changes to blead that I
have already done to local copies of Perl 5.8.6 and 5.8.7. I would
estimate that I am now to about the 50% mark.
Craig A. Berry wrote:
<snip>
I would suggest figuring out how to get them all implemented as the
first challenge and then how to access them from Perl as the second.
For a number of reasons, a pragmatic module may or may not be the way
to go.
I already pretty much know how to implement most of them, and how to
get Perl to access them from copying other things.
What I am not sure of is where to put them.
There are some things you should be aware of about how pragmas work.
A pragma is a way of passing hints to the Perl compiler at the time
it is compiling your script. It is also lexically scoped, which
means that a value set in an inner scope needs to revert to the outer
scope value when you exit the inner scope.
A pragma implementation is worth considering for the CRTL features,
though an extension might be just as good. For merely fetching
global values like DCL command-line length, they should be made
available in %Config if they are set at build time, or via some
extension if they can vary at run-time. In some cases, an
appropriate extension namespace may already exist. For example, if
something is available from the native $GETSYI, it belongs in
VMS::System, if from $GETJPI then VMS::Process.
I looked at those a bit, they are not in the blead or main Perl
distribution. These values/methods need to be available to all Perl
programs that run on VMS.
There are many other changes that I have to do to get UNIX and ODS-5
filenames to work properly. And the routines that I need to make those
changes in need to be able to access some of this information.
I do not know how to add items to %Config.
The other methods are:
vmsish::decc_feature_get_index($name);
vmsish::decc_feature_get_name($index);
vmsish::decc_feature_get_value($name, $mode);
vmsish::decc_feature_set_value($name, $mode, $value);
vmsish::decc_feature_deed_to_child($value);
These need to be visible to many of the modules that are doing VMS
specific file name manipulation, or testing POSIX compliance.
Think of these as more primitive operations that allow modules like
pathtools, filespec, and cwd to work more correctly than methods that
the typical Perl script would need to know about. In fact I would
recommend that most Perl scripts not use these unless they had no other
choice.
For practical use, there needs to be other methods on top of these to
make them more usable.
Right now where a Perl script is doing a test for ($^O eq 'VMS'), it may
need to be making a test of to see if also UNIX filename mode is active.
If so, it may not want to take the VMS behavior.
Determining if UNIX filename mode is active from these decc_feature
calls is not something that you would want in every program that is
currently testing for VMS specific behavior, so another layer on top
of these will be needed, most likely that would reside in pathtools or
filespec, and presented as an additional method.
It is also easier to code those guidelines in a Perl Module than to code
them into VMS.C, so that if someone needs a specific combination, but
does not care about others, it is easy to change. Especially when new
options get added.
The decc_features do not belong in any of those modules though as they
control more than just the file system behavior.
These are actually easy to fallback to for use if the VMS.C module
does not yet override them, as the decc_feature_get_value/set_value just
need to set/read logical names.
vmsish::dcl_present;
Needs to be a run time value of course. Fall back value of true if
VMS.C does not override.
vmsish::dcl_extended_syntax($value);
Needs to be a run time set/get, fallback value of false if VMS.C does
not override.
vmsish::dcl_command_line_length;
vmsish::dcl_command_file_line_length;
vmsish::dcl_symbol_value_length;
vmsish::dcl_token_length;
vmsish::logical_name_value_length;
vmsish::vms_pathname_length;
vmsish::unix_pathname_length;
vmsish::vms_filename_length;
vmsish::wide_filename_length;
These can be config time values. Is there some appropriate
uninitialized equivalent config values that I could set?
Or can someone help me with adding them to the config?
The disadvantage of adding them to config is that unless I find a way to
back door the configure process, I have to completely rebuild Perl when
I implement support for a larger value.
It also may be easier to track what is the current supported value for
these items for a given platform in VMSISH.H or VMS.C
But configure.com can read those files if need be :-).
-John
[EMAIL PROTECTED]
Personal Opinion Only
