On Mon, 7 Mar 2011, Bill Janssen wrote:
Andi Vajda <va...@apache.org> wrote:
So, I went to my Mac, and looked for libjcc.dylib. Sure enough,
it's there. So I tried this simple program:
import org.apache.jcc.PythonVM;
public class test {
public static void main (String[] argv) {
PythonVM.start("/usr/bin/python",
new String[] { "-c", "import time; print time.localtime()"});
}
}
It seems that you think that this is going to run /usr/bin/python.
Not really.
Right. I finally broke down and read the code. I see there's no way to
do a "simple" test case.
What the "instantiate" code does is to load a callable from a specified
module, then call it, passing no arguments. That callable must return
an instance of a Python class which explicitly extends a Java class, if
the value is to be returned to Java. Otherwise, a value of "null" is
returned. The callable may of course have side-effects in the Python
world.
It would be nice to be able to pass arguments to the callable.
And there doesn't seem to be any way to modify Python's sys.path before
one attempts to instantiate one's own Python class, either. Adding a
PythonVM.exec() method would be a help there.
To fix that, to help the dynamic linker to load that library, you need
to change the LFLAGS for 'darwin' in JCC's setup.py to also list the
python framework by adding '-framework', 'Python' to that list.
After rebuilding JCC, be sure then that otool lists libpython.dylib to
verify that it worked.
Is there any reason not to make that change globally? Is there a
downside to automatically building against the Python framework on OS X?
Yes, if one uses a virtual env or some other non-standard Python framework
location, it's better to let the python executable provide the correct
library than having to ensure that it matches in setup.py.
I believe, at first, it was that way, there was a -framework Python entry.
I then removed it because it was in the way, if I remember correctly.
Andi..
