jepp-users — Send your questions here

[Jepp-users] Getting started with Jepp

[Sébastien P. <seb...@gm...>]

Hello,

I have a freshly installed Jepp on my Ubuntu Linux 9.10, and tried the test
examples using the startup script you described, but the examples seem to be
broken. For instance, invokin the 'swingtest.py' example will raise:

> ./jep testswing.py
jep.JepException: <type 'exceptions.ImportError'>: No module named
javax.swing
 at jep.Jep.run(Native Method)
 at jep.Jep.runScript(Jep.java:191)
 at jep.Jep.runScript(Jep.java:167)
 at jep.Run.run(Run.java:58)
 at jep.Run.main(Run.java:153)

but I checked that jep is able to find java classes, as the following
example works:

from jep import *
__builtins__.__import__ = jep.jimport

import java.lang
from java.util import HashMap
from java.io import FileInputStream
print java

if __name__ == '__main__':
    print 'sys.path:        ', sys.path
    print 'dir(jep):        ', dir(jep)
    print 'dir(jep):        ', dir(java.lang)

Any idea why this happens ?

 -- Sébastien

[Jepp-users] Jepp 2.4 Released

[Mike J. <mi...@pu...>]

Hi All,

I tossed out a new release that disables the old import hack that was
causing so many problems.

To get the old behavior back, run this:

from jep import *
__builtins__.__import__ = jep.jimport

Or build with –enable-import.

The new release also has a x64 build fix for Fedora and rpm-based
distros and a working .spec generated from configure that should work
on Fedora, thanks to John Matthews.

Thanks,
Mike

-- 
Open source monitoring http://www.leemba.com

Re: [Jepp-users] Import problem

[Mike J. <mi...@pu...>]

Hey, I'm sorry for the delay.

I'm probably going to upload a new version with the import hack disabled.
I've been playing around with import hooks but it's not really good for lazy
loading and is probably more trouble than it's worth.

If you're able to compile your own I can point you to the source line to
comment out.

On Fri, Jan 1, 2010 at 9:15 AM, Rick Giuly <rg...@gm...> wrote:

>
> Hello All,
>
> I'm using jep.eval to append to sys.path and import a module.
> The import is failing with this error:
>
> Package not found: detector
>
> As far as I can tell the file is in the sys.path and should load fine
> (detector.py is in the sys.path).
>
> I'm using the Jepp windows binary on sourceforge
> WindowsXP
> Python 2.5.2
>
>
> Any help is appreciated
>
> The files I'm using to test are attached
>
> -rick
>
>
> import java.io.*;
> import java.util.ArrayList;
>
> import jep.python.*;
> import jep.*;
>
>
> /**
>  * Test2.java
>  *
>  *
>  * Created: Fri Apr 30 12:42:58 2004
>  *
>  * @author [mrjohnson0 at sourceforge.net] Mike Johnson
>  * @version $Id: Test2.java 445 2007-11-20 06:57:06Z mrjohnson0 $
>  */
> public class Test2 implements Runnable {
>    private Jep jep = null;
>    private boolean testEval = false;
>
>    public Test2() {
>    } // Test2 constructor
>
>
>    public Test2(boolean testEval) {
>        this.testEval = testEval;
>    }
>
>
>    public void run() {
>
>            try {
>                File pwd = new File(".");
>
>                //this.jep = new Jep(this.testEval, pwd.getAbsolutePath());
>                    //this.jep = new Jep(this.testEval,
> "C:\\data\\m\\eclipse_workspace\\blobcenter\\cytoseg\\testing");
>                this.jep = new Jep();
>                //jep.setInteractive(false);
>                jep.set("testo", this);
>                System.out.println("Test get object: " +
> jep.getValue("testo"));
>
>                jep.eval("import os");
>                jep.eval("print os.getcwd()");
>                jep.eval("os.getcwd()");
>                jep.eval("import sys");
>                //jep.eval("sys.path.append('../..')");
>
>  //jep.eval("sys.path.append('C:\\data\\m\\eclipse_workspace\\\\blobcenter\\cytoseg')");
>                //jep.eval("sys.path.append('..')");
>                //jep.eval("sys.path");
>
>                //jep.eval("from detector import Detector");
>
>  jep.eval("sys.path.append('C:\\data\\m\\eclipse_workspace\\\\blobcenter\\cytoseg');import
> detector;print detector");
>                //jep.eval("import detector");
>
>                jep.eval("param = {}");
>                jep.eval("1;1");
>                //jep.eval("detector");
>
>                // each volume is a stack of 8 bit tiff images
>
>
>                // full input volume
>
>  jep.eval("param['originalImageFilePath']='/home/rgiuly/images/HPFcere_vol/HPF_rotated_tif/padding_removed/8bit'");
>
>                // training data image volume
>
>  jep.eval("param['voxelTrainingImageFilePath']='/home/rgiuly/images/HPFcere_vol/HPF_rotated_tif/three_compartment'");
>
>                // training data label, 0 for nonmitochondria pixels, 1 for
> mitochondria pixels
>                // this should have the exact same dimensions as
> param['voxelTrainingImageFilePath']
>
>  jep.eval("param['voxelTrainingLabelFilePath']='/home/rgiuly/images/HPFcere_vol/HPF_rotated_tif/three_compartment/membrane_label_for_three_compartments'");
>
>                // output volume
>
>  jep.eval("param['blobImageStackOutputFolder']='/home/rgiuly/temp/blobOutput'");
>
>                //jep.eval("detector.Detector(param)");
>
>
>
>
>
>
>            }
>            catch(Throwable t) {
>                System.out.println("Java caught error:");
>                t.printStackTrace();
>            }
>            finally {
>                System.out.println("**** close me");
>                if(jep != null)
>                    jep.close();
>            }
>    }
>
>    protected void finalize() {
>        System.out.println("test instance finalized, you should see this " +
>                           "if the reference counting worked...");
>    }
>
>    // get the jep used for this class
>    public Jep getJep() {
>        return this.jep;
>    }
>
>    public String toString() {
>        return "[Test2 Object]";
>    }
>
>
>
>
>    public static Class getStaticClass() {
>        return Thread.currentThread().getClass();
>    }
>
>    public static void main(String argv[]) throws Throwable {
>
>        new Test2().run();
>
>        System.gc();
>    }
>
> } // Test2
>
>
> import sys
>
> from component_detector import *
>
> class Detector:
>
>    def __init__(self, parameterDict):
>
>        dataIdentifier = 'hpf'
>        #mode = 'hpf_training'
>        mode = 'hpf_test'
>        target = 'mitochondria'
>        #target = 'vesicles'
>        #target = 'blankInnerCell'
>        #defaultStepNumber = 10
>        #defaultStepNumber = 3
>        defaultStepNumber = 7
>        #defaultStepNumber = 106
>        contourListClassificationMethod='bayes' # use for mitochondria
>        #contourListClassificationMethod='randomForest'
>
>        self.app = wx.PySimpleApp()
>        self.dataViewer = ClassificationControlsFrame(makeClassifyGUITree())
>        self.dataViewer.Show()
>
>        print "mode: %s" % mode
>
>        if len(sys.argv) < 2:
>            print "step not specified, using default step",
> defaultStepNumber
>            stepNumber = defaultStepNumber
>        else:
>            stepNumber = int(sys.argv[1])
>
>        # process the contours in a small dataset to learn about them
>        #if mode == 'hpf_training':
>
>        labelFilePaths = odict()
>        labelFilePaths['mitochondria'] = odict()
>        labelFilePaths['vesicles'] = odict()
>
>        labelFilePaths['mitochondria']['process_a1'] =
> "O:/images/Eric_07-10-09/process_traces/Working crop x116 y105 w362
> h315/set/a1"
>        labelFilePaths['mitochondria']['process_a2'] =
> "O:/images/Eric_07-10-09/process_traces/Working crop x116 y105 w362
> h315/set/a2"
>        labelFilePaths['mitochondria']['process_0'] =
> "O:/images/Eric_07-10-09/process_traces/Working crop x116 y105 w362
> h315/set/0"
>        labelFilePaths['mitochondria']['process_1'] =
> "O:/images/Eric_07-10-09/process_traces/Working crop x116 y105 w362
> h315/set/1"
>        labelFilePaths['mitochondria']['process_2'] =
> "O:/images/Eric_07-10-09/process_traces/Working crop x116 y105 w362
> h315/set/2"
>        labelFilePaths['vesicles']['all'] =
> "O:/images/HPFcere_vol/HPF_rotated_tif/vesicles/label/one_label/0_to_25"
>
>        self.contourTrainer = CellComponentDetector(
>            dataViewer=self.dataViewer,
>            dataIdentifier=mode,
>            target=target,
>
>  originalImageFilePath="O:/images/HPFcere_vol/HPF_rotated_tif/vesicles/input",
>            contourListClassificationMethod=contourListClassificationMethod,
>            #contourListExamplesIdentifier="contourPathFeatures" + "_" +
> target,
>            #contourListTrainingExamplesIdentifier="contourPathFeatures" +
> "_" + target,
>            contourListExamplesIdentifier="contourPathFeatures" + "_" +
> dataIdentifier,
>            contourListTrainingExamplesIdentifier="contourPathFeatures" +
> "_" + dataIdentifier,
>            voxelTrainingImageFilePath="data/sbfsem_training/images",
>            voxelTrainingLabelFilePath="data/sbfsem_training/label",
>            labelFilePaths=labelFilePaths[target])
>
>        self.contourTrainer.numberOfLayersToProcess = None
>        self.contourTrainer.numberOfThresholds = 1
>        self.contourTrainer.firstThreshold = 0.4
>        self.contourTrainer.thresholdStep = 0.2
>
>        # process the contours in a full dataset
>        #elif mode == 'hpf_test':
>
>        self.contourClassifier = CellComponentDetector(
>            dataViewer=self.dataViewer,
>            dataIdentifier=mode,
>            target=target,
>            originalImageFilePath=parameterDict['originalImageFilePath'],
>            contourListClassificationMethod=contourListClassificationMethod,
>            #contourListExamplesIdentifier="contourPathFeatures" + "_" +
> target,
>            #contourListTrainingExamplesIdentifier="contourPathFeatures" +
> "_" + target,
>            contourListExamplesIdentifier="contourPathFeatures" + "_" +
> dataIdentifier,
>            contourListTrainingExamplesIdentifier="contourPathFeatures" +
> "_" + dataIdentifier,
>
>  voxelTrainingImageFilePath=parameterDict['voxelTrainingImageFilePath'],
>
>  voxelTrainingLabelFilePath=parameterDict['voxelTrainingLabelFilePath'])
>
>        self.contourClassifier.voxelClassificationInputVolumeName =\
>            self.contourClassifier.blurredVolumeName
>        self.contourClassifier.voxelClassificationMethod = 'randomForest'
>
>        self.contourClassifier.blobImageStackOutputFolder =\
>            parameterDict['blobImageStackOutputFolder']
>
>        #self.contourClassifier.numberOfLayersToProcess = 10
>        self.contourClassifier.numberOfLayersToProcess = None
>
>        # for mitochondria
>        self.contourClassifier.numberOfThresholds = 4 #1 #4
>        self.contourClassifier.firstThreshold = 0.2 #0.4 #0.2
>
>        # not for mitochondria
>        #self.contourClassifier.numberOfThresholds = 1 #4
>        #self.contourClassifier.firstThreshold = 0.4 #0.2
>
>        self.contourClassifier.thresholdStep = 0.2
>
>
>    def run(self, runAllSteps=True):
>
>        if runAllSteps:
>
>            self.contourClassifier.runInitialize()
>            #self.contourClassifier.runStep(stepNumber)
>            self.contourClassifier.runPreclassificationFilter()
>            self.contourClassifier.runClassifyVoxels()
>            self.contourClassifier.runFindContours()
>            self.contourClassifier.runMakeContourLists()
>            self.contourClassifier.loadItemsForViewing()
>            self.contourClassifier.saveContourPathsToJinxFile()
>            self.contourClassifier.run3DShellActiveContourToDetect3DBlobs()
>            self.contourClassifier.runWrite3DBlobsVolume()
>            #self.contourClassifier.runContourProbabilityFilter()
>
>  #self.contourClassifier.run3DShellActiveContourToDetect3DBlobsHighProbabilityOnly()
>            #self.contourClassifier.runVoxelTestSteps()
>            #self.contourClassifier.runContourTestSteps()
>            #self.contourClassifier.runMainLoop()
>            self.app.MainLoop()
>
>        else:
>
>            #self.contourClassifier.runStep(stepNumber)
>            self.contourClassifier.runInitialize()
>            #self.contourClassifier.loadItemsForViewing()
>            #self.contourClassifier.calculateVoxelClassificationAccuracy()
>            #self.contourClassifier.runMainLoop()
>            self.contourClassifier.runFindContours()
>            self.app.MainLoop()
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Jepp-users mailing list
> Jep...@li...
> https://lists.sourceforge.net/lists/listinfo/jepp-users
>
>

