Re: First look: Advanced Polymorphism whitepaper
On Wednesday 30 April 2008 21:58:50 Brandon S. Allbery KF8NH wrote: On May 1, 2008, at 0:53 , chromatic wrote: correctness sense. Sadly, both trees and dogs bark.) Hm, no. One's a noun, the other's a verb. Given the linguistic orientation of [Perl 6], it seems a bit strange that the syntax for both is the same: while accessors and mutators are *implemented* as verbs, they should *look* like nouns. Given: my $result = $thingie.bark; ... where $thingie may be a Dog or $thingie may be a Tree, is bark a noun or a verb? Sure, it's a lousy example, but remember the immutable law of OO didactics: all examples must be terrible. Shapes, colors, and cars, -- c
a foundation for Parrot
Off-and-on over the past year there have been sporadic conversations about starting a foundation for Parrot separate from the Perl Foundation. With 1.0 approaching, it's making more and more sense. Parrot will be better able to approach the Python, Ruby, PHP, Lua, etc communities if we're hosted by an organization that's not Perl. It makes sense for the Perl Foundation too, as they work to give equal attention to all Perl 6 implementations. The Perl Foundation fully supports the idea, and is willing to put whatever resources they can behind helping us get the new foundation started. I just wanted to let everyone know that some gears are starting to turn in this direction. We'll work on this the same as we do the rest of Parrot, drafting documents in the wiki so everybody has a chance to contribute, etc. Allison
Re: [perl #53298] [BUG] inheritance not working?
Hi,
dakkar (via RT) wrote:
If I uncomment the $u.boo after the re-assignment to $u, I get a Null
PMC access in get_string()
It looks like inheritance is not working as I'd expect.
To make it work, I have to move the 'set' method into Foo, and
remove all references to Bar.
Thanks for reporting. Initialization of attributes in parent classes
hadn't been implemented; I've done that today. However, the code wasn't
quite right. For attributes in parent classes, you must write them as an
auto-vivification closure of the parent.
$u=Bar.new(Foo{ :x(12) });
Which is implemented now. So now your example with that fix and the one
line uncommented gives:
5
12
9
As a bonus, if you try and do it the way you originally did, you will
now get a more helpful error message too.
This was done in a few patches, but r27268 is the final one that
actually gets your example running.
Thanks,
Jonathan
Re: OK, ::?CLASS not virtual
Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: John M. Dlugosz wrote: And you can use CLASS in a role also, confidant that it will be looked up according to the normal rules when the class is composed using that role, just like any other symbol that is not found when the role is defined. Using ::?CLASS in a role is an error (unless you mean the class surrounding this role's definition, in which case it is a warning). Can a role inherit from a class? If so, to which class does CLASS refer: the inherited one, or the one into which the role is composed? If you have an is Base item in a role, that will apply the inheritance to the composited class when it is used. Whether the role itself inherits depends on how you think about it. In all cases, CLASS will refer to a virtual symbol that becomes the most-derived (complete) class at run time. In an object, CLASS refers to the final dynamic type. It is virtual. For my treatment of the subject, see my spec doc at http://www.dlugosz.com/Perl6/, section 12.5.1 Class names used in methods. I'd be happy to talk more about it in-depth. Also check the mailing list for the discussion Class names are virtual starting on the 20th: Larry, you've wanted to have class names used within a class be virtual. With various degrees of conviction across the synopses, you've wanted classes defined within a class to be overridable, or all classes referenced by a class to be overridable, speculating on whether this is do-able. ... You'll be happy to know that not only is it do-able (once you know what is and is not affected), but it will play a role in making the type system F-bounds quantified. --John
Re: First look: Advanced Polymorphism whitepaper
Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: On Wed, Apr 30, 2008 at 9:58 PM, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: On May 1, 2008, at 0:53 , chromatic wrote: correctness sense. Sadly, both trees and dogs bark.) Hm, no. One's a noun, the other's a verb. Given the linguistic orientation of Perl6, it seems a bit strange that the syntax for both is the same: while accessors and mutators are *implemented* as verbs, they should *look* like nouns. In defense of chromatic's point, both people and syrup run. Sometimes you don't even know the correct part of speech without a backtracking parser or infinite lookahead in English. The green can (continues...) be watered after it has been cut.
Re: First look: Advanced Polymorphism whitepaper
chromatic chromatic-at-wgz.org |Perl 6| wrote: This is why roles-as-types is so important: type inferencers can't infer allomorphism because allomorphism relies on explicitly-marked semantic meanings. What is your nomenclature here? vary in sound without changing its meaning? What are marked semantic meanings? --John
Re: First look: Advanced Polymorphism whitepaper
-- Original message -- From: John M. Dlugosz [EMAIL PROTECTED] Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: On Wed, Apr 30, 2008 at 9:58 PM, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: On May 1, 2008, at 0:53 , chromatic wrote: correctness sense. Sadly, both trees and dogs bark.) Hm, no. One's a noun, the other's a verb. Given the linguistic orientation of Perl6, it seems a bit strange that the syntax for both is the same: while accessors and mutators are *implemented* as verbs, they should *look* like nouns. In defense of chromatic's point, both people and syrup run. Sometimes you don't even know the correct part of speech without a backtracking parser or infinite lookahead in English. The green can (continues...) be watered after it has been cut. And sometime you can't even do it syntactically: Time flies like an arrow. Fruit flies like a banana. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: First look: Advanced Polymorphism whitepaper
Brandon S. Allbery KF8NH wrote:
But there *is* some commonality there, to the extent that both are
motion. This is the kind of thing that spawned this discussion, in
fact: if what matters is motion, there is no reason *not* to substitute
one for the other.
{ draw $gun }: makes a big difference whether you're talking to a
gunfighter or an artist (and if the gunfighter is an artist in her days
off...)
Re: First look: Advanced Polymorphism whitepaper
On Thu, May 01, 2008 at 10:02:27AM -0700, Dave Whipp wrote:
Brandon S. Allbery KF8NH wrote:
But there *is* some commonality there, to the extent that both are motion.
This is the kind of thing that spawned this discussion, in fact: if what
matters is motion, there is no reason *not* to substitute one for the
other.
{ draw $gun }: makes a big difference whether you're talking to a
gunfighter or an artist (and if the gunfighter is an artist in her days
off...)
Duck typing: if it walks like a duck, and talks like a duck, then you'd
better duck, because the person drawing the gun is probably not an artist.
Larry
[perl #53600] config/auto/python.pm unused?
# New Ticket Created by Will Coleda # Please include the string: [perl #53600] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53600 the only place that the config setting has_python is referenced in the distro is in config/auto/python.pm itself; we can probably remove this step, and any related tests. -- Will Coke Coleda
[perl #53602] remove or convert tools/docs/search-ops.py
# New Ticket Created by Will Coleda # Please include the string: [perl #53602] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53602 We shouldn't rely on having python available to developers. If this script is worth keeping, it should be converted to perl. -- Will Coke Coleda
Re: Parrot and Dynamic Loading (Mainly MacOS X)
On Thursday 01 May 2008 12:07:47 Alberto Simões wrote: There was a test (test three from t/examples/library.t) that was failing and failing under MacOS X. That test relies on libpcre that is not available by default on MacOS X. It seems to me that the test should skip itself if dynamic loading of libpcre fails. If you use MacPort to install the library, it will be placed under /opt/local/lib. The configure step I added to the configure system will detect it, but the test will fail, because pcre.pir can't locate the library. My current solution was to export DYLD_FALLBACK_LIBRARY_PATH including the /opt/local/lib path, but I think this is not a good solution. I don't know much about Mac OS X, but there should be a way to add this path to the list of paths ld.so (or the Darwin equivalent) searches. If we are going to rely on DYLD_FALLBACK_LIBRARY_PATH, we should make a configure step to check if all libraries that will be loaded dynamically are available using the current DYLD_FALLBACK_LIBRARY_PATH. The other option, might be a -L flag to parrot, so we can add those extra library paths there. This second solution would also need a configure step to find out which libraries paths should be used for each test. I think this might happen as well for Linux, and LD_LIBRARY_PATH. I'm not sure. Why add special logic to Parrot to find poorly-installed libraries? If you install a dynamic library outside of your normal system library paths, no other program will find it. If you want other things to find it, add it to your paths, or add its path to your list of dynamic loading paths. I vote for fixing the buggy test (no pcre, no reason to run the tests) but not working around standard dynamic library loading. -- c
Re: Parrot and Dynamic Loading (Mainly MacOS X)
On Thu, May 01, 2008 at 12:19:06PM -0700, chromatic wrote: I'm not sure. Why add special logic to Parrot to find poorly-installed libraries? If you install a dynamic library outside of your normal system library paths, no other program will find it. If you want other things to find it, add it to your paths, or add its path to your list of dynamic loading paths. I vote for fixing the buggy test (no pcre, no reason to run the tests) but not working around standard dynamic library loading. +1 Pm
t/pugs/operator/arith.t
Jesse asked about getting t/pugs/operator/arith.t to run
on Rakudo, as written arith.t depends on the .nextwith
capability from S06. For example:
sub tryok ($ok, $todo) {
if ($todo) {
ok.nextwith($ok,$todo, :todo);
} else {
ok.nextwith($ok);
}
}
I'm of the opinion that we shouldn't require .nextwith to
be implemented for testing something basic like arithmetics,
so if we keep the above I propose changing ok.nextwith() to
ok() calls for now.
In general, I think that tests should only need a rather
limited set of functions and Perl 6 features, and something
like .nextwith seems to fall outside of that. So as far
as we can, I think the test suite ought to stick to things
like:
ok($cond)
ok($cond, $desc)
is($got, $expected)
is($got, $expected, $desc)
isnt($got, $expected)
isnt($got, $expected, $desc)
is_approx($got, $expected)
is_approx($got, $expected, $desc)
Note that in the test suite 'todo' and 'skip' are often
handled by fudge as opposed to being an optional argument
to ok().
In the case of arith.t, I don't quite see the need for
the tryok() definition and tryeq(). It seems that it
would be much cleaner and more consistent for arith.t
to use
is 13 % 4, 1;
is -13 % 4, 3;
is_approx13e21 % 4e21 - 1e21, 0;
is_approx -13e21 % 4e21 - 3e21, 0;
instead of
tryeq 13 % 4, 1;
tryeq -13 % 4, 3;
tryok abs( 13e21 % 4e21 - 1e21) $limit;
tryok abs(-13e21 % 4e21 - 3e21) $limit;
and locally defined try* subs. (There's also the point
that 'try' is a keyword in Perl 6, and 'tryeq' and 'tryok'
don't seem to have anything obvious to do with that 'try'.)
Pm
[perl #53606] [TODO] pge - change syntax of .foo: arg subrule calls
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #53606] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53606 S05 has changed the meaning of colons following assertions, such that .foo: Some important message must now be written as .foo: 'Some important message' In the near term PGE will add support for recognizing quotes following the colon and parsing accordingly. Well deprecate the non-quoted form, but leave it in place for a while to allow existing Perl6Regex users to convert to the new quoted form. After that's been done, we'll eliminate the non-quoted form from PGE. S05 further generalizes the syntax to allow multiple arguments after the colon, as in: .foo: 'message', 13, $xyz PGE doesn't support this yet, and we probably won't worry about multiple arguments until Rakudo is a bit farther along and we can do a better job of argument parsing. There is also the question of handling arguments for languages other than Perl 6, which is why I'm postponing this entire issue for now. Pm
Re: rand in Rakudo
Following up on this, I found it odd that '~~' didn't work in the rps.pl
script (or sleep() ;-)
if $you ~~ $my { say 'Draw.' } # don`t work (
as in:
./perl6 languages/perl6/t/02-test-pm/3-output.t
Statement not terminated properly at line 26, near :P5/output
current instr.: 'parrot;PGE::Util;die' pc 120
(runtime/parrot/library/PGE/Util.pir:82)
called from Sub 'parrot;Perl6::Grammar;statementlist' pc 16752
(src/gen_grammar.pir:2398)
called from Sub 'parrot;Perl6::Grammar;statement_block' pc 13923
(src/gen_grammar.pir:1384)
called from Sub 'parrot;Perl6::Grammar;TOP' pc 10765
(src/gen_grammar.pir:204)
called from Sub 'parrot;PCT::HLLCompiler;parse' pc 564
(src/PCT/HLLCompiler.pir:348)
called from Sub 'parrot;PCT::HLLCompiler;compile' pc 440
(src/PCT/HLLCompiler.pir:291)
called from Sub 'parrot;PCT::HLLCompiler;eval' pc 755
(src/PCT/HLLCompiler.pir:450)
called from Sub 'parrot;PCT::HLLCompiler;evalfiles' pc 1067
(src/PCT/HLLCompiler.pir:587)
called from Sub 'parrot;PCT::HLLCompiler;command_line' pc 1246
(src/PCT/HLLCompiler.pir:676)
called from Sub 'parrot;Perl6::Compiler;main' pc 9205 (perl6.pir:183)
*** glibc detected *** double free or corruption (!prev): 0x084f85b8 ***
*** glibc detected *** double free or corruption (out): 0x08599ee0 ***
which is what I was seeing w/ rps.pl Line 26 of the test file is:
my $file = $?FILE;
$file ~~ s:P5/output.t/script.pl/;
So, should we be worrying about this not working or is it too early? Hmm,
it fails this way too
languages/perl6 ../../parrot perl6.pbc t/02-test-pm/3-output.t
Statement not terminated properly at line 26, near :P5/output
I'd guess it's a parsing issue on ~~ Hmm, make spectest
...
Files=82, Tests=670, 247 wallclock secs ( 0.50 usr 0.23 sys + 242.52 cusr
3.92 csys = 247.17 CPU)
So I guess it's not odd ;-
a
---
Andy Bach
Systems Mangler
Internet: [EMAIL PROTECTED]
Voice: (608) 261-5738 Fax: 264-5932
When angry, count to four; when very angry, swear.
Mark Twain
string documentation: PDD and docs/strings.pod
hi, it seems that there is overlap in the strings pdd (28) and the strings implementation document in docs/strings.pod. I'm not sure if this is a good idea; I think these should be merged. If so, I'll open a ticket to do so (but wanted to check first) kjs
Re: Parrot and Dynamic Loading (Mainly MacOS X)
chromatic wrote: I vote for fixing the buggy test (no pcre, no reason to run the tests) but not working around standard dynamic library loading. It is not that easy (I think). Also, I do not know much about these things, so let me try explain some more details. 1) the configure step finds pcre correctly (using macports specific code). Thus, pcre exists on the system. 2) the library is not installed in a precarious place. We are talking of one of the two major ways MacOS people have to install software (find and macports), both of which will have this problem. 3) there are other libraries (like ICU) that are on the same place. Parrot gets linked with it, and works without any kind of environment variable. This should mean that gcc stores the path somewhere, I would say. 4) that I know (and I readed dyld man page) there isn't a ld.so.conf or whatever under MacOS. As this is not just a problem that affects one test, but will affect all dynamic library loading that is not Apple standard, I think we should look to it with some care. Also, note that some standard modules, like OpenGL, are doing this by brute force, testing specific hard-coded libraries. That is not at all a good option. Cheers ambs -- Alberto Simões - Departamento de Informática - Universidade do Minho Campus de Gualtar - 4710-057 Braga - Portugal
Parrot being too much linked?
Hi Doing an otool -l (and some greps) to check libraries from the parrot binary, I got: name /usr/lib/dyld (offset 12) name /Users/ambs/Projects/parrot/blib/lib/libparrot.dylib (offset 24) name /usr/lib/libSystem.B.dylib (offset 24) name /opt/local/lib/libicuuc.38.dylib (offset 24) name /opt/local/lib/libicudata.38.dylib (offset 24) name /usr/lib/libutil.dylib (offset 24) name /opt/local/lib/libgmp.3.dylib (offset 24) name /opt/local/lib/libreadline.5.2.dylib (offset 24) name /opt/local/lib/libpcre.0.dylib (offset 24) name /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (offset 24) name /System/Library/Frameworks/GLUT.framework/Versions/A/GLUT (offset 24) name /usr/lib/libcrypto.0.9.7.dylib (offset 24) name /opt/local/lib/libintl.8.dylib (offset 24) name /usr/lib/libstdc++.6.dylib (offset 24) name /usr/lib/libgcc_s.1.dylib (offset 24) From these, I would say OpenGL, GLUT and libpcre (at least) should not be linked to parrot. I think they are used by dynamic loading. Or not? :) Cheers ambs -- Alberto Simões - Departamento de Informática - Universidade do Minho Campus de Gualtar - 4710-057 Braga - Portugal
Re: Parrot being too much linked?
On Thursday 01 May 2008 13:07:10 Alberto Simões wrote: Doing an otool -l (and some greps) to check libraries from the parrot binary, I got: name /usr/lib/dyld (offset 12) name /Users/ambs/Projects/parrot/blib/lib/libparrot.dylib (offset 24) name /usr/lib/libSystem.B.dylib (offset 24) name /opt/local/lib/libicuuc.38.dylib (offset 24) name /opt/local/lib/libicudata.38.dylib (offset 24) name /usr/lib/libutil.dylib (offset 24) name /opt/local/lib/libgmp.3.dylib (offset 24) name /opt/local/lib/libreadline.5.2.dylib (offset 24) name /opt/local/lib/libpcre.0.dylib (offset 24) name /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (offset 24) name /System/Library/Frameworks/GLUT.framework/Versions/A/GLUT (offset 24) name /usr/lib/libcrypto.0.9.7.dylib (offset 24) name /opt/local/lib/libintl.8.dylib (offset 24) name /usr/lib/libstdc++.6.dylib (offset 24) name /usr/lib/libgcc_s.1.dylib (offset 24) From these, I would say OpenGL, GLUT and libpcre (at least) should not be linked to parrot. I think they are used by dynamic loading. Agreed. -- c
Re: Exceptions and Concurrency Questions
chromatic wrote: From the wiki at http://www.perlfoundation.org/parrot/index.cgi?concurrency_tasks : * Deprecate rethrow. The replacement seems to be that an exception handler declines to handle an exception. This is the default behavior; an exception handler explicitly notifies the scheduler that it has handled (or will handle) the exception by using the handled opcode. PDD 25 suggests that there are Task PMCs which represent or encapsulate these exceptions. Presumably the handled opcode will remove the exception Task from the scheduler and resume execution at the appropriate point. Presumably also the declining to handle an exception (the replacement for rethrow) will cause the scheduler to move to the next exception handler in its list? If so, how do we model this control flow? I planned to handle these parts of the code myself, so I only noted enough to use as a checklist when I'd finished the task. Essentially, we're ripping out the entire underpinning of the old exception system, and replacing it with the concurrency scheduler, while still preserving the same interface. The deprecation of rethrow will have to come towards the end of the transition, after exceptions are moved over to the concurrency scheduler (it can be deleted when it no longer does anything). More on control flow tomorrow. * Change 'real_exception' to use concurrency scheduler. Does this mean to change the opcode and its backing functions to create a Task PMC, an Exception PMC, or both? If so, where does control flow go with the scheduler works asynchronously? Or does the scheduler handle exceptions as they occur in real-time? A later task: Exception PMCs are polymorphically substitutable for Tasks. (Event PMCs are also.) Ultimately Exception may inherit from Task, but for now it's not necessary. * 'throw_exception' and 'rethrow_exception' change to something more like 'Parrot_cx_handle_tasks'. ... suggests that these functions may schedule the exception (if necessary) and then immediately run the scheduler in the current interpreter. Yes. * 'push_exception' changes to 'Parrot_cx_add_handler'. The latter function already exists. Merge or rename? Note that exception handling has to stop looking in interp-dynamic_env for this to work. 'push_exception' is what registers the exception handler for later lookup (terrible name for it). With the new implementation, 'Parrot_cx_add_handler' will register the exception handler (with the concurrency scheduler). IIRC, all it needs is to change the check for a valid handler type to also allow exception handlers (don't have time to verify at the moment). * 'count_exception_handlers' changes to access the concurrency scheduler (a simple method call or keyed access). There's currently no way of filtering handlers in the scheduler by parentmost type; should there be one? Yes. Allison
[perl #53600] config/auto/python.pm unused?
Coke, This has been come up a couple of times either on list or on #parrot. And the same question has been raised about config/auto/m4.pm. Other things being equal, I'm in favor of this. Hey! Two fewer config steps to have to maintain or test! But then I grepped for the string 'python' (upper or lower case) in the distro and came up with the list of files attached. Before we remove config/auto/python.pm, we should assess what the impact would be on each of these 81 files -- which includes a lot of source code. kid51 ./ChangeLog ./compilers/imcc/pbc.c ./config/auto/python.pm ./CREDITS ./docs/art/pp001-intro.pod ./docs/art/pp003-oop.pod ./docs/book/ch01_overview.pod ./docs/book/ch02_getting_started.pod ./docs/book/ch07_architecture.pod ./docs/faq.pod ./docs/imcc/imcfaq.pod ./docs/intro.pod ./docs/overview.pod ./docs/pct/gettingstarted.pod ./docs/pdds/draft/pdd06_pasm.pod ./docs/pdds/draft/pdd29_compiler_tools.pod ./docs/pdds/pdd15_objects.pod ./docs/pdds/pdd17_pmc.pod ./docs/pdds/pdd21_namespaces.pod ./docs/pdds/pdd25_concurrency.pod ./docs/pdds/pdd26_ast.pod ./docs/vtables.pod ./examples/benchmarks/fib.py ./examples/benchmarks/oo1.pasm ./examples/benchmarks/oo2.pasm ./examples/benchmarks/oofib.py ./examples/benchmarks/primes2.py ./examples/benchmarks/vpm.py ./examples/mops/mops.py ./examples/mops/README ./examples/shootout/revcomp.pir ./include/parrot/exceptions.h ./include/parrot/parrot.h ./include/parrot/sub.h ./languages/dotnet/t/harness ./languages/jako/examples/python.jako ./languages/LANGUAGES_STATUS.pod ./languages/lua/t/harness ./languages/parrot_compiler/t/harness ./languages/PIR/src/pasm/pasm.pg ./languages/plumhead/docs/antlr3.pod ./languages/pugs/t/harness ./languages/pynie/pynie.pir ./languages/pynie/README ./languages/pynie/src/builtins/funcs.pir ./languages/pynie/src/parser/Grammar.pg ./languages/pynie/src/parser/indent.pir ./languages/scheme/t/harness ./languages/t/harness ./lib/Parrot/Configure/Step/List.pm ./lib/Parrot/Distribution.pm ./lib/Parrot/Docs/File.pm ./lib/Parrot/Test/APL.pm ./lib/Parrot/Test/Punie.pm ./MANIFEST ./MANIFEST.generated ./NEWS ./ports/debian/control.in ./ports/macports/Portfile ./README_win32.pod ./src/call_list.txt ./src/exceptions.c ./src/gc/dod.c ./src/io/io_private.h ./src/ops/experimental.ops ./src/pmc/array.pmc ./src/pmc/complex.pmc ./src/pmc/fixedpmcarray.pmc ./src/pmc/slice.pmc ./src/pmc/string.pmc ./src/pmc/sub.pmc ./src/spf_render.c ./src/string.c ./t/codingstd/linelength.t ./t/compilers/json/from_parrot.t ./t/pmc/bigint.t ./t/pmc/object-mro.t ./t/pmc/string.t ./t/steps/auto_python-01.t ./tools/dev/parrotbench.pl ./tools/docs/search-ops.py
[perl #53602] remove or convert tools/docs/search-ops.py
On Thu May 01 11:20:22 2008, coke wrote: We shouldn't rely on having python available to developers. If this script is worth keeping, it should be converted to perl. *Is* the script worth keeping? If someone can describe how it is useful, then I will take a crack at perl-izing it. kid51
Re: [perl #53602] remove or convert tools/docs/search-ops.py
On Thursday 01 May 2008 15:51:17 James Keenan via RT wrote: *Is* the script worth keeping? If someone can describe how it is useful, then I will take a crack at perl-izing it. I believe that you give it the name of an opcode, and it tells you which src/ops/*.ops file contains it and any documentation for that opcode. I'd use it, if it worked. -- c
