Re: deferred vtable assignment?
Dan Sugalski wrote: What if the decision in-vtable or not-in-vtable is deferred? That's doable, I think, though I can see some issues. how about a two-tiered vtable, where a single high bit, if set, indicates extended handling, or at least consultation of a different table. I guess that amounts to the same as having a set number of extended entries that indicate check elsewhere to decide what do do now. Which again causes mind-expoloding possibilities, except that there is no reason to keep all possibilities in mind, just open up the pandorabox and let all the evil out. teddy bears get drunk and they all say yodelahihu
Re: deferred vtable assignment?
At 03:02 PM 4/26/2001 -0500, David L. Nicol wrote: Dan Sugalski wrote: What if the decision in-vtable or not-in-vtable is deferred? That's doable, I think, though I can see some issues. how about a two-tiered vtable, where a single high bit, if set, indicates extended handling, or at least consultation of a different table. I guess that amounts to the same as having a set number of extended entries that indicate check elsewhere to decide what do do now. Yeah, I think this might be what we do, but there are still issues. I'd rather know at runtime (or, rather, after BEGIN time) what I've got handy for vtable entries, since it's at that point that the vtable messiness will be finalized as the bytecode hits the optimizer. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
PDD for debugger
=head1 The Perl6 Debugger
=head2 Perl-level Debugging
=head3 Existing Functionality
The following is a list of the functionality in the existing Perl5
debugger; this functionality should, of course, be maintained for
backwards compatibility.
=over 4
=item T
Stack trace.
=item s [expr]
Single step [in expr].
=item n [expr]
Next, steps over subroutine calls [in expr].
=item CR
Repeat last n or s command.
=item r
Return from current subroutine.
=item c [line|sub]
Continue; optionally inserts a one-time-only breakpoint at the
specified position.
=item l min+incr
List incr+1 lines starting at min.
=item l min-max
List lines min through max.
=item l line
List single line.
=item l subname
List first window of lines from subroutine.
=item l C$var
List first window of lines from subroutine referenced by C$var.
=item l
List next window of lines.
=item -
List previous window of lines.
=item w [line]
List window around line.
=item .
Return to the executed line.
=item f filename
Switch to viewing filename. File must be already loaded. Filename may
be either the full name of the file, or a regular expression matching
the full file name: f /home/me/foo.pl and f oo\. may access the same
file. Evals (with saved bodies) are considered to be filenames: f
(eval 7) and f eval 7\b access the body of the 7th eval (in the order
of execution).
=item /pattern/
Search forwards for pattern; final / is optional.
=item ?pattern?
Search backwards for pattern; final ? is optional.
=item L
List all breakpoints and actions.
=item S [[!]pattern]
List subroutine names [not] matching pattern.
=item t
Toggle trace mode.
=item t expr
Trace through execution of expr.
=item b [line] [condition]
Set breakpoint; line defaults to the current execution line; condition
breaks if it evaluates to true, defaults to '1'.
=item b subname [condition]
Set breakpoint at first line of subroutine.
=item b C$var
Set breakpoint at first line of subroutine referenced by C$var.
=item b load filename
Set breakpoint on `require'ing the given file.
=item b postpone subname [condition]
Set breakpoint at first line of subroutine after it is compiled.
=item b compile subname
Stop after the subroutine is compiled.
=item d [line]
Delete the breakpoint for line.
=item D
Delete all breakpoints.
=item a [line] command
Set an action to be done before the line is executed; line defaults to
the current execution line. Sequence is: check for
breakpoint/watchpoint, print line if necessary, do action, prompt user
if necessary, execute line.
=item a [line]
Delete the action for line.
=item A
Delete all actions.
=item W expr
Add a global watch-expression.
=item W
Delete all watch-expressions.
=item V [pkg [vars]]
List some (default all) variables in package (default current). Use
~pattern and !pattern for positive and negative regexps.
=item X [vars]
Same as V currentpackage [vars].
=item x expr
Evals expression in array context, dumps the result.
=item m expr
Evals expression in array context, prints methods callable on the
first element of the result.
=item m class
Prints methods callable via the given class.
=item ?
List Perl commands to run before each prompt.
=item expr
Define Perl command to run before each prompt.
=item expr
Add to the list of Perl commands to run before each prompt.
=item ?
List Perl commands to run after each prompt.
=item expr
Define Perl command to run after each prompt.
=item expr
Add to the list of Perl commands to run after each prompt.
=item { db_command
Define debugger command to run before each prompt.
=item { ?
List debugger commands to run before each prompt.
=item expr
Define Perl command to run before each prompt.
=item {{ db_command
Add to the list of debugger commands to run before each prompt.
=item ! number
Redo a previous command (default previous command).
=item ! -number
Redo number'th-to-last command.
=item ! pattern
Redo last command that started with pattern. See 'O recallCommand' too.
=item !! cmd
Run cmd in a subprocess (reads from DB::IN, writes to DB::OUT) See 'O
shellBang' too.
=item H -number
Display last number commands (default all).
=item p expr
Same as print {DB::OUT} expr in current package.
=item |dbcmd
Run debugger command, piping DB::OUT to current pager.
=item ||dbcmd
Same as |dbcmd but DB::OUT is temporarilly select()ed as well.
=item = [alias value]
Define a command alias, or list current aliases.
Re: PDD for debugger
You list the particular commands as 'existing functionality'. I think this is a mistake, even if you didn't mean it that way, if it was just an artifact of your presentation format. I know that breaking debugging habits that have been ingrained in at the spinal level may be hard to break, but thinking that we must save t (or any particular command) is in my opinion the wrong to approach a new design. Rather, look at the higher level concepts; take a look, nay, several looks, at other command line debuggers, what commands do they offer? Collect and group the concepts. Take a look at graphical debuggers (boo! hiss! I hear the chorus moaning) -- but seriously: take a look at, say, ddd and its data displays. What kind of hooks, APIs, design, we can supply so that making the life of gooey looser interfaces is easier? Take a look at various Perl debugging books and tutorials: what (lack of) features they apologize about? Take a look at perltrap and similar documents, like beginners' tips and ticks: what are the common mistakes? Also, one current problem with the debugger should of course harass us no more in Perl 6: the lexical scope of the debugger is different from the scope of the debuggee. (You may have mentioned this but I didn't see it.) The debugger must be able to see two scopes at the same time: its own and the debuggee's. Finally my personal pet peeve that I wish would be banished: 'h' should give just a short summary, not the full story that needs a pager. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: deferred vtable assignment?
At 05:14 PM 4/25/2001 -0500, David L. Nicol wrote: Dan Sugalski wrote: 2) Anyway, even resizing vtables we would need some more indirection to determine in which position of the vtable is which operator. No. Each operator goes in a fixed position in the vtable, and it's the same for each table. Anything else is nasty, error prone, and slow. What if the decision in-vtable or not-in-vtable is deferred? The size of the vtable could be chosen late in the compilation. There could be hints. That's doable, I think, though I can see some issues. It means that the bytecode compiler will need to do some reorganization and possibly emit different opcode streams. That's not a huge issue, but it does mean that we'll need to do extra processing of bytecode-compiled modules. (Especially ones loaded at runtime, unless we restrict the module compilation sequence to not use extra vtable entries, or spit out two streams of bytecode and choose which to use based on the number of remaining vtable entries) The logic could get potentially rather dodgy when twiddling code sequences from one way to the other. I'd really just as soon not deal with the issue this way, though that doesn't mean it won't be the way we end up going. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
