Re: Git workflow
Moritz Lenz wrote in perl.perl6.compiler : Hi, fREW Schmidt wrote: I just threw together a workflow for git with rakudo ( http://wiki.github.com/rakudo/rakudo/frews-recommended-workflow) and I think it will help a lot. Hopefully I didn't make any mistakes. Anyway, I plan on trying it out tomorrow (Boo Haman!) and I'd appreciate it if anyone who knows git well will make any necesary changes. When you did more than one commit in the branch, please merge with the ---squash option, so that our dear pumpking only has to review one patch, not multiple. As someone who reviews patches quite often, my advice would be exactly the contrary -- I tend to prefer a series of small patches with long commit messages: that way it's easier to review the logic of the whole change. (Personal taste only.) -- It is official: perl people are crazy. -- Linus Torvalds on the git mailing list
Re: Files, Directories, Resources, Operating Systems
Richard Hainsworth wrote in perl.perl6.language : The S16: chown, chmod thread seems to be too unix-focussed. I was more or less thinking that the syscall-related primitives, like chown or chmod, could go in a POSIX namespace. Even in UNIX land nowadays the situation can be much more complex than traditional ownership and modes (a situation not entirely satisfactorily addressed by Perl 5's filetest pragma). Following the general perl6 philosophy, perhaps too there should be an abstract definition for the language that is core and additional modules that are specific to operating systems. Thus when generic software is distributed, it comes with an installer that determines the operating system chooses whether to use IO::Unix, IO::Unix::Gnome, IO::MS::WindowsXP, IO::MS::Vista, IO::Apple, etc. Maybe also IO::Internet::Http, IO::Internet::Ftp? IO (streams) and rights are not naturally related. Maybe you're thinking about filesystems and other content addressing schemes (like URLs). The subject is more complex than it seems at first glance, because you can have, for example, per-volume current working directories. It's quite hard to design something that is abstract enough, but at the same time not totally useless.
Re: [perl #60732] Hash indexes shouldn't work on array refs
Moritz Lenz wrote in perl.perl6.compiler : jerry gay wrote: On Fri, Nov 21, 2008 at 10:43, via RT Moritz Lenz [EMAIL PROTECTED] wrote: # New Ticket Created by Moritz Lenz # Please include the string: [perl #60732] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60732 From #perl6 today: 19:33 moritz_ rakudo: my $x = [ 42 ]; say $x0 19:33 p6eval rakudo 32984: OUTPUT[42] I don't think that should be allowed. the real test is: (8:52:47 PM) [particle]1: rakudo: my $x = [42]; say $x0_but_true; (8:52:49 PM) p6eval: rakudo 32998: OUTPUT[42] (8:53:38 PM) [particle]1: rakudo: my $x = [42]; say $xtrue_but_0; (8:53:40 PM) p6eval: rakudo 32998: OUTPUT[42] (8:53:50 PM) [particle]1: rakudo: my $x = [42]; say $xXXX; (8:53:52 PM) p6eval: rakudo 32998: OUTPUT[42] (8:54:37 PM) [particle]1: rakudo: my $x = ['a', 42]; say $xXXX; (8:54:39 PM) p6eval: rakudo 32998: OUTPUT[a] (8:58:41 PM) [particle]1: rakudo: my $x = ['a', 42]; say $x1.4; (8:58:44 PM) p6eval: rakudo 32998: OUTPUT[42] (8:58:48 PM) [particle]1: rakudo: my $x = ['a', 42]; say $x0.4; (8:58:50 PM) p6eval: rakudo 32998: OUTPUT[a] so, the index is coerced to an integer. is that really wrong? ~jerry IMHO yes, because Perl explicitly distinguishes between arrays and hashes (and it's one of the things we never regretted, I think ;-). Any intermixing between the two would only lead to confusion, especially if somebody writes a class whose objects are both hashe and array. Yes, that leads to confusion. (And confusion leads to anger, and so on) Which is why we removed pseudo-hashes from Perl 5.10. -- The key words SHALT, SHALT NOT, SMITE, and PILLAR OF SALT in this document are to be interpreted as expected. -- RFC 4041
Re: the future of testing
Allison Randal wrote in perl.perl6.internals : In the Python test suite, there's a single global location to declare a list of test files that are expected to be skipped on a particular platform. This has a much cleaner feel than our own motley collection of skip and todo markers in various test files. That assumes that tests are skipped per file, which is not always the case (sometimes you want to skip only one test, sometimes even to work around an OS bug that appears only in one specific version). But reorganizing platform-dependent tests might be a good idea. I (mostly on behalf on P5P) would find it interesting to see how that turns out to be implemented in parrot's test suite, so we can blatanly copy the good ideas and avoid the pitfalls :) -- The man does not exist who, outside his own specialty, is not credulous. -- Borges
Re: RPMs
David Fetter wrote in perl.perl6.internals : Folks, I've been wrestling with the .spec file to generate RPMs for parrot 0.4.12, and so far, the .spec file is winning, so I figured I'd do what I always do when I'm losing: fight dirty and call in help :) I think that Steven Pritchard has worked on RPMs for Fedora. See the fedora-perl-devel-list, at redhat.com. Notably, he posted this specfile there : http://ftp.kspei.com/pub/steve/rpms/parrot/parrot.spec -- I asked for concrete usage cases, not for everyone's opinions. -- Jeff Johnson in rpm-devel
Re: Negative array subscripts
Smylers wrote in perl.perl6.language : Hmmm, a pragma's a bit heavyweight for this; how about being able to set this with a special global variable -- that sure sounds handy ... Actually, in perl 5, $[ *is* a pragma... :) -- Grepping the source is good for the soul. -- the perldebguts manpage
Re: fetching module version from the command line
Gabor Szabo wrote in perl.qa : While checking if the versions of all the modules are as required in our installation I am using the following one liner to fetch the version numbers. perl -MModule -e'print $Module::VERSION' You should probably use -mModule to avoid calling Module::import(). (also, in some pathological cases, one can imagine that UNIVERSAL::VERSION() has been overidden) Side note: Abe Timmerman has a module, V, useful to get versions of installed modules: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-03/msg01038.html
Re: TAP::Harness
Michael G Schwern wrote in perl.qa : * What about Test::Harness? Test::Harness remains its own thing. At some point in the future Test::Harness will likely be gutted and turned into a thin wrapper around TAP::Harness. I'm not caring about this right now. What about prove(1) ? Are you going to make a version of it that uses TAP::Harness ? And it so, will it be removed it from T::H ? (I hope not, since it's part of the core). Or have a fork ? -- The rpmvercmp() algorithm has been implemented in shell, python, perl, ruby, java, and some gawd awful Oracle DB internal scripting language. Dunno about Forth and FORTRAN, but little surprises me any more. -- Jeff Johnson in rpm-devel
Re: interesting behavior in use_ok()
Ovid wrote in perl.qa :
You've run into a problem which surprises a few folks but definitely
causes problems. In a nutshell, use_ok internally traps the use
call with an eval. However, even if it fails (as in your case), the
bytecode might still be compiled and in memory and, as a result, some
tests might pass and others fail. As a result, *all* of my tests
generally start with something similar to the following (season to
test):
my $CLASS;
BEGIN {
$CLASS = 'Some::Module';
use_ok $CLASS or die; # or die saves the day
maybe BAIL_OUT could be better than die here, in at least a few cases.
}
can_ok $CLASS, 'new';
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
Andy Lester wrote: I'm approaching the end of this release cycle. I really want to get this released. I've removed the meaningless percentages of tests that have failed. If you rely on the output at the end, it's different now. I'm not attached to percentages, which I wasn't looking at anyway, but when several tests fail, the header is repeated for each test. Failed Test Stat Wstat Total Fail List of Failed ---
Re: Smoke [5.9.4] 27938 FAIL(X) linux 2.6.15-20-386 [debian] (i686/1 cpu)
On 23/04/06, Steve Peters [EMAIL PROTECTED] wrote: What's happening above is that TEST cannot handle seeing tests come in out of order, while harness can. I'm scanning Test::Harness::TAP a bit, but it seems to be unspecified whether this is OK or not. Should TEST care if the tests are reported out of order? I think it should. If the order of tests is really random, on can remove the numbering of the tests and only output ok\n or not ok\n.
Re: Test::Harness now tells you which TODOs passed unexpectedly
Andy Lester wrote in perl.qa : Please try out this dev release. I'd like to make it 2.58 tomorrow. Now integrated into bleadperl, all tests pass here. -- * What system had proved more effective? * Indirect suggestion implicating selfinterest. -- Ulysses
Re: First (developers) Release of Test::Shlomif::Harness
Andy Lester wrote in perl.qa : On Mon, Oct 10, 2005 at 02:52:49PM -0700, chromatic ([EMAIL PROTECTED]) wrote: I do NOT want to see that sort of thing as patches to Test::Harness. I have a few ideas myself on how to make T::H a little more clean and useful, but I'd have to do some refactorings myself on a private fork to see how well they look in practice. And I'm OK with that. I just want, and I suspect 99% of any authors want, to have people work WITH me. Hey, Andy, I've got some ideas on X, are you interested? Is this something you're looking at exploring? That said, now that TAP is well documented (yay), there's nothing wrong with writing other harnesses. For example, an harness that would run tests in parallel would be interesting, but I don't think there would be much code to reuse from the current T::H. (waving hands) -- Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. -- RFC 1925
Re: my $key is sensitive;
Brent 'Dax' Royal-Gordon wrote in perl.perl6.language : I would like is sensitive to be defined to mean that any data stored in that variable, at any level of recursion, will be zeroed out as soon as it is garbage collected. Particular implementations can add extra features on top of that--such as stopping the VM from swapping it or even actively encrypting that area of memory--but without a minimum standard there's no point in supporting the feature at all. That really sounds like an unportable feature that should go in a module. On in many modules (Linux::VolatileVariables, etc etc)
Re: my $key is sensitive;
Brent 'Dax' Royal-Gordon wrote in perl.perl6.language : Basically, I'd like to be able to mark a variable as sensitive or secret. This implies that the language should overwrite the memory it uses before deallocating it, and that if possible it should tell the virtual memory system to avoid swapping it out. Moreover, it should probably do so recursively, and to any value that has ever been stored in the variable. (In essence, the *variable* marks all *values* it ever contains as sensitive.) This feature could make Perl 6 a better language for security work than any other I've seen. C and C++ could do this, but only with the programmer's assistance (by calling a wipe function or making sure a destructor is correctly called), and optimizers have been known to helpfully remove such code. Isn't the volatile modifier supposed to avoid this ? Oh, and remark that volatile is quite a high-level construct for a language like C. So, such a sensitive modifier could be added, but its precise meaning would be highly dependent on the underlying implementation. -- The universe (which others call the Library) is composed of an indefinite and perhaps infinite number of hexagonal galleries. -- Borges
no 6;
I just commited into bleadperl a patch that implements this : $ ./perl -e 'no 5' Perls since v5.0.0 too modern--this is v5.9.3, stopped at -e line 1. BEGIN failed--compilation aborted at -e line 1. That is, the exact opposite of the current use VERSION syntax. One of the uses I had in mind for it is to put no 6 at the top of modules or programs that are too tightly bound to Perl 5 that there wouldn't be beneficial to port them to Perl 6. B::* or Safe come to mind. Of course, that would mean that Perl 6 should also recognize and handle the no 6 idiom. That's why I'm cc:ing p6l. Comments ? The patch can be found at http://public.activestate.com/cgi-bin/perlbrowse?patch=25344
Re: Sun Fortress and Perl 6
Autrijus Tang wrote in perl.perl6.language : 4. Software Transaction Memory Like GHC Haskell, Fortress introduces the `atomic` operator that takes a block, and ensures that any code running inside the block, in a concurrent setting, must happen transactionally -- i.e. if some precondition is modified by another thread before this block runs completely, then it is rolled back and tried again. This slides covers some aspects of STM as used in GHC: http://homepages.inf.ed.ac.uk/wadler/linksetaps/slides/peyton-jones.ppt In Fortress, there is also an `atomic` trait for functions, that declares the entire function as atomic. Interesting; and this rolling-back approach avoids the deadlock issues raised by the use of semaphores (like in Java's synchronization approach). But, as the slides point out, you can't do I/O or syscalls from an atomic function; and in Haskell you can ensure that with the wise use of monads. Perl 6 has no monads, last time I checked... 6. Database-indexed module management An embedded database (such as SQLite) can be used to track different revisions of installed modules on the local machine, manage upgrades, check api compatibility, and keep related logs; see Chapter 4 for details. I have long wanted something like that for CPANPLUS, instead of the current, limited, nonversioned, unrevertable, partial information provided by .packlist files. Plea : don't mess up with the job of the packagers and of the package manangement systems. You can write one, or several, but you can't assume they will be used, or that only one of them will be used at the same time on the same system. I think that if somethings needs to be standardised here is a complete, correct, useful metadata format (à la META.yml).
Re: Module and package version numbering
Michael G Schwern wrote in perl.qa : On Mon, Apr 18, 2005 at 05:03:42PM +0100, David Cantrell wrote: 1) Am I correct to seperate the package version (1.3004) from the A small correction -- 1.3004 would be the distribution version, (not mentioned as $...::VERSION in any package).
Re: should we change [^a-z] to -[a..z] instead of -[a-z]?
Aaron Sherman wrote in perl.perl6.language : A silly question: is there a canonical character set from which we extract these ranges? Are we hard-coding Unicode here, or is there some way for the user to specify the character set for ranges? Perl 5 forces [a-z] (or [i-j] for that matter) to be a range of lowercase alphabetic characters, even on EBCDIC platforms (where it's not).
[PATCH] support make DESTDIR=/... install
This fixes installing to a different DESTDIR.
Index: Makefile.PL
===
--- Makefile.PL (revision 1233)
+++ Makefile.PL (working copy)
@@ -105,10 +105,10 @@
pure_site_install ::
\$(NOECHO) \$(MOD_INSTALL) \\
- \$(INST6_LIB) $config-{privlib} \\
- \$(INST6_ARCHLIB) $config-{archlib} \\
- \$(INST6_BIN) $config-{installbin} \\
- \$(INST6_SCRIPT) $config-{installscript} \\
+ \$(INST6_LIB) \$(DESTDIR)$config-{privlib} \\
+ \$(INST6_ARCHLIB) \$(DESTDIR)$config-{archlib} \\
+ \$(INST6_BIN) \$(DESTDIR)$config-{installbin} \\
+ \$(INST6_SCRIPT) \$(DESTDIR)$config-{installscript} \\
\$(INST6_MAN1DIR) \$(DESTINSTALLMAN1DIR) \\
\$(INST6_MAN3DIR) \$(DESTINSTALLMAN3DIR)
.
End.
More Makefile.PL patches
This one fixes make test, by forcing the fix of test target of the
generated Makefile. I'd rather have Ingy reviewing it or something,
because AFAICT it's his territory -- dark makemaker places where black
magic hides behind obscure curtains. (make install still works and
still installs everything in its right place)
Index: inc/Module/Install/Pugs.pm
===
--- inc/Module/Install/Pugs.pm (revision 1236)
+++ inc/Module/Install/Pugs.pm (working copy)
@@ -22,8 +22,7 @@
$self-WriteAll(@_);
-$self-pugs_fix_makefile
- if $install_version eq '6';
+$self-pugs_fix_makefile;
}
sub set_makefile_macros {
This one is just a nit : it silences make test, that complains
about t/*.t not existing.
Index: Makefile.PL
===
--- Makefile.PL (revision 1236)
+++ Makefile.PL (working copy)
@@ -27,7 +27,7 @@
} glob(ext/*)
);
makemaker_args (
-test = { TESTS = join ' ', t/*.t, t/*/*.t, t/*/*/*.t },
+test = { TESTS = join ' ', t/*/*.t, t/*/*/*.t },
MAN1PODS = {},
);
clean_files (map fixpaths($_),
Re: BEGIN {}
Autrijus Tang wrote in perl.perl6.compiler :
Consider this program, example.p6:
use v6;
my $var = BEGIN { say I'm compiling, man; time() }
say Compiled at { time() - $var } seconds ago!;
Is this behaviour correct?
% pugscc --parrot example.p6
I'm compiling, man
% sleep 60
% parrot example.pmc
Compiled at 60 seconds ago!
It looks not correct to my perl 5 trained eyes.
BEGIN is designed to let things run as early as possible, mostly
for Perl programs to discover things about the environment they're
running in. That's a different environment than the environment they
were compiled in. For example :
my $use_debug_mode = BEGIN { %*ENV{DEBUGME} ?? 1 :: 0 };
On the other hand there are CHECK blocks too.
Re: BEGIN {}
Markus Laire wrote in perl.perl6.compiler :
my $use_debug_mode = BEGIN { %*ENV{DEBUGME} ?? 1 :: 0 };
According to S04 you'd use INIT block for that. INIT is run at run time,
ASAP. But BEGIN is run at compile time, ASAP.
Fair enough, makes sense. As long as BEGIN and CHECK blocks are run when
you evaluate code at run-time (which is not the case in perl 5 for CHECK
blocks currently)
My example code:
use v6;
my $compile_begin_time = BEGIN { time() }
my $compile_end_time = CHECK { time() }
my $run_begin_time = INIT { time() }
my %compile_time_environment = BEGIN { %*ENV }
my %run_time_environment = INIT { %*ENV }
(this list from http://dev.perl.org/perl6/synopsis/S04.html )
BEGIN {...}* at compile time, ASAP
CHECK {...}* at compile time, ALAP
INIT {...}* at run time, ASAP
END {...} at run time, ALAP
FIRST {...}* at first block entry time
ENTER {...}* at every block entry time
LEAVE {...} at every block exit time
KEEP {...} at every successful block exit
UNDO {...} at every unsuccessful block exit
NEXT {...} at loop continuation time
LAST {...} at loop termination time
PRE {...} assert precondition at every block entry
POST {...} assert postcondition at every block exit
CATCH {...} catch exceptions
CONTROL {...} catch control exceptions
Re: #perl6, pugscode.org, and more
Aaron Sherman wrote in perl.perl6.compiler : On Wed, 2005-02-23 at 07:43 -0500, Aaron Sherman wrote: has anyone considered petitioning the major Linux distribution vendors to include it in their upcoming releases? [...] I don't know anything about Haskell, and it would be presumptuous of me. Face... so... red... Ignore me, this is already under way (and being quite well managed, it seems at http://www.haskell.org/fedora/ for the Fedora platform). They're pushing to get included in Fedora's extras. I've included it in Mandrakelinux's contribs. It's a huge RPM, but we may try to find place for it on the editions that come with the largest number of CDs :)
Environment variables
I had this silly idea, to try to add %ENV to pugs. That would be an interesting exercise. So I can write CGI scripts. Maybe. But I don't know what's the Right way to do it in Perl 6. Any hints ? -- #!/usr/bin/pugs say Just another Pugs hacker;
Re: Environment variables
Autrijus Tang wrote:
jn Tue, Feb 22, 2005 at 10:54:26AM -, Rafael Garcia-Suarez wrote:
I had this silly idea, to try to add %ENV to pugs. That would be an
interesting exercise. So I can write CGI scripts. Maybe. But I don't
know what's the Right way to do it in Perl 6. Any hints ?
In Perl6 I think you do it by populating the %*ENV hash, when the
script is first run. To add it, hack Main.hs line 102 to add a new
SGlobal symbol of a VHash. If you already have a list of pairs x,
it is as simple as:
VHash $ MkHash (listToFM x)
Here's a patch to add this. It's heavily cargo-culted, I need to read
some docs about haskell some day. As I wasn't able to get FiniteMaps to
work I implemented my own kludgy function to flatten pairs for the hash.
Also I suspect that the type of the internal thingy in %*ENV might not
be right, so you may want to turn it in a VHash instead (I haven't found
any difference).
Comes with tests. Note that this %*ENV is not magical. It should be
sufficient to write simple http-GET CGI scripts, though.
Index: t/op/magic.t
===
--- t/op/magic.t(revision 0)
+++ t/op/magic.t(revision 0)
@@ -0,0 +1,13 @@
+# Tests for magic variables
+
+use v6;
+
+say 1..2;
+
+# Tests for %*ENV
+
+# it must not be empty at startup
+if (0 + %*ENV.keys 0) { say ok 1; } else { say not ok 1; }
+
+# PATH is usually defined. But this test is not portable
+if %*ENV{PATH} ne { say ok 2; } else { say not ok 2; }
Index: MANIFEST
===
--- MANIFEST(revision 170)
+++ MANIFEST(working copy)
@@ -71,6 +71,7 @@
t/op/hash.t
t/op/inc.t
t/op/join.t
+t/op/magic.t
t/op/pair.t
t/op/pop.t
t/op/push.t
Index: src/Main.hs
===
--- src/Main.hs (revision 170)
+++ src/Main.hs (working copy)
@@ -22,6 +22,7 @@
import Parser
import Help
import Pretty
+import Posix
main :: IO ()
main = do
@@ -92,14 +93,20 @@
runFile file = do
withArgs [file] main
+flattenPairs :: [(x,x)] - [x]
+flattenPairs [] = []
+flattenPairs ((a,b):q) = [a,b] ++ flattenPairs q
+
runProgramWith :: (Env - Env) - (Val - IO ()) - VStr - [VStr] - String
- IO ()
runProgramWith fenv f name args prog = do
+environ - getEnvironment
env - emptyEnv
[ Symbol SGlobal @*ARGS (Val $ VList $ map VStr args)
, Symbol SGlobal @*INC (Val $ VList [])
, Symbol SGlobal $*PROGNAME (Val $ VStr name)
--, Symbol SGlobal $*STDIN (Val $ VStr str)
, Symbol SGlobal $*END (Val VUndef)
+, Symbol SGlobal %*ENV (Val $ VList $ map VStr $ flattenPairs
environ)
]
--str - return -- getContents
let env' = runRule (fenv env) id ruleProgram prog
Index: src/Posix.hs
===
--- src/Posix.hs(revision 170)
+++ src/Posix.hs(working copy)
@@ -21,9 +21,11 @@
rename,
removeLink,
sleep,
+getEnvironment,
) where
#ifdef PUGS_HAVE_POSIX
+import System.Posix.Env
import System.Posix.Files
import System.Posix.Process
import System.Posix.Unistd
@@ -47,4 +49,7 @@
sleep :: Int - IO ()
sleep _ = fail 'sleep' not implemented on this platform.
+getEnvironment :: IO [(String, String)]
+getEnvironment = []
+
#endif
Re: New version of Test::LongString
David Wheeler wrote in perl.qa : Test::LongString is one of those modules that you should be using if you're doing testing against large data elements, especially web pages. There are now examples in the docs that I hope make you say Wow, this is cool, thanks RGS! I use Text::Differences for this, as it will show which lines are different, rather than just the first 50 characters. Much easier for me to diagnose problems. It's probably better adapted to text pages. I wrote Test::LongString to debug and test a serialization/deserialization protocol that was producing long binary strings. For this purpose, it was most helpful :)
Re: Synopsis 9 draft 1
On Fri, 3 Sep 2004 11:41:05 +0100, Tim Bunce [EMAIL PROTECTED] wrote: Is there some syntax to express if the struct is packed or needs alignment? (Perhaps that would be needed per element.) Why am I suddenly thinking about unions ?
Re: Invalid value for shared scalar
Andrew Pimlott wrote:
I got this error, which I traced down to accidentally calling is() with
a hashref as the third argument, where the name should have been:
use Test::More 'no_plan';
is(1,1,{});
Autrijus has fixed this bug in bleadperl, see the patch at
http://public.activestate.com/cgi-bin/perlbrowse?patch=23167
It should be integrated in the next Test::Builder CPAN release.
I found some mailing list discussions about this problem without much
conclusion. This leads me to believe that perl threads are not mature
enough to foist on people without their express consent. Of course,
this case can be fixed, but if such innocent code can be broken by
threads, I'm sure there are more bugs lurking. And they are very
frustrating to debug for people without experience in perl threads.
In this case that's a bug in Test::Builder, not in perl.
So I suggest that Test::Builder not enable threads itself, unless
explicitly requested. Even if your code uses threads, it seems unlikely
that you'd want to run your tests in parallel anyway. You could perhaps
enable thread-safe tests with
use Test::Builder 'thread_safe';
Re: Invalid value for shared scalar
Andrew Pimlott wrote: Can you tell me where this limitation in perl threads is documented? Is there any hope that it will be removed in the future? It's not a limitation, if you share a hash it looks normal to me that you should share its elements too. (or you end up with weird quantum hashes that don't look the same from different threads...) That said, threads are underdocumented and the error message could be made much clearer.
Re: Updates to modules-related pod
Kirrily Skud Robert wrote: Here's an initial patch to perlnewmod, the main points of which are: * recommend module-starter over h2xs * modernise recommended h2xs invocation * modernise list of recommended modules to learn from * refer to Test::Simple and Test::More instead of Test * modernise PAUSE-related instructions Thanks, applied as change #23220 to bleadperl. I know module-starter (part of the Module::Starter package) isn't part of the core, but I figure that there are two answers to that: 1) propose M::S for inclusion in the core, or 2) since this doc is aimed at CPAN authors anyway, let's assume that it won't kill them to get the module from there. 2) is surely better :) BTW, isn't the habit to post to c.l.p.announce a bit deprecated now ?
Re: Updates to modules-related pod
[EMAIL PROTECTED] wrote: 04pause.html has some useful and important information people should probably read before requesting an account. It's also linked from http://pause.perl.org/ (about PAUSE); this latest URL is probably easier to remember.
Re: Test for functions with operator names
Andy Lester wrote:
Here's a test file that makes sure that even with sub q{}, that q() is
an operator, but q() and main::q() are function calls. I suggest that
it be called t/comp/operator-subs.t.
Thanks, applied as #23215.
#./perl -T
^^
the lack of ! here gave me a small headache during the integration.
Re: Patch for t/op/sleep.t
Andy Lester wrote: t/op/sleep.t doesn't actually check to see how long it's slept for. The test takes sleep()'s word for it. I also modernized it to use Test::More and its convenience functions. Thanks, applied as change 23206.
Re: Test-Regex-0.01.tar.gz
Andy Lester wrote: Lets you check the dollar vars of your results matches_are( dog food, qr/dog(.+)/, 1=food, Matched OK ); or matches_are( first middle end, qr/middle|center/, = middle, ` = first ); Eventually we'll handle the punc vars, but for now this will do. Thoughts? What kind of useful diagnostics could this module emit in case of failure? IMO they have to be precisely detailed.
Re: undo()?
Michele Dondi wrote: I must say I've still not read all apocalypses, and OTOH I suspect that this could be done more or less easily with a custom function (provided that variables will have a method to keep track of their history, or, more reasonably, will be *allowed* to have it), but I wonder if Perl6 may include a builtin undo() function to recover values prior, say, to the last assignement (or push() or, etc. etc.[*]) Difficulties: define history of a function w.r.t. threads; closures; and system side-effects (writing to files, locking them etc.) In other words, if you want a transaction/rollback mechanism, use a suitable transaction library that fits your needs, not a half-baked kludge built into the base language.
Re: simple grammar example
Luke Palmer wrote:
Also, if this is going to be an explanation rather than just a picture,
I suggest you go with Perl's usual versatile power, and store the
operators in a declarative data source.
grammar RPN {
my @operator = + - * / ;
rule input { line* }
rule line { exp? \n }
rule exp :w{ NUM | @operator }
rule NUM { \d+ }
This becomes too weak.
rule exp :w{ NUM | exp exp @binary_operator }
is stronger.
But it involves left-recursion, so it's typically better adapted to
yacc-like parser generators. Probably not to P6 rules...
Re: simple grammar example
Sean O'Rourke wrote: * To really show where P6 rocks, you need to show dynamic features. A simple example might be using a language with keywords kept in variables, allowing you change between e.g. for, while, if, pour, tandis-que, si, etc. Small correction : pour, tant_que, si :)
Re: simple grammar example
Luke Palmer wrote:
That left recursion won't do. I can't remember my transformation rules
well enough to know how to put that in a form suitable for a recursive
descent parser. To be honest, I've never seen an RPN calculator modeled
with a grammar.
Well, the main advantage of an RPM syntax is to avoid the need for a
grammar. The parsing stack and the execution stack are the same.
To be sure, a prefix calculator should be the easiest:
rule exp :w { @operator exp exp | NUM }
Indeed.
With infix operators you need precedences.
Re: more B::Concise stuff (PATCH - updated)
Jim Cromie wrote: Jim Cromie wrote: folks, attached patch has following adjustments to B::Concise and its tests. heres 2nd rev of that patch, now against 22802 Thanks, applied as change 22820. Time to play with it...
Re: $foo.s/foo/bar/
Aaron Sherman wrote:
Is it a special type of calling convention, e.g.:
sub s (Regex $pat, Str $replace, bool ?$i) is doublequotelike returns(Str) {
Ooh, doublequotelike sounds so much 1984.
(Moreover it doesn't describe accurately the reality, which allows to
use different delimiters for the pattern and the replacement.)
Re: tests for change #22539
Jim Cromie wrote: Heres a 'working' version of my earlier proposal, patched against [EMAIL PROTECTED] I hope you find it useful for regression testing of the optimizer, and the opcode generation phases. Thanks, applied to bleadperl as change #22664.
Re: Safety and security
Larry Wall wrote in perl.perl6.internals :
Do bear in mind that Perl can execute bits of code as it's compiling,
so if a bit of code is untrustworthy, you shouldn't be compiling it
in the first place, unless you've prescanned it to reject Cuse,
CBEGIN, and other macro definitions, or (more usefully) have hooks
in the compiler to catch and validate those bits of code before
running them. Doesn't do you much good to disallow
eval 'system rm -rf /';
at run time if you don't also catch
BEGIN { system rm -rf /; }
at compile time...
That's mostly what Perl 5's Safe is doing. Hence my previous comment.
The major flaw with this approach is that it's probably not going to
prevent
eval 'while(1){}'
or
eval '$x = take this! x 1_000_000'
or my personal favourite, the always funny
eval 'CORE::dump()'
unless you set up a very restrictive set of allowed ops.
(in each case, you abuse system resources: CPU, memory or ability to
send a signal. I don't know how to put restrictions on all of these
in the general case...)
Re: Safety and security
Dan Sugalski wrote in perl.perl6.internals : At 2:50 PM +0100 3/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: At any rate, perl 5's Safe module is a good example of the Wrong Way to do security, and as such we're going to take it as a cautionary tale rather than a template. Ok. What about Ponie? What about it? Safe's one of those modules that's guaranteed to not work under Ponie, as are a number of the B modules. That's OK. Why? OK, I understand that Ponie will compile Perl 5 source to parrot ops, and that Safe's interface uses perl ops. However it's a pure compile-time module -- it hooks into the optree construction routines -- so it may be possible to have an equivalent of it under Ponie. (not saying that this would be necessarily a good idea, though) -- rgs
Re: Funky «vector» operator
Andy Wardley wrote in perl.perl6.language : I'm so happy! I just found out, totally by accident, that I can type the « and » characters by pressing AltGr + Z and AltGr + X, respectively. Of course this information is almost completely unusable without knowing your OS, your locale, and your keyboard flavour. But thanks anyway, and I'll share mine : with vim, and with the 'digraph' option set, just type Del to get « Del to get » This is probably common knowledge as well.
Re: Method caches
Dan Sugalski wrote in perl.perl6.internals : This seems... too simple, so I'm sure I'm missing something besides the potential massive memory usage. So, by all means, have at it. You'll need to worry about actions that invalidate all or part of the method cache : introduction of a new class, of a new method, modification of the inheritance hierarchy, destruction of a whole class. Not mentioning autoloaded methods.
Re: Configure.pl and the history of the world
Larry Wall wrote in perl.perl6.internals : Not using metaconfig (or something like it) would be the biggest mistake. It's actually next to impossible to maintain something like a Configure script directly. Actually as parrot already uses IIUC variables set up by Configure, I think one could drop the or something like it. The biggest drawback of Configure is that it's UNIX-centric. But it's yet impressively portable and backwards-compatible (ask any Richard Clamp). [Some time ago Raphael Manfredi, bored by the autocrap tools (as he names it) expressed the intent to work on metaconfig again, but then he disappeared again.]
Re: parrotbug working...
Jerome Quelin wrote in perl.perl6.internals : But what should those addresses do when receiving a message? - parrotbug: should open a RT ticket? - status-ok: ? - status-nok: should open a RT ticket? Excuse me from stepping in, but I don't see why three adresses are necessary. From my (limited) knowledge of RT, I thing that the parrot bug address could create a ticket in the parrot queue, or add the mail body to the appropriate ticket if the subject contains [perl #X] -- then, it could close the ticket automatically if the subject matches an OK report.
Re: Compile-time undefined sub detection
Larry Wall wrote in perl.perl6.language : In theory, yes, if you ask it to check in a CHECK block, and if you're willing for the check to assume that no eval or INIT block is going to supply the missing sub before it's actually called, and that no run-time code is going to alias the sub into one of your namespaces where it'll be visible to call, and that no AUTOLOAD in scope will be willing to emulate it. (But then, all that's true of Perl 5 right now as well...) While we're at it. Is there some precise definition of the CHECK/INIT blocks for perl 6 right now ? In perl 5 those blocks are executed at the transition between the compilation and the execution phase *of the main program*. This is convenient for some purposes (the O and B::* modules) and inconvient for others (Attribute::Handlers, etc. etc.). It's not feasible to modify this for Backwards Compatibility Reasons; how will Perl 6 handle this ? is there going to be a CHECK-by-compilation-unit kind of block ?
Re: Compile-time undefined sub detection
Larry Wall wrote in perl.perl6.language :
: In perl 5 those blocks are executed at the
: transition between the compilation and the execution phase *of the main
: program*. This is convenient for some purposes (the O and B::* modules)
: and inconvient for others (Attribute::Handlers, etc. etc.).
Hmm, well, I think it's a problem with Attribute::Handlers only because
that interface binds too late by default. Perl 6 traits will run at
BEGIN time by default. (Though you can define actions at trait time
that don't run till a later phase.) Can you elaborate on the etc. etc.?
Of course :) the main problem is not that CHECK blocks are executed
late (just at the end of the compilation phase); it's that they're
executed too early, notably in some persistent environment, notably
mod_perl (or mod_parrot in the future.) When you have a virtual machine,
you'll end up including modules at run time, because the main
compilation phase becomes less important. Thus CHECK blocks become
worthless, code-reusability-wise.
The link phase is still controlled by the main compilation pulling
in other modules, so CHECK still has the same semantics for the main
program, at least. And for consistency (especially with Perl 5),
a CHECK block from a separately compiled module probably should wait
till end of link time to run. Particularly since we have modules
that specifically create a CHECK knowing it runs at the end of the
main compilation.
But, as I was saying, modules have no control on what the end of the
compilation is; notably, they've no control on whether it's still
finished.
my @x will unitcheck {...}# at UNITCHECK time
your next mission is now to put something like this in Perl 5...
Re: Compile-time undefined sub detection
Larry Wall wrote in perl.perl6.language : Possibly a CHECK block that is compiled after end of main compilation should translate itself to a UNITCHECK. But maybe it should be an error. But it's also possible that CHECK should mean unit check, and there should be an explicit MAINCHECK for delegating checks to the main compilation. In that case, only in the main compilation would CHECK and MAINCHECK mean the same thing. (And since MAINCHECK is explicitly requesting a check at the end of main, a late MAINCHECK should probably be considered an error. (But by that argument, a late CHECK should probably fail under the current naming scheme.)) Anybody got opinions on the naming of these beasts? Certainly *not* renaming CHECK is more compatible with Perl 5. And I kinda got fond of UNITCHECK in the last hour or so. :-) I think I like CHECK and MAINCHECK. (and MAINCHECK being an error after the main compilation phase.) Lots of people who use CHECK (for some value of lots -- let's say, Damian and a few others) actually mean UNITCHECK. MAINCHECK is mainly useful for the O compiler backend, which is part of the perl core anyway, thus without any backward-compatility constraint. (I'd like to have opinions about PAR as well.) So I think changing the meaning of CHECK in Perl 5 is feasible. (and I know it would be welcomed by the mod_perl crowd.)
Re: Compile-time undefined sub detection
Damian Conway wrote in perl.perl6.language : I'd favour UNITCHECK and CHECK, mainly for the greater compatibility with Perl 5 and with software engineering jargon. As far as Perl 5 is concerned, it appears that most people who write CHECK mean UNITCHECK. Including you :) And because MAINCHECK is *ugly*. ;-) I can't disagree. So ugly that, if we go the other way and do change CHECK's behaviour, then the new postlinkage phase should be something else: like POSTLINK or PREINIT or INTEGRATE. But INTEGRATE is even more ugly.
Re: Change 22021: Upgrade to Test::Harness 2.40.
Jim Cromie wrote: Well, it seems Ive been abusing diag() for some time now :-O Is there a 'right' way to do this ? perhaps just using ok() ? ok() goes to stdout by default, diag() to stderr or maybe a new function, ex: note() is better: note..ok# YOUR INFORMATIONAL MESSAGE HERE if that goes to stdout, that won't appear in the default harness output Since Ive been using diag() to denote groups of tests, which separates chunks of foo . ok, But this appears to be precisely what RGS doesnt like. Or use separate .t files ? Hence ive UPCASEd the note to give it some of the visual distinction that I got from diag(), hopefully w/o the annoyance. Is this worthwhile ? If so, Ill work up a patch
Re: Perl Abstract/Concrete Syntax Tree
Andrew Potozniak wrote in perl.qa : I was wondering if there was anything built in Perl (a Module) that will take in a Perl file and parse that into an abstract or concrete syntax tree. I searched around cpan for a bit and couldn't find what I was looking for. If anyone is wondering what I'm talking about there is a nice Java package that Eclipse uses to create a tree for Java compilation that I can point you toward. Thanks for your time. Hm -- as the task of parsing perl involves some complex interplay between compile-time and run-time -- think about the function prototypes, for example -- perl can't be described by a non-ambiguous grammar, and can't be parsed accurately by tools that don't include a full-fledged perl interpreter already. However, during parsing, perl builds internally an abstract syntax tree for its own usage ; the syntax tree is then walked during execution. It's possible to stop the perl interpreter after the compilation of the main program and to have it print the current contents of the parse tree. This is achieved by the O and B::* modules, that come with perl. You may want something not too far from this : $ perl -MO=Concise -e 'print $a + $b' 8 @ leave[1 ref] vKP/REFC -(end) 1 0 enter -2 2 ; nextstate(main 1 -e:1) v -3 7 @ print vK -8 30 pushmark s -4 62 add[t1] sK/2 -7 - 1 ex-rv2sv sK/1 -5 4 $ gvsv(*a) s -5 - 1 ex-rv2sv sK/1 -6 5 $ gvsv(*b) s -6 -e syntax OK See the docs for O, B and B::Concise for more information.
Re: Vocabulary
Larry Wall wrote in perl.perl6.language : On Wed, Dec 17, 2003 at 12:11:59AM +, Piers Cawley wrote: : When you say CHECK time, do you mean there'll be a CHECK phase for : code that gets required at run time? Dunno about that. When I say CHECK time I'm primarily referring to the end of the main compilation. Perl 5 appears to ignore CHECK blocks declared at run time, so in the absence of other considerations I suspect Perl 6 might do the same. This has proven to be inconvenient except for a few specialized usages, such as the B::/O compiler framework. There's a need (more or less) for special blocks that can be run at the end of the compilation phase of any arbitrary compilation unit.
Re: T::H 2.38
Andy Lester wrote in perl.qa :
prove begins with #!/usr/bin/perl and prove-switches.t
runs it with
my @actual = qx/$prove -Ifirst -D -I second -Ithird -Tvdb/;
A $^X should be inserted here.
(in bleadperl, the shebang line of prove is fixed when installed.)
What should be in prove's shebang?
The $Config{startperl} configure variable of the perl being installed.
Re: T::H 2.38
H.Merijn Brand wrote: t/prove-switchesPerl lib version (v5.6.1) doesn't match executable version (v5.8.0) at /pro/lib/perl5/5.6.1/PA-RISC2.0/Config.pm line 21. prove begins with #!/usr/bin/perl and prove-switches.t runs it with my @actual = qx/$prove -Ifirst -D -I second -Ithird -Tvdb/; A $^X should be inserted here. (in bleadperl, the shebang line of prove is fixed when installed.)
Re: tesing exceptions of Error.pm
Andy Lester wrote: How am I going to test this ? Take a look at Test::Warn for warnings, and Test::Exception for errors. I think qa.perl.org needs a listing of Test::* modules so that people know what's available. http://search.cpan.org/search?query=Test-mode=dist lists many of them, but maybe a more comprehensive list would categorize them in 'test modules that use the Test::Builder framework', 'test report utils' (such as Test::Harness), 'mod_perl related tests', etc.
Re: thinking about variable context for like()
Potozniak, Andrew wrote: Is anyone going to develop this, or is all of this just wishfull/theorhetical thinking? If someone will develop this are we going to add it to Test::More or create a module wrapped around Test::More with the added functionality? What is this feature you're referring to exactly ? Doesn't http://search.cpan.org/~rgarcia/Test-LongString-0.03/lib/Test/LongString.pm (uploaded yesterday) do what you want ?
Re: thinking about variable context for like()
Potozniak, Andrew wrote: I would suggest something along the lines of: like_html(actual_value, expected_regex, max_chars_to_output, string_description); In fact I think that making max_chars_to_output a global configuration variable is a better option, because repeating it (if you have lots of tests) will become quickly fastidious.
Re: thinking about variable context for like()
Chromatic wrote in perl.qa : On Mon, 2003-11-17 at 06:54, Potozniak, Andrew wrote: What's stopping you from creating this global var and passing it in to the function whenever it is called? Good taste. If it's going to be more convenient than Test::More's like(), go all the way and make it more convenient. Thanks, but actually that's due to my habit of adding tests to files that already contain hundreds of tests written by a dozen of people. Adding a test should be made the most straightforward possible and an interface shouldn't puzzle people. Moreover, it's convenient, when you debug a module, to have a more useful drop-in replacement for whatever test subroutine you have. That's how Test::LongString::is_string works : you can get a test file, include use Test::LongString at the top, and replace the offending is() by is_string() to have more readable diagnostics. You can always tweak the defaults later, but it's more convenient to do this by bringing the least possible modification to the test code itself. (That's why I can imagine accepting the default length as an argument to Test::LongString::import().)
Re: thinking about variable context for like()
FWIW, I uploaded Test::LongString 0.03 to CPAN. It implements like_string() and unlike_string(), and also : (That's why I can imagine accepting the default length as an argument to Test::LongString::import().)
Re: thinking about variable context for like()
Mark Stosberg wrote in perl.qa : I'm frequently using 'like' to test $agent-content against a regular expression. When I have a lot of these in a new test script and they are all failing, I get a boatload of HTML source floating by, which makes it tedious at times to find out what actually went wrong. I would like a way to tune the amount context that like presents upon failure. For example, the first 1000 characters of the HTML source would do most of the time. I'm not sure what the best way to do this might be. For now, I'll stop at merely suggesting something like this might be useful. :) Write your own test module on top of Test::Builder / Test::More. I faced a similar problem with is() for very long strings and/or strings that may contain non printable characters : http://search.cpan.org/~RGARCIA/Test-LongString-0.02/lib/Test/LongString.pm Now, it seems like your proposed long-string friendly like() is something that could go in Test::LongString. Patches welcome, of course, but I may look at implementing this myself. Other suggestions ?
Re: Hoplites: Watch for each
Elizabeth Mattijsen wrote: Just wondering, is keys() optimized for void context? Perlfunc only states: As a side effect, calling keys() resets the HASHâ¤_s internal iterator... Yes, it is. If keys() _is_ optimized for void context, a change in the perlfunc.pod seems to be in order. Thanks, applied as #21644 :) --8-- As a side effect, calling keys() resets the HASH's internal iterator, -see L/each. +see L/each. (In particular, calling keys() in void context resets +the iterator with no other overhead.) --8--
Re: Taint mode testing and project Phalanx
Andrew Savige wrote in perl-qa :
Given the differences in behaviour with taint mode, it seems to me
that for a taint mode test (i.e. one with -wT in its first line)
Test::Harness should run the test twice -- once with taint mode and
once without. Though I suppose there might be a case where you want
to run the test in taint mode only, so maybe Test::Harness needs
some options to control this.
Following this idea, I just added to bleadperl (change 21515)
a make test.taintwarn target that runs the test suite with the
-t (taint warnings) command-line flags.
It spits out a lot of Insecure dependency warnings, and several
tests fail. Notably, tests that install $SIG{__WARN__} handlers
are unhappy to catch taint warnings in it. However some failures
may require more careful investigation.
Re: Phalanx / CPANTS / Kwalitee
Thomas Klausner wrote in perl.qa : Well, here's a list of lowercase dist on CPAN (238 dists). Quite a lot of those are in fact real distributions (eg. perl, parrot). In fact I think that perl itself shouldn't be part of CPANTS I've no clue on how to figure out if something is a pragmatic module (any hints appreciated..) You could check for the interface type field in the module list : 'p' means 'pragmatic'. You could also check if the distribution name matches a .pm file in the tarball. Oh, and the ex:: namespace is officially for experimental pragmas.
Re: Perl Core Tests
Chromatic wrote in perl.qa : Stuff in t/op mostly can't use Test or Test::More because those modules rely on the features being tested. Most everything else can use Test::More. Barring any Unicode-related fiascos (of which I am proudly and blissfully unaware), they probably haven't been converted yet. t/test.pl is intended to be a lightweight replacement for Test::* for op/ tests. My goal was to improve coverage so every piece had at least nominal tests that could be improved, not to improve every existing test. Other people have had different goals. (It feels pretty good to port the tests to a more maintainable framework.) One improvement is to add names to tests. It makes them damn easier to track down when they fail.
Re: Phalanx / CPANTS / Kwalitee
Thomas Klausner wrote: there are currently 4 dists on CPAN that only include a configure script (makepp-1.19, glist-0.9.17a10, swig1.1p5, shufflestat-0.0.3) 179 do not include any of Makefile.PL, Build.PL or configure. Quite a lot come with two or three of those files. Could we infer that a distribution that comes with several Makefile.PLs may have an overcomplicated build process, maybe indicating a low kwalitee ? See for example : http://search.cpan.org/~msergeant/XML-Parser-2.34/MANIFEST
Re: Phalanx / CPANTS / Kwalitee
Nick Ing-Simmons [EMAIL PROTECTED] wrote: Could we infer that a distribution that comes with several Makefile.PLs may have an overcomplicated build process, maybe indicating a low kwalitee ? Should I infer that to get Tk's kwalitee up it should build as a one monolithic .so ? I don't know, I'm asking. So it's necessary to have one separate Makefile.PL by .so built ?
Re: Phalanx / CPANTS / Kwalitee
Thomas Klausner wrote in perl.qa : Hints that were in Leon's last release, but which I didn't port up to now: * POD errors * POD/Code ratio (what would be a good measurement?) use Pod::Coverage ? * testers results * number of releases
Test modules in 5.6.2
Folks, I've added and integrated a bunch of Test::* modules from bleadperl to 5.6.2. I've also roughly modernized the scripts t/TEST and t/harness with the bleadperl version, so that all *.t files are found, etc. Now if you're aware of a difference between bleadperl and CPAN or something, or if you find that this isn't a good idea, comments welcome. (Next step is MakeMaker. I needed the Test modules for it...) Change 20849 on 2003/08/22 by [EMAIL PROTECTED] Integrate Test::More, Test::Builder and Test::Simple, from bleadperl. Pulling in dependencies, I had to integrate if.pm as well (it's used in some tests.) Change 20848 on 2003/08/22 by [EMAIL PROTECTED] Upgrade to Test 1.24 (from bleadperl) Change 20847 on 2003/08/22 by [EMAIL PROTECTED] Two tests were failing after the Test::Harness upgrade, because they use Test, that loads Test::Harness, that doesn't load FileHandle anymore. Change 20846 on 2003/08/22 by [EMAIL PROTECTED] Upgrade to Test::Harness 2.30, and get t/harness from bleadperl (more or less, due to the different set of directories to scan for tests) -- perl -sleprint -- -_='Just another Perl hacker,'
Re: Testing for valid path names in CPAN distributions
Andrew savige wrote in perl.qa : Running variants of: tar tzf perl-5.8.0.tar.gz | perl -lne'print if tr|-_./a-zA-Z0-9||c' suggests only [-_./a-zA-Z0-9] are valid characters in a path name. Then I noticed 'perldoc perlport' lists the portable filename characters as defined by ANSI C and various other restrictions. What is the length limit of each path name component? What is the length limit of file extensions? I heard YAML changed from .yaml to .yml, for instance, yet Perl itself has many files with long extensions -- runtime.porting, for example. Also, don't ever include files that differ only by case. In the perl source distribution, Porting/check83.pl checks that filenames are friendly to 8.3 filesystems. What you want is probably more complex : a test to see if a *set* of filenames is portable. It'd be nice to have a standard test for valid portable path names. Does such a test exist? I noticed Archive::Any has is_impolite() and is_naughty() but didn't see any checks for basic path name validity. BTW, is Archive::Any a dead camel?
Re: Return of the Perl QA Wiki, this time for good
Michael G Schwern wrote in perl.qa : http://www.pobox.com/~schwern/cgi-bin/perl-qa-wiki.cgi Do you want a link to this from qa.perl.org ?
Re: This Week's Summary
Piers Cawley wrote in perl.perl6.internals : I want a Ponie! I promise that, as development of Ponie (the port of Perl 5 to Parrot) accelerates you'll see a summary of Ponie activity in this summary as well. In fact I imagined I was more or less going to do this, based on imagining what will be the contents of the future ponie discussions : how the hell will I be able to interface that spaghetti Perl 5 mess with that clean Parrot API ? Will I really be forced to reimplement the whole subrecursive frobnizer for tied magic ?
Re: %_ - is it available for use?
david nicol wrote:
[EMAIL PROTECTED] perl -le '$_{a}=27; package notmain; print $_{a}'
27
Gosh!
Let's document it! Would it go in perlvar or perlsyn?
It's already documented, in perlvar/Technical Note on the Syntax of Variable Names
(at the end)
Re: Blurring the line between assertions and tests
Michael G Schwern wrote in perl.qa : The only part missing is the ability to shut the tests off once you've released it to production. You could perhaps use the assertion feature of perl = 5.9.0 (assertion.pm and -A switch -- yes I know it lacks docs.)
Re: HACKING (was [PATCH] Fix copyright notices )
Robert Spier wrote in perl.perl6.internals : A lot of projects have a HACKING file that explains ground rules for contributing to the project -- all in one place. (Or at least it references where things are.) I'd love to see a file like this in parrot. Perl 5 provides pod/perlhack.pod.
Re: TODO tests for outstanding bugs?
chromatic wrote in perl.qa : One idea is attaching a simple test case to every bug report that doesn't have test code that's nearly right for the core. It's a lot easier to touch up a test case than it is to write one, so we could do a lot of good by turning bug reports into executable tests without having to worry about where they'll eventually end up. Write tests before fixes :) This always help. For such standalone 1-bug test scripts, Test::More is (most of the time) ok. However there are places in the core where Test::More can't be used, simply because they're tests for core features used by Test::More.
Re: This week's summary
Alan Burlison wrote in perl.perl6.internals : Piers Cawley wrote: Small Perl task for the interested Want to get involved in the Parrot development process? Don't know much about Virtual Machine design and implementation? Do know Perl? Dan has a small but interesting task for you. At present, Parrot gets built without any compiler level optimizations turned on because files like tsq.c can't have any optimizations turned on (tsq.c is the thread safe queue module, which is annoyingly execution-order-dependent because it has to operate safely as interrupt code potentially interrupting itself). Dan would like a version of Configure.pl which can build a makefile (or whatever build tool we end up using) with per-C-file compiler flags, and it needs to be possible to override those flags, per file, by the platform configuration module. Hmm, I'm only a lurker, but that looks *very* suspect to me. Some compilers may choose to reorder even without optimization turned on. I'd say that it is a bug in Parrot if it requires optimization to be off for this code - how many different compilers have you tried? That doesn't make this per-C-file-cc-option-tweaking necessarily unuseful. Perl 5 uses something similar, because the lexer is sometimes miscompiled when some compilers with a high optimization level. Example : see the hints files and lookup XXX_cflags or toke_cflags in hints/README.hints.
Re: Perl6 Daydreams (on topic but frivolous)
Jonathan Scott Duff wrote in perl.perl6.language : My only dream is that by this time next year we have a fully- functional-people-can-use-it-in-production Perl6. It doesn't even have to be 100% complete; I think just 85% would be enough if it were the right 85%. 20% would be enough if it's what it takes to get 80% of the job done ;-)
Re: [ANNOUNCE] Test::Warn::None 0.02
Fergal Daly wrote: Also how about calling it Test::Warn::Auto? I'm not particularly happy with None, +1 for ::Auto. BTW, what about modules that define their own category of warnings (via warnings::register) ? It'd be useful to have a module to ease testing for warnings presence/absence on certain conditions. (Avoiding to span perl interpreters at each test would be a bonus.)
Re: [ANNOUNCE] Test::Warn::None 0.02
Michael G Schwern wrote in perl.qa : On Tue, Jun 24, 2003 at 01:36:52PM +0200, Rafael Garcia-Suarez wrote: BTW, what about modules that define their own category of warnings (via warnings::register) ? It'd be useful to have a module to ease testing for warnings presence/absence on certain conditions. There's Test::Warn, but I don't think it does anything special with registered warning classes. It doesn't support them for now, according to the docs. (Avoiding to span perl interpreters at each test would be a bonus.) I don't quite understsand what spanning perl interpreters means. qx// (like lib/warnings.t in the perl core) -- Is it any wonder the world's gone insane, with information come to be the only real medium of exchange ? -- Thomas Pynchon, Gravity's Rainbow
Re: [ANNOUNCE] Test::Warn::None 0.02
Michael G Schwern wrote in perl.qa : On Tue, Jun 24, 2003 at 02:04:25PM -0500, Andy Lester wrote: All this make sure no warnings fired is good thinking. But why not roll it into Test::Harness, and make it switch selectable? It's really T::H that we want keeping an eye on this, right? No, its definately a test feature. Much easier to set up (no MakeMaker muckery), finer granularity (can be done on a per test file basis rather than a whole suite) and can distinguish between warnings and diagnostic output (ie. warn() vs diag() vs print STDERR). Besides, Test::Harness can't portably trap STDERR. If you can figure out a way to do it that would solve lots of problems. If you want to do it to a whole test suite, PERL5OPT=-MTest::Warn::None comes to mind. Provided that all test scripts are written with a Test::Warn::None-compatible plan(). -- Don't use color combinations that cause problems for people with color blindness in its various forms. -- W3C, HTML 4.01 Specification, 6.5.1
Re: P6ML?
Andy Wardley wrote: If my understanding of the design of Perl 6 is correct, the lexer, parser and any other related components will be highly configurable and/or replaceable. The goal is to provide support for little languages by separating Perl the language from perl the interpreter. It will be possible to modify or replace Perl the grammar so that perl the program can parse other languages, including Python, Ruby and presumably, XML. I think that you're a bit mistaken : the goal is to have (a) parrot execute other languages (once compiled to parrot bytecode) and (b) perl's parser able to modify itself at runtime. The fact that Perl's grammar can evolve doesn't mean that the basic entities it operates on will also evolve, and, as a Python string can't be seamlessly mapped to a Perl string, one can't have perl behave as a Python interpreter only by modifying its parser. So instead of writing Perl programs to parse and manipulate XML, it should be possible to modify Perl itself so that it parses the XML directly into some internal form suitable for programmatical manipulation. And moreover XML by itself is not a programming language, so I don't see how it's possible to build a generic interpreter for it. How exactly this will manifest itself, I cannot tell. If you wave hands very fast, bushes might start burning ;-) Nor can I say if this is actually a sensible thing to do or not. But unless my understanding is warped, support for parsing XML and other markup languages could be moved down into the core of the parser internals for Perl 6. I think you're overriding too much the meaning of 'parser' here. Basically I think that perl6's internal parser, even after heavy reconfiguration, will remain an engine to parse context-free languages, with a few improvements. That's very different from a parser for markup languages. (Of course, with a mechanism comparable to perl 5's source filters, one can plug everything. So, as Leon was saying, you can begin to implement a Perl5::XML source filter module right now.)
Re: Using imcc as JIT optimizer
Nicholas Clark wrote in perl.perl6.internals : r-score = r-use_count + (r-lhs_use_count 2); r-score += 1 (loop_depth * 3); [...] I wonder how hard it would be to make a --fsummon-nasal-demons flag for gcc that added trap code for all classes of undefined behaviour, and caused code to abort (or something more colourfully undefined) if anything undefined gets executed. I realise that code would run very slowly, but it would be a very very useful debugging tool. What undefined behaviour are you referring to exactly ? the shift overrun ? AFAIK it's very predictable (given one int size). Cases of potential undefined behavior can usually be detected at compile-time. I imagine that shift overrun detection can be enabled via an ugly macro and a cpp symbol. (what's a nasal demon ? can't find the nasald(8) manpage)
Re: AUTOLOADED pre- and post- handler methods?
Dan Sugalski wrote in perl.perl6.internals :
In Perl terms, assume we have a method PRE that gets called before
any method in a class is called, and AUTOLOAD which is called if you
call a method on a class and that method doesn't exist. Does AUTOLOAD
have to get called to check for PRE if PRE doesn't exist in a class?
In Perl 5, AUTOLOAD is called for destructors :
$ perl -wle 'sub AUTOLOAD{print $AUTOLOAD};bless{}'
main::DESTROY
While I think this is annoying in most cases, I imagine this may be
useful. And adding an empty destructor to a class is not a huge effort.
The situation is similar for a PRE method. If it's not defined, there's
no error ; if it's not defined but if AUTOLOAD exists, AUTOLOADing is
tried. (I imagine that if AUTOLOAD gracefully refuses to create the PRE
method, no further attempt will be made.)
Re: A proposal on if and else
Brent Dax wrote in perl.perl6.language : Yes, I know this means that we have 'else if' instead of 'elsif', but it's only two more characters and it makes the grammar cleaner. The tokeniser could send two tokens else and if whenever it recognizes the keyword elsif -- so this isn't a problem.
Re: A proposal on if and else
Joseph F. Ryan wrote in perl.perl6.language : I think the point of having Cif as a sub rather than as a separate syntax is so the parser doesn't have to do anything special for special keywords. I think the goal was to simplify the compiler, but with the discussion of recent weeks, it certainly doesn't look like that happened. :) Simplify the compiler, yes; but (with my limited knowledge of Perl 6) I don't expect the tokenizer to be simple. And the hack I just proposed to the tokenizer is mostly stateless. -- If strain on the lexer were a design criterion, I blew it long ago. -- Larry Wall
Re: A proposal on if and else
Joseph F. Ryan wrote in perl.perl6.language : If the final design stays the way it is now, there really won't be a lexer. Instead, a perl6 grammar parses the data, and builds up a huge match-object as it, well, matches. This match object is then munged into the optree. Oh, yes, I remember now. Thanks. This means the grammar probably won't be anything resembling simple, since it has to act as both a lexer and a parser at the same time. However, that's not to say your hack couldn't work; in fact, it would be easy to implement during the match-object-munging phase. Indeed. However, it still treats Cif as special syntax, which is the real issue at hand.. I question whether treating Cif as a function rather than as built-in syntax will make the parser any simpler if special block rules keep getting added to simply make it work. I'm in favor of keeping a few special blocks if it makes things easier to implement/design in the long run. Makes sense. Note that I'm not advocating elsif, quite an horrible keyword, that I still mispell as elseif sometimes. But I like hacking on grammars ;-)
Re: L2R/R2L syntax (was Re: Everything is an object.)
Dan Sugalski [EMAIL PROTECTED] wrote: And keyboards, don't forget keyboards. These pesky primitive ones we have now would require a lot of shift-control-alt-meta-cokebottle key sequences... And vt100 consoles ! There are still sysadmins that struggle with a buggy perl script, having rebooted in single user mode, on a production box at 23:15 pm. But this has been already said...
Re: Disappearing code
John Siracusa [EMAIL PROTECTED] wrote: Well, er, don't we need to decide what the subroutine attribute is, so that the compiler will know to honor it and make the code disappear? It doesn't seem like a feature that can be added from userland after the fact (but maybe I'm wrong...) In Perl 5 that could be done from userland, as you say, by using an optree manipulator (optimizer.pm for example). This could even be lexically scoped. [Once the compiler hints are fixed.] I expect Perl 6 to ship with (Parrot::* ?) modules that allow to examine and to modify the compiled form of the programs. Something that probably Java 6 will not have...
Re: Variable Types Vs Value Types
Damian Conway [EMAIL PROTECTED] wrote: There are in fact *two* types associated with any Perl variable: 1. Its storage type (i.e. the type(s) of value it can hold) This is specified before the variable or after an Cof or Creturns. It defaults to Scalar. 2. Its implementation type (i.e. the class that tells it how to act) This is specified after an Cis. It defaults to the type indicated by the variable's sigil. How does it work regarding inheritance and polymorphism ? E.g. consider my @a is Set of Apple; my @b is Basket of Fruit; with Apple isa Fruit, and Basket is a Set. I assume I can use @a or @b where the expected type is: @a @b Set ok ok Set of Fruitok ok Set of Appleok no(?) Basket no ok Basket of Fruit no ok Basket of Apple no no(?) the errors being compile-time or run-time, depends on how much verification the compiler can perform with its input. Reminds me the SetApple C++ templates. And the whole mess that comes with it (when you've got a statically typed language.)
Re: L2R/R2L syntax (was Re: Everything is an object.)
frederic fabbro [EMAIL PROTECTED] wrote: Can one see it as a shell redirection/pipe? This may sound funny, but is the following ok? @b ~ @a ~ @c; # @c = @b = @a; (@b ~ @a) ~ @c; # same order i guess so one can also: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; is this if valid too? @b ~ @a ~ @c; # push @a, @b, @c; or: @b, @c ~ push @a; qw/hello world/ ~ print Just add ^~ and v~ and we've got our own Befunge flavor.
Re: L2R/R2L syntax (was Re: Everything is an object.)
Nicholas Clark wrote in perl.perl6.language : Actually I don't think you can define a grammar where two operators have the same precedence but different associativity. Be it a pure BNF grammar, or a classical yacc specification (using the %left and %right declarations). But that would mean only perl6 could pass perl6, which isn't much different from the perl5 situation, is it? I meant that if ~ and ~ are going to have the same precedence, you can't parse s ~ t ~ u It's not a well formed phrase of the language (even though this language can't described by a nonambiguous BNF grammar.) In fact, this is different from the Perl 5 situation you're alluding to.
Re: L2R/R2L syntax (was Re: Everything is an object.)
Dave Whipp wrote in perl.perl6.language : But with the different precedence. At last, I can assign from a list without using parentheses: @a = 1, 2, 3; # newbie error @a ~ 1, 2, 3; # would work or : @a ~ 1 ~ 2 ~ 3; or : 1, 2, 3 ~ @a; which would be also written as : 3 ~ 2 ~ 1 ~ @a; shoot me : 3 ~ 2 ~ @a ~ 1; (Aha, Damian's 1st proposal seems to imply that ~ has highest precedence than ~).
Re: Variable Types Vs Value Types
Dan Sugalski [EMAIL PROTECTED] wrote: Like I said, you can always use delegation to subclass an array, or limit yourself to an odd and restrictive subset of behaviour. (Basically just vtable method overriding) Delegation has drawbacks compared to inheritance : you can't use a object that delegates to class Foo where an instance of Foo is expected. Unless Foo and the class that delegates to Foo both inherit from a common (abstract) superclass (ArrayInterface ? Dictionary ?) (Duh, this is just starting to sound like Java.) How do you override vtable methods from within Perl 6 ?
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
Simon Cozens [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Larry Wall) writes: Which basically comes down to this: an id represents a location in memory for any objects that don't override the .id method. Aiee! No! Please don't let things override the address-in-memory method, as that makes foo.id == bar.id comparisons dubious at best and useless at worst. Java-like final methods in core classes ? (And even in Java, Object.hashCode(), which returns the object's memory address in its base implementation, is overridable.) And by the way, doesn't Perl 6 allow C\$foo == \$bar ? (I missed the beggining of the thread.)
Re: purge: opposite of grep
John Williams wrote in perl.perl6.language : While purge is cute, it certainly is not obvious what it does. Of course neither is grep unless you are an aging unix guru... How about something which is at least obvious to someone who knows what grep is, such as vgrep or grep:v? If you want good'ol Unix flavor, call it vrep. Compare the ed(1) / ex(1) / vi(1) commands (where 're' stands for regular expression, of course) : :g/re/p :v/re/p What would be an idiomatic Perl 6 implementation of such a vrep function ?
Re: UTF-8 and Unicode FAQ, demos
Matthew Zimmerman wrote in perl.perl6.language : So let me make my original question a little more general: are Perl 6 source files encoded in Latin-1, UTF-8, or will Perl 6 provide some sort of translation mechanism, like specifying the charset on the command line? I expect probably something similar to Perl 5's encoding pragma. (But hopefully lexically scoped.)
Re: Character Properties
Dan Sugalski wrote : And, FWIW, emacs is written in C. Granted a much macro-mutated version of C, but C nonetheless. Just like Perl 5 ;-)
