Re: [Jython-dev] *loading

[Samuele P. <pe...@in...>]

Hi.

[Finn]
> [Samuele]
>
> >Let's do that way. If you mean the gathering of frozen packages info,
plus
> >the initProxy,initProps,runMain stuff,
>
> I will commit this soon. The list of modules is passed to
> Py.initProperties() which right now only prints the list for debugging
> purposes. The list looks like this:
>
>    String[] modules = { "p0.__init__", "a", "p0.x" }
>
> Is this what you need?

It should be ok, otherwise I can adjust your code, if that does not disturb
you.

> >I imagine I can also fix the two last bugs: very likely the first as part
of
> >the findattr rewriting.
>
> I assume bug #2 must be solved in jythonc. (Pity we can't re-use the
> algorithm for searching for modules from jython itself)

Yes, it's a jythonc bug.

> >[Finn]
> >>>(a little note) Differently from jython, jythonc follows
> >>>the proposed precedence py > java. For the rest (java loading)
> >>>it uses the org.python.core runtime. Is that true?
> >>
> >>I don't think so. jythonc creates a list of known java packages and
> >>passes this list on to sys.add_package() during initialization. This
> >>creates PyJavaPackages which is currently searched before the python
> >>modules. I think. But hey, you're the expert <wink>.
> >
> >I just hope I'm the expert ;). Sorry for the confusion. I was referring
to
> >the jythonc handling of import stmt
> >at compilation time, not to the interaction between compiled code and
jython
> >runtime.
>
> Ohh, I see. I'm entirely sure about that either, but it does seem to be
> the case. I'll look further into this and maybe fix bug #2.

I have studied the code for tracking bug #2. In order to solve it one should
give jythonc ImportName.lookupName
information about the package of the module in which the involved import is.
The information is somehow around.
It is clearly needed to construct the path necessary for relative lookup.

I have just started working on the rest.

regards, Samuele