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.
One more remark:
This is classes/nci.pmc:invoke
void* invoke (void * next) {
Parrot_csub_t func = (Parrot_csub_t)D2FPTR(PMC_data(SELF));
func(INTERP, SELF);
return next;
}
It's not returning NULL.
leo
[perl #31859] Re: Plain ole Hash
The attached patch makes the Hash PMC use basic PMCs by default. Sorry again, one shouldn't send any patches after midnight. First I forgot to clean up cruft from hash_pmc_20041218.patch. Then, trying to send the corrected patch, I misspelled the name of the mailing list. So, please note that a patch for the Hash PMC, hash_pmc_20041218_cleaned.patch, is lying at http://rt.perl.org/rt3/index.html?q=31859. CU, Bernhard -- /* [EMAIL PROTECTED] */
Re: [perl #31859] [TODO] Plain ole Hash
Bernhard Schmalhofer via RT wrote: The attached patch makes the Hash PMC use basic PMCs by default. Native integers, numbers and strings are now stored as Integer, Float and String PMCs. For keys without values, the Undef PMC is returned, as it is laid out in pdd17. As already mentioned: the Hash PMC is mainly used inside Parrot to manage internals. For a non-existent key NULL should be returned. WRT type mappings: we need a more general scheme for mappings of basic types to Perl, python, whatever. TODO: - Go skiing in the Austrian Alps!! He, he. Have fun! CU, Bernhard Servus, leo
Re: RT#31859, Plain ole Hash
Sam Ruby wrote: Any objections to the NCI methods being removed from Coroutine(next), Hash(fromkeys), Iterator(next), and PerlHash(fromkeys) now? The fromkeys in Hash and PerlHash can be removed. The .next methods in iterable PMCs will be needed generally. But iterators need some rework still, especially Python generator functions. - Sam Ruby leo
Re: PGE tests wanted (was P6GE tests wanted)
Patrick R. Michaud wrote:
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_*
'simple script' .. it isn't so simple anymore ;)
I'm not aware of anyone working on it currently, so please go ahead
and do this!
This test seems to cause an infinite loop
(with parrot_2004-12-16_160001)
p6rule_isnt('a--', '^[a?b?]*$', 're_tests 387 (#438)'); # infinite loop
I currently have some 400..500 tests autoconverted from 're_tests', but
quite many are broken as my script still has few bugs. I'll send the
tests here once I get as many tests converted as seems plausible. (The
rest can then be converted manually, or ignored. Not all of those tests
have use with perl6, e.g. many tests for \z \Z $ etc...)
Resulting file 're_tests.t' has original lines as comments, so if test
fails, it's easy to check whether problem is in test or in pge.
(Currently I skip all tests for $+ as pge-testing format doesn't support
this. I'm not sure if these are needed for anything, as it's trivial to
get endpoint from startpoint and string length.)
== re_tests.t example ==
use Parrot::Test 'no_plan';
use Parrot::Test::PGE;
# Tests from re_tests in perl5-source
# --- re_tests ---
# 1: abcabc y $ abc
# 2: abcabc y $-[0] 0
# 3: abcabc y $+[0] 3 # SKIP
p6rule_like('abc', 'abc', qr/0: \Qabc\E @ 0/, 're_tests 1 (#1)');
# 4: abcxbc n - -
p6rule_isnt('xbc', 'abc', 're_tests 2 (#2)');
# 5: abcaxc n - -
p6rule_isnt('axc', 'abc', 're_tests 3 (#3)');
# 6: abcabx n - -
p6rule_isnt('abx', 'abc', 're_tests 4 (#4)');
# 7: abcxabcy y $ abc
# 8: abcxabcy y $-[0] 1
# 9: abcxabcy y $+[0] 4 # SKIP
p6rule_like('xabcy', 'abc', qr/0: \Qabc\E @ 1/, 're_tests 5 (#5)');
...
...
== re_tests.t example ==
--
Markus Laire
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.
One more remark:
This is classes/nci.pmc:invoke
void* invoke (void * next) {
Parrot_csub_t func = (Parrot_csub_t)D2FPTR(PMC_data(SELF));
func(INTERP, SELF);
return next;
}
It's not returning NULL.
Fixed.
- Sam Ruby
Re: [perl #33092] IMCC sub/opcode invocation conflict
Quoting Luke Palmer via RT [EMAIL PROTECTED]:
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.
That looks really great, but when I try it in 0.1.1 (on Windows), I get:
error:imcc:parse error, unexpected '(', expecting '\n'
--
Dave Brondsema : [EMAIL PROTECTED]
http://www.brondsema.net : personal
http://www.splike.com : programming
http://csx.calvin.edu : student org
Re: PGE tests wanted (was P6GE tests wanted)
On Sat, Dec 18, 2004 at 12:16:31PM +0200, Markus Laire wrote:
This test seems to cause an infinite loop
(with parrot_2004-12-16_160001)
p6rule_isnt('a--', '^[a?b?]*$', 're_tests 387 (#438)'); # infinite loop
So far repeating groups of zero-length strings causes an infinite loop-
I just haven't added the code to detect + avoid that yet. I'll take care
of it today/tomorrow, but it's good to have the test in place.
I currently have some 400..500 tests autoconverted from 're_tests', but
quite many are broken as my script still has few bugs. I'll send the
tests here once I get as many tests converted as seems plausible. (The
rest can then be converted manually, or ignored. Not all of those tests
have use with perl6, e.g. many tests for \z \Z $ etc...)
Wow, excellent! If you want to go ahead and get them in earlier, you
could send what you have with the unconverted tests commented out.
Pm
Re: [perl #33092] IMCC sub/opcode invocation conflict
Dave Brondsema wrote:
print(hello)
That looks really great, but when I try it in 0.1.1 (on Windows), I get:
error:imcc:parse error, unexpected '(', expecting '\n'
You'd need latest from CVS, sorry.
leo
Re: need help
Sridhar Subbarayan wrote: Hi, I am urgently in need of some study material that deals with using perl in QA process. How is functionality testing done using perl. How is performance testing done using perl. How does perl help in automation. Please give some examples. Please let me know if there are any books or tutors that will answer my above questions. I have knowledge in perl and also have tutors for it. Please help me. I suspect that the fact that your question has gone several days on this list without a response reflects its overly broad nature. Could you give us a specific example of the type of functionality testing or performance testing you need to accomplish? Jim Keenan
Re: PGE tests wanted (was P6GE tests wanted)
On Sat, Dec 18, 2004 at 12:16:31PM +0200, Markus Laire wrote:
: Patrick R. Michaud wrote:
: 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_*
:
: 'simple script' .. it isn't so simple anymore ;)
Sorry. Well, okay, I'm not really sorry. :-)
In fact, I might like to look at your 'simple script' when I get further
along on the p5-to-p6 translator...
: I'm not aware of anyone working on it currently, so please go ahead
: and do this!
:
: This test seems to cause an infinite loop
: (with parrot_2004-12-16_160001)
:
: p6rule_isnt('a--', '^[a?b?]*$', 're_tests 387 (#438)'); # infinite loop
Detecting failure to progress can be quite tricky, actually. It's easy
enough to detect that it *might* be an infinite loop. But that pattern
would succeed the string were all a's and b's. It's not enough to figure
out that you're at the same position or the same state. You have to figure
out that you're at the same position and the same state, and you may well
have visited different positions in this state, or different states in
this position. So a naive solution requires N**2 in time or space.
Henry Spencer's original regex routines simply disallowed expressions
that might be infinite. We tried relaxing that in Perl 5, and got
it wrong more than one way. I'm not actually sure what approach p5
takes right now, if any.
: (Currently I skip all tests for $+ as pge-testing format doesn't support
: this. I'm not sure if these are needed for anything, as it's trivial to
: get endpoint from startpoint and string length.)
The whole notion of string positions as integers is now somewhat
problematic in the Unicode era. Is a position of 5 to be interpreted
as 5 bytes, 5 codepoints, 5 graphemes, or 5 letters? String positions
are probably opaque objects that return different integer values
in different contexts. And there is no such thing as the length
of a string anymore, unless it's another opaque object representing
the position at the end of the string. And we've outlawed length
as a too-general concept. You have to tell it what units you mean
(.bytes, .codes, .graphs), or maybe use .chars for the default meaning
in the current context, if we decide to allow that.
As long as we're banishing .length from strings, we're also banishing
it from arrays. You have to use .elems for that. (At least all
this specificity now allows us to ask for the length of an array in
codepoints or graphemes...)
Anyway, sorry about the diatribe, but this is an area where we'll be
battling our own imprecision for years to come, not to mention everyone
else's.
Larry
Re: PGE tests wanted (was P6GE tests wanted)
Larry Wall [EMAIL PROTECTED] wrote:
:Henry Spencer's original regex routines simply disallowed expressions
:that might be infinite. We tried relaxing that in Perl 5, and got
:it wrong more than one way. I'm not actually sure what approach p5
:takes right now, if any.
We detect and warn of repeated empty expressions:
zen% perl -wle 'print ok if x =~ /()*/'/'
()* matches null string many times in regex; marked by -- HERE in m/()* --
HERE / at -e line 1.
ok
zen%
For optionally empty expressions, we don't allow them to match emptily
more than once:
zen% perl -wle 'while (baa =~ /((b??)*a)/g) { print $1 }'
ba
a
zen%
For optionally empty patterns, we don't allow them to match emptily at
the same location more than once:
zen% perl -wle 'while (a =~ /(a??)/g) { print $1 }'
a
zen%
This last is achieved by magic on the string to which the pattern is
applied, which can lead to problematic interactions with other magic
(eg tainting) or restoration after local(). In principle it may also
be undesirable if you are parsing a string with a variety of //gc
patterns, and want to allow more than one of them to match an empty
string at the same location.
Hugo
700 tests for PGE
Here are 700 tests for pge, autoconverted from 're_tests' file, from perl5 source. If there are any significant errors in these tests, please tell, and I can correct the script. Original perl5-tests are in comments so it's quite easy to see if there has been an error in converting. After commenting out test #441 (which causes infinite loop), I get this result with parrot_2004-12-16_160001 : DIED. FAILED tests 11-12, 37-93, 96-99, 102, 105, 114, 116, 120, 122, 124, 129, 132-135, 146-148, 153-171, 181-194, 200-206, 208, 210-217, 220-392, 395-397, 401-410, 414-434, 436-440, 442-467, 469-474, 476-500, 503-509, 512, 514-515, 518, 520-521, 536, 538-539, 554, 556-557, 572-591, 593-601, 603-622, 624-626, 629, 631, 633, 635, 637-685, 687-689, 691-693, 695-697, 699 Failed 530/699 tests, 24.18% okay Failed TestStat Wstat Total Fail Failed List of Failed --- mytests/re_tests.t 254 65024 699 530 75.82% ... Failed 1/1 test scripts, 0.00% okay. 530/699 subtests failed, 24.18% okay. Test numbers are marked as (#441), so you can use them to find certain test quickly. (These numbers might be one off, because one test was commented out). -- Markus Laire Jam. 1:5-6 re_tests.t.tar.bz2 Description: BZip2 compressed data
Auto My?
Considering that proper and common usage, not to mention strictures, dictates a heavy insistence on 'my'. I will thus assume that creation of lexical variables with 'my' far out numbers the creation of package space globals. Should we not then have it where it's the default behavior, and creation of package ones take explicit declaration (via 'our')? Well, at least when strictures are on. When they are off, the coder is obviously playing fast and loose, and should get the easy 'everything global' behavior. What issues am I overlooking here? -- Rod
Re: Auto My?
Rod Adams writes: Considering that proper and common usage, not to mention strictures, dictates a heavy insistence on 'my'. I will thus assume that creation of lexical variables with 'my' far out numbers the creation of package space globals. Should we not then have it where it's the default behavior, and creation of package ones take explicit declaration (via 'our')? Larry has addressed this before, coining I made 'my' short for a reason. Python and Ruby both autodeclare in the lexical scope like this, and some people like that. Sometimes you see bogus assignments in those languages just to declare a variable in an outer scope. Also, the idea is a bit brittle in the face of large subs. If you change the control flow a little bit, you might accidentally change a variable's scope, and then what you thought was one variable just became two distinct lexicals. There are pros and cons, and it basically ends up being a design choice. Well, at least when strictures are on. When they are off, the coder is obviously playing fast and loose, and should get the easy 'everything global' behavior. When strictures are on, the compiler ought to die if you're tyring to use a variable without declaration. This is another reason why Perl doesn't like autodeclaration. Luke
Re: Auto My?
Rod Adams skribis 2004-12-18 14:55 (-0600): Considering that proper and common usage, not to mention strictures, dictates a heavy insistence on 'my'. I will thus assume that creation of lexical variables with 'my' far out numbers the creation of package space globals. Should we not then have it where it's the default behavior, and creation of package ones take explicit declaration (via 'our') No. Some other languages, including Ruby, do this. I dislike it. The best thing about strict is that it catches typos. With automatic declaration, you loose typo checking, or solve it in an ugly manner by requiring assignment (which is still declaration, just with different syntax). Just typing my before the first use of a variable isn't hard, and it makes things much clearer for both the programmer and the machine. For the programmer, because you immediately see what some variable's scope is, and for the machine because it no longer has to guess whether something's a typo in order to warn you (used only once is not always a typo). Juerd
Re: PGE tests wanted (was P6GE tests wanted)
On Sat, Dec 18, 2004 at 08:47:42AM -0800, Larry Wall wrote:
: This test seems to cause an infinite loop
: (with parrot_2004-12-16_160001)
:
: p6rule_isnt('a--', '^[a?b?]*$', 're_tests 387 (#438)'); # infinite loop
Detecting failure to progress can be quite tricky, actually. It's easy
enough to detect that it *might* be an infinite loop. But that pattern
would succeed the string were all a's and b's. It's not enough to figure
out that you're at the same position or the same state. You have to figure
out that you're at the same position and the same state, and you may well
have visited different positions in this state, or different states in
this position. So a naive solution requires N**2 in time or space.
In PGE I've been thinking this won't be *too* difficult (and I'll fully
admit to the possibility of being naive here). Our states are actually
encoded into the pattern's subroutine code, with our current state
being held by Parrot's execution pointer and the various stacks, and
we're already keeping track of the starting and current position of
each substring being matched by a repeating group. (Or, if we're
not, we certainly can keep track of it in a stack of some sort.
So, when we get to the end of the bracketed group, we look to see
if the current position has changed at all since we started the group,
and if not we refuse to repeat the group again but just go on to
whatever other checks need to be made. If going on to the remaining
checks causes a match failure, we're just going to backtrack into the
group's subexpression anyway, which would then start doing things that
change the current pointer we'll be seeing at the end of the group.
This may not always be the most efficient mechanism -- i.e., we could
find ourselves repeating later matches we've already tried, but at
least it shouldn't infinite loop.
But rather than trying to explain it all and debate here whether it'll
work or not, it's probably quicker for me to just implement that section
of code and let our tests tell the tale. I'll do that today/tomorrow and
report back on the results. But if anyone knows of a case where what
I've discussed isn't likely to work or has caused problems in the past,
let me know so we can code up a test and/or workaround for it and see
what happens.
Pm
Re: Auto My?
- Original Message - From: Luke Palmer [EMAIL PROTECTED] Date: Saturday, December 18, 2004 4:16 pm Subject: Re: Auto My? Rod Adams writes: There are pros and cons, and it basically ends up being a design choice. Well, at least when strictures are on. When they are off, the coder is obviously playing fast and loose, and should get the easy 'everything global' behavior. When strictures are on, the compiler ought to die if you're tyring to use a variable without declaration. This is another reason why Perl doesn't like autodeclaration. As bad of an idea that I think this is, I wonder if Perl6's reflection capabilities will be powerful enough to where a module/pragma could be written that would be able to do this? For instance, one idea was: lexically change the current grammar to a subclass of the grammar. In this subclass, there is a hook on the variable deparsing rule that will implictly declare a variable into its outer scope if it has not yet been declared in the current scope. Totally whacky, sure; but doable? That brings up another idea that I had just now: will it be possible to load 2 different grammars at once if they don't conflict with each other? For instance, say we have loaded a grammer, Grammar::WhackyVars, that subclasses from the main Perl6 grammar but modifies the variable rule somehow. However, then say I want to use a grammar that also subclasses from the main Perl6 grammar that lets you use happyfunactiontime instead of the word class. Since the modified rules don't conflict with each other, can I just use Grammar::HappyFunActionTime and everything will work? Or will Grammar::HappyFunActionTime overload the changes done by the Grammar::WhackyVars? - Joe
Re: Auto My?
JOSEPH RYAN writes: As bad of an idea that I think this is, I wonder if Perl6's reflection capabilities will be powerful enough to where a module/pragma could be written that would be able to do this? For instance, one idea was: lexically change the current grammar to a subclass of the grammar. In this subclass, there is a hook on the variable deparsing rule that will implictly declare a variable into its outer scope if it has not yet been declared in the current scope. Totally whacky, sure; but doable? I don't doubt it. I'd write it right now, but we don't know enough about the compiler interface yet. That brings up another idea that I had just now: will it be possible to load 2 different grammars at once if they don't conflict with each other? For instance, say we have loaded a grammer, Grammar::WhackyVars, that subclasses from the main Perl6 grammar but modifies the variable rule somehow. However, then say I want to use a grammar that also subclasses from the main Perl6 grammar that lets you use happyfunactiontime instead of the word class. Since the modified rules don't conflict with each other, can I just use Grammar::HappyFunActionTime and everything will work? Or will Grammar::HappyFunActionTime overload the changes done by the Grammar::WhackyVars? This begs the use of a particular abstraction Perl 6 has introduced with grammars. Maybe grammar munges aren't subclasses at all, but grammatical roles. The only problem I see with such roles is code generation. If we're going to make it parse in such a modular way, we ought to generate code in the same modular way. That will take some clever design (but I think it can be done). This is important insight right about now, since we're rethinking what the parse tree that rules spit out looks like. Luke
