Private tests
Hello all, I've just published an article about public vs. private regression tests. I've defined private tests as t/*.t files that are for the author only and don't go in MANIFEST. Naturally, those don't get as much publicity as tests included in CPAN distributions. In the article I advocate that some tests should be private. In particular, 1) those that test non-critical aspects of a module (like documentation and coding style) 2) those that are too expensive to run often 3) those that require special software or customization In my conclusion I describe a possible system where authors publish the results of private tests with their distributions as a trust- based kwalitee system. That is, authors assert kwalitee rather than be judged for it. http://www.chrisdolan.net/talk/index.php/2005/11/14/private- regression-tests/ Both positive and negative feedback is very welcome! Chris -- Chris Dolan, Software Developer, www.chrisdolan.net Public key: http://www.chrisdolan.net/public.key
Private tests
Hello all, I've just published an article about public vs. private regression tests. Private ones are t/*.t files that are for the author only and don't go in MANIFEST. Naturally, those don't get as much publicity as tests included in CPAN distributions. In the article I advocate that some tests should be private. In particular, 1) those that test non-critical aspects of a module (like documentation and coding style) 2) those that are too expensive to run often 3) those that require special software or customization In my conclusion I describe a possible system where authors publish the results of private tests with their distributions as a trust- based kwalitee system. http://www.chrisdolan.net/talk/index.php/2005/11/14/private- regression-tests/ Both positive and negative feedback is very welcome! Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Private tests
Tels, I believe you have misunderstood my intentions. I was not advocating that any algorithmic tests be non-public. The only tests that should be private are ones that satisfy one or more of the following restrictions: 1. require special additional software that’s difficult or expensive to acquire, 2. require special configuration to run properly, 3. don’t affect the quality of the final software, or 4. take too long to run. That is, tests like spell-checking, pod-checking, Perl::Critic and ones that take tens of minutes to run. Naturally, any test whose results may vary from machine to machine should be public wherever feasible. After reading some of the insightful comments posted on my blog, I've been convinced that the private tests should be included in the CPAN distribution, but disabled in some way (perhaps via a file extension other than .t?). That way, resourceful or interested users can run the tests but average users don't need to. The example I included at the end of the article stating a failed test under Windows was only tangentially related and perhaps was a distraction. I was saying that perhaps it would be useful if authors could assert things about their personal testing experience that would be machine readable and useful to others. In that example I was suggesting that the author could announce that the hypothetical module was known to fail under Windows and, as a TODO test, was an implicit request for help from other developers. Chris On Nov 15, 2005, at 4:12 AM, Tels wrote: -BEGIN PGP SIGNED MESSAGE- Moin, On Monday 14 November 2005 18:21, Chris Dolan wrote: Hello all, I've just published an article about public vs. private regression tests. I've defined private tests as t/*.t files that are for the author only and don't go in MANIFEST. Naturally, those don't get as much publicity as tests included in CPAN distributions. In the article I advocate that some tests should be private. In particular, 1) those that test non-critical aspects of a module (like documentation and coding style) 2) those that are too expensive to run often 3) those that require special software or customization In my conclusion I describe a possible system where authors publish the results of private tests with their distributions as a trust- based kwalitee system. That is, authors assert kwalitee rather than be judged for it. http://www.chrisdolan.net/talk/index.php/2005/11/14/private- regression-tests/ Both positive and negative feedback is very welcome! Private tests will only be run by the author, meaning they will be only run on a very small subset of all systems the modules can be used on. This limits their usefullness quite a bit. Case ein point: I can test my modules on linux, 32 bit, unthreaded, under unicode, and under perl 5.8.x. Thats about it, everything else gets really really complicated for me to set up and maintain/test. So, no win32, no mac, now solaris, no irix, no perl 5.6.x, no iso-something, no EBDIC (or however it is spelled), no threading, no 64 bit, no SMP system. As for 1), these things should matter (the "broken window analogy") and you would be surprised to know how these tests can pass on your system, and still fail on other systesm (forget to include the .pod file in MANIFEST is the most obvious one). As for 2), random testing should be employed (Math::BigInt does this, it runs 256 or so tests with random number patterns (and thus known results like "2 * A - A == A"). The tests are quite fast, but they cover only a small subset of potential values. However, since each system and user runs a new, different random set, you end up with a really huge testing number being run. (Yes, this has found some bugs) And for 3), this might be the only point I can think that private tests are usefull (I have a private testset for Graph::Easy that I use from time to time, it is not public mainly because it fails/hangs/takes forever and is work-in-progress). However, I have to actually read your article to find out what your proposal solves (compared to me just running thetest once in a while :) Hope that was usefull :) Best wishes, Tels - -- Signed on Tue Nov 15 11:04:21 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. "Now, _you_ behave!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iQEVAwUBQ3m0pHcLPEOTuEwVAQF6lQf8CtubDMQjLdCBcEGNczxZj2Y1kTVhOU7Z bvweeJe4RWFfmd2JMw7dwiu3Sjb57hNlVkl4LwN+7vx3tm3DsnhRUoMHvkDtCddC 8bfxpLcOi8WMlySAud+unKnpZVwlwn2rZ/enu2Dd01QKOgOQkBr1HWTJUguPv4No eWT3UiEZhV4hU764gtF7a8raHjbvxpTJcNk22KHnRmyTKX+SugCyI0qkmIQrFntl cQWXyA9GV7V+5bK5/Sp2eWv2MXX3fhNDxtZywkmqun+6/YhPgSDJQp3FcKThZFYy WxPXsrXVIXFJbbtkSs+PGe18VdXqEFCHOI29H1+9gyiC3FW3N6AARw== =GA3y -END PGP SIGNATURE
Re: Private tests
On Nov 15, 2005, at 3:38 PM, chromatic wrote: I posted a small Module::Build subclass that shows one way to do this to Perl Monks: http://perlmonks.org/?node_id=508160 Yeah, I saw that one. Perhaps a better approach is to store these tests in a subdirectory of t/. Beware that M::B has a recursive mode for finding tests. It's set by the author, so you should be safe in this case, but it's a point worth remembering. *light bulb* And in fact, that could be the run-time trigger. Hmmm Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: How to use Devel::Cover?
On Dec 25, 2005, at 3:46 PM, Scott Wang wrote: I am new to use Devel::Cover. We have lots of product Perl modules in our product "lib" folder and we have lots of Perl test scripts to cover those modules, right now, we are trying to get the code coverage metrics for our tests on those modules. I find we might get help by using Devel::Cover, would you please give me some idea on how I should use the Devel::Cover to generate our tests coverage metrics on our Perl modules? Thanks in advance, Scott If you use Module::Build, then simply type "./Build testcover" and then open cover_db/coverage.html in your browser. If you are using a version of M::B older than 0.27_02, you may wish to manually delete the whole cover_db directory between runs. Later M::B versions auto- detect when cover_db files are out of date. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
punie.g observation
Allison et al.,
I was looking at languages/punie/lib/punie.g in the current SVN head
and got confused. I see:
rule gprint { (print) \s* }
and
rule expr{ | }
Doesn't that imply that "print print print print 1;" is a valid Punie
program? Is that intentional? It seems to me that the gprint rule
should instead contain "cexpr":
rule gprint { (print) \s* }
Sorry if these are dumb questions. I've been following Parrot for a
while, but I'm new to the code...
Chris
--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
On Jan 27, 2006, at 12:01 PM, Tels wrote: On Friday 27 January 2006 18:48, Chris Dolan wrote: On Jan 27, 2006, at 11:23 AM, Tels wrote: Basically something like CPAN, but with much less network traffic and much less hassle for a user. Bonus points if it gives you stuff pre- compiled for windows (all those ppl w/o a compiler). I think you just described ActiveState's Perl Package Manager (PPM). http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/ I lived under the expression that it is: * for windows only * only includes Foo-Bar, but not it's dependecies It will auto-install dependencies just like CPAN, I believe. And, yes, it's currently Windows-only. Didn't you offer bonus points for Windows?? Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
On Jan 27, 2006, at 11:23 AM, Tels wrote: Basically something like CPAN, but with much less network traffic and much less hassle for a user. Bonus points if it gives you stuff pre- compiled for windows (all those ppl w/o a compiler). I think you just described ActiveState's Perl Package Manager (PPM). http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/ Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
On Jan 27, 2006, at 12:30 PM, Tyler MacDonald wrote: Chris Dolan <[EMAIL PROTECTED]> wrote: * for windows only * only includes Foo-Bar, but not it's dependecies It will auto-install dependencies just like CPAN, I believe. And, yes, it's currently Windows-only. Didn't you offer bonus points for Windows?? Um, no it isn't! http://ppm.activestate.com/ PPMs are built for a variety of platforms, windows, OSX, and various unixes. You can download ActivePerl for these platforms here: http://www.activestate.com/Products/Download/Download.plex? id=ActivePerl - Tyler Sweet! I didn't know that. Yay ActiveState! Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
Tels,
Please forgive me for being blunt, but I think it's your fault for
writing fragile META.yml creation code. YAML.pm is not even at 1.00
yet, so an API change is allowed by convention, and lack of backward
compatibility is to be expected. If you were to have wrapped your
whole custom META.yml creation code in a big eval, there would not
have been a problem. Furthermore, it seems to me that you are
reinventing the wheel by adding custom META.yml code to the
Makefile.PL of every package you write instead of, say, using
Module::Build or just omitting the non-essential META.yml customization.
The ultimate solution, of course, is that there will be a standard
way to generate proper META.yml. In the meantime, however, it is my
opinion that we're better off lacking META.yml than having a
proliferation of different solutions to the META.yml issues.
Chris
On Jan 28, 2006, at 4:26 AM, Tels wrote:
Moin,
On Saturday 28 January 2006 11:08, Adam Kennedy wrote:
Graph::Easy installation failing here with YAML 0.50 (newer
versions of
YAML seem to be uninstallable at the moment due to Class::Spiffy +
Spiffy + Test::Base install failures...
Just what I said about dependecies etc. My Makefile.PL uses YAML
for me
(e.g. the author) to create a META.yml file with a license field,
something that MakeMaker (could?) can't do.
I used "require YAML;" to avoid that the user has to has it installed.
Unfortunately, YAML got changed, and now you also need "require
YAML::Node;" for my Makefile.PL working properly. :-(
So you can either:
* patch my Makefile.PL
* patch YAML to work like the previous version, then update it on
CPAN,
then install it
The latter is way more work, and needs time and due to what you wrote
above, might even not work.
I'd say keep the dependencies out of YAML ("KISS"!). Whether YAML
should
also load YAML::Node when you do "require YAML;" is a point for
discussion, but it certainly tripped up a *lot* of existing
Makefiles and
I don't have the time to patch them all because that requires me to
release a dozend or so modules.
Sorry for the problem, but it is only partly my fautl :)
Best wishes,
Tels
--
Signed on Sat Jan 28 11:22:01 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
This email violates EU patent EP0394160:
[ ## 66% ]
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)
On Jan 30, 2006, at 10:04 AM, David Cantrell wrote: [...] for example, on OS X, HFS+ is case-preserving but case- insensitive. UFS is case-sensitive. And FAT16 smashes case. And to make matters even worse (better?) Apple added a case-sensitive mode to HFS+ in 10.4. It's not widely used. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: YAML and Makefile.PL (was various topics)
On Jan 31, 2006, at 2:30 AM, Adam Kennedy wrote: Solutions that can be implement without either betting incredibly aggressive to users, putting MB or CPANPLUS into the core, or going down the bundled route, would be interesting to hear though. If I've read the perl5-porter summaries correctly, M::B just entered core in 5.9.3. There has long been hope that M::B and CPANPLUS will be in core for 5.10. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: YAML and Makefile.PL (was various topics)
On Jan 31, 2006, at 2:32 AM, Adam Kennedy wrote: But then how are you going to make Bundle::CPAN trigger when there's a critical failure, without requiring the user to be smart? CPAN.pm and CPANPLUS.pm already check their own version against CPAN on every run. All we'd need to do is have Andreas or Jos increment the CPAN.pm/CPANPLUS.pm version and just about everyone would be prompted to upgrade the next time they tried to install something. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: TODO test paradox: better TODO test management?
On Jan 31, 2006, at 10:40 AM, demerphq wrote: While only indirectly related. Lately when ive built blead I see stuff like "10 TODO tests unexpectedly passed!" So far ive not found a way to make harness tell me which they are... So i too would like a report of TODO tests, both those passing and those failing. You could try: make test verbose=1 > out and then search the output for "TODO" Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [Module::Build] [RFC] author tests
On Feb 1, 2006, at 10:35 PM, Tyler MacDonald wrote: Chris Dolan <[EMAIL PROTECTED]> wrote: There is a class of tests that module authors perform that end users are not expected to run. For example code coverage tests, spelling tests, coding style tests, etc. These tests are either prohibitively expensive or complicated or unpredictable for end users to run. I call these "private tests" or author tests. I really like this idea. But as you pointed out, it's not just authors that need to worry about running these tests, it's packagers (ppm/deb/etc), automated testers (cpants/testers.cpan.org/etc), and hackers. I'd suggest we call these "exhaustive" tests. No, I disagree. I'm specifically talking about author tests, NOT packager tests. Things like Test::Spelling are pointless and difficult for packagers to execute because Test::Spelling relies on an external aspell or ispell program *and* performs differently in the presence of an author's custom dictionary (mine has "Dolan"; does yours?) These specifically are not exhaustive tests but spit-and-polish tests. To make this less abstract, let me list the specific author tests that I employ for most of my CPAN modules, along with an explanation of why it wouldn't work for a packager * copyright.t - Ensures that there is a "Copyright ".([localtime]-> [5]+1900) somewhere in every .pm file. Will break 11 months from now. * distribution.t - Relies on Test::Distribution, which is not in my prereq list * perlcritic.t - Runs Test::Perl::Critic on all .pm files. Will fail without my specific $HOME/.perlcriticrc and will fail with future, more exhaustive versions of P::C * spelling.t - Runs Test::Spelling. Will fail without my custom dictionary * versionsync.t - Checks that the $VERSION is the same in all bin/* and *.pm files. This test is pointless after release, since it's already been tested before release * pod.t - Checks POD validity. This test is pointless after release, since it's already been tested before release * pod-coverage.t - Checks POD completeness. This test is pointless after release, since it's already been tested before release and one I have not yet employed: * coverage.t - Ensures that Devel::Cover totals are higher than some threshold Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [Module::Build] [RFC] author tests
On Feb 2, 2006, at 9:19 PM, Yitzchak Scott-Thoennes wrote: Chris, how are you currently set up to run these tests only when preparing a release? I make no such distinction. Instead, I see these tests as part of my day-to-day development and run all of them with every "./Build test". Presently, I simply include them all in my MANIFEST.SKIP so they are not included in my uploaded package. That's why I call these "author tests" and not "release tests" or "exhaustive tests". Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Default tests, beta testing, etc.
On Feb 5, 2006, at 2:36 PM, Bryce Harrington wrote: [snip] It would seem to be useful if CPAN were to have a couple really basic tests like this to run for perl modules that haven't created any tests themselves. Obviously, this only benefits immature modules, but this might be a good way to motivate new authors to put more attention into testing. I recommend Test::Distribution for this type of "default" tests. It looks for .pm files in blib and performs a bunch of tests on them -- POD, compile, version, etc. [snip] Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Default tests, beta testing, etc.
On Feb 6, 2006, at 1:37 AM, Adam Kennedy wrote: In fact, what you just asked is already listed in the PITA documentation as within it's scope. For lack of a better name, I've called it Fallout Testing. As opposed to Rot Testing, which is when your module doesn't change, but makes sure it still works as Perl is upgraded and your dependencies evolve. Since I've got a terribly bad habit of inventing things that have existing names, I'm sure someone will correct my on the two above namings. I think those are great names. Very clear. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: OS.pmc patch to add 'ls'
On Feb 12, 2006, at 6:52 PM, Joshua Hoblitt wrote: It would also be 'really nice' have a glob(3) like method that is implemented as a wrapper around *dir methods so the semantics are portable. My outsider opinion is that parrot should focus on exposing basic OS functions (opendir, readdir, closedir) and leave the high-level functions (ls, glob) to the languages or libraries. My justification for that opinion is security lockdown. If there are more op-level ways of accessing the system, then there are more features that sandboxes like Safe.pm have to disable. Even more critical is the potential for creep. If sandboxes have to follow a moving target, then it could make it challenging to make security promises. Certainly, it would aid performance to have parrot-level support for commonly used idioms like directory slurping, but the price is more work for the languages. It's kind of a CISC vs. RISC argument. Again, this is an outsider opinion. Apologies in advance if I'm off- base or misunderstood the proposal. Chris -- Chris Dolan, Software Developer, http://www.chrisdolan.net/ Public key: http://www.chrisdolan.net/public.key vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: OS.pmc patch to add 'ls'
On Feb 13, 2006, at 1:20 PM, Joshua Hoblitt wrote: On Mon, Feb 13, 2006 at 09:28:40AM -0600, Chris Dolan wrote: On Feb 12, 2006, at 6:52 PM, Joshua Hoblitt wrote: It would also be 'really nice' have a glob(3) like method that is implemented as a wrapper around *dir methods so the semantics are portable. My outsider opinion is that parrot should focus on exposing basic OS functions (opendir, readdir, closedir) and leave the high-level functions (ls, glob) to the languages or libraries. My justification for that opinion is security lockdown. If there are more op-level ways of accessing the system, then there are more features that sandboxes like Safe.pm have to disable. Even more critical is the potential for creep. If sandboxes have to follow a moving target, then it could make it challenging to make security promises. I think your slightly confusing OPs and PMCs. Presumably the *dir functionality would be implemented as OP codes while glob(3) would be implemented in the OS.pmc. For all intents and purposes PMCs can fill the role of what you referred to as libraries. Thanks for the clarification. Apologies for the spam! Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [perl #38604] m4.pm vs. M4.pm causes problems in case-insensitive filesystems
On Feb 21, 2006, at 1:30 PM, Bernhard Schmalhofer wrote: Chris Dolan (via RT) schrieb: # New Ticket Created by Chris Dolan # Please include the string: [perl #38604] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38604 > While doing an "svn update" from a Mac OS X box today, I got this error: svn: Failed to add file 'languages/m4/lib/Parrot/Test/M4.pm': object of the same name already exists This is funny. I think that I have renamed m4.pm to M4.pm around revision 11350. So it should be OK for fresh checkouts. The funny thing is that I can do a 'svn mv' under Unix, which causes troubles on case-insensitive filesystems. Aha. Indeed, the last time I updated was prior to 11350, I believe. I agree that fresh checkouts should be OK. In this case, my successful workaround was simply "rm languages/m4/lib/Parrot/Test/ m4.pm ; svn update" IIRC, "svn mv" is really just "svn cp" followed by "svn rm" behind the scenes. So, there is a moment during update when both files need to exist. A possible (untested) workaround for committers might be: svn mv m4.pm m4-temp.pm svn commit svn mv m4-temp.pm M4.pm svn commit To prevent a repeat of this problem in the future, one solution is to use the check-case-insensitive.pl pre-commit hook script that is in the contrib directory of the subversion source. This FAQ has more info: http://subversion.tigris.org/faq.html#case-change Somebody who can administrate the SVN server could take a look at this script. The FAQ does not really tell what it does. Mandating all lower case filenames is no solution. The script looks at the incoming files and compares to existing files to see if any names differ only in case. If there are such files, the commit fails. Chris
Surprising use_ok false positive
I encountered a real-world case where Test::More's use_ok() passed
when the specified package had a fatal syntax error. I'm looking for
advice about whether I should file a bug, or fix my code that
triggered the false positive. Read on for details...
Consider two packages Foo.pm and Bar.pm:
--- Foo.pm ---
package Foo;
my $has_Bar = eval {require Bar; 1;};
sub print_msg {
$has_Bar ? Bar->print("Hello") : print "Hello";
}
1;
--- Bar.pm ---
package Bar;
sub print { # egregious syntax error
1;
--- t/use.t ---
use Test::More tests => 2;
use_ok('Foo');
use_ok('Bar');
Then if I run "perl t/use.t" I get the surprising result:
1..2
ok 1 - use Foo;
ok 2 - use Bar;
The problem is that Foo trapped Bar's syntax error in the eval, so %
INC{Bar} is defined and use_ok() sees it as a success.
Advice? While this example is contrived, the "eval { require ... }"
idiom is used often in the wild, so this is not a wholly unrealistic
scenario.
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: Surprising use_ok false positive
On Mar 5, 2006, at 3:55 PM, David Wheeler wrote:
On Mar 5, 2006, at 13:52, Chris Dolan wrote:
Advice? While this example is contrived, the "eval
{ require ... }" idiom is used often in the wild, so this is not a
wholly unrealistic scenario.
Of course it should be
eval { require Bar; 1; } or die $@;
But I agree that it seems like if the load failed in your eval, it
should fail for Test::More, too. But maybe even a failed require
sets the record in %INC?
In this case, Bar.pm is intended to represent optional functionality
that Foo.pm conditionally loads. So, adding a die would be
counterproductive. The problem is that I don't know how to
distinguish between a load failure or a compile failure. There must
be a way to do that right?
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: early draft of I/O PDD
On Mar 6, 2006, at 6:08 AM, Leopold Toetsch wrote:
Using opcodes for all the IO has some disadvantages:
a) namespace pollution: all opcodes are reserved words in Parrot
b) opcodes aren't overridable, that is you can't provide your own
'print' opcode for e.g. debugging
c) all such IO opcodes have to verify that the given PMC is
actually a ParrotIO PMC.
E.g.
new P0, .Undef # or .Integer, ...
print P0, "foo"
I'm in favor of using methods for almost all IO functionality:
P0.'print'("sample data\n")
I agree. Additionally, I speculate that the latter would make it
easier to write the Parrot equivalent of Safe.pm's sandbox later. It
would likely be easier to disable a PMC class than a diverse
collection of opcodes.
Chris
--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: Best Practice for testing compilation of scripts
On Mar 15, 2006, at 2:47 PM, Geoffrey Young wrote: chromatic wrote: On Wednesday 15 March 2006 12:25, Jeffrey Thalhammer wrote: I'm sure I could clean this up by opening a pipe instead of using backticks and output redirection. But even that doesn't smell very good. I've looked around on CPAN, but I have not yet found a Test:: module that seems appropriate. I also wondered if fiddling with $^C would do the trick somehow. Any suggestions? Thanks. I've long intended to take t/test.pl from the Perl core distribution and wrap up at least its runperl() in a Test:: module. Perhaps that would work for you? compile_ok() ? --Geoff It is unclear from Geoff's message above whether he is asserting that function exists, or if he is merely proposing it, so I googled. It doesn't appear to exist in any Test:: package (corrections VERY welcome). However, Adam Kennedy wrote one: http://search.cpan.org/src/ADAMK/ThreatNet-Bot-AmmoBot-0.10/t/ 01_compile.t That function should probably be changed to use FindBin instead of updir() calls. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Upgrading core modules on Windows
On Mar 16, 2006, at 8:51 AM, David Golden wrote: ... So why not bundle a snapshot of all the module dependencies for PPM/ cpan.pm into a separate directory and put that at the start of @INC when running PPM/cpan.pm? ... Makes sense to me. PAR would be a very valuable tool to implement this, although that would be a huge addition to the dependency list. With PAR, you could employ a whole separate .exe and probably even do the core updates. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [PATCH] Forking tests with Test::More
On Mar 28, 2006, at 4:55 AM, Tassilo von Parseval wrote:
Do you think this might work better, or could be implemented as, a
seperate Test::Fork type module?
It certainly could be done. But it would essentially share 90% of its
code with Test::Builder.
Umm, subclassing? :-)
It's simple really: Either my proposed method
is robust in which case it can go into Test-Simple. Or it isn't. Then
there's no need to implement it as a separate module. :-)
I don't think it is that simple. *IF* there are any bugs in this
niche feature, then it could break the most popular test module on
CPAN. Clearly from your proposed patch, any code that needs the fork
feature of Test::More says so explicitly via the $self->{Forked}
property. So specifying a subclass instead, like a hypothetical
Test::More::Forked, should be trivial. I have not yet seen any
justification for adding this feature to Test::More itself.
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: Module requirements
On Apr 5, 2006, at 9:06 AM, David Landgren wrote: perl -MModule::CoreList -le 'print Module::CoreList->first_release ($_) for @ARGV' File::Find Memoize 5 5.007003 (um, that can no doubt be golfed, but you get the picture). Yes, it can: % corelist File::Find Memoize File::Find was first released with perl 5 Memoize was first released with perl 5.007003 Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: CPANTS is not a game.
On May 23, 2006, at 8:39 AM, David Golden wrote: How does "is_prereq" improve quality? Or, put differently, how does measuring something that an author can't control create an incentive to improve? is_prereq is usually a proxy metric for software maturity: if someone thinks your module is good enough that he would rather depend on it than reinvent it, then it's probably a better-than-average module on CPAN. is_prereq is usually a vote of confidence, so it is likely a good proxy for quality. In fact I believe that because the author (usually) can't control it directly, is_prereq is one of the best proxies for quality among the current kwalitee metrics. CPANTS by itself does nothing to improve quality. However, by drawing attention to kwalitee metrics, I argue that CPANTS draws attention to quality too. Even if many authors don't understand that, the ones that do makes CPANTS worthwhile. If making it a game helps to further raise awareness, then I think that should be tolerated until CPANTS matures. IMHO, the best way to improve CPANTS and move away from the game mentality is to continually add more tests. Each added test diminishes the weight of previous tests. This will annoy the "gamers" because their modules keep dropping in kwalitee, while those that genuinely care about quality will appreciate the additional measurements. If some gamers get annoyed enough to quit the game, that's not a big deal because they didn't really understand the point of CPANTS anyway. If some keep playing the game by cleaving to the standards the community sets for them, then all the better for the rest of us. As an example, consider pod_coverage. It's a rather annoying metric, most of us agree. Test::Pod::Coverage really only needs to be run on the author's machine, not on every user's machine. However, by adding pod_coverage to kwalitee we got LOTS of authors to improve their POD with the cost of wasting cycles on users' machines. I think that's a price worth paying -- at least until we rewrite the metric to actually test POD coverage (which is a decent proxy for POD quality) instead of just checking for the presence of a t/ pod_coverage.t file (which is a weak proxy for POD quality, but dramatically easier to measure). Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: CPANTS is not a game.
On May 23, 2006, at 10:34 AM, David Golden wrote: Chris Dolan wrote: ... just checking for the presence of a t/pod_coverage.t file (which is a weak proxy for POD quality, but dramatically easier to measure). It doesn't check for the existence of a t/pod_coverage.t file. It checks that a string like "use Test::Pod::Coverage" appears properly formatted. E.g. I believe this is sufficient to get the Kwalitee point: # t/pod_coverage.t __END__ use Test::Pod::Coverage; And, unfortunately, it also misses actual perl that doesn't meet its regex expectations. (E.g. see the bug I recently filed for Module::ExtractUse.) Point taken, apologies for the inaccuracy. However, that supports my argument that pod_coverage is a weak proxy. I say it's much better than nothing, but still weak and the brittleness documented above makes it weaker. Actually, I'd rather see a robust pod_coverage that just checks for the existence of t/.*pod_coverage.t than a slightly brittle that parses that file. That is, I'd rather see false positives than false negatives. To put it another way, I'll tolerate cheaters to avoid annoying the well-intentioned authors. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: CPANTS is not a game.
On May 23, 2006, at 10:15 AM, H.Merijn Brand wrote: is_prereq is usually a vote of confidence, I respectfully disagree completely. It's been more than once that I did *not* install a module because it required a module that I did not trust, either because of (the programming style of) the author of that module, or because that module required yet another zillion things I do not want installed (think YAML). I believe we are largely in agreement, but I think your example demonstrates that you missed my point. As you well know, CPANTS is not making recommendations whether a module is a good solution for your problem, or whether you should trust a given module. Instead, it is currently measuring maturity of a module and the author's attention to detail. is_prereq just measures whether *any* other humans trust the module in question. In that way, is_prereq is like a simplistic binary version of Google's page rank. Just because Google rates a page highly doesn't mean it's a good page. Similarly just because CPANTS ranks a module highly doesn't mean it's a good module. However, both is_prereq and page rank are among the current best automatable proxies we have for approximating human judgment of quality. Yes, there are great modules with is_prereq of 0 and there are great web sites with low page ranks. But in both cases they're harder to find than their highly-linked counterparts, except via word of mouth (perlmonks, cpanratings, etc). I keep advocating for is_prereq because currently it's the only non- author-controlled input to CPANTS. That's it's primary value, and it will continue to be important until some better proxy for human confidence comes along, like incorporating cpanratings into CPANTS (I do NOT advocate that!) or getting download stats from CPAN (never gonna happen) or adding voluntary "Someone installed module X" pings from CPAN.pm. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: 3 Good Reasons...
On May 26, 2006, at 6:37 AM, Michael Mathews wrote: I use the expat and libxslt libraries (both in C) regularly via perl, so I guess I must agree that there is a distinction -- thank you for clarifying that. But I can't think of any examples where I was stuck because I couldn't use a "library" only available in, say Python, or JavaScript in my Perl. But then I'm seeking to learn here so can you give a nice juicy example of a non-C library that would be a big plus to be able to include in Perl? I have a real-world example from my work. Perl lacked a library for parsing and editing Macromedia FLV files. There was one in Ruby[1], but the rest of my code was written in Perl. So, I created the FLV- Info library[2]. It's pretty nice for reading FLVs IMHO, but has no edit features due to my time constraints. If I were working in the magic future where Perl and Ruby are bytecode compatible, perhaps I would have just interfaced with the Ruby library directly instead of having to reinvent it, saving a couple of days of coding and debugging. [1] http://inlet-media.de/flvtool2 [2] http://search.cpan.org/dist/FLV-Info/ Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Relationship between pugs and parrot/language/perl6
On May 29, 2006, at 6:34 PM, Audrey Tang wrote: Personally, I think a canonical acceptance test suite is more important than a canonical implementation, but if the Parrot/Perl6 official-perl6 plan works out, that's wonderful too. :-) That's so cool. :-) This positive attitude toward testing is what has kept me so excited about the Perl community over the last few years, even after the initial love for the language wore off. So instead of "Only Perl can parse Perl" we get "Only Perl regression tests can specify Perl". I can be happy with that. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Continuous testing tools
On Jun 8, 2006, at 10:39 AM, Tels wrote: On my todo (well, wish list) is still a project that works rouhgly like a server/client model. You upload a snapshot to the server, it notifies the clients, they download the package, run the tests and report the result back. Reports are viewed on the server. Is there any interest in such a package? Best wishes, Tels That sounds very similar to Adam Kennedy's PITA project. Yes, there is great interest! Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: TAP Grammar
On Jul 3, 2006, at 6:33 PM, chromatic wrote: On Monday 03 July 2006 09:01, Jonathan T. Rockway wrote: That said, I would be interested. I'm still trying to page all the perl6/parrot grammars (PGE, TGE, etc.) into my brain, so any additional examples would helpful, interesting, and fun. For me, anyway :) Jerry Gay just wrote a PGE TAP grammar: <http://svn.perl.org/parrot/trunk/examples/pge/grammars/TAP.pg> -- c I hacked a rudimentary test case for that grammar, borrowing heavily from Punie: https://svn.clotho.com/public/parrot-experiments/TAP/ To run it, edit the first line of the Makefile to specify the path to PARROT_DIR and run "make". My tests found a few bugs in Jerry's grammar. My fixed version of that grammar is here: https://svn.clotho.com/public/parrot-experiments/TAP/grammars/TAP.pg Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Old and broken versions of Module::Install
On Jul 6, 2006, at 9:18 AM, A. Pagaltzis wrote: * Steffen Mueller <[EMAIL PROTECTED]> [2006-07-06 15:20]: What does Module::Build count as? ;) I use M::B with `create_makefile_pl => 'traditional'`. What does that count as? Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> IMHO it likely counts as a CPANTS pass for now, but it may be a fail in the future unless you update the Makefile.PL with a newer M::B as bugs are discovered. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Old and broken versions of Module::Install
On Jul 6, 2006, at 8:10 AM, Steffen Mueller wrote: David Golden schrieb: What about adding NO_BROKEN_INSTALLER as a Kwalitee point for CPANTS? Maybe tongue-in-cheek, but it's actually a good idea. Module::Install pre-0.61 is certainly "broken". What does Module::Build count as? ;) Steffen I agree, this is a really good idea. I would call it "UP_TO_DATE_INSTALLER". For the present, it could simply test for old Module::Install. In the future, it could be expanded to look for compatibility problems in Build.PL or Makefile.PL (e.g. a Makefile.PL using out-of-date Module::Build::Compat boilerplate). If the CPANTS "game" gets any M::I-using authors to upgrade, then it has served its purpose. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Cage Cleaning for dummies? Re: Call for Parrot Janitors
On Jul 5, 2006, at 11:10 PM, chromatic wrote: * Is a FQDN with RDNS required for access or posting of bugs? I believe you can post through the web interface. Not as of yesterday. RT appears broken and searches return no bugs... The official bug submission recommendations are listed here: http://bugs6.perl.org/ Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Old and broken versions of Module::Install
On Jul 6, 2006, at 10:18 AM, A. Pagaltzis wrote: * Chris Dolan <[EMAIL PROTECTED]> [2006-07-06 16:30]: IMHO it likely counts as a CPANTS pass for now, but it may be a fail in the future unless you update the Makefile.PL with a newer M::B as bugs are discovered. To make sure we’re on the same page: that would be bugs in M::B::Compat, not M::B itself, right? If that isn’t accepted, then I will revert to EU::MM (with apologies to Schwern) until you all figure out the damn installers among yourselves. Yes indeed, that's what I meant. I'm not saying there are M::B::Compat bugs, just *if* any were discovered someday, they could be flagged by CPANTS. Anywhere you have boilerplate code, you have the possibility of bugs that need to be fixed via the good intentions of authors deploying that boilerplate. M::B- and EU::MM-using authors generally create minimal boilerplate and thus have a central point of upgrade. M::B::Compat is the only exception I could think of, so it became my example in my effort *not* to incite an M::I vs. M::B flamefest. Apologies for any confusion. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [perl #39743] [PATCH] change perl6-internals to parrot-porters in docs
Oops, I missed a couple of instances of perl6-internals in the previous patch (notably, in parrotbug). This updated patch obsoletes the previous one. % diffstat parrot-porters2.patch README |4 ++-- README.win32.pod |2 +- RELEASE_INSTRUCTIONS |8 compilers/imcc/README|2 +- docs/debug.pod |2 +- docs/dev/dod.pod |6 +++--- docs/faq.pod |6 +++--- docs/gettingstarted.pod | 15 --- docs/glossary.pod|2 +- docs/intro.pod |8 docs/parrot.pod |2 +- docs/pdds/pdd00_pdd.pod |4 ++-- docs/submissions.pod |4 ++-- editor/pir-mode.el |4 ++-- languages/regex/README |4 ++-- languages/tcl/README.pod |2 +- parrotbug|2 +- src/exceptions.c |2 +- 18 files changed, 40 insertions(+), 39 deletions(-) parrot-porters2.patch Description: Binary data
Re: [Slightly OT] Understanding Software Licences [was Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]]
On Jul 7, 2006, at 8:13 AM, Shlomi Fish wrote: This kind of attitude was also said by another responder to this mailing list. It's sort of a "small headed" (see http://www.joelonsoftware.com/items/2004/12/06.html ) "I just want to write code and am not interested in any legal details" attitude. May I suggest a compromise? As the author of the MIT-licensed code in Test::Run, Shlomi has the option of releasing the code under any license he prefers. Shlomi can releases *two* versions of Test::Run with every update -- a mixed license version and an Artistic/GPL version. With that solution, Shlomi himself shoulders the burden of resolving license compatibility and tracking which line of code is under which license. I do believe that the quest for license simplicity in the Perl core is not "small headed" or rooted in ignorance, but is instead inspired. While many developers or TPF itself could easily delve deep enough to decide whether MIT/BSD licensed code in the core is a threat, I think that would be a wasted effort. The increased complexity of licensing (whether real or perceived) could easily turn off third parties with less dedication to Perl, thereby decreasing the attractiveness of the language. After all, software engineering is largely about reducing the exposed complexity of a project. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Java Script in Parrot
On Jul 10, 2006, at 4:31 PM, Vishal Soni wrote:
This is is a good starting point. I have been writing the
JavaScript grammar
in PGE fromECMA-262 spec. They lay out the operator precedence
using Grammar
rules. Instead of using rules for operator precedence I would like
to use
your optok approach. Is there some help I can get? I did look at
your YAPC
2006 presentation. Are there any code examples?
Take a look at parrot/languages/punie/lib/{punie.pg,PunieGrammar.pir}
which has both bottom up and top down parsing. I found it very
educational.
Chris
--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: [perl #39809] PGE crash on parrot;PGE::Exp::Quant;reduce
On Jul 12, 2006, at 10:53 PM, Patrick R. Michaud wrote:
On Wed, Jul 12, 2006 at 08:04:01PM -0700, Chris Dolan wrote:
As simple token containing ":i" causes PGE to crash with an attempted
method call on Undef.
Steps to reproduce:
1) Create a grammar file called "foo.pg" that has one line:
token foo { :i a }
As I read S05, a modifier has to occur at the *very* beginning
of a regex (or group) in order to work. In other words, no whitespace
before modifiers in a regex (because whitespace may have some
other meta-syntactic meaning with :sigspace). Thus
token foo {:i a }
works, while
token foo { :i a }
is an error, since the ':' acts as a cut operator that doesn't
have anything to cut.
But I admit that since we've gone to regex/token/rule, then perhaps
leading whitespace prior to a modifier should be ignored. That
probably needs a ruling from p6l or @Larry.
Pm
Ahh, that makes sense. So it's possibly just an uncaught syntax
error, and definitely a syntax error under :sigspace. I propose that
P6Regex.pir gets something like:
parse_error(mob, pos, "Too late for modifier")
but I have not yet figured out where it belongs in P6Regex.pir.
On a related note, I don't see any regression tests for syntactically
incorrect regexps. I'm good at writing invalid regexps :-) so if
someone starts a stub .t file for syntax errors, I'd be happy to
populate it with TODO tests like the above.
Chris
--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: [perl #39829] [PATCH] accept() always fails
On Jul 14, 2006, at 4:56 AM, Leopold Toetsch wrote: Am Donnerstag, 13. Juli 2006 23:41 schrieb Kay-Uwe Huell: Hi parrot, unfortunatly you fail when I call your accept() op. I have fixed this issue with attached patch. The Parrot documentation can now be accessed at http:// localhost:1234 . accept: errno=22unknown method:'' I don't get that error and I can't see, why changing the (not-reached) diagnostic might fix accept. The httpd.pir has different problems, though, which seem to be protocol-related. leo Kiwi, I also don't experience this error but instead for me httpd.pir fails at bind() [see RT #39738] on Darwin and FreeBSD. On which platform does accept() fail for you? Which C compiler are you using? I agree with Leo that your patch looks suspicious. If you are right that just adding that diagnostic really does fix it, then it sounds like a compiler bug that needs to be reported, or at least documented. Chris P.S. I've been working on some small improvements to httpd.pir, including better failure diagnostics. Please contact me off-list for a patch if you are interested. -- Chris Dolan, Software Developer, http://www.chrisdolan.net/ Public key: http://www.chrisdolan.net/public.key vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: Time for a Revolution
On Jul 14, 2006, at 8:03 PM, chromatic wrote: On Friday 14 July 2006 17:59, Andrew Savige wrote: I thought Chromatic might be the name of chromatic's father or older brother. No, that's Mixolydian and Ionian, respectively. -- c (Yes, of course my mother is Dorian. What were you thinking?) Whoa, this is becoming an unexpectedly educational thread... Chris -- Chris Dolan, Software Developer, http://www.chrisdolan.net/ Public key: http://www.chrisdolan.net/public.key vCard: http://www.chrisdolan.net/ChrisDolan.vcf
ICU advantages? was Re: Problems Installing Parrot
On Jul 21, 2006, at 9:48 AM, Jonathan Rockway wrote: I have downloaded the icu4j_3_4_4.jar but have no idea what to do with it. Could someone please help? You'll want to get icu4c (icu for C), not icu4j (for java). If you get the tgz C version, just tar xzvf it, cd source; ./configure; make; make install. Note that most Linux distros have packages for icu. apt-get install libicu.* will get everything you need on Debian. (On other distros, be sure to install the -dev or -devel pacakages). Anyway, here's where I got it from: ftp://ftp.software.ibm.com/software/globalization/icu/3.4.1/ icu-3.4.1.tgz On a related note, I understand that ICU is recommended but not required for Parrot (right?). After searching in the Parrot docs subdir a couple weeks ago, I couldn't find more than that. Questions: 1) Is there documentation on how ICU relates to Parrot somewhere that I missed? 2) How important is ICU? 3) If I build Parrot without ICU, what repercussions should I expect? This would be a good entry for the FAQs for a cage cleaner. Thanks, Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: FAQ Questions (WAS: ICU advantages? was Re: Problems Installing Parrot)
On Jul 21, 2006, at 1:12 PM, Mr. Shawn H. Corey wrote: Chris Dolan wrote: This would be a good entry for the FAQs for a cage cleaner. If you're collect questions for the FAQ, here are some Andy Lester answered for me: I'm not, actually. :-( Could you do one of the following, in order of preference: 1) Write these up as a patch to the FAQ 2) Write these up as a patch for cage/TODO.pod 3) Submit an RT bug to add these to the FAQ Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Questions
On Aug 1, 2006, at 2:45 PM, Joshua Hoblitt wrote:
While I'd been hoping that M::B had a public method for changing
'blib'
this appears not to be the case (just looking at the pod). If this
functionality were added we could have the root makefile invoke each
module as `perl Build.PL --blib [buildroot/somedir]`, use that path
for
runtime testing, and still let M::B handle the packages own
installation. I admit this scheme is a little hackish but it avoids
having to do a custom setup for each bundled package. Thoughts?
That syntax works:
% perl Build.PL --blib=foobar
Checking whether your kit is complete...
Looks good
Checking prerequisites...
Looks good
Creating new 'Build' script for 'FLV-Info' version '0.11'
% ./Build
lib/FLV/File.pm -> foobar/lib/FLV/File.pm
...
% perl -MModule::Build -le'print Module::Build->VERSION'
0.2801
This also works:
my $mb = Module::Build->new(
...
);
$mb->blib('foobar');
$mb->create_build_script;
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: Perl6 "style-guide"
On Sep 20, 2006, at 6:16 PM, Darren Duncan wrote: At 4:56 PM +0200 9/20/06, Fagyal Csongor wrote: I was wondering if there is (or there should be) a documentation on how to elegantly write Perl6 code. I have found that Damian's "Perl Best Practices" still works very well for Perl 6 code, so I still apply that where reasonably possible. And in fact, I expect that PBP was written to be forward compatible to Perl 6, as it could describe styles that should be natural in Perl 6, even if less so in Perl 5. Does anyone want to start a port of Perl::Critic to Perl6? :-) Chris -- Chris Dolan, Software Developer, http://www.chrisdolan.net/ Public key: http://www.chrisdolan.net/public.key vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: [CAGE] perl coding standards...
On Sep 26, 2006, at 10:21 PM, Will Coleda wrote: I took a first pass at a perlcritic test: t/codingstd/ perlcritic.t ; this test isn't run by default. [snip] Cool! Attached is a patch to simplify this test code a little bit by leveraging Test::Perl::Critic. I also reworked CodeLayout::UseParrotCoda to use current P::C conventions. lib/Perl/Critic/Policy/CodeLayout/UseParrotCoda.pm | 41 +++-- t/codingstd/perlcritic.t | 88 +++ +- 2 files changed, 51 insertions(+), 78 deletions(-) Chris -- Chris Dolan, Software Developer, http://www.chrisdolan.net/ Public key: http://www.chrisdolan.net/public.key vCard: http://www.chrisdolan.net/ChrisDolan.vcf perlcritic.patch Description: Binary data
Re: Emacs/vim code coda placement
On Oct 3, 2006, at 1:29 AM, Paul Cochrane wrote: Hi all, In the process of trying to finish off the perl coda cage task, I notice that the Perl::Critic policy for the emacs/vim coda skips __END__ and __DATA__ sections at the end of perl files, however vim (I don't know about emacs) requires the coda to be within either the first or last 5 lines of the file (by default) for which the editor settings are to be applied, and so if one has a large __END__ or __DATA__ section (not exactly difficult) the coda will be missed by vim. A lot of the time __END__ sections are used for pod, so there is an easy fix for these situations such that the coda can be added without affecting perldoc output namely: put a C<=cut> at the end of the pod, before the coda. However, this doesn't work in all situations, and I believe the coda will add itself to the data in the __DATA__ block, am I correct? In short, the coda needs to be at the end of each of the files, however, not to be included in any present __END__ or __DATA__ blocks; how do we get around this in nice, general way? Thanks heaps in advance, Paul Paul, Good point, I meant to bring this up myself when I was fiddling with lib/Perl/Critic/Policy/CodeLayout/UseParrotCoda.pm I agree that using =cut in __END__ is the right solution. I have no idea how to handle __DATA__ since you can't put an __END__ embedded in a __DATA__ section. If Will Coleda (or someone else) approves the coda-after-__END__ spec change, I'll be happy to code that up in CodeLayout::UseParrotCoda. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [perl #40482] [PATCH] Perl::Critic policy for perl -w, and unix-specific shebang lines
On Oct 9, 2006, at 4:51 AM, Paul Cochrane (via RT) wrote:
# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40482]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40482 >
Hi,
This patch adds a new policy for the Parrot Perl::Critic tests, namely
to check that the shebang line doesn't use 'perl -w', rather 'use
warnings;' and that the shebang line doesn't use something unix
specific such as '#!/usr/bin/perl' and rather '#! perl'. Would it be
a good idea to group all of the code standards-related stuff into a
directory CodeStandards? As such, should I then make a patch for
CodeLayout::UseParrotCoda to go under CodeStandards::UseParrotCoda
instead? I'm also wondering what the policy is on svn Id keywords in
files, and whether or not the svn:keywords property is set to a
particular value. I don't think there's a standard or anything
defined for this yet. Should there be? If so, should I put a request
into RT?
Paul,
A few comments:
* No, this shouldn't go into UseParrotCoda. Separately enabled
policies are more flexible.
* In fact, yours should probably be broken into two policies. Perhaps
CodeStandards::ProhibitShebangWarningsArg
and
CodeStandards::RequirePortableShebang
* This would be a nice addition to core Perl::Critic!
* The -w catcher fails on "#!perl -T -w" or other variations on
argument lists. Perhaps forbid any arguments at all?
* The shebang line is always a PPI::Token::Comment and is always on
the first line. Take a look at this utility function from
Perl::Critic::Utils:
sub is_script {
my $doc = shift;
my $first_comment = $doc->find_first('PPI::Token::Comment');
return if !$first_comment;
return if $first_comment->location()->[0] != 1;
return $first_comment =~ m{ \A \#\! }mx;
}
Now that I'm talking about it, I should write a
Perl::Critic::Utils::get_shebang() function...
Chris
--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: [perl #40482] [PATCH] Perl::Critic policy for perl -w, and unix-specific shebang lines
On Oct 9, 2006, at 11:50 AM, Paul Cochrane wrote: Will, They're all coding standards. I say leave the Coda where it is, and put this in the same grouping as 'use warnings' (i.e. 'TestingAndDebugging'). Ok, see attached patch. This one is still a false negative on "#!perl -Tw" and is a false positive on "package main; #!!! my co-worker provided this non-Perl- licensed code to Parrot!!!". Yes, that's a highly contrived example. :-) But the false positive would be avoidable by checking the line and column number of the element. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [perl #40482] [PATCH] Perl::Critic policy for perl -w, and unix-specific shebang lines
On Oct 10, 2006, at 3:12 AM, Paul Cochrane wrote: * This would be a nice addition to core Perl::Critic! Do you want me to supply a patch for Perl::Critic too, or will the file added to Parrot suffice? That's completely up to you. You seem to have a knack for writing policies, so we'd love to have the help with Perl::Critic. But Parrot is a worthy cause too! :-) If you don't provide a P::C patch, I'll probably do it myself eventually. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [perl #40482] [PATCH] Perl::Critic policy for perl -w, and unix-specific shebang lines
On Oct 10, 2006, at 11:03 AM, Paul Cochrane wrote: I've been playing around for a while with the shebang line tests, and it struck me that the is_script() function will return true on your contrived example. Yeah, I saw that and fixed it in SVN yesterday. :-) It now checks that column == 1 too. Also, the fact that you mention that the shebang should be the first line lead me to think that maybe we could look for misplaced shebang lines, and report an error there as well. I've got a patch for that and can send this in too if you want. Interesting idea. You'll have to ensure it's a PPI::Token::Comment and not a PPI::Token::Quote, for example. Perhaps further discussion should move to the perlcritic.tigris.org dev mailing list or to http://rt.cpan.org/Dist/Display.html?Queue=perl-critic Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [perl #40564] [TODO] fix perlcritic Subroutines::RequireFinalReturn policy
On Oct 18, 2006, at 4:27 PM, Jerry Gay (via RT) wrote: currently, this policy does not ignore subs which exit or die... it forces the addition of a return statement in these subs. yuck. this policy will be disabled until this is fixed. ~jerry Fixed in Perl::Critic svn r737. This will appear in the next release of Perl::Critic. Chris -- Chris Dolan, Software Developer, http://www.chrisdolan.net/ Public key: http://www.chrisdolan.net/public.key vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: [perl #40544] [NEW] Test for DOS line endings in Parrot text files
On Oct 23, 2006, at 7:39 AM, Paul Cochrane wrote:
BEGIN {
eval { use SVN::Client; };
if ($@) {
plan skip_all => 'SVN::Client not installed';
}
}
Paul,
This should be
eval {require SVN::Client; };
use() is a compile-time directive, not runtime.
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: [perl #40596] [CAGE] modify perl coding standard test format
On Oct 25, 2006, at 1:24 PM, Jerry Gay (via RT) wrote: modify perl coding standard test format to match the c tests--one test per standard, rather than one test per file. coding standard tests are designed to test maintainability, not functionality. testing parrot functionality is much more important than testing maintainability--just look at perl 5 :-) inflating test numbers (and percentages) by adding a zillion coding standards tests leads to false perception of test coverage. i'd like very much to avoid this situation. ~jerry Jerry, I fully understand your reasoning, but this is going to slow down the tests. Perl::Critic's overhead comes primarily from parsing each source file, not from checking the standards, so Test::Perl::Critic is oriented to work per-file. Your suggested change goes across the grain for Perl::Critic. Certainly the perlcritic.t can be changed to have just one test -- all files pass all standards, or not -- without a performance penalty, but perhaps that might be too much in the other direction? Chris
Re: [perl #40596] [CAGE] modify perl coding standard test format
On Oct 25, 2006, at 3:23 PM, jerry gay wrote: one overall test for perlcritic is fine with me. there's nothing stopping us from parsing perlcritic output if we want a different format, however i'd rather not go that far. additionally, i'd like to see less verbose output from perlcritic. the thousands of lines of diag output from a single test file is ...distracting. i'm sure it's configurable, but i haven't taken the time to look into it. do you have any quick suggestions, or should i dive into the docs? ~jerry Jerry: * open t/codingstd/perlcritic.t * search for "-format" * look at the below URL for the allowed sprintf-like codes http://search.cpan.org/~thaljef/Perl-Critic-0.2/lib/Perl/Critic/ Violation.pm#OVERLOADS The current format is: -format => '[%p] %m at %l,%c', which yields "[TestingAndDebugging::RequireUseStrict] Code before strictures are enabled at 235,1" If you want to see fewer errors, add -top => 5 after the -format to only show the first 5 violations per .pm file. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [perl #40598] [PATCH] Make perlcritic.t barf more nicely when Test::Perl::Critic not installed
On Oct 26, 2006, at 5:21 AM, Paul Cochrane (via RT) wrote:
this patch ensures that when t/codingstd/perlcritic.t can't find
Test::Perl::Critic, that instead of exiting with a "Can't locate
Test/Perl/Critic.pm in @INC" compile-time error, it reports that it is
skipping the test with the message defined in perlcritic.t.
One can't use C in this case as the C call needs to pass
an argument to the package if Test::Perl::Critic is found.
Comments welcome,
Paul,
A better implementation of that patch would be:
BEGIN {
eval { require Test::Perl::Critic; };
if ($@) {
plan skip_all => 'Test::Perl::Critic not installed';
}
Test::Perl::Critic->import(-verbose => 7);
Chris
Re: [perl #40861] [CAGE] - add a Perl::Critic policy to look for FIXME|TODO|XXX
On Nov 13, 2006, at 8:31 AM, Paul Cochrane (via RT) wrote: # New Ticket Created by Paul Cochrane # Please include the string: [perl #40861] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40861 > The t/codingstd/fixme.t test only looks in C-language files for FIXME|TODO|XXX comments. It would therefore be good for the t/codingstd/perlcritic.t test to check for these comments in the Perl source files. There is a policy on CPAN to do this: http://search.cpan.org/~petdance/Perl-Critic-Bangs-0.22/ ProhibitFlagComments.pm Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)
On Dec 16, 2006, at 12:41 PM, Paul Cochrane via RT wrote: Hi all, We could close this ticket if a decision were made as to whether or not the emacs/vim formatting information can be put at the *beginning* of a file in the case where __END__ or __DATA__ blocks are used within a perl source file. What are people's opinions? Would it be too ugly to put the "coda" at the beginning of the file just after the shebang line? Paul Be aware that you cannot use the verbose form of Emacs settings at the beginning of a file, unless the file is shorter than 3000 bytes. See Perl::Critic::Policy::Editor::RequireEmacsFileVariables policy for more details: http://search.cpan.org/~cdolan/Perl-Critic-More-0.12/lib/Perl/Critic/ Policy/Editor/RequireEmacsFileVariables.pm Chris -- Chris Dolan, Software Developer, http://www.chrisdolan.net/ Public key: http://www.chrisdolan.net/public.key vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)
On Dec 18, 2006, at 1:57 AM, Paul Cochrane wrote: Be aware that you cannot use the verbose form of Emacs settings at the beginning of a file, unless the file is shorter than 3000 bytes. See Perl::Critic::Policy::Editor::RequireEmacsFileVariables policy for more details: So this means we need to put the emacs and vim settings at the end of the file. No, it means that if you want to use the verbose form of Emacs file variables, then it has to be at the end of the file. Vim sets a similar restriction in that its settings should be in the first or last 5 lines. The problem that I'm trying to solve here is: how do we add the settings information to perl language files such that it doesn't cause problems with __END__ and __DATA__ blocks, is testable by perlcritic, emacs *and* vim pick up their settings values, and it doesn't interfere with the visual structure of the file. I've hit a bit of a brick wall in trying to satisfy all these conditions; any ideas as to how we can achieve this? Not really... The only elegany approach is: # -*- parrot -*- and insist that parrot-mode.el be installed. That may annoy some people, but I don't see another way without crufting up the top of the file or requiring that you de-cruft everywhere. Chris -- Chris Dolan, Software Developer, http://www.chrisdolan.net/ Public key: http://www.chrisdolan.net/public.key vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: Kwalitee and Perl::Critic
On Oct 4, 2005, at 1:04 PM, Nik Clayton wrote: I don't have strong opinions about this yet, but has anyone else looked at the Perl::Critic suite of modules on CPAN? It occurs to me that: a) Kwalitee metrics could quite easily be implemented as Perl::Critic plugins. b) The plugins that it ships with (based on Perl Best Practices) may form good kwalitee indicators. As a framework, yes, it has potential for being useful for kwalitee metrics. The PPI foundation that Perl::Critic uses is a very powerful tool for parsing Perl without actually running Perl. Some of the plugins would be good for kwalitee, but many of them are just very well-reasoned opinions. I'm a fan of most of PBP, but many of the ideas are too strict to impose on all of CPAN. Things that PPI/Perl::Critic could judge that might lead to quantitative, non-controversial metrics: * are the variables/functions consistently named? (i.e. all of them in_underscore_style or allInCamelCase) * what's the ratio of globals to subroutines? (smaller is better) * is there a SYNOPSIS section and is it valid Perl? * do OO-style modules bless into a hardcoded package or a passed package name? (former kills subclassing) * are there any undeclared, non-core dependencies? * does the module use Perl 5.6.x+ constructs without declaring "use 5.006"? * does the module use platform directory syntax or portable tools? (e.g. File::Spec, Path::Class) All of these would be very hard to judge without parsing the module. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Kwalitee and Perl::Critic
On Oct 5, 2005, at 6:18 AM, A. Pagaltzis wrote: * what's the ratio of globals to subroutines? (smaller is better) Does that include file-scoped lexicals? ’Cause in that case I disagree – I’m just overhauling a module, in which process I’m also moving it to inside-out object style, and so I’ve got about 20 file-scoped lexical hashes. But that doesn’t at all mean the code is really full of globals. My fault for sloppy terminology -- I did not mean to include lexicals. I meant 'use vars qw(...)' and 'our ...' variables specifically. Chris -- Chris Dolan, Software Developer, www.chrisdolan.net Public key: http://www.chrisdolan.net/public.key
Proposed Kwalitee tests: has_license and/or has_meta_yml_license
In the last year as a Fink maintainer (Mac OS X debian-like package manager), I've come across a couple CPAN modules that have no license information at all. It's very frustrating. I've submitted RT bugs, but one of them has been fixed (thanks Ken Williams). To encourage authors to correct this oversight, I propose a new pair of Kwalitee tests. Both would be nice, but if either of them were implemented, I'd be thrilled. I'd prefer that someone else implement the test (lack of tuits), but if there is approval for the idea without a motivated implementer I will take a hack at it. 1) has_license -- check for the presence of a file named something like LICENSE or COPYING or COPYLEFT or GPL or ... (each test case insensitive, with or without .txt extensions). Alternatively, the test can be more liberal by looking for the string "copyright" in README, *pm and *.pod. 2) has_meta_yml_license -- check for a META.yml field named "license". Module::Build supports this. These tests should not care which license is claimed, just that there is a license present. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Devel::Cover not DWIMming on upgraded Perl -- but problem solved
James,
The explanation is that D::C saves a copy of your @INC at build time
in a .pm and subsequently uses that list to filter out the code perl
libraries. That @INC probably had some /5.8.4/ subdirs in it. With
the new Perl, the @INC now has /5.8.7/ subdirs and those aren't being
filtered.
When I first discovered that detail, I thought "Why can't D::C just
look at @INC at runtime?" The answer, of course, is that you've
probably changed @INC with -Mblib or -Ilib or 'use lib qw(.);' or
something. So, there has to be a pristine @INC to reference.
I haven't fully thought this out, but it seems to me that some
combination of @INC from %Config and $ENV{PERL5LIB} should cover
pretty much all of core, so perhaps D::C can do away with the hard-
coded @INC filter list in the future?
Chris
On Nov 1, 2005, at 7:25 PM, James E Keenan wrote:
When I began to write this posting, it was to get an answer to a
question. But I figured out a workaround halfway through, so now
I'm posting an answer.
I have happily been using Devel::Cover for more than a year on Perl
5.8.4 on Darwin (Mac OS X 10.3). Recently I upgraded to Perl
5.8.7. Tonight I went to use Devel::Cover (v0.55, as previously)
for the first time since that Perl upgrade. At first, it no longer
DWIMmed. Specifically:
1. When I ran 'make test HARNESS_PERL_SWITCHES=MDevel::Cover', I
got this message:
t/01_test..
This version of Devel::Cover was built with Perl version 5.008004.
It is now being run with Perl version 5.008007.
Attempting to make adjustments, but you may find that some of
your modules do
not have coverage data collected. You may need to alter the +-
inc, +-ignore
and +-select options.
t/01_test..ok
I'd never had to set these options before; previously, D::C just
worked. Also, D::C took much longer to run.
2. I was testing coverage of a new module I'm developing called
File::Save::Home. When I called 'cover', I got a report on this
module, but also on every core module as well:
[snip]
-- -- -- -- --
-- --
File stmt bran condsubpod
time total
-- -- -- -- --
-- --
...perl5/5.8.7/AutoLoader.pm0.00.00.00.00.0
n/a0.0
...l/lib/perl5/5.8.7/Carp.pm0.00.00.00.00.0
n/a0.0
...erl5/5.8.7/Digest/base.pm0.00.0n/a0.00.0
n/a0.0
...b/perl5/5.8.7/Exporter.pm 50.0 57.1 44.7 33.30.0
0.3 44.8
...5/5.8.7/Exporter/Heavy.pm 10.48.8 12.5 11.10.0
0.19.8
...l5/5.8.7/File/Basename.pm 28.2 25.87.7 50.0 100.0
0.1 27.8
[snip]
8.7/warnings/register.pm 100.0 50.0n/a 100.00.0
0.1 89.5
blib/lib/File/Save/Home.pm 77.1 44.4n/a 100.0 100.0
0.3 73.4
Total 10.86.24.3 12.3 14.0
100.09.0
-- -- -- -- --
-- --
Writing HTML output to
/Users/jimk/work/fsh/File-Save-Home/cover_db/coverage.html ...
done.
This problem of excessive output is the same one I typically
experience using D::C (v0.47, I believe) on Windows. This is much
more output than I want or need.
I hypothesized that if I were to upgrade to a new version of D::C,
it would be compiled against Perl 5.8.7 and these problems might go
away. But 'cpan' did nothing because it detected that I was using
the most recent version of D::C.
So I downloaded the latest version of Devel::Cover from CPAN and
installed it manually. (I did call 'make install UNINSTALL=1'.)
This solved the problem. The message described above went away,
and 'cover' reported only the results for the module under
development.
Jim Keenan
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: Proposed Kwalitee tests: has_license and/or has_meta_yml_license
On Nov 2, 2005, at 10:19 AM, David Landgren wrote: Chris Dolan wrote: In the last year as a Fink maintainer (Mac OS X debian-like package manager), I've come across a couple CPAN modules that have no license information at all. It's very frustrating. I've submitted RT bugs, but one of them has been fixed (thanks Ken Williams). To encourage authors to correct this oversight, I propose a new pair of Kwalitee tests. Both would be nice, but if either of them were implemented, I'd be thrilled. I'd prefer that someone else implement the test (lack of tuits), but if there is approval for the idea without a motivated implementer I will take a hack at it. 1) has_license -- check for the presence of a file named something like LICENSE or COPYING or COPYLEFT or GPL or ... (each test case insensitive, with or without .txt extensions). Alternatively, the test can be more liberal by looking for the string "copyright" in README, *pm and *.pod. 2) has_meta_yml_license -- check for a META.yml field named "license". Module::Build supports this. That would suck, you may as well propose a Kwalitee bit for modules that use Module::Build. I know that the current alpha of ExtUtils::MakeMaker supports this, but until it is released as stable *and* module authors have the time to upgrade EU::MM *and* release a new version of their module (s), those authors will be penalised through no fault of their own. David What penalty? The whole point of Kwalitee is not to reward authors who jump through hoops, but to encourage authors to live up to community expectations. That includes good packaging, good POD and, I say emphatically, clear licensing. Anything we can do to encourage authors to more clearly state their license is a good thing. If that in turn means encouraging them to 1) use Module::Build, 2) upgrade EU::MM or 3) hand-edit META.yml, then I think that's a burden worth bearing. You're complaining that its too big a burden to clearly state your module's license? To me that's just crazy. To some people, the license is actually more important than the module (e.g. if I can only redistribute Artistically license code). After all, Kwalitee is not an entrance barrier to CPAN. It's a tool to let authors know what is important to the rest of us. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Proposed Kwalitee tests: has_license and/or has_meta_yml_license
On Nov 2, 2005, at 12:13 PM, David Landgren wrote: No. I'm complaining that there's no need for two different Kwalitee points for this, that's all. I think one is sufficient (and a very worthy one I should add, in case I wasn't being clear, which I probably wasn't). Ahh, that was unclear from your message. I thought you were protesting the addition of a new Kwalitee test in general, hence my annoyance. Apologies for the misunderstanding. I originally advocated for one of the two methods of determining the license, not necessarily for both. Chris P.S. On a marginally-related note, I released Module::License::Report yesterday. Unfortunately, it's not immediately useful for Kwalitee because it eval()s code from Makefile.PL and/or Build.PL, and makes use of Module::Depends::Intrusive which does more of the same. -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: How to force tests to issue "NA" reports?
On Apr 6, 2005, at 7:13 AM, Robert Rothenberg wrote: Is there a way tests to determine that a module cannot be installed on a platform so that CPANPLUS or CPAN::YACSmoke can issue an "NA" (Not Applicable) report? CPANPLUS relies on module names (e.g. "Solaris::" or "Win32::") but that is not always appropriate in cases where a module runs on many platforms except some that do not have the capability. There's also a separate issue of whether "NA" reports should be issued if a library is missing. (Usually these come out as failures.) Regards, Rob (Co-author of CPAN::YACSmoke) It won't help you *today* but there is a proposed META.yml field called "excludes_os" which fits your request perfectly. http://module-build.sourceforge.net/META-spec-new.html#excludes_os See also "optional_features.foo.excludes_os" http://module-build.sourceforge.net/META-spec-new.html#recommends Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) PGP.sig Description: This is a digitally signed message part
Re: [perl #39738] [BUG] bind fails with errno EADDRNOTAVAIL on darwin and FreeBSD
On Jul 22, 2008, at 6:35 PM, Christoph Otto via RT wrote: On Thu Jul 06 09:21:34 2006, [EMAIL PROTECTED] wrote: With parrot r13181, binding to a non-privileged port on localhost consistently fails with EADDRNOTAVAIL on Mac OS X and FreeBSD boxes for Intel and PPC platforms. The same command succeeds on Linux. Steps to reproduce: 1) ./parrot examples/io/httpd.pir 2) netstat -na | grep 1234 | grep LISTEN Actual results: Socket is not bound Expected results: "netstat -na" should contain a line like this: tcp0 0 127.0.0.1:1234 0.0.0.0:* LISTEN This no longer fails on a FreeBSD 7.0 vm. It'd be nice to confirm that it also works on Darwin, but I'll plan on marking this resolved in a few days if there are no objections. Christoph It works for me too on Mac OSX 10.4 and parrot rev 29370. Thanks for following up! Chris
Assigning and passing $/
I'm learning about Match objects today. I can't assign $/ to a
variable or pass it to a method. Is this a bug, or am I just
confused? I get the following results. In both cases, $/ gets
stringified instead of remaining as a Match instance.
% ./perl6 -e 'if ("f" ~~ m/f/) { my Match $m = $/; }'
Type check failed
current instr.: 'parrot;Perl6Object;infix:=' pc 60 (src/
gen_builtins.pir:52)
called from Sub '_block21' pc 328 (EVAL_13:131)
called from Sub '_block11' pc 46 (EVAL_13:20)
called from Sub 'parrot;PCT;HLLCompiler;eval' pc 864 (src/PCT/
HLLCompiler.pir:498)
called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1355 (src/
PCT/HLLCompiler.pir:725)
called from Sub 'parrot;Perl6;Compiler;main' pc 17077 (perl6.pir:179)
or
% ./perl6 -e 'sub foo(Match $m) { say $m; }; if ("f" ~~ m/f/) { foo
($/); }'
Parameter type check failed
current instr.: 'die' pc 13235 (src/gen_builtins.pir:8178)
called from Sub '!TYPECHECKPARAM' pc 14145 (src/gen_builtins.pir:8725)
called from Sub 'foo' pc 144 (EVAL_14:59)
called from Sub '_block43' pc 470 (EVAL_14:177)
called from Sub '_block11' pc 46 (EVAL_14:20)
called from Sub 'parrot;PCT;HLLCompiler;eval' pc 864 (src/PCT/
HLLCompiler.pir:498)
called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1355 (src/
PCT/HLLCompiler.pir:725)
called from Sub 'parrot;Perl6;Compiler;main' pc 17077 (perl6.pir:179)
% ./perl6 -v
This is Rakudo Perl 6, revision 32120 built on parrot 0.8.0-devel
for darwin-thread-multi-2level.
Argument scoping error or bug?
I stumbled across this issue while descending into a recursive Match
structure. Consider the following reentrant subroutine:
sub f($n) {
for 0..$n -> $i {
say "$i of 0..$n";
if ($i == 4) {
f(0);
}
}
};
f(6);
The value of the argument, $n, gets overwritten on reentry.
0 of 0..6
1 of 0..6
2 of 0..6
3 of 0..6
4 of 0..6
0 of 0..0
5 of 0..0
6 of 0..0
The last two lines of output should say "0..6" not "0..0".
Am I supposed to making the sub argument lexical?
sub f(my $n) { ... }
But Rakudo doesn't like that syntax.
Chris
Precompilation to PIR
How safe is it today to pre-compile Rakudo code to PIR and expect that to behave identically to as if I compiled from .pm at runtime? I believe PCT is just generating PIR anyway, so my initial guess is that there should be no differences. Are there any gotchas, like compile-time dependency checks, that I should look out for? I just added the following to my project Makefile attempting to tighten my code-compile-test loop: PIR = $(shell ls lib/*.pm t/*.pm | sed s/pm/pir/) prebuild: $(PIR) %.pir: %.pm $(PERL6) --target=pir --output=$@ $< Should I go further and try to compile to PBC? Chris
Why {{}} for regexp closures instead of just {}?
S05 always uses single curlies for closures, but throughout Parrot,
code seems to use double curlies in PGE regexps. Why is that?
That is, why this:
m/ foo {{ say "found foo" }} /
and not this:
m/ foo { say "found foo" } /
The latter complains about "Statement not terminated properly".
Chris
Re: Precompilation to PIR
On Oct 27, 2008, at 3:07 AM, Carl Mäsak wrote: Chris (>): How safe is it today to pre-compile Rakudo code to PIR and expect that to behave identically to as if I compiled from .pm at runtime? I believe PCT is just generating PIR anyway, so my initial guess is that there should be no differences. Are there any gotchas, like compile-time dependency checks, that I should look out for? Precompilation to PIR currently doesn't work in the November project -- the difficulties occur when trying to call methods in the precompiled module. Right now our Makefile protests if someone tries to compile the modules to PIR. I think there is an rt ticket for this, but my attempts to dig it up fail. Maybe someone else is more lucky. // Carl Good to know. My tests were passing as PIR-compiled, but I only tested my grammar so far before I got roadblocked. I'll keep testing with and without PIR as time permits. Thanks! Chris
Invoking PGE closures as Rakudo code
Earlier, I sent in a patch for PGE to support S05-style single-curly
closures (RT#60186). The next thing I'm trying to do is to get this
to work:
./perl6 -e '"" ~~ m/:lang(Perl6) { say "hi" }/'
The PIR version works perfectly:
./perl6 -e '"" ~~ m/:lang(PIR) { say "hi" }/'
Out of the box, the Perl6 version fails like this:
invoke() not implemented in class 'Perl6::Compiler'
current instr.: '_block17_corou' pc 209 (EVAL_11:87)
called from Sub '_block17' pc 84 (EVAL_11:40)
called from Sub 'parrot;Code;ACCEPTS' pc 5402 (src/
gen_builtins.pir:3517)
called from Sub '_block11' pc 28 (EVAL_11:14)
called from Sub 'parrot;PCT;HLLCompiler;eval' pc 864 (src/PCT/
HLLCompiler.pir:498)
called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1355 (src/
PCT/HLLCompiler.pir:725)
called from Sub 'parrot;Perl6;Compiler;main' pc 17089 (perl6.pir:184)
I edited perl6.pir to add this debug code:
.sub 'invoke' :vtable :method
say 'invoke called'
.return ()
.end
so now I get:
./perl6 -e '"" ~~ m/:lang(Perl6) { say "hi" }/'
invoke called
invoke called
as expected (well, I don't understand why it's doubled, but I'm happy
that it's called). But I'm still a novice and I can't figure out the
next step. I know that this code is being called from code generated
in the [PGE;Exp;Closure;'pir'] method in compilers/pge/PGE/Exp.pir,
and the closure $P1 is being invoked like so:
($P0 :optional, $I0 :opt_flag) = $P1(mob)
I think "mob" is the default Match instance, aka $/. It looks like
$I0 is a boolean indicating whether the closure has significance to
the match (true) or is pure side effect (false). It also looks like
$P0 is the 'make' result for the closure. But, I'm not really sure
I'm interpreting that code correctly.
Can anyone offer some advice on how I should write the 'invoke'
method? My goal is to build arbitrarily complex data structures from
closures fired in my grammar. Specifically, I'm trying to write a
PDF parser -- my grammar is parsing correctly now, but I'd rather not
have to write the closures in PIR if I can help it.
Chris
Re: Invoking PGE closures as Rakudo code
On Oct 28, 2008, at 10:06 AM, Patrick R. Michaud wrote:
On Tue, Oct 28, 2008 at 01:50:42AM -0500, Chris Dolan wrote:
My goal is to build arbitrarily complex data structures from closures
fired in my grammar. Specifically, I'm trying to write a PDF
parser --
my grammar is parsing correctly now, but I'd rather not have to
write the
closures in PIR if I can help it.
Would it make sense to use action methods (the "{*}" tokens) for the
closures instead of embedding them directly into the grammar?
Pm
Certainly, yes, but my goal was to learn, not to be productive. :-)
The "{*}" notation is not part of S05, so I thought I'd try to see
what was possible with real Perl6 and embedded closures. I did
indeed learn a lot!
But since you've said that PGE is getting an overhaul, I'll stow my
patches and wait.
Chris
Re: Invoking PGE closures as Rakudo code
On Oct 28, 2008, at 10:06 AM, Patrick R. Michaud wrote:
On Tue, Oct 28, 2008 at 01:50:42AM -0500, Chris Dolan wrote:
My goal is to build arbitrarily complex data structures from closures
fired in my grammar. Specifically, I'm trying to write a PDF
parser --
my grammar is parsing correctly now, but I'd rather not have to
write the
closures in PIR if I can help it.
Would it make sense to use action methods (the "{*}" tokens) for the
closures instead of embedding them directly into the grammar?
Pm
Taking the {*} approach with the actions written in Perl6 instead of
NQP (or PIR) turned out to be significantly harder than I expected,
largely because I'm using a straight Perl6 grammar instead of PCT and
HLLCompiler. I encountered three problems, both solved temporarily:
1) how to tell Perl6 which action class to use, 2) how to get my
$/.result_object back, and 3) how to keep from blowing away my
overridden match object.
=== begin gory details ===
The Grammar.ACCEPTS nor Code.ACCEPTS methods don't pass an action
adverb to the PGE subrule, and there doesn't seem to be a way to set
a default action on a grammar. So, I changed my test code from this:
'1 0 R' ~~ PDF__Grammar::pdf_reference;
is(~$($/).WHAT, 'PDF__Syntax__Reference'); # fails, got 'Str'
because the action is not invoked
to the following, to force the action class:
my $method = PDF__Grammar::pdf_reference;
my $m = '1 0 R'.$method(action => PDF__Grammar__Actions.new);
is(~$m.WHAT, 'PDF__Syntax__Reference'); # succeeds
where my action looks like this:
class PDF__Grammar__Actions {
method pdf_reference($m) {
my $ref = PDF__Syntax__Reference.new(objnum => +
$m, gennum => +$m);
$m.result_object($ref);
return;
}
}
grammar PDF__Grammar {
rule pdf_reference { R {*} };
}
I found that a bit confusing because: a) because I'm invoking the
subrule directly, $/ is not getting set and b) assigning back to $m
at the end apparently calls get_scalar() on the Match instance, so it
is dereferenced to get my result_object instead. Unexpected, but
convenient. I might wrap it in a superfluous $() in case that
get_scalar() is ever changed.
In retrospect, if I had been matching against the whole grammar
instead of the subrule, my second problem would not have happened
because Grammar.ACCEPTS sets $/.
The third problem was because I had whitespace between the {*} and
the terminal } of the rule. That overrode $/ until I cuddled my
rule like "rule pdf_reference { R {*}};" Is there
an easy way to make my white space non-capturing? I'm sure I'm just
overlooking something...
=== end gory details ===
So, I have two change proposals. I'm not sure if either of them are
good ideas...
1) Make grammar rules be type Rule instead of Method, and add a
custom ACCEPTS that behaves like Grammar.ACCEPTS.
2) Add a Parrot-specific adverb to the Perl6 "grammar" declaration
to allow programmers to specify a default action class for the whole
grammar.
And bug reports:
1) Perl6 mangles Match instances when they are assigned to scalars
2) The rules incorrectly require a closing ";" to avoid a syntax error
I'm happy to write up concise ticket for any of those if they aren't
insane or already known.
Chris
Re: Argument scoping error or bug?
On Oct 27, 2008, at 2:07 PM, Patrick R. Michaud wrote: On Sat, Oct 25, 2008 at 10:52:13AM +0200, Moritz Lenz wrote: You have just experienced this bug: http://rt.perl.org/rt3/Ticket/Display.html?id=58392 "Recursion and for loops interact badly in Rakudo". Patrick is working on it. That said, I'm also looking for others to help work on it. But it's not a pretty bug, and it's deeply embedded in Parrot internals. :-) I expect the answer is "not really", but is there anything that a motivated novice like me can do to help? I switched to the "lex" branch and looked at the changes you've made (svn diff -r32136:HEAD), but I also see that it's not in a working state right now (./perl6 - e"say 'Hello, world.'" => Lexical '$/' not found) Tip jar? Chris
"::" in namespaces
Thanks to Jonathan for working on the :: bug. I'm still having
problems, however. The code below worked before I switched all of my
"__" class separators to "::". I'm not sure how to tell whether it's
failing to find my .pm (I moved the .pm from lib/
PDF__Grammar__Actions.pm to lib/PDF/Grammar/Actions.pm at the same
time) or if there's a lingering flaw in the namespace code.
What SVN revision did that change go in? In r32354 on Mac 10.4 ppc
I'm getting:
invoke() not implemented in class 'Undef'
The Perl6 code that triggers that looks like this:
method is_string(Str $src, Str $expected, Str $msg) {
my $method = PDF::Grammar::literal_string;
my $m = $src.$method(:action(PDF::Grammar::Actions.new));
is($m, $expected, $msg) || diag("got: $m, expected: $expected");
}
and the corresponding PIR is:
find_lex $P111, "$src"
unless_null $P111, vivify_19
new $P111, "Perl6Scalar"
vivify_19:
get_hll_global $P112, ["PDF";"Grammar"], "Actions"
unless_null $P112, vivify_20
new $P112, "Failure"
vivify_20:
$P113 = $P112."new"()
$P114 = $P111.$P110($P113 :named("action")) # <-- this line fails
Thanks,
Chris
Re: "::" in namespaces
Replying to myself: I think the flaw is in my use of
"PDF::Grammar::literal_string" as a method pointer. This worked fine
when it was "PDF__Grammar::literal_string", but now the following PIR:
get_hll_global $P108, ["PDF";"Grammar"], "literal_string"
is returning undef. The answer appears to be that the PIR for PDF/
Grammmar.pm includes this:
.namespace ["PDF::Grammar"]
.sub "literal_string" :method
instead of
.namespace ["PDF";"Grammar"]
.sub "literal_string" :method
So, does that mean teaching PGE/Exp.pir about double-colon
separators? Or does namespace separator need to be some sort of
compreg flag?
Chris
On Nov 4, 2008, at 9:10 PM, Chris Dolan wrote:
Thanks to Jonathan for working on the :: bug. I'm still having
problems, however. The code below worked before I switched all of
my "__" class separators to "::". I'm not sure how to tell whether
it's failing to find my .pm (I moved the .pm from lib/
PDF__Grammar__Actions.pm to lib/PDF/Grammar/Actions.pm at the same
time) or if there's a lingering flaw in the namespace code.
What SVN revision did that change go in? In r32354 on Mac 10.4 ppc
I'm getting:
invoke() not implemented in class 'Undef'
The Perl6 code that triggers that looks like this:
method is_string(Str $src, Str $expected, Str $msg) {
my $method = PDF::Grammar::literal_string;
my $m = $src.$method(:action(PDF::Grammar::Actions.new));
is($m, $expected, $msg) || diag("got: $m, expected: $expected");
}
and the corresponding PIR is:
find_lex $P111, "$src"
unless_null $P111, vivify_19
new $P111, "Perl6Scalar"
vivify_19:
get_hll_global $P112, ["PDF";"Grammar"], "Actions"
unless_null $P112, vivify_20
new $P112, "Failure"
vivify_20:
$P113 = $P112."new"()
$P114 = $P111.$P110($P113 :named("action")) # <-- this line
fails
Thanks,
Chris
Re: "::" in namespaces
Aha, this was already reported as
[perl #60358] Rakudo doesn't recognize grammars with :: in the name
I added my thoughts to that ticket.
Chris
On Nov 5, 2008, at 12:36 AM, Chris Dolan wrote:
Replying to myself: I think the flaw is in my use of
"PDF::Grammar::literal_string" as a method pointer. This worked
fine when it was "PDF__Grammar::literal_string", but now the
following PIR:
get_hll_global $P108, ["PDF";"Grammar"], "literal_string"
is returning undef. The answer appears to be that the PIR for PDF/
Grammmar.pm includes this:
.namespace ["PDF::Grammar"]
.sub "literal_string" :method
instead of
.namespace ["PDF";"Grammar"]
.sub "literal_string" :method
So, does that mean teaching PGE/Exp.pir about double-colon
separators? Or does namespace separator need to be some sort of
compreg flag?
Chris
On Nov 4, 2008, at 9:10 PM, Chris Dolan wrote:
Thanks to Jonathan for working on the :: bug. I'm still having
problems, however. The code below worked before I switched all of
my "__" class separators to "::". I'm not sure how to tell
whether it's failing to find my .pm (I moved the .pm from lib/
PDF__Grammar__Actions.pm to lib/PDF/Grammar/Actions.pm at the same
time) or if there's a lingering flaw in the namespace code.
What SVN revision did that change go in? In r32354 on Mac 10.4
ppc I'm getting:
invoke() not implemented in class 'Undef'
The Perl6 code that triggers that looks like this:
method is_string(Str $src, Str $expected, Str $msg) {
my $method = PDF::Grammar::literal_string;
my $m = $src.$method(:action(PDF::Grammar::Actions.new));
is($m, $expected, $msg) || diag("got: $m, expected:
$expected");
}
and the corresponding PIR is:
find_lex $P111, "$src"
unless_null $P111, vivify_19
new $P111, "Perl6Scalar"
vivify_19:
get_hll_global $P112, ["PDF";"Grammar"], "Actions"
unless_null $P112, vivify_20
new $P112, "Failure"
vivify_20:
$P113 = $P112."new"()
$P114 = $P111.$P110($P113 :named("action")) # <-- this line
fails
Thanks,
Chris
Re: "::" in namespaces
On Nov 5, 2008, at 9:41 PM, Patrick R. Michaud wrote:
On Tue, Nov 04, 2008 at 09:10:02PM -0600, Chris Dolan wrote:
The Perl6 code that triggers that looks like this:
method is_string(Str $src, Str $expected, Str $msg) {
my $method = PDF::Grammar::literal_string;
... just a point of syntax (which probably doesn't resolve the
issue you're having), but "PDF::Grammar::literal_string" above
gets treated like a listop call instead of a method reference.
To get the method itself, we probably need an ampersand in front.
I'm still looking into the other details of the problem you're having.
Pm
Actually, I just submitted a one-line patch to the Rakudo actions.pm
via RT 60358 that solves this problem. I got a big boost from the
namespace fix Jonathan did this week.
It sure behaves like a method reference... Anyway, I didn't actually
*want* the method. Rakudo wouldn't let me do the perl5ish external-
package-method-call syntax like this:
my $m = $src.PDF::Grammar::literal_string(...);
so I had to break it up into two statements
my $method = PDF::Grammar::literal_string;
my $m = $src.$method(...);
which works. I can't explain why I didn't need the ampersand.
Lucky, I guess. It'll probably break when someone fixes that bug. :-)
Chris
Numify
In "[perl #60350] [TODO] default __get_string method", Patrick added a default Object.Str() that classes can override to get custom stringification. Formerly, you could do that only by defining a method named __get_string(). Currently, you can overload number context by creating a __get_number () method and boolean context via __get_bool(). Should there be an analogous Num() and Bool() method on Object? Would it Num() return 0 by default? And a default Bool() that returns True? The Failure class would override negatively, and the container classes could override Num() Is this making life harder by making two methods to override, Str() and __get_string, Num() and __get_number(), Bool() and __get_bool()? Maybe instead Str(), Bool(), Num() should be magic and automatically get a :vtable tag via actions.pm? Then maybe we could drop the __get_* counterparts? I'd be happy to implement if someone would comment on the best approach. Chris
flagging compiler-generated code
I'm thinking ahead to the Parrot equivalent of Perl::Critic, which I
hope will someday be able to analyze arbitrary .pbc files. One
problem I foresee is that there seems to be no way to distinguish
anonymous subs ("my $f = sub { 1 };") from inner blocks. Both
compile down to something like this:
.sub "_block16" :anon :lexid("23") :outer("21")
Would it be feasible to add a new PIR adverb to mark anonymous
methods invented by the compiler so we can easily tell them apart
from anonymous methods invented by the programmer? In Java, the
former get isSynthetic=true, which makes it easier to suppress
complaints about code violations in code out of the programmer's
control.
Chris
Re: flagging compiler-generated code
> On Tue, Nov 11, 2008 at 11:03:09PM -0600, Chris Dolan wrote:
>> I'm thinking ahead to the Parrot equivalent of Perl::Critic, which I
>> hope will someday be able to analyze arbitrary .pbc files. One problem
>> I
>> foresee is that there seems to be no way to distinguish anonymous subs
>> ("my $f = sub { 1 };") from inner blocks. Both compile down to
>> something
>> like this:
>> .sub "_block16" :anon :lexid("23") :outer("21")
>>
>> Would it be feasible to add a new PIR adverb to mark anonymous methods
>> invented by the compiler so we can easily tell them apart from anonymous
>> methods invented by the programmer?
>
> I'm having trouble understanding "anonymous methods invented by
> the compiler" in this context, probably because in a Perl 6
> sense I don't think of inner blocks as being "invented" by the
> compiler. They're right there in the code where the programmer
> wrote them.
>
> Perhaps you could clarify what you mean by "inner block" here?
>
> Pm
Sorry, I'm having trouble finding the right vocabulary. The following
should make more sense:
Both of the following code snippets result in a PIR .sub that is annotated
as :anon
if True {
say 'Hello';
}
vs.
my $f = {
say 'Hello';
}
The former results in a trivial entry in the call graph (exactly one
caller) while the latter can cause arbitrarily complexity in the call
graph. So, a static analysis tool has to work much harder on the latter.
I thought it would be a useful shortcut if the compiler would add a flag
to help distinguish the two cases, so I wouldn't have to include the first
example above in the call graph at all.
Chris
PGE HLLMapping
I've been thinking a lot about how PGE implements closures. Right
now, the closures are a bit rough -- PGE does heuristic look-ahead to
find the end of the closure, saves off the code as a string, and
compiles it at runtime like an eval. To make the heuristic look-
ahead work, PGE insists that closures must be bound by "{{...}}"
instead of "{...}" as Larry has specified. The problems are 1) you
don't find syntax errors at compile time, 2) you need a cache to keep
the compiler from being re-invoked after every match, 3) PIR is
implemented as a special case.
Patrick has mentioned several times that the proper solution to the
problem is a representation of the high-level language that PGE can
interact with. My thoughts about that HLL mapping:
1) we should invoke the other language's compiler at compile-time and
generate an anonymous PIR .sub
a) a special version of the compiler that just parses a block,
rather than a whole program (for Perl6 for example, I think the
distinction is irrelevant)
b) the returned PIR might have several subs. In this case, the
anonymous one will typically be short and will invoke the others
--> so there should be two return values: the library and the
entry point
2) the other language should be represented as an object which can:
a) parse a block
b) pre-process that block to insert boilerplate (see PIR_closure
in PGE::Perl6Regex today) for the anonymous entry point
I thought about co-opting the PGE :lang adverb, which is currently a
string representing the compreg name. If that were optionally a
PGE::HLLMapping instance, then we could conditionally invoke some of
the behavior described above.
Remaining questions:
1) what's the namespace of the generated code?
2) how do we handle languages where embedded code blocks are not
equivalent to whole programs? Do we subclass the grammar and redefine
TOP to be a statement block?
Chris
Re: [perl #60674] sign($x) always returns 1 when $x ~~ Complex
> Mark (>): >> I think the most sensible thing is to be consistent. sgn() fails for >> non-real input as long as sqrt() returns NaN for negative input. >> Change the latter behavior (via a pragma or whatever) so that sqrt() >> returns complex numbers, and then sgn() should start behaving on such >> numbers. > > I like that. Both sign() and sqrt() will then behave like they usually > do, without complex surprises. But for those who want the generalized > behvaiour, it's only a pragma away. > > // Carl Rather than a pragma, wouldn't it make more sense to have multi sub sgn(Num) -> Num multi sub sqrt(Num) -> Num behave appropriately for real numbers and multi sub sgn(Complex) -> Complex multi sub sqrt(Complex) -> Complex behave appropriately for complex numbers? So people who want sqrt(-1) be return i must pass in Complex.new(-1,0) or whatever the right syntax is.
bytes, lazy strings and zlib
In my ongoing quest to create a PDF parser in Perl6, I have some Rakudo/PGE/parrot questions. These are low-urgency and some of these may not be implemented yet... 1) byte orientation PDF's syntax is inherently an 8-bit ASCII superset. Some subsections may be interpreted as some multi-byte encoding or even binary, but low-level parsers can safely work solely in the string-as-byte-array domain. How do I make a grammar work on bytes instead of chars? Is that a property of the $.target string? 2) file as lazy string PDF files are largely random access, but individual segments have arbitrary lengths. Rather than slurping in the whole file or guessing at segment lengths, I'd like to emulate a string via a wrapper around a seekable file, and then apply my grammar to that fake string. I think I can accomplish this by subclassing PGE::Match and override new(), text() and item() appropriately. text() would seek to appropriate locations in the file and buffer chunks at a time. From there, I could substr the desired passages. Does anyone know any implementation details that would make this lazy- string approach work or not work? Has someone tried this? It seems like the runtime/parrot/library/Stream classes parallel what I want to accomplish. 3) gzip Has anyone worked on a zlib interface? Thanks, Chris
Re: [perl #61308] rule's capture ws
On Dec 13, 2008, at 3:44 AM, Moritz Lenz wrote:
Martin Kjeldsen (via RT) wrote:
# New Ticket Created by Martin Kjeldsen
# Please include the string: [perl #61308]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=61308 >
When using rules at least with overwritten, the rule also
captures
whitespace. Please see attached file for example.
You're right that there's a bug, but the real issue is that 'token
ws {
... }' isn't used by implicit <.ws> in rules yet:
grammar A {
token ws { 'a' };
rule b {x y};
};
if 'xab' ~~ m/ ^ $/ {
say "match";
} else {
say "no match";
}
# output: no match\n
Thank you for your report,
Moritz
In which case, the root cause may be the same as
[perl #57864] Calling a token "text", "null" or "ws" in Rakudo
makes matching fail
Chris
Re: [perl #63086] [BUG] can't declare class after deeper-namespace class declared
Ahh, It looks like my report below is a duplicate of
[perl #62898] Rakudo can't handle A declared after A::B was
declared in an included module
Sorry about that...
Chris
On Feb 7, 2009, at 4:10 PM, perl6 via RT wrote:
Consider the following two files:
--- Foo/Bar/Baz.pm ---
class Foo::Bar::Baz {
}
--- Foo/Bar.pm ---
use Foo::Bar::Baz;
class Foo::Bar {
}
When you load Foo::Bar, you get:
Re-declaration of type Foo::Bar at line 4, near ""
I think this is because 'use'ing Foo::Bar::Baz vivifies the Foo::Bar
package. This error does NOT happen if the two classes are declared
in the same file, presumably a compiletime-vs-runtime difference.
This problem began sometime in the last month.
Re: [perl #62898] Rakudo can't handle A declared after A::B was declared in an included module
The following reproduces the bug more simply:
perl6 -e 'BEGIN {class Foo::Bar::Baz {}}; class Foo::Bar {}'
I'm working on a patch at the Frozen Perl hackathon now...
Re: [perl #62898] Rakudo can't handle A declared after A::B was declared in an included module
I wrote a simple solution that works, but I'd like someone more PIR- savvy to improve it. http://github.com/chrisdolan/rakudo/tree/package-redeclaration (5d6cec9) --- a/src/parser/methods.pir +++ b/src/parser/methods.pir @@ -30,8 +30,11 @@ Registers a type in the namespace. # Check if the symbol already exists in the NS; if so we record it as # an existing type. $P0 = get_hll_global ns, short_name -unless null $P0 goto type_exists +if null $P0 goto no_namespace +$S0 = typeof $P0 +unless $S0 == 'NameSpace' goto type_exists + no_namespace: # Work outwards to find a block defining a package and put the type # there. XXX This makes it too visible for lexical types, but if we # assume lexical rather than package scope then we will fail various
{*} and actions
1) Will the "{*}" syntax to invoke an external action method from
within a grammar be an official part of the language, or an
implementation hack?
2) If it becomes official, how should people specify the action class/
instance to be used with a grammar?
Currently in Rakudo, I use the following deprecated hack:
my $method := &My::Grammar::TOP;
my $match := $str.$method(:action(My::Grammar::Actions.new));
but I'd greatly prefer something more like
my $grammar = My::Grammar.new(:action(My::Grammar::Actions.new));
my $match = $str ~~ $grammar;
Chris
PCT via Perl6: success!
I just finished converting Perk (a Java compiler targeting Parrot) from PCT+NQP/PIR to PCT+Rakudo. That is, the main entry point and actions.pm for my compiler are written in Perl 6. http://github.com/chrisdolan/perk/tree/master I had to make a few little hacks along the way: * PCT::HLLCompiler.parsegrammar() and .parseaction() require Parrot strings as arguments, not Rakudo strings. So, I used .WHICH as a hack to downconvert. * I couldn't figure out how to call 'compreg' from Rakudo, so I used inline PIR * a '>' token in my grammar couldn't find the token in the grammar, so I had to fully qualify it as . This is probably because the grammar is declared from Rakudo vs. compiled directly from PGE. Happily, I didn't need to change a single line of code in my actions.pm -- with the new 'make' builtin, my NQP code is fully supported by Rakudo. It would be interesting to see what remaining NQP constructs are not supported under Rakudo. Chris
Re: PCT via Perl6: success!
On Feb 13, 2009, at 9:54 AM, Patrick R. Michaud wrote: On Fri, Feb 13, 2009 at 12:58:13AM -0600, Chris Dolan wrote: * I couldn't figure out how to call 'compreg' from Rakudo, so I used inline PIR If using PCT, it shouldn't be necessary to call 'compreg' at all... where was this needed? Oh yeah, duh... I translated too literally from the PIR code. * a '>' token in my grammar couldn't find the token in the grammar, so I had to fully qualify it as . This is probably because the grammar is declared from Rakudo vs. compiled directly from PGE. Yes, that sounds like a PGE bug. I'll look for the root cause and file either a bug or a patch. It would be interesting to see what remaining NQP constructs are not supported under Rakudo. The main construct that NQP has that Rakudo has difficulty with is the binding operator. Hmm, I've heard you say that before, but I have not encountered any such difficulty to date. I wonder what gotcha I'm destined to hit? :-) Thanks for the feedback. Chris
Re: r25325 - docs/Perl6/Spec
Argh! I submitted a patch implementing $?PROGRAM in Rakudo literally 5 minutes before you sent this... http://rt.perl.org/rt3/Ticket/Display.html?id=63228 Chris On Feb 13, 2009, at 11:21 PM, pugs-comm...@feather.perl6.nl wrote: Author: lwall Date: 2009-02-14 06:21:13 +0100 (Sat, 14 Feb 2009) New Revision: 25325 Modified: docs/Perl6/Spec/S19-commandline.pod Log: [S19] $?PROGRAM makes no sense Modified: docs/Perl6/Spec/S19-commandline.pod === --- docs/Perl6/Spec/S19-commandline.pod 2009-02-14 05:13:04 UTC (rev 25324) +++ docs/Perl6/Spec/S19-commandline.pod 2009-02-14 05:21:13 UTC (rev 25325) @@ -14,8 +14,8 @@ Maintainer: Jerry Gay Date: 12 Dec 2008 - Last Modified: 11 Feb 2009 - Version: 24 + Last Modified: 13 Feb 2009 + Version: 25 This is a draft document. This document describes the command line interface. It has changed extensively from previous versions of Perl in order to increase @@ -67,7 +67,7 @@ and performs the requested actions. It looks something like Fbin/perl6>, F, or F, and is followed by zero or more I. Perl 6 does not do any processing of the I portion of the command -line, but it is made available at run-time in the read-only C<$? PROGRAM> +line, but it is made available at run-time via the C<< PROCESS::< $PROGRAM_NAME> >> variable. Command line I are broken down into I and I.
Re: r25325 - docs/Perl6/Spec
On Feb 13, 2009, at 11:50 PM, Larry Wall wrote: On Fri, Feb 13, 2009 at 11:34:03PM -0600, Chris Dolan wrote: Argh! I submitted a patch implementing $?PROGRAM in Rakudo literally 5 minutes before you sent this... http://rt.perl.org/rt3/Ticket/Display.html?id=63228 Indeed, why do you think I fixed the spec? :) But don't worry, we tend to do thing on the basis of forgiveness rather than permission, so I'm glad you did that or I wouldn't have noticed the $?PROGRAM problem. (The reason it can't be $?PROGRAM is that the name of the eventual executable program can't necessarily be known at compile time, which $? implies. $? variables have to be constants known at compile time.) Larry Aha! Thanks for clarifying that. However, now S19 and S02-magicals/progname.t disagree on whether PROCESS::<$PROGRAM_NAME> means $^X='/usr/bin/perl' or $0='foo.pl'. S02 suggests $*PERL is $^X. Maybe PROCESS::<$PERL_EXECUTABLE> for $^X? Chris
Implementing $?LINE and other S02 compile-time vars
I've been considering how to inject compile-time values ($?VAR) into
Rakudo.
I was thinking about how to implement $?LINE and came up with two
ways to do it: on the fly and post processing.
On the fly would require some significant work in PGE, I think, to
keep the line count correct in the face of backtracking. However,
this may already be necessary down the road for proper line numbers
in error messages for code mapped from an HLL to a lower level syntax.
Post-processing on the other hand would require me to keep an
actions.pm 'our' variable of whether we found a $?LINE or not. Only
if so, then in TOP we walk the parse tree counting newlines and
replacing PAST::Var(:name('$?LINE')) with PAST::Val(:value
($linecount)). That way, we'd encounter no performance hit if there
were no line number requests.
The former seems like the right general solution for the long term,
but the latter seems doable today. Thoughts?
Other compile-time variables like $?OS and $?FILE seem easier to
implement because they require a lot less context. I think $?OS is
just the NQP equivalent of the following code:
use cfg;
my %cfg = _config();
make PAST::Val(:value(%cfg));
$?PARSER should be simply the grammar class name. $?LANG should
always be 'Perl6', unless explicitly overridden with :lang. $?VM and
$?KVM should just be 'Parrot', at present.
Should $?PERL be 'Rakudo' or '/path/to/perl6.pbc'?
I think $?GRAMMAR, $?CLASS, $?ROLE, $?MODULE and $?PACKAGE should be
easy because actions.pm already tracks those values in @?PKGDECL[*-1]
(or something like that). @?GRAMMAR, @?CLASS, @?ROLE, @?
MODULE, and @?PACKAGE should be similar operations on @?PKGDECL.
Thoughts?
Chris
