Re: extend perl debugger

hi,

i've now trying to run your example but there is one problem: i cannot 
set $DB::trace to 4!
when i execute "$DB::trace |= 4;" as comand in the debugger, it doesn't 
change the trace value(because the eval block saves the $DB::trace 
content before evaluating "$DB::trace |= 4;" and reset the content saved 
in $DB::trace after evaluating)!
how can i set the $DB::trace to 4?

thx mseele

Joe McMahon wrote:

> On Tue, 22 Nov 2005, Michael Seele wrote:
>
>> hi,
>>
>> i write on a (java) gui for the perl debugger and have a problem: 
>> when i use the perl debugger i can suspend the execution with CTRL+C. 
>> i talk over a socket with the perl debugger process and the problem 
>> is that i can't send CTRL+C from the java programm to the perl 
>> process. for this reason i should extend the perl debugger: i will 
>> send a special command(e.g. SUSPEND) to the perl debugger and the 
>> debugger should execute the method bundeled with $SIG{INT}(catch() 
>> method).
>> is this possible?
>> i think i can override the DB method of the debugger and check for 
>> the special command. after checking i would like to call the original 
>> DB method. here are my little try:
>>
>> PERL5DB={ package DB; our @ISA='DB'; sub DB { } }
>>
>> but when i doe this i got errors everytime. can you help my how to 
>> override the debugger!?
>
>
> Are you trying to catch the program in mid-execution and halt it? That 
> might take a bit of diddling about to do, since the debugger's not 
> reading from its input filehandle during continuous execution. A 
> watchfunction() could possibly check for input pending on the 
> debugger's input filehandle using 3-argument select() and interrupt 
> execution based on that (it can set $DB::single, which drops the 
> debugger back into single-step mode).
>
> Normally this would be a bad idea (if the user started typing 
> anything, the program would suddenly stop running), but since the 
> GUI's controlling access to the debugger, it should work fine. Here's 
> a basic cut at doing this; you will probably have to tweak it a bit to 
> make sure that it works properly.
>
> Just before going into continuous execution, execute "$DB::trace |= 
> 4;" (sending this to the debugger directly is as good as any way to do 
> it). This tells the debugger to enable the watchfunction.
>
> In your .perldb (or perldb.ini, on Windows), add this:
>
> sub watchfunction {
>   my $rin = ''; my $rout;
>   vec($rin,fileno(DB::IN),1)=1;
>
>   # Wait 5 milliseconds for input to be present.
>   $DB::single |= 1
>     if select($rout=$rin, undef, undef, 0.05);
> }
>
> This will define the watchfunction for you (note that this way you 
> need no mods to the debugger). Here's how it goes:
>
> Normally, you're executing without the watchfunction (the program's 
> not running continuously). When your interface wants to start 
> continuous execution (the 'c' command, most likely; possibly if you 
> want to be able to interrupt the execution of code entered by the 
> user), set $DB::trace to turn on the watchfunction, and then issue the 
> 'c' command. Before each statement, the watchfunction looks to see if 
> anything is queued up on DB::IN, and sets $DB::single (which stops 
> continuous execution), dropping you back into single-step mode, and 
> giving you control again.
>
> You don't have to create the watchfunction in .perldb; you can 
> actually send it to the debugger as one long line and define it that way.
>
> I note that the select() documentation notes that this may not work 
> for buffered filehandles, but as I recall, we unbuffer DB::IN, so this 
> will probably work fine. I can't guarantee it, but this is probably 
> your best angle of attack to get things in place with the minimum fuss.
>
>  --- Joe M.
>
>

-- 
G & H Softwareentwicklung GmbH     Tel.: +49(0)7451/53706-20
Robert-Bosch-Str. 23               Fax:  +49(0)7451/53706-90
D-72160 Horb a.N.                  http://www.guh-software.de