jython-users — Discussion of and questions about using Jython

Re: [Jython-users] Jini

[charles c. <cc...@ps...>]

Hi, yup, i'm about to. So far all i did was import some Jini stuff into
the interpreter, but as that was effortless, it's the way i'll be
doing Jini work for the most part.  Good to know there's someone
else interested in the same.
Charles Cosse

Jaap Spies wrote:

> Hi,
>
> Is there anybody out there who is using J(P)ython to write
> JINI-applications??
>
> Jaap Spies
>
> Keep Peace in Mind
>
> _______________________________________________
> Jython-users mailing list
> Jyt...@li...
> http://lists.sourceforge.net/lists/listinfo/jython-users

[Jython-users] Debuggers

[Stephen R. F. <fi...@mo...>]

What debugging tools do you/can you use with Jython?

-Stephen

[Jython-users] ANN: First release candidate of Jython-2.0

[<bc...@wo...>]

I am happy to announce the first release candidate of Jython 2.0. 

Jython is a Java implementation of the Python programming language.  It
allows users to compile Python source code to Java byte codes, and run
the resulting bytecodes on any Java Virtual Machine. It is a very
seamless and smooth integration with Java: from Python you have complete
access to all Java libraries, can build applets, can integrate with Java
beans, and can subclass Java classes in Python and vice versa. Like
Python, and unlike Java, Jython can also be used interactively: just
type some Jython code at the prompt and see the results immediately.

A java installer is available for download at the Jython website:

    http://jython.sourceforge.net/

Installation is started by running the installer class. Further 
information and tips on installation is available at:

    http://jython.sourceforge.net/install.html

Jython 2.0 is feature compatible with Python 2.0 and among the 
new features are:

  - Augmented assignment, e.g. x += 1
  - List comprehensions, e.g. [x**2 for x in range(10)]
  - Extended import statement, e.g. import Module as Name
  - Extended print statement, e.g. print >> file, "Hello"

The changes from beta 2 include:

  New features
   - Experimental support for reloading java packages. Thanks to
     Samuele Pedroni for all his work on the Jython/Java integration.

  Bug fixes.
   - Prevent a NPE when a .jar on the classpath is corrupt. Instead
     a message with the original IOException is printed.


A complete list of changes and differences are available here:

  http://jython.sourceforge.net/NEWS.html

Bugs can be reported to the bug manager on SourceForge:

  http://sourceforge.net/bugs/?group_id=12867

Cheers,
the jython-developers

[Jython-users] How do i override a static Java method in Jython ?

[Erlend V <eb...@im...>]

Hi all!

I'm trying to look into using Jython with JUnit

in my Class that extends junit.framework.TestCase, i have

 def suite():
        "@sig public static junit.framework.Test suite()"
        print "suite called"
        return junit.framework.TestSuite("test.SimpleTest")


If I dont specify the "@sig", the static suite method is not overridden, and 
if I add the @sig, I get the problem shown below.

How can a Jython program override a static method?

Erlend
------
[evb@evb unittest]$ jythonc -p test SimpleTest.py
processing SimpleTest

Required packages:
  junit.swingui
  junit.framework
 
Creating adapters:
 
Creating .java files:
  SimpleTest module
    SimpleTest extends junit.framework.TestCase
 
Compiling .java to .class...
Compiling with args: ['/usr/local/ibmjdk1.3/bin/javac', '-classpath', 
'/usr/local/jython-2.0b2/jython.jar:.::/usr/local/ant/ant/lib/ant.jar:/usr/local/JacORB1_1/classes:/usr/local/JacORB1_1/lib/idl.jar:/usr/local/JacORB1_1/lib/jacorb.jar:/usr/local/jython-2.0b2/jython.jar:/usr/local/junit3.4/junit.jar:./jpywork::/usr/local/jython-2.0b2/Tools/jythonc:/home/evb/work/python/unittest/.:/usr/local/jython-2.0b2/Lib', 
'./jpywork/test/SimpleTest.java']
1  ./jpywork/test/SimpleTest.java:158: non-static variable this cannot be 
referenced from a static context
        PyObject inst = Py.jgetattr(this, "suite");
                                    ^
Note: ./jpywork/test/SimpleTest.java uses or overrides a deprecated API.
Note: Recompile with -deprecation for details.
1 error
 
ERROR DURING JAVA COMPILATION... EXITING

[Jython-users] string in jar?

[John M. <joh...@ya...>]

Is there a way that I can put a string constant in my Jython code,
compile it to a jar file using jpythonc and have the string appear in
the jar file?  I'm trying to get RCS keywords included so that I can
tell what version of code was used to build the jar file.

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

[Jython-users] Jini

[Jaap S. <j....@hc...>]

Hi,

Is there anybody out there who is using J(P)ython to write
JINI-applications??

Jaap Spies

Keep Peace in Mind

[Jython-users] Re: [JPython] HP HotSpot JIT vesus JPython?

[<bc...@wo...>]

On Sat, 13 Jan 2001 23:21:02 -0800 (PST), you wrote:

>Thanks for the benchmark.   Here's what i got on Linux and HP. 
>Interesting HP result.
>
>Linux:
>
> Linux: /home/mudd[1]  finn.benchmark.py
>0.484000 sys.path
>2.210000 System.getProperties()
>1.231000 [].append
>2.069000 [].pop
>1.276000 [].__len__
> Linux: /home/mudd[1]

The fact that the numbers for append and pop are so close together show
that the java.lang.reflect.Method implementation is very fast on this
JVM.

