From @jeffhorwitz

Rakduo's behavior has changed in the past two weeks -- as of r34349,
it seems to evaluate "use" statements during the parse phase. Among other
things, this breaks precompilation when the "used" module is not in the
@​INC path during compilation. This causing all sorts of problems for
mod_perl6, which precompiles its modules.

Example​:

[jeff@​groovy perl6]$ cat x.p6
use Foo;

[jeff@​groovy perl6]$ ../../parrot perl6.pbc --target=past x.p6
Can't find ./Foo in @​INC
current instr.​: 'die' pc 14705 (src/builtins/control.pir​:204)
called from Sub 'require' pc 15075 (src/builtins/eval.pir​:111)
called from Sub 'use' pc 15137 (src/builtins/eval.pir​:134)
called from Sub 'parrot;Perl6;Grammar;Actions;_block598' pc 109316
(src/gen_actions.pir​:1962)
called from Sub 'parrot;Perl6;Grammar;Actions;use_statement' pc 109138
(src/gen_actions.pir​:1909)
called from Sub 'parrot;Perl6;Grammar;use_statement' pc 45201
(src/gen_grammar.pir​:9663)
called from Sub 'parrot;Perl6;Grammar;statement_control' pc 34050
(src/gen_grammar.pir​:5371)
called from Sub 'parrot;Perl6;Grammar;statement' pc 29125
(src/gen_grammar.pir​:3577)
called from Sub 'parrot;Perl6;Grammar;statementlist' pc 27178
(src/gen_grammar.pir​:2809)
called from Sub 'parrot;Perl6;Grammar;statement_block' pc 24716
(src/gen_grammar.pir​:1838)
called from Sub 'parrot;Perl6;Grammar;TOP' pc 20606
(src/gen_grammar.pir​:207)
called from Sub 'parrot;PCT;HLLCompiler;parse' pc 634
(src/PCT/HLLCompiler.pir​:388)
called from Sub 'parrot;PCT;HLLCompiler;compile' pc 428
(src/PCT/HLLCompiler.pir​:301)
called from Sub 'parrot;PCT;HLLCompiler;eval' pc 862
(src/PCT/HLLCompiler.pir​:500)
called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1217
(src/PCT/HLLCompiler.pir​:669)
called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1398
(src/PCT/HLLCompiler.pir​:759)
called from Sub 'parrot;Perl6;Compiler;main' pc 18946 (perl6.pir​:162)

From @jeffhorwitz

On Fri Dec 26 12​:56​:20 2008, jhorwitz wrote​:

Rakduo's behavior has changed in the past two weeks -- as of r34349,
it seems to evaluate "use" statements during the parse phase.

Sorry, this should read "PAST generation phase", not "parse phase."

@jeffhorwitz - Status changed from 'new' to 'open'

From @moritz

Jeff Horwitz (via RT) wrote​:

# New Ticket Created by Jeff Horwitz
# Please include the string​: [perl #​61742]
# in the subject line of all future correspondence about this issue.
# <URL​: http://rt.perl.org/rt3/Ticket/Display.html?id=61742 >

Rakduo's behavior has changed in the past two weeks -- as of r34349,
it seems to evaluate "use" statements during the parse phase.

That is the correct behaviour

Among other
things, this breaks precompilation when the "used" module is not in the
@​INC path during compilation. This causing all sorts of problems for
mod_perl6, which precompiles its modules.

Example​:

[jeff@​groovy perl6]$ cat x.p6
use Foo;

[jeff@​groovy perl6]$ ../../parrot perl6.pbc --target=past x.p6
Can't find ./Foo in @​INC

So does Foo.{pm,pir} not exist while you compile x.p6?

Cheers,
Moritz

From @jeffhorwitz

On Sat, 27 Dec 2008, Moritz Lenz via RT wrote​:

Example​:

[jeff@​groovy perl6]$ cat x.p6
use Foo;

[jeff@​groovy perl6]$ ../../parrot perl6.pbc --target=past x.p6
Can't find ./Foo in @​INC

So does Foo.{pm,pir} not exist while you compile x.p6?

correct. after reviewing the changes to rakudo, i understand why use now
works this way. but it breaks things in interesting ways, especially for
modules whose dependencies cannot be met during a precompilation phase
(e.g. loading PIR that dlfuncs from the embedding apache process).

maybe i haven't thought about this enough. i'll flesh it out a bit and
post to the list for comment.

-jeff

From @moritz

On Sun Dec 28 07​:50​:32 2008, jhorwitz wrote​:

On Sat, 27 Dec 2008, Moritz Lenz via RT wrote​:

Example​:

[jeff@​groovy perl6]$ cat x.p6
use Foo;

[jeff@​groovy perl6]$ ../../parrot perl6.pbc --target=past x.p6
Can't find ./Foo in @​INC

So does Foo.{pm,pir} not exist while you compile x.p6?

correct. after reviewing the changes to rakudo, i understand why use now
works this way. but it breaks things in interesting ways, especially for
modules whose dependencies cannot be met during a precompilation phase
(e.g. loading PIR that dlfuncs from the embedding apache process).

maybe i haven't thought about this enough. i'll flesh it out a bit and
post to the list for comment.

Jeff, could you please clarify, is there something in this ticket which
still goes wrong? If yes, what?

Cheers,
Moritz

From @jeffhorwitz

On Wed Jan 28 09​:53​:31 2009, moritz wrote​:

Jeff, could you please clarify, is there something in this ticket
which
still goes wrong? If yes, what?

Sure, and I'll restate my problem. When the compiler
encounters "use", it immediately compiles and executes the module
passed to it. That's good, and obviously how it should work. But
since this happens at compile time, runtime dependencies might not be
satisfied when precompiling a module, since this happens outside of
the runtime environment. Right now, such code cannot be precompiled.

In my case, I precompile mod_perl6.pm and other modules for better
startup performance. However, mod_perl6.pm loads modules that are
only available at runtime, since they loadlib/dlfunc from the Apache
process. Precompilation fails very loudly.

I have a workaround in place for mod_perl6, but what I really need is
a runtime-only block that doesn't get executed when compiling to
bytecode. This may exist, but I'm not aware of it.

From @moritz

As far as I can tell this now exists with the import() statement.

@moritz - Status changed from 'open' to 'resolved'