HLLs sometimes leak into loaded modules #274

sorear opened this Issue Apr 4, 2010 · 5 comments


None yet
3 participants

sorear commented Apr 4, 2010

stefan@stefans:~$ perl6 -e 'pir::load_bytecode("/usr/local/lib/parrot/2.2.0-devel/languages/nqp/nqp.pbc")'
Parent isn't a Class.
current instr.: 'parrot;P6metaclass;add_parent' pc 224 (runtime/parrot/library/P6object.pir:232)
called from Sub 'parrot;P6metaclass;register' pc 532 (runtime/parrot/library/P6object.pir:408)
called from Sub 'perl6;PCT;Grammar;onload' pc -1 ((unknown file):-1)
called from Sub 'perl6;PCT;__onload' pc 0 (compilers/pct/PCT.pir:18)
... call repeated 1 times

I'm not sure what's going on here or how to start debugging it. Austin thinks that Rakudo is redefining something somewhere, but that wouldn't explain the fact that PCT has somehow become loaded into the perl6 top level namespace. I suspect a Parrot bug somewhere.

Originally http://trac.parrot.org/parrot/ticket/1542


particle commented Apr 15, 2010

this is blocking Blizkost *.

sorear commented Apr 25, 2010

Some more data points. This occurs with any module that loads PCT/Grammar.pbc, or loading PCT/Grammar.pbc itself. It does not occur with PCT/HLLCompiler.pbc. It was possible to make Blizkost load by narrowing the load_bytecode opcode to only load HLLCompiler; thus this is no longer a blocker. I am still curious what causes this though.


plobsing commented Sep 28, 2010

748 byte attachment from plobsing
at http://trac.parrot.org/parrot/raw-attachment/ticket/1542/ns_abduction.patch

```Index: src/pmc/namespace.pmc

--- src/pmc/namespace.pmc (revision 49323)
+++ src/pmc/namespace.pmc (working copy)
@@ -468,8 +468,10 @@
if (val_is_NS) {
/* TODO - this hack needs to go */
Parrot_NameSpace_attributes *nsinfo = PARROT_NAMESPACE(value);

  •        nsinfo->parent = SELF;  /\* set parent */
  •        nsinfo->name   = key;   /\* and name */
  •        if (PMC_IS_NULL(nsinfo->parent)) {
  •            nsinfo->parent = SELF;  /\* set parent */
  •            nsinfo->name   = key;   /\* and name */
  •        }
         if (new_tuple) {
             VTABLE_set_pmc_keyed_int(INTERP, new_tuple, NS_slot_ns, value);

plobsing commented Sep 28, 2010

Here's why PCT is in the perl6 HLL:

  • Rakudo exports PCT (among other things) into perl6 root namespace using Namespace.export_to
  • Namespace.export_to adds to the target namespace using Namespace.set_pmc_keyed_str
  • when Namespace.set_pmc_keyed_str detects that it is adding a Namespace to a Namespace, it reparents the child Namespace to SELF.

This means that PCT is available both as ['parrot';'PCT'] and ['perl6';'PCT'], but anything under PCT will think it is in ['perl6';'PCT'].

The good news is that the HLL associated with Namespaces, Subs, etc in this heirarchy should remain unchanged.

The bad news is that it appears we have yet another Namespace <=> Class mismatch occuring (which is why we get the 'Parrent isn't a Class' error).

A small patch to src/pmc/namespace.pmc is sufficient to fix *this* bug, but I think more important here is the overall insanity of the reparenting special case at all. Also the lingering Namespace/Class associations (which is the root of this as well as other bugs).


plobsing commented Sep 28, 2010

Only adopt Namespaces without parents.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment