Re: IMCC problems with library loading

[Jeff Clites]

On Nov 17, 2003, at 1:59 AM, Leopold Toetsch wrote:

Jeff Clites <[EMAIL PROTECTED]> wrote:
I've run into a couple of issue with library loading which have their
origin down inside the IMCC code:

1) External libraries are being loaded at parse time.

Inside of INS() in imcc/parser_util.c, Parrot_load_lib() is called at
parse-time when loadlib is encountered. This is causing libraries to 
be
loaded twice (once at parse-time and once at run-time), which is a
problem in its own right, but it also just seems like generally the
wrong behavior.
If the library registers itself correctly, its loaded once only. E.g. a
PMC library calls pmc_register() so that the classname is known.
Actually, Parrot_load_lib calls Parrot_dlopen (inside if the call to 
get_path), then later calls is_loaded and closes the library if it was 
already loaded before. This is loading the library twice, from the 
perspective of the operating system. But that's really a side issue.

My main point is that you can't do conditional library loading. This 
code will try to load the "doesnt_exist" library, and I don't think it 
should:

        branch  HERE
        loadlib P1, "doesnt_exist"
HERE:
        end
It's not because the branch fails--it's because the library is loaded 
before the script starts running.

Or is this expected--that a loadlib instruction will cause a library to 
be loaded, even if the instruction is never reached?

2) Code which tries to instantiate a dynamically-loaded PMC fails to
parse.

Code such as this:

         loadlib P1, "foo"
         new P0, .Foo
How does "foo" look like? dynclasses/dynfoo.pasm has an example of
loading dynamic classes (and it works here).
dynclasses/dynfoo.pasm is the example I was referring to. It actually 
works for me also--if I leave the code in imcc/parser_util.c which 
causes the parse-time library loading mentioned above. (I had commented 
that out.)

But rearranging the assembly slightly so that the execution order is 
logically the same but the loadlib instruction is further down in the 
source causes it to fail. That is:

        null P0
        branch one
two:
        find_type I0, "Foo"
        print I0
        print "\n"
        new P0, .Foo
        print "ok 2\n"
        branch three
one:
        loadlib P1, "foo"
        print "ok 1\n"
        branch two
three:
        set I0, P0
        print I0
        print "\n"
        end
This again fails with the error:

	error:imcc:unknown macro '.Foo'

This is because the parser is encountering ".Foo" before it has loaded 
the lib at parse-time.

This brings me back to my original question of whether the parser 
should think ".Foo" is a macro at all, or if rather that's not legal 
macro syntax.

JEff