Re: PGE tests wanted (was P6GE tests wanted)
I'm currently writing few tests for PGE. So far I've found 2 failing
tests: (with parrot_2004-12-16_160001.tar.gz)
p6rule_like('abcabbc', 'ab+?bc', qr/0: abbc @ 3/, '');
p6rule_like('abbcabbbc', 'ab+?', qr/0: ab @ 0/, '');
output from perl t/harness mytests/*.t is attached.
Larry mentioned 're_tests' file from perl5-source. Is anyone working on
it currently? I could make a simple script to convert at least some of
it to this pge-testing format which uses p6rule_*
mytests/capture# Failed test (lib/Parrot/Test/PGE.pm at line 73)
# 'error:imcc:parse error, unexpected LABEL, expecting
IDENTIFIER or PARROT_OP
# in file 'EVAL_1' line 136
# '
# doesn't match '(?-xism:0: abbc @ 3)'
# '(cd . ./parrot
/home/malaire/omat/downloads/parrot/mytests/capture_6.imc)' failed with exit
code 17
# Failed test (lib/Parrot/Test/PGE.pm at line 73)
# 'error:imcc:parse error, unexpected LABEL, expecting
IDENTIFIER or PARROT_OP
# in file 'EVAL_1' line 134
# '
# doesn't match '(?-xism:0: ab @ 0)'
# '(cd . ./parrot
/home/malaire/omat/downloads/parrot/mytests/capture_7.imc)' failed with exit
code 17
# Looks like you failed 2 tests of 7.
dubious
Test returned status 2 (wstat 512, 0x200)
Scalar found where operator expected at (eval 158) line 1, near 'int' $__val
(Missing operator before $__val?)
DIED. FAILED tests 6-7
Failed 2/7 tests, 71.43% okay
Failed 1/1 test scripts, 0.00% okay. 2/7 subtests failed, 71.43% okay.
Failed Test Stat Wstat Total Fail Failed List of Failed
---
mytests/capture.t2 512 72 28.57% 6-7
Re: runops_args vs NCI
Sam Ruby wrote: However, VTABLE_invoke on NCI methods is where the real work is done (including reading from and writing to registers), and a null dest is returned. Ouch. Sorry, probably cut'n'paste code, relicts or whatever. runops_* isn't supposed to be called for NCI methods. It's for running PASM opcodes. A NCI methods wraps a C function to be callable by PASM. If we are calling a NCI function from C, we can run the code diretly too. I'll fix that. - Sam Ruby leo
Re: Context, wrappers, and rules
Sam Ruby wrote:
Leopold Toetsch wrote:
You'd need in pyclass.pmc:
PMC* get_repr() {
return pmc_new_string( ... class ...)
}
In this case, there is a Python specific default. In other cases, there
are other Python specific behaviors like mapping not found to an
exception or to None. In short, I don't see wrappers going away.
Yes, I already said that some methods might need either a wrapper or
just simpler the class implementes the method.
The problem with you code is: you call again VTABLE_find_method and
then, if a method is found, run_meth_fromc_args. This is already done by
Parrot eventually, you are already in PyClass.__repr__. No redispatch is
needed, just return a string.
get_repr is overloadable. Being overloadable is the norm rather than
the exception in Python.
Yes, of course. But that's part of the dispatch that Parrot is doing,
not part of *each* method in PyClass or such. If get_repr was overloaded
then Parrot runs the user code.
Again:
STRING* get_repr() {
PMC *repr = VTABLE_find_method(INTERP, SELF, REPR);
if (repr) {
PMC *temp = Parrot_run_meth_fromc_args(INTERP, repr, SELF, REPR
This part is done in the run-core. The HLLs part is to install a
function with add_method that is found if needed.
* Parrot knows common type names (Integer, Float, String, Bool, ...)
of the supported languages
The alternative (which is supported today) is that callers pass in a PMC
which defines a morph method which maps common type names to language
specific alternatives.
Well and this scheme doesn't match overloaded methods. So we'd have two
different calling conventions, which of course would need glue code to
make them compatible. We don't need that glue code or wrapper, if
overloaded function syntax matches the internal C implementation.
The advantage of what exists today is that adding a new language does
not require any changes to Parrot. The caller defines the mapping.
Such a mapping is easily extendible. New languages aren't added
silently, Parrot needs to know a few bits about the HLL.
* all dispatch is based on VTABLE_find_method
Just to be clear, in the cases where a wrapper is needed (which I would
argue is the majority of cases), this works out to be: a call to
VTABLE_find_method for the wrapper which in turn uses VTABLE_find_method
to access the real logic.
No. VTABLE_find_method locates the very method that should be run. Being
it a C function or a user provided subroutine. So when e.g.
Parrot_PyInt_divide_PyInt is called, you know exactly the class (in case
of MMD both classes). As you know that the base class is Integer, you
can just call the baseclass function directly, if you desire so.
A user can't insert another __bases__ in core classes, so that's save.
For overloaded methods again the pair add_method/find_method is doing
the job. If the result of find_method is a Sub PMC, the run-core runs
the function.
Again, just to be clear: this hinges on dual assumptions: (1) that
wrappers aren't needed in the majority of cases,
Yes. Basic mathematical functions are just the same in Python or Perl6
or whatever.
... and (2) every time
someone gets or sets a method, a mapping can be done from language
defined names to Parrot conventions.
Of course. How else would you be able to overload add Px, Py, Pz if
you can't detect that certain manipulations of attributes have that effect?
Note that in Python, all attributes may potentially be a method.
Yes. Your implementation of find_method has to cope with it. You need
that anyway.
- Sam Ruby
leo
Re: cvs commit: parrot vtable.tbl
Sam Ruby wrote: Are namespaces subject to garbage collection? Classes may be created on the fly in Python, and disapear just as quickly. In Python as well as in Perl. We have to deal with that anyway. Perl6 has the notion of lexically scoped multimethods. Operator overloading only for one specific scope. In the example, two objects with the same class have different implementations of a given method. Fine. The find_method call has to consult the properties of the object too. Furthermore, every assignment to any property of any instance has the potential of invalidating whatever caches you may have. The assignment of a Sub PMC, yes. But if your implementation of find_method is able to locate a method now, you know already where and in which order you are searching. And if the implementation can overload e.g. a add method, you know where you have to call add_method to achieve that effect. I don't see a problem here. Worst case is an uncached find_method call as you are doing now anyway in e.g. PyClass. - Sam Ruby leo
RE: [ANNOUNCE] Test::Simple/More/Builder 0.54 (problem with signa ture?)
Michael G Schwern wrote on 16 December 2004 23:06 On Thu, Dec 16, 2004 at 12:59:00PM -, Orton, Yves wrote: Ah, sorry. I didnt understand. Im just curious if i alter this file this will affect all make dist commands? Only if that module doesn't have its own MANIFEST.SKIP. Ok, that makes sense. Is there any chance the default could have .bak added in future releases? I've considered that many times. I'll slap it in. Thank you. :-) Also will the fact that some of the patterns depend on *NIX style paths be an issue on Win32? Im guessing not, but i think its worth asking. No, MANIFEST files are always Unixy. Ok, good to know. And no the version on my machine doesnt look (exactly) like either one you linked to: Ok, that's good enough. If you throw in pmfiles.dat$ that should solve your Module::Signature problems. Great. Thanks. Cheers, Yves
Re: runops_args vs NCI
Leopold Toetsch wrote: Sam Ruby wrote: However, VTABLE_invoke on NCI methods is where the real work is done (including reading from and writing to registers), and a null dest is returned. Ouch. Sorry, probably cut'n'paste code, relicts or whatever. runops_* isn't supposed to be called for NCI methods. It's for running PASM opcodes. A NCI methods wraps a C function to be callable by PASM. If we are calling a NCI function from C, we can run the code diretly too. I'll fix that. I have a number of cases (filter, map, reduce), where I am passed an arbirary sub and need to call it. I should not have to know how the sub is implemented. So, what you are telling me is that I need to clone runops_args and fix it right. I'll do that. - Sam Ruby
Re: runops_args vs NCI
Sam Ruby wrote: Leopold Toetsch wrote: Sam Ruby wrote: However, VTABLE_invoke on NCI methods is where the real work is done (including reading from and writing to registers), and a null dest is returned. Ouch. Sorry, probably cut'n'paste code, relicts or whatever. runops_* isn't supposed to be called for NCI methods. It's for running PASM opcodes. A NCI methods wraps a C function to be callable by PASM. If we are calling a NCI function from C, we can run the code diretly too. I'll fix that. I have a number of cases (filter, map, reduce), where I am passed an arbirary sub and need to call it. I should not have to know how the sub is implemented. Just invoke it. So, what you are telling me is that I need to clone runops_args and fix it right. I'll do that. Argh. I didn't tell you that. The interface to run an arbitrary piece of code is VTABLE_invoke. The runops_fromc* functions run *opcodes* from inside C. - Sam Ruby leo
Re: runops_args vs NCI
Leopold Toetsch wrote: Sam Ruby wrote: Leopold Toetsch wrote: Sam Ruby wrote: However, VTABLE_invoke on NCI methods is where the real work is done (including reading from and writing to registers), and a null dest is returned. Ouch. Sorry, probably cut'n'paste code, relicts or whatever. runops_* isn't supposed to be called for NCI methods. It's for running PASM opcodes. A NCI methods wraps a C function to be callable by PASM. If we are calling a NCI function from C, we can run the code diretly too. I'll fix that. I have a number of cases (filter, map, reduce), where I am passed an arbirary sub and need to call it. I should not have to know how the sub is implemented. Just invoke it. So, what you are telling me is that I need to clone runops_args and fix it right. I'll do that. Argh. I didn't tell you that. The interface to run an arbitrary piece of code is VTABLE_invoke. The runops_fromc* functions run *opcodes* from inside C. Grrr. First you tell me: Crunops is a low-level function that awaits all properly setup. Around that are more function that e.g. create a return continuation and do argument or returnvalue passing. Just use one of these functions as delegate.c does. To which I respond: I *am* using Parrot_run_meth_fromc_args, just like delegate.c does. Now you tell me, Just invoke it. But I need to do more than that. I need to do what Parrot_run_meth_fromc_args is attempting to do (i.e., create a return continuation and do argument or returnvalue passing.), but correctly. - Sam Ruby
Re: runops_args vs NCI
Sam Ruby wrote: But I need to do more than that. I need to do what Parrot_run_meth_fromc_args is attempting to do (i.e., create a return continuation and do argument or returnvalue passing.), but correctly. 1) runops_fromc and friends are running *opcodes*, nothing else 2) the functions are working, nothing needs fixing here. I've already stated several times: let's adjust Parrot's method dispatch and overloaded method signatures, so that it's directly usable for target languages. When that is done, you can get rid of all the additional dispatch functions. - Sam Ruby leo
Re: runops_args vs NCI
Sam Ruby wrote:
I have a number of cases (filter, map, reduce), where I am passed an
arbirary sub and need to call it. I should not have to know how the sub
is implemented.
I'd a look at map and friends now. You are running code that has a
signature of PP. You'd need additionally:
if (func-vtable-base_type == enum_class_NCI) {
typedef PMC* (*func_pp)(Interp*, PMC*);
func_pp cfunc = (func_pp) D2FPTR(PMC_struct_val(func));
item = (cfunc)(interpreter, item);
}
else { ...
You could of course add a general call_PP wrapper that handles both
cases. But as you did already replace the general runops_args with a
hand-crafted call setup, adding above lines should do it.
leo
Re: runops_args vs NCI
Leopold Toetsch wrote: Sam Ruby wrote: But I need to do more than that. I need to do what Parrot_run_meth_fromc_args is attempting to do (i.e., create a return continuation and do argument or returnvalue passing.), but correctly. 1) runops_fromc and friends are running *opcodes*, nothing else 2) the functions are working, nothing needs fixing here. I've made a clone of these functions, and made the relevant fixes to my copy. Hopefully someday this will get refactored back into Parrot. For the record, in the test case I provided, I was calling Parrot_run_meth_fromc_args twice. The first time with a real Sub. One implemented with opcodes. Or, as you prefer to say it, *opcodes*. It was this call that did not restore the context interpreter-ctx.bp. As near as I can tell, this path is identical to the usage in classes/delegate.c. In other words, it is an accident waiting to happen. Take a look at Parrot_PyClass_runops_fromc. If you do, you will see that I am only restoring the value of interpreter-ctx.bp if dest is non-zero. Think about it. The second time I called Parrot_run_meth_fromc_args, it was with an NCI method. The only problem is that in this call, the parameters were set into registers after the invoke call. I believe it to be customary to set the parameters into registers prior to the invoke call. In fact, I have logic in PyFunc.pmc (again which is used to invoke Python functions which are implemented in opcodes, er, I mean *opcodes*), which depends on things happening in this order in order to handle defaults and varargs. I've already stated several times: let's adjust Parrot's method dispatch and overloaded method signatures, so that it's directly usable for target languages. When that is done, you can get rid of all the additional dispatch functions. I am not interested in discussing this any more. The current Parrot has bugs. I've notified you of a number of them. You are apparently not interested as you would prefer to rewrite Parrot instead. Undoubtably, at that time it will have a different set of bugs. At which point, undoubtably, the process will repeat. Onward. - Sam Ruby
Re: $SIG{__DIE__} should be localized and cleared at the start of an eval block
I agree with you but an alternative you didn't mention is to start off your die handler with: die @_ if $^S;
Re: runops_args vs NCI
Sam Ruby wrote: I've made a clone of these functions, and made the relevant fixes to my copy. As you said, that's your time. You can clone half of Parrot core for experiments. Hopefully someday this will get refactored back into Parrot. The code for running PASM/PIR code is fine. The second time I called Parrot_run_meth_fromc_args, it was with an NCI method. The only problem is ... ... that you are calling the wrong function during your handrolled and unneeded redispatch. Why are you are creating a return continuation for calling a C function? Why do you pass registers according to pdd03 to a C function? Why do you execute a C function with a new context structure? *runops_args* is running *opcodes*. A NCI fuction is a thin wrapper around a piece of C code. I am not interested in discussing this any more. Sam, it's a big difficult to tell you that the current approach of implementing Python will not work, because as soon as I say so, you gonna stop discussing necessary issues. The current Parrot has bugs. I've notified you of a number of them. Sure - And, yes, thanks your notice I've fixed one today. ... You are apparently not interested as you would prefer to rewrite Parrot instead. Make it workable. Complete. Which admittedly needs some rewrite, yes. Such is life. Undoubtably, at that time it will have a different set of bugs. At which point, undoubtably, the process will repeat. No, there are of course no bugs in Parrot final, never ;) Onward. - Sam Ruby leo
Re: PGE tests wanted (was P6GE tests wanted)
On Fri, Dec 17, 2004 at 10:21:40AM +0200, Markus Laire wrote:
I'm currently writing few tests for PGE. So far I've found 2 failing
tests: (with parrot_2004-12-16_160001.tar.gz)
p6rule_like('abcabbc', 'ab+?bc', qr/0: abbc @ 3/, '');
p6rule_like('abbcabbbc', 'ab+?', qr/0: ab @ 0/, '');
Woops, the compiled output had an extraneous colon in the PIR
code on line 239 of pge_gen.c. Now fixed in CVS -- it only
would show up on lazy quantifications where the minimum number
of repetitions was less than zero.
Larry mentioned 're_tests' file from perl5-source. Is anyone working on
it currently? I could make a simple script to convert at least some of
it to this pge-testing format which uses p6rule_*
I'm not aware of anyone working on it currently, so please go ahead
and do this!
Many thanks!
Pm
Re: RT#31859, Plain ole Hash
Leopold Toetsch wrote: - The NCI method has an implementation in Hash and in PerlHash, this is not nice The NCI method is automatically inherited from Hash. But as it's a python method it'll be removed from Hash anyway. Any objections to the NCI methods being removed from Coroutine(next), Hash(fromkeys), Iterator(next), and PerlHash(fromkeys) now? - Sam Ruby
[perl #33092] IMCC sub/opcode invocation conflict
# New Ticket Created by Dave Brondsema # Please include the string: [perl #33092] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=33092 If I define a sub as: .sub print .param string arg print arg .end Then I cannot invoke it using the IMCC short way: print(hello) because I get this error: error:imcc:op not found 'print' (print0) But I have to invoke it like this: find_global $P0, print $P0(hello) -- Dave Brondsema : [EMAIL PROTECTED] http://www.brondsema.net : personal http://www.splike.com : programming http://csx.calvin.edu : student org
Re: [perl #33092] IMCC sub/opcode invocation conflict
Dave Brondsema writes: # New Ticket Created by Dave Brondsema # Please include the string: [perl #33092] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=33092 If I define a sub as: .sub print .param string arg print arg .end Then I cannot invoke it using the IMCC short way: print(hello) because I get this error: error:imcc:op not found 'print' (print0) You can invoke it the almost short way: print(hello) You can also define the sub like this: .sub print .param string arg print arg .end Which is quite nice for compiler writers. Luke
[perl #33094] [PATCH] Clean Up POD Errors and Warnings
# New Ticket Created by chromatic # Please include the string: [perl #33094] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=33094 Here's a patch to clean up all of the POD errors I found and most of the warnings, too. If no one objects, I'll commit it myself in a few days. Some of the remaining warnings are legitimate differences of opinion between podchecker and the sane world. Still, cleaner is better. -- c Index: parrotbug === RCS file: /cvs/public/parrot/parrotbug,v retrieving revision 1.35 diff -u -r1.35 parrotbug --- parrotbug 16 Sep 2004 12:57:23 - 1.35 +++ parrotbug 18 Dec 2004 00:35:28 - @@ -709,12 +709,10 @@ parrotbug - Parrot Bug Reporter - =head1 SYNOPSIS % ./parrotbug [options] [actions] - =head1 DESCRIPTION A program to help generate bug reports about parrot, and mail them. Index: classes/bigint.pmc === RCS file: /cvs/public/parrot/classes/bigint.pmc,v retrieving revision 1.20 diff -u -r1.20 bigint.pmc --- classes/bigint.pmc 16 Dec 2004 09:17:49 - 1.20 +++ classes/bigint.pmc 18 Dec 2004 00:35:28 - @@ -359,9 +359,6 @@ =over 4 -*/ -/* - =item CPMC* instantiate() Object constructor. SELF is a BigInt Class object. Return a new Index: classes/genclass.pl === RCS file: /cvs/public/parrot/classes/genclass.pl,v retrieving revision 1.22 diff -u -r1.22 genclass.pl --- classes/genclass.pl 22 Feb 2004 17:48:41 - 1.22 +++ classes/genclass.pl 18 Dec 2004 00:35:28 - @@ -9,7 +9,7 @@ =head1 SYNOPSIS % perl classes/genclass.pl Foo Foo.pmc - + =head1 DESCRIPTION Use this script to generate a template PMC file with stubs for all the @@ -18,7 +18,7 @@ To see what a minimal PMC looks like, create a PMC template and compile it to C. - + cd classes perl genclass.pl Foo foo.pmc perl pmc2c.pl foo.pmc Index: classes/hash.pmc === RCS file: /cvs/public/parrot/classes/hash.pmc,v retrieving revision 1.1 diff -u -r1.1 hash.pmc --- classes/hash.pmc 13 Dec 2004 13:45:59 - 1.1 +++ classes/hash.pmc 18 Dec 2004 00:35:28 - @@ -609,8 +609,6 @@ /* -=item CPMC* slice (PMC *key) - Return a new iterator for the slice PMC Ckey =item CPMC *get_pmc_keyed(PMC *key) Index: classes/integer.pmc === RCS file: /cvs/public/parrot/classes/integer.pmc,v retrieving revision 1.21 diff -u -r1.21 integer.pmc --- classes/integer.pmc 12 Dec 2004 23:03:45 - 1.21 +++ classes/integer.pmc 18 Dec 2004 00:35:28 - @@ -640,8 +640,6 @@ =item Cvoid divide_int(INTVAL value, PMC *dest) -=item Cvoid floor_divide_int(INTVAL value, PMC *dest) - Divides the integer by Cvalue and returns the result in C*dest. =cut Index: classes/parrotclass.pmc === RCS file: /cvs/public/parrot/classes/parrotclass.pmc,v retrieving revision 1.31 diff -u -r1.31 parrotclass.pmc --- classes/parrotclass.pmc 15 Dec 2004 12:52:38 - 1.31 +++ classes/parrotclass.pmc 18 Dec 2004 00:35:28 - @@ -312,6 +312,7 @@ } /* + =back =cut Index: classes/parrotlibrary.pmc === RCS file: /cvs/public/parrot/classes/parrotlibrary.pmc,v retrieving revision 1.11 diff -u -r1.11 parrotlibrary.pmc --- classes/parrotlibrary.pmc 16 Dec 2004 19:22:37 - 1.11 +++ classes/parrotlibrary.pmc 18 Dec 2004 00:35:28 - @@ -18,7 +18,7 @@ _filename full path/file of lib _ro true after init - + All ParrotLibrary PMCs are in interpreter-iglobals. When a dynamic library (pmc or ops) is loaded, the load function returns Index: classes/sub.pmc === RCS file: /cvs/public/parrot/classes/sub.pmc,v retrieving revision 1.69 diff -u -r1.69 sub.pmc --- classes/sub.pmc 11 Dec 2004 12:08:07 - 1.69 +++ classes/sub.pmc 18 Dec 2004 00:35:29 - @@ -23,7 +23,7 @@ /* -=item C +=item Csub_name Print name and location of subroutine, This should finally use the label name of the frozen CSub PMC image for now locate the CSub name in Index: compilers/pge/README === RCS file: /cvs/public/parrot/compilers/pge/README,v retrieving revision 1.2 diff -u -r1.2 README --- compilers/pge/README 1 Dec 2004 20:45:00 - 1.2 +++ compilers/pge/README 18 Dec 2004 00:35:29 - @@ -32,7 +32,7 @@ print - display the PIR cod generated for current rule trace - toggle pattern execution tracing next - repeat last match on target string - + If you get
Test::Harness no longer watches for coredumps
file: $CPAN/authors/id/P/PE/PETDANCE/Test-Harness-2.45_01.tar.gz size: 59764 bytes md5: ad3c49dea2dfdd4fd2a70cc8ffa11c36 We've finally given up on the code in Test::Harness that tries to print a stack trace if it finds a coredump. The code that tried to find the coredump relied on wait.ph, and this caused all sorts of problems with various Linux distros with broken wait.ph files. This also means the little message about Test::Harness would like, but does not require, Devel::StackTrace is now gone, too. Do any of you actually use this feature? Does it make you sad to see it leave? Please tell me about how and when you use it, so that we might look at re-implementing it. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
