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;
}