On Mar 2, 2007, at 3:06 PM, Charles Oliver Nutter wrote:
> I'd personally like to also see a roundup of what Leo's working on as
> part of this talk at JavaOne. While the primary Jython train is
> chugging
> toward complete 2.2 compatibility, Leo may make some good progress on
> the more wild and crazy side of things. The two versions presented
> together could help show there's a lot of action in the Jython world.
Speaking of action in the jython world, Jim Baker and Michael Taylor
also spent a good bit of time at the sprints trying to see what
leverage they could get out of ANTLR towards more 2.5 language
features. There may be fun things in there to include too.
-Eric

Im working on getting "jythonx" founded. I finished
up on the 2nd pass through of "new style/java class"
integration. Its been a pretty interesting journey so
far, its somewhat fun to see stuff like:
class a(swing.JLabel, int):
pass
actually work. I quickly ran into the fun of
deciphering why "remove" on a JFrame was tossing an
ArrayOutOfBoundsException. Since the instance of "a"
is also an "int", the first pass in deciding what
method to call successfully turned the object into an
Integer and called:
remove(int i)
instead of
remove(Component c)
I had to laugh about this one. Multiple inheritence
still seems to be the tool of the mad.
Ive got the code up on svn, but the project hasn't
entered the "visibility/project approved" stage yet so
its still my secret. :D Its going to be an
incremental project, which means dependance on vanilla
jython for bootstraping the new code is going to exist
for a duration.
One thing that became clear is that the JVM is
adequate for many things, it doesn't seem adequate
enough for this type of integration. "Hotswapping" as
a JVM feature really seems important. When a new
class is generated, the only sensible strategy seems
to be conservative in what methods are overriden. In
this case that means only overriding methods that
correspond to jython defined ones. Taking the blunt
approach of doing all the methods, eats memory like a
pig. Classic classes appear to follow this
conservative path. But it still relegates mutation to
second class status:
class a(swing.JLabel, object): pass
#Ok class is generated, without any overriden methods.
def zooba(self):
return "ZOOBA"
a.getText = zooba
i = a()
i.getText()
#This works here but:
jf = swing.JFrame()
jf.add(i)
#The getText method doesn't get called
Now if we had "hotswapping", we could keep the
conservative path and add the added methods as they
happen. An alternative Ive been spinning around is if
there was some form of cheap pre-call method that
could be used. If each Jython/Java class had to just
add:
Object premptiveMethod(String methodName, Object[]
args){
}
which would be called before each Jython/Java method
invocation and had the chance to prempt that call and
takes its place, maybe life without hotswapping would
be ok. I think that would certainly eliminate any
need to override most methods in a generated
Jython/Java class. It also would eliminate the need
to watch when methods were added or removed, which
would be needed if there was a hotswapping approach
used.
leouser
--- Charles Oliver Nutter <charles.nutter@...>
wrote:
> Oti wrote:
> > Frank,
> >
> > I plan to publish drafts of them as soon as
> possible, to get the
> > review of you all.
> >
> > What I particularly would appreciate at the moment
> are:
> > - statements about the current development status
> > - statements about the future
> > of Jython.
> >
> > So please feel free to send your comments to me,
> I'll do my best to
> > weave them in.
>
> I'd personally like to also see a roundup of what
> Leo's working on as
> part of this talk at JavaOne. While the primary
> Jython train is chugging
> toward complete 2.2 compatibility, Leo may make some
> good progress on
> the more wild and crazy side of things. The two
> versions presented
> together could help show there's a lot of action in
> the Jython world.
>
> - Charlie
>
>
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get
> the chance to share your
> opinions on IT & business topics through brief
> surveys-and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Jython-dev mailing list
> Jython-dev@...
>
https://lists.sourceforge.net/lists/listinfo/jython-dev
>
____________________________________________________________________________________
Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index

A very good point. I haven't been reading the Jython emails lately.
What is Leo up to? -Frank
On Mar 2, 2007, at 2:06 PM, Charles Oliver Nutter wrote:
> Oti wrote:
>> Frank,
>>
>> I plan to publish drafts of them as soon as possible, to get the
>> review of you all.
>>
>> What I particularly would appreciate at the moment are:
>> - statements about the current development status
>> - statements about the future
>> of Jython.
>>
>> So please feel free to send your comments to me, I'll do my best to
>> weave them in.
>
> I'd personally like to also see a roundup of what Leo's working on as
> part of this talk at JavaOne. While the primary Jython train is
> chugging
> toward complete 2.2 compatibility, Leo may make some good progress on
> the more wild and crazy side of things. The two versions presented
> together could help show there's a lot of action in the Jython world.
>
> - Charlie
>
> ----------------------------------------------------------------------
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Jython-dev mailing list
> Jython-dev@...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
--
Frank Cohen, PushToTest, http://www.PushToTest.com, phone 408 374 7426
TestMaker: The open-source SOA test automation tool