[Jepp-users] Import problem

[Rick G. <rg...@gm...>]

Hello All,

I'm using jep.eval to append to sys.path and import a module.
The import is failing with this error:

Package not found: detector

As far as I can tell the file is in the sys.path and should load fine 
(detector.py is in the sys.path).

I'm using the Jepp windows binary on sourceforge
WindowsXP
Python 2.5.2


Any help is appreciated

The files I'm using to test are attached

-rick

Re: [Jepp-users] win64 numpy hangs during tests using embedded interpreter

[Mike J. <mrj...@mi...>]

Yeah, that's a common Windows problem. You'll have to match the
runtime of Java. A symptom of the runtime not matching is a crash on
any file access from within Python and a really unhelpful stack trace.

I think recent Java builds use vs 2005 but I'm not sure anymore. You
can use depends.exe to find out which C runtime Java depends on and go
from there. You're right, you'll need a Python compiled with the same
version. For a while the builds from python.org were using the same,
which made it a ton easier. I've not used recent Windows builds.

Of course, you won't be able to download/buy that version anywhere
that I've looked. There used to be free express versions but the links
have all been replaced by newer stuff. I'm no Windows guru, but I was
unable to find a switch to link to a different C runtime from a newer
VS. I ran into this recently, too. :-)

You also have to be sure to build a 'release' version or Windows gets
it all screwed up. I'm not sure why that really matters but I guess in
Windows that's a big deal for some crazy reason.

I don't really use Windows so I'm not much of a help. I really don't
understand how people put up with it. :-)

I'm sure you'd have a much easier time on Linux. You can always just
apt-get the appropriate compiler. But then I've never had any
compatibility problems. *shrugs*

On Mon, Jul 20, 2009 at 11:22 PM, Jon Wright <wr...@es...> wrote:
>
> Mike Johnson wrote:
> > I would use Python 2.5 and compile numpy for it. They may have a
> > configure test for compatibility. Or you're right, it may be necessary
> > to patch numpy. (Eh, you may also get away with defining macros...
> > maybe. :-)
> I'm still working on getting the right compiler to try python25 win64,
> should be possible, but it looks like I might need to cross compile on a
> different machine. Delving into this compiler story it looks like the
> reason python extensions have to be built with precise version of the MS
> compiler is to do with matching MS runtimes (msvcrt.dll or msvcrt80.dll
> or msvcrt90.dll). It seems one should try to avoid mixing C runtimes
> across dll boundaries:
>
> http://msdn.microsoft.com/en-gb/library/ms235460.aspx
>
> They mention heap managers (no unmatched malloc/free across boundaries),
> file handles and also environment vars.
>
> This leads me to wonder if jepp should be using the same C runtime as
> pythonXX.dll, or the java.exe, or does it imply we should match the jre
> and python.dll ?? If jepp only has to match python, that is a lot
> easier, as python.org are using at least three different versions of msvcrt!
>
> Cheers,
>
> Jon
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Jepp-users mailing list
> Jep...@li...
> https://lists.sourceforge.net/lists/listinfo/jepp-users
>

Re: [Jepp-users] win64 numpy hangs during tests using embedded interpreter

[Jon W. <wr...@es...>]

Mike Johnson wrote:
> I would use Python 2.5 and compile numpy for it. They may have a 
> configure test for compatibility. Or you're right, it may be necessary 
> to patch numpy. (Eh, you may also get away with defining macros... 
> maybe. :-)
I'm still working on getting the right compiler to try python25 win64, 
should be possible, but it looks like I might need to cross compile on a 
different machine. Delving into this compiler story it looks like the 
reason python extensions have to be built with precise version of the MS 
compiler is to do with matching MS runtimes (msvcrt.dll or msvcrt80.dll 
or msvcrt90.dll). It seems one should try to avoid mixing C runtimes 
across dll boundaries:

http://msdn.microsoft.com/en-gb/library/ms235460.aspx

They mention heap managers (no unmatched malloc/free across boundaries), 
file handles and also environment vars.

This leads me to wonder if jepp should be using the same C runtime as 
pythonXX.dll, or the java.exe, or does it imply we should match the jre 
and python.dll ?? If jepp only has to match python, that is a lot 
easier, as python.org are using at least three different versions of msvcrt!

Cheers,

Jon

Re: [Jepp-users] win64 numpy hangs during tests using embedded interpreter

[Jon W. <wr...@es...>]

Mike Johnson wrote:
> I'm not really sure what Python expects me to do here. Jep continues 
> to rely on sub interpreters so scripts run in their own environments. 
> I'm not aware of another way to do that.
I don't see it as a jepp bug but something to try to see about fixing in 
python. I'm stuck for the moment that I can't compile jepp, or numpy, 
for 2.5 64bit on windows as I don't seem to have the exactly right 
compiler. Will let you know if I get anywhere on testing that. 
Obviously, the 32 bit versions should run OK, but it is nice to have 
extra memory to work with.

Thanks

Jon

Re: [Jepp-users] win64 numpy hangs during tests using embedded interpreter

[Mike J. <mrj...@mi...>]

I'm not really sure what Python expects me to do here. Jep continues to rely
on sub interpreters so scripts run in their own environments. I'm not aware
of another way to do that.

And yet, modules depend on APIs that aren't compatible with sub
interpreters. So... kinda stuck. That's why I haven't yet devoted a lot of
attention to versions >2.6.

I would use Python 2.5 and compile numpy for it. They may have a configure
test for compatibility. Or you're right, it may be necessary to patch numpy.
(Eh, you may also get away with defining macros... maybe. :-)

On Sun, Jul 19, 2009 at 11:33 AM, Jon Wright <wr...@es...> wrote:

> Mike Johnson wrote:
> > Please don't cross post...
> Sorry! Thanks for the fast reponse.
> > What version of Python are you using? You might try an older version
> > of numpy that's not using those newer functions.
> The python is 2.6 for windows amd64 from python.org.
>
> It seems numpy had macros calling PyGILState_* for a long time now, at
> least since 1.0.4 and in their svn for 3 years. Somehow, the problem
> didn't surface and now many changes have come at once (win64, python2.6,
> numpy1.4) as older versions just don't exist for this platform. The
> amd64 binaries from the numpy folks usually crash during import, and
> don't even get as far as testing (built by gcc, versus home-made ones
> with msvc).
> > Unfortunately, since Jep is using the sub interpreters either all of
> > your modules have to use that API or they wouldn't be compatible, I
> > guess. You'd have to find versions that'd work together.
> It is not obvious how best to solve the problem in the longer term.
> There is more info on the issue here:
> http://www.linuxjournal.com/article/3641   ...   Several ideas come to
> mind:
>
> - patch jepp to only use a single interpreter at a time (by adding a
> lock). This probably doesn't make the problem go away anyway.
>
> - patch all the modules we use make sure they don't use these GILState
> calls. Scary.
>
> - have a version of python where the calls to PyGILState_* are OK for
> sub-interpreters. eg; jepython26.dll
>
> We would like to have multiple concurrent things going on, which seems
> to recommend the last option. The thought of patching and compiling
> python itself is making me pretty nervous. I think I need a reduced
> testcase to pin down the problem a little more clearly too.
>
> Any other ideas?
>
> Thanks!
>
> Jon
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Jepp-users mailing list
> Jep...@li...
> https://lists.sourceforge.net/lists/listinfo/jepp-users
>
>

Re: [Jepp-users] win64 numpy hangs during tests using embedded interpreter

[Jon W. <wr...@es...>]

Mike Johnson wrote:
> Please don't cross post...
Sorry! Thanks for the fast reponse.
> What version of Python are you using? You might try an older version 
> of numpy that's not using those newer functions.
The python is 2.6 for windows amd64 from python.org.

It seems numpy had macros calling PyGILState_* for a long time now, at 
least since 1.0.4 and in their svn for 3 years. Somehow, the problem 
didn't surface and now many changes have come at once (win64, python2.6, 
numpy1.4) as older versions just don't exist for this platform. The 
amd64 binaries from the numpy folks usually crash during import, and 
don't even get as far as testing (built by gcc, versus home-made ones 
with msvc).
> Unfortunately, since Jep is using the sub interpreters either all of 
> your modules have to use that API or they wouldn't be compatible, I 
> guess. You'd have to find versions that'd work together.
It is not obvious how best to solve the problem in the longer term. 
There is more info on the issue here:
http://www.linuxjournal.com/article/3641   ...   Several ideas come to mind:

- patch jepp to only use a single interpreter at a time (by adding a 
lock). This probably doesn't make the problem go away anyway.

- patch all the modules we use make sure they don't use these GILState 
calls. Scary.

- have a version of python where the calls to PyGILState_* are OK for 
sub-interpreters. eg; jepython26.dll

We would like to have multiple concurrent things going on, which seems 
to recommend the last option. The thought of patching and compiling 
python itself is making me pretty nervous. I think I need a reduced 
testcase to pin down the problem a little more clearly too.

Any other ideas?

Thanks!

Jon

Re: [Jepp-users] win64 numpy hangs during tests using embedded interpreter

[Mike J. <mrj...@mi...>]

Please don't cross post...

What version of Python are you using? You might try an older version of
numpy that's not using those newer functions.

Unfortunately, since Jep is using the sub interpreters either all of your
modules have to use that API or they wouldn't be compatible, I guess. You'd
have to find versions that'd work together.



On Sun, Jul 19, 2009 at 3:41 AM, Jon Wright <wr...@es...> wrote:

> Ah, bugger, found the answer and it is bad news, from
> http://docs.python.org/c-api/init.html
>
> "Note that the PyGILState_*() functions assume there is only one global
> interpreter (created automatically by Py_Initialize()
> <http://docs.python.org/c-api/init.html#Py_Initialize>). Python still
> supports the creation of additional interpreters (using
> Py_NewInterpreter()
> <http://docs.python.org/c-api/init.html#Py_NewInterpreter>), but mixing
> multiple interpreters and the PyGILState_*() API is unsupported."
>
> Since jepp is using Py_NewInterpreter() to allow many interpreters then
> it means it won't play nicely with extension modules who use PyGILState,
> like numpy. I can get around it by disabling threads in numpy
> altogether, but I'd rather have them working in these days of multi-core
> CPUs. Any ideas?
>
> Thanks,
>
> Jon
>
> Jon Wright wrote:
> > Hi There,
> >
> > I am trying to use numpy with jepp (from jepp.sourceforge.net) which is
> > an embedded python interpreter on win64 (vista). With the sourceforge
> > binaries I get intermittent crashes on import which went away when I
> > compiled svn trunk with msvc9. Suggests there is something incompatible
> > about them?
> >
> > Jepp has been compiled with Py_OptimizeFlag = 0 in pyembed_startup and
> > also removing  PyRun_SimpleString("__builtins__.__import__ =
> > jep.jimport\n");
> > from pyembed_thread_init (otherwise numpy is not found).
> >
> > Using the python.org win64 interpreter it seems to work fine, so I'm
> > looking for advice on how to debug the problem. Compiling with debugging
> > on (edit distutils/msvc9compiler.py as described here
> > http://mail.python.org/pipermail/python-list/2003-October/229543.html )
> > I found it is blocking here:
> >
> >
> >  >    umath.pyd!_error_handler(int method=2, _object *
> > errobj=0x000000004d774d88, char * errtype=0x000000004c06c280, int
> > retstatus=1, int * first=0x00000000024f8de0)  Line 69 +
> >
> >       ALLOW_C_API;
> >      000000004C04A783  call        qword ptr [__imp_PyGILState_Ensure
> > (4C0684C8h)]
> > ->   000000004C04A789  mov         dword ptr [__save__],eax
> >     switch(method) {
> >
> > Way up the call stack it seems jepp has done this to call numpy:
> >
> >     PyEval_AcquireLock();
> >     prevThread = PyThreadState_Swap(jepThread->tstate);
> > ...
> >     result = PyRun_String(str,  /* = numpy.test() */
> >                           Py_single_input,
> >                           jepThread->globals,
> >                           jepThread->globals);
> >
> > So it seems there is some sort of a threading problem. Does anyone have
> > any ideas?
> >
> > Thanks for any tips,
> >
> > Jon
> >
> >
> >
> ------------------------------------------------------------------------------
> > Enter the BlackBerry Developer Challenge
> > This is your chance to win up to $100,000 in prizes! For a limited time,
> > vendors submitting new applications to BlackBerry App World(TM) will have
> > the opportunity to enter the BlackBerry Developer Challenge. See full
> prize
> > details at: http://p.sf.net/sfu/Challenge
> > _______________________________________________
> > Jepp-users mailing list
> > Jep...@li...
> > https://lists.sourceforge.net/lists/listinfo/jepp-users
> >
>
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Jepp-users mailing list
> Jep...@li...
> https://lists.sourceforge.net/lists/listinfo/jepp-users
>
>

Re: [Jepp-users] win64 numpy hangs during tests using embedded interpreter

[Jon W. <wr...@es...>]

Ah, bugger, found the answer and it is bad news, from 
http://docs.python.org/c-api/init.html

"Note that the PyGILState_*() functions assume there is only one global 
interpreter (created automatically by Py_Initialize() 
<http://docs.python.org/c-api/init.html#Py_Initialize>). Python still 
supports the creation of additional interpreters (using 
Py_NewInterpreter() 
<http://docs.python.org/c-api/init.html#Py_NewInterpreter>), but mixing 
multiple interpreters and the PyGILState_*() API is unsupported."

Since jepp is using Py_NewInterpreter() to allow many interpreters then 
it means it won't play nicely with extension modules who use PyGILState, 
like numpy. I can get around it by disabling threads in numpy 
altogether, but I'd rather have them working in these days of multi-core 
CPUs. Any ideas?

Thanks,

Jon

Jon Wright wrote:
> Hi There,
>
> I am trying to use numpy with jepp (from jepp.sourceforge.net) which is 
> an embedded python interpreter on win64 (vista). With the sourceforge 
> binaries I get intermittent crashes on import which went away when I 
> compiled svn trunk with msvc9. Suggests there is something incompatible 
> about them?
>
> Jepp has been compiled with Py_OptimizeFlag = 0 in pyembed_startup and 
> also removing  PyRun_SimpleString("__builtins__.__import__ = 
> jep.jimport\n");
> from pyembed_thread_init (otherwise numpy is not found).
>
> Using the python.org win64 interpreter it seems to work fine, so I'm 
> looking for advice on how to debug the problem. Compiling with debugging 
> on (edit distutils/msvc9compiler.py as described here 
> http://mail.python.org/pipermail/python-list/2003-October/229543.html ) 
> I found it is blocking here:
>
>
>  >    umath.pyd!_error_handler(int method=2, _object * 
> errobj=0x000000004d774d88, char * errtype=0x000000004c06c280, int 
> retstatus=1, int * first=0x00000000024f8de0)  Line 69 +
>
>       ALLOW_C_API;
>      000000004C04A783  call        qword ptr [__imp_PyGILState_Ensure 
> (4C0684C8h)]
> ->   000000004C04A789  mov         dword ptr [__save__],eax
>     switch(method) {
>
> Way up the call stack it seems jepp has done this to call numpy:
>
>     PyEval_AcquireLock();
>     prevThread = PyThreadState_Swap(jepThread->tstate);
> ...
>     result = PyRun_String(str,  /* = numpy.test() */
>                           Py_single_input,
>                           jepThread->globals,
>                           jepThread->globals);
>
> So it seems there is some sort of a threading problem. Does anyone have 
> any ideas?
>
> Thanks for any tips,
>
> Jon
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Jepp-users mailing list
> Jep...@li...
> https://lists.sourceforge.net/lists/listinfo/jepp-users
>   

[Jepp-users] win64 numpy hangs during tests using embedded interpreter

[Jon W. <wr...@es...>]

Hi There,

I am trying to use numpy with jepp (from jepp.sourceforge.net) which is 
an embedded python interpreter on win64 (vista). With the sourceforge 
binaries I get intermittent crashes on import which went away when I 
compiled svn trunk with msvc9. Suggests there is something incompatible 
about them?

Jepp has been compiled with Py_OptimizeFlag = 0 in pyembed_startup and 
also removing  PyRun_SimpleString("__builtins__.__import__ = 
jep.jimport\n");
from pyembed_thread_init (otherwise numpy is not found).

Using the python.org win64 interpreter it seems to work fine, so I'm 
looking for advice on how to debug the problem. Compiling with debugging 
on (edit distutils/msvc9compiler.py as described here 
http://mail.python.org/pipermail/python-list/2003-October/229543.html ) 
I found it is blocking here:


 >    umath.pyd!_error_handler(int method=2, _object * 
errobj=0x000000004d774d88, char * errtype=0x000000004c06c280, int 
retstatus=1, int * first=0x00000000024f8de0)  Line 69 +

      ALLOW_C_API;
     000000004C04A783  call        qword ptr [__imp_PyGILState_Ensure 
(4C0684C8h)]
->   000000004C04A789  mov         dword ptr [__save__],eax
    switch(method) {

Way up the call stack it seems jepp has done this to call numpy:

    PyEval_AcquireLock();
    prevThread = PyThreadState_Swap(jepThread->tstate);
...
    result = PyRun_String(str,  /* = numpy.test() */
                          Py_single_input,
                          jepThread->globals,
                          jepThread->globals);

So it seems there is some sort of a threading problem. Does anyone have 
any ideas?

Thanks for any tips,

Jon

Re: [Jepp-users] how to acess enum of a java class from python side

[Mike J. <mrj...@mi...>]

Hi,

All enums are instances of java.lang.Enum, so to Jep it really doesn't
make much difference. I added this to Test.java:
    public TestEnum getEnum() {
        return TestEnum.One;
    }
    public static enum TestEnum {
        One,
        Two
    }

And ran the python script (have to use findClass here since the module
is also called 'jep'):
$ java -cp jep.jar jep.Run console.py
>>> from jep import *
>>> test = findClass('jep.Test')()
>>> test.getEnum()
<PyJobject object at 0x404d7bb8>
>>> print test.getEnum()
One
>>> print test.getEnum().name()
One

Or going the other way, instantiating from Python:
>>> from java.lang import Enum
>>> TestEnum = findClass('jep.Test$TestEnum')
>>> Enum.valueOf(TestEnum, 'One')
<PyJobject object at 0x7ffce80bc0c0>
>>> print Enum.valueOf(TestEnum, 'One')
One


So it's just like using any other object.

Mike

On Mon, May 18, 2009 at 9:33 PM, lizhu hua <li...@gm...> wrote:
> Dear Jep users,
>
> Jep provided easy ways of access java field and method from python side.
>
> But when I tried to acess an enum, I got exceptions.
>
> Then I looked at the source code, there is no way to access a class's enums.
>
> Did anyone ever try ot enhance jep to provide a way of access java enums?
>
> Or is there any workaround?
>
> Thanks.
>
>
> Linda
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables
> unlimited royalty-free distribution of the report engine
> for externally facing server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Jepp-users mailing list
> Jep...@li...
> https://lists.sourceforge.net/lists/listinfo/jepp-users
>
>

[Jepp-users] how to acess enum of a java class from python side

[lizhu h. <li...@gm...>]

Dear Jep users,

Jep provided easy ways of access java field and method from python side.

But when I tried to acess an enum, I got exceptions.

Then I looked at the source code, there is no way to access a class's enums.

Did anyone ever try ot enhance jep to provide a way of access java enums?

Or is there any workaround?

Thanks.


Linda

Re: [Jepp-users] switching off Python optimisation

[Andy G. <and...@es...>]

Hi,

thanks for this tip. I have commented out the line in question and 
everything still works. I also get error messages if imports do not 
work. I will leave it like this. I don't know enough to judge if by 
commenting this line out I am running a risk of things crashing 
somewhere else down the line. I have also switched off optimisation to 
get scipy to load on windows. Works like a charm now. Thanks again for a 
very useful software.

Andy

Mike Johnson wrote:
> Hi,
>
> I keep getting complaints about the import failing, but I'm not able to
> reproduce them.
>
> Possibly whatever package you're using is also trying to do something
> funky with the import function. I had a lot of trouble getting the
> import hooks to work from C. You can see the comment I left in
> frustration in pyembed.c. :-)
>
> I heard that'd been cleaned up in 2.6 so it might be worthwhile to
> update jepp to that version. But there have been a number of api
> changes, too.
>
> Maybe in the short term it'd be best to rename the original import
> function and try using that from your code?
>
> Look for the line:
>     PyRun_SimpleString("__builtins__.__import__ = jep.jimport\n");
>
>
> On Fri, 2008-11-21 at 15:04 +0100, Andy Gotz wrote:
>   
>> Hi,
>>
>> I would like to know what is the best way to switch off Python 
>> optimisation in the jep interpreter. I see the optimisation is set to 2 
>> in the embedded interpreter. The optimisation is causing me problems I 
>> think because it is hiding certain error messages and beacause it means 
>> jep does not have the same behaviour as the python console. This makes 
>> it difficult to diagnose problems. In our project we are making heavy 
>> use of jepp to call python code from Java and it works very well most of 
>> the time (thanks again for this great piece of code) but when we our 
>> module imports fail we do not know why and we spend a lot of time 
>> looking. Ideally I would like a way of switching optimisation off/on 
>> dynamically. If this is not possible I will have to compile my own 
>> private version of jep and modify the code. BTW how to compile jep on 
>> Windows ?
>>
>> Thanks for any help you can give us
>>
>> Andy
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Jepp-users mailing list
>> Jep...@li...
>> https://lists.sourceforge.net/lists/listinfo/jepp-users
>>     

Re: [Jepp-users] switching off Python optimisation

[Mike J. <mrj...@mi...>]

Hi,

I keep getting complaints about the import failing, but I'm not able to
reproduce them.

Possibly whatever package you're using is also trying to do something
funky with the import function. I had a lot of trouble getting the
import hooks to work from C. You can see the comment I left in
frustration in pyembed.c. :-)

I heard that'd been cleaned up in 2.6 so it might be worthwhile to
update jepp to that version. But there have been a number of api
changes, too.

Maybe in the short term it'd be best to rename the original import
function and try using that from your code?

Look for the line:
    PyRun_SimpleString("__builtins__.__import__ = jep.jimport\n");


On Fri, 2008-11-21 at 15:04 +0100, Andy Gotz wrote:
> Hi,
> 
> I would like to know what is the best way to switch off Python 
> optimisation in the jep interpreter. I see the optimisation is set to 2 
> in the embedded interpreter. The optimisation is causing me problems I 
> think because it is hiding certain error messages and beacause it means 
> jep does not have the same behaviour as the python console. This makes 
> it difficult to diagnose problems. In our project we are making heavy 
> use of jepp to call python code from Java and it works very well most of 
> the time (thanks again for this great piece of code) but when we our 
> module imports fail we do not know why and we spend a lot of time 
> looking. Ideally I would like a way of switching optimisation off/on 
> dynamically. If this is not possible I will have to compile my own 
> private version of jep and modify the code. BTW how to compile jep on 
> Windows ?
> 
> Thanks for any help you can give us
> 
> Andy
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Jepp-users mailing list
> Jep...@li...
> https://lists.sourceforge.net/lists/listinfo/jepp-users

Re: [Jepp-users] switching off Python optimisation

[Jon W. <wr...@es...>]

Hi Andy,

Here a dos batch file that used to work under windows.

Cheers,

Jon

D:\wright\build_software\jepp>more build_jepp_mingw.bat

set JEPP_HOME=D:\wright\build_software\jepp\jepp\jep-2.2
set JAVA_HOME="c:\Program Files\Java\jdk1.6.0_02"
set JAVAC=%JAVA_HOME%\bin\javac
set JAVAH=%JAVA_HOME%\bin\javah
set JAVACOPT=-deprecation -classpath src/
set JAR=%JAVA_HOME%\bin\jar
set JAROPTS=-u0f


:JAVAC

REM Make the Java classes

cd %JEPP_HOME%

%JAVAC% %JAVACOPT% src/jep/python/PyObject.java
%JAVAC% %JAVACOPT% src/jep/python/PyModule.java
%JAVAC% %JAVACOPT% src/jep/python/PyClass.java
%JAVAC% %JAVACOPT% src/jep/Jep.java
%JAVAC% %JAVACOPT% src/jep/Run.java
%JAVAC% %JAVACOPT%;./ext/bsf.jar src/jep/BSFJepEngine.java
%JAVAC% %JAVACOPT% src/jep/Test.java
%JAVAC% %JAVACOPT% src/jep/JepException.java
%JAVAC% %JAVACOPT% src/jep/ClassList.java
%JAVAC% %JAVACOPT% src/jep/JepScriptEngine.java
%JAVAC% %JAVACOPT% src/jep/JepScriptEngineFactory.java
%JAVAC% %JAVACOPT% src/jep/InvocationHandler.java
%JAVAC% %JAVACOPT% src/jep/Proxy.java
%JAVAC% %JAVACOPT% src/jep/Util.java

:JAVAH
REM Make the C header files (depend on classes)

cd %JEPP_HOME%
%JAVAH% -o src/jep/python/jep_object.h -classpath src/ jep.python.PyObject
%JAVAH% -o src/jep/jep.h -classpath src/ jep.Jep
%JAVAH% -o src/jep/invocationhandler.h -classpath src/ jep.InvocationHandler

REM Make the jar file
:JAR

cd %JEPP_HOME%\src
set JARFILE=%JEPP_HOME%\jep.jar
%JAR% -cfm %JARFILE% manifest 
META-INF/services/javax.script.ScriptEngineFactory

set CLASSES=jep/python/PyObject.class jep/python/PyModule.class 
jep/python/PyClass.class jep/Jep.class jep/JepException.
class jep/Test.class jep/Run.class jep/InvocationHandler.class 
jep/Proxy.class  jep/Util.class jep/ClassList.class

%JAR% %JAROPTS% %JARFILE% %CLASSES%

cd %JEPP_HOME%

:C
cd %JEPP_HOME%\src\jep
set PYHOME=c:\python25
set CSOURCE=python/jep_object.c jep.c system.h pyembed.c util.c 
pyjmethod.c pyjobject.c pyjclass.c pyjfield.c pyjarray.c
  invocationhandler.c
set COBJS=jep_object.o jep.o pyembed.o util.o pyjmethod.o pyjobject.o 
pyjclass.o pyjfield.o pyjarray.o invocationhandler
.o
set CINC=-I%JAVA_HOME%/include -I%JAVA_HOME%/include/win32 
-I%PYHOME%/include -I%JEPP_HOME%/src/jep
set LIBS=-L%PYHOME%/libs -lpython24
set COPT=-Wall -D_JNI_IMPLEMENTATION_ -Wl,--kill-at -mno-cygwin
set CLIB=-shared

REM Use gcc to compile c
gcc %COPT% %CINC% %LIBS% %CLIB% -Wl,--kill-at -c %CSOURCE% 2> gcc_errors.log
REM But g++ to link symbols as __imp__ rather than _imp__ ... ahem.
g++ %COPT% %COBJS% %CINC% %LIBS% %CLIB% -Wl,--kill-at 
%JAVA_HOME%/lib/jvm.lib -o jep.dll 2> gpp_errors2.log
REM gvim errors.log
REM gvim errors2.log
more errors2.log

:TEST

:END


Andy Gotz wrote:
> Hi,
> 
> I would like to know what is the best way to switch off Python 
> optimisation in the jep interpreter. I see the optimisation is set to 2 
> in the embedded interpreter. The optimisation is causing me problems I 
> think because it is hiding certain error messages and beacause it means 
> jep does not have the same behaviour as the python console. This makes 
> it difficult to diagnose problems. In our project we are making heavy 
> use of jepp to call python code from Java and it works very well most of 
> the time (thanks again for this great piece of code) but when we our 
> module imports fail we do not know why and we spend a lot of time 
> looking. Ideally I would like a way of switching optimisation off/on 
> dynamically. If this is not possible I will have to compile my own 
> private version of jep and modify the code. BTW how to compile jep on 
> Windows ?
> 
> Thanks for any help you can give us
> 
> Andy
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Jepp-users mailing list
> Jep...@li...
> https://lists.sourceforge.net/lists/listinfo/jepp-users

[Jepp-users] switching off Python optimisation

[Andy G. <and...@es...>]

Hi,

I would like to know what is the best way to switch off Python 
optimisation in the jep interpreter. I see the optimisation is set to 2 
in the embedded interpreter. The optimisation is causing me problems I 
think because it is hiding certain error messages and beacause it means 
jep does not have the same behaviour as the python console. This makes 
it difficult to diagnose problems. In our project we are making heavy 
use of jepp to call python code from Java and it works very well most of 
the time (thanks again for this great piece of code) but when we our 
module imports fail we do not know why and we spend a lot of time 
looking. Ideally I would like a way of switching optimisation off/on 
dynamically. If this is not possible I will have to compile my own 
private version of jep and modify the code. BTW how to compile jep on 
Windows ?

Thanks for any help you can give us

Andy

[Jepp-users] how to recover the AssertionError message

[Andy G. <and...@es...>]

Hi,

I am trying to recover the AssertionError message from jep generated by 
calling assert in python. I only seem to be able to recover the 
ErrorValue generated by raise in python. Any ideas ?

Thanks

Andy

Re: [Jepp-users] Another import problem

[Alban H. <alb...@go...>]

Continuing my monologue,

I omitted to set variable LD_PRELOAD to /usr/lib/libpython2.5.so . If
I had took 2 sec to read the README carefully, I would have saved 2
hours.

My bad,

Alban



2008/10/6 Alban Hessler <alb...@go...>:
> Hi,
>
> I am trying to use Jepp in order to run some Python script from within Java.
>
> The script I run imports some modules, some from the python
> distribution, other ones custom made (for example, TOSSIM).
>
> Somehow, I get an exception when importing modules, for example random:
>
> ===================================================
>
> jep.eval("from random import *");
>
> # /usr/lib/python2.5/random.pyo matches /usr/lib/python2.5/random.py
> import random # precompiled from /usr/lib/python2.5/random.pyo
> # /usr/lib/python2.5/warnings.pyo matches /usr/lib/python2.5/warnings.py
> import warnings # precompiled from /usr/lib/python2.5/warnings.pyo
> # /usr/lib/python2.5/linecache.pyo matches /usr/lib/python2.5/linecache.py
> import linecache # precompiled from /usr/lib/python2.5/linecache.pyo
> dlopen("/usr/lib/python2.5/lib-dynload/math.so", 2);
> jep.JepException: <type 'exceptions.ImportError'>: jep.JepException:
> Package not found: random
>
> =========================================================
>
> According to the python verbose, it seems it finds random.py..
>
> I run the java program with admin priv (otherwise jepp can't create
> the pyo files). I have Jepp 2.3 and python 2.5.
>
> Thank you in advance for your help,
>
> Alban Hessler
>

Re: [Jepp-users] Another import problem

[Alban H. <alb...@go...>]

Thanks lunch, I noticed it always happen after a dlopen call. Will
investigate further.

/Alban

2008/10/6 Alban Hessler <alb...@go...>:
> Hi,
>
> I am trying to use Jepp in order to run some Python script from within Java.
>
> The script I run imports some modules, some from the python
> distribution, other ones custom made (for example, TOSSIM).
>
> Somehow, I get an exception when importing modules, for example random:
>
> ===================================================
>
> jep.eval("from random import *");
>
> # /usr/lib/python2.5/random.pyo matches /usr/lib/python2.5/random.py
> import random # precompiled from /usr/lib/python2.5/random.pyo
> # /usr/lib/python2.5/warnings.pyo matches /usr/lib/python2.5/warnings.py
> import warnings # precompiled from /usr/lib/python2.5/warnings.pyo
> # /usr/lib/python2.5/linecache.pyo matches /usr/lib/python2.5/linecache.py
> import linecache # precompiled from /usr/lib/python2.5/linecache.pyo
> dlopen("/usr/lib/python2.5/lib-dynload/math.so", 2);
> jep.JepException: <type 'exceptions.ImportError'>: jep.JepException:
> Package not found: random
>
> =========================================================
>
> According to the python verbose, it seems it finds random.py..
>
> I run the java program with admin priv (otherwise jepp can't create
> the pyo files). I have Jepp 2.3 and python 2.5.
>
> Thank you in advance for your help,
>
> Alban Hessler
>

[Jepp-users] Another import problem

[Alban H. <alb...@go...>]

Hi,

I am trying to use Jepp in order to run some Python script from within Java.

The script I run imports some modules, some from the python
distribution, other ones custom made (for example, TOSSIM).

Somehow, I get an exception when importing modules, for example random:

===================================================

jep.eval("from random import *");

# /usr/lib/python2.5/random.pyo matches /usr/lib/python2.5/random.py
import random # precompiled from /usr/lib/python2.5/random.pyo
# /usr/lib/python2.5/warnings.pyo matches /usr/lib/python2.5/warnings.py
import warnings # precompiled from /usr/lib/python2.5/warnings.pyo
# /usr/lib/python2.5/linecache.pyo matches /usr/lib/python2.5/linecache.py
import linecache # precompiled from /usr/lib/python2.5/linecache.pyo
dlopen("/usr/lib/python2.5/lib-dynload/math.so", 2);
jep.JepException: <type 'exceptions.ImportError'>: jep.JepException:
Package not found: random

=========================================================

According to the python verbose, it seems it finds random.py..

I run the java program with admin priv (otherwise jepp can't create
the pyo files). I have Jepp 2.3 and python 2.5.

Thank you in advance for your help,

Alban Hessler

Re: [Jepp-users] Jepp problem

[Mike J. <mrj...@mi...>]

Shoot, I don't remember. :-)

Looking at the code it looks like it does the right thing. Is it not
working?

On Thu, 2008-07-03 at 11:31 +0200, Uwe Schmitt wrote:
> Hi,
> 
> is 
> http://sourceforge.net/mailarchive/message.php?msg_name=47C2ACD7.6010400%40mineway.de
> solved ? There was no posting on jepp-users concerning this issue.
> 
> Greetings, Uwe
> 

Re: [Jepp-users] Create personalized objects for Java

[Mike J. <mrj...@mi...>]

Hi,

You could just import java.util.Map and build java objects for storage.

Or, I like to keep complicated data structures abstracted into classes
or modules and provide access though getter functions. I find sharing
data structures in my designs is usually a bad idea.

Depends how much you need to use it in python, I guess. If I hear people
clamoring for it I could add some code to return python objects for a
few python object protocols. I don't think it'd be too hard, just a lot
of files to touch and time to do it.

On Thu, 2008-07-03 at 11:20 +0200, Edoardo Tosca wrote:
> Hi all.
> 
> Invoking some Python modules from Java i saw that lists and dict
> returned from Python are mapped in Java as Strings.
> And that is for me a "problem" because i have to use the data inside
> lists and dicts; so one possible, but bad solution is to parse the
> string and recreate a Java object.
> 
> Mike told me that if i have a list i can map it in Java as an array,
> using jarray, and that's ok. I have only to rewrite some python code
> and that is not a big problem.
> but if i have a Python module that returns something like the dict
> below or some other complex data structures:
> {
>  key = [ val1, val2, val3],
>  key2 = [val21, val22, val23],
>  key3 {
>           key31 = val31,
>           key32 = val32,
>           key3n = val3n,
>           }
> }
> 
> How can i map it?
> Do you think is a possible solution if i write some C modules that
> maps my personal objects?
> 
> thank you all
> 
> 
> -- 
> Edoardo Tosca
> Mail: edoardo.tosca@{autistici.org, gmail.com}
> Skype: edoardotosca
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________ Jepp-users mailing list Jep...@li... https://lists.sourceforge.net/lists/listinfo/jepp-users

[Jepp-users] Jepp problem

[Uwe S. <usc...@mi...>]

Hi,

is 
http://sourceforge.net/mailarchive/message.php?msg_name=47C2ACD7.6010400%40mineway.de
solved ? There was no posting on jepp-users concerning this issue.

Greetings, Uwe

-- 
Dr. rer. nat. Uwe Schmitt
F&E Mathematik
 
mineway GmbH
Science Park 2
D-66123 Saarbrücken
 
Telefon: +49 (0)681 8390 5334
Telefax: +49 (0)681 830 4376
 
usc...@mi...
www.mineway.de
 
Geschäftsführung: Dr.-Ing. Mathias Bauer
Amtsgericht Saarbrücken HRB 12339