[John fixes an unstable baseline]

>Here we go one more time...
>
>HP HotSpot:
>
>$ /opt/java1.3/bin/java -server -version
>java version "JavaVM-1.3.0.00"
>Java(TM) 2 Runtime Environment, Standard Edition (build
>jinteg:11/28/00-11:08)
>HotSpot VM (build 1.0.1fcs jinteg:11/28/00-13:54 PA2.0, mixed mode)
>$ finn.benchmark.py
>2.173000 sys.path
>13.505000 System.getProperties()
>1.677000 [].append
>11.210000 [].pop
>1.137000 [].__len__
>$

And here the huge difference between append and pop indicate that there
might be room for improving the implementation of Method.invoke().

JPython is very depending on the performance of reflection. It totally
depends on reflection for calling methods in java classes. Barry have
done a lot of work by optimizing most of the often used methods (like
len() and append() above) but there are still some internal & builtin
methods which are using reflection.

I would say that this is reason for the general performance slowness you
have seen on HP.

>HP classic JIT:
>
>$ /opt/java1.3/bin/java -classic -version
>java version "JavaVM-1.3.0.00"
>Java(TM) 2 Runtime Environment, Standard Edition (build
>jinteg:11/28/00-11:08)
>Classic VM (build jinteg:11/28/00-13:54, build jinteg:11/28/00-13:54,
>native threads, HP)
>$ finn.benchmark.py
>6.491000 sys.path
>13.045000 System.getProperties()
>7.310000 [].append
>14.966000 [].pop
>7.868000 [].__len__

Here the difference between append and pop is reduced. This is as I
would expect (but perhaps somewhat more pronounced than I had expected)
because the optimization that avoids using reflection are now executing
more pure java code.

>HP interpretter:
>
>$ /opt/java1.3/bin/java -Xint -version
>java version "JavaVM-1.3.0.00"
>Java(TM) 2 Runtime Environment, Standard Edition (build
>jinteg:11/28/00-11:08)
>HotSpot VM (build 1.0.1fcs jinteg:11/28/00-13:54 PA2.0, interpreted
>mode)
>$ finn.benchmark.py
>10.043000 sys.path
>21.941000 System.getProperties()
>7.364000 [].append
>21.474000 [].pop
>7.250000 [].__len__

Here the reflection calls are going through the roof while the java code
are about the same. I have no explanation for that!

>Hey...  I expected your benchmark to speed up as I transitioned from
>HOTSpot to interpretter like my application does.  The number for your
>benchmark make sense as far as the interpretter being slow compared
>to HotSpot.
>
>But that just makes me more frustrated that my application has the
>opposite result.  Maybe it the threads I have running.  I have maybe
>five threads running in parallel, passing lots of 15 KB octet strings
>back and forth via queues built on dictionaries.

I assume there are some synchronization done by wait() and notifyAll().
IIRC the sync mechanisme is also changed significantly by hotspot. A
benchmark of the time to call synchronized & non-synchronized methods
might show something interesting (or might not). Again it is a
difference between the two that is interesting and a comparison of this
difference when using the clasic jit and hotspot.

Such test would probably have be in pure java. Otherwise the result
might drown in the jpython overhead.

>Also...
>
>Yes, I'm already using both JPython source code and jpythonc jar files.
> No difference that I've noticed.

That's good. Then the bytecode created by the jpython compiler are just
as good and fast as the bytecode created by the javac compiler.

>Yes, I agree that's it's unlikely for HP to make any sort of quick fix.
> For now I'd be happy for some sort of explanation. 

While you have the contact, do not miss the change to tell them that
their Method.invoke() is slower than other jdk1.3 implementations. That
is making their java offering look worse than it actually is when using
script languages.

>I may pursue trying to reproduce the "problem" with HotSpot hurting
>performance by writing a siple script to create some relatively simple
>threads to simulate what the application does. 

Yes. Breaking down the application to pinpointing the performance
characteristics is the only way to go.

regards,
finn

[Jython-users] Fwd: Re: [JPython] HP HotSpot JIT vesus JPython?

[John M. <joh...@ya...>]

