Fwd: [Jython-users] jythonshell fork

4 views
Skip to first unread message

Duncan Child

unread,
Feb 4, 2008, 7:05:49 PM2/4/08
to ijytho...@googlegroups.com
---------- Forwarded message ----------
From: Mike
Date: Feb 4, 2008 3:41 PM
Subject: Re: [Jython-users] jythonshell fork
To: Duncan


I downloaded the source, but I can't build it because it requires Java
6 and I only have Java 6. :(

Here is the actual only JDK 6-related error:
[javac] H:\Projects\ijython\src\org\leo\shell\actions\ConfigureColors.java:43:
cannot find symbol
[javac] symbol : variable ModalityType
[javac] location: class
org.leo.shell.actions.ConfigureColors.ColorEditorDialog
[javac] super(parentWindow, "Configure Shell Colors",
ModalityType.DOCUMENT_MODAL);
[javac] ^


And I'm attaching an ant build that I've tried to get to work, but I
can't say for sure -- because I get the above.

I would make these tickets in Trac, but I don't have access.

Oh yeah -- thanks for forking the project! I'm in to bang on ijython.

On Feb 3, 2008 4:25 PM, Duncan Child <duncan...@gmail.com> wrote:

>
>
>
> A couple of people were asking about a possible fork of the
> discontinued jythonshell project.
>
> We started work on one a few weeks ago -
> http://wush.net/trac/geocraft/wiki/InteractiveJython
>
> It works with the latest version of jython.
>
> There is a unrelated jythonshell project at
> http://code.google.com/p/jythonshell/ so I am planning to rename
> leouser's version ijython.
>
> Would be interested in feedback, comments and suggestions.
>
> Regards,
>
> Duncan
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Jython-users mailing list
> Jython...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jython-users
>

build.xml

Duncan Child

unread,
Feb 4, 2008, 11:09:23 PM2/4/08
to ijytho...@googlegroups.com
Dan,

I tried compiling it using 1.5 and it does indeed barf on the Window
and the enum.

You can replicate this in Eclipse. Let me know if you can't find how
to do this - it was not very intuitive.

What version of Java should we try and support? I haven't tried it
with 1.4 but I guess it would have many more issues and may not be
worth it.

Mike,

We haven't tried Hudson though it does look cool. We are currently
evaluating Atlassian's tools for another project and will most likely
use the same for ijython.

Duncan


---------- Forwarded message ----------
From: Mike
Date: Feb 4, 2008 9:59 PM
Subject: Re: [Jython-users] jythonshell fork
To: Duncan


Yes I meant Java 5, not 6. And we still have tons of projects on Java
1.4.2 so there isn't going to be a change to Java 6 anytime soon.

I really wouldn't ask but the JDialog thing is the only item at the
moment that seems Java 6-specific.

As far as continuous builds go, are you familiar with Hudson? That's
what we use at work -- it's wonderful.

On Feb 4, 2008 6:17 PM, Duncan wrote:

> Hi Mike,
>
> Thanks for the build file. We will use it when we hook up the
> continuous builds later this week.


>
>
> > it requires Java 6 and I only have Java 6. :(
>

> Did you mean 5? Do you think that it will be necessary for us to
> support 5 or will you move to 6 fairly soon?
>
> It looks like we are just using an improved api for JDialog so it
> wouldn't be hard to change it. Dan any thoughts?
>
> Regards,
>
> Duncan

Dan Dromereschi

unread,
Feb 5, 2008, 5:19:52 AM2/5/08
to ijytho...@googlegroups.com, hoste...@gmail.com
Hi Duncan, Mike,

I think we should have ijython Java 5 and later compatible. It is already Java 5 compatible as I've removed the ModalityType usage. I tested it with the latest Java 5 Update 14 and it compiles and runs fine now.

The code base we inherited was not Java 1.4.2 compatible. It uses a lot of generics, for each, enums, java.util.concurrency and probably other APIs that is only available from Java 5. I think it would be a lot of effort to fix all these.

Regards,

Dan

Duncan Child

unread,
Feb 5, 2008, 2:27:45 PM2/5/08
to Daniel Abel, jython...@lists.sourceforge.net, ijytho...@googlegroups.com
Hi Daniel,

Comments below ....

On Feb 5, 2008 8:50 AM, Daniel Abel <ab...@freemail.hu> wrote:


> On Sun, Feb 03, 2008 at 04:25:52PM -0600, Duncan Child wrote:
> > A couple of people were asking about a possible fork of the
> > discontinued jythonshell project.
> >
> > We started work on one a few weeks ago -
> > http://wush.net/trac/geocraft/wiki/InteractiveJython
> >

> > Would be interested in feedback, comments and suggestions.
>

> Do you intend to keep the 'embed gui widgets into the terminal output'
> aspect of it? judging by the screenshot, you will be using it the same
> way I was going to: on a small tab that shows only a few lines in an
> app. For such use, I found the embedded gui widgets that appear when
> doing "foo?" etc. kinda frustrating because they use up much more
> screen real-estate than, say, IPython's pure-text output.

Maybe it could be a configurable display option? iJython should
probably leverage Swing when it makes sense though.

Right now, the only concrete request we have from our users is to make
the color scheme configurable :-)

I would like to spend the next few weeks on setting up a continuous
build, adding some tests etc. before adding new features.

>
> among 'minor enhancements' you list
> 'autocomplete doesn't work for foo.bar().[what is next?]'
> How do you intend to do that and why do you think that is 'minor'?
> (IPython can't autocomplete in such situations, and in fact, it might
> be pretty much impossible: due to python's dynamic typing, you don't
> know what kind of object a function will return without either calling
> the function or doing some really intricate type-guessing. I don't
> think either of those would be an acceptable solution.)

We were thinking about improving the introspection of java objects not
python ones.

>
> I second the question about the licence. I guess a BSD-like would be the
> most appropriate. (i.e. one allowing use in closed-source apps).

Yes. The license will be BSD - like.

>
> And I'm looking forward to collaborate on this,

Thanks,

Duncan

> Daniel Abel
> ab...@freemail.hu
>

Reply all
Reply to author
Forward
0 new messages