From: Tom W. <to...@ss...> - 2009-02-09 16:35:01
|
(Sorry if this has been covered before -- I searched, but found no other comments/questions.) We just moved an application to Jython 2.2 ....and found that JNumeric is quite broken. One cannot even say "from Numeric import *" without getting an Exception. Any ideas and help appreciated. Here's the Excpetion (abreviated): >>> from Numeric import * Traceback (innermost last): File "<console>", line 1, in ? at JNumeric.PyMultiarray.<init>(PyMultiarray.java:73) ........ java.lang.NoSuchMethodError: java.lang.NoSuchMethodError: org.python.core.PySequence.<init>(Lorg/python/core/PyClass;)V The issues appear to be mostly (if not all) in the PyMultiarray class, referencing signatures that have changed since 2.1. Here's the output from an attempt to recompile the package: C:\Temp\jnumeric\src\>javac -cp \jython2.2b2\jython.jar;. *.java JNumeric\*.java PyMultiarray.java:29: JNumeric.PyMultiarray is not abstract and does not override abstract method pyget(int) in org.python.core.PySequence public class PyMultiarray extends PySequence { ^ PyMultiarray.java:73: cannot find symbol symbol : constructor PySequence(org.python.core.PyClass) location: class org.python.core.PySequence super(__class__); ^ PyMultiarray.java:904: cannot find symbol symbol : method getValue() location: class org.python.core.PyObject return new int [] {asarray(o).__getitem__(Py.Ellipsis).__int__().getValue()}; ^ PyMultiarray.java:913: cannot find symbol symbol : method getValue() location: class org.python.core.PyObject intArray[i] = o.__getitem__(i).__int__().getValue(); ^ PyMultiarray.java:1428: list has protected access in org.python.core.PySequenceL ist PyObject indices[] = (pyIndices instanceof PyTuple) ? ((PyTuple)pyIndices).list : new PyObject[] {pyIndices}; ^ PyMultiarray.java:1428: incompatible types found : java.lang.Object required: org.python.core.PyObject[] PyObject indices[] = (pyIndices instanceof PyTuple) ? ((PyTuple)pyIndices).list : new PyObject[] {pyIndices}; ^ -- Tom Whittaker University of Wisconsin-Madison Space Science & Engineering Center (SSEC) Cooperative Institute for Meteorological Satellite Studies (CIMSS) 1225 W. Dayton Street Madison, WI 53706 USA ph: +1 608 262 2759 |
From: Jim B. <jb...@zy...> - 2009-02-10 04:03:29
|
Tom, For this problem, you may want to look at the tracker for JNumeric, apparently a quick fix for the 2.2beta was determined. This might be applicable to your situation: http://sourceforge.net/tracker/index.php?func=detail&aid=1734031&group_id=49106&atid=455128 Unfortunately, JNumeric to my knowledge is no longer supported. The last email on its mailing list was in 2004, on which someone said they "Have $ to support" :), but that still wasn't enough. But that's not the end of it. Along with a number of other people, I'm personally planning on revisiting numerical Jython issues, around a port of NumPy -- let's call it NumJy. In particular, we would like to address how we can effectively use many cores concurrently and work with extremely large data sets (so from the start, support for NetCDF, DAP, and HDF). It simply makes sense to take the premier high-level programming language for scientific computing and support it on the Java platform. Kickoff for NumJy work will be at PyCon, so if you're interested, please catch us there! - Jim On Mon, Feb 9, 2009 at 9:34 AM, Tom Whittaker <to...@ss...> wrote: > (Sorry if this has been covered before -- I searched, but found no > other comments/questions.) We just moved an application to Jython 2.2 > ....and found that JNumeric is quite broken. One cannot even say > "from Numeric import *" without getting an Exception. Any ideas and > help appreciated. > > Here's the Excpetion (abreviated): > > >>> from Numeric import * > Traceback (innermost last): > File "<console>", line 1, in ? > at JNumeric.PyMultiarray.<init>(PyMultiarray.java:73) > ........ > java.lang.NoSuchMethodError: java.lang.NoSuchMethodError: > org.python.core.PySequence.<init>(Lorg/python/core/PyClass;)V > > > The issues appear to be mostly (if not all) in the PyMultiarray class, > referencing signatures that have changed since 2.1. Here's the output > from an attempt to recompile the package: > > C:\Temp\jnumeric\src\>javac -cp \jython2.2b2\jython.jar;. *.java > JNumeric\*.java > > PyMultiarray.java:29: JNumeric.PyMultiarray is not abstract and does > not override abstract method pyget(int) in org.python.core.PySequence > public class PyMultiarray extends PySequence { > ^ > PyMultiarray.java:73: cannot find symbol > symbol : constructor PySequence(org.python.core.PyClass) > location: class org.python.core.PySequence > super(__class__); > ^ > PyMultiarray.java:904: cannot find symbol > symbol : method getValue() > location: class org.python.core.PyObject > return new int [] > {asarray(o).__getitem__(Py.Ellipsis).__int__().getValue()}; > ^ > PyMultiarray.java:913: cannot find symbol > symbol : method getValue() > location: class org.python.core.PyObject > intArray[i] = o.__getitem__(i).__int__().getValue(); > ^ > PyMultiarray.java:1428: list has protected access in > org.python.core.PySequenceL > ist > PyObject indices[] = (pyIndices instanceof PyTuple) ? > ((PyTuple)pyIndices).list : new PyObject[] {pyIndices}; > ^ > PyMultiarray.java:1428: incompatible types > found : java.lang.Object > required: org.python.core.PyObject[] > PyObject indices[] = (pyIndices instanceof PyTuple) ? > ((PyTuple)pyIndices).list : new PyObject[] {pyIndices}; > ^ > > -- > Tom Whittaker > University of Wisconsin-Madison > Space Science & Engineering Center (SSEC) > Cooperative Institute for Meteorological Satellite Studies (CIMSS) > 1225 W. Dayton Street > Madison, WI 53706 USA > ph: +1 608 262 2759 > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code > to > build responsive, highly engaging applications that combine the power of > local > resources and data with the reach of the web. Download the Adobe AIR SDK > and > Ajax docs to start building applications today- > http://p.sf.net/sfu/adobe-com > _______________________________________________ > Jython-users mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-users > -- Jim Baker jb...@zy... |
From: Frank W. <fwi...@gm...> - 2009-02-10 18:54:42
|
On Mon, Feb 9, 2009 at 11:03 PM, Jim Baker <jb...@zy...> wrote: > Kickoff for NumJy work will be at PyCon, so if you're interested, please > catch us there! Cool! -- Jim, would you mind adding a blurb to http://us.pycon.org/2009/sprints/projects/jython/ about NumJy? -Frank |
From: Tom W. <to...@ss...> - 2009-02-10 16:09:22
|
Thanks, Jim. I guess we're a little behind in updating. > For this problem, you may want to look at the tracker for JNumeric, > apparently a quick fix for the 2.2beta was determined. This might be > applicable to your situation: > http://sourceforge.net/tracker/index.php?func=detail&aid=1734031&group_id=49106&atid=455128 I'll have to dig into the source code for 2.2 and see what the issues are. I note that the poster didn't make their changes available. Plus, I note even more issues with Jython 2.5... > But that's not the end of it. Along with a number of other people, I'm > personally planning on revisiting numerical Jython issues, around a port of > NumPy -- let's call it NumJy. That's great news (catchy name, too). Years ago, we integrated Jython into VisAD to make a great scripting language for manipulating and displaying data. We have found, however, that scientists don't alway want to think of their data in such a "rich" manner -- sometimes they just think of it as "an array"....hence, the use of JNumeric as well. > In particular, we would like to address how we > can effectively use many cores concurrently and work with extremely large > data sets (so from the start, support for NetCDF, DAP, and HDF). It simply > makes sense to take the premier high-level programming language for > scientific computing and support it on the Java platform. I wholeheartedly agree. We use NetCDF for everything we can -- and now that version 4 supports HDF and lots of other file formats, it is great to have just one API to deal with (now all we have to do is get the data providers to use conventions like CF). > Kickoff for NumJy work will be at PyCon, so if you're interested, please > catch us there! Sorry I will miss you -- but I do strongly support this....and look forward to the release of NumJy!! Thanks again for writing, tom |