Re: The Generics Branch: A Proposal +1
Andrew John Hughes wrote: I'd like to suggest that we merge the generics branch to HEAD, following the branch for 0.93 (making 0.93 the last non-generics version of GNU Classpath, and 0.94 the first generics one). +1, for sure. Audrius
Re: ASM and gnu.bytecode
Only part of RMIC (direct bytecode generation) is really dependent from ASM. That part which supports the source code generation is not dependent, was a separate compiler in the past and can be easily separated apart again. If we do not like ASM, this should make using the alternative replacement easier, as only the bytecode generating part needs to be rewritten. The classes being generated are also relatively simple. Audrius.
Re: ASM and gnu.bytecode
> > I recently tried to build Classpath and discovered that to build > > gjavah and grmic, ASM is required. "No problem", thought I, and > > downloaded the latest version. Oddly, that didn't work. > > > > So, I downloaded a few more versions of ASM until I found a version > > that did work: version 2.3. This looked very odd to me, as I would > > have expected such a utility library to be backwards compatible. But > > no, it isn't, and there have been discussions about this on the ASM > > mailing list. To summarize, they have no intention of providing a > > stable API, ever. Their response when someone points out that they > > have conflicting requirements for different versions of ASM in the > > same application, is "Tools and frameworks that are using ASM for > > bytecode processing (e.g. Hibernate, CGLIB, AspectWerkz) should > > repackage ASM code within their own name space. This can be automated > > with Jar Jar Links tool." > > > > We don't want to package an ASM binary file within Classpath. I > > imagine we don't want our own copy of the binary either. gcj Version > > 4.3 will require gjavah, so I want to find a clean solution for this > > problem. > > > > I suggest that we give up on ASM and move to a bytecode manipulation > > library whose public API isn't going to incompatibly change with every > > release. I imagine that gnu.bytecode would be a good choice, but am > > open to other suggestions. Perhaps gnu.bytecode could be part of > > Classpath. > > Audrius Meskauskas writes: > Only part of RMIC (direct bytecode generation) is really dependent from > ASM. That part which supports the source code generation is not > dependent, was a separate compiler in the past and can be easily > separated apart again. If we do not like ASM, this should make using the > alternative replacement easier, as only the bytecode generating part > needs to be rewritten. The classes being generated are also relatively > simple. OK, that's good. So, my main problem is to free gjavah from ASM. I'll have a look at what might be required. Per, if you're listening: may we incorporate gnu.bytecode within classpath? It surely makes more sense there than as part of Kawa. Andrew.
Re: ASM and gnu.bytecode
Audrius Meskauskas wrote: Only part of RMIC (direct bytecode generation) is really dependent from ASM. That part which supports the source code generation is not dependent, was a separate compiler in the past and can be easily separated apart again. If we do not like ASM, this should make using the alternative replacement easier, as only the bytecode generating part needs to be rewritten. The classes being generated are also relatively simple. The direct bytecode generation is needed for performance and compatibility reasons. If ASM is replaced with gnu.bytecode, then the direct bytecode generation RMIC should be ported rather than removed. FWIW, porting from ASM 1.x to ASM 2.x was not very involved, and the update from 2.x to 3.x was even more trivial: http://lists.gnu.org/archive/html/cp-tools-discuss/2006-03/msg0.html I'm not sure trivial porting work between versions warrants an all-out replacement. Tom
Re: ASM and gnu.bytecode
Andrew Haley wrote: Per, if you're listening: may we incorporate gnu.bytecode within classpath? Absolutely. Might as well get the most recent version from svn: http://www.gnu.org/software/kawa/Getting-Kawa.html However, Tom does have a point that sticking with ASM is probably easier. Kawa probably does make it easier to generate quality code for a compiler (and can do it very fast), but I doubt you'd get much gain using it for rmic, especially since the ASM version more-or-less works. Here is an article I wrote on using gnu.bytecode: http://per.bothner.com/compiling-regexps.html It surely makes more sense there than as part of Kawa. Huh? Kawa needs gnu.bytecode amd can't assume Classpath - at least not yet! -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: ASM and gnu.bytecode
Thomas Fitzsimmons writes: > Audrius Meskauskas wrote: > > Only part of RMIC (direct bytecode generation) is really dependent from > > ASM. That part which supports the source code generation is not > > dependent, was a separate compiler in the past and can be easily > > separated apart again. If we do not like ASM, this should make using the > > alternative replacement easier, as only the bytecode generating part > > needs to be rewritten. The classes being generated are also relatively > > simple. > > The direct bytecode generation is needed for performance and > compatibility reasons. If ASM is replaced with gnu.bytecode, then the > direct bytecode generation RMIC should be ported rather than removed. > > FWIW, porting from ASM 1.x to ASM 2.x was not very involved, and the > update from 2.x to 3.x was even more trivial: > > http://lists.gnu.org/archive/html/cp-tools-discuss/2006-03/msg0.html > > I'm not sure trivial porting work between versions warrants an all-out > replacement. Sure it does. At the present time, gcj is mostly self-contained, but we're soon to be adding a new dependency: ecj. We also need gjavah to work, and at the moment that needs ASM. That's one more external dependency for gcj, and one with an unstable API. Having gcj depend not only on ASM but also on a *specific version* of ASM is intolerable. If gnu.bytecode will do the job, we should use it. Andrew.
Re: ASM and gnu.bytecode
Andrew Haley wrote: Having gcj depend not only on ASM but also on a *specific version* of ASM is intolerable. If gnu.bytecode will do the job, we should use it. While gnu.bytecode (along with gnu.math) has been fairly stable for quite a while, and it probably has been the most stable part of Kawa, I have not guaranteed backward compatibility in the past. Of course if other projects start depending on gnu.bytecode, I'll try to not break things! One bonus of using gnu.bytecode: the class gnu.bytecode.dump is a direct clone on jcf-dump. (However, it doesn't have all the features of jcf-dump, and jcf-dump is fast and compact.) -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Mauve regressions 0.92/0.93-pre
Hi, We seem to be doing pretty well on regression with respect to 0.92. Here is the current list. It would be good to get this list down a bit before we branch for 0.93. The number of new passes has gone up a lot. So it looks like 0.93 will be a much better release than 0.92. - gnu.javax.swing.text.html.parser.support.Parser.Text - gnu.javax.swing.text.html.parser.support.Parser.textPreProcessor_Test Both fail with subtle differences in the result of what gets parsed. is this caused by the changes on how to handle whitespace? - java.awt.datatransfer.Clipboard.clipboardFlavors - java.awt.datatransfer.DataFlavor.flavor Failures are in cases where the representation class is one of the standard classes like java.io.InputStream. I'll look into this. - java.awt.Frame.isDisplayable2 This might be a non-deterministic test. But it seems these two checks are regularly failing: FAIL: line 59: after showing dialog [1] -- boolean passed to check was false FAIL: line 61: after showing dialog [3] -- got false but expected true - java.awt.image.IndexColorModel.getAlpha Fails with the following stacktrace: java.lang.ArrayIndexOutOfBoundsException: 99 at java.awt.image.IndexColorModel.getAlpha(IndexColorModel.java:585) at gnu.testlet.java.awt.image.IndexColorModel.getAlpha.test(getAlpha.java:76) at RunnerProcess.runtest(RunnerProcess.java:360) at RunnerProcess.runAndReport(RunnerProcess.java:415) at RunnerProcess.main(RunnerProcess.java:227) - java.awt.List.ScrollbarPaintTest PaintTests can sometimes be undeterministic, but this one seems to fail not deterministically with: FAIL: line 75: [2] -- boolean passed to check was false - java.net.ServerSocket.AcceptTimeout This one fails undeterministifcally with either: FAIL: line 44: [1] -- got 200 but expected 0 Or the following stacktrace: java.net.BindException: Address already in use at gnu.java.net.VMPlainSocketImpl.bind(Native Method) at gnu.java.net.VMPlainSocketImpl.bind(VMPlainSocketImpl.java:302) at gnu.java.net.PlainSocketImpl.bind(PlainSocketImpl.java:306) at java.net.ServerSocket.bind(ServerSocket.java:254) at java.net.ServerSocket.(ServerSocket.java:185) at java.net.ServerSocket.(ServerSocket.java:159) at java.net.ServerSocket.(ServerSocket.java:141) at gnu.testlet.java.net.ServerSocket.AcceptTimeout.test(AcceptTimeout.java:41) I suspect the second is caused by the later. - java.sql.Timestamp.TimestampTest - java.text.MessageFormat.format - java.text.MessageFormat.parse - java.text.NumberFormat.UK - locales.LocaleTest These all seem to be caused by the last Decimal/NumberFormat patch. We get a couple of new passes back for it, but it would be good to investigate these failures. - javax.swing.JSpinner.DefaultEditor.propertyChange - javax.swing.JSpinner.DefaultEditor.stateChanged Similar. Both have checks fail like: FAIL: line 49: (PropertyChangeEvent) [3] -- got 88.0 but expected 88 FAIL: line 46: (ChangeEvent) [3] -- got 99.0 but expected 99 - java.util.Vector.AcuniaVectorTest Fails because it expects a NullPointerException on a v.removeAll(null) and v.retainAll(null), where the Vector v is empty. This seems a little pedantic, but might be right. - javax.swing.border.TitledBorder.getBorderInsets All results seem slightly off with this test. - javax.swing.JToolTip.setTipText Has one new check failure: FAIL: line 53: [2] -- got 2 but expected 1 - javax.swing.text.StringContent.createPosition - javax.swing.text.StringContent.getChars Not investigated yet. Anybody with some more insight into these regressions please do mail to the list. In general we seem to be doing really well compared to 0.92. Cheers, Mark signature.asc Description: This is a digitally signed message part
building 0.93 on Mac OS X 10.3.9
Hi, i thought i'd share my experiences building classpath 0.93 on a mac. I've had add a missing #include in classpath-0.93-pre/native/jni/native-lib/cpnet.[ch] before #include to make sure "n_long" is a defined type then add manual override of presence of HAVE_SO_NOSIGPIPE, because even though it is present in /usr/include/sys/socket.h it isnt correctly detected by configure and finally in classpath-0.93-pre/native/jni/java-nio/gnu_java_nio_VMChannel.c at line 1515 replace O_SYNC with O_FSYNC. hope this helps & this is the proper list to report this. jb.
[Bug classpath/23185] TARGET_NATIVE_FILE_AVAILABLE broken for select case
--- Comment #1 from robilad at kaffe dot org 2006-11-26 21:07 --- the native/target directory does not exist any more in classpath since 0.92+cvs native layer merge. -- robilad at kaffe dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23185 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: newbie question: compiling the examples
On Sun, 2006-11-26 at 17:23 +1100, Alexander Samad wrote: > On Sun, Nov 26, 2006 at 05:03:33PM +1100, Alexander Samad wrote: > > I have just come across classpath, I am using debian amd64. I have > > downloaded > > the current version 0.92 > > > > When I try the examples I get > > [...] > had a bit more of a play with it and I had to add in all the *.java files to > command line, once it all compiled it ran fine Great! Hope you like the examples. There is also a Makefile in the examples dir when you build from CVS that generates an examples.zip file with everything you need 9which should be installed if you run from an installation). And there is a README in the examples dir that should give you all instructions you need when doing it by hand (attached). Cheers, Mark This directory contains example programs that show how the GNU Classpath library can be used. Each example has its own package under gnu.classpath.examples and has a class Demo which contains a main() method to run that particular example. The examples can be compiled and run with gcj as follows: gcj -o swingdemo --main=gnu.classpath.examples.swing.Demo \ gnu/classpath/examples/swing/Demo.java \ gnu/classpath/examples/swing/GNULookAndFeel.java ./swingdemo Or with a traditional byte code interpreter like: gcj -C gnu/classpath/examples/awt/Demo.java gij gnu.classpath.examples.awt.Demo The installation also comes with an examples.zip archive that contains all needed resources and compiled byte code class files that can be run as follows: kaffe -classpath examples.zip gnu.classpath.examples.awt.Demo kaffe -classpath examples.zip gnu.classpath.examples.swing.Demo The jawt Demo needs some extra support library that currently needs to be build by hand. The following assumes GNU Classpath was installed in /usr/local/classpath, if you installed it somewhere else then adjust the -I and -L paths accordingly. The included Makefile.jawt is setup this way. You can invoke it with: make -f Makefile.jawt Or you can compile by hand as follows: gcj -C gnu/classpath/examples/jawt/DemoJAWT.java gcjh -jni gnu.classpath.examples.jawt.DemoJAWT -o DemoJAWT.h gcc -g -O0 -Wall -I. -I/usr/X11R6/include -L. -L/usr/X11R6/lib \ -I/usr/local/classpath/include -L/usr/local/classpath/lib/classpath \ -lX11 -ljawtgnu -shared -o libDemoJAWT.so \ gnu/classpath/examples/jawt/DemoJAWT.c You can then run the example as follows: export LD_LIBRARY_PATH=.:/usr/local/classpath/lib/classpath jamvm gnu.classpath.examples.jawt.DemoJAWT The java2d benchmarking demos include a GTK widget to measure the native speed of some basic java2d options, without the JNI overhead. You can invoke it with: make -f Makefile.java2d Or you can compile by hand as follows: gcc -g -O0 -Wall -I./gnu/classpath/examples/java2d \ -o cairobench gnu/classpath/examples/java2d/bench.c \ `pkg-config --libs --cflags gtk+-2.0` You can then run the example as follows: ./cairobench All example code is distributed under the GNU General Public License (GPL). The example icons used in some of the examples come from gnome-icon-theme version 1.2.3 and are also distributed under the GPL. All these images are stored in the directory gnu/classpath/examples/icons/. More free icons can be found in the gnome-icon-theme package: http://ftp.gnome.org/pub/GNOME/sources/gnome-icon-theme/ GNU Classpath examples are free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. GNU Classpath examples are distributed in the hope that they will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with GNU Classpath examples; see the file COPYING. If not, write to the Free Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
FYI: few DecimalFormat fixes
Il giorno dom, 26/11/2006 alle 21.06 +0100, Mark Wielaard ha scritto:
> - java.sql.Timestamp.TimestampTest
> - java.text.MessageFormat.format
> - java.text.MessageFormat.parse
> - java.text.NumberFormat.UK
> - locales.LocaleTest
>
> These all seem to be caused by the last Decimal/NumberFormat patch. We
> get a couple of new passes back for it, but it would be good to
> investigate these failures.
>
> - javax.swing.JSpinner.DefaultEditor.propertyChange
> - javax.swing.JSpinner.DefaultEditor.stateChanged
>
> Similar. Both have checks fail like:
> FAIL: line 49: (PropertyChangeEvent) [3] -- got 88.0 but expected 88
> FAIL: line 46: (ChangeEvent) [3] -- got 99.0 but expected 99
I've fixed some of them. There are a couple of them difficult to find,
though.
In one case the specs defines two mutually exclusives scenarios :)
They say (Format) that "pos" should not be null, or an NPE would be
generated, but then, in MessageFormat, let pass this example in one of
the methods:
format(argument, new StringBuffer(), null);
^^
:)
I've fixed this, though we now check in DecimalFormat for null, which is
not really correct.
I'll search for the other failures tomorrow.
Mario
2006-11-27 neugens <[EMAIL PROTECTED]>
* java/text/DecimalFormat.java (formatInternal): Add an explicit test
for FieldPosition to be null.
Check if the factional part is just 0 and can be omitted from the
result.
(scanNegativePattern): Fixed index out of bound exception when
searching
for international currency symbol in negative pattern.
--
Lima Software, SO.PR.IND. s.r.l.
http://www.limasoftware.net/
pgp key: http://subkeys.pgp.net/
Please, support open standards:
http://opendocumentfellowship.org/petition/
http://www.nosoftwarepatents.com/
### Eclipse Workspace Patch 1.0
#P classpath
Index: java/text/DecimalFormat.java
===
RCS file: /cvsroot/classpath/classpath/java/text/DecimalFormat.java,v
retrieving revision 1.27
diff -u -r1.27 DecimalFormat.java
--- java/text/DecimalFormat.java 25 Nov 2006 18:20:54 - 1.27
+++ java/text/DecimalFormat.java 27 Nov 2006 02:42:20 -
@@ -1650,7 +1650,7 @@
currencySymbol = CURRENCY_SYMBOL;
// if \u00A4 is doubled, we use the international currency symbol
-if (i < len && pattern.charAt(i + 1) == '\u00A4')
+if ((i + 1) < len && pattern.charAt(i + 1) == '\u00A4')
{
currencySymbol = symbols.getInternationalCurrencySymbol();
i = i + 2;
@@ -1728,6 +1728,15 @@
private void formatInternal(BigDecimal number, boolean isLong,
StringBuffer dest, FieldPosition fieldPos)
{
+// The specs says that fieldPos should not be null, and that we
+// should throw a NPE, but it seems that in few classes that
+// reference this one, fieldPos is set to null.
+// This is even defined in the javadoc, see for example MessageFormat.
+// I think the best here is to check for fieldPos and build one if it is
+// null. If it cause harms or regressions, just remove this line and
+// fix the classes in the point of call, insted.
+if (fieldPos == null) fieldPos = new FieldPosition(0);
+
int _multiplier = this.multiplier;
// used to track attribute starting position for each attribute
@@ -1853,7 +1862,7 @@
// the sum of the minimum integer and maximum fraction
// digits, and does not take into account the maximun integer
// digits to display.
-// This methods takes care of the integer portion of the mantissa.
+
if (attributeStart < 0)
attributeStart = Math.max(dest.length() - 1, 0);
appendDigit(intPart, dest, this.groupingUsed);
@@ -1916,10 +1925,33 @@
}
fractPart = adjustTrailingZeros(fractPart, digits);
-appendDigit(fractPart, dest, false);
-endIndexFract = dest.length();
-addAttribute(Field.FRACTION, attributeStart, endIndexFract);
+// FIXME: this code must be improved
+// now check if the factional part is just 0, in this case
+// we need to remove the '.' unless requested
+boolean allZeros = true;
+char fracts[] = fractPart.toCharArray();
+for (int i = 0; i < fracts.length; i++)
+ {
+if (fracts[i] != '0')
+ allZeros = false;
+ }
+
+if (!allZeros || minimumFractionDigits > 0)
+ {
+appendDigit(fractPart, dest, false);
+endIndexFract = dest.length();
+addAttribute(Field.FRACTION, attributeStart, endIndexFract);
+ }
+else if (!this.decimalSeparatorAlwaysShown)
+ {
+dest.deleteCharAt(dest.length() - 1);
+ }
+else
+ {
+endIndexFract = dest.
