From fitzsim at redhat.com Fri Apr 1 04:18:12 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 31 Mar 2005 23:18:12 -0500 Subject: [fedora-java] db merging script In-Reply-To: <20050329224815.GB20638@redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> Message-ID: <1112329092.30802.142.camel@tortoise.toronto.redhat.com> Hi, On Tue, 2005-03-29 at 17:48 -0500, Andrew Overholt wrote: > > Could these go in java-gcj-compat? Or maybe as RPM macros? > > Tom Fitzsimmons has offered to put these in java-gcj-compat. > These scripts are in java-1.4.2-gcj-compat-1.4.2.0-40jpp_14rh. I renamed them find-and-nativify, nativify and rename-gcj-db. Tom From greenrd at presidium.org Sun Apr 3 02:08:18 2005 From: greenrd at presidium.org (Robin Green) Date: Sat, 2 Apr 2005 21:08:18 -0500 (EST) Subject: [fedora-java] Debuginfo problems Message-ID: 3 problems with building -debuginfo packages for native java packages. I'm using latest rawhide, find-and-nativify to nativify [which I keep typo-ing as nativity for some reason ;) ] and ecj as source-to-bytecode compiler. 1. gcj outputs bogus source filenames for inner classes, which makes rpmbuild spew a shedload of errors like this when building the -debuginfo package: cpio: rssowl_1_1_src/src/java/net/sourceforge/rssowl/controller/GUI$4.java: No such file or directory I filed this as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20735 2. cpio outputs some more "No such file or directory errors" referring to a few classes whose source files aren't part of this project at all, e.g. cpio: rssowl_1_1_src/src/java/org/xml/sax/EntityResolver.java: No such file or directory cpio: rssowl_1_1_src/src/java/org/xml/sax/ErrorHandler.java: No such file or directory cpio: rssowl_1_1_src/src/java/org/xml/sax/InputSource.java: No such file or directory cpio: rssowl_1_1_src/src/java/org/xml/sax/SAXParseException.java: No such file or directory 3. For some strange reason - I only changed like one line in my spec file - I'm now getting this odd error: Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/rssowl-1.1-1rdg error: Installed (but unpackaged) file(s) found: /usr/lib/debug/usr/lib/rssowl/librssowl.jar.so.debug /usr/src/debug/rssowl_1_1_src/src/java/net/sourceforge/rssowl/controller/ChannelInfo.java /usr/src/debug/rssowl_1_1_src/src/java/net/sourceforge/rssowl/controller/DisposeListenerImpl.java etc. (continues with list of lots and lots of source files) So, I'm turning off -debuginfo building for my specfile for now. -- Robin From green at redhat.com Sun Apr 3 23:41:36 2005 From: green at redhat.com (Anthony Green) Date: Sun, 03 Apr 2005 16:41:36 -0700 Subject: [fedora-java] jogl package Message-ID: <1112571697.5223.25.camel@localhost.localdomain> Here's my first stab at an RPM with the new scripts (find-and-nativify and rebuild-gcj-db). It's the OpenGL java bindings: http://people.redhat.com/green/FC4 A couple of observations.... It's still not super-trivial to add native versions of jar files. See attached spec file. On the other hand, I don't know how we could make it simpler. Our libjawt.so.6 is a bit of a problem. I was unable to run any jogl code with a non-gcj alternative, since they all pick up /usr/lib/libjawt.so.6, which has references to our gtk peers and fails to load. Should libjawt.so be an alternative? Or can we install it somewhere gcj specific? AG -------------- next part -------------- Name: jogl Version: 1.1b10 Release: 1fc Epoch: 0 Summary: Java bindings for the OpenGL API. Group: System Environment/Libraries License: BSD URL: http://jogl.dev.java.net/ Source0: jogl-src.zip Source1: jogl.properties Source2: SGIFreeSWLicB.1.1.ps Source3: jogl-README.txt Patch0: %{name}-build.patch BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildRequires: ant, antlr, java-1.4.2-gcj-compat-devel, jpackage-utils >= 0:1.5 Requires: java-1.4.2-gcj-compat %description The JOGL Project hosts a reference implementation of the Java bindings for OpenGL API, and is designed to provide hardware-supported 3D graphics to applications written in the Java programming language. Is is part of a suite of open-source technologies initiated bu the Game Technology Group at Sun Microsystems. JOGL provides full access to the APIs in the OpenGL 1.5 specification as well as nearly all vendor extensions, and integrated with the AWT and Swing widget sets. %package javadoc Summary: Javadoc for %{name} Group: Development/Documentation #BuildRequires: java-javadoc %description javadoc %{summary}. %prep %setup -q -n jogl %patch0 -p0 cp %{SOURCE1} . cp %{SOURCE2} . cp %{SOURCE3} . %build (cd make && ant -Duser.home=/usr/src/redhat/SOURCES linux javadoc.dev.x11) # Rename the jar into a versioned jar name and create the .so version. mv build/jogl.jar build/%{name}-%{version}.jar find-and-nativify . "$RPM_OPT_FLAGS -fPIC -fjni" %install rm -rf $RPM_BUILD_ROOT install -dm 755 $RPM_BUILD_ROOT%{_javadir} install -pm 644 build/%{name}-%{version}.jar $RPM_BUILD_ROOT%{_javadir}/%{name}-%{version}.jar ln -s %{name}-%{version}.jar $RPM_BUILD_ROOT%{_javadir}/%{name}.jar install -dm 755 $RPM_BUILD_ROOT%{_libdir} install -pm 755 build/obj/libjogl.so $RPM_BUILD_ROOT%{_libdir}/libjogl.so install -pm 755 build/lib%{name}-%{version}.jar.so $RPM_BUILD_ROOT%{_libdir}/lib%{name}-%{version}.jar.so install -pm 755 build/lib%{name}-%{version}.jar.so $RPM_BUILD_ROOT%{_libdir}/lib%{name}-%{version}.jar.so ln -s lib%{name}-%{version}.jar.so $RPM_BUILD_ROOT%{_libdir}/lib%{name}.jar.so install -dm 755 $RPM_BUILD_ROOT%{_javadocdir}/%{name}-%{version} cp -pR javadoc_jogl_dev/* $RPM_BUILD_ROOT%{_javadocdir}/%{name}-%{version} ln -s %{name}-%{version} $RPM_BUILD_ROOT%{_javadocdir}/%{name} gcjdbdir=$RPM_BUILD_ROOT`gcj-dbtool -p %{_libdir}`.d install -dm 755 $gcjdbdir gcj-dbtool -n $gcjdbdir/%{name}-%{version}.db 80000 gcj-dbtool -f $gcjdbdir/%{name}-%{version}.db \ $RPM_BUILD_ROOT%{_javadir}/%{name}-%{version}.jar %{_libdir}/lib%{name}-%{version}.jar.so %clean rm -rf $RPM_BUILD_ROOT %post rebuild-gcj-db %{_libdir} %postun rebuild-gcj-db %{_libdir} %post javadoc rm -f %{_javadocdir}/%{name} ln -s %{name}-%{version} %{_javadocdir}/%{name} %files %defattr(644,root,root,755) %doc SGIFreeSWLicB.1.1.ps %doc jogl-README.txt %doc doc/* %{_javadir}/*.jar %{_libdir}/* %files javadoc %defattr(644,root,root,755) %doc %{_javadocdir}/%{name}-%{version} %ghost %doc %{_javadocdir}/%{name} %changelog * Sun Apr 3 2005 Anthony Green - 0:1.1b10-1fc - Created. From fitzsim at redhat.com Mon Apr 4 05:24:31 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 04 Apr 2005 01:24:31 -0400 Subject: [fedora-java] jogl package In-Reply-To: <1112571697.5223.25.camel@localhost.localdomain> References: <1112571697.5223.25.camel@localhost.localdomain> Message-ID: <1112592272.9902.5.camel@rh-ibm-t41> On Sun, 2005-04-03 at 16:41 -0700, Anthony Green wrote: > Here's my first stab at an RPM with the new scripts (find-and-nativify > and rebuild-gcj-db). It's the OpenGL java bindings: > > http://people.redhat.com/green/FC4 > > A couple of observations.... > > It's still not super-trivial to add native versions of jar files. See > attached spec file. On the other hand, I don't know how we could make > it simpler. > > Our libjawt.so.6 is a bit of a problem. I was unable to run any jogl > code with a non-gcj alternative, since they all pick > up /usr/lib/libjawt.so.6, which has references to our gtk peers and > fails to load. Should libjawt.so be an alternative? Or can we install > it somewhere gcj specific? > I think we should rename it libgcj-jawt.so. libjawt-using apps will look for $JAVA_HOME/jre/lib/i386/libjawt.so which we already have a symlink for in java-gcj-compat. Tom From tromey at redhat.com Mon Apr 4 18:49:57 2005 From: tromey at redhat.com (Tom Tromey) Date: 04 Apr 2005 12:49:57 -0600 Subject: [fedora-java] db merging script In-Reply-To: <16972.17579.880662.402733@cuddles.cambridge.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> <200503301519.j2UFJpAv024829@littlepinkcloud.com> <16971.37411.793787.473750@cuddles.cambridge.redhat.com> <16972.17579.880662.402733@cuddles.cambridge.redhat.com> Message-ID: >>>>> "Andrew" == Andrew Haley writes: Andrew> So we have an additional "-0" arg to dbtool? Sounds good to me. Tom From overholt at redhat.com Tue Apr 5 01:36:30 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 4 Apr 2005 21:36:30 -0400 Subject: [fedora-java] db merging script In-Reply-To: <20050329224815.GB20638@redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> Message-ID: <20050405013630.GA29238@redhat.com> * Andrew Overholt [2005-03-29 16:52]: [...] > > (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB) [...] I'm thinking this should be: (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) What's the purpose of the extraneous $DB? I don't think we want it because we actually want the entire db recreated every time. We don't want entries that are not in sub-dbs in $DB.d to be in the resultant db. Does that make sense? Andrew From fitzsim at redhat.com Tue Apr 5 03:43:28 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 04 Apr 2005 23:43:28 -0400 Subject: [fedora-java] db merging script In-Reply-To: <20050405013630.GA29238@redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> <20050405013630.GA29238@redhat.com> Message-ID: <1112672608.2981.38.camel@rh-ibm-t41> On Mon, 2005-04-04 at 21:36 -0400, Andrew Overholt wrote: > * Andrew Overholt [2005-03-29 16:52]: > [...] > > > (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB) > [...] > > I'm thinking this should be: > > (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) > > What's the purpose of the extraneous $DB? I don't think we want it because > we actually want the entire db recreated every time. We don't want entries > that are not in sub-dbs in $DB.d to be in the resultant db. Does that make > sense? > The -m option cases the destination database to be overwritten. If you want to maintain its contents you need to specify it as a source database. From "gcj-dbtool --help" output: gcj-dbtool -m dest.gcjdb [source.gcjdb]... - Merge gcj map databases into dest Replaces dest To add to dest, include dest in the list of sources But as I understand it, rebuild-gcj-db is supposed to rebuild classmap.db from scratch. If that's the intended behaviour (and is safe -- aph?) then (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) is correct. Tom From aph at redhat.com Tue Apr 5 08:38:18 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Apr 2005 09:38:18 +0100 Subject: [fedora-java] db merging script In-Reply-To: <20050405013630.GA29238@redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> <20050405013630.GA29238@redhat.com> Message-ID: <16978.20090.942656.185821@cuddles.cambridge.redhat.com> Andrew Overholt writes: > * Andrew Overholt [2005-03-29 16:52]: > [...] > > > (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB) > [...] > > I'm thinking this should be: > > (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) > > What's the purpose of the extraneous $DB? I don't think we want it because > we actually want the entire db recreated every time. We don't want entries > that are not in sub-dbs in $DB.d to be in the resultant db. Does that make > sense? Yes. The extra $DB is there because xargs will call gcj-dbtool multiple times if it needs to. The right answer is not to use xargs. Andrew. From aph at redhat.com Tue Apr 5 14:15:23 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Apr 2005 15:15:23 +0100 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> <200503301519.j2UFJpAv024829@littlepinkcloud.com> <16971.37411.793787.473750@cuddles.cambridge.redhat.com> Message-ID: <16978.40315.135940.44507@cuddles.cambridge.redhat.com> Tom Tromey writes: > >> This needs a corresponding gcj.texi patch. > > Andrew> Yes, but I'm waiting for feedback before I write it. > > I think the idea is sound, and needed. > > I think we should also support reading "find -0" output, > i.e. '\0'-separated strings. That would let us support file names > with spaces in them, and other oddities. 2005-04-05 Andrew Haley * gnu/gcj/tools/gcj_dbtool/Main.java (Fileset): New class. (Tokenizer): New class. (getFiles): New method. (main): Add "-" argument. Add "-0" argument. Read list of files from stdin when merging map databases. (usage): Add "-" argument. Add "-0" argument. Minor corrections. Index: gnu/gcj/tools/gcj_dbtool/Main.java =================================================================== RCS file: /cvs/gcc/gcc/libjava/gnu/gcj/tools/gcj_dbtool/Main.java,v retrieving revision 1.9 diff -p -2 -c -r1.9 Main.java *** gnu/gcj/tools/gcj_dbtool/Main.java 25 Mar 2005 00:38:43 -0000 1.9 --- gnu/gcj/tools/gcj_dbtool/Main.java 5 Apr 2005 14:10:33 -0000 *************** public class Main *** 23,27 **** --- 23,42 ---- public static void main (String[] s) { + boolean fileListFromStdin = false; + char filenameSeparator = ' '; + insist (s.length >= 1); + + if (s[0].equals("-") || + s[0].equals("-0")) + { + if (s[0].equals("-0")) + filenameSeparator = (char)0; + fileListFromStdin = true; + String[] newArgs = new String[s.length - 1]; + System.arraycopy(s, 1, newArgs, 0, s.length - 1); + s = newArgs; + } + if (s[0].equals("-v") || s[0].equals("--version")) { *************** public class Main *** 146,150 **** { // Merge databases. ! insist (s.length >= 3); try { --- 161,166 ---- { // Merge databases. ! insist (s.length >= 3 ! || fileListFromStdin && s.length == 2); try { *************** public class Main *** 156,171 **** int newSize = 0; int newStringTableSize = 0; ! PersistentByteMap[] sourceMaps = new PersistentByteMap[s.length - 2]; // Scan all the input files, calculating worst case string // table and hash table use. ! for (int i = 2; i < s.length; i++) ! { ! PersistentByteMap b ! = new PersistentByteMap(new File(s[i]), ! PersistentByteMap.AccessMode.READ_ONLY); ! newSize += b.size(); ! newStringTableSize += b.stringTableSize(); ! sourceMaps[i - 2] = b; ! } newSize *= 1.5; // Scaling the new size by 1.5 results in --- 172,195 ---- int newSize = 0; int newStringTableSize = 0; ! Fileset files = getFiles(s, 2, fileListFromStdin, ! filenameSeparator); ! PersistentByteMap[] sourceMaps ! = new PersistentByteMap[files.size()]; ! // Scan all the input files, calculating worst case string // table and hash table use. ! { ! Iterator it = files.iterator(); ! int i = 0; ! while (it.hasNext()) ! { ! PersistentByteMap b ! = new PersistentByteMap((File)it.next(), ! PersistentByteMap.AccessMode.READ_ONLY); ! newSize += b.size(); ! newStringTableSize += b.stringTableSize(); ! sourceMaps[i++] = b; ! } ! } newSize *= 1.5; // Scaling the new size by 1.5 results in *************** public class Main *** 173,177 **** PersistentByteMap map = PersistentByteMap.emptyPersistentByteMap ! (temp, newSize, newStringTableSize); for (int i = 0; i < sourceMaps.length; i++) --- 197,201 ---- PersistentByteMap map = PersistentByteMap.emptyPersistentByteMap ! (temp, newSize, newStringTableSize); for (int i = 0; i < sourceMaps.length; i++) *************** public class Main *** 297,310 **** + " gcj-dbtool -n file.gcjdb [size] - Create a new gcj map database\n" + " gcj-dbtool -a file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a new gcj map database\n" + " gcj-dbtool -f file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a new gcj map database\n" + " gcj-dbtool -t file.gcjdb - Test a gcj map database\n" + " gcj-dbtool -l file.gcjdb - List a gcj map database\n" ! + " gcj-dbtool -m dest.gcjdb [source.gcjdb]...\n" ! + " - Merge gcj map databases into dest\n" ! + " Replaces dest\n" ! + " To add to dest, include dest in the list of sources\n" ! + " gcj-dbtool -p [LIBDIR] - Print default database name"); } --- 321,337 ---- + " gcj-dbtool -n file.gcjdb [size] - Create a new gcj map database\n" + " gcj-dbtool -a file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a gcj map database\n" + " gcj-dbtool -f file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a gcj map database\n" + " gcj-dbtool -t file.gcjdb - Test a gcj map database\n" + " gcj-dbtool -l file.gcjdb - List a gcj map database\n" ! + " gcj-dbtool [-][-0] -m dest.gcjdb [source.gcjdb]...\n" ! + " - Merge gcj map databases into dest\n" ! + " Replaces dest\n" ! + " To add to dest, include dest in the list of sources\n" ! + " If the first arg is -, read the list from stdin\n" ! + " If the first arg is -0, filenames separated by nul\n" ! + " gcj-dbtool -p [LIBDIR] - Print default database name" ! ); } *************** public class Main *** 406,409 **** return hexBytes.toString(); } } - --- 433,535 ---- return hexBytes.toString(); } + + + // Return a Fileset, either from a String array or from System.in, + // depending on fileListFromStdin. + private static final Fileset getFiles(String[] s, int startPos, + boolean fileListFromStdin, + char separator) + { + if (fileListFromStdin) + return new Fileset(System.in, separator); + else + return new Fileset(s, startPos, s.length); + } + } + + // Parse a stream into tokens. The separator can be any char, and + // space is equivalent to any whitepace character. + class Tokenizer + { + final Reader r; + final char separator; + + Tokenizer(Reader r, char separator) + { + this.r = r; + this.separator = separator; + } + + boolean isSeparator(int c) + { + if (Character.isWhitespace(separator)) + return Character.isWhitespace((char)c); + else + return c == separator; + } + + // Parse a token from the input stream. Return the empty string + // when the stream is exhausted. + String nextToken () + { + StringBuffer buf = new StringBuffer(); + int c; + try + { + while ((c = r.read()) != -1) + { + if (! isSeparator(c)) + { + buf.append((char)c); + break; + } + } + while ((c = r.read()) != -1) + { + if (isSeparator(c)) + break; + else + buf.append((char)c); + } + } + catch (java.io.IOException e) + { + } + return buf.toString(); + } + } + + // A Fileset is a container for a set of files; it can be created + // either from a string array or from an input stream, given a + // separator character. + class Fileset + { + LinkedHashSet files = new LinkedHashSet(); + + Fileset (String[] s, int start, int end) + { + for (int i = start; i < end; i++) + { + files.add(new File(s[i])); + } + } + + Fileset (InputStream is, char separator) + { + Reader r = new BufferedReader(new InputStreamReader(is)); + Tokenizer st = new Tokenizer(r, separator); + String name; + while (! "".equals(name = st.nextToken())) + files.add(new File(name)); + } + + Iterator iterator() + { + return files.iterator(); + } + + int size() + { + return files.size(); + } } From aph at redhat.com Tue Apr 5 14:32:51 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Apr 2005 15:32:51 +0100 Subject: [fedora-java] db merging script In-Reply-To: <16978.40315.135940.44507@cuddles.cambridge.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> <200503301519.j2UFJpAv024829@littlepinkcloud.com> <16971.37411.793787.473750@cuddles.cambridge.redhat.com> <16978.40315.135940.44507@cuddles.cambridge.redhat.com> Message-ID: <16978.41363.834663.889985@cuddles.cambridge.redhat.com> And the corresponding texinfo patch. Andrew. Index: gcj.texi =================================================================== RCS file: /cvs/gcc/gcc/gcc/java/gcj.texi,v retrieving revision 1.77 diff -u -r1.77 gcj.texi --- gcj.texi 29 Mar 2005 21:46:49 -0000 1.77 +++ gcj.texi 5 Apr 2005 14:31:02 -0000 @@ -990,9 +990,9 @@ @c man begin SYNOPSIS gcj-dbtool gcj-dbtool @option{OPTION} @var{DBFILE} [@option{MORE}] @dots{} -gcj-dbtool [@option{-n}] [@option{-a}] [@option{-f}] +gcj-dbtool [@option{-0}] [@option{-}] [@option{-n}] [@option{-a}] [@option{-f}] [@option{-t}] [@option{-l}] [@option{-p} [@var{LIBDIR}]] - [@option{-v}] [@option{--version}] [@option{--help}] + [@option{-v}] [@option{-m}] [@option{--version}] [@option{--help}] @c man end @c man begin SEEALSO gij @@ -1037,6 +1037,18 @@ that @var{LIB} exists before adding it to the database; @option{-f} skips this check. + at item [@option{-}][@option{-0}] -m @var{DBFILE} @var{DBFILE},[@var{DBFILE}] +Merge a number of databases. The output database overwrites any +existing database. To add databases into an existing database, +include the destination in the list of sources. + +If @option{-} or @option{-0} are used, the list of files to read is +taken from standard input instead of the command line. For + at option{-0}, Input filenames are terminated by a null character +instead of by whitespace. Useful when arguments might contain white +space. The GNU find -print0 option produces input suitable for this +mode. + @item -t @var{DBFILE} Test a database. From overholt at redhat.com Tue Apr 5 14:55:40 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 5 Apr 2005 10:55:40 -0400 Subject: [fedora-java] Eclipse UI Tests Message-ID: <20050405145540.GA12831@redhat.com> Hi, I was talking with Billy last night about Eclipse unit tests and I ran the UI ones this morning. There are 806 tests and we get 152 Errors and 40 Failures. 144 of the 152 Errors are from org.eclipse.ui.tests.dnd.DragTestSuite in which Billy said to expect errors (since this is 3.1M5a I'm testing). I'd like to set things up to run these automatically (Aaron is looking into it) and get some hard data that we can work with. The one thing that bothered me is that the tests took about 43 minutes to run on my P4 3 GHz with 1 GB RAM. Billy says the tests take only about 10 minutes normally. I'll try to spend some time figuring out where the time goes. This could have been my machine/setup but they took about the same amount of time to run on my laptop which is a much less beefier machine so I sort of doubt it. This is how Billy taught me to run the tests (for future reference): . start Eclipse with a new workspace eclipse -data testworkspace . switch to CVS perspective and add the Eclipse repo (dev.eclipse.org - /home/eclipse - anonymous - pserver) . expand the Eclipse repo and expand versions . expand org.eclipse.releng . expand I20050219-1500 (the tag for 3.1M5a) . expand maps . double-click on ui.map . note that plugin at org.eclipse.ui.tests=v20050218-1200 . close ui.map and expand org.eclipse.ui.tests . check out org.eclipse.ui.tests v20050218-1200 . switch to the Java perspective . once your workspace finishes building, there will be errors in a few things ... we only care about the errors in plugin.xml so edit it to comment out or remove the two offending lines . expand Eclipse UI Tests -> org.eclipse.ui.tests . right-click on UiTestSuite.java and click Run As -> JUnit Plug-in Test . beside Package Explorer and Hierarchy, you should get a JUnit tab; quickly select it and select the Hierarchy tab within before the tests start up . let the tests run without playing with your computer because some of the tests rely on focus Andrew From aluchko at redhat.com Tue Apr 5 17:54:43 2005 From: aluchko at redhat.com (Aaron Luchko) Date: Tue, 05 Apr 2005 13:54:43 -0400 Subject: [fedora-java] Re: Eclipse UI Tests In-Reply-To: <20050405145540.GA12831@redhat.com> References: <20050405145540.GA12831@redhat.com> Message-ID: <1112723683.4784.35.camel@tomaluk.toronto.redhat.com> On Tue, 2005-04-05 at 10:55 -0400, Andrew Overholt wrote: > Hi, > > I was talking with Billy last night about Eclipse unit tests and I ran the > UI ones this morning. There are 806 tests and we get 152 Errors and 40 > Failures. 144 of the 152 Errors are from > org.eclipse.ui.tests.dnd.DragTestSuite in which Billy said to expect errors > (since this is 3.1M5a I'm testing). > > I'd like to set things up to run these automatically (Aaron is looking into > it) and get some hard data that we can work with. I've been working on running them with a headless eclipse as outlined here, http://download.eclipse.org/eclipse/downloads/drops/S-3.1M5a-200502191500/automatedtesting.html and using 3.0 have been able to run them however using 3.1 M5 I've been unable to successfully run them due to a number of issues. First the instructions on the page appear to be incomplete, first the runtests script requires a directory test-eclipse/eclipse which is not created by the script, as well the line unzip -qq -o -C eclipse-junit-tests-*.zip */plugins/org.eclipse.test* does not fully expand the tests. To run them successfully on 3.0.1 I run unzip eclipse-SDK-*.zip unzip eclipse-junit-*.zip mkdir test-eclipse cp -r eclipse test-eclipse/ ./runtests -os linux -ws gtk -arch x86 -vm /usr/lib/jvm/java-1.4.2- ibm-1.4.2.1//jre/bin/java -noclean which works, however of M5 using the identical steps (with zips changed to tar.gz) I get Buildfile: test.xml all: jdttext: runtests: setup: junit: init: BUILD FAILED /notnfs/eclipse-tests/nightlies/eclipse-tests-devel/eclipse- testing/test.xml:299: The following error occurred while executing this line: /notnfs/eclipse-tests/nightlies/eclipse-tests-devel/eclipse- testing/test.xml:155: The following error occurred while executing this line: /notnfs/eclipse-tests/nightlies/eclipse-tests-devel/eclipse- testing/test.xml:84: The following error occurred while executing this line: /notnfs/eclipse-tests/nightlies/eclipse-tests-devel/eclipse- testing/test.xml:65: The following error occurred while executing this line: /notnfs/eclipse-tests/nightlies/eclipse-tests-devel/eclipse- testing/test- eclipse/eclipse/plugins/org.eclipse.jdt.text.tests_3.1.0/test.xml:17: org.eclipse.ant.core.AntSecurityException Total time: 1 second Aaron From bkonrath at redhat.com Tue Apr 5 18:02:27 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Tue, 05 Apr 2005 14:02:27 -0400 Subject: [fedora-java] Re: Eclipse UI Tests In-Reply-To: <1112723683.4784.35.camel@tomaluk.toronto.redhat.com> References: <20050405145540.GA12831@redhat.com> <1112723683.4784.35.camel@tomaluk.toronto.redhat.com> Message-ID: <1112724147.32112.2.camel@town.toronto.redhat.com> On Tue, 2005-04-05 at 13:54 -0400, Aaron Luchko wrote: > /notnfs/eclipse-tests/nightlies/eclipse-tests-devel/eclipse- > testing/test- > eclipse/eclipse/plugins/org.eclipse.jdt.text.tests_3.1.0/test.xml:17: > org.eclipse.ant.core.AntSecurityException I think this is bug in 3.1M5a. I encountered a similar problem when I was generating the tarballs for the CDT. Maybe you should try it again with 3.1M6 and see how it goes. Cheers, Ben From aluchko at redhat.com Tue Apr 5 19:37:51 2005 From: aluchko at redhat.com (Aaron Luchko) Date: Tue, 05 Apr 2005 15:37:51 -0400 Subject: [fedora-java] Re: Eclipse UI Tests In-Reply-To: <1112724147.32112.2.camel@town.toronto.redhat.com> References: <20050405145540.GA12831@redhat.com> <1112723683.4784.35.camel@tomaluk.toronto.redhat.com> <1112724147.32112.2.camel@town.toronto.redhat.com> Message-ID: <1112729871.4784.42.camel@tomaluk.toronto.redhat.com> On Tue, 2005-04-05 at 14:02 -0400, Ben Konrath wrote: > On Tue, 2005-04-05 at 13:54 -0400, Aaron Luchko wrote: > > /notnfs/eclipse-tests/nightlies/eclipse-tests-devel/eclipse- > > testing/test- > > eclipse/eclipse/plugins/org.eclipse.jdt.text.tests_3.1.0/test.xml:17: > > org.eclipse.ant.core.AntSecurityException > > I think this is bug in 3.1M5a. I encountered a similar problem when I > was generating the tarballs for the CDT. Maybe you should try it again > with 3.1M6 and see how it goes. > Yup that fixes it, thanks for the tip, I was hoping something would be fixed in M6 that would allow them to work but hadn't yet got around to testing it. Well fixes it as far as here, BUILD FAILED /notnfs/eclipse-tests/temp/eclipse-testing/test.xml:300: The following error occurred while executing this line: /notnfs/eclipse-tests/temp/eclipse-testing/test.xml:161: The following error occurred while executing this line: /notnfs/eclipse-tests/temp/eclipse-testing/test.xml:84: The following error occurred while executing this line: /notnfs/eclipse-tests/temp/eclipse-testing/test.xml:65: The following error occurred while executing this line: /notnfs/eclipse-tests/temp/eclipse-testing/test- eclipse/eclipse/plugins/org.eclipse.releng.tests_3.1.0/test.xml:31: Directory /builds/t creation was not successful for an unknown reason these tests didn't work in M5 either, but removing the relEng test plugin and target in the test.xml fixes it, unfortunately this means that we won't be able to do automated tests until we change the rpms to M6. Aaron From pmuldoon at redhat.com Tue Apr 5 20:05:50 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Tue, 05 Apr 2005 15:05:50 -0500 Subject: [fedora-java] Re: Eclipse UI Tests In-Reply-To: <1112729871.4784.42.camel@tomaluk.toronto.redhat.com> References: <20050405145540.GA12831@redhat.com> <1112723683.4784.35.camel@tomaluk.toronto.redhat.com> <1112724147.32112.2.camel@town.toronto.redhat.com> <1112729871.4784.42.camel@tomaluk.toronto.redhat.com> Message-ID: <1112731551.5609.24.camel@dhcp-12.hsv.redhat.com> > these tests didn't work in M5 either, but removing the relEng test > plugin and target in the test.xml fixes it, unfortunately this means > that we won't be able to do automated tests until we change the rpms to > M6. The Eclipse CDT is the blocker on M6 at the moment as Eclipse 3.0 CDT M5 will flat not work with Eclipse 3.1 M6. So with that in mind, I thought it best to hold off an additional week to to let the Eclipse CDT 3.0 M6 build be published, as the schedules are so close. This will ensure that our CDT users are not left stranded. One week, one way or the other, is not too much time. So soon, very soon... ;) Regards Phil Muldoon From fitzsim at redhat.com Fri Apr 1 04:18:12 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 31 Mar 2005 23:18:12 -0500 Subject: [fedora-java] db merging script In-Reply-To: <20050329224815.GB20638@redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> Message-ID: <1112329092.30802.142.camel@tortoise.toronto.redhat.com> Hi, On Tue, 2005-03-29 at 17:48 -0500, Andrew Overholt wrote: > > Could these go in java-gcj-compat? Or maybe as RPM macros? > > Tom Fitzsimmons has offered to put these in java-gcj-compat. > These scripts are in java-1.4.2-gcj-compat-1.4.2.0-40jpp_14rh. I renamed them find-and-nativify, nativify and rename-gcj-db. Tom From greenrd at presidium.org Sun Apr 3 02:08:18 2005 From: greenrd at presidium.org (Robin Green) Date: Sat, 2 Apr 2005 21:08:18 -0500 (EST) Subject: [fedora-java] Debuginfo problems Message-ID: 3 problems with building -debuginfo packages for native java packages. I'm using latest rawhide, find-and-nativify to nativify [which I keep typo-ing as nativity for some reason ;) ] and ecj as source-to-bytecode compiler. 1. gcj outputs bogus source filenames for inner classes, which makes rpmbuild spew a shedload of errors like this when building the -debuginfo package: cpio: rssowl_1_1_src/src/java/net/sourceforge/rssowl/controller/GUI$4.java: No such file or directory I filed this as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20735 2. cpio outputs some more "No such file or directory errors" referring to a few classes whose source files aren't part of this project at all, e.g. cpio: rssowl_1_1_src/src/java/org/xml/sax/EntityResolver.java: No such file or directory cpio: rssowl_1_1_src/src/java/org/xml/sax/ErrorHandler.java: No such file or directory cpio: rssowl_1_1_src/src/java/org/xml/sax/InputSource.java: No such file or directory cpio: rssowl_1_1_src/src/java/org/xml/sax/SAXParseException.java: No such file or directory 3. For some strange reason - I only changed like one line in my spec file - I'm now getting this odd error: Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/rssowl-1.1-1rdg error: Installed (but unpackaged) file(s) found: /usr/lib/debug/usr/lib/rssowl/librssowl.jar.so.debug /usr/src/debug/rssowl_1_1_src/src/java/net/sourceforge/rssowl/controller/ChannelInfo.java /usr/src/debug/rssowl_1_1_src/src/java/net/sourceforge/rssowl/controller/DisposeListenerImpl.java etc. (continues with list of lots and lots of source files) So, I'm turning off -debuginfo building for my specfile for now. -- Robin From green at redhat.com Sun Apr 3 23:41:36 2005 From: green at redhat.com (Anthony Green) Date: Sun, 03 Apr 2005 16:41:36 -0700 Subject: [fedora-java] jogl package Message-ID: <1112571697.5223.25.camel@localhost.localdomain> Here's my first stab at an RPM with the new scripts (find-and-nativify and rebuild-gcj-db). It's the OpenGL java bindings: http://people.redhat.com/green/FC4 A couple of observations.... It's still not super-trivial to add native versions of jar files. See attached spec file. On the other hand, I don't know how we could make it simpler. Our libjawt.so.6 is a bit of a problem. I was unable to run any jogl code with a non-gcj alternative, since they all pick up /usr/lib/libjawt.so.6, which has references to our gtk peers and fails to load. Should libjawt.so be an alternative? Or can we install it somewhere gcj specific? AG -------------- next part -------------- Name: jogl Version: 1.1b10 Release: 1fc Epoch: 0 Summary: Java bindings for the OpenGL API. Group: System Environment/Libraries License: BSD URL: http://jogl.dev.java.net/ Source0: jogl-src.zip Source1: jogl.properties Source2: SGIFreeSWLicB.1.1.ps Source3: jogl-README.txt Patch0: %{name}-build.patch BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildRequires: ant, antlr, java-1.4.2-gcj-compat-devel, jpackage-utils >= 0:1.5 Requires: java-1.4.2-gcj-compat %description The JOGL Project hosts a reference implementation of the Java bindings for OpenGL API, and is designed to provide hardware-supported 3D graphics to applications written in the Java programming language. Is is part of a suite of open-source technologies initiated bu the Game Technology Group at Sun Microsystems. JOGL provides full access to the APIs in the OpenGL 1.5 specification as well as nearly all vendor extensions, and integrated with the AWT and Swing widget sets. %package javadoc Summary: Javadoc for %{name} Group: Development/Documentation #BuildRequires: java-javadoc %description javadoc %{summary}. %prep %setup -q -n jogl %patch0 -p0 cp %{SOURCE1} . cp %{SOURCE2} . cp %{SOURCE3} . %build (cd make && ant -Duser.home=/usr/src/redhat/SOURCES linux javadoc.dev.x11) # Rename the jar into a versioned jar name and create the .so version. mv build/jogl.jar build/%{name}-%{version}.jar find-and-nativify . "$RPM_OPT_FLAGS -fPIC -fjni" %install rm -rf $RPM_BUILD_ROOT install -dm 755 $RPM_BUILD_ROOT%{_javadir} install -pm 644 build/%{name}-%{version}.jar $RPM_BUILD_ROOT%{_javadir}/%{name}-%{version}.jar ln -s %{name}-%{version}.jar $RPM_BUILD_ROOT%{_javadir}/%{name}.jar install -dm 755 $RPM_BUILD_ROOT%{_libdir} install -pm 755 build/obj/libjogl.so $RPM_BUILD_ROOT%{_libdir}/libjogl.so install -pm 755 build/lib%{name}-%{version}.jar.so $RPM_BUILD_ROOT%{_libdir}/lib%{name}-%{version}.jar.so install -pm 755 build/lib%{name}-%{version}.jar.so $RPM_BUILD_ROOT%{_libdir}/lib%{name}-%{version}.jar.so ln -s lib%{name}-%{version}.jar.so $RPM_BUILD_ROOT%{_libdir}/lib%{name}.jar.so install -dm 755 $RPM_BUILD_ROOT%{_javadocdir}/%{name}-%{version} cp -pR javadoc_jogl_dev/* $RPM_BUILD_ROOT%{_javadocdir}/%{name}-%{version} ln -s %{name}-%{version} $RPM_BUILD_ROOT%{_javadocdir}/%{name} gcjdbdir=$RPM_BUILD_ROOT`gcj-dbtool -p %{_libdir}`.d install -dm 755 $gcjdbdir gcj-dbtool -n $gcjdbdir/%{name}-%{version}.db 80000 gcj-dbtool -f $gcjdbdir/%{name}-%{version}.db \ $RPM_BUILD_ROOT%{_javadir}/%{name}-%{version}.jar %{_libdir}/lib%{name}-%{version}.jar.so %clean rm -rf $RPM_BUILD_ROOT %post rebuild-gcj-db %{_libdir} %postun rebuild-gcj-db %{_libdir} %post javadoc rm -f %{_javadocdir}/%{name} ln -s %{name}-%{version} %{_javadocdir}/%{name} %files %defattr(644,root,root,755) %doc SGIFreeSWLicB.1.1.ps %doc jogl-README.txt %doc doc/* %{_javadir}/*.jar %{_libdir}/* %files javadoc %defattr(644,root,root,755) %doc %{_javadocdir}/%{name}-%{version} %ghost %doc %{_javadocdir}/%{name} %changelog * Sun Apr 3 2005 Anthony Green - 0:1.1b10-1fc - Created. From fitzsim at redhat.com Mon Apr 4 05:24:31 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 04 Apr 2005 01:24:31 -0400 Subject: [fedora-java] jogl package In-Reply-To: <1112571697.5223.25.camel@localhost.localdomain> References: <1112571697.5223.25.camel@localhost.localdomain> Message-ID: <1112592272.9902.5.camel@rh-ibm-t41> On Sun, 2005-04-03 at 16:41 -0700, Anthony Green wrote: > Here's my first stab at an RPM with the new scripts (find-and-nativify > and rebuild-gcj-db). It's the OpenGL java bindings: > > http://people.redhat.com/green/FC4 > > A couple of observations.... > > It's still not super-trivial to add native versions of jar files. See > attached spec file. On the other hand, I don't know how we could make > it simpler. > > Our libjawt.so.6 is a bit of a problem. I was unable to run any jogl > code with a non-gcj alternative, since they all pick > up /usr/lib/libjawt.so.6, which has references to our gtk peers and > fails to load. Should libjawt.so be an alternative? Or can we install > it somewhere gcj specific? > I think we should rename it libgcj-jawt.so. libjawt-using apps will look for $JAVA_HOME/jre/lib/i386/libjawt.so which we already have a symlink for in java-gcj-compat. Tom From tromey at redhat.com Mon Apr 4 18:49:57 2005 From: tromey at redhat.com (Tom Tromey) Date: 04 Apr 2005 12:49:57 -0600 Subject: [fedora-java] db merging script In-Reply-To: <16972.17579.880662.402733@cuddles.cambridge.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> <200503301519.j2UFJpAv024829@littlepinkcloud.com> <16971.37411.793787.473750@cuddles.cambridge.redhat.com> <16972.17579.880662.402733@cuddles.cambridge.redhat.com> Message-ID: >>>>> "Andrew" == Andrew Haley writes: Andrew> So we have an additional "-0" arg to dbtool? Sounds good to me. Tom From overholt at redhat.com Tue Apr 5 01:36:30 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 4 Apr 2005 21:36:30 -0400 Subject: [fedora-java] db merging script In-Reply-To: <20050329224815.GB20638@redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> Message-ID: <20050405013630.GA29238@redhat.com> * Andrew Overholt [2005-03-29 16:52]: [...] > > (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB) [...] I'm thinking this should be: (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) What's the purpose of the extraneous $DB? I don't think we want it because we actually want the entire db recreated every time. We don't want entries that are not in sub-dbs in $DB.d to be in the resultant db. Does that make sense? Andrew From fitzsim at redhat.com Tue Apr 5 03:43:28 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 04 Apr 2005 23:43:28 -0400 Subject: [fedora-java] db merging script In-Reply-To: <20050405013630.GA29238@redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> <20050405013630.GA29238@redhat.com> Message-ID: <1112672608.2981.38.camel@rh-ibm-t41> On Mon, 2005-04-04 at 21:36 -0400, Andrew Overholt wrote: > * Andrew Overholt [2005-03-29 16:52]: > [...] > > > (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB) > [...] > > I'm thinking this should be: > > (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) > > What's the purpose of the extraneous $DB? I don't think we want it because > we actually want the entire db recreated every time. We don't want entries > that are not in sub-dbs in $DB.d to be in the resultant db. Does that make > sense? > The -m option cases the destination database to be overwritten. If you want to maintain its contents you need to specify it as a source database. From "gcj-dbtool --help" output: gcj-dbtool -m dest.gcjdb [source.gcjdb]... - Merge gcj map databases into dest Replaces dest To add to dest, include dest in the list of sources But as I understand it, rebuild-gcj-db is supposed to rebuild classmap.db from scratch. If that's the intended behaviour (and is safe -- aph?) then (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) is correct. Tom From aph at redhat.com Tue Apr 5 08:38:18 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Apr 2005 09:38:18 +0100 Subject: [fedora-java] db merging script In-Reply-To: <20050405013630.GA29238@redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> <20050405013630.GA29238@redhat.com> Message-ID: <16978.20090.942656.185821@cuddles.cambridge.redhat.com> Andrew Overholt writes: > * Andrew Overholt [2005-03-29 16:52]: > [...] > > > (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB) > [...] > > I'm thinking this should be: > > (cd $DB.d; ls . | xargs gcj-dbtool -m $DB) > > What's the purpose of the extraneous $DB? I don't think we want it because > we actually want the entire db recreated every time. We don't want entries > that are not in sub-dbs in $DB.d to be in the resultant db. Does that make > sense? Yes. The extra $DB is there because xargs will call gcj-dbtool multiple times if it needs to. The right answer is not to use xargs. Andrew. From aph at redhat.com Tue Apr 5 14:15:23 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Apr 2005 15:15:23 +0100 Subject: [fedora-java] db merging script In-Reply-To: References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> <200503301519.j2UFJpAv024829@littlepinkcloud.com> <16971.37411.793787.473750@cuddles.cambridge.redhat.com> Message-ID: <16978.40315.135940.44507@cuddles.cambridge.redhat.com> Tom Tromey writes: > >> This needs a corresponding gcj.texi patch. > > Andrew> Yes, but I'm waiting for feedback before I write it. > > I think the idea is sound, and needed. > > I think we should also support reading "find -0" output, > i.e. '\0'-separated strings. That would let us support file names > with spaces in them, and other oddities. 2005-04-05 Andrew Haley * gnu/gcj/tools/gcj_dbtool/Main.java (Fileset): New class. (Tokenizer): New class. (getFiles): New method. (main): Add "-" argument. Add "-0" argument. Read list of files from stdin when merging map databases. (usage): Add "-" argument. Add "-0" argument. Minor corrections. Index: gnu/gcj/tools/gcj_dbtool/Main.java =================================================================== RCS file: /cvs/gcc/gcc/libjava/gnu/gcj/tools/gcj_dbtool/Main.java,v retrieving revision 1.9 diff -p -2 -c -r1.9 Main.java *** gnu/gcj/tools/gcj_dbtool/Main.java 25 Mar 2005 00:38:43 -0000 1.9 --- gnu/gcj/tools/gcj_dbtool/Main.java 5 Apr 2005 14:10:33 -0000 *************** public class Main *** 23,27 **** --- 23,42 ---- public static void main (String[] s) { + boolean fileListFromStdin = false; + char filenameSeparator = ' '; + insist (s.length >= 1); + + if (s[0].equals("-") || + s[0].equals("-0")) + { + if (s[0].equals("-0")) + filenameSeparator = (char)0; + fileListFromStdin = true; + String[] newArgs = new String[s.length - 1]; + System.arraycopy(s, 1, newArgs, 0, s.length - 1); + s = newArgs; + } + if (s[0].equals("-v") || s[0].equals("--version")) { *************** public class Main *** 146,150 **** { // Merge databases. ! insist (s.length >= 3); try { --- 161,166 ---- { // Merge databases. ! insist (s.length >= 3 ! || fileListFromStdin && s.length == 2); try { *************** public class Main *** 156,171 **** int newSize = 0; int newStringTableSize = 0; ! PersistentByteMap[] sourceMaps = new PersistentByteMap[s.length - 2]; // Scan all the input files, calculating worst case string // table and hash table use. ! for (int i = 2; i < s.length; i++) ! { ! PersistentByteMap b ! = new PersistentByteMap(new File(s[i]), ! PersistentByteMap.AccessMode.READ_ONLY); ! newSize += b.size(); ! newStringTableSize += b.stringTableSize(); ! sourceMaps[i - 2] = b; ! } newSize *= 1.5; // Scaling the new size by 1.5 results in --- 172,195 ---- int newSize = 0; int newStringTableSize = 0; ! Fileset files = getFiles(s, 2, fileListFromStdin, ! filenameSeparator); ! PersistentByteMap[] sourceMaps ! = new PersistentByteMap[files.size()]; ! // Scan all the input files, calculating worst case string // table and hash table use. ! { ! Iterator it = files.iterator(); ! int i = 0; ! while (it.hasNext()) ! { ! PersistentByteMap b ! = new PersistentByteMap((File)it.next(), ! PersistentByteMap.AccessMode.READ_ONLY); ! newSize += b.size(); ! newStringTableSize += b.stringTableSize(); ! sourceMaps[i++] = b; ! } ! } newSize *= 1.5; // Scaling the new size by 1.5 results in *************** public class Main *** 173,177 **** PersistentByteMap map = PersistentByteMap.emptyPersistentByteMap ! (temp, newSize, newStringTableSize); for (int i = 0; i < sourceMaps.length; i++) --- 197,201 ---- PersistentByteMap map = PersistentByteMap.emptyPersistentByteMap ! (temp, newSize, newStringTableSize); for (int i = 0; i < sourceMaps.length; i++) *************** public class Main *** 297,310 **** + " gcj-dbtool -n file.gcjdb [size] - Create a new gcj map database\n" + " gcj-dbtool -a file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a new gcj map database\n" + " gcj-dbtool -f file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a new gcj map database\n" + " gcj-dbtool -t file.gcjdb - Test a gcj map database\n" + " gcj-dbtool -l file.gcjdb - List a gcj map database\n" ! + " gcj-dbtool -m dest.gcjdb [source.gcjdb]...\n" ! + " - Merge gcj map databases into dest\n" ! + " Replaces dest\n" ! + " To add to dest, include dest in the list of sources\n" ! + " gcj-dbtool -p [LIBDIR] - Print default database name"); } --- 321,337 ---- + " gcj-dbtool -n file.gcjdb [size] - Create a new gcj map database\n" + " gcj-dbtool -a file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a gcj map database\n" + " gcj-dbtool -f file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a gcj map database\n" + " gcj-dbtool -t file.gcjdb - Test a gcj map database\n" + " gcj-dbtool -l file.gcjdb - List a gcj map database\n" ! + " gcj-dbtool [-][-0] -m dest.gcjdb [source.gcjdb]...\n" ! + " - Merge gcj map databases into dest\n" ! + " Replaces dest\n" ! + " To add to dest, include dest in the list of sources\n" ! + " If the first arg is -, read the list from stdin\n" ! + " If the first arg is -0, filenames separated by nul\n" ! + " gcj-dbtool -p [LIBDIR] - Print default database name" ! ); } *************** public class Main *** 406,409 **** return hexBytes.toString(); } } - --- 433,535 ---- return hexBytes.toString(); } + + + // Return a Fileset, either from a String array or from System.in, + // depending on fileListFromStdin. + private static final Fileset getFiles(String[] s, int startPos, + boolean fileListFromStdin, + char separator) + { + if (fileListFromStdin) + return new Fileset(System.in, separator); + else + return new Fileset(s, startPos, s.length); + } + } + + // Parse a stream into tokens. The separator can be any char, and + // space is equivalent to any whitepace character. + class Tokenizer + { + final Reader r; + final char separator; + + Tokenizer(Reader r, char separator) + { + this.r = r; + this.separator = separator; + } + + boolean isSeparator(int c) + { + if (Character.isWhitespace(separator)) + return Character.isWhitespace((char)c); + else + return c == separator; + } + + // Parse a token from the input stream. Return the empty string + // when the stream is exhausted. + String nextToken () + { + StringBuffer buf = new StringBuffer(); + int c; + try + { + while ((c = r.read()) != -1) + { + if (! isSeparator(c)) + { + buf.append((char)c); + break; + } + } + while ((c = r.read()) != -1) + { + if (isSeparator(c)) + break; + else + buf.append((char)c); + } + } + catch (java.io.IOException e) + { + } + return buf.toString(); + } + } + + // A Fileset is a container for a set of files; it can be created + // either from a string array or from an input stream, given a + // separator character. + class Fileset + { + LinkedHashSet files = new LinkedHashSet(); + + Fileset (String[] s, int start, int end) + { + for (int i = start; i < end; i++) + { + files.add(new File(s[i])); + } + } + + Fileset (InputStream is, char separator) + { + Reader r = new BufferedReader(new InputStreamReader(is)); + Tokenizer st = new Tokenizer(r, separator); + String name; + while (! "".equals(name = st.nextToken())) + files.add(new File(name)); + } + + Iterator iterator() + { + return files.iterator(); + } + + int size() + { + return files.size(); + } } From aph at redhat.com Tue Apr 5 14:32:51 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Apr 2005 15:32:51 +0100 Subject: [fedora-java] db merging script In-Reply-To: <16978.40315.135940.44507@cuddles.cambridge.redhat.com> References: <20050322171350.GC10152@redhat.com> <1111530405.5163.57.camel@dhcp-172-16-25-146.sfbay.redhat.com> <1111713951.17650.62.camel@dhcp-172-16-25-146.sfbay.redhat.com> <20050329224815.GB20638@redhat.com> <200503301519.j2UFJpAv024829@littlepinkcloud.com> <16971.37411.793787.473750@cuddles.cambridge.redhat.com> <16978.40315.135940.44507@cuddles.cambridge.redhat.com> Message-ID: <16978.41363.834663.889985@cuddles.cambridge.redhat.com> And the corresponding texinfo patch. Andrew. Index: gcj.texi =================================================================== RCS file: /cvs/gcc/gcc/gcc/java/gcj.texi,v retrieving revision 1.77 diff -u -r1.77 gcj.texi --- gcj.texi 29 Mar 2005 21:46:49 -0000 1.77 +++ gcj.texi 5 Apr 2005 14:31:02 -0000 @@ -990,9 +990,9 @@ @c man begin SYNOPSIS gcj-dbtool gcj-dbtool @option{OPTION} @var{DBFILE} [@option{MORE}] @dots{} -gcj-dbtool [@option{-n}] [@option{-a}] [@option{-f}] +gcj-dbtool [@option{-0}] [@option{-}] [@option{-n}] [@option{-a}] [@option{-f}] [@option{-t}] [@option{-l}] [@option{-p} [@var{LIBDIR}]] - [@option{-v}] [@option{--version}] [@option{--help}] + [@option{-v}] [@option{-m}] [@option{--version}] [@option{--help}] @c man end @c man begin SEEALSO gij @@ -1037,6 +1037,18 @@ that @var{LIB} exists before adding it to the database; @option{-f} skips this check. + at item [@option{-}][@option{-0}] -m @var{DBFILE} @var{DBFILE},[@var{DBFILE}] +Merge a number of databases. The output database overwrites any +existing database. To add databases into an existing database, +include the destination in the list of sources. + +If @option{-} or @option{-0} are used, the list of files to read is +taken from standard input instead of the command line. For + at option{-0}, Input filenames are terminated by a null character +instead of by whitespace. Useful when arguments might contain white +space. The GNU find -print0 option produces input suitable for this +mode. + @item -t @var{DBFILE} Test a database. From overholt at redhat.com Tue Apr 5 14:55:40 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 5 Apr 2005 10:55:40 -0400 Subject: [fedora-java] Eclipse UI Tests Message-ID: <20050405145540.GA12831@redhat.com> Hi, I was talking with Billy last night about Eclipse unit tests and I ran the UI ones this morning. There are 806 tests and we get 152 Errors and 40 Failures. 144 of the 152 Errors are from org.eclipse.ui.tests.dnd.DragTestSuite in which Billy said to expect errors (since this is 3.1M5a I'm testing). I'd like to set things up to run these automatically (Aaron is looking into it) and get some hard data that we can work with. The one thing that bothered me is that the tests took about 43 minutes to run on my P4 3 GHz with 1 GB RAM. Billy says the tests take only about 10 minutes normally. I'll try to spend some time figuring out where the time goes. This could have been my machine/setup but they took about the same amount of time to run on my laptop which is a much less beefier machine so I sort of doubt it. This is how Billy taught me to run the tests (for future reference): . start Eclipse with a new workspace eclipse -data testworkspace . switch to CVS perspective and add the Eclipse repo (dev.eclipse.org - /home/eclipse - anonymous - pserver) . expand the Eclipse repo and expand versions . expand org.eclipse.releng . expand I20050219-1500 (the tag for 3.1M5a) . expand maps . double-click on ui.map . note that plugin at org.eclipse.ui.tests=v20050218-1200 . close ui.map and expand org.eclipse.ui.tests . check out org.eclipse.ui.tests v20050218-1200 . switch to the Java perspective . once your workspace finishes building, there will be errors in a few things ... we only care about the errors in plugin.xml so edit it to comment out or remove the two offending lines . expand Eclipse UI Tests -> org.eclipse.ui.tests . right-click on UiTestSuite.java and click Run As -> JUnit Plug-in Test . beside Package Explorer and Hierarchy, you should get a JUnit tab; quickly select it and select the Hierarchy tab within before the tests start up . let the tests run without playing with your computer because some of the tests rely on focus Andrew From aluchko at redhat.com Tue Apr 5 17:54:43 2005 From: aluchko at redhat.com (Aaron Luchko) Date: Tue, 05 Apr 2005 13:54:43 -0400 Subject: [fedora-java] Re: Eclipse UI Tests In-Reply-To: <20050405145540.GA12831@redhat.com> References: <20050405145540.GA12831@redhat.com> Message-ID: <1112723683.4784.35.camel@tomaluk.toronto.redhat.com> On Tue, 2005-04-05 at 10:55 -0400, Andrew Overholt wrote: > Hi, > > I was talking with Billy last night about Eclipse unit tests and I ran the > UI ones this morning. There are 806 tests and we get 152 Errors and 40 > Failures. 144 of the 152 Errors are from > org.eclipse.ui.tests.dnd.DragTestSuite in which Billy said to expect errors > (since this is 3.1M5a I'm testing). > > I'd like to set things up to run these automatically (Aaron is looking into > it) and get some hard data that we can work with. I've been working on running them with a headless eclipse as outlined here, http://download.eclipse.org/eclipse/downloads/drops/S-3.1M5a-200502191500/automatedtesting.html and using 3.0 have been able to run them however using 3.1 M5 I've been unable to successfully run them due to a number of issues. First the instructions on the page appear to be incomplete, first the runtests script requires a directory test-eclipse/eclipse which is not created by the script, as well the line unzip -qq -o -C eclipse-junit-tests-*.zip */plugins/org.eclipse.test* does not fully expand the tests. To run them successfully on 3.0.1 I run unzip eclipse-SDK-*.zip unzip eclipse-junit-*.zip mkdir test-eclipse cp -r eclipse test-eclipse/ ./runtests -os linux -ws gtk -arch x86 -vm /usr/lib/jvm/java-1.4.2- ibm-1.4.2.1//jre/bin/java -noclean which works, however of M5 using the identical steps (with zips changed to tar.gz) I get Buildfile: test.xml all: jdttext: runtests: setup: junit: init: BUILD FAILED /notnfs/eclipse-tests/nightlies/eclipse-tests-devel/eclipse- testing/test.xml:299: The following error occurred while executing this line: /notnfs/eclipse-tests/nightlies/eclipse-tests-devel/eclipse- testing/test.xml:155: The following error occurred while executing this line: /notnfs/eclipse-tests/nightlies/eclipse-tests-devel/eclipse- testing/test.xml:84: The following error occurred while executing this line: /notnfs/eclipse-tests/nightlies/eclipse-tests-devel/eclipse- testing/test.xml:65: The following error occurred while executing this line: /notnfs/eclipse-tests/nightlies/eclipse-tests-devel/eclipse- testing/test- eclipse/eclipse/plugins/org.eclipse.jdt.text.tests_3.1.0/test.xml:17: org.eclipse.ant.core.AntSecurityException Total time: 1 second Aaron From bkonrath at redhat.com Tue Apr 5 18:02:27 2005 From: bkonrath at redhat.com (Ben Konrath) Date: Tue, 05 Apr 2005 14:02:27 -0400 Subject: [fedora-java] Re: Eclipse UI Tests In-Reply-To: <1112723683.4784.35.camel@tomaluk.toronto.redhat.com> References: <20050405145540.GA12831@redhat.com> <1112723683.4784.35.camel@tomaluk.toronto.redhat.com> Message-ID: <1112724147.32112.2.camel@town.toronto.redhat.com> On Tue, 2005-04-05 at 13:54 -0400, Aaron Luchko wrote: > /notnfs/eclipse-tests/nightlies/eclipse-tests-devel/eclipse- > testing/test- > eclipse/eclipse/plugins/org.eclipse.jdt.text.tests_3.1.0/test.xml:17: > org.eclipse.ant.core.AntSecurityException I think this is bug in 3.1M5a. I encountered a similar problem when I was generating the tarballs for the CDT. Maybe you should try it again with 3.1M6 and see how it goes. Cheers, Ben From aluchko at redhat.com Tue Apr 5 19:37:51 2005 From: aluchko at redhat.com (Aaron Luchko) Date: Tue, 05 Apr 2005 15:37:51 -0400 Subject: [fedora-java] Re: Eclipse UI Tests In-Reply-To: <1112724147.32112.2.camel@town.toronto.redhat.com> References: <20050405145540.GA12831@redhat.com> <1112723683.4784.35.camel@tomaluk.toronto.redhat.com> <1112724147.32112.2.camel@town.toronto.redhat.com> Message-ID: <1112729871.4784.42.camel@tomaluk.toronto.redhat.com> On Tue, 2005-04-05 at 14:02 -0400, Ben Konrath wrote: > On Tue, 2005-04-05 at 13:54 -0400, Aaron Luchko wrote: > > /notnfs/eclipse-tests/nightlies/eclipse-tests-devel/eclipse- > > testing/test- > > eclipse/eclipse/plugins/org.eclipse.jdt.text.tests_3.1.0/test.xml:17: > > org.eclipse.ant.core.AntSecurityException > > I think this is bug in 3.1M5a. I encountered a similar problem when I > was generating the tarballs for the CDT. Maybe you should try it again > with 3.1M6 and see how it goes. > Yup that fixes it, thanks for the tip, I was hoping something would be fixed in M6 that would allow them to work but hadn't yet got around to testing it. Well fixes it as far as here, BUILD FAILED /notnfs/eclipse-tests/temp/eclipse-testing/test.xml:300: The following error occurred while executing this line: /notnfs/eclipse-tests/temp/eclipse-testing/test.xml:161: The following error occurred while executing this line: /notnfs/eclipse-tests/temp/eclipse-testing/test.xml:84: The following error occurred while executing this line: /notnfs/eclipse-tests/temp/eclipse-testing/test.xml:65: The following error occurred while executing this line: /notnfs/eclipse-tests/temp/eclipse-testing/test- eclipse/eclipse/plugins/org.eclipse.releng.tests_3.1.0/test.xml:31: Directory /builds/t creation was not successful for an unknown reason these tests didn't work in M5 either, but removing the relEng test plugin and target in the test.xml fixes it, unfortunately this means that we won't be able to do automated tests until we change the rpms to M6. Aaron From pmuldoon at redhat.com Tue Apr 5 20:05:50 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Tue, 05 Apr 2005 15:05:50 -0500 Subject: [fedora-java] Re: Eclipse UI Tests In-Reply-To: <1112729871.4784.42.camel@tomaluk.toronto.redhat.com> References: <20050405145540.GA12831@redhat.com> <1112723683.4784.35.camel@tomaluk.toronto.redhat.com> <1112724147.32112.2.camel@town.toronto.redhat.com> <1112729871.4784.42.camel@tomaluk.toronto.redhat.com> Message-ID: <1112731551.5609.24.camel@dhcp-12.hsv.redhat.com> > these tests didn't work in M5 either, but removing the relEng test > plugin and target in the test.xml fixes it, unfortunately this means > that we won't be able to do automated tests until we change the rpms to > M6. The Eclipse CDT is the blocker on M6 at the moment as Eclipse 3.0 CDT M5 will flat not work with Eclipse 3.1 M6. So with that in mind, I thought it best to hold off an additional week to to let the Eclipse CDT 3.0 M6 build be published, as the schedules are so close. This will ensure that our CDT users are not left stranded. One week, one way or the other, is not too much time. So soon, very soon... ;) Regards Phil Muldoon From maiko at 072cha.net Thu Apr 7 07:04:55 2005 From: maiko at 072cha.net (}CR) Date: 7 Apr 2005 16:04:55 +0900 Subject: [fedora-java] =?iso-2022-jp?b?GyRCJDMkcyRQJHMkbyEpGyhC?= Message-ID: <20050407070455.484.qmail@localhost> ????????????????????????????????????? ??????????????????????????????????????? ???????????????????????? ??? http://218.24.145.241/fly/?xk43thzh6t3gzgdth2edgue$5elqxhmdg24 ??????????????????????????????????????????? ????????????????????? ?????????????????????? ????????????????? ??????????????????? ????? ???????????????????????????????? ????????????????????? ??????????????????????? ??????????????????????????? ?????????????????????? From green at redhat.com Thu Apr 7 12:24:06 2005 From: green at redhat.com (Anthony Green) Date: Thu, 07 Apr 2005 05:24:06 -0700 Subject: [fedora-java] jogl package In-Reply-To: <1112592272.9902.5.camel@rh-ibm-t41> References: <1112571697.5223.25.camel@localhost.localdomain> <1112592272.9902.5.camel@rh-ibm-t41> Message-ID: <1112876646.5741.1.camel@localhost.localdomain> On Mon, 2005-04-04 at 01:24 -0400, Thomas Fitzsimmons wrote: > I think we should rename it libgcj-jawt.so. libjawt-using apps will > look for $JAVA_HOME/jre/lib/i386/libjawt.so which we already have a > symlink for in java-gcj-compat. This is a fine idea for java-gcj-compat users, but what about the others? AG From dmalcolm at redhat.com Thu Apr 7 19:49:02 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Thu, 07 Apr 2005 15:49:02 -0400 Subject: [fedora-java] Re: PDF generation problem solved for me In-Reply-To: <20050407114143.0d16fbec.Tommy.Reynolds@MegaCoder.com> References: <20050407103823.0e5a81dd.Tommy.Reynolds@MegaCoder.com> <36079.193.195.148.66.1112888566.squirrel@webmail.suretecsystems.com> <1112890370.4996.10.camel@localhost.localdomain> <20050407114143.0d16fbec.Tommy.Reynolds@MegaCoder.com> Message-ID: <1112903342.10670.4.camel@cassandra.boston.redhat.com> On Thu, 2005-04-07 at 11:41 -0500, Tommy Reynolds wrote: > Uttered "Paul W. Frields" , spake thus: > > > There was some list traffic about this several times in the not-too- > > distant past... I can't remember the content of all the discussions, but > > the idea of whether to use FOP was definitely tossed around. Could > > anyone with some time and inclination check the archives and try to > > summarize the discussions here? Or is that unnecessary? If someone > > were to do that, I would put a page up on the wiki in an agreeable place > > (and with an agreeable name) just so we have a reference point. > > The concern was that FOP needed some non-GPL assistance to render > some graphic content. Specifically, FOP can render BMP, EPS, GIF, > JPEG and TIFF files without any assistance. With JIMI or JAI (which > are not GPL'ed), PNG can be rendered. With BATIK, also an Apache > product, SVG files can also be rendered. > > None of the non-free assistant packages are included or distributed > with FOP. FOP will notice these add-ons if present, but will work > without them, with the only caveat being PNG input will not work. > > The official details are at http://xml.apache.org/fop/graphics.html, > for those who are interested. CC-ing to fedora-devel-java-list Surely there must be a GPL-friendly PNG handler in Java somewhere? How hard would it be to rewrite this part of FOP? What's the status of getting a natively-compiled FOP into Fedora? From fitzsim at redhat.com Thu Apr 7 20:27:55 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 07 Apr 2005 16:27:55 -0400 Subject: [fedora-java] Re: PDF generation problem solved for me In-Reply-To: <1112903342.10670.4.camel@cassandra.boston.redhat.com> References: <20050407103823.0e5a81dd.Tommy.Reynolds@MegaCoder.com> <36079.193.195.148.66.1112888566.squirrel@webmail.suretecsystems.com> <1112890370.4996.10.camel@localhost.localdomain> <20050407114143.0d16fbec.Tommy.Reynolds@MegaCoder.com> <1112903342.10670.4.camel@cassandra.boston.redhat.com> Message-ID: <1112905675.14716.59.camel@tortoise.toronto.redhat.com> On Thu, 2005-04-07 at 15:49 -0400, David Malcolm wrote: > On Thu, 2005-04-07 at 11:41 -0500, Tommy Reynolds wrote: > > Uttered "Paul W. Frields" , spake thus: > > > > > There was some list traffic about this several times in the not-too- > > > distant past... I can't remember the content of all the discussions, but > > > the idea of whether to use FOP was definitely tossed around. Could > > > anyone with some time and inclination check the archives and try to > > > summarize the discussions here? Or is that unnecessary? If someone > > > were to do that, I would put a page up on the wiki in an agreeable place > > > (and with an agreeable name) just so we have a reference point. > > > > The concern was that FOP needed some non-GPL assistance to render > > some graphic content. Specifically, FOP can render BMP, EPS, GIF, > > JPEG and TIFF files without any assistance. With JIMI or JAI (which > > are not GPL'ed), PNG can be rendered. With BATIK, also an Apache > > product, SVG files can also be rendered. > > > > None of the non-free assistant packages are included or distributed > > with FOP. FOP will notice these add-ons if present, but will work > > without them, with the only caveat being PNG input will not work. > > > > The official details are at http://xml.apache.org/fop/graphics.html, > > for those who are interested. > > CC-ing to fedora-devel-java-list > > Surely there must be a GPL-friendly PNG handler in Java somewhere? How > hard would it be to rewrite this part of FOP? What's the status of > getting a natively-compiled FOP into Fedora? > There's a gdk-pixbuf-based PNG decoder in libgcj's javax.imageio implementation. No encoder though. Probably the most efficient way to get a GPL-compatible Java PNG encoder is to package JMagick: http://www.yeo.id.au/jmagick/ Likely some glue code will be required to make it work with FOP. Have you asked the FOP maintainers why a JMagick back end doesn't exist yet? Tom From ziga.mahkovec at klika.si Thu Apr 7 21:41:21 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Thu, 07 Apr 2005 23:41:21 +0200 Subject: [fedora-java] Re: PDF generation problem solved for me In-Reply-To: <1112905675.14716.59.camel@tortoise.toronto.redhat.com> References: <20050407103823.0e5a81dd.Tommy.Reynolds@MegaCoder.com> <36079.193.195.148.66.1112888566.squirrel@webmail.suretecsystems.com> <1112890370.4996.10.camel@localhost.localdomain> <20050407114143.0d16fbec.Tommy.Reynolds@MegaCoder.com> <1112903342.10670.4.camel@cassandra.boston.redhat.com> <1112905675.14716.59.camel@tortoise.toronto.redhat.com> Message-ID: <1112910081.6508.19.camel@localhost> On Thu, 2005-04-07 at 16:27 -0400, Thomas Fitzsimmons wrote: > On Thu, 2005-04-07 at 15:49 -0400, David Malcolm wrote: > > Surely there must be a GPL-friendly PNG handler in Java somewhere? How > > hard would it be to rewrite this part of FOP? What's the status of > > getting a natively-compiled FOP into Fedora? > > There's a gdk-pixbuf-based PNG decoder in libgcj's javax.imageio > implementation. No encoder though. How about the imageio stuff from the java-gui-branch[1]? I've successfully rendered PNG images using the java-gui-20050128-branch, so this should be available in gcc4 as well. > Probably the most efficient way to get a GPL-compatible Java PNG > encoder is to package JMagick. Before libgcj got imageio writing support, I also used PndEncoder[2], which is a pure-java encoder (LGPL). [1] http://lists.gnu.org/archive/html/classpath-patches/2005-01/msg00093.html [2] http://catcode.com/pngencoder/ -- Ziga From fitzsim at redhat.com Thu Apr 7 21:53:39 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 07 Apr 2005 17:53:39 -0400 Subject: [fedora-java] Re: PDF generation problem solved for me In-Reply-To: <1112910081.6508.19.camel@localhost> References: <20050407103823.0e5a81dd.Tommy.Reynolds@MegaCoder.com> <36079.193.195.148.66.1112888566.squirrel@webmail.suretecsystems.com> <1112890370.4996.10.camel@localhost.localdomain> <20050407114143.0d16fbec.Tommy.Reynolds@MegaCoder.com> <1112903342.10670.4.camel@cassandra.boston.redhat.com> <1112905675.14716.59.camel@tortoise.toronto.redhat.com> <1112910081.6508.19.camel@localhost> Message-ID: <1112910819.14716.64.camel@tortoise.toronto.redhat.com> On Thu, 2005-04-07 at 23:41 +0200, Ziga Mahkovec wrote: > On Thu, 2005-04-07 at 16:27 -0400, Thomas Fitzsimmons wrote: > > On Thu, 2005-04-07 at 15:49 -0400, David Malcolm wrote: > > > Surely there must be a GPL-friendly PNG handler in Java somewhere? How > > > hard would it be to rewrite this part of FOP? What's the status of > > > getting a natively-compiled FOP into Fedora? > > > > There's a gdk-pixbuf-based PNG decoder in libgcj's javax.imageio > > implementation. No encoder though. > > How about the imageio stuff from the java-gui-branch[1]? I've > successfully rendered PNG images using the java-gui-20050128-branch, so > this should be available in gcc4 as well. > Oh damn, yes. I forgot Graydon had added that. I also see I didn't answer the actual question: providing a natively-compiled FOP in Fedora wouldn't be very hard at all. What is the application you're trying to get working? Tom From dina at acis.com Thu Apr 7 08:23:15 2005 From: dina at acis.com (Vanessa J. Smith) Date: Thu, 07 Apr 2005 08:23:15 +0000 Subject: [fedora-java] Microsoft Office 2003 - very low price Message-ID: Get all the popular software possible for prices substantially lower than in stores! We sell software 2-6 times cheaper than retail price. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 Quark Xpress 6 Passport Multilanguage Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... Enter here: http://dst.gbverdunde.com/?OxQnk3Ok0mpZ2Cidst Best, Vanessa Smith _____________________________________________________ To be taken off future campaigns, go here: http://dst.gbverdunde.com/?IrehKZIKqgPnYwcdst _____________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From greenrd at presidium.org Fri Apr 8 22:29:45 2005 From: greenrd at presidium.org (Robin Green) Date: Fri, 8 Apr 2005 18:29:45 -0400 (EDT) Subject: [fedora-java] Debugging native java libs loaded via lookup in classmap.db Message-ID: Currently, it seems impossible to set breakpoints with gdb in native libraries loaded via the new classmap.db mechanism, aka the 'BC API'. (I know that the library in question _is_ being loaded, because it appears in a stack trace in the debuggee!) I have filed this problem as gdb PR 1907 (see http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb ). -- Robin From overholt at redhat.com Sat Apr 9 17:40:23 2005 From: overholt at redhat.com (Andrew Overholt) Date: Sat, 9 Apr 2005 13:40:23 -0400 Subject: [fedora-java] Re: [JPackage-discuss] Why libswt3-gtk2 isn't split between lib and plugin? also multiple SWTs and GCJ binaries In-Reply-To: <20050409001345.54301.qmail@web51405.mail.yahoo.com> References: <20050409001345.54301.qmail@web51405.mail.yahoo.com> Message-ID: <20050409174023.GB12731@redhat.com> CCing fedora-devel-java-list * rivasdiazx-jpackage at yahoo.com [2005-04-08 20:15]: > > Problem+Proposal 1: > In both cases I found that the package libswt3-gtk2 installs SWT JARs > and SOs as an independent library (in /usr/lib) and as an eclipse > plugin (in /usr/share/eclipse/plugins). I think that this package > should be splitted in lib and plugin. Something like libswt3-gtk2 and > eclipse-swt3-gtk2 which depends on the former. This doesn't work. The libraries are needed for SWT since it has native bits. > Problem+Proposal 2: > I think that libswt3 should be a generic package and should exist > libswt3-gtk2, libswt3-motif, even maybe libswt3-fox, which are platform > dependant. [...] This would be fine, but we'd have to add back in the motif stuff and figure out how to build the fox stuff. It's not impossible, but it'd be a lot of work. This is why we have libswt3-gtk2, BTW. > Problem+Proposal 3: > FC4 will include Eclipse IDE and some plugins (very good!) but it will > require the GCJ based java implementation, because they have compiled Yes and no. I recently added the requirement on java-1.4.2-gcj-compat because we don't want people to think they're running our native packages when they are actually running them on a proprietary JVM. If someone has their alternatives set up for, say, the Sun JVM, our packages will work without the native bits (all the .jar.so files) entirely. > more GCJ bugs reported, etc), but it will make a fork on JPackage RPMs > and users will not be able to update to new versions using JPackage > RPMs. David Walluck and I have been talking about adding some sections to our (FC) RPMs so that they are basically the same as the JPackage pure bytecode ones. I believe Tom Fitzsimmons has worked with the various depsolvers (yum, up2date) to make sure that arch->noarch and noarch->arch upgrades work fine. > Something like eclipse-jdt (-base?) and eclipse-jdt-gcj. No. :) Many discussions took place about this and that's not the direction that we decided to take. Tom, Fernando, Gary, and others can explain more if necessary. > process should invoke the Java Engine the standard way (JNI?, > /usr/bin/java?), then if I have GCJ as my selected Java virtual > machine, Eclipse will run with GCJ (as it will run in base FC4), but if That's how we've set things up with java-gcj-compat. If you have j-g-c set up as your java alternative and you run Eclipse, it'll use the natively-compiled stuff. If you have another JVM set as your alternative, it will seamlessly use it and ignore the native bits. > PD: I made a fast search on the list to find something on this, I > apologize if it was discused before. That's cool. Not much of this was discussed on list and I apologize for that. Thanks for the interest and suggestions! Hopefully my comments clear things up a bit. Andrew From david at zarb.org Sat Apr 9 19:44:17 2005 From: david at zarb.org (David Walluck) Date: Sat, 09 Apr 2005 15:44:17 -0400 Subject: [fedora-java] Re: [JPackage-discuss] Why libswt3-gtk2 isn't split between lib and plugin? also multiple SWTs and GCJ binaries In-Reply-To: <20050409174023.GB12731@redhat.com> References: <20050409001345.54301.qmail@web51405.mail.yahoo.com> <20050409174023.GB12731@redhat.com> Message-ID: <42583091.9060503@zarb.org> Andrew Overholt wrote: >* rivasdiazx-jpackage at yahoo.com [2005-04-08 20:15]: >> >> Problem+Proposal 1: >> In both cases I found that the package libswt3-gtk2 installs SWT JARs >> and SOs as an independent library (in /usr/lib) and as an eclipse >> plugin (in /usr/share/eclipse/plugins). I think that this package >> should be splitted in lib and plugin. Something like libswt3-gtk2 and >> eclipse-swt3-gtk2 which depends on the former. > >This doesn't work. The libraries are needed for SWT since it has native >bits. > > > With the new package layout in 3.1-fc, I believe that eclipse-gtk2 got folded into libswt3-gtk2. I suppose the argument is that some packages might require only swt, with no reliance on eclipse at all. However, I don't know if this is possible. Even our swingwt rpm requires eclipse. Clearly, eclipse-gtk2 requires libswt3-gtk2, but is it also true the other way around? >> Something like eclipse-jdt (-base?) and eclipse-jdt-gcj. > >No. :) Many discussions took place about this and that's not the >direction that we decided to take. Tom, Fernando, Gary, and others can >explain more if necessary. > > The native bits won't hurt other jvm's. On the other hand, it would hurt gcj. If the idea is to allow the user to switch between jvm's, then we want them to be able to do it painlessly. -- Sincerely, David Walluck From overholt at redhat.com Sat Apr 9 19:57:41 2005 From: overholt at redhat.com (Andrew Overholt) Date: Sat, 9 Apr 2005 15:57:41 -0400 Subject: [fedora-java] Re: [JPackage-discuss] Why libswt3-gtk2 isn't split between lib and plugin? also multiple SWTs and GCJ binaries In-Reply-To: <42583091.9060503@zarb.org> References: <20050409001345.54301.qmail@web51405.mail.yahoo.com> <20050409174023.GB12731@redhat.com> <42583091.9060503@zarb.org> Message-ID: <20050409195741.GB21345@redhat.com> * David Walluck [2005-04-09 15:47]: > > With the new package layout in 3.1-fc, I believe that eclipse-gtk2 got > folded into libswt3-gtk2. I suppose the argument is that some packages > might require only swt, with no reliance on eclipse at all. However, I > don't know if this is possible. Even our swingwt rpm requires eclipse. > Clearly, eclipse-gtk2 requires libswt3-gtk2, but is it also true the > other way around? Oh yeah. I forgot that we had done that. I'm open to change if it's necessary but I forget what is in (or was, in our case :) eclipse-gtk2. Andrew From overholt at redhat.com Sat Apr 9 21:05:44 2005 From: overholt at redhat.com (Andrew Overholt) Date: Sat, 9 Apr 2005 17:05:44 -0400 Subject: [fedora-java] Eclipse 3.1M6 Message-ID: <20050409210544.GA21943@redhat.com> I put together some rudimentary RPMs for Eclipse 3.1M6. I tried them very briefly and they appear to work. Give them a shot if you have a chance. I'd appreciate any feedback. RPMs: http://people.redhat.com/~overholt/eclipserpms/ SRPM: overholt.ca/rpms/eclipse-3.1.0_fc-0.M6.1.src.rpm Thanks, Andrew "yes, I should get my disk quota upped" Overholt From david at zarb.org Sun Apr 10 04:11:41 2005 From: david at zarb.org (David Walluck) Date: Sun, 10 Apr 2005 00:11:41 -0400 Subject: [fedora-java] Re: [JPackage-discuss] Why libswt3-gtk2 isn't split between lib and plugin? also multiple SWTs and GCJ binaries In-Reply-To: <20050409195741.GB21345@redhat.com> References: <20050409001345.54301.qmail@web51405.mail.yahoo.com> <20050409174023.GB12731@redhat.com> <42583091.9060503@zarb.org> <20050409195741.GB21345@redhat.com> Message-ID: <4258A77D.6000707@zarb.org> Andrew Overholt wrote: >Oh yeah. I forgot that we had done that. I'm open to change if it's >necessary but I forget what is in (or was, in our case :) eclipse-gtk2. > > Unless there's a good reason not to, it makes sense to have libswt separate from any eclipse stuff so that using libswt doesn't pull in (parts of) the IDE. -- Sincerely, David Walluck From david at zarb.org Sun Apr 10 04:15:49 2005 From: david at zarb.org (David Walluck) Date: Sun, 10 Apr 2005 00:15:49 -0400 Subject: [fedora-java] Eclipse 3.1M6 In-Reply-To: <20050409210544.GA21943@redhat.com> References: <20050409210544.GA21943@redhat.com> Message-ID: <4258A875.3030301@zarb.org> Andrew Overholt wrote: >I put together some rudimentary RPMs for Eclipse 3.1M6. I tried them very >briefly and they appear to work. Give them a shot if you have a chance. >I'd appreciate any feedback. > > Sun-based JVM's have $JAVA_HOME/include/linux/jni_md.h. The Makefile's assume everything is in $JAVA_HOME/include, so $JAVA_HOME/include/linux will have to be added to the include path. Now it seems that `make' is never called directly during the build process, so how are flags like includes passed to make? Another problem is that the build expects JAVA_HOME to be set, doesn't it? It's not guaranteed that it would be set before building. The %ant macro attempted to correct this problem, by setting JAVA_HOME before ant is called. -- Sincerely, David Walluck From overholt at redhat.com Sun Apr 10 14:52:08 2005 From: overholt at redhat.com (Andrew Overholt) Date: Sun, 10 Apr 2005 10:52:08 -0400 Subject: [fedora-java] Re: [JPackage-discuss] Why libswt3-gtk2 isn't split between lib and plugin? also multiple SWTs and GCJ binaries In-Reply-To: <4258A77D.6000707@zarb.org> References: <20050409001345.54301.qmail@web51405.mail.yahoo.com> <20050409174023.GB12731@redhat.com> <42583091.9060503@zarb.org> <20050409195741.GB21345@redhat.com> <4258A77D.6000707@zarb.org> Message-ID: <20050410145208.GA6084@redhat.com> * David Walluck [2005-04-10 00:13]: > Andrew Overholt wrote: > > >Oh yeah. I forgot that we had done that. I'm open to change if it's > >necessary but I forget what is in (or was, in our case :) eclipse-gtk2. > > Unless there's a good reason not to, it makes sense to have libswt > separate from any eclipse stuff so that using libswt doesn't pull in > (parts of) the IDE. I folded eclipse-gtk2 into eclipse-platform to reduce the sub-package count. The libswt3-gtk2 package still contains just SWT stuff so you can run SWT apps with just that installed. If someone does decide to do the work to have motif sub-packages (or fox ones), then I guess whatever used to be in eclipse-gtk2 will have to be resurrected and similar -motif and -fox packages will need to be created. Andrew From ziga.mahkovec at klika.si Sun Apr 10 19:50:40 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Sun, 10 Apr 2005 21:50:40 +0200 Subject: [fedora-java] Eclipse 3.1M6 In-Reply-To: <20050409210544.GA21943@redhat.com> References: <20050409210544.GA21943@redhat.com> Message-ID: <1113162640.23180.3.camel@localhost> On Sat, 2005-04-09 at 17:05 -0400, Andrew Overholt wrote: > I put together some rudimentary RPMs for Eclipse 3.1M6. I tried them very > briefly and they appear to work. Give them a shot if you have a chance. > I'd appreciate any feedback. > > RPMs: > http://people.redhat.com/~overholt/eclipserpms/ I tried these, here are my first impressions: - During installation of eclipse-ecj, I got a (harmless) error: rpm-tmp.61447: line 5: cd: /usr/lib/gcj-4.0.0/classmap.db.d: No such file or directory java.io.FileNotFoundException: bin is a directory at ... (looking at the spec file, the db.d directory is never created) - /usr/bin/eclipse still contains the following line: -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db Since this file no longer exists, eclipse will effectively run in interpreted mode (according to lsof, no jar.so files are opened). By simply removing the line, gij will correctly pick up the new classmap (/usr/lib/gcj-4.0.0/classmap.db). - I no longer have problems with opening XML files [1]. - The disabled search button issue [2] is back. The button is disabled both in native and interpreted mode now. Works fine with Sun's JRE. [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149915 [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149927#c8 -- Ziga From overholt at redhat.com Sun Apr 10 21:09:31 2005 From: overholt at redhat.com (Andrew Overholt) Date: Sun, 10 Apr 2005 17:09:31 -0400 Subject: [fedora-java] Eclipse 3.1M6 In-Reply-To: <1113162640.23180.3.camel@localhost> References: <20050409210544.GA21943@redhat.com> <1113162640.23180.3.camel@localhost> Message-ID: <20050410210931.GA21074@redhat.com> Hi, * Ziga Mahkovec [2005-04-10 15:55]: > > - During installation of eclipse-ecj, I got a (harmless) error: > > rpm-tmp.61447: line 5: cd: /usr/lib/gcj-4.0.0/classmap.db.d: > No such file or directory [...] > - /usr/bin/eclipse still contains the following line: > > -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db [...] Oops. Both of these issues are because I forgot that I had updated eclipse.script and eclipse.spec in the devel branch. I didn't bring over those changes with this M6 set. I'm rebuilding now and I'll post here when they're uploaded. > - I no longer have problems with opening XML files [1]. That's good. Do you still get the error upon opening for the first time as in [3]? > - The disabled search button issue [2] is back. The button is disabled > both in native and interpreted mode now. Works fine with Sun's JRE. That sucks :( I wonder what changed. This appears to be a gcj regression, right? > [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149915 > [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149927#c8 [3] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151919#c3 Thanks for the comments and for trying things out! Andrew From ziga.mahkovec at klika.si Sun Apr 10 23:38:57 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Mon, 11 Apr 2005 01:38:57 +0200 Subject: [fedora-java] Eclipse 3.1M6 In-Reply-To: <20050410210931.GA21074@redhat.com> References: <20050409210544.GA21943@redhat.com> <1113162640.23180.3.camel@localhost> <20050410210931.GA21074@redhat.com> Message-ID: <1113176337.6669.5.camel@localhost> On Sun, 2005-04-10 at 17:09 -0400, Andrew Overholt wrote: > > - I no longer have problems with opening XML files [1]. > > That's good. Do you still get the error upon opening for the first time as > in [3]? Nope, works fine. I was also able to open {build,plugin}.xml files, without a trace of that ClassCastException. > > - The disabled search button issue [2] is back. The button is disabled > > both in native and interpreted mode now. Works fine with Sun's JRE. > > That sucks :( I wonder what changed. This appears to be a gcj regression, > right? Actually, this was my mistake. My rawhide setup was a mess, so I was testing this on FC3 (with gcc/eclipse/gtk from rawhide, but still). I sorted out rawhide now and search works fine. Sorry for the confusion. -- Ziga From greenrd at presidium.org Sun Apr 10 23:32:21 2005 From: greenrd at presidium.org (Robin Green) Date: Mon, 11 Apr 2005 00:32:21 +0100 Subject: [fedora-java] Patch to find-and-nativify Message-ID: This proposed patch makes 4 changes to the find-and-nativify in java-1.4.2-gcj-compat-1.4.2.0-40jpp_14rh. - Generates a database as it goes, rather than forcing the spec file writer to write a similar script to build the db. - Qualifies each lib with the package name, to avoid name collisions in Provides. (Which suggests the thought that since package names _must_ be unique by design in rpm - isn't it then sufficient to generate libs in %{_libdir}/%{name} instead of as %{_libdir}/%{name}/full/path/to/jar ?) - Ignores jars which are symlinks (they might not even be in the package, and if they are, you will end up compiling them more than once.) - You can set the SKIPTAR environment variable to skip the tar building, for more efficient rpm builds. I have a handy utility script to post next which assumes some of these changes, so I will wait to see what happens to this patch first. -- Robin --- find-and-nativify.old 2005-04-10 22:28:23.000000000 +0100 +++ find-and-nativify 2005-04-11 00:02:59.000000000 +0100 @@ -12,20 +12,33 @@ (ex. eclipse) BUILD_OPTIONS - a list of gcj options to pass to nativify (outside of -findirect-dispatch, -shared, and -Wl,-Bsymbolic) + + By default, the generated database will assume libraries will go in /usr/lib. + To change this, set LIBDIR to the appropriate directory. + + Set SKIPTAR=y to skip tar file creation. "} name=$1 build_options=$2 -for jarfile in $(find -name \*.jar); do +# There's this great concept - it's called databases with no fixed size limits! +# For now, kludge the fixed size limit at 80000 +gcj-dbtool -n $name.db 80000 + +# Use type -f to ignore symlinks +for jarfile in $(find -type f -name \*.jar); do # This is ugly. What we want is to be able to natively-compile all the # jars within an RPM build tree as well as from an arbitrary location # in the filesystem. Patches welcome :) so_dir="./$name/$(dirname $jarfile | \ sed 's:^\.\+/::')"; mkdir -p $so_dir; - dest_so_name=$so_dir/lib`basename $jarfile`.so + dest_so_name=$so_dir/lib$name-`basename $jarfile`.so nativify $jarfile $dest_so_name "$build_options" + gcj-dbtool -f $name.db $jarfile ${LIBDIR:-/usr/lib}/$dest_so_name done -tar czf $name.tar.gz $name +if [ -z "${SKIPTAR:-}" ]; then + tar czf $name.tar.gz $name +fi From overholt at redhat.com Sun Apr 10 23:52:03 2005 From: overholt at redhat.com (Andrew Overholt) Date: Sun, 10 Apr 2005 19:52:03 -0400 Subject: [fedora-java] Eclipse 3.1M6 In-Reply-To: <1113176337.6669.5.camel@localhost> References: <20050409210544.GA21943@redhat.com> <1113162640.23180.3.camel@localhost> <20050410210931.GA21074@redhat.com> <1113176337.6669.5.camel@localhost> Message-ID: <20050410235203.GA31394@redhat.com> * Ziga Mahkovec [2005-04-10 19:43]: > On Sun, 2005-04-10 at 17:09 -0400, Andrew Overholt wrote: > > > - I no longer have problems with opening XML files [1]. > > > > That's good. Do you still get the error upon opening for the first time as > > in [3]? > > Nope, works fine. I was also able to open {build,plugin}.xml files, > without a trace of that ClassCastException. Awesome! > > > - The disabled search button issue [2] is back. The button is disabled > > > both in native and interpreted mode now. Works fine with Sun's JRE. > > > > That sucks :( I wonder what changed. This appears to be a gcj regression, > > right? > > Actually, this was my mistake. My rawhide setup was a mess, so I was > testing this on FC3 (with gcc/eclipse/gtk from rawhide, but still). I > sorted out rawhide now and search works fine. Sorry for the confusion. No problem. That's great to hear! Once we get these RPMs into rawhide, we can verify that the open bugs are fixed. Andrew From david at zarb.org Mon Apr 11 01:28:42 2005 From: david at zarb.org (David Walluck) Date: Sun, 10 Apr 2005 21:28:42 -0400 Subject: [fedora-java] Patch to find-and-nativify In-Reply-To: References: Message-ID: <4259D2CA.9030303@zarb.org> Robin Green wrote: >This proposed patch makes 4 changes to the find-and-nativify in >java-1.4.2-gcj-compat-1.4.2.0-40jpp_14rh. > >- Generates a database as it goes, rather than forcing the spec file >writer to write a similar script to build the db. > > > It makes sense to move the gcj-specific stuff out of the spec, but it also makes sense to do so in a jdk-agnostic way. So, wouldn't it make sense for find_and_nativify to be an rpm macro in jpackage-utils /etc/rpm/macros.jpackage rather than to have it exist only in java-1.4.2-gcj-compat? It would perhaps just define itself to `:' if the compiler is not gcj (or if a particular package breaks when nativified). A method is still needed in order to determine if gcj is being used. File lists for native libs would also need to be generated so that the file list does not need to be altered when building a non-nativified rpm. (One must still be careful not to list the files twice by accident). -- Sincerely, David Walluck From dpaun at rogers.com Mon Apr 11 01:31:03 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Sun, 10 Apr 2005 21:31:03 -0400 Subject: [fedora-java] Re: [JPackage-discuss] Why libswt3-gtk2 isn't split between lib and plugin? also multiple SWTs and GCJ binaries In-Reply-To: <20050410145208.GA6084@redhat.com> References: <20050409001345.54301.qmail@web51405.mail.yahoo.com> <20050409174023.GB12731@redhat.com> <42583091.9060503@zarb.org> <20050409195741.GB21345@redhat.com> <4258A77D.6000707@zarb.org> <20050410145208.GA6084@redhat.com> Message-ID: <20050411013103.GT13251@rogers.com> On Sun, Apr 10, 2005 at 10:52:08AM -0400, Andrew Overholt wrote: > The libswt3-gtk2 package still contains just SWT stuff so you can > run SWT apps with just that installed. This is a really good idea. SWT is a much better toolkit IMO than either AWT or Swing, and it is very important that it's made available standalone if Java is to have any impact on the desktop. -- Dimi. From overholt at redhat.com Mon Apr 11 03:14:22 2005 From: overholt at redhat.com (Andrew Overholt) Date: Sun, 10 Apr 2005 23:14:22 -0400 Subject: [fedora-java] Re: [JPackage-discuss] Why libswt3-gtk2 isn't split between lib and plugin? also multiple SWTs and GCJ binaries In-Reply-To: <20050411013103.GT13251@rogers.com> References: <20050409001345.54301.qmail@web51405.mail.yahoo.com> <20050409174023.GB12731@redhat.com> <42583091.9060503@zarb.org> <20050409195741.GB21345@redhat.com> <4258A77D.6000707@zarb.org> <20050410145208.GA6084@redhat.com> <20050411013103.GT13251@rogers.com> Message-ID: <20050411031422.GA17537@redhat.com> * Dimitrie O. Paun [2005-04-10 21:35]: > On Sun, Apr 10, 2005 at 10:52:08AM -0400, Andrew Overholt wrote: > > The libswt3-gtk2 package still contains just SWT stuff so you can > > run SWT apps with just that installed. > > This is a really good idea. SWT is a much better toolkit IMO than > either AWT or Swing, and it is very important that it's made > available standalone if Java is to have any impact on the desktop. What about Java-GNOME? http://java-gnome.sf.net Andrew "plug-city" Overholt From dpaun at rogers.com Mon Apr 11 03:24:36 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Sun, 10 Apr 2005 23:24:36 -0400 Subject: [fedora-java] Re: [JPackage-discuss] Why libswt3-gtk2 isn't split between lib and plugin? also multiple SWTs and GCJ binaries In-Reply-To: <20050411031422.GA17537@redhat.com> References: <20050409001345.54301.qmail@web51405.mail.yahoo.com> <20050409174023.GB12731@redhat.com> <42583091.9060503@zarb.org> <20050409195741.GB21345@redhat.com> <4258A77D.6000707@zarb.org> <20050410145208.GA6084@redhat.com> <20050411013103.GT13251@rogers.com> <20050411031422.GA17537@redhat.com> Message-ID: <20050411032436.GV13251@rogers.com> On Sun, Apr 10, 2005 at 11:14:22PM -0400, Andrew Overholt wrote: > What about Java-GNOME? Java-GNOME is a fine project, but in all honesty, SWT is a tried-tested-and-true solution. Moreover it gives you cross-platform compatibility to Windows (and like it or not, Windows does matter on the desktop). I don't use many Java apps on the desktop. In fact, I used to *hate* java for desktop app because of Swing (mind you, I do Java for a living :)). And yeah, AWT is a joke nowadays for anything serious, so it's not even worth a mention. Eclipse changed all that for me. It showed me that a Java app can look and feel "native". It's nice. If I needed to do a desktop app and wanted to code it in Java, why pick anything else other than SWT for my toolkit? -- Dimi. From fernando at lozano.eti.br Mon Apr 11 03:58:46 2005 From: fernando at lozano.eti.br (Fernando Lozano) Date: Mon, 11 Apr 2005 00:58:46 -0300 Subject: [fedora-java] Re: [JPackage-discuss] Why libswt3-gtk2 isn't split between lib and plugin? also multiple SWTs and GCJ binaries In-Reply-To: <20050411032436.GV13251@rogers.com> References: <20050409001345.54301.qmail@web51405.mail.yahoo.com> <20050409174023.GB12731@redhat.com> <42583091.9060503@zarb.org> <20050409195741.GB21345@redhat.com> <4258A77D.6000707@zarb.org> <20050410145208.GA6084@redhat.com> <20050411013103.GT13251@rogers.com> <20050411031422.GA17537@redhat.com> <20050411032436.GV13251@rogers.com> Message-ID: <4259F5F6.8050700@lozano.eti.br> Hi, I think the message was't about the best Java GUI toolkit, but on how to package SWT and apps that depend on them. Nothing prevents the packaging of Java-Gnome and apps that depends on it, and it was done at least by Fedora. If everyone would package just the "best" app/library for each category, How would sendmail/postfix and Gnome/KDE users feel? But if you don't mind having your app running on Linux only (actually on BSD and other Unixes) Java-Gnome would be a better toolkit. Go see their websites and mailing list archives for specific reaons. :-) Actually, using Java-Gnome is not Unix-only, just nobody did the port for Windows. GTK itself and many apps, like Gimp and Ethereal, run fine under Windows using the GTK port. []s, Fernando Lozano >On Sun, Apr 10, 2005 at 11:14:22PM -0400, Andrew Overholt wrote: > > >>What about Java-GNOME? >> >> > >Java-GNOME is a fine project, but in all honesty, SWT is a >tried-tested-and-true solution. Moreover it gives you cross-platform >compatibility to Windows (and like it or not, Windows does >matter on the desktop). > >I don't use many Java apps on the desktop. In fact, I used to >*hate* java for desktop app because of Swing (mind you, I do >Java for a living :)). And yeah, AWT is a joke nowadays for >anything serious, so it's not even worth a mention. > >Eclipse changed all that for me. It showed me that a Java app >can look and feel "native". It's nice. If I needed to do a >desktop app and wanted to code it in Java, why pick anything >else other than SWT for my toolkit? > > > From rayauge at doublebite.com Mon Apr 11 05:10:07 2005 From: rayauge at doublebite.com (Ray Auge) Date: Mon, 11 Apr 2005 01:10:07 -0400 Subject: [fedora-java] [slightly off topic from] Why libswt3-gtk2 isn't split between lib and plugin In-Reply-To: <4259F5F6.8050700@lozano.eti.br> References: <20050409001345.54301.qmail@web51405.mail.yahoo.com> <20050409174023.GB12731@redhat.com> <42583091.9060503@zarb.org> <20050409195741.GB21345@redhat.com> <4258A77D.6000707@zarb.org> <20050410145208.GA6084@redhat.com> <20050411013103.GT13251@rogers.com> <20050411031422.GA17537@redhat.com> <20050411032436.GV13251@rogers.com> <4259F5F6.8050700@lozano.eti.br> Message-ID: <1113196207.21115.30.camel@localhost.localdomain> Just clarifying this discussion, which is going slightly off topic. As of the last official release, the Java-GNOME has a supported port of libgtk-java and libglade-java for Windows. Please do not talk around them and make assumptions without first informing yourselves. http://java-gnome.sourceforge.net/cgi-bin/bin/view/Main/WindowsCompilation This port has been going on for about a year (since the first tested were conducted successfully). These guys deserve credit for all their hard work, as do you all. On Mon, 2005-11-04 at 00:58 -0300, Fernando Lozano wrote: > Hi, > > I think the message was't about the best Java GUI toolkit, but on how to > package SWT and apps that depend on them. Nothing prevents the packaging > of Java-Gnome and apps that depends on it, and it was done at least by > Fedora. > > If everyone would package just the "best" app/library for each category, > How would sendmail/postfix and Gnome/KDE users feel? > > But if you don't mind having your app running on Linux only (actually on > BSD and other Unixes) Java-Gnome would be a better toolkit. Go see their > websites and mailing list archives for specific reaons. :-) Actually, > using Java-Gnome is not Unix-only, just nobody did the port for Windows. > GTK itself and many apps, like Gimp and Ethereal, run fine under Windows > using the GTK port. > > []s, Fernando Lozano > > >On Sun, Apr 10, 2005 at 11:14:22PM -0400, Andrew Overholt wrote: > > > > > >>What about Java-GNOME? > >> > >> > > > >Java-GNOME is a fine project, but in all honesty, SWT is a > >tried-tested-and-true solution. Moreover it gives you cross-platform > >compatibility to Windows (and like it or not, Windows does > >matter on the desktop). > > > >I don't use many Java apps on the desktop. In fact, I used to > >*hate* java for desktop app because of Swing (mind you, I do > >Java for a living :)). And yeah, AWT is a joke nowadays for > >anything serious, so it's not even worth a mention. > > > >Eclipse changed all that for me. It showed me that a Java app > >can look and feel "native". It's nice. If I needed to do a > >desktop app and wanted to code it in Java, why pick anything > >else other than SWT for my toolkit? > > > > > > > > _______________________________________________ > JPackage-discuss mailing list > JPackage-discuss at zarb.org > https://www.zarb.org/mailman/listinfo/jpackage-discuss > -- Ray Auge From aph at redhat.com Mon Apr 11 09:18:30 2005 From: aph at redhat.com (Andrew Haley) Date: Mon, 11 Apr 2005 10:18:30 +0100 Subject: [fedora-java] Patch to find-and-nativify In-Reply-To: References: Message-ID: <16986.16614.460126.194620@cuddles.cambridge.redhat.com> Robin Green writes: > This proposed patch makes 4 changes to the find-and-nativify in > java-1.4.2-gcj-compat-1.4.2.0-40jpp_14rh. > > - Generates a database as it goes, rather than forcing the spec file > writer to write a similar script to build the db. > > - Qualifies each lib with the package name, to avoid name collisions in > Provides. (Which suggests the thought that since package names _must_ be > unique by design in rpm - isn't it then sufficient to generate libs in > %{_libdir}/%{name} instead of as %{_libdir}/%{name}/full/path/to/jar ?) > > - Ignores jars which are symlinks (they might not even be in the package, > and if they are, you will end up compiling them more than once.) > > - You can set the SKIPTAR environment variable to skip the tar building, > for more efficient rpm builds. > > I have a handy utility script to post next which assumes some of these > changes, so I will wait to see what happens to this patch first. > > -- > Robin > > > --- find-and-nativify.old 2005-04-10 22:28:23.000000000 +0100 > +++ find-and-nativify 2005-04-11 00:02:59.000000000 +0100 > @@ -12,20 +12,33 @@ > (ex. eclipse) > BUILD_OPTIONS - a list of gcj options to pass to nativify > (outside of -findirect-dispatch, -shared, and -Wl,-Bsymbolic) > + > + By default, the generated database will assume libraries will go in /usr/lib. > + To change this, set LIBDIR to the appropriate directory. > + > + Set SKIPTAR=y to skip tar file creation. > "} > > name=$1 > build_options=$2 > > -for jarfile in $(find -name \*.jar); do > +# There's this great concept - it's called databases with no fixed size limits! They don't have fixed size limits. > +# For now, kludge the fixed size limit at 80000 > +gcj-dbtool -n $name.db 80000 > + > +# Use type -f to ignore symlinks > +for jarfile in $(find -type f -name \*.jar); do > # This is ugly. What we want is to be able to natively-compile all the > # jars within an RPM build tree as well as from an arbitrary location > # in the filesystem. Patches welcome :) > so_dir="./$name/$(dirname $jarfile | \ > sed 's:^\.\+/::')"; > mkdir -p $so_dir; > - dest_so_name=$so_dir/lib`basename $jarfile`.so > + dest_so_name=$so_dir/lib$name-`basename $jarfile`.so > nativify $jarfile $dest_so_name "$build_options" > + gcj-dbtool -f $name.db $jarfile ${LIBDIR:-/usr/lib}/$dest_so_name It's a lot quicker to build individual dbs and mrget them at the end. Andrew. From green at redhat.com Mon Apr 11 11:24:25 2005 From: green at redhat.com (Anthony Green) Date: Mon, 11 Apr 2005 04:24:25 -0700 Subject: [fedora-java] Re: [JPackage-discuss] Why libswt3-gtk2 isn't split between lib and plugin? also multiple SWTs and GCJ binaries In-Reply-To: <4259F5F6.8050700@lozano.eti.br> References: <20050409001345.54301.qmail@web51405.mail.yahoo.com> <20050409174023.GB12731@redhat.com> <42583091.9060503@zarb.org> <20050409195741.GB21345@redhat.com> <4258A77D.6000707@zarb.org> <20050410145208.GA6084@redhat.com> <20050411013103.GT13251@rogers.com> <20050411031422.GA17537@redhat.com> <20050411032436.GV13251@rogers.com> <4259F5F6.8050700@lozano.eti.br> Message-ID: <1113218665.6187.10.camel@localhost.localdomain> On Mon, 2005-04-11 at 00:58 -0300, Fernando Lozano wrote: > Actually, > using Java-Gnome is not Unix-only, just nobody did the port for Windows. ...until recently: http://java-gnome.sourceforge.net/cgi-bin/bin/view/Main/WindowsCompilation AG From overholt at redhat.com Mon Apr 11 12:52:05 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 11 Apr 2005 08:52:05 -0400 Subject: [fedora-java] Re: [JPackage-discuss] Why libswt3-gtk2 isn't split between lib and plugin? also multiple SWTs and GCJ binaries In-Reply-To: <4259F5F6.8050700@lozano.eti.br> References: <20050409001345.54301.qmail@web51405.mail.yahoo.com> <20050409174023.GB12731@redhat.com> <42583091.9060503@zarb.org> <20050409195741.GB21345@redhat.com> <4258A77D.6000707@zarb.org> <20050410145208.GA6084@redhat.com> <20050411013103.GT13251@rogers.com> <20050411031422.GA17537@redhat.com> <20050411032436.GV13251@rogers.com> <4259F5F6.8050700@lozano.eti.br> Message-ID: <20050411125205.GA23409@redhat.com> * Fernando Lozano [2005-04-11 00:34]: > > I think the message was't about the best Java GUI toolkit, but on how to > package SWT and apps that depend on them. [...] Agreed, we're getting off-topic. > But if you don't mind having your app running on Linux only (actually on > BSD and other Unixes) Java-Gnome would be a better toolkit. Go see their > websites and mailing list archives for specific reaons. :-) Actually, > using Java-Gnome is not Unix-only, just nobody did the port for Windows. libgtk-java and libglade-java now both build and can be used on Windows: http://java-gnome.sourceforge.net/cgi-bin/bin/view/Main/WindowsCompilation Andrew From overholt at redhat.com Mon Apr 11 13:42:28 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 11 Apr 2005 09:42:28 -0400 Subject: [fedora-java] Eclipse 3.1M6 In-Reply-To: <20050410210931.GA21074@redhat.com> References: <20050409210544.GA21943@redhat.com> <1113162640.23180.3.camel@localhost> <20050410210931.GA21074@redhat.com> Message-ID: <20050411134228.GA24024@redhat.com> * Andrew Overholt [2005-04-10 17:09]: > > [...] I didn't bring over those changes with this M6 set. I'm rebuilding > now and I'll post here when they're uploaded. http://people.redhat.com/~overholt/eclipserpms http://overholt.ca/rpms/eclipse-3.1.0_fc-0.M6.2.src.rpm Andrew From alberto at acadia.net Mon Apr 11 15:08:01 2005 From: alberto at acadia.net (Vanessa J. Smith) Date: Mon, 11 Apr 2005 15:08:01 +0000 Subject: [fedora-java] Adobe Acrobat 6.0 - 75% OFF Message-ID: Access all the software imaginable for prices substantially lower than in stores! Our software is 2-10 times cheaper than sold by our competitors. Just a few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $59.95 Corel Draw Graphics Suite 11 Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many more... Enter here: http://www.bestcds.su Best regards, Vanessa J. Smith _____________________________________________________ To be taken out, go: http://www.bestcds.su/uns.htm _____________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmuldoon at redhat.com Mon Apr 11 15:32:10 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Mon, 11 Apr 2005 10:32:10 -0500 Subject: [fedora-java] Re: Eclipse UI Tests In-Reply-To: <1112731551.5609.24.camel@dhcp-12.hsv.redhat.com> References: <20050405145540.GA12831@redhat.com> <1112723683.4784.35.camel@tomaluk.toronto.redhat.com> <1112724147.32112.2.camel@town.toronto.redhat.com> <1112729871.4784.42.camel@tomaluk.toronto.redhat.com> <1112731551.5609.24.camel@dhcp-12.hsv.redhat.com> Message-ID: <1113233530.1859.7.camel@localhost.localdomain> > So with that in mind, I thought > it best to hold off an additional week to to let the Eclipse CDT 3.0 M6 > build be published, as the schedules are so close. This will ensure that > our CDT users are not left stranded. One week, one way or the other, is > not too much time. So soon, very soon... ;) There is a candidate integration build that the Eclipse CDT team has released for M6. As yet it is untagged in the eclipse repository, so I built a test CDT M6 build and put the rpm/srpm on: http://people.redhat.com/pmuldoon/cdt I did a quick smoke test, and it appears to work with Eclipse M6 ok. Feedback appreciated. Regards Phil From overholt at redhat.com Tue Apr 12 02:53:19 2005 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 11 Apr 2005 22:53:19 -0400 Subject: [fedora-java] Eclipse 3.1M6 In-Reply-To: <20050411134228.GA24024@redhat.com> References: <20050409210544.GA21943@redhat.com> <1113162640.23180.3.camel@localhost> <20050410210931.GA21074@redhat.com> <20050411134228.GA24024@redhat.com> Message-ID: <20050412025319.GA15057@redhat.com> * Andrew Overholt [2005-04-11 09:45]: > * Andrew Overholt [2005-04-10 17:09]: > > > > [...] I didn't bring over those changes with this M6 set. I'm rebuilding > > now and I'll post here when they're uploaded. I built new RPMs with one small change: there is now an ecj binary installed in /usr/bin. I've also run createrepo this time so if you add something like this to yum.conf or create a file in /etc/yum.repos.d you should be able to update. [eclipse] name=eclipse baseurl=http://overholt.ca/rpms/eclipse enabled=0 gpgcheck=0 Please don't forget that these are just preview RPMs. I'll keep the numbers consistent when I build into rawhide, though, so that upgrades will work. Hopefully we'll have some M6 RPMs in rawhide soon. Andrew From stemeri at yahoo.fr Tue Apr 12 08:25:12 2005 From: stemeri at yahoo.fr (stemeri) Date: Tue, 12 Apr 2005 10:25:12 +0200 (CEST) Subject: [fedora-java] native eclipse freezing Message-ID: <20050412082512.9315.qmail@web25807.mail.ukl.yahoo.com> With all updates OK on rawhide (on a daily basis), I have troubles with native eclipse. It looks like this post : https://www.redhat.com/archives/fedora-devel-java-list/2005-March/msg00265.html However, some more informations: Launching eclipse as a user is perfect and CDT (I develop only in c++) is working for me. However, launching eclipse as root freezes the computer. Only way to go : hard reset (no alt-sys..., no ssh, ...). __________________________________________________________________ D?couvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Cr?ez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ From mlists at juma.me.uk Tue Apr 12 14:05:35 2005 From: mlists at juma.me.uk (Ismael Juma) Date: Tue, 12 Apr 2005 15:05:35 +0100 Subject: [fedora-java] Eclipse 3.1M6 In-Reply-To: <20050412025319.GA15057@redhat.com> References: <20050409210544.GA21943@redhat.com> <1113162640.23180.3.camel@localhost> <20050410210931.GA21074@redhat.com> <20050411134228.GA24024@redhat.com> <20050412025319.GA15057@redhat.com> Message-ID: <1113314735.16346.18.camel@localhost.localdomain> On Mon, 2005-04-11 at 22:53 -0400, Andrew Overholt wrote: > [...] > Please don't forget that these are just preview RPMs. I'll keep the > numbers consistent when I build into rawhide, though, so that upgrades will > work. Hopefully we'll have some M6 RPMs in rawhide soon. > [...] Hi, I'm running a system with all packages updated from rawhide as of yesterday (the eclipse packaged I have installed are listed at the end of the email) and if I: 1. Launch eclipse using a clean workspace 2. Create a new project. 3. Create a file named build.xml. I get an exception when eclipse tries to open the newly created file in the ant editor. The following message shows up: "Unable to create editor. This message may be due to a bug in the editor, not a problem with the file you are trying to edit. First close this error message and then use "Open With..." to open the file in a different editor. Reason for the failure: Editor could not be initialized." I'm attaching the stack trace that is provided if I click on "Details". The problem occurs with both gij and jdk 1.5.0_02. It seems related to the ant editor. If I create a file named web.xml for example, it works without problems. Since these packages haven't been released yet, I wasn't sure if I should add it to bugzilla. Please let me know if you want me to do that. Keep up the good work. :) Regards, Ismael Eclipse packages: eclipse-ecj-3.1.0_fc-0.M6.3 eclipse-cdt-3.0.0_fc-0.M6.1 eclipse-platform-3.1.0_fc-0.M6.3 eclipse-jdt-devel-3.1.0_fc-0.M6.3 eclipse-changelog-2.0.1_fc-19 eclipse-platform-devel-3.1.0_fc-0.M6.3 eclipse-pde-3.1.0_fc-0.M6.3 eclipse-bugzilla-0.1.0_fc-9 eclipse-pde-devel-3.1.0_fc-0.M6.3 eclipse-jdt-3.1.0_fc-0.M6.3 -------------- next part -------------- at java.lang.VMClassLoader.resolveClass(java.lang.Class) (/usr/lib/libgcj.so.6.0.0) at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.6.0.0) at org.eclipse.ant.internal.ui.editor.text.AntEditorDocumentProvider.createAntModel(java.lang.Object, org.eclipse.jface.text.IDocument, org.eclipse.jface.text.source.IAnnotationModel) (/usr/lib/eclipse/plugins/org.eclipse.ant.ui_3.1.0/antui.jar.so) at org.eclipse.ant.internal.ui.editor.text.AntEditorDocumentProvider.createFileInfo(java.lang.Object) (/usr/lib/eclipse/plugins/org.eclipse.ant.ui_3.1.0/antui.jar.so) at org.eclipse.ui.editors.text.TextFileDocumentProvider.connect(java.lang.Object) (/usr/lib/eclipse/plugins/org.eclipse.ui.editors_3.1.0/editors.jar.so) at org.eclipse.ui.texteditor.AbstractTextEditor.doSetInput(org.eclipse.ui.IEditorInput) (/usr/lib/eclipse/plugins/org.eclipse.ui.workbench.texteditor_3.1.0/texteditor.jar.so) at org.eclipse.ui.texteditor.StatusTextEditor.doSetInput(org.eclipse.ui.IEditorInput) (/usr/lib/eclipse/plugins/org.eclipse.ui.workbench.texteditor_3.1.0/texteditor.jar.so) at org.eclipse.ui.texteditor.AbstractDecoratedTextEditor.doSetInput(org.eclipse.ui.IEditorInput) (/usr/lib/eclipse/plugins/org.eclipse.ui.editors_3.1.0/editors.jar.so) at org.eclipse.ui.editors.text.TextEditor.doSetInput(org.eclipse.ui.IEditorInput) (/usr/lib/eclipse/plugins/org.eclipse.ui.editors_3.1.0/editors.jar.so) at org.eclipse.ant.internal.ui.editor.AntEditor.doSetInput(org.eclipse.ui.IEditorInput) (/usr/lib/eclipse/plugins/org.eclipse.ant.ui_3.1.0/antui.jar.so) at org.eclipse.ui.texteditor.AbstractTextEditor$16.run(org.eclipse.core.runtime.IProgressMonitor) (/usr/lib/eclipse/plugins/org.eclipse.ui.workbench.texteditor_3.1.0/texteditor.jar.so) at org.eclipse.jface.operation.ModalContext.runInCurrentThread(org.eclipse.jface.operation.IRunnableWithProgress, org.eclipse.core.runtime.IProgressMonitor) (Unknown Source) at org.eclipse.jface.operation.ModalContext.run(org.eclipse.jface.operation.IRunnableWithProgress, boolean, org.eclipse.core.runtime.IProgressMonitor, org.eclipse.swt.widgets.Display) (Unknown Source) at org.eclipse.jface.window.ApplicationWindow$1.run() (Unknown Source) at org.eclipse.swt.custom.BusyIndicator.showWhile(org.eclipse.swt.widgets.Display, java.lang.Runnable) (Unknown Source) at org.eclipse.jface.window.ApplicationWindow.run(boolean, boolean, org.eclipse.jface.operation.IRunnableWithProgress) (Unknown Source) at org.eclipse.ui.internal.WorkbenchWindow.run(boolean, boolean, org.eclipse.jface.operation.IRunnableWithProgress) (Unknown Source) at org.eclipse.ui.texteditor.AbstractTextEditor.internalInit(org.eclipse.ui.IWorkbenchWindow, org.eclipse.ui.IEditorSite, org.eclipse.ui.IEditorInput) (/usr/lib/eclipse/plugins/org.eclipse.ui.workbench.texteditor_3.1.0/texteditor.jar.so) at org.eclipse.ui.texteditor.AbstractTextEditor.init(org.eclipse.ui.IEditorSite, org.eclipse.ui.IEditorInput) (/usr/lib/eclipse/plugins/org.eclipse.ui.workbench.texteditor_3.1.0/texteditor.jar.so) at org.eclipse.ui.internal.EditorManager.createSite(org.eclipse.ui.IEditorReference, org.eclipse.ui.IEditorPart, org.eclipse.ui.internal.registry.EditorDescriptor, org.eclipse.ui.IEditorInput) (Unknown Source) at org.eclipse.ui.internal.EditorManager.busyRestoreEditorHelper(org.eclipse.ui.internal.EditorManager$Editor) (Unknown Source) at org.eclipse.ui.internal.EditorManager.busyRestoreEditor(org.eclipse.ui.internal.EditorManager$Editor) (Unknown Source) at org.eclipse.ui.internal.EditorManager$7.run() (Unknown Source) at org.eclipse.swt.custom.BusyIndicator.showWhile(org.eclipse.swt.widgets.Display, java.lang.Runnable) (Unknown Source) at org.eclipse.ui.internal.EditorManager.restoreEditor(org.eclipse.ui.internal.EditorManager$Editor) (Unknown Source) at org.eclipse.ui.internal.EditorManager$Editor.getEditor(boolean) (Unknown Source) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(org.eclipse.ui.IEditorInput, java.lang.String, boolean) (Unknown Source) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(org.eclipse.ui.IEditorInput, java.lang.String, boolean) (Unknown Source) at org.eclipse.ui.internal.WorkbenchPage.access$7(org.eclipse.ui.internal.WorkbenchPage, org.eclipse.ui.IEditorInput, java.lang.String, boolean) (Unknown Source) at org.eclipse.ui.internal.WorkbenchPage$9.run() (Unknown Source) From pmuldoon at redhat.com Tue Apr 12 14:33:37 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Tue, 12 Apr 2005 09:33:37 -0500 Subject: [fedora-java] native eclipse freezing In-Reply-To: <20050412082512.9315.qmail@web25807.mail.ukl.yahoo.com> References: <20050412082512.9315.qmail@web25807.mail.ukl.yahoo.com> Message-ID: <1113316417.5603.0.camel@dhcp-12.hsv.redhat.com> Hi File a bug so we can track it (it will get lost in the mailing lists) Regards Phil Muldoon On Tue, 2005-04-12 at 10:25 +0200, stemeri wrote: > With all updates OK on rawhide (on a daily basis), I > have > troubles with native eclipse. It looks like this post > : > https://www.redhat.com/archives/fedora-devel-java-list/2005-March/msg00265.html > > However, some more informations: > Launching eclipse as a user is perfect and CDT (I > develop only in c++) is working for me. > However, launching eclipse as root freezes the > computer. Only way to go : hard reset (no alt-sys..., > no ssh, ...). > > > > > > > __________________________________________________________________ > D?couvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! > Cr?ez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From aph at redhat.com Tue Apr 19 08:42:17 2005 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Apr 2005 09:42:17 +0100 Subject: [fedora-java] Rewrite exception region handling in bytecode compiler Message-ID: <16996.50281.698871.468123@cuddles.cambridge.redhat.com> Jakub, we need this in the Fedora compiler. It's too late for 4.0. Andrew. -------------- next part -------------- An embedded message was scrubbed... From: Andrew Haley Subject: Rewrite exception region handling in bytecode compiler Date: Mon, 18 Apr 2005 21:15:33 +0100 Size: 21250 URL: From lockedroom_lady at yahoo.co.jp Tue Apr 19 20:38:33 2005 From: lockedroom_lady at yahoo.co.jp (=?ISO-2022-JP?B?GyRCNVxCPBsoQg==?=) Date: Tue, 19 Apr 2005 16:38:33 -0400 Subject: [fedora-java] =?iso-2022-jp?b?GyRCRnM/TSRHJGJCZz5mSVckRyQ5GyhC?= =?iso-2022-jp?b?GyRCJCshKRsoQg==?= Message-ID: <200504192038.j3JKcXJH012403@mx1.redhat.com> ??????????????? ???????????????????? ????????????????? ????????23??28?????????????3P?????????? ????1?????????????????49????????? ????1????????????????????? ????????????????????????? ???????????????????????? ????????????????????????? ???????????????????????? 3P??????????????????? ???????????????????????????? ????????????????????????????? ????????? ???????????????????? From gbenson at redhat.com Thu Apr 21 09:46:42 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 21 Apr 2005 10:46:42 +0100 Subject: [fedora-java] Rewrite exception region handling in bytecode compiler In-Reply-To: <16996.50281.698871.468123@cuddles.cambridge.redhat.com> References: <16996.50281.698871.468123@cuddles.cambridge.redhat.com> Message-ID: <20050421094641.GA16116@redhat.com> Jakub, can you let me know when this is available in beehive please? Thanks, Gary Andrew Haley wrote: > Jakub, we need this in the Fedora compiler. It's too late for 4.0. > > Andrew. > > Content-Description: forwarded message > Date: Mon, 18 Apr 2005 21:15:33 +0100 > From: Andrew Haley > To: java-patches at gcc.gnu.org, gcc-patches at gcc.gnu.org > Subject: Rewrite exception region handling in bytecode compiler > > PR 20768 shows that the gcj bytecode compiler is miscompiling > exeception regions. This only occurs when such regions aren't > properly nested, and Sun's compiler doesn't seem to output such > regions. However, ecj does, and this has been causing many failures > of gcj-compiled packages in Fedora Core. > > > If we have an exception range like this: > > from to target type > 2 14 14 Class TestExceptionBug$IndexedStoreException > 2 12 29 Throwable /* finally */ > > we compile it to > > try > { > try > { > bytes 2 .. 11; > } > catch (java.lang.Throwable) > { > goto *.LJpc=29; > } > *.LJpc=12: > bytes 12 .. 13; > } > catch (TestExceptionBug$IndexedStoreException) > { > goto *.LJpc=14; > } > *.LJpc=14: > > That is, we have moved the Throwable inside the IndexedStoreException. > But this is wrong: the JVM Spec makes it clear that the exception > table is to be searched from top to bottom, and the first matching > exception used. > > It is not legitimate to hoist an exception region inside one higher in > the table. > > What we really need to do in this case is split the exception table > into properly nested regions, like this: > > from to target type > 2 12 14 Class TestExceptionBug$IndexedStoreException > 2 12 29 Throwable /* finally */ > 12 14 14 Class TestExceptionBug$IndexedStoreException > > Which gives: > > try > { > try > { > bytes 2 .. 11; > } > catch (TestExceptionBug$IndexedStoreException) > { > goto *.LJpc=14; > } > } > catch (java.lang.Throwable) > { > goto *.LJpc=29; > } > try > { > *.LJpc=12: > bytes 12 .. 13; > } > catch (TestExceptionBug$IndexedStoreException) > { > goto *.LJpc=14; > } > *.LJpc=14: > > > This patch is a rewrite of the logic that generates exception > regions. The priority of exceptions in the exception table is > preserved, and no matter how scrambled the exception table, we > generate a logically equivalent tree. > > In a few cases this logic generates more exception regions than the > existing code. Some region merging optimizations are possible at a > later date, but it's more important for this to be correct. > > Tested with JOnAS and Eclipse. > > Andrew. > > > 2005-04-18 Andrew Haley > > * java-except.h (struct eh_range.handler): Remove unused field. > (handle_nested_ranges): Remove function declaration. > (sanity_check_exception_range): Add function declaration. > * verify.c (verify_jvm_instructions): Remove call to > handle_nested_ranges. > * verify-glue.c (verify_jvm_instructions_new): Call > sanity_check_exception_range. > * except.c (link_handler, eh_range_freelist, link_handler, > handle_nested_ranges): Remove. > (add_handler): Rewrite. > (sanity_check_exception_range): New function. > (print_ranges): New function. > > Index: except.c > =================================================================== > RCS file: /cvs/gcc/gcc/gcc/java/except.c,v > retrieving revision 1.47 > diff -c -p -r1.47 except.c > *** except.c 3 Dec 2004 18:11:21 -0000 1.47 > --- except.c 18 Apr 2005 18:58:45 -0000 > *************** > *** 1,5 **** > /* Handle exceptions for GNU compiler for the Java(TM) language. > ! Copyright (C) 1997, 1998, 1999, 2000, 2002, 2003, 2004 > Free Software Foundation, Inc. > > This file is part of GCC. > --- 1,5 ---- > /* Handle exceptions for GNU compiler for the Java(TM) language. > ! Copyright (C) 1997, 1998, 1999, 2000, 2002, 2003, 2004, 2005 > Free Software Foundation, Inc. > > This file is part of GCC. > *************** The Free Software Foundation is independ > *** 42,48 **** > static void expand_start_java_handler (struct eh_range *); > static struct eh_range *find_handler_in_range (int, struct eh_range *, > struct eh_range *); > - static void link_handler (struct eh_range *, struct eh_range *); > static void check_start_handlers (struct eh_range *, int); > static void free_eh_ranges (struct eh_range *range); > > --- 42,47 ---- > *************** struct eh_range *current_method_handlers > *** 50,57 **** > > struct eh_range *current_try_block = NULL; > > - struct eh_range *eh_range_freelist = NULL; > - > /* These variables are used to speed up find_handler. */ > > static int cache_range_start, cache_range_end; > --- 49,54 ---- > *************** static struct eh_range *cache_next_child > *** 62,73 **** > > struct eh_range whole_range; > > #if defined(DEBUG_JAVA_BINDING_LEVELS) > - extern int binding_depth; > extern int is_class_level; > extern int current_pc; > ! extern void indent (); > > #endif > > /* Search for the most specific eh_range containing PC. > --- 59,118 ---- > > struct eh_range whole_range; > > + /* Check the invariants of the structure we're using to contain > + exception regions. Either returns true or fails an assertion > + check. */ > + > + bool > + sanity_check_exception_range (struct eh_range *range) > + { > + struct eh_range *ptr = range->first_child; > + for (; ptr; ptr = ptr->next_sibling) > + { > + gcc_assert (ptr->outer == range > + && ptr->end_pc > ptr->start_pc); > + if (ptr->next_sibling) > + gcc_assert (ptr->next_sibling->start_pc >= ptr->end_pc); > + gcc_assert (ptr->start_pc >= ptr->outer->start_pc > + && ptr->end_pc <= ptr->outer->end_pc); > + (void) sanity_check_exception_range (ptr); > + } > + return true; > + } > + > #if defined(DEBUG_JAVA_BINDING_LEVELS) > extern int is_class_level; > extern int current_pc; > ! extern int binding_depth; > ! extern void indent (void); > ! static void > ! print_ranges (struct eh_range *range) > ! { > ! if (! range) > ! return; > ! > ! struct eh_range *child = range->first_child; > ! > ! indent (); > ! fprintf (stderr, "handler pc %d --> %d ", range->start_pc, range->end_pc); > ! > ! tree handler = range->handlers; > ! for ( ; handler != NULL_TREE; handler = TREE_CHAIN (handler)) > ! { > ! tree type = TREE_PURPOSE (handler); > ! if (type == NULL) > ! type = throwable_type_node; > ! fprintf (stderr, " type=%s ", IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type)))); > ! } > ! fprintf (stderr, "\n"); > > + int saved = binding_depth; > + binding_depth++; > + print_ranges (child); > + binding_depth = saved; > + > + print_ranges (range->next_sibling); > + } > #endif > > /* Search for the most specific eh_range containing PC. > *************** find_handler (int pc) > *** 117,230 **** > return find_handler_in_range (pc, h, cache_next_child); > } > > - /* Recursive helper routine for check_nested_ranges. */ > - > - static void > - link_handler (struct eh_range *range, struct eh_range *outer) > - { > - struct eh_range **ptr; > - > - if (range->start_pc == outer->start_pc && range->end_pc == outer->end_pc) > - { > - outer->handlers = chainon (outer->handlers, range->handlers); > - return; > - } > - > - /* If the new range completely encloses the `outer' range, then insert it > - between the outer range and its parent. */ > - if (range->start_pc <= outer->start_pc && range->end_pc >= outer->end_pc) > - { > - range->outer = outer->outer; > - range->next_sibling = NULL; > - range->first_child = outer; > - { > - struct eh_range *p = outer; > - struct eh_range **pr = &(outer->outer->first_child); > - while (*pr != outer) > - pr = &(*pr)->next_sibling; > - *pr = range; > - > - while (p) > - { > - p->outer = range; > - p = p->next_sibling; > - } > - } > - return; > - } > - > - /* Handle overlapping ranges by splitting the new range. */ > - if (range->start_pc < outer->start_pc || range->end_pc > outer->end_pc) > - { > - struct eh_range *h = xmalloc (sizeof (struct eh_range)); > - if (range->start_pc < outer->start_pc) > - { > - h->start_pc = range->start_pc; > - h->end_pc = outer->start_pc; > - range->start_pc = outer->start_pc; > - } > - else > - { > - h->start_pc = outer->end_pc; > - h->end_pc = range->end_pc; > - range->end_pc = outer->end_pc; > - } > - h->first_child = NULL; > - h->outer = NULL; > - h->handlers = build_tree_list (TREE_PURPOSE (range->handlers), > - TREE_VALUE (range->handlers)); > - h->next_sibling = NULL; > - h->expanded = 0; > - h->stmt = NULL; > - /* Restart both from the top to avoid having to make this > - function smart about reentrancy. */ > - link_handler (h, &whole_range); > - link_handler (range, &whole_range); > - return; > - } > - > - ptr = &outer->first_child; > - for (;; ptr = &(*ptr)->next_sibling) > - { > - if (*ptr == NULL || range->end_pc <= (*ptr)->start_pc) > - { > - range->next_sibling = *ptr; > - range->first_child = NULL; > - range->outer = outer; > - *ptr = range; > - return; > - } > - else if (range->start_pc < (*ptr)->end_pc) > - { > - link_handler (range, *ptr); > - return; > - } > - /* end_pc > (*ptr)->start_pc && start_pc >= (*ptr)->end_pc. */ > - } > - } > - > - /* The first pass of exception range processing (calling add_handler) > - constructs a linked list of exception ranges. We turn this into > - the data structure expected by the rest of the code, and also > - ensure that exception ranges are properly nested. */ > - > - void > - handle_nested_ranges (void) > - { > - struct eh_range *ptr, *next; > - > - ptr = whole_range.first_child; > - whole_range.first_child = NULL; > - for (; ptr; ptr = next) > - { > - next = ptr->next_sibling; > - ptr->next_sibling = NULL; > - link_handler (ptr, &whole_range); > - } > - } > - > - /* Free RANGE as well as its children and siblings. */ > - > static void > free_eh_ranges (struct eh_range *range) > { > --- 162,167 ---- > *************** method_init_exceptions (void) > *** 252,306 **** > cache_range_start = 0xFFFFFF; > } > > ! /* Add an exception range. If we already have an exception range > ! which has the same handler and label, and the new range overlaps > ! that one, then we simply extend the existing range. Some bytecode > ! obfuscators generate seemingly nonoverlapping exception ranges > ! which, when coalesced, do in fact nest correctly. > ! > ! This constructs an ordinary linked list which check_nested_ranges() > ! later turns into the data structure we actually want. > > ! We expect the input to come in order of increasing START_PC. This > ! function doesn't attempt to detect the case where two previously > ! added disjoint ranges could be coalesced by a new range; that is > ! what the sorting counteracts. */ > > ! void > add_handler (int start_pc, int end_pc, tree handler, tree type) > { > ! struct eh_range *ptr, *prev = NULL, *h; > > for (ptr = whole_range.first_child; ptr; ptr = ptr->next_sibling) > { > ! if (start_pc >= ptr->start_pc > ! && start_pc <= ptr->end_pc > ! && TREE_PURPOSE (ptr->handlers) == type > ! && TREE_VALUE (ptr->handlers) == handler) > { > ! /* Already found an overlapping range, so coalesce. */ > ! ptr->end_pc = MAX (ptr->end_pc, end_pc); > ! return; > } > ! prev = ptr; > } > > h = xmalloc (sizeof (struct eh_range)); > h->start_pc = start_pc; > h->end_pc = end_pc; > h->first_child = NULL; > ! h->outer = NULL; > h->handlers = build_tree_list (type, handler); > h->next_sibling = NULL; > h->expanded = 0; > h->stmt = NULL; > > ! if (prev == NULL) > ! whole_range.first_child = h; > ! else > ! prev->next_sibling = h; > ! } > > /* if there are any handlers for this range, issue start of region */ > static void > expand_start_java_handler (struct eh_range *range) > --- 189,354 ---- > cache_range_start = 0xFFFFFF; > } > > ! /* Split an exception range into two at PC. The sub-ranges that > ! belong to the range are split and distributed between the two new > ! ranges. */ > ! > ! static void > ! split_range (struct eh_range *range, int pc) > ! { > ! struct eh_range *ptr; > ! struct eh_range **first_child, **second_child; > ! struct eh_range *h; > ! > ! /* First, split all the sub-ranges. */ > ! for (ptr = range->first_child; ptr; ptr = ptr->next_sibling) > ! { > ! if (pc > ptr->start_pc > ! && pc < ptr->end_pc) > ! { > ! split_range (ptr, pc); > ! } > ! } > ! > ! /* Create a new range. */ > ! h = xmalloc (sizeof (struct eh_range)); > ! > ! h->start_pc = pc; > ! h->end_pc = range->end_pc; > ! h->next_sibling = range->next_sibling; > ! range->next_sibling = h; > ! range->end_pc = pc; > ! h->handlers = build_tree_list (TREE_PURPOSE (range->handlers), > ! TREE_VALUE (range->handlers)); > ! h->next_sibling = NULL; > ! h->expanded = 0; > ! h->stmt = NULL; > ! h->outer = range->outer; > ! h->first_child = NULL; > ! > ! ptr = range->first_child; > ! first_child = &range->first_child; > ! second_child = &h->first_child; > ! > ! /* Distribute the sub-ranges bewteen the two new ranges. */ > ! for (ptr = range->first_child; ptr; ptr = ptr->next_sibling) > ! { > ! if (ptr->start_pc < pc) > ! { > ! *first_child = ptr; > ! ptr->outer = range; > ! first_child = &ptr->next_sibling; > ! } > ! else > ! { > ! *second_child = ptr; > ! ptr->outer = h; > ! second_child = &ptr->next_sibling; > ! } > ! } > ! *first_child = NULL; > ! *second_child = NULL; > ! } > ! > ! > ! /* Add an exception range. > ! > ! There are some missed optimization opportunities here. For > ! example, some bytecode obfuscators generate seemingly > ! nonoverlapping exception ranges which, when coalesced, do in fact > ! nest correctly. We could merge these, but we'd have to fix up all > ! the enclosed regions first and perhaps create a new range anyway if > ! it overlapped existing ranges. > > ! Also, we don't attempt to detect the case where two previously > ! added disjoint ranges could be coalesced by a new range. */ > > ! void > add_handler (int start_pc, int end_pc, tree handler, tree type) > { > ! struct eh_range *ptr, *h; > ! struct eh_range **first_child, **prev; > > + /* First, split all the existing ranges that we need to enclose. */ > for (ptr = whole_range.first_child; ptr; ptr = ptr->next_sibling) > { > ! if (start_pc > ptr->start_pc > ! && start_pc < ptr->end_pc) > { > ! split_range (ptr, start_pc); > } > ! > ! if (end_pc > ptr->start_pc > ! && end_pc < ptr->end_pc) > ! { > ! split_range (ptr, end_pc); > ! } > ! > ! if (ptr->start_pc >= end_pc) > ! break; > } > > + /* Create the new range. */ > h = xmalloc (sizeof (struct eh_range)); > + first_child = &h->first_child; > + > h->start_pc = start_pc; > h->end_pc = end_pc; > h->first_child = NULL; > ! h->outer = NULL_EH_RANGE; > h->handlers = build_tree_list (type, handler); > h->next_sibling = NULL; > h->expanded = 0; > h->stmt = NULL; > > ! /* Find every range at the top level that will be a sub-range of the > ! range we're inserting and make it so. */ > ! { > ! struct eh_range **prev = &whole_range.first_child; > ! for (ptr = *prev; ptr;) > ! { > ! struct eh_range *next = ptr->next_sibling; > ! > ! if (ptr->start_pc >= end_pc) > ! break; > > + if (ptr->start_pc < start_pc) > + { > + prev = &ptr->next_sibling; > + } > + else if (ptr->start_pc >= start_pc > + && ptr->start_pc < end_pc) > + { > + *prev = next; > + *first_child = ptr; > + first_child = &ptr->next_sibling; > + ptr->outer = h; > + ptr->next_sibling = NULL; > + } > + > + ptr = next; > + } > + } > + > + /* Find the right place to insert the new range. */ > + prev = &whole_range.first_child; > + for (ptr = *prev; ptr; prev = &ptr->next_sibling, ptr = ptr->next_sibling) > + { > + gcc_assert (ptr->outer == NULL_EH_RANGE); > + if (ptr->start_pc >= start_pc) > + break; > + } > + > + /* And insert it there. */ > + *prev = h; > + if (ptr) > + { > + h->next_sibling = ptr; > + h->outer = ptr->outer; > + } > + } > + > + > /* if there are any handlers for this range, issue start of region */ > static void > expand_start_java_handler (struct eh_range *range) > Index: java-except.h > =================================================================== > RCS file: /cvs/gcc/gcc/gcc/java/java-except.h,v > retrieving revision 1.18 > diff -c -p -r1.18 java-except.h > *** java-except.h 12 Feb 2005 15:21:14 -0000 1.18 > --- java-except.h 18 Apr 2005 18:58:45 -0000 > *************** struct eh_range > *** 54,61 **** > > /* The TRY_CATCH_EXPR for this EH range. */ > tree stmt; > - > - tree handler; > }; > > /* A dummy range that represents the entire method. */ > --- 54,59 ---- > *************** extern struct eh_range * find_handler (i > *** 67,71 **** > extern void method_init_exceptions (void); > extern void maybe_start_try (int, int); > extern void add_handler (int, int, tree, tree); > - extern void handle_nested_ranges (void); > extern void expand_end_java_handler (struct eh_range *); > --- 65,69 ---- > extern void method_init_exceptions (void); > extern void maybe_start_try (int, int); > extern void add_handler (int, int, tree, tree); > extern void expand_end_java_handler (struct eh_range *); > + extern bool sanity_check_exception_range (struct eh_range *); > Index: verify-glue.c > =================================================================== > RCS file: /cvs/gcc/gcc/gcc/java/verify-glue.c,v > retrieving revision 1.5 > diff -c -p -r1.5 verify-glue.c > *** verify-glue.c 7 Mar 2005 21:10:49 -0000 1.5 > --- verify-glue.c 18 Apr 2005 18:58:45 -0000 > *************** verify_jvm_instructions_new (JCF *jcf, c > *** 487,493 **** > instruction_bits[handler_pc] |= BCODE_EXCEPTION_TARGET; > } > > ! handle_nested_ranges (); > > method.method = current_function_decl; > method.signature = build_java_signature (TREE_TYPE (current_function_decl)); > --- 487,493 ---- > instruction_bits[handler_pc] |= BCODE_EXCEPTION_TARGET; > } > > ! gcc_assert (sanity_check_exception_range (&whole_range)); > > method.method = current_function_decl; > method.signature = build_java_signature (TREE_TYPE (current_function_decl)); > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From aluchko at redhat.com Thu Apr 21 21:42:42 2005 From: aluchko at redhat.com (Aaron Luchko) Date: Thu, 21 Apr 2005 17:42:42 -0400 Subject: [fedora-java] Test results for eclipse gcj/sun/ibm/bea Message-ID: <1114119763.4784.206.camel@tomaluk.toronto.redhat.com> I've posted some results to http://people.redhat.com/aluchko/ There's a bug I'm trying to track down causing gcj to fail on the genHtml stage so I have to run that with sun, this has no effect on the results at all it just means a tiny bit of hackery in the scripts. The M6.6 tests were only done on the jdttext tests. The M6.7 were done on as much of the suite as I could get, there were a number of the tests which appeared to hang (ie no visible progress after 1hr+ though there was often high CPU usage) in these cases I killed the test which is why some of the result sets are empty. In total this took about 22hrs to run (how much of this is due to the hanging tests I'm not sure but it's no less then half). I'll try running the tests on the other VMs and post the results as they finish, also I'll set the GCJ tests running again on their own over the weekend and see if they complete or not. Aaron From lovelove at 072chan.com Fri Apr 22 21:46:54 2005 From: lovelove at 072chan.com (lovelove at 072chan.com) Date: 23 Apr 2005 06:46:54 +0900 Subject: [fedora-java] =?iso-2022-jp?b?GyRCIXowJiQsJC0kQyRIOCskRCQrGyhC?= =?iso-2022-jp?b?GyRCJGshehsoQg==?= Message-ID: <20050422214654.2028.qmail@localhost> ????????? ???????????????? ??????????? http://lovers.sh/?dr01 ?????????????????????????????????? ????????????????????????? ??????????????????????????? ???????????????????????????????? ?????????????????? ???????????????????????????? LOVERS????????????? ????????????????????? ?????????????????????????? ?????????????????????????????????? ???????????http://lovers.sh/?dr01?????? From gbenson at redhat.com Fri Apr 22 15:56:15 2005 From: gbenson at redhat.com (Gary Benson) Date: Fri, 22 Apr 2005 16:56:15 +0100 Subject: [fedora-java] New aot-compile syntax? Message-ID: <20050422155614.GA5618@redhat.com> While I've been nativifying various bits of the Tomcat stack I've kept finding myself with bits of specfile like: for jar in %{name} %{name}-launcher; do aot-compile build/lib/$jar.jar build/lib/lib$jar.jar.so done The attached patch changes aot-compile's syntax to allow that bit f spec to be rewritten as: aot-compile build/lib/%{name}.jar build/lib/%{name}-launcher.jar With the attached patch you can pass build options to gcc by putting them before the jars on the command line: aot-compile -march=i386 -mtune=pentium4 build/lib/%{name}.jar or (more likely): aot-compile $RPM_OPTS build/lib/%{name}.jar Anyone see any problems? Cheers, Gary [ gbenson at redhat.com ][ I am Red Hat ][ http://inauspicious.org/ ] -------------- next part -------------- Index: aot-compile.in =================================================================== RCS file: /cvs/rhug/java-gcj-compat/aot-compile.in,v retrieving revision 1.1 diff -u -r1.1 aot-compile.in --- aot-compile.in 14 Apr 2005 22:12:54 -0000 1.1 +++ aot-compile.in 22 Apr 2005 15:34:44 -0000 @@ -4,12 +4,21 @@ : ${1?" aot-compile: Natively-compile a given JAR - Usage: $0 SRC_JARFILE DEST_SO_NAME BUILD_OPTIONS - SRC_JARFILE - the jar file we want to process - DEST_SO_NAME - the destination name of the .so of the compiled JAR + Usage: $0 [BUILD_OPTIONS] JARS + JARS - jar files we want to process BUILD_OPTIONS - a list of gcj options (outside of -findirect-dispatch -shared -Wl,-Bsymbolic) "} - at GCJ_BIN_DIR@/gcj at gcc_suffix@ $3 -findirect-dispatch \ - -shared -Wl,-Bsymbolic -o $2 $1 +unset opts +while [ ! -z "$1" ]; do + (echo -- "$1" | grep -q '\.jar$') && break + opts="$opts${opts:+ }$1" + shift +done +while [ ! -z "$1" ]; do + @GCJ_BIN_DIR@/gcj at gcc_suffix@ \ + $opts -findirect-dispatch -shared -Wl,-Bsymbolic \ + -o `dirname $1`/lib`basename $1`.so $1 + shift +done From overholt at redhat.com Fri Apr 22 16:20:51 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 22 Apr 2005 12:20:51 -0400 Subject: [fedora-java] New aot-compile syntax? In-Reply-To: <20050422155614.GA5618@redhat.com> References: <20050422155614.GA5618@redhat.com> Message-ID: <20050422162051.GA18410@redhat.com> * Gary Benson [2005-04-22 11:59]: > > The attached patch changes aot-compile's syntax to allow that bit f > spec to be rewritten as: > > aot-compile build/lib/%{name}.jar build/lib/%{name}-launcher.jar Looks good to me. Thanks, Andrew From aizawa at lily-adolescence.cx Sun Apr 24 20:26:39 2005 From: aizawa at lily-adolescence.cx (aizawa at lily-adolescence.cx) Date: Mon, 25 Apr 2005 05:26:39 +0900 Subject: [fedora-java] =?iso-2022-jp?b?GyRCJCo1VyQ3JFYkaiRHJDkhIxsoQg==?= Message-ID: <200504250526453.SM00744@192.168.1.11> ????????????????????????????????????? ?????? ????????????? ????????????????????????????????????? ????????????????????????????????????? ????????????????????????????????????? ????????????????????????????????? ??? ????????????????????????????????????? ????????????????????????????????????? ????????????? ????????????????????????????????????? ????????????????????????????????????? ????????????????????????????????????? ????????????????????????????????????? ??????????? ????????????????????????????????????? ???????????????????????????????? ?????????????????????????????????????? ???????????????????????????????? ???????????????????????????????????? ??????????????????????????????????? ? ????????????????????????????????? ??????????????????????????????????? ?? ?????????? ??????????????????? ??????????????????????????????????? ? ??????????????????????????? ? ? 1?????????????????????????????? ? 2???????????????????? ?? 3?????????????????? ?? ??? ????????? ???????????????????? ??????????????????????????????????? ???????????????????????????????????? ????????????????????????????????????? ????????????????????????????????????? ????????????? ????????????????????????????????????? ????????????????????????????????????? ???????????????????????????????? ?Adolescence?????? ?? From donald at accel.net Mon Apr 25 18:36:19 2005 From: donald at accel.net (Vanessa J. Smith) Date: Mon, 25 Apr 2005 18:36:19 +0000 Subject: [fedora-java] Popular soft - very low price Message-ID: Access all the popular software you ever imagined for less! We sell software 2-6 times cheaper than retail price. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $59.95 Corel Draw Graphics Suite 11 Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And lots more... Please visit us at: http://www.cheapsoft.biz Best, Vanessa Smith _____________________________________________________ To be taken out, go here: http://www.cheapsoft.biz/uns.htm _____________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From greenrd at presidium.org Tue Apr 26 21:43:41 2005 From: greenrd at presidium.org (Robin Green) Date: Tue, 26 Apr 2005 22:43:41 +0100 Subject: [fedora-java] swt-mozilla, swt-pi missing in libswt3-gtk2 >= 3.1.0_fc-0.M6 Message-ID: Is this (see Subject) intentional? -- Robin From overholt at redhat.com Tue Apr 26 22:13:34 2005 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 26 Apr 2005 18:13:34 -0400 Subject: [fedora-java] swt-mozilla, swt-pi missing in libswt3-gtk2 >= 3.1.0_fc-0.M6 In-Reply-To: References: Message-ID: <20050426221334.GA2018@redhat.com> * Robin Green [2005-04-26 17:50]: > Is this (see Subject) intentional? I'm pretty sure things changed upstream in M6. Maybe Billy can shed some light on this? Andrew From vektor at dumbterm.net Tue Apr 26 22:16:46 2005 From: vektor at dumbterm.net (Billy Biggs) Date: Tue, 26 Apr 2005 17:16:46 -0500 Subject: [fedora-java] swt-mozilla, swt-pi missing in libswt3-gtk2 >= 3.1.0_fc-0.M6 In-Reply-To: <20050426221334.GA2018@redhat.com> References: <20050426221334.GA2018@redhat.com> Message-ID: <20050426221646.GB11879@dumbterm.net> Andrew Overholt (overholt at redhat.com): > * Robin Green [2005-04-26 17:50]: > > Is this (see Subject) intentional? > > I'm pretty sure things changed upstream in M6. Maybe Billy can shed > some light on this? The SWT plugin was changed to the new plugins-as-jar format, which means that as a plugin we're just one .jar file which includes the .class and .so files. I think this also changed for the SWT only download so that we're just one .jar file now, which makes much more sense. So, yeah, it's intentional. -Billy From aph at redhat.com Wed Apr 27 09:59:25 2005 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Apr 2005 10:59:25 +0100 Subject: [fedora-java] swt-mozilla, swt-pi missing in libswt3-gtk2 >= 3.1.0_fc-0.M6 In-Reply-To: <20050426221646.GB11879@dumbterm.net> References: <20050426221334.GA2018@redhat.com> <20050426221646.GB11879@dumbterm.net> Message-ID: <17007.25213.320292.780667@cuddles.cambridge.redhat.com> Billy Biggs writes: > Andrew Overholt (overholt at redhat.com): > > > * Robin Green [2005-04-26 17:50]: > > > Is this (see Subject) intentional? > > > > I'm pretty sure things changed upstream in M6. Maybe Billy can shed > > some light on this? > > The SWT plugin was changed to the new plugins-as-jar format, which > means that as a plugin we're just one .jar file which includes the > .class and .so files. I think this also changed for the SWT only > download so that we're just one .jar file now, which makes much more > sense. I'm a little mystified about how this might work. Shared libraries are memory mapped files, so they're little use inside a .jar file. I guess the .so is put somewhere at installation? Andrew. From overholt at redhat.com Wed Apr 27 13:17:52 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 27 Apr 2005 09:17:52 -0400 Subject: [fedora-java] swt-mozilla, swt-pi missing in libswt3-gtk2 >= 3.1.0_fc-0.M6 In-Reply-To: <17007.25213.320292.780667@cuddles.cambridge.redhat.com> References: <20050426221334.GA2018@redhat.com> <20050426221646.GB11879@dumbterm.net> <17007.25213.320292.780667@cuddles.cambridge.redhat.com> Message-ID: <20050427131752.GA9879@redhat.com> * Andrew Haley [2005-04-27 06:03]: > Billy Biggs writes: > > Andrew Overholt (overholt at redhat.com): > > > > > * Robin Green [2005-04-26 17:50]: > > > > Is this (see Subject) intentional? > > > > > > I'm pretty sure things changed upstream in M6. Maybe Billy can shed > > > some light on this? > > > > The SWT plugin was changed to the new plugins-as-jar format, which > > means that as a plugin we're just one .jar file which includes the > > .class and .so files. I think this also changed for the SWT only > > download so that we're just one .jar file now, which makes much more > > sense. > > I'm a little mystified about how this might work. Shared libraries > are memory mapped files, so they're little use inside a .jar file. I > guess the .so is put somewhere at installation? Yes. See, for example, https://bugs.eclipse.org/bugs/show_bug.cgi?id=90535 Andrew From vektor at dumbterm.net Wed Apr 27 13:42:04 2005 From: vektor at dumbterm.net (Billy Biggs) Date: Wed, 27 Apr 2005 08:42:04 -0500 Subject: [fedora-java] swt-mozilla, swt-pi missing in libswt3-gtk2 >= 3.1.0_fc-0.M6 In-Reply-To: <17007.25213.320292.780667@cuddles.cambridge.redhat.com> References: <20050426221334.GA2018@redhat.com> <20050426221646.GB11879@dumbterm.net> <17007.25213.320292.780667@cuddles.cambridge.redhat.com> Message-ID: <20050427134204.GC11879@dumbterm.net> Andrew Haley (aph at redhat.com): > Billy Biggs writes: > > The SWT plugin was changed to the new plugins-as-jar format, which > > means that as a plugin we're just one .jar file which includes the > > .class and .so files. I think this also changed for the SWT only > > download so that we're just one .jar file now, which makes much > > more sense. > > I'm a little mystified about how this might work. Shared libraries > are memory mapped files, so they're little use inside a .jar file. I > guess the .so is put somewhere at installation? It's just for eclipse plugins. The eclipse osgi framework extracts any shared libraries for the platform its running on when the plugin is first loaded. This lets plugins be distributed as single .jar files. Also see: http://bugs.eclipse.org/bugs/show_bug.cgi?id=90535 http://dev.eclipse.org/viewcvs/index.cgi%7Echeckout%7E/platform-core-home/documents/3.1/run_from_jars.html -Billy From gbenson at redhat.com Thu Apr 28 13:15:05 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 28 Apr 2005 14:15:05 +0100 Subject: [fedora-java] Rewrite exception region handling in bytecode compiler In-Reply-To: <16996.50281.698871.468123@cuddles.cambridge.redhat.com> References: <16996.50281.698871.468123@cuddles.cambridge.redhat.com> Message-ID: <20050428131503.GB4898@redhat.com> Jakub, does the FC4 compiler have Andrew's new exception code now? Cheers, Gary Andrew Haley wrote: > Jakub, we need this in the Fedora compiler. It's too late for 4.0. > > Andrew. > > > Date: Mon, 18 Apr 2005 21:15:33 +0100 > From: Andrew Haley > To: java-patches at gcc.gnu.org, gcc-patches at gcc.gnu.org > Subject: Rewrite exception region handling in bytecode compiler > > PR 20768 shows that the gcj bytecode compiler is miscompiling > exeception regions. This only occurs when such regions aren't > properly nested, and Sun's compiler doesn't seem to output such > regions. However, ecj does, and this has been causing many failures > of gcj-compiled packages in Fedora Core. > > > If we have an exception range like this: > > from to target type > 2 14 14 Class TestExceptionBug$IndexedStoreException > 2 12 29 Throwable /* finally */ > > we compile it to > > try > { > try > { > bytes 2 .. 11; > } > catch (java.lang.Throwable) > { > goto *.LJpc=29; > } > *.LJpc=12: > bytes 12 .. 13; > } > catch (TestExceptionBug$IndexedStoreException) > { > goto *.LJpc=14; > } > *.LJpc=14: > > That is, we have moved the Throwable inside the IndexedStoreException. > But this is wrong: the JVM Spec makes it clear that the exception > table is to be searched from top to bottom, and the first matching > exception used. > > It is not legitimate to hoist an exception region inside one higher in > the table. > > What we really need to do in this case is split the exception table > into properly nested regions, like this: > > from to target type > 2 12 14 Class TestExceptionBug$IndexedStoreException > 2 12 29 Throwable /* finally */ > 12 14 14 Class TestExceptionBug$IndexedStoreException > > Which gives: > > try > { > try > { > bytes 2 .. 11; > } > catch (TestExceptionBug$IndexedStoreException) > { > goto *.LJpc=14; > } > } > catch (java.lang.Throwable) > { > goto *.LJpc=29; > } > try > { > *.LJpc=12: > bytes 12 .. 13; > } > catch (TestExceptionBug$IndexedStoreException) > { > goto *.LJpc=14; > } > *.LJpc=14: > > > This patch is a rewrite of the logic that generates exception > regions. The priority of exceptions in the exception table is > preserved, and no matter how scrambled the exception table, we > generate a logically equivalent tree. > > In a few cases this logic generates more exception regions than the > existing code. Some region merging optimizations are possible at a > later date, but it's more important for this to be correct. > > Tested with JOnAS and Eclipse. > > Andrew. > > > 2005-04-18 Andrew Haley > > * java-except.h (struct eh_range.handler): Remove unused field. > (handle_nested_ranges): Remove function declaration. > (sanity_check_exception_range): Add function declaration. > * verify.c (verify_jvm_instructions): Remove call to > handle_nested_ranges. > * verify-glue.c (verify_jvm_instructions_new): Call > sanity_check_exception_range. > * except.c (link_handler, eh_range_freelist, link_handler, > handle_nested_ranges): Remove. > (add_handler): Rewrite. > (sanity_check_exception_range): New function. > (print_ranges): New function. > > Index: except.c > =================================================================== > RCS file: /cvs/gcc/gcc/gcc/java/except.c,v > retrieving revision 1.47 > diff -c -p -r1.47 except.c > *** except.c 3 Dec 2004 18:11:21 -0000 1.47 > --- except.c 18 Apr 2005 18:58:45 -0000 > *************** > *** 1,5 **** > /* Handle exceptions for GNU compiler for the Java(TM) language. > ! Copyright (C) 1997, 1998, 1999, 2000, 2002, 2003, 2004 > Free Software Foundation, Inc. > > This file is part of GCC. > --- 1,5 ---- > /* Handle exceptions for GNU compiler for the Java(TM) language. > ! Copyright (C) 1997, 1998, 1999, 2000, 2002, 2003, 2004, 2005 > Free Software Foundation, Inc. > > This file is part of GCC. > *************** The Free Software Foundation is independ > *** 42,48 **** > static void expand_start_java_handler (struct eh_range *); > static struct eh_range *find_handler_in_range (int, struct eh_range *, > struct eh_range *); > - static void link_handler (struct eh_range *, struct eh_range *); > static void check_start_handlers (struct eh_range *, int); > static void free_eh_ranges (struct eh_range *range); > > --- 42,47 ---- > *************** struct eh_range *current_method_handlers > *** 50,57 **** > > struct eh_range *current_try_block = NULL; > > - struct eh_range *eh_range_freelist = NULL; > - > /* These variables are used to speed up find_handler. */ > > static int cache_range_start, cache_range_end; > --- 49,54 ---- > *************** static struct eh_range *cache_next_child > *** 62,73 **** > > struct eh_range whole_range; > > #if defined(DEBUG_JAVA_BINDING_LEVELS) > - extern int binding_depth; > extern int is_class_level; > extern int current_pc; > ! extern void indent (); > > #endif > > /* Search for the most specific eh_range containing PC. > --- 59,118 ---- > > struct eh_range whole_range; > > + /* Check the invariants of the structure we're using to contain > + exception regions. Either returns true or fails an assertion > + check. */ > + > + bool > + sanity_check_exception_range (struct eh_range *range) > + { > + struct eh_range *ptr = range->first_child; > + for (; ptr; ptr = ptr->next_sibling) > + { > + gcc_assert (ptr->outer == range > + && ptr->end_pc > ptr->start_pc); > + if (ptr->next_sibling) > + gcc_assert (ptr->next_sibling->start_pc >= ptr->end_pc); > + gcc_assert (ptr->start_pc >= ptr->outer->start_pc > + && ptr->end_pc <= ptr->outer->end_pc); > + (void) sanity_check_exception_range (ptr); > + } > + return true; > + } > + > #if defined(DEBUG_JAVA_BINDING_LEVELS) > extern int is_class_level; > extern int current_pc; > ! extern int binding_depth; > ! extern void indent (void); > ! static void > ! print_ranges (struct eh_range *range) > ! { > ! if (! range) > ! return; > ! > ! struct eh_range *child = range->first_child; > ! > ! indent (); > ! fprintf (stderr, "handler pc %d --> %d ", range->start_pc, range->end_pc); > ! > ! tree handler = range->handlers; > ! for ( ; handler != NULL_TREE; handler = TREE_CHAIN (handler)) > ! { > ! tree type = TREE_PURPOSE (handler); > ! if (type == NULL) > ! type = throwable_type_node; > ! fprintf (stderr, " type=%s ", IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type)))); > ! } > ! fprintf (stderr, "\n"); > > + int saved = binding_depth; > + binding_depth++; > + print_ranges (child); > + binding_depth = saved; > + > + print_ranges (range->next_sibling); > + } > #endif > > /* Search for the most specific eh_range containing PC. > *************** find_handler (int pc) > *** 117,230 **** > return find_handler_in_range (pc, h, cache_next_child); > } > > - /* Recursive helper routine for check_nested_ranges. */ > - > - static void > - link_handler (struct eh_range *range, struct eh_range *outer) > - { > - struct eh_range **ptr; > - > - if (range->start_pc == outer->start_pc && range->end_pc == outer->end_pc) > - { > - outer->handlers = chainon (outer->handlers, range->handlers); > - return; > - } > - > - /* If the new range completely encloses the `outer' range, then insert it > - between the outer range and its parent. */ > - if (range->start_pc <= outer->start_pc && range->end_pc >= outer->end_pc) > - { > - range->outer = outer->outer; > - range->next_sibling = NULL; > - range->first_child = outer; > - { > - struct eh_range *p = outer; > - struct eh_range **pr = &(outer->outer->first_child); > - while (*pr != outer) > - pr = &(*pr)->next_sibling; > - *pr = range; > - > - while (p) > - { > - p->outer = range; > - p = p->next_sibling; > - } > - } > - return; > - } > - > - /* Handle overlapping ranges by splitting the new range. */ > - if (range->start_pc < outer->start_pc || range->end_pc > outer->end_pc) > - { > - struct eh_range *h = xmalloc (sizeof (struct eh_range)); > - if (range->start_pc < outer->start_pc) > - { > - h->start_pc = range->start_pc; > - h->end_pc = outer->start_pc; > - range->start_pc = outer->start_pc; > - } > - else > - { > - h->start_pc = outer->end_pc; > - h->end_pc = range->end_pc; > - range->end_pc = outer->end_pc; > - } > - h->first_child = NULL; > - h->outer = NULL; > - h->handlers = build_tree_list (TREE_PURPOSE (range->handlers), > - TREE_VALUE (range->handlers)); > - h->next_sibling = NULL; > - h->expanded = 0; > - h->stmt = NULL; > - /* Restart both from the top to avoid having to make this > - function smart about reentrancy. */ > - link_handler (h, &whole_range); > - link_handler (range, &whole_range); > - return; > - } > - > - ptr = &outer->first_child; > - for (;; ptr = &(*ptr)->next_sibling) > - { > - if (*ptr == NULL || range->end_pc <= (*ptr)->start_pc) > - { > - range->next_sibling = *ptr; > - range->first_child = NULL; > - range->outer = outer; > - *ptr = range; > - return; > - } > - else if (range->start_pc < (*ptr)->end_pc) > - { > - link_handler (range, *ptr); > - return; > - } > - /* end_pc > (*ptr)->start_pc && start_pc >= (*ptr)->end_pc. */ > - } > - } > - > - /* The first pass of exception range processing (calling add_handler) > - constructs a linked list of exception ranges. We turn this into > - the data structure expected by the rest of the code, and also > - ensure that exception ranges are properly nested. */ > - > - void > - handle_nested_ranges (void) > - { > - struct eh_range *ptr, *next; > - > - ptr = whole_range.first_child; > - whole_range.first_child = NULL; > - for (; ptr; ptr = next) > - { > - next = ptr->next_sibling; > - ptr->next_sibling = NULL; > - link_handler (ptr, &whole_range); > - } > - } > - > - /* Free RANGE as well as its children and siblings. */ > - > static void > free_eh_ranges (struct eh_range *range) > { > --- 162,167 ---- > *************** method_init_exceptions (void) > *** 252,306 **** > cache_range_start = 0xFFFFFF; > } > > ! /* Add an exception range. If we already have an exception range > ! which has the same handler and label, and the new range overlaps > ! that one, then we simply extend the existing range. Some bytecode > ! obfuscators generate seemingly nonoverlapping exception ranges > ! which, when coalesced, do in fact nest correctly. > ! > ! This constructs an ordinary linked list which check_nested_ranges() > ! later turns into the data structure we actually want. > > ! We expect the input to come in order of increasing START_PC. This > ! function doesn't attempt to detect the case where two previously > ! added disjoint ranges could be coalesced by a new range; that is > ! what the sorting counteracts. */ > > ! void > add_handler (int start_pc, int end_pc, tree handler, tree type) > { > ! struct eh_range *ptr, *prev = NULL, *h; > > for (ptr = whole_range.first_child; ptr; ptr = ptr->next_sibling) > { > ! if (start_pc >= ptr->start_pc > ! && start_pc <= ptr->end_pc > ! && TREE_PURPOSE (ptr->handlers) == type > ! && TREE_VALUE (ptr->handlers) == handler) > { > ! /* Already found an overlapping range, so coalesce. */ > ! ptr->end_pc = MAX (ptr->end_pc, end_pc); > ! return; > } > ! prev = ptr; > } > > h = xmalloc (sizeof (struct eh_range)); > h->start_pc = start_pc; > h->end_pc = end_pc; > h->first_child = NULL; > ! h->outer = NULL; > h->handlers = build_tree_list (type, handler); > h->next_sibling = NULL; > h->expanded = 0; > h->stmt = NULL; > > ! if (prev == NULL) > ! whole_range.first_child = h; > ! else > ! prev->next_sibling = h; > ! } > > /* if there are any handlers for this range, issue start of region */ > static void > expand_start_java_handler (struct eh_range *range) > --- 189,354 ---- > cache_range_start = 0xFFFFFF; > } > > ! /* Split an exception range into two at PC. The sub-ranges that > ! belong to the range are split and distributed between the two new > ! ranges. */ > ! > ! static void > ! split_range (struct eh_range *range, int pc) > ! { > ! struct eh_range *ptr; > ! struct eh_range **first_child, **second_child; > ! struct eh_range *h; > ! > ! /* First, split all the sub-ranges. */ > ! for (ptr = range->first_child; ptr; ptr = ptr->next_sibling) > ! { > ! if (pc > ptr->start_pc > ! && pc < ptr->end_pc) > ! { > ! split_range (ptr, pc); > ! } > ! } > ! > ! /* Create a new range. */ > ! h = xmalloc (sizeof (struct eh_range)); > ! > ! h->start_pc = pc; > ! h->end_pc = range->end_pc; > ! h->next_sibling = range->next_sibling; > ! range->next_sibling = h; > ! range->end_pc = pc; > ! h->handlers = build_tree_list (TREE_PURPOSE (range->handlers), > ! TREE_VALUE (range->handlers)); > ! h->next_sibling = NULL; > ! h->expanded = 0; > ! h->stmt = NULL; > ! h->outer = range->outer; > ! h->first_child = NULL; > ! > ! ptr = range->first_child; > ! first_child = &range->first_child; > ! second_child = &h->first_child; > ! > ! /* Distribute the sub-ranges bewteen the two new ranges. */ > ! for (ptr = range->first_child; ptr; ptr = ptr->next_sibling) > ! { > ! if (ptr->start_pc < pc) > ! { > ! *first_child = ptr; > ! ptr->outer = range; > ! first_child = &ptr->next_sibling; > ! } > ! else > ! { > ! *second_child = ptr; > ! ptr->outer = h; > ! second_child = &ptr->next_sibling; > ! } > ! } > ! *first_child = NULL; > ! *second_child = NULL; > ! } > ! > ! > ! /* Add an exception range. > ! > ! There are some missed optimization opportunities here. For > ! example, some bytecode obfuscators generate seemingly > ! nonoverlapping exception ranges which, when coalesced, do in fact > ! nest correctly. We could merge these, but we'd have to fix up all > ! the enclosed regions first and perhaps create a new range anyway if > ! it overlapped existing ranges. > > ! Also, we don't attempt to detect the case where two previously > ! added disjoint ranges could be coalesced by a new range. */ > > ! void > add_handler (int start_pc, int end_pc, tree handler, tree type) > { > ! struct eh_range *ptr, *h; > ! struct eh_range **first_child, **prev; > > + /* First, split all the existing ranges that we need to enclose. */ > for (ptr = whole_range.first_child; ptr; ptr = ptr->next_sibling) > { > ! if (start_pc > ptr->start_pc > ! && start_pc < ptr->end_pc) > { > ! split_range (ptr, start_pc); > } > ! > ! if (end_pc > ptr->start_pc > ! && end_pc < ptr->end_pc) > ! { > ! split_range (ptr, end_pc); > ! } > ! > ! if (ptr->start_pc >= end_pc) > ! break; > } > > + /* Create the new range. */ > h = xmalloc (sizeof (struct eh_range)); > + first_child = &h->first_child; > + > h->start_pc = start_pc; > h->end_pc = end_pc; > h->first_child = NULL; > ! h->outer = NULL_EH_RANGE; > h->handlers = build_tree_list (type, handler); > h->next_sibling = NULL; > h->expanded = 0; > h->stmt = NULL; > > ! /* Find every range at the top level that will be a sub-range of the > ! range we're inserting and make it so. */ > ! { > ! struct eh_range **prev = &whole_range.first_child; > ! for (ptr = *prev; ptr;) > ! { > ! struct eh_range *next = ptr->next_sibling; > ! > ! if (ptr->start_pc >= end_pc) > ! break; > > + if (ptr->start_pc < start_pc) > + { > + prev = &ptr->next_sibling; > + } > + else if (ptr->start_pc >= start_pc > + && ptr->start_pc < end_pc) > + { > + *prev = next; > + *first_child = ptr; > + first_child = &ptr->next_sibling; > + ptr->outer = h; > + ptr->next_sibling = NULL; > + } > + > + ptr = next; > + } > + } > + > + /* Find the right place to insert the new range. */ > + prev = &whole_range.first_child; > + for (ptr = *prev; ptr; prev = &ptr->next_sibling, ptr = ptr->next_sibling) > + { > + gcc_assert (ptr->outer == NULL_EH_RANGE); > + if (ptr->start_pc >= start_pc) > + break; > + } > + > + /* And insert it there. */ > + *prev = h; > + if (ptr) > + { > + h->next_sibling = ptr; > + h->outer = ptr->outer; > + } > + } > + > + > /* if there are any handlers for this range, issue start of region */ > static void > expand_start_java_handler (struct eh_range *range) > Index: java-except.h > =================================================================== > RCS file: /cvs/gcc/gcc/gcc/java/java-except.h,v > retrieving revision 1.18 > diff -c -p -r1.18 java-except.h > *** java-except.h 12 Feb 2005 15:21:14 -0000 1.18 > --- java-except.h 18 Apr 2005 18:58:45 -0000 > *************** struct eh_range > *** 54,61 **** > > /* The TRY_CATCH_EXPR for this EH range. */ > tree stmt; > - > - tree handler; > }; > > /* A dummy range that represents the entire method. */ > --- 54,59 ---- > *************** extern struct eh_range * find_handler (i > *** 67,71 **** > extern void method_init_exceptions (void); > extern void maybe_start_try (int, int); > extern void add_handler (int, int, tree, tree); > - extern void handle_nested_ranges (void); > extern void expand_end_java_handler (struct eh_range *); > --- 65,69 ---- > extern void method_init_exceptions (void); > extern void maybe_start_try (int, int); > extern void add_handler (int, int, tree, tree); > extern void expand_end_java_handler (struct eh_range *); > + extern bool sanity_check_exception_range (struct eh_range *); > Index: verify-glue.c > =================================================================== > RCS file: /cvs/gcc/gcc/gcc/java/verify-glue.c,v > retrieving revision 1.5 > diff -c -p -r1.5 verify-glue.c > *** verify-glue.c 7 Mar 2005 21:10:49 -0000 1.5 > --- verify-glue.c 18 Apr 2005 18:58:45 -0000 > *************** verify_jvm_instructions_new (JCF *jcf, c > *** 487,493 **** > instruction_bits[handler_pc] |= BCODE_EXCEPTION_TARGET; > } > > ! handle_nested_ranges (); > > method.method = current_function_decl; > method.signature = build_java_signature (TREE_TYPE (current_function_decl)); > --- 487,493 ---- > instruction_bits[handler_pc] |= BCODE_EXCEPTION_TARGET; > } > > ! gcc_assert (sanity_check_exception_range (&whole_range)); > > method.method = current_function_decl; > method.signature = build_java_signature (TREE_TYPE (current_function_decl)); From jakub at redhat.com Thu Apr 28 13:17:06 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 28 Apr 2005 09:17:06 -0400 Subject: [fedora-java] Rewrite exception region handling in bytecode compiler In-Reply-To: <20050428131503.GB4898@redhat.com> References: <16996.50281.698871.468123@cuddles.cambridge.redhat.com> <20050428131503.GB4898@redhat.com> Message-ID: <20050428131706.GV17420@devserv.devel.redhat.com> On Thu, Apr 28, 2005 at 02:15:05PM +0100, Gary Benson wrote: > Jakub, does the FC4 compiler have Andrew's new exception code now? Yes, 4.0.0-0.43 and above, currently rawhide has 4.0.0-1 and I'm working ATM on 4.0.0-2 rpms. Jakub From aph at redhat.com Thu Apr 28 13:20:57 2005 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 Apr 2005 14:20:57 +0100 Subject: [fedora-java] Rewrite exception region handling in bytecode compiler In-Reply-To: <20050428131706.GV17420@devserv.devel.redhat.com> References: <16996.50281.698871.468123@cuddles.cambridge.redhat.com> <20050428131503.GB4898@redhat.com> <20050428131706.GV17420@devserv.devel.redhat.com> Message-ID: <17008.58169.299481.56259@cuddles.cambridge.redhat.com> Jakub Jelinek writes: > On Thu, Apr 28, 2005 at 02:15:05PM +0100, Gary Benson wrote: > > Jakub, does the FC4 compiler have Andrew's new exception code now? > > Yes, 4.0.0-0.43 and above, currently rawhide has 4.0.0-1 and I'm working > ATM on 4.0.0-2 rpms. I didn't get a chance to look at the PPC issues, sorry. Let me know if I can still be of assistance. Andrew. From gbenson at redhat.com Thu Apr 28 13:39:27 2005 From: gbenson at redhat.com (Gary Benson) Date: Thu, 28 Apr 2005 14:39:27 +0100 Subject: [fedora-java] Rewrite exception region handling in bytecode compiler In-Reply-To: <20050428131706.GV17420@devserv.devel.redhat.com> References: <16996.50281.698871.468123@cuddles.cambridge.redhat.com> <20050428131503.GB4898@redhat.com> <20050428131706.GV17420@devserv.devel.redhat.com> Message-ID: <20050428133926.GD4898@redhat.com> Jakub Jelinek wrote: > On Thu, Apr 28, 2005 at 02:15:05PM +0100, Gary Benson wrote: > > Jakub, does the FC4 compiler have Andrew's new exception code now? > > Yes, 4.0.0-0.43 and above, currently rawhide has 4.0.0-1 and I'm > working ATM on 4.0.0-2 rpms. Thank you. Gary From overholt at redhat.com Fri Apr 29 13:42:29 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 29 Apr 2005 09:42:29 -0400 Subject: [fedora-java] [Jim_des_Rivieres@ca.ibm.com: [platform-releng-dev] proposed 3.1 endgame plan] Message-ID: <20050429134229.GA29336@redhat.com> For those not on platform-releng-dev: ----- Forwarded message from Jim des Rivieres ----- From: Jim des Rivieres To: platform-releng-dev at eclipse.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Date: Thu, 28 Apr 2005 19:37:51 -0400 Subject: [platform-releng-dev] proposed 3.1 endgame plan After a number of conversations today about how to best structure the 3.1 endgame, here's what we came up with (consider this still a proposal until everyone has had a chance to digest and comment). We make an immediate (May 2) transition to fixing and polishing mode for all Eclipse component teams, reflecting the fact that most teams have already finished all their feature work for 3.1. The focus becomes the current backlog of bugs which needs to be prioritized, and then reduced. The few teams with additional feature work need to obtain PMC approval to complete that work; all feature work is expected to be done by M7 (May 13) as originally scheduled. The point is not to cut off feature work entirely, but rather to strike the right balance between last-minute feature work and addressing serious bugs, especially if there's already a backlog of bugs also need attending to. After M7, all work is on fixing serious defects, performance, and on special polish items. The work on special polish items is done by RC1 (May 27). We immediately (May 2) start nightly integration builds from HEAD leading up to milestone M7 scheduled for May 13. M7 will also be our release candidate RC0. The difference from the nightly builds is that all teams are expected to pick up and work with the nightly integration builds. This puts a premium on keeping HEAD viable at all time, and requires disciple from all committers to ensure that the bug fixes and approved feature work they release to HEAD do not destabilize any of these integration builds. This is the one area where we've become complacent and dropped our guard for some of our recent integration and milestone builds. We will be depending on the committers to tame their desire to fix as many serious bugs as quickly as possible with the reality that we only have a limited amount of time before 3.1 goes out the door, so we need the right fixes to the right problems. There will be time for further fixing after M7, so no one should feel that M7 is the last chance to get the fix in. On Tuesday and Wednesday May 10-12, we do a full 2-day all-hands test pass to ensure that the new feature in M7 are up to snuff, and to ferret out any serious bugs lurking anywhere. This is one more day of testing that we usually do for our milestones, and gives us a good chance to shake the tree hard to see what falls out. On Thursday May 12 we would fix any bugs that would reflect poorly on M7, but likely defer until after M7 fixing long-standing problems that had never come to light before. We would put together a M7 new and noteworthy as usual describing all the interesting features that were added since M6. After M7 is out the door, we have 2 full weeks of bug fixing, performance, and special polish before RC1 (Fri. May 27). RC1 is followed by 2 day test pass (May 31-June 1), followed by bug fixing until RC2 2 weeks later (Fri. June 10). RC2 is followed by 2 day test pass (June 13-14), followed by bug fixing until RC3 exactly 1 week later (Fri. June 17). RC3 is followed by 1 day test pass (June 20), followed by surgical bug fixing until RC4 (Fri. June 24). RC4 will be promoted to 3.1 release by Thursday of the next week as scheduled (and exactly 1 year since we shipped 3.0). That adds up to a total of 7 days of testing until we're done. Sounds like light work, given it's spread over 2 months. And especially when compared to the number of bugs that we'll fix between now and then. A draft endgame plan with all the dates is posted here: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/eclipse-project-home/plans/3_1/freeze_plan_3_1.html I've spoken with several of the component leads and know right now of only 2 that have feature work that will not be completed this week. I'll contact the rest of you tomorrow to find out if there are any other teams in this position. Please send any comments or suggestions to this list. ---jim _______________________________________________ platform-releng-dev mailing list platform-releng-dev at eclipse.org https://dev.eclipse.org/mailman/listinfo/platform-releng-dev ----- End forwarded message -----