Re: CPAN and META.yml: no_index dir vs directory
no_index/dir 13 no_index/directory 1397 private/directory40 As for dir, I'm three of the 13, I'm another three of the 13, and I'll switch to 'directory' as of the next upload. -- Johan
Re: Test::Builder feature request...
On 2/9/06, Geoffrey Young [EMAIL PROTECTED] wrote: This works: yes, excellent randy. thanks for that. it still seems a little hackish but that's ok - hackish works for me if it means I can do what I want and nobody else needs to do extra work :) I made some tweaks to your format and added a few minor notes here http://people.apache.org/~geoff/test-more-separately.tar.gz A less hackish version of plan.t is... use Test::More; my $TB = Test::More-builder; $TB-no_ending(1); plan tests = 3; print qx!perl t/response.pl!;
Re: Proposal Suggestion - Test::Run
On Thursday 06 July 2006 00:36, Jonathan T. Rockway wrote: Two comments, pretty much agreeing with chromatic and Ricardo: 1) How would this proposed module benefit the perl community? Why can't you fix things in Test::Harness and send the patch in? If you fix deployed modules, everyone wins. If you write your own module, it sits on CPAN unused. What exactly is wrong with Test::Harness, anyway? The development team is pretty agreeable, the code is good, the module works, etc. Is there some large problem I'm missing? (A problem so large that TPF needs to *pay* someone to fix it!?) I've answered some of these things in the following links: http://www.shlomifish.org/lecture/Perl/Lightning/Test-Run/ http://use.perl.org/~Shlomi+Fish/journal/27467 http://use.perl.org/~Shlomi+Fish/journal/27887 Also see my other replies to this thread: http://www.mail-archive.com/perl-qa%40perl.org/msg05987.html And also the resource that Schwern pointed to: http://www.mail-archive.com/perl-qa%40perl.org/msg06014.html 2) If you use GPL'd code in an MIT-licensed app, the entire app becomes GPL. I don't think you can say, this requires xyz GPL'd code, but if it didn't it would be MIT. It's GPL by virtue of requiring GPL code. (Hence the accusation that the GPL is 'viral' or whatever.) IANAL, but this is my understanding from reading the license, the FSF's site, etc. If the code isn't derived, though, feel free to MIT license it. There is a difference between derived code and inclusive code. The code that originated from other people's code was kept under the same licence (GPL+Artistic in this case). I also disclaimed any explicit ownership of it. OTOH, the code that was written from scratch and was my original code was licensed under the X11 licence, because it did not include anything else. (The fact of the matter, though, is that Perl uses the Perl license. I don't really love the Artistic license, but I release my perl code under the dual license because Everyone Else Does. I don't like doing everything only because everyone else does them. I like to think for myself what is the best course of action and long time strategy. It makes everything work nicely and builds community too :) I don't see using the X11 licence for my software as anti-social. Like I said, anyone can easily fork it as a software of a different licence. It's also more permissive than the GPL+Artistic licence (and much less problematic than the Artistic 1.0 licence, which some people don't even consider as free-as-in-speech.) So far I've released all the software (Perl or otherwise) for which I had a choice under the Public Domain or X11 licence. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: TAP::Harness
On 7/1/06, Michael G Schwern [EMAIL PROTECTED] wrote: As my flight is delayed I'll try to make a stab at posting up the basic design. The whole point of replacing the Perl QA wiki was to have a public place for the TAP::Harness design to live. :) http://perl-qa.yi.org/index.php/TAP::Harness The sources and runners work. I started on the parser and then stopped when I realized it would work better with a separate lexer. The responsibilities of the parser vs the aggregator are still a bit fuzzy as is exactly what goes into an event. But hopefully there's enough there to give a clearish idea of where I'm headed, what its potentially capable of and to warn me alway from any horrible design mistakes.
Re: Proposal Suggestion - Test::Run
On Wednesday 05 July 2006 23:02, Shlomi Fish n wrote: I don't see using the X11 licence for my software as anti-social. Like I said, anyone can easily fork it as a software of a different licence. Supposing you actually find a mentee and TPF actually does fund this project and this code is substantially better than Test::Harness such that it is an obvious candidate for inclusion in the Perl core. It must be under the Perl license. Now there is a fork of a fork, as the code that makes it into the core has an incompatible license with your fork. (Do NOT assert, yet again without proof or a demonstratable understanding of the problem, that there exists a trivial solution. The linking clause of the GPL is hardly a new or poorly understood legal invention, for example.) I am not sure what to call this, but I do know that it is not a viable long term strategy for anyone else. How is your refusal to follow community norms (or, I suppose, to work with an amenable maintainer) anything *but* anti-social? I suppose copy-and-relicense forking is as good a description as any. That is not a complimentary description, by the way. -- c
Re: a smarter form of whitespace
Patrick R. Michaud wrote:
On Tue, Jul 04, 2006 at 12:57:16PM -0700, Allison Randal wrote:
--
token start { ^emptyline*$ }
regex emptyline { ^^ $$ \n }
token ws { [sp | \t]* }
--
The above grammar doesn't have a grammar statement; as a result
the regexes are being installed into the '' namespace.
The original did have a 'grammar' statement, I just didn't paste it into
the email.
$ cat xyz.pir
.sub main :main
load_bytecode 'PGE.pbc'
load_bytecode 'ar.pir'
load_bytecode 'dumper.pbc'
load_bytecode 'PGE/Dumper.pbc'
$P0 = find_global 'XYZ', 'start'
$P1 = $P0(\n\n\n\n\n\n\n, 'grammar' = 'XYZ')
What the original didn't have is the 'grammar' named argument when
calling the start rule. When I replace the previous line with:
$P1 = $P0(\n\n\n\n\n\n\n)
then your sample code exhibits the same problem. I assume this means
that the reason overriding ws wasn't working is because it was calling
the default version of ws in the root namespace. But, if it was
defaulting to the root namespace, why was it able to find any of the
rules? Shouldn't it have complained that it couldn't find emptyline?
Thanks,
Allison
namespaces, a single colon to separate HLL prefix?
Quick question, is there a syntax specified in Perl 6 for referring to
namespaces from other languages?
I'm reviewing the namespaces PDD and want to update this snippet:
--
IMPLEMENTATION EXAMPLES: Suppose a Perl program were to import some Tcl
module with an import pattern of ``c*'' -- something that might be
expressed in Perl 6 as use tcl:Some::Module 'c*'. This operation would
import all the commands that start with 'c' from the given Tcl namespace
into the current Perl namespace. This is so because, regardless of
whether 'c*' is a Perl 6 style export pattern, it is a valid Tcl export
pattern.
{XXX - Is the ':' for HLL approved or just proposed? Somebody familiar
with Perl 6 please fix the example in the preceding paragraph to use the
currently planned syntax for importing modules from other languages.}
--
Thanks,
Allison
Re: The new wiki
I own p6docs.com if you'd like to use that, just give me some nameservers to point to. On 7/5/06, Michael G Schwern [EMAIL PROTECTED] wrote: Thanks to Tyler MacDonald and yi.org we now have a brand spanking new wiki! http://perl-qa.yi.org/ is its location, we'll worry about getting more official domains later. Its a wiki. Go nuts. Err on the side of editing rather than doing nothing. Not sure if something should go on the wiki? Put it there, it can be deleted. This is MediaWiki, the wiki which Wikipedia runs. Its got some features and differences from other wikis, so please read http://perl-qa.yi.org/index.php/MediaWiki_Editing_Tips to learn how to use it most effectively. I've put together a short list of things you can do for the Wiki. http://perl-qa.yi.org/index.php/What_can_I_do%3F Those of you who have proposed TAP extensions, kindly scrape the details off the mailing list, write them up on the wiki and list them here: http://perl-qa.yi.org/index.php/TAP_Proposals Those writing TAP parsers, kindly write them up on the wiki and list them here: http://perl-qa.yi.org/index.php/TAP_Parsers Those writing TAP producers (things which can produce TAP output. ie. Test::Builder, libtap, Test.pm, Selenium?...), write them up on the Wiki and list them here: http://perl-qa.yi.org/index.php/TAP_Producers
Re: a smarter form of whitespace
On Tue, Jul 04, 2006 at 12:57:16PM -0700, Allison Randal wrote: I'm writing a parser for a language that treats a double newline as a statement terminator. It works if I make every rule a 'regex' (to turn off smart whitespace). But I want spaces and tabs to act as smart whitespace, and newlines to act as literal whitespace. I've overloaded ws to match only spaces and tabs, but the grammar still consumes newlines where it shouldn't consume newlines. For a simple repeatable example, take the following grammar: Overloading ws and other builtins was fixed in parrot and pugs approaching midnight (hackathon time) on 2006-06-29. If your parrot and pugs are both more recent than that, I'm not sure where the bug is. -kolibrie
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
Chip Salzenberg wrote: --- PART 2, IN WHICH AN ELEGANT SOLUTION IS PROPOSED -- On the other hand, we could extend the key PMC to represent emptiness, i.e. zero dimensions. This seems useful for namespaces and could even prove useful for real keys. And this makes keys even more compatible with the Array interface, which I think they might need to implement someday anyway. Allison, what do you think of zero-length keys, i.e. having [] construct a Key PMC describing no dimensions of lookup? If we use those we can get rid of the current null-string hack. Fundamentally altering the way keyed access works seems like a pretty extreme solution when the problem is just the root HLL namespace doesn't have a name. (Actually, it does have a name: 'parrot', 'tcl', 'perl6', etc. A sort of key who must not be named, if I won't be shot for making terrible Harry Potter references at 1am.) It's simpler to give the root HLL namespace a name. If zero-length keys are not OK, then... --- PART 3, IN WHICH AN UGLY BUT WORKING HACK IS DESCRIBED -- I introduced a hack in my recent namespace cleanups. I was planning to ask/warn users about it, but then forgot I'd done it, so it's in the svn repo now. The hack is: When find_global or store_global expects a string or PMC to designate (name) a namespace, Parrot takes a null value to name the HLL root namespace. A null string could be canonized as the name of the root namespace, though something a little more meaningful and easier to type would be nice. The problem is really that we're trying to simultaneously a) refer to the root HLL namespace directly, and b) pretend that it doesn't exist. I had a much longer reply, but I'm going to let it steep overnight and see what percolates. Allison
Re: TAP Grammar
On 7/5/06, Chris Dolan [EMAIL PROTECTED] wrote: 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/ excellent! i have the beginnings of a TAP parser in my working copy, i'll look at what you've got and synchronize them up. thanks for the test cases, it should be a simple matter to migrate them into tests in the parrot repo. i'll also make the makefile platform-independent, as it won't run on windows as it is. 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 i've applied your changes (with one minor mod: s/\n/$$/) to parrot revision 13168.) thanks and keep the patches coming! ~jerry
Re: CPAN and META.yml: no_index dir vs directory
B/BL/BLM/Win32API-Registry-0.27 I can move this one pretty easily too, it needs a new release anyway. R/RC/RCAPUTO/POE-0.3502 R/RC/RCAPUTO/POE-Component-Client-Keepalive-0.0801 I'm pretty sure Rocco will move next release as well. Adam K
Re: On Gaming CPANTS, and a Kwalitee Suggestion
Tels wrote: And, improve compatibility - with broken systems? OMG. :) Yeah, you know, like when you comment this out before release :-) # die(Sorry, you must have a computer to run this software\n) # if($^O =~ /win32/i); Given that Mod::Sig checks are just that the signature is valid, not that the signature matches a known/registered developer, the security aspect is already minimal. This is a security bug and should then be fixed ASAP. Given that you have to be logged in to the PAUSE and have permission to upload stuff for that module, then I don't think that signatures matter in the slightest. It doesn't give you any kind of trust metric (like, say, that the author is a nice guy and his Makefile.PL won't delete your home directory) that you don't already have from the fact that my module had to have been uploaded by me. -- David Cantrell
Old and broken versions of Module::Install
Hi perl.qa, hopefully, this message will not provoke another flame war about Module::Install and Module::Build. Please don't feel tempted. I don't care which build system you use if it works. Versions of Module::Install 0.61 do not work on the current ActivePerl release 5.8.8 build 817. There are *a lot* of CPAN distributions that use Module::Install versions in the 0.3X range. In fact the most modules that use Module::Install are still 0.3X. For example an integral distribution like Scalar-List-Utils is using Module::Install 0.37. You can find a complete (and somewhat current) list of problematic modules at http://steffen-mueller.net/mi_old.html Installing modules from CPAN on win32 is really frustrating if you have to do the following dance for every other module you install: (install current Module::Install once, then:) look Foo::Bar $ rm -rf inc/ $ perl Makefile.PL $ make $ make install $ exit This is particularly nasty if it happens somewhere in the dependency chain. Why am I posting here? a) Perhaps some of those distributions belong to you. If so, please consider releasing a new version with a more current Module::Install or without using Module::Install at all. b) You care about perl and CPAN qa. What can we do to motivate authors to upgrade? Keep in mind that a kitten, err, a would-be win32 Perl programmer and/or user is turned away for every module that doesn't install because of this. In particular, the above solution for a module that doesn't install cleanly isn't known to just anybody because the error you get isn't self-explanatory. Ideas? Steffen
Re: Old and broken versions of Module::Install
Steffen Mueller wrote: Versions of Module::Install 0.61 do not work on the current ActivePerl release 5.8.8 build 817. There are *a lot* of CPAN distributions that use Module::Install versions in the 0.3X range. In fact the most modules that use Module::Install are still 0.3X. For example an integral distribution like Scalar-List-Utils is using Module::Install 0.37. You can find a complete (and somewhat current) list of problematic modules at http://steffen-mueller.net/mi_old.html Ideas? What about adding NO_BROKEN_INSTALLER as a Kwalitee point for CPANTS? :-) Regards, David Golden
Re: Test::Builder feature request...
Michael G Schwern wrote: On 2/9/06, Geoffrey Young [EMAIL PROTECTED] wrote: This works: yes, excellent randy. thanks for that. it still seems a little hackish but that's ok - hackish works for me if it means I can do what I want and nobody else needs to do extra work :) I made some tweaks to your format and added a few minor notes here http://people.apache.org/~geoff/test-more-separately.tar.gz A less hackish version of plan.t is... use Test::More; my $TB = Test::More-builder; $TB-no_ending(1); plan tests = 3; print qx!perl t/response.pl!; cool, thanks. I've updated the example package to include that format as well. --Geoff
Re: Old and broken versions of Module::Install
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
Re: [perl #39734] t/doc/pod.t fails on Mac OS 10.4.6/perl 5.8.8
On 7/5/06, via RT David H. Adler [EMAIL PROTECTED] wrote: As bugs go, not a killer, but still... The problem tests are as follows: not ok 329 - POD test for /Users/dha/parrot-0.4.5/src/ops/experimental.ops # Failed test (t/doc/pod.t at line 62) # /Users/dha/parrot-0.4.5/src/ops/experimental.ops (229): '=item' outside of any '=over' and not ok 1162 - POD test for /Users/dha/parrot-0.4.5/docs/ops/experimental.pod # Failed test (t/doc/pod.t at line 62) # /Users/dha/parrot-0.4.5/docs/ops/experimental.pod (105): '=item' outside of any '=over' i can't recreate this with a recent revision. from the svn log, it seems src/ops/experimental.ops was modified 19 june. perhaps you have a modified file in your working copy? ~jerry snip/ Updated to revision 13181. D:\usr\local\parrot\trunkprove t/doc/pod.t t/doc/pod# finding files with pod, this may take a minute. t/doc/podok All tests successful. Files=1, Tests=1177, 226 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
Re: Cage Cleaning for dummies? Re: Call for Parrot Janitors
On Thu, Jul 06, 2006 at 06:33:48AM +0100, Nicholas Clark wrote: On Wed, Jul 05, 2006 at 09:10:47PM -0700, chromatic wrote: On Wednesday 05 July 2006 19:58, Bill Ricker wrote: * Minimum GCC == whatever Perl5 was built with? or specific? Probably at least 2.9x. Why? IIRC gcc 2.7 was good and stable, and it's not like C89 has changed much in the past 10 years. I guess it's really down to whether the C compiler (gcc or otherwise) has awkward bugs on your platform. (Alas, I do _not_ have the Tru64/DEC compiler for Alpha AXP on my Debian/Alpha. There's someone I can talk to, I might be able to get it, or get access to it. Hmm.) Alpha would be very good. Any vendor compiler is very good at picking up sloppy C code. As well as Tru64, anyone with Irix, AIX, HP-UX, particularly if 64 bit, would be most welcome. The MS Visual Studio compilers are also very picky, and that's where I made some initial contributions. Alternative compilers on various OS's are also a good place to look for problems. Intel C++ is on Linux, Windows, and Mac OS X (Intel). The alpha Sun Studio compiler is available for Linux. Steve Peters [EMAIL PROTECTED]
Re: Module Signatures [was Re: On Gaming CPANTS...]
* Jonathan Rockway [EMAIL PROTECTED] [2006-07-06 03:25]: I think the solution (to dependency hell) is to dictate that CPAN modules be signed with a standard algorithm. OpenPGP allows too many different algorithms, hence the 22 modules Crypt::OpenPGP is dependent on. The only strong reason to stick with OpenPGP is that it has the whole web-of-trust and keyserver infrastructure. If we can live without that, What’s the point? If all that’s verified is that the distribution was signed with the key uploaded to the same directory, then all you can have confidence in is that distribution was uploaded by someone who has permission to upload a key. That might be the author, or it might be an impostor who got ahold of the author’s account details and uploaded his own key. But to upload a distribution you need the author’s account details anyway! So the cryptosig doesn’t give you confidence in any facts that you didn’t already have confidence in. In other words, for the signatures to improve confidence, they have to be generated from keys that either form of a web of trust in which the downloader participates, or they have to be issued by a certification authority that imposes additional background verification before it will issue a key. I don’t think running a cert auth is feasible for CPAN. So the only worthwhile option is to participate in the PGP web of trust. If you do away with that, you can just as well do away with cryptosigs alltogether. NB.: of course, Mod::Sig currently doesn’t check the trustworthiness of a key, only whether a distribution is signed with the uploaded key, so it’s pointless in precisely the way outlined above. Until such time as trust checks are implemented, there is no point to signing CPAN distros. Regards, -- Aristotle Pagaltzis // http://plasmasturm.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: Old and broken versions of Module::Install
* 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/
Re: Old and broken versions of Module::Install
* 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. But you’re not catching me dead using an installer that requires me to pay attention to its development and to push up new versions of my distros in response to its bugs. There are far better ways to waste my time. Sorry that this turned into an M::B/M::I flame anyway, -- Aristotle Pagaltzis // http://plasmasturm.org/
check if all the links on an HTML page are working (except the mailto links)
Using Test::WWW::Mechanize 1.10 I am trying to $w-page_links_ok(); on a page that has an e-mail address in it and the test fails. How could I tell TWM not to bother with the mailto links on the page? Gabor
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: Cage Cleaning for dummies? Re: Call for Parrot Janitors
Submitting bugs is not done through the web interface, but via email. Please see: http://www.parrotcode.org/docs/submissions.html RT was upgraded recently. It seems to be working at the moment. Regards. On Jul 6, 2006, at 10:39 AM, Chris Dolan wrote: 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 -- Will Coke Coleda [EMAIL PROTECTED]
Re: namespaces, a single colon to separate HLL prefix?
在 2006/7/6 上午 3:30 時，Allison Randal 寫到：
Quick question, is there a syntax specified in Perl 6 for referring
to namespaces from other languages?
I'm reviewing the namespaces PDD and want to update this snippet:
--
IMPLEMENTATION EXAMPLES: Suppose a Perl program were to import some
Tcl module with an import pattern of ``c*'' -- something that might
be expressed in Perl 6 as use tcl:Some::Module 'c*'. This operation
would import all the commands that start with 'c' from the given
Tcl namespace into the current Perl namespace. This is so because,
regardless of whether 'c*' is a Perl 6 style export pattern, it is
a valid Tcl export pattern.
{XXX - Is the ':' for HLL approved or just proposed? Somebody
familiar with Perl 6 please fix the example in the preceding
paragraph to use the currently planned syntax for importing modules
from other languages.}
--
The : form is approved and canonical (line 303, the Modules spec, aka
S11.pm version 14).
use perl5:DBI;
However, currently it's only available at use/require line.
Afterwards, the user simply say:
my $dbh = DBI.connect(...);
Though I think this:
my $dbh = perl5:DBI.connect(...)
can be made to work, as it's currently parsefail, thought there is a
marginal case:
my $dbh = perl5:DBI; # currently parsed as perl5(:DBI)
but we can say that for each HLL-qualified module name, it's a single
token and is therefore recognized first.
Does that sound sane? If yes, S11 can be updated to reflect that.
Thanks,
Audrey
PGP.sig
Description: This is a digitally signed message part
Re: a smarter form of whitespace
On Thu, Jul 06, 2006 at 12:29:12AM -0700, Allison Randal wrote: $ cat xyz.pir .sub main :main load_bytecode 'PGE.pbc' load_bytecode 'ar.pir' load_bytecode 'dumper.pbc' load_bytecode 'PGE/Dumper.pbc' $P0 = find_global 'XYZ', 'start' $P1 = $P0(\n\n\n\n\n\n\n, 'grammar' = 'XYZ') What the original didn't have is the 'grammar' named argument when calling the start rule. When I replace the previous line with: $P1 = $P0(\n\n\n\n\n\n\n) then your sample code exhibits the same problem. I assume this means that the reason overriding ws wasn't working is because it was calling the default version of ws in the root namespace. But, if it was defaulting to the root namespace, why was it able to find any of the rules? Shouldn't it have complained that it couldn't find emptyline? At the moment (and this may be incorrect), PGE looks for named rules via inheritance, and if not found that way it looks in the available symbol tables using the find_name opcode. So, the match was able to find the rules because they are in the current namespace, but when it came time to find the rule for ?ws there was a ws method available (the default) and so that one was used. Again, this may not be the correct behavior; I've been using S12 as the guide here, in that a method call first considers methods from the class hierarchy and fails over to subroutine dispatch. Pm
Re: check if all the links on an HTML page are working (except the mailto links)
On Jul 6, 2006, at 10:22 AM, Gabor Szabo wrote: Using Test::WWW::Mechanize 1.10 I am trying to $w-page_links_ok(); on a page that has an e-mail address in it and the test fails. How could I tell TWM not to bother with the mailto links on the page? That's silly that it tries the mailto. I'm fixing it right now. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: check if all the links on an HTML page are working (except the mailto links)
* Gabor Szabo [EMAIL PROTECTED] [2006-07-06 17:25]:
Using Test::WWW::Mechanize 1.10 I am trying to
$w-page_links_ok();
on a page that has an e-mail address in it and the test fails.
How could I tell TWM not to bother with the mailto links on the page?
There’s no official way. Until Andy fixes it somehow, you can
hack it:
package Test::WWW::Mechanize::CheckOnlyHTTPURI;
our @ISA = qw( Test::WWW::Mechanize );
sub _check_links_status {
my $self = shift;
my $urls = shift;
$urls = [ grep m!^s?https?:!, @$urls ];
return $self-SUPER::_check_links_status( $urls, @_ );
}
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: check if all the links on an HTML page are working (except the mailto links)
On 7/6/06, Andy Lester [EMAIL PROTECTED] wrote: On Jul 6, 2006, at 10:46 AM, A. Pagaltzis wrote: $urls = [ grep m!^s?https?:!, @$urls ]; What's an shttps link? That the Sean Connery version... Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: Proposal Suggestion - Test::Run
Shlomi Fish n wrote: I don't see using the X11 licence for my software as anti-social. Like I said, But it is. You are forcing people to spend some of their precious time to understand the ramifications of this different license, and consider the differences between it and the GPL and AL. anyone can easily fork it as a software of a different licence. It's also Again, you are forcing people to expend effort for what could otherwise be a non-issue. more permissive than the GPL+Artistic licence (and much less problematic than the Artistic 1.0 licence, which some people don't even consider as free-as-in-speech.) That's their problem. So far I've released all the software (Perl or otherwise) for which I had a choice under the Public Domain or X11 licence. Personally, I'm happy enough to sign my modules as licenced under the same terms as Perl itself, thereby letting other people deal with a matter for which I have next to no interest in. My own take on this is that even if your code was better, I wouldn't use it, since I couldn't be sure that my use of it may in some way violate its terms. At least I know where I stand with the GPL and AL. Life is short, and the less I have to think about licensing issues, the better. David Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%. Indeed. -- Much of the propaganda that passes for news in our own society is given to immobilising and pacifying people and diverting them from the idea that they can confront power. -- John Pilger
Re: check if all the links on an HTML page are working (except the mailto links)
* Andy Lester [EMAIL PROTECTED] [2006-07-06 17:55]: On Jul 6, 2006, at 10:46 AM, A. Pagaltzis wrote: $urls = [ grep m!^s?https?:!, @$urls ]; What's an shttps link? Err, right. I suppose that should be `m!^(s?)http(?(1)|s?):!`, or else you just punt on `shttp` (does LWP handle those, anyway?). Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: check if all the links on an HTML page are working (except the mailto links)
On Jul 6, 2006, at 10:46 AM, A. Pagaltzis wrote: $urls = [ grep m!^s?https?:!, @$urls ]; What's an shttps link? -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: check if all the links on an HTML page are working (except the mailto links)
On Jul 6, 2006, at 11:01 AM, A. Pagaltzis wrote: Err, right. I suppose that should be `m!^(s?)http(?(1)|s?):!`, or else you just punt on `shttp` (does LWP handle those, anyway?). I was going to just make it be /^https?/. Never heard of shttp. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: check if all the links on an HTML page are working (except the mailto links)
* A. Pagaltzis [EMAIL PROTECTED] [2006-07-06 18:05]: Err, right. I suppose that should be `m!^(s?)http(?(1)|s?):!`, Drat, `m!^(s)?http(?(1)|s?):!` of course. Regards, -- Aristotle Pagaltzis // http://plasmasturm.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: Old and broken versions of Module::Install
On 7/6/06, Steffen Mueller [EMAIL PROTECTED] wrote: Versions of Module::Install 0.61 do not work on the current ActivePerl release 5.8.8 build 817. What's broken and why suddenly 5.8.8?
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
On Thu, Jul 06, 2006 at 01:21:08AM -0700, Allison Randal wrote: The problem is really that we're trying to simultaneously a) refer to the root HLL namespace directly, and b) pretend that it doesn't exist. I don't think (b) is quite true. It's more that we're avoiding explicit re-coding of a known bit of environmental information, as in the first floor of this building rather than the first floor of 123 main street. Chip Salzenberg wrote: Allison, what do you think of zero-length keys, i.e. having [] construct a Key PMC describing no dimensions of lookup? If we use those we can get rid of the current null-string hack. Fundamentally altering the way keyed access works seems like a pretty extreme solution when the problem is just the root HLL namespace doesn't have a name. I brought it up partly because I was hoping you'd say something like, Oh yeah, we're gonna need zero-length keys anyway for Perl 6. What is the parameter to operator:postcircumfix [] when a user says @array.[] ? It's simpler to give the root HLL namespace a name. Indeed, it already has the name of empty list when a PMC array is the naming vehicle: $P0 = new .FixedPMCArray $P1 = get_namespace $P0 # that's the HLL root There are two kinds of lists in play for namespaces; one of them can have a length of zero (PMC array), but the other one can't (key), and the one that can be zero-length doesn't have convenience pasm syntax. A null string could be canonized as the name of the root namespace, though something a little more meaningful and easier to type would be nice. I should emphasize that I've gone to the recent trouble of making namespace [''] *not* mean the HLL root for two reasons: (1) it's poor manners on the part of a VM to steal names from HLLs or users, and (2) when a user is working with an array of names, they'll want to be able to decompose the list -- which puts a string that used to be in the middle out on the front, or by itself -- without accidentally re-rooting the search. Possibility: If we introduce a pasm keyword Null to mean a pmc constant null (and perhaps a string contant null), then the null name could be easier to type. It could also be useful in other contexts. Gentle observation: [] is pretty easy to type, and offers consistency: $P2 = get_namespace ['a','b'] # two levels from root $P1 = get_namespace ['a'] # one level from root $P0 = get_namespace [] # zero levels from root Ugly hack / joke: If you were willing to look the other way, [] could be an alternative spelling for PMC Null. :-P -- Chip Salzenberg [EMAIL PROTECTED]
[perl #39738] bind fails with errno EADDRNOTAVAIL on darwin and FreeBSD
# New Ticket Created by Chris Dolan # Please include the string: [perl #39738] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39738 --- osname= darwin osvers= 8.0 arch= darwin-thread-multi-2level cc= cc --- Flags: category=core severity=medium ack=no --- 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 Reproducibility: Reproduced on a G5 Powermac running Mac OS X 10.4.6 Reproduced on an Intel Macbook running Mac OS X 10.4.7 Reproduced on a G5 Xserve running Mac OS X Server 10.3.9 Reproduced on an x86 box running FreeBSD 5.4 Not reproduced on an x86 box running RedHat 7.x On my G5 Powermac, I get the same results if I change examples/io/httpd.pir to listen on 127.0.0.1 instead of localhost. --- Summary of my parrot 0.4.5 (r13165) configuration: configdate='Wed Jul 5 14:31:06 2006' Platform: osname=darwin, archname=darwin-thread-multi-2level jitcapable=1, jitarchname=ppc-darwin, jitosname=DARWIN, jitcpuarch=ppc execcapable=1 perl=perl Compiler: cc='cc', ccflags='-g -pipe -fno-common -no-cpp-precomp -I/usr/local/include -pipe -fno-common -Wno-long-double -I/sw/include -I/sw/include', Linker and Libraries: ld='c++', ldflags='-L/usr/local/lib -flat_namespace -L/sw/lib -L/sw/lib', cc_ldflags='', libs='-lm -lgmp -lreadline' Dynamic Linking: share_ext='.dylib', ld_share_flags='-dynamiclib -undefined suppress', load_ext='.bundle', ld_load_flags='-bundle -undefined suppress' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=4321, nv=double, numvalsize=8, doublesize=8 --- Environment: DYLD_LIBRARY_PATHHOMELANGLANGUAGELC_ALLLD_LIBRARY_PATH LOGDIRPATHPERL5LIBPERL5_CPANPLUS_CONFIGSHELL
Re: namespaces, a single colon to separate HLL prefix?
On Thu, Jul 06, 2006 at 10:40:21AM -0400, Audrey Tang wrote: : The : form is approved and canonical (line 303, the Modules spec, aka : S11.pm version 14). : : use perl5:DBI; : : However, currently it's only available at use/require line. : Afterwards, the user simply say: : : my $dbh = DBI.connect(...); : : Though I think this: : : my $dbh = perl5:DBI.connect(...) : : can be made to work, as it's currently parsefail, thought there is a : marginal case: : : my $dbh = perl5:DBI; # currently parsed as perl5(:DBI) : : but we can say that for each HLL-qualified module name, it's a single : token and is therefore recognized first. : : Does that sound sane? If yes, S11 can be updated to reflect that. It's only sane if we require the predeclaration of the language higher in the lexical scope. Suppose we try to maintain a secret canonical list, and then suppose someone adds a language 'q', for instance? But after a use q:mumble we can certainly recognize q:, presumably forcing people to write q :mumble for the rest of the lexical scope if they want a mumbled quote. Alternately we could force explicit declaration of all foreign namespaces: use namespace perl5 q; ... use q:QueryMe; use perl5:DBI; Actually, I kinda like that because it gives a logical spot to talk about how to import a namespace, if you want to modify it. Like what if you want to alias the namespace: use namespace :perl5OldSchoolPerl; or some such. But it's also possible we should do something more sigilistic or twigilistic for foreign namespace roots. A punishingly dehuffmanized version might be use NAMESPACE::perl5::DBI; which for alphabetic names the parser might allow us to reduce to use **perl5::DBI; much like we allow *Foo as short for GLOBAL::Foo. Larry
sprintf for S29
I've taken a stab at sprintf for S29. All I've done differently from
Perl 5 is to drop %p and %n (generates an exception) and add %C
(closure) to replace the functionality of %n. Are there any additional
formats that we want to add?
Other than that, this should be exactly the same as Perl 5:
=item sprintf
our method Str Str::sprintf ( Str $format: [EMAIL PROTECTED] )
our multi Str sprintf ( Str $format, [EMAIL PROTECTED] )
This function is mostly identical to the C library sprintf function.
The C$format is scanned for C% characters. Any C% introduces a
format token. Format tokens have the following grammar:
grammar Str::SprintfFormat {
rule format_token { \%: index? precision? modifier? directive }
rule index { \d+ \$ }
rule precision { flags? vector? precision_count }
rule flags { [\ +0\#\-]+ }
rule precision_count { [ [1-9]\d* | \* ]? [ \. [ \d* | \* ] ]? }
rule vector { \*? v }
rule modifier { [lhVqL] | ll }
rule directive { [\%csduoxefgXEGbpniDUOF] }
}
Directives guide the use (if any) of the arguments. When a directive
(other than C%) are used, they indicate how the next argument
passed is to be formatted into the string.
The directives are:
% a percent sign
c a character with the given number
s a string
d a signed integer, in decimal
u an unsigned integer, in decimal
o an unsigned integer, in octal
x an unsigned integer, in hexadecimal
e a floating-point number, in scientific notation
f a floating-point number, in fixed decimal notation
g a floating-point number, in %e or %f notation
X like x, but using upper-case letters
E like e, but using an upper-case E
G like g, but with an upper-case E (if applicable)
b an unsigned integer, in binary
C special: invokes the arg as code, see below
Compatibility:
i a synonym for %d
D a synonym for %ld
U a synonym for %lu
O a synonym for %lo
F a synonym for %f
Perl 5 compatibility:
n produces a runtime exception (see below)
p produces a runtime exception
The special format directive, C%C invokes the target argument as
code, passing it the result string that has been generated thus
far and the argument array.
Here's an example of its use:
sprintf %d%C is %d digits long,
$num,
sub($s,@args is rw) [EMAIL PROTECTED],
0;
The special directive, C%n does not work in Perl 6 because of the
difference in parameter passing conventions, but the example above
simulates its effect using C%C.
=cut
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
We had some good machines, but they don't work no more. -Shriekback
Re: namespaces, a single colon to separate HLL prefix?
On Thu, Jul 06, 2006 at 09:09:08AM -0700, Larry Wall wrote: : use **perl5::DBI; which, if you don't like the two-character form, you can spell: ⁑perl5::DBI :-) Hmm, hmm, speaking of sanity, how 'bout user-defined sigils and twigils: sigil ¢ = Capture; twigil ¬ = NOTREALLY::; ¢¬foo; # not really a capture... :) Larry
Re: [perl #38594] [BUG] source line numbers
Hi Chip, Can you please apply this patch for me? This is a fix to the YACC file. As a result you will also have to checkin the imcparser.c and imcparser.h after applying the patch and recompiling the source. Thanks, Vishal Index: compilers/imcc/imcc.y === --- compilers/imcc/imcc.y (revision 13035) +++ compilers/imcc/imcc.y (working copy) @@ -202,7 +202,7 @@ r-type = (r-type VT_ENCODED) ? VT_PCC_SUB|VT_ENCODED : VT_PCC_SUB; r-pcc_sub = calloc(1, sizeof(struct pcc_sub_t)); cur_call = r; -i-line = line - 1; +i-line = line ; add_namespace(interp, unit); return i; } On 7/3/06, Vishal Soni [EMAIL PROTECTED] wrote: Will, Did we get this one in? -Vishal On 6/30/06, Vishal Soni [EMAIL PROTECTED] wrote: Hi, The .end seems to be replaced by an implicit end. -Vishal On 6/29/06, Will Coleda via RT [EMAIL PROTECTED] wrote: Hey, Vishal: [vsoni - Tue Jun 27 05:48:27 2006]: Hi, This was a straight forward fix. The line number was being decremented at the start of a 'sub' token imcc.y. Thanks, Vishal Here is a sample run Sample Code: --- .sub main :main print 2\n print 3\n print 4\n .end Output: ./parrot -d 10 ./hello.pir 1 last:5 pcc_sub main nparams 0 Dumping the instructions status: --- nins line blck deep flags type opnr size pc X ins 0100 0 8 -100 main: 1200 1 0 41320print 2\n 2300 1 0 41322print 3\n 3400 1 0 41324print 4\n 4400 0 18000016end Looks like the first line is fixed there (1) and then the guts are fixed (2,3,4), but is the duplicate line 4 correct? (is that corresponding to the implicit end that PIR puts in, or the .end of the subroutine? If you can just validate that, we can apply this. Labels namepos last ref --- Dumping the CFG: --- 0 (0)- - Dumping the Dominators Tree: --- 0 - ( 0) 0 Loop info - Patch Index: compilers/imcc/imcc.y = == --- compilers/imcc/imcc.y (revision 13035) +++ compilers/imcc/imcc.y (working copy) @@ -202,7 +202,7 @@ r-type = (r-type VT_ENCODED) ? VT_PCC_SUB|VT_ENCODED : VT_PCC_SUB; r-pcc_sub = calloc(1, sizeof(struct pcc_sub_t)); cur_call = r; -i-line = line - 1; +i-line = line ; add_namespace(interp, unit); return i; } -- Thanks, Vishal -- Thanks, Vishal -- Thanks, Vishal
Re: [perl #39734] t/doc/pod.t fails on Mac OS 10.4.6/perl 5.8.8
On Thu, Jul 06, 2006 at 06:22:31AM -0700, jerry gay wrote: On 7/5/06, via RT David H. Adler [EMAIL PROTECTED] wrote: As bugs go, not a killer, but still... The problem tests are as follows: not ok 329 - POD test for /Users/dha/parrot-0.4.5/src/ops/experimental.ops # Failed test (t/doc/pod.t at line 62) # /Users/dha/parrot-0.4.5/src/ops/experimental.ops (229): '=item' outside of any '=over' and not ok 1162 - POD test for /Users/dha/parrot-0.4.5/docs/ops/experimental.pod # Failed test (t/doc/pod.t at line 62) # /Users/dha/parrot-0.4.5/docs/ops/experimental.pod (105): '=item' outside of any '=over' i can't recreate this with a recent revision. from the svn log, it seems src/ops/experimental.ops was modified 19 june. perhaps you have a modified file in your working copy? Actually, as I see it, you have a modified file in yours. :-) I was working from the release version, which predates that change by about 2 hours... I guess it's fixed now. I suppose this is what I get for posting bug reports at 3am... dha -- David H. Adler - [EMAIL PROTECTED] - http://www.panix.com/~dha/ In the silence that followed, Homer was heard to mutter, Mmmm... context- dependent semantics... - Darrin Edwards in c.l.p.m.
.namespace [''] in TGE
I think this patch is advisable, or at least not wrong. Yes/no? === compilers/tge/TGE/Compiler.pir == --- compilers/tge/TGE/Compiler.pir (revision 13181) +++ compilers/tge/TGE/Compiler.pir (local) @@ -380,6 +380,9 @@ .return (code) .end +# NOTE - this code assumes that a type of '' is impossible +#(in older versions of Parrot, it was) + .sub 'grammar_string' :method .param pmc grammar .local string code @@ -387,9 +390,13 @@ .local string inherit type = grammar[type] inherit = grammar[inherit] -code = \n.namespace [ ' +code = \n.namespace +if type == '' goto no_type +code .= [ ' code .= type -code .= ' ]\n\n +code .= ' ] + no_type: +code .= \n\n code .= .sub '__onload' :load\n code .= load_bytecode 'TGE.pbc'\n code .= $I0 = find_type ' -- Chip Salzenberg [EMAIL PROTECTED]
Re: Old and broken versions of Module::Install
Michael G Schwern schrieb: On 7/6/06, Steffen Mueller [EMAIL PROTECTED] wrote: Versions of Module::Install 0.61 do not work on the current ActivePerl release 5.8.8 build 817. What's broken and why suddenly 5.8.8? ActiveState introduced some new form of local configuration or something. Module::Install couldn't handle it until 0.61. M::I's change log would have told you: [Changes for 0.61 - 2006-03-15] * ActivePerl::Config on case-insensitive filesystems interacts erroneously with Module::Install's (outdated) @INC hack, so remove it. (Patch from Gisle Aas) [...] Sounds like its a combination of an M::I hack and Windows being the bad platform its often perceived as. 5.8.8 because AS Perl build 817 *is* 5.8.8. Build 816 was the first 5.8.8 build and a bad build (some symbols weren't exported, PAR broke, etc.) which is why 817 was pushed out of the door quickly. I don't *think* versions prior to build 816 were affected. Now, that doesn't help. It just means people who have AS Perl on their boxes since before the 816 release won't notice a problem. (Hence the cpan testers results for win32 are likely PASS if no other problems exist.) But if a new Perl programmer or an end user who wants to run an application written in Perl on Windows installs AS Perl build 817 (which happens to be 5.8.8), he or she will not be able to install many modules from CPAN. (One way or another you'll end up installing a M::I based module due to dependencies.) Just one more thing. Please, nobody suggest that people download older AS Perl releases to fix this. It's not going to happen. Unless, of course, you want to limit the usage of Perl (and CPAN) to programmers and sysadmins. Does that clarify things? Steffen
RE: Old and broken versions of Module::Install
On Thu, 06 Jul 2006, Michael G Schwern wrote: On 7/6/06, Steffen Mueller [EMAIL PROTECTED] wrote: Versions of Module::Install 0.61 do not work on the current ActivePerl release 5.8.8 build 817. What's broken and why suddenly 5.8.8? Module::Install version 0.60 and earlier pushes one of its own directories to the front of @INC, and that directory contains Base.pm or BASE.pm, shadowing the core base.pm on case insensitive filesystems (Windows, OS X). ActivePerl 5.8.7 build 815 and later load additional code in Config.pm to automatically adjust to using dmake and gcc if nmake and/or the Microsoft compiler cannot be found on the PATH. This allows you to use MingW with ActivePerl out of the box with zero configuration required. One of the modules used in the ActivePerl::Config code use 'base.pm', which breaks if it cannot load the core version anymore. This has been fixed in Module::Install version 0.61: http://rt.cpan.org/Public/Bug/Display.html?id=18181 I've also modified the code in ActivePerl to not use base.pm in any of the modules loaded by Config.pm, so starting with build 818 you should be able to install CPAN modules with the broken Module::Install again. Cheers, -Jan
Re: TAP extension proposal: test groups
On 7/4/06, Ovid [EMAIL PROTECTED] wrote: Original Message From: Jonathan Rockway [EMAIL PROTECTED] This leads me to another question -- what to do about output that the program prints to STDOUT or STDERR? There are some modules that I use that insist on Cwarn-ing whenever something weird happens... will these mess up my tests? (They don't *now*, but that's because Test::Harness is being overly nice.) From the discussion here, anything which is not recognized as TAP output is discarded, so those warnings probably won't matter unless they look like a test plan or a test line. I'm finding myself more and more liking this feature of TAP and reversing my will become more stringent in the future declaration. If nothing else it makes backwards compatibility with older TAP parsers a lot easier to deal with. Anyhow, TAP says nothing about STDOUT or STDERR. It just wants a stream of text. If your TAP source decides to blend STDOUT and STDERR together and feed it to the TAP parser, it can do that. What would happen if TAP dictated that TAP output be sent to an extra filehandle? For example, prove could open filehandle 3, fork the test process, and collect TAP data on descriptor 3 ... Unless I'm greatly mistaken, the is outside the scope of TAP. TAP is merely a protocal and where it gets written to/read from should be irrelevant. Mandating that would only impose extra overhead. More importantly it would limit us to executing local programs on systems with good filehandle support. Consider the case of accepting TAP by fetching an HTTP uri. No filehandles there. I'm sure you could fake it, but then all your simplicity is gone.
Re: TAP extension proposal: test groups
On 7/3/06, Jonathan Rockway [EMAIL PROTECTED] wrote: If you wanted to truly please DJB (with his don't parse mantra), then you could open two extra filehandles, one for 'ok' and one for 'not ok', and print the number of the test mod 256 (i.e. one byte per test, no newline; just the byte) to each handle. If it comes in on pipe one and the number is where it should be, it's a 'ok #', if it comes in on that second pipe, it's a 'not ok #'. Some days I wish I was DJB and only had to support one operating system and one environment. :P
PGE and TGE vs. .namespace
The below patches are my guess as to how to fix PGE and TGE for the recent change in .namespace. (That is, C.namespace [''] now means what it says, and the HLL root is reachable by C.namespace w/o parameters.) The TGE patch seems to work, but I got test failure from my PGE patch. Patrick? Allison? === compilers/tge/TGE/Compiler.pir == --- compilers/tge/TGE/Compiler.pir (revision 13181) +++ compilers/tge/TGE/Compiler.pir (local) @@ -380,6 +380,9 @@ .return (code) .end +# NOTE - this code assumes that a type of '' is impossible +#(in older versions of Parrot, it was) + .sub 'grammar_string' :method .param pmc grammar .local string code @@ -387,9 +390,13 @@ .local string inherit type = grammar[type] inherit = grammar[inherit] -code = \n.namespace [ ' +code = \n.namespace +if type == '' goto no_type +code .= [ ' code .= type -code .= ' ]\n\n +code .= ' ] + no_type: +code .= \n\n code .= .sub '__onload' :load\n code .= load_bytecode 'TGE.pbc'\n code .= $I0 = find_type ' === compilers/pge/PGE/P6Regex.pir == --- compilers/pge/PGE/P6Regex.pir (revision 13181) +++ compilers/pge/PGE/P6Regex.pir (local) @@ -117,9 +117,14 @@ pir: .local pmc code .local string grammar +.local string nsformat grammar = adverbs['grammar'] +nsformat = .namespace +if grammar == '' goto pir_emit +nsformat = .namespace [ '%0' ] + pir_emit: code = new 'PGE::CodeString' -code.emit(.namespace [ '%0' ], grammar) +code.emit(nsformat, grammar) $P0 = exp.root_pir(adverbs :flat :named) code .= $P0 if target != 'PIR' goto bytecode -- Chip Salzenberg [EMAIL PROTECTED]
Re: [perl #39734] t/doc/pod.t fails on Mac OS 10.4.6/perl 5.8.8
On 7/6/06, David H. Adler [EMAIL PROTECTED] wrote: On Thu, Jul 06, 2006 at 06:22:31AM -0700, jerry gay wrote: perhaps you have a modified file in your working copy? Actually, as I see it, you have a modified file in yours. :-) I was working from the release version, which predates that change by about 2 hours... your report didn't specify which revision you were testing. as parrot's under active (pre-release) development, i assumed HEAD. I guess it's fixed now. I suppose this is what I get for posting bug reports at 3am... no problem, no bugs are good bugs :) thanks for reporting! ~jerry
Re: Old and broken versions of Module::Install
Steffen Mueller wrote: Michael G Schwern schrieb: What's broken and why suddenly 5.8.8? * ActivePerl::Config on case-insensitive filesystems interacts erroneously with Module::Install's (outdated) @INC hack, so remove it. (Patch from Gisle Aas) [...] Sounds like its a combination of an M::I hack and Windows being the bad platform its often perceived as. I take issue with the bad platform bit. The underlying issue is Perl developers who assume unix semantics (perhaps unconsciously, even) and don't write for portability. The Vanilla Perl project (vanillaperl.com) has been squashing numerous bugs of this sort in CPAN modules. There are surprisingly many forward/backslash bugs, even by developers who should know better. Many of them crop up in test-suites, even when the code itself uses File::Spec. The M::I hack doesn't help, but probably neither does AS's config hacking. David Golden
Re: Old and broken versions of Module::Install
Jan Dubois schrieb: Module::Install version 0.60 and earlier pushes one of its own directories to the front of @INC, and that directory contains Base.pm or BASE.pm, shadowing the core base.pm on case insensitive filesystems (Windows, OS X). Thank you for the explanation. I wasn't aware of this. ActivePerl 5.8.7 build 815 and later load additional code in Config.pm to automatically adjust to using dmake and gcc if nmake and/or the Microsoft compiler cannot be found on the PATH. This allows you to use MingW with ActivePerl out of the box with zero configuration required. Which is great, by the way. One of the modules used in the ActivePerl::Config code use 'base.pm', which breaks if it cannot load the core version anymore. This has been fixed in Module::Install version 0.61: http://rt.cpan.org/Public/Bug/Display.html?id=18181 I've also modified the code in ActivePerl to not use base.pm in any of the modules loaded by Config.pm, so starting with build 818 you should be able to install CPAN modules with the broken Module::Install again. While that's also great, I still think the old Module::Install versions lying around on CPAN are prone to blow up eventually and need a fix. Steffen
Re: Old and broken versions of Module::Install
On 7/6/06, David Golden [EMAIL PROTECTED] wrote: Steffen Mueller wrote: Michael G Schwern schrieb: What's broken and why suddenly 5.8.8? * ActivePerl::Config on case-insensitive filesystems interacts erroneously with Module::Install's (outdated) @INC hack, so remove it. (Patch from Gisle Aas) [...] Sounds like its a combination of an M::I hack and Windows being the bad platform its often perceived as. I take issue with the bad platform bit. The underlying issue is Perl developers who assume unix semantics (perhaps unconsciously, even) and don't write for portability. The Vanilla Perl project (vanillaperl.com) has been squashing numerous bugs of this sort in CPAN modules. There are surprisingly many forward/backslash bugs, even by developers who should know better. Many of them crop up in test-suites, even when the code itself uses File::Spec. Hear, hear! Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
Allison Randal wrote:
I had a much longer reply, but I'm going to let it steep overnight and
see what percolates.
I ran through a number of possibilities, but so far my favorite is:
find_global and store_global are truly 'global', that is, they always
require a fully specified namespace, including the HLL namespace.
$P0 = find_global 'bar' # the top-level namespace
$P1 = find_global 'parrot', 'bar' # 'bar' in ['parrot']
$P2 = find_global ['parrot';'Foo'], 'bar' # 'bar' in ['parrot';'Foo']
$P3 = find_global 'tcl', 'bar'# 'bar' in ['tcl']
Then a set of opcodes using the add_*, del_*, get_* naming scheme handle
the magically assume the HLL root/current namespace behavior. (PDD 21
uses both get_* and find_* for retrieval. It's better to standardize on
one, but it doesn't really matter which one.)
.HLL Perl5, perl5_group
$P0 = get_symbol 'bar'# 'bar' in ['perl5']
$P1 = get_symbol 'Foo', 'bar' # 'bar in ['perl5';'Foo']
.namespace [ 'Foo' ]
$P2 = get_symbol 'bar'# 'bar' in ['perl5';'Foo']
(I thought about prefixing all the opcodes that assume the HLL namespace
with hll_, but since those are the common case, I'd rather mark the
rarer global case.)
The .namespace directive has more flexibility, since it's a directive
not an opcode. We can keep the basic syntax as the magical HLL behavior:
.namespace [ 'Foo' ]# namespace is ['parrot';'Foo']
.HLL Perl5, perl5_group # namespace is ['perl5']
.namespace [ 'Foo' ]# namespace is ['perl5';'Foo']
If you only use .HLL and no .namespace, then it assumes the root HLL
namespace.
And add a couple of special forms for the rarer cases when you want to
set the current namespace to the HLL or global root:
.namespace hll_root
.namespace global_root
--
Here are some of the also-rans, in abbreviated form:
--
We could take the Perl 5 strategy of reserving a name ('main' or 'root'
or something similar) to always act as an alias to the top-level of the
current HLL namespace.
Conclusion: Perl 5 on Parrot will use this strategy, and so might other
languages, but we shouldn't force it on all languages.
--
We could break out the root prefix from the rest of the name:
$P2 = find_global 'parrot', ['Foo'], 'bar' # bar in ['parrot';'Foo']
Conclusion: reaching the global root would require an empty prefix key
and an empty namespace name key. Not really an improvement, more of an
unprovement.
--
We could have separate opcodes for direct access and hll indirect
access.
Conclusion: this led to a combinatorial explosion (bad), but then to the
simplified solution above.
--
We could assume the current HLL namespace, and call methods on the
namespace object to retrieve meta information like the root HLL
namespace or global namespace.
Conclusion: more complex than is necessary to solve the problem.
--
Allison
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
Chip Salzenberg wrote: On Thu, Jul 06, 2006 at 01:21:08AM -0700, Allison Randal wrote: The problem is really that we're trying to simultaneously a) refer to the root HLL namespace directly, and b) pretend that it doesn't exist. I don't think (b) is quite true. It's more that we're avoiding explicit re-coding of a known bit of environmental information, as in the first floor of this building rather than the first floor of 123 main street. That's another good way of phrasing it. It's essentially the linguistic problem of being able to refer to something both by its full name and by the pronoun it. (Otherwise known as topic.) Only, currently it isn't represented by a word. There are natural languages with zero-length pronouns, but they generally compensate by marking the verb with enough information to disambiguate. And when that gets unclear, they throw in the full name again. ...I was hoping you'd say something like, Oh yeah, we're gonna need zero-length keys anyway for Perl 6. What is the parameter to operator:postcircumfix [] when a user says @array.[] ? Various HLLs will assign some meaning to a null key. But the semantics of this isn't keyed access. The HLL is just using a bit of unused syntax to mean return an empty list, or return null, or return all the elements of the array as a list, or whatever else they decide to use it for. It's up to the HLL compiler to distill the syntax down to meaningful semantics. Allison
Re: namespaces, a single colon to separate HLL prefix?
On Thu, 2006-07-06 at 09:09 -0700, Larry Wall wrote:
On Thu, Jul 06, 2006 at 10:40:21AM -0400, Audrey Tang wrote:
: The : form is approved and canonical (line 303, the Modules spec, aka
: S11.pm version 14).
:
: use perl5:DBI;
[...]
: my $dbh = perl5:DBI; # currently parsed as perl5(:DBI)
:
: but we can say that for each HLL-qualified module name, it's a single
: token and is therefore recognized first.
:
: Does that sound sane? If yes, S11 can be updated to reflect that.
It's only sane if we require the predeclaration of the language higher
in the lexical scope.
Namespaces aren't your only concern here. You also care about all of the
semantics of module loading and the integration of the target language's
module loading semantics with Perl 6's. For example, there's a
completely separate search path for Perl 5 modules, and an implicit
invocation of a package method that might not happen in P6. I think what
you want to be saying is not, use DBI from the Perl 5 namespace, but
invoke the Perl 6 / Perl 5 module loader interface for DBI.
That's really something like:
use Lang::Perl5::Loader;
perl5use DBI;
That we provide a shortcut called use perl5:DBI is just sugar, and we
might provide that for many languages. However, the user should know how
to do it the hard way in case they want to talk to a less officially
blessed language:
use Lang::Bash::Loader;
use Lang::Elisp::Loader;
bashuse ~/.bashrc;
elispuse hanoi;
say %*ENV{PATH}
hanoi(13);
Inventing syntactic sugar for the back-end case probably doesn't buy you
anything special.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
We had some good machines, but they don't work no more. -Shriekback
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
[svn:parrot-pdd] r13183 - in trunk: . compilers/imcc docs docs/dev docs/pdds editor languages/regex languages/tcl src
Author: chip
Date: Thu Jul 6 13:05:47 2006
New Revision: 13183
Modified:
trunk/docs/pdds/pdd00_pdd.pod
Changes in other areas also in this revision:
Modified:
trunk/README
trunk/README.win32.pod
trunk/RELEASE_INSTRUCTIONS
trunk/compilers/imcc/README
trunk/docs/debug.pod
trunk/docs/dev/dod.pod
trunk/docs/faq.pod
trunk/docs/gettingstarted.pod
trunk/docs/glossary.pod
trunk/docs/intro.pod
trunk/docs/parrot.pod
trunk/docs/submissions.pod
trunk/editor/pir-mode.el
trunk/languages/regex/README
trunk/languages/tcl/README.pod
trunk/parrotbug
trunk/src/exceptions.c
Log:
From: Chris Dolan [EMAIL PROTECTED]
Subject: Re: [perl #39743] [PATCH] change perl6-internals to parrot-porters in
docs
{ a followup patch will be required if p6i doesn't end up forwarding to p2 }
Modified: trunk/docs/pdds/pdd00_pdd.pod
==
--- trunk/docs/pdds/pdd00_pdd.pod (original)
+++ trunk/docs/pdds/pdd00_pdd.pod Thu Jul 6 13:05:47 2006
@@ -145,8 +145,8 @@
=head2 SUBMISSION CRITERIA
-Proposed PDDs should be submitted to the perl6-internals mailing list (located
-at perl6-internals@perl.org) for discussion, criticism and general kibitzing.
+Proposed PDDs should be submitted to the parrot-porters mailing list (located
+at [EMAIL PROTECTED]) for discussion, criticism and general kibitzing.
Acceptance of a particular PDD is ultimately up to the Parrot Architect.
=head2 PDD TRANSLATIONS
Re: [perl #39743] [PATCH] change perl6-internals to parrot-porters in docs
On Thu, Jul 06, 2006 at 02:52:10PM -0500, Chris Dolan wrote: Oops, I missed a couple of instances of perl6-internals in the previous patch (notably, in parrotbug). This updated patch obsoletes the previous one. Thanks, applied. A followup may be needed if p6i ends up *not* forwarding to p2. The perl.org admins are not pleased by the prospect, saying it has caused confusion in the past, and it's easy for a bounce message to tell people a new list address. % diffstat parrot-porters2.patch README |4 ++-- Hey, I *like* diffstat. I wish I saw it used more. -- Chip Salzenberg [EMAIL PROTECTED]
Re: Module Signatures
Sorry, meant to send this to the list. :) What’s the point? Good question. Crypt::OpenPGP doesn't maintain a web-of-trust either. People that have webs of trust have GPG, otherwise, what are they using? If all that’s verified is that the distribution was signed with the key uploaded to the same directory, then all you can have confidence in is that distribution was uploaded by someone who has permission to upload a key. That might be the author, or it might be an impostor who got ahold of the author’s account details and uploaded his own key. This protects end-users against a malicious CPAN mirror, though. If PAUSE is compromised, that's a whole other set of problems. (Yes, WoT would protect you from PAUSE being compromised. Only if your network is extensive enough to cover every person who has ever uploaded anything to CPAN. I use PGP extensively, but have never actually verified any CPAN authors' keys in person. I tried at YAPC but I never managed to actually find anyone that was intersted in exchanging keys :) I doubt the average JAPH is going to go to that much effort just to be sure that nobody's secretly compromised the PAUSE or their friendly local CPAN mirror. I don’t think running a cert auth is feasible for CPAN. So the only worthwhile option is to participate in the PGP web of trust. If you do away with that, you can just as well do away with cryptosigs alltogether. True. Right now they're pretty useless. I have downloaded some modules that didn't verify and installed them anyway. Jifty, for example, contains a bunch of ._foo and ._bar files that aren't in the MANIFEST, and therefore CPANPLUS chokes when you try to install it. On a more positive note, we can eliminate a lot of Crypt::OpenPGP's dependencies by stripping out keygen (Crypt::Random - Math::Pari, which is a nightmare to isntall on some systems). If everyone somehow gets a web-of-trust, then modifying Crypt::OpenPGP to require a certain level of trust would be simple. Right now, though, it's just not worth it IMHO. (What would be marginally worth it is having PAUSE sign distros. At least we can assure that the CPAN mirror didn't tamper with the files, which I think is the most likely attack on CPAN.) Regards, Jonathan Rockway
Re: CPAN and META.yml: no_index dir vs directory
Hmm, it looks like there is a strong correspondence between distros using 'directory' and distros produced by Module::Install. There goes Adam, breaking rules and rebelling against established conventions. Hehe. Just kidding. I think I like 'directory' better myself anyway. Sigh, one of these days people will realize that Module::Install is NOT MY FAULT and I'm just the guy that documents EXISTING behavior and tries to make things less buggy and insane. Well, except for the 0.59 and 0.60 disaster, that was my fault... But yes, Module::Install does use directory, and it adds it pretty much automatically to make sure nothing in t gets indexed, but I'm not sure why that got added as directory, and in any case I like it better too. :) While we're tweaking META.yaml, can we find out if ANYBODY is using is_dynamic (the optimization flag), and if not can we move it to is_static, like it should have been in the first place. There's also been requests for things like links to SVN, RT/support, and commercial support in the spec. Is it perhaps time for a more general 0.1 increment? Adam K
Re: Old and broken versions of Module::Install
But you’re not catching me dead using an installer that requires me to pay attention to its development and to push up new versions of my distros in response to its bugs. There are far better ways to waste my time. Good, because that's entirely the point I've been trying to make ever since I started doing maint releases of Module::Install. Module;:Install is not finished (at 1.0) and until it is if you want to take advantage of it as an early user, you should be willing to do the occasional incremental release if something big comes up. Module::Build is not finished (at 1.0) and until it is if you want to take advantage of it as an early user, and you use ::Compat, you should be willing to do the occasional incremental release if something big comes up. If you ONLY use the basic functionality, and you aren't willing to pay attention, you should be using EU:MM still, until either MB or or MI hits 1.0, because neither of them are ready for general use. I find it unfortunate that hype on both sides resulted in what I would consider overuse this early in their development, but there you go... Adam K
Re: PGE and TGE vs. .namespace
Chip Salzenberg wrote: The below patches are my guess as to how to fix PGE and TGE for the recent change in .namespace. (That is, C.namespace [''] now means what it says, and the HLL root is reachable by C.namespace w/o parameters.) TGE and PGE both need a thorough going-over for the new namespaces implementation. I'm thinking they should act in an HLL-agnostic fashion, so it's possible to compile one grammar in, say, the Perl 6 HLL namespace, another in Ruby, another in Python, and another system-internal grammar into 'parrot'. Allison
Re: Old and broken versions of Module::Install
* Adam Kennedy [EMAIL PROTECTED] [2006-07-07 00:00]: If you ONLY use the basic functionality, and you aren't willing to pay attention, you should be using EU:MM still, until either MB or or MI hits 1.0, because neither of them are ready for general use. Manual inspection has always suggested that the Makefile.PL generated for me by M::B::Compat is sane enough. Given that, I’d prefer to stick with it so I don’t have to do much of anything at the time that M::B hits both 1.0 and core. I understand the concerns with M::B itself; that’s why I always use `create_makefile_pl = 'traditional'`. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
On Thu, Jul 06, 2006 at 12:11:47PM -0700, Allison Randal wrote: It's essentially the linguistic problem of being able to refer to something both by its full name and by the pronoun it. (Otherwise known as topic.) Only, currently it isn't represented by a word. Well, we have three distinct 'it's for namespaces: the Parrot root, the HLL root, and the current. I view the HLL root as the main one for most purposes, and escaping the HLL root I model as escaping a Unix chroot (in rarity if not security), which is why I'm conformable with using interpinfo to get the global root. And of course the current namespace maps onto the Unix working dir for me. -- Chip Salzenberg [EMAIL PROTECTED]
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
{ All you HLL implementors and other PIR users out there, please be assured
that I'll be providing as easy a transition as possible when/if these global
opcodes are adjusted. }
On Thu, Jul 06, 2006 at 11:53:59AM -0700, Allison Randal wrote:
I ran through a number of possibilities, but so far my favorite is:
find_global and store_global are truly 'global', that is, they always
require a fully specified namespace, including the HLL namespace.
Then a set of opcodes using the add_*, del_*, get_* naming scheme handle
the magically assume the HLL root/current namespace behavior. (PDD 21
uses both get_* and find_* for retrieval. It's better to standardize on
one, but it doesn't really matter which one.)
Well, I see a lot to like about this, but (and you knew there was a but
(but that's my job now :-))), in descending order of difficulty:
* The division into two categories (global and symbol) leaves the third
category (current namespace) with no clear home.
* All the things being accessed are globals. Seems like the word global
should be used consistently, and symbol has many meanings in Parrot
that only partly overlap the specific meaning of global.
* We still don't have way to ask for my HLL without spelling it. I can
say my HLL's Foo without spelling my HLL, but when I go up to my HLL's
root I must suddenly know the spelling of my HLL and say it. Seems like
a sign of a design problem.
* The global root is available as Cinterpinfo .INTERPINFO_ROOT_NAMESPACE
at present -- awkward but fast. Since global root accesses are supposed
to be rare, awkwardness doesn't bug me for that case. But adding opcodes
for absolute-root ... hey, absolute, that's a good name.
* Huffmanizing shouldn't be as big a consideration with PIR/pasm as with
most languages. Most PIR/pasm is program-generated.
So here's an illustrative suggestion, which I think is a variant on one of
your also-rans, albeit one that leaves the common HLL case unmarked:
.HLL 'perl5', perl5_group
.namespace ['Foo']
$P0 = get_cur_global 'x' # ['perl5';'Foo';'x']
$P0 = get_cur_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
$P0 = get_global 'x' # ['perl5';'x']
$P0 = get_global ['Corge'], 'x' # ['perl5';'Corge';'x']
$P0 = get_abs_global 'x' # ['x']
$P0 = get_abs_global ['parrot'], 'x' # ['parrot';'x']
(If there is no Null, substitute a null PMC register.)
--
Chip Salzenberg [EMAIL PROTECTED]
Re: PGE and TGE vs. .namespace
On 7/6/06, Allison Randal [EMAIL PROTECTED] wrote: Chip Salzenberg wrote: The below patches are my guess as to how to fix PGE and TGE for the recent change in .namespace. (That is, C.namespace [''] now means what it says, and the HLL root is reachable by C.namespace w/o parameters.) TGE and PGE both need a thorough going-over for the new namespaces implementation. meanwhile, back at the ranch, perl6 is failing all t/00-parrot/08-regex.t tests due to the .namespace changes. chip's proposed PGE patch fixes those failures. i don't mind broken tests between releases, but if this patch won't be applied in the next day or three, let me know. the tests can be marked as TODO, and we can eagerly wait for the day of unexpected success that will surely follow. ~jerry
Re: PGE and TGE vs. .namespace
On Thu, Jul 06, 2006 at 04:44:35PM -0700, jerry gay wrote: On 7/6/06, Allison Randal [EMAIL PROTECTED] wrote: Chip Salzenberg wrote: The below patches are my guess as to how to fix PGE and TGE for the recent change in .namespace. (That is, C.namespace [''] now means what it says, and the HLL root is reachable by C.namespace w/o parameters.) TGE and PGE both need a thorough going-over for the new namespaces implementation. meanwhile, back at the ranch, perl6 is failing all t/00-parrot/08-regex.t tests due to the .namespace changes. chip's proposed PGE patch fixes those failures. Indeed, the patch has nothing to do with extending full nested namespace support to TGE and PGE. It's just a regression fix now that .namespace [''] doesn't do what it used to. Unless you're planning to do that overhaul before 0.4.6, I'd like to at least avoid those regressions. -- Chip Salzenberg [EMAIL PROTECTED]
Re: PGE and TGE vs. .namespace
jerry gay wrote: On 7/6/06, Allison Randal [EMAIL PROTECTED] wrote: meanwhile, back at the ranch, perl6 is failing all t/00-parrot/08-regex.t tests due to the .namespace changes. chip's proposed PGE patch fixes those failures. Oh, I didn't mean don't apply it, just there's more work ahead. I can't speak for Patrick, but go ahead and apply the TGE patch. Chip, did you resolve the failing PGE test(s)? Allison
Re: Module Signatures
(What would be marginally worth it is having PAUSE sign distros. At least we can assure that the CPAN mirror didn't tamper with the files, which I think is the most likely attack on CPAN.) Frankly, that's the best idea I've heard yet. It would at least be trivial to implement compared to the current situation, and would allow us to provide some manner of security against bad mirrors. The only downside though might be problems if we have custom mirrors that have third-party module built into them. But in general I find the idea less insane that what we do now. Adam K
Re: Old and broken versions of Module::Install
I understand the concerns with M::B itself; that’s why I always use `create_makefile_pl = 'traditional'`. Indeed, and if you insist on using Module::Build, that is most certainly the sanest approach. Adam K
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
On 7/6/06, Chip Salzenberg [EMAIL PROTECTED] wrote: So here's an illustrative suggestion, which I think is a variant on one of your also-rans, albeit one that leaves the common HLL case unmarked: .HLL 'perl5', perl5_group .namespace ['Foo'] $P0 = get_cur_global 'x' # ['perl5';'Foo';'x'] $P0 = get_cur_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x'] am i silly to think that if i'm looking for globals from the current namespace, they're just as likely to be found closer to the namespace root, than further away? perhaps something like .namespace [ 'Foo'; 'Bar' ] $P0 = get_cur_global -1, 'x' # [ 'perl5' ; 'Foo' ; 'x' ] i don't see any examples that make it easy to look in that direction. ~jerry
Re: Module Signatures
Andreas J. Koenig wrote: On Fri, 07 Jul 2006 10:02:00 +1000, Adam Kennedy [EMAIL PROTECTED] said: (What would be marginally worth it is having PAUSE sign distros. At least we can assure that the CPAN mirror didn't tamper with the files, which I think is the most likely attack on CPAN.) Frankly, that's the best idea I've heard yet. What does it bring you more that the signed CHECKSUMS file? That sounds more or less equivalent. Are they signed now? Adam K
Re: Module Signatures
On Fri, 07 Jul 2006 10:02:00 +1000, Adam Kennedy [EMAIL PROTECTED] said: (What would be marginally worth it is having PAUSE sign distros. At least we can assure that the CPAN mirror didn't tamper with the files, which I think is the most likely attack on CPAN.) Frankly, that's the best idea I've heard yet. What does it bring you more that the signed CHECKSUMS file? -- andreas
Re: Module Signatures
* Adam Kennedy [EMAIL PROTECTED] [2006-07-07 03:25]: Andreas J. Koenig wrote: On Fri, 07 Jul 2006 10:02:00 +1000, Adam Kennedy [EMAIL PROTECTED] said: (What would be marginally worth it is having PAUSE sign distros. At least we can assure that the CPAN mirror didn't tamper with the files, which I think is the most likely attack on CPAN.) Frankly, that's the best idea I've heard yet. What does it bring you more that the signed CHECKSUMS file? That sounds more or less equivalent. Are they signed now? And if so, by whom? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
Allison Randal [EMAIL PROTECTED] wrote: Chip Salzenberg wrote: --- PART 2, IN WHICH AN ELEGANT SOLUTION IS PROPOSED -- On the other hand, we could extend the key PMC to represent emptiness, i.e. zero dimensions. This seems useful for namespaces and could even prove useful for real keys. And this makes keys even more compatible with the Array interface, which I think they might need to implement someday anyway. Allison, what do you think of zero-length keys, i.e. having [] construct a Key PMC describing no dimensions of lookup? If we use those we can get rid of the current null-string hack. Fundamentally altering the way keyed access works seems like a pretty extreme solution when the problem is just the root HLL namespace doesn't have a name. (Actually, it does have a name: 'parrot', 'tcl', 'perl6', etc. A sort of key who must not be named, if I won't be shot for making terrible Harry Potter references at 1am.) I don't think fundamentally altering the way keyed access works is a fair description of what Chip proposed (and what I was asking for). 0-dimensional keys seem like a logical extension to multi-dimensional keys, IMO. Chip actually forgot that there is another way to get to the root HLL namespace besides using the null string hack: $P0 = new .ResizablePMCArray # this can be any array type $P1 = get_namespace $P0 But arrays fill a different niche than keys do. Arrays are a runtime solution and keys are a compile time solution. Writing out arrays when you're writing code is painful and making keys at runtime is impossible AFAICT. So for the runtime (this is the HLL runtime, not the PIR runtime, btw) we're all set. Arrays fill the need perfectly and let us access the root HLL namespace. That makes me think that we don't need any new opcodes. It's just the compile time time -- the code that humans actually have to write -- that is giving us trouble. That's a bit of a simplification because in many cases compiler writers can optimize the code and use keyed access in the output code, but it's just as simple in that case to use any old hack. That's why I was asking for C $P0 = get_namespace [] -- because I actually have to write it. And I think it's a worthy goal to make compiler writer's lives good. Adding 0-dimensional keys would also let us get rid of the C .namespace special case and replace it with C .namespace [] . It's simpler to give the root HLL namespace a name. I disagree on two counts here. First, I think C [] *is* a name. Second, any solution which involves giving the HLL namespace a different name will have to either (a) add new opcodes, (b) add more code for all the other cases by making all referencing originate at the root, or (c) add a special syntax, none of which is simple. -- matt diephouse http://matt.diephouse.com
Re: PGE and TGE vs. .namespace
On Thu, Jul 06, 2006 at 05:22:47PM -0700, Allison Randal wrote: jerry gay wrote: On 7/6/06, Allison Randal [EMAIL PROTECTED] wrote: meanwhile, back at the ranch, perl6 is failing all t/00-parrot/08-regex.t tests due to the .namespace changes. chip's proposed PGE patch fixes those failures. Oh, I didn't mean don't apply it, just there's more work ahead. I can't speak for Patrick, but go ahead and apply the TGE patch. Chip, did you resolve the failing PGE test(s)? Oddly enough, no. I actually made it worse, to my great surprise. Still hacking tho... -- Chip Salzenberg [EMAIL PROTECTED]
Re: PGE and TGE vs. .namespace
On Thu, Jul 06, 2006 at 10:01:39PM -0700, Chip Salzenberg wrote: On Thu, Jul 06, 2006 at 05:22:47PM -0700, Allison Randal wrote: jerry gay wrote: On 7/6/06, Allison Randal [EMAIL PROTECTED] wrote: meanwhile, back at the ranch, perl6 is failing all t/00-parrot/08-regex.t tests due to the .namespace changes. chip's proposed PGE patch fixes those failures. Oh, I didn't mean don't apply it, just there's more work ahead. I can't speak for Patrick, but go ahead and apply the TGE patch. Chip, did you resolve the failing PGE test(s)? Oddly enough, no. Strangely enough, yes. Apparently I hadn't waved enough 'make clean' chickens over the computer. All better now. -- Chip Salzenberg [EMAIL PROTECTED]
