Author: leo
Date: Tue Mar  7 12:55:42 2006
New Revision: 11817

Modified:
   trunk/src/hll.c

Log:
Namespaces 7 - caching HLL namespace in HLL_info isn't trivial

* see the comment in src/hll.c:138


Modified: trunk/src/hll.c
==============================================================================
--- trunk/src/hll.c     (original)
+++ trunk/src/hll.c     Tue Mar  7 12:55:42 2006
@@ -17,7 +17,7 @@
    interpreter->HLL_info
 
    @HLL_info = [
-     [ hll_name, hll_lib, namespace, { core_type => HLL_type, ... } ],
+     [ hll_name, hll_lib, { core_type => HLL_type, ... }, namespace ],
      ...
      ]
 
@@ -61,8 +61,8 @@
 enum {
     e_HLL_name,
     e_HLL_lib,
-    e_HLL_namespace,
     e_HLL_typemap,
+    e_HLL_namespace,
     e_HLL_MAX
 } HLL_enum_t;
 
@@ -134,6 +134,16 @@
     }
 
     /* UNLOCK */
+
+    /*
+     * XXX the HLL_info is frozen with the ParrotInterpreter, to be able
+     *     to preserve all in the PBC *but* the namespace hash shouldn't be
+     *     included in the bytecode - HACK - reduce array.elems by one
+     *     so that namespace isn't seen by freeze/thaw
+     * XXX this still doesn't recreate the namespace slot TODO    
+     *     better use a distinct structure for namespaces ? 
+     */
+    PMC_int_val(entry) = e_HLL_namespace;
     return idx;
 }
 

Reply via email to