improved heredocs (r9734)
Heredocs have proven to create much more readable syntax especially inside compilers. I've hacked them a bit with the following effects: 1) single-quote-delimitted heredocs are valid now These wprk like single-quoted strings, that is: no backslash substitutions. 2) heredocs are now valid inside statements too, not just at end of line: .sub main :main .local string code code = '' emit(code, HERE, 10) line 1 line %d line 2 HERE .end .sub emit .param string code .param string more .param pmc args :slurpy $S0 = sprintf more, args code .= $S0 print code .end Thanks to Patrick for the hint. Please note that only one heredoc can be active at one time. Have fun, leo
Re: syntax-variants, RPN (was: Re: $_ defaulting for mutating ops)
On Wed, 2 Nov 2005, Ruud H.G. van Tol wrote: http://www.nntp.perl.org/group/perl.perl6.language/17556 I understand that Perl6 allows blocks with changed/enhanced syntax, so it is or will become possible (to add it) as if it was in the core language. Do I understand that right? Something as simple as a 'use RPN' in a block? (assuming that someone created such an RPN-pre-processor or -compiler) Indeed this is what that we all know. Of course the possibility of doing so will depend on the possiblity of building up suitable RPN syntax consistent with the rest of the syntax. Michele -- E' molto piu' facile affrontare il lutto, il disonore e la perdita della propria anima - che questo tipo di fame prolungata. - Joseph Conrad, Cuore di Tenebra.
Re: Proposed Kwalitee tests: has_license and/or has_meta_yml_license
David Landgren wrote: I don't know how to distinguish between someone who likes to jumps through hoops and someone who cares about their modules. I do, but it involves reading what they've written instead of (for example) just rgrepping for the current POD testing flavour of the month. I choose to achieve the highest possible Kwalitee for my modules because it's a way of showing people that I care. Perhaps you'd do better at showing *people*, as opposed to simplistic scripts, that you care by aiming for high Quality instead of Kwalitee. I'm all in favour of adding has_licence, on the grounds that some people care about Kwalitee willy-waving and not Quality, and so it'll be a good way to encourage them to DTRT. -- David Cantrell
Re: $_ defaulting for mutating ops
On Thu, 3 Nov 2005, Sam Vilain wrote: That being said, there are probably other more pressing reasons that ops should not accept $_ as default; I would guess, for a start, it makes determining semantics very difficult. Does ++; mean postfix:++ or prefix:++ ? If we had it, I think we would be more interested in it for incrementing $_ than for its return value, so it wouldn't make such a huge difference. However I find myself using $var++ much more often than ++$var, and I'm biased to think this is the general situation: if it is actually so, then the choice should fall on the former. If my impression is just a personal artifact... oh, don't mind! Michele -- Billy: I'm scared Poncho. Poncho: Bullshit! You ain't afraid of no man! Billy: There's something out there waiting for us, and it ain't no man. We're all gonna die. - Predator (1987)
Re: [perl #37372] [TODO] unicode charset classification
Leopold Toetsch (via RT) wrote: charset/unicode.c needs implementation of is_ccass / find_cclass, / find_not_cclass. Done - r9737, r9738. More tests are very welcome (t/op/string_cclass.t). 10) receive grand Parrot unicode award All mine. leo
Re: CPAN Testers results
Quoting Ovid [EMAIL PROTECTED]: I've noticed that http://search.cpan.org/~ovid/HOP-Parser-0.01/, amongst other modules, has no CPAN test results appearing even though CPAN tester reports are coming in. I've seen this for other modules, too. Is there an announced reason for this I missed or is something down? Unfortunately Leon has been having problems with his server [1], which is where the parsing of all the reports is done and the master testers.db resides. Until it's back online there won't be any updates. [1] http://use.perl.org/~acme/journal/27294 Barbie. -- Barbie (@missbarbell.co.uk) | Birmingham Perl Mongers user group | http://birmingham.pm.org/ --- This mail sent through http://www.easynetdial.co.uk
Re: Segfault with structs and CSTR
Joshua Isom wrote: I'm trying to use libc to be able to do a directory listing, and and if I used the DATATYPE_CSTR I get a segfault, and if I use DATATYPE_STRING, I get a returning unhandled string type in struct I tried this a while back, and got it working (as a kind of proof-of-concept) by reading the directory name character-by-character (using multiple occurrences of DATATYPE_CHAR, instead of DATATYPE_STRING or DATATYPE_CSTR). Clearly that's not the right way to do it, so I didn't bother to keep my code. Then I looked at all the #IFDEFs in dirent.h and decided that a NCI approach was unlikely to work on other platforms, so I wrote a PMC instead. Regards, Roger Browne
Re: syntax-variants, RPN (was: Re: $_ defaulting for mutating ops)
On 11/3/05, Michele Dondi [EMAIL PROTECTED] wrote: On Wed, 2 Nov 2005, Ruud H.G. van Tol wrote: http://www.nntp.perl.org/group/perl.perl6.language/17556 I understand that Perl6 allows blocks with changed/enhanced syntax, so it is or will become possible (to add it) as if it was in the core language. Do I understand that right? Something as simple as a 'use RPN' in a block? (assuming that someone created such an RPN-pre-processor or -compiler) Indeed this is what that we all know. Of course the possibility of doing so will depend on the possiblity of building up suitable RPN syntax consistent with the rest of the syntax. If Perl6 is parseable by Perl6, then wouldn't you be able to completely throw out the default Perl6 syntax and create your own, completely unrelated syntax? I don't know ... maybe you have PGE::Ruby that would throw out the P6 grammar and give you Ruby's grammar within the block. Then, it's just a matter of describing what PGE::RPN does - what it adds, what it removes, and what it modifies. In my opinion, if you use a grammar extension, ALL bets are off within that scope until you've read the documentation. Literally anything and everything can happen, if the author deemed it so. It's a source filter-like construct that doesn't suck because source filter-like constructs are part of the spec. Rob
Re: Segfault with structs and CSTR
Joshua Isom wrote: I'm trying to use libc to be able to do a directory listing, and and if I used the DATATYPE_CSTR I get a segfault, and if I use DATATYPE_STRING, It's neither nor. A DATATYPE_CSTR would be a pointer to a cstring. But when you look at the definition of struct dirent, you see an inlined array of chars with size 256. After fixing this and specifying d_fileno is DATATYPE_INT64, the program works: leo .sub _main @MAIN .local pmc libc .local pmc opendir .local pmc readdir .local pmc closedir null libc dlfunc opendir, libc, 'opendir', 'pt' dlfunc readdir, libc, 'readdir', 'pp' dlfunc closedir, libc, 'closedir', 'ip' store_global 'libc::opendir', opendir store_global 'libc::readdir', readdir store_global 'libc::closedir', closedir .local pmc curdir curdir = libc::opendir(.) .local OrderedHash entry entry = libc::readdir(curdir) entry = libc::readdir(curdir) entry = libc::readdir(curdir) .include datatypes.pasm new $P2, .OrderedHash set $P2[d_fileno], .DATATYPE_INT64 push $P2, 0 push $P2, 0 set $P2[d_reclen], .DATATYPE_SHORT push $P2, 0 push $P2, 0 set $P2[d_type], .DATATYPE_CHAR push $P2, 0 push $P2, 0 set $P2[d_name], .DATATYPE_CHAR push $P2, 256 push $P2, 0 # 11 assign entry, $P2 $I1 = 0 loop: $I0 = entry[d_name;$I1] unless $I0 goto ex chr $S0, $I0 print $S0 inc $I1 goto loop ex: print \n .end
Re: Segfault with structs and CSTR
Joshua Isom wrote: I'm trying to use libc to be able to do a directory listing, ... Another tricky part is detecting the NULL pointer after the end, achievable with the get_addr opcode. Here is a directory lister: leo .sub _main @MAIN .local pmc libc .local pmc opendir .local pmc readdir .local pmc closedir null libc dlfunc opendir, libc, 'opendir', 'pt' dlfunc readdir, libc, 'readdir', 'pp' dlfunc closedir, libc, 'closedir', 'ip' store_global 'libc::opendir', opendir store_global 'libc::readdir', readdir store_global 'libc::closedir', closedir .local pmc curdir curdir = libc::opendir(charset) .local OrderedHash entry .include datatypes.pasm new $P2, .OrderedHash set $P2[d_fileno], .DATATYPE_INT64 push $P2, 0 push $P2, 0 set $P2[d_reclen], .DATATYPE_SHORT push $P2, 0 push $P2, 0 set $P2[d_type], .DATATYPE_CHAR push $P2, 0 push $P2, 0 set $P2[d_name], .DATATYPE_CHAR push $P2, 256 push $P2, 0 # 11 lp_dir: entry = libc::readdir(curdir) $I0 = get_addr entry unless $I0 goto done assign entry, $P2 $I1 = 0 loop: $I0 = entry[d_name;$I1] unless $I0 goto ex chr $S0, $I0 print $S0 inc $I1 goto loop ex: print \n goto lp_dir done: libc::closedir(curdir) .end
[perl #37600] [TODO] Heredocs as macro args
# New Ticket Created by Will Coleda
# Please include the string: [perl #37600]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37600
I dug through partcl to see where I could take advantage of the new
anywhere HEREDOCS, and found a case that didn't work.
.macro print(THING)
print .THING
.endm
.sub main
.print ('ok 1\n')
.print ('WHEE')
ok 2
WHEE
.end
I'd expect this to print ok 1\nok 2\n, but it doesn't compile:
error:imcc:The opcode 'print' (print0) was not found. Check the
type and number of the arguments
in macro '.say' line 2
included from 'foo.pir' line 7
[perl #37386] [PATCH] Swapped enum_cclass_any and enum_cclass_none in cclass.h
This patch has not been applied, but the same bug has been fixed by Leo's work in revision 9737. Could somebody please mark this ticket as Resolved? Thanks. Regards, Roger Browne -- Roger Browne - [EMAIL PROTECTED] - http://xamber.org/
Re: [perl #37600] [TODO] Heredocs as macro args
Will Coleda (via RT) wrote: error:imcc:The opcode 'print' (print0) was not found. Check the type and number of the arguments in macro '.say' line 2 included from 'foo.pir' line 7 This is a different error then the subject says - you are using a reserved word (opcode) as macro name. Anyway, using heredocs in macro arguments gives now an error saying this isn't allowed. leo
Re: Role Method Conflicts and Disambiguation
On Nov 2, 2005, at 9:02 PM, Jonathan Lang wrote:
Let's say you have this:
role A {method foo() { code1; } }
role B {method foo() { code2; } }
role C does A does B {
method foo() { A::foo(); }
method bar() { B::foo(); }
}
Should the following be valid?
role D does C { method foo() { B::foo(); } }
IMHO, it shouldn't, because D doesn't do B.
Not valid in what way? Should this be a fatal error?
Are you implying that B is not local to D, so it cannot use it? that
somehow disambiguation must be done using one of your local subroles
only?
I think this is too restrictive, D should be able to freely
disambiguate or override using anything it want's to. It need not be
related at all to it's subroles.
Stevan
Re: [perl #37600] [TODO] Heredocs as macro args
This is what I get for changing my sample at the last minute. =-) On Nov 3, 2005, at 10:26 AM, Leopold Toetsch wrote: Will Coleda (via RT) wrote: error:imcc:The opcode 'print' (print0) was not found. Check the type and number of the arguments in macro '.say' line 2 included from 'foo.pir' line 7 This is a different error then the subject says - you are using a reserved word (opcode) as macro name. Anyway, using heredocs in macro arguments gives now an error saying this isn't allowed. leo
Re: Role Method Conflicts and Disambiguation
On Nov 2, 2005, at 9:02 PM, Jonathan Lang wrote:
Let's say you have this:
role A {method foo() { code1; } }
role B {method foo() { code2; } }
role C does A does B {
method foo() { A::foo(); }
method bar() { B::foo(); }
}
Should the following be valid?
role D does C { method foo() { B::foo(); } }
IMHO, it shouldn't, because D doesn't do B.
Additionally, D most certainly does B. That it does B through a proxy
is irrelevant. Think about it this way - if you had Surfer and Dog and
SurferDog does Surfer does Dog, wouldn't you want to know that
class ScoobyDoo does SurferDog does Dog?
If SurferDog doesn't do Dog, how would ScoobyDoo do Dog?
I think this is too restrictive, D should be able to freely
disambiguate or override using anything it want's to. It need not be
related at all to it's subroles.
To further expand on this, D's disambiguation of method foo() could be:
role D does C { method foo() { Completely::Unrelated::foo() } }
Rob
Re: Why submethods
HaloO,
Luke Palmer wrote:
On 10/29/05, Damian Conway [EMAIL PROTECTED] wrote:
So we need a mechanism that is externally (i.e. from a class interface
point-of-view) a subroutine, but internally has the features of a method (i.e.
has an invocant). Since it's externally sub-like but internally method-like,
we call this useful construct a submethod.
Wouldn't the semantics fall out naturally from
1) beeing a scoped 'our sub'
2) the topic type ^_ of the topic item $_ beeing
contra-variantly defined to the concrete class type?
Number 1) assumes that a sub definition in a class without my or our gets
a sig of :(Any $_ = CALLER$_, [EMAIL PROTECTED]). The property 2) ensures the
non-inheritance indirectly because an overriding sub in a derived class
would permit the Foo::bar application.
That is Luke's example could read
class Foo
{
has $.data; # creates rw accessor
our sub bar # sig is :( void: Foo $_, [EMAIL PROTECTED] )
{
$.data = 23; # Not allowed outside of class scope?
# .data = 23; # Or force through accessor?
}
}
my $foo = Foo.new;
$foo.bar; # binds $_ := $foo and all member refs through $foo,
# then calls Foo::bar with empty @_
say $foo.data; # prints 23
For most of that, doesn't a private method suffice?
When it doesn't, I feel uneasy about:
class Foo {
submethod bar() { ... }
}
my $foo = Foo.new;
$foo.bar;
If that's externally sub-like, why does it look so much like a method?
Isn't looking like a method more a feature of the dot syntax than anything
else? Does bar($foo) cause the same perception? If my signature assumptions
above are correct then an argumentless bar call without invocant is a
too few arguments error.
If I understand the term 'package dispatch' of Sam Vilain correctly the
package that contains class Foo would maintain a dispatch into class scoped
subs depending on the immediate class---is that the eigenclass?---of the
invocant. That is we could define
class Bar
{
has $.data; # creates rw accessor
our sub bar # sig is :( void: Bar $_, [EMAIL PROTECTED] )
{
$.data = 42;
}
}
in addition to the Foo from above and then
sub package_dispatched ($x) { $x.bar }
my $bar = Bar.new;
package_dispatched( $foo ); say $foo.data; # 23
package_dispatched( $bar ); say $bar.data; # 42
But I can understand that Damian thinks that spelling 'our sub' as
'submethod' is good documentation and not a subtlety. OTOH, a 'my sub'
is not considered too subtle. Actually a 'has sub foo ...' form might be
an alternate spelling for 'has .foo = sub ...' and we can drop the
strange word 'submethod' and nicely unify all code types. That is
sub = package dispatch on void
method = unary dispatch on single invocant item type
multi = symmetric multi dispatch on invocant tuple type
or left biased successive single dispatch on invocant list
or a mix of both
--
Re: Determining number of return values expected
On Sun, 2005-10-30 at 20:54 +, Jonathan Worthington wrote: $P0 = result_info $I0 = elements $P0 Will leave $I0 containing the number of return values. Thanks Jonathan, it seem to work perfectly. I'm very grateful for this. Regards, Roger Browne
Test::More behavior issue with Devel::Cover + patch
First of all, I have Test::More 0.62 installed and Devel::Cover 0.55 under
Perl 5.8.2. I also have a simple test script:
$ cat test.pl
#!/usr/bin/perl
use warnings;
use strict;
use Test::More tests = 1;
$a = {};
isa_ok($a,'HASH');
...which works well under prove:
$ prove test.pl
testok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.03 cusr + 0.00 csys = 0.03 CPU)
When I throw Devel::Cover into the mix, however, prove gets a little sick:
$ HARNESS_PERL_SWITCHES=-MDevel::Cover prove test.pl
testok 1/1# Looks like your test died just after 1.
testdubious
Test returned status 255 (wstat 65280, 0xff00)
after all the subtests completed successfully
Failed Test Stat Wstat Total Fail Failed List of Failed
---
test.pl 255 65280 10 0.00% ??
Failed 1/1 test scripts, 0.00% okay. 0/1 subtests failed, 100.00% okay.
After tracing this for a while, I found out this is because Test::More is
attempting to call -isa on the empty, unblessed hashref. There's a
comment in the code about honoring isa() overrides, which I understand.
The problem lies in that Test::Builder overrides $SIG{__DIE__} with
something that checks the caller stack for an eval. However, for some
reason under D::C 0.55, this doesn't catch and prove thinks the test dies,
when it doesn't.
The solution I see is to make sure the object can() isa(), thus avoiding
the die in the process:
diff -ur Test-Simple-0.62/lib/Test/More.pm
Test-Simple-0.62-patched/lib/Test/More.pm
--- Test-Simple-0.62/lib/Test/More.pm 2005-10-08 01:56:17.0 -0500
+++ Test-Simple-0.62-patched/lib/Test/More.pm 2005-11-03 10:47:39.0
-0600
@@ -531,7 +531,7 @@
elsif( !ref $object ) {
$diag = $obj_name isn't a reference;
}
-else {
+elsif( UNIVERSAL::can($object,'isa') ) {
# We can't use UNIVERSAL::isa because we want to honor isa() overrides
local($@, $!); # eval sometimes resets $!
my $rslt = eval { $object-isa($class) };
@@ -555,6 +555,12 @@
$diag = $obj_name isn't a '$class' it's a '$ref';
}
}
+else {
+if ( !UNIVERSAL::isa($object, $class) ) {
+my $ref = ref $object;
+$diag = $obj_name isn't a '$class' it's a '$ref';
+}
+}
And that makes prove happy once more.
Thanks,
-Pete K
--
Pete Krawczyk
perl at bsod dot net
Re: automated web testing with selenium
-BEGIN PGP SIGNED MESSAGE- Moin, On Wednesday 02 November 2005 22:56, Luke Closs wrote: Hey there. I was just interviewed by qapodcast.com about Selenium, a cool new automated web testing tool. It's really great, and super easy to use. Also, yesterday Test::WWW::Selenium was uploaded to CPAN, so Selenium can now be driven by perl! Anyways, check out the podcast at http://qapodcast.com You mean you posted a link to an .mp3 file on a website, but hadn't had the courtesy to include in the mail (so that we all have to actually load the page to find it)? Bah! SCNR;) Tels - -- Signed on Thu Nov 3 18:47:02 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. Retsina? - Ja, Papa? - Angriff im Morgengrauen. - Is gut, Papa. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iQEVAwUBQ2pNs3cLPEOTuEwVAQFauAf/TAp0j5yQigNurotky33uTFYbC9xxWxrS n50KOkHh5xoB13EYdHqMWk19S0AIEwzxIsztDVDd+ucuBD5n5cB007Dgqa7Lpkq5 FpAzs0RpXKXlXGTJrSlgd6iKFU/aR5ITAgnjkCYDgaNz1FePyW97r6dqsek+eRfY B4JG2bV1w3L0Yr0RbP4RWLHkdcRI9fzkvHrfcNUvugYNYmCooD+M+UFsA8IZdeD3 6PXJwYZqZQVbGtDCnAJVDZoaaHrIRIiCZaLDt5ZqFB1ZcS13h5mlRhM2pmDX3piE eZsKAR9qHfqRc2Hca8KAvf4LnLZhWgyw1PTPb4aHxTh7XDCfAARnrg== =SQ+k -END PGP SIGNATURE-
Re: Test::More behavior issue with Devel::Cover + patch
* Pete Krawczyk [EMAIL PROTECTED] [2005-11-03T12:46:48] The solution I see is to make sure the object can() isa(), thus avoiding the die in the process: It was using -isa instead of UNIVERSAL::isa because isa might be overridden. Surely the same could apply to -can. -- rjbs pgpe2GjbXn9Q1.pgp Description: PGP signature
Re: Role Method Conflicts and Disambiguation
HaloO,
Rob Kinyon wrote:
On Nov 2, 2005, at 9:02 PM, Jonathan Lang wrote:
Let's say you have this:
role A {method foo() { code1; } }
role B {method foo() { code2; } }
I think, A and B might just be aliases to the *identical* structural type
because the only constraint that both roles impose on their implicit type
parameter is the presence of a method foo() on the type of just this
parameter. The implementation parts are of course different. In other words
the roles A and B are interchangable as far as the structural type checker
is concerned! That is there is a
theory T{^R} { multi foo (^R) {...} }
A ::= T{A};
B ::= T{B};
A::foo.block ::= code1; # or however .block is spelled
A::foo.block ::= code2; # or { code2; } ?
role C does A does B {
method foo() { A::foo(); }
method bar() { B::foo(); }
}
Should the following be valid?
role D does C { method foo() { B::foo(); } }
IMHO, it shouldn't, because D doesn't do B.
Additionally, D most certainly does B. That it does B through a proxy
is irrelevant. Think about it this way - if you had Surfer and Dog and
SurferDog does Surfer does Dog, wouldn't you want to know that
class ScoobyDoo does SurferDog does Dog?
Semantic wise or type wise?
If SurferDog doesn't do Dog, how would ScoobyDoo do Dog?
Assuming that the type system supervises the constraint addition
in role composition, a meta information lookup on SurferDog should
yield all you need to know about what kind of thing it is!
Just think of electrons and the double slit, if you don't require
them to know through which slit they passed, they don't bother to
remember it ;)
I think this is too restrictive, D should be able to freely
disambiguate or override using anything it want's to. It need not be
related at all to it's subroles.
Well, it can't step out of the frame that the constraints of C impose.
Actually it can because not all contstraints are computer enforceable
but it shouldn't for social reasons.
To further expand on this, D's disambiguation of method foo() could be:
role D does C { method foo() { Completely::Unrelated::foo() } }
Yes, of course. But these are the boring cases. More interesting is
something like
role X
{
method foo (: XA $a, XB $b -- XC ) {...}
}
role Y does X
{
method foo (: YA $a, YB $b -- YC ) {...}
}
where the definition of Y should succeed only iff Y::foo : X::foo
which requires YC : XC and (XA,XB) : (YA,YB) where : denotes the
subtype relation.
--
co/contra variance of roles/factories in theory.pod
HaloO,
I don't understand why theory.pod states that roles are covariant, unary
theories and factories are contravariant. I would expect the opposite from
the requirement that all functions in roles only take the topic type while
function in factories only return the topic type.
So if A : B, I would expect Role{B} : Role{A} and Factory{A} : Factory{B}
on the following rational. Thinking of A beeing a proper subset of B we
get the reverse relation for their complements because parts of the outside
of A are inside of B. Functions in roles have type (R -- None(R)) and
functions in factories have type (None(F) -- F) with R and F the implicit
topic types of the role and factory respectively. Normal arrow subtyping
rules then result in roles beeing *contravariant*, unary theories and
factories beeing *covariant*, unary theories.
OTOH, theory.pod talks about the topic type appearing in the invocant
position of methods of roles, which subtypes covariantly. Note also that
the return type is covariant. So I neither understand the part about roles
having methods that return the type the role defines.
Thanks in advance for clarification.
--
Re: co/contra variance of roles/factories in theory.pod
On 11/3/05, TSa [EMAIL PROTECTED] wrote:
So if A : B, I would expect Role{B} : Role{A} and Factory{A} : Factory{B}
on the following rational.
Well, it's possible that I'm abusing the terms, since I first heard
the terms from you and inferred what they meant.
However, there is a problem in your statement:
A : B implies Role{B} : Role{A}
Since Role{B} is not a type: it is a predicate. The way I put it (and
I think it is put this way in the document):
If Role{B} and A : B, then Role{A} (for any role Role)
Similarly:
If Factory{A} and A : B, then Factory{B} (for any factory Factory)
Thinking of A beeing a proper subset of B we
get the reverse relation for their complements because parts of the outside
of A are inside of B. Functions in roles have type (R -- None(R)) and
functions in factories have type (None(F) -- F) with R and F the implicit
topic types of the role and factory respectively. Normal arrow subtyping
rules then result in roles beeing *contravariant*, unary theories and
factories beeing *covariant*, unary theories.
Hmm, okay. Then I probably reversed them (I need to read more about
arrow subtyping).
OTOH, theory.pod talks about the topic type appearing in the invocant
position of methods of roles, which subtypes covariantly. Note also that
the return type is covariant. So I neither understand the part about roles
having methods that return the type the role defines.
Let's see if I understand what you're asking. You're asking about:
role Foo {
method bar(-- Foo) {...}
}
Expanding this to a theory:
theory Foo{^T} {
method bar(^T: -- ^U = Foo{^U}) {...}
}
This is different from:
theory Foo2{^T} {
method bar2(^T: -- ^T) {...}
}
We can see the difference when we have, say:
class Bar does Foo does Foo2 {...}
class Baz does Foo does Foo2 {...}
my $bar = Bar.new;
$bar.bar;# may return a Bar or a Baz
$bar.bar2; # may only return a Bar
If Foo2 were a role (that is, if it obeys the role relation above),
then the only thing bar2() could do would be to take some side-effect
action and then return the same object it was passed. Here's a proof:
Given ^T $x where Foo{^T}. Because of the role relation,
Foo{{$x}} (The singleton set {$x} does Foo). Therefore
the signature of bar in this instance is
:({$x} -- {$x}). Since $x was unrestricted, bar()
must be the identity on things that do Foo.
But of course, that's probably not what the author of the Foo role
intended. So we allow any Foo to be returned.
Did I answer your question?
Luke
Re: co/contra variance of roles/factories in theory.pod
On 11/3/05, Luke Palmer [EMAIL PROTECTED] wrote:
If Foo2 were a role (that is, if it obeys the role relation above),
then the only thing bar2() could do would be to take some side-effect
action and then return the same object it was passed. Here's a proof:
Given ^T $x where Foo{^T}. Because of the role relation,
Foo{{$x}} (The singleton set {$x} does Foo). Therefore
the signature of bar in this instance is
:({$x} -- {$x}). Since $x was unrestricted, bar()
must be the identity on things that do Foo.
Excuse me, s:g/Foo/Foo2/; s:g/bar/bar2/.
Luke
Re: Test::More behavior issue with Devel::Cover + patch
Subject: Re: Test::More behavior issue with Devel::Cover + patch
From: Ricardo SIGNES [EMAIL PROTECTED]
Date: Thu, 3 Nov 2005 13:14:34 -0500
}* Pete Krawczyk [EMAIL PROTECTED] [2005-11-03T12:46:48]
}
} The solution I see is to make sure the object can() isa(), thus avoiding
} the die in the process:
}
}
}It was using -isa instead of UNIVERSAL::isa because isa might be
}overridden. Surely the same could apply to -can.
Well, one of my other approaches was to do:
$SIG{__DIE__} = 'default'
but I didn't feel that was as elegant as the patch I proposed.
I'm not sure what the best method is.
-Pete K
--
Pete Krawczyk
petek at ignore dot us
Re: Segfault with structs and CSTR
I'm on FreeBSD 5.4 so aside from the char array, the rest was correct, which I guess means it's not at all portable. It's working now, now I just need to expand on it. On Nov 3, 2005, at 9:01 AM, Leopold Toetsch wrote: Joshua Isom wrote: I'm trying to use libc to be able to do a directory listing, ... Another tricky part is detecting the NULL pointer after the end, achievable with the get_addr opcode. Here is a directory lister: leo .sub _main @MAIN .local pmc libc .local pmc opendir .local pmc readdir .local pmc closedir null libc dlfunc opendir, libc, 'opendir', 'pt' dlfunc readdir, libc, 'readdir', 'pp' dlfunc closedir, libc, 'closedir', 'ip' store_global 'libc::opendir', opendir store_global 'libc::readdir', readdir store_global 'libc::closedir', closedir .local pmc curdir curdir = libc::opendir(charset) .local OrderedHash entry .include datatypes.pasm new $P2, .OrderedHash set $P2[d_fileno], .DATATYPE_INT64 push $P2, 0 push $P2, 0 set $P2[d_reclen], .DATATYPE_SHORT push $P2, 0 push $P2, 0 set $P2[d_type], .DATATYPE_CHAR push $P2, 0 push $P2, 0 set $P2[d_name], .DATATYPE_CHAR push $P2, 256 push $P2, 0 # 11 lp_dir: entry = libc::readdir(curdir) $I0 = get_addr entry unless $I0 goto done assign entry, $P2 $I1 = 0 loop: $I0 = entry[d_name;$I1] unless $I0 goto ex chr $S0, $I0 print $S0 inc $I1 goto loop ex: print \n goto lp_dir done: libc::closedir(curdir) .end
shr bug when shifting by a multiple of the int size?
I was trying to use bit shifting for division by multiples of two, but if the shift amount is a multiple of the int size, it seems to fail to shift the bits. Here's some example code demonstrating it. .sub _main @MAIN .local int a, b, c print a\tb\tc\n a = 24 b = 32 c = a b print a print \t print b print \t print c print \n a = 24 b = 16 c = a b print a print \t print b print \t print c print \n c = b print a print \t print b print \t print c print \n .end Here's the output I get. a b c 24 32 24 24 16 0 24 16 0 If I change b to 64, 96, or any multiple of 32, a remains unchanged. The size of int does make the difference. It works with my darwin installation with 32 but not my freebsd installation. hugefloatvalsize is 12 for darwin but 8 for freebsd. Gcc 3.4 for darwin, 3.3 for freebsd. Other than differences with compile environments(ppc darwin and x86 freebsd differences), it's a fairly identical installation. It's getting me somewhat confused.
Re: shr bug when shifting by a multiple of the int size?
On Nov 3, 2005, at 20:49, Joshua Isom wrote: I was trying to use bit shifting for division by multiples of two, but if the shift amount is a multiple of the int size, it seems to fail to shift the bits. Here's some example code demonstrating it. .sub _main @MAIN .local int a, b, c print a\tb\tc\n a = 24 b = 32 c = a b Shifting anything by = the bits of the int isn't portable nor specified. a = 24 b = 16 c = a b and shifting a small number by 16 gives 0 - that's fine. leo
Re: shr bug when shifting by a multiple of the int size?
On 11/3/05, Leopold Toetsch [EMAIL PROTECTED] wrote: On Nov 3, 2005, at 20:49, Joshua Isom wrote: I was trying to use bit shifting for division by multiples of two, but if the shift amount is a multiple of the int size, it seems to fail to shift the bits. Here's some example code demonstrating it. .sub _main @MAIN .local int a, b, c print a\tb\tc\n a = 24 b = 32 c = a b Shifting anything by = the bits of the int isn't portable nor specified. Why isn't it specified? It seems to me that it should be zero. The result being zero is also portable. Right-shifting only ever makes the number smaller. Luke
