From @jeffhorwitz

Jonathan asked that I submit this as a reminder to him.

mod_perl6 is written in Perl 6 and relies heavily on classes defined in
PIR. However, when mod_perl6 is precompiled to PIR, those classes do
not yet exist, and parser does not see the names as classes. The result
is that Foo.new() becomes​:

  $P20 = "Foo"()
  $P21 = "!dispatch_method"($P20, "new")

with the out-of-place "Foo"() failing miserably. The offending code can
be easily reproduced using the pir target​:

[jeff@​groovy rakudo]$ ./perl6 --target=pir

Foo.new

.namespace []
.sub "_block11" :main :anon :subid("10_1240503611")
  .param pmc param_22 :slurpy
.annotate "line", 0
  .const 'Sub' $P24 = "12_1240503611"
  capture_lex $P24
  find_name $P13, "!UNIT_START"
.annotate "line", 1
  .const 'Sub' $P15 = "11_1240503611"
  .lex "@​_", param_22
  .tailcall $P13($P15, param_22)
.annotate "line", 0
  .return ()
.end

.namespace []
.sub "" :load :init :subid("post13") :outer("10_1240503611")
.annotate "line", 0
  .const 'Sub' $P12 = "10_1240503611"
  .local pmc block
  set block, $P12
$P0 = compreg "Perl6"
unless null $P0 goto have_perl6
load_bytecode "perl6.pbc"
have_perl6​:
.end

.namespace []
.sub "_block14" :anon :subid("11_1240503611")
.annotate "line", 1
  get_namespace $P16
  .lex "$?PACKAGE", $P16
.include "interpinfo.pasm"
  new $P17, "Perl6Scalar"
  .lex "$_", $P17
  new $P18, "Perl6Scalar"
  .lex "$/", $P18
  new $P19, "Perl6Scalar"
  .lex "$!", $P19
  $P20 = "Foo"()
  $P21 = "!dispatch_method"($P20, "new")
  .return ($P21)
.end

.namespace []
.sub "_block23" :load :anon :subid("12_1240503611")
:outer("10_1240503611")
.annotate "line", 0
.include "interpinfo.pasm"
$P0 = interpinfo .INTERPINFO_CURRENT_SUB
$P0 = $P0."get_outer"()
$P0()
  .return ()
.end

From @pmichaud

On Thu, Apr 23, 2009 at 09​:33​:37AM -0700, Jeff Horwitz wrote​:

The result is that Foo.new() becomes​:

 $P20 = "Foo"\(\)
 $P21 = "\!dispatch\_method"\($P20, "new"\)

with the out-of-place "Foo"() failing miserably. The offending code can
be easily reproduced using the pir target​:

[jeff@​groovy rakudo]$ ./perl6 --target=pir

Foo.new

Rakudo is behaving precisely according to the spec here --
unknown identifiers ("Foo") are presumed to be listops
in absence of some other declaration. So, Foo.new above
is exactly the same as Foo().new() .

In order to get the above to work you'd need a "use Foo;" statement
somewhere first, to load the Foo class (and register it in the parser).

Pm

The RT System itself - Status changed from 'new' to 'open'

From @jeffhorwitz

On Fri Apr 24 05​:51​:23 2009, pmichaud wrote​:

Rakudo is behaving precisely according to the spec here --
unknown identifiers ("Foo") are presumed to be listops
in absence of some other declaration. So, Foo.new above
is exactly the same as Foo().new() .

In order to get the above to work you'd need a "use Foo;" statement
somewhere first, to load the Foo class (and register it in the
parser).

ok, makes sense. it worked before, so i thought something was broken.
turns out it was me. :)

i'm going to have to play some games to get this working correctly when
i precompile my modules, since these classes are created by the
mod_parrot runtime and don't exist at compile-time.

i can bring up any other issues offline -- if you have no other
comments, go ahead and reject the ticket.

-jeff

From @jeffhorwitz

On Fri, 24 Apr 2009, Patrick R. Michaud via RT wrote​:

On Thu, Apr 23, 2009 at 09​:33​:37AM -0700, Jeff Horwitz wrote​:

The result is that Foo.new() becomes​:

 $P20 = "Foo"\(\)
 $P21 = "\!dispatch\_method"\($P20, "new"\)

with the out-of-place "Foo"() failing miserably. The offending code can
be easily reproduced using the pir target​:

[jeff@​groovy rakudo]$ ./perl6 --target=pir

Foo.new

Rakudo is behaving precisely according to the spec here --
unknown identifiers ("Foo") are presumed to be listops
in absence of some other declaration. So, Foo.new above
is exactly the same as Foo().new() .

In order to get the above to work you'd need a "use Foo;" statement
somewhere first, to load the Foo class (and register it in the parser).

ok, makes sense. it worked before, so i thought something was broken.
turns out it was me. :)

i'm going to have to play some games to get this working correctly when i
precompile my modules, since these classes are created by the mod_parrot
runtime and don't exist at compile-time.

-jeff

From @pmichaud

On Fri, Apr 24, 2009 at 09​:01​:41AM -0400, Jeff Horwitz wrote​:

In order to get the above to work you'd need a "use Foo;" statement
somewhere first, to load the Foo class (and register it in the parser).

ok, makes sense. it worked before, so i thought something was broken.
turns out it was me. :)

i'm going to have to play some games to get this working correctly when i
precompile my modules, since these classes are created by the mod_parrot
runtime and don't exist at compile-time.

If your modules are using P6object to create their classes, then
everything should "just work" with "use Foo" -- just put the
Foo.pir or Foo.pbc somewhere that Rakudo can find it.

Pm

From @jeffhorwitz

On Sun Apr 26 07​:17​:11 2009, pmichaud wrote​:

On Fri, Apr 24, 2009 at 09​:01​:41AM -0400, Jeff Horwitz wrote​:

In order to get the above to work you'd need a "use Foo;" statement
somewhere first, to load the Foo class (and register it in the
parser).

ok, makes sense. it worked before, so i thought something was
broken.
turns out it was me. :)

i'm going to have to play some games to get this working correctly
when i
precompile my modules, since these classes are created by the
mod_parrot
runtime and don't exist at compile-time.

If your modules are using P6object to create their classes, then
everything should "just work" with "use Foo" -- just put the
Foo.pir or Foo.pbc somewhere that Rakudo can find it.

Pm

I was able to force Foo to be parsed as a type by prepending
with '​::'. :​:Foo.new() works as expected, and pmichaud confirmed this
is proper behavior. I'll close out this ticket.

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