Global not found between PIR and PMC

[Francois PERRAD]

In a library (languages/lua/lib/luastring.pir), I declare a global variable
("mt_string"):

.namespace [ "Lua" ]
.HLL "Lua", "lua_group"

.sub init :load, :anon
...
.local pmc _lua_mt_string
_lua_mt_string = new .LuaTable
global "mt_string" = _lua_mt_string
...

In a PMC method, I want to access it :
Index: luabase.pmc
===================================================================
--- luabase.pmc (revision 11848)
+++ luabase.pmc (working copy)
@@ -559,6 +559,11 @@
if (dynpmc_LuaTable == retval->vtable->base_type)
return retval;
}
+ else if (dynpmc_LuaString == SELF->vtable->base_type) {
+ return Parrot_get_global(INTERP,
+ const_string(INTERP, "Lua"),
+ const_string(INTERP, "mt_string"), NULL);
+ }
return pmc_new(INTERP, dynpmc_LuaNil);
}

But I've the following result :
$ perl -I../../lib t/pmc/string.t
not ok 11 - check tostring
# Failed test (t/pmc/string.t at line 224)
# got: 'value
# Global 'mt_string' not found
# current instr.: '_main' pc 16
(C:\fperrad\parrot\trunk\languages\lua\t\pmc\string_11.pir:8)
# '

What is it wrong ?

François.

[Leopold Toetsch]

Francois PERRAD wrote:
>
> In a library (languages/lua/lib/luastring.pir), I declare a global
> variable ("mt_string"):
>
> .namespace [ "Lua" ]
> .HLL "Lua", "lua_group"
>
> .sub init :load, :anon
> ...
> .local pmc _lua_mt_string
> _lua_mt_string = new .LuaTable
> global "mt_string" = _lua_mt_string

> What is it wrong ?

First and foremost, it's hard to follow the problem, if there are
several snippets, a patch that fails, well, and a test that then
succeeds, if hopefully all steps are implemented.

Please provide one patch against svn head, relative to Parrot root that
contains everything to repeat the problem.

WRT subject: it seems to me that

global "mt_string" = _lua_mt_string

is storing into the global (root) namespace [1], while in LuaBase
'Lua::mt_string' is trying to be loaded. ('::' is the namespace
delimiter according to pdd21 and not to be taken literally)

[1] this will change, when pdd21 is fully implemented, i.e. it will
store into the current namespace then.

> François.

leo

[Chip Salzenberg]

On Fri, Mar 10, 2006 at 01:06:10PM +0100, Leopold Toetsch wrote:
> ('::' is the namespace delimiter according to pdd21 and not to be taken
> literally)

Indeed so; but the Perl and C++ usage is so ingrained that people are still
instinctively trying to use it. So, it's time for a bigger hammer.

First, I'm modifying pdd21 to remove all occurrences of "::".

Second: Leo, in your copious free time (:-)) could you please tell me
whether it's feasible to add a hack to the PIR compiler so that compiling
namespace ops, with a literal string parameter containing "::" will throw a
warning? I don't want a runtime warning, but a compile-time warning will
avoid trouble. (It's possible that by 1.0 we'll be able to kill the
warning, but I doubt it.)
--
Chip Salzenberg <ch...@pobox.com>

[Leopold Toetsch]

On Mar 14, 2006, at 18:33, Chip Salzenberg wrote:

> On Fri, Mar 10, 2006 at 01:06:10PM +0100, Leopold Toetsch wrote:
>> ('::' is the namespace delimiter according to pdd21 and not to be
>> taken
>> literally)
>
> Indeed so; but the Perl and C++ usage is so ingrained that people are
> still
> instinctively trying to use it. So, it's time for a bigger hammer.
>
> First, I'm modifying pdd21 to remove all occurrences of "::".

Hah - I've said that it's confusing ;-)

> Second: Leo, in your copious free time (:-)) could you please tell me
> whether it's feasible to add a hack to the PIR compiler so that
> compiling
> namespace ops, with a literal string parameter containing "::" will
> throw a
> warning? I don't want a runtime warning, but a compile-time warning
> will
> avoid trouble. (It's possible that by 1.0 we'll be able to kill the
> warning, but I doubt it.)

I'll add the warning as soon as there is an answer, where all the
parrot symbols and already existing lib "globals", including PGE*,
should actually be stored into :-) Or some such. And, well, a
compile-time warning still would break a lot of tests.

Anyway: as said, specifying namespaces needs also policy decisions for
existing stuff.

The current implementation assumes in the absence of any .HLL directive
that HLL_id := 0 aka 'parrot' and namespace is '::parrot' (errr).

leo