Re: strings: sequence-of-integer ... list of chunks
On Thu, 31 Jan 2002, Bryan C. Warnock wrote: print There's a letter in here!\n if (substr($pi, 0, 200) =~ /[a-z]/); *shrug* I actually did think of that when I first proposed this; doesn't substr make a fresh copy of the string? (I honestly don't know.) What happens if you take a substring of a generator? Have you just used up the first 200 characters? What if I the thing I'm matching on is tied, and taking a substring of it has side effects? Plus the fact that, folding this functionality into the regex engine gives us an extra set of tools for doing optimizations with...if we can determine that their pattern cannot match more than N characters, then we can stop after N characters, without having to take substrs or such. I assume we're going to have this ability in the RE for its own use...why not make it directly available to the user? Dave
Re: Revamping the build system
Any interest in using something less painful than Make for this? I was thinking of Cons, myself...built in Perl 5 (which we are already requiring you to have), and much more friendly than Make. Of course, Make has the advantage of being the standard. I won't be at all upset if people don't like the idea--just thought I'd raise the issue. Dave On Wed, 10 Oct 2001, Dan Sugalski wrote: Okay, I think it's time to abstract out how the build system's handled a bit. I'm not sure how much we need, but filling in a template makefile's not going to cut it, I think.
Re: [PATCH] Changes to interpreter op table and simplified DO_OP
On Wed, 19 Sep 2001, Dan Sugalski wrote: Basically we're getting a free load on most architectures, so we ought to use it where we can. (And it doesn't hurt us on those architectures where we don't have it) 1) Does that make us freeloaders? 2) I guess the architecture designers are not Heinlein fans, or they would realize that TANSTAAFL(oad). : Sorry, couldn't resist. Dave
RE: question about branching/returning
Ok, that was pretty much what I thought. But then what is the 'end' opcode for? It does a 'RETURN 0', which would increment the PC by 0 opcodes...which either counts as an infinite loop or a no-op, and we've already got a no-op op. Dave On Thu, 20 Sep 2001, Gibbs Tanton - tgibbs wrote: RETURN causes the program counter to be incremented by that many opcodes. So RETURN 4 would move forward 4 opcodes and RETURN -2 would move backward 2 opcodes. Basically, it returns a relative offset from the current position.
Re: question about branching/returning
Well, I'm in the process of fiddling with this stuff anyway...what do you want me to make it do? Dave On Thu, 20 Sep 2001, Simon Cozens wrote: On Wed, Sep 19, 2001 at 10:32:18PM -0700, Dave Storrs wrote: Ok, that was pretty much what I thought. But then what is the 'end' opcode for? It does a 'RETURN 0', which would increment the PC by 0 opcodes...which either counts as an infinite loop or a no-op, and we've already got a no-op op. end *ought* to break the loop. Whoever rewrote the op loop to keep going until the end of the bytecode stream didn't think of that. :) -- Um. There is no David conspiracy. Definitely not. No Kate conspiracy either. No. No, there is definitely not any sort of David conspiracy, and we are definitely *not* in league with the Kate conspiracy. Who doesn't exist. And nor does the David conspiracy. No. No conspiracies here. - Thorfinn, ASR
naming conventions on opcodes
There was a thread on this recently, but I'm not sure what was resolved. Do we have a standard naming convention for opcodes? Personally, I'd like to see that we stick with (what I thought was) the original plan: a nice, simple ruleset that produces long but predictable names. - the opcode name starts with a short mnemonic prefix (e.g. mul) - every argument adds an '_x', where the exact value of 'x' is determined by the type of the args So, yes, you'd get 'mul_i_ic_ic', but who cares? It's not really that hard to type, and it is absolutely unambiguous. If you want to make the interpreter magically deduce the full opcode name from the prefix, that's cool, too. Just my 1 penny, Dave
The Lost String Functions
In strings.pod, the following string functions are documented and (most|all) are already implemented: DOCUMENTED: chopn concat length substr string_nprintf However, Perl5 also includes the following functions that operate on or otherwise relate to strings: IN PERL5: chomp chr crypt hex index lc lcfirst oct ord pack q/STRING/ qq/STRING/ reverse rindex tr/// uc ucfirst y/// Are these latter functions going to receive opcodes and vtable entries of their own? Or will they be composites of lower level ops? (Simon, I remember that you said you wanted to hold on vtable modifications for the nonce; and thank _you_ for remembering me! :) Dave
string vtable editing script
I've been offline for a few days and haven't caught up on email yet
(nor, most likely, will I ever), so I hope no one else has already
done this, but
Attached is a file, msv.tar.gz which contains a simple script and .pm
file (*) for editing the string vtable. It asks you for a bunch of
typedef/function_name pairs and then rewrites string.h, string.c, and
all of the encoding code files (strnative.c, strforeign.c, strutf*.c),
incorporating what you gave it.
PROS:
- you can give it as many typedef/function pairs as you want at once
- it adds your new typedef only if it isn't already there
- before adding your new function, it checks the vtable in string.h to
make sure that there isn't already an identical function, or one that
differs only by return type
- it understands that (e.g.) 'two_strings_to_iv_t' should expand to:
IV (*two_strings_to_iv_t)(STRING *, STRING *);
(Actually, it understands numbers up to nine, but I hope you never go
that high.)
- it sets up stubs in string.c and all the encoding files, and adds
the appropriate entry to each file's vtable
- if your encoding files don't exist, it will generate them for you
CONS:
- your typedefs must match: type+_to_type_t where type is
composed only of word characters. The arguments (the part before the
'to') must be separated by underscores. So, these are legal:
string_to_string_t
iv_nv_to_string_t
three_strings_nv_to_nv_t OR three_string_nv_to_nv_t (same thing)
these are not legal:
(*_t (not a valid symbol)
string_string_t (doesn't specify a return type)
worst of all, this doesn't work:
substr_t(the patch to change it to an accepted version
is below)
- any comments that you put in the vtable or the typedef section will
be stomped the next time you run the program. If people actually use
this and find it useful, I will fix this misbehaviour.
NOTES:
- the stubs that are put into string.c and the encoding tables don't
have names for their parameters, since the program has no way of
knowing what meaningful names would be.
- the bodies of the stubs consist almost solely of 'FINISH ME', not in
comments (so that it won't compile). There is probably more that I
could make it do for you here, but I wanted to get a working version
out.
- the program uses various parts, including comments, of the string.h
file as delimiters, so if you start making regular manual changes it
might stop working or misbehave.
A sample session (actually a record of the last session I ran before
writing this email) is below. I've put my inputs on the line
following the prompt and indented them to make them stand out.
CUT HERE--
Enter a function name (e.g. chopn), or RET to quit:
reverse
Enter a typedef name (e.g. iv_to_iv_t) to associate with reverse:
string_to_string_t
Enter a function name (e.g. chopn), or RET to quit:
About to rewrite string.h...
Successfully wrote revised text to 'string.h.working'
About to rewrite string.c...
Successfully wrote revised text to 'string.c.working'
About to rewrite encoding files...
Successfully wrote revised text to 'strforeign.c.working'
Successfully wrote revised text to 'strnative.c.working'
Successfully wrote revised text to 'strutf16.c.working'
Successfully wrote revised text to 'strutf32.c.working'
Successfully wrote revised text to 'strutf8.c.working'
About to move working copies to primary versions...
Successfully moved working file 'strforeign.c.working' to 'strforeign.c'
Successfully moved working file 'strutf32.c.working' to 'strutf32.c'
Successfully moved working file 'strutf16.c.working' to 'strutf16.c'
Successfully moved working file 'strutf8.c.working' to 'strutf8.c'
Successfully moved working file 'strnative.c.working' to 'strnative.c'
Successfully moved working file 'string.h.working' to 'string.h'
Successfully moved working file 'string.c.working' to 'string.c'
./msv.pl completed successfully.
$ [edit string.c and strnative.c]
$ [compile and test]
$ [celebrate by submitting]
Here is the patch to change substr_t into something this program can
accept:
[dstorrs@localhost parrot]$ cvsp -q diff -c string.h
-- DIFF OUTPUT STARTS ON NEXT LINE ---
Index: string.h
===
RCS file: /home/perlcvs/parrot/string.h,v
retrieving revision 1.5
diff -u -d -c -r1.5 string.h
cvs server: conflicting specifications of output style
*** string.h2001/09/14 14:08:00 1.5
--- string.h2001/09/16 03:54:37
***
*** 25,31
typedef IV (*string_to_iv_t)(STRING *);
typedef STRING* (*string_iv_to_string_t)(STRING *, IV);
typedef STRING* (*two_strings_iv_to_string_t)(STRING *, STRING *, IV);
! typedef STRING* (*substr_t)(STRING*, IV, IV, STRING*);
typedef IV (*iv_to_iv_t)(IV);
struct string_vtable {
--- 25,31
typedef IV (*string_to_iv_t)(STRING *);
typedef STRING*
Re: String API
(As previously remarked, I'm trying to catch up from a few days offline, so excuse me if this is OOD.) On Tue, 11 Sep 2001, Ken Fox wrote: The interpreter knows the internals of the stack structure and is responsible for managing it. To change the stack implementation, we'll have to carefully examine all the interpreter code. The semantics of the stack aren't real clear either. For example, when changing the stack code what invariants must be preserved? If the stack had an API the interpreter used I think this would be much clearer. If we defined that API as a series of tests, we might save ourselves a lot of grief. I'll volunteer to (attempt to) write the tests, if someone will specify what the invariants are. Dave
debugger API PDD, v1.1
=head1 TITLE API for the Perl 6 debugger. =head1 VERSION 1.1 =head2 CURRENT Maintainer: David Storrs ([EMAIL PROTECTED]) Class: Internals PDD Number: ? Version: 1 Status: Developing Last Modified: August 18, 2001 PDD Format: 1 Language: English =head2 HISTORY =over 4 =item Version 1.1 =item Version 1 First version =back =head1 CHANGES 1.1 - Minor edits throughout - Explicit and expanded list of how breakpoints may be set - Explicit mention of JIT compilation - Added mention of edit-and-continue functionality - Added remote debugging section. - Added multithreaded debugging section 1 None. First version =head1 ABSTRACT This PDD describes the API for the Perl6 debugger. =head1 DESCRIPTION The following is a simple English-language description of the functionality that we need. Implementation is described in a later section. Descriptions are broken out by which major system will need to provide the functionality (interpreter, optimizer, etc) and the major systems are arranged in (more or less) the order in which the code passes through them. Within each section, functionality is arranged according to (hopefully) logical groupings. =head2 Compiler =head3 Generating Code on the Fly =over 4 =item * Compile and return the bytecode stream for a given expression. Used for evals of user-specified code and edit/JIT compiling of source. Should be able to compile in any specified context (e.g., scalar, array, etc). =item * Show the bytecode stream emitted by a particular expression, either a part of the source or user-specified. (This is basically just the above method with a 'print' statement wrapped around it.) =item * Do JIT compilation of source at runtime (this is implied by the first item in this list, but it seemed better to mention it explicitly). =back # Closes 'Generating Code on the Fly' section =head2 Optimizer =head3 Generating and Comparing Optimizations =over 4 =item * Optimize a specified bytecode stream in place. =item * Return an optimized copy of the specified bytecode stream. =item * Show the diffs between two bytecode streams (presumably pre- and post-optimization versions of the same stream). =back # Closes 'Generating and Comparing Optimizations' section =head2 Interpreter =head3 Manipulating the Bytecode Stream =over 4 =item * Display the bytecodes for a particular region. =item * Fetch the next bytecode from the indicated stream. // @@NOTE: from a design perspective, this is nicer than doing (*bcs) everywhere, but we definitely don't want to pay a function call overhead every time we fetch a bytecode. Can we rely on all compilers to inline this properly? =item * Append/prepend all the bytecodes in 'source_stream' to 'dest_stream'. Used for things like JIT compilation. =back # Closes 'Manipulating the Bytecode Stream' section =head3 Locating Various Points in the Code =over 4 =item * Locate the beginning of the next Perl expression in the specified bytestream (which could be, but is not necessarily, the head of the stream). =item * Locate the beginning of the next Perl source line in the specified bytestream (which could be, but is not necessarily, the head of the stream). =item * Search the specified bytestream for the specified bytecode. Return the original bytecode stream, less everything up to the located bytecode. // @@NOTE: Should the return stream include the searched-for bytecode or not? In general, I think this will be used to search for 'return' bytecodes, in order to support the step out of function functionality. In that case, it would be more convenient if the return were Bnot there. =item * Search the specified bytecode stream for the specified line number. This line may appear in the current module (the default), or in another module, which must then be specified. =item * Search the specified bytecode stream for the beginning of the specified subroutine. =item * Locates the beginning of the source line which called the function for which the current stack frame was created. =item * Locate the next point, or all points, where a specified file is 'use'd or 'require'd =back # Closes 'Locating Various Points in the Code' section. =head3 Moving Through the Code =over 4 =item * Continue executing code, stop at end of code or first breakpoint found. =item * Continue up to a specified line, ignoring breakpoints on the way. =item * In the source which produced a specified bytecode stream, search forwards for a specified pattern. =item * In the source which produced a specified bytecode stream, search backwards for a specified pattern. =item * In the source which produced a specified bytecode stream, search forwards for lines where expression is satisfied =item * In the source which produced a specified bytecode stream, search backwards for lines where expression is satisfied =back # Closes 'Moving
Re: PDD 2nd go: Conventions and Guidelines for Perl Source Code
On Tue, 5 Jun 2001, Hugo wrote: I'd also like to see a specification for indentation when breaking long lines. Fwiw, the style that I prefer is: someFunc( really_long_param_1, (long_parm2 || parm3), really_long_other_param ); or, for really complex expressions: ( really_long_param_1 (parm1 || long_parm1) ( yet_another_long_param parm2 (long_parm2 || parm3) ) ); Putting the final close paren on the next line makes it easier to tell where the (sub)expression finishes. Dave
Re: Stacks, registers, and bytecode. (Oh, my!)
On Tue, 5 Jun 2001, Dave Mitchell wrote: dispatch loop. I'd much rather have a 'regex start' opcode which calls a separate dispath loop function, and which then interprets any further ops in the bytestream as regex ops. That way we double the number of 8-bit ops, and can have all the regex-specific state variables (s, send etc in the earlier example) and logic separated out. This is an interesting idea...could we use this more generally to multiply our number of opcodes? Basically, you have one set of opcodes for (e.g.) string parsing, one set for math, etc, all of which have the same value. Then you have a set of opcodes that tells the interpreter which opcode table to look in. The 'switching' opcodes then become overhead, but if there aren't too many of those, perhaps its acceptable. And it would mean that we could specialize the opcodes a great deal more (if, of course, that is desirable), and still have them fit in an octet. (Sorry if this is a stupid question, but please be patient; I've never done internals stuff before.) Dave
Re: PDD: Conventions and Guidelines for Perl Source Code
On Wed, 9 May 2001, Larry Wall wrote: Dave Mitchell writes: : My thinking behind if fails on one, avoid on all was that if it failed : on at least one, then it may well fail on others that you dont have access : to - either now or in the future, and thus perhaps isnt as good an optimisation : as you figured. The other way would to be only enable for those architectures : that experience a speedup. Makes sense. Larry It does, however, mean that the code ends up *riddled* with with #ifdef's instead of merely shot full of them. I don't know about the rest of you, but I find this annoying and difficult to read: #if defined MAC do A ...ten lines or so... #elif defined WIN32 do B ...ten lines or so... #elif defined VMS do C ...ten lines or so... #elif defined AMIGA do D ...ten lines or so... #elif defined BIG_IRON do E ...ten lines or so... #else do non-optimized version ...ten lines or so... #endif Dave
Re: PDD for debugger
On Tue, 1 May 2001, Dan Sugalski wrote: Right. What I'm thinking would be a good place to get to is a list of the functionality that the debugger needs to provide or have available to it from the interpreter, rather than the actual interface to the user. (Which is important, but a separate issue) [snip] though. I think we're still at the What functionality should the interpreter/compiler/parser provide to the person writing a debugger phase. Errrmmm...sorry, but let me just be clear on this. I had intended to write this document in (more or less) the following sections: - things that the user can do (set breakpoints, step, etc) - implementation details of each feature in the previous section (what data structures do we use to store breakpoints? what information is associated with them? etc) - the internals of the debugger; its APIs, etc. It sounds like you don't want the first two sections. Can you give me a better idea of what exactly you are looking for in this document? Incidentally, I'm not trying to dictate interface...it's just that starting with the functionality is a convenient handle for figuring out what internals the debugger will need. Dave
Re: So, we need a code name...
On Wed, 25 Apr 2001, Johan Vromans wrote: Andy Dougherty [EMAIL PROTECTED] writes: Starting with 'P' is useful so we can keep our acronyms such as PMC and PERIL (hi Tom!). -- Johan ACCENT=ENGLISH Please, can't I have just a little PERIL? /ACCENT Dave
Re: PDD for debugger
Great, thanks very much. Dave On Fri, 27 Apr 2001, Jarkko Hietaniemi wrote: see it.) The debugger must be able to see two scopes at the same time: its own and the debuggee's. Could you expand on this? http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-02/msg01613.html for example. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
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.
debugger PDD delay
Apologies all...I have the document, but I'm having trouble getting it out of my computer. I don't have Internet access yet and my floppy drive is refusing to read. I'll see if I can get the printer hooked up tonight, print the thing out, retype it at work tomorrow, and send it in then. Dave
debugging PDD: request for suggestions
Hey folks, Ok, so I've picked up Dan's gauntlet on the debugging PDD. I've got a pretty long list of things to put in it already, but if anyone would care to send me their suggestions, I can get them integrated into the initial draft. I probably won't have it ready by tomorrow, and I only have Internet from work (I'm in the process of moving), so it will probably be coming out on Monday. Feel free to send suggestions direct to me so as not to clog the list (or send them to the list, so as to spark other people's imagination; I'm relaxed). Dave
Re: Perl_foo() vs foo() etc
On Thu, 12 Apr 2001, Dan Sugalski wrote: I think Perl_ and maybe Perl__ would be fine. I'd rather Perl_ and _Perl_, but... How about PerlF_ and PerlD_ (for Functions and Data)? To also specify Exported and Private we could have PerlFE_, PerlFP, etc. Dave
Re: Thought for the day
On Wed, 31 Jan 2001, Tim Bunce wrote: Since this thread is in the mood for quotes, here's one I'm fond of... It goes something along the lines of: Any fool can create a complicated system. The real skill is in making a simple one. Ok, if we're all contributing quotes, here's mine: "I'm sorry for writing you such a long letter; I didn't have time to write a shorter one." -- Abraham Lincoln
Re: RFC 334 (v1) Ahhhh.. i get it
Heh. In my youth, we said "Thanks a million." I see that inflation has now turned that into "Thanks a million and twenty four thousand." : On 12 Oct 2000, John van V wrote: $thanks - (1000K)
Re: RFC 326 (v1) Symbols, symbols everywhere
On Wed, 27 Sep 2000, Dan Sugalski wrote: At 05:37 AM 9/27/00 +, Perl6 RFC Librarian wrote: Perl should adopt scheme-like symbols, both at the language level and at the internals level. The explanation of this isn't that clear for me. (I have no scheme experience at all) It isn't terribly clear to me either, but I think that what he's saying is that you can qs() a method name, get a "thingie" out, store the thingine in a scalar, and then that scalar becomes a direct portal to the method...somewhat like a coderef, but without a required deref. Dave
Re: RFC 310 (v1) Ordered bytecode
On Tue, 26 Sep 2000, Dan Sugalski wrote: What'd be a larger win would be if we have async I/O built into the core ... This is reasonably simple on Unices that support it, as well as on VMS and Windows. Can't speak for other platforms, but I'm not hugely worried that we won't get the win on, say, HP/UX 10.x or SunOS 4.x... Just a point of information: Windows 95/98 can NOT do asynch IO...I've just spent the last week researching this, and that fact is clearly and frequently scattered through the MSDN documentation. You can fake AIO by using an IO thread (which is generally worthless, given the lousy W95 thread model) or by doing manual timeslicing, but you can't get true AIO. Just FWIW. Dave
Re: RFC 214 (v1) Emit warnings and errors based on unoptimized code
It seems to me that everyone in this thread pretty much agrees that this is a good idea, but has one of the following reservations: 1) Tracking sufficient information to be able to report errors at the exact spot they happen involves bloating the optree a lot and slowing down the whole program; 2) The implementation of this idea is decidedly non-trivial. First of all, does anyone have a concern other than these two? As to solving #2...well, I'm going to wave my hands a lot and say, "Oh, that's an SEP and besides, it's just a SMOP." Which, I realize, is incredibly unfair. As to solving problem #1 (which is, arguably, the bigger problem), suppose we add a new switch to perl? I propose we add the -H switch (mnemonic: *H*elpful errors/warnings). When -H is set, the optree would be generated with a sufficient amount of bloat that it could report the errors/warnings at the exact spot they occur, even down to reporting the appropriate failure line in a multiline statement. We don't worry about bloat or slowdown, because the assumption is that -H is only used during debugging or when speed doesn't matter, and it will be turned off when the code goes to production. Separate from the above idea, I would like to debate whether -H should be on or off by default. Either way has advantages and disadvantages: -on by default: PRO:newbies have an easier time, one-offs and short programs are easier to debug; CON:p526 must insert a -H into older programs in order to keep them running at the same speed, experts who don't want this functionality (will there be such people?) must type an extra 2 characters into every script. -off by default: PRO:p526 doesn't have to add a command line switch, those who don't want the functionality don't have to type the extra 2 characters; CON:people who DO want the functionality (probably the majority) will need to type an extra 2 characters Dave
Re: RFC 214 (v1) Emit warnings and errors based on unoptimized code
On Wed, 13 Sep 2000, Nathan Torkington wrote: Simon Cozens writes: Nice! Efficient! Practical! Choose two. I take this oblique comment to mean that it'd bloat the op-tree too much? Well, suppose we simply add the -FOO (choose your letter) flag to perl...-FOO is a toned-down -d in that it produces a debug version with bloated op-trees, but having these bloated op-trees allows it to emit more useful warnings/errors. When you want it to run faster, you turn off -FOO and it runs faster. (Actually, -FOO should probably be _on_ by default and be something that you turn _off_ as an optimization, once your script is ready to roll.) Dave
Re: Ideas On what a SV is
On Fri, 11 Aug 2000, David L. Nicol wrote: [...] Redefining a method during run time --- is that even a feature that needs to be supported? I think so. A couple of examples are the Memoize module, which works by rewriting your memoized function into something that uses caching, then replacing the old version with the new version in the stash. Another time you would want to do this would be the following: you write your AUTOLOAD function such that, when it receives a request it can handle, it creates a sub to handle the request and installs the sub directly in the stash so that, the next time you need that function, you don't need to traverse @ISA before going to AUTOLOAD. Dave
