Re: Punie
On Jul 11, 2005, at 21:41, Autrijus Tang wrote: Cool! However, I wonder if Punie is indeed targetting Perl 1. As Schwern will attest, Perl 1 is a quite complicated language, with nullary, unary, binary and ternary functions, arrays, hashes, pattern matches, transliteration, format, loop control and labels. As a test case for the Parrot compiler tools, those are certainly useful features to implement. We'll have to deal with them in more serious languages anyway. But, we'll see. I'm not promising it'll be an exact match to Perl 1 semantics, but I'd like to push it as close to supporting the full Perl 1 test suite as possible. Is it Punie's goal to support all of those semantic constructs? If not, maybe call it something else than Perl 1, to avoid confusion? :) How about Punie? :) Allison
Re: Punie
On Mon, Jul 11, 2005 at 11:43:55PM -0700, Allison Randal wrote: As Schwern will attest, Perl 1 is a quite complicated language, with nullary, unary, binary and ternary functions, arrays, hashes, pattern matches, transliteration, format, loop control and labels. As a test case for the Parrot compiler tools, those are certainly useful features to implement. We'll have to deal with them in more serious languages anyway. But, we'll see. I'm not promising it'll be an exact match to Perl 1 semantics, but I'd like to push it as close to supporting the full Perl 1 test suite as possible. That's cool. In that case I'll commit the test suite from perl-1.0_16 as TODO tests to the Punie tree, if that's okay with you. :) Thanks, /Autrijus/ pgp0crWgZaONS.pgp Description: PGP signature
Re: Possible bug calculating dominators
On 7/5/05, Leopold Toetsch [EMAIL PROTECTED] wrote: On Jul 5, 2005, at 8:50, Curtis Rawls wrote: I seem to have come across a bug in the compute_dominators() algorithm with the following PIR: It's not unlikely that there are bugs in that part of imcc. It was contributed by Angel Faus, who seems to be not participating in Parrot dev anymore. Some times ago, I was pondering some tests for CFG-related items, but no one (including me) seems to have the tuits to attack it. Yes, I'm running into a lot of areas of the CFG/optimizer that I would like to modify, and some CFG tests would be great to help avoid introducing new bugs. Basically just checking the cfg and dominator dump outputs for correctness. I have looked at the tests in t/ and imcc/t/, but have not found a way to test the compiler debug output. Any suggestions? Also, I am working on some new (and hopefully more correct) implementations of some of the CFG algorithms, such as compute_dominators(). I would appreciate having someone to run these by. Any takers? -Curtis
Re: DBI v2 - The Plan and How You Can Help
RE: Placeholders: since DBIv1 already supports both forms of PH's, I see no reason to deprecate or abandon either form. Furthermore, to my knowledge, none of (ODBC, JDBC, ADO.NET) has abandonded or deprecated the ? form, so I don't see the need for DBI to. RE: LOBs and SQL Parse Trees: having recently implemented LOB support for a JDBC driver (and soon for a DBD), I can assure you that SQL parse trees are unneeded to support them. For databases robust enough to support LOBs, they'll almost always provide sufficient metadata info and/or SQL syntax to manipulate them; only databases which don't support LOBs have that difficulty. Furthermore, a quick review of the current DBI will indicate that Mssr. Bunce has already implemented some stub methods for generalized support. RE: SQL Parse Trees (or other non-SQL query input) Since none of (ODBC, JDBC, ADO.NET) seems compelled to impose this concept on driver writers, I don't see why DBI should be the vanguard. However, implementing a subclass of DBI to support it seems technically feasible, so I'd suggest that those of you championing this requirement implement one on DBI v1. Feel free to use DBIx::Chart to bootstrap your project. As the proponents of this notion are so generous with their requirements for those of us who develop DBI drivers and/or contribute development efforts to the DBI itself, I'm sure they won't object if I provide a few requirements: 1. For DBI drivers which support them, your subclass must support - arbitrary numbers and levels of JOINs (including various outer, and non-equijoins) - arbitrarily nested subqueries (including correlated) - HAVING and GROUP BY clauses - ORDER and LIMIT clauses - updatable cursors - database-specific SQL extensions 2. It must function with current versions of 40% of DBD's created or updated on CPAN since Jan. 1, 2003. Said 40% must include - DBD::ODBC - DBD::Oracle - DBD::Pg - DBD::MySQL - DBD::CSV - one 'exotic' driver (e.g., DBD::iPod or DBD::Amazon, but excluding DBD::Google, whose syntax is too simplistic for a meaningful test) (FWIW: Past experience (e.g., execute_array()) leads me to believe Mssr. Bunce's requirements are likely much higher than 40%, so choose wisely, grasshopper) BTW: If you need a list of DBD's meeting said requirement, let me know, I just pulled one down. 3. It cannot require any changes to either DBI or the selected DBD's. 4. It must produce a database-independent conforming set of error codes (feel free to use SQLSTATE aka $h-state) 5. It must be uploaded to CPAN, and list, and demonstrably function against, the DBD's selected in requirement (2) above. Once you've implemented the subclass, you'll have empirical proof of the feasibility, and, more importantly, you'll be able to port the subclass to DBIv2, without any additional burden on DBI developers. Regards, Dean Arnold Presicient Corp.
Re: User-defined infix subs/methods?
On Sat, Jul 09, 2005 at 03:58:45PM -0700, Larry Wall wrote: It should take a little more effort to mess with the minds of unsuspecting modules, so maybe the standard syntax is cloned out of *STANDARD_PERL_6 or some such scary package name. It's the default for starting all require-like Perl 6 parses. Note that this requirement is already satisfied, under the separate compilation doctrine in the hackathon notes. Each compilation unit needs to be compiled without any information to the symbols in the caller environment. It may export symbols, but may not silently make use of caller's symbols, which naturally includes user-defined operators. Thanks, /Autrijus/ pgp65NisqOEgX.pgp Description: PGP signature
Raw bytes in perl6
How do we intend to manipulate raw binary in Perl6? Perl5's use
bytes; pragma is rather poor (forcing all strings to be raw in its
scope or requiring do {use bytes; ...} type tricks to deal with them)
and now Perl6 has real typing perhaps it would be more usefull to have
a bytestring type (or and octect string type) that doesn't get
utf8ed.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
Re: DBI v2 - The Plan and How You Can Help
BTW: If you need a list of DBD's meeting said requirement, let me know, I just pulled one down. Sure, send it over. [ ] DBD-ADO-2.94.tar.gz 31-Jan-2005 02:4041k GZIP compressed docume [ ] DBD-ASAny-1.13.tar.gz 31-Oct-2003 15:0030k GZIP compressed docume [ ] DBD-Amazon-0.10.tar.gz 23-May-2005 15:4158k GZIP compressed docume [ ] DBD-AnyData-0.08.tar.gz 19-Apr-2004 03:1620k GZIP compressed docume [ ] DBD-CSV-0.22.tar.gz 31-Mar-2005 18:0636k GZIP compressed docume [ ] DBD-Chart-0.81.tar.gz 26-Jan-2005 19:59 212k GZIP compressed docume [ ] DBD-DB2-0.78.tar.gz 19-Sep-2004 10:3475k GZIP compressed docume [ ] DBD-File-0.34.tar.gz21-Jun-2005 01:14 8k GZIP compressed docume [ ] DBD-Google-0.11.tar.gz 04-Mar-2004 18:5120k GZIP compressed docume [ ] DBD-Informix-2005.01.. 14-Mar-2005 19:01 267k GZIP compressed docume [ ] DBD-Ingres-0.51.tar.gz 12-Jan-2004 06:1846k GZIP compressed docume [ ] DBD-InterBase-0.43.t.. 25-Feb-2004 04:3078k GZIP compressed docume [ ] DBD-LDAP-0.06.tar.gz12-Mar-2004 21:4825k GZIP compressed docume [ ] DBD-Log-0.22.tar.gz 27-May-2005 06:5114k GZIP compressed docume [ ] DBD-MaxDB-7_5_00_26... 18-Apr-2005 08:3879k GZIP compressed docume [ ] DBD-Mimer-1.00.tar.gz 25-Nov-2003 15:5171k GZIP compressed docume [ ] DBD-Mock-0.27.tar.gz11-Jul-2005 11:3634k GZIP compressed docume [ ] DBD-Multiplex-1.96.t.. 25-Jan-2005 17:30 9k GZIP compressed docume [ ] DBD-ODBC-1.13.tar.gz08-Nov-2004 10:1595k GZIP compressed docume [ ] DBD-Oracle-1.16.tar.gz 22-Oct-2004 05:17 230k GZIP compressed docume [ ] DBD-Pg-1.43.tar.gz 23-Jun-2005 08:09 128k GZIP compressed docume [ ] DBD-PgPP-0.05.readme09-May-2004 08:06 3k [ ] DBD-PgPP-0.05.tar.gz13-May-2004 12:5616k GZIP compressed docume [ ] DBD-PgSPI-0.02.tar.gz 06-Dec-2004 00:3021k GZIP compressed docume [ ] DBD-Redbase-0.22.tar.gz 21-Oct-2003 22:5128k GZIP compressed docume [ ] DBD-SQLite-1.09.tar.gz 20-Jun-2005 11:42 464k GZIP compressed docume [ ] DBD-SQLite2-0.33.tar.gz 10-Sep-2004 11:50 355k GZIP compressed docume [ ] DBD-Sprite-0.56.tar.gz 12-Jun-2005 21:5286k GZIP compressed docume [ ] DBD-Sybase-1.05.tar.gz 19-Dec-2004 05:01 183k GZIP compressed docume [ ] DBD-TSM-0.04.readme 22-Mar-2005 16:05 2k [ ] DBD-TSM-0.04.tar.gz 23-Jun-2005 16:32 9k GZIP compressed docume [ ] DBD-Teradata-1.20.ta.. 17-Sep-2004 19:2736k GZIP compressed docume [ ] DBD-Trini-0.01.tar.gz 15-Jul-2003 03:1821k GZIP compressed docume [ ] DBD-Unify-0.31.tgz 16-Mar-2004 11:0731k GZIP compressed tar ar [ ] DBD-XBase-0.241.tar.gz 21-Nov-2003 09:25 109k GZIP compressed docume [ ] DBD-Yaswi-0.01.tar.gz 21-Feb-2005 19:46 4k GZIP compressed docume [ ] DBD-iPod-0.01.tar.gz06-Jan-2005 02:4113k GZIP compressed docume [ ] DBD-mysql-3.0002.tar.gz 11-Jul-2005 12:49 127k GZIP compressed docume [ ] DBD-mysql-AutoTypes-.. 02-Mar-2004 06:03 3k GZIP compressed docume [ ] DBD-mysql-SimpleMySQ.. 28-Apr-2004 16:39 4k GZIP compressed docume [ ] DBD-mysqlPP-0.04.tar.gz 24-Jan-2003 06:14 7k GZIP compressed docume - Dean
Re: Devel::Cover Problem: testing || for a default value.
On Tue, Jul 12, 2005 at 07:45:35AM +, Smylers wrote: I can see why having 'inline' directives specifically for Devel::Cover could be seen as ugly, but if instead they are general-purpose assumptions then it's obviously better to have them next to the code that's relying on the assumption than in some other file. A good way of putting assumptions into code is with (Michael's excellent) Carp::Assert: assert $p || $q, 'Either $p or $q must be supplied' if DEBUG; That improves your code, makes it easier for other people who have to deal with it, and should be enough to keep Devel::Cover happy. While I get where you're going, I don't see how this could be made to work. What, exactly, is Devel::Cover supposed to do with those assert statements? -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
Re: Devel::Cover Problem: testing || for a default value.
Michael G Schwern writes:
my $foo = $p || $q is not boolean. I'm not even sure you can call
it pseudo-boolean without understanding the surrounding code. How
do you know that $q can never be false?
So we want some way of annotating the code which will let Devel::Cover
know that you're assuming that $p and $q won't both be false.
Devel::Cover wouldn't be the only beneficiary of having such an
assumption explicitly stated: other humans having to read the code might
appreciate it too.
I can see why having 'inline' directives specifically for Devel::Cover
could be seen as ugly, but if instead they are general-purpose
assumptions then it's obviously better to have them next to the code
that's relying on the assumption than in some other file.
A good way of putting assumptions into code is with (Michael's
excellent) Carp::Assert:
assert $p || $q, 'Either $p or $q must be supplied' if DEBUG;
That improves your code, makes it easier for other people who have to
deal with it, and should be enough to keep Devel::Cover happy.
The other examples in the ticket play out the same way:
bless {}, ref $class || $class;
$class being false would be quite the error.
Ditto, so you could make the assumption explicit with an assertion. Or
perhaps something like Params::Validate would be better.
Smylers
--
May God bless us with enough foolishness to believe that we can make a
difference in this world, so that we can do what others claim cannot be done.
Re: AnnoCPAN and a wiki POD idea
Ivan Tubert-Brohman writes: I'm happy to listen to your suggestions; AnnoCPAN is a work in progress and I'm still adding features and fixing bugs. Thanks Ivan for your work on this. I'm also considering the possibility of sending automated emails, similar to what rt.cpan.org does. However, I was still unsure about whether to do it opt-in or opt-out (or no-option ;-). Opt-out (or no-option) would irritate far too many people (not necessarily rationally, but it would). But people can only opt in if they know it exists to opt in to. Perhaps you could send one mail once, the first time each author has a note added (or as soon as the mail feature is deployed, for authors that already have notes) letting her know about the feature and inviting her to opt in to receive further notifications. Doubtless there will be some people who complain about receiving even this single mail, but it should cause less grief. There is a (yet unused) mailing list, where we could discuss AnnoCPAN in more detail if it's considered off-topic for this perl-qa. I probably don't care about AnnoCpan enough to bother to subscribe to yet another mailing list, but I'd be happy to read about it here -- or possibly on module-authors, which might be even more on-topic than this list. Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: AnnoCPAN and a wiki POD idea
On Tue, Jul 12, 2005 at 07:37:05AM +, Smylers wrote: Opt-out (or no-option) would irritate far too many people (not necessarily rationally, but it would). But people can only opt in if they know it exists to opt in to. Perhaps you could send one mail once, the first time each author has a note added (or as soon as the mail feature is deployed, for authors that already have notes) letting her know about the feature and inviting her to opt in to receive further notifications. Seconded. I suggested exactly the same thing for CPAN::Forum. http://rt.cpan.org/NoAuth/Bug.html?id=13568 -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern 'All anyone gets in a mirror is themselves,' she said. 'But what you gets in a good gumbo is everything.' -- Witches Abroad by Terry Prachett
WTF? - Re: method calls on $self
Larry Wall skribis 2005-07-11 18:29 (-0700):
is that we simply outlaw .foo notation at *compile* time in those
scopes where we know (at compile time) that $_ and $?SELF diverge.
In such a scope you *must* specify $_ or $?SELF (or equivalent).
What?
That makes having a default at all useless, it makes moving code without
breaking it impossible again, it requires a lot of extra typing with
shifted keys, it adds an arbitrary looking exception, and it is wildly
undwimmy and impractical, and thus unperlish by every definition I know.
This is, by far, the silliest solution for this problem that I have seen
proposed, because it is a combination of almost all the cons, and comes
at a time in which all the pros and cons of other solutions are already
known and discussed.
That's the default, and I'm not changing my mind ever again, at least
till next week.
I can wait till next week.
use self this;
use self self;
use self o;
use self ./;
use self ;
Any of these must be the default, and frankly I do not care much which
one it is, if that means the current non-solution goes away.
Obviously, use self is the least attractive of these, but I would
still prefer it to outlawing .foo.
If the default isn't sane, the language isn't sane. That there is a
pragma to change things, should never be a reason to stop picking good
defaults.
Yes, this is possibly a hazard for cut-n-pasters. But then,
you weren't supposed to be cutting-n-pasting anymore, were you?
No, but I do refactor. I do add loops and methods around existing code.
I do use for (or given in p6) to topicalize, to be able to type LESS.
In Perl 5, I really hate
for ($object) {
$_-method(...);
$_-method(...);
$_-method(...);
}
And the Perl 6 equivalent until your revelation,
given $object {
.method(...);
.method(...);
.method(...);
}
was the perfect solution. Killing off a useful and much used idiom even
before the first release is quite an accomplishment.
Disallowing .method here means a huge step back in time. Back to
$_.method or $object.method.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: WTF? - Re: method calls on $self
I feel a me too post is in order.
I've written code that is 2-3 levels of nested given/when in a
method of an object that wasn't the topic.
I did not feel confused at all, juggling .foo and ./foo, which are
visually distinct, and different to type. They convey a big
difference of meaning, even if it's only 1 char apart.
I think a solution to the problem of being able to use those two
well, is not a solution, because there isn't a problem.
On Tue, Jul 12, 2005 at 12:59:22 +0200, Juerd wrote:
Larry Wall skribis 2005-07-11 18:29 (-0700):
is that we simply outlaw .foo notation at *compile* time in those
scopes where we know (at compile time) that $_ and $?SELF diverge.
In such a scope you *must* specify $_ or $?SELF (or equivalent).
What?
That makes having a default at all useless, it makes moving code without
breaking it impossible again, it requires a lot of extra typing with
shifted keys, it adds an arbitrary looking exception, and it is wildly
undwimmy and impractical, and thus unperlish by every definition I know.
This is, by far, the silliest solution for this problem that I have seen
proposed, because it is a combination of almost all the cons, and comes
at a time in which all the pros and cons of other solutions are already
known and discussed.
That's the default, and I'm not changing my mind ever again, at least
till next week.
I can wait till next week.
use self this;
use self self;
use self o;
use self ./;
use self ;
Any of these must be the default, and frankly I do not care much which
one it is, if that means the current non-solution goes away.
Obviously, use self is the least attractive of these, but I would
still prefer it to outlawing .foo.
If the default isn't sane, the language isn't sane. That there is a
pragma to change things, should never be a reason to stop picking good
defaults.
Yes, this is possibly a hazard for cut-n-pasters. But then,
you weren't supposed to be cutting-n-pasting anymore, were you?
No, but I do refactor. I do add loops and methods around existing code.
I do use for (or given in p6) to topicalize, to be able to type LESS.
In Perl 5, I really hate
for ($object) {
$_-method(...);
$_-method(...);
$_-method(...);
}
And the Perl 6 equivalent until your revelation,
given $object {
.method(...);
.method(...);
.method(...);
}
was the perfect solution. Killing off a useful and much used idiom even
before the first release is quite an accomplishment.
Disallowing .method here means a huge step back in time. Back to
$_.method or $object.method.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: uhm, no, I think I'll sit this one out..: neeyah!
pgpXVD4JFgqKt.pgp
Description: PGP signature
Re: WTF? - Re: method calls on $self
On 7/12/05, Juerd [EMAIL PROTECTED] wrote: [snip] Disallowing .method here means a huge step back in time. Back to $_.method or $object.method. [snip] I agree with what is being said here. `.method` is a great way to eliminate a lot of repetitive, tedious typing. Surely there is a viable alternative that doesn't involve outlawing it? Aankhen
Re: Test::Cmd -- Recommended?
Ian Langworth wrote: On 7/8/05, James E Keenan [EMAIL PROTECTED] wrote: One other curiosum: As a result of my Phalanx work, I've gotten in the habit of using File::Temp to create 'anonymous' directories and files in which to conduct testing. This is one of the many features of Test::Cmd, which I a was about to recommend. However, I remember being discouraged from using it, but I'm not sure from where or whom. Does anyone use Test::Cmd? Are there features in it that you like? Is it overcomplicated? Should it be updated to use Test::Builder? Do these pants make my butt look big? I use it daily (well, tests that I've written using it get run daily, which is almost the same thing). I quite like it, it certainly let me get the job done. Looking through it now I think it might benefit from being pared down a little. The match* and diff* methods could probably be removed in favour of functionality in Test::More or Test::Diff, and merging in the functionality from Test::Expect would probably be useful. N
What do use and require evaluate to?
Hi,
what do use and require evaluate to?
S06 suggests it's probably some kind of Module object:
The result of a use statement is a (compile-time) object that also has
an .assuming method, allowing the user to bind parameters in all the
module's subroutines/methods/etc. simultaneously:
(use IO::Logging).assuming(logfile = .log)
We could make (use Foo) evaluate to the class object Foo,
allowing:
my $foo = (use Foo).new(...);
Alternatively, we could go the Perl 5 way and return the
last thing evaluated in Foo.pm (which might be a Module
object, assuming that module Foo {...} evaluates to Foo).
What do successive uses of use and require evaluate to?
Perl 5 is inconsistent:
$ cat Foo.pm
package Foo; 42;
$ perl -we 'warn require Foo; warn require Foo'
42 at -e line 1.
1 at -e line 1.
I'd like Perl 6's use and require to return the same thing.
In Perl 5, %INC maps the partial path names of the modules
loaded to their absolute ones. What should the keys and values
of %*INC be in Perl 6?
--Ingo
--
Linux, the choice of a GNU | self-reference, n. - See self-reference
generation on a dual AMD |
Athlon!|
Re: Punie
Allison Randal wrote:
I'd like to add Punie to the Parrot repository.
Great. And for more fun I've created the basics of a NCI interface [1]
for ast functions. Heavily underdocumented and unfinished (as of an hour
hacking time ;-), but maybe someone takes it over and continues it. It
needs trunk rev 8598 for some added NCI signatures in src/call_list.txt.
It needs probably also a split into a Past and Node classes.
Compiling the resulting top node is also missing, but it should be quite
simple to either call the ast compile / emit functions with NCI or
create a better interface for that (I didn't look yet).
PS due to upcoming changes in parrot opcodes, you might avoid the
'compile' opcode. Instead:
compi = compreg 'PIR'
prog = compile compi, 'the_code'
the future is:
prog = compi('the_code')
i.e. just invoke the compiler.
Thanks,
Allison
leo
[1]
$ tar -tzf libpast.tar.gz
ast.pir
libpast.pir
$ tar -xzf libpast.tar.gz
$ ./parrot ast.pir
libast loaded
open_unit ok
Py_Module(
Py_Print(
Const(hello
n)))
done
libpast.tar.gz
Description: application/gzip
Re: Punie
Leopold Toetsch wrote: needs trunk rev 8598 for some added NCI signatures in src/call_list.txt. or branches/leo-ctx5 r8599. leo
Re: Devel::Cover Problem: testing || for a default value.
David Golden wrote: I think this is a coverage vs correctness distinction. The idea that I was trying to convey is that while these expressions use a boolean operator for a shortcut, they aren't really about truth vs. falsity of the overall expression, *except* when they are being used as part of a conditional statement. From a coverage perspective, what should matter in my $foo = $p || $q is that $foo takes on the values of both $p and $q at some point during the test suite, not whether or not $foo takes on both true and false values -- coverage of that condition should be checked when $foo is used in another expression. I respectfully disagree. I think you're focusing too much on the low-level behavior of || returning one of its operands. That behavior makes Perl's syntax flexible and a little ambiguous. Because Perl doesn't make a distinction between assign with a default value and perform a boolean OR Devel::Cover it has to play it conservatively. You shouldn't shift the burden to somewhere else (where $foo is subsequently used) either, because you don't know how it will be used. It could be 1) a boolean in a condition 2) used in another $a = $b || $c type expression 3) an output that only appears in a print() statement ... In any of these cases, it's possible that $foo is really a boolean but by the method you proposed $foo would only be tested for taking both true and false values in the first one. Regardless, if that subsequent expression doesn't get full coverage the user is forced to trace the error back to where $foo was set -- something Devel::Cover could have done for them. (And more challenging if $foo is set in multiple places.) The moral of the story is that only the author knows exactly what my $foo = $p || $q means. It should be up to the author to analyze it accordingly. -mjc
Re: MML dispatch
On 2005-07-11 23:46, Damian Conway [EMAIL PROTECTED] wrote: 3. Work out the Manhattan distance from the argument list to each variant's parameter list. OK, sorry if I missed this in an earlier discussion. For purposes of calculating this Manhattan distance, I gather that we're treating lists of N arguments/parameters as points in N-space. I further assume that the monoaxial distance between a parameter coördinate and the corresponding argument coördinate - the distance between two types, where the types are known to be assignment-compatible - is the number of inheritance steps between them? And one more dumb question: why is it that the L[1] metric is superior to the L[2] metric for this purpose?
Re: Devel::Cover Problem: testing || for a default value.
On Monday 11 July 2005 23:17, Michael G Schwern wrote: On Mon, Jul 11, 2005 at 07:38:57PM +0300, Yuval Kogman wrote: So what should I do to eliminate it? Maybe Just Nothing The issue is that you can't special case get_current_coords to be truish, as far as Devel::Cover is concerned - it might not be. Any fix that could be thought up is inherently problematic. Coverage reporting is not done for the pretty colors - a human reads it, and says OK, this is logical, get_current_coords always returns a true value. It's not a race for greens and percentages. While I agree coverage is not a race, I disagree that a human should have to disambiguate between real missing coverage and a false negative. At least not more than once. I'll make the same argument no broken windows argument here that I do about warnings and tests: elminate all warnings, even if they are dubious. Ensure all tests pass eliminating all false negatives. Do not leave any expected warnings or expected failures because this erodes the confidence in the test suite. Warnings and test failures fail to ring alarm bells. One expected warning leads to two. Then four. Then finally too many to remember which are expected and which are not and you ignore them all together. I fully agree with you. The purpose of the test coverage's main report page is to let me know if I missed anything. And I want to make sure that I missed nothing. Not to go over the problems one by one and see which one is a false positive and which one isn't. I wanted to say something similar along this line before your comment, but you said it much better. :-) Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Tcl is LISP on drugs. Using strings instead of S-expressions for closures is Evil with one of those gigantic E's you can find at the beginning of paragraphs.
Re: MML dispatch
Mark Reed wrote: And one more dumb question: why is it that the L[1] metric is superior to the L[2] metric for this purpose? I am also interested in the rational behind the approach to manage MMD my means of a metric instead of a partial order on the types. Metric is a geometric concept which in my eyes doesn't fit type theory. I would join Luke and recommend 'pure' MMD. That is there has to be exactly one target that is most specific on all positions relevant for the dispatch. In particular do I dislike the the property of a metric that several smaller mismatches can be compensated by a good match. -- TSa (Thomas Sandlaß)
Re: MML dispatch
Damian Conway wrote:
This is a much less dwimmy solution than Yuval's or Luke's, but it has the
advantage that those eight steps reduce to eight words:
Unique least-inherited most-specialized match, or default
Do I read this correctly as dispatching partly in the class hierarchy
and partly in the type hierarchy? Or do you mean with 'least-inherited'
most specific non-where type and with 'most-specialized' the strictest
where clause? To me these two concepts are the same if you think of the
does operator as a predicate:
multi sub foo ($x where { $x.does(Num) }) {...}
beeing the same as
multi sub foo (Num $x) {...}
--
TSa (Thomas Sandlaß)
Re: How to write a self.pm (Re: method calls on $self)
Autrijus Tang wrote:
The compiler, in turn inspect whether there's an bound $_ in scope
with $?SELF set. It is not trivial, because this should work:
sub baz (c) { c() }
method foo { baz { .bar } } # $_ is free in inner closure
But this needs to fail:
sub baz (c) { c(1) }
method foo { baz { .bar } } # $_ is bound in inner closure
I might still not understand topic, $_ or lexical vars in general.
But why does the fact that c is called with a parameter
in the second case and without one in the first example make a
difference? Isn't $_ always coming in out of band? So .bar is always
invoked on the invocant of foo if we think that there is an implicit
$_ := $?SELF before the call to baz in foo. And I hope the binding
of $_ to $?SELF is a read-only binding!
--
TSa (Thomas Sandlaß)
Re: MML dispatch
On 2005-07-12 12:22, TSa (Thomas Sandlaß) [EMAIL PROTECTED] wrote: I am also interested in the rationale behind the approach to manage MMD my means of a metric instead of a partial order on the types. Metric is a geometric concept which in my eyes doesn't fit type theory. The geometric interpretation does bring us into somewhat philosophical territory. Not that that's anything new on this list. :) Let me try a concrete example. Suppose that class Answer has subclasses Animal, Vegetable, and Mineral, with respective subclasses Dog, Potato, and Diamond. There are two methods named foo in scope, neither overriding the other. One is declared to take (Animal, Vegetable, Mineral), the other (Dog, Potato, Answer). Assuming the obvious memberships, which method should foo(Snoopy, Mr_PotatoHead, HopeDiamond) call? And more importantly, why do you feel that is the right answer? According to Damian's metric, we have distances of 0+0+2=2 and 1+1+1=3, so (Dog, Potato, Answer) is closer and would get called.
Re: What do use and require evaluate to?
On Tue, Jul 12, 2005 at 12:15:30PM +, Ingo Blechschmidt wrote:
In Perl 5, %INC maps the partial path names of the modules
loaded to their absolute ones. What should the keys and values
of %*INC be in Perl 6?
Conceptually, the Perl 5 %INC maps from what to which. It also imposes
a coupling with the filesystem which makes things like require $module
awkward. The hook mechanism in values breaks consistency, unless you
think of string values as shorthand for sub { slurp path }.
I propose to throw away the filesystem coupling, and map from a more
general name of the bit of code we are requiring to a more general
description of which instance of it we actually got. Once modules return
interesting values, it might be useful to keep a copy of that value
somewhere on the value side of %*INC: or else turn it inside out and
stipulate that a standard field in the Module object is where you got
this particular module. Probably, %*INC values should be weak references.
On the key side, I think we should allow more than just strings.
`use Bar` and `require Bar` invoke the module loader on a
ModuleName.new(Bar). Passing a straight string performs this promotion
automatically. Path separators and '.pm' need never seen outside the
module loader. You can also ask to use/require a File or a URI, but
those requests are only honored if you have appropriate entries in the
module search path. In the case of URIs we could allow, for example,
only modules from a particular domain or even under a particular path.
Examples:
%*INC = (
# weak references
ModuleName.new(Bar) = Module.new(name= Bar,
version = 0.0.7,
author = BarCom,
path= /usr/lib/perl6/Bar.pm,
loaded_classes =
(::Bar, ::Bar::Internals),
),
URI.new(http://codeIZus.com/perl/randommodule.cgi;) =
Module.new(name= Acme::emcA, ...),
$an_open_file = ...
);
@*INC = (/usr/local/lib/perl6,
URI.new(http://codeIZus.com/perl/;),
URI.new(http://;), # this would mean allow loading code from ANYWHERE.
);
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: MML dispatch
Mark Reed wrote: On 2005-07-12 12:22, TSa (Thomas Sandlaß) [EMAIL PROTECTED] wrote: I am also interested in the rationale behind the approach to manage MMD my means of a metric instead of a partial order on the types. Metric is a geometric concept which in my eyes doesn't fit type theory. The geometric interpretation does bring us into somewhat philosophical territory. Not that that's anything new on this list. :) Let me try a concrete example. Suppose that class Answer has subclasses Animal, Vegetable, and Mineral, with respective subclasses Dog, Potato, and Diamond. There are two methods named foo in scope, neither overriding the other. One is declared to take (Animal, Vegetable, Mineral), the other (Dog, Potato, Answer). Assuming the obvious memberships, which method should foo(Snoopy, Mr_PotatoHead, HopeDiamond) call? And more importantly, why do you feel that is the right answer? According to Damian's metric, we have distances of 0+0+2=2 and 1+1+1=3, so (Dog, Potato, Answer) is closer and would get called. Uhh, both targets are applicable but none is more specific on all positions. I would like this to be an ambiguous dispatch error. Actually it's a pitty, that the multi method call syntax isn't as rich as the single method call syntax where we have .?method, .+method and .*method. Something like (Snoopy, Mr_PotatoHead, HopeDiamond).*foo doesn't exist, right? Or is it foo.*(Snoopy, Mr_PotatoHead, HopeDiamond)? -- TSa (Thomas Sandlaß)
[perl #36520] TODO: Steal Good Ideas from Dan
# New Ticket Created by Will Coleda # Please include the string: [perl #36520] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36520 Someone should go through Dan's blog and convert all the ideas (esp. from the WCB series of posts) into TODOs in RT, putting them in a place where our fearless leader can accept them or reject them.
Re: Punie
Autrijus Tang schrieb: If the goal is to demonstrate the capability of the upcoming expression parser and minimal AST, I think bc, the arbitrary precision calculator language, is a good candidate. Indeed it is. The nice thing about 'bc' is that is fairly simple, but still has variables and subroutines. It might also be a neat test case for a future BigNum PMC, as the specs that it must support multi precission decimal coded numbers. For my humble efforts, I'm just trying to make the step from evaluationg '1+1' to evaluating '1+1+1'. Anybody knows about a bc test suite? CU, Bernhard
Re: Punie
On Jul 12, 2005, at 0:37, Autrijus Tang wrote: That's cool. In that case I'll commit the test suite from perl-1.0_16 as TODO tests to the Punie tree, if that's okay with you. :) Most welcome. I'm following a naming convention in the t/ directory of changing the original io.print-style file names to io_print.t, to make it easier to see the correspondence between the Perl 1 and Punie tests. Of course, the ultimate test will eventually be running the Perl 1 test suite as-is, without pre-digesting it into Parrot::Test calls. :) Allison
Re: MML dispatch
On Tue, Jul 12, 2005 at 08:13:22PM +0200, TSa (Thomas Sandlaß) wrote: : Actually it's a pitty, that the multi method call syntax isn't as : rich as the single method call syntax where we have .?method, .+method : and .*method. Something like (Snoopy, Mr_PotatoHead, HopeDiamond).*foo : doesn't exist, right? Or is it foo.*(Snoopy, Mr_PotatoHead, HopeDiamond)? It doesn't seem to make much practical sense. Multimethods are generally written to be exclusive of ancestral methods. Ordinary methods are generally written to be cumulative with ancestral methods. Larry
Re: What do use and require evaluate to?
On Tue, Jul 12, 2005 at 12:15:30PM +, Ingo Blechschmidt wrote:
: Hi,
:
: what do use and require evaluate to?
:
: S06 suggests it's probably some kind of Module object:
: The result of a use statement is a (compile-time) object that also has
: an .assuming method, allowing the user to bind parameters in all the
: module's subroutines/methods/etc. simultaneously:
:
: (use IO::Logging).assuming(logfile = .log)
:
: We could make (use Foo) evaluate to the class object Foo,
: allowing:
:
: my $foo = (use Foo).new(...);
I don't think it's wise to presume a magical binding between the package
name and the file name in this case.
: Alternatively, we could go the Perl 5 way and return the
: last thing evaluated in Foo.pm (which might be a Module
: object, assuming that module Foo {...} evaluates to Foo).
That works for me. I would note that when you say
module Foo;
...
it is equivalent to
module Foo {
...
}
so the first form does in fact return the module as the last (and only)
statement in the file. Presumbaly one can override this with an
explicit return.
: What do successive uses of use and require evaluate to?
: Perl 5 is inconsistent:
:
: $ cat Foo.pm
: package Foo; 42;
: $ perl -we 'warn require Foo; warn require Foo'
: 42 at -e line 1.
: 1 at -e line 1.
:
: I'd like Perl 6's use and require to return the same thing.
They will. It'll be the last thing, as defined above to usually
mean the whole thing. In the case of separate compilation this
may actually be a proxy or stub for the module or class that is just
smart enough to manage the interface to the module/class without
necessarily knowing the implementation. (This does imply that
used modules must be compiled no later than use time, since we
can't know what the module exports without compiling it.)
: In Perl 5, %INC maps the partial path names of the modules
: loaded to their absolute ones. What should the keys and values
: of %*INC be in Perl 6?
It's not clear that Perl 6 will use the same search strategy for
modules, so there may not even be a %INC, or if there is, there's no
guarantee what the keys and values will really be. This has not yet
been specified. But searching a path of directories is certainly
one thing that slows down Perl 5 startup times. Whether or not the
Perl 6 library system is implemented using a database or flat files,
the search for a module matching various criteria will likely be in
some kind of index rather than doing probes on the bare filesystem.
There might well be a %INC, but its value might well be that very
package and/or proxy object we were discussing above, and what file
it came from might just be part of its metadata. Also, if the key
of %INC is the short name of a module, than it really has to be
kept per lexical scope, since different lexical scopes are allowed
to have different mappings from short names to long, so that we
can have dependencies on two different versions of the same module
simultaneously (to the extent allowed by shared resources).
In short, Perl 5 code that assumes too much knowledge about %INC
will have to be recoded to work under Perl 6.
Larry
Re: Raw bytes in perl6
On Tue, Jul 12, 2005 at 04:53:49AM -, David Formosa (aka ? the Platypus)
wrote:
: How do we intend to manipulate raw binary in Perl6? Perl5's use
: bytes; pragma is rather poor (forcing all strings to be raw in its
: scope or requiring do {use bytes; ...} type tricks to deal with them)
: and now Perl6 has real typing perhaps it would be more usefull to have
: a bytestring type (or and octect string type) that doesn't get
: utf8ed.
I've said that string types will be allowed to specify a minimum and
maximum abstraction level. Byte strings merely specify a maximum
abstraction level of bytes, and then any code that looks at it as
codepoints, graphemes, or characters will only see values in the
range of 0..255, and any attempt to store a character larger than
255 into such a string will fail.
On the other extreme we can have abstract string types that encapsulate
their representation, so that you're allowed to deal with them as
graphemes or characters, but not get at their true representation,
so you can't tell whether they're stored in UTF-8, UTF-32, UTF-EBCDIC,
ASN.1, ISO-2022-jp, or Morse Code.
As for naming string types, perhaps the main Str type can be parameterized.
my ::bitstr ::= Str of bit;
my ::bytestr ::= Str of uint8;
my ::codestr ::= Str of Code;
On the other hand, if the basic Str type is unwilling to take on the
burden of being parameterized, we could generate all our funny string
types by mapping a string name to an array declaration.
my Str $foo is Array of byte;
or some such. But maybe we can make Str of byte mean that by way
of shorthand.
Larry
Need to talk to an EU patent attorney
Barbie's journal, via Ovid, made me aware of patent EP1170667 Software Package Verification granted last month in the EU. http://gauss.ffii.org/PatentView/EP1170667 It appears to patent basic software testing frameworks. There is a nine month window to oppose this patent. I believe Test::Harness constitutes prior art but IANAL. I would like to speak with a lawyer. Does anyone happen to know an EU patent attorney who is willing to do a little pro bono work? At this point I only want an educated reading of the patent to determine if Test::Harness may be prior art. I've contacted the EFF's staff attorney about this but he's not familiar with EU patent laws and recommended I find someone who is. I've also attempted to contact the Inventors listed on the patent (valid email addresses are difficult to find these days) in the hopes of discussing this programmer-to-programmer and cut through the legal BS. Haven't heard back yet. Here is my figuring on how Test::Harness is prior art: It includes the control (Test::Harness), framework (Test.pm, Test::More, etc..) and modules (*.t files) as outlined in claim 1. It can handle many test files (claim 2). It has the ability to order the execution of test files based on the filename which serves as a priority (claims 3 and 4). It has means to indicate if a given module is active or inactive (claim 5, 6 and 7) by the module issuing a skip flag. http://search.cpan.org/dist/Test-Harness/lib/Test/Harness/TAP.pod#Skipping_tests Test modules are typically stored as individual files, usually ending in .t, in a directory, usually t/ (claim 8). Test::Harness can be told the order in which tests are to be run. MakeMaker specifically runs test files in alphabetical order by filename (claims 9, 10, 11, 12). Test::Harness only recently added support for non-file based testing but JUnit and the Smalltalk testing frameworks handle tests in software objects (claim 13). The rest of the claims appear to repeat 1-13 in legalese. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
Re: User-defined infix subs/methods?
On Tue, Jul 12, 2005 at 05:27:48PM +0800, Autrijus Tang wrote: : On Sat, Jul 09, 2005 at 03:58:45PM -0700, Larry Wall wrote: : It should take a little more effort to mess with the minds of : unsuspecting modules, so maybe the standard syntax is cloned out of : *STANDARD_PERL_6 or some such scary package name. It's the default for : starting all require-like Perl 6 parses. : : Note that this requirement is already satisfied, under the separate : compilation doctrine in the hackathon notes. : : Each compilation unit needs to be compiled without any information to : the symbols in the caller environment. It may export symbols, but may : not silently make use of caller's symbols, which naturally includes : user-defined operators. Good, I'd forgotten about that. Which means that it's even harder for someone to compile a module in a strange dialect, since they'd essentially have to write their own version of use that forces recompilation (reuse, if you will). And the harder we make it to write reuse, the better. Larry
Mobilizing PM groups for parrot..
Anyone have any ideas on how you might harness a PM group to work on parrot? (Resending from correct account)
Re: Hackathon notes
On Thu, Jul 07, 2005 at 06:37:58PM +0800, Autrijus Tang wrote:
: * A closure form of `but` is desugared into a `do given` block that
: eliminates the need of returning $_ explicitly. So those two forms
: are equivalent:
:
: my $foo = Cls.new but {
: .attr = 1;
: };
:
: my $foo = do given Cls.new {
: .attr = 1;
: $_;
: };
I just noticed that our rewrite doesn't quite work unless you rewrite
every when clause in the first form to also return $_, since when
blocks would escape past the return of the $_. Any form of leave
could have the same problem. I think the proper semantics of but
are that it ignores any return value however generated and pretends
the topic was returned. In fact, the original closure should probably
be evaluated in void context. So it's doing something more complicated
like:
my $foo = do given Cls.new {
given $_ {
.attr = 1;
}
$_;
}
};
But hey, that just makes the monkey-but sugar seem all the sweeter. :P
Larry
Re: Raw bytes in perl6
On Tue, Jul 12, 2005 at 13:55:56 -0700, Larry Wall wrote: On the other hand, if the basic Str type is unwilling to take on the burden of being parameterized, we could generate all our funny string types by mapping a string name to an array declaration. my Str $foo is Array of byte; or some such. But maybe we can make Str of byte mean that by way of shorthand If this means that the string role, composed with the array role is just a way to apply a bunch of really cool operations (rules, substringing, composition, conversion) onto a stream of things that know to do the Char role, can we have monads too? ;-) Seriously though, haskell's way of treating strings as lists make strings useful in a totally different way than perl5 makes them useful, and I'd like to have both. Perhaps the most interesting aspect of the string-is-a-list mindset is that Parsec can parse any list of crap into any structured crap. It's only affinity towards real strings and characters is the builtin library of useful rules. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me has realultimatepower.net: neeyah pgpybQOC4mGML.pgp Description: PGP signature
Re: Need to talk to an EU patent attorney
On 12 Jul 2005, at 22:00, Michael G Schwern wrote: Barbie's journal, via Ovid, made me aware of patent EP1170667 Software Package Verification granted last month in the EU. http://gauss.ffii.org/PatentView/EP1170667 [snip] Oh for f**k's sake :-( Don't know any patent lawyers myself, but it might be worth dropping a line to one or more of: http://www.nosoftwarepatents.com/en/m/about/contact.html http://fsfeurope.org/ The FSFE in particular have been campaigning hard in Europe so should hopefully have some decent contacts. I knew I should have been a train driver sigh Adrian
Re: Need to talk to an EU patent attorney
On 12 Jul 2005, at 23:07, Adrian Howard wrote: [snip] Don't know any patent lawyers myself, but it might be worth dropping a line to one or more of: http://www.nosoftwarepatents.com/en/m/about/contact.html http://fsfeurope.org/ [snip] http://www.eurolinux.org/ also might be worth asking. Adrian
Re: Need to talk to an EU patent attorney
-BEGIN PGP SIGNED MESSAGE- Moin, On Tuesday 12 July 2005 23:00, Michael G Schwern wrote: Barbie's journal, via Ovid, made me aware of patent EP1170667 Software Package Verification granted last month in the EU. http://gauss.ffii.org/PatentView/EP1170667 It appears to patent basic software testing frameworks. This entire patent system is becoming so silly. :-( For what it is worth, this patent would be not legal/not enforcable in Germany due to be software only. (It would also probably not quality on grounds of being obvious, I fail to see what is so patent-worthy on this patent. Even I could have come up with a testsystem.) As for the rest of the EU, software-only patents are very probably not enforcable, anyway. (Although I lost track over how the issue now really is, the last thing I heard there was a victory for the no-software-patent crowd (yeah!), but then maybe it just cemented the status quo (namely, everything under the sun gets patented left/right). But IANAL nor a PA. Best wishes, Tels - -- Signed on Wed Jul 13 00:27:25 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. Duke Nukem Forever will come out before Doom 3. - George Broussard, 2002 (http://tinyurl.com/6m8nh) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iQEVAwUBQtRFVHcLPEOTuEwVAQEbOAf+L12iUs3dcSI438H6h5q3QYWvCl1yeqQi Lj0N1uIFTJjJTavUiOyPfwKO6OswVVCKfezukfHGlayaZ27yrry2O4PMMs33bwbP w7ueSJf8X0iHOQOX464/tI+DnIlzpnfLpT+TMHxot0XYB1WHa8nyfuFcZBHtTqrn 5/QdxXxR91RHAMFpAZjvMXfUyre0yQGqZCiqXtcEkBBMxN7NW6ATwojBXkg/cj/W jAj4T0iuIIe6CfKQyv/tzEBwgsucFSHkvLs4g8AWTco9bD2gjQMGDVn6aOsqzbu/ hbX6paEwa0Ygti6zxWO68BOx303p30yAGGdG4VNJGoYoEyNRLfd+LQ== =3zD3 -END PGP SIGNATURE-
Re: Mobilizing PM groups for parrot..
On Jul 12, 2005, at 13:51, Will Coleda wrote: Anyone have any ideas on how you might harness a PM group to work on parrot? Harness them to do what? Write tests? Clean up documentation? There's certainly precedent (Phalanx), but you need a bunch of small, achievable goals. Allison
Re: How to write a self.pm (Re: method calls on $self)
On Tue, Jul 12, 2005 at 12:36:23PM +0800, Autrijus Tang wrote:
: On Mon, Jul 11, 2005 at 09:04:54PM -0700, Larry Wall wrote:
: On Tue, Jul 12, 2005 at 10:17:01AM +0800, Autrijus Tang wrote:
: : On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
: : The obvious thought is to have yet another magical, $^H like flag, to
: : denote the current dialect. If it is set, then the parser can emit
: : .method as $_.method, instead of $?IMPLICIT_INVOCANT.method.
:
: The parser always emits .method as $_.method under any dialect, or
: fails. What has changed is whether $_ sometimes means the invocant.
:
: But the compiler needs to trigger ambiguity resolution -- i.e. check
: for $?SELF agreement with $_ -- when it sees $?IMPLICIT_INVOCANT.
:
: No need to do that if it sees $_.method. So they need to be different.
Well, another approach is to treat .method as invariably $_.method,
and catch the problem at the attempt to rebind $_. Thomas seems to
think it should already be doing that. Of course, that would make it
impossible to use given or for inside a method at all...
So the other approach is to give up on compile-time checks and say
that $?IMPLICIT_INVOCANT.method in a method's lexical scope (and
in the absence of use self) turns into
($_ =:= $?SELF ?? $_.method :: fail Phooey)
: In any event, SMD methods always have a first argument, so you're never
: in doubt at that point. And since .bar always means $_.bar, I don't
: think you really have a problem here that's any harder than you already
: had with $_.
:
: The problem here is for the compiler to detect whether $_ agrees
: with $?SELF, when it sees $?IMPLICIT_INVOCANT. If they agree,
: $?IMPLICIT_INVOCANT gets replaced by $_; otherwise it is an error.
:
: Consider this construct:
:
: method foo {
: $_ := $something_else if rand(2)1;
: .bar;
: }
:
: That's one case where it's not possible to detect at compile time,
: so it needs to silently let .bar go thru as $_.bar.
Though Thomas's constant binding notion would presumably catch that.
But then we're getting into the noalias zone that Dennis Ritchie hates.
On the other hand, I can see lots of uses for variables that may
not be rebound, at least in terms of reassuring the optimizer that
Weird Things Can't Happen.
: : Clearly we need a way to statically determine statement:given
: : and statement:for will always assign at least one argument to
: : its block argument. Without that, the compile-time analysis mandated by
: : Larry is infeasible.
:
: I think you can assume that given and for always bind at least one
: argument. In particular, a for that binds 0 arguments will never
: progress, plus you can recognize it:
:
: But what in given and for signify that? I do not want to special
: case based on function names, and statement:given may be rebound
: to something else.
I understand the desire for generality, but that road also leads to
error messages that are completely opaque to naive users, who are
pretty accurate in their view that features like given and for
will Stay Put in the normal course of events. Many of the most useful
diagnostics in Perl 5 are the ones that are guessing based on common
usage patterns. Users can't do much with messages that when deciphered
come out to mean something like you called a function passing as
its first argument another function whose first argument's declared
type allows it to be optionally bound to $_ but if we actually try to
make use of that we'll get some ambiguity further on down the road,
and that's bad. They'd much rather chuck the generality and have
You can't say .foo inside given where the topic could be either $_
or the method's invocant. Or in the absense of that just blow up
at run time.
Of course, I'm just restating your problem here...
: How does that something else signify that it will
: at least bind at least one argument to its code argument? Via the
: signature of the code argument, i.e. the Any in codeAny?
:
: sub statement:given (Any $topic, codeAny) { ... }
Maybe something like:
sub statement:given (Any $topic, *code:(Any is topic)) { ... }
: If so, what is the signature of for? I can't seem to write it down.
Good question. I suppose the signature wants to guarantee minimum arity
of 1 somehow. Maybe
sub statement:for (Lazy [EMAIL PROTECTED], *code:(Any is topic, *)) {
... }
or some such. But whether the outer function is actually functioning
as a topicalizer would still depend on the innards of your function.
Hmm. We might settle for declaring such functions with a special trait
that indicates that they are *intended* to function as topicializers.
And then maybe the compiler could just depend on those declarations
for its static analysis:
sub statement:given (Any $topic, *code:(Any)) is topicalizer { ... }
Other that that we rely on the run-time check. (Which hopefully common
code analysis can factor out multiple copies of.)
: : Then,
Re: Mobilizing PM groups for parrot..
That was kind of my point, yes. =-) Hey, Allison - you drafted up the project plan for TPF grant for parrot, neh? Are you the defacto Project Manager for parrot? Or is that position unfilled? On Jul 12, 2005, at 6:56 PM, Allison Randal wrote: On Jul 12, 2005, at 13:51, Will Coleda wrote: Anyone have any ideas on how you might harness a PM group to work on parrot? Harness them to do what? Write tests? Clean up documentation? There's certainly precedent (Phalanx), but you need a bunch of small, achievable goals. Allison
Re: Devel::Cover Problem: testing || for a default value.
[EMAIL PROTECTED] wrote: I respectfully disagree. I think you're focusing too much on the low-level behavior of || returning one of its operands. That behavior makes Perl's syntax flexible and a little ambiguous. Because Perl doesn't make a distinction between assign with a default value and perform a boolean OR Devel::Cover it has to play it conservatively. You shouldn't shift the burden to somewhere else (where $foo is subsequently used) either, because you don't know how it will be used. It could be 1) a boolean in a condition 2) used in another $a = $b || $c type expression 3) an output that only appears in a print() statement ... In any of these cases, it's possible that $foo is really a boolean but by the method you proposed $foo would only be tested for taking both true and false values in the first one. I appreciate your point of view. My suggestion (as I stated in my original post) is conditional on being able to determine the context in which the || is used. If you read the documentation for Want.pm or perldoc perlguts (search for context propogation) there seems to be the possibility of doing this -- though I freely admit that I don't understand perlguts well enough to say. Regards, David Golden
Re: DBI v2 - The Plan and How You Can Help
Dean Arnold wrote: RE: LOBs and SQL Parse Trees: having recently implemented LOB support for a JDBC driver (and soon for a DBD), I can assure you that SQL parse trees are unneeded to support them. For databases Great! Perhaps you can shed some light on how to do it for this, then. SQL command; INSERT INTO FOO (?, ?, ?, ?); Column 3 is a BYTEA column in Pg and needs special peppering to work. or this; SELECT * FROM FOO WHERE SOME_DATE_COLUMN ? SOME_DATE_COLUMN is the database native date type. On Oracle you'll need to convert the ? to a 'TO_DATE(?)'. Sam.
HTTP::Recorder
I'd like to improve HTTP::Recorder. I've contacted Linda Julien (http://search.cpan.org/~leira/) via her CPAN email address, but I've received no response. The module hasn't been touched in over a year and every RT ticket seems to have gone unanswered (http://rt.cpan.org/NoAuth/Bugs.html?Dist=HTTP-Recorder). Suggestions? -- Ian Langworth
Re: Need to talk to an EU patent attorney
Tels wrote: On Tuesday 12 July 2005 23:00, Michael G Schwern wrote: Barbie's journal, via Ovid, made me aware of patent EP1170667 Software Package Verification granted last month in the EU. http://gauss.ffii.org/PatentView/EP1170667 It appears to patent basic software testing frameworks. This entire patent system is becoming so silly. :-( For what it is worth, this patent would be not legal/not enforcable in Germany due to be software only. (It would also probably not quality on grounds of being obvious, I fail to see what is so patent-worthy on this patent. Even I could have come up with a testsystem.) As for the rest of the EU, software-only patents are very probably not enforcable, anyway. (Although I lost track over how the issue now really is, the last thing I heard there was a victory for the no-software-patent crowd (yeah!), but then maybe it just cemented the status quo (namely, everything under the sun gets patented left/right). Indeed, there was a great victory for the no-software-patent side, as the EP massively voted against software patents (648 against, 14 for, 18 nulls). See FFII press releases: http://wiki.ffii.org/Ep050706En http://wiki.ffii.org/SpinPr050708En What this means is that, at the European level, we're back to the statu quo which is: software isn't a technology, therefore it is no patentable (Munich Convention of 1973, confirmed by article 27.1 of TRIPS). Consequence is that the currently 30,000 patents granted by EPO are not legal, hence not enforceable. Of course, IANAL, but that's what MEP and people who actually reading the texts say. Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO
Re: HTTP::Recorder
On Tue, Jul 12, 2005 at 07:35:40PM -0400, Ian Langworth wrote: I'd like to improve HTTP::Recorder. I've contacted Linda Julien (http://search.cpan.org/~leira/) via her CPAN email address, but I've received no response. The module hasn't been touched in over a year and every RT ticket seems to have gone unanswered (http://rt.cpan.org/NoAuth/Bugs.html?Dist=HTTP-Recorder). Suggestions? Roll a new release of the module, upload it to CPAN, announce this on modules@perl.org and module-authors@perl.org and request PAUSE to transfer ownership. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
Re: Raw bytes in perl6
On Wed, Jul 13, 2005 at 00:46:49 +0300, Yuval Kogman wrote: Perhaps the most interesting aspect of the string-is-a-list mindset is that Parsec can parse any list of crap into any structured crap. It's only affinity towards real strings and characters is the builtin library of useful rules. By the way, a nice use case for using the rules engine could be parsing a stream of SAX events into a structure... XML::Simple in perl6 could be really as simple as it sounds =) Can anyone see this being retrofitted on top of current rules semantics? How does PGE relate to this? -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /methinks long and hard, and runs away: neeyah!!! pgpxy6DqV1e8O.pgp Description: PGP signature
Re: Raw bytes in perl6
Yuval Kogman wrote: By the way, a nice use case for using the rules engine could be parsing a stream of SAX events into a structure... XML::Simple in perl6 could be really as simple as it sounds =) Can anyone see this being retrofitted on top of current rules semantics? How does PGE relate to this? Yes, in fact SGML DTDs, once reduced to compact forms such as in; http://search.cpan.org/src/SAMV/Perldoc-0.13/t/09-scottish.t End up looking surprisingly similar to rules. Sam.
Perl 6 Summary for 2005-07-05 through 2005-07-12
Perl 6 Summary for 2005-07-05 through 2005-07-12 All~ Welcome to another summary from the frog house. A house so green it can be seen from outerspace (according to google earth). Perl 6 Compiler Building Pugs Workaround Sam Vilain posted a useful work around to the error error: field `_crypt_struct' has incomplete type which occurs on some systems. Fortunately, Salvador Ortiz Garcia found a fix. http://xrl.us/gqjy http://xrl.us/gqjz Pugs, Pirate. Pirate, Pugs. Autrijus began plotting with the Pirate folks. Thoughts include unifying PIL and PAST or possibly retargeting PIL to PAST. Perhaps the result should be a more nautical dog... maybe schipperke. http://xrl.us/gqj2 Implicit Invocants and Pain Larry (as will be summarized later) ruled that ./method was gone. he further ruled that .method would pitch fits at either compile or run time if $_ =:= $?SELF was false. Autrijus found this quite difficult to implement. Talk continues, my instincts tell me that this too will pass, although Larry assures us that it is absolutely permanent for at least a week. http://xrl.us/gqj3 Parrot Key Question Klass-Jan Stol found that using a assigning a floating point value to a key and then using it make parrot segfault. Warnock applies. http://xrl.us/gqj4 Parrot Copyrights Allison Randal hinted that The Perl Foundation has almost finished hammering out some legal stuff and there will soon be sweeping changes throughout the repository addressing copyright issues. http://xrl.us/gqj5 Character Classes in Globs Will Coleda noted that Tcl would pass more tests if PGE supported characters classes in globs. Patrick, unable to resist the siren call of passing tests, implemented it. http://xrl.us/gqj6 Amber for Parrot Roger Browne announced that he had succeed in extracting viable DNA from a Parrot encased in amber since the Jurasic age. Either that or he release Amber version 0.2.2... not sure which. http://xrl.us/gqj7 Leo's Branch Leo has created a branch in SVN (branches/leo-ctx5) of his work implementing the new calling conventions. This led to some discussion of how to deal with optional arguments. http://xrl.us/gqj8 http://xrl.us/gqj9 Leo's Branch Meets mod_parrot Jeff Horwitz posted some observations and troubles he was having with Leo's branch of new calling conventions. Leo warned that the branch was still young, but would gladly take test cases. http://xrl.us/gqka Leo's Branch Meets PGE After the initial discussion of optional parameter, Patrick updated the leo_ctx5 branch of PGE to the new calling conventions. All tests pass. http://xrl.us/gqkb Get onto the Bus Matt Diephouse found a Bus Error when running languages/tcl/examples/bench.tcl. Warnock applies. http://xrl.us/gqkc MinGW Patch Resurrection François Perrad resurected a patch from mid June with a set of action items. Warnock applies. http://xrl.us/gqkd Scared Parrots Like Scheme Joh Lenz posted an announcement that he had an alpha version of Chicken (a Scheme to C compiler) backending to Parrot. Leo provided answers to some of his questions. http://xrl.us/gqke Bytecode vs PMCs Matt Diephouse posted a list of questions about the place of PMCs. Some of the core tradeoffs include: maintability, portability, optimization, duplicate implementations, and security. http://xrl.us/gqkf make svnclean Leo pointed out that make svnclean got removed, but that he found it useful. Chip suggested that it be renamed make svnclobber, as it does more than just clean. http://xrl.us/gqkg pmc2c.pl Bug Nicholas Clark found a bug in the shortcut to avoid writing a pmc dump file. Warnock applies. http://xrl.us/gqkh Define cache Nicholas Clark suggested that it was probably not wise to #define cache. So they removed it. http://xrl.us/gqki Parrots Getting Smarter Leo pointed out that at least one parrot understood the concept of zero, putting it some distance ahead of romans when it comes to math. Once the Parrots start to grow opposable thumbs, I will welcome our new Parrot overlords. http://xrl.us/gqkj Leo's Branch Meets Exceptions Leo posted two suggestions for how the new calling conventions could interact with Exceptions. Autrijus liked the one that unifies exception handlers with the rest of calls and returns. http://xrl.us/gqkk Control Flow Graph Bugs Curtis Rawls noted what he thought might be a bug in the compute_dominators function. Leo confirmed that it was likely a bug. Later he posted a note saying he was working on a new implementation for some of the CFG algorithms. He asked for a hand, but Warnock applied. Actually, I think I have
Re: Devel::Cover Problem: testing || for a default value.
Michael G Schwern wrote:
The other examples in the ticket play out the same way:
bless {}, ref $class || $class;
I encountered the coverage problem inherent in this code in the
constructor of a module whose maintenance I recently assumed. (For that
matter, I could have encountered it in modules I myself wrote and still
maintain.) I eventually figured that there was no reasonable way to
make the red in the top line of the condition box go away. And since
that was the last remaining bit of uncovered code within the
constructor, I figured I should clean that up as well. So I re-coded
along these lines:
my $self = ref($class) ? bless( {}, ref($class) )
: bless( {}, $class );
More verbose. Less elegant. But more strictly precise. And 100%
testable with reasonable conditions.
jimk
Re: Testing a Script Distributed with a Module
James E Keenan wrote:
Michael G Schwern wrote:
Oh yeah, forgot about that. Its not in your path so you have to give
it the full path to the program.
The directories in blib have no relation to where the file came from.
Non-binary executables always go into blib/script. Binary executables
go into blib/bin.
One other curiosum: As a result of my Phalanx work, I've gotten in the
habit of using File::Temp to create 'anonymous' directories and files in
which to conduct testing. I tried that here:
my $tdir = tempdir( CLEANUP = 1);
ok(chdir $tdir, 'changed to temp directory for testing');
but, once again, 'blib/' couldn't be located. So I had to resort to
manually constructing, populating and cleaning up a 'tmp/' directory at
the same level as 'blib/' or 't/'.
What finally seems to be working is this:
my $cwd = cwd();
my $tdir;
{
$tdir = tempdir( CLEANUP = 1);
ok(chdir $tdir, 'changed to temp directory for testing');
ok(!
system($^X -I$cwd/blib/lib $cwd/blib/script/modulemaker -Icn
XYZ::ABC),
able to call modulemaker utility);
...
jimk
Re: 5.004_xx in the wild?
Michael G Schwern wrote: On Mon, Jul 04, 2005 at 03:59:23PM -0400, James E Keenan wrote: I've only developed in 5.6+ environments. Can anyone provide a link to what I would have to do to make my modules compatible with 5.4 and/or 5.5? Step one: Install 5.4.5 and 5.5.4. Step two: Try out your module with them. Step three: Curse, scream and yell as you work around all sorts of long fixed bugs. [snip] qr// is the only thing I really miss. After spending/wasting a couple of hours trying to do regex tests with just 'ok', I agree. I think I'll try to make the .pm files pre-5.6 compatible, but write all the tests for the modern era and just use SKIP blocks that require 5.6. jimk
Re: Devel::Cover Problem: testing || for a default value.
On Tue, Jul 12, 2005 at 10:44:02PM -0400, James E Keenan wrote:
The other examples in the ticket play out the same way:
bless {}, ref $class || $class;
I encountered the coverage problem inherent in this code in the
constructor of a module whose maintenance I recently assumed. (For that
matter, I could have encountered it in modules I myself wrote and still
maintain.) I eventually figured that there was no reasonable way to
make the red in the top line of the condition box go away. And since
that was the last remaining bit of uncovered code within the
constructor, I figured I should clean that up as well. So I re-coded
along these lines:
my $self = ref($class) ? bless( {}, ref($class) )
: bless( {}, $class );
More verbose. Less elegant. But more strictly precise. And 100%
testable with reasonable conditions.
I would have just eliminated the $obj-new option. In all my years of
programming Perl I've never used it nor have I recently seen it used.
Pure YAGNI.
bless {}, $class;
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
'All anyone gets in a mirror is themselves,' she said. 'But what you
gets in a good gumbo is everything.'
-- Witches Abroad by Terry Prachett
Re: 5.004_xx in the wild?
On Tue, Jul 12, 2005 at 10:52:44PM -0400, James E Keenan wrote: qr// is the only thing I really miss. After spending/wasting a couple of hours trying to do regex tests with just 'ok', I agree. like() takes a string. like( $foo, qr/regex/ ); # same like( $foo, '/regex/' ); # thing -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
partcl accelerator
After a patch to prebuild PGE/Glob.pir and use the precompiled bytecode, I'm seeing the following timings with hello.tcl in partcl's examples: CokeZero:~/research/parrot/languages/tcl/examples wcoleda$ time ../..//../parrot ../tcl.pbc hello.tcl Hello World real0m0.313s user0m0.187s sys 0m0.057s CokeZero:~/research/parrot/languages/tcl/examples wcoleda$ time ../..//../parrot ../tcl.pbc hello.tcl Hello World real0m0.315s user0m0.189s sys 0m0.061s CokeZero:~/research/parrot/languages/tcl/examples wcoleda$ time tclsh hello.tcl Hello World real0m0.325s user0m0.035s sys 0m0.032s Yes, it's actually *faster* than real tclsh. This cannot be right (Actually, given the incredible amount of cheating partcl must be doing, only going this much faster is disappointing. =-) Let's try again. CokeZero:~/research/parrot/languages/tcl/examples wcoleda$ time tclsh hello.tcl Hello World real0m0.069s user0m0.035s sys 0m0.023s Ah, there we go. partcl is back down to about 4.5 times slower. Running a trace, I see the top two opcodes are: Code J Name Calls Total/s Avg/ms 177 - compile_p_p_s20.088355 44.177380 537 - load_bytecode_sc 60.0348095.801486 Which combined only make up .122s - not enough to get us back down to even, but it's a start. There are no compile opcodes in the path for hello.tcl, so this has to be coming in through something we're loading: load_bytecode library/Data/Escape.pbc load_bytecode library/PGE.pbc load_bytecode library/PGE/Glob.pbc Can any of these stdlib items be optimized so they load faster? Anything they're doing at load time that could have been done at compile time instead - like the hash init in PGE::EXP P6Rule, or the rule compilation in PGE::Rule. As for the load_bytecode, I followed the code from the opcode back into src/embed.c, where it calls (eventually) Parrot_readbc - which appears to read the files via fread(). Can we can changed this to something that mmaps instead? (I wonder how much time is spent setting up the initial load of tcl.pbc - that's not done via an opcode, so that time isn't reported via -p, is it?) Regards.
Re: Perl 6 Summary for 2005-07-05 through 2005-07-12
Matt Fowles summarized: Method Call on Invocant Now ./method is gone, and .method only works when $_ =:= $?SELF . Important qualification: Within a method or submethod, C.method only works when C$_ =:= $?SELF. C.method is perfectly legal on *any* topic anywhere that $?SELF doesn't exist. Damian
