Menu
▾
▴
jython-bugs — Private bug notification list. Do not post to this list.
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(34) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(33) |
Feb
(21) |
Mar
(7) |
Apr
(9) |
May
(15) |
Jun
(14) |
Jul
(60) |
Aug
(31) |
Sep
(4) |
Oct
(38) |
Nov
(69) |
Dec
(67) |
| 2002 |
Jan
(15) |
Feb
(13) |
Mar
(30) |
Apr
(9) |
May
(19) |
Jun
(8) |
Jul
(15) |
Aug
(7) |
Sep
(41) |
Oct
(29) |
Nov
(7) |
Dec
(8) |
| 2003 |
Jan
(4) |
Feb
(5) |
Mar
(3) |
Apr
(11) |
May
(17) |
Jun
(8) |
Jul
(48) |
Aug
(2) |
Sep
(5) |
Oct
(12) |
Nov
(11) |
Dec
(5) |
| 2004 |
Jan
(8) |
Feb
(4) |
Mar
(3) |
Apr
(3) |
May
(5) |
Jun
(1) |
Jul
(10) |
Aug
(2) |
Sep
(5) |
Oct
(7) |
Nov
|
Dec
(3) |
| 2005 |
Jan
|
Feb
(12) |
Mar
(3) |
Apr
(4) |
May
(1) |
Jun
(19) |
Jul
(12) |
Aug
(20) |
Sep
(8) |
Oct
(27) |
Nov
(12) |
Dec
(8) |
| 2006 |
Jan
(4) |
Feb
(8) |
Mar
(9) |
Apr
(9) |
May
(195) |
Jun
(16) |
Jul
(13) |
Aug
(77) |
Sep
(52) |
Oct
(17) |
Nov
(74) |
Dec
(88) |
| 2007 |
Jan
(171) |
Feb
(184) |
Mar
(54) |
Apr
(91) |
May
(109) |
Jun
(65) |
Jul
(171) |
Aug
(193) |
Sep
(155) |
Oct
(79) |
Nov
(66) |
Dec
(86) |
| 2008 |
Jan
(52) |
Feb
(13) |
Mar
(14) |
Apr
(9) |
May
(12) |
Jun
(25) |
Jul
(26) |
Aug
(25) |
Sep
(24) |
Oct
(28) |
Nov
(21) |
Dec
(30) |
| 2009 |
Jan
(40) |
Feb
(11) |
Mar
(30) |
Apr
(37) |
May
(28) |
Jun
(30) |
Jul
(31) |
Aug
(31) |
Sep
(32) |
Oct
(16) |
Nov
(10) |
Dec
(21) |
| 2010 |
Jan
(19) |
Feb
(16) |
Mar
(23) |
Apr
(15) |
May
(10) |
Jun
(9) |
Jul
(17) |
Aug
(12) |
Sep
(11) |
Oct
(10) |
Nov
(9) |
Dec
(14) |
| 2011 |
Jan
(10) |
Feb
(11) |
Mar
(13) |
Apr
(18) |
May
(10) |
Jun
(12) |
Jul
(21) |
Aug
(12) |
Sep
(12) |
Oct
(17) |
Nov
(15) |
Dec
(4) |
| 2012 |
Jan
(6) |
Feb
(10) |
Mar
(27) |
Apr
(8) |
May
(29) |
Jun
(34) |
Jul
(12) |
Aug
(13) |
Sep
(6) |
Oct
(8) |
Nov
(14) |
Dec
(10) |
| 2013 |
Jan
(8) |
Feb
(10) |
Mar
(15) |
Apr
(7) |
May
(14) |
Jun
(7) |
Jul
(9) |
Aug
(8) |
Sep
(12) |
Oct
(9) |
Nov
(3) |
Dec
(3) |
| 2014 |
Jan
(5) |
Feb
(3) |
Mar
(4) |
Apr
(13) |
May
(23) |
Jun
(19) |
Jul
(9) |
Aug
(13) |
Sep
(18) |
Oct
(10) |
Nov
(9) |
Dec
(8) |
| 2015 |
Jan
(21) |
Feb
(13) |
Mar
(33) |
Apr
(43) |
May
(17) |
Jun
(8) |
Jul
(8) |
Aug
(5) |
Sep
(22) |
Oct
(12) |
Nov
(18) |
Dec
(12) |
| 2016 |
Jan
(7) |
Feb
(25) |
Mar
(10) |
Apr
(6) |
May
(7) |
Jun
(4) |
Jul
(6) |
Aug
(5) |
Sep
(6) |
Oct
(7) |
Nov
(5) |
Dec
(4) |
| 2017 |
Jan
(5) |
Feb
(16) |
Mar
(14) |
Apr
(9) |
May
(13) |
Jun
(6) |
Jul
(12) |
Aug
(9) |
Sep
(4) |
Oct
(13) |
Nov
(10) |
Dec
(4) |
| 2018 |
Jan
(2) |
Feb
(2) |
Mar
(6) |
Apr
(12) |
May
(16) |
Jun
(6) |
Jul
(4) |
Aug
(3) |
Sep
(6) |
Oct
(7) |
Nov
(4) |
Dec
(8) |
| 2019 |
Jan
(6) |
Feb
(1) |
Mar
(6) |
Apr
(6) |
May
(6) |
Jun
(2) |
Jul
(4) |
Aug
(5) |
Sep
(5) |
Oct
(5) |
Nov
(12) |
Dec
(6) |
| 2020 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(7) |
May
(6) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(4) |
Oct
(1) |
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: nobody <no...@so...> - 2001-02-28 20:34:50
|
Bugs #404525, was updated on 2001-02-26 23:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=404525&group_id=12867 Category: Library Group: None Status: Closed Priority: 5 Submitted By: Gert Lehmann Assigned to: Nobody/Anonymous Summary: ConfigParser.remove_option method fails Initial Comment: If you try to use the remove_option() method in the ConfigParser class, then you get an error message like this: File "...\jython-2.0\Lib\ConfigParser.py", line 364, in remove_option NameError: key This is beacause the remove_option() method referes to an unknown variable called "key" - if you changes this to "option" the method works fine. ---------------------------------------------------------------------- Comment By: Finn Bock Date: 2001-02-28 12:36 Message: Logged In: YES user_id=4201 Most of library is copied from CPython2.0 including ConfigParser.py. In CPython this bug have been fixed in the current CVS and the new version will be included automaticly when Jython-2.1 is released. Nothing further is needed on our part to solve this bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=404525&group_id=12867 |
|
From: nobody <no...@so...> - 2001-02-27 07:28:02
|
Artifact #404525, was updated on 2001-02-26 23:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=404525&group_id=12867 Category: Library Group: None Status: Open Priority: 5 Submitted By: Gert Lehmann Assigned to: Nobody/Anonymous Summary: ConfigParser.remove_option method fails Initial Comment: If you try to use the remove_option() method in the ConfigParser class, then you get an error message like this: File "...\jython-2.0\Lib\ConfigParser.py", line 364, in remove_option NameError: key This is beacause the remove_option() method referes to an unknown variable called "key" - if you changes this to "option" the method works fine. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=404525&group_id=12867 |
|
From: nobody <no...@so...> - 2001-02-25 16:30:56
|
Artifact #229958, was updated on 2001-01-24 11:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=229958&group_id=12867 Category: Installer Group: None Status: Closed Priority: 5 Submitted By: Jaejun Lee Assigned to: Nobody/Anonymous Summary: no interface to change drive in "change path dialog box" Initial Comment: When I try to change the path on "install in", the dialog box doesn't show any interface to change drive. ---------------------------------------------------------------------- Comment By: Finn Bock Date: 2001-02-25 08:32 Message: Logged In: YES user_id=4201 The fact that the installer was written on a unix platform shows. There the author had no use for a change drive GUI feature. As a workaround you can edit the drive letter in the "File name:" field. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=229958&group_id=12867 |
|
From: nobody <no...@so...> - 2001-02-25 16:19:41
|
Artifact #229320, was updated on 2001-01-18 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=229320&group_id=12867 Category: Core Group: None Status: Closed Priority: 5 Submitted By: Mike Hostetler Assigned to: Nobody/Anonymous Summary: can't delete file when file is left open Initial Comment: This is related to a bug I submitted a month or so ago. You guys rightfully closed it, but I finally nailed down what was causing it. There should be at least be a note somewhere in the documentation about it. I'm not sure it can be fixed. I know, technically, you should always close your files. But what if you don't? In CPython, if you don't close your files when opening them in a function, the garbage collector closes it for you. But there has been some inconsisencies in how Jython behaves. Here is my test: import os,tempfile def writeFile(fileName,str): file = open(fileName,"w") file.write(str) # I'm not closing the file on purpose if __name__ == '__main__': fileName = "bugtest.tmp" str = "Frank Burns eats worms\n" writeFile(fileName,str) os.remove(fileName) This works fine on CPython on Windows 2000 and Solaris as well as Jython 2.0 on Solaris, but not with Jython 2.0 on Windows 2000. On Windows 2000, it gives this exception: Traceback (innermost last): File "bug.py", line 16, in ? File "C:\jython-2.0\Lib\javaos.py", line 44, in remove OSError: [Errno 0] couldn't delete file: 'bugtest.tmp' In reality, I think the behavior on Windows 2000 is the correct one, but the choice is up to you. We did some research here, and this really does go down to the C level. Following is an example, which we compiled with gcc on Solaris, gcc on Cygwin, and lc (the line compiler with Visual Studio). #include <stdio.h> int main() { FILE *f; f=fopen("tempfile","r"); if(f != NULL) { printf("File is Open\nAttempting to Delete..."); } if(remove("tempfile")!=0) { printf("Delete Failed\n"); } else { printf("Delete Successful (Solaris Sucks)\n"); } } With both versions of gcc, this file was deleted. With lc, the delete failed. (Obviously, the file "tempfile" needs to be created before running this). ---------------------------------------------------------------------- Comment By: Finn Bock Date: 2001-02-25 08:21 Message: Logged In: YES user_id=4201 In reallity we have no choice on the matter. The file is kept open due to the GC nature of java and the operating systems are defining whether deleting an open file is allowed. As such the different behaviour is here to stay. ---------------------------------------------------------------------- Comment By: Mike Hostetler Date: 2001-01-18 19:28 Message: I'm obsessed - can't you tell?? Actually, here is an article that describes the Unix side of it . .. . it explains the IEEE standard of unlinking files. http://www.itl.nist.gov/div897/staff/barkley/titleissues/node26.html ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=229320&group_id=12867 |
|
From: nobody <no...@so...> - 2001-02-25 15:38:54
|
Artifact #229252, was updated on 2001-01-18 07:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=229252&group_id=12867 Category: Jythonc compiler Group: None Status: Closed Priority: 5 Submitted By: Brian Ericson Assigned to: Nobody/Anonymous Summary: try/except/else statements improperly compiled Initial Comment: #!/usr/bin/python if __name__ == "__main__": try: raise "me" except: print "In except..." else: print "In else..." The above should execute the except block only, and does when run by jython: [core 737] /opt/jython-2.0/jython test.py In except... However, when byte-compiled using jythonc and run by Java, both the except and the else block are executed: [core 742] java -classpath ./test.jar:/opt/jython-2.0/jython.jar test In except... In else... ---------------------------------------------------------------------- Comment By: Finn Bock Date: 2001-02-25 07:39 Message: Logged In: YES user_id=4201 Fixed in SimpleCompiler.py 2.13; ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=229252&group_id=12867 |
|
From: nobody <no...@so...> - 2001-02-25 15:38:01
|
Artifact #229252, was updated on 2001-01-18 07:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=229252&group_id=12867 Category: Jythonc compiler Group: None Status: Open Priority: 5 Submitted By: Brian Ericson Assigned to: Nobody/Anonymous Summary: try/except/else statements improperly compiled Initial Comment: #!/usr/bin/python if __name__ == "__main__": try: raise "me" except: print "In except..." else: print "In else..." The above should execute the except block only, and does when run by jython: [core 737] /opt/jython-2.0/jython test.py In except... However, when byte-compiled using jythonc and run by Java, both the except and the else block are executed: [core 742] java -classpath ./test.jar:/opt/jython-2.0/jython.jar test In except... In else... ---------------------------------------------------------------------- Comment By: Finn Bock Date: 2001-02-25 07:39 Message: Logged In: YES user_id=4201 Fixed in SimpleCompiler.py 2.13; ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=112867&aid=229252&group_id=12867 |
|
From: <no...@so...> - 2001-02-23 20:24:24
|
Bug #122819, was updated on 2000-Nov-18 11:11
Here is a current snapshot of the bug.
Project: Jython
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Submitted by: bckfnn
Assigned to : nobody
Summary: Multi-level Java method overriding fails
Details: Consider the following script --
==========
#!/usr/bin/env jpython
from java.util import Date
class SubDate(Date):
def toString(self): return 'SubDate.toString() -> ' +
Date.toString(self)
class SubSubDate(SubDate):
def toString(self): return 'SubSubDate.toString() -> ' +
SubDate.toString(self)
print Date().toString()
print SubDate().toString()
print SubSubDate().toString()
==========
The output is as follows --
==========
Fri Oct 22 12:53:58 CDT 1999
SubDate.toString() -> Fri Oct 22 12:53:58 CDT 1999
Traceback (innermost last):
File "test.py", line 12, in ?
File "test.py", line 8, in toString
File "test.py", line 6, in toString
java.lang.StackOverflowError
at org.python.core.PyClass.lookupGivingClass(PyClass.java:137)
at
org.python.core.PyJavaClass.lookupGivingClass(PyJavaClass.java:673)
at org.python.core.PyClass.lookup(PyClass.java:155)
at
org.python.util.PythonInterpreter.execfile(PythonInterpreter.java:132)
< ... >
at org.python.proxies.SubDate$0.toString(Unknown Source)
at org.python.proxies.SubSubDate$1.super__toString(Unknown
Source)
at
org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:156)
< ... >
at org.python.proxies.SubDate$0.toString(Unknown Source)
at org.python.proxies.SubSubDate$1.super__toString(Unknown
Source)
at
org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:156)
< ... >
at org.python.util.jpython.main(jpython.java:123)
==========
What seems to happen is that SubSubDate.toString() calls
SubDate.toString()
calls Date.toString() ... which then turns around and calls the
derived-most
implementation of toString() all over again, ie, the one at SubSubDate.
This
goes on and on until the above stack overflow occurs.
Note that with only one level of inheritance, ie, calling
SubDate.toString(),
it worked correctly with no problems.
I originally observed this problem with overriding
java.lang.Thread.interrupt(),
so the above simplified test case has been reproduced elsewhere.
I can reproduce this with Sun Solaris JDK versions 1.3, 1.2.2 and 1.1.8.
Follow-Ups:
Date: 2001-Feb-23 12:26
By: bckfnn
Comment:
Ian Castleden's fix added to the interpreter. Same fix must also be added
to jythonc. The bug report will closed when that is done.
-------------------------------------------------------
Date: 2001-Feb-19 01:26
By: ianzsk
Comment:
Any python subclass that contains a java class as a parent
will have a proxy created for it. Also, in the PyReflectionFunction
__call__
there is code to "translate" unbound methods to bound "super__" methods.
However the "self" argument passed to this method is null so that
the superclass (Here SubDate) again looks for a "super__" method ( viz:
super__super__toString()!) This of course fails and so the
call drops through.
I can't really make heads or tails of this code so I have no idea where the
"bug"
is (altough the search for "super__super__" is surely wrong). I also think
the fact
that the SubSubDate class has a java proxyClass created for it (--because
SubDate
has a proxyClass--- see PyClass.init()) somehow contributes to the
recursion.
-------------------------------------------------------
Date: 2000-Dec-16 12:52
By: pedronis
Comment:
Just checked that the nasty bug is still there.
It should be solved for sure, at least the
stack overflow.
Not analyzed yet.
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=122819&group_id=12867
|
|
From: <no...@so...> - 2001-02-19 09:25:10
|
Bug #122819, was updated on 2000-Nov-18 11:11
Here is a current snapshot of the bug.
Project: Jython
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Submitted by: bckfnn
Assigned to : nobody
Summary: Multi-level Java method overriding fails
Details: Consider the following script --
==========
#!/usr/bin/env jpython
from java.util import Date
class SubDate(Date):
def toString(self): return 'SubDate.toString() -> ' +
Date.toString(self)
class SubSubDate(SubDate):
def toString(self): return 'SubSubDate.toString() -> ' +
SubDate.toString(self)
print Date().toString()
print SubDate().toString()
print SubSubDate().toString()
==========
The output is as follows --
==========
Fri Oct 22 12:53:58 CDT 1999
SubDate.toString() -> Fri Oct 22 12:53:58 CDT 1999
Traceback (innermost last):
File "test.py", line 12, in ?
File "test.py", line 8, in toString
File "test.py", line 6, in toString
java.lang.StackOverflowError
at org.python.core.PyClass.lookupGivingClass(PyClass.java:137)
at
org.python.core.PyJavaClass.lookupGivingClass(PyJavaClass.java:673)
at org.python.core.PyClass.lookup(PyClass.java:155)
at
org.python.util.PythonInterpreter.execfile(PythonInterpreter.java:132)
< ... >
at org.python.proxies.SubDate$0.toString(Unknown Source)
at org.python.proxies.SubSubDate$1.super__toString(Unknown
Source)
at
org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:156)
< ... >
at org.python.proxies.SubDate$0.toString(Unknown Source)
at org.python.proxies.SubSubDate$1.super__toString(Unknown
Source)
at
org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:156)
< ... >
at org.python.util.jpython.main(jpython.java:123)
==========
What seems to happen is that SubSubDate.toString() calls
SubDate.toString()
calls Date.toString() ... which then turns around and calls the
derived-most
implementation of toString() all over again, ie, the one at SubSubDate.
This
goes on and on until the above stack overflow occurs.
Note that with only one level of inheritance, ie, calling
SubDate.toString(),
it worked correctly with no problems.
I originally observed this problem with overriding
java.lang.Thread.interrupt(),
so the above simplified test case has been reproduced elsewhere.
I can reproduce this with Sun Solaris JDK versions 1.3, 1.2.2 and 1.1.8.
Follow-Ups:
Date: 2001-Feb-19 01:26
By: ianzsk
Comment:
Any python subclass that contains a java class as a parent
will have a proxy created for it. Also, in the PyReflectionFunction
__call__
there is code to "translate" unbound methods to bound "super__" methods.
However the "self" argument passed to this method is null so that
the superclass (Here SubDate) again looks for a "super__" method ( viz:
super__super__toString()!) This of course fails and so the
call drops through.
I can't really make heads or tails of this code so I have no idea where the
"bug"
is (altough the search for "super__super__" is surely wrong). I also think
the fact
that the SubSubDate class has a java proxyClass created for it (--because
SubDate
has a proxyClass--- see PyClass.init()) somehow contributes to the
recursion.
-------------------------------------------------------
Date: 2000-Dec-16 12:52
By: pedronis
Comment:
Just checked that the nasty bug is still there.
It should be solved for sure, at least the
stack overflow.
Not analyzed yet.
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=122819&group_id=12867
|
|
From: <no...@so...> - 2001-02-16 18:14:18
|
Bug #132462, was updated on 2001-Feb-14 19:27
Here is a current snapshot of the bug.
Project: Jython
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: ianzsk
Assigned to : nobody
Summary: jython invokes interface "method" instead actual method
Details: This bug seems similar to(but not the same as) bug #122847
Given the following Java code:
//-----------------------------
package aa;
interface Named {
String getName();
}
public class bug implements Named {
public bug() {}
public String getName() { return "name"; }
}
//--------
The following jython (Jython 2.0 on java1.3.0 (JIT: null)) script invokes
an IllegalAccessException
#!/usr/bin/env jython
from aa import bug
b=bug()
b.getName()
# same problem with bean property : b.name
Possible resolution:
----------------------------
Assuming that creating PyJavaClass Objects for interfaces is a requirement
for
jython to work properly (!), the short circuit in
PyJavaClass.addPropery() method viz:
// If this adds nothing over old property, do nothing
if ((prop.getMethod == null || oldProp.getMethod != null)
&&
(prop.setMethod == null || oldProp.setMethod != null))
should be replace with:
boolean nogetOverride=(oldProp.getMethod != null &&
!Modifier.isAbstract(oldProp.getMethod.getModifiers()) );
boolean nosetOverride =(oldProp.setMethod != null &&
!Modifier.isAbstract(oldProp.setMethod.getModifiers()) );
if ((prop.getMethod == null || nogetOverride )
&&
(prop.setMethod == null || nogetOverride ) )
{
set = false;
}
// Add old get/set methods to current prop
// Handles issues with private classes
if (nogetOverride) {
prop.getMethod = oldProp.getMethod;
}
if (nosetOverride) {
prop.setMethod = oldProp.setMethod;
}
i.e. override if it is abstract.
I also changed the code at the bottom of ReflectedArgs.compareTo() method
to:
// For static methods, use the child's version
// For instance methods, use the parent's version
if (!isStatic && ( other.declaringClass.getModifiers() &
(Modifier.INTERFACE))==0 ) replace = !replace;
These two changes at least fix the problem above, but are not maybe the
most general solution.
Follow-Ups:
Date: 2001-Feb-16 10:11
By: bckfnn
Comment:
Fixed in PyJavaClass.java: 2.33;
-------------------------------------------------------
Date: 2001-Feb-15 22:58
By: ianzsk
Comment:
OK, OK forget all of the above "fixes". this bug is the same type of
bug
as demonstrated in BUG#122847
my workaround is to add a method to PyJavaClass (see below) that returns
only the public interfaces of a class; and then change __init_bases to:
Class[] interfaces=getAccessibleInterfaces(c);
This fixes up the problem above. Similar alteratertions to
getAccessibleMethods(), getAccessibleFields() and
getAccessibleConstructors()
in PyJavaClass fixes BUG#122847
//----
private static Class[] filterPublic(Class[] in) {
java.util.Vector v=new java.util.Vector();
for(int i=0;i<in.length;i++) {
if(!Modifier.isPublic(in[i].getModifiers())) continue;
v.addElement(in[i]);
}
if(v.size()==in.length) return in;
Class[] ret = new Class[v.size()];
v.copyInto(ret);
return ret;
}
private static Class[] getAccessibleInterfaces(Class c) {
// can't modify accessibility of interfaces in Java2
// thus get only public interfaces
return filterPublic(c.getInterfaces());
}
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132462&group_id=12867
|
|
From: <no...@so...> - 2001-02-16 07:03:59
|
Bug #122847, was updated on 2000-Nov-18 11:31
Here is a current snapshot of the bug.
Project: Jython
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 1
Submitted by: bckfnn
Assigned to : nobody
Summary: Can't acces public member of package private base class
Details: For some reason, JPython cannot access a public method that is
defined
in the package private base class of my object instance. public Foo
extends (package private) Bar. Bar defines public String hi(). If I
instantiate Foo and call hi() on the instance, I get an
IllegalAccessException.
Java classes:
--------------------------------------------------------------
package testpackage;
public class Foo extends Bar {
}
class Bar {
public String hi() {
return "hi";
}
}
---------------------------------------------------------------
Python code:
---------------------------------------------------------------
>>> from testpackage import Foo
>>> f = Foo()
>>> f.hi()
---------------------------------------------------------------
Resulting exception:
---------------------------------------------------------------
Traceback (innermost last):
File "<console>", line 1, in ?
java.lang.IllegalAccessException: testpackage/Bar
at
org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:158)
at org.python.core.PyMethod.__call__(PyMethod.java:66)
at org.python.core.PyObject.__call__(PyObject.java:260)
at org.python.core.PyInstance.invoke(PyInstance.java:254)
at org.python.pycode._pyx5.f$0(<console>)
at org.python.pycode._pyx5.call_function(<console>)
at org.python.core.PyTableCode.call(PyTableCode.java:155)
at org.python.core.Py.runCode(Py.java:937)
at org.python.core.Py.exec(Py.java:951)
at org.python.util.PythonInterpreter.exec(PythonInterpreter.java:121)
at
org.python.util.InteractiveInterpreter.runcode(InteractiveInterpreter.java:82)
at
org.python.util.InteractiveInterpreter.runsource(InteractiveInterpreter.java:63)
at
org.python.util.InteractiveInterpreter.runsource(InteractiveInterpreter.java:42)
at org.python.util.InteractiveConsole.push(InteractiveConsole.java:84)
at
org.python.util.InteractiveConsole.interact(InteractiveConsole.java:63)
at org.python.util.jpython.main(jpython.java:141)
java.lang.IllegalAccessException: java.lang.IllegalAccessException:
testpackage/Bar
Follow-Ups:
Date: 2001-Feb-15 23:05
By: ianzsk
Comment:
this is a similar bug to #132462
I've altered a few methods in PyJavaClass and added another Options flag
to use the JavaAccessibility.setAccessible() to "mimic" the equivalent
Java access. (Now if I can only give jython classes access to protected
members
of Java super classes!)
-------------------------------------------------------
Date: 2000-Nov-23 01:06
By: bckfnn
Comment:
I don't think this is solvable at all! The method is accessible through
java but inaccessible through reflection!
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=122847&group_id=12867
|
|
From: <no...@so...> - 2001-02-16 07:01:09
|
Bug #132462, was updated on 2001-Feb-14 19:27
Here is a current snapshot of the bug.
Project: Jython
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: ianzsk
Assigned to : nobody
Summary: jython invokes interface "method" instead actual method
Details: This bug seems similar to(but not the same as) bug #122847
Given the following Java code:
//-----------------------------
package aa;
interface Named {
String getName();
}
public class bug implements Named {
public bug() {}
public String getName() { return "name"; }
}
//--------
The following jython (Jython 2.0 on java1.3.0 (JIT: null)) script invokes
an IllegalAccessException
#!/usr/bin/env jython
from aa import bug
b=bug()
b.getName()
# same problem with bean property : b.name
Possible resolution:
----------------------------
Assuming that creating PyJavaClass Objects for interfaces is a requirement
for
jython to work properly (!), the short circuit in
PyJavaClass.addPropery() method viz:
// If this adds nothing over old property, do nothing
if ((prop.getMethod == null || oldProp.getMethod != null)
&&
(prop.setMethod == null || oldProp.setMethod != null))
should be replace with:
boolean nogetOverride=(oldProp.getMethod != null &&
!Modifier.isAbstract(oldProp.getMethod.getModifiers()) );
boolean nosetOverride =(oldProp.setMethod != null &&
!Modifier.isAbstract(oldProp.setMethod.getModifiers()) );
if ((prop.getMethod == null || nogetOverride )
&&
(prop.setMethod == null || nogetOverride ) )
{
set = false;
}
// Add old get/set methods to current prop
// Handles issues with private classes
if (nogetOverride) {
prop.getMethod = oldProp.getMethod;
}
if (nosetOverride) {
prop.setMethod = oldProp.setMethod;
}
i.e. override if it is abstract.
I also changed the code at the bottom of ReflectedArgs.compareTo() method
to:
// For static methods, use the child's version
// For instance methods, use the parent's version
if (!isStatic && ( other.declaringClass.getModifiers() &
(Modifier.INTERFACE))==0 ) replace = !replace;
These two changes at least fix the problem above, but are not maybe the
most general solution.
Follow-Ups:
Date: 2001-Feb-15 22:58
By: ianzsk
Comment:
OK, OK forget all of the above "fixes". this bug is the same type of
bug
as demonstrated in BUG#122847
my workaround is to add a method to PyJavaClass (see below) that returns
only the public interfaces of a class; and then change __init_bases to:
Class[] interfaces=getAccessibleInterfaces(c);
This fixes up the problem above. Similar alteratertions to
getAccessibleMethods(), getAccessibleFields() and
getAccessibleConstructors()
in PyJavaClass fixes BUG#122847
//----
private static Class[] filterPublic(Class[] in) {
java.util.Vector v=new java.util.Vector();
for(int i=0;i<in.length;i++) {
if(!Modifier.isPublic(in[i].getModifiers())) continue;
v.addElement(in[i]);
}
if(v.size()==in.length) return in;
Class[] ret = new Class[v.size()];
v.copyInto(ret);
return ret;
}
private static Class[] getAccessibleInterfaces(Class c) {
// can't modify accessibility of interfaces in Java2
// thus get only public interfaces
return filterPublic(c.getInterfaces());
}
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132462&group_id=12867
|
|
From: <no...@so...> - 2001-02-15 03:26:41
|
Bug #132462, was updated on 2001-Feb-14 19:27
Here is a current snapshot of the bug.
Project: Jython
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: ianzsk
Assigned to : nobody
Summary: jython invokes interface "method" instead actual method
Details: This bug seems similar to(but not the same as) bug #122847
Given the following Java code:
//-----------------------------
package aa;
interface Named {
String getName();
}
public class bug implements Named {
public bug() {}
public String getName() { return "name"; }
}
//--------
The following jython (Jython 2.0 on java1.3.0 (JIT: null)) script invokes
an IllegalAccessException
#!/usr/bin/env jython
from aa import bug
b=bug()
b.getName()
# same problem with bean property : b.name
Possible resolution:
----------------------------
Assuming that creating PyJavaClass Objects for interfaces is a requirement
for
jython to work properly (!), the short circuit in
PyJavaClass.addPropery() method viz:
// If this adds nothing over old property, do nothing
if ((prop.getMethod == null || oldProp.getMethod != null)
&&
(prop.setMethod == null || oldProp.setMethod != null))
should be replace with:
boolean nogetOverride=(oldProp.getMethod != null &&
!Modifier.isAbstract(oldProp.getMethod.getModifiers()) );
boolean nosetOverride =(oldProp.setMethod != null &&
!Modifier.isAbstract(oldProp.setMethod.getModifiers()) );
if ((prop.getMethod == null || nogetOverride )
&&
(prop.setMethod == null || nogetOverride ) )
{
set = false;
}
// Add old get/set methods to current prop
// Handles issues with private classes
if (nogetOverride) {
prop.getMethod = oldProp.getMethod;
}
if (nosetOverride) {
prop.setMethod = oldProp.setMethod;
}
i.e. override if it is abstract.
I also changed the code at the bottom of ReflectedArgs.compareTo() method
to:
// For static methods, use the child's version
// For instance methods, use the parent's version
if (!isStatic && ( other.declaringClass.getModifiers() &
(Modifier.INTERFACE))==0 ) replace = !replace;
These two changes at least fix the problem above, but are not maybe the
most general solution.
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132462&group_id=12867
|
|
From: <no...@so...> - 2001-02-14 22:36:08
|
Bug #129363, was updated on 2001-Jan-19 01:47 Here is a current snapshot of the bug. Project: Jython Category: Core Status: Closed Resolution: Fixed Bug Group: None Priority: 3 Submitted by: bckfnn Assigned to : bckfnn Summary: Calling overriden method from java ctor Details: Methods implemented in python will not be called from the java super class constructor. Se this mail for more details: http://mail.python.org/pipermail/jpython-interest/2000-September/003871.html Follow-Ups: Date: 2001-Feb-14 14:36 By: bckfnn Comment: Fixed as good as it can be fixed. If an overriden method is called from the java ctor, the python ctor will be called without any arguments. If the python ctor expect arguments, the java class have to call the __initProxy__(Object[]) method. ((PyProxy) this).__initProxy__(new Object[] { "A string", new Integer(42), }); ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129363&group_id=12867 |
|
From: <no...@so...> - 2001-02-08 07:10:03
|
Bug #131507, was updated on 2001-Feb-07 23:09
Here is a current snapshot of the bug.
Project: Jython
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: tbreuel
Assigned to : nobody
Summary: stack overflow for simple class
Details: The little program below dies with a stack overflow.
Apparently, something is going wrong with combining
the PyList class (which conforms to the List
interface) with the List interface. This should
probably either be disallowed, or, better, should
work correctly.
import java.util
import org.python.core
class LX(org.python.core.PyList,java.util.List):
pass
l = LX()
l.add('x')
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131507&group_id=12867
|
|
From: <no...@so...> - 2001-02-07 21:15:22
|
Bug #129363, was updated on 2001-Jan-19 01:47 Here is a current snapshot of the bug. Project: Jython Category: Core Status: Open Resolution: None Bug Group: None Priority: 3 Submitted by: bckfnn Assigned to : bckfnn Summary: Calling overriden method from java ctor Details: Methods implemented in python will not be called from the java super class constructor. Se this mail for more details: http://mail.python.org/pipermail/jpython-interest/2000-September/003871.html For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129363&group_id=12867 |
|
From: <no...@so...> - 2001-02-07 09:25:20
|
Bug #127340, was updated on 2001-Jan-02 14:42
Here is a current snapshot of the bug.
Project: Jython
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: njcarriero
Assigned to : bckfnn
Summary: Problem with serializable method parameters
Details: An object crossing from jython to java seems to lose its
identity
if passed as a serializable object . The following illustrates the
problem.
==== Output from java ====
[carriero@callisto kinase-search]$ java TellMeMore
class java.util.Hashtable
{zwei=two, uno=one}
class java.util.Hashtable
{zwei=two, uno=one}
==== Output from jython 2.0b1 ====
[carriero@callisto kinase-search]$
/home/carriero/jython/jython-2.0b1/jython tmm.py
class java.util.Hashtable
{zwei=two, uno=one}
class org.python.core.PyJavaInstance
org.python.core.PyJavaInstance@38ed7d
==== Python source ====
from java.util import *
import TellMeMore
h = Hashtable()
h.put("uno", "one")
h.put("zwei", "two")
tmm = TellMeMore()
tmm.TellMeMoreO(h)
tmm.dump()
tmm.TellMeMoreS(h)
tmm.dump()
==== Java source ====
import java.io.*;
import java.util.*;
public class TellMeMore {
Object o;
public void TellMeMoreS(Serializable o) {
this.o = o;
}
public void TellMeMoreO(Object o) {
this.o = o;
}
public void dump() {
System.out.println(o.getClass());
System.out.println(o.toString());
}
public static void main(String args[]) {
Hashtable h = new Hashtable();
h.put("uno", "one");
h.put("zwei", "two");
TellMeMore tmm = new TellMeMore();
tmm.TellMeMoreO(h);
tmm.dump();
tmm.TellMeMoreS(h);
tmm.dump();
}
}
Follow-Ups:
Date: 2001-Feb-07 01:25
By: bckfnn
Comment:
Fixed in:
PyClass.java: 2.19;
PyFloat.java: 2.7;
PyInstance.java: 2.18;
PyInteger.java: 2.9;
PyLong.java: 2.10;
PyString.java: 2.39;
-------------------------------------------------------
Date: 2001-Jan-03 03:20
By: bckfnn
Comment:
This problem have been raised before and we quick forgot all about it:
http://mail.python.org/pipermail/jpython-interest/1999-July/001944.html
I don't feel that the solution Jim describe is such a big hack, but it does
require changes to the highly sensitive __tojava__() methods in the
classes:
PyClass
PyFloat
PyInstance
PyInteger
PyLong
PyString
Because such a change will need a long period if test, I'll delay the fix
until after the 2.0 release.
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=127340&group_id=12867
|
|
From: <no...@so...> - 2001-02-06 23:19:45
|
Bug #131321, was updated on 2001-Feb-06 12:22 Here is a current snapshot of the bug. Project: Jython Category: Library Status: Closed Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: Using Jython with JBuilder 2.0 Details: Can't seem to compile a java applet with jython embedded, could REALLY use some info, the jbuilder is giving me an ambiguous error message about internal assertion if I refer to anything in the jpython package, i can import it into the java applet and compile, I just can't use any of it... I would really like to use jython with this new game I'm developing so let me know if anyone has any ideas. Follow-Ups: Date: 2001-Feb-06 15:20 By: pedronis Comment: Seem a JBuilder problem. Description is confused and insufficient. There is nothing special in jython that should prevent an IDE to compile against it. For example I always succeeded in compiling code that embedded jython under Forte. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=131321&group_id=12867 |
|
From: <no...@so...> - 2001-02-06 20:21:27
|
Bug #131321, was updated on 2001-Feb-06 12:22 Here is a current snapshot of the bug. Project: Jython Category: Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: Using Jython with JBuilder 2.0 Details: Can't seem to compile a java applet with jython embedded, could REALLY use some info, the jbuilder is giving me an ambiguous error message about internal assertion if I refer to anything in the jpython package, i can import it into the java applet and compile, I just can't use any of it... I would really like to use jython with this new game I'm developing so let me know if anyone has any ideas. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=131321&group_id=12867 |
|
From: <no...@so...> - 2001-02-04 20:02:36
|
Bug #129364, was updated on 2001-Jan-19 01:52
Here is a current snapshot of the bug.
Project: Jython
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 1
Submitted by: bckfnn
Assigned to : bckfnn
Summary: Internal exception thrown for illegal listcomp code
Details: [i for i in range(10)] = (1, 2, 3)
Jython 2.0 on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> [i for i in range(10)] = (1, 2, 3)
Traceback (innermost last):
(no code object) at line 0
java.lang.InternalError: stack < 0: -1
at org.python.compiler.Code.push(Code.java:155)
at org.python.compiler.Code.pop(Code.java:456)
Follow-Ups:
Date: 2001-Feb-04 06:57
By: bckfnn
Comment:
Fixed in LocalsCompiler.java: 2.7;
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129364&group_id=12867
|
|
From: <no...@so...> - 2001-02-04 20:02:33
|
Bug #127340, was updated on 2001-Jan-02 14:42
Here is a current snapshot of the bug.
Project: Jython
Category: Core
Status: Open
Resolution: Later
Bug Group: None
Priority: 5
Submitted by: njcarriero
Assigned to : bckfnn
Summary: Problem with serializable method parameters
Details: An object crossing from jython to java seems to lose its
identity
if passed as a serializable object . The following illustrates the
problem.
==== Output from java ====
[carriero@callisto kinase-search]$ java TellMeMore
class java.util.Hashtable
{zwei=two, uno=one}
class java.util.Hashtable
{zwei=two, uno=one}
==== Output from jython 2.0b1 ====
[carriero@callisto kinase-search]$
/home/carriero/jython/jython-2.0b1/jython tmm.py
class java.util.Hashtable
{zwei=two, uno=one}
class org.python.core.PyJavaInstance
org.python.core.PyJavaInstance@38ed7d
==== Python source ====
from java.util import *
import TellMeMore
h = Hashtable()
h.put("uno", "one")
h.put("zwei", "two")
tmm = TellMeMore()
tmm.TellMeMoreO(h)
tmm.dump()
tmm.TellMeMoreS(h)
tmm.dump()
==== Java source ====
import java.io.*;
import java.util.*;
public class TellMeMore {
Object o;
public void TellMeMoreS(Serializable o) {
this.o = o;
}
public void TellMeMoreO(Object o) {
this.o = o;
}
public void dump() {
System.out.println(o.getClass());
System.out.println(o.toString());
}
public static void main(String args[]) {
Hashtable h = new Hashtable();
h.put("uno", "one");
h.put("zwei", "two");
TellMeMore tmm = new TellMeMore();
tmm.TellMeMoreO(h);
tmm.dump();
tmm.TellMeMoreS(h);
tmm.dump();
}
}
Follow-Ups:
Date: 2001-Jan-03 03:20
By: bckfnn
Comment:
This problem have been raised before and we quick forgot all about it:
http://mail.python.org/pipermail/jpython-interest/1999-July/001944.html
I don't feel that the solution Jim describe is such a big hack, but it does
require changes to the highly sensitive __tojava__() methods in the
classes:
PyClass
PyFloat
PyInstance
PyInteger
PyLong
PyString
Because such a change will need a long period if test, I'll delay the fix
until after the 2.0 release.
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=127340&group_id=12867
|
|
From: <no...@so...> - 2001-02-04 20:02:30
|
Bug #130261, was updated on 2001-Jan-27 03:18 Here is a current snapshot of the bug. Project: Jython Category: Core Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: ahillbo Assigned to : bckfnn Summary: looping over (j.l.System) getProperties gives inifite loop? Details: import java.lang.System as jls jp = jls.getProperties() for i in jp: print i # gives infinite loop of .... None None : : Should it not give an error "loop over non-sequence" instead? This is jython 2.0 on Redhat 7.0 IBM vm cx130-20001124 AND dito on W2k Sun VM 1.3.0. BTW: I am really impressed by your extremely nice work with Jython!!! I'm using it with apache jserv for servlets etc, as we have other people working on "normal" java servlets this integrates better that running cpython with mod_python. Keep up the good work! Follow-Ups: Date: 2001-Feb-04 07:37 By: bckfnn Comment: Fixed in: CollectionProxy.java: 2.3; CollectionProxy2.java: 2.2; ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130261&group_id=12867 |
|
From: <no...@so...> - 2001-01-31 10:46:57
|
Bug #129746, was updated on 2001-Jan-22 17:47
Here is a current snapshot of the bug.
Project: Jython
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: sjprocter
Assigned to : bckfnn
Summary: possibe bug in jython re package
Details: re.findall throws an exception when processing some strings.
Following is a code fragment which exhibits this.
The only difference between the two strings in the example, okinput and
badinput,
is a space between the HTML tags in badinput. Calling findall on okinput
works and
on badinput generates an exception.
When run from C python both strings are processed without exception.
- Steven
--- cut here ---
import re
def test():
imagepattern = '(?P<img><[ \t\n]*img[^>]*>)'
framepattern = '(?P<frame><[ \t\n]*frame[^>]*>)'
# embed directives that use a src= construction
extractSrcTags = '(' + imagepattern + '|' + framepattern + ')'
okinput = """<img src="foo bar"><frame src=baz>"""
badinput = """<img src="foo bar"> <frame src=baz>"""
print re.findall(extractSrcTags, okinput)
print re.findall(extractSrcTags, badinput)
--- cut here ---
Here is the first bit of the exception:
Traceback (innermost last):
File "<console>", line 1, in ?
File "E:\jakarta-tomcat\webapps\python\WEB-INF\source\bug.py", line 14,
in tes
t
File "e:\jython-2.0\Lib\sre.py", line 59, in findall
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(Unknown Source)
at org.python.modules.sre.SRE_STATE.getslice(SRE_STATE.java:1128)
Follow-Ups:
Date: 2001-Jan-31 02:46
By: bckfnn
Comment:
This appears to be fixed by my recent update to lastest CPython-2.1a1
version of sre. I have tested this with the CVS version of CPython.
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129746&group_id=12867
|
|
From: <no...@so...> - 2001-01-31 10:41:39
|
Bug #130021, was updated on 2001-Jan-25 02:01
Here is a current snapshot of the bug.
Project: Jython
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: karthy
Assigned to : bckfnn
Summary: os.stat return wrong values
Details: jython-2.0, Sun JDK-1.3, Linux
The os.stat differs between cpython and jython. One can expect, that not
all values is available in jython, but the time fields is 1000 times larger
in jython that in cpython which makes the time library fail when operating
on the values.
Here is an example in jython and cpython for comarrison:
Jython:
>>> import os
>>> os.stat('jakarte-test')
(0, 0, 0, 0, 0, 0, 15761L, 980410501000L, 980410501000L, 0)
Python:
>>> import os
>>> os.stat('jakarte-test')
(33204, 1217412, 3, 1, 2115, 1000, 15761, 980410501, 980410501,
980410501)
Also, the size is a long, while Python return an int.
Follow-Ups:
Date: 2001-Jan-31 02:40
By: bckfnn
Comment:
Fixed in javaos.py 2.5;
The value returned as mtime is now a double in the right range. By using a
double, we ensure that no information is lost when used on windows NT which
have millisecond resolution.
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130021&group_id=12867
|
|
From: <no...@so...> - 2001-01-31 10:41:36
|
Bug #129364, was updated on 2001-Jan-19 01:52
Here is a current snapshot of the bug.
Project: Jython
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 1
Submitted by: bckfnn
Assigned to : bckfnn
Summary: Internal exception thrown for illegal listcomp code
Details: [i for i in range(10)] = (1, 2, 3)
Jython 2.0 on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> [i for i in range(10)] = (1, 2, 3)
Traceback (innermost last):
(no code object) at line 0
java.lang.InternalError: stack < 0: -1
at org.python.compiler.Code.push(Code.java:155)
at org.python.compiler.Code.pop(Code.java:456)
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129364&group_id=12867
|
|
From: <no...@so...> - 2001-01-27 11:18:39
|
Bug #130261, was updated on 2001-Jan-27 03:18 Here is a current snapshot of the bug. Project: Jython Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: ahillbo Assigned to : nobody Summary: looping over (j.l.System) getProperties gives inifite loop? Details: import java.lang.System as jls jp = jls.getProperties() for i in jp: print i # gives infinite loop of .... None None : : Should it not give an error "loop over non-sequence" instead? This is jython 2.0 on Redhat 7.0 IBM vm cx130-20001124 AND dito on W2k Sun VM 1.3.0. BTW: I am really impressed by your extremely nice work with Jython!!! I'm using it with apache jserv for servlets etc, as we have other people working on "normal" java servlets this integrates better that running cpython with mod_python. Keep up the good work! For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130261&group_id=12867 |
46 messages has been excluded from this view by a project administrator.
