From: Frank W. <fwi...@gm...> - 2009-06-11 17:37:14
|
Hi all, I plan to re-label rc4 as final sometime next week (barring any showstopping bug reports). As part of that process I will create a maintenance branch for 2.5. I then plan to point trunk at the 2.6 CPython libs and bring over a 2.6 grammar + a handful of fixes that will be just enough to get regrtest running. I want to be more aggressive about merging from trunk back to the 2.5 branch compared to how things worked for the 2.2 maintenance branch. I'm not sure how often I want to do this, but I'd like to make svnmerge.py block and merge decisions for everything that goes into trunk. I plan to handle the merges (unless someone else feels doing some), but please don't do by hand (not svnmerge.py) merges into 2.5. If anyone wants to do hand merges into 2.2 maint, that's fine, since we never really kept up with svnmerge on that branch. I'm thinking about moving the minimum JDK for Jython 2.6 up to JDK 6 -- any objections? -Frank |
From: Steven G. <swg...@mt...> - 2009-06-11 17:57:15
|
Frank Wierzbicki wrote: > I'm thinking about moving the minimum JDK for Jython 2.6 up to JDK 6 > -- any objections? > > I realize that jdk 5 is going to hit it's end of life date fairly soon, but I'm curious if there's some functionality that was introduced in 6 that we'll depend on. ( i.e. Even if we say that the minimum is JDK 6, does it seem likely that unofficially things should still be ok on jdk 5? ) - steve ( who oddly still works on a bunch of deployments using jdk 5 ) > -Frank > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
From: Oti <oh...@gm...> - 2009-06-11 18:23:14
|
Frank, On Thu, Jun 11, 2009 at 7:37 PM, Frank Wierzbicki<fwi...@gm...> wrote: > I plan to re-label rc4 as final sometime next week (barring any > showstopping bug reports). As part of that process I will create a > maintenance branch for 2.5. I then plan to point trunk at the 2.6 > CPython libs and bring over a 2.6 grammar + a handful of fixes that > will be just enough to get regrtest running. > > I want to be more aggressive about merging from trunk back to the 2.5 > branch compared to how things worked for the 2.2 maintenance branch. > I'm not sure how often I want to do this, but I'd like to make > svnmerge.py block and merge decisions for everything that goes into > trunk. I plan to handle the merges (unless someone else feels doing > some), but please don't do by hand (not svnmerge.py) merges into 2.5. > If anyone wants to do hand merges into 2.2 maint, that's fine, since > we never really kept up with svnmerge on that branch. That makes perfect sense. > I'm thinking about moving the minimum JDK for Jython 2.6 up to JDK 6 > -- any objections? No! best wishes, Oti. |
From: Moss P. <mo...@th...> - 2009-06-11 19:03:25
|
Hi Frank, Thanks for all the hard work. I'm pinching myself at the idea of running a Jython that's on the same major version as the current CPython! On Jun 11, 2009, at 11:37 AM, Frank Wierzbicki wrote: > > I'm thinking about moving the minimum JDK for Jython 2.6 up to JDK 6 > -- any objections? > > -Frank One possible hangup is that Mac OS X seems to still have 1.5 on the PATH, although 1.6 is also installed. Anyway that's how it is on my up- to-date system, and it probably won't change at least until 10.6 in Sept. (which won't be universally adopted for a long time anyway, especially since they've dropped PowerPC support). I have no idea what Apple is thinking, but it would be a shame to require Mac users to mess with environment variables or symlinks. It's certainly frustrating that Apple continues to neglect Java; I guess we're expected to be grateful that the Steve hasn't pulled the plug entirely, right? Anyway, does anyone have a sense of what might be in 1.6 that impacts Jython? My experience has been that performance is better, but the few small additions to the library that I know about aren't much of a motivation to do a mandatory switch. - moss |
From: Josh J. <jun...@gm...> - 2009-06-11 21:05:28
|
Frank and all of the developers have done a great job! Really looking forward to the release and for the upcoming 2.6. With regards to running on JDK 6 as a minimum, it is true that OS X 10.4 only runs Java 1.5. However, isn't Snow Leopard due out this fall? That would make 10.4 two releases behind and my guess is that people still on 10.4 would be moving to 10.5 soon thereafter anyways. There's also Soylatte for those who need JDK 1.6 on Tiger. Java 6 has reached a mature state now, especially with Java 7 coming soon (maybe). Josh Juneau jun...@gm... http://jj-blogger.blogspot.com Twitter ID: javajuneau On Thu, Jun 11, 2009 at 2:03 PM, Moss Prescott <mo...@th...>wrote: > Hi Frank, > > Thanks for all the hard work. I'm pinching myself at the idea of > running a Jython that's on the same major version as the current > CPython! > > On Jun 11, 2009, at 11:37 AM, Frank Wierzbicki wrote: > > > > > I'm thinking about moving the minimum JDK for Jython 2.6 up to JDK 6 > > -- any objections? > > > > -Frank > > One possible hangup is that Mac OS X seems to still have 1.5 on the > PATH, although 1.6 is also installed. Anyway that's how it is on my up- > to-date system, and it probably won't change at least until 10.6 in > Sept. (which won't be universally adopted for a long time anyway, > especially since they've dropped PowerPC support). I have no idea what > Apple is thinking, but it would be a shame to require Mac users to > mess with environment variables or symlinks. It's certainly > frustrating that Apple continues to neglect Java; I guess we're > expected to be grateful that the Steve hasn't pulled the plug > entirely, right? > > Anyway, does anyone have a sense of what might be in 1.6 that impacts > Jython? My experience has been that performance is better, but the > few small additions to the library that I know about aren't much of a > motivation to do a mandatory switch. > > - moss > > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
From: Frank W. <fwi...@gm...> - 2009-06-12 00:52:14
|
On Thu, Jun 11, 2009 at 1:56 PM, Steven Githens<swg...@mt...> wrote: > I realize that jdk 5 is going to hit it's end of life date fairly soon, but > I'm curious if there's some functionality that was introduced in 6 that > we'll depend on. ( i.e. Even if we say that the minimum is JDK 6, does it > seem likely that unofficially things should still be ok on jdk 5? ) There are a number of features that would be nice to have around, for example the stuff in javax.tools: http://java.sun.com/javase/6/docs/api/javax/tools/package-summary.html. Another example is Gregor Lingl's implementation of turtle.py for Java, which uses some newer 2d stuff. I'm sure there are others, though it is true that the near end of life status of JDK 5 is a big part of this. BTW I expect we will be maintaining 2.5 for at least a few years, so JDK 5 people will continue to have a good option for Jython. -Frank |
From: Steven G. <swg...@mt...> - 2009-06-12 16:26:35
|
Frank Wierzbicki wrote: > On Thu, Jun 11, 2009 at 1:56 PM, Steven Githens<swg...@mt...> wrote: > >> I realize that jdk 5 is going to hit it's end of life date fairly soon, but >> I'm curious if there's some functionality that was introduced in 6 that >> we'll depend on. ( i.e. Even if we say that the minimum is JDK 6, does it >> seem likely that unofficially things should still be ok on jdk 5? ) >> > There are a number of features that would be nice to have around, for > example the stuff in javax.tools: > http://java.sun.com/javase/6/docs/api/javax/tools/package-summary.html. > Another example is Gregor Lingl's implementation of turtle.py for > Java, which uses some newer 2d stuff. I'm sure there are others, > though it is true that the near end of life status of JDK 5 is a big > part of this. > Ah, cool, those are actually really good reasons from an extra functionality viewpoint. ( Not that just upgrading stable platforms isn't a good reason. :) ) > BTW I expect we will be maintaining 2.5 for at least a few years, so > JDK 5 people will continue to have a good option for Jython. > > That sounds awesome. -Steve > -Frank > |
From: Leo S. M. <leo...@gm...> - 2009-06-12 01:12:06
|
On Thu, Jun 11, 2009 at 8:45 PM, Frank Wierzbicki<fwi...@gm...> wrote: > > BTW I expect we will be maintaining 2.5 for at least a few years, so > JDK 5 people will continue to have a good option for Jython. I think this is the stronger point. People wanting to stay on a hyper-stable really-old platform, can just use our own hyper-stable really-old releases. This applies right now for the Java1.4/Jython2.2 combination and will apply to Java5/Jython2.5 on the future. -- Leo Soto M. http://blog.leosoto.com |
From: Jim B. <jb...@zy...> - 2009-06-12 03:59:29
|
Given that the Java 5 end-of-life is October 30, I don't think we should be bending over backwards for Java 5 support in a release that we are only now just planning, and will come after at least one point release (2.5.1), if not more if we move to a more time-based release schedule. (But that's the subject of another email thread!) However, I would like to provide as many options as possible to Jython users, especially those running in a container where they can't control the specific JVM level. So a reasonable compromise might be that we will target Java 6, but Jython 2.6 runs on Java 5 with these limitations: - Require that the build be done on Java 6. - Reduced functionality will be seen. So turtle will require Java 6 so as to access the appropriate 2D API. And I should point out that we already have one dependency on Java 6 in the 2.5 release - unicodedata.normalize only works on Java 6. (However, this should be relaxed in 2.5.1 once we have a Java implementation, instead of a Python one for the unicodedata database.) - There may be bugs. We had to work around some Java 5 bugs in the rewrite of tuple/list, however, they were really in the domain of rare corner cases. Reduced functionality is a reality of a sandbox environment like the JVM. Certain things are not available when running in the context of a servlet container or Google App Engine, as just a couple of examples. This does not reduce the importance of being able to do other tasks for that same code base when not running in a restricted fashion. An alternative is that we will simply require Java 6, and backport fixes, performance optimizations, etc., for a while. This would be easier than it's against 2.2, for a number of reasons (continuous integration, same internal type system, continuing active support by core Python dev). - Jim On Thu, Jun 11, 2009 at 7:12 PM, Leo Soto M. <leo...@gm...> wrote: > On Thu, Jun 11, 2009 at 8:45 PM, Frank Wierzbicki<fwi...@gm...> > wrote: > > > > BTW I expect we will be maintaining 2.5 for at least a few years, so > > JDK 5 people will continue to have a good option for Jython. > > I think this is the stronger point. > > People wanting to stay on a hyper-stable really-old platform, can just > use our own hyper-stable really-old releases. > > This applies right now for the Java1.4/Jython2.2 combination and will > apply to Java5/Jython2.5 on the future. > -- > Leo Soto M. > http://blog.leosoto.com > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > -- Jim Baker jb...@zy... |
From: Philip J. <pj...@un...> - 2009-06-13 06:18:51
|
On Jun 11, 2009, at 10:37 AM, Frank Wierzbicki wrote: > I want to be more aggressive about merging from trunk back to the 2.5 > branch compared to how things worked for the 2.2 maintenance branch. I want to emphasize this, we should really try tackling some of the things we put off before focusing on 2.6 features. There's the obvious 2.5 bug fixes, but also ctypes, ideally unicodedata in Java, bz2, even cjkcodecs. Clamp should be of highest priority. > I'm not sure how often I want to do this, but I'd like to make > svnmerge.py block and merge decisions for everything that goes into > trunk. I plan to handle the merges (unless someone else feels doing > some), but please don't do by hand (not svnmerge.py) merges into 2.5. I think folks should be responsible for their own svnmerges -- it's your code, you know where it should go and how to merge it better than anyone =P -- Philip Jenvey |
From: Daniel <dan...@gm...> - 2009-06-13 14:23:48
|
On Sat, Jun 13, 2009 at 1:18 PM, Philip Jenvey <pj...@un...> wrote: > > There's the obvious 2.5 bug fixes, but also ctypes, ideally unicodedata in Java, > bz2, even cjkcodecs. Clamp should be of highest priority. I'm not sure what you're referring to with bz2 (zlib.py?) but I recently came across a 'post' from from Kohsuke Kawaguchi[1] (author of Hudson[2] (CI server) and other nifty stuff) where he mentions: > Apache Ant includes a Java implementation of the bzip2 stream compression algorithm. It takes more resources/time compared to gzip, but it compresses better than gzip. > > The code in Ant seems to be the best open-source Java implementation of bzip2 available today, but unfortunately it is not advertised well. So I decided to just rip the portion and repackage it. > > Obviously the code is covered by the Apache Software License. The license file is included in the jar file. > Don't know if that's any help to you, but there you go. Cheers, Daniel [1]: http://www.kohsuke.org/bzip2/ [2]: http://hudson.dev.java.net/ |
From: Frank W. <fwi...@gm...> - 2009-06-13 23:05:34
|
On Sat, Jun 13, 2009 at 2:18 AM, Philip Jenvey<pj...@un...> wrote: > > On Jun 11, 2009, at 10:37 AM, Frank Wierzbicki wrote: > >> I want to be more aggressive about merging from trunk back to the 2.5 >> branch compared to how things worked for the 2.2 maintenance branch. > > I want to emphasize this, we should really try tackling some of the things > we put off before focusing on 2.6 features. There's the obvious 2.5 bug > fixes, but also ctypes, ideally unicodedata in Java, bz2, even cjkcodecs. > Clamp should be of highest priority. Maybe I should consider not starting a 2.5 maint branch just yet then. I do need to put a 2.6 together somewhere, but maybe I'll just do that as a branch for now (I promised a just-enough-for-netbeans 2.6 within the next week or so) > I think folks should be responsible for their own svnmerges -- it's your > code, you know where it should go and how to merge it better than anyone =P That would be quite nice, I won't stop anybody :) -- maybe I should reduce this to an offer of help for anyone who is a bit hazy on svnmerge.py. -Frank |
From: Jim B. <jb...@zy...> - 2009-06-14 02:41:00
|
I think doing this work in a 2.6 branch makes more sense for now. All my feature branches currently target 2.5 (presumably 2.5.1) for some functionality, including one I still need to create (unicodedata). As I understand it, svnmerge doesn't solve the scenario where we need to merge between branches, although there are some tools that might help instead. Once we move to Mercurial, that problem goes away. Since we are planning to go to hg once core Python makes this transition, that's probably when we should make what we might call "trunk" 2.6. This transition also can involve the effort to pull core Python apart from CPython, although that might be actually 2.7... Like Phil, right now I personally am much more interested in 2.5.x since I'd like to focus on better Java integration and performance - instead of Python compatibility! - for once. - Jim On Sat, Jun 13, 2009 at 5:04 PM, Frank Wierzbicki <fwi...@gm...>wrote: > On Sat, Jun 13, 2009 at 2:18 AM, Philip Jenvey<pj...@un...> > wrote: > > > > On Jun 11, 2009, at 10:37 AM, Frank Wierzbicki wrote: > > > >> I want to be more aggressive about merging from trunk back to the 2.5 > >> branch compared to how things worked for the 2.2 maintenance branch. > > > > I want to emphasize this, we should really try tackling some of the > things > > we put off before focusing on 2.6 features. There's the obvious 2.5 bug > > fixes, but also ctypes, ideally unicodedata in Java, bz2, even cjkcodecs. > > Clamp should be of highest priority. > Maybe I should consider not starting a 2.5 maint branch just yet then. > I do need to put a 2.6 together somewhere, but maybe I'll just do > that as a branch for now (I promised a just-enough-for-netbeans 2.6 > within the next week or so) > > > I think folks should be responsible for their own svnmerges -- it's your > > code, you know where it should go and how to merge it better than anyone > =P > That would be quite nice, I won't stop anybody :) -- maybe I should > reduce this to an offer of help for anyone who is a bit hazy on > svnmerge.py. > > -Frank > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > -- Jim Baker jb...@zy... |
From: Philip J. <pj...@un...> - 2009-06-15 01:19:42
|
On Jun 13, 2009, at 6:51 AM, Daniel wrote: > On Sat, Jun 13, 2009 at 1:18 PM, Philip Jenvey > <pj...@un...> wrote: >> >> There's the obvious 2.5 bug fixes, but also ctypes, ideally >> unicodedata in Java, >> bz2, even cjkcodecs. Clamp should be of highest priority. > > I'm not sure what you're referring to with bz2 (zlib.py?) but I > recently came across a 'post' from from Kohsuke Kawaguchi[1] (author > of Hudson[2] (CI server) and other nifty stuff) where he mentions: 2.3 added a bz2 module similar to gzip/zlib. A while ago I implemented some of it using this ant bz2 lib, but the ant code lacks the ability to incrementally stream to a bz2 encoder (or was it stream from a decoder?). I found an alternative from the old jythonx project that seems to be more of a straight port of the C libbz2 lib to Java, but I don't know what state that code is in. We can either figure the jythonx code out, or do a somewhat crippled bz2 via the ant lib -- and maybe even hack it to support the streaming feature. -- Philip Jenvey |
From: Frank W. <fwi...@gm...> - 2009-06-16 02:12:28
|
I Just realized that I really need a 2.5 maint branch to properly release -- I need to work off of the rc4 tag but need to commit the release number updates, etc. It shouldn't include the work that has continued on trunk. So I think I will go ahead and target trunk to 2.6 (otherwise we end up with 3 branches). I plan to put this thing together Tuesday night or early Wednesday. I don't think there is any reason for me to announce a freeze since I'll be working off of a maint branch for the release. BTW I agree that most fixes should be targeted at issues that will move 2.5.1 along. And of course I agree that clamp is a very high priority. For my own work I'll probably stray a little from this target to get a 2.6 grammar going and to see what I can do with InvokeDynamic (though maybe we can get an indy mode in for 2.5.1....) -Frank |
From: Philip J. <pj...@un...> - 2009-06-16 02:55:01
|
On Jun 15, 2009, at 6:52 PM, Frank Wierzbicki wrote: > I Just realized that I really need a 2.5 maint branch to properly > release -- I need to work off of the rc4 tag but need to commit the > release number updates, etc. It shouldn't include the work that has > continued on trunk. The 2 commits to trunk since rc4 are not at all worth worrying about. We should just declare a freeze (we're already implicitly frozen) and go from trunk. Worst case scenario should be to just revert anything unwanted in the release. -- Philip Jenvey |