$SIG{__DIE__} = sub { # a die callback
TELL_EPIC_TO_BREAK_ON("this file", 23);
my $dummy = 0; # line 23 would be right here, the debugger would break on this line
#
}
the only missing piece is : TELL_EPIC_TO_BREAK_ON($file,$line);
I see that there is a file :
.metadata/.plugins/org.epic.debug/epic_breakpoints.pm that has such a method !
Thanks !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The traditional way to embed breakpoints in Perl code is to insert the line $DB::single=1; before the statement you want to break on. This will indeed cause the perl5db.pl debugger to pause, however, EPIC will let it continue, seeing that it knows of no such breakpoint. The reason for this continuation is that not every pause of perl5db.pl is a real user-defined breakpoint (perl5db.pl also pauses on loading files, in which case EPIC has to insert the local breakpoints and let it run on).
In short, there is currently no way to break programmatically without (also) setting a breakpoint on the following line in the EPIC editor. I'm also not sure how well breakpoints in anonymous blocks are handled (I know for sure that you cannot step into such blocks using EPIC).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, I got it wrong. The problem I described is limited to code executed with "eval $string" - no support for breakpoints and no stepping into those in EPIC (although stepping can be done with perl5db).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I actually have a simple workaround, I override the die
and set a breakpoint in it, when something dies, the debugger
breaks, and I can navigate in the stack view, 95% as usefull
as 'breaking on die'.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Given that it is possible to override 'die' in perl,
I was wondering what it would take to do break with
the debugger on the faulty line, with something like
the following :
$SIG{__DIE__} = sub { # a die callback
my $trace = Devel::StackTrace->new;
my $f = $trace->{frames};
shift @$f;
$trace->reset_pointer;
my $er = Error::Simple->new();
my $f1 = $trace->next_frame;
TELL_EPIC_TO_BREAK_ON($f1->filename, $f1->line);
}
Or even simlpy :
$SIG{__DIE__} = sub { # a die callback
TELL_EPIC_TO_BREAK_ON("this file", 23);
my $dummy = 0; # line 23 would be right here, the debugger would break on this line
#
}
the only missing piece is : TELL_EPIC_TO_BREAK_ON($file,$line);
I see that there is a file :
.metadata/.plugins/org.epic.debug/epic_breakpoints.pm that has such a method !
Thanks !
The traditional way to embed breakpoints in Perl code is to insert the line $DB::single=1; before the statement you want to break on. This will indeed cause the perl5db.pl debugger to pause, however, EPIC will let it continue, seeing that it knows of no such breakpoint. The reason for this continuation is that not every pause of perl5db.pl is a real user-defined breakpoint (perl5db.pl also pauses on loading files, in which case EPIC has to insert the local breakpoints and let it run on).
In short, there is currently no way to break programmatically without (also) setting a breakpoint on the following line in the EPIC editor. I'm also not sure how well breakpoints in anonymous blocks are handled (I know for sure that you cannot step into such blocks using EPIC).
>I'm also not sure how well breakpoints in anonymous blocks are handled
>(I know for sure that you cannot step into such blocks using EPIC).
Are you sure ?
$SIG{__DIE__} = sub {
....I have set breakpoints in here and they do get caught by the debugger !
};
I can even step into them, and see the local variables
very usefull for debugging legacy apps !
Sorry, I got it wrong. The problem I described is limited to code executed with "eval $string" - no support for breakpoints and no stepping into those in EPIC (although stepping can be done with perl5db).
I actually have a simple workaround, I override the die
and set a breakpoint in it, when something dies, the debugger
breaks, and I can navigate in the stack view, 95% as usefull
as 'breaking on die'.