Jython

Thank you Charlie.? You of course are right about time.time().? It couldn't be improved using nanoTime.? Time clock should be relatively easy though and should improve things by quite a bit.? I will put my example scripts together with a naive first pass at a solution and open a problem.

I imagine Python uses getTimeOfDay() on unix like systems for time.time().? time.time() could could still be improved using JNI and getTimeOfDay() on Unix like systems and then Jython's resolution would basically match Pythons (since Pythons Windows XP resolution for time.time() really isn't any better than Jythons).? I understand that it isn;'t quite as simple of an enhancement though to use JNI.? Does/would Jython consider using JNI and c for time.time()?

?- Bob



 


 

-----Original Message-----
From: Charlie Groves <charlie.groves@...>
To: boblusebob@...
Cc: jython-dev@...
Sent: Fri, 23 Nov 2007 1:43 pm
Subject: Re: [Jython-dev] Jython Clock Resolution










On Nov 17, 2007 3:50 PM,  <boblusebob@...> wrote:
> I was looking into the clock resolution for Jython and ran into something
> that doesn't seen right to me.  I ran simple tests  on Windows XP and Linux
> and came up with the following results:
>
>  Windows XP
>      Python
>          time.clock()    -   2 microseconds
>          time.time()    - 15 milliseconds
>
>      Jython
>          time.clock() - 15 milliseconds
>          time.time()    - 15 milliseconds
>
>  Linux
>      Python
>          time.clock()    - 10 milliseconds
>          time.time()    - 5 microseconds
>
>      Jython
>          time.clock() - 1 millisecond
>          time.time()    - 1 millisecond
>
>  Shouldn't time.clock() on Jython for Windows and time.time() on Linux have
> much better resolution?  I believe that if Jython used Java nanoTime it
> could reach these levels.  Am I way off base?

I don't think there's anything we can do about the resolution of
time.time.  I don't see how it could be done with System.nanoTime
since that just yields the number of nanoseconds since the first time
it was called and has no bearing on the time since the epoch.  We
could probably use nanoTime for time.clock though and get better
numbers.

>  I have simple scripts to demo this if anyone is interested, and will open a
> problem against the current code if that is where the problem is, but I
> don't know the plan for Jython to implement clock timing.

If you want to file a bug for time.clock with your scripts, I'll see
about switching it to use nanoTime.

Charlie



 


________________________________________________________________________
Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection.

On Nov 22, 2007, at 6:29 PM, Tristan King wrote:

> the problem doesn't seem to be with PyFile itself, but with the use of
> it with sockets.
>
> here's a test server and client that produces different results under
> windows jython (svn-trunk) and windows cpython2.5
>
> here's the server output (with line feeds removed)
>
> C:\testserver\jython>jython.bat server.py
> 0x61 0xd 0xd 0xa 0x61 0xd 0xd 0xa
> C:\testserver\jython>c:\Python25\python.exe server.py
> 0x61 0xd 0xa 0x61 0xd 0xa
>
> I'm looking into a fix in my spare time, but it's coming along rather
> slowly, so if anyone else knows how to fix it, please do :)
>

I'm almost positive this issue was fixed just recently in the jython  
2.2.x branch.

The problem was due to the fact that socket's makefile defaults the  
file mode to text mode. This isn't a problem with CPython because  
socket's makefile uses a fake file object that doesn't support text  
mode (so it always acts like binary mode), whereas Jython was using  
its real file object (PyFile) that does support text mode.

As of a week or so ago Jython started using the same fake file object  
CPython does, which would take care of this issue.

Thanks for the tests, you can run them on the 2.2.x branch if you  
want to verify this right now. Otherwise I'll give them a shot  
sometime tomorrow (today's a holiday) and let you know.

--
Philip Jenvey

Ok here's a different patch that solves my problem.

--- src/org/python/core/PyFile.java     (revision 3652)
+++ src/org/python/core/PyFile.java     (working copy)
@@ -546,6 +546,8 @@
         this.mode = mode;
         this.softspace = false;
         this.closed = false;
+       if (mode.contains("b"))
+               this.binary = true;
         if (universal) {
             this.file = new UniversalWrapper(file);
         } else if (!binary) {

what is happening, is that even tho 'wb' is specified, it isn't setting
the variable "binary" before it checks it. because of this, it always
uses the TextWrapper class.

This fixes up the 'wb' example i posted before, and fixes up my server,
but there are still differences between cpython2.5 and jython (cpython
doesn't replace \n's with \r\n's for sockets no matter what os.)

thoughts?

-Tristan

On Fri, 2007-11-23 at 12:29 +1000, Tristan King wrote:
> the problem doesn't seem to be with PyFile itself, but with the use of
> it with sockets.
> 
> here's a test server and client that produces different results under
> windows jython (svn-trunk) and windows cpython2.5
> 
> here's the server output (with line feeds removed)
> 
> C:\testserver\jython>jython.bat server.py
> 0x61 0xd 0xd 0xa 0x61 0xd 0xd 0xa
> C:\testserver\jython>c:\Python25\python.exe server.py
> 0x61 0xd 0xa 0x61 0xd 0xa
> 
> I'm looking into a fix in my spare time, but it's coming along rather
> slowly, so if anyone else knows how to fix it, please do :)
> 
> -Tristan
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________ Jython-dev mailing list Jython-dev@... https://lists.sourceforge.net/lists/listinfo/jython-dev

Ooops, my bad.
i just updated my svn tree, and this is fixed.
dunno why i didn't do that before :|

Thanks for the patience :)
-Tristan

On Thu, 2007-11-22 at 20:25 -0800, Philip Jenvey wrote:
> On Nov 22, 2007, at 6:29 PM, Tristan King wrote:
> 
> > the problem doesn't seem to be with PyFile itself, but with the use of
> > it with sockets.
> >
> > here's a test server and client that produces different results under
> > windows jython (svn-trunk) and windows cpython2.5
> >
> > here's the server output (with line feeds removed)
> >
> > C:\testserver\jython>jython.bat server.py
> > 0x61 0xd 0xd 0xa 0x61 0xd 0xd 0xa
> > C:\testserver\jython>c:\Python25\python.exe server.py
> > 0x61 0xd 0xa 0x61 0xd 0xa
> >
> > I'm looking into a fix in my spare time, but it's coming along rather
> > slowly, so if anyone else knows how to fix it, please do :)
> >
> 
> I'm almost positive this issue was fixed just recently in the jython  
> 2.2.x branch.
> 
> The problem was due to the fact that socket's makefile defaults the  
> file mode to text mode. This isn't a problem with CPython because  
> socket's makefile uses a fake file object that doesn't support text  
> mode (so it always acts like binary mode), whereas Jython was using  
> its real file object (PyFile) that does support text mode.
> 
> As of a week or so ago Jython started using the same fake file object  
> CPython does, which would take care of this issue.
> 
> Thanks for the tests, you can run them on the 2.2.x branch if you  
> want to verify this right now. Otherwise I'll give them a shot  
> sometime tomorrow (today's a holiday) and let you know.
> 
> --
> Philip Jenvey
> 
>