Craig A. Berry wrote:
At 4:32 PM -0500 11/25/06, John E. Malmberg wrote:
John E. Malmberg wrote:
Have you tried this new feature for VMS yet? It seems to work very
well for me in separating debugger I/O from application I/O.
I've committed a revised version of the patch as #29380. As submitted,
your version had trouble compiling with either -Uuselargefile or
-Duseithreads. It should be tested more in more configurations
(particularly -Uusedebugging), but at least with my most common
configuration I now get a clean build and no new test failures.
Since I build with -Uuselargefiles I am surprised that it did not work.
The descrip_mms.template was missing parenthesis for passing multiple
defines through by that method.
Here's a summary of what I changed:
There was no reason to define USE_VMS_DECTERM on the command line
since it does not need to be seen by system headers.
I could not figure out a different way of passing from configure.com to
the resulting descrip.mms.
It was much easier and more robust to use existing infrastructure for
adding linker options rather than creating a new linker options file
(although sorting out how the existing infrastructure works is not
necessarily straightforward).
I was not aware that existing infrastructure. I spent quite a bit of
time trying to find one.
Please be aware that the _ckvmssts macro is a kill switch that brings
Perl down hard when passed a non-success status, and it is usually
the wrong thing to use when implementing your own library functions
or something that will be called from a homegrown library function.
Instead, set errno and return a failure status. Also note that the
macro assumes thread context is available and thus it cannot be used
in a function that does not know its thread context.
The thread context was being passed to the functions, unless I messed
something up.
I deliberately chose a hard failure in the case of a failure of setting
up the new DECTerm. The two causes of failure that I saw where either a
programming bug, or total resource exhaustion.
I was concerned about either failure causing a silent hang in the debugger.
Even for single process debugging, I like it much better.
If you are on a DECTerm, just set the logical names:
$define TERM "xterm"
$define DISPLAY "0:0.0"
$define PERLDB_PIDS "XXX"
I have some concerns about perverting the meaning of PERLDB_PIDS in
this fashion. If what we're saying is that there is already an
existing debugger process but not one we can use, there must be a
better way to say it.
This is making a feature available on VMS that is not available on other
platforms. It is tricking the existing Perl debugger script into
thinking that a forked condition exists when it does not.
If a general method were to be made available, it could be used for
other platforms. As even in a non-forked debugger case, it is a pain
when debugger I/O and application I/O.
I wanted to only make changes to the VMS specific code, but apparently
because OpenVMS does not really fork(), I needed to make some changes to
the perl debugger script.
And then run the debugger on the script of your choice. A new
DECTerm should be created, which you can resize as needed where all
the debugging commands are executed and results displayed.
When you quit the debugger, the DECTerm window is automatically closed.
Still sounds very promising, and now that I've got it to build, I'll try it.
Any results?
I have not had time to debug the why the Perl debugger test is failing
to redirect the input to a script. I learned a lot about how the perl
debugging program works from debugging this new feature, so I will try
to look into it.
-John
[EMAIL PROTECTED]
Personal Opinion Only
