Re: A proposition for streamlining Perl 6 development
I'd like to have a crack at rephrasing this, since everyone but stevan seems to be getting the wrong impression. Perl 6 has some hard to answer questions. The questions the community has answered so far are: * How the VM will work/look * What the syntax/feature requirements are If we ignore pugs for a second. These are though questions to answer, and I have no criticism whatsoever that they took long to answer. Development speed is *NOT* what this post was about. What I do think is that there is something in the middle of these two big questions, and they are: * How will the Perl 6 compiler be designed (parts, etc) * What are the definitions of some of the standard features mentioned in the Synopses ( S29 is a good start, but we need more than the standard perlfunc) If we let Perl 6 continue to grow organically we will have answers to these questions, but we will likely invest lots of effort in trial and error. I think that some of these questions can be answered based on some up front design, thinking, and decision making, thus helping us direct our trial and error efforts towards a more defined goal. Furthermore, I think this has important implications on the quality of the implementation of the Perl 6 compiler and standard library, and that we should start worrying about that too. The second (much larger) part of the post contains a sort of draft, if you will, of what I think can be a good start towards trying to answer these questions. Thanks -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /methinks long and hard, and runs away: neeyah!!! pgpEyRQC2JVbl.pgp Description: PGP signature
Re: A proposition for streamlining Perl 6 development
Yuval Kogman wrote: > What I do think is that there is something in the middle of these > two big questions, and they are: > > * How will the Perl 6 compiler be designed (parts, etc) That... was what Pugs Apocrypha was meant to contain, with PA02 being a design overview, and PA03 onward documenting the various parts with their interfaces. But English is not my forte (by far), and the last time you and I worked toward it, it resulted in a jargon-filled document largely inaccessible to a casual participant. So that needs to be fixed. I'll be in Tel Aviv in 5 days (thank $deity), and I'd be very willing to work with you on this before the Hackathon starts. Audrey signature.asc Description: OpenPGP digital signature
Heureka - from the -Ofun department
Parrot runs the ackermann benchmark faster than C.
leo
Heureka - from the -Ofun department
Or - running the ackermann function (and possibly other recursive
functions) really fast.
$ time ./parrot -Oc -C ack.pir 11
Ack(3, 11) = 16381
real0m0.567s
user0m0.559s
sys 0m0.008s
$ time ./ack 11
Ack(3,11): 16381
real0m0.980s
user0m0.978s
sys 0m0.002s
Parrot is svn head (not optimized BTW), the C version is compiled -O3
with 3.3.5. Below is the C [1] and the PIR source [2]. The ack
function is renamed to __pic_test - currently all the checks that
would enable this optimization are missing, e.g. if only I and N
registers are used and not too many, if there is no introspection and
so on.
The created JIT code for the ack function is also shown [3]. This is
actually only the recursive part of it, there is a small stub that
moves the arguments into registers and fetches the return result.
./parrot -Oc -C turns on tail-recursion optimization (recursive tail
calls are converted to loops). -C is the CGP or direct-threaded
runcore, which is able to recompile statically known stuff into faster
versions by e.g. caching lookups and such.
Have fun,
leo
[1]
/* -*- mode: c -*-
* $Id: ackermann-gcc-3.code,v 1.8 2005/12/02 08:05:56 bfulgham Exp $
* http://www.bagley.org/~doug/shootout/
*
* modified by Isaac Gouy
*/
#include
#include
#include
int Ack(int M, int N) { return(M ? (Ack(M-1,N ? Ack(M,(N-1)) : 1)) : N+1); }
int main(int argc, char *argv[]) {
int n = ((argc == 2) ? atoi(argv[1]) : 1);
printf("Ack(3,%d): %d\n", n, Ack(3, n));
return(0);
}
[2]
#!./parrot -C
#
# ackermann - ack(3, 9) is default
# shootout runs ack(3, 11)
# by Leopold Toetsch
.sub main :main
.param pmc argv
.local int argc
argc = elements argv
.local int x, y, r
x = 3
y = 9
if argc == 1 goto go
$S0 = argv[1]
if argc == 2 goto xdefault
x = $S0
$S0 = argv[2]
y = $S0
goto go
xdefault:
y = $S0
go:
$P0 = getinterp
$P0.'recursion_limit'(10)
r = __pic_test(x, y)
.local pmc args
args = new .ResizableIntegerArray
push args, x
push args, y
push args, r
$S0 = sprintf "Ack(%d, %d) = %d\n", args
print $S0
.end
.sub __pic_test
.param int x
.param int y
if x goto a1
inc y
.return (y)
a1:
if y goto a2
dec x
.return __pic_test(x, 1)
a2:
dec y
y = __pic_test(x, y)
dec x
.return __pic_test(x, y)
.end
[3]
0x84a80c7: test %edx,%edx
0x84a80c9: jne0x84a80d3
0x84a80cf: inc%ecx
0x84a80d0: mov%ecx,%eax
0x84a80d2: ret
0x84a80d3: test %ecx,%ecx
0x84a80d5: jne0x84a80e4
0x84a80db: dec%edx
0x84a80dc: mov$0x1,%ecx
0x84a80e1: jmp0x84a80c7
0x84a80e3: nop
0x84a80e4: dec%ecx
0x84a80e5: push %edx
0x84a80e6: call 0x84a80c7
0x84a80eb: pop%edx
0x84a80ec: mov%eax,%ecx
0x84a80ee: mov%esi,%esi
0x84a80f0: dec%edx
0x84a80f1: jmp0x84a80c7
0x84a80f3: ret
Re: Heureka - from the -Ofun department
I guess this is one place where being CISC really is better than being RISC. But how much improvement with outputting to a pbc first? But a couple notes, there's no --help-optimize like --help-debug, and as far as I know, there's no way to disable optimizations completely, e.g. this pir .sub main :main $N0 = pow 2.0, 5.0 .end Is always converted to this. main: set N0, 32 end Which can lead to misleading test results for when pow's actually broken. On Feb 8, 2006, at 7:07 AM, Leopold Toetsch wrote: Parrot runs the ackermann benchmark faster than C. leo Heureka - from the -Ofun department Or - running the ackermann function (and possibly other recursive functions) really fast. $ time ./parrot -Oc -C ack.pir 11 Ack(3, 11) = 16381 real0m0.567s user0m0.559s sys 0m0.008s $ time ./ack 11 Ack(3,11): 16381 real0m0.980s user0m0.978s sys 0m0.002s Parrot is svn head (not optimized BTW), the C version is compiled -O3 with 3.3.5. Below is the C [1] and the PIR source [2]. The ack function is renamed to __pic_test - currently all the checks that would enable this optimization are missing, e.g. if only I and N registers are used and not too many, if there is no introspection and so on. The created JIT code for the ack function is also shown [3]. This is actually only the recursive part of it, there is a small stub that moves the arguments into registers and fetches the return result. ./parrot -Oc -C turns on tail-recursion optimization (recursive tail calls are converted to loops). -C is the CGP or direct-threaded runcore, which is able to recompile statically known stuff into faster versions by e.g. caching lookups and such. Have fun, leo
Re: Heureka - from the -Ofun department
"Joshua Isom" <[EMAIL PROTECTED]> wrote: I guess this is one place where being CISC really is better than being RISC. But how much improvement with outputting to a pbc first? But a couple notes, there's no --help-optimize like --help-debug, and as far as I know, there's no way to disable optimizations completely, e.g. this pir .sub main :main $N0 = pow 2.0, 5.0 .end Is always converted to this. main: set N0, 32 end I think that doesn't class as an optimization as such, but rather a way to avoid having to have opcodes that take two constant arguments. Over a number of instructions, that's a worthwhile saving. Ops cost space in the Parrot executable, which means we fit less of Parrot in the CPU caches, which is bad. Which can lead to misleading test results for when pow's actually broken. Hopefully we have tests with just one constant argument to detect breakage of this kind? It does bring out an interesting issue in so far as if we don't promise the same behaviour for pow then you could end up with a hybrid of the behaviour on the system the PBC was generated on and the system you run it on, but I think we're aiming for consistent behaviour. Jonathan
[perl #38459] global.t failures in tcl
This failure is actually a bus error. You can generate it with:'
../../parrot tcl.pbc -e 'proc a {} {global q;puts $q};a'
Here's the gdb backtrace:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x01b4
0x0106fc60 in Parrot_dec_p (cur_opcode=0x281b79c, interpreter=0x2400210) at
src/ops/
math.ops:353
353 $1->vtable->decrement(interpreter, $1);
(gdb) bt
#0 0x0106fc60 in Parrot_dec_p (cur_opcode=0x281b79c, interpreter=0x2400210) at
src/
ops/math.ops:353
#1 0x0101a83c in runops_slow_core (interpreter=0x2400210, pc=0x281b79c) at src/
runops_cores.c:157
#2 0x0100be78 in runops_int (interpreter=0x2400210, offset=4983) at
src/interpreter.c:
763
#3 0x0100f358 in runops (interpreter=0x2400210, offs=8012288) at
src/inter_run.c:81
#4 0x0100f558 in runops_args (interpreter=0x2400210, sub=0x2410e50,
obj=0x281c1d0,
meth=0x1, sig=0x1185034 "vP", ap=0xb6a4 "") at src/inter_run.c:180
#5 0x0100f678 in Parrot_runops_fromc_args (interpreter=0x2400210,
sub=0x7a4200,
sig=0x1185034 "vP") at src/inter_run.c:274
#6 0x3f5c in main (argc=4, argv=0x0) at compilers/imcc/main.c:655
last few lines of the -t1 parrot trace:
18187 throw P1 - P1=Exception=PMC(0x425ff8)
213 set I0, P1[9]- I0=2, P1=Exception=PMC(0x425ff8),
217 ne I0, 2, 14 - I0=1, ,
231 dec P0 - P0=Bus error
Regards.
[perl #38467] Parrot::Test cross platform nit
# New Ticket Created by Will Coleda # Please include the string: [perl #38467] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38467 > Right now the Parrot::Test module is explicitly doing a check for a / dev/null and changing it on windows: instead, we should be using File::Spec->devnull
[perl #38468] [TODO] modify copyright info in parrot repo
# New Ticket Created by jerry gay # Please include the string: [perl #38468] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38468 > copyright info in the parrot repository has not been maintained. this should be remedied. through discussions with TPF and Chip, the following strategy has been approved: ~ the official copyright text will reside in the README file in the parrot root dir. [DONE] ~ the official text will be associated to each file in the parrot repository via a new svn keyword, 'Copyright' ~ copyright text in each text file will be replaced with the new keyword for expansion ~ committers will be instructed on setting their environments to understand this custom keyword ~ tests will be designed to detect differences between the official copyright text (README) and text files in the repository, with an exception list for files that do not contain the copyright message ~ these tests will be run before every release ~ a script will be made available to add or otherwise maintain the copyright info in all files this will be implemented over the coming days and weeks. ~jerry
Re: Heureka - from the -Ofun department
Joshua Isom wrote: I guess this is one place where being CISC really is better than being RISC. It really depends on the hardare you are running. E.g. add I0, I1, 20 translates either to something like: lea %ecx, 20(%edx) # not yet but in case .. or ori r11, r31, 20# r31 is 0 add r3, r4, r11# a 2nd oris is needed for constants > 0x If x86 were not the leading instruction set, I'd toss the opcode variants with constants almost all. ... But how much improvement with outputting to a pbc first? If you are gonna running the code multiple times, you save a few cycles compilation time. JIT code is still created at runtime. ... But a couple notes, there's no --help-optimize like --help-debug, and as far as I know, perldoc docs/runnning.pod - but these optimizations aren't settled nor finished. You can ignore them for now. there's no way to disable optimizations completely, e.g. this pir .sub main :main $N0 = pow 2.0, 5.0 .end Is always converted to this. main: set N0, 32 end This isn't an optimization. The 'pow' opcode is just run at compiletime. Which can lead to misleading test results for when pow's actually broken. If 'pow' is broken then it's borken. The only case where that would matter is, when you are compiling a PBC on a machine with a broken 'pow' and ship that PBC. leo
Re: Please revert and explain ":non_volatile"
"Jonathan Worthington" <[EMAIL PROTECTED]> wrote: Better names and/or solutions welcome. Chip has blessed this feature with a name - ":unique_reg" - and I've just checked in the same stuff as before, but with the accepted name in place of :non_volatile. Jonathan
Re: Heureka - from the -Ofun department
Leopold Toetsch wrote: ori r11, r31, 20# r31 is 0 add r3, r4, r11# a 2nd oris is needed for constants > 0x Well that's actually a bad example as there exists addi and addis instructions. But have a look at src/jit/arm/jit_emit.h emit_load_constant() and follow the functions it's calling. leo
Testing module name/interface advice
Hi,
I recently fell in love with Test::Base and I decided to use
it at $work. Since the 'run filter, compare output' mode
of T::B did not fit my needs, I wrote a small wrapper
(Test::XXX for now...) that
enables to check/establish preconditions, run one or
more actions and check postconditions, for each block, depending
on the sections that are present. I think this might be useful
to others and I wanted to release it to CPAN, but I am stuck
with finding it a proper name for it, and I also wonder if I chose
the right interface.
The module iterates over the Test::Base blocks. The processing
of each block is divided in three phases (begin, run, end). In each
phase one or more subroutines is run for every section of the block.
The (phase, section) -> subroutine association is declared in the
testing module.
Since the description above is a bit vague, I am pasting
below an example test module based upon Test::XXX and a couple
of example tests for a 'Dummy' module providing touch, mkdir, rmdir
and ls functions. In the example the touch and mkpath sections
execute actions, directory declared the directory whose contents
I want to test and the created section (associated to sub
post_created()) is the "real" test i.e. it tests the results
of the executed actions.
Thanks in advance for any suggestions!
Regards
Mattia
# t/lib/DummyT.pm
package DummyT;
use Test::XXX::Plugin -base;
use Test::Differences;
use Dummy;
use File::Path;
__PACKAGE__->register( 'Test::XXX' );
sub run_mkpath : Run(mkpath) {
my( $block, $section, @v ) = @_;
Dummy::mkpath( @v );
}
sub run_touch : Run(touch) {
my( $block, $section, @v ) = @_;
Dummy::touch( @v );
}
my @orig;
my $directory;
sub pre_directory : Begin(directory) {
my( $block, $section, @v ) = @_;
$directory = $v[0];
}
sub pre_created : Begin(created) {
my( $block, $section, @v ) = @_;
@orig = Dummy::ls( $directory . '/*' );
}
sub _lsd {
my( $block, $section, @v ) = @_;
my %final = map { ( $_ => 1 ) } Dummy::ls( $directory . '/*' );
delete $final{$_} foreach @orig;
my @final = map { s{^$directory/}//; $_ } keys %final;
}
sub post_created : End(created) {
my( $block, $section, @v ) = @_;
my @final = _lsd( @_ );
eq_or_diff( [EMAIL PROTECTED], [EMAIL PROTECTED], test_name );
}
1;
# t/foo.t
use DummyT;
use Test::XXX tests => 1;
Test::XXX->run;
__DATA__
=== Run some actions (1)
--- touch lines chomp
t/dummy/file1
=== Run more actions (2)
--- directory chomp
t/dummy
--- touch lines chomp
t/dummy/file2
--- mkpath lines chomp
t/dummy/dir
--- created lines chomp
file2
dir/
Re: overloading the variable declaration process
Stevan~ On 2/7/06, Stevan Little <[EMAIL PROTECTED]> wrote: > > > After all Foo is just a specific instance of the class Class. > > Shhh... class objects don't exist ... I was never here,... I will I > count to three and when I snap my fingers you will awaken and will > have forgotten all about class Class. > > 1 ... 2 ... 3 ... *snap* ... What!?!? Where was I? Oh, yeah. As I was saying, I think we just take C++'s object system exactly. Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: The definition of 'say'
On Tue, Feb 07, 2006 at 06:38:14PM +, Robin Houston wrote:
: Late last year I implemented a few Perl 6 features in Perl 5.
: A couple of things have emerged that may be relevant to the
: Perl 6 design. Certainly they're things that I'm curious about.
: I'll send the other one in a separate message to keep the
: threads apart: this message is about 'say'.
:
: The definition of 'say' is very simple:
:
: say
:
: is exactly equivalent to
:
: print , "\n"
:
: and that's just the way it works in Perl 5.9.3. In fact,
: that's how it's compiled. A few people on p5p have expressed
: some disquiet that
:
: say "foo";
:
: will print the string "foo$,\n$\". I'm inclined to agree that
: this seems sensible only when $, and $\ are both empty, as
: they are by default.
:
: I'm not sure what the Perl 6 analogues are of $, and $\. I've
: heard that $\ is a per-filehandle setting. Is there any analogue
: of $,? Presumably there is.
Yes, native Perl 6 will attach such things to the filehandle objects,
though the p5-to-p6 translator will have to emulate them somehow...
: In short, I'm curious as to why say is defined as it is, rather
: than, for example, to be the equivalent of the Perl 5 code
:
: { local $\ = "\n"; print }
:
: I've searched the archives of this list, but failed to turn
: up anything relevant.
You're searching the wrong archives. :-) Here's something from the
@Larry's archives--Damian first brought this up almost two years ago,
and I don't think he'll mind me forwarding the last message in that
thread:
> From [EMAIL PROTECTED] Sun Jan 23 14:31:50 2005
> Message-ID: <[EMAIL PROTECTED]>
> Date: Mon, 24 Jan 2005 09:31:36 +1100
> From: Damian Conway <[EMAIL PROTECTED]>
> To: Perl 6 Design Team <[EMAIL PROTECTED]>
> Subject: Revisiting an old decision (after extensive play-testing)
> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL
> PROTECTED]> <[EMAIL PROTECTED]>
> In-Reply-To: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
> Content-Length: 2404
> Lines: 56
>
> Some time back, we were discussing the C function, and its interaction
> with a filehandle's ORS:
>
> > On Fri, Mar 26, 2004 at 01:01:28PM +1100, Damian Conway wrote:
> > : So, how (if at all) does C interact with the filehandle's output
> > : record separator? Does it:
> > :
> > : a. Temporarily set the filehandle's ORS to newline and call C?
> > : (i.e. just append: "\n")
> > :
> > : b. Temporarily set the filehandle's ORS to newline unless that ORS is
> > : already defined as something else and call C?
> > : (i.e. append: $fh.outsep // "\n")
> > :
> > : c. Append a newline and call C, which then appends the
> > :filehandle's ORS?
> > : (i.e. append: "\n" ~ $fh.outsep)
> > :
> > :
> > : d. Append the filehandle's ORS, then a newline, and output directly?
> > : (i.e. append: $fh.outsep ~ $fh)
> > :
> > :
> > : Personally, I think a. or b. would probably be the least surprising.
> >
> > I think b. seems likeliest to do what they want. Of course, it doesn't
> > actually have to be implemented in terms of print.
>
> I've now been using C (via Perl6::Say) for some time -- testing our
> collective intuition on this -- and it turns out that b. isn't the least
> surprising. At least, not to me. In fact, I am regularly (and annoyingly)
> re-surprised every time $\ overrides what I was sure was going to be newline.
>
> I've realised that this is because I constantly abstract C in terms of
> C. Specifically, as "print plus a newline".
>
> But the b. semantics constantly thwart that unconscious abstraction, giving
> me
> instead "print plus *sometimes* a newline, but sometimes not".
> That's because, if $\ is set, C devolves to exactly C (which also
> seems somehow "wasteful").
>
> I have the definite sense that C is going to be one of the most-used
> features of Perl 6 (it's certainly the one I use most so far), so I'd
> strongly
> suggest that we revisit its semantics to make them less surprising.
>
> In particular, I think the simplest, most useful, and most predictable
> semantics are actually those suggested in alternative c. above. That is, I
> think the following equivalence should hold exactly:
>
> say @args <> print @args, "\n"
>
> That's definitely how I find myself thinking about C when I'm not
> actually...err...thinking about C, so I think that's what might fit
> hacker brains most naturally.
>
> Damian
The question basically boils down to how you think about "say".
Damian's argument is that, if people are like him, they will learn
it as "print plus newline" rather than as "emit a whole record".
I'm inclined to think that people do in fact learn one feature in
terms of other features like that, rather than treating "say" as a
different primitive.
It would be nice to h
Re: overloading the variable declaration process
On Tue, Feb 07, 2006 at 07:32:18PM -0500, Stevan Little wrote:
: On 2/7/06, Matt Fowles <[EMAIL PROTECTED]> wrote:
: > Stevan~
: >
: > I am going to assume that you intended to reply to perl 6 language,
: > and thus will include your post in its entirety in my response.
:
: Yes, sorry... I missed the "reply to all" button on the gmail UI by a
: few pixels I guess. Thank you for forwarding.
:
: > Now that everyone is on the same page, I will go about responding
: >
:
: # snip some code
:
: > >
: > > class Pipe::Stem {
: > >has $composed_of;
: > >has $color;
: > >has $length;
: > >has $filter = bool::false;
: > > }
: >
: > so far I am mostly with you, except one question. Does bool::false;> just provide a default?
:
: Yes, that is a default value. I assume that most Pipe smokers don't
: like filters in their pipes, I might be wrong on that one because I am
: not a pipe smoker :)
:
: > > You would then model the different pipes you sell;
: > >
: > > class MagrittePipe {
: > > has $stem = Pipe::Stem.new(
: > > :composed_of,
: > > :color,
: > > :length
: > > );
: > > has $bowl = Pipe::Bowl.new(
: > > :composed_of,
: > > :color,
: > > :size
: > > );
: > > }
: > >
: > > Now, you might say, why not make the MagrittePipe an instance of Pipe,
: > > and give the Pipe class a few more attributes, like a name. Well, if
: > > you did that then you couldn't subclass it of course.
: >
: > Actually, I was going to ask why not make MagrittePipe inherit from Pipe.
:
: Ooops, forgot that part it should infact inherit from Pipe. And of
: course you can do that dynamically with the metamodel ;)
:
: > > Well, using introspection, it becomes very simple to discover various
: > > qualities about your inventory, enough to probably even autogenerate
: > > the HTML pages for your online-web store (powered by Perl 6 of
: > > course). And lets not forget the uber-cool Perl 6 Object Database
: > > which you are using to store your real-time inventory in (all
: > > metamodel powered of course). And of course if you want, you can use
: > > the DistributedObjectProxy metaclass which will automatically make
: > > your objects distributed so that your door-to-door Pipe saleforce can
: > > update your inventory in real time from their cellphones. And your R&D
: > > department can use the built-in (but as yet unspeced) logic
: > > programming features of Perl 6 to mine your customer information from
: > > your (previously mentioend) object database and genetically "grow"
: > > new, more desireable Pipe products (which is easy to do since your
: > > metaclasses are programatically composable (and no I don't mean eval
: > > $code)).
: >
: > I think you mis-understand me. I do not question the value of a
: > powerful meta-model. Quite the contrary I want to see Perl 6 have a
: > meta-model more powerful and accessible then CLOS. I see it as a
: > necessity for a language that plans to truely scale in the future.
: >
: > What I do question is the usefullness of having bare class names
: > represent these "prototype objects". I just don't really understand
: > what they are for or do.
:
: Well, to be totally honest, I think only Larry truely understands
: their usage, but to the best of my understanding they are intented to
: serve a number of roles;
:
: (Larry, please correct me if I am wrong here)
:
: - to allow for introspection of the class.
:
: After all ^Foo.can() is really just a series of method calls to the
: Foo metaobject. And besides ^Foo.meta.can() is 5 more characters to
: type!!
:
: - provide an invocant for "class" methods.
:
: Larry does not like the class-method/instance-method distinction (in
: fact it seems he doesn't even like the class/instance distinction
: either), and has declared that a "class method" is really just a
: method of the class which does not access any instance attributes.
: Well, this complicates the type signature of the invocant, and we need
: an invocant that the type-checker can check.
:
: In Perl 5, classes were just package names which were just strings.
: This will not work in Perl 6 in the presence of a reasonably decent
: type checker, the class needs to be *something*. Now Larry has also
: declared that he does not like the idea of a "class object", I think
: this is because that means that a properly typed method signature for
: a class method would look like this:
:
: class Foo {
: method foo (Class $class:) {
: say "I am a class method, and proud of it";
: }
: }
:
: According to the signature, this method takes any Class instance as an
: invocant. Well
: thats just not right because it should only accept the Class instance
: which represents the Foo class. But we can't (at least I dont think we
: can) be that
Re: The definition of 'say'
IMHO, people who set $/ are, by definition, saying that they expect lines to terminate with something other than a newline; they should expect 'say' to conform to their wishes. I don't like the notion of perl second-guessing the programmer's intentions here; "Do what I mean, not what I say" only carries so far. That said, I very rarely set $/, so this aspect of 'say' doesn't really affect me. -- Jonathan Lang
Re: The definition of 'say'
On Wed, Feb 08, 2006 at 08:38:32AM -0800, Larry Wall wrote: > The question basically boils down to how you think about "say". > Damian's argument is that, if people are like him, they will learn > it as "print plus newline" rather than as "emit a whole record". > I'm inclined to think that people do in fact learn one feature in > terms of other features like that, rather than treating "say" as a > different primitive. > > It would be nice to have other data points, though, since I think > even Damian will admit that Damian's brain doesn't work like everyone > else's brain. Just as another data point, I too have been thinking of "say" as "print + newline". -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
sub introspection: filename and line
while debugging partcl, leo asked will for some source comments to understand where the generated code came from. i thought it should be possible to walk the chain from the code emitter, and print the calling sub's filename and line number in PIR. walking the call chain is possible using a ParrotInterpreter PMC, however, the Sub PMC isn't able to get file and line info. in order to do this, the Sub PMC needs two new methods, which i propose we call 'get_file' and 'get_line'. does this seem appropriate? are these method names acceptable? if so, i'm pretty sure it can be implemented shortly, and should allow hll compilers to emit better debugging information. ~jerry
Re: sub introspection: filename and line
"jerry gay" <[EMAIL PROTECTED]> wrote: while debugging partcl, leo asked will for some source comments to understand where the generated code came from. i thought it should be possible to walk the chain from the code emitter, and print the calling sub's filename and line number in PIR. walking the call chain is possible using a ParrotInterpreter PMC, however, the Sub PMC isn't able to get file and line info. in order to do this, the Sub PMC needs two new methods, which i propose we call 'get_file' and 'get_line'. does this seem appropriate? are these method names acceptable? Oops. In contrast to what I had said on IRC, this isn't the way to do it, as a sub PMC only exists per sub. What exists per *call* of a sub is a context. You can walk down the context chain using the ParrotInterpreter PMC, but that hands back a struct. We can't have a context PMC yet 'cus we need those weak reference thingies that I needed for .NET register pointers. They don't exist yet - they're half way there though. ;-) So get_file and get_line want to be methods on some context PMC that we don't yet have, if that's all acceptable. Jerry - sorry for being so brain dead. Jonathan
Re: The definition of 'say'
One more data point?
I might want a newline or I might want an ORS. The former, say()
gives me. The latter, print() provides.
I cannot imagine ever wanting a mixture of those, and if I ever do,
I expect I'll prefer to say what I mean:
# modulo syntax:
{ temp ORS //= "\n"; print @args } # b
print @args, "\n"; # c
{ temp ORS ~= "\n"; print @args } # d
In the common case, I think I'll have one or the other, and no
surprises, if you please. Option a.
Eirik
--
Habit is a cable; we weave a thread of it each day,
and at last we cannot break it.
--Horace Mann
Test::Builder feature request...
hi all :) there's a feature split I'm itching for in Test::Builder, etc - the ability to call is() and have it emit TAP free from the confines of plan(). not that I don't want to call plan() (or no_plan) but I want to do that in a completely separate perl interpreter. for example, I want to do something that looks a bit like this use Test::More tests => 1; print qx!perl t/response.pl!; where response.pl makes a series of calls to is(), ok(), whatever. while this may seem odd it's actually not - I'd like to be able to plan() tests within a client *.t script but have the responses come from one (or more) requests to any kind of server (httpd, smtp, whatever). currently in httpd land we can do this by calling plan() and is() from within a single server-side perl script, but the limitation there is that you can only do that once - if I want to test, say, keepalives I can't have a single test script make multiple requests each with their own plan() calls without things getting tripped up. so, I guess my question is whether the plan->is linkage can be broken in Test::Builder/Test::Harness/wherever and still keep the bookkeeping in tact so that the library behaves the same way for the bulk case. or maybe at least provide some option where calls to is() don't bork out because there's no plan (and providing an option to Test::More where it doesn't send a plan header). so, thoughts or ideas? am I making any sense? --Geoff
Q: namespaces and classes
I'm still having troubles, when thinking about namespace PMCs and implementation thereof. Especially the relationship of class namespaces and the store_global opcode. We have e.g. this PIR snippets: .sub main :main cl = newclass 'Foo' # a class isa/hasa namespace ?! ... .end .namespace ['Foo'] # namespace 'Foo' .sub __init :method # a method &Foo::__init ... .end Currently '__init' is stored with: store_global "Foo', '__init', $PSub (Actually, if the class already exists, the C vtable is used, but that just does C too) But usually, this happens at compile-time, or PBC-load-time, when the class 'Foo' doesn't yet exist. Therefore C can't be stored into the proposed class->vtable->namespace, as there is no such class (yet). To actually implement this (and assuming that my thoughts so far are correct) I was thinking about this strategy: The usage of the C<.namespace> directive causes the creation of a new namespace PMC with that name. Additionally the namespace PMC is registered as a type. This needs a bit of additional code that prevents instantiation of namespaces. When now at runtime C is executed, we find the existing namespace PMC (with all the statically visible methods inside) and just promote the namespace PMC into a class PMC. Is this sane? Comments welcome, leo
Re: Test::Builder feature request...
On Feb 8, 2006, at 11:41, Geoffrey Young wrote: so, I guess my question is whether the plan->is linkage can be broken in Test::Builder/Test::Harness/wherever and still keep the bookkeeping in tact so that the library behaves the same way for the bulk case. or maybe at least provide some option where calls to is() don't bork out because there's no plan (and providing an option to Test::More where it doesn't send a plan header). so, thoughts or ideas? am I making any sense? Yes, you are. I think that the subprocess can load Test::More and friends like this: use Test::More no_plan => 1; Test::More->builder->no_header(1); That will set No_Plan, Have_Plan, and No_Header to true, silencing the "Gotta have a plan!" error and the "1.." message at the end. HTH, David
Re: The definition of 'say'
On 2/8/06, Larry Wall wrote: > From: Damian Conway <[EMAIL PROTECTED]> > I've now been using C (via Perl6::Say) for some time -- testing our collective intuition on this -- and it turns out that b. isn't the least surprising. At least, not to me. In fact, I am regularly (and annoyingly) > re-surprised every time $\ overrides what I was sure was going to be newline. The question basically boils down to how you think about "say". I guess I think of "say" as "print + \n" too... because that's how everyone explains it. If we told everyone it meant "print + ORS", I think it would be less surprising. Of course, I hardly ever set a record separator, and I'm not sure what Damian was doing that led him to want to set one and to use 'say' at the same time. What's the difference between an ORS and a newline anyway? The purpose of a newline is typically to provide a visual separation... hm. Maybe we should take a step back: 'say' and ORS's are both a kind of shortcut to save you from typing everything out explicitly in every print statement. What if 'print' never added anything to its output, and 'say' always added the field and record separators? The default ORS should then be \n. Instead of turning the separators on and off (as in P5), you would switch between using 'print' and 'say'. (You might also make an argument that the default OFS should be a space or a tab, but I think OFS="" and ORS="\n" are probably what most people want most of the time. That certainly fits my typical uses of 'print' and 'say'.) -David "say what?" Green
Re: The definition of 'say'
Larry Wall skribis 2006-02-08 8:38 (-0800):
> It would be nice to have other data points
I associate "say" with to-human communication, and there, I don't
generally have records. Without records, no ORS.
However, while I think that &say should not be
&print.assuming(:ors("\n")), it shouldn't be print + \n either.
Instead, I think the format should be configurable, defaulting to
suffixing \n, but configurable to have another suffix, and possibly a
prefix even. For example, I may very well like a "* %s\n"-like output,
or when dealing with HTML, "%s".
Of course, I could just override &say. But I think making it
configurable and documenting the difference between say and print as a
difference in final recipient (human versus computer) may make more
sense.
In any case, &say being print + \n as the default is IMO a better plan
than having it default to any ORS, even if that ORS happens to be \n.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: A proposition for streamlining Perl 6 development
On Tuesday 07 February 2006 23:55, Yuval Kogman wrote: > Does this imply that we should think up this process? Go ahead. > If I propose a concrete plan for the implementation of Perl 6 in a > layered fashion it will probably be even more overlooked. > > I have no authority, and this is not something I can do on my own. If other people find it valuable, that's all the authority you need. The last time someone tried to set forth a complete specification in a particular order was the Perl 6 documentation project. That didn't work then. I have doubts that specifying a complete compiler and toolchain without at least some trial and error will work, but I could be wrong. Maybe the right place to start is to gather a list of all of the questions you need to have answered and all of the features people want, and then try to unify them into a Perl 6-ish whole. -- c
Re: Test::Builder feature request...
>> so, thoughts or ideas? am I making any sense? > > > Yes, you are. *whew* :) > I think that the subprocess can load Test::More and > friends like this: > > use Test::More no_plan => 1; > Test::More->builder->no_header(1); cool, thanks. > > That will set No_Plan, Have_Plan, and No_Header to true, silencing the > "Gotta have a plan!" error and the "1.." message at the end. with your suggestion I'm almost there: 1..1 ok 1 - this was a passing test # No tests run! http://people.apache.org/~geoff/test-more-separately.tar.gz if you want to try... --Geoff
[perl #38469] [BUG] -O1 branch optimization
# New Ticket Created by Leopold Toetsch # Please include the string: [perl #38469] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38469 > Something's wrong with it: $ ./parrot -Oc ack.pir 3 Ack(3, 3) = 61 $ /parrot -Oc1 ack.pir 3 maximum recursion depth exceeded -Oc turns on recursive tailcall optimization, see $ ./parrot -Oc -o- ack.pir for generated code. leo
Re: Heureka - from the -Ofun department
But with jit enabled on x86/freebsd/openbsd, I was having problems with some of the pow functions. The rt number is #38382. Because of the compile time optimization, it made it trickier to work with because the compile time was ok, but the jit runtime wasn't, and it took me a little while to realize the compile time optimization. I'm not saying no optimizations should be the default, but an option to disable compile time optimizations would help with the testing the interpreter instead of the compiler. On Feb 8, 2006, at 9:23 AM, Leopold Toetsch wrote: there's no way to disable optimizations completely, e.g. this pir .sub main :main $N0 = pow 2.0, 5.0 .end Is always converted to this. main: set N0, 32 end This isn't an optimization. The 'pow' opcode is just run at compiletime. Which can lead to misleading test results for when pow's actually broken. If 'pow' is broken then it's borken. The only case where that would matter is, when you are compiling a PBC on a machine with a broken 'pow' and ship that PBC. leo
Re: Heureka - from the -Ofun department
On Feb 8, 2006, at 22:28, Joshua Isom wrote: but an option to disable compile time optimizations would help with the testing the interpreter instead of the compiler It's not an optimization and it can't be turned off, as there are no such opcodes like 'pow_i_ic_ic'. And again - the evaluation of that constant is using the parrot *runtime* (compilation is runtime, just earlier ;) . And if a JITted program behaves differently that's still another case. See also compilers/imcc/optimizer.c:eval_ins and especially line 655. leo
Re: Test::Builder feature request...
Geoffrey Young wrote: hi all :) there's a feature split I'm itching for in Test::Builder, etc - the ability to call is() and have it emit TAP free from the confines of plan(). not that I don't want to call plan() (or no_plan) but I want to do that in a completely separate perl interpreter. for example, I want to do something that looks a bit like this use Test::More tests => 1; print qx!perl t/response.pl!; where response.pl makes a series of calls to is(), ok(), whatever. while this may seem odd it's actually not - I'd like to be able to plan() tests within a client *.t script but have the responses come from one (or more) requests to any kind of server (httpd, smtp, whatever). currently in httpd land we can do this by calling plan() and is() from within a single server-side perl script, but the limitation there is that you can only do that once - if I want to test, say, keepalives I can't have a single test script make multiple requests each with their own plan() calls without things getting tripped up. so, I guess my question is whether the plan->is linkage can be broken in Test::Builder/Test::Harness/wherever and still keep the bookkeeping in tact so that the library behaves the same way for the bulk case. or maybe at least provide some option where calls to is() don't bork out because there's no plan (and providing an option to Test::More where it doesn't send a plan header). so, thoughts or ideas? am I making any sense? --Geoff One of the problems is going to be numbering, surely? I've just started myself mucking around with some ideas where I wanted to fork off a server process and then test in BOTH halves of a connection at the same time. It sounds like something relatively similar to what you need to do. One of the things I didn't really like about generating fragments is you don't really get a chance to count each set, only the total (or worse, no plans at all). What I think might be a useful approach is being able to "merge" fragments to test output. So the lines from the external fragment would be parsed in, checked (in plan terms) and then re-emitted into the main test (which would have a plan totallying the whole group). Adam K
Re: Smart match table
On 2/7/06, Robin Houston <[EMAIL PROTECTED]> wrote:
> Any undef undefinedmatch if !defined $a
> Any Regex pattern matchmatch if $a =~ /$b/
> Code() Code()results are equalmatch if $a->() eq $b->()
> Any Code()simple closure truth match if $b->() (ignoring $a)
> Num numish[!] numeric equality match if $a == $b
> Any Str string equality match if $a eq $b
> Any Num numeric equality match if $a == $b
>
> which retains commutativity in all cases. Of course it's
> different in Perl 6, because the "dotted entries" like
> .[number] and .method need to behave non-commutatively.
> But is it really necessary for coderefs?
My interpretation (which may be totally off, as I don't have any
confirmation that anybody else is thinking the same way I am) is that
the synopsis is wrong, and commutivity of ~~ is a happy coincidence
wherever it exists. The way I've been thinking about ~~ is just as
the following object-oriented sugar:
role Pattern {
method match(Any $x) {...}
}
sub infix:<~~> (Any $x, Pattern $y) {
$y.match($x);
}
And then the interpretation of ~~ is determined by its right-hand side.
Luke
Re: Smart match table
Luke wrote:
> My interpretation (which may be totally off, as I don't have any
> confirmation that anybody else is thinking the same way I am) is that
> the synopsis is wrong, and commutivity of ~~ is a happy coincidence
> wherever it exists. The way I've been thinking about ~~ is just as
> the following object-oriented sugar:
>
> role Pattern {
> method match(Any $x) {...}
> }
> sub infix:<~~> (Any $x, Pattern $y) {
> $y.match($x);
> }
>
> And then the interpretation of ~~ is determined by its right-hand side.
Heavens, I hope not!
The whole point of ~~ is that it's dispatched multimorphically, *not*
polymorphically. So you get the most appropriate matching behaviour
for the *combination* of arguments.
And I've always imagined that it's commutative for the same reason ==
and eq are communative: because that's the only thing that makes
sense. When you're comparing two apples (or an apple and a
handgrenade), it shouldn't matter which of the two is in your left
hand, and which is in your right.
Damian
Re: Test::Builder feature request...
Adam Kennedy wrote:
Geoffrey Young wrote:
hi all :)
there's a feature split I'm itching for in Test::Builder, etc - the
ability to call is() and have it emit TAP free from the confines of
plan(). not that I don't want to call plan() (or no_plan) but I want to
do that in a completely separate perl interpreter. for example, I want
to do something that looks a bit like this
use Test::More tests => 1;
print qx!perl t/response.pl!;
where response.pl makes a series of calls to is(), ok(), whatever.
while this may seem odd it's actually not - I'd like to be able to
plan() tests within a client *.t script but have the responses come from
one (or more) requests to any kind of server (httpd, smtp, whatever).
currently in httpd land we can do this by calling plan() and is() from
within a single server-side perl script, but the limitation there is
that you can only do that once - if I want to test, say, keepalives I
can't have a single test script make multiple requests each with their
own plan() calls without things getting tripped up.
so, I guess my question is whether the plan->is linkage can be broken in
Test::Builder/Test::Harness/wherever and still keep the bookkeeping in
tact so that the library behaves the same way for the bulk case. or
maybe at least provide some option where calls to is() don't bork out
because there's no plan (and providing an option to Test::More where it
doesn't send a plan header).
so, thoughts or ideas? am I making any sense?
--Geoff
One of the problems is going to be numbering, surely?
This works:
---test.pl---
use Test::More tests => 1;
my $Test = Test::More->builder;
my $counter = $Test->current_test;
print qx!perl t/response.pl!;
$Test->current_test($counter + 1);
__END__
---response.pl---
use Test::More no_plan => 1;
Test::More->builder->no_header(1);
Test::More->builder->no_ending(1);
pass ('this was a passing test');
___END___
The problem was the test.pl file counter was never incremented so it
never saw the planned test.
Re: Test::Builder feature request...
On Feb 8, 2006, at 12:41, Geoffrey Young wrote: with your suggestion I'm almost there: 1..1 ok 1 - this was a passing test # No tests run! What parts do you want left out? Best, David
Re: Test::Builder feature request...
This works:
---test.pl---
use Test::More tests => 1;
my $Test = Test::More->builder;
my $counter = $Test->current_test;
print qx!perl t/response.pl!;
$Test->current_test($counter + 1);
But why 1? Why not 5? or 10?
__END__
---response.pl---
use Test::More no_plan => 1;
Test::More->builder->no_header(1);
Test::More->builder->no_ending(1);
pass ('this was a passing test');
___END___
The problem was the test.pl file counter was never incremented so it
never saw the planned test.
Re: Test::Builder feature request...
Adam Kennedy wrote:
This works:
---test.pl---
use Test::More tests => 1;
my $Test = Test::More->builder;
my $counter = $Test->current_test;
print qx!perl t/response.pl!;
$Test->current_test($counter + 1);
But why 1? Why not 5? or 10?
It has to be set to the number of tests run in the other process. I
don't know if there is a way to do something like no_plan for the sub
process... I don't think so... Every time pass(), ok(), etc is called it
updates the counter. In the sub process there is no way to pass back the
internal counter, so you have to update the counter manually.
__END__
---response.pl---
use Test::More no_plan => 1;
Test::More->builder->no_header(1);
Test::More->builder->no_ending(1);
BTW, not sure if the no_ending() is needed. It works with and without in
this case.
pass ('this was a passing test');
___END___
The problem was the test.pl file counter was never incremented so it
never saw the planned test.
Re: overloading the variable declaration process
Consider "my Dog $spot". From the Perl6-to-English Dictionary: Dog: a dog. $spot: the dog that is named Spot. ^Dog: the concept of a dog. Am I understanding things correctly? If so, here's what I'd expect: a dog can bark, or Spot can bark; but the concept of a dog cannot bark: can Dog "bark"; # answer: yes can $spot "bark"; # answer: yes can ^Dog "bark"; # answer: no -- Jonathan "Dataweaver" Lang
Re: Smart match table
-- Original message --
From: Luke Palmer <[EMAIL PROTECTED]>
> On 2/7/06, Robin Houston <[EMAIL PROTECTED]> wrote:
> > Any undef undefinedmatch if !defined $a
> > Any Regex pattern matchmatch if $a =~ /$b/
> > Code() Code()results are equalmatch if $a->() eq $b->()
> > Any Code()simple closure truth match if $b->() (ignoring $a)
> > Num numish[!] numeric equality match if $a == $b
> > Any Str string equality match if $a eq $b
> > Any Num numeric equality match if $a == $b
> >
> > which retains commutativity in all cases. Of course it's
> > different in Perl 6, because the "dotted entries" like
> > .[number] and .method need to behave non-commutatively.
> > But is it really necessary for coderefs?
>
> My interpretation (which may be totally off, as I don't have any
> confirmation that anybody else is thinking the same way I am) is that
> the synopsis is wrong, and commutivity of ~~ is a happy coincidence
> wherever it exists. The way I've been thinking about ~~ is just as
> the following object-oriented sugar:
>
> role Pattern {
> method match(Any $x) {...}
> }
> sub infix:<~~> (Any $x, Pattern $y) {
> $y.match($x);
> }
>
> And then the interpretation of ~~ is determined by its right-hand side.
>
> Luke
Also ermemebr that a very common user of ~~ is the implisit use in a when
conditional inside a given block, which is an inheirently assymeterical (thus
non-communitive) situation.
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: The definition of 'say'
At 21:30 +0100 2/8/06, Juerd wrote: >Larry Wall skribis 2006-02-08 8:38 (-0800): > > It would be nice to have other data points In the Macintosh world: 1) say is a reserved word in AppleScript that sends text to a speaker (with windings and a cone). 2) We are forever mucking with $/ and $\ set to different values. One for reading someone else's file and the other for writing something the Macintosh way. (It's better in OS neXt.) And everywhere: 3) There are two more 16 bit line ends in unicode that may or may not ever be really used. -- Applescript syntax is like English spelling: Roughly, but not thoroughly, thought through.
Re: overloading the variable declaration process
On 2/8/06, Jonathan Lang <[EMAIL PROTECTED]> wrote: > Consider "my Dog $spot". From the Perl6-to-English Dictionary: > Dog: a dog. > $spot: the dog that is named Spot. > ^Dog: the concept of a dog. > > Am I understanding things correctly? > > If so, here's what I'd expect: a dog can bark, or Spot can bark; but > the concept of a dog cannot bark: > can Dog "bark"; # answer: yes > can $spot "bark"; # answer: yes > can ^Dog "bark"; # answer: no Yes, that is correct, because: Dog.isa(Dog) # true $spot.isa(Dog) # true ^Dog.isa(Dog) # false In fact ^Dog isa MetaClass (or Class whatever you want to call it). At least that is how I see/understand it. Stevan
Re: Test::Builder feature request...
On 2/8/06, Adam Kennedy <[EMAIL PROTECTED]> wrote: > Geoffrey Young wrote: > > hi all :) > > > > there's a feature split I'm itching for in Test::Builder, etc - the > > ability to call is() and have it emit TAP free from the confines of > > plan(). not that I don't want to call plan() (or no_plan) but I want to > > do that in a completely separate perl interpreter. for example, I want > > to do something that looks a bit like this > > > > use Test::More tests => 1; > > > > print qx!perl t/response.pl!; > > > > where response.pl makes a series of calls to is(), ok(), whatever. > > while this may seem odd it's actually not - I'd like to be able to > > plan() tests within a client *.t script but have the responses come from > > one (or more) requests to any kind of server (httpd, smtp, whatever). > > > > currently in httpd land we can do this by calling plan() and is() from > > within a single server-side perl script, but the limitation there is > > that you can only do that once - if I want to test, say, keepalives I > > can't have a single test script make multiple requests each with their > > own plan() calls without things getting tripped up. > > > > so, I guess my question is whether the plan->is linkage can be broken in > > Test::Builder/Test::Harness/wherever and still keep the bookkeeping in > > tact so that the library behaves the same way for the bulk case. or > > maybe at least provide some option where calls to is() don't bork out > > because there's no plan (and providing an option to Test::More where it > > doesn't send a plan header). > > > > so, thoughts or ideas? am I making any sense? > > > > --Geoff > > One of the problems is going to be numbering, surely? > > I've just started myself mucking around with some ideas where I wanted > to fork off a server process and then test in BOTH halves of a > connection at the same time. It sounds like something relatively similar > to what you need to do. > > One of the things I didn't really like about generating fragments is you > don't really get a chance to count each set, only the total (or worse, > no plans at all). > > What I think might be a useful approach is being able to "merge" > fragments to test output. > > So the lines from the external fragment would be parsed in, checked (in > plan terms) and then re-emitted into the main test (which would have a > plan totallying the whole group). A long time ago, I suggested (and implemented) the idea of nested test numbers. The idea being that your output looks like 1 # ok 2.1 # ok 2.2 # ok 2.3 # ok 3.1.1.1 # ok ... you get the idea the only rule would be that a.b.c.d must come before a.b.c.d+1 in the output. Each block can have a plan if you like then you just create a block for each process/thread that will emit test results. I've a feeling that Test::Harness would barf on the above output but if you prefix all the numbers with . then it's happy. Of course it would be good to have a version of TH that also undertands these nested test number properly, the . thing just lets you keep backward compatibility. So this solves the present problem and it also solves the problem of it being a pain to have a plan when you have data driven testing (#tests = #data x #tests per datum and other adjustments and don't forget those data that get an extra test etc etc). You can also put a group of tests into a subroutine and just plan for 1 test for each time the sub is called. Anyway, I hereby suggest it again but this time without an implementation. The last time, the biggest part of the implementation was rewiring Test::Builder to use a blessed ref rather than lexical variables for it's object attributes but now TB is like that by default, the rest shouldn't be too hard :) F
Re: overloading the variable declaration process
Stevan Little wrote: > Yes, that is correct, because: > > Dog.isa(Dog) # true > $spot.isa(Dog) # true > ^Dog.isa(Dog) # false > > In fact ^Dog isa MetaClass (or Class whatever you want to call it). > > At least that is how I see/understand it. OK. To help me get a better idea about what's going on here, what sorts of attributes and methods would ^Dog have? -- Jonathan "Dataweaver" Lang
Re: Test::Builder feature request...
Adam Kennedy wrote:
Randy W. Sims wrote:
Adam Kennedy wrote:
This works:
---test.pl---
use Test::More tests => 1;
my $Test = Test::More->builder;
my $counter = $Test->current_test;
print qx!perl t/response.pl!;
$Test->current_test($counter + 1);
But why 1? Why not 5? or 10?
It has to be set to the number of tests run in the other process. I
don't know if there is a way to do something like no_plan for the sub
process... I don't think so... Every time pass(), ok(), etc is called
it updates the counter. In the sub process there is no way to pass
back the internal counter, so you have to update the counter manually.
Well, that would be why you allow the sub-process's plan code to run as
normal. When you get the fragment back, you can update it from the
header or the foot, but not print the actual header/footer.
You mean capture the output from the child process? Then allow the
parent to generate the test output from the captured & parsed output of
the child? That would mean for any lengthy child process there would be
a pause until the child completed; only then would the parent output the
results from the child. Otherwise, I guess you could Tee the output from
the child.
Is that what you mean by getting the fragment back?
It also means you get the numbers in order in the main tests too,
because of the reprocessing.
The counter gets out of order in the snippet I sent if any tests are
added before the child process. That can be fixed with the code below
(Alt: use an $ENV variable to pass $counter), but you still need to know
how many tests are running in the child ahead of time. I guess you could
write out the counter to a file in the child & read it back in the
parent, or any other normal means of IPC. All of this would presumably
be wrapped in a Test::* module to hide the ugly.
---plan.t---
use Test::More tests => 3;
pass('Parent: Begin');
my $Test = Test::More->builder;
my $counter = $Test->current_test;
print qx!perl t/response.pl $counter!;
$Test->current_test($counter + 1);
pass('Parent: End');
__END__
---response.t---
use Test::More no_plan => 1;
my $Test = Test::More->builder;
$Test->no_header(1);
my $counter = shift;
$Test->current_test($counter);
pass('Child');
__END__
[perl #38472] $test_suite ~~ s:g/ (\b) output_ [ like | isnt | is ] /pasm_/;
# New Ticket Created by jerry gay # Please include the string: [perl #38472] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38472 > well, i'm not certain my perl 6 syntax is correct (it's still a moving target, and i'm still learning.) however, i am certain that the 'output_is', 'output_isnt', and 'output_like' functions are synonyms for the more descriptively and accurately named 'pasm_output_is', 'pasm_output_isnt', and 'pasm_output_like' functions. usage of the former should be replaced with the latter throughout the test suite, and the former should be removed from Parrot::Test after conversion is complete.