--- John Mudd <joh...@ya...> wrote:
> Date: Sat, 13 Jan 2001 23:21:02 -0800 (PST)
> From: John Mudd <joh...@ya...>
> Subject: Re: [JPython] HP HotSpot JIT vesus JPython?
> To: Finn Bock <bc...@wo...>
> 
> Thanks for the benchmark.   Here's what i got on Linux and HP. 
> Interesting HP result.
> 
> 
> 
> Linux:
> 
>  Linux: /home/mudd[1]  finn.benchmark.py
> 0.484000 sys.path
> 2.210000 System.getProperties()
> 1.231000 [].append
> 2.069000 [].pop
> 1.276000 [].__len__
>  Linux: /home/mudd[1]
> 
> 
> 
> 
> 
> 
> HP HotSpot:
> 
> $ /opt/java1.3/bin/java -server -version
> java version "JavaVM-1.3.0.00"
> Java(TM) 2 Runtime Environment, Standard Edition (build
> jinteg:11/28/00-11:08)
> HotSpot VM (build 1.0.1fcs jinteg:11/28/00-13:54 PA2.0, mixed mode)
> $ finn.benchmark.py
> 1.321000 sys.path
> 11.558000 System.getProperties()
> -0.319000 [].append
> 11.154000 [].pop
> -0.814000 [].__len__
> $
> 
> 
> Hmmm... the baseline value is not stable.  Here's what I get when I
> run
> just the baseline repeatedly using HP's HotSpot:
> 
> 2.66  
> 0.73  <-- OK, now HotSpot is helping on 2nd pass.
> 0.93
> 0.53
> 0.86
> 0.53
> 0.73
> 0.54
> 0.69
> 0.53
> 0.66
> 0.54
> 0.64
> 0.54
> 0.61
> 0.54
> 0.59
> 0.54
> 0.57
> 0.54
> 0.54
> 0.75
> 0.54
> 0.75
> 0.53
> 1.13  <-- Is this normal??  The occasional extra pause w/ HotSpot?
> 0.54
> 0.74
> 0.53
> 0.73
> 0.53
> 0.74
> 0.53
> 0.74
> 0.54
> 0.74
> 0.53
> 0.74
> 0.53
> 0.74
> 0.54
> 0.74
> 0.53
> 0.75
> 0.53
> 0.74
> 0.54
> 1.15   <-- again, another pause.
> 
> 
> 
> The negative numbers are the result of an invalid value for the
> baseline.  I changed your benchmark program to ignore the first
> couple
> of baseline values as follows:
> 
> for i in range(3):
>     baseline = test(f1)
> 
> 
> 
> Here we go one more time...
> 
> 
> HP HotSpot:
> 
> $ /opt/java1.3/bin/java -server -version
> java version "JavaVM-1.3.0.00"
> Java(TM) 2 Runtime Environment, Standard Edition (build
> jinteg:11/28/00-11:08)
> HotSpot VM (build 1.0.1fcs jinteg:11/28/00-13:54 PA2.0, mixed mode)
> $ finn.benchmark.py
> 2.173000 sys.path
> 13.505000 System.getProperties()
> 1.677000 [].append
> 11.210000 [].pop
> 1.137000 [].__len__
> $
> 
> 
> 
> 
> 
> HP classic JIT:
> 
> $ /opt/java1.3/bin/java -classic -version
> java version "JavaVM-1.3.0.00"
> Java(TM) 2 Runtime Environment, Standard Edition (build
> jinteg:11/28/00-11:08)
> Classic VM (build jinteg:11/28/00-13:54, build jinteg:11/28/00-13:54,
> native threads, HP)
> $ finn.benchmark.py
> 6.491000 sys.path
> 13.045000 System.getProperties()
> 7.310000 [].append
> 14.966000 [].pop
> 7.868000 [].__len__
> $
> 
> 
> 
> 
> HP interpretter:
> 
> $ /opt/java1.3/bin/java -Xint -version
> java version "JavaVM-1.3.0.00"
> Java(TM) 2 Runtime Environment, Standard Edition (build
> jinteg:11/28/00-11:08)
> HotSpot VM (build 1.0.1fcs jinteg:11/28/00-13:54 PA2.0, interpreted
> mode)
> $ finn.benchmark.py
> 10.043000 sys.path
> 21.941000 System.getProperties()
> 7.364000 [].append
> 21.474000 [].pop
> 7.250000 [].__len__
> $
> 
> 
> Hey...  I expected your benchmark to speed up as I transitioned from
> HOTSpot to interpretter like my application does.  The number for
> your
> benchmark make sense as far as the interpretter being slow compared
> to HotSpot.
> 
> But that just makes me more frustrated that my application has the
> opposite result.  Maybe it the threads I have running.  I have maybe
> five threads running in parallel, passing lots of 15 KB octet strings
> back and forth via queues built on dictionaries.
> 
> 
> 
> 
> Also...
> 
> Yes, I'm already using both JPython source code and jpythonc jar
> files.
>  No difference that I've noticed.
> 
> 
> Yes, I agree that's it's unlikely for HP to make any sort of quick
> fix.
>  For now I'd be happy for some sort of explanation. 
> 
> I may pursue trying to reproduce the "problem" with HotSpot hurting
> performance by writing a siple script to create some relatively
> simple
> threads to simulate what the application does. 
> 
> 
> 
> 
> 
> --- Finn Bock <bc...@wo...> wrote:
> > [John Mudd]
> > 
> > >I have a large (5,000 line) JPython disk server that's running too
> > slow
> > >on a HP machine using 1.3 Java & HotSpot.  It has several
> > components. 
> > >I benchmark all of the components but, surisingly, when I combine
> > the
> > >whole server the overall performance is only half of the slowest
> > >(bottleneck) component.  It's as if really complex multi-threaded
> > code
> > >is a recipe for trouble on HP in terms of performance.
> > >
> > >For one benchmark that I've selected I can actually double
> > performance
> > >by switching to pure interpreted (-Xint) mode.  If I try that on
> > Sun,
> > >the performance is cut in half (which makes sense).  So... why
> > doesn't
> > >HotSpot help on HP??
> > >
> > >I've used the verbose option to trace GC operations.  That's not
> the
> > >source of the problem.  I'm pretty sure about this.
> > >
> > >On one hand, I'm tempted to say that JPython generated Java code
> is
> > >complicated and/or special in some way as to interfere with
> HotSpot
> > >technology.  If so, that's a shame.  On the other hand, it doesn't
> > >interfere on Sun's version of java.
> > 
> > In itself not surprising, because JimH was using different versions
> > of
> > javasoft JVM's. One naturally uses whatever works and works fast.
> > 
> > The byte code created by the dynamic code generator is of course
> > different from the byte code created by java compilers. If a JIT
> make
> > many assumptions about the ordering or frequency of the byte codes,
> > it
> > may be surprised when it turns out that jpython doesn't fulfill the
> > assumptions. But I don't think that it what is happening here.
> > 
> > If your application is of such a type that it can be compiled with
> > jpythonc, you can use this route to insure that the byte code is
> > created
> > by a traditional java compiler. Generally the overall running time
> > should be close to the same. (jpythonc'ed application may have a
> > slight
> > performance edge because the proxies have been precompiled. For a
> > longer
> > running application the difference should be very small).
> > 
> > Coming up with a guess, I would say the performance difference with
> > calling reflected methods and fields are far more important that
> the
> > actual byte code. A JVM which have optimized the
> > java.lang.reflect.Method implementation will enjoy a huge
> performance
> > gain when used with jpython. That is even more true if the python
> are
> > making direct use of java packages and classes, but it also holds
> for
> > some non-java use of jpython.
> > 
> > >I have HP Java technicians on hand to respond to the situation but
> > I'm
> > >wondering if this is more than they can be held responsible for. 
> Is
> > >JPython beyond the realm of "normal" Java code or should I press
> HP
> > for help?
> > 
> > What ever the reason turns out to be, I somehow doubt that HP can
> do
> > anything on the short term. You can try to do some bench marking to
> > find
> > where it is HP comparably slower that your other JVMs.
> > 
> > Here is a starting point:
> > 
> > from time import time
> > import sys
> > 
> > def test(f):
> >      t1=time();
> >      for i in range(100000):
> >          f()
> >      return time()-t1
> > 
> > def f1():
> >     pass
> > 
> > def f2():
> >     sys.path
> > 
> > from java.lang import System
> > def f3():
> >     System.getProperties()
> > 
> > def f4():
> >     [].append(0)
> > 
> > def f5():
> >     [0].pop()
> > 
> > def f6():
> >     [].__len__()
> > 
> > baseline = test(f1)
> > print "%6f sys.path" % (test(f2) - baseline)
> > print "%6f System.getProperties()" %  (test(f3) - baseline)
> > print "%6f [].append" %  (test(f4) - baseline)
> > print "%6f [].pop" %  (test(f5) - baseline)
> > print "%6f [].__len__" %  (test(f6) - baseline)
> > 
> > 
> > 
> > My numbers are:
> > 
> > 1.042000 sys.path
> > 3.484000 System.getProperties()
> > 0.791000 [].append
> > 4.116000 [].pop
> > 0.721000 [].__len__
> > 
> > The sys.path are using Field reflection. Optimizing the sys.path so
> > it
> > avoid field reflecttion, the number becomes:
> > 
> > 0.070000 sys.path
> > 3.615000 System.getProperties()
> > 0.842000 [].append
> > 4.026000 [].pop
> > 0.711000 [].__len__
> > 
> > The pop() test only works on jython, but it is IMO quite
> interesting
> > as
> > a comparison to append(). The append() is optimized so it does not
> > use
> > reflection, while the jython pop() uses reflection. With an
> > optimization
> > change to jython, so pop() works similar to append(), the numbers
> > are:
> > 
> > 0.071000 sys.path
> > 3.355000 System.getProperties()
> > 0.921000 [].append
> > 1.192000 [].pop
> > 0.902000 [].__len__
> > 
> > Calling through reflection is very expension, even on JDK1.3.
> > 
> > regards,
> > finn
> > 
> > _______________________________________________
> > JPython-Interest maillist  -  JPy...@py...
> > http://www.python.org/mailman/listinfo/jpython-interest
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail. 
> http://personal.mail.yahoo.com/
> 


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

