Thread: [Jython-dev] Weekly status report

Hello everyone!

I have been working in the past on several Zope components and made
some further steps to get closer to the point for running core Zope
components on Jython.

This week I have mainly spend time on getting zope.testing to work
correctly, to be able to use it to test other Zope components.
A part of the time was spent on getting several Zope components working
by modifying code and also getting a working zc.buildout for zope.testing,
which is mostly finished now.

In addition I was working on getting bootstrap.py to work on Zope, which
needed modifications to the code (process execution), but also an
implementation
for the CPython flag "-m" in Java for Jython, which is mostly done and working.
The CPython "-m" flag which is now available for Jython searches for a
given module
name "foo" in the sys.path and runs the corresponding "foo.py" file as a script.

I will upload the patch during the next week, as the code still needs
some additional
testing and maybe some clean ups.

The work was done using Jython trunk and Zope trunk with the following
results by now:

-zc.buildout:
    -builds
    -installs
    -has local changes to build and install
    -has local changes to pass several tests
    -needs stills a lot of work and modifications to pass all tests
     provided by zope.testing


-zope.configuration
    -builds
    -will need modifications and a working zope.schema

	
-zope.component:
    -builds
    -install fails, has several decorator errors and shows errors within Jython
    -will need modifications + will resolve Jython error for "from xyz
import (abc)" syntax
     which works on CPython
     e.g. valid CPython: from os import (sys)
          Jython error: SyntaxError: invalid syntax


-zope.deferredimport
    -builds
    -has local changes to build and install
    -install fails
    -> depends on zope.proxy, which is not working yet


-zope.deprecation
    -builds
    -installs
    -will need testing


-zope.event
    -builds
    -installs
    -will need testing


-zope.exceptions
    -builds
    -installs
    -will need improved and Jython specific testing


-zope.hookable
    -builds
    -installs without C extension and crashes therefore
    -will need C parts to have rewritten in Python or Java
    -will need better testing after replacing missing C parts on Jython


-zope.i18nmessageid
    -builds
    -installs without C extension and crashes threfore
    -will need C parts to have rewritten in Python or Java
    -will need better testing after replacing missing C parts on Jython


-zope.interface:
    -builds
    -installs
    -is working
    -will need C parts to have rewritten in Python or Java
    -needs additional Jython testing


-zope.proxy
    -builds
    -installs without C extension and chrashes therefore
    -will need C parts to have rewritten in Python or Java
    -will need better testing after replacing missing C parts on Jython


-zope.schema
    -builds
    -install runs partly and fails
    -has lots of errors, which will have to be fixed


-zope.testing:
    -builds
    -installs
    -needs work on the extras (e.g. zope.exceptions) within setup.py
    -needs testing and modifications to pass tests


-bootstrap.py support for Jython
    -needs the "-m" flag from CPython:
        -m module-name
        Searches sys.path for the named module and runs the
corresponding .py file as a script.

    -implementation in Java for Jython trunk, which needs some code
clean up and some improvements
     to running modules from sys.path

    -has replacement for for os.spawnle, using the subprocess module
(CPython>=2.4) and Jython trunk



During the next week, I will concentrate on working on:

-finishing zope.testing
-bootstrap.py support
-fixing errors within several of the above Zope components
-submitting -m to Jython
-starting to rewrite the C code in Java, in case that it will take a lot
of time I will come up with Python implementations for the missing parts
-try to do the majority of the work on getting the above packages bug fixed
and also pass more tests
-apply additional changes to bootstrap.py in other packages (at the
moment: zope.testing)
-start to submit code to Zope, when the main tests pass and a fully working
zope.testing is available (for now: maybe upload the changes in form
of patches on the web)


Kind regards and happy hacking, Georgy

-- 
Georgy Berdyshev

GPG key: 830F68C5
Fingerprint: 0379 ED5A BEE5 65A8 7BD5 31E7 F5B4 1EC7 830F 68C5

On Jun 8, 2008, at 8:09 PM, Georgy Berdyshev wrote:
> In addition I was working on getting bootstrap.py to work on Zope,  
> which
> needed modifications to the code (process execution), but also an
> implementation
> for the CPython flag "-m" in Java for Jython, which is mostly done  
> and working.
> The CPython "-m" flag which is now available for Jython searches for a
> given module
> name "foo" in the sys.path and runs the corresponding "foo.py" file  
> as a script.

Are you using CPython 2.5's runpy.py? I would think it would simplify  
our -m implementation quite a bit, compared to what CPython 2.4 was  
doing.

--
Philip Jenvey

On Mon, Jun 9, 2008 at 12:53 AM, Philip Jenvey <pj...@un...> wrote:
>
> On Jun 8, 2008, at 8:09 PM, Georgy Berdyshev wrote:
>>
>> In addition I was working on getting bootstrap.py to work on Zope, which
>> needed modifications to the code (process execution), but also an
>> implementation
>> for the CPython flag "-m" in Java for Jython, which is mostly done and
>> working.
>> The CPython "-m" flag which is now available for Jython searches for a
>> given module
>> name "foo" in the sys.path and runs the corresponding "foo.py" file as a
>> script.
>
> Are you using CPython 2.5's runpy.py? I would think it would simplify our -m
> implementation quite a bit, compared to what CPython 2.4 was doing.
I just became aware of runpy.py this morning looking through "what's
new in Python 2.5?" -- here are some pointers:

http://docs.python.org/whatsnew/pep-338.html

http://www.python.org/dev/peps/pep-0338/

Too bad I didn't know about this when you asked.... probably when you
send email questions it would be a good idea to cc jyhton-dev just in
case someone else knows something like this.

Of course this may be beyond the scope of you Zope work,  but it does
look like it is "the right way" to do -m.

-Frank

Hello,

I am posting here on the Jython mailing list as my GSoC project is to
make TurboGears 2 run on Jython and includes many different components.
The TurboGears project has a different approach of status reports, which are

not public, but Frank Wierzbicki asked me to post here on the list, so that
the
Jython community will be kept up to date, and I think that it is a good way
for getting suggestions and new ideas.
My mentor Philip Jenvey is a Jython developer and therefore it is a good
place
to post here on the list :) - btw TG2 should work on Jython at the end
anyway...


In the past week I have been working on two big packages:
genshi - http://genshi.edgewall.org/
and
paver - http://www.blueskyonmars.com/projects/paver/

I was also working on other parts, doing unittests and looking for
improvements,
e.g. the jython mako branch, which offers an _ast implementation and is a
good
example for future work on genshi (parsing code into AST), and also Pylons
which is working on Jython now, but still needs some further improvements.

Having a look at the unittest of those packages introduced a nice side
effect - for
example nose passes now all of its 260 tests on Jython and Jython is getting

better from day to day. Here is a last unittest fix for nose:
http://groups.google.com/group/nose-dev/browse_thread/thread/1835681dcf5964db
formencode, which is used by twforms, depends on nose.


The TurboGears developers have switched from setuptools to paver on tg2
trunk.
As far as I know there is also the possibility that the TurboGears
developers
will adopt paver for all other packages developed by them instead of
setuptools.
I have been working on paver, using the 0.8 release, but will contact the
paver
developer and try to merge the fixes into upstream.
Paver builds and installs now on Jython without failures and also many
unittests
pass and I will do additional work on them.
I had to change a small part of the distutils on Jython trunk and I think
that
I will try to port a newer version, which has the missing features, to
Jython.

TurboGears 2 trunk uses paver-minilib.zip, which is subset of paver and is
fully functional now on Jython.


The work that I did for genshi is at the moment a big construction, because
I had to look at xml.parsers.expat to know how the genshi code will behave
and also to look at xml.sax to find the appropriate parts for rewriting the
code. Some parts with xml.sax are at the moment just code snippets for
testing.

Having already collected more experience with both XML parsers will ease the
coding
later on.
xml.parsers.expat is not only used by genshi and not available on Jython,
but
also used by:

-babel
-twforms, which depends on formencode
-formencode
-formencode in elementtree mode
-elementtree
-kid, used by turbokid
-and others

Porting genshi's expat to sax will make also the porting of other parts
faster.


Next week, I will work on:
- finishing unittest fixes for simplejson, used by turbojson
- finishing paver, fixes for unittest
- trying to get paver changes upstream
- implement some missing Python lib features for Jython (paver)
- including / porting missing parts of distutils
- completing the rewritement of xml.sax genshi parser
- see for possibilities to include the new genshi parser
  code upstream (maybe genshi branch on their svn)
- start to work on AST via compiler / parser module
  -> a good example is the mako Jython branch


Ariane Paola

-- 
Ariane Paola Gomes

GPG key: F20E69CC
Fingerprint: 506B DFFE 34A4 AA0B 4157 61D8 6D1B D69E F20E 69CC