On Wed, Jan 02, 2002 at 05:37:28PM +0100, Mattia Barbon wrote:
> I don't care for the variable name, but I'd really like
> to have this feature.
Would it work ok as a Test::Builder accessor method rather than an
environment variable?
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.p
> On Wed, Jan 02, 2002 at 05:37:28PM +0100, Mattia Barbon wrote:
> > I don't care for the variable name, but I'd really like
> > to have this feature.
>
> Would it work ok as a Test::Builder accessor method rather than an
> environment variable?
No, unfortunately, because the call order is like t
On Sat, Jan 05, 2002 at 10:17:34PM +0100, Mattia Barbon wrote:
> > On Wed, Jan 02, 2002 at 05:37:28PM +0100, Mattia Barbon wrote:
> > > I don't care for the variable name, but I'd really like
> > > to have this feature.
> >
> > Would it work ok as a Test::Builder accessor method rather than an
>
> On Sat, Jan 05, 2002 at 10:17:34PM +0100, Mattia Barbon wrote:
> > > On Wed, Jan 02, 2002 at 05:37:28PM +0100, Mattia Barbon wrote:
> > > > I don't care for the variable name, but I'd really like
> > > > to have this feature.
> > >
> > > Would it work ok as a Test::Builder accessor method rathe
On Sun, Jan 06, 2002 at 03:56:24PM +0100, Mattia Barbon wrote:
> > Could you explain again why you need test output while compiling, I'm
> > not quite following. Assume you had the I_WANT_OUTPUT_DURING_COMPILE
> > environment variable could you show how you'd be using it?
>
> Let's say I have th
On 2002.01.05 23:45 Michael G Schwern wrote:
> Here's an interesting alternative. Do C just before
> running the tests, though that's pretty ugly.
Interesting idiom, but I don't see when this can be done.
> > But I rwally like the environment variable better, because with the
> > package variab
On Sun, Jan 06, 2002 at 09:46:13PM +0100, Rafael Garcia-Suarez wrote:
> Instead of using an environment variable, you can use a global variable
> in the O namespace. Let's say $O::No_Test_Output defaults to 1 (set by
> O.pm).
>
> In Test::Builder (line #571) you would have
> return if $O::N
> On Sun, Jan 06, 2002 at 03:56:24PM +0100, Mattia Barbon wrote:
> > > Could you explain again why you need test output while compiling, I'm
> > > not quite following. Assume you had the I_WANT_OUTPUT_DURING_COMPILE
> > > environment variable could you show how you'd be using it?
> >
> > Let's s
On Tue, Jan 08, 2002 at 11:02:27PM +0100, Mattia Barbon wrote:
> > Code inside the BEGIN blocks has $^C set?? Or are they just not being
> > run at all? Either of those are bugs. But there's a third
>
> The code inside the begin blocks has $^C set ( as it should ), and they
> are being run
>
perlcc seems to be dropping BEGIN blocks entirely, that's the problem.
# foo.plx
BEGIN {
print "foo\n";
}
print "bar\n";
$ bleadperl foo.plx
foo
bar
$ perlcc foo.plx
$ ./a.out
bar
The result from the compiled program should be the same as the
original. For some reason
Now I understand I missed to tell you this fundamental detail before,
sorry.
> perlcc seems to be dropping BEGIN blocks entirely, that's the problem.
No, that's correct. Explanation: if I have a module Foo
package Foo;
$x = 1;
print "AAA";
sub a { $x }
1;
and a main program foo.pl
--
On Sun, Jan 13, 2002 at 07:39:52PM +0100, Mattia Barbon wrote:
> > perlcc seems to be dropping BEGIN blocks entirely, that's the problem.
>
> No, that's correct. Explanation: if I have a module Foo
>
> package Foo;
>
> $x = 1;
> print "AAA";
>
> sub a { $x }
>
> 1;
>
> and a main prog
> On Sun, Jan 13, 2002 at 07:39:52PM +0100, Mattia Barbon wrote:
> > > perlcc seems to be dropping BEGIN blocks entirely, that's the problem.
> >
> > No, that's correct. Explanation: if I have a module Foo
> >
> > package Foo;
> >
> > $x = 1;
> > print "AAA";
> >
> > sub a { $x }
> >
> > 1
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
>
> 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
On Mon, Jan 14, 2002 at 04:16:49PM +, Piers Cawley wrote:
> > 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
On Mon, Jan 14, 2002 at 04:16:49PM +, Piers Cawley wrote:
> 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
On 2002.01.14 22:27 Michael G Schwern wrote:
> B::Deparse has slowly gotten very good at figuring out BEGIN blocks
> from 'use' statements and putting them in the right places. Hard
> fought knowledge. Steal from it.
There are still problems with pragmas. (As I was working on B::Deparse
the las
On Mon, Jan 14, 2002 at 11:20:43PM +0100, Rafael Garcia-Suarez wrote:
> On 2002.01.14 22:27 Michael G Schwern wrote:
> > B::Deparse has slowly gotten very good at figuring out BEGIN blocks
> > from 'use' statements and putting them in the right places. Hard
> > fought knowledge. Steal from it.
>
On Mon, Jan 14, 2002 at 10:38:36PM +, Piers Cawley wrote:
> >> Deferring BEGIN blocks 'til runtime will break rather more realworld
> >> program than it fixes I think.
> >
> > Where is deferring involved?
>
> Err... it goes like this:
>
> by the main program>
>
>
>
>
>
> The compiled f
On Mon, Jan 14, 2002 at 11:11:57PM +, Nicholas Clark wrote:
> On Mon, Jan 14, 2002 at 10:38:36PM +, Piers Cawley wrote:
> > Michael G Schwern <[EMAIL PROTECTED]> writes:
> >
> > > On Mon, Jan 14, 2002 at 04:16:49PM +, Piers Cawley wrote:
> > >> Michael G Schwern <[EMAIL PROTECTED]> wr
On Mon, Jan 14, 2002 at 11:43:24PM +, Piers Cawley wrote:
> > What's left?
>
> What about begin blocks with side effects. How do you propose
> detecting the side effects. How do you deal with things that may
> dispatch to different subroutines depending on when they are
> evaluated? How do yo
On Tue, Jan 15, 2002 at 08:51:06AM +, Piers Cawley wrote:
> > I don't understand. Why do we have to deal with them? Just translate
> > the Perl code in the BEGIN block to C , dump it and make
> > sure it gets run first. Right?
> >
> > I think I'm missing something very vital here.
>
> Let'
On Wed, Jan 16, 2002 at 08:45:26AM +0100, Paul Johnson wrote:
> The fundamental problem here is that BEGIN blocks have to run when they
> are compiled. This is documented. You can try to work out whether the
> BEGIN blocks can be rearranged and run at different times, but as Piers
> has pointed
On Tue, Jan 15, 2002 at 05:30:09PM -0500, [EMAIL PROTECTED] wrote:
> On Tue, Jan 15, 2002 at 08:51:06AM +, Piers Cawley wrote:
> > > I don't understand. Why do we have to deal with them? Just translate
> > > the Perl code in the BEGIN block to C , dump it and make
> > > sure it gets run firs
On Wed, Jan 16, 2002 at 11:39:05AM +0100, Mattia Barbon wrote:
> >It seems that's wrong. That what perlcc/B::C does is 'freeze' the
> >current state of the interpreter after compilation, including the
> >values of variables, and then spit out appropriate C code for only
> >the post-compile opcod
26 matches
Mail list logo