RE: [Jython-users] slow JPython math on HP??

[Tim P. <ti...@ho...>]

[attribution lost]
> HP:
>
> JPython 1.1+09 on java1.2.2.05 (JIT: null)
> 86.5       <--  interpretted, very slow
>
> JPython 1.1+09 on java1.2.2.05 (JIT: HP)
> 11.8     <-- classic JIT
>
> JPython 1.1+09 on java1.2.2.05 (JIT: null)
> 14.9     <--  HotSpot JIT

[Finn Bock]
> My numbers are on Win2k & JDK1.3 & 300Mhz P3:
>
> Jython 2.0beta2 on java1.3.0 (JIT: null)
> 37.74500000476837  <-- interpretted
>
> Jython 2.0beta2 on java1.3.0 (JIT: null)
> 4.736999988555908  <-- hotspot
>
> While somewhat faster then your HP it is in the within the same range.

[AL]
> Linux        512 MHz   dual Celeron (brain dead?) Pentium
>
> Linux: /home/mudd[1]  jpython
> JPython 1.1 on java1.2.2-RC2 (JIT: javacomp)
> Copyright (C) 1997-1999 Corporation for National Research Initiatives
> >>> from time import time
> >>> t1=time(); x=2L**10000; delay=time()-t1; print delay
> 0.00499        <-- About 2,400 times faster than HP's best numbers??!?
> >>>

[FB]
> That's fast! Does it actually calculate the correct value?
>
> The power calculation is done fully by the java.math.BigInteger
> implementation. The BigInteger.pow() on JDK1.3 (and HP too I
> expect) is implemented in java as some kind of loop which I
> don't understand.
>
> If the linux JVM are doing its BigInteger stuff in native code, that
> might explain the difference.

Let's try it under CPython on a Pentium box (866MHz P3 here):

>>> t1=clock(); x= 2L**10000; delay=clock()-t1; print delay
0.00165775490706
>>>

