At 4:32 PM -0500 11/25/06, John E. Malmberg wrote: >John E. Malmberg wrote: >>Craig A. Berry wrote: >> >>>At 12:03 PM -0500 11/24/06, John E. Malmberg wrote: >>> >>>>In configure.com, vms/descrip.mms_template, vms/vms.c: >>>> >>>>Add the smoke and mirrors to make the perl5db.pl xterm create >>>>request create a decterm for debugging. >>> >>> >>>Interesting. I have a couple of questions but this looks very >>>promising. > >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. 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. 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). 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. > >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. >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. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
