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
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: 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?
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: 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
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
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 re_tests.t.tar.bz2 Description: BZip2 compressed data
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>" }' 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>" }' <> <> 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
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: 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: [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: 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
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. > > # 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' (print<0>) > > 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: 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: 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: 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: [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
[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: 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