So that's how fast a good (but not optimal) pow runs:  the Linux number is
plausible.

The obvious way to implement m**n is to do O(n) multiplications.  A much
smarter way (which CPython implements) uses only O(log2(n)) multiplications.
For n==10000, n/log2(n) is very roughly about 1000.  That's in the right
ballpark for explaining a factor-of-2400 difference, which latter is very
hard to explain otherwise.

all-answers-are-in-the-source-code<wink>-ly y'rs  - tim

Re: [Jython-users] slow JPython math on HP??

[L. H. <hu...@ha...>]

Finn Bock wrote:


>> HP:
>> 
>> JPython 1.1+09 on java1.2.2.05 (JIT: null)
>> 86.5       <--  interpretted, very slow
>> 
>> JPython 1.1+09 on java1.2.2.05 (JIT: HP)
>> 11.8     <-- classic JIT
>> 
>> JPython 1.1+09 on java1.2.2.05 (JIT: null)
>> 14.9     <--  HotSpot JIT
> 
> 
> My numbers are on Win2k & JDK1.3 & 300Mhz P3:
> 
> Jython 2.0beta2 on java1.3.0 (JIT: null)
> 37.74500000476837  <-- interpretted
> 
> Jython 2.0beta2 on java1.3.0 (JIT: null)
> 4.736999988555908  <-- hotspot 
> 
> While somewhat faster then your HP it is in the within the same range.
> 
> 
>> Linux        512 MHz   dual Celeron (brain dead?) Pentium
>> 
>> Linux: /home/mudd[1]  jpython
>> JPython 1.1 on java1.2.2-RC2 (JIT: javacomp)
>> Copyright (C) 1997-1999 Corporation for National Research Initiatives
>> 
>>>>> from time import time
>>>>> t1=time(); x=2L**10000; delay=time()-t1; print delay
>>>> 
>> 0.00499        <-- About 2,400 times faster than HP's best numbers??!?
>> 
> 
> That's fast! Does it actually calculate the correct value?

I checked it out on my Machine:

/home/humbert > cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 5
model           : 9
model name      : AMD-K6(tm) 3D+ Processor
stepping        : 1
cpu MHz         : 400.917224
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
sep_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 sep mtrr pge mmx 3dnow
bogomips        : 799.54

humbert@haspe:~/jython-2.0b2 > ./jython
Jython 2.0beta2 on java1.3.0_01 (JIT: null)
Type "copyright", "credits" or "license" for more information.
 >>> from time import time
 >>> t1=time(); x=2L**10000; delay=time()-t1; print delay
4.932000041007996
 >>>


	TNX
	Ludger

Re: [Jython-users] slow JPython math on HP??

[<bc...@wo...>]

On Fri, 12 Jan 2001 22:20:52 -0800 (PST), you wrote:

>Why is math sooooooooo slow on HP versus Linux??  For the example below
>I calculate the time to calculate 2L**10000 on HP and Linux.  It's over
>2,000 faster on a Linux PC (512 MHz dual Celeron) than on a HP (K box,
>4 processor, 180 MHz).  
>
>This particular example is not critical to my application.  I just
>focus on it because of the dramatic difference in performance on HP
>versus other platforms.  Might this be a clue as to a problem with HP??
>
>
>HP:
>
>JPython 1.1+09 on java1.2.2.05 (JIT: null)
>86.5       <--  interpretted, very slow
>
>JPython 1.1+09 on java1.2.2.05 (JIT: HP)
>11.8     <-- classic JIT
>
>JPython 1.1+09 on java1.2.2.05 (JIT: null)
>14.9     <--  HotSpot JIT

My numbers are on Win2k & JDK1.3 & 300Mhz P3:

Jython 2.0beta2 on java1.3.0 (JIT: null)
37.74500000476837  <-- interpretted

Jython 2.0beta2 on java1.3.0 (JIT: null)
4.736999988555908  <-- hotspot 

While somewhat faster then your HP it is in the within the same range.

>Linux        512 MHz   dual Celeron (brain dead?) Pentium
>
> Linux: /home/mudd[1]  jpython
>JPython 1.1 on java1.2.2-RC2 (JIT: javacomp)
>Copyright (C) 1997-1999 Corporation for National Research Initiatives
>>>> from time import time
>>>> t1=time(); x=2L**10000; delay=time()-t1; print delay
>0.00499        <-- About 2,400 times faster than HP's best numbers??!?
>>>>

That's fast! Does it actually calculate the correct value?

The power calculation is done fully by the java.math.BigInteger
implementation. The BigInteger.pow() on JDK1.3 (and HP too I expect) is
implemented in java as some kind of loop which I don't understand.

If the linux JVM are doing its BigInteger stuff in native code, that
might explain the difference.

regards,
finn

[Jython-users] slow JPython math on HP??

[John M. <joh...@ya...>]

Why is math sooooooooo slow on HP versus Linux??  For the example below
I calculate the time to calculate 2L**10000 on HP and Linux.  It's over
2,000 faster on a Linux PC (512 MHz dual Celeron) than on a HP (K box,
4 processor, 180 MHz).  

This particular example is not critical to my application.  I just
focus on it because of the dramatic difference in performance on HP
versus other platforms.  Might this be a clue as to a problem with HP??


HP:

$ jpython
JPython 1.1+09 on java1.2.2.05 (JIT: null)
Copyright (C) 1997-1999 Corporation for National Research Initiatives
>>> from time import time
>>> t1=time(); x=2L**10000; delay=time()-t1; print delay
86.5       <--  interpretted, very slow
>>>
$ jpython
JPython 1.1+09 on java1.2.2.05 (JIT: HP)
Copyright (C) 1997-1999 Corporation for National Research Initiatives
>>> from time import time
>>> t1=time(); x=2L**10000; delay=time()-t1; print delay
11.539999961853027
>>> t1=time(); x=2L**10000; delay=time()-t1; print delay
11.8     <-- classic JIT
>>>
$ jpython
JPython 1.1+09 on java1.2.2.05 (JIT: null)
Copyright (C) 1997-1999 Corporation for National Research Initiatives
>>> from time import time
>>> t1=time(); x=2L**10000; delay=time()-t1; print delay
14.9     <--  HotSpot JIT
>>> $ ^C
$




Linux        512 MHz   dual Celeron (brain dead?) Pentium

 Linux: /home/mudd[1]  jpython
JPython 1.1 on java1.2.2-RC2 (JIT: javacomp)
Copyright (C) 1997-1999 Corporation for National Research Initiatives
>>> from time import time
>>> t1=time(); x=2L**10000; delay=time()-t1; print delay
0.00499        <-- About 2,400 times faster than HP's best numbers??!?
>>>
 Linux: /home/mudd[1]




__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Re: [Jython-users] Using JNI together with jython

[Thomas H. <tho...@io...>]

I wrote:
> >C:\work\chip\debugger>jython
> >Jython 2.0beta1 on java1.3.0 (JIT: null)
> >Type "copyright", "credits" or "license" for more information.
> >>>> from ColoredConsole import setColor
> >>>> setColor(10)
> >Traceback (innermost last):
> >  File "<console>", line 1, in ?
> >java.lang.IllegalAccessException
> >...
> >
> >Is it possible to use native methods together with jython?
> 
and Finn replied:
> Generally yes. I have done so extensively in my JNI based "os" module
> implementation. One advice which I remember, is to put your java class
> into a package. 
> 
> [Quoting JimH from 25 Nov 1998:]
> """
> > Does JNI work with jpython?  I've been fiddling with it but haven't
> > gotten it to work.
> I'm guessing that the entire problem here is related to using the
> top-level unnamed package.  I've gone into some of the issues with this
> before, so I won't reiterate them here.  The summary is that whenever
> anything goes wrong with a top-level package, my first suggestion is to
> move it into a real named package.
> """
> 
My problem is solved with the help of Jeff Emanuel who sent
me the right answer: My class containing the native method(s)
was not declared public. It works fine now.

Thanks,

Thomas

Re: [Jython-users] An implicit "self" reference in OO Jython?

[<bc...@wo...>]

[Ben Hutchison]

>This posting is about language design. I want to pose the question: Is
>there a way to tweak Jython so that the "self" reference that refers the
>containing instance can be implicitly, like the implicit "this" pointer
>of java or C++?

Regardless of whether there are a technical way to do this, I must
establish that Jython will *not* innovate on the core python language
design. On this I place all my trust on Guido.

>Im a java developer who feels very comfortable with the OO paradigm, yet
>am attracted to Jython because the it makes somethings that are too hard
>in java much easier: map(), list slicing, keyword arguments. But the
>need to explictly specify self.X and self.Y and pass it to instance
>methods disturbs me.

I clearly recall that it disturbed me too when I discovered JPython
about three years ago. Coming from the normal java & C++ background, it
just seems so unnecessary.

It took me a full week <wink> to accept this as a natural part of the
python language, and it haven't bothered me since. I think you will get
to accept it too.

>It makes Python's OO features look something of an
>afterthought, grafted on to a imperative/functional language. Using this
>frequent, default construct, seems like uneccesary hard work.

Based on the history lectures Tim Peters have been teaching on c.l.py, I
think that OO was a fundamental part of python from the very beginning.

>eg:
>    class MyClass:
>        def __init__(self, name):
>        def doIt(self):
>becomes:
>    class MyClass:
>        def __init__(name):
>        def doIt():
>
>which seems far more natural (and easier) from a java point of view.
>
>Why cant "self" be prepended to all functions and vars by default, when
>inside a class definition?

If "self." was prepended to all vars, how could the python compiler tell
the difference between a local vrbl and a instance vrbl

class Foo:
   def bar():
       v = 1 # is "v" a local or an instance vrbl?

Today an instance vrbl is clearly visibly to both programmers and the
compiler because of the explicit self.v syntax.

>If this issue has already been thrashed out on a forum, please refer me
>an archive link.

I'm certain this issue have been discussed on c.l.py (I say that I'm
certain, because every topic have already been discussed on c.l.py
several times over the last 10 years). I don't have a link because, I
don't track c.l.py closely.


The Jython language spec will stay closely tied to the Python language.
It is only on the integration of java classes and java objects that
jython will invent new semantics. If Jython should change on the topic
of explicit self, it will only be because CPython have changed.

regards,
finn

Re: [Jython-users] Using JNI together with jython

[<bc...@wo...>]

[Thomas Heller]

