[PATCH] json reimplemented with pct
without any internet connection at home you get really bored. that means, time for some fun :-) Included is a patch that implements JSON with the PCT. As JSON is just a data description (sub) language, I was not sure what the TOP rule should contain; I decided for now that it would be just value* Running the pct-based JSON language, just input some string on the command line, like [1, 2, 3], and the output is dumped to stdout. kjs json_pct.patch Description: Binary data
Re: [perl #56230] [PATCH] Multimethods for Complex.
Another question: Vasily Chekalkin (via RT) wrote: +.sub 'sqrt' :multi(Complex) +.param pmc a +a = sqrt a +.return (a) +.end Do we actually want a sqrt(Complex)? Somebody who is sufficiently mathematically educated to work with complex numbers should now that sqrt() is ambigous, because there are two possible results, and will revert to roots() for that. Any thoughts? Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
[svn ci] :lexid(...)
Hi,
So before, this would not work out because it found the wrong outer:
--
.sub main
outer()
.end
.namespace [ 'Foo' ]
.sub outer
say oops
.end
.namespace []
.sub outer
$P0 = new 'Integer'
$P0 = 42
.lex '$a', $P0
test()
.end
.sub test :outer('outer')
$P0 = find_lex '$a'
say $P0
.end
--
Now with :lexid, we can mark the subs and use it to refer to them in
outer (note that :lexid defaults to the sub name, so this change is
backward compatible):
--
.sub main
outer()
.end
.namespace [ 'Foo' ]
.sub outer :lexid('foo')
say oops
.end
.namespace []
.sub outer :lexid('bar')
$P0 = new 'Integer'
$P0 = 42
.lex '$a', $P0
test()
.end
.sub test :outer('bar')
$P0 = find_lex '$a'
say $P0
.end
--
This gives 42, which is The Answer, so all must be good. (Apart from my
sanity, after hacking on IMCC...)
No new failing tests in Parrot nor Rakudo spectest_regression. In as r28710.
Hope this is what's needed,
Jonathan
[perl #56382] [RFC] Making Test::Harness 3 available without including it in core parrot.
# New Ticket Created by Will Coleda # Please include the string: [perl #56382] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56382 I wanted to open a new ticket on this so discussion regarding how we get this in place for smolder is separate from smolder itself. The most expedient solution to getting this working is to simply bundle TH3 with parrot, as we do for other non-core modules we must rely on. I am wondering if it would not be better to more specifically declare our dependencies so we can avoid backsliding on our goal of eliminating CPAN modules from our repository. We have the following types of parrot builders: 1) Those that install from CPAN. This means a pretty trivial dependency listing. 2) Those that install from a package The package builder already has to depend on perl, they can depend on other modules as well. 3) Developers We already have Bundle::Parrot for developers; moving another item into that Bundle shouldn't be an issue. 4) ... everyone else. For someone grabbing a version of parrot off the website (especially if we ever host them away from CPAN) isn't going to have any easy hooks for following dependencies. However, we can just add this as a probe during Configure.pl; if we find any dependencies that are not available with the perl we're running as, we can print out a nice, helpful diagnostic about the minimum required version of the module. (I recommend a single probe that checks for all the perl dependencies for the build. If any modules required for building are missing, die. If any modules used in testing are missing, only warn, and conditionalize all the tests to handle the lack of the module gracefully.) (This step would probably have to be one of the first steps run, since I see File::Which is used during configure.) -- If we went this route, we could avoid including T:H3, and also remove any of the remaining modules we bundle in lib/ Comments? -- Will Coke Coleda
Re: [perl #56382] [RFC] Making Test::Harness 3 available without including it in core parrot.
On Thursday 26 June 2008 07:37:46 Will Coleda wrote: If we went this route, we could avoid including T:H3, and also remove any of the remaining modules we bundle in lib/ Comments? T::H 3 is only a requirement for people who want to type 'make smolder' (and eventually I hope 'make smoke'), so probing for it without bundling it seems eminently sensible to me. -- c
Re: [perl #56382] [RFC] Making Test::Harness 3 available without including it in core parrot.
chromatic wrote: T::H 3 is only a requirement for people who want to type 'make smolder' (and eventually I hope 'make smoke'), so probing for it without bundling it seems eminently sensible to me. Agreed. That's what we do with TAP::Harness::Archive. -- Michael Peters Plus Three, LP
[perl #38194] [TODO] build - optimize pmc2c.pl
On #parrot I had some discussion about tools/build/pmc2c.pl with bacek and DietCoke. I pasted some output from dprofpp: http://nopaste.snit.ch/13401 http://nopaste.snit.ch/13402 On the basis of these pastes, I was advised to consider using Memoize.pm to memoize the most frequently called functions in the modules underlying pmc2c.pl. However, my preliminary investigation suggests that Memoize is not a good bet here. As I understand Memoize, it is useful in circumstances where you have to have to call a function repeatedly and where there's a high probability that you will call it with the same arguments more than once. Memoize caches the return value associated with a particular set of arguments. But Memoize will only be worth the effort if the time you save by doing cache lookups rather than function calls is greater than the time needed to load Memoize.pm and memoize the function in the first place. But the functions in the modules underlying pmc2c.pl are not this sort of functions. They tend to be OO methods that change the internal state of the object. They tend not to have meaningful return values (i.e., return values other than truth, falseness, undef, etc.) So my hunch is that Memoize is not likely to be useful here -- but I would welcome any cases to the contrary that anyone might cite. Thank you very much. kid51
Re: [perl #38194] [TODO] build - optimize pmc2c.pl
On Thu, Jun 26, 2008 at 2:50 PM, James Keenan via RT [EMAIL PROTECTED] wrote: On #parrot I had some discussion about tools/build/pmc2c.pl with bacek and DietCoke. I pasted some output from dprofpp: http://nopaste.snit.ch/13401 http://nopaste.snit.ch/13402 On the basis of these pastes, I was advised to consider using Memoize.pm to memoize the most frequently called functions in the modules underlying pmc2c.pl. However, my preliminary investigation suggests that Memoize is not a good bet here. As I understand Memoize, it is useful in circumstances where you have to have to call a function repeatedly and where there's a high probability that you will call it with the same arguments more than once. Memoize caches the return value associated with a particular set of arguments. But Memoize will only be worth the effort if the time you save by doing cache lookups rather than function calls is greater than the time needed to load Memoize.pm and memoize the function in the first place. But the functions in the modules underlying pmc2c.pl are not this sort of functions. They tend to be OO methods that change the internal state of the object. They tend not to have meaningful return values (i.e., return values other than truth, falseness, undef, etc.) In that case, Memoize will not help, you're absolutely right. (Might be worth seeing if the code is amenable to a refactor that -would- be amenable to this, but that's probably more work.) So my hunch is that Memoize is not likely to be useful here -- but I would welcome any cases to the contrary that anyone might cite. Thank you very much. kid51 -- Will Coke Coleda
Re: [perl #56166] [BUG] [PATCH] Perl::Critic Version Problems
On Sun, Jun 22, 2008 at 10:35 PM, Will Coleda via RT
[EMAIL PROTECTED] wrote:
Attached find a first pass at converting our perlcritic.t into using
Test::Perl::Critic.
This patch:
- requires Test::Perl::Critic to do anything useful with the test. (We can
add it to
Bundle::Parrot)
- creates a new perlcritic.conf file that represents declaratively a large
chunk of the code we
used to use to manage the policy list.
- removes the ability to list the policies. (you have the conf file)
- removes the ability to specify a specific policy (you can roll your own
with themes)
- removes the ability to specify a directory to run the policies against (but
if we do, let's do it
without File::Find, and just key off the MANIFEST like we do now.)
- keeps the ability to specify a group of tests, but calls it a theme,
following the lead set by
Perl::Critic.
- reports each file as a test, not each policy.
I think the last item there is a big reason we started down the path we did,
but given how
much simpler this script is, I don't think it's worth worrying about.
I've tested this on Perl::Critic 1.086; I'd be interested to hear feedback on
older versions of
P::C before I apply. (The old version I had installed is no longer available
for easy download
on the CPAN)
Feedback in general, as well: This is a reduction in features from the
original version, but I
think it's a step forward.
It's been 4 days with no negative feedback; I'll plan on applying the
patch this weekend.
--
Will Coke Coleda
Index: tools/util/perlcritic.conf
===
--- tools/util/perlcritic.conf (revision 0)
+++ tools/util/perlcritic.conf (revision 0)
@@ -0,0 +1,65 @@
+verbose = 3
+
+[BuiltinFunctions::ProhibitStringySplit]
+add_themes = parrot
+
+[CodeLayout::ProhibitDuplicateCoda]
+add_themes = parrot
+
+[CodeLayout::ProhibitHardTabs]
+allow_leading_tabs = 0
+add_themes = parrot
+
+[CodeLayout::ProhibitTrailingWhitespace]
+add_themes = parrot
+
+[CodeLayout::RequireTidyCode]
+perltidyrc = tools/util/perltidy.conf
+add_themes = extra
+
+[CodeLayout::UseParrotCoda]
+add_themes = parrot
+
+[InputOutput::ProhibitBarewordFileHandles]
+add_themes = parrot
+
+[InputOutput::ProhibitTwoArgOpen]
+add_themes = parrot
+
+[NamingConventions::ProhibitAmbiguousNames]
+# remove abstract from the list of forbidden names
+forbid = bases close contract last left no record right second set
+add_themes = extra
+
+[Subroutines::ProhibitBuiltinHomonyms]
+add_themes = extra
+
+[Subroutines::ProhibitExplicitReturnUndef]
+add_themes = parrot
+
+[Subroutines::ProhibitSubroutinePrototypes]
+add_themes = parrot
+
+[Subroutines::RequireFinalReturn]
+add_themes = extra
+
+[TestingAndDebugging::MisplacedShebang]
+add_themes = parrot
+
+[TestingAndDebugging::ProhibitShebangWarningsArg]
+add_themes = parrot
+
+[TestingAndDebugging::RequirePortableShebang]
+add_themes = parrot
+
+[TestingAndDebugging::RequireUseStrict]
+add_themes = parrot
+
+[TestingAndDebugging::RequireUseWarnings]
+add_themes = parrot
+
+[Variables::ProhibitConditionalDeclarations]
+add_themes = parrot
+
+[Bangs::ProhibitFlagComments]
+add_themes = extra
Index: MANIFEST
===
--- MANIFEST(revision 28654)
+++ MANIFEST(working copy)
@@ -1,7 +1,7 @@
# ex: set ro:
# $Id$
#
-# generated by tools/dev/mk_manifest_and_skip.pl Sun Jun 22 17:10:01 2008 UT
+# generated by tools/dev/mk_manifest_and_skip.pl Mon Jun 23 02:21:20 2008 UT
#
# See tools/dev/install_files.pl for documentation on the
# format of this file.
@@ -3888,6 +3888,7 @@
tools/util/dump_pbc.pl []
tools/util/gen_release_info.pl []
tools/util/ncidef2pasm.pl []
+tools/util/perlcritic.conf []
tools/util/perltidy.conf[]
tools/util/pgegrep []
tools/util/release.json []
Index: t/codingstd/perlcritic.t
===
--- t/codingstd/perlcritic.t(revision 28654)
+++ t/codingstd/perlcritic.t(working copy)
@@ -1,256 +1,54 @@
#! perl
-# Copyright (C) 2001-2007, The Perl Foundation.
+# Copyright (C) 2008, The Perl Foundation.
# $Id$
use strict;
use warnings;
-use lib qw(. lib ../lib ../../lib);
+use lib qw{lib};
-use Fatal qw(open);
-use File::Find;
use File::Spec;
-use Test::More;
-use Parrot::Config qw{%PConfig};
-use Parrot::Distribution;
use Getopt::Long;
+use Parrot::Config qw(%PConfig);
+use Parrot::Distribution;
+use Test::More;
-BEGIN {
-eval { require Perl::Critic; };
-if ($@) {
-plan skip_all = 'Perl::Critic not installed';
-}
-
[perl #56166] [BUG] [PATCH] Perl::Critic Version Problems
FWIW, the part of the patch pertaining to t/codingstd/perlcritic.t did not apply cleanly when I tried it on Linux. That may just indicate that the guts have been ripped out of that file and replaced with mostly new code. Perhaps you could post the complete text of your new version of that file? Thank you very much. kid51
Re: [perl #56346] [PATCH] Check for valid conditions in debug opcodes
More refactor: in addition to the changes in the previous, this also
moves the PDB_extend_const_table from src/debug.c to
compilers/imcc/pbc.c, because is the only file that uses it and seems
to not be related to the debugger (historical reasons?), renames it
and makes it static, and add a few auxiliar functions to clean his
usage.
--
Salu2
Index: src/ops/debug.ops
===
--- src/ops/debug.ops (revisión: 28719)
+++ src/ops/debug.ops (copia de trabajo)
@@ -44,15 +44,7 @@
=cut
op debug_init() :base_debug {
-PDB_t *pdb;
-
-if (!(interp-pdb)) {
-pdb = (PDB_t *)mem_sys_allocate_zeroed(sizeof (PDB_t));
-
-interp-pdb = pdb;
-pdb-cur_opcode = interp-code-base.data;
-pdb-state |= PDB_RUNNING;
-}
+Parrot_debugger_init(interp);
}
@@ -64,13 +56,7 @@
=cut
op debug_load(inconst STR) :base_debug {
-char *f;
-
-if (!(interp-pdb-state PDB_BREAK)) {
-f = string_to_cstring(interp, ($1));
-PDB_load_source(interp, f);
-string_cstring_free(f);
-}
+Parrot_debugger_load(interp, ($1));
}
@@ -90,23 +76,7 @@
=cut
op debug_break() :base_debug {
-const char *command;
-
-if (!(interp-pdb-state PDB_BREAK)) {
-interp-pdb-state |= PDB_BREAK;
-interp-pdb-state |= PDB_STOPPED;
-interp-pdb-cur_opcode = (opcode_t *)cur_opcode + 1;
-PDB_set_break(interp, NULL);
-while (!(interp-pdb-state PDB_EXIT)) {
-PDB_get_command(interp);
-command = interp-pdb-cur_command;
-PDB_run_command(interp, command);
-}
-/* RT#42378 this is not ok */
-exit(EXIT_SUCCESS);
-}
-interp-pdb-cur_opcode = (opcode_t *)cur_opcode + 1;
-PDB_set_break(interp, NULL);
+Parrot_debugger_break(interp, cur_opcode);
}
Index: src/debug.c
===
--- src/debug.c (revisión: 28719)
+++ src/debug.c (copia de trabajo)
@@ -36,7 +36,51 @@
IMCC_warning(PARROT_INTERP, ARGIN(const char *fmt), ...);
extern void imcc_init(PARROT_INTERP);
+/*
+ * These constants correspond to the debugger commands.
+ * To map command strings to their numeric values,
+ * use the algorithm from parse_command().
+ */
+enum DebugCmd {
+debug_cmd_b = 25245,
+debug_cmd_c = 25500,
+debug_cmd_d = 25755,
+debug_cmd_e = 26010,
+debug_cmd_h = 26775,
+debug_cmd_i = 27030,
+debug_cmd_l = 27795,
+debug_cmd_n = 28305,
+debug_cmd_p = 28815,
+debug_cmd_q = 29070,
+debug_cmd_r = 29325,
+debug_cmd_s = 29580,
+debug_cmd_t = 29835,
+debug_cmd_w = 30600,
+debug_cmd_int = 175185,
+debug_cmd_run = 176460,
+debug_cmd_num = 174675,
+debug_cmd_str = 179265,
+debug_cmd_pmc = 163455,
+debug_cmd_eval= 277950,
+debug_cmd_help= 282540,
+debug_cmd_info= 281775,
+debug_cmd_list= 295035,
+debug_cmd_load= 268005,
+debug_cmd_next= 297330,
+debug_cmd_quit= 294780,
+debug_cmd_break = 409785,
+debug_cmd_print = 441150,
+debug_cmd_stack = 414120,
+debug_cmd_trace = 405705,
+debug_cmd_watch = 416160,
+debug_cmd_enable = 571455,
+debug_cmd_delete = 588285,
+debug_cmd_script_file = 617610,
+debug_cmd_disable = 772140,
+debug_cmd_continue= 1053405,
+debug_cmd_disassemble = 1903830
+};
/* HEADERIZER HFILE: include/parrot/debug.h */
@@ -357,6 +401,83 @@
/*
+=item Cvoid Parrot_debugger_init
+
+Init the parrot debugger, if not already done.
+
+=item Cvoid Parrot_debugger_load
+
+Load a Parrot source file for the current program.
+
+=item Cvoid Parrot_debugger_break
+
+Break execution and drop into the debugger.
+If we are already into the debugger and is the first time we are
+called set a breakpoint.
+
+When you re run/continue the program begin debugged it will pay
+no attention to the debug ops.
+
+RT#42377: clone the interpreter to allow people to play into the
+debugger and then continue the normal execution of the program.
+
+=cut
+
+*/
+
+void
+Parrot_debugger_init(PARROT_INTERP)
+{
+if (!(interp-pdb)) {
+PDB_t * pdb = (PDB_t *)mem_sys_allocate_zeroed(sizeof (PDB_t));
+
+interp-pdb = pdb;
+pdb-cur_opcode = interp-code-base.data;
+pdb-state |= PDB_RUNNING;
+}
+}
+
+void
+Parrot_debugger_load(PARROT_INTERP, ARGIN_NULLOK(STRING *filename))
+{
+if (!(interp-pdb))
+real_exception(interp, NULL, 0, No debugger);
+else {
+char *f= string_to_cstring(interp, filename);
+
[perl #47794] [BUG] objects - :method doesn't work with :outer()
This appears to have been resolved by jonathan++ in r28716. Way to go Jonathan! Pm
Re: [perl #56166] [BUG] [PATCH] Perl::Critic Version Problems
On Thu, Jun 26, 2008 at 4:18 PM, James Keenan via RT [EMAIL PROTECTED] wrote: FWIW, the part of the patch pertaining to t/codingstd/perlcritic.t did not apply cleanly when I tried it on Linux. That may just indicate that the guts have been ripped out of that file and replaced with mostly new code. Perhaps you could post the complete text of your new version of that file? Thank you very much. kid51 Attached. -- Will Coke Coleda pc.pl Description: Binary data
[perl #56166] [BUG] [PATCH] Perl::Critic Version Problems
Thanks, Coke. On my Linux VM I did not yet have Test::Perl::Critic installed, so I first tested the patch to see if it would DTRT, i.e., skip all. It did. I then installed Test::Perl::Critic via 'cpan' and retested, successfully. (I might add that since the first files to be tested are Configure.pl and the config/*/*.pm modules I maintain, it was gratifying to see all those oks whiz by!) kid51
[perl #42293] [TODO] t/doc/pod.t vs. tools/doc/pod_errors.pl
On Tue Apr 03 21:29:13 2007, coke wrote: These two scripts perform the same basic task, but do so inconsistently. The tools/ script should be removed, and someone should investigate how it's checking the pod (it finds errors in the current distro while the test does not.) -- Will Coke Coleda [EMAIL PROTECTED] Removed in r28732; The primary source of differences is that it was checking _every_ file, including those in the .svn directories. Closing ticket. -- Will Coke Coleda
[perl #41606] [TODO] Add flag to do runtime check on deprecated ops
On Mon Feb 26 02:32:10 2007, kjs wrote:
On Fri Feb 23 14:46:17 2007, [EMAIL PROTECTED] wrote:
hi,
it might be a good idea to add a flag to parrot that checks at runtime
whether any deprecated ops are used.
the flag should be turned off by default; some ops like find_global are
used all over the place, so if it would be
turned on, that would give too many warnings.
Having this flag will help people to stop using those ops (the flag can
be added when doing make test), so we
can remove the ops soon.
The flag should check at runtime, not compile time, because the check
should also be possible when running pbc files.
regards,
kjs
I did some more thinking about this. The point is, we don't want the
engine to check all ops being executed whether they are deprecated. This
would make the runcore slower, so that doesn't really motivate to use
the flag (--check-deprecated-ops or whatever).
Another thing: it is undesirable to have some list of deprecated ops
somewhere in the core that should be updated whenever ops are
deprecated, or after a deprecation cycle, ops are removed (the list to
be checked should be cleaned up).
A much better approach, IMHO, would be to add some annotation to the
.ops file.
Now, an instruction is specified as:
op foo(out PMC) {
/* do something */
goto NEXT();
}
If foo would be deprecated, just add some tag, for instance like so:
deprecated op foo(out PMC) {
}
The ops2c.pl script should then check for the tag deprecated, and if
present, add this line to the op body: (or something a like)
if(FLAGS(DEPRECATED_OPS)) { /* or whatever a flag check looks like */
fprintf(stderr, Warning: instruction 'foo' is deprecated\n);
}
To summarize the advantages of this approach:
1. no messing around with runtime core code
2. the solution is isolated to the point where it should be: the source
of the instruction itself: easy to deprecated ops; easy to remove ops
(no need to change other files)
3. self-documenting .ops files. (is .ops documentation extracted from
the .ops files? -- if so this would be an additional feature, the docs
then can add: DEPRECATED)
4. Not too hard to implement (although I don't really understand
ops2c.pl, it shouldn't be too hard I guess)
5. No overhead for non-deprecated instructions.
Comments are most certainly welcome,
kjs
Attached, find a patch that allows us to specify a :deprecated flag (post op,
ala :flow). It
also adds a new parrot warning (configurable with warningson) level called
PARROT_WARNING_DEPRECATED_FLAG. The patch only applies this flag to getclass.
Comments welcome. (Hopefully sooner than it took me to comment on kjs's last
send on this
ticket. =-). The one thing I'm not sure about is that I'm just using fprintf as
in kjs's original
sample. Could probably stand to actually use parrot IO. I'm also not happy that
it doesn't
show the location of the opcode, but I can live with that for now.
You can see the behavior with:
%cat foo.pir
.include 'include/warnings.pasm'
.sub main
$P1 = getclass 'Integer'
say 'ok'
warningson .PARROT_WARNINGS_DEPRECATED_FLAG
$P1 = getclass 'Float'
.end
%./parrot foo.pir
ok
Warning: instruction 'getclass' is deprecated
--
Will Coke Coleda
Index: src/ops/core.ops
===
--- src/ops/core.ops(revision 28731)
+++ src/ops/core.ops(working copy)
@@ -974,18 +974,11 @@
Turns on warnings categories. Categories already turned on will stay on.
Initial setting is currently all warnings off. Include Fwarnings.pasm to
-access the categories. They are:
+access the categories. Refer to that file for the current list of warnings
+available.
=over 4
-=item .PARROT_WARNINGS_UNDEF_FLAG
-
-=item .PARROT_WARNINGS_IO_FLAG
-
-=item .PARROT_WARNINGS_PLATFORM_FLAG
-
-=item .PARROT_WARNINGS_ALL_FLAG
-
=back
To turn on multiple categories, OR the category numbers together.
Index: src/ops/object.ops
===
--- src/ops/object.ops (revision 28731)
+++ src/ops/object.ops (working copy)
@@ -366,7 +366,7 @@
=cut
-inline op getclass(out PMC, in STR) :object_classes :flow {
+inline op getclass(out PMC, in STR) :object_classes :flow :deprecated {
PMC * const _class = Parrot_class_lookup(interp, $2);
opcode_t * const next = expr NEXT();
@@ -376,8 +376,6 @@
$1 = _class;
goto ADDRESS(next);
-/* real_exception(interp, NULL, UNIMPLEMENTED,
-The 'getclass' opcode has been deprecated, use 'get_class'. See RT
#47972.);*/
}
inline op getclass(out PMC, in PMC) :object_classes :flow {
Index: lib/Parrot/Op.pm
===
--- lib/Parrot/Op.pm(revision 28731)
+++ lib/Parrot/Op.pm(working copy)
@@ -168,8 +168,6 @@
$name .= _ . join( _, @arg_types ) if @arg_types;
-$name = deprecated_$name if (
[perl #48445] [TODO] [NQP] - report undeclared variable usage
On Mon Dec 10 11:49:08 2007, pmichaud wrote: When an NQP program uses a variable that hasn't been previously declared, it should report a useful error message: Use of undeclared variable '$x' at ... Pm Looking at this, there doesn't seem to be a way to write a self-hosted test (in nqp) for this since there's no try/catch equivalent. Can someone add a PIR based TODO test for this (in compilers/nqp/t) that shows the desired (but not yet implemented) behavior? -- Will Coke Coleda
Re: [perl #41606] [TODO] Add flag to do runtime check on deprecated ops
On Thursday 26 June 2008 20:02:18 Will Coleda via RT wrote: Attached, find a patch that allows us to specify a :deprecated flag (post op, ala :flow). It also adds a new parrot warning (configurable with warningson) level called PARROT_WARNING_DEPRECATED_FLAG. The patch only applies this flag to getclass. Comments welcome. (Hopefully sooner than it took me to comment on kjs's last send on this ticket. =-). The one thing I'm not sure about is that I'm just using fprintf as in kjs's original sample. Could probably stand to actually use parrot IO. I'm also not happy that it doesn't show the location of the opcode, but I can live with that for now. +1 from me as-is. ParrotIO stuff will likely have to change in the medium-term anyway, so we'll probably have to modify this code (if we don't remove the ops altogether) at some point anyway. -- c
