Andi Vajda <[email protected]> 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? Bill
