Re: Test::Harness::Straps - changes?
On Fri, Jul 29, 2005 at 22:27:29 +0100, Adrian Howard wrote: Earlier today chromatic kindly gave me a gentle tap with the cluestick which let me figure out how to give T::H::S STDERR STDOUT, which means my mates test results are now toddling off to a SQLite database quite happily. By the way, Test::TAP::Model is a hack on top of Test::Harness::Straps that is supposed to make the toddling off part easier. I hope that in future incarnations (that is Perl 6 land) Test::Harness::Straps will resemble a SAX like parser, and Test::TAP will be one handler, and the interactive terminal output thingy will be another. Even in it's current hackish status Test::TAP::Model sure made writing Test::TAP::HTMLMatrix a lot easier. Ciao! -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me kicks %s on the nose: neeyah! pgpaPFJ6Bvdyx.pgp Description: PGP signature
sub foo ($x) returns ref($x)
Suppose we have a function that takes an argument and returns something
with the same type as that argument. One previous suggestion is this:
sub identity ((::a) $x) returns ::a { return(...) }
This is fine if both invariants in the the meaning of 'returns' thread
are observed, since the inner return will check that (...).does(::a),
and the outer context will demand ::a.does(ref($x)).
However, this relies on the fact that we unify argument types first,
then use the bounded type variables to handle returns types. Under that
scheme, It is less clear how to talk about how the types of two arguments
must relate. For example, assuming argument types are unified in a single
phase, the example below does nothing useful:
sub equitype ((::a) $x, (::a) $y) { ... }
It won't not help even if we replace the implicit does with of:
sub equitype ($x of (::a), $y of (::a)) { ... }
The reason, in Luke Palmer's words:
The trouble with this is that it doesn't provide any type safety.
In the case of a type conflict, a just degenerates to the Any type.
(cf. pugs/docs/notes/recursive_polymorphism_and_type)
This fact, coupled with the unappealing (::a) syntax, leads me to look
for a more Perlish representation. Adopting an idea from Odersky's
Nested Types paper, we can let terms occur at type variant position,
by introducing a ref form for types:
sub equitype ($x, $y of ref($x)) { ... }
sub subtype ($x, $y does ref($x)) { ... }
sub identity ($x) returns ref($x) { ... }
This reads like Perl, and can be guarded with trivial compile time
and runtime checks. We can also use type selectors to check
that pick can always return Int from an Array[of = Int]:
sub pick (@x) returns ref(@x).of { ... }
The only problem I can find is that the possible confusion between the
ref() operator and the unboxed basic type ref. Another thought is to
simply use ::() as a special ref form:
sub pick (@x) returns ::(@x).of { ... }
But that can confuse with the symbolic dereference syntax. All in all
I'm more happy with ref(), but better suggestions welcome.
Thanks,
/Autrijus/
pgpVukkp3HJdW.pgp
Description: PGP signature
Re: Test::Builder::STDOUT ?
On 30 Jul 2005, at 00:00, Michael G Schwern wrote:
[snip]
Perhaps you misunderstand.
I did
I mean to put that BEGIN { *STDERR = *STDOUT }
in the test script. foo.t never prints to STDERR.
Doh. I would have to put in in a module so I could shim it in with
HARNESS_PERL_SWITCHES but yes, that would have been simpler.
However analyse rather analyse_file was the right way in this
instance I think.
Adrian
Re: Does it cost anything to use a big pmc everywhere?
On Jul 29, 2005, at 18:58, Amir Karger wrote: So I think to avoid these problems I need to declare image at the top of every Z-code sub. My question is, is there any cost associated with always declaring this array holding 50-500K ints, other than having one P register always full? No not at all. just emit the 'image' declaration and the global fetch on top of each subroutine. If image isn't used below, the register occupied by image will even be reused. You could even avoid the global lookup (if image isn't used), by making .GETWORD a bit smarter: .macro GET_WORD(RES, IDX) .local pmc image unless_null image , .$ok image = global .. .local $ok: .RES = image[.IDX]# or some such ... .endm But that's probably not worth the effort. leo
Re: Test::Harness::Straps - changes?
On 30 Jul 2005, at 01:05, Andy Lester wrote:
On Fri, Jul 29, 2005 at 03:57:07PM -0700, Michael G Schwern
([EMAIL PROTECTED]) wrote:
This is, IMHO, the wrong place to do it. The test should not be
responsible
for decorating results, Test::Harness should be. It means you can
decorate
ANY test, not just those that happen to use Test::Builder.
This also coincides with the premise that Test::Harness::Straps are
just
parsing TAP from any given source.
I took chromatic to mean that he'd like the test harness to do the
decorating... so you could do something along the lines of:
{ package GrowlingFailure;
use base qw( Test::Harness::Test::Failure );
use Mac::Growl::Testing;
sub action {
my $self = shift
Mac::Growl::Testing-failed(
title = $self-name
description = $self-diagnostics
);
$self-SUPER::action;
}
}
{ package GrowlingTodo;
use base qw( Test::Harness::Test::Todo );
use Mac::Growl::Testing;
sub action {
Mac::Growl::Testing-unexpected_pass(
description = $self-diagnostics
) if $self-actually_passed;
$self-SUPER::action;
}
}
{ package GrowlingTestHarness;
use base qw( Test::Harness );
sub failure_test_class { 'GrowlingFailure' }
sub todo_test_class { 'GrowlingToodo' }
}
# show me pretty dialogs for test failures
GrowlingTestHarness-new-analyse_files( @ARGV );
So we have the underlying test harness producing different classes
for each variety of test.
(BTW chromatic: I'm curious why you didn't break todo tests into
separate passing/failing classes as you did the normal test?)
Adrian
say's return value
What do print and say return? fail would be great on errors. On success, they return 1 now, which doesn't look very useful. How about returning the printed string? Unless called in void context, of course. (This introduces a potential semipredicate problem when looking at the return value of a printed 0 or while not using fatal, but the code can use a defined guard.) -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
$arrayref.ref?
Hi, http://use.perl.org/~autrijus/journal/25337: deref is now 0-level; $x = 3; $y = \$x; $y++. # now an exception my $arrayref = [1,2,3]; say $arrayref.ref;# Ref or Array? say $arrayref.isa(Ref); # true or false? say $arrayref.isa(Array); # false or true? say +$arrayref; # 3 or error? say $arrayref + 1;# 4 or error? --Ingo -- Linux, the choice of a GNU | Black holes result when God divides the generation on a dual AMD | universe by zero. Athlon!|
Binding scalars to aggregates
Hi, my @array = a b c; my $arrayref := @array; push $arrayref, c; say [EMAIL PROTECTED]; # a b c d, no problem $arrayref = [d e f]; say [EMAIL PROTECTED]; # d e f, still no problem $arrayref = 42;# !!! 42 is not a Ref of Array Should the last line be treated as $arrayref = (42,); which, as the LHS is in scalar context, would auto-referize to $arrayref = [42]; which would work? Or should that be an error? (FWIW, I favour option 2.) --Ingo -- Linux, the choice of a GNU | Row, row, row your bits, gently down the generation on a dual AMD | stream... Athlon!|
Binding hashes to arrays?
Hi, is binding hashes to arrays (or arrays to hashes) legal? If not, please ignore the following questions :) my @array = a b c d; my %hash := @array; say %hasha; # b push @array, e f; say %hashe; # f? %hashX = Y; say [EMAIL PROTECTED]; # ??? # X Y (or X = Y?) appended to the end of @array? It seems to me supporting this is hard to get right... --Ingo -- Linux, the choice of a GNU | Mr. Cole's Axiom: The sum of the generation on a dual AMD | intelligence on the planet is a constant; Athlon!| the population is growing.
Re: $arrayref.ref?
On Sat, Jul 30, 2005 at 02:14:52PM +0200, Ingo Blechschmidt wrote: : Hi, : : http://use.perl.org/~autrijus/journal/25337: : deref is now 0-level; $x = 3; $y = \$x; $y++. # now an exception : : my $arrayref = [1,2,3]; : : say $arrayref.ref;# Ref or Array? Array. : say $arrayref.isa(Ref); # true or false? False, though tied($arrayref).isa(Ref) is probably true. : say $arrayref.isa(Array); # false or true? True. : say +$arrayref; # 3 or error? : say $arrayref + 1;# 4 or error? Both work. To the first approximation, refs to scalar non-object values must be explicitly derefed. But refs to non-scalar containers are considered objects so they will happily autoderef one level. It's possible we may find a way to relax the former constraint, but if so, it would go back to one-level deref, not all levels. Larry
Re: Binding scalars to aggregates
On Sat, Jul 30, 2005 at 02:33:15PM +0200, Ingo Blechschmidt wrote: : Hi, : : my @array = a b c; : my $arrayref := @array; : : push $arrayref, c; : say [EMAIL PROTECTED]; # a b c d, no problem : : $arrayref = [d e f]; : say [EMAIL PROTECTED]; # d e f, still no problem : : $arrayref = 42;# !!! 42 is not a Ref of Array : : Should the last line be treated as : $arrayref = (42,); : which, as the LHS is in scalar context, would auto-referize to : $arrayref = [42]; : which would work? : : Or should that be an error? : : (FWIW, I favour option 2.) Why shouldn't it do option 3, which is to work like in Perl 5? It should only be an error if $arrayref is declared with a type inconsistent with 42. Assignment goes to the container, not the current contents of that container. Larry
Re: Binding scalars to aggregates
Except that you've rebound the container. Hmm, maybe the original binding is an error. Larry
Re: Binding hashes to arrays?
On Sat, Jul 30, 2005 at 02:59:02PM +0200, Ingo Blechschmidt wrote: : Hi, : : is binding hashes to arrays (or arrays to hashes) legal? If not, please : ignore the following questions :) : : my @array = a b c d; : my %hash := @array; : : say %hasha; # b : push @array, e f; : say %hashe; # f? : %hashX = Y; : say [EMAIL PROTECTED]; # ??? : # X Y (or X = Y?) appended to the end of @array? : : It seems to me supporting this is hard to get right... As with the scalar binding I'm inclined to disallow it for now. Our theme this year: Be strict now--we can always relax it later. Of course, I shall probably violate that myself when I get around to answering Autrijus on return type checking... Larry
Re: Binding scalars to aggregates
Hi, Larry Wall wrote: On Sat, Jul 30, 2005 at 02:33:15PM +0200, Ingo Blechschmidt wrote: : my @array = a b c; : my $arrayref := @array; [...] : $arrayref = 42;# !!! 42 is not a Ref of Array : : Should the last line be treated as : $arrayref = (42,); : which, as the LHS is in scalar context, would auto-referize to : $arrayref = [42]; : which would work? : : Or should that be an error? : : (FWIW, I favour option 2.) Why shouldn't it do option 3, which is to work like in Perl 5? It should only be an error if $arrayref is declared with a type inconsistent with 42. Assignment goes to the container, not the current contents of that container. hm, I thought binding would make $arrayref and @array point to the same container? I.e.: my $a = 42; my $b; # $a -- Container1 -- 42 # $b -- Container2 -- undef $b := $a; # $a -- Container1 -- 42 # $b -- Container1 -- 42 (note: Container*1*) $a = 23; # $a -- Container1 -- 23 # $b -- Container1 -- 23 # But plain assignment does, of course, not change containers: my $c; # $c -- Container3 -- undef $c = $a; # $c -- Container3 -- 23 $a = 19; # $a -- Container1 -- 19 # $b -- Container1 -- 19 # $c -- Container3 -- 23 I.e. assignment goes to the container, but doesn't change it, and binding changes the container. --Ingo -- Linux, the choice of a GNU | Elliptic paraboloids for sale. generation on a dual AMD | Athlon!|
Re: Binding scalars to aggregates
Hi,
Larry Wall wrote:
Except that you've rebound the container. Hmm, maybe the original
binding is an error.
what about:
sub foo (Array $arrayref) {...}
my @array = a b c d;
foo @array;
The binding used by the parameter binding code does not use the
standard := operator then, right? (As it'd have to $arrayref :=
@array.)
--Ingo
--
Linux, the choice of a GNU | We are Pentium of Borg. Division is futile.
generation on a dual AMD | You will be approximated.
Athlon!|
Re: $arrayref.ref?
On 7/30/05, Larry Wall [EMAIL PROTECTED] wrote: On Sat, Jul 30, 2005 at 02:14:52PM +0200, Ingo Blechschmidt wrote: : say $arrayref.isa(Ref); # true or false? False, though tied($arrayref).isa(Ref) is probably true. In that case, how do you check if something is a ref? `if (tied($foo))`? Aankhen
Re: say's return value
On Sat, 2005-07-30 at 14:56 +0300, Gaal Yahas wrote: (This introduces a potential semipredicate problem when looking at the return value of a printed 0 or while not using fatal, but the code can use a defined guard.) I don't know if returning the printed string is the right approach, but would returning '$string but true' avoid the semipredicate problem? -- c
Re: say's return value
On Sat, Jul 30, 2005 at 09:25:12AM -0700, chromatic wrote: : On Sat, 2005-07-30 at 14:56 +0300, Gaal Yahas wrote: : : (This introduces a potential semipredicate problem when looking at the : return value of a printed 0 or while not using fatal, but the : code can use a defined guard.) : : I don't know if returning the printed string is the right approach, but : would returning '$string but true' avoid the semipredicate problem? I don't see any reason to return the string at all. It's almost never wanted, and you can always use .= or monkey but. Larry
Re: Binding scalars to aggregates
On Sat, Jul 30, 2005 at 05:17:29PM +0200, Ingo Blechschmidt wrote:
: Hi,
:
: Larry Wall wrote:
: Except that you've rebound the container. Hmm, maybe the original
: binding is an error.
:
: what about:
:
: sub foo (Array $arrayref) {...}
:
: my @array = a b c d;
: foo @array;
:
: The binding used by the parameter binding code does not use the
: standard := operator then, right? (As it'd have to $arrayref :=
: @array.)
Right, so I guess what really happens is ref autogeneration in that
case, and there's no difference between
$x = @array;
$x := @array;
Hey, who said anything about consistency? :-)
Larry
Re: Test::Harness::Straps - changes?
On Sat, 2005-07-30 at 11:50 +0100, Adrian Howard wrote: I took chromatic to mean that he'd like the test harness to do the decorating... Yep -- that way you don't have to munge whatever formatting Test::Harness::Straps does, you just decorate on a method that does the formatting for you. (BTW chromatic: I'm curious why you didn't break todo tests into separate passing/failing classes as you did the normal test?) TAP doesn't, so I didn't see any reason to do it. Now that you mention it, reporting unexpected successes might be worthwhile -- but then again, Test::Harness::Straps reports that as a bonus in the summary anyway. I can't think of anything useful to do with it, but if there is something, I'm happy to make that separation. -- c
Re: say's return value
On Sat, Jul 30, 2005 at 09:36:13AM -0700, Larry Wall wrote: I don't see any reason to return the string at all. It's almost never wanted, and you can always use .= or monkey but. So: fail on failure bool::true on success? Pugs currently returns bool::true. Is there a way to tag a sub as failable? Should there be one? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
module init hooks and pragmas
What gets called for me when someone uses my module? What gets called when someone nos it? LS11/Importation stipulates a standard syntax for import lists, and that's probably a good thing, but then how do you pass other compile-time requests to code that's being used? Perhaps in light of LS04/Closure traits, we can make use and no activate TURNON and TURNOFF blocks? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: Binding scalars to aggregates
On Sat, Jul 30, 2005 at 09:40:11AM -0700, Larry Wall wrote: Right, so I guess what really happens is ref autogeneration in that case, and there's no difference between $x = @array; $x := @array; Hey, who said anything about consistency? :-) Hm, not exactly. This form: $x = [EMAIL PROTECTED]; Triggers STORE for a tied $x, and allows for assignments to $x afterwards. This form: $x := [EMAIL PROTECTED]; Destroys $x's current tie, and binds it to a read-only container (as \ produces rvalues), so future assignments will not work. I'll post a separate semi-formal analysis of containers to perl6-compiler. Thanks, /Autrijus/ pgpzQezRLYGMl.pgp Description: PGP signature
Definition of containers.
I have just checked in the container type part of the new PIL runcore: http://svn.openfoundry.org/pugs/src/PIL.hs In the Pugs directory, you can run a sample test with: *PIL tests == %ENV =:= %ENV; True == %ENV =:= %foo; False == untie(%ENV); my %foo := %ENV; () == my %foo := %ENV; Following is a semi-formal treatment for containers, directly transliterated from the Haskell source. Containers come in two flavours: Non-tieable and Tieable. Both are typed, mutable references. There is no way in runtime to change the flavour. data Container s a = NCon (STRef s (NBox a)) | TCon (STRef s (TBox a)) A Non-tieable container is comprised of an Id and a storage of that type, which can only be Scalar, Array or Hash. Again, there is no way to cast a Scalar container into a Hash container at runtime. type NBox a = (BoxId, a) A Tieable container also contains an Id and a storage, but also adds a tie-table that intercepts various operations for its type. type TBox a = (BoxId, a, Tieable a) The type of tie-table must agree with the storage type. Such a table may be empty, as denoted by the nullary constructor Untied. Each of the three storage types comes with its own tie-table layout. data Tieable a where Untied :: Tieable a TieScalar :: TiedScalar - Tieable Scalar TieArray :: TiedArray - Tieable Array TieHash:: TiedHash - Tieable Hash Binding only happens between containers of the same type: bind :: Container s a - Container s a - ST s () Additionally, the compiler needs to compile ($x := @y) into ($x := [EMAIL PROTECTED]). To bind a container to another, we first check to see if they are of the same tieableness. If so, we simply overwrite the target one's Id, storage and tie-table (if any): bind (TCon x) (TCon y) = writeSTRef x = readSTRef y bind (NCon x) (NCon y) = writeSTRef x = readSTRef y To bind an non-tieable container to a tieable one, we implicitly remove any current ties on the target, although it can be retied later: -- %*ENV := %foo bind (TCon x) (NCon y) = do (id, val) - readSTRef y writeSTRef x (id, val, Untied) To bind a tieable container to a tied one, we first check if it is actually tied. If yes, we throw a runtime exception. If not, we proceed as if both were non-tieable. -- %foo := %*ENV bind (NCon x) (TCon y) = do (id, val, tied) - readSTRef y case tied of Untied - writeSTRef x (id, val) _ - fail Cannot bind a tied container to a non-tieable one We can compare two containers for Id equivalence. If the container types differ, this should never return True: (=:=) :: Container s a - Container s b - ST s Bool x =:= y = do x_id - readId x y_id - readId y return (x_id == y_id) Untie an non-tieable container is a no-op: untie (NCon x) = return () For a tieable container, we first invokes the UNTIE handler, then set its tied slot to Untied: untie (TCon x) = do (id, val, tied) - readSTRef x case tied of Untied - return () _ - do tied `invokeTie` UNTIE writeSTRef x (id, val, Untied) Thanks, /Autrijus/ pgpZ4bQLJ5AWC.pgp Description: PGP signature
Re: Definition of containers.
Autrijus Tang wrote:
Containers come in two flavours: Non-tieable and Tieable. Both are typed,
mutable references. There is no way in runtime to change the flavour.
data Container s a
= NCon (STRef s (NBox a))
| TCon (STRef s (TBox a))
A Non-tieable container is comprised of an Id and a storage of that type, which
can only be Scalar, Array or Hash. Again, there is no way to cast a Scalar
container into a Hash container at runtime.
Is 'tie' even required?
Tieing a hash would be the same as sub-classing it, and overriding
.post_circumfix:{}. Similarly with arrays and .post_circumfix:[].
Tieing a scalar would be achieved using those Proxy objects discussed
earlier and in S06.
Or is this merely a mechanism for the above?
Sam.