Oti wrote:
> Frank,
>
> I plan to publish drafts of them as soon as possible, to get the
> review of you all.
>
> What I particularly would appreciate at the moment are:
> - statements about the current development status
> - statements about the future
> of Jython.
>
> So please feel free to send your comments to me, I'll do my best to
> weave them in.
I'd personally like to also see a roundup of what Leo's working on as
part of this talk at JavaOne. While the primary Jython train is chugging
toward complete 2.2 compatibility, Leo may make some good progress on
the more wild and crazy side of things. The two versions presented
together could help show there's a lot of action in the Jython world.
- Charlie

Hello Tim.
Thanks for "trying to get involved". I'm new to this project too
(which means the project's veterans will correct me if I've
misunderstood). I think you've run into a sticky problem. Jython
has two separate "compilers" -- 1) the runtime interpreter which is
getting some active attention, and 2) jythonc which is not getting
attention. The larger problem is that the jython community is too
small at the moment to support two separate compilers and jythonc is
collecting dust (it doesn't support generator expressions, for example).
It doesn't sound like anyone has enough energy to try and fix
jythonc, based on what I heard at the sprint. The preferred
alternative would be to re-use the runtime compiler in a batch mode.
That compiler is already creating .class files. It should be
possible to use it to compile a bunch of jython code into .class
files and then bundle them in a .jar so that jython code could be
used by regular java classes. As far as I know, no one has taken
ownership of that particular bit of work, though. Would you be
interested in looking into it?
Take care.
-Eric
ps. Many thanks for coming to the BOF and for following up with your
email. Every little bit of support and energy is helpful.

On 3/2/07, Oti <ohumbel@...> wrote:
> Frank,
>
> I plan to publish drafts of them as soon as possible, to get the
> review of you all.
>
> What I particularly would appreciate at the moment are:
> - statements about the current development status
> - statements about the future
> of Jython.
>From discussing the roadmap with other Jythoners at PyCon -- we are
trying to target spring as the time to get to a 2.2 final. Beyond 2.2
things are still quite fuzzy -- but it will certainly take far less
time to get the next release out when compared to the 2.1->2.2 phase.
CPython has been adding features much more slowly since 2.2, and we
already have many (if not most) 2.3 features implemented.
-Frank

On 3/2/07, James Abley <james.abley@...> wrote:
> The main reason (that I've encountered so far, but I haven't written
> any real code) is what feels like the slow rhythm of test, code, test.
> Having to run a full build and then run the specific test case each
> time is a lot slower than I'm used to and in an ideal situation, the
> feedback loop is a lot shorter. But maybe that's just me.
You shouldn't have to run a full build each time -- you could do the
default developer build, which should only operate on the files you
have changed.
-Frank

On Fri, Mar 02, 2007 at 06:13:29PM +0000, James Abley wrote:
> The main reason (that I've encountered so far, but I haven't written
> any real code) is what feels like the slow rhythm of test, code, test.
> Having to run a full build and then run the specific test case each
> time is a lot slower than I'm used to and in an ideal situation, the
> feedback loop is a lot shorter.
Isn't the slow step there the full build step, not the running of the
actual test?
--amk

The main reason (that I've encountered so far, but I haven't written
any real code) is what feels like the slow rhythm of test, code, test.
Having to run a full build and then run the specific test case each
time is a lot slower than I'm used to and in an ideal situation, the
feedback loop is a lot shorter. But maybe that's just me.
I appreciate and applaud the rationale for using Python tests, but I
was curious as how other people feel when developing Jython.
Cheers,
James
On 02/03/07, Oti <ohumbel@...> wrote:
> Hi all,
>
> on behalf of JUnits:
>
> there are some Java JUnit tests in the installer part.
> And in fact I usually write a JUnit test in the core part, too.
>
> But I didn't want to introduce them for 2.2.
>
> There are some strong pro's and con's, especially regarding the
> existing test base (as Frank pointed out).
>
> If possible, I'd like to discuss this face to face with those
> developers I'm going to meet at JavaOne.
>
> best wishes,
> Oti.
>
> On 3/2/07, Frank Wierzbicki <fwierzbicki@...> wrote:
> > On 3/1/07, James Abley <james.abley@...> wrote:
> > > 1. JUnit / TestNG / ANOther isn't used - just CPython tests.
> > There is a set of Jython-specific tests that use a Jython-custom
> > framework -- see the "bugtests" directory which is a sibling directory
> > of "src". Someday I'd like to get these tests to be somehow based on
> > unittest -- but I think this will be a large task.
> >
> > -Frank
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Jython-dev mailing list
> > Jython-dev@...
> > https://lists.sourceforge.net/lists/listinfo/jython-dev
> >
>

On 02/03/07, A.M. Kuchling <amk@...> wrote:
> On Thu, Mar 01, 2007 at 09:03:42PM +0000, James Abley wrote:
> > Apparently, they aren't interested in fixing the issue in the older
> > releases, since 2.5 is the current good release. Obviously, I don't
>
> I have commit privileges to the CPython SVN. Older release or not,
> I'm happy to commit any changes to the 22-maint branch that will
> enable the tests to be used with Jython.
>
> > c) I'd prefer to use unittest anyway, rather than the custom framework
> > that test_unicodedata.py currently uses.
>
> Note that converting tests to unittest is an ongoing task for CPython,
> so, if this hasn't already been done in the current trunk, please
> contribute the patch back to CPython.
I can write the tests, but I have no intention of writing C to fix CPython!
Thanks.
>
> --amk
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Jython-dev mailing list
> Jython-dev@...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Hi all,
on behalf of JUnits:
there are some Java JUnit tests in the installer part.
And in fact I usually write a JUnit test in the core part, too.
But I didn't want to introduce them for 2.2.
There are some strong pro's and con's, especially regarding the
existing test base (as Frank pointed out).
If possible, I'd like to discuss this face to face with those
developers I'm going to meet at JavaOne.
best wishes,
Oti.
On 3/2/07, Frank Wierzbicki <fwierzbicki@...> wrote:
> On 3/1/07, James Abley <james.abley@...> wrote:
> > 1. JUnit / TestNG / ANOther isn't used - just CPython tests.
> There is a set of Jython-specific tests that use a Jython-custom
> framework -- see the "bugtests" directory which is a sibling directory
> of "src". Someday I'd like to get these tests to be somehow based on
> unittest -- but I think this will be a large task.
>
> -Frank
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Jython-dev mailing list
> Jython-dev@...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Frank,
I plan to publish drafts of them as soon as possible, to get the
review of you all.
What I particularly would appreciate at the moment are:
- statements about the current development status
- statements about the future
of Jython.
So please feel free to send your comments to me, I'll do my best to
weave them in.
Thanks in advance !
Oti.
On 3/2/07, Frank Wierzbicki <fwierzbicki@...> wrote:
> On 3/2/07, Charles Oliver Nutter <charles.nutter@...> wrote:
> > Now let's see what you Jythonistas can get done by May :)
> Sounds like there is going to be so much good stuff! It turns out
> that I can't make it for a number of personal and work-related reasons
> :(
>
> Please publish slides for those of us who can't make it!
>
> -Frank
>

On 3/1/07, James Abley <james.abley@...> wrote:
> 1. JUnit / TestNG / ANOther isn't used - just CPython tests.
There is a set of Jython-specific tests that use a Jython-custom
framework -- see the "bugtests" directory which is a sibling directory
of "src". Someday I'd like to get these tests to be somehow based on
unittest -- but I think this will be a large task.
-Frank

On 3/2/07, Charles Oliver Nutter <charles.nutter@...> wrote:
> Now let's see what you Jythonistas can get done by May :)
Sounds like there is going to be so much good stuff! It turns out
that I can't make it for a number of personal and work-related reasons
:(
Please publish slides for those of us who can't make it!
-Frank

On 3/1/07, James Abley <james.abley@...> wrote:
> Hi all,
> 1. JUnit / TestNG / ANOther isn't used - just CPython tests. How well
> do people find that works with regard to refactoring?
Personally, I prefer unittest to Java-based unit testing. I think
that making the CPython unit tests better for cross-implementation
testing is a place where we (the Jython development community) can
really make a contribution back to CPython.
> 2. At least for unicodedata, the existing 2.3 CPython tests aren't
> quite what I'd like. CPython 2.3 and 2.4 unicodedata contains at
> least one bug, which has been confirmed by via private email
> discussion with one of the CPython developers (Martin von L=F6wis).
> Apparently, they aren't interested in fixing the issue in the older
> releases, since 2.5 is the current good release. Obviously, I don't
> intend to create the same bug in any implementation I provide, but
> that means that the 2.3 CPython tests won't pass. So, I would like to
> change those tests for three reasons.
> a) They aren't sufficiently granular.
> b) They are wrong.
> c) I'd prefer to use unittest anyway, rather than the custom framework
> that test_unicodedata.py currently uses.
I have no problem with pulling the 2.5 test in early (although not for
the 2.2 release) -- especially since we are going to up our target for
the next release to either 2.4 or 2.5. As AMK points out any
improvements we make to the CPython unittests can and should be
contributed back.
-Frank

On Thu, Mar 01, 2007 at 09:03:42PM +0000, James Abley wrote:
> Apparently, they aren't interested in fixing the issue in the older
> releases, since 2.5 is the current good release. Obviously, I don't
I have commit privileges to the CPython SVN. Older release or not,
I'm happy to commit any changes to the 22-maint branch that will
enable the tests to be used with Jython.
> c) I'd prefer to use unittest anyway, rather than the custom framework
> that test_unicodedata.py currently uses.
Note that converting tests to unittest is an ongoing task for CPython,
so, if this hasn't already been done in the current trunk, please
contribute the patch back to CPython.
--amk

Oti wrote:
> Charles,
>
> my talk was accepted - great !
> Am I right that this decision was considerably influenced by you ?
>
> Thank you very much !
> I'm looking forward to it (20 days left to write).
Well really all I did was offer to give up one of my JRuby talks so that
your Jython talk could be included. The JavaOne committee agreed to
those terms and made it happen.
Now let's see what you Jythonistas can get done by May :)
- Charlie

Alan,
at the moment I get one difference in bugtests/test392.
I'm still on it.
Oti.
On 2/28/07, Oti <ohumbel@...> wrote:
> Alan,
>
> I found 2 occurrences in
> org.python.core.PrecompiledImporter
> org.python.core.Py
> and the comments around there strongly indicate that these are
> precompiled classes.
>
> On the other hand, there is code in
> Tools/jythonc/PythonModule.py
> where an inner class named _PyInner is added.
> Since inner classes are separated by a $ sign from the surrounding
> class, something ending in $_PyInner.class is very likely to result.
>
> See also:
> http://sourceforge.net/tracker/index.php?func=detail&aid=480373&group_id=12867&atid=112867
>
> It is almost impossible for me to detect other secret class name endings.
>
> There is a comment in PathPackageManager saying
> /*
> * Figure out if we have a directory a mixture of python and
> * java or just an empty directory (which means Java) or a
> * directory with only Python source (which means Python).
> */
>
> So, from a high level view, your approach of preventing
> $_PyInner.class from indicating a mixture (leading to java) seems
> right.
>
> Regarding your concerns about really mixing java packages and python
> modules, I believe we should not get too paranoid about that. IMHO
> common sense will prevent people from messing with such a setup.
>
> I suggest I run the tests with and without your patch, and if I do not
> encounter strange effects, it'll get in.
>
> Thanks again!
> Oti.
>
>
>
> On 2/28/07, Alan Field <Alan.Field@...> wrote:
> > Oti,
> >
> > Thanks a lot. Finding the debug messages was really a big help. I did not know about them until I found them in the source code, and then checked the registry file. The messages helped to narrow down which method was behaving incorrectly. Good luck finding the other jythonc file extensions. I haven't had any luck so far.
> >
> > The more I think about this, the more I am concerned though. Basically my import was failing because the directory was being flagged as both a Java and Python package. Adding the test for "$_PyInner.class" will fix my situation, but it seems like the import will still fail if I have a Java class in the default package in the same directory as a Python "__init__.py" file. I'll try an experiment to see if this is true, but I think this is a scenario that should work.
> >
> > Thanks,
> > Alan
> >
> > -----Original Message-----
> > From: Oti [mailto:ohumbel@...]
> > Sent: Wednesday, February 28, 2007 3:27 PM
> > To: Alan Field
> > Cc: Charlie Groves; jython users; Jython-Dev
> > Subject: Re: [Jython-users] Problems with import and Jython 2.2 Beta1...
> >
> > Alan,
> >
> > my compliments - great analysis !
> >
> > Unfortunately I do not know enough about jythonc to give a list of possible class file endings. I'll check if I can find the $_PyInner.class somewhere in the code and deduce the rest from it.
> >
> > best wishes,
> > Oti.
> >
>