Re: What the heck is a submethod (good for)
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Okay, I seriously have to see an example of a submethod in use.
Likewise. As far as I've seen, submethods are a kludge wedged in for
cases where you're actually calling all the way up the inheritence
tree. Personally, I've always thought a "cascade method" syntax would
be better for that:
post method BUILD($foo, $bar) { ... }
pre method DESTROY() { ... }
Cascade methods would be called (before|after) the indicated method in
a superclass was called. Their return values would probably be thrown
away. I think they might actually be a sort of syntactic sugar for
inserting `call` in the method body, but that's an implementation
detail, really...
--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
[perl #37430] [PATCH] support __delete_keyed_int methods in PMC objects
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #37430]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37430 >
In r9445 Leo added code to special-case the get_*_keyed_int
and set_*_keyed_int methods for parrot objects.
This patch adds support for delete_keyed_int (needed for PGE),
as well as updating the corresponding test in t/pmc/object_meths.t .
Pm
Index: classes/parrotobject.pmc
===
--- classes/parrotobject.pmc(revision 9474)
+++ classes/parrotobject.pmc(working copy)
@@ -189,8 +189,10 @@
=item C
-These methods have default implmentations in F
-which redirct to PMC keys. Test if a specialized method exists, else
+=item C
+
+These methods have default implementations in F
+which redirect to PMC keys. Test if a specialized method exists, else
use fallback.
=cut
@@ -285,6 +287,17 @@
SUPER(key, value);
}
+void delete_keyed_int (INTVAL key) {
+STRING *meth = CONST_STRING(interpreter, "__delete_keyed_int");
+PMC *sub = find_meth(interpreter, pmc, meth);
+if (sub) {
+(void) Parrot_run_meth_fromc_args(interpreter, sub,
+ pmc, meth, "vI", key);
+}
+else
+SUPER(key);
+}
+
/*
=item C
Index: t/pmc/object-meths.t
===
--- t/pmc/object-meths.t(revision 9474)
+++ t/pmc/object-meths.t(working copy)
@@ -1019,6 +1019,8 @@
$S0 = "foo"
o[$I0] = 42
o[$S0] = 42
+delete o[$I0]
+delete o[$S0]
.end
.namespace ["MyClass"]
@@ -1035,9 +1037,21 @@
print "skey\n"
.end
+.sub __delete_keyed_int :method
+.param int key
+print "del_ikey\n"
+.end
+
+.sub __delete_keyed :method
+.param string key
+print "del_skey\n"
+.end
+
CODE
ikey
skey
+del_ikey
+del_skey
OUTPUT
pir_output_is(<<'CODE', <<'OUTPUT', "delegate keyed_int PMC derived");
[PATCH] split on strings
Here's a patch to implement the split opcode such that it splits on
strings rather than regular expressions. I've also added a test to
t/op/string.t
Files affected:
M ops/string.ops
M t/op/string.t
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
=== ops/string.ops
==
--- ops/string.ops (revision 63)
+++ ops/string.ops (local)
@@ -479,8 +479,10 @@
=item B(out PMC, in STR, in STR)
-Create a new Array PMC $1 by splitting the string $3 with
-regexp $2. Currently implemented only for the empty string $2.
+Create a new Array PMC $1 by splitting the string $3 into pieces
+delimited by the string $2. If $2 does not appear in $3, then return $3
+as the sole element of the Array PMC. Will return empty strings for
+delimiters at the beginning and end of $3
=cut
@@ -507,22 +509,43 @@
}
op split(out PMC, in STR, in STR) :base_core {
-PMC *res = $1 = pmc_new(interpreter, enum_class_Array);
-STRING *r = $2;
-STRING *s = $3;
-int slen = string_length(interpreter, s);
-int i;
+PMC *res = $1 = pmc_new(interpreter, enum_class_ResizableStringArray);
+STRING *delim = $2;
+STRING *str = $3;
+int dlen = string_length(interpreter, delim);
+int slen = string_length(interpreter, str);
+int ps,pe;
if (!slen)
goto NEXT();
-if (string_length(interpreter, r))
- internal_exception(1, "Unimplemented split by regex");
-VTABLE_set_integer_native(interpreter, res, slen);
-for (i = 0; i < slen; ++i) {
- STRING *p = string_substr(interpreter, s, i, 1, NULL, 0);
- /* TODO first set empty string, then replace */
- VTABLE_set_string_keyed_int(interpreter, res, i, p);
+
+if (dlen == 0) {
+int i;
+VTABLE_set_integer_native(interpreter, res, slen);
+for (i = 0; i < slen; ++i) {
+ STRING *p = string_substr(interpreter, str, i, 1, NULL, 0);
+ VTABLE_set_string_keyed_int(interpreter, res, i, p);
+}
+ goto NEXT();
}
+
+ps = 0;
+pe = string_str_index(interpreter,str,delim,0);
+if (pe < 0) {
+ VTABLE_push_string(interpreter,res,str);
+ goto NEXT();
+}
+while (ps <= slen) {
+int pl = pe - ps;
+ STRING *tstr = string_substr(interpreter, str, ps, pl, NULL, 0);
+ VTABLE_push_string(interpreter,res,tstr);
+ ps = pe + string_length(interpreter,delim);
+ if (ps > slen)
+ break;
+pe = string_str_index(interpreter,str,delim,ps);
+ if (pe < 0)
+ pe = slen;
+}
goto NEXT();
}
=== t/op/string.t
==
--- t/op/string.t (revision 63)
+++ t/op/string.t (local)
@@ -16,7 +16,7 @@
=cut
-use Parrot::Test tests => 156;
+use Parrot::Test tests => 157;
use Test::More;
output_is( <<'CODE', <
Re: cpan testers and dependencies
On 10/12/05, David Landgren <[EMAIL PROTECTED]> wrote: > Fergal Daly wrote: > > http://www.nntp.perl.org/group/perl.cpan.testers/257538 > > > > shows a fail for Test-Benchmark but the fail seems to be caused by > > CPANPLUS not installing dependencies: > > Apparently it's a bug in CPANPLUS that stops it from keeping track of > grand children dependencies. @INC winds up only containing the first > level of prerequisites. That is, if A prereqs B, and B prereqs C, then > after having built C and then B, when testing A, only B appears in @INC. > There's a bug report on this on RT. > > In the meantime, I've given up smoking :( As much as that sucks I'm not sure it's the cause. In this case it was a direct prereq not a grandchild. Now that I've got RT open I guess I'll file a bug too, F
[perl #37428] [PATCH] Trivial typo fixes
# New Ticket Created by Joshua Hoblitt
# Please include the string: [perl #37428]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37428 >
- Forwarded message from Nick Glencross <[EMAIL PROTECTED]> -
From: Nick Glencross <[EMAIL PROTECTED]>
Date: Wed, 12 Oct 2005 12:51:44 +0100
To: perl6-internals@perl.org
Subject: [PATCH] Trivial typo fixes
Guys,
Nothing too much to this patch. A fix to a couple of typos
('unimplemented' and 'too') and a few paths in examples.
Regards,
Nick
Index: src/pmc_freeze.c
===
--- src/pmc_freeze.c(revision 9465)
+++ src/pmc_freeze.c(working copy)
@@ -712,7 +712,7 @@
else {
if (string_length(interpreter, s) < PACKFILE_HEADER_BYTES) {
real_exception(interpreter, NULL, E_IOError,
-"bad string too thaw");
+"bad string to thaw");
}
mem_sys_memcopy(pf->header, s->strstart, PACKFILE_HEADER_BYTES);
PackFile_assign_transforms(pf);
Index: t/native_pbc/header.t
===
--- t/native_pbc/header.t (revision 9465)
+++ t/native_pbc/header.t (working copy)
@@ -26,7 +26,7 @@
use Parrot::Config;
SKIP: {
-skip "new header format not yet implimented", 8;
+skip "new header format not yet implemented", 8;
# idea stolen from t/pmc/sub.t
my $tmppasm = File::Temp->new(UNLINK => 1, SUFFIX => '.pasm');
print $tmppasm <
pgpv6THYe7blA.pgp
Description: PGP signature
[perl #37431] [PATCH] (REVISED) support *_keyed_int methods in PMC objects
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #37431]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37431 >
REVISED-REVISED-REVISED
In r9445 Leo added code to special-case the get_*_keyed_int
and set_*_keyed_int methods for parrot objects.
This patch (which replaces the patch I sent earlier in #37430)
adds support for the other *_keyed_int methods (needed for PGE).
The patch also updates the corresponding test in t/pmc/object_meths.t .
Sorry for the double-patch submission; I didn't realize I would need the
other *_keyed_int methods as well.
Pm
Index: classes/parrotobject.pmc
===
--- classes/parrotobject.pmc(revision 9474)
+++ classes/parrotobject.pmc(working copy)
@@ -189,8 +189,14 @@
=item C
-These methods have default implmentations in F
-which redirct to PMC keys. Test if a specialized method exists, else
+=item C
+
+=item C
+
+=item C
+
+These methods have default implementations in F
+which redirect to PMC keys. Test if a specialized method exists, else
use fallback.
=cut
@@ -285,6 +291,39 @@
SUPER(key, value);
}
+void delete_keyed_int (INTVAL key) {
+STRING *meth = CONST_STRING(interpreter, "__delete_keyed_int");
+PMC *sub = find_meth(interpreter, pmc, meth);
+if (sub) {
+(void) Parrot_run_meth_fromc_args(interpreter, sub,
+ pmc, meth, "vI", key);
+}
+else
+SUPER(key);
+}
+
+INTVAL defined_keyed_int (INTVAL key) {
+STRING *meth = CONST_STRING(interpreter, "__defined_keyed_int");
+PMC *sub = find_meth(interpreter, pmc, meth);
+if (sub) {
+(void) Parrot_run_meth_fromc_args_reti(interpreter, sub,
+ pmc, meth, "II", key);
+}
+else
+SUPER(key);
+}
+
+INTVAL exists_keyed_int (INTVAL key) {
+STRING *meth = CONST_STRING(interpreter, "__exists_keyed_int");
+PMC *sub = find_meth(interpreter, pmc, meth);
+if (sub) {
+(void) Parrot_run_meth_fromc_args_reti(interpreter, sub,
+ pmc, meth, "II", key);
+}
+else
+SUPER(key);
+}
+
/*
=item C
Index: t/pmc/object-meths.t
===
--- t/pmc/object-meths.t(revision 9474)
+++ t/pmc/object-meths.t(working copy)
@@ -1019,6 +1019,12 @@
$S0 = "foo"
o[$I0] = 42
o[$S0] = 42
+delete o[$I0]
+delete o[$S0]
+$I1 = defined o[$I0]
+$I1 = defined o[$S0]
+$I1 = exists o[$I0]
+$I1 = exists o[$S0]
.end
.namespace ["MyClass"]
@@ -1035,9 +1041,49 @@
print "skey\n"
.end
+.sub __delete_keyed_int :method
+.param int key
+print "del_ikey\n"
+.end
+
+.sub __delete_keyed :method
+.param string key
+print "del_skey\n"
+.end
+
+.sub __defined_keyed_int :method
+.param int key
+print "def_ikey\n"
+.return (0)
+.end
+
+.sub __defined_keyed :method
+.param string key
+print "def_skey\n"
+.return (0)
+.end
+
+.sub __exists_keyed_int :method
+.param int key
+print "exists_ikey\n"
+.return (0)
+.end
+
+.sub __exists_keyed :method
+.param string key
+print "exists_skey\n"
+.return (0)
+.end
+
CODE
ikey
skey
+del_ikey
+del_skey
+def_ikey
+def_skey
+exists_ikey
+exists_skey
OUTPUT
pir_output_is(<<'CODE', <<'OUTPUT', "delegate keyed_int PMC derived");
[perl #32544] [TODO] split opcode unfinished
I've added this patch to ticket #32544. Thanks, Applied. > [coke - Thu Oct 13 05:20:53 2005]: > > Here's a patch to implement the split opcode such that it splits on > strings rather than regular expressions. I've also added a test to > t/op/string.t > > Files affected: > M ops/string.ops > M t/op/string.t > > -Scott > -- > Jonathan Scott Duff > [EMAIL PROTECTED]
Re: [perl #37431] [PATCH] (REVISED) support *_keyed_int methods in PMC objects
Patrick R.Michaud (via RT) wrote: This patch (which replaces the patch I sent earlier in #37430) adds support for the other *_keyed_int methods (needed for PGE). The patch also updates the corresponding test in t/pmc/object_meths.t . Looks good. Just ci it - thanks. leo
Re: What the heck is a submethod (good for)
All~
On 10/13/05, Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> Luke Palmer <[EMAIL PROTECTED]> wrote:
> > Okay, I seriously have to see an example of a submethod in use.
>
> Likewise. As far as I've seen, submethods are a kludge wedged in for
> cases where you're actually calling all the way up the inheritence
> tree. Personally, I've always thought a "cascade method" syntax would
> be better for that:
>
> post method BUILD($foo, $bar) { ... }
> pre method DESTROY() { ... }
>
> Cascade methods would be called (before|after) the indicated method in
> a superclass was called. Their return values would probably be thrown
> away. I think they might actually be a sort of syntactic sugar for
> inserting `call` in the method body, but that's an implementation
> detail, really...
I have always wondered about the absence of these. CLOS has them and
they look quite useful. Was it an intentionaly decision to omit this
type of multi method?
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary
Re: cpan testers and dependencies
On 10/13/05, James E Keenan <[EMAIL PROTECTED]> wrote:
> David Landgren wrote:
> > Fergal Daly wrote:
> >
> >> http://www.nntp.perl.org/group/perl.cpan.testers/257538
> >>
> >> shows a fail for Test-Benchmark but the fail seems to be caused by
> >> CPANPLUS not installing dependencies:
> >
> >
> > Apparently it's a bug in CPANPLUS that stops it from keeping track of
> > grand children dependencies. @INC winds up only containing the first
> > level of prerequisites.
>
> Without disputing the accuracy of that bug report for CPANPLUS
> (https://rt.cpan.org/NoAuth/Bug.html?id=14760), I doubt that's the
> problem here.
>
> Test-Benchmark-0.04/Makefile.PL includes this code:
>
> PREREQ_PM => {
> Benchmark => 1,
> 'Test::Builder' => 0,
> 'Test::Tester' => 0.103,
> 'Test::NoWarnings' => 0,
> },
>
> Benchmark and Test::Builder are core, so there are no missing
> dependencies there. AFAICT, Test-Tester-0.103 and the latest version of
> Test::NoWarnings do not 'use' or 'require' any non-core modules other
> than the superclasses included in their distributions. So I don't think
> that multiple levels of prerequisites can be the source of this problem.
>
> Another reason why I don't think it's a CPANPLUS problem is that I
> encountered the same bug as did cpan.tester imacat in the report F
> cited, namely, that "# Looks like you planned 36 tests but only ran 29."
> But I got that FAIL not by using CPANPLUS but by downloading the
> module with LWP::Simple::getstore, then manually trying to build the
> module with tar and make. As I reported off-list to Fergal, I had an
> older version of Test::Tester (0.07) installed on my box.
> Test-Benchmark-0.04/Makefile.PL should have forced me to upgrade, just
> as it should have forced the cpan tester to upgrade. But it didn't, for
> reasons unknown.
>
> When, however, I manually upgraded to Test-Tester-0.103, I re-ran 'make
> test' for Test-Benchmark-0.04 and all tests passed. I've diffed v0.07
> and v0.103 of Test-Tester, but nothing leaps out and says "I'm what's
> missing from the older version." I'm also puzzled by the fact that the
> block of tests which are failing in Test-Benchmark-0.04/t/test.t,
>
>check_test(
> sub {
> is_faster(-1, 2, $fac10, $fac30, "30 2 times faster than 10");
> },
> {
> actual_ok => 0,
> },
> "30 2 times than 10"
>);
>
> ... doesn't look materially different from the preceding block of tests:
>
>check_tests(
> sub {
> is_faster(-1, $fac20, $fac10, "20 faster than 10 time");
> is_faster(1000, $fac20, $fac10, "20 faster than 10 num");
> },
> [
> {
> actual_ok => 0,
> },
> {
> actual_ok => 0,
> },
> ],
> "20 slower than 10"
>);
>
>
> So, while I know that getting the latest version of Test-Tester clears
> up the problem with Test-Benchmark-0.04, I'm stumped as to why
> Test-Benchmark's Makefile.PL didn't force me to upgrade to
> Test-Tester-0.103. And I'm stumped as to why the last block of tests
> fails when very similar blocks pass.
To clarify, there are 2 problems.
1 the plan is out of whack. This is expected, I updated Test::Tester
so that it tests more things and as a result I updated all the modules
that depend on it. I also updated the PREREQs of those modules to
require the latest Test::Tester
2 the last test is failing. I'm not sure why but the nature of
Test::Benchmark is that things can fail occasionally because
benchmarks are not reliable, in fact the test that seems to be failing
is one that compares running factorial of 30 against factorial of 10
and expects them to differ by a factor of 2. This might be a bad test.
If (on your machine) it works consistently with 0.103 and fails
consitently with earlier version then that's puzzling but I can't
reproduce it.
The Makefile.PL won't force you to upgrade, it should warn you that
you have the wrong version and CPANPLUS should then ensure that the
correct one is installed before continuing. I tried it yesterday with
plain old CPAN.pm and it correctly fetched the latest version. A bug
has been filed,
F
Re: What the heck is a submethod (good for)
On Oct 13, 2005, at 9:47 AM, Matt Fowles wrote:
On 10/13/05, Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
Luke Palmer <[EMAIL PROTECTED]> wrote:
Okay, I seriously have to see an example of a submethod in use.
Likewise. As far as I've seen, submethods are a kludge wedged in for
cases where you're actually calling all the way up the inheritence
tree. Personally, I've always thought a "cascade method" syntax
would
be better for that:
post method BUILD($foo, $bar) { ... }
pre method DESTROY() { ... }
Cascade methods would be called (before|after) the indicated
method in
a superclass was called.
I don't think there is a need to restrict it to the wrapping
superclasses methods only, there is no reason that you could not also
have them wrap a local method too if you wanted.
This might actually be a legitimate use for a submethod too.
pre method foo () { ... } # this is inherited
submethod foo () { ... } # this is not inherited
post method foo () { ... } # this is inherited
I could see this construct being quite useful in a "Template Method"
pattern sort of way.
Their return values would probably be thrown
away. I think they might actually be a sort of syntactic sugar for
inserting `call` in the method body, but that's an implementation
detail, really...
I have always wondered about the absence of these. CLOS has them and
they look quite useful.
CLOS has "before", "after" and "around" method qualifiers actually.
AFAIK, the return values of these methods are thrown away too, as
Brent suggests.
One thing to keep in mind is that CLOS has generic functions instead
of the usual methods-attached-to-a-class scheme. It also has no
(simple) means of calling superclass methods and capturing the return
values (at least AFAIK, I am sure someone has hacked the abilities,
but I don't think it is part of the spec). The method qualifiers were
added to CLOS to allow for this kind of behavior.
Since Perl 6 does not suffer from this same issue, method qualifiers
are not *needed* like they are in CLOS. That said, they are a nice
bit of syntactic sugar (as Brent points out).
Maybe this could be done with traits?
method BUILD ($foo, $bar) is post { ... }
method DESTROY () is pre { ... }
Or possibly with some kind of name-mangling:
method BUILD:post ($foo, $bar) { ... }
method DESTROY:pre () { ... }
Stevan
Variable-sized register frames
Folks watching SVN checkins have already seen some patches floating by with: "Variable-sized reg frames" in the log head line. The complete plan is now available at: http://perlcabal.org/~lt/VR.txt There will be no visible impact on the surface of Parrot, all code will continue to run, *except* code that uses deprecated register stack opcodes from the file DEPRECATED. The opcodes C and C will be supported in the future, but with a by far more efficient implementation. Currently each of these opcodes comprises *eight* stack operation to copy 640 (32-bit arch) bytes. The reimplementation will just be one stack-like operation, to copy exactly what is needed, which will be typically a lot less. This makes all the over half-frame copy opcodes and such obsolete, so these will be tossed RSN. leo
Re: Closed Classes Polemic (was Re: What the heck is a submethod (good for))
> I think this is an opportune time for me to express that I think the > ability to close-source a module is important. I love open source, > and I couldn't imagine writing anything by myself that I wouldn't > share. But in order for Perl to be taken seriously as a commercial > client-side language, it must be possible to close the source. I > started writing a game with a few friends last year, and as we were > picking our implementation strategy, using Perl as the primary > "sequencing engine" for non-time-critical tasks was immediately > discounted when I commented that anybody can look at your perl source > if they want to. I'd be interested in finding out how this is reasonably feasible for, given that you just said a disassembler for Parrot is going to be relatively simple due to the level of introspection Perl is going to require. Of course, given that Parrot is the ultimate interoperability swiss army knife, one could envision a language without the introspection Perl requires (such as C) that would target Parrot quite nicely. (Isn't Carrot the name for this push? I haven't kept up with the Parrot list.) Then, disassembling that bytecode back to its original form becomes much less desirable. > Of course, there is no argument there for allowing closed-source > *modules*, just complete applications. But I'm sure you could fish > one out involving dynamic loading, or modding, or whatever you want to > call it. The argument that was made was for closing modules, not applications. Specifically, a DB vendor might be more comfortable providing a DBD for their product(s) if they could close the source.
Re: Checklist for resolving a [PATCH] bug
Joshua Hoblitt schrieb: It looks like the CREDITS file hasn't been getting updated. I'd like to revise that check-list to: - add the patch author to CREDITS or update the authors entry in CREDITS - add correspondence to the bug stating that the patch was applied AND the svn revision number. - make sure that the bugs 'Tag' includes 'Patch' I've got three more: - Claim ownership or interest ( CC ) of the ticket. In this way you will be received further correspondence about the ticket. - Run the test suite - make manitest - set the bugs 'Patch Status' to 'Applied' - set the bugs 'Status' to 'resolved' CU, Bernhard
Re: Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On Thu, Oct 13, 2005 at 03:01:29PM -0400, Rob Kinyon wrote: > > I think this is an opportune time for me to express that I think the > > ability to close-source a module is important. I love open source, > > and I couldn't imagine writing anything by myself that I wouldn't > > share. But in order for Perl to be taken seriously as a commercial > > client-side language, it must be possible to close the source. I > > started writing a game with a few friends last year, and as we were > > picking our implementation strategy, using Perl as the primary > > "sequencing engine" for non-time-critical tasks was immediately > > discounted when I commented that anybody can look at your perl source > > if they want to. > > I'd be interested in finding out how this is reasonably feasible for, > given that you just said a disassembler for Parrot is going to be > relatively simple due to the level of introspection Perl is going to > require. When I added the original encryption mechanism for perl (in early perl 3 days) I knew that it would not be an absolute ban to stop people from recreating my company's original source (and that was long before B::Deparse came along, of course). I certainly knew how to beat the encryption; and anyone with half a clue would know that it could be beaten. (Clue: perl has to be able to read the unencrypted code. It wasn't hard to find the right place in the perl source to insert a print statement that would dump out code that had been decrypted.) However, anyone who took the effort to recreate that source from encrypted form would *know* that any use of that decrypted source was not authorized by the copyright owners. This was considered by that company to be an adequate protection. Any infringement that did occur would clearly be a deliberate misuse and could be prosecuted with a reasonable assurance of success. (No such infringement was ever found - either anyone who considered it decided it would be too much work, or no-one was interested enough to consider it, or quite possibly there were one or more instances where it was decrypted for the challenge of "beating" the encryption but not in any way that lead to an obvious competitive misuse.) Just because you can't make locking perfect does not mean it has no value. --
Re: Proposal to make class method non-inheritable
HaloO, Stevan Little wrote: On Oct 11, 2005, at 8:47 PM, Larry Wall wrote: You seem to be arguing that a class has no state, but my view is that, in the abstract, a class encompasses the state of *all* its objects. It just hasn't picked one particular object to be at the moment. I love this notion because that makes the type that the class represents the potential state it would reach when *all* distinguishable instances were realized---which needs a lot of memory for many classes. But the bit class/type e.g. has exactly two distinguishable states! Well and more then these two will never be needed if the algebraic, boolean type is build with !, && and ||. Negation just exchanges the half of the type that is in use, the former one is returned into potentiality, that is, it leaves the programs actuality. The binary connectives leave false and true in the program respectively as soon as both booleans have entered the program! That is (1 && 0 == 0) and (0 || 1 == 1) dual each other, just as the unrealized potential state of a class duals the actually realized state of the instances of the class in any particular moment. Here's a nice magic square picture of the idea: -Class .. ::Classmeta space ** | /| | / |The diagonal line splits the potential(-) from | / |the actual(+) instances. Undef and the ::Class |/ |are the "singularities" of the class. The state | /|of the class moves up the diagonal through instance | / |creation, while the GC moves it towards Undef. | / | ** Undef .. +Classvalue space No, not that class has no state, but that with the currently specced classes we have inherited behaviors (class methods) but they do not inherit the accompanying state (class attributes) as well. I see this as potentially very problematic. What do you mean with "not inheriting class state"? I would think that beeing an instance of a class, an object should have access to the shared class data, but it is not part of the per object state. Or do you mean that class data is not accessable to the instances at all? I would hope that this is 'hidden' in the scopes where the class's parts are defined but of course accessable lexically from class support code there. --
Thoughs on Theory.pm
(ref: http://svn.openfoundry.org/pugs/docs/notes/theory.pod)
>theory Ring{::R} {
>multi infix:<+> (R, R --> R) {...}
>multi prefix:<-> (R --> R){...}
>multi infix:<-> (R $x, R $y --> R) { $x + (-$y) }
>multi infix:<*> (R, R --> R) {...}
># only technically required to handle 0 and 1
>multi coerce: (Int --> R) {...}
>}
>
> This says that in order for a type R to be a ring, it must
> supply these operations. The operations are necessary but
> not sufficient to be a ring; you also have to obey some
> algebraic laws (which are, in general, unverifiable
> programmatically), for instance, associativity over
> addition: C<(a + b) + c == a + (b + c)>.
I started thinking about the "in general, unverifiable programmatically"
bit. While obviously true, perhaps we can get closer than just leaving
them as comments. It should be possible to associate a
unit-test-generator with the theory, so I can say:
theory Ring(::R) {
...
axiom associative(R ($a, $b, $b)) {
is_true( ((a+b)+c) - (a+(b+c)) eqv R(0) );
}
...
}
And then say "for type T, please generate 1000 random tests of T using
axioms of Ring".
In an ultra-slow debug mode, the aximons could be propagated as post
conditions on every public mutator of T, so that we test them
continuously in a running application (or tes suite).
Re: Thoughs on Theory.pm
On Oct 13, 2005, at 6:45 PM, Dave Whipp wrote: I started thinking about the "in general, unverifiable programmatically" bit. While obviously true, perhaps we can get closer than just leaving them as comments. It should be possible to associate a unit-test-generator with the theory, so I can say: [...] And then say "for type T, please generate 1000 random tests of T using axioms of Ring". In an ultra-slow debug mode, the aximons could be propagated as post conditions on every public mutator of T, so that we test them continuously in a running application (or tes suite). While I like the idea, I would point out that 1000 tests with randomly generated data are far less useful than 5 tests chosen to hit boundary conditions. --Dks
Parrot leaks?
I've sent this before just to Leo, but this time I though it might be better to send to all people. I (and I think nobody more) is having malloc library complaining about a wrong free somewhere. I'm trying to debug it. In attach you can see the .pir I tried to compile, and the leaks log file. Also, I ran parrat --leak-test foo.pir. Hope this can help Cheers Alberto -- Alberto Simões - Departamento de Informática - Universidade do Minho Campus de Gualtar - 4710-057 Braga - Portugal .include "datatypes.pasm" .sub test :main # load library .local pmc libnci_test libnci_test = loadlib "libnci_test" unless libnci_test goto NOT_LOADED print "libnci_test was successfully loaded\n" # calling a function in libnci_test .local pmc nci_c dlfunc nci_c, libnci_test, "nci_c", "c" .local int nci_c_out ( nci_c_out ) = nci_c( ) print nci_c_out print "\n" .end Process 28136: 3374 nodes malloced for 2656 KB Process 28136: 256 leaks for 4800 total leaked bytes. Leak: 0x00d085d0 size=240 0x00d085d0 0x 0x 0x00d081f0 0x 0x 0x 0x 0x 0x 0x 0x 0x00d086c0 0x 0x 0x 0x00d081d0 0x00010df0 0x000115b0 0x000117f0 0x00011a00 0x00010fe0 0x00010e60 0x00011d70 ...`...p 0x 0x 0x 0x 0x00010210 0x00012ec0 0x00012ba0 0x00012bf0 ..+...+. ... Call stack: [thread 219b]: | 0x0 | start | _start | main | Parrot_new | make_interpreter | Parrot_init | init_world | create_config_hash | Parrot_thaw | run_thaw | todo_list_init | ft_init | PackFile_new | mem_sys_allocate_zeroed Leak: 0x00d0aa60 size=64 string '/Users/ambs/tmp/parrot/runtime/parrot/include/datatypes.pasm' Call stack: [thread 219b]: | 0x0 | start | _start | main | yyparse | yylex | include_file | Parrot_locate_runtime_file | mem_sys_allocate | malloc Leak: 0x00d13410 size=64 0x00d0a7f0 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x Call stack: [thread 219b]: | 0x0 | start | _start | main | yyparse | imc_close_unit | imc_compile_unit | emit_flush | e_pbc_emit | add_const_pmc_sub | pmc_new | Parrot_Sub_init | new_sub | mem_sys_allocate_zeroed Leak: 0x00d07950 size=48 0x00d00180 0x4d555458 0x 0x MUTX 0x 0x 0x 0x 0x 0x 0x 0x Call stack: [thread 219b]: | 0x0 | start | _start | main | Parrot_new | make_interpreter | Parrot_init | init_world | Parrot_initialize_core_pmcs | Parrot_SharedRef_class_init | Parrot_create_mro | create_class_pmc | get_new_pmc_header | new_pmc_header | mem__internal_allocate | malloc Leak: 0x00d07a00 size=48 0x00d00180 0x4d555458 0x 0x MUTX 0x 0x 0x 0x 0x 0x 0x 0x Call stack: [thread 219b]: | 0x0 | start | _start | main | Parrot_new | make_interpreter | Parrot_init | init_world | Parrot_initialize_core_pmcs | Parrot_TQueue_class_init | Parrot_create_mro | create_class_pmc | get_new_pmc_header | new_pmc_header | mem__internal_allocate | malloc Leak: 0x00d086c0 size=48 0x00d085d0 0x 0x 0x00d081f0 0x 0x 0x 0x 0x 0x 0x 0x Call stack: [thread 219b]: | 0x0 | start | _start | main | Parrot_new | make_interpreter | Parrot_init | init_world | create_config_hash | Parrot_thaw | run_thaw | todo_list_init | ft_init | PackFile_new | PackFile_Segment_new_seg | directory_new | mem_sys_allocate | malloc Leak: 0x00d13200 size=32 0x00d0a7f0 0x 0x02000460 0x ...` 0x 0x00d13220 0x00d13230 0x00d10002 ..2 ..20 Call stack: [thread 219b]: | 0x0 | start | _start | main | Parrot_runcode | Parrot_runcode | Parrot_runops_fromc_args | runops_args | new_ret_continuation_pmc | pmc_new | Parrot_RetContinuation_init | new_ret_continuation | mem_sys_allocate | malloc Leak: 0x00d0b620 size=32 string 'DATATYPE_LONGDOUBLE' Call stack: [thread 219b]: | 0x0 | start | _start | main | yyparse | yylex | yylex_skip | str_dup | mem_sys_allocate | malloc Leak: 0x00d0b600 size=32 str
Re: Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On Wed, Oct 12, 2005 at 13:08:27 -0700, chromatic wrote: > Closed classes should not exist. > > At least, they should only exist if the person *running* Perl 6 wants > them to exist -- never if merely the class writer wants to close them. In theory I agree, and I hope that will be the defacto way of doing it, but if perl 6 gets compiled portably to many different bytecodes (which it seems like it will) someone somewhere will write a backend which allows people to encrypt, and people will use it. I think this is something we need to accept, even if it isn't something we like. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me sneaks up from another MIME part: neeyah! pgpTI6eLrvl9T.pgp Description: PGP signature
Re: First (developers) Release of Test::Shlomif::Harness
In article <[EMAIL PROTECTED]>, Andy Lester <[EMAIL PROTECTED]> wrote: > On Mon, Oct 10, 2005 at 02:52:49PM -0700, chromatic ([EMAIL PROTECTED]) wrote: > > > I do NOT want to see that sort of thing as patches to Test::Harness. > > I have a few ideas myself on how to make T::H a little more clean and > > useful, but I'd have to do some refactorings myself on a private fork to > > see how well they look in practice. > And I'm OK with that. I just want, and I suspect 99% of any authors > want, to have people work WITH me. "Hey, Andy, I've got some ideas on > X, are you interested? Is this something you're looking at exploring?" If you want people to work with you, you can't talk to them like you just did to Shlomi. Since this is a community, you can also work with him to make it all work out. I don't think anyone should have to get anyone's permission to play with open source code. Just because you *think* someone else is behaving badly doesn't mean you have an excuse to. I'd much rather see Shlomi play around with his ideas outside of Test::Harness so we can take only the parts we like for the main line development. -- brian d foy, [EMAIL PROTECTED]
Re: Proposal to make class method non-inheritable
On Oct 13, 2005, at 4:45 PM, TSa wrote:
No, not that class has no state, but that with the currently
specced classes we have inherited behaviors (class methods) but
they do not inherit the accompanying state (class attributes) as
well. I see this as potentially very problematic.
What do you mean with "not inheriting class state"? I would think that
beeing an instance of a class, an object should have access to the
shared
class data, but it is not part of the per object state. Or do you mean
that class data is not accessable to the instances at all? I would
hope
that this is 'hidden' in the scopes where the class's parts are
defined
but of course accessable lexically from class support code there.
I mean that classes do not inherit class state along subclass lines.
Take this code for instance:
class Foo {
has $.bar;
}
every instance of Foo I create has it's own copy of $.bar. Now I
subclass it:
class Bar is Foo {}
every instance of Bar has it's own copy of $.bar as well. Now look at
this from the class attribute perspective.
class Foo {
our $.baz; # class data here,.. not instance data
}
Foo has a single copy of $.baz in it's internal namespace. Now
subclass it:
class Bar is Foo {}
Bar does not have it own copy of $.baz, in fact Bar's ability to
access Foo::{$.baz} (or however it would be spelt) is not more
special than any other class in the system.
The point I am trying to make is that class data is unique to the
class itself, and subclasses of said class do not have any special
priviledges or access to that data (leaving auto-generated accessors
out of the picture for now).
This is different though from how class methods behave, which seems
to me to be problematic.
Stevan
Re: Thoughs on Theory.pm
David Storrs wrote: While I like the idea, I would point out that 1000 tests with randomly generated data are far less useful than 5 tests chosen to hit boundary conditions. I come from a hardware verification background. The trend in this industry is driven from the fact that the computer can generate (and) run 1000 random tests more quickly than a human can write 5 directed tests. And a quick question: just what are the boundary cases of "a+(b+c)==(a+b)+c" for a generic Ring type? Of course, in the hardware world we give hints (constraints) to the generators to bias it towards interesting cases. Plus the tools use coverage data to drive the tests towards uncovered code (not entirely automatic). Finally, we have tools that can spend 48+ hours analyzing a small block (statically) to find really good set of tests.
Re(vised): Proposal to make class method non-inheritable
Well, I suspected there would not be much support for my initial
proposal on class methods, but I felt I had to try. Not being the
type of person who gives up easily, I want to revise the proposal
(incorporating some of the ideas in the responses).
I propose that class methods are inheritable, but have the following
behaviors/attributes:
1) Autogenerated Class attribute accessors will be submethods.
This means that this code:
class Foo {
our $.bar;
}
will be functionally identical to this code:
class Foo {
our $.bar;
submethod bar (Class $c:) { $.bar }
}
This will ensure that class methods which are specifically tied to
some kind of state within the class will not be inherited. At least
not by default, if you want that behavior, then you can do this:
class Foo {
our $.bar;
method bar (Class $c:) { $.bar }
}
2) Class methods be defined more specifically
I think that "method (Class $c:) { ... }" is kind of ugly, and if we
use eigenclasses to implement class methods, is not even correct.
Ideally we have some kind of way to represent Larry's "Dog but undef"
concept. This could be thought of as being the prototypical instance
(for those who like prototype based OO), and it would also be the
invocant for all class methods for Dog.
So anyway, here are a few ideas, in no particular order:
method bark (::Dog $d:) { ... }
# not sure if this notation is already taken or not
method bark ($Dog $d:) { ... }
# not sure I like this one myself, but to me it helps to re-
enforce the singleton nature of the class instance
method bark (Dog) { ... }
# this would be similar to functional languages where the
parameter matches a value, not the type of a value.
# The user would then be forced to use $?CLASS inside (this one is
probably too much B&D)
classmethod bark { ... }
# you can't get more specific than this :)
Okay, thats all for now, however, be on the lookout for some other
mails on the specifics of class method dispatch. If we are going to
do it, we need to do it right.
Thanks,
Stevan
Re: Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On 10/13/05, John Macdonald <[EMAIL PROTECTED]> wrote: > Just because you can't make locking perfect does not mean it > has no value. Acme::Bleach it is!
Re: Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On Fri, 2005-10-14 at 02:18 +0200, Yuval Kogman wrote: > On Wed, Oct 12, 2005 at 13:08:27 -0700, chromatic wrote: > > Closed classes should not exist. > > > > At least, they should only exist if the person *running* Perl 6 wants > > them to exist -- never if merely the class writer wants to close them. > In theory I agree, and I hope that will be the defacto way of doing > it, but if perl 6 gets compiled portably to many different > bytecodes (which it seems like it will) someone somewhere will write > a backend which allows people to encrypt, and people will use it. > > I think this is something we need to accept, even if it isn't > something we like. I don't care if people encrypt their code. I don't have to use it. I just don't want people who merely write a module or class to be able to prevent people who actually use that module or class from using, extending, or poking around in it. No Java "final", unless you're the one running the program. -- c
Re: [P6L] Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On Thu, Oct 13, 2005 at 06:13:09PM -0700, chromatic wrote: > I just don't want people who merely write a module or class to be > able to prevent people who actually use that module or class from > using, extending, or poking around in it. Sounds kind of like Linus's opinion of close-source modules. If they exist and work, he's not going to break them, but he's not going to do *anything* to specially support them. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: First (developers) Release of Test::Shlomif::Harness
Since this is a community, you can also work with him to make it all work out. Shlomi and I have already discussed this. I don't think anyone should have to get anyone's permission to play with open source code. That's exactly right, they don't, and I would never presume to tell them that they can't. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Re(vised): Proposal to make class method non-inheritable
On 14/10/05, Stevan Little <[EMAIL PROTECTED]> wrote:
> So anyway, here are a few ideas, in no particular order:
>
>method bark (::Dog $d:) { ... }
># not sure if this notation is already taken or not
>
>method bark ($Dog $d:) { ... }
># not sure I like this one myself, but to me it helps to re-
> enforce the singleton nature of the class instance
>
>method bark (Dog) { ... }
># this would be similar to functional languages where the
> parameter matches a value, not the type of a value.
># The user would then be forced to use $?CLASS inside (this one is
> probably too much B&D)
>
>classmethod bark { ... }
># you can't get more specific than this :)
>
> Okay, thats all for now, however, be on the lookout for some other
> mails on the specifics of class method dispatch. If we are going to
> do it, we need to do it right.
How about:
method bark (Dog ::K:) { ... }
Where ::K must hold a class that is a subclass of Dog. Or 'is a
subtype of', or 'does', or whatever the most correct term is in this
context.
(I seem to recall Damian mentioning something like this on the list
somewhere, but I might have misunderstood him and made it up myself.)
I do notice, though, that most of these class-method forms don't stand
out very well--maybe something like 'classmethod' might be best after
all, particularly if class methods aren't heavily used.
Stuart
Continuing in the face of exceptions, and what's the negation of // ?
I retract my opposition to "err". After coding this:
try
{
try { path = f.getCanonicalPath(); }
catch (Exception e) { path = f.getAbsolutePath(); }
}
catch (Exception e) { path = f.toString(); }
I am now a convert. To the extent that we are going to throw exceptions,
there needs to be a quick way of huffmanizing the scaffolding.
IIRC, "use fatal" decides between an exception being thrown and an
"undef but ..." value being returned.
IMO, it's important to coerce code into the same behavior: If a sub that
I call tries to throw an exception, that needs to be converted into
undef-but-whatever, too.
One problem, of course, is drawing the line: «|die| creates a "normal"
exception»[A4] so how, if at all, can a library coder force an abort? I
suspect exit() is the only way -- there's always some guy wanting to
override everything.
So the "err" operator, or whatever, has to suppress fatal, call, check,
return:
sub infix: (Code &lhs, Code &rhs)
{
no fatal;
&lhs;
CATCH { &rhs; }
}
Producing:
my $path = $f.getCanonicalPath()
err $f.getAbsolutePath()
err $f.toString();
But using "no fatal" at the top of your code reduces this to plain old //:
no fatal;
my $path = $f.getCanonicalPath()
// $f.getAbsolutePath()
// $f.toString();
I wonder what '\\' means?
Is it the negation of //? So that:
my $x = $hash<$key> \\ die "Error: hash<$key> already defined!"
Or can we continue the breaktyping theme and grab it for fatal-suppression?
Alternatively, of course, there's always /// or //! -- probably one of
these is best, extending the theme of the "if undef" to include "if
undef (and exception is very undef!)".
At any rate, count me in for suppressing errors inline -- also for
tarring and feathering the guy who put that kind of crap in the Java
standard library.
=Austin
Custom Metaclass and Inheritance of Class Methods
Hey All, So, given the abundance of positive responses ;) for my "class methods don't inherit" proposal, I have decided to withdraw that proposal (see my last response on the thread). Of course, this means we now have to work out the details of exactly *how* they get inherited in all situations. The trickiest one being in the presence of custom metaclasses. So, onto the questions. (NOTE: if you get bored about half-way through this mail (and you probably will), there is a conculsion/wrap-up at the very bottom that you can probably safely skip ahead too) Should custom metaclasses are "inherited" along "normal" subclass lines? This would mean that if Foo uses CustomMeta as it's metaclass, any subclass of Foo will do the same. This is something Larry mentioned, and something I had been thinking about a lot myself and discussed recently with Rob Kinyon. I drew a diagram in my response to Larry that looked like this: Class ^ : CustomMeta ^ : eFoo<...eBar ^ ^ | | Foo<...Bar This shows the structure which would be created. The result is that method dispatch would go like this: Bar.foo eBar.get_method(foo) eFoo.get_method(foo) CustomMeta.get_method(foo) Class.get_method(foo) ! No Method Found Error ! I think this makes sense in many ways since CustomMeta can theoretically add capabilities to the Foo class, which one would want inherited by subclasses of Foo. (NOTE: if CustomMeta adds instance methods to Foo, they will get inherited, mostly I am talking about class functionality here) However, I can also see where it would make sense for this *not* to behave this way. But if we the opposite approach, the eigenclass/ metaclass hierarchy begins to get more complex. To start with, we would need to create another anon-class (called xFoo here) which uses multiple inheritence to inherit from eFoo and CustomMeta, then eBar would inherit from eFoo (and through eFoo, to Class), this would keep CustomMeta out of Bar's method dispatch path. Class ^^... : : CustomMeta : ^ : : : xFoo...>eFoo<...eBar ^ ^ | | FooeFoo xBar>eBar ^ ^ ^: | :.|: | | Foo<..Bar The method dispatch path for this is pretty much the same as above, with the addition of CustomMeta2. This example now actually brings up another issue. What should the superclass ordering be within the x* classes? If eBar comes first, followed by CustomMeta2, then we get the following method dispatch path: Bar.foo xBar.has_method(foo) # xBar should never have any of it's own method eBar.has_method(foo) eFoo.has_method(foo) CustomMeta2.has_method(foo) # this would fall here under C3 Class.has_method(foo) ! Method Not Found Error ! But if CustomMeta2 comes first, followed by eBar, then we get the following method dispatch path: Bar.foo xBar.has_method(foo) CustomMeta2.has_method(foo) eBar.has_method(foo) eFoo.has_method(foo) Class.has_method(foo) ! Method Not Found Error ! The question really is, which has precedence, the custom metaclass, or the local class methods (including class methods inherited along "normal" class lines)? Now, all these method dispatch paths are using the C3 MRO. And personally I find neither of these approaches to be the best. One alternate (but kind of whacky) approach would be to not use C3 here, but instead use breath-first traversal. Now, this may seem really odd at first, but given the highly regular structure of these class groupings, it might make the most sense. Here is what that method dispatch path might look like: Bar.foo xBar.has_method(foo) eBar.has_method(foo) CustomMeta2.has_method(foo) eFoo.has_method(foo) Class.has_method(foo) ! Method Not Found Error ! Notice how the eBar (which hold's Bar's class methods) is first, followed by the CustomMeta2 class, the followed by eFoo, then onto Class. This specialized dispatching beha
Re: [P6L] Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On Thu, 2005-10-13 at 18:36 -0700, Chip Salzenberg wrote: > On Thu, Oct 13, 2005 at 06:13:09PM -0700, chromatic wrote: > > I just don't want people who merely write a module or class to be > > able to prevent people who actually use that module or class from > > using, extending, or poking around in it. > Sounds kind of like Linus's opinion of close-source modules. If they > exist and work, he's not going to break them, but he's not going to do > *anything* to specially support them. I mostly agree, but I'm not talking about the *license* of the code. I don't think that's clear to everyone reading this thread, so I think I should clarify. Regardless of the license, the author of a class or module should not be able to close off that class or module from people using that class or module who want to poke around in its guts at runtime, regardless of the license or availability of the source code. Allowing authors to say "This is my namespace and you cannot touch it" or "This is my class and you cannot touch it or derive from it or decorate it or apply roles to it" is silly, because they'll do stupid and wrong things that the rest of the world will have to work around forever, regardless of the license of their code. By all means write efficient code and well-encapsulated code and document your interfaces and intentions appropriately, but if you want to write generic and reusable code, don't "optimize" for situations which you can't possibly have profiled because no one has written the code for them yet. We should not encourage that. -- c
Re: Thoughs on Theory.pm
On 10/13/05, Dave Whipp <[EMAIL PROTECTED]> wrote:
> I started thinking about the "in general, unverifiable programmatically"
> bit. While obviously true, perhaps we can get closer than just leaving
> them as comments. It should be possible to associate a
> unit-test-generator with the theory, so I can say:
>
> theory Ring(::R) {
> ...
> axiom associative(R ($a, $b, $b)) {
> is_true( ((a+b)+c) - (a+(b+c)) eqv R(0) );
> }
> ...
> }
>
> And then say "for type T, please generate 1000 random tests of T using
> axioms of Ring".
The points about hand-crafted edge-case tests are good, but that's not
to say that this isn't a good idea. Putting the properties inline
with the theory is good documentation (plus, as you say, it could be
used to generate pre- and postconditions).
By the way, Haskell already did this.
http://www.haskell.org/ghc/docs/latest/html/libraries/QuickCheck/Test.QuickCheck.html
:-)
Luke
