Menu
▾
▴
jython-dev
|
From: Mike R. <jyt...@bl...> - 2002-08-09 20:01:08
|
Hey Everyone,
I have a couple of questions.
1) I have been asked by my employer to modify the jython interface to by
default treat all numbers as floats instead of ints. I think I have
figured out how to do this.
In python.jjt change these lines
around line 802 of the file
| (
t=<DECNUMBER> { jjtThis.setInteger(t.image, 10); }
)#Int
to
| (
t=<DECNUMBER> { jjtThis.setFloat(t.image); }
)#Float
This seems to run through jjtree and javacc fine. But here comes my second
question.
2) When ever I try to compile the .java files that are generated I get
many missing symbol errors this happens with jython 2.1 and the CVS build
20020809. I don't believe this is due to my changes as the build fails on
a clean version of the tree as well. I have tried compiling by hand and
the build.xml with the CVS build, I have tried including the javacc zip
file of classes as part of my classpath in the compile as well.
I'm using jdk 1.3.1_04 (but have also tried 1.4.0_01) with javacc 2.1. If
anyone has any ideas on how I can make this work or another way to change
the default number format to float please let me know.
Thanks
--Mike
|
|
From: Manoj & A. T. <man...@ho...> - 2003-04-17 12:30:22
|
Getting the following error when I try to run the command:
java -classpath . jython-21
ERROR:
java.lang.ClassFormatError: jython-21
java.lang.Class =
java.lang.ClassLoader.defineClass0(java.lang.String, byte[], int, int, =
java.
security.ProtectionDomain)
native code
java.lang.Class =
java.lang.ClassLoader.defineClass(java.lang.String, byte[], int, int, =
java.s
ecurity.ProtectionDomain)
ClassLoader.java:493
java.lang.Class =
java.security.SecureClassLoader.defineClass(java.lang.String, byte[], =
int, i
nt, java.security.CodeSource)
SecureClassLoader.java:111
java.lang.Class =
java.net.URLClassLoader.defineClass(java.lang.String, sun.misc.Resource)
URLClassLoader.java:248
java.lang.Class =
java.net.URLClassLoader.access$100(java.net.URLClassLoader, =
java.lang.String
, sun.misc.Resource)
URLClassLoader.java:56
java.lang.Object java.net.URLClassLoader$1.run()
URLClassLoader.java:195
java.lang.Object =
java.security.AccessController.doPrivileged(java.security.PrivilegedExcep=
ti
onAction, java.security.AccessControlContext)
native code
java.lang.Class =
java.net.URLClassLoader.findClass(java.lang.String)
URLClassLoader.java:188
java.lang.Class =
java.lang.ClassLoader.loadClass(java.lang.String, boolean)
ClassLoader.java:299
java.lang.Class =
sun.misc.Launcher$AppClassLoader.loadClass(java.lang.String, boolean)
Launcher.java:286
java.lang.Class =
java.lang.ClassLoader.loadClass(java.lang.String)
ClassLoader.java:255
java.lang.Class =
java.lang.ClassLoader.loadClassInternal(java.lang.String)
ClassLoader.java:315 |
|
From: Oti <oh...@ya...> - 2003-04-23 19:53:40
|
[ Manoj & Anu Turlapati ] > Getting the following error when I try to run the command: > java -classpath . jython-21 > > > ERROR: > java.lang.ClassFormatError: jython-21 > java.lang.Class Either download jython-21.class again (check the size in bytes), or download and start jython_21.class. There are systems which do not like a '-' in the class name. Best wishes, Oti. __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com |
|
From: Anand C. <str...@gm...> - 2005-10-18 12:53:05
|
hi,
I found a bug!
public methods of a package private class are not accessible through
its public subclass. This happens both in 2.1 and 2.2a1 versions.
// package private class
class A {
public void f() {
System.out.println("f");
}
}
// public class extending from a package private class
public class B extends A {
public void g() {
System.out.println("g");
}
}
This is the output i got when i tried to access in jython.
>>> import B
>>> dir(B)
['g']
>>> b = B()
>>> b.g()
g
>>> b.f()
Traceback (innermost last):
File "<console>", line 1, in ?
AttributeError: 'javainstance' object has no attribute 'f'
# but there are available in java.
>>> for m in B.getMethods(): print m.getName()
g
f
hashCode
getClass
wait
wait
wait
equals
notify
notifyAll
toString
Shall i submit this a bug in the project page.
can try to debug this??
- anand
|
|
From: Frank W. <fwi...@gm...> - 2005-10-18 13:19:04
|
> Shall i submit this a bug in the project page. Please do. can try to debug this?? Even better! - anand Thanks, Frank |
|
From: Petr G. <pet...@gm...> - 2007-02-28 09:56:12
|
Hello. I feel i have encountered a bug. With latest beta 2.2 I have created db connection object as follows: dbConn = zxJDBC.connect(uri, username, password, driver) However subsequent dir(dbConn) causes following exception AttributeError: 'list' object has no attribute 'keys' at org.python.core.Py.AttributeError(Unknown Source) at org.python.core.PyObject.noAttributeError(Unknown Source) at org.python.core.PyObject.__getattr__(Unknown Source) at org.python.core.PyObject.invoke(Unknown Source) at org.python.core.PyDictionary.dict_update(Unknown Source) at org.python.core.PyDictionary.update(Unknown Source) at org.python.core.PyObject.addKeys(Unknown Source) at org.python.core.PyObject.__rawdir__(Unknown Source) at org.python.core.PyObject.__dir__(Unknown Source) at org.python.core.__builtin__.dir(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.python.core.PyReflectedFunction.__call__(Unknown Source) at org.python.core.PyReflectedFunction.__call__(Unknown Source) at org.python.core.PyObject.__call__(Unknown Source) at org.python.pycode._pyx0.f$0(src/py/main.py:107) at org.python.pycode._pyx0.call_function(src/py/main.py) at org.python.core.PyTableCode.call(Unknown Source) at org.python.core.PyCode.call(Unknown Source) at org.python.core.Py.runCode(Unknown Source) at org.python.core.__builtin__.execfile_flags(Unknown Source) at org.python.util.PythonInterpreter.execfile(Unknown Source) Should I post this bug to bugtracker? -- Petr Gladkikh |
|
From: Charlie G. <cha...@gm...> - 2007-02-28 17:08:56
|
On 2/28/07, Petr Gladkikh <pet...@gm...> wrote: > I feel i have encountered a bug. > > Should I post this bug to bugtracker? Yep! Charlie |
|
From: Philip J. <pj...@gr...> - 2007-09-03 00:30:12
|
Charles Nutter has made some major headway on implementing chmod/ chown on JRuby (and that's just the beginning) via JNA's trunk build: http://headius.blogspot.com/2007/09/java-native-access-jruby-true- posix.html JNA could let Jython implement a full suite of POSIX functions (like Finn Bock's jnios or jtux), but without the headaches of JNI/ compiling native code. JNA appears to "just work" out of the box for the most popular platforms (win32, osx, linux, solaris, freebsd), so we could include this potential suite with our normal Jython distribution, by just shipping it with the JNA jar. It's licensed under the LGPL. That sounds compatible enough; would the Jython/PSF lawyers approve? =] -- Philip Jenvey |
|
From: Frank W. <fwi...@gm...> - 2007-09-03 14:20:27
|
On 9/2/07, Philip Jenvey <pj...@gr...> wrote: > Charles Nutter has made some major headway on implementing chmod/ > chown on JRuby (and that's just the beginning) via JNA's trunk build: > > http://headius.blogspot.com/2007/09/java-native-access-jruby-true- > posix.html > > JNA could let Jython implement a full suite of POSIX functions (like > Finn Bock's jnios or jtux), but without the headaches of JNI/ > compiling native code. JNA appears to "just work" out of the box for > the most popular platforms (win32, osx, linux, solaris, freebsd), so > we could include this potential suite with our normal Jython > distribution, by just shipping it with the JNA jar. This does sound very promising. > It's licensed under the LGPL. That sounds compatible enough; would > the Jython/PSF lawyers approve? =] I know the answer is easy for GPL (no) and the answer is easy for APL and other BSD style licenses (yes), but the LGPL might be a gray area. Since we can ship the jar separately, this is probably worth trying out -- we could implement os.py similarly to the way CPython does it so that the runtime imports what it can based on the os is on, and we could make jna optional the way we do with readline. This way, if jna is present then we get chmod, etc, but if it is not we don't (just like CPython does it) If we make it pluggable the way we do with readline, I'd say we can just see where it goes and give it a try. If it turns out that we can't distribute jna.jar -- we can hopefully have simple instructions (much simpler than the readline instructions since there is no compile step). Also, if it is written in a pluggable style, we might eventually find a BSD licensed jar that we could use instead so that distribution ability is unambiguous. -Frank |
|
From: Lino M. <l.m...@gm...> - 2007-09-03 16:25:24
|
2007/9/3, Frank Wierzbicki <fwi...@gm...>: > If we make it pluggable the way we do with readline, I'd say we can > just see where it goes and give it a try. If it turns out that we > can't distribute jna.jar [...] I think that the GNU LGPL allows to include the JNA sources, .class and/or .jar files directly within the Jython installer, without releasing Jython itself under the LGPL (of course you must still comply with the other LGPL conditions: include somewhere the text of the LGPL itself, give the JNA source to the users that want it and a few minor details). AFAIK the main point of the LGPL is that the end user must be able to use the application with modified versions of the LGPLed library. Since Jython users have the full Jython source code, this can be easily accomplished (recompile everything), even if you mix Jython and JNA classes inside the same jar. More infos: http://www.gnu.org/licenses/lgpl-java.html And the LGPL itself: http://www.gnu.org/copyleft/lesser.html But, of course, the only way to be really sure is to ask directly to the JNA developers! Regards, -- Lino Mastrodomenico E-mail: l.m...@gm... |
|
From: Frank W. <fwi...@gm...> - 2007-09-03 16:27:51
|
On 9/3/07, Frank Wierzbicki <fwi...@gm...> wrote: > If we make it pluggable the way we do with readline, I'd say we can > just see where it goes and give it a try. If it turns out that we > can't distribute jna.jar -- we can hopefully have simple instructions > (much simpler than the readline instructions since there is no compile > step). Also, if it is written in a pluggable style, we might > eventually find a BSD licensed jar that we could use instead so that > distribution ability is unambiguous. So I took another look at JNA, and it looks like it will need to get distributed with some os-specific code. While this doesn't kill the idea -- I think it puts it squarely into the area of being an optional plugin, since there will need to be one for each os. -Frank |
|
From: Wayne M. <wme...@gm...> - 2007-09-03 17:18:14
|
Frank Wierzbicki wrote: > On 9/3/07, Frank Wierzbicki <fwi...@gm...> wrote: > >> If we make it pluggable the way we do with readline, I'd say we can >> just see where it goes and give it a try. If it turns out that we >> can't distribute jna.jar -- we can hopefully have simple instructions >> (much simpler than the readline instructions since there is no compile >> step). Also, if it is written in a pluggable style, we might >> eventually find a BSD licensed jar that we could use instead so that >> distribution ability is unambiguous. > So I took another look at JNA, and it looks like it will need to get > distributed with some os-specific code. While this doesn't kill the > idea -- I think it puts it squarely into the area of being an optional > plugin, since there will need to be one for each os. JNA supports and comes with binaries for most of the operating systems the Sun JDK supports - linux/i386, linux/amd64, win32, macosx/ppc, macosx/i386, solaris/x86, solaris/sparc, solaris/sparc64, freebsd/i386. Windows/amd64 and solaris/amd64 are the only exceptions I can think of. But regardless of that, you probably still want to make it pluggable so when something better comes along (which always happens in software development) you can switch to that. Other options are using C/Invoke http://www.nongnu.org/cinvoke/index.html or libffi and writing enough java/JNI to interface with it. When called from jython, the JNA API is pretty narrow - only a handful of methods. You could abstract them, use a JNA backend initially, then switch to a BSD-licensed backend when you have one ready. |
|
From: Frank W. <fwi...@gm...> - 2007-09-03 17:34:51
|
On 9/3/07, Wayne Meissner <wme...@gm...> wrote: > > > Frank Wierzbicki wrote: > > On 9/3/07, Frank Wierzbicki <fwi...@gm...> wrote: > JNA supports and comes with binaries for most of the operating systems > the Sun JDK supports - linux/i386, linux/amd64, win32, macosx/ppc, > macosx/i386, solaris/x86, solaris/sparc, solaris/sparc64, freebsd/i386. > Windows/amd64 and solaris/amd64 are the only exceptions I can think of. > > But regardless of that, you probably still want to make it pluggable so > when something better comes along (which always happens in software > development) you can switch to that. > > Other options are using C/Invoke > http://www.nongnu.org/cinvoke/index.html or libffi and writing enough > java/JNI to interface with it. > > When called from jython, the JNA API is pretty narrow - only a handful > of methods. You could abstract them, use a JNA backend initially, then > switch to a BSD-licensed backend when you have one ready. Thanks for the extra information -- this convinces me more that this should be written in a plugin style. Philip: does any of this deter you from giving it a try? I would love to see better support for os calls in Jython -- and JRuby can be a nice prototype for us in these areas... -Frank |
|
From: Philip J. <pj...@gr...> - 2007-09-04 17:48:59
|
On Sep 3, 2007, at 10:34 AM, Frank Wierzbicki wrote: > On 9/3/07, Wayne Meissner <wme...@gm...> wrote: >> >> >> Frank Wierzbicki wrote: >>> On 9/3/07, Frank Wierzbicki <fwi...@gm...> wrote: >> JNA supports and comes with binaries for most of the operating >> systems >> the Sun JDK supports - linux/i386, linux/amd64, win32, macosx/ppc, >> macosx/i386, solaris/x86, solaris/sparc, solaris/sparc64, freebsd/ >> i386. >> Windows/amd64 and solaris/amd64 are the only exceptions I can >> think of. >> >> But regardless of that, you probably still want to make it >> pluggable so >> when something better comes along (which always happens in software >> development) you can switch to that. >> >> Other options are using C/Invoke >> http://www.nongnu.org/cinvoke/index.html or libffi and writing enough >> java/JNI to interface with it. >> >> When called from jython, the JNA API is pretty narrow - only a >> handful >> of methods. You could abstract them, use a JNA backend initially, >> then >> switch to a BSD-licensed backend when you have one ready. > Thanks for the extra information -- this convinces me more that this > should be written in a plugin style. > > Philip: does any of this deter you from giving it a try? I would love > to see better support for os calls in Jython -- and JRuby can be a > nice prototype for us in these areas... Nope, making it pluggable sounds like a good idea anyway. To define "native" methods in JNA, you write an interface defining all the method prototypes, and your interface has to subclass their Library interface. We can define those "native" methods in our own Interface that doesn't subclass JNA's Library interface, which I believe a cinvoke version, for example, could also utilize. Then our actual JNA Library interface would extend their Library and our own: interface PosixModule { int chmod(String filename, int mask); } interface JNAPosixModule extends PosixModule, com.sun.jna.Library { // The super interfaces provide all that's needed } PosixModule posix = (PosixModule)com.sun.jna.Native.loadLibrary("c", JNAPosixModule.class); -- Philip Jenvey |
|
From: John E. <joh...@ya...> - 2009-01-12 19:03:25
|
please remove me from your mailing list |
|
From: Tim P. <ti...@ho...> - 2001-01-12 02:58:43
|
> I wonder if the JPython has changed to Jython. Please let me > know as soon as possible so that I can change our company > brochure. Our web site is Exolink.com We are currently using > JPython to read XML to convert our database format . Thank you > very much. JPython is a project hosted at CNRI, although it no longer appears to be under active development. Jython is a project that spun off of JPython, is hosted at SourceForge, and is under active development. So, no, JPython hasn't changed. If you're using JPython, you should probably say JPython. If you switched to Jython, then Jython. Note that JPython and Jython may (or may not) merge again someday. |
Thanks for helping keep SourceForge clean.
X