Re: Compiled programs to keep BEGIN blocks? (was Re: [RFC] Switchto make Test::Builder output even if $^C ( for B::C ))
Michael G Schwern [EMAIL PROTECTED] writes:
On Sun, Jan 13, 2002 at 10:04:58PM +0100, Mattia Barbon wrote:
$ bleadperl -MO=-qq,Deparse foo.plx
sub BEGIN {
print foo\n;
}
print bar\n;
If B::Deparse can save BEGIN blocks, B::C can.
I didn't mean that I can't write code to make B::C save BEGIN blocks
( it'd require 10 lines, probably ), I did mean that doing so would
not be a god idea: _I am
saving the state of the program after those blocks were ran_ and
they will be run _another time_ at runtime, and this is not correct:
( for example use lib 'a'; would put 'a' into @INC twice, once
( correctly ) at compile time, and another time ( incorrectly ) at
runtime ). In this
case this is not harmful, but you get the idea.
I don't understand. The compiled program should do exactly what the
original program did. Anything else, as difficult as it may be, is a
bug. Lots of programs and modules do important load-time checks and
logic inside BEGIN blocks.
Why would this:
BEGIN {
push @INC, 'foo';
}
put 'foo' into @INC twice if it were compiled? The compiled program
should not be storing the post-BEGIN value of @INC, it should store
the original value at startup.
Um... You're wrong. If you do need 'startup time' initialization then
you should do it in an INIT block. If I may quote from the
documentation:
Once a BEGIN has run, it is immediately unde
fined and any code it used is returned to Perl's memory
pool. This means you can't ever explicitly call a
BEGIN.
So, by the time that the compiler comes to generate its output, the
BEGIN block as vanished, never to be seen again, which is as it should
be.
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Compiled programs to keep BEGIN blocks? (was Re: [RFC] Switchto make Test::Builder output even if $^C ( for B::C ))
Michael G Schwern [EMAIL PROTECTED] writes:
On Mon, Jan 14, 2002 at 10:23:46AM +, Piers Cawley wrote:
Um... You're wrong. If you do need 'startup time' initialization then
you should do it in an INIT block. If I may quote from the
documentation:
Like it or not, people put lots of init code into BEGIN blocks, if
nothing else for backwards compatiblity with 5.005. perlcc has to
compile real world programs.
Deferring BEGIN blocks 'til runtime will break rather more realworld
program than it fixes I think.
Can't solve this with a do not rule.
Once a BEGIN has run, it is immediately unde?
fined and any code it used is returned to Perl's memory
pool. This means you can't ever explicitly call a
BEGIN.
So, by the time that the compiler comes to generate its output, the
BEGIN block as vanished, never to be seen again, which is as it should
be.
There's a special B::save_BEGINs function which O.pm uses to get
around this.
Like I said, if B::Deparse can do it, B::C can.
But it shouldn't. How do you distinguish between:
use Foo;
(needs to use 'Foo' before generating the compiled script, otherwise
what's the bloody point?)
and
BEGIN { ... }
Also, as the docs for B::Deparse points out:
we can't guarantee to produce BEGIN blocks or use declarations
in exactly the right place.
Which can become a big problem when you find that your compiled script
doesn't work and there's no easy way of debugging the program that it
thinks it's evaluating.
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Untested modules update: There's more than we thought
Michael G Schwern [EMAIL PROTECTED] writes:
On Mon, Dec 17, 2001 at 08:12:43AM +, Piers Cawley wrote:
What's wrong with
ok ( eval { $foo-isa('Foo') } );
or even:
ok (eval { ref($foo) $foo-isa('Foo') });
As Kurt already pointed out, you can do:
ok( UNIVERSAL::isa($foo, 'Foo') );
but if it fails you have no idea what $foo was.
No you can't. Not if you've overridden isa anywhere. (Which is
perfectly possible.)
Ooooh, hadn't thought about that. I've done it myself a few times (to
make a delegation look like inheritance). Now I have to go fix
Test::More to deal with it. Ya know, I was literally just about to
release 0.40 and I HAD to go read my email first.
Either way, your above ok() solutions still give you no failure
diagnostics, which is the whole point.
Well, yes. At least the point about overridden isa didn't get lost...
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Starting with a test 1
Dave Rolsky [EMAIL PROTECTED] writes:
For my Alzabo tests, I do some weird stuff involving forking off processes
during tests and running the same (basically same) set of tests multiple
times, each time with different modules loaded. The parent process
calculates how many tests will be involved in each run and how many runs
will occur to print the '1..?' stuff at the beginning.
As part of this, I need to be able to tell the forked process to start its
test count at a certain number (greater than 1).
There's no way to do this with Test::Simple currently. What I need is to
be able to set $Planned_Tests and $Num_Tests without print the 1..$x bit
again.
Either that or set a $Offset so that when it prints the test number it
prints $Num_Tests + $Offset.
If it's not a dumb question, why are you doing it that way? If you
were using PerlUnit, aka Test::Unit::TestCase, you could do something
like:
package ParentTest;
use base 'Test::Unit::TestCase';
sub setup {
...
}
sub test_foo {
...
}
Then simply inherit from it for each different set of tests.
package DerivedTest;
use base 'ParentTest';
use SomeModule;
Then your /t would have files like:
derived.t:
use Test::Unit::HarnessUnit;
Test::Unit::HarnessUnit-new-start('DerivedTest');
which could be programmatically generated.
Thinking about it, you could probably move the module loads into the
test scripts and have them just run the basic test, which would, in
turn, probably mean you could get away with just using Test::More/Simple
--
Piers Cawley
www.iterative-software.com
Re: A Kwalitee HOWTO
[EMAIL PROTECTED] writes: Hi Is there a step-by-step guide how to create a module with high kwalitee? Make sure you don't write a module that does anything really interesting... -- Piers Cawley www.iterative-software.com
Re: Test::Harness rewrite
Kirrily Robert [EMAIL PROTECTED] writes: In perl.qa, you wrote: Sounds like what we need is a smorgasboard of make test targets. Looks like a job for a callback. Give the users the opportunity to write a handler for each test result -- print, output to file, email, stick it in a database, whatever. Test::Unit's has the idea of Listeners that are responsible for interpreting the test data and reporting on it. Thus, when you're running the tests under make test you use a Test::Harness compatible TestRunner. It works quite well. -- Piers Cawley www.iterative-software.com
Re: on QA
Michael G Schwern [EMAIL PROTECTED] writes: On Tue, Aug 07, 2001 at 09:47:26PM -0500, Jarkko Hietaniemi wrote: http://www.bad-managers.com/rumours/story019.shtml Don't put bad ideas into my head like that. You obviously didn't hear about me getting the whole YAPC::Europe audience yelling Sir, yes, sir! during my talk. I'm raising a QA army. Hey, I was in that talk and I definitely wasn't yelling 'Sir, yes, sir!' -- Piers Cawley www.iterative-software.com
Re: on QA
Michael G Schwern [EMAIL PROTECTED] writes: On Mon, Aug 13, 2001 at 06:13:24AM +0100, Piers Cawley wrote: Hey, I was in that talk and I definitely wasn't yelling 'Sir, yes, sir!' You'll be the first against the wall when the revolution comes. But I thought you were the running dog lackey of the counter revolutionary forces with your authoritarian ways and excessive shouting. -- Piers Cawley www.iterative-software.com
