Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

HLLs sometimes leak into loaded modules #274

Open
sorear opened this Issue · 5 comments

3 participants

@sorear
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
Owner

this is blocking Blizkost *.

@sorear

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
Collaborator

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
Collaborator

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
Collaborator

Only adopt Namespaces without parents.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.