Re: Next release
Stuart Ballard wrote: On the other hand, well spotted (I think?) that 0.9.x might be considered a lower version that 0.21 by packaging tools. dpkg --compare-versions appears to think so, if I'm understanding how tg use it right. This may be moot though as the debian classpath package already has an epoch on it; I don't know how rpm handles this kind of issue. rpm has epoch too. Cheers, Gary
Re: milestone for release 1. was Next release
Hi Raif, On Wed, 2006-03-01 at 05:51 +1100, Raif S. Naffah wrote: what is the expected milestone (definition and how to measure it) to reach before releasing a version 1 --or 1.4 whatever that final number will be? According to our homepage it is: GNU Classpath 1.0 will be fully compatible with the 1.1 and largely compliant with the 1.2 API specification and will have a stable API for interacting with virtual machines. Which I think we have now (plus lots of additional 1.3, 1.4 and 1.5 stuff). Personally I think 1.0 is when we feel it isn't just some experimental code anymore, but that people can use GNU Classpath for real world applications, and we feel comfortable supporting those users. Which also has been true (for years). Just look at any recent distribution. Seeing all the comments to my simple question what should the next snapshot release version be? I get the feeling 1.0 means a lot of different things to a lot of different people. That was really why I just suggested to drop the 0. from our version number (21), or use date based version numbers (6.03). I thought we could avoid a discussion about the semantics of 1.0, while still showing how mature our product is. Guess I was wrong :) I actually think the projects based on GNU Classpath (gcj, kaffe, ikvm, cacao, jamvm, ovm, jikesrvm, sablevm, jnode, etc.) is what it is all about. And funnily enough most of those projects, except ikvm and jnode, have a version numbers (much) higher than 1.0 (cacao is almost at 1.0, with their latest 0.95 release). Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: milestone for release 1. was Next release
hello Mark, On Wednesday 01 March 2006 22:23, Mark Wielaard wrote: On Wed, 2006-03-01 at 05:51 +1100, Raif S. Naffah wrote: what is the expected milestone (definition and how to measure it) to reach before releasing a version 1 --or 1.4 whatever that final number will be? According to our homepage it is: GNU Classpath 1.0 will be fully compatible with the 1.1 and largely compliant with the 1.2 API specification and will have a stable API for interacting with virtual machines. Which I think we have now (plus lots of additional 1.3, 1.4 and 1.5 stuff). i was, and still am interested, in getting a common consensus on what would constitute a non 0. release! Personally I think 1.0 is when we feel it isn't just some experimental code anymore, but that people can use GNU Classpath for real world applications, and we feel comfortable supporting those users. Which also has been true (for years). Just look at any recent distribution... i would like to see a more quantifiable description of when we can say we reached that 1.0 release level. measuring a difference against the API of the JDK 1.4 is not enough, IMHO, as a target milestone. i do agree with you that applications, and i would add tools, would be a better measure of our readiness for a 1.0 release. having a specific list of (JDK) tools we must have, and applications that must run with no errors or problems, will determine: a. the API implementations we have to have --does not matter then how close or far we are from the 100% API match. b. the bugs we have to squash, and c. the Mauve tests we have to monitor to ensure no regressions are introduced. and consequently if we have a 1.0 release, or how far we are from having one. cheers; rsn pgpRYBMBiT47V.pgp Description: PGP signature
Re: Next release
- Decide on the version number. We had a very small/brief discussion about this during Fosdem. Everybody seems to agree 0.x really doesn't do justice to the maturity we have reached over the years. And it is really hard to define when we hit 1.0. So the proposal is to keep using a sequence version number. Either just drop the 0. and make the next release-number classpath-21, or adopt a year.month style version number and make the next version number classpath-6.3 for the March 2006 release. In either case we will just use a code name for a release that has some special feature set that we are proud of, but we will always just increase the release snapshot number. Suggestions or Opinions? I think the best wold be, if GNU Classpath 1.0 is 100% compatible to Java 1.4 and GNU Classpath 2.0 would be 100% compatible to Java 1.5. The reason: Dates are also nice version numbers. But they don't seem for me like versions. The packages at http://builder.classpath.org/dist/ can be becomming names like classpath-06-03-01.tar.gz and so on (which would be nice, because at the moment all snapshots have the same name), but not releases. Calling a mostly 1.4 compatible GNU Classpath 1.4.x and a mostly 1.5 compatible GNU Classpath 1.5.x, is something I don't like. This means, that after 0.20 comes 1.4. That is a big step, which firms for commercial products do (somebody says to me, that there existing a commercial program, which begins with the version number 2.1), but not for an OpenSource-product. GNU Classpath is not compatible to Java. In the current version of GNU Classpath are classes, which are at first in Java 1.5 and there are other classes, which existing since Java 1.4, which are still not compatible to Suns Java. So, GNU Classpath isn't Suns Java. And it makes in my eyes no sense, to give it the same version numbers like Suns Java. If anybody want to know to which Java-version GNU Classpath is compatible, everybody can read the GNU Classpath release notes or look at the proberty java.version. The most people who looks at GNU Classpath are knowing about it. They don't need a version number like Suns one. But a 1.0 if GNU Classpath seems to be really 100% compatible to Java 1.4 would be nice. But until this, there is still a long way. It's a pity, that there existing no JavaVM, which used GNU Classpath and want's to be J2SE 1.4 certified. So, the step to GNU Classpath 1.0 would be by looking, if all Java 1.4 programs which everybody know can be running with GNU Classpath. To give a Java 1.5 compatible GNU Classpath the version 2.0 is in my eyes justifiable, because with new features like generics, it needs new Compiler and new JVMs. And to find the time to give GNU Classpath the version 2.0 would be much easier. Because Apache Harmony wants to be J2SE 1.5 certified, GNU Classpath can be known 2.0 as soon as Harmony have its certification. Greatings theuserbl
Re: Next release
theUser BL wrote: I think the best wold be, if GNU Classpath 1.0 is 100% compatible to Java 1.4 and GNU Classpath 2.0 would be 100% compatible to Java 1.5. Why not take a lesson from Sun: Classpath 1.0 implements JDK 1.1 Classpath 2.0 implements Java 2 aka JDK 1.2 Classpath 3.0 implements JDK 1.3 (does anyone remember what was new in 1.3?) Classpath 4.0 imlements JDK 1.4 Classpath 5.0 implements Java 5 aka JDK 1.5 Classpath 6.0 implements Java 6 aka JDK 1.6 So we can release Classpath 1.0 now (after a little more testing) and Classpath 2.0 in half a year, maybe. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Next release
On Mon, 2006-02-27 at 23:09 +0100, Mark Wielaard wrote:
Hi Andrew,
On Mon, 2006-02-27 at 21:42 +, Andrew John Hughes wrote:
On Mon, 2006-02-27 at 17:54 +0100, Mark Wielaard wrote:
- Remerge CVS trunk with the generics branch
(I don't know whether Andrew has had time for that since his Math
work. Please yell and scream if you need help with this Andrew.)
It's mostly there. I expected to have it in during the weekend, but the
merge included a few classes that differ significantly between the
branches and had to be merged manually (e.g. the Character changes,
changes to the collection classes).
Thank you!
There are also the two divergences that I introduced during the last
release (EventSetDescriptor and Hashtable)
http://lists.gnu.org/archive/html/classpath-patches/2006-01/msg00254.html
And which I never cleaned up... Apologies.
Again, please say if you need/want any help.
You were right to drop them at the time; the Hashtable is the main
collections class I was referring to above, and the beans one was also a
fairly manual job.
It then just needs to be brought up to date with the patches inbetween
Saturday and the point where the release is called.
Roman wanted some more time to stabilize so lets just pick Saturday as
the day we freeze (meaning, when the release branch is created). Then
only patches going on this release-branch should also be added to the
generics branch (I can take care of this).
The release branch will make this a lot easier, given that we then just
need to merge the patches between the tag I created on Saturday and the
branch.
- Make builder produce a real classpath-generics dist again.
(I'll try to take a look at that tonight.)
Would be great to see that.
Done. But in a bit hacky way. We have a regression in gcj-svn-trunk it
seems. Running the build under gdb show our friend doubleParse() again:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1236678656 (LWP 15045)]
_Jv_lshift (ptr=0xbfffdb74, b=0xbfffde68, k=1073257029)
at ../../../../../../trunk/libjava/classpath/native/fdlibm/mprec.c:469
469 *x1++ = 0;
(gdb) bt
#0 _Jv_lshift (ptr=0xbfffdb74, b=0xbfffde68, k=1073257029)
at ../../../../../../trunk/libjava/classpath/native/fdlibm/mprec.c:469
#1 0xb789183a in _Jv_strtod_r (ptr=0xbfffdb74,
s00=0xbfffdac0 1.570796251296997, se=0xbfffe4cc)
at ../../../../../../trunk/libjava/classpath/native/fdlibm/strtod.c:479
#2 0xb6efd82a in java::lang::VMDouble::parseDouble (str=0x0)
at ../../../trunk/libjava/java/lang/natDouble.cc:209
#3 0x in ?? ()
For now I just installed a fake ecj under /usr/local that just uses
the gij-4.0 as runtime. Unfortunately gcj-4.0 is unable to compile to
native (either from source or from byte-code), both issues (accessing
inner-class-super-fields and the gcj-byte-code-verifier) seem to be
fixed in gcj-4.1, but that hasn't been released yet. I'll install 4.1 on
builder when it is actually officially released and will then try to
create a new native-ecj binary again.
The only native ecj I've had working reliably has been the one in
Debian. I still haven't got it working on x86_64, but then that's
probably because I need to do it manually, and install a more recent gcj
than comes with unstable. I might give 4.1 a try when it's released.
Cheers,
Mark
Cheers,
--
Andrew :-)
Please avoid sending me Microsoft Office (e.g. Word, PowerPoint)
attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
If you use Microsoft Office, support movement towards the end of vendor
lock-in:
http://opendocumentfellowship.org/petition/
Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn.
-- Richard Stallman
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }
Re: Next release
Hi there, I had a look at the mauve regressions. Here are my comments so far: -PASS: gnu.testlet.javax.swing.JLabel.Icon (number 6) -PASS: gnu.testlet.javax.swing.JLabel.Icon (number 7) +FAIL: gnu.testlet.javax.swing.JLabel.Icon (number 6) +FAIL: gnu.testlet.javax.swing.JLabel.Icon (number 7) I fixed this. This was caused by the regressions in SwingUtilities.layoutCompoundLabel below. -PASS: gnu.testlet.javax.swing.text.AbstractDocument.BranchElement.getElementIndexNullPointer (number 1) +FAIL: gnu.testlet.javax.swing.text.AbstractDocument.BranchElement.getElementIndexNullPointer: AbstractDocument.BranchElement.getElementIndex should throw NPE when it has no children (number 1) Fixed. I added some more tests and fixed up the Branch- and LeafElement. +FAIL: gnu.testlet.javax.swing.text.AbstractDocument.ElementChange: uncaught exception: java.lang.NullPointerException This is strange and non-trivial. Could probably make removing stuff in JTextAreas impossible. Must investigate more. +FAIL: uncaught exception loading gnu.testlet.javax.swing.text.DefaultStyledDocument.ElementBuffer.StyledDocument2: java.lang.NullPointerException +FAIL: uncaught exception loading gnu.testlet.javax.swing.text.DefaultStyledDocument.ElementBuffer.StyledDocument3: java.lang.NullPointerException Well, these are weird. But the ElementBuffer is still shaky and we probably won't get these fixed for 0.21 (or whatever it will become). -PASS: gnu.testlet.javax.swing.text.MaskFormatter.MaskFormatterTest: valid output (number 7) +FAIL: gnu.testlet.javax.swing.text.MaskFormatter.MaskFormatterTest: uncaught exception at valid output number 2: java.lang.NullPointerException Haven't looked at it yet. -PASS: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: TC-text (number 3) +FAIL: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: TC-text (number 3) -PASS: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: TR-text (number 3) +FAIL: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: TR-text (number 3) -PASS: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: CL-text (number 2) +FAIL: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: CL-text (number 2) -PASS: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: CC-text (number 2) -PASS: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: CC-text (number 3) +FAIL: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: CC-text (number 2) +FAIL: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: CC-text (number 3) -PASS: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: CR-text (number 3) +FAIL: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: CR-text (number 3) -PASS: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: BC-text (number 3) +FAIL: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: BC-text (number 3) -PASS: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: BR-text (number 3) +FAIL: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: BR-text (number 3) Fixed completely. Some tests were not quite right (checking for fixed value when they should take font metrics into account), but some were real regressions which are fixed now. -PASS: gnu.testlet.javax.swing.plaf.metal.MetalComboBoxUI.getDisplaySize (number 2) -PASS: gnu.testlet.javax.swing.plaf.metal.MetalComboBoxUI.getDisplaySize (number 3) -PASS: gnu.testlet.javax.swing.plaf.metal.MetalComboBoxUI.getDisplaySize (number 4) +FAIL: gnu.testlet.javax.swing.plaf.metal.MetalComboBoxUI.getDisplaySize (number 2) +FAIL: gnu.testlet.javax.swing.plaf.metal.MetalComboBoxUI.getDisplaySize (number 3) +FAIL: gnu.testlet.javax.swing.plaf.metal.MetalComboBoxUI.getDisplaySize (number 4) These particular tests pass here, but number#5 fails. But according to the comment in the testcase this is a strange issue anyway. -PASS: gnu.testlet.javax.swing.plaf.basic.BasicComboBoxUI.getMinimumSize (number 2) -PASS: gnu.testlet.javax.swing.plaf.basic.BasicComboBoxUI.getMinimumSize (number 3) +FAIL: gnu.testlet.javax.swing.plaf.basic.BasicComboBoxUI.getMinimumSize (number 2) +FAIL: gnu.testlet.javax.swing.plaf.basic.BasicComboBoxUI.getMinimumSize (number 3) These pass here. -PASS: gnu.testlet.javax.swing.plaf.basic.BasicComboBoxUI.getPreferredSize (number 2) -PASS: gnu.testlet.javax.swing.plaf.basic.BasicComboBoxUI.getPreferredSize (number 3) +FAIL: gnu.testlet.javax.swing.plaf.basic.BasicComboBoxUI.getPreferredSize (number 2) +FAIL: gnu.testlet.javax.swing.plaf.basic.BasicComboBoxUI.getPreferredSize (number 3) These pass also. -PASS: gnu.testlet.javax.swing.plaf.basic.BasicComboBoxUI.getDisplaySize (number 2) -PASS: gnu.testlet.javax.swing.plaf.basic.BasicComboBoxUI.getDisplaySize (number 3) -PASS: gnu.testlet.javax.swing.plaf.basic.BasicComboBoxUI.getDisplaySize (number
Re: Next release
On 2/27/06, Brian Jones [EMAIL PROTECTED] wrote: Suggest making next release 0.90 and incrementing towards 1.0. The 1.0 release should be 1.4.0 (or 1.40 if you were going to be consistent, but I digress). Anyway my $0.02. 0.90 has problems if there turn out to be more than 9 more releases before 1.(4.)0 is reached. Hard to say whether that's likely or not, but I think it would be better if our decision of when to hit 1.x was based purely on technical grounds and not affected by limits on the version-number space. On the other hand, well spotted (I think?) that 0.9.x might be considered a lower version that 0.21 by packaging tools. dpkg --compare-versions appears to think so, if I'm understanding how to use it right. This may be moot though as the debian classpath package already has an epoch on it; I don't know how rpm handles this kind of issue. Stuart. -- http://sab39.dev.netreach.com/
milestone for release 1. was Next release
hello all, what is the expected milestone (definition and how to measure it) to reach before releasing a version 1 --or 1.4 whatever that final number will be? cheers; rsn pgpedKocpYsKX.pgp Description: PGP signature
Re: Next release
On Mon, 2006-02-27 at 20:36 +, Chris Burdess wrote: Archie Cobbs wrote: - Decide on the version number. We had a very small/brief discussion about this during Fosdem. Everybody seems to agree 0.x really doesn't do justice to the maturity we have reached over the years. And it is really hard to define when we hit 1.0. So the proposal is to keep using a sequence version number. Either just drop the 0. and make the next release-number classpath-21, or adopt a year.month style version number and make the next version number classpath-6.3 for the March 2006 release. In either case we will just use a code name for a release that has some special feature set that we are proud of, but we will always just increase the release snapshot number. Suggestions or Opinions? Opinion requested, here granted :-) Changes in version number format, etc. have a cost in that can confuse (or at least complicate) packaging and versioning software like RPM, FreeBSD ports, etc. not to mention consumers (i.e., users). If all we want is a sequence numbering, then 0.xx has been working fine so why change it? If we want to be prouder, let's just release 1.0 and be done with it. Surely 1.0.1, 1.1, 1.2, etc will shortly follow and the whole grandness of 1.0 will fade quickly. So I vote either keeping the status quo, or releasing 1.0. A classpath-6.3 seems to be the worst of both worlds. I agree with the above but my preference would be for 1.4.x. We are at about 99% of 1.4 API coverage, and we have many features that weren't shipped by Sun until 1.5. When we are in the same situation with respect to 1.5, we should call ourselves 1.5.x and so forth. This makes the situation much more clear to casual users as to what they can expect in terms of features. I agree that this would be the best versioning scheme. If we're 1.4 API-complete then we want to advertise that fact, since it will help users know what to expect. Tom
Re: Next release
Stuart Ballard wrote: On 2/27/06, Brian Jones [EMAIL PROTECTED] wrote: Suggest making next release 0.90 and incrementing towards 1.0. The 1.0 release should be 1.4.0 (or 1.40 if you were going to be consistent, but I digress). Anyway my $0.02. 0.90 has problems if there turn out to be more than 9 more releases before 1.(4.)0 is reached. Hard to say whether that's likely or not, but I think it would be better if our decision of when to hit 1.x was based purely on technical grounds and not affected by limits on the version-number space. On the other hand, well spotted (I think?) that 0.9.x might be considered a lower version that 0.21 by packaging tools. dpkg --compare-versions appears to think so, if I'm understanding how to use it right. This may be moot though as the debian classpath package already has an epoch on it; I don't know how rpm handles this kind of issue. I think the actual precedent is to go 0.9xx... as needed until you _can_ declare the 1.0. So it's more of a mindset thing to bump the number and get folks really working towards that 1 goal. You do not need to feel limited to only 9 releases. There can in fact remain an infinite number of releases between 0.90 and 1.x. :) I just can't figure out a good way to declare something as pre-1.4.0 without confusing folks more, as in 1.3.x won't work as it is also false. So just keeping the same style as now and moving forward to 0.90 makes good sense to me. But what version numbers will you use post 1.4.0 for development releases? Would you go with 1.5.0- or similar for HEAD and 1.4.0- for the 1.4 release branch? That actually doesn't quite work, the 1.5 release branch would also end up 1.5.0- so something else will have to differentiate a dev release. You can of course internally continue with your same scheme and simply tag your production releases as corresponding to a particular java release and leave it at that. Doesn't look like anyone wants to do that though. Oh yes, if the packaging tools can't tell 1.4.0 is newer than 0.90 then perhaps you'd want to bring about the package version change hell sooner rather than later. Brian
Re: Next release
On Tue, 2006-02-28 at 17:45 +0100, Roman Kennke wrote: -PASS: gnu.testlet.javax.swing.text.MaskFormatter.MaskFormatterTest: valid output (number 7) +FAIL: gnu.testlet.javax.swing.text.MaskFormatter.MaskFormatterTest: uncaught exception at valid output number 2: java.lang.NullPointerException Haven't looked at it yet. Fixed. Lillian
Re: Next release
I think the actual precedent is to go 0.9xx... as needed until you _can_ declare the 1.0. So it's more of a mindset thing to bump the number and get folks really working towards that 1 goal. You do not need to feel limited to only 9 releases. There can in fact remain an infinite number of releases between 0.90 and 1.x. :) I just can't figure out a good way to declare something as pre-1.4.0 without confusing folks more, as in 1.3.x won't work as it is also false. So just keeping the same style as now and moving forward to 0.90 makes good sense to me. But what version numbers will you use post 1.4.0 for development releases? Would you go with 1.5.0- or similar for HEAD and 1.4.0- for the 1.4 release branch? That actually doesn't quite work, the 1.5 release branch would also end up 1.5.0- so something else will have to differentiate a dev release. I agree that trying to stick with the api version we're aiming for is probably very problematic as we'll have most 1.3 and 1.4 working, but a bit of 1.5 and later a bit of 1.6 too, but without 100% 1.4, so it doesn't mean much to the casual user I guess. I'd tend to reuse an early proposition, with the date being included in the release version. After all, we're in the same situation as the wine guys, and they used a date as release version for quite some time iirc and only recently they switched to 0.9.x because they feel that they were close to a mostly working implementation (whatever mostly mean, either for them or us). So, having a classpath 0.200602 (or similar) as the next version could be useable since it's 0.20 from an raw ascii lexycographical order (hence for packager), it's not a = 1.0 version as we're still in the process of getting most stuff working (most should include running flawlessly the entire test suites of the major products imho [just define major product and we're done ] ) and it includes an indicator of the freshness of the release (with the date). When we will all be happy with the advances, we may then switch to 0.9.x with the adequate precision to fit enough release before the 1.0 my 0.02 euros You can of course internally continue with your same scheme and simply tag your production releases as corresponding to a particular java release and leave it at that. Doesn't look like anyone wants to do that though. Oh yes, if the packaging tools can't tell 1.4.0 is newer than 0.90 then perhaps you'd want to bring about the package version change hell sooner rather than later. Brian Olivier
Next release
Hi all, As some people have been saying already there were some impressive showcases at Fosdem of things that just work now. So I feel it is time to do a new snapshot this week to share all this great work with our users. Both awt and swing made some very nice improvements, we have all the new crypto algorithms now (https support out of the box), new rmi/corba tools, unicode 4.0 support, (VM)Math improvements, regex improvements, and probably lots of other things I am forgetting now. (Please update the NEWS file!) It looks like we are in pretty good shape. Some smoke-tests with some simple applications work nicely for me. And Mauve gives us this impressive score: classpath-0.20 38115 PASS 983 FAIL classpath-0.21-pre 43615 PASS 583 FAIL There are some regressions that builder didn't seem to have picked up though (attached). We need to go through these to see whether they are fatal/embarrassing. Other things to do: - Update the NEWS file! - Test more apps. - Go through the bug-list for must fix things. - Remerge CVS trunk with the generics branch (I don't know whether Andrew has had time for that since his Math work. Please yell and scream if you need help with this Andrew.) - Make builder produce a real classpath-generics dist again. (I'll try to take a look at that tonight.) - Decide on the version number. We had a very small/brief discussion about this during Fosdem. Everybody seems to agree 0.x really doesn't do justice to the maturity we have reached over the years. And it is really hard to define when we hit 1.0. So the proposal is to keep using a sequence version number. Either just drop the 0. and make the next release-number classpath-21, or adopt a year.month style version number and make the next version number classpath-6.3 for the March 2006 release. In either case we will just use a code name for a release that has some special feature set that we are proud of, but we will always just increase the release snapshot number. Suggestions or Opinions? Different from previous releases I will probably create a branch for this one. If things look basically OK, I'll create that on Wednesday and then test that and back-port patches from CVS trunk to it till it is perfect. That makes sure other people can just happily go on hacking. Please let me know if there is something you feel would be really nice to have in for this release. Cheers, Mark -PASS: gnu.testlet.javax.swing.JLabel.Icon (number 6) -PASS: gnu.testlet.javax.swing.JLabel.Icon (number 7) +FAIL: gnu.testlet.javax.swing.JLabel.Icon (number 6) +FAIL: gnu.testlet.javax.swing.JLabel.Icon (number 7) -PASS: gnu.testlet.javax.swing.text.AbstractDocument.BranchElement.getElementIndexNullPointer (number 1) +FAIL: gnu.testlet.javax.swing.text.AbstractDocument.BranchElement.getElementIndexNullPointer: AbstractDocument.BranchElement.getElementIndex should throw NPE when it has no children (number 1) +FAIL: gnu.testlet.javax.swing.text.AbstractDocument.ElementChange: uncaught exception: java.lang.NullPointerException +FAIL: uncaught exception loading gnu.testlet.javax.swing.text.DefaultStyledDocument.ElementBuffer.StyledDocument2: java.lang.NullPointerException +FAIL: uncaught exception loading gnu.testlet.javax.swing.text.DefaultStyledDocument.ElementBuffer.StyledDocument3: java.lang.NullPointerException -PASS: gnu.testlet.javax.swing.text.MaskFormatter.MaskFormatterTest: valid output (number 7) +FAIL: gnu.testlet.javax.swing.text.MaskFormatter.MaskFormatterTest: uncaught exception at valid output number 2: java.lang.NullPointerException -PASS: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: TC-text (number 3) +FAIL: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: TC-text (number 3) -PASS: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: TR-text (number 3) +FAIL: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: TR-text (number 3) -PASS: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: CL-text (number 2) +FAIL: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: CL-text (number 2) -PASS: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: CC-text (number 2) -PASS: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: CC-text (number 3) +FAIL: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: CC-text (number 2) +FAIL: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: CC-text (number 3) -PASS: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: CR-text (number 3) +FAIL: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: CR-text (number 3) -PASS: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: BC-text (number 3) +FAIL: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: BC-text (number 3) -PASS: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: BR-text (number 3) +FAIL: gnu.testlet.javax.swing.SwingUtilities.layoutCompoundLabel: BR-text
Re: Next release
Mark Wielaard wrote: - Decide on the version number. We had a very small/brief discussion about this during Fosdem. Everybody seems to agree 0.x really doesn't do justice to the maturity we have reached over the years. And it is really hard to define when we hit 1.0. So the proposal is to keep using a sequence version number. Either just drop the 0. and make the next release-number classpath-21, or adopt a year.month style version number and make the next version number classpath-6.3 for the March 2006 release. In either case we will just use a code name for a release that has some special feature set that we are proud of, but we will always just increase the release snapshot number. Suggestions or Opinions? Opinion requested, here granted :-) Changes in version number format, etc. have a cost in that can confuse (or at least complicate) packaging and versioning software like RPM, FreeBSD ports, etc. not to mention consumers (i.e., users). If all we want is a sequence numbering, then 0.xx has been working fine so why change it? If we want to be prouder, let's just release 1.0 and be done with it. Surely 1.0.1, 1.1, 1.2, etc will shortly follow and the whole grandness of 1.0 will fade quickly. So I vote either keeping the status quo, or releasing 1.0. A classpath-6.3 seems to be the worst of both worlds. Not a big deal really, but that's my $0.02 anyway... -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Next release
On 2/27/06, Mark Wielaard [EMAIL PROTECTED] wrote: Everybody seems to agree 0.x really doesn't do justice to the maturity we have reached over the years. And it is really hard to define when we hit 1.0. So the proposal is to keep using a sequence version number. Either just drop the 0. and make the next release-number classpath-21, or adopt a year.month style version number and make the next version number classpath-6.3 for the March 2006 release. In either case we will just use a code name for a release that has some special feature set that we are proud of, but we will always just increase the release snapshot number. Suggestions or Opinions? I agree with the difficulty of picking a point to hit 1.0, but I'm a little worried about running into the opposite problem of overselling the level of maturity. A version 21 product sounds like it should be... well, emacs. A version 6.x also seems like it should be an extremely mature product, and 6 also happens to be the next pending version of Sun's JSE which might confuse people. If we're going to go with one of these approaches, my preference would be for the year-based one but I'd suggest making it more obvious that it's year-based. Either version 2006.3 or, if that's too much, version 06.3 - 06 looks more like a year than just 6 does. My own personal feeling, though, is that even though it's hard to pick a point to go to 1.x, it's not *impossible*. I'd suggest that the right point to go 1.x is when people can be reasonably confident that a randomly-chosen app that runs on Java 1.4 will run on Classpath (I also think it might be worth calling that version 1.4.0 rather than 1.0). This means basically getting to full 1.4 API coverage with no stubs, and a fair degree of real-world testing, all of which seem eminently likely to happen, at the current rate of improvement, within months rather than years. The numbering game is all about psychology really anyway; version 0.21 suggests 21% of the way to maturity. If we stuck a 9 in there and made the next version either 0.9.21 or 0.9.1, it'd give a much more accurate representation of the real level of maturity without needing to go to a more unconventional system. Just my opinion, for whatever it's worth. Stuart. -- http://sab39.dev.netreach.com/
Re: Next release
On Mon, Feb 27, 2006 at 05:54:41PM +0100, Mark Wielaard wrote: - Decide on the version number. We had a very small/brief discussion about this during Fosdem. Everybody seems to agree 0.x really doesn't do justice to the maturity we have reached over the years. And it is really hard to define when we hit 1.0. So the proposal is to keep using a sequence version number. Either just drop the 0. and make the next release-number classpath-21, or adopt a year.month style version number and make the next version number classpath-6.3 for the March 2006 release. In either case we will just use a code name for a release that has some special feature set that we are proud of, but we will always just increase the release snapshot number. Suggestions or Opinions? I don't really like this approach. I think we should just do a 1.0 release when work for all applications written for Java 1.4. We will have regressions against Java 1.4 but these can be fixed in 1.1, 1.2 ... Or if you want a slower version inflation 1.0.1, 1.0.2, ... Using a year-based approach means nothing. Then we can use evil codenames like wealthy walrus. Cheers, Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/
Re: Next release
Hi Mark, As some people have been saying already there were some impressive showcases at Fosdem of things that just work now. So I feel it is time to do a new snapshot this week to share all this great work with our users. Both awt and swing made some very nice improvements, we have all the new crypto algorithms now (https support out of the box), new rmi/corba tools, unicode 4.0 support, (VM)Math improvements, regex improvements, and probably lots of other things I am forgetting now. (Please update the NEWS file!) It looks like we are in pretty good shape. I would really like to get my latest stuff (offscreen buffer, painting, etc) a little more stable. I am still having problems here and there. And I would like to get all those Swing regressions cleared (either Swing or testcase beeing fixed). Maybe the other Swing hackers can also have a look? If that is done (hopefully by the end of this week), I am ok with release. Roman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Next release
Am Montag, den 27.02.2006, 12:23 -0500 schrieb Stuart Ballard: On 2/27/06, Mark Wielaard [EMAIL PROTECTED] wrote: Everybody seems to agree 0.x really doesn't do justice to the maturity we have reached over the years. And it is really hard to define when we hit 1.0. So the proposal is to keep using a sequence version number. Either just drop the 0. and make the next release-number classpath-21, or adopt a year.month style version number and make the next version number classpath-6.3 for the March 2006 release. In either case we will just use a code name for a release that has some special feature set that we are proud of, but we will always just increase the release snapshot number. Suggestions or Opinions? The numbering game is all about psychology really anyway; version 0.21 suggests 21% of the way to maturity. If we stuck a 9 in there and made the next version either 0.9.21 or 0.9.1, it'd give a much more accurate representation of the real level of maturity without needing to go to a more unconventional system. If anything, I would vote for this approach. 0.9.1 really sounds logical wrt the current rate of maturity and an 1.0 really seems not that far away. So this would be the 1st snapshot in the maybe-soon-1.0 cycle of snapshots. Ah yes, codenames would also be nice, I really like such kind of things, just for the fun of it. /Roman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Next release
Archie Cobbs wrote: - Decide on the version number. We had a very small/brief discussion about this during Fosdem. Everybody seems to agree 0.x really doesn't do justice to the maturity we have reached over the years. And it is really hard to define when we hit 1.0. So the proposal is to keep using a sequence version number. Either just drop the 0. and make the next release-number classpath-21, or adopt a year.month style version number and make the next version number classpath-6.3 for the March 2006 release. In either case we will just use a code name for a release that has some special feature set that we are proud of, but we will always just increase the release snapshot number. Suggestions or Opinions? Opinion requested, here granted :-) Changes in version number format, etc. have a cost in that can confuse (or at least complicate) packaging and versioning software like RPM, FreeBSD ports, etc. not to mention consumers (i.e., users). If all we want is a sequence numbering, then 0.xx has been working fine so why change it? If we want to be prouder, let's just release 1.0 and be done with it. Surely 1.0.1, 1.1, 1.2, etc will shortly follow and the whole grandness of 1.0 will fade quickly. So I vote either keeping the status quo, or releasing 1.0. A classpath-6.3 seems to be the worst of both worlds. I agree with the above but my preference would be for 1.4.x. We are at about 99% of 1.4 API coverage, and we have many features that weren't shipped by Sun until 1.5. When we are in the same situation with respect to 1.5, we should call ourselves 1.5.x and so forth. This makes the situation much more clear to casual users as to what they can expect in terms of features. -- 犬 Chris Burdess They that can give up essential liberty to obtain a little safety deserve neither liberty nor safety. - Benjamin Franklin PGP.sig Description: This is a digitally signed message part
Re: Next release
On Mon, Feb 27, 2006 at 08:36:37PM +, Chris Burdess wrote: Changes in version number format, etc. have a cost in that can confuse (or at least complicate) packaging and versioning software like RPM, FreeBSD ports, etc. not to mention consumers (i.e., users). If all we want is a sequence numbering, then 0.xx has been working fine so why change it? If we want to be prouder, let's just release 1.0 and be done with it. Surely 1.0.1, 1.1, 1.2, etc will shortly follow and the whole grandness of 1.0 will fade quickly. So I vote either keeping the status quo, or releasing 1.0. A classpath-6.3 seems to be the worst of both worlds. I agree with the above but my preference would be for 1.4.x. We are at about 99% of 1.4 API coverage, and we have many features that weren't shipped by Sun until 1.5. When we are in the same situation with respect to 1.5, we should call ourselves 1.5.x and so forth. This makes the situation much more clear to casual users as to what they can expect in terms of features. Full ACK. This really makes sense. Cheers, Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/
Re: Next release
On Mon, 2006-02-27 at 17:54 +0100, Mark Wielaard wrote: Hi all, As some people have been saying already there were some impressive showcases at Fosdem of things that just work now. So I feel it is time to do a new snapshot this week to share all this great work with our users. Both awt and swing made some very nice improvements, we have all the new crypto algorithms now (https support out of the box), new rmi/corba tools, unicode 4.0 support, (VM)Math improvements, regex improvements, and probably lots of other things I am forgetting now. (Please update the NEWS file!) It looks like we are in pretty good shape. Some smoke-tests with some simple applications work nicely for me. And Mauve gives us this impressive score: classpath-0.20 38115 PASS 983 FAIL classpath-0.21-pre 43615 PASS 583 FAIL There are some regressions that builder didn't seem to have picked up though (attached). We need to go through these to see whether they are fatal/embarrassing. Other things to do: - Update the NEWS file! - Test more apps. - Go through the bug-list for must fix things. - Remerge CVS trunk with the generics branch (I don't know whether Andrew has had time for that since his Math work. Please yell and scream if you need help with this Andrew.) It's mostly there. I expected to have it in during the weekend, but the merge included a few classes that differ significantly between the branches and had to be merged manually (e.g. the Character changes, changes to the collection classes). Hopefully, I should be able to wrap it up sometime tomorrow morning (GMT). This will bring it in sync up to about the 25th (Saturday). It then just needs to be brought up to date with the patches inbetween Saturday and the point where the release is called. The Math changes make this particularly important as otherwise generics will ship with broken floating point stuff... :( I can do this too, but if anyone wants to help out, I'd be grateful. More specifically, if you did a recent patch and have a checked-out and compiling generics branch too, it would be great if you could commit to that as well once the initial merge is over. The majority of stuff _should be_ fairly clean to apply (java.util stuff is usually the exception). Post-release, I'd like to do a run-through in the opposite direction, checking that everything in generics branch that should be in HEAD is... This has already caused a few hiccups in the past. My take on that is that anything that will compile there should be on HEAD, but I'd be interested to hear what others think. It depends on whether you want to target the generics branch for people who need to do stuff with generics, enums, etc. or just generally for people who want some level of 1.5 compatability. - Make builder produce a real classpath-generics dist again. (I'll try to take a look at that tonight.) Would be great to see that. - Decide on the version number. We had a very small/brief discussion about this during Fosdem. Everybody seems to agree 0.x really doesn't do justice to the maturity we have reached over the years. And it is really hard to define when we hit 1.0. So the proposal is to keep using a sequence version number. Either just drop the 0. and make the next release-number classpath-21, or adopt a year.month style version number and make the next version number classpath-6.3 for the March 2006 release. In either case we will just use a code name for a release that has some special feature set that we are proud of, but we will always just increase the release snapshot number. Suggestions or Opinions? Jumping version numbers would be very appropriate for a Java library release... ;) Either of the 0.9--1 or 1.4.x, 1.5.x suggestions sounds good to me. The latter sound better for a final versioning system, but I'm wary of calling us 1.4 yet. API compatability isn't everything. Although, on that note, it would be nice to have HEAD as 1.4.x and the generics branch as 1.5.x (one being our current 'stable' release, the other being the next big thing eventually). Different from previous releases I will probably create a branch for this one. If things look basically OK, I'll create that on Wednesday and then test that and back-port patches from CVS trunk to it till it is perfect. That makes sure other people can just happily go on hacking. Please let me know if there is something you feel would be really nice to have in for this release. Sounds like a good idea, especially as CVS is so much more active these days (in that I can't get a patch in in the space it takes me to write the Changelog). A release branch would also mean we could apply bad regressions to it if we find any later on. Classpath is different from most other codebases in that we don't really have features in new releases, and fixes to the old ones; everything at present is an attempt to get a certain level of functionality that exists
Re: Next release
Hi Andrew, On Mon, 2006-02-27 at 21:42 +, Andrew John Hughes wrote: On Mon, 2006-02-27 at 17:54 +0100, Mark Wielaard wrote: - Remerge CVS trunk with the generics branch (I don't know whether Andrew has had time for that since his Math work. Please yell and scream if you need help with this Andrew.) It's mostly there. I expected to have it in during the weekend, but the merge included a few classes that differ significantly between the branches and had to be merged manually (e.g. the Character changes, changes to the collection classes). Thank you! There are also the two divergences that I introduced during the last release (EventSetDescriptor and Hashtable) http://lists.gnu.org/archive/html/classpath-patches/2006-01/msg00254.html And which I never cleaned up... Apologies. Again, please say if you need/want any help. It then just needs to be brought up to date with the patches inbetween Saturday and the point where the release is called. Roman wanted some more time to stabilize so lets just pick Saturday as the day we freeze (meaning, when the release branch is created). Then only patches going on this release-branch should also be added to the generics branch (I can take care of this). - Make builder produce a real classpath-generics dist again. (I'll try to take a look at that tonight.) Would be great to see that. Done. But in a bit hacky way. We have a regression in gcj-svn-trunk it seems. Running the build under gdb show our friend doubleParse() again: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1236678656 (LWP 15045)] _Jv_lshift (ptr=0xbfffdb74, b=0xbfffde68, k=1073257029) at ../../../../../../trunk/libjava/classpath/native/fdlibm/mprec.c:469 469 *x1++ = 0; (gdb) bt #0 _Jv_lshift (ptr=0xbfffdb74, b=0xbfffde68, k=1073257029) at ../../../../../../trunk/libjava/classpath/native/fdlibm/mprec.c:469 #1 0xb789183a in _Jv_strtod_r (ptr=0xbfffdb74, s00=0xbfffdac0 1.570796251296997, se=0xbfffe4cc) at ../../../../../../trunk/libjava/classpath/native/fdlibm/strtod.c:479 #2 0xb6efd82a in java::lang::VMDouble::parseDouble (str=0x0) at ../../../trunk/libjava/java/lang/natDouble.cc:209 #3 0x in ?? () For now I just installed a fake ecj under /usr/local that just uses the gij-4.0 as runtime. Unfortunately gcj-4.0 is unable to compile to native (either from source or from byte-code), both issues (accessing inner-class-super-fields and the gcj-byte-code-verifier) seem to be fixed in gcj-4.1, but that hasn't been released yet. I'll install 4.1 on builder when it is actually officially released and will then try to create a new native-ecj binary again. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Next release
Hi Mark, It then just needs to be brought up to date with the patches inbetween Saturday and the point where the release is called. Roman wanted some more time to stabilize so lets just pick Saturday as the day we freeze (meaning, when the release branch is created). Then only patches going on this release-branch should also be added to the generics branch (I can take care of this). So that means, we have finally a real release process? Cool. Makes sense nowadays, looking at this stream of patches... /Roman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Next release
Michael Koch wrote: On Mon, Feb 27, 2006 at 08:36:37PM +, Chris Burdess wrote: Changes in version number format, etc. have a cost in that can confuse (or at least complicate) packaging and versioning software like RPM, FreeBSD ports, etc. not to mention consumers (i.e., users). If all we want is a sequence numbering, then 0.xx has been working fine so why change it? If we want to be prouder, let's just release 1.0 and be done with it. Surely 1.0.1, 1.1, 1.2, etc will shortly follow and the whole grandness of 1.0 will fade quickly. So I vote either keeping the status quo, or releasing 1.0. A classpath-6.3 seems to be the worst of both worlds. I agree with the above but my preference would be for 1.4.x. We are at about 99% of 1.4 API coverage, and we have many features that weren't shipped by Sun until 1.5. When we are in the same situation with respect to 1.5, we should call ourselves 1.5.x and so forth. This makes the situation much more clear to casual users as to what they can expect in terms of features. Full ACK. This really makes sense. Cheers, Michael Suggest making next release 0.90 and incrementing towards 1.0. The 1.0 release should be 1.4.0 (or 1.40 if you were going to be consistent, but I digress). Anyway my $0.02. Brian
RE: Next release?
Mark Wielaard wrote: On Wed, 2004-03-31 at 10:32, Jeroen Frijters wrote: I'm planning my first real IKVM release (to be included with the Mono 1.0 release) and I'd like to know when the next GNU Classpath release is approximately due. Do you know have a date planned already? I like our time-based release cycle. To be clear, I think it's fine too. I didn't mean to imply otherwise. I just wasn't clear on when the next scheduled drop would be. The 0.08 release was late by two weeks, but I think we have enough new things already to just ignore that and do a 0.09 snapshot in the last week of April. And then 0.10 in the last week of June (hope that is just in time to make it for that mono 1.0 thing.) In that case I think I'll probably stick to 0.09 for the Mono release. How do people feel about the Class/VMClass changes? Should we include those in 0.09? Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Next release?
Hi, On Wed, 2004-03-31 at 10:32, Jeroen Frijters wrote: I'm planning my first real IKVM release (to be included with the Mono 1.0 release) and I'd like to know when the next GNU Classpath release is approximately due. Do you know have a date planned already? I like our time-based release cycle. We used to do it every three months, but I think there is enough progress to do it every two months. The 0.08 release was late by two weeks, but I think we have enough new things already to just ignore that and do a 0.09 snapshot in the last week of April. And then 0.10 in the last week of June (hope that is just in time to make it for that mono 1.0 thing.) I did think a bit about whether we could guarantee more then just a time-based snapshot. Some sort of minimal feature based release. But I am afraid there is just to much to do just yet to make any promise. This does mean that we will not guarantee that 0.11 or 0.10 will be backwards compatible with 0.09 though. So you should be prepared for that even though you want to be included in a 1.0 mono release. How do other Compiler/VM-integrators feel about this? gcj and kaffe seem to go their own way mostly. The rest seems to follow the GNU Classpath release snapshots and recommend out latest release be combined with their latest release. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Next release?
Hi Mark, I'm planning my first real IKVM release (to be included with the Mono 1.0 release) and I'd like to know when the next GNU Classpath release is approximately due. Do you know have a date planned already? Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NEWS file for next release
Bryce McKinlay wrote: I think that is not a bug, but rather an obscure C++ misfeature called trigraphs. Don't I recall reading in the index of some GNU manual (probably for gcc): ANSI Trigraphs You don't want to know about this particular braindamage. :) Chris Gray VM Architect, ACUNIA ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NEWS file for next release
Hi, On Thu, 2002-02-07 at 10:18, Chris Gray wrote: Bryce McKinlay wrote: I think that is not a bug, but rather an obscure C++ misfeature called trigraphs. Don't I recall reading in the index of some GNU manual (probably for gcc): ANSI Trigraphs You don't want to know about this particular braindamage. :) Really funny. The gcc manual actually says that when it explains the -trigraphs option. That is all the documentation it gives! Argh. I tried to lookup more info on trigraphs but could not find that much. What I could find did not say that ::: was actually a trigraph. Stange. The patch is neccessary and does work for me (gcc 3.0.4 debian prerelease). Does anybody know if it is a real fix or something bogus? Anyway, I added a new file with the patches that I needed as resource/orp-1.0.9.patch and updated the ORP build instructions for using the native Classpath libraries with the latest ORP on http://www.gnu.org/software/classpath/doc/orp.html. (And I actually tested it with clean installs of both ORP and Classpath.) If someone else could try it out that would be much appreciated. I also updated the README file with new URLs for the VMs that currently use Classpath and added the following text: GNU Classpath has been tested to work out of the box with the latest ORP release. Instructions for building ORP with this GNU Classpath release can be found at http://www.gnu.org/software/classpath/doc/orp.html. Most JVMs come with their own customized version of GNU Classpath. Please check if there is a customised version available for the JVM you use before trying the bare bones GNU Classpath release. We are working with the JVM creators to keep the differences between the core classes as small as possible. Please tell us if you make GNU Classpath work with a new JVM. We are very close to a realease now. Yeah! Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NEWS file for next release
Mark Wielaard wrote: The patch is neccessary and does work for me (gcc 3.0.4 debian prerelease). Does anybody know if it is a real fix or something bogus? Isn't it just that :: is a valid operator in C++ (but not in C)? I have no idea what a line of code that uses three : operators in a row could possibly mean (in either language) and I can't find the source code file to get context. But my guess is that the tokenizer is seeing :: and thinking ooh, class member operator (or whatever that operator is called in c++), and it doesn't occur to it that it might actually be two separate : operators. Now whether that means the fix is *real* or not is unclear to me. C is pretty good at avoiding these kinds of ambiguous situations, but I bet that: int *a; int b; c = b/*a; wouldn't divide b by the value pointed to by a, either :) Anyone know what these three : operators are actually supposed to be doing in this case? At first I assumed that it was in the context of some wacky nested use of the ternary operator, but even then the closest you can get is a?b?c?d:e:f:g - the three :s must be separated by something. Stuart. -- Stuart Ballard, Programmer FASTNET - Internet Solutions 215.283.2300, ext. 126 www.fast.net ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NEWS file for next release
Mark Wielaard wrote:
Hi,
On Thu, 2002-02-07 at 10:18, Chris Gray wrote:
Don't I recall reading in the index of some GNU manual (probably for
gcc):
ANSI Trigraphs
You don't want to know about this particular braindamage.
:)
Really funny. The gcc manual actually says that when it explains the
-trigraphs option. That is all the documentation it gives! Argh.
I actually had to use them once. I was compiling C code on an IBM
mainframe and doing most of my editing on a PC XT ... there was no
other way of getting source code converted from the DOS code page
to EBCDIC and back, and still be recognisable.
It's quite easy really - you just write { and } as ?? and ??, [ ] as
??( ??), ~ as ??-, and so forth. Unfortunately the sed scripts I used
to do this stuff ended up in the skip, along with the PC XT ... (the
mainframe is probably still running. ;) Anyway, I don't recall
anything about ::: - have you tried the I Ching?
Chris
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: NEWS file for next release
Mark Wielaard wrote: - There seems to be a gcc compiler bug that makes the following patch necessary: --- orp-1.0.9/base_natives/common_olv2/mon_enter_exit.cpp +++ orp/base_natives/common_olv2/mon_enter_exit.cpp @@ -294,7 +294,7 @@ #else nop;nop;nop #endif - ::: memory + : : : memory ); #else I think that is not a bug, but rather an obscure C++ misfeature called trigraphs. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
TODO list for the next release
Hi, Here is my TODO list for the next (0.03) release. It seems like a good idea to get a release out the door now that we have the AWT and license clarification worked out and the libraries seem to work with Orp 1.0.9 out of the box. 0.02 was released more then a year ago and we made lots of progress since then. Lets show the world! Brian, you have been our release master in the past. Will you also do the actual release this time? When would you have time? I think we should set a target date somewhere next week (friday or next weekend). I will try to make sure that the things on the list below are done by friday. What do other people think? Am I missing something obvious that is needed before the release? TODO for 0.03: - Check and apply patches in Savannah bugdatabase http://savannah.gnu.org/patch/index.php?group_id=85. A lot of the patches that Intel submitted were set to postponed but the copyright assignment papers have been sorted out so they can go in now. - Add workaround for compiling with gcj (3.0.x and 3.1 CVS). I have two workaround for compiling with gcj in my local tree. It might be a good idea to apply them. - Check and update README, HACKING, NEWS and webpages for new release. - Figure out why make dist does not work. - Check build instructions when make dist does work so people can easily download the Classpath 0.03 and the ORP 1.0.9 release on a clean machine and get it working out of the box. - Make release announcement for announce newsgroup, Freshmeat, etc. Fun to have but not neccessary/to much work for 0.03: - Popping up a AWT window with ORP (I have seen it work under gcj but cannot get it working with ORP.) - Working out of the box with other free JVMs. SableVM and Kissme seem to be not that much work to get working out of the box and Etienne wanted to contribute some build magic to make it simpler. Maybe if he has time. - T-Shirt! Last time I promised to make T-Shirts if we ever got a new release. So I should finally make them now :) Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: TODO list for the next release
Hi,
On Sun, 2002-02-03 at 17:34, Brian Jones wrote:
Mark Wielaard [EMAIL PROTECTED] writes:
- Check and apply patches in Savannah bugdatabase
http://savannah.gnu.org/patch/index.php?group_id=85.
A lot of the patches that Intel submitted were set to postponed but
the copyright assignment papers have been sorted out so they can go in
now.
The FSF has a signed document, but it failed to define developer
names, so RMS is not going to sign it until they get a letterhead
defining whose contributions count. So I set the patches to postponed
again.
Bummer. I might take a look to see if I can reproduce the errors and
write the fixes myself then. Or are you expecting a quick turnaround for
the papers?
- Add workaround for compiling with gcj (3.0.x and 3.1 CVS). I have two
workaround for compiling with gcj in my local tree. It might be a good
idea to apply them.
Is there some way to detect gcj version and apply the right workaround
as needed?
The workarounds are really simple and don't really hurt in other
situations. The one needed for gcj 3.0.x is:
diff -u -u -r1.14 BigInteger.java
--- java/math/BigInteger.java 22 Jan 2002 22:27:00 - 1.14
+++ java/math/BigInteger.java 3 Feb 2002 17:05:21 -
@@ -37,7 +37,7 @@
package java.math;
-import gnu.java.math.*;
+import gnu.java.math.MPN;
import java.util.Random;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
Which I will checkin after this email.
The one for gcc 3.1 (CVS) is:
--- vm/reference/java/lang/Class.java 22 Jan 2002 22:27:03 - 1.14
+++ vm/reference/java/lang/Class.java 3 Feb 2002 17:05:22 -
@@ -68,7 +68,7 @@
public class Class {
private Object[] signers = null;
-private ProtectionDomain protectionDomain = null;
+private ProtectionDomain pd = null;
// The unknown protection domain.
private final static ProtectionDomain unknownProtectionDomain;
@@ -546,10 +546,10 @@
if (sm != null)
sm.checkPermission(protectionDomainPermission);
-if (protectionDomain == null)
+if (pd == null)
return unknownProtectionDomain;
else
-return protectionDomain;
+return pd;
}
}
I have to check if this gives any problem with Orp but I don't think
that variable is actually used at the moment.
For the gcj from CVS we have another problem that prevents compiling the
collection classes.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=viewdatabase=gccpr=4715
The workaround in that bugreport works for me but I don't know the
status.
And I have had some trouble with ORP accepting classes compiled with gcj
(3.0.3) I don't know what or why that is though or if it is a bug in gcj
-C or in ORP (see the orp mailinglist for more info). So maybe we should
recommend jikes anyway for now.
- Check build instructions when make dist does work so people can easily
download the Classpath 0.03 and the ORP 1.0.9 release on a clean
machine and get it working out of the box.
- Make release announcement for announce newsgroup, Freshmeat, etc.
Could you do this? Aaron made the original announcement on Freshmeat.
Sure. Bragging about a project sounds like fun :)
Fun to have but not neccessary/to much work for 0.03:
- Popping up a AWT window with ORP
(I have seen it work under gcj but cannot get it working with ORP.)
I'd love to have the AWT in the same quasi working condition with ORP.
I'll look into that today. The superbowl is boring between
commercials anyway.
Funny. I never saw the superbowl (we don't have a football tradition in
Europe) but all I ever hear about it is that you should watch the
commercials. Strange people those Americans :)
I still have access to the ftp area on alpha.gnu.org as far as I know
so I should be able to make a release available when we're ready.
Great. Should we aim the release for Friday?
There is one more thing that I want to have working for the release and
that is Mauve with Orp. Then we can report what is actually supposed to
work and what not. So people can easily test their installation.
Cheers,
Mark
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: TODO list for the next release
Hi,
On Sun, 2002-02-03 at 18:25, Mark Wielaard wrote:
The one for gcc 3.1 (CVS) is:
--- vm/reference/java/lang/Class.java 22 Jan 2002 22:27:03 - 1.14
+++ vm/reference/java/lang/Class.java 3 Feb 2002 17:05:22 -
@@ -68,7 +68,7 @@
public class Class {
private Object[] signers = null;
-private ProtectionDomain protectionDomain = null;
+private ProtectionDomain pd = null;
// The unknown protection domain.
private final static ProtectionDomain unknownProtectionDomain;
@@ -546,10 +546,10 @@
if (sm != null)
sm.checkPermission(protectionDomainPermission);
-if (protectionDomain == null)
+if (pd == null)
return unknownProtectionDomain;
else
-return protectionDomain;
+return pd;
}
}
I have to check if this gives any problem with Orp but I don't think
that variable is actually used at the moment.
Hmmm. ORP uses Class.setProtectionDomain() to set the initial protection
domain. But we don't provide that method at the moment. And they
actually need a whole couple of changes to the Class(Loader) mechanism
to have ORP work correctly (which have been submitted to savannah). It
is a miracle that what we have now actually works :)
Changing the variable name this does not make the situation better or
worse for our ORP interoperability. But does bring compiling with gcj
3.1 (CVS) a step closer. So I will commit it.
Cheers,
Mark
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: TODO list for the next release
Mark Wielaard [EMAIL PROTECTED] writes: The FSF has a signed document, but it failed to define developer names, so RMS is not going to sign it until they get a letterhead defining whose contributions count. So I set the patches to postponed again. Bummer. I might take a look to see if I can reproduce the errors and write the fixes myself then. Or are you expecting a quick turnaround for the papers? Haven't heard anything, the turnaround would be at least a week is my guess, but is mostly dependent on RMS's schedule once the new piece of paper is sent and arrives in Boston. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: TODO list for the next release
Mark Wielaard wrote: - Add workaround for compiling with gcj (3.0.x and 3.1 CVS). I have two workaround for compiling with gcj in my local tree. It might be a good idea to apply them. I will try to fix any remaining issues preventing classpath being compiled with GCC 3.1. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: TODO list for the next release
Hi Bryce,
On Sun, 2002-02-03 at 21:27, Bryce McKinlay wrote:
Mark Wielaard wrote:
- Add workaround for compiling with gcj (3.0.x and 3.1 CVS). I have two
workaround for compiling with gcj in my local tree. It might be a good
idea to apply them.
I will try to fix any remaining issues preventing classpath being
compiled with GCC 3.1.
The only issue that I don't know how to work around in Classpath for 3.1
is the one that Nick also just found:
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=viewdatabase=gccpr=4715
Other then that there aren't any real issues (all the rest has
workarounds in the Classpath code).
There is a workaround in java/lang/reflect/Proxy.java that works around
a bug in 3.0.x but which I believe is already fixed in 3.1:
// FIXME workaround for bug in gcj 3.0.x
// Not needed with the latest gcj from cvs
//clazz = (Configuration.HAVE_NATIVE_GENERATE_PROXY_CLASS
// ? generateProxyClass0(loader, data)
// : new ClassFactory(data).generate(loader));
if (Configuration.HAVE_NATIVE_GENERATE_PROXY_CLASS)
clazz = generateProxyClass0(loader, data);
else
{
ClassFactory cf = new ClassFactory(data);
clazz = cf.generate(loader);
}
There is the java.util.TreeMap.TreeIterator constructor workaround for
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=viewdatabase=gccpr=4695:
TreeIterator(int type)
{
// FIXME gcj cannot handle this. Bug java/4695
// this(type, firstNode(), nil);
this.type = type;
this.next = firstNode();
this.max = nil;
}
And the workaround for Class.java that I just checked in since gcj
doesn't like the fact the there is a field named protectionDomain in
that class.
Cheers,
Mark
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
