Re: [perl #33129] N registers get whacked in odd circumstances
Dan Sugalski (via RT) wrote: You'll note that N5 is set to 22253 when the returncc's done, but after the return the value is -21814.6. Looks like something's stomping the N registers. The program below shows exactly the same behavior WRT __set_number_native. The call comes from inside of the mmd_fallback function, so I presume that in the part before the shown trace you are having some kind of mathematical operation that leads to the change in N5. leo .sub main .local pmc cl, o, p, q newclass cl, money addattribute cl, n o = new money p = new money q = new money o = 2.0 p = 3.0 q = o + p print q print \n .end .namespace [money] .sub __init method $P0 = new Float setattribute self, money\0n, $P0 .end .sub __set_number_native method .param float n $P0 = getattribute self, money\0n $P0 = n .end .sub __get_string method $P0 = getattribute self, money\0n $S0 = $P0 .return($S0) .end .sub __get_number method $P0 = getattribute self, money\0n $N0 = $P0 .return($N0) .end
Re: MMD and VTABLE_find_method
Sam Ruby wrote: Leopold Toetsch wrote: However, from http://www.perl.com/pub/a/2004/04/16/a12.html?page=10: Whenever you make a call using subroutine call syntax, it's a candidate for multiple dispatch. I read this to mean that the *caller* does nothing to distinguish between calls to single dispatch subroutines from multiple dispatch subroutines. So... how does one determine at compile time which opcode to use? This probably needs some clarification from Perl6 people. Anyway, if Parrot just gets: foo(Px, Py, Pz) there is no information, how many invocants are participating in MMD. So candidates for multiple dispatch must be declared somewhere. $a.foo($b, $c) := foo($a, $b, $c) Given the latter syntax, how does the compiler know when to emit a callmethodcc foo and when to emit a call_MMD foo? The compiler has to know it. E.g. foo($a: $b, $c); # 1 invocant foo($a, $b: $c); # 2 MMD invocants and as Parrot has to find a method depending on n MMD invocants, this information must be present at runtime. This leads to the assumption that we'll need an opcode call_MMD meth, n_invocants and some changes in pdd03 as the current calling scheme doesn't have anything about argument order. I have described that in subject: MMD: more implications The only thing I am attempting to solve is the presumption that MMD calls can be detected at compile time. It's quite clear for infix operations like add. For arbitrary subroutines the compiler has to know it, as outlined above. Unless you can describe a mechanism which enables the callers to detect at compile time whether they are invoking a MMD subroutine or not, this code needs to be either executed as a part of an VTABLE_invoke. See above. Again, I am not suggesting that the algorithm be made any thinner, in fact, I am not suggesting any change to the algorithms that you have described. I am merely suggesting where the logic needs to be placed. This is quite clear, IMHO. As said: Px = Py + Pz is a call to a MMD function, which is located by the described sequence of VTABLE_find_method and called. The dispatch happens at the opcode level. That's really the same as a callmethodcc opcode, which happens to have just one invocant. There is no difference between these to invocations except that add or + is a fancy shortcut for humans reading the source code. Above is exactly the same as: Px = Py.__add(Pz) But as there are two invocants and we know that's and add operation, we have an optimized opcode for this kind of infix MMD operations like: Px = call_MMD_2 __add, Py, Pz where Px is *created* by the opcode. I'm just proposing this equivalence and a scheme to make it running. And despite that it's looking like a fat method call, Parrot executes this sequence, if the __add isn't overloaded: if (cache-type == (Py-vtable-base_type 16|Pz-vtable-base_type) Px = (cache-function)(Py, Pz); which is 30% faster then the current mmd_dispatch based opcode. - Sam Ruby leo
Re: P5 is the new P2
Matt Fowles wrote: P5 is the new P2 Sam and Leo came to the conclusion that the current object should be passed in P5 as well as P2. Currently they are waiting for Dan... Nudge, Nudge... http://xrl.us/ef8r I've implemented this, but I am near the point of recanting. Examples of problematic code (both from t/pie/b3.t): return TT.__new__(cls, value) return T.__cmp__(a, b) Where the latter ends up invoking the cmp method with three arguments instead of the customary two, and confusion reigns. The way this is resolved in Python is with a distinction between bound and unbound methods. Roughly, in Parrot terms, this is a distinction between methods where the object can be found in P2 and P5 respectively. I'm resisting implementing this for now, but will likely have to cave ultimately. To implement this would require a call to pmc_new on each method call on an instance, as well as reinserting the argument as the first parameter (shifting each of the curent parameters in the process). Blech. - Sam Ruby
Re: MMD and VTABLE_find_method
Leopold Toetsch wrote: Sam Ruby wrote: Leopold Toetsch wrote: However, from http://www.perl.com/pub/a/2004/04/16/a12.html?page=10: Whenever you make a call using subroutine call syntax, it's a candidate for multiple dispatch. I read this to mean that the *caller* does nothing to distinguish between calls to single dispatch subroutines from multiple dispatch subroutines. So... how does one determine at compile time which opcode to use? This probably needs some clarification from Perl6 people. Anyway, if Parrot just gets: foo(Px, Py, Pz) there is no information, how many invocants are participating in MMD. So candidates for multiple dispatch must be declared somewhere. A few things to note: foo is a PMC. It therefore is an object. It can have state (properties, attributes, etc). It can know how many arguments are involved in multiple dispatch. All calls to foo are likely to have the same number of arguments participating in MMD. This number is known when foo is defined. If that information is captured in the PMC itself, it can be exploited at runtime. $a.foo($b, $c) := foo($a, $b, $c) Given the latter syntax, how does the compiler know when to emit a callmethodcc foo and when to emit a call_MMD foo? The compiler has to know it. E.g. foo($a: $b, $c); # 1 invocant foo($a, $b: $c); # 2 MMD invocants and as Parrot has to find a method depending on n MMD invocants, this information must be present at runtime. This leads to the assumption that we'll need an opcode call_MMD meth, n_invocants Changing the external syntax for subroutine calls in P6 may be an option. Changing the syntax for function calls in Python is not an option. Therefore, if changing the syntax is required, it is likely that Python will not be able to call arbitrary subroutines involving MMD. It would be ideal if callers did not have to know how such subroutines were defined, and could continue to emit invokecc sequences on Sub PMCs, and for this to be handled at runtime. and some changes in pdd03 as the current calling scheme doesn't have anything about argument order. I have described that in subject: MMD: more implications The only thing I am attempting to solve is the presumption that MMD calls can be detected at compile time. It's quite clear for infix operations like add. For arbitrary subroutines the compiler has to know it, as outlined above. When expressed via an infix notation, I agree that it is not a problem. When expressed via the equivalent method call notation, (as Python allows), it becomes one. And despite that it's looking like a fat method call, Parrot executes this sequence, if the __add isn't overloaded: if (cache-type == (Py-vtable-base_type 16|Pz-vtable-base_type) Px = (cache-function)(Py, Pz); which is 30% faster then the current mmd_dispatch based opcode. That code will execute just as fast if placed inside the invoke logic of a MMD PMC. - Sam Ruby
Re: cvs commit: parrot/dynclasses pybuiltin.pmc pyclass.pmc pyfunc.pmc pylist.pmc pynone.pmc
Sam Ruby [EMAIL PROTECTED] wrote:
--- nci.pmc 7 May 2004 10:33:26 - 1.27
+++ nci.pmc 20 Dec 2004 22:27:11 - 1.28
+=item CPMC* get_attr_str(STRING *name)
+
+Return attribute named Cname.
+
+=cut
+
+*/
+
+PMC* get_attr_str(STRING* idx) {
+return VTABLE_getprop(INTERP, SELF, idx);
+}
+
}
What is the rational for this pythonism in Parrot core?
leo
Re: cvs commit: parrot/dynclasses pybuiltin.pmc pyclass.pmc pyfunc.pmc pylist.pmc pynone.pmc
Leopold Toetsch wrote:
Sam Ruby [EMAIL PROTECTED] wrote:
--- nci.pmc7 May 2004 10:33:26 - 1.27
+++ nci.pmc20 Dec 2004 22:27:11 - 1.28
+=item CPMC* get_attr_str(STRING *name)
+
+Return attribute named Cname.
+
+=cut
+
+*/
+
+PMC* get_attr_str(STRING* idx) {
+return VTABLE_getprop(INTERP, SELF, idx);
+}
+
}
What is the rational for this pythonism in Parrot core?
Good catch. I've added the following directly to nci.pmc both to
capture the rationale and to record a TODO.
--- nci.pmc 20 Dec 2004 22:27:11 - 1.28
+++ nci.pmc 21 Dec 2004 11:50:16 -
@@ -159,6 +159,16 @@
=cut
+TODO: refactor into a separate subclass, and either modify Pmc2c.pm and
+enter_nci_method to directly build this subclass, or add code to morph
+NCI instances into the correct subclass later.
+
+The line of code in test case t/pie/b3 that motivates this is:
+
+ print using, cmp.__name__
+
+Where cmp may be a NCI subroutine.
+
*/
PMC* get_attr_str(STRING* idx) {
Re: MMD and VTABLE_find_method
Sam Ruby wrote: Leopold Toetsch wrote: A few things to note: foo is a PMC. It therefore is an object. It can have state (properties, attributes, etc). It can know how many arguments are involved in multiple dispatch. The MMD information can't hang off the Sub PMCs. How do you find the correct foo Sub then? ... This leads to the assumption that we'll need an opcode call_MMD meth, n_invocants Changing the external syntax for subroutine calls in P6 may be an option. Changing the syntax for function calls in Python is not an option. Therefore, if changing the syntax is required, it is likely that Python will not be able to call arbitrary subroutines involving MMD. Python doesn't have the concept of MMD. You can't specify the number of invocants in Python source code. So yes, if nothing is known about the subroutine, it's unlikely that it can be called from Python. If the translator is aware of the fact that a Perl6 multi sub is called, the call syntax can be adapted - however it'll look like. It would be ideal if callers did not have to know how such subroutines were defined, and could continue to emit invokecc sequences on Sub PMCs, and for this to be handled at runtime. Well, I don't know how the Perl6 compiler will translate: foo($a, $b, $c) If there is more then one foo Sub PMC around, the call syntax still must have the number of invocants attached to it, so that MMD can happen. It's quite clear for infix operations like add. For arbitrary subroutines the compiler has to know it, as outlined above. When expressed via an infix notation, I agree that it is not a problem. When expressed via the equivalent method call notation, (as Python allows), it becomes one. Please note that the shown method call syntax was an internal representation of the functionality. But WRT Python: i = 1 j = 2 print i.__add__(j) can be translated directly to the method call of Parrot's infix __add method. And despite that it's looking like a fat method call, Parrot executes this sequence, if the __add isn't overloaded: if (cache-type == (Py-vtable-base_type 16|Pz-vtable-base_type) Px = (cache-function)(Py, Pz); which is 30% faster then the current mmd_dispatch based opcode. That code will execute just as fast if placed inside the invoke logic of a MMD PMC. Where does this hypothetical MMD PMC come from? Where is it created? The opcode is just: add Px, Py, Pz Py or Pz can be plain PyInts or Integers. Where does that MMD PMC come from? And no, it wouldn't have the same performance. - Sam Ruby leo
Re: cvs commit: parrot/dynclasses pybuiltin.pmc pyclass.pmc pyfunc.pmc pylist.pmc pynone.pmc
Sam Ruby wrote: Leopold Toetsch wrote: What is the rational for this pythonism in Parrot core? +The line of code in test case t/pie/b3 that motivates this is: + + print using, cmp.__name__ + +Where cmp may be a NCI subroutine. Python's builtin cmp is basially a Sub PMC. Parrot Sub's have already a name: .sub main .const .Sub c = cmp print c .end .sub cmp .end So I think, you could translate access to the __name__ attribute directly to VTABLE_name(). WRT NCI: The b3.py test doesn't need it, but I can imagine that the method name of Parrots cmp method is just __cmp and available with VTABE_name(). leo
Re: [perl #33129] N registers get whacked in odd circumstances
At 10:56 AM +0100 12/21/04, Leopold Toetsch wrote: Dan Sugalski (via RT) wrote: You'll note that N5 is set to 22253 when the returncc's done, but after the return the value is -21814.6. Looks like something's stomping the N registers. The program below shows exactly the same behavior WRT __set_number_native. The call comes from inside of the mmd_fallback function, so I presume that in the part before the shown trace you are having some kind of mathematical operation that leads to the change in N5. Yep, that's it. Going back a page or so I see this is triggered by some math, and I assume that something's not preserving the N registers as part of the dispatch in there somewhere. I'll see about poking around the code and tracking it down tomorrow unless someone beats me to it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #33129] N registers get whacked in odd circumstances
Dan Sugalski wrote: At 10:56 AM +0100 12/21/04, Leopold Toetsch wrote: The program below shows exactly the same behavior WRT __set_number_native. The call comes from inside of the mmd_fallback function, so I presume that in the part before the shown trace you are having some kind of mathematical operation that leads to the change in N5. Yep, that's it. Going back a page or so I see this is triggered by some math, and I assume that something's not preserving the N registers as part of the dispatch in there somewhere. I'll see about poking around the code and tracking it down tomorrow unless someone beats me to it. You must have some additional features in that piece of code. The example below does preserve N5 around the overloaded object access. But maybe you can extend it to what your code is doing at the failing place. leo .sub main .local pmc cl, o, p, q N5 = 100.0 newclass cl, money addattribute cl, n o = new money p = new money q = new money o = 2.0 p = 3.0 q = o + p print q print \n print N5 print \n .end .namespace [money] .sub __init method $P0 = new Float setattribute self, money\0n, $P0 .end .sub __set_number_native method .param float n $P0 = getattribute self, money\0n $P0 = n .end .sub __get_string method $P0 = getattribute self, money\0n $S0 = $P0 .return($S0) .end .sub __get_number method $P0 = getattribute self, money\0n $N0 = $P0 .return($N0) .end
700 tests for PGE
[Markus == [EMAIL PROTECTED] on Mon, 20 Dec 2004 13:59:57 +0200] Markus I was wondering if it would make sense to add the original Markus 're_tests' file to parrot distribution, with a script which Markus autogenerates 're_tests.t' from it. To me, it certainly would. I would note, however, that my implementation of something like this approach was rejected prior to the release of PGE as too complicated, despite a working code base. Please sync up carefully with Patrick and Dan on your approach to this automation to avoid rework. It may be that it's still preferred to just maintain your cooker script outside the tree and check in only the results. (Briefly, my approach was to have a p5_re_tests.t script, which would generate 1 PGE test for each line in the re_tests source file, but do that testing on-the-fly, not cooked, so no regeneration would ever be necessary.) The argument for avoiding this approach didn't really make sense to me at the time, as I saw a future with thousands of PGE tests. I believed (and still believe) that given more time, it would be realized that automating the infrastructure so people didn't have to type in or port repetitive regexp/rule tests would be beneficial and result in more, better tests. If you're on a roll, Markus, I'd like to point you to: svn://software.wordzoo.com/p6ge-test-harness/trunk where I gathered lots of additional tests (including perl 5's re_tests file) that were intended to be ported to PGE. The codebase is abortive at best, as I simply dropped it when Patrick indicated he was going a different direction. So I've since applied my open-source time in other directions, but you are welcome to browse this obsolete codebase for ideas. -- [EMAIL PROTECTED] Better to be of a rare breed than a long line. -- TDK
Re: Let the hacking commence!
Patrick R. Michaud writes:
rule identifier() { alpha \w* }
Does Perl 6 allow leading underscores in identifiers? If so,
shouldn't this be
rule identifier() { +alpha+[_] \w* }
?
Yeah, it should. There was an error anyway:
rule identifier() { +alpha \w* }
Fixed.
rule open_expression_grouping() { \( }
rule close_expression_grouping() { \) }
rule open_argument_list() { \( }
rule close_argument_list() { \) }
I'm not sure I agree with expression_grouping being defined in this
way-- it seems to me that parens (and brackets and braces and dots)
are being treated as operators (S03, S04), perhaps even
postcircumfix operators if I understand what that means (A12). So
we need to be a bit careful here.
Parens are plain old circumfix. We could stick that into the
operator-precedence parser, and in fact they probably belong there. But
the grammar is supposed to be so extensible that if we try to define
things in terms of hooks from the beginning, we'll never get anywhere.
You're right about the argument_list forms. Keep in mind that these are
just the token definitions. The rules for using them are up higher.
Again, my reasoning for including them was the same: we have to include
something. And I figure it's easier to take stuff out than to put stuff
in.
In addition to reviewing what's been done so far, I'll take a stab
at writing the rules for P6 rules. :-)
Eexcellent.
Luke
Re: MMD and VTABLE_find_method
Leopold Toetsch wrote:
Sam Ruby wrote:
Leopold Toetsch wrote:
A few things to note: foo is a PMC. It therefore is an object. It
can have state (properties, attributes, etc). It can know how many
arguments are involved in multiple dispatch.
The MMD information can't hang off the Sub PMCs. How do you find the
correct foo Sub then?
[snip]
Well, I don't know how the Perl6 compiler will translate:
foo($a, $b, $c)
If there is more then one foo Sub PMC around, the call syntax still
must have the number of invocants attached to it, so that MMD can happen.
A foo PMC could represent an entire row in a two dimensional MMD, or
an entire plane in a three dimensional MMD, ... etc.
A Perl6 compiler could translate the above to:
87 find_lex P5, a
90 find_lex P6, b
93 find_lex P7, c
96 find_global P0, foo
108 set I0, 1
111 set I1, 0
114 set I2, 0
117 set I3, 3
120 set I4, 0
126 invokecc
The foo PMC could know how many of the arguments are relevant for MMD
dispatch. Should only the first two arguments be relevant, this code
could be as simple as:
void* invoke(void* next) {
...
if (cache-type == (Py-vtable-base_type
16|Pz-vtable-base_type)
return VTABLE_invoke( cache-function );
...
}
[snip]
That code will execute just as fast if placed inside the invoke
logic of a MMD PMC.
Where does this hypothetical MMD PMC come from? Where is it created? The
opcode is just:
add Px, Py, Pz
Py or Pz can be plain PyInts or Integers. Where does that MMD PMC come
from?
Once MMD is solved connecting it up to the PerlScalar PMC (for example)
would be rather straightforward. Syntax like the following would result
in an appropriate entry being added to the MMD dispatch table:
multi sub infix:+ (Us $us, Us $ustoo) {...}
The Parrot_PerlScalar_add function (which would revert back to being a
vanilla vtable) would know about the portion of the MMD dispatch table
that is relevant to Perl scalar add operations, and invoke it.
(Note: one thing that hasn't been discussed to date is how registers
will be handled. The current add opcode doesn't have any side effects)
- Sam Ruby
Re: cvs commit: parrot/dynclasses pybuiltin.pmc pyclass.pmc pyfunc.pmc pylist.pmc pynone.pmc
Leopold Toetsch wrote: Sam Ruby wrote: Leopold Toetsch wrote: What is the rational for this pythonism in Parrot core? +The line of code in test case t/pie/b3 that motivates this is: + + print using, cmp.__name__ + +Where cmp may be a NCI subroutine. Python's builtin cmp is basially a Sub PMC. Parrot Sub's have already a name: At the moment, Python's builtin cmp is implemented thus: enter_nci_method(interp, my_enum_class_PyBuiltin, F2DPTR(Parrot_PyBuiltin_cmp), cmp, PIOPP); .sub main .const .Sub c = cmp print c .end .sub cmp .end So I think, you could translate access to the __name__ attribute directly to VTABLE_name(). WRT NCI: The b3.py test doesn't need it, but I can imagine that the method name of Parrots cmp method is just __cmp and available with VTABE_name(). For this test to pass, the __name__ must be cmp. As this issue is obviously very important to you, I'll drop what I am doing make creating a new subclass of NCI for my purposes my top priority. - Sam Ruby
Re: Test::Legacy warnock'd
On Tue, Dec 21, 2004 at 04:53:18PM +0100, Tels wrote: On Tuesday 21 December 2004 08:53, Michael G Schwern wrote: I've gotten absolutely no response about Test::Legacy. Is anybody using it? Anybody tried migrating old Test.pm based tests with it? I am converting my old tests directly to Test::More (Test::legacy wasn't available before so :) Currently I do not plan to do this - the old tests either work (never fix what is working) or they don't (seldom), at which point I would convert them to Test::More. There's no I want to add a new test to this test file that uses Test.pm and it would be nice if I could use Test::Foo case? -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ Ooops, fatal mutation in the test script.
Re: Test::Legacy warnock'd
Michael G Schwern wrote: On Tue, Dec 21, 2004 at 04:53:18PM +0100, Tels wrote: On Tuesday 21 December 2004 08:53, Michael G Schwern wrote: I've gotten absolutely no response about Test::Legacy. Is anybody using it? Anybody tried migrating old Test.pm based tests with it? I am converting my old tests directly to Test::More (Test::legacy wasn't available before so :) Currently I do not plan to do this - the old tests either work (never fix what is working) or they don't (seldom), at which point I would convert them to Test::More. There's no I want to add a new test to this test file that uses Test.pm and it would be nice if I could use Test::Foo case? I could see this being really good for Apache-Test, which is by default Test.pm driven. the thing is that - I've already ported A-T to use Test::More in place of Test.pm - the native implementation uses Test.pm magic like $Test::ntest = 1; %Test::todo = (); which I figured might be supported in time but not at the moment. of course, that was only speculation on my part, since - a severe lack of tuits on my part has kept me away so I, for one, am very sorry that you've taken the time to work on something that might prove useful to me and I haven't been able to reciprocate with any kind of meaningful feedback. sorry. --Geoff
Re: Test::Legacy warnock'd
On Tue, Dec 21, 2004 at 12:56:27PM -0500, Geoffrey Young wrote: There's no I want to add a new test to this test file that uses Test.pm and it would be nice if I could use Test::Foo case? I could see this being really good for Apache-Test, which is by default Test.pm driven. the thing is that - I've already ported A-T to use Test::More in place of Test.pm - the native implementation uses Test.pm magic like $Test::ntest = 1; $Test::Legacy::ntest = 1 will DWYM. $TESTERR and $TESTOUT work, too. I should probably emphisize this in the docs as folks are going to assume it doesn't work. Test::Builder-current_test(0) will also DWYM. %Test::todo = (); You're treading on thin ice using that from Test.pm. Even Test.pm's own tests don't use that. However, it would be trivial to make Test::Legacy support that as well. But for all Test::Builder based modules you can get the same intent with Test::Builder-reset. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ ...and that, children, is how to clean and load a .38 revolver. Questions?
Re: Test::Legacy warnock'd
But for all Test::Builder based modules you can get the same intent with Test::Builder-reset. yup, I used that for the port away from Test.pm - works like a charm :) --Geoff
Re: Test::Legacy warnock'd
On Tue, Dec 21, 2004 at 06:09:40PM +0100, Tels wrote: Granted, that was what I did before Test::Legacy, which seems to have gone from a wild idea to some working stage while I was not looking :) Most of it was written in about an hour and a half late one night with another hour worth of polishing. I decided rather than try to somehow merge with the Test.pm code base, which looked daunting, I'd see how far I could get prototyping it up from scratch. Answer: nearly all the way! Oooh, you mean I change: use Test; to: use Test::Legacy; use Test::More; and slap an is() a the end? Wow, that would be nifty. You should mention this in the docs! I do think that I still would convert the tests eventually to Test::More, but for the more huge test files that would be a nice intermidiate solution.. By jove I think he's got it! I'll make the docs a little more explicit about that though. And you don't have to stop with Test::More. use Test::Legacy; # you don't want to blow over Test::Legacy's own functions use Test::More import = ['!ok', '!plan', '!skip']; use Test::Exception; use Test::WWW::Mechanize; ...etc... -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ You see, in this world there's two kinds of people. Those with loaded guns, and those who dig. Dig. -- Blondie, The Good, The Bad And The Ugly
Re: Test::Legacy warnock'd
On Tue 21 Dec 2004 18:32, Michael G Schwern [EMAIL PROTECTED] wrote: On Tue, Dec 21, 2004 at 04:53:18PM +0100, Tels wrote: On Tuesday 21 December 2004 08:53, Michael G Schwern wrote: I've gotten absolutely no response about Test::Legacy. Is anybody using it? Anybody tried migrating old Test.pm based tests with it? I am converting my old tests directly to Test::More (Test::legacy wasn't available before so :) Currently I do not plan to do this - the old tests either work (never fix what is working) or they don't (seldom), at which point I would convert them to Test::More. There's no I want to add a new test to this test file that uses Test.pm and it would be nice if I could use Test::Foo case? I also immetiately switched from Copy-n-Paste tests (all starting DBD authors do) to a full fletched Test::More, and used T::M for every test written from scratch thereafter. I never (knowingly) used Test.pm for my own tests. -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.5, 5.9.x, and 809 on HP-UX 10.20 11.00, 11i, AIX 4.3, AIX 5.2, SuSE 9.1, and Win2k. http://www.cmve.net/~merijn/ http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
[PATCH] Stomp a warning in pybuiltin.pmc
The attached patch fixes this warning in pybuiltin.pmc:
pybuiltin.pmc: In function `make_type':
pybuiltin.pmc:76: warning: declaration of `nameprop' shadows previous local
Simon
--- dynclasses/pybuiltin.pmc.oldTue Dec 21 15:30:01 2004
+++ dynclasses/pybuiltin.pmcTue Dec 21 15:32:25 2004
@@ -73,7 +73,7 @@ static PMC* make_type(Interp* interprete
item = VTABLE_get_pmc_keyed_str(interpreter, stash, key);
if (item-vtable-base_type == enum_class_NCI) {
-PMC *nameprop = pmc_new(interpreter, dynclass_PyString);
+nameprop = pmc_new(interpreter, dynclass_PyString);
VTABLE_set_string_native(interpreter, nameprop, key);
VTABLE_setprop(interpreter, item, NAME, nameprop);
item-vtable = Parrot_base_vtables[dynclass_PyNCI];
Re: Test::Legacy warnock'd
-BEGIN PGP SIGNED MESSAGE- Moin, On Tuesday 21 December 2004 08:53, Michael G Schwern wrote: I've gotten absolutely no response about Test::Legacy. Is anybody using it? Anybody tried migrating old Test.pm based tests with it? I am converting my old tests directly to Test::More (Test::legacy wasn't available before so :) Currently I do not plan to do this - the old tests either work (never fix what is working) or they don't (seldom), at which point I would convert them to Test::More. Best wishes, Tels - -- Signed on Tue Dec 21 16:51:54 2004 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. Elliot, sie Schwachkopf! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iQEVAwUBQchG+HcLPEOTuEwVAQG3hQf/QJa3/rTZXr1VDQ5trSeZ7Ip+SAf57mkj /WHqxi3riUmwobJMfI2OrOGgN04ciY2dGLrVVDSwy2KOiKzetQ3uLJC/AyryoV/h FyuQRSHNEYi3h1jucWRAsNrTiFcRYIou+yRoVxy04x5RkSmH2sDgPnlzIsPewZFx EtOxQMajJM+8jk6uBtPwkVBD0pF2Huru8oag8wxQdhIMKDnS3KEDWo03QeoFyQF9 3NjGEXKeW+KV3LIPZTLWubSZFv+NvxpuPiydgRnyv9pLGMGKMVgr8B78pCyQa/Rz JOsmcjMG7ciLQcrR6W0qiCsXNCEUNjwia5zmsJ8LzuYNV6i7fvmFqQ== =sJ4Y -END PGP SIGNATURE-
Re: Test::Legacy warnock'd
-BEGIN PGP SIGNED MESSAGE- Moin, On Tuesday 21 December 2004 18:32, Michael G Schwern wrote: On Tue, Dec 21, 2004 at 04:53:18PM +0100, Tels wrote: On Tuesday 21 December 2004 08:53, Michael G Schwern wrote: I've gotten absolutely no response about Test::Legacy. Is anybody using it? Anybody tried migrating old Test.pm based tests with it? I am converting my old tests directly to Test::More (Test::legacy wasn't available before so :) Currently I do not plan to do this - the old tests either work (never fix what is working) or they don't (seldom), at which point I would convert them to Test::More. There's no I want to add a new test to this test file that uses Test.pm and it would be nice if I could use Test::Foo case? Depending on the size of the testfile and my mood to change, I either grudgingly add another ok() (if the test-cases aren't in the data section anyway), or convert it to Test::More straightaway. Granted, that was what I did before Test::Legacy, which seems to have gone from a wild idea to some working stage while I was not looking :) So, what would the benefit of using Test::Legacy? Reading the pod I do not see for me why I should use it, because I only ever used Test.pm, or Test::More and never both of them in the same test script. (I try to keep my tests simple so that even people like me in 3 months understand them :) Yes, I could go all nillywilly :) and change every use Test; to use Test::Legacy; but as I said, don't fix what aint borkened. Of course, unless you tell me that use Test; _is_ broken and one should replace it :o) I am really open-minded about this. Maybe there are problems which I simple haven't noticed yet - my experience is quite limited. Afterthought: Oooh, you mean I change: use Test; to: use Test::Legacy; use Test::More; and slap an is() a the end? Wow, that would be nifty. You should mention this in the docs! I do think that I still would convert the tests eventually to Test::More, but for the more huge test files that would be a nice intermidiate solution.. Best wishes, Tels - -- Signed on Tue Dec 21 17:53:08 2004 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. Laugh and the world laughs with you, snore and you sleep alone. -- Unknown -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iQEVAwUBQchY1HcLPEOTuEwVAQEKyAf9GtIWdmx8KSgBsl5osrhVjbv/48B1tTqX ny48s5U2vOGbCUqt06NNd40WrXBd5O/N41SINXyXSbkVerNOBHuxQNurvW+LLUA1 +h5FyL1DLx55cEtoSj/wllQhj14M4iSAcC8N+/4wJqdK47gz+O1heQ5ug0wJK4GU nvWP4OilsF2GvOlb/7Gg52JFsjx51johuTBmesQUe9r6h8v8naWKFn65ItqWnJF8 Ier32h3dMV6y2ke3iNvL+s/jKadE59nt2YN8kfgsdf6wnzUurr7dUnTFz5uhDlFv F7xr3Vq1V0hFEswyuLCeuJC6Uhpz4Z3i3mTMk7++QjehYMlp1Qpfyg== =hQBz -END PGP SIGNATURE-
Re: Test::Legacy warnock'd
-BEGIN PGP SIGNED MESSAGE- Moin, On Tuesday 21 December 2004 19:35, Michael G Schwern wrote: On Tue, Dec 21, 2004 at 06:09:40PM +0100, Tels wrote: Granted, that was what I did before Test::Legacy, which seems to have gone from a wild idea to some working stage while I was not looking :) Most of it was written in about an hour and a half late one night with another hour worth of polishing. I decided rather than try to somehow merge with the Test.pm code base, which looked daunting, I'd see how far I could get prototyping it up from scratch. Answer: nearly all the way! Not because it was easy, but because you a genius :) Oooh, you mean I change: [schnipp] By jove I think he's got it! I'll make the docs a little more explicit about that though. Not everybody is knee-deep in testing and all that stuff. In fact, I would say most normal authors are probably a bit out of the loop and really need docs to tell them the why and how. So far quite a lot of the docs (if not most) talk about how, but not why you would want to use that module, or what it is for. Unfortunately, the person most likely to fix the docs, the author, usually doesn't need nor read them, and even if he did, he wouldn't notice that something is wrong. Best wishes, Tels - -- Signed on Tue Dec 21 19:05:07 2004 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. Retsina? - Ja, Papa? - Rasenmähen. - Is gut, Papa. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iQEVAwUBQchm9XcLPEOTuEwVAQF4Hwf/RvUw7XZVF0W7rE0wgv8pCq6LvmwNkfp8 NAsH4Ec6f5Q1jhKharcfs7WKIj3tot051GKZBVa5g3tbhLF2KtJZ17duV7FrznM7 yVtPvjhQ8ndetm1+88K5POYtD9IL28f3d+a1z0yCSziSkEApUYYc077f/OD/VY1l 5BNUYdevPzyo7q3f5SytUxpNStqj3xddxUnvv5K+HFbX1SpAPWWaKcZbwIe15aQR To7XrkyEtfx7TuR9yeOD21FORr2hmR8OjjxWqL7VHYFs7FxvzCW9e1Z6Aiq/6Ji1 Tm+q3YinJ93548jSVGXENJiFKVdVvyBLXX3gfG2HPOmiSF5/eD//vA== =3x9u -END PGP SIGNATURE-
Re: Auto My?
On Mon, 20 Dec 2004, James Mastros wrote: OTOH, I realize now you can do that with zip in P6, in which case you do have a mention of the whole variable to stick a my on -- Cmy %foo = zip(@keys, @values); I think Cmy [EMAIL PROTECTED] = @values; reads better though, even though looking at it literally, you're attempting to lexicalize an element. But dealing with a natural language, or with a programming language that is so strongly inspired by natural languages it doesn't seem so mandatory to have to look at it literally. I don't know if it will be eventually chosen so, but since (even intuitively speaking) you can't lexicalize an element of an aggregate, an alleged attempt to do so could perfectly well be Perl's lingo for what some people already think to be a logical way to interpret it... Michele -- The trouble with engineers is that given the problem of knocking down a stack of 100 bricks, they will start at the top, and work all day removing them one at a time, while the mathematician will, after a momemt's thought, remove the bottom brick and be done with it. The trouble part, is having to brook the noise of the engineer boasting about how much harder he worked while one is trying to think about the next problem. - Bart Goddard in sci.math