>I'm just trying to get up to speed with Jython: Very impressive!
>
>One problem though:
>
>I have a java JNI component which allows to set the color
>of the Console (I'm using win2000 here).
>This works fine from any java console program,
>but from jython (or even from the program compiled with
>jythonc) I get a traceback:
>
>C:\work\chip\debugger>jython
>Jython 2.0beta1 on java1.3.0 (JIT: null)
>Type "copyright", "credits" or "license" for more information.
>>>> from ColoredConsole import setColor
>>>> setColor(10)
>Traceback (innermost last):
>  File "<console>", line 1, in ?
>java.lang.IllegalAccessException
>...
>
>Is it possible to use native methods together with jython?

Generally yes. I have done so extensively in my JNI based "os" module
implementation. One advice which I remember, is to put your java class
into a package. 

[Quoting JimH from 25 Nov 1998:]
"""
> Does JNI work with jpython?  I've been fiddling with it but haven't
> gotten it to work.
I'm guessing that the entire problem here is related to using the
top-level unnamed package.  I've gone into some of the issues with this
before, so I won't reiterate them here.  The summary is that whenever
anything goes wrong with a top-level package, my first suggestion is to
move it into a real named package.
"""

Unfortunately I can't find the post where Jim goes over the issues.

regards,
finn

[Jython-users] An implicit "self" reference in OO Jython?

[Ben H. <be...@in...>]

This posting is about language design. I want to pose the question: Is
there a way to tweak Jython so that the "self" reference that refers the
containing instance can be implicitly, like the implicit "this" pointer
of java or C++?

Im a java developer who feels very comfortable with the OO paradigm, yet
am attracted to Jython because the it makes somethings that are too hard
in java much easier: map(), list slicing, keyword arguments. But the
need to explictly specify self.X and self.Y and pass it to instance
methods disturbs me. It makes Python's OO features look something of an
afterthought, grafted on to a imperative/functional language. Using this
frequent, default construct, seems like uneccesary hard work.

eg:
    class MyClass:
        def __init__(self, name):
        def doIt(self):
becomes:
    class MyClass:
        def __init__(name):
        def doIt():

which seems far more natural (and easier) from a java point of view.

Why cant "self" be prepended to all functions and vars by default, when
inside a class definition?

If this issue has already been thrashed out on a forum, please refer me
an archive link.

Regards
Ben
--
Ben Hutchison
Software Engineer-Market Predictor
Webmind Australia
http://www.webmind.com/productspredictor.html

[Jython-users] Using JNI together with jython

[Thomas H. <tho...@io...>]

I'm just trying to get up to speed with Jython: Very impressive!

One problem though:

I have a java JNI component which allows to set the color
of the Console (I'm using win2000 here).
This works fine from any java console program,
but from jython (or even from the program compiled with
jythonc) I get a traceback:

C:\work\chip\debugger>jython
Jython 2.0beta1 on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> from ColoredConsole import setColor
>>> setColor(10)
Traceback (innermost last):
  File "<console>", line 1, in ?
java.lang.IllegalAccessException
        at java.lang.reflect.Method.invoke(Native Method)
        at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:158)
        at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:166)
        at org.python.core.PyObject.__call__(PyObject.java:272)
        at org.python.pycode._pyx2.f$0(<console>)
        at org.python.pycode._pyx2.call_function(<console>)
        at org.python.core.PyTableCode.call(PyTableCode.java:155)
        at org.python.core.Py.runCode(Py.java:1050)
        at org.python.core.Py.exec(Py.java:1064)
        at org.python.util.PythonInterpreter.exec(PythonInterpreter.java:124)
        at org.python.util.InteractiveInterpreter.runcode(InteractiveInterpreter.java:87)
        at org.python.util.InteractiveInterpreter.runsource(InteractiveInterpreter.java:68)
        at org.python.util.InteractiveInterpreter.runsource(InteractiveInterpreter.java:42)
        at org.python.util.InteractiveConsole.push(InteractiveConsole.java:83)
        at org.python.util.InteractiveConsole.interact(InteractiveConsole.java:62)
        at org.python.util.jython.main(jython.java:178)

java.lang.IllegalAccessException: java.lang.IllegalAccessException
>>> ^Z

C:\work\chip\debugger>

Is it possible to use native methods together with jython?

Regards,

Thomas

Re: [Jython-users] NullpointerException witj jython-2.0b2: bug + ...

[Samuele P. <pe...@in...>]

Hi.

It's a bug, but it manifests trying to handle another exception
raised reading xerces.jar, so it is possible that the jar is somehow
corrupted or ...


Thanks for the report.

RE: [Jython-users] NullpointerException witj jython-2.0b2

[Adam B. <ada...@gb...>]

Benjamin Scherrey wrote:

> 	I'm trying to install jython but whenever I try to execute any
> program
> I get a NullPointerException. I'm running Linux RedHat 6.1. Attached is
> a file that shows what occurs. What am I doing wrong?
> 
It looks like it has a problem with caching xerces.jar.  As a short term
workaround you could try removing it from your CLASSPATH.  Why it chokes
might need some investigating, though ...

> 	thanx & later,
> 
> 		Ben Scherrey:
> 
> 
> jython Demo/swing/TreeDemo.py
> java -version
> package-mgr*: processing new jar, '/home/scherrey/jython-2.0b2/jython.jar'
> *sys-package-mgr*: processing new jar, '/usr/java/jars/bsf.jar'
> *sys-package-mgr*: processing new jar, '/usr/java/jars/fop.jar'
> *sys-package-mgr*: processing new jar, '/usr/java/jars/xalan.jar'
> *sys-package-mgr*: processing new jar, '/usr/java/jars/xerces.jar'
> Exception in thread "main" java.lang.NullPointerException
> 	at org.python.core.CachedJarsPackageManager.addJarToPackages
> 
Looks like it stuffs up here.

> (CachedJarsPackageManager.java:271)
> 	at
> org.python.core.CachedJarsPackageManager.addJarToPackages(CachedJarsPackag
> eManager.java:175)
> 	at
> org.python.core.PathPackageManager.addClassPath(PathPackageManager.java:13
> 4)
> 	at
> org.python.core.SysPackageManager.findAllPackages(SysPackageManager.java:6
> 3)
> 	at
> org.python.core.SysPackageManager.<init>(SysPackageManager.java:23)
> 	at
> org.python.core.PySystemState.initPackages(PySystemState.java:385)
> 	at org.python.core.PySystemState.initialize(PySystemState.java:327)
> 	at org.python.core.PySystemState.initialize(PySystemState.java:294)
> 	at org.python.util.jython.main(jython.java:75)
> 
> :java -version
> java version "1.3.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
> Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)

[Jython-users] NullpointerException witj jython-2.0b2

[Benjamin S. <sch...@in...>]

	I'm trying to install jython but whenever I try to execute any program
I get a NullPointerException. I'm running Linux RedHat 6.1. Attached is
a file that shows what occurs. What am I doing wrong?

	thanx & later,

		Ben Scherrey

[Jython-users] ANN: Second beta release of Jython-2.0

[<bc...@wo...>]

I am happy to announce the second beta release of Jython 2.0. 

Jython is a Java implementation of the Python programming language.  It
allows users to compile Python source code to Java byte codes, and run
the resulting bytecodes on any Java Virtual Machine. It is a very
seamless and smooth integration with Java: from Python you have complete
access to all Java libraries, can build applets, can integrate with Java
beans, and can subclass Java classes in Python and vice versa. Like
Python, and unlike Java, Jython can also be used interactively: just
type some Jython code at the prompt and see the results immediately.

A java installer is available for download at the Jython website:

    http://jython.sourceforge.net/

Installation is started by running the installer class. Further 
information and tips on installation is available at:

    http://jython.sourceforge.net/install.html

Jython 2.0 is feature compatible with Python 2.0 and among the 
new features are:

  - Augmented assignment, e.g. x += 1
  - List comprehensions, e.g. [x**2 for x in range(10)]
  - Extended import statement, e.g. import Module as Name
  - Extended print statement, e.g. print >> file, "Hello"

The changes from beta 1 include:

  New features
   - Added socket.getfqdn(). Thanks to Brian Zimmer for the patch.

  Bug fixes.
   - Fixed innerclass names with '$' #127200 
   - Fixed a bug where final methods were overriden in proxy #127201.
   - Fixed a bug in exec which allow a fileobject to be passed in.
     Thanks to Brian Zimmer for the patch.

A complete list of changes and differences are available here:

  http://jython.sourceforge.net/NEWS.html

Bugs can be reported to the bug manager on SourceForge:

  http://sourceforge.net/bugs/?group_id=12867

Cheers,
the jython-developers

Re: [Jython-users] @sig doesn't seem to work

[Brad C. <bk...@mu...>]

Adding

Import Java

to the .py code fixed it.. duh

Thanks

---



Brad Clements,                bk...@mu...   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               AOL-IM: BKClements

Re: [Jython-users] @sig doesn't seem to work

[<bc...@wo...>]

[Finn]

> The class *must* inherit from a java class. F.ex 
> 
> from ftplib import FTP
> import java
> 
> class FTPClient(java.lang.Object):

[Brad]

>Thanks for the suggestion, but it still doesn't work.
>
>Somehow I thought that inheritance from Object was implied for all 
>classes in Jython.. Since all objects are a subclass of Object in Java

Using a java base class (like Object) tells the jython compiler to
generate a proxy class. It is this proxy class which should contain your
Put() method. Without a java base class, the python class is only
compiled into series of PyCode objects. These code objects are callable
and usefull from jython, but does not have any representation in java.

>In any case, changing it to:
>
>class FTPClient(java.lang.Object):
>
>Still doesn't produce a public Put method.

I assume you also added a "import java" somewhere above. Take a look at
the output from jythonc. If the proxy generation is succesfull, the
output must include:

Creating .java files:
    FTPClient extends java.lang.Object

regards,
finn

Re: [Jython-users] @sig doesn't seem to work

[Brad C. <bk...@mu...>]

On 10 Jan 2001, at 16:25, Finn Bock wrote:

> >For some reason the @sig line in the code below doesn't work. The 
> >resulting .java file doesn't have a public Put() method..
> 
> The class *must* inherit from a java class. F.ex 
> 
> from ftplib import FTP
> import java
> 
> class FTPClient(java.lang.Object):

Thanks for the suggestion, but it still doesn't work.

Somehow I thought that inheritance from Object was implied for all 
classes in Jython.. Since all objects are a subclass of Object in Java

In any case, changing it to:

class FTPClient(java.lang.Object):

Still doesn't produce a public Put method.

> Also, the @sig must be placed on one single line. It was probably just
> your (or my) mailer that did the line folding.

Mailer wrapped it, it is all on one line in the .py file.

This is very strange because I have another .py module where it does 
work.


Brad Clements,                bk...@mu...   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               AOL-IM: BKClements

Re: [Jython-users] @sig doesn't seem to work

[<bc...@wo...>]

[Brad Clements]

>For some reason the @sig line in the code below doesn't work. The 
>resulting .java file doesn't have a public Put() method..

The class *must* inherit from a java class. F.ex 

from ftplib import FTP
import java

class FTPClient(java.lang.Object):
   ...

Also, the @sig must be placed on one single line. It was probably just
your (or my) mailer that did the line folding.

regards,
finn