Re: TAP::Harness
On Sunday 02 July 2006 01:24, Michael G Schwern wrote: On 7/1/06, Shlomi Fish [EMAIL PROTECTED] wrote: One thing I'm wondering about is whether you are going to code all of this into TAP::Harness from scratch. I believe I mentioned, I intend to steal lots of code from Test::Harness and Straps. Steal in the cut paste sense. I have already adapted much of Straps-analyze_line as well as copied Point and Results wholesale. OK. Good. Folks might cringle at the cut paste, but I do not TAP::Harness to have any dependencies upon Test::Harness. Plus, I've also been planning similar things for Test::Run too, (and already started implementing to some extent) I glanced at Test::Run today and had two initial observations. 1) Your licensing is possibly incompatible. You're using a mix of MIT X11, BSD and Artistic. I'm not familiar with the former two. I can't use anything not licensed Perl style. For one, it will not be able to enter the core. OK, OK. Let me explain. When I say BSD there, it's actually MIT X11 and that's because the MIT X11 licence falls under the BSD licenses. The reason it says so is because module-starter did not have a choice for MIT X11, and so BSD was the closest thing. Not what are MIT X11/BSD? They are Public Domain-like licences that basically allow *almsot anything* to be done with the code (including relicensing under any different licences). For more information see: http://www.faqs.org/docs/artu/ch19s05.html http://blogs.zdnet.com/Burnette/?p=130 http://blogs.zdnet.com/Burnette/?p=131 Now where it was used? Whenever I wrote entirely new code, from scratch. And I used the MIT X11 licence because I like to use it for code I'm starting from scratch, because it's the closest one get to Public Domain but keeping it copyrighted and without the warranty clause. There isn't any legal problem because MIT X11 is compatible with anything, and you can relicense it to the GPL+Artistic or whatever, or include it at the core using this licence. 2) I think your model does not perform a clean enough break with Test::Harness compared to what I'm planning. I realize this claim is vapor until I post the design. Yes. PS You might want to fix your copyright notices. I thank you for retaining our copyright for our portions of the code you took from Test::Harness but we do not have copyright over Test::Run::Obj, for example. IANAL so I don't know what should be there, but it probably shouldn't just be me and Andy. Test::Run::Obj is derived from Test::Harness. From what I recall, I left the copyright notice verbatim from Test::Harness. (and to not complicate things further, diclaimed any ownership of my own changes). I'd hate to see some duplicate effort. Sometimes you have to make a clean break with the past. The code in Test::Harness was started almost 20 years ago. That's right, t/TEST in Perl 1 became Test::Harness. Its designed along procedural lines and we've been trying to slowly morph it into a more flexible model over the years and still haven't succeeded. Its not a large or complex module, it should not take this long I see. Further, I think the duplication is healthy. Part of the problem with Test::Harness is its the only game in town. Its the only thing which can parse TAP. Its very bad for a protocol to have only one implementation. The monolithic and inflexible nature of Test::Harness has held back Perl testing in the last few years. Having more than one TAP harness implementation will be healthy. OK. I'm starting over. You're free to do whatever you want. Please do not consider this email as an attack against your attempt to write code or fix what's broken with Test::Harness. I don't mind having some competition. However, I'm trying to see whether there is some way we can consolidate our efforts. Licencing issues mentioned above prevent any code sharing, but I'll look at your lightning talk and see what ideas I can steal. Thanks. And like I said the licencing issues are non-existent. If you wish, you can take my original MIT X11 code and relicence it with the GPL+Artistic licence. But you can also safely use it as it is, which would be preferable. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: TAP extension proposal: test groups
On 02/07/06, chromatic [EMAIL PROTECTED] wrote:
On Saturday 01 July 2006 16:46, Fergal Daly wrote:
It looks like it's only one level of nesting. Any reason not to go the
whole hog with something like
..1
OK 1
..2
...1
OK 2
OK 3
...2
OK 4
..3
OK5
No one has provided an actual use case for it yet. YAGNI.
I think I've misinterpreted the numbers. Each one is a plan, not a group number.
Here's the use case I was thinking of
use Test::More tests = 1;
my $l = Leopard-new();
IsALeopard($l);
sub IsALeopard {
my $thing = shift;
my $g = Group(tests = 4);
IsACat($thing);
HasSpots($thing);
Colour(yellow);
Colour(black);
# $g gets destroyed, we leave the block
}
sub IsACat {
my $thing = shift;
my $g = Group(test = 3);
IsAMammal($thing);
HasWhiskers($thing);
Likes(milk);
# $g gets destroyed, we leave the block
}
which isn't supported supported by the above,
F
Re: [BUG] parrot 0.4.5: Configure.pl: tru64
On Jul 1, 2006, at 21:42, Jarkko Hietaniemi wrote: (1) I don't know all those -libraries are being listed, the test program certainly doesn't need them... yes, the linker should know to ignore them as unused... but: (2) This is not Linux so that -lgmp and -lreadline are not standard but have been compiled and installed by the sysadmins (not admin) and: (3) They most definitely have not been compiled with cxx, but most probably with gcc. And I have no idea whether the libreadline.so actually works, since I haven't lately tried to compile anything with it. In non-Linux systems one cannot always assume installed GNU stuff works and/or is uptodate... -lgmp or -lreadline are either just coming from (a) the equivalent perl settings or are the result of an (b) earlier test. For (a) the libs could be disabled in the hints file [1]. For (b) we'd need some commandline and hints settings like: 'no-readline' or such, which disables this lib. [1] config/init/hints/* leo
Re: TAP extension proposal: test groups
chromatic wrote: On Saturday 01 July 2006 16:46, Fergal Daly wrote: It looks like it's only one level of nesting. Any reason not to go the whole hog with something like ..1 OK 1 ..2 ...1 OK 2 OK 3 ...2 OK 4 ..3 OK5 No one has provided an actual use case for it yet. YAGNI. I've got plenty of test fixtures where subroutine X with tests calls subroutine Y with tests. Or a loop calls a subroutine with tests. It would be intuitive to group and nest those. David Golden
Re: [BUG] parrot 0.4.5: Configure.pl: tru64
Leopold Toetsch wrote: On Jul 1, 2006, at 21:42, Jarkko Hietaniemi wrote: (1) I don't know all those -libraries are being listed, the test program certainly doesn't need them... yes, the linker should know to ignore them as unused... but: (2) This is not Linux so that -lgmp and -lreadline are not standard but have been compiled and installed by the sysadmins (not admin) and: (3) They most definitely have not been compiled with cxx, but most probably with gcc. And I have no idea whether the libreadline.so actually works, since I haven't lately tried to compile anything with it. In non-Linux systems one cannot always assume installed GNU stuff works and/or is uptodate... -lgmp or -lreadline are either just coming from (a) the equivalent perl settings or are the result of an (b) earlier test. For (a) the libs could be disabled in the hints file [1]. For (b) we'd need some commandline and hints settings like: 'no-readline' or such, which disables this lib. But the -lreadline is needed for something later? [1] config/init/hints/* leo
Re: [BUG] parrot 0.4.5: Configure.pl: tru64
On Jul 2, 2006, at 15:04, Jarkko Hietaniemi wrote: But the -lreadline is needed for something later? If readline is available, it can be used at interactive prompts, but it's not absolutely needed. $ cd languages/perl6/ ... [EMAIL PROTECTED] $ ../../parrot perl6.pbc p6 say 'ok' ok p6 leo
Re: TAP extension proposal: test groups
On 1 Jul 2006, at 23:38, Michael G Schwern wrote:
Cons?
* Doesn't handle nested groups - but I have to admit that's a use
case I've never wanted :-)
* Doesn't handle groups with an undefined number of tests. The
obvious solution would be to allow .. sans numeric suffix so you
would have something like
..2 - I want to run two tests
ok 1
ok 2
.. - I don't know how many tests in this group
ok 3
ok 4
ok 5
ok 6
..1 - one last test
ok 7
1..7
* since there is no end of group marker you get problems when
mixing grouped and non-grouped tests together. Let's pretend
Test::Block output TAP with this format.
use Test::More 'no_plan';
use Test::Block qw( $Plan );
{
local $Plan = 2;
pass 'first test';
# oops - forgot second test
}
pass 'non-grouped test';
gives us
..2
ok 1 - first test
ok 2 - non-grouped test
1..2
which misses the fact the second test isn't intended to be part of
the group. This is nasty enough to need fixing IMO.
* Another use case that this doesn't support is having the output
from different test groups interleaved. This is something that I
would have found useful on the occasions that I've built test farms
that collate the TAP output from different machines together. Rather
than wait for each to finish and output everything together it would
be nice to be able to do something like:
ok 1.1 - first result from first group
ok 2.1 - first result from second group
ok 2.2 - second result from second group
ok 1.2 - second result from first group
Although this could also be handled by a test runner that was bright
enough to read multiple streams at the same time - which might be a
better solution than making TAP more complex now that I think of it...
Cheers,
Adrian
Re: TAP::Harness
On 1 Jul 2006, at 20:36, Michael G Schwern wrote: [snip] * How can I help? Provide use cases, what would you want to do with Test::Harness if you could? What are you doing with Straps? What features do other testing systems (JUnit, for example) have that you'd like to see in Perl? Once I post the design, pick it to pieces. Use case: Run test scripts simultaneously I sometimes split up long test runs by running multiple test scripts on multiple machines, or on the same machine where multiple CPUs, blocking for IO, etc. means I'll get quicker results. Test::Harness currently forces me to process the test results in series - which means that I can wait longer than necessary to discover a test failure that's been processed, but is waiting behind a longer running test script. I'd like TAP::Harness to be able to accept multiple streams of TAP input that it can process simultaneously. Cheers, Adrian
[PATCH] #38627: [TODO] fill Parrot_register_move() with code
This patch implements the register content preserving move operation.
Thanks,VishalPreviously:-Now:1..3ok 1 - in P paramok 2 - tailcall 1not ok 3 - tailcall 2 # TODO use temp# Failed (TODO) test (t/compilers/imcc/imcpasm/optc.t at line 59)
# '# IMCC does produce b0rken PASM files# # see http://[EMAIL PROTECTED]/rt3/Ticket/Display.html?id=32392# _main:# @pcc_sub_call_0:
# set_args# set_p_pc P0, foo# get_results# invokecc P0# set_returns# returncc# foo:# get_params# [EMAIL PROTECTED]:# @pcc_sub_call_1:# set I0, I1# set I1, I0# branch [EMAIL PROTECTED]
# '# doesn't match '/ set I(\d), I(\d)# set I\2, I(\d)# set I\3, I\1/# '--1..3ok 1 - in P paramok 2 - tailcall 1ok 3 - tailcall 2 # TODO use temp
Patch:---Index: src/utils.c===--- src/utils.c (revision 13113)+++ src/utils.c (working copy)@@ -48,6 +48,7 @@=cut
*/+#define MAX_REGISTER 256INTVALintval_mod(INTVAL i2, INTVAL i3)@@ -678,12 +679,29 @@TODO add a define, if it's implemented so that we can start filling the gaps+TODO The current implementation will not work for following cases
++1. I0-I1 I1-I0 I0-I3+2. I1-I2 I3-I2++Vishal Soni=cut*//* proto TODO mv to hdr */typedef int (*reg_move_func)(Interp*, unsigned char d, unsigned char s, void *);
+int reorder_move(unsigned char (*a)[MAX_REGISTER],unsigned char *val ,int src , int prev, int depth ,reg_move_func mov,Interp *interpreter,void *info,int temp);+int find_first_indegree(unsigned char (*a)[MAX_REGISTER] , int dest);
+int find_root(unsigned char (*a)[MAX_REGISTER],unsigned char* root_vertex ,int src, int dest);+void emit_mov(reg_move_func mov,Interp *interpreter,void *info,int emit,int emit_temp,int src,int dest,int temp);
+void+Parrot_register_move(Interp *interpreter, int n_regs,+ unsigned char *dest_regs, unsigned char *src_regs,+ unsigned char temp_reg,+ reg_move_func mov,
+ reg_move_func mov_alt,+ void *info);voidParrot_register_move(Interp *interpreter, int n_regs,@@ -693,16 +711,113 @@ reg_move_func mov_alt, void *info)
{- int i;+ //int i; /* TODO */ /* brute force and wrong */- for (i = 0; i n_regs; ++i) {+ /* for (i = 0; i n_regs; ++i) { if (dest_regs[i] != src_regs[i])
mov(interpreter, dest_regs[i], src_regs[i], info);+ printf(Vishal:[%d],[%d]\n,dest_regs[i],src_regs[i]);+ }*/++ int i;+ unsigned char (*reg_move_graph)[MAX_REGISTER] = (unsigned char (*)[MAX_REGISTER])mem_sys_allocate_zeroed(sizeof (unsigned char)*MAX_REGISTER *MAX_REGISTER);
+ unsigned char *root_vertx= (unsigned char *)mem_sys_allocate_zeroed(sizeof (unsigned char)*MAX_REGISTER);++ for (i = 0 ; i n_regs; i++)+ {+ reg_move_graph[src_regs[i]][dest_regs[i]]=1;
+ root_vertx[find_root(reg_move_graph,root_vertx,src_regs[i],dest_regs[i])]=1; }++ unsigned char *val = (unsigned char *)mem_sys_allocate_zeroed(sizeof (unsigned char)*MAX_REGISTER);+ for (i = 0 ; i MAX_REGISTER; i++)
+ {+ if (root_vertx[i]0)+ {+ mov(interpreter,temp_reg,i,info);+ reorder_move(reg_move_graph,val,i,-1,0,mov,interpreter,info,temp_reg);+ }+ }
+ free(val);+ free(reg_move_graph);+ free(root_vertx);}+int find_root(unsigned char (*a)[MAX_REGISTER],unsigned char* root_vertex ,int src, int dest)+{+ if (a[src][dest]==2)
+ {+ a[src][dest]=1;+ return dest;+ }+ root_vertex[src]=0;+ a[src][dest]=2;+ int in_degree=find_first_indegree(a,src);+ if (in_degree==-1)
+ {+ a[src][dest]=1;+ return src;+ }+ return find_root(a,root_vertex,in_degree,src);+}++int find_first_indegree(unsigned char (*a)[MAX_REGISTER] , int dest)
+{+ int i=0;+ for( i= 0; iMAX_REGISTER; i++)+ {+ if (a[i][dest] 0 )+ {+ return i;+ }+ }
+ return -1;+}+int reorder_move(unsigned char (*a)[MAX_REGISTER],unsigned char (*val),int src , int prev, int depth , reg_move_func mov,Interp *interpreter,void *info,int temp)+{+ int i=0;+ val[src]=1;
+ for (i=0;iMAX_REGISTER;i++)+ {+ if (a[src][i]0 )+ {+ if (val[i]==1)+ {+ emit_mov(mov,interpreter,info,prev,0,i,src,temp);+ emit_mov(mov,interpreter,info,prev,depth = 1,src,prev,temp);
+ return 1;+ }+ if (val[i]!=2 )+ {+ depth++;+ int x=reorder_move(a,val,i,src,depth,mov,interpreter,info,temp);+ depth--;
+ emit_mov(mov,interpreter,info,prev,x (depth = 1),src,prev,temp);+ return x;+ }+ }+ }+ val[src]=2;+ emit_mov(mov,interpreter,info,prev,0,src,prev,temp);
+ return 0;+}++void emit_mov(reg_move_func mov,Interp *interpreter,void *info,int emit,int emit_temp,int dest,int src,int temp)+{+ if (emit -1 )+ {+ if (emit_temp)
+ {+ mov(interpreter,dest,temp,info);+ }+ else+ {+ mov(interpreter,dest,src,info);+ }
+ }+}/*=back
Index: src/utils.c
===
--- src/utils.c (revision 13113)
+++ src/utils.c (working copy)
@@ -48,6 +48,7 @@
=cut
*/
+#define MAX_REGISTER 256
INTVAL
intval_mod(INTVAL i2, INTVAL i3)
@@ -678,12 +679,29 @@
TODO add a define, if it's implemented so that we can start filling the gaps
+TODO The current implementation will not work for following cases
+
+1. I0-I1 I1-I0 I0-I3
+2. I1-I2 I3-I2
+
+Vishal Soni
=cut
[perl #39683] [PATCH] #38627: [TODO] fill Parrot_register_move() with code
# New Ticket Created by Vishal Soni
# Please include the string: [perl #39683]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39683
This transaction appears to have no contentThis patch implements the register content preserving move operation.
Thanks,
Vishal
Previously:
-
Now:1..3
ok 1 - in P param
ok 2 - tailcall 1
not ok 3 - tailcall 2 # TODO use temp
# Failed (TODO) test (t/compilers/imcc/imcpasm/optc.t at line 59)
# '# IMCC does produce b0rken PASM files
# # see http://[EMAIL PROTECTED]/rt3/Ticket/Display.html?id=32392
# _main:
# @pcc_sub_call_0:
# set_args
# set_p_pc P0, foo
# get_results
# invokecc P0
# set_returns
# returncc
# foo:
# get_params
# [EMAIL PROTECTED]:
# @pcc_sub_call_1:
# set I0, I1
# set I1, I0
# branch [EMAIL PROTECTED]
# '
# doesn't match '/ set I(\d), I(\d)
# set I\2, I(\d)
# set I\3, I\1/
# '
--
1..3
ok 1 - in P param
ok 2 - tailcall 1
ok 3 - tailcall 2 # TODO use temp
Patch:
---Index: src/utils.c
===
--- src/utils.c (revision 13113)
+++ src/utils.c (working copy)
@@ -48,6 +48,7 @@
=cut
*/
+#define MAX_REGISTER 256
INTVAL
intval_mod(INTVAL i2, INTVAL i3)
@@ -678,12 +679,29 @@
TODO add a define, if it's implemented so that we can start filling the
gaps
+TODO The current implementation will not work for following cases
+
+1. I0-I1 I1-I0 I0-I3
+2. I1-I2 I3-I2
+
+Vishal Soni
=cut
*/
/* proto TODO mv to hdr */
typedef int (*reg_move_func)(Interp*, unsigned char d, unsigned char s,
void *);
+int reorder_move(unsigned char (*a)[MAX_REGISTER],unsigned char *val ,int
src , int prev, int depth ,reg_move_func mov,Interp *interpreter,void
*info,int temp);
+int find_first_indegree(unsigned char (*a)[MAX_REGISTER] , int dest);
+int find_root(unsigned char (*a)[MAX_REGISTER],unsigned char* root_vertex
,int src, int dest);
+void emit_mov(reg_move_func mov,Interp *interpreter,void *info,int emit,int
emit_temp,int src,int dest,int temp);
+void
+Parrot_register_move(Interp *interpreter, int n_regs,
+unsigned char *dest_regs, unsigned char *src_regs,
+unsigned char temp_reg,
+reg_move_func mov,
+reg_move_func mov_alt,
+void *info);
void
Parrot_register_move(Interp *interpreter, int n_regs,
@@ -693,16 +711,113 @@
reg_move_func mov_alt,
void *info)
{
-int i;
+//int i;
/* TODO */
/* brute force and wrong */
-for (i = 0; i n_regs; ++i) {
+ /* for (i = 0; i n_regs; ++i) {
if (dest_regs[i] != src_regs[i])
mov(interpreter, dest_regs[i], src_regs[i], info);
+printf(Vishal:[%d],[%d]\n,dest_regs[i],src_regs[i]);
+}*/
+
+int i;
+unsigned char (*reg_move_graph)[MAX_REGISTER] = (unsigned char
(*)[MAX_REGISTER])mem_sys_allocate_zeroed(sizeof (unsigned
char)*MAX_REGISTER *MAX_REGISTER);
+unsigned char *root_vertx= (unsigned char
*)mem_sys_allocate_zeroed(sizeof (unsigned char)*MAX_REGISTER);
+
+for (i = 0 ; i n_regs; i++)
+{
+reg_move_graph[src_regs[i]][dest_regs[i]]=1;
+
root_vertx[find_root(reg_move_graph,root_vertx,src_regs[i],dest_regs[i])]=1;
}
+
+unsigned char *val = (unsigned char *)mem_sys_allocate_zeroed(sizeof
(unsigned char)*MAX_REGISTER);
+for (i = 0 ; i MAX_REGISTER; i++)
+{
+if (root_vertx[i]0)
+{
+mov(interpreter,temp_reg,i,info);
+
reorder_move(reg_move_graph,val,i,-1,0,mov,interpreter,info,temp_reg);
+}
+}
+free(val);
+free(reg_move_graph);
+free(root_vertx);
}
+int find_root(unsigned char (*a)[MAX_REGISTER],unsigned char* root_vertex
,int src, int dest)
+{
+ if (a[src][dest]==2)
+ {
+ a[src][dest]=1;
+ return dest;
+ }
+ root_vertex[src]=0;
+ a[src][dest]=2;
+ int in_degree=find_first_indegree(a,src);
+ if (in_degree==-1)
+ {
+ a[src][dest]=1;
+ return src;
+ }
+ return find_root(a,root_vertex,in_degree,src);
+}
+
+int find_first_indegree(unsigned char (*a)[MAX_REGISTER] , int dest)
+{
+ int i=0;
+ for( i= 0; iMAX_REGISTER; i++)
+ {
+ if (a[i][dest] 0 )
+ {
+ return i;
+ }
+ }
+ return -1;
+}
+int reorder_move(unsigned char (*a)[MAX_REGISTER],unsigned char (*val),int
src , int prev, int depth , reg_move_func mov,Interp *interpreter,void
*info,int temp)
+{
+int i=0;
+val[src]=1;
+for (i=0;iMAX_REGISTER;i++)
+{
+if (a[src][i]0 )
+{
+if (val[i]==1)
+{
+ emit_mov(mov,interpreter,info,prev,0,i,src,temp);
+ emit_mov(mov,interpreter,info,prev,depth =
1,src,prev,temp);
+return 1;
+}
+if
Re: TAP extension proposal: test groups
Fergal Daly wrote: It looks like it's only one level of nesting. Any reason not to go the whole hog with something like ..1 OK 1 ..2 ...1 OK 2 OK 3 ...2 OK 4 ..3 OK5 I believe the conclusion here was that because demand for nested groups appeared to be extremely limited, to START with just the one level, with the notion of nested groups having that syntax, but not included in the specification or implementation until there's been time for the initial group code to settle down. So we have a place to put nests should we need to, but it would complicate implementation greatly if we had it immediately. Adam K
Re: TAP extension proposal: test groups
On 02/07/06, Adam Kennedy [EMAIL PROTECTED] wrote: Fergal Daly wrote: It looks like it's only one level of nesting. Any reason not to go the whole hog with something like ..1 OK 1 ..2 ...1 OK 2 OK 3 ...2 OK 4 ..3 OK5 I believe the conclusion here was that because demand for nested groups appeared to be extremely limited, to START with just the one level, with the notion of nested groups having that syntax, but not included in the specification or implementation until there's been time for the initial group code to settle down. So we have a place to put nests should we need to, but it would complicate implementation greatly if we had it immediately. Since my understanding of the notation was wrong, my proposed notations is wrong. That said, I'm not sure how the above extends to nested groups. F Adam K
Re: TAP::Harness
* How can I help? Provide use cases, what would you want to do with Test::Harness if you could? What are you doing with Straps? What features do other testing systems (JUnit, for example) have that you'd like to see in Perl? Once I post the design, pick it to pieces. I know I mentioned it to you before, but there's the PITA case, which basically goes... Capture and extract the raw TAP output from a set of named tests (files, urls etc) and do negligable or no analysis, because the analysis will be done outside the current environment. Adam K
Re: TAP::Harness
The most up-to-date Test-Run code is here: http://svn.berlios.de/svnroot/repos/web-cpan/Test-Harness-NG/ I don't mind giving Subversion access to the repository to anyone who registers in http://developer.berlios.de/ and is either a CPAN contributor, or has sent me one patch for me to commit. With Adam Kennedy's permission, I can also move the files to his Subversion repository, where everyone with a PAUSE ID can commit to. I'd prefer not to add it at this point. That's not so much because of the code itself, but because currently it's MY repository for the module _I_ maintain, please a few other things I'm very very tight with and likely to have to do releases for anyway (PITA/Win32). They are structured a certain way, the licenses must be Perl (at present the dist-builder would change your license at release time) and it's build around the way I do things. While it might some time in the future end up as the kernel of some sort of larger svn.cpan.org it is absolutely NOT that at the moment. That particular issue is one I want a year or so of experience with the current setup under my belt before I address. But you also have dozens of modules, so I imagine it would be worth you just creating your own setup, be it Trac, Insurrection (assuming you can get the damned thing installed) or otherwise. That way you're able to set it up as you like, rather than me forcing my structures and policies onto you. Adam K
Re: TAP::Harness
Michael G Schwern wrote: On 7/1/06, Yuval Kogman [EMAIL PROTECTED] wrote: Please look at Test::TAP::Model and the horrrible hooks it goes through to make things work. I'd love to have a SAX like event-handler model for TAP through TAP::Harness so that I can construct Test::TAP::Model objects in a cleaner way (without the parser-is-the-model and all that mess). Yes, it is SAXy. You have Adam to thank for that. As my flight is delayed I'll try to make a stab at posting up the basic design. If it wasn't for the fact this code needs to live in toolchainland (that evil environment where you can't have dependencies and bug damage is amplified) I'd still say you could ACTUALLY use SAX, so we have TAPML :) But maybe that's a task for another day, to interface the TAP event model to SAX... Adam K
Re: TAP extension proposal: test groups
Fergal Daly wrote: On 02/07/06, Adam Kennedy [EMAIL PROTECTED] wrote: Fergal Daly wrote: It looks like it's only one level of nesting. Any reason not to go the whole hog with something like ..1 OK 1 ..2 ...1 OK 2 OK 3 ...2 OK 4 ..3 OK5 I believe the conclusion here was that because demand for nested groups appeared to be extremely limited, to START with just the one level, with the notion of nested groups having that syntax, but not included in the specification or implementation until there's been time for the initial group code to settle down. So we have a place to put nests should we need to, but it would complicate implementation greatly if we had it immediately. Since my understanding of the notation was wrong, my proposed notations is wrong. That said, I'm not sure how the above extends to nested groups. The idea was that the number of dots determines nesting level... ..2 (group of 5) ...3 (subgroup of 3) Adam K
Re: TAP extension proposal: test groups
On 01/07/06, Michael G Schwern [EMAIL PROTECTED] wrote: The PITA / TestBuilder2 BOF at YAPC whacked up this TAP extension. Test groups in TAP. There are several use-cases here. 1. I want to name a group of tests rather than the individuals. 2. I don't want to have to count up the total number of tests in my file but I do want the protection of the plan. I'd like to be able to say I'm going to run 5 tests. I'm going to run 4 more tests. Now 8 more. 3. The spew to STDERR from my code when it does something wrong cannot be associated with a single test. But if I had a test grouping I could associate it with that group. Here's what we came up with. 1..10 ..4 - name for this group ok 1 ok 2 ok 3 ok 4 ..2 - I will call this group Bruce ok 5 ok 6 ..4 ok 7 ok 8 ok 9 ok 10 Pros: * Its backwards compatible. The ..# lines are currently considered junk and ignored. * Its pretty readable. * It solves #1 * Combined with 'no_plan' it solves #2. ..2 ok 1 ok 2 ..3 ok 3 ok 4 ok 5 1..5 * It solves #3. 1..5 ..3 ok 1 Oh god, the hurting oh dear, oh god at Foo.pm line 23 not ok 2 # Failed test ... # got : this # expected: that ok 3 ..2 ok 4 ok 5 Cons? There's no way to declare a top-level plan. That is, I can't say how many groups of tests I'm going to run so there's effectively no plan, F
Re: TAP extension proposal: test groups
There's no way to declare a top-level plan. That is, I can't say how many groups of tests I'm going to run so there's effectively no plan, One point that Andy was extremely insistant on, and I think Schwern and I agree, is that the main plan is ALWAYS the total number of tests for the entire test script. In that case, groups form an additional set of checks, but do NOT alter the plan for the entire script. Adam K
Re: TAP extension proposal: test groups
On 02/07/06, Adam Kennedy [EMAIL PROTECTED] wrote: There's no way to declare a top-level plan. That is, I can't say how many groups of tests I'm going to run so there's effectively no plan, One point that Andy was extremely insistant on, and I think Schwern and I agree, is that the main plan is ALWAYS the total number of tests for the entire test script. In that case, groups form an additional set of checks, but do NOT alter the plan for the entire script. That contradicts #2 I don't want to have to count up the total number of tests in my file but I do want the protection of the plan. but looking again, I see that the example does include an overall plan that does count up the total. Is the example correct? F
Re: [BUG] parrot 0.4.5: Configure.pl: tru64
Leopold Toetsch wrote: On Jul 2, 2006, at 15:04, Jarkko Hietaniemi wrote: But the -lreadline is needed for something later? If readline is available, it can be used at interactive prompts, but it's not absolutely needed. I think I will first try to get the admins to get compile a newer libreadline.
Re: TAP extension proposal: test groups
Fergal Daly wrote: On 02/07/06, Adam Kennedy [EMAIL PROTECTED] wrote: There's no way to declare a top-level plan. That is, I can't say how many groups of tests I'm going to run so there's effectively no plan, One point that Andy was extremely insistant on, and I think Schwern and I agree, is that the main plan is ALWAYS the total number of tests for the entire test script. In that case, groups form an additional set of checks, but do NOT alter the plan for the entire script. That contradicts #2 I don't want to have to count up the total number of tests in my file but I do want the protection of the plan. but looking again, I see that the example does include an overall plan that does count up the total. There's four cases here. 1. Plan, no groups 2. No plan, no groups As is now 3. Plan, with groups The plan still is for the ENTIRE test script, but in addition within that total you can define groups to add extra protection or grouping information for diagnostics. 4. No plan, with groups In THIS case, the total of the script does not matter or may not be known, but you want protection of a sort of miniplan for specific sections. This does bring up a gap in the spec though (or I'm not remembering right). If you have the following, how do you tell where the end of the group is. Currently I think it would be implicit and unclear? (noplan) ok 1 ok 2 ..2 ok 3 ok 4 ok 5 ok 6 Adam K
DOC: glossary
hi to all docathon hackers (and others too), one idea we came up with during the docathon is that perl6 needs a glossary. would the terms autobox or mixin make any sense to a newcomer who didn't know any OO theory? so this is a proposal to start a glossary as a new S\d+ or other document. here are some ideas i have been bouncing in my skull that i would like to see in it: the list of terms should include all of perl6's special variable names, namespaces (including the term namespace! :), keywords, OO theory terms (like autobox). i think it should also include many/most of parrot's terms as there is some overlap. stuff like haskell, pugs, PGE, and others should also be included. i don't think perl6 ops should be included. each term should have a pronunciation if it isn't obvious. of course there should be a succinct definition of no more than a couple of sentences. a reference to the S\d+ docs that discuss the term in depth links/references to longer definitions on the web for non-perl specific terms like autobox. a 'see also' section referring to other terms. i think a pumpking should be annointed to own the master doc. this would be a great job for anyone who wants to help as you don't even need to understand all the terms or be a core perl6 hacker. you just need to know how to alphabetize, format and handle patches, google a bit for external links, track xrefs and see also's and such. this is basically an ongoing editor job. a first task would be to create this doc and to create a pod template for entries. then others can submit entries in that format or the pumpking can edit them into that format. we can start with just a list of terms and they can be filled out incrementally. i do expect this to be fairly large with several hundred terms. i will post a starter list of terms soon. it will just be words i have been seeing in S02 which is the spec i have been editing. all the other docathon hackers (and anyone else) can submit lists as well. when we have a pumpking, then the glossary doc itself can be started. if you want to submit entries do that too. thanx, uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: [BUG] parrot 0.4.5: Configure.pl: tru64
While you're waiting, we should improve the test for readline: we used to have similar failures where we found readline (or other probed thingees) but the version was not recent enough for us to link with. Regards. On Jul 2, 2006, at 4:47 PM, Jarkko Hietaniemi wrote: Leopold Toetsch wrote: On Jul 2, 2006, at 15:04, Jarkko Hietaniemi wrote: But the -lreadline is needed for something later? If readline is available, it can be used at interactive prompts, but it's not absolutely needed. I think I will first try to get the admins to get compile a newer libreadline. -- Will Coke Coleda [EMAIL PROTECTED]
Let's stop talking about test grouping and TAP extensions
I would like to suggest that we ignore the questions of test counting right now. In fact, let's leave Schwern alone until TAP::Harness has the functionality of Test::Harness. THEN we can argue about the new stuff. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: DOC: glossary
I haven't actually read your message, just the Subject, because I was just going to bed. Be sure to check out http://pugs.kwiki.org/?Perl6Nomenclature Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
[perl #39685] [CAGE] warning: no previous prototype
# New Ticket Created by Will Coleda # Please include the string: [perl #39685] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39685 Some parrot droppings... I get a few warnings of this type during build on OSX 10.4 with gcc 4.x on r13123. src/utils.c:695: warning: no previous prototype for 'Parrot_register_move' src/encodings/utf8.c:157: warning: no previous prototype for 'Parrot_utf8_encode' compilers/imcc/reg_alloc.c:56: warning: no previous prototype for 'ig_test' compilers/imcc/parser_util.c:782: warning: no previous prototype for 'IMCC_compile_file' compilers/ast/ast_main.c:31: warning: no previous prototype for 'ast_compile_past' -- Will Coke Coleda [EMAIL PROTECTED]
Are CATCH blocks still in effect when run?
From: Chip Salzenberg [EMAIL PROTECTED] Date: Sat, 24 Jun 2006 21:56:32 -0700 On Sat, Jun 24, 2006 at 11:18:41PM -0400, Bob Rogers wrote: . . . I even intend to use continations to implement THROW and CATCH; I just won't be able to expose them to users via standard Lisp constructs. So, yes, I could install the equivalent of an UNDO block around the Lisp code that does whatever Parrot maintenance is required on the Parrot exception object (which, it now occurs to me, may need to be distinct from the Lisp condition object). But would I really need to do anything here? If an exception is caught by Lisp, why would Parrot even need to know? S04 seems to require a great deal of bookkeeping for unhandled exceptions, but would that necessarily impact Lisp handlers? It's just a little hack, no big deal. Imagine this scenario: 1. Parrot has exceptions 2. Parrot requires handlers to mark exceptions handled with a caught [now handled] opcode 3. Parrot has dynamic-wind Given: (handler-case (signal condition) (printer-on-fire () YOUR_FORM_HERE)) Your CL compiler would replace YOUR_FORM_HERE with the equivalent of this, written in pidgin Scheme . . . Impressive. This is close to what I had in mind for the general case when I said I could install the equivalent of an UNDO block around the Lisp code ... above. It looks like you're beginning to think like a Lisp implementor. (Are you scared yet?) But your implementation is really for this use of HANDLER-BIND: (handler-bind ((printer-on-fire #'(lambda (cond) YOUR_FORM_HERE))) (signal condition)) (Please bear with me here, I'm trying to draw parallels between CL and Perl 6 error semantics.) Typically, HANDLER-CASE is implemented in terms of HANDLER-BIND, and creates a handler for PRINTER-ON-FIRE errors that does a nonlocal transfer-of-control to the dynamic context of the HANDLER-CASE. (This is easier, in that code emitted by the compiler knows that it's doing a nonlocal exit and can emit a Chandled op directly.) The YOUR_FORM_HERE body [1] therefore runs in the original HANDLER-BIND contenxt, not the error-signalling context. However, I notice that S04 doesn't explicitly specify the dynamic environment for anything evaluated in a CATCH block. (Indeed, it seems to use the terms handler and CATCH block interchangeably.) Would the CATCH block still be in scope as a handler while it was executing? This seems problematic, so I am hoping it's an oversight. If so, then that would make my life easier. A key aspect of both HANDLER-CASE and HANDLER-BIND is that none of the handlers they establish are in scope when those handlers are invoked. That way, if a badly-written handler should be prone to (re)igniting printers, you don't get looping. But if you really do want CATCH blocks to be in effect when run, then I have two ideas for PIR-level APIs for changing this default: 1. Implement catch-out-of-own-scope by default and let CATCH blocks re-establish themselves when they execute, e.g. by doing a Cpush_eh_self in the preamble; or 2. Store the list of active handlers in a global variable so that PIR handler code can rebind them dynamically. I suspect that the lexical nature of the 'handled' flag may not match the interpreter-wide-dynamic nature of the signal stack, leading to incorrect results with nested signals. But with that caveat, I think this would work. You might also get odd results if the context was re-entered and re-exited while some other error was being signalled. For instance, what would happen the second time your dynamic-wind cleanup block is run? (This couldn't happen in vanilla CL, but might in Parrot if the handler called something else that took a continuation.) However, this ought to be fixable by having the Chandled instruction mention the exception that it wants to mark as caught. -- Bob [1] The spec calls them error clauses; see http://www.lispworks.com/documentation/HyperSpec/Body/m_hand_1.htm#handler-case
Re: S04
在 2006/7/1 下午 6:08 時，Tom Allison 寫到： I picked this up at the YAPC and made some markups on it. Apologies that it is not in a diff format, but that's going to come with practice. ... is there a file attachment somewhere? :-) I got stuck on some of the intended behaviors and prohibited behaviors of the 'goto' function. For the purpose of clarity would it be useful to provide a series of specific test cases (in perl 5) to identify what it does today and what (if anything) it will do differently? Yes, that would be very useful. The Pugs t/builtins/control_flow/ goto.t in particular needs to include all the S04 forms; I have sent you a commit bit -- please checkout http://svn.openfoundry.org/pugs with Subversion, add yourself to AUTHORS, and change/augment goto.t to include those test cases. Thanks! Audrey PGP.sig Description: This is a digitally signed message part
Re: pdd21 vs. find_global
On Sat, Jul 01, 2006 at 05:10:59PM -0500, Chip Salzenberg wrote: Darn, find_global has collided with pdd21. Currently find_global is prepared to accept a key or a namespace, and distinguishing namespaces from arrays is starting to get just a little too polymorphic for an opcode. Agreed. And find_global gets a bit overloaded anyway. you change to $P99 = get_namespace key_or_array $P0 = $P99['foo'] which also incidentally encourages(!) compilers to cache namespace pointers. Ooh. I like it very much! Pm
Re: [perl #38594] [BUG] source line numbers
Will, Did we get this one in? -Vishal On 6/30/06, Vishal Soni [EMAIL PROTECTED] wrote: Hi, The .end seems to be replaced by an implicit end. -Vishal On 6/29/06, Will Coleda via RT [EMAIL PROTECTED] wrote: Hey, Vishal: [vsoni - Tue Jun 27 05:48:27 2006]: Hi, This was a straight forward fix. The line number was being decremented at the start of a 'sub' token imcc.y. Thanks, Vishal Here is a sample run Sample Code: --- .sub main :main print 2\n print 3\n print 4\n .end Output: ./parrot -d 10 ./hello.pir 1 last:5 pcc_sub main nparams 0 Dumping the instructions status: --- nins line blck deep flags type opnr size pc X ins 0100 0 8 -100 main: 1200 1 0 41320print 2\n 2300 1 0 41322print 3\n 3400 1 0 41324print 4\n 4400 0 18000016end Looks like the first line is fixed there (1) and then the guts are fixed (2,3,4), but is the duplicate line 4 correct? (is that corresponding to the implicit end that PIR puts in, or the .end of the subroutine? If you can just validate that, we can apply this. Labels namepos last ref --- Dumping the CFG: --- 0 (0)- - Dumping the Dominators Tree: --- 0 - ( 0) 0 Loop info - Patch Index: compilers/imcc/imcc.y = == --- compilers/imcc/imcc.y (revision 13035) +++ compilers/imcc/imcc.y (working copy) @@ -202,7 +202,7 @@ r-type = (r-type VT_ENCODED) ? VT_PCC_SUB|VT_ENCODED : VT_PCC_SUB; r-pcc_sub = calloc(1, sizeof(struct pcc_sub_t)); cur_call = r; -i-line = line - 1; +i-line = line ; add_namespace(interp, unit); return i; } -- Thanks, Vishal -- Thanks, Vishal
