From: Samuele P. <pe...@in...> - 2000-10-28 19:18:42
|
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 |