Re: Upgrading core modules on Windows
On 3/17/06, David Golden <[EMAIL PROTECTED]> wrote: > Adam Kennedy wrote: > > The only problem with this is that it only deals with CPAN.pm itself. > > > > The problem with locked files is wider than this. > > > > Imagine for example that you have Windows mod_perl or some other > > long-running program holding a lock on the modules. > > I realized that complication, but plenty of Windows installers already > warn you to close all open programs before upgrading. That's not an > unrealistic expectation for users on Windows. > > > So I'd like to see where we get to once the new ExtUtils::Install is out > > and we can install properly, and then if there are still problems after > > that, we take the next step. > > That's good news. I hope the Schwern bottleneck clearly up soon. The point i was making is that it isnt actually necessary for Schwern to do anything for you to enjoy the benefits of the new Install code. The thing that isnt possible right now is to say cpan> install ExtUtils::Install but if you say cpan> install YVES/ex-ExtUtils-Install-1.3701.tar.gz the you are cooking, with gas, right now. :-) And to be honest the package could use a bit of a workout so I encourage people to try it out. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
Re: Upgrading core modules on Windows
demerphq wrote: The point i was making is that it isnt actually necessary for Schwern to do anything for you to enjoy the benefits of the new Install code. > [snip] cpan> install YVES/ex-ExtUtils-Install-1.3701.tar.gz the you are cooking, with gas, right now. :-) That's great, but I want everyone *else* to use gas, too, so that modules I write that use, say, Scalar::Util::refaddr, will automatically be built into PPMs. Since the big bottleneck is apparently Activestate's challenge in upgrading core modules, this is just one step in a much bigger process. (I still want an 8xx-latest repository built, too.) And to be honest the package could use a bit of a workout so I encourage people to try it out. That's a different story -- I'll install it this weekend and see what happens. Regards, David
[svn:parrot-pdd] r11914 - trunk/docs/pdds
Author: pmichaud
Date: Thu Mar 16 18:44:22 2006
New Revision: 11914
Modified:
trunk/docs/pdds/pdd03_calling_conventions.pod
Log:
"Paramters" -> "Parameters"
Modified: trunk/docs/pdds/pdd03_calling_conventions.pod
==
--- trunk/docs/pdds/pdd03_calling_conventions.pod (original)
+++ trunk/docs/pdds/pdd03_calling_conventions.pod Thu Mar 16 18:44:22 2006
@@ -334,7 +334,7 @@
foo(p, q :named('q')) # the same
foo(kw :named :flat)# a flattening has
-=head2 Paramters
+=head2 Parameters
.param int i# positional parameter
.param pmc argv :slurpy # slurpy array
Warnings from Devel::Cover/Test::Harness
I'm trying to capture coverage data for a large project I'm working on. I'm
running all of my unit tests through Test::Harness and I'm trying to utilize
Devel::Cover within the harness. Honestly this is mostly a nitpicky thing
because I can get Devel::Cover to work, but I'm seeing warnings and I want
to make sure I'm not loosing anything because of them.
My harness looks roughly like this:
use Test::Harness;
$Test::Harness::switches = '-MDevel::Cover';
my @tests_to_run = qw(
test1.t
test2.t
test3.t
...
);
runtests(@tests_to_run);
...about as simple as it gets. When I run this way I get warnings like this:
Devel::Cover: Can't find file "blib/lib/Net/SSLeay.pm": ignored.
Devel::Cover: Can't find file "blib/lib/Storable.pm": ignored.
Devel::Cover: Can't find file "../../lib/POSIX.pm": ignored.
Interestingly enough if I change the $Test::Harness::switches assignment to
this:
$ENV{HARNESS_PERL_SWITCHES} = '-MDevel::Cover';
I no longer see the warnings. This seems like a kludge, but I also don't
want to deal with the warnings. Any thoughts as to what's going on?
Note that I do use Storable and POSIX in places, but I don't use
Net::SSLeay, at least not directly.
Andrew
Andrew Gianni
Administrative Computing Services
Computing and Information Technology
University at Buffalo
215 MFAC, Ellicott Complex
Buffalo, NY 14261-0026
716.645.3587x7124
Re: Warnings from Devel::Cover/Test::Harness
Hi Mr. Gianni! I don't know what is the solution to your problem, but I'd like to make a general netiquette note. Please don't start a new thread by replying to an existing message from the list. That's because that way, thread-aware mailers display it as a reply to the message. Instead, write a completely new message to the mailing list. Some mailers have a "Compose New Message" option in the right-click menu on a mail address which allows just that. If not you can put the mailing list's address in your address book. In that case you also don't need to erase the contents of the reply. Regards, Shlomi Fish On Friday 17 March 2006 16:07, Andrew Gianni wrote: > I'm trying to capture coverage data for a large project I'm working on. I'm > running all of my unit tests through Test::Harness and I'm trying to > utilize Devel::Cover within the harness. Honestly this is mostly a nitpicky > thing because I can get Devel::Cover to work, but I'm seeing warnings and I > want to make sure I'm not loosing anything because of them. > [Snipped] - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
PGE internal attributes change
Just a quick note that in r11916 I've updated PGE's internal attribute names to match the new secondary sigils identified by S12. Thus, @:capt is now @!capt, &:corou is now &!corou, etc. (For the pugs folks, I updated the Hs.pir file as well.) This shouldn't have much of an impact on anyone using PGE, but I wanted to send a notification out in case it did. It may be worthwhile to rebuild PGE from scratch to make sure all of the related libraries match. Thanks, Pm
Re: parrotcode.org needs update (0.4.1 to 0.4.2)
Fixed, finally. On Mar 16, 2006, at 5:40 AM, Alberto Simoes wrote: Cheers Alberto
[svn:perl6-synopsis] r8328 - doc/trunk/design/syn
Author: pmichaud Date: Fri Mar 17 08:05:47 2006 New Revision: 8328 Modified: doc/trunk/design/syn/S12.pod Log: Typo fix: "In Perl 6 gives you a choice." -> "Perl 6 gives you a choice." Modified: doc/trunk/design/syn/S12.pod == --- doc/trunk/design/syn/S12.pod(original) +++ doc/trunk/design/syn/S12.podFri Mar 17 08:05:47 2006 @@ -297,7 +297,7 @@ =head1 Class methods Other OO languages give you the ability to declare "class" methods that either don't -need or actively prohibit calls on instances. In Perl 6 gives you a choice. +need or actively prohibit calls on instances. Perl 6 gives you a choice. If you declare an ordinary method, it can function as a "class" method when you pass it a prototype object such as "Dog" regardless of how defined the prototype object is, as long as the method body doesn't try to access any information that
Re: What is the Value of t/0-signature.t?
On 3/17/06, chromatic <[EMAIL PROTECTED]> wrote: > > Do you mean that it's valuable only for the author to run (perhaps during > disttest) and rarely useful for the user to run during installation? Aye. Though I can imagine users who'd like to run them as well... This is after all not that different from the Test::Pod situation, in it that it verifies integrity of the distribution and not the module's function itself. Audrey
Re: early draft of I/O PDD
On Mar 11, 2006, at 2:07, Nicholas Clark wrote: I feel more comfortable with the idea of IO being methods on PMCs than raw OPs. They are methods on I/O objects internally. (Just as most opcodes on PMCs actually call vtable methods.) So, the question isn't as significant as it appears. It's really just "Do we provide a simple opcode interface for the most common operations on I/O objects?" Which is an easy "yes". However, I think that the biggest thing is seeing how the Perl 5 IO works, where all the IO ops have to redispatch if the "file handle" turns out to be tied, and in turn the PerlIO system has a whole second level of redispatch at the C level of "overloading the file handle's behaviour". Oh, and then there's PerlIO::via which hooks that C level back up to Perl methods. That's a Perl 5 problem that Parrot handles with vtables. It's not specific to I/O. So a single level of method calls feels much cleaner, as that means only 1 level of dispatch, however the program is re-implementing IO, be it writes to tied scalars, character set conversion, or merely a direct IO with the most native operating system interfaces. It's not quite that simple, as you still have the I/O layers. Allison
[svn:perl6-synopsis] r8336 - doc/trunk/design/syn
Author: larry
Date: Fri Mar 17 15:41:25 2006
New Revision: 8336
Modified:
doc/trunk/design/syn/S11.pod
Log:
Fixes from Damian
Clarification of default Perl package name
Clarification of when we need not default to Perl 5
Modified: doc/trunk/design/syn/S11.pod
==
--- doc/trunk/design/syn/S11.pod(original)
+++ doc/trunk/design/syn/S11.podFri Mar 17 15:41:25 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 27 Oct 2004
- Last Modified: 23 Feb 2006
+ Last Modified: 17 Mar 2006
Number: 11
- Version: 9
+ Version: 10
=head1 Overview
@@ -89,6 +89,8 @@
the C above will bind as C<&Foo::EXPORT::DEFAULT::bar>,
C<&Foo::EXPORT::ALL::bar>, and C<&Foo::EXPORT::others::bar>.
+Tagset names consisting entirely of capitals are reserved for Perl.
+
Inner modules automatically add their export list to modules in all their
outer scopes:
@@ -239,19 +241,31 @@
use Perl-6;
-you're asking for any version of Perl 6. Say:
+you're asking for any version of Perl 6. You need to say:
use Perl-6.0;
use Perl-6.0.0;
use Perl-6.2.7.1;
if you want to lock in a particular set of semantics at some greater
-degree of specificity. And some large company ever forks Perl, you can say
+degree of specificity. And if some large company ever forks Perl, you can say
use Perl-6-cpan:TPF
to guarantee that you get the unembraced Perl. C<:-)>
+Perl is the default module name, so
+
+use v6-cpan:TPF;
+
+means the same thing. As a variant of that, the current Perl 5
+incantation to switch to Perl 6 parsing is
+
+use v6-pugs;
+
+(though in Perl 5 this actually ends up calling the v6.pm module with a
+'-pugs' argument for insane-but-useful reasons.)
+
For wildcards any valid smartmatch selector works:
use Dog-(1.2.1 | 1.3.4)-(/:i jrandom/);
@@ -273,7 +287,7 @@
my Dog-1.3.4-cpan:JRANDOM $spot .= new("woof");
-The use statement actually allows a language on the front of a module name,
+The C statement actually allows a language on the front of a module name,
so that you can use modules from other languages. The language is separated
by a colon. For instance:
@@ -314,3 +328,7 @@
a bare literal in a void context I to have produced a warning.
(Invoking perl with C<-e6> has the same effect.)
+It's not necessary to force Perl 6 if the interpreter or command
+specified already implies it, such as use of a "C<#!/usr/bin/perl6>"
+shebang line. Nor is it necessary to force Perl 6 in any file that
+beings with the "class" or "module" keywords.
PGE: return values in embedded closures
I've just applied a change (r11921) to PGE that allows
embedded closures in rules to designate a "return value" for
a match (recently added to S05).
Essentially this means that a rule such as
/:lang(PIR) foo {{ .return "bar" }} /
will match a string containing "foo" but gives the returned match
object a value of "bar".
We can also do things such as
/:lang(PIR) \d+ {{ # return 200 more than matched
$I0 = match
$I0 += 200
.return ($I0) }} /
/:lang(PIR) {{
$P0 = match["moose"]# get subpattern match
$P1 = "Moose_new"($P0) # create a new Moose object from it
.return ($P0) }} / # and return that as the Match value
To obtain the return value of a Match object, use the value() method:
match = rule(string)# match string against rule
$P0 = match.value()
If a match object doesn't have an explicit return value, then
its value is the substring that it matched.
There are some small examples in t/compilers/pge/p6rules/closure.t .
Comments, questions and tests welcomed.
Pm
Re: early draft of I/O PDD
On Mar 3, 2006, at 15:54, Joshua Isom wrote: Concerning all the byte/character issues, all the string opcodes except bytelength work with characters. But the io subsystem currently only deals with bytes. I know there is the speed issue for things like reading with dealing with utf8, but something like 'peek' should probably be able to get the full character. Also, what's supposed to be the default encoding for all data read in from a stream where a layer's not added that explicitly states so? Ascii, binary? These we'll put off until we get to the Character Set PDD (as yet unnumbered). I don't think it's really been addressed, at least not recently, but what about IPv6? By the time perl6 becomes commonplace and used often(and thus, parrot), IPv6 will be common enough that problems could occur. Currently it's not speced or stated, aside from a comment in PIO_sockaddr_in. Added. One more thing, what about specing directory handling? Nothing is speced yet for it. Added. Thanks! Allison
PGE update fails some tests under x86_64
On Fri, Mar 17, 2006 at 07:08:55PM -0600, Patrick R. Michaud wrote: > I've just applied a change (r11921) to PGE that allows > embedded closures in rules to designate a "return value" for > a match (recently added to S05). > [...] I neglected to mention in my previous post that this update seems to cause some PGE tests to fail when run in the x86_64 platform (and the failures seem inconsistent). They all pass when run 32-bit, however. Before committing this latest update I spent some time trying to resolve the x86_64 issues, but with little success. So, despite the failed tests, I decided to commit the update anyway so that others with more knowledge than me can track down the problem. Pm
Re: What is the Value of t/0-signature.t?
Audrey Tang wrote: On 3/17/06, chromatic <[EMAIL PROTECTED]> wrote: Do you mean that it's valuable only for the author to run (perhaps during disttest) and rarely useful for the user to run during installation? Aye. Though I can imagine users who'd like to run them as well... This is after all not that different from the Test::Pod situation, in it that it verifies integrity of the distribution and not the module's function itself. Audrey For a user, how does signature.t act differently to the built-in signature checking of CPAN.pm. What does it add? (apart from hung blocky non-blocking connections to the keyserver on Win32) :( Adam K
Re: early draft of I/O PDD
On Mar 6, 2006, at 4:06, Nicholas Clark wrote: On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote: =head2 Network I/O Opcodes Functionality wise, the following are missing: shutdown Added. getpeername/getsockname getsockopt/setsockopt These seem rare, and intimately associated with the I/O object (they're just retrieving and setting attributes), enough to be left as methods. C isn't listed, but I'd assume that that is more a class method called on the class representing Unix Domain sockets. Makes sense as a method. Would it work to have classes representing each address format, each providing a packsockaddr method? I think it makes more sense to have a single opcode that returns the appropriate kind of address object depending on the format of the arguments you pass it. (Though internally it will rely on whatever the chosen class uses to set its address information.) Though, a single class that's smart enough to store different formats of addresses may be better. There's no direct access to fnctl or ioctl given. Specifically it would be useful to have a way to set handles non-blocking (and have the entire IO system cope with synchronous-but-non-blocking IO, even if async IO is more powerful still) This is currently pioctl, but may be replaced by methods on the ParrotIO PMCs. Allison
second draft of I/O PDD
I just committed a more complete draft of the I/O PDD to docs/pdds/ clip/pddXX_io.pod. I've integrated or responded to the mailing list comments. I also added a good bit of additional discussion of asynchronous operations and error handling. The original draft was "how it works now", while this draft is "how it should work", so a diff between the two provides an interesting comparison. Comments and questions welcome as usual. Allison
Proposed kwalitee metric: installer_not_executable
From my understanding, one of the little idiosyncrasies of Makefile.PL/Build.PL installers (including MI variants of both) is that in order to make sure that the Makefile and Build use the correct perl installation, you should always be explicitly running M/B.PL with the perl you want to install the module with, and NOT necesarily with the default perl. This is why installation instructions read perl Makefile.PL make make test make install and not ./Makefile.PL make make test make install As a result, to help enforce this and prevent accidental usage of the installer as an executable, it seems to be (at least in the MI case) highly recommended that you M/B.PL file NOT be executable, and NOT contain a #!/usr/bin/perl line at the top. This is specifically the sort of thing that Kwalitee is aimed at, a not-strictly-enforced but almost-always-recommended rule that many people might not be aware of, or might easily get wrong. And it's easy to check with requiring the CPAN metadata or heavy-duty PPI parsing to acomplish. I'd like to propose a Kwalitee test installed_not_executable be added for which you get the Kwalitee point if and only if: 1) Both Makefile.PL and Build.PL (if they exist) are not executable 2) Both Makefile.PL and Build.PL (if they exist) do not have a leading hash-bang line What happens in the case with a pre-rolled Makefile I'm not entirely sure, or other modules that have neither of the files I'm not sure, but such a distribution hasn't strictly speaking made the mistake, so I'm not against given them the point. Comments? Thoughts? Adam K
