Re: RFC 292 (v1) Extensions to the perl debugger
[Quoting Dave Storrs, on September 26 2000, 11:47, in "Re: RFC 292 (v1) Ext"] I'm confused...are you suggesting that the debugger should no longer be integrated into perl? Absolutely not! What I wanted to indicate is that the input and output handling of the debugger, currently line input and line output, should not be turned into a sophisticated user interface with command line recall/editing and fancy output paging (e.g. two independently scrollable windows, one for input and one for output). External tools should manage that. I mentioned the way the perl debugger runs under Emacs, ptkdb is another good example. BTW: the debugger already has command line recall/editing using Term::ReadLine. -- Johan
Re: RFC 292 (v1) Extensions to the perl debugger
On Wed, 27 Sep 2000, Johan Vromans wrote: What I wanted to indicate is that the input and output handling of the debugger, currently line input and line output, should not be turned into a sophisticated user interface with command line recall/editing and fancy output paging (e.g. two independently scrollable windows, one for input and one for output). External tools should manage that. I mentioned the way the perl debugger runs under Emacs, ptkdb is another good example. BTW: the debugger already has command line recall/editing using Term::ReadLine. I disagree. I want to have perl provide reasonable default behavior for these extremely useful and commonly-desired functions, and I don't want it to be dependent on modules from outside the core or on requiring the user to configure something (after all, if the user must configure it, it's not default). I want perl to provide me with a standard interface which satsifies my basic requirements. I want this interface to be the same on all platforms so I don't need to get used to "oh yeah, today I'm on the Windows box, so it's Shift-UpArrow for the command history." I'm not saying that outside tools shouldn't be built to provide _better_ versions of the standard behavior, or nicer UIs. I'm just saying that the basic versions are not acceptable, and should be improved and standardized. Dave
Re: RFC 292 (v1) Extensions to the perl debugger
Perl6 RFC Librarian [EMAIL PROTECTED] writes: The ability to easily retrieve and edit your N most recent commands to the debugger (much like a bash_history). and A better default pager. The default pager should assume a 24x80 term window ... To me, these clearly indicates that the debugger should be run as a subsystem of some other tool that takes care of this. It is not part of the debugger itself. For example, take a look at how emacs runs the debugger. -- Johan
Re: RFC 292 (v1) Extensions to the perl debugger
On 26 Sep 2000, Johan Vromans wrote: Perl6 RFC Librarian [EMAIL PROTECTED] writes: The ability to easily retrieve and edit your N most recent commands to the debugger (much like a bash_history). and A better default pager. The default pager should assume a 24x80 term window ... To me, these clearly indicates that the debugger should be run as a subsystem of some other tool that takes care of this. It is not part of the debugger itself. For example, take a look at how emacs runs the debugger. I'm confused...are you suggesting that the debugger should no longer be integrated into perl? If so, I disagree...I absolutely insist that, no matter what pathological distribution someone may put together for Perl, I will get the debugger so at least I have a chance of figuring out what's wrong. The only way to absolutely ensure this is to have it built into the interpreter itself. As to the history file...this is something that I've wanted since I first touched the debugger, and I suspect others would like it as well. As to the pager...the "default pager" is currently "no pager", which is silly. I distinctly remember having the following thought pattern, from back when I was learning how to use the debugger: "Ok, what commands are available? Let's type 'h' " "Hmm...it scrolls off the screen...aha! look, down here at the bottom it says I can do '|dbcmd' to pipe the output of a debugger command through the current pager! Excellent, that's just what I need." " '|h' " [it runs off the screen again] "DOH!" All humor aside, there is too much information in the debugger help screen to fit in 50 lines. That means that anyone trying to use the debugger through a DOS window, or a fixed-size telnet client, can't see the majority of the information. Dave
Re: RFC 292 (v1) Extensions to the perl debugger
On Mon, Sep 25, 2000 at 07:34:04PM -, Perl6 RFC Librarian wrote:
Mailing List: [EMAIL PROTECTED]
Most of this RFC would probably be better off in perl6-stdlib; the debugger
isn't really part of the language. That being said, however...
The ability to easily retrieve and edit your N most recent commands to the
debugger (much like a bash_history).
Dosn't the default debugger do this if you've got ReadLine?
A better default pager.
I think it would be better for this to be a nonperl thing (possibly written
in perl, but not a part of the debugger proper).
The ability to provide a function name (preferably just the first unique
section of its name) and
You can do the unique prefix part by looking in the symbol table.
jump to where that function is defined,
This, I think, would be a quite useful and simple thing to acatualy put in
the language. Just have two implicit attributes on a sub: :line and :file,
that recive the value of __LINE__ and __FILE__ at the sub {} statement.
Note that the AutoLoader and such things that use evals to define subs would
probably want to change these attributes -- otherwise they'd probably get
the location of the AUTOLOADER sub and not where the sub being autoloaded
was acatualy written.
Most of the rest would require siginificant overhead on all programs that
might get debugged (the debugger is a module; you don't necessarly have to
start it from the commandline). Use a tags program. G
-=- James Mastros
--
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GUCS d--- s-:- a20 C++ UL+++@ P L++@ E-() N o? K? w@ M-- !V
PS++ PE Y+ PGP(-) t++@ 5+ X+++ R+ tv+ b+++ DI+ D+ G e++ h! r- y?
--END GEEK CODE BLOCK--
