[classlib] Really trivial comment about exception messages
While checking and applying some of Ilya's patches for internationalisation, I noticed that there were quite a few messages that end with a fullstop. Aside from the inconsistency (which unfortunately always seems to irritate me), it occurs to me that we will end up with stack traces that read like: IllegalArgumentException: position less than zero. at blah(blah.java:101) So, unless anyone objects, can we avoid putting fullstops on the end of exception messages. Thanks, Mark.
Re: [security][testing] 2 tests failed today
On 1 November 2006 at 13:39, Mark Hindess <[EMAIL PROTECTED]> wrote: > > Fixed in r469902. Turns out the exec was putting double quotes around > the classpath argument (which might make sense if it was going to a > shell) but it doesn't for an exec syscall. This resulted in classes > being search for in the non-existent directory: > > "/path/to/modules/luni/bin/test > > rather than: > > /path/to/modules/luni/bin/test > > Regards, > Mark - confused as to why it didn't also fail on windows Oops. Tim mentioned that my fixed breaks things on windows. I've checked in a better fix that I hope should be more well-defined on all platforms. That is, pass the arguments to Runtime.exec as an array not a string. Aside: My tests show that the behaviour we saw with the quotes in the string being passed directly through to the execve syscall is consistent with the RI. Regards, Mark. > On 1 November 2006 at 10:37, Tim Ellison <[EMAIL PROTECTED]> wrote: > > Boris Kuznetsov wrote: > > > The tests use tests.support.Support_Exec.execJava2() to perform > > > testing on other JVM. This method uses Runtime.getRuntime().exec() to > > > run command. You can see command (it looks like java -cp > > > ) in the test's System.out. It woks OK on Win, but produces > > > NoClassDefFoundError on linux. > > > Note, the command woks OK in linux sh also. > > > > Yes, I don't think it is the tests for HARMONY-1674 per se that are > > failing, but they are exposing a problem in the exec -- which is why I > > haven't rolled back that commit. > > > > I'll keep looking at it, let me know if you see the problem. > > > > Regards, > > Tim > > > > -- > > > > Tim Ellison ([EMAIL PROTECTED]) > > >
Re: [security][testing] 2 tests failed today
Fixed in r469902. Turns out the exec was putting double quotes around the classpath argument (which might make sense if it was going to a shell) but it doesn't for an exec syscall. This resulted in classes being search for in the non-existent directory: "/path/to/modules/luni/bin/test rather than: /path/to/modules/luni/bin/test Regards, Mark - confused as to why it didn't also fail on windows On 1 November 2006 at 10:37, Tim Ellison <[EMAIL PROTECTED]> wrote: > Boris Kuznetsov wrote: > > The tests use tests.support.Support_Exec.execJava2() to perform > > testing on other JVM. This method uses Runtime.getRuntime().exec() to > > run command. You can see command (it looks like java -cp > > ) in the test's System.out. It woks OK on Win, but produces > > NoClassDefFoundError on linux. > > Note, the command woks OK in linux sh also. > > Yes, I don't think it is the tests for HARMONY-1674 per se that are > failing, but they are exposing a problem in the exec -- which is why I > haven't rolled back that commit. > > I'll keep looking at it, let me know if you see the problem. > > Regards, > Tim > > -- > > Tim Ellison ([EMAIL PROTECTED]) >
Re: [general] creation of "jdktools"
On 31 October 2006 at 7:24, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > > > Alexei Zakharov wrote: > > Take me for example. I will be most likely misleaded with "build" > > since the majority of projects I've seen in my life were using "build" > > or "build." for storing build artifacts (as Mark said). I > > agree it is logically to call it "build". But "make" is logical too. > > "ant" or "ant.scripts" also sound not so bad. Why not to choose the > > less confusing name? > > (I believe you meant "make" or "make.") > > What projects? Java projects? ? Apache Jakarta Commons Collections uses build/classes and build/tests for artifacts... just like classlib does. -Mark. > > > > With best regards, > > > > 2006/10/31, Geir Magnusson Jr. <[EMAIL PROTECTED]>: > >> Why? I'm really curious about this. We "build" the project, using the > >> "build.xml" file with Ant. > >> > >> > >> Ilya Neverov wrote: > >> > I would prefer to keep the current name "make" for directories related > >> > to build system. For me it looks natural; at least it looks less > >> > misleading than "build" :) > >> > > >> > -Ilya > >> > > >> > On 10/31/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > >> >> > >> >> On 30 October 2006 at 18:38, "Geir Magnusson Jr." <[EMAIL PROTECTED]> > >> wrote: > >> >> > > >> >> > Ilya Neverov wrote: > >> >> > > Hello, > >> >> > > > >> >> > > I want to gather opinions about structure of the "jdktools" > >> >> component. > >> >> > > > >> >> > > I'm going to create scripts for moving tools' sources from > >> classlib/ > >> >> > > to top-level directory jdktools/ and to prepare patches for build > >> >> > > system for building tools from new place. > >> >> > > >> >> > Cool > >> >> > > >> >> > > > >> >> > > I think the following structure will be appropriate for future > >> >> > > evolution of the jdktools: > >> >> > > > >> >> > > jdktools/trunk/ > >> >> > > build.xml > >> >> > > make/ > >> >> > > >> >> > Can we stop persisting this mistake? Please call it "build" :) > >> >> > >> >> And call 'build' something else like 'target'? > >> >> > >> >> I'm not actually sure calling it build is a good idea because a number > >> >> of common projects use build to contain built artifacts. What is your > >> >> objection to 'make'? > >> >> > >> >> > > doc/ > >> >> > > modules/ > >> >> > > jre/ # keytool, tool launcher go > >> here > >> >> > > build.xml # classes go to > >> >> jdk/jre/lib/tools.jar > >> >> > > make/ > >> >> > > src/ > >> >> > > jdk/ # javac, jarsigner go here > >> >> > > build.xml # classes go to > >> jdk/lib/tools.jar > >> >> > > make/ > >> >> > > src/ > >> >> > > jdwp/# separate module for large > >> >> component > >> >> > > build.xml > >> >> > > make/ > >> >> > > src/ > >> >> > > >> >> > Only comment is that we might want to pull the launcher out to be a > >> >> > peer. Otherwise, I like it. > >> >> > >> >> I'd be a little tempted by that idea too. > >> >> > >> >> > > > >> >> > > Assumptions which look reasonable for jdktool's build subsystem: > >> >> > > > >> >>
Re: [general] creation of "jdktools"
On 30 October 2006 at 18:38, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > > Ilya Neverov wrote: > > Hello, > > > > I want to gather opinions about structure of the "jdktools" component. > > > > I'm going to create scripts for moving tools' sources from classlib/ > > to top-level directory jdktools/ and to prepare patches for build > > system for building tools from new place. > > Cool > > > > > I think the following structure will be appropriate for future > > evolution of the jdktools: > > > > jdktools/trunk/ > > build.xml > > make/ > > Can we stop persisting this mistake? Please call it "build" :) And call 'build' something else like 'target'? I'm not actually sure calling it build is a good idea because a number of common projects use build to contain built artifacts. What is your objection to 'make'? > > doc/ > > modules/ > > jre/ # keytool, tool launcher go here > > build.xml # classes go to jdk/jre/lib/tools.jar > > make/ > > src/ > > jdk/ # javac, jarsigner go here > > build.xml # classes go to jdk/lib/tools.jar > > make/ > > src/ > > jdwp/# separate module for large component > > build.xml > > make/ > > src/ > > Only comment is that we might want to pull the launcher out to be a > peer. Otherwise, I like it. I'd be a little tempted by that idea too. > > > > Assumptions which look reasonable for jdktool's build subsystem: > > > > 1) it works in presence of built classlib (as HDK binaries or as a > > result of classlib phase of overall build); > > yes - think of the same trick we do w/ DRLVM to "reach over" to find it. > I'd imagine the federated build to then have : > > trunk/ >working_classlib/ >working_vm/ >working_jdktools/ > > > 2) the 'jre' module is always built before building 'jdk' to provide > > generic tool launcher and the jre/lib/tools.jar. Probably it will be > > easy to obtain these items from HDK. > > That's one reason why I'd pull the launcher out to it's own module > > > > > I'm rather newbie in the Harmony build system so your thoughts will be > > very helpful. > > Ant and make will be your friends here :) Note that you will have > native issues (because of the launcher), so please track the way that > classlib does this wrt platforms to start, and if you find things that > work better, suggest it. Mark and Ollie are wizards here. > > I'd suggest starting out to accommodate (windows,linux) X (x86, x86_64) > if you grok what I mean, and do it in a way that it will be trivial to > add other OSs or processor architectures (IPF, for example). > This might be a good place to figure out how this should work going > forward for harmony, rather than experimenting in classlib. +1 > > > > Thank you > > No, thank you :) +1 Regards, Mark. > geir > > > -Ilya > > > > > > On 10/19/06, Ilya Neverov <[EMAIL PROTECTED]> wrote: > >> Hi Geir, > >> > >> Looks like that creating the "jdktools" source tree and build was > >> shaded by other tasks. I can help with preparing and checking updates > >> in the build system. Please let me know what needs to do in this area > >> (besides svn commits) to complete the task. > >> > >> I'm especially interested in completing the move to "jdktools" > >> structure since there will be a home for the JDWP code, which has beed > >> voted but still resides in JIRA. Working with SVN will be easier. > >> > >> Thanks. > >> -Ilya > >> > >> On 10/4/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > >> > yep, that's the plan. And once we have that, we can simplify the > >> > launcher as well... > >> > > >> > Tim Ellison wrote: > >> > > +1 for creating a jdktools directory. The dependency on the classlib > >> > > launcher should be relatively light if we go with a simple tools > >> > > launcher that rewrites the tool invocation into a generic launcher > >> > > invocation. You may recall the idea was discussed a while ago. > >> > > > >> > > So, for example, > >> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar > >> > > is rewritten to > >> > > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M > >> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar > >> > > > >> > > and so on. > >> > > > >> > > Regards, > >> > > Tim > >> > > > >> > > Geir Magnusson Jr. wrote: > >> > >> Geir Magnusson Jr. wrote: > >> > >>> Now that we have javac, javah, javap (if Tim votes ;) and > >> keytool, I'd > >> > >>> like to organize these and add them to the next snapshot. > >> > >> My bad - the javap isn't being voted on yet. I was thinking of > >> the jdwp > >> > >> vote... sorry > >> > >> > >> > >>> So I propose addin
Re: [general] creation of "jdktools"
On 30 October 2006 at 23:55, "Ilya Neverov" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I want to gather opinions about structure of the "jdktools" component.
>
> I'm going to create scripts for moving tools' sources from classlib/
> to top-level directory jdktools/ and to prepare patches for build
> system for building tools from new place.
Excellent!
Some general comments (that others might disagree with?):
1) Don't copy the classlib build practice of using separate build.xml
files from java, natives and documentation. Or at least, if you do use
import rather than antcall. Why? Well, besides being more efficient,
importing allows ant dependency resolution to work across all build
files.
2) Consider using subant for the modules, you may need to make it two
stages[0] ... first do modules/jre using a trivial subant task, then a
second subant task to do everything but modules/jre.
3) I recently added the build/ant/properties.xml to the hdk which
contains platform definitions, build/make also contains native code
defines. You should try to use these if possible. (If there are other
things I've missed let me know - this was just the first thing that came
up in my recent abortive attempt to do item 4.)
4) I thought the easiest way to start the tool launcher might be
to just copy (svn copy even) the current launcher. At least we'd
have something that worked. It would then be possible to hack the
java launcher to remove the tools specific code and the tool launcher
could be hacked to remove the vm initialisation code - it should be
replaced with exec("java", ...).
> I think the following structure will be appropriate for future
> evolution of the jdktools:
>
> jdktools/trunk/
>build.xml
>make/
>doc/
>modules/
>jre/ # keytool, tool launcher go here
> build.xml # classes go to jdk/jre/lib/tools.jar
> make/
> src/
>jdk/ # javac, jarsigner go here
> build.xml # classes go to jdk/lib/tools.jar
> make/
> src/
>jdwp/# separate module for large component
> build.xml
> make/
> src/
Looks reasonable.
> Assumptions which look reasonable for jdktool's build subsystem:
>
> 1) it works in presence of built classlib (as HDK binaries or as a
> result of classlib phase of overall build);
I think it should be an HDK (with hy.hdk defaulting to
"../classlib/deploy" but with a user properties file to override it).
Perhaps something like:
> 2) the 'jre' module is always built before building 'jdk' to provide
> generic tool launcher and the jre/lib/tools.jar. Probably it will be
> easy to obtain these items from HDK.
Hmm... Geir was not in favour of updating the hdk directly IIRC?
Perhaps consider a separate deploy tree to begin with.
> I'm rather newbie in the Harmony build system so your thoughts will be
> very helpful.
Fresh eyes are great. It's often useful to have to justify/describe
why/how we are doing things - it makes us think again about our
decisions.
Regards,
Mark.
[0] Statements like this usually trigger Matt Benson to appear on the
list telling me the neat trick for doing this elegantly. ;-)
Re: [classlib][tests] Junit best practice
On 26 October 2006 at 16:33, "Alexei Zakharov" <[EMAIL PROTECTED]> wrote: > > BTW - the script does run on Windows with ActiveState's Perl runtime. > > > > Number of Issues by module > > > > 45 beans > > I've also checked it on WinXP + cygwin + perl v5.8.7. Also works good > (HARMONY-1976). Thanks Alexei. Your patch illustrates an issue that I forgot to mention... Another good reason not to automatically fix the "faults" raised by my script is that they are often indications that there are other similar but not so easily mechanically-spotted problems with the tests. For instance, you might have code like (this is a terrible example, sorry): assertEquals(actual, 1); assertEquals(actual, expected); My script will only spot the former because it is an obvious constant, but a human-being would (hopefully) spot the second when they go to fix the first one. Alexei has done a great job of reviewing the tests and fixing the non-obvious issues. I especially like the fact that fixing the exception handling shortens many tests and makes them much more readable. Alexei, thanks for taking the time to do this. Regards, Mark. > 2006/10/26, Nathan Beyer <[EMAIL PROTECTED]>: > > BTW - the script does run on Windows with ActiveState's Perl runtime. > > > > -Nathatn > > > > On 10/25/06, Richard Liang <[EMAIL PROTECTED]> wrote: > > > Awesome. I just plan to review our junit tests, now it seems your tool > > > has done what I want ;-) > > > > > > I highly recommend we read this article "JUnit best practices"[1] in java > world. > > > > > > [1] http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit.html > > > > > > On 10/25/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > > > > > > Earlier in the year we discussed junit best practice. For example, > > > > making sure assertEquals calls have the expected and actual arguments i > n > > > > the correct order to avoid getting confusing failure messages. > > > > > > > > Robert posted a script a week or so ago, to look for some of junit > > > > issues but it didn't handle asserts that spanned multiple lines so, > > > > unfortunately, it was missing the majority of them. I had a script tha > t > > > > I'd thrown together one evening that would handle multi-line asserts bu > t > > > > annoyingly (because it read the whole file at once) couldn't report the > > > > line number of the potential issue as Robert's script did. > > > > > > > > Inspired by Robert's post, I looked at my script again. I've now fixed > > > > it to report line numbers, added a little bit of documentation and > > > > attached it to a JIRA: > > > > > > > > https://issues.apache.org/jira/browse/HARMONY-1960 > > > > > > > > It finds quite a lot of potential problems (I've appended a summary of > > > > the findings below). (There will be a few false positives but hopefull > y > > > > not too many.) It would be nice to fix these issues - I fixed several > > > > hundred while testing the script - but more importantly we should make > > > > sure we avoid adding any new issues. > > > > > > > > Improvements to the script would be most welcome. > > > > > > > > Regards, > > > > Mark. > > > > > > > > Types of issue identified > > > > > > > > 4949 should possibly use assertEquals > > > > 815 actual may be a constant > > > > 437 consider using separate asserts for each '&&' component > > > > 330 exception may be left to junit > > > > 135 actual *may* be a constant > > > > 48 should be fail (always false) > > > > 40 should be fail (always true) > > > > 20 expected is null - should use assertNull > > > > 12 consider using separate asserts for each '||' component > > > >8 expected is false - should use assertFalse > > > >7 expected is true - should use assertTrue > > > >1 should use assertNotNull > > > > > > > > > > > > Number of Issues by module > > > > > > > > 1907 luni > > > > 1440 swing > > > > 699 math > > > > 611 security > > > > 335 text > > > > 322 awt > > > > 222 sound > > > > 186 nio > > > > 178 jndi > > > > 123 archive > > > > 118 auth > > > > 117 crypto > > > > 116 logging > > > > 91 nio_char > > > > 87 print > > > > 74 regex > > > > 68 concurrent > > > > 45 beans > > > > 41 x-net > > > > 21 sql > > > >1 rmi > > > -- > Alexei Zakharov, > Intel Enterprise Solutions Software Division >
[classlib][swing] test failure on linux JSpinnerTest
Anyone else seeing: testDateEditor_formatterError N/A java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(System.java:327) at java.lang.System.arraycopy(System.java:237) at com.ibm.icu.text.DigitList.set(DigitList.java:551) at com.ibm.icu.text.DecimalFormat.format(DecimalFormat.java:96) at java.text.DecimalFormat.format(DecimalFormat.java:233) at java.text.NumberFormat.format(NumberFormat.java:183) at java.text.DecimalFormat.format(DecimalFormat.java:264) at java.text.SimpleDateFormat.appendNumber(SimpleDateFormat.java:321) at java.text.SimpleDateFormat.append(SimpleDateFormat.java:249) at java.text.SimpleDateFormat.formatImpl(SimpleDateFormat.java:630) at java.text.SimpleDateFormat.format(SimpleDateFormat.java:481) at java.text.DateFormat.format(DateFormat.java:233) at java.text.Format.format(Format.java:115) at javax.swing.text.InternationalFormatter.valueToString(InternationalFormatter.java:22) at javax.swing.JFormattedTextField.revertValue(JFormattedTextField.java:518) at javax.swing.JFormattedTextField.setValue(JFormattedTextField.java:479) at javax.swing.JSpinner$DefaultEditor.(JSpinner.java:181) at javax.swing.JSpinner$DateEditor.(JSpinner.java:278) at javax.swing.JSpinnerTest.testDateEditor_formatter(JSpinnerTest.java:356) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) at javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:117) at javax.swing.BasicSwingTestCase.runBareImpl(BasicSwingTestCase.java:122) at javax.swing.BasicSwingTestCase$1.run(BasicSwingTestCase.java:136) at java.lang.Thread.run(Thread.java:872) Regards, Mark.
Re: [classlib][tests] Junit best practice
On 26 October 2006 at 19:16, "Tony Wu" <[EMAIL PROTECTED]> wrote:
> I have scratched out the stand alone rules,
>
> should use assertNull, assertEquals\s*\((.*,\s*null\s*|\s*null\s*,.*)\)\s*;
> should use assertFalse, assertEquals\s*\((.*,\s*false\s*|\s*false\s*,.*)\)\s*
> ;
> should use assertTrue, assertEquals\s*\((.*,\s*true\s*|\s*true\s*,.*)\)\s*;
> last argument should not be a constant,
> assertEquals\s*\(.*,\s*("[^"]*"|'[^']'|[+-]?\d+[0-9a-fA-FLlPp]*|[A-Z_]*)\s*\)
> \s*;
> always true/false, assert(False|True)\s*\(\s*(false|true)\s*\)\s*;
> multiple assertion, assertTrue\s*\(.*\&\&.*\)\s*;
> multiple assertion, assertFalse\s*\(.*\|\|.*\)\s*;
> should use assertNull, assertTrue\s*\((.*==\s*null\s*|\s*null\s*==.*)\)\s*;
> should use assertTrue, assertTrue\s*\((.*==\s*true\s*|\s*true\s*==.*)\)\s*;
> should use assertFalse, assertTrue\s*\((.*==\s*false\s*|\s*false\s*==.*)\)\s*
> ;
> should use assertNotNull, assertTrue\s*\((.*!=\s*null\s*|\s*null\s*!=.*)\)\s*
> ;
> should use assertFalse, assertTrue\s*\((.*!=\s*true\s*|\s*true\s*!=.*)\)\s*;
> should use assertTrue, assertTrue\s*\((.*!=\s*false\s*|\s*false\s*!=.*)\)\s*;
> should use assertFalse, assertTrue\s*\(\s*!.*\)\s*;
> should use assertFalse, assertTrue\s*\("[^"]*"\s*,\s*!.*\)\s*;
> should use assertNotNull, assertFalse\s*\((.*==\s*null\s*|\s*null\s*==.*)\)\s
> *;
> should use assertFalse, assertFalse\s*\((.*!=\s*true\s*|\s*true\s*!=.*)\)\s*;
> should use assertTrue, assertFalse\s*\((.*!=\s*false\s*|\s*false\s*!=.*)\)\s*
> ;
> should use assertNull, assertFalse\s*\((.*!=\s*null\s*|\s*null\s*!=.*)\)\s*;
> should use assertFalse, assertFalse\s*\((.*==\s*true\s*|\s*true\s*==.*)\)\s*;
> should use assertTrue, assertFalse\s*\((.*==\s*false\s*|\s*false\s*==.*)\)\s*
> ;
> should use assertEquals, assertTrue\s*\(.*==.*\)\s*;
> should use assertEquals, assertTrue\s*\(.*\.euqals.*\)\s*;
There's a typo in that last one. But be careful with these. For
example, the second last rule will match things like:
modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java:
assertTrue("Wrong bytes", in.read() == 6 && in.read() == 7);
which is why the regular expressions in my script are a little stricter
(that is not using .* but a character class to avoid catching complex
cases).
> any comments?
If you fix any automatically, please check them over manual unless you
are really, really sure the fixes are not breaking anything.
Regards,
Mark.
Re: [classlib][awt] dependency cleanup and potential build breakage
I've checked these changes in now. Linux developers should be able to
fix the dependencies with something like:
for f in depends/libs/build/*/*.ia32 ;do mv $f ${f%.ia32}.linux.x86;done
for f in depends/libs/build/*/*.ipf ;do mv $f ${f%.ipf}.linux.x86_64;done
Regards,
Mark.
On 25 October 2006 at 13:54, "Mark Hindess" <[EMAIL PROTECTED]> wrote:
>
> Currently there is a quick hack in make/depends.xml because the awt
> dependencies have extensions that use a different convention for
> architecture names than the one used in the rest of classlib.
>
> I'm going to fix the README, build.xml files, and makefiles to use the
> standard harmony define for *platform* (rather than just architecture[0])
> This means that your build might break. Renaming the libs (*.ia32
> => *.linux.x86, *.ipf => *.linux.x86_64) should fix the problem.
> (Re-running fetch-depends should also fix it if you are using symlinks
> to system resources although it will leave a few unused symlinks
> behind.)
>
> I'm *not* going to fix the windows .lib file to use windows.x86 since
> this would involve creating a new tar in geir's people.apache.org web
> space to work smoothly. But we probably should do this at some point in
> the not to distant future.
>
> Any objections?
>
> Regards,
> Mark.
>
> [0] So we don't have to break it all again when we have macosx.x86 which
> wont work with the linux.x86 library file.
>
Re: [classlib][tests] Junit best practice
On 25 October 2006 at 18:38, "Denis Kishenko" <[EMAIL PROTECTED]> wrote: > > Mark, I have just tried your tool. It's really helpful, thanks a lot! > > It's so pitty that script doesn't fix issues by itself =) It could (and I have been known to use scripts to fix things) but as Nathan recently pointed out. It's not always a good idea. Specifically, my tool is not perfect at identifying the different types of assertEquals calls (e.g. the variants for double where the last argument might look like a constant but isn't the expected value but a delta). It does a reasonable job but without implementing a full parser it's never going to be 100% reliable. I did use a script - a one-off on the command line - to fix a significant number of assertEquals calls to use assertTrue/assertFalse/assertNull a week or so ago, but I did also scan the diff to see if it looked sane. Scanning the diff was almost as tedious as fixing them manually. ;-( Regards, Mark. > 2006/10/25, Geir Magnusson Jr. <[EMAIL PROTECTED]>: > > > > > > Mark Hindess wrote: > > > On 25 October 2006 at 7:41, "Geir Magnusson Jr." <[EMAIL PROTECTED]> > > > wrote: > > >> Cool - but why not just put into SVN somewhere? > > > > > > Okay. classlib/trunk/support/tools/bin perhaps? > > > > Sure. Whatever you feel is best. I have no strong opinion. We do have > > junit tests in DRLVM too, but we can "reach over" and use from there for > > now. > > > > geir > > > > > > > > -Mark. > > > > > >> either in enhanced/tools or classlib/trunk somewhere where it can be > > >> invoked as an option by people from ant (so that we can wire it into the > > >> CI system...) > > >> > > >> geir > > >> > > >> > > >> Mark Hindess wrote: > > >>> Earlier in the year we discussed junit best practice. For example, > > >>> making sure assertEquals calls have the expected and actual arguments i > n > > >>> the correct order to avoid getting confusing failure messages. > > >>> > > >>> Robert posted a script a week or so ago, to look for some of junit > > >>> issues but it didn't handle asserts that spanned multiple lines so, > > >>> unfortunately, it was missing the majority of them. I had a script tha > t > > >>> I'd thrown together one evening that would handle multi-line asserts bu > t > > >>> annoyingly (because it read the whole file at once) couldn't report the > > >>> line number of the potential issue as Robert's script did. > > >>> > > >>> Inspired by Robert's post, I looked at my script again. I've now fixed > > >>> it to report line numbers, added a little bit of documentation and > > >>> attached it to a JIRA: > > >>> > > >>> https://issues.apache.org/jira/browse/HARMONY-1960 > > >>> > > >>> It finds quite a lot of potential problems (I've appended a summary of > > >>> the findings below). (There will be a few false positives but hopefull > y > > >>> not too many.) It would be nice to fix these issues - I fixed several > > >>> hundred while testing the script - but more importantly we should make > > >>> sure we avoid adding any new issues. > > >>> > > >>> Improvements to the script would be most welcome. > > >>> > > >>> Regards, > > >>> Mark. > > >>> > > >>> Types of issue identified > > >>> > > >>> 4949 should possibly use assertEquals > > >>> 815 actual may be a constant > > >>> 437 consider using separate asserts for each '&&' component > > >>> 330 exception may be left to junit > > >>> 135 actual *may* be a constant > > >>> 48 should be fail (always false) > > >>> 40 should be fail (always true) > > >>> 20 expected is null - should use assertNull > > >>> 12 consider using separate asserts for each '||' component > > >>>8 expected is false - should use assertFalse > > >>>7 expected is true - should use assertTrue > > >>>1 should use assertNotNull > > >>> > > >>> > > >>> Number of Issues by module > > >>> > > >>> 1907 luni > > >>> 1440 swing > > >>> 699 math > > >>> 611 security > > >>> 335 text > > >>> 322 awt > > >>> 222 sound > > >>> 186 nio > > >>> 178 jndi > > >>> 123 archive > > >>> 118 auth > > >>> 117 crypto > > >>> 116 logging > > >>> 91 nio_char > > >>> 87 print > > >>> 74 regex > > >>> 68 concurrent > > >>> 45 beans > > >>> 41 x-net > > >>> 21 sql > > >>>1 rmi > > >>> > > >>> > > >>> > > >>> > > > > > > > > > > > > > > -- > Denis M. Kishenko > Intel Middleware Products Division >
Re: svn commit: r467634 - in /incubator/harmony/enhanced/classlib/trunk/doc: build.xml vminterface/natives.cfg
Thanks Paulex. I really should have remembered that when I committed that the JIRA to move that code. -Mark. On 25 October 2006 at 13:21, [EMAIL PROTECTED] wrote: > Author: pyang > Date: Wed Oct 25 06:21:53 2006 > New Revision: 467634 > > URL: http://svn.apache.org/viewvc?view=rev&rev=467634 > Log: > Update the portlib document creation script to adapt the relayout that move p > ortlib out of luni > > Modified: > incubator/harmony/enhanced/classlib/trunk/doc/build.xml > incubator/harmony/enhanced/classlib/trunk/doc/vminterface/natives.cfg > > Modified: incubator/harmony/enhanced/classlib/trunk/doc/build.xml > URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/d > oc/build.xml?view=diff&rev=467634&r1=467633&r2=467634 > = > = > --- incubator/harmony/enhanced/classlib/trunk/doc/build.xml (original) > +++ incubator/harmony/enhanced/classlib/trunk/doc/build.xml Wed Oct 25 06:21: > 53 2006 > @@ -88,6 +88,7 @@ > > > > + > > > > > Modified: incubator/harmony/enhanced/classlib/trunk/doc/vminterface/natives.c > fg > URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/d > oc/vminterface/natives.cfg?view=diff&rev=467634&r1=467633&r2=467634 > = > = > --- incubator/harmony/enhanced/classlib/trunk/doc/vminterface/natives.cfg (or > iginal) > +++ incubator/harmony/enhanced/classlib/trunk/doc/vminterface/natives.cfg Wed > Oct 25 06:21:53 2006 > @@ -438,16 +438,18 @@ > "$(HARMONY_DOC_DIR)/vminterface" \ > "$(HARMONY_LUNI_NATIVES_DIR)/vmi/$(HARMONY_TARGET_PLATFORM)" \ > "$(HARMONY_LUNI_NATIVES_DIR)/luni/$(HARMONY_TARGET_PLATFORM)" \ > - "$(HARMONY_LUNI_NATIVES_DIR)/pool/$(HARMONY_TARGET_PLATFORM)" \ > - "$(HARMONY_LUNI_NATIVES_DIR)/port/$(HARMONY_TARGET_PLATFORM)" \ > - "$(HARMONY_LUNI_NATIVES_DIR)/thread/$(HARMONY_TARGET_PLATFORM)" > \ > "$(HARMONY_LUNI_NATIVES_DIR)/include/$(HARMONY_TARGET_PLATFORM) > " \ > + "$(HARMONY_PORTLIB_NATIVES_DIR)/pool/$(HARMONY_TARGET_PLATFORM) > " \ > + "$(HARMONY_PORTLIB_NATIVES_DIR)/port/$(HARMONY_TARGET_PLATFORM) > " \ > + "$(HARMONY_PORTLIB_NATIVES_DIR)/thread/$(HARMONY_TARGET_PLATFOR > M)" \ > + "$(HARMONY_PORTLIB_NATIVES_DIR)/include/$(HARMONY_TARGET_PLATFO > RM)" \ > "$(HARMONY_LUNI_NATIVES_DIR)/vmi/shared" \ > "$(HARMONY_LUNI_NATIVES_DIR)/luni/shared" \ > - "$(HARMONY_LUNI_NATIVES_DIR)/pool/shared" \ > - "$(HARMONY_LUNI_NATIVES_DIR)/port/shared" \ > - "$(HARMONY_LUNI_NATIVES_DIR)/thread/shared" \ > "$(HARMONY_LUNI_NATIVES_DIR)/include/shared" \ > + "$(HARMONY_PORTLIB_NATIVES_DIR)/pool/shared" \ > + "$(HARMONY_PORTLIB_NATIVES_DIR)/port/shared" \ > + "$(HARMONY_PORTLIB_NATIVES_DIR)/thread/shared" \ > + "$(HARMONY_PORTLIB_NATIVES_DIR)/include/shared" \ > "$(HARMONY_ARCHIVE_NATIVES_DIR)/zip/$(HARMONY_TARGET_PLATFORM)" > \ > "$(HARMONY_ARCHIVE_NATIVES_DIR)/archive/$(HARMONY_TARGET_PLATFO > RM)" \ > "$(HARMONY_ARCHIVE_NATIVES_DIR)/zip/shared" \ > @@ -975,7 +977,9 @@ > # contain include files that are not input files but should be processed by > # the preprocessor. > > -INCLUDE_PATH = "$(HARMONY_LUNI_NATIVES_DIR)/include/shared" \ > +INCLUDE_PATH = "$(HARMONY_PORTLIB_NATIVES_DIR)/include/shared" \ > + "$(HARMONY_PORTLIB_NATIVES_DIR)/include/$(HARMONY_TARGET_PLATFO > RM)" \ > + "$(HARMONY_LUNI_NATIVES_DIR)/include/shared" \ > "$(HARMONY_LUNI_NATIVES_DIR)/include/$(HARMONY_TARGET_PLATFORM) > " > > # You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard >
Re: [classlib][awt] dependency cleanup and potential build breakage
On 25 October 2006 at 9:04, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > > Mark Hindess wrote: > > Currently there is a quick hack in make/depends.xml because the awt > > dependencies have extensions that use a different convention for > > architecture names than the one used in the rest of classlib. > > > > I'm going to fix the README, build.xml files, and makefiles to use the > > standard harmony define for *platform* (rather than just architecture[0]) > > This means that your build might break. Renaming the libs (*.ia32 > > => *.linux.x86, *.ipf => *.linux.x86_64) should fix the problem. > > (Re-running fetch-depends should also fix it if you are using symlinks > > to system resources although it will leave a few unused symlinks > > behind.) > > > > I'm *not* going to fix the windows .lib file to use windows.x86 since > > this would involve creating a new tar in geir's people.apache.org web > > space to work smoothly. But we probably should do this at some point in > > the not to distant future. > > > > Any objections? > > None, and once people.apache.org comes back from the dead, I'll post > another tarball with a different name and different extensions, and you > can integrate as you see fit. Excellent. Thanks Geir. I'll wait and commit the linux changes in the morning to give others a little time to comment before I break things. Regards, Mark.
[build][federation] building snapshots and releases
Currently, the federation build looks at the revision of the federation tree that you have checked out and checks out the same revision of the classlib and drlvm trees. Since we want releases to be reproducible (i.e. known tags of not only classlib and drlvm but also of the federation code that was used to combine them), then I think it make sense to use a similar mechanism when building from an svn tag. That is, if you check out the federation build from[0]: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/tags/1.0 then the federation build.xml should ensure that it also checks out the 1.0 tag of classlib and drlvm. That is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tags/1.0 and: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/drlvm/tags/1.0 This will need a little tweaking to the federation build.xml and I wanted to be sure this made sense before I started. What do people think? I've started on the source archive for snapshots (though it doesn't work yet[1]). My feeling is that although the federation build.xml in the svn checkout can be used to produce the binary archives - as it was used to produce the current snapshots - that in order to prove the source snapshot works (and to make sure that what we test/release is consistent) we should actually create the binary archives for a "release" from the source archive. That is, the process should be: 1) check out federation build using https://.../tags/1.0 2) ant bundle_src 3) unpack the resulting source archive (or perhaps just cd target/src) 4) build binary archives using contents of the source archive In short, make the binaries using the source archive that you are planning to "release" so that you know the source archive is really complete and works. Does this seem reasonable? Regards, Mark. [0] We don't have a tags directory yet and maybe we might make it under harmony/enchanced/federation rather than in harmony/enchanced but we can fix that later. [1] Currently: ant bundle_src; cd target/src; ant fails on check-depends but: ant bundle_src; cd target/src/working_classlib ; ant check-depends works. I can't see why yet. Perhaps someone will take a look? I can't see why it's any different from the svn tree.
[classlib][awt] dependency cleanup and potential build breakage
Currently there is a quick hack in make/depends.xml because the awt dependencies have extensions that use a different convention for architecture names than the one used in the rest of classlib. I'm going to fix the README, build.xml files, and makefiles to use the standard harmony define for *platform* (rather than just architecture[0]) This means that your build might break. Renaming the libs (*.ia32 => *.linux.x86, *.ipf => *.linux.x86_64) should fix the problem. (Re-running fetch-depends should also fix it if you are using symlinks to system resources although it will leave a few unused symlinks behind.) I'm *not* going to fix the windows .lib file to use windows.x86 since this would involve creating a new tar in geir's people.apache.org web space to work smoothly. But we probably should do this at some point in the not to distant future. Any objections? Regards, Mark. [0] So we don't have to break it all again when we have macosx.x86 which wont work with the linux.x86 library file.
Re: Harmony passes 94% on derby tests.
On 25 October 2006 at 18:36, "Vladimir Ivanov" <[EMAIL PROTECTED]> wrote: > > Excellent! > > I have one more idea: we already have buildtest module. Some time ago we > agreed to extends it by coverage and japi scripts (I hope it happens soon:) > ). May be we extend it one more time and store here some scripts for > automatic run of other-projects unit tests? Seems, in this case we can > easily reproduce tests run and enable new platforms. > > Of cause, we can not cover all application but we can define some list of > 'most important application'. > > Is it OK? I think gump will do this? > PS. The directory structure may be something like that: > > builtest > - trunk > - cc > - coverage > - japi > - application_test > - derby > - ant > - etc > - misc (some other scripts) I had assumed we'd make separate, optional cruisecontrol jobs to perform the coverage/japi/etc reporting. These jobs would depend on the build ant test jobs succeeding. Judging by the structure you suggest, it seems to me that you may anticipate doing it differently? Regards, Mark.
Re: [classlib][tests] Junit best practice
On 25 October 2006 at 7:41, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > > Cool - but why not just put into SVN somewhere? Okay. classlib/trunk/support/tools/bin perhaps? -Mark. > either in enhanced/tools or classlib/trunk somewhere where it can be > invoked as an option by people from ant (so that we can wire it into the > CI system...) > > geir > > > Mark Hindess wrote: > > Earlier in the year we discussed junit best practice. For example, > > making sure assertEquals calls have the expected and actual arguments in > > the correct order to avoid getting confusing failure messages. > > > > Robert posted a script a week or so ago, to look for some of junit > > issues but it didn't handle asserts that spanned multiple lines so, > > unfortunately, it was missing the majority of them. I had a script that > > I'd thrown together one evening that would handle multi-line asserts but > > annoyingly (because it read the whole file at once) couldn't report the > > line number of the potential issue as Robert's script did. > > > > Inspired by Robert's post, I looked at my script again. I've now fixed > > it to report line numbers, added a little bit of documentation and > > attached it to a JIRA: > > > > https://issues.apache.org/jira/browse/HARMONY-1960 > > > > It finds quite a lot of potential problems (I've appended a summary of > > the findings below). (There will be a few false positives but hopefully > > not too many.) It would be nice to fix these issues - I fixed several > > hundred while testing the script - but more importantly we should make > > sure we avoid adding any new issues. > > > > Improvements to the script would be most welcome. > > > > Regards, > > Mark. > > > > Types of issue identified > > > > 4949 should possibly use assertEquals > > 815 actual may be a constant > > 437 consider using separate asserts for each '&&' component > > 330 exception may be left to junit > > 135 actual *may* be a constant > > 48 should be fail (always false) > > 40 should be fail (always true) > > 20 expected is null - should use assertNull > > 12 consider using separate asserts for each '||' component > >8 expected is false - should use assertFalse > >7 expected is true - should use assertTrue > >1 should use assertNotNull > > > > > > Number of Issues by module > > > > 1907 luni > > 1440 swing > > 699 math > > 611 security > > 335 text > > 322 awt > > 222 sound > > 186 nio > > 178 jndi > > 123 archive > > 118 auth > > 117 crypto > > 116 logging > > 91 nio_char > > 87 print > > 74 regex > > 68 concurrent > > 45 beans > > 41 x-net > > 21 sql > >1 rmi > > > > > > > > >
[classlib][tests] Junit best practice
Earlier in the year we discussed junit best practice. For example, making sure assertEquals calls have the expected and actual arguments in the correct order to avoid getting confusing failure messages. Robert posted a script a week or so ago, to look for some of junit issues but it didn't handle asserts that spanned multiple lines so, unfortunately, it was missing the majority of them. I had a script that I'd thrown together one evening that would handle multi-line asserts but annoyingly (because it read the whole file at once) couldn't report the line number of the potential issue as Robert's script did. Inspired by Robert's post, I looked at my script again. I've now fixed it to report line numbers, added a little bit of documentation and attached it to a JIRA: https://issues.apache.org/jira/browse/HARMONY-1960 It finds quite a lot of potential problems (I've appended a summary of the findings below). (There will be a few false positives but hopefully not too many.) It would be nice to fix these issues - I fixed several hundred while testing the script - but more importantly we should make sure we avoid adding any new issues. Improvements to the script would be most welcome. Regards, Mark. Types of issue identified 4949 should possibly use assertEquals 815 actual may be a constant 437 consider using separate asserts for each '&&' component 330 exception may be left to junit 135 actual *may* be a constant 48 should be fail (always false) 40 should be fail (always true) 20 expected is null - should use assertNull 12 consider using separate asserts for each '||' component 8 expected is false - should use assertFalse 7 expected is true - should use assertTrue 1 should use assertNotNull Number of Issues by module 1907 luni 1440 swing 699 math 611 security 335 text 322 awt 222 sound 186 nio 178 jndi 123 archive 118 auth 117 crypto 116 logging 91 nio_char 87 print 74 regex 68 concurrent 45 beans 41 x-net 21 sql 1 rmi
Re: [general] Announcing newest members of the Harmony PPMC
Congrats! -Mark. On 24 October 2006 at 18:41, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > As progress towards our goal of having all committers on the PPMC, the > Harmony PPMC is proud to announce it's newest members : > >Nathan Beyer >Paulex Yang >Weldon Washburn > > Please join us in congratulating them (and then tell them to get back to > work...) :) > > The Harmony PPMC >
Re: [classlib][awt] Revision #465514 broke image decoders.
On 24 October 2006 at 18:25, "Oleg Khaschansky" <[EMAIL PROTECTED]> wrote:
> > > Where are the tests for these decoders? How did you determine that
> > > they no longer worked?
>
> Unfortunately, these classes are not covered with the unit tests.
>
> I was running a simple test application that did something like this:
> Toolkit.getDefaultToolkit().getImage("image.jpg");
> and if failed with a NPE.
That's the start of a unit test, are you going to finish it? ;-)
> > I removed the final modifiers
> At the first glance it seems like the problem doesn't appear any more.
>
> > There were only 3-4 other fields that were finalized. Your email
> > mentioned "a lot of invalid modifications"; what are the other issues,
> > specifically?
> Only final fields. No other issues. But 3-4 in 3 classes - it is alot for me
> :)
But not a lot compared to the number of cleanup changes Nathan has been
busy making!
Regards,
Mark.
> On 10/24/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
> > I removed the final modifiers; this only affected PngDecoder,
> > GifDecoder and JpegDecoder. I missed the comments in the fields of
> > JpegDecoder, that was my mistake.
> >
> > There were only 3-4 other fields that were finalized. Your email
> > mentioned "a lot of invalid modifications"; what are the other issues,
> > specifically?
> >
> > -Nathan
> >
> > On 10/24/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
> > > Where are the tests for these decoders? How did you determine that
> > > they no longer worked?
> > >
> > > I'll remove the final modifiers.
> > >
> > > -Nathan
> > >
> > > On 10/24/06, Oleg Khaschansky <[EMAIL PROTECTED]> wrote:
> > > > Hi,
> > > >
> > > > Rev. 465514 introduced a lot of invalid modifications to the
> > > > GifDecoder, PngDecoder and JpegDecoder. There were a number of fields
> > > > modified or initialized from the native code only, but they were
> > > > redeclared as final, so the decoders doesn't work properly any more.
> > > >
> > > > This revision has the following comment:
> > > >
> > > > Cleanup code
> > > > * Add if/else braces
> > > > * Add missing annotations
> > > > * Add type variables
> > > > * Use foreach loops
> > > > * etc
> > > >
> > > > I'd suggest to roll back this revision and redo the cleanup in the
> > > > more accurate way.
> > > >
> > > > Thanks,
> > > > Oleg
> > > >
> > >
> >
>
Re: [vote] Graduate Apache Harmony podling from the Incubator
+1 -Mark. On 20 October 2006 at 15:30, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > > We're trying something a little different. I think Roy Fielding one > said something along the lines of "when a community gets organized > enough to vote itself out of the Incubator, it's appropriate." > > So to bring the Harmony community and the Incubator community together > for this important event in Harmony's life, I'm calling for a vote on > graduating Harmony here on our own -dev list. The objective is for all > in both the Harmony community and the Incubator community that have an > opinion to vote together, in the same place, and have it "hosted" by the > Harmony podling. > > This is an unconventional way to do this, but I think that it's valid > and could provide one example to the Incubator on how it can work going > forward. > > So, without any further ado : > > [ ] +1 Graduate Apache Harmony from incubation, and let it petition the > board for Top Level Project status > > [ ] 0 No opinion > > [ ] -1 No, don't graduate Harmony. Here's why : > > > This vote will end 72 hours from now + time of Apache mail outage. It > will therefore end on Monday, October 23, at 3:30 PM eastern, + delta > for mail outage. > > Thanks > > geir > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] [general] Incubator graduation update
On 20 October 2006 at 12:52, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
>
> Mark Hindess wrote:
> > On 20 October 2006 at 10:11, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
> >>
> >> Mark Hindess wrote:
> >>> On 20 October 2006 at 9:31, Tim Ellison <[EMAIL PROTECTED]> wrote:
> >>>> FWIW: Below are the results of running RAT on a windows snapshot.
> >>>> For some reason it complained about lack of ASF block comments in
> >>>> DLLs, and proceeded to dump them to the console, so I chopped them out
> >>>> of the report. Looks like mainly missing block comments in emconf
> >>>> files.
> >>>>
> >>>> I suspect that it will be helpful to do this on an HDK snapshot, plus
> >>>> on a source drop (that we don't produce at present, but should IMO).
> >>> I'm looking at modifying the federation build to have a source drop
> >>> target. It looks like doing:
> >>>
> >>> svn export . target/src
> >>>
> >>> and modifying the build.xml to cope with the lack of svn files might
> >>> be a good start. I'll probably take a little more work but I'll get
> >>> something checked in so we have something to work with.
> >> Wait.
> >
> > I don't think I have much choice. It's more likely you'll be waiting
> > for me. ;-) It's not as trivial as it sounds[0] so I'm sure this
> > discussion will be done before I'm ready to check anything in. ;-(
> >
> >> Why not just do a tar/zip on the working_classlib and working_vm with
> >> a filter to keep out the generated stuff?
> >
> > This was my first thought but it didn't take long before I decided I had
> > to think again. I think it is much too error prone. Consider figuring
> > out which .so files are generated/downloaded and which are in svn.
> > Repeat for dll files, jar files, etc. Then keep this up to date. It'd
> > be a full-time job.
>
> A *real* unix hacker would walk the tree looking at .svn/entry files ;)
> In Perl. in less than 20 lines.
;-) It's Friday night so I'll bite...
It'd be a (longish) one-line on unix, perhaps something like:
find . -name 'entries' -print|while read e; do
sed -e '/ name=\"/!d;s:.*name=\":'${e%.svn/entries}':;s/\".*//' <$e; done
but I'd be trickier under Windows (unless we assume everyone has Perl
which even I know is unrealistic).
But I disagree, a *real* hacker would:
a) look for a tool that is meant for the job,
b) look for a tool that is meant for something entirely different but
which happens to do the job very well, or
c) writes it in sh, awk, sed, or Perl
If I always rushed straight to step c) I'd never be able to make a cup
of tea in the morning. (My house is quite automated so Perl can put
the kettle on but can't yet make the tea.)
Regards,
Mark.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r466154 - in /incubator/harmony/standard/classlib/trunk/modules/concurrent/src/main/java/java/util/concurrent: ./ locks/
On 20 October 2006 at 17:21, Tim Ellison <[EMAIL PROTECTED]> wrote: > > Mark, > > I suggest that this is rolled back since it is modifying the > concurrency code in our 'standard' SVN area that we aim to keep in > close sync with Doug's repository. Agreed. I thought about this after doing it then had to make dinner. > Perhaps we can offer the patch to that community, and/or set up local > compiler options to hide the warnings in this module. We'd have to take it out of the global compile to do this later, so I think we should do the former. Denis, how do you feel about doing this? Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][build] svn commit: r466199 - /incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
Excellent! That should deal with those odd compile errors that people were seeing that went away if they did a rebuild. -Mark. On 20 October 2006 at 16:53, [EMAIL PROTECTED] wrote: > Author: tellison > Date: Fri Oct 20 09:53:49 2006 > New Revision: 466199 > > URL: http://svn.apache.org/viewvc?view=rev&rev=466199 > Log: > Global compile should not pick up older class files from the classpath, but r > ely on the latest versions from source. > > Modified: > incubator/harmony/enhanced/classlib/trunk/make/build-java.xml > > Modified: incubator/harmony/enhanced/classlib/trunk/make/build-java.xml > URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m > ake/build-java.xml?view=diff&rev=466199&r1=466198&r2=466199 > = > = > --- incubator/harmony/enhanced/classlib/trunk/make/build-java.xml (original) > +++ incubator/harmony/enhanced/classlib/trunk/make/build-java.xml Fri Oct 20 > 09:53:49 2006 > @@ -179,7 +179,7 @@ > > > > - > + > > > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Incubator graduation update
On 20 October 2006 at 10:11, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > > > Mark Hindess wrote: > > On 20 October 2006 at 9:31, Tim Ellison <[EMAIL PROTECTED]> wrote: > >> FWIW: Below are the results of running RAT on a windows snapshot. > >> For some reason it complained about lack of ASF block comments in > >> DLLs, and proceeded to dump them to the console, so I chopped them out > >> of the report. Looks like mainly missing block comments in emconf > >> files. > >> > >> I suspect that it will be helpful to do this on an HDK snapshot, plus > >> on a source drop (that we don't produce at present, but should IMO). > > > > I'm looking at modifying the federation build to have a source drop > > target. It looks like doing: > > > > svn export . target/src > > > > and modifying the build.xml to cope with the lack of svn files might > > be a good start. I'll probably take a little more work but I'll get > > something checked in so we have something to work with. > > Wait. I don't think I have much choice. It's more likely you'll be waiting for me. ;-) It's not as trivial as it sounds[0] so I'm sure this discussion will be done before I'm ready to check anything in. ;-( > Why not just do a tar/zip on the working_classlib and working_vm with > a filter to keep out the generated stuff? This was my first thought but it didn't take long before I decided I had to think again. I think it is much too error prone. Consider figuring out which .so files are generated/downloaded and which are in svn. Repeat for dll files, jar files, etc. Then keep this up to date. It'd be a full-time job. svn export does just the right thing. It takes only the stuff you get from svn but without the .svn files. This seems much less likely to turn around and bite us. (Though even this isn't without issues.) Regards, Mark. [0] not as trivial as I was expecting that's for sure - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] How to debug the drlvm with gdb?
On 20 October 2006 at 16:34, Egor Pasko <[EMAIL PROTECTED]> wrote: > On the 0x208 day of Apache Harmony Tonny Lau wrote: > > Hi, > > > > I checked out the latest drlvm, and failed to set breakpoint when I used > > gdb. It seems the > > "harmony/enhanced/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/java" > > is copied from "harmony/enhanced/classlib/trunk/deploy/jdk/jre/bin/java", > > i.e., it is not a debug version. Does anyone know how to debug it? Thanks! > > Oh! should be on the site!! some day .. some day .. > > Yes, it's the launcher. It is taken from classlib (which is not built > in debug mode even if DRLVM is built in debug (=default)). If you want > to build the launcher in debug mode, change: > working_classlib/depends/build/makefile.include > (put -O0 -g instead of -O1) > > pretty, huh? :) pretty ugly. ;-) I think https://issues.apache.org/jira/browse/HARMONY-803 was supposed to make it less ugly but it was linux only and needs a windows patch to make it suitable for integration. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Incubator graduation update
On 20 October 2006 at 9:31, Tim Ellison <[EMAIL PROTECTED]> wrote: > FWIW: Below are the results of running RAT on a windows snapshot. > For some reason it complained about lack of ASF block comments in > DLLs, and proceeded to dump them to the console, so I chopped them out > of the report. Looks like mainly missing block comments in emconf > files. > > I suspect that it will be helpful to do this on an HDK snapshot, plus > on a source drop (that we don't produce at present, but should IMO). I'm looking at modifying the federation build to have a source drop target. It looks like doing: svn export . target/src and modifying the build.xml to cope with the lack of svn files might be a good start. I'll probably take a little more work but I'll get something checked in so we have something to work with. -Mark. P.S. Geir, can we move https://svn.apache.org/repos/asf/incubator/harmony/enhanced/trunk/sandbox out of the federation trunk so the svn export above doesn't copy it? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][swing][test] Excluded tests clean up
On 20 October 2006 at 11:31, "Ivanov, Alexey A" <[EMAIL PROTECTED]> wrote: > Hello, > > I am working to clean up the excluded list and to make all the tests > run-able without failures. > I've created several JIRA issues. > > https://issues.apache.org/jira/browse/HARMONY-1825 > https://issues.apache.org/jira/browse/HARMONY-1866 > https://issues.apache.org/jira/browse/HARMONY-1910 Thanks for looking at these excluded tests. I've taken a look and added some comments about the unexcluded tests that still fail for me on linux. > And https://issues.apache.org/jira/browse/HARMONY-1892 to make all > Windows users happier. :) I'll leave that to a committer who can reproduce the problem. > Can anyone look at them and apply patches to make creation of patches > to build.xml easier and less reject-prone? Don't worry too much about the rejects on removal of exclude lines from build.xml it's really pretty trivial to see what is intend and manually remove the required lines. (Feel free to worry about more complicated rejects in code though - committers like an easy life. ;-) Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-1813) [classlib][awt][test] java.awt test resources are located in wrong place
Denis, Unfortunately, I missed that you'd uploaded these and sadly I get lots of rejects from the new patch now. I'm still taking a look but a new patch would be helpful. I have now assigned the JIRA to myself so I shouldn't miss any changes to it. Regards, Mark. On 18 October 2006 at 17:19, "Denis Kishenko" <[EMAIL PROTECTED]> wrote: > Mark, I have updated patch as you suggested week ago. Did you try it? > > 2006/10/10, Mark Hindess <[EMAIL PROTECTED]>: > > > > On 10 October 2006 at 19:00, "Denis Kishenko" <[EMAIL PROTECTED]> wrote: > > > Hi committers > > > > > > Could someone look at this issue. Because I am going to make another > > > fix which is depend on this patch. > > > > The diff looks like it contains some moves. In order to keep the > > history, please submit moves as a recipe (batch/shell script) rather > > than as part of a diff. > > > > Regards, > > Mark. > > > > > > > 2006/10/10, Denis Kishenko (JIRA) <[EMAIL PROTECTED]>: > > > > [classlib][awt][test] java.awt test resources are located in wrong plac > e > > > > --- > - > > > > > > > > Key: HARMONY-1813 > > > > URL: http://issues.apache.org/jira/browse/HARMONY-1813 > > > > Project: Harmony > > > > Issue Type: Bug > > > > Components: Classlib > > > >Reporter: Denis Kishenko > > > >Priority: Minor > > > > > > > > > > > > There are several moments to be fixed > > > > 1. Serialization and shape resources necessary for junit test are locat > ed i > > > n wrong places. > > > > modules\awt\src\test\api\java\common\java\awt\serialization > > > > modules\awt\src\test\api\java\common\java\awt\shapes > > > > modules\awt\src\test\api\java\common\java\awt\geom\serialization > > > > modules\awt\src\test\api\java\common\java\awt\geom\shapes > > > > 2. Tests use TEST_SRC_DIR parameter to find resources. > > > > 3. DimensionTest serialization test failed (test excluded). > > > > > > > > > > > > -- > > > > This message is automatically generated by JIRA. > > > > - > > > > If you think it was sent incorrectly contact one of the administrators: > htt > > > p://issues.apache.org/jira/secure/Administrators.jspa > > > > - > > > > For more information on JIRA, see: http://www.atlassian.com/software/ji > ra > > > > > > > > > > > > > > > > > > > > > -- > > > Denis M. Kishenko > > > Intel Middleware Products Division > > > > > > - > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Denis M. Kishenko > Enterprise Solutions Software Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][portlib] classlib tests fail on portlib
On 19 October 2006 at 16:14, "Elena Semukhina" <[EMAIL PROTECTED]> wrote:
>
> After the portlib module has been added today to
> classlib/trunk/modules "ant test" started failing on this module with
> the message "Target `test' does not exist in this project. "
This should be fixed in r465546. ("ant -Dbuild.module=portlib test" will
still fail since portlib has no tests but "ant test" should complete.)
I think it might be nice to add some (native) tests to portlib since
this would aid porting to new platforms. What do other people think?
Regards,
Mark.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] Build failure messages
These messages aren't getting through on the commits list on due to the large number of warnings since switching to ecj. I've modified the summary process so that it ignores these for the moment. Hopefully this means that the failure messages that haven't been making the commits list will start getting through. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ECJ set as default compiler (WAS: [general] version of gcc and other tools)
On 17 October 2006 at 2:17, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > On Tuesday 17 October 2006 02:07 Nathan Beyer wrote: > > I've set the default compiler value to use the ECJ adapter. I've also > > added a check to fail the build (in build-java.xml and > > build-tests.xml) if the ECJ adapter class is missing. The message says > > that the ECJ JAR is missing and to copy it from the depends folder. > > > > If there are any changes or suggestions for a more elegant Ant > > solution, just let me know and I'll add them. > > > > Note: The build seemingly takes a bit longer, as ECJ reports a > > significant amount of warnings by default. Personally, these are > > things I believe need to be cleaned up anyway (unused imports, missing > > serialVersionUIDs, etc). I haven't figured out to configure the ECJ > > options via the Ant task yet, so if anyone know, please let the list > > know. > > > > Mark, Tim, IBM folks, > > This may require an update to the automated builds if Ant isn't > > setup like this yet, sorry. No problem. (I think I said I do this a while ago.) > I want to ask how valid were the errors from Sun javac of 1.5.0_08 > version which caused some compilation problems? Maybe it makes sense > to check with Sun compiler once in a while? When I first setup our builds, I built harmony twice, once with sun and then with ecj. I stopped this when we were using the jsr14 target. I'm now tempted to put this back in place. (It shouldn't make too much difference to build times since compiling the java is a relatively small part of the overall build time.) I'll probably do: 1) build with ecj 2) build with sun (using result of 1) 3) run tests, japi, etc (again with output from 1) Does that sound reasonable? (This probably involves quite a bit of shuffling deploy directories around but it should be reasonably easy to do.) Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
Congratulations! -Mark. On 16 October 2006 at 22:59, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > Please join the Apache Harmony PPMC in welcoming the project's newest > committers, in alphabetical order : > > Oliver Deakin > Richard Liang > Alexey Petrenko > Gregory Shimansky > Alexey Varlamov > Alexei Zakharov > > These six individuals have shown sustained dedication to the project, an > ability to work well with others, and share the common vision we have > for Harmony. We all continue to expect great things from them. > > Gentlemen, you don't have accounts yet. When you finally receive your > new committer account information, as a first step to test your almighty > powers of committitude, please update the committers page on the > website. That should be a good (and harmless) exercise to test if > everything is working. > > Things to do : > > 1) test ssh-ing to the server people.apache.org. > 2) Change your login password on the machine > 3) Add a public key to .ssh so you can stop using the password > 4) Set your SVN password : just type 'svnpasswd' > > At this point, you should be good to go. Checkout the website from svn > and update it. See if you can figure out how. > > Also, anything checked out of SVN, be sure that you have checked out via > 'https' and not 'http' or you can't check in. You can switch using "svn > switch". (See the manual) > > Finally, although you now have the ability to commit, please remember : > > 1) continue being as transparent and communicative as possible. You > earned committer status in part because of your engagement with others. > While it was a "have to" situation because you had to submit patches > and defend them, but we believe it is a "want to". Community is the key > to any Apache project. > > 2)We don't want anyone going off and doing lots of work locally, and > then committing. Committing is like voting in Chicago - do it early and > often. Of course, you don't want to break the build, but keep the > "commit bombs" to an absolute minimum, and warn the community if you are > going to do it - we may suggest it goes into a branch at first. Use > branches if you need to. > > 3) Always remember that you can **never** commit code that comes from > someone else, even a co-worker. All code from someone else must be > submitted by the copyright holder (either the author or author's > employer, depending) as a JIRA, and then follow up with the required > ACQs and BCC. > > Again, thanks for your hard work so far, and welcome. > > The Apache Harmony PPMC > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] quicker reporting of test failures/errors (was Re: svn commit: r463824 - /incubator/harmony/enhanced/classlib/trunk/make/build-test.xml)
Frustrated with the time that gen-report takes to produce a report (which mainly consists of pages and pages of information about test passes that I'll never read), I implemented a short report mode on Friday. So now, running: ant -Dshort.report=true test will produce a report that only contains information about tests that have failures or errors. Unless you've broken something really badly it will run in a tiny fraction of the time that the full report takes - 15minutes for me if I run all the classlib tests! Regards, Mark. On 13 October 2006 at 20:58, [EMAIL PROTECTED] wrote: > Author: hindessm > Date: Fri Oct 13 13:58:51 2006 > New Revision: 463824 > > URL: http://svn.apache.org/viewvc?view=rev&rev=463824 > Log: > Generating the test report takes ten minutes on my thinkpad so I've added > a short report mode that only reports on tests that have either errors or > failures. It takes only a few seconds assuming most tests are passing. > Activate it with command line argument -Dshort.report=true. > > Modified: > incubator/harmony/enhanced/classlib/trunk/make/build-test.xml > > Modified: incubator/harmony/enhanced/classlib/trunk/make/build-test.xml > URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m > ake/build-test.xml?view=diff&rev=463824&r1=463823&r2=463824 > = > = > --- incubator/harmony/enhanced/classlib/trunk/make/build-test.xml (original) > +++ incubator/harmony/enhanced/classlib/trunk/make/build-test.xml Fri Oct 13 > 13:58:51 2006 > @@ -52,7 +52,9 @@ > > > > - > + > + > + > > > > @@ -63,6 +65,20 @@ > > > > + > + > + > + > + > + > + > + > + > + > + > + > + > + > > > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] HARMONY-1505 and HARMONY-1608 - cleanup of JNI function names
On 15 October 2006 at 18:40, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > > Does anyone have an objection to those two JIRAs? I don't. -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][classlib] thread library - let there be one!
Artem,
Thanks for this patch. Works for me on Linux.
Moving common and pool as well seems reasonable.
I'll make a minor modification once Weldon has committed it. (Just to
combine the copy-native-includes-windows and copy-native-includes-linux
actions into a second copy in the copy-native-includes target by using
the ${hy.os} variable as the last component in the path.)
Regards,
Mark.
On 15 October 2006 at 11:53, "Weldon Washburn" <[EMAIL PROTECTED]> wrote:
>
> Artem,
> Thanks. I will take a look.
>
>
> On 10/12/06, Artem Aliev <[EMAIL PROTECTED]> wrote:
> >
> > Guys,
> >
> >
> > > 1. Make classlib/modules/portlib directory (or portlib in the root?)
> > > and move hyprt, hysig and hythread code into it. Update build to work
> > > with new directory.
> > >
> > > > [Andrey]- pull out hythread from classlib, make it a shared component
> > >
> >
> > The first step is done in JIRA HARMONY-1843.
> >
> > I move common, pool, port, thread, sig from luni to new component portlib.
> > The first idea was to move only port, thread, sig, but they depend on
> > common and pool libs. It looks natural to do not produce cyclic
> > dependencies among components, so I move these two also to portlib.
> >
> > Unfortunately, this does not fully solve two stage luni building
> > process (build-native-core and build-native-secondary), but this is
> > another problem.
> >
> > So If we are still committed on these reorganization, please review
> > and apply the patch.
> >
> > A move_to_portlib.sh script create portlib directory structure and
> > move appropriate files from luni to portlib (by svn move).
> > A portlib_files.patch update build to works with new structure.
> >
> > Thanks
> > Artem
> >
> >
> >
> >
> > On 9/29/06, Artem Aliev <[EMAIL PROTECTED]> wrote:
> > > Guys,
> > >
> > > Let me try to make this changes.
> > >
> > > Here is my understanding of the steps I need to do.
> > >
> > > 1. Make classlib/modules/portlib directory (or portlib in the root?)
> > > and move hyprt, hysig and hythread code into it. Update build to work
> > > with new directory.
> > >
> > > > [Andrey]- pull out hythread from classlib, make it a shared component
> > >
> > > 2. Move DRLVM hythread to classlib and update drlvm build for it. So
> > > both classlib and drlvm will work on the drlvm hythread.
> > >
> > > > - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and
> > > > upper layer (hythead_xxx)
> > > > - migrate classlib code to the bottom layer (1) of hythread
> > > I do not think it is necessary because the hythread will be shared
> > library.
> > > This make sense only in case we move only layer(1) into the shared
> > directory.
> > >
> > > 3. merge hythreads into one library getting bast code from both sources.
> > > > migrate DRLVM's thread manager to (1) from APR
> > > Will be done on this stage.
> > >
> > > 4. merge classlib and drlvm signal handling code.
> > >
> > > 5. merge port libs code.
> > >
> > > 6.
> > >
> > > Thanks
> > > Artem
> > >
> > > On 9/28/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> > > >
> > > > On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote:
> > > >
> > > > > On 9/28/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> > > > >>
> > > > >> On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote:
> > > > >>
> > > > >> > +1 on the below.
> > > > >> >
> > > > >> > I am assuming Andrey and his team will do this work. (Andrey,
> > when
> > > > >> > will you
> > > > >> > start?)
> > > > >>
> > > > >> We have to start first by pulling hythread out, but where? After
> > > > >> thinking about it for 5 more seconds, putting it on the top level
> > > > >>
> > > > >>enhanced/
> > > > >>
> > > > >> is IMO a bad idea. There's nothing worse than going to a project's
> > > > >> SVN and finding tons of confusing things.
> > > > >
> > > > > I agree making "thread" a standalone component at the level of
> > > > > enhanced/ probably isn't worth doing. What may make a
> > sense
> > > > > is to consider thread a part of the portlib and make the portlib a
> > > > > separate component at that level. Portlib is the only piece which is
> > > > > shared between VM and classlib, this could justify it's appearance
> > at
> > > > > the high level.
> > > > >
> > > > >>
> > > > >> Is there any downside to keeping it somewhere under /classlib/trunk
> > > > >
> > > > > My only guess would be the inability to build VM independently from
> > > > > the classlib.
> > > >
> > > > Sure, you'll still need either to build the /portlib or the /classlib
> > > >
> > > > >
> > > > >> and simply make it a module by itself?
> > > > >
> > > > > If we can not have a portlib as a high level component (like
> > classlib
> > > > > or drlvm), then at least having it as a separate module within
> > > > > classlib would be nice.
> > > >
> > > > This is one of those things where doing the small step (do it in
> > > > classlib) and then consider the large step (do it as a peer) seems to
> > > > be reasonable, but
Re: [classlib][security] provider for algorithms for signing and verifying
Brilliant. Nice work Yuri. I'll take a look at changing the dependency code tomorrow. -Mark On 13 October 2006 at 17:43, "Yuri Kropachev" <[EMAIL PROTECTED]> wrote: > > Yes, it can. > > Thanks, > Yuri > > > On 10/13/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > Cool! > > > > Do you mean that it can now validate a signature in BouncyCastle jar file? > > > > Thanks, > > Mikhail > > > > 2006/10/13, Yuri Kropachev <[EMAIL PROTECTED]>: > > > Hello, > > > > > > With reference to my e-mail dated 2006-06-29 (below) and > > > JIRA ## 742, 837, 872, 908, 1159, 1396, 1837, > > > I inform you that the provider's code is ready to use. > > > > > > Thanks, > > > Yuri > > > > > > > > > > Hello, > > > > > > > > Let me make update to the February talk on a need to have in Harmony > > > > means for signing and verifying; > > > > I refer to the following thread of discussion: > > > > > > > > > http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mb > > > > ox/[EMAIL PROTECTED] > > > > > > > > As according to current state of art the need to have discussed > > services > > > > still exists, I am beginning the implementation of a provider for > > > > algorithms; first ones are for secure random and message digest. If > > > > there is something special I need to know wrt that provider, please > > let > > > > me know. > > > > > > > > Best regards, > > > > Yuri Kropachev > > > > > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --=_Part_35208_28378205.1160736184456-- > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] 'Patch available' status
I'll take a look. -Mark. On 11 October 2006 at 20:03, Salikh Zakirov <[EMAIL PROTECTED]> wrote: > Hi, > > we had a discussion about adding new searchable 'Patch Available' status > to JIRA [1] some time ago. Several people supported the idea, and there > were no objections. > > However, no actions have been made. > > Geir, have you forgotten about it, or do you have some objections? > > [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbo > x/[EMAIL PROTECTED] > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ant][classlib][em64t]Problems during classlib on em64t (revision 462753)
On 11 October 2006 at 18:26, "Valentin Al. Sitnick (Moscow)" <[EMAIL PROTECTED]> wrote: > > It is very strange but I have needed jdk & jars Yeah. I thought when adding the regexp mapper dependency that this should be a non-issue since everyone will need 1.5 to compile anyway. Your setup looks like it has all three options to me. You could check the "ant -v" output but it'll be very verbose and I'm not certain it'll help with this problem. I've added an [ant] tag to the subject in the hope that Matt Benson will spot this thread and might offer some insight? Regards, Mark. > --- > compile-java: > [echo] Compiling ACCESSIBILITY classes > > copy-resources: > > svn-info: > > build-jar: > > BUILD FAILED > /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/build.xml:108 > : > The following error occurred while executing this line: > /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/make/build- > java.xml:183: The following error occurred while executing > this line: > /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/make/properti > es.xml:249: > The following error occurred while executing > this line: > /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/make/properti > es.xml:259: > The following error occurred while executing > this line: > /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/modules/acces > sibility/build.xml:90: > No supported regular expression matcher found > > Total time: 20 seconds > > Linux_x86_64 (bigbox): /home/angel/builds/harmony/suse-10.1-em64t > /clean/classlib/trunk > 18:17:24 $ java -version > java version "1.5.0_09" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b01) > Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_09-b01, mixed mode) > > Linux_x86_64 (bigbox): /home/angel/builds/harmony/suse-10.1-em64t > /clean/classlib/trunk > 18:19:32 $ ant -version > Apache Ant version 1.6.5 compiled on June 16 2006 > > Linux_x86_64 (bigbox): /home/angel/builds/harmony/suse-10.1-em64t > /clean/classlib/trunk > 18:19:54 $ ls /usr/postinstall/ant/apache-ant-1.7.0Beta2/lib/ > ant-antlr.jarant.jar ant-stylebook.jar > ant-apache-bcel.jar ant-javamail.jar ant-swing.jar > ant-apache-bsf.jar ant-jdepend.jar ant-trax.jar > ant-apache-log4j.jar ant-jmf.jar ant-weblogic.jar > ant-apache-oro.jar ant-jsch.jar jakarta-oro-2.0.8.jar > ant-apache-regexp.jarant-junit.jar jakarta-regexp-1.4.jar > ant-apache-resolver.jar ant-launcher.jar libraries.properties > ant-commons-logging.jar ant-netrexx.jar README > ant-commons-net.jar ant-nodeps.jarxercesImpl.jar > ant-jai.jar ant-starteam.jar xml-apis.jar > > Linux_x86_64 (bigbox): /home/angel/builds/harmony/suse-10.1-em64t > /clean/classlib/trunk > 18:20:16 $ > > - > > > > > > > > > > > On 10/11/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > > > > On 11 October 2006 at 16:18, "Valentin Al. Sitnick (Moscow)" < > > [EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > I've tried to build classlib on em64t workstation an got some > > problems: > > > > > > 0. Bug in depends.xml - hosts architectures defined with bug > > > --- > > > > > > > > > > > > --- small fix > > > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > 1. ant (1.6.5 or 1.7.0.beta2 - I've tried to use both) cannot create > > > symlinks. It is not serious porblem - it is possible to create these > > lintks > > > manually > > > 2. build process was interrupted by error: > > > > > > > > --- > -- > > > - > > > -really-link: > > > > > > check: > > > > > > -compile: > > > [mkdir] Created dir: /home/angel/builds/harmony/suse-10.1-em64t > > > /clean/classlib/trunk/build/classes > > > [javac] Compiling 3397 source files to > > /home/angel/builds/harmony/suse- > > > 10.1-em64t/clean/classlib/trunk/build/class
Re: [classlib][em64t]Problems during classlib on em64t (revision 462753)
On 11 October 2006 at 16:18, "Valentin Al. Sitnick (Moscow)" <[EMAIL PROTECTED]> wrote: > > Hi, > I've tried to build classlib on em64t workstation an got some problems: > > 0. Bug in depends.xml - hosts architectures defined with bug > --- > > > > --- small fix > > > > > > > > --- > > 1. ant (1.6.5 or 1.7.0.beta2 - I've tried to use both) cannot create > symlinks. It is not serious porblem - it is possible to create these lintks > manually > 2. build process was interrupted by error: > > - > - > -really-link: > > check: > > -compile: > [mkdir] Created dir: /home/angel/builds/harmony/suse-10.1-em64t > /clean/classlib/trunk/build/classes > [javac] Compiling 3397 source files to /home/angel/builds/harmony/suse- > 10.1-em64t/clean/classlib/trunk/build/classes > [javac] Note: * uses or overrides a deprecated API. > [javac] Note: Recompile with -Xlint:deprecation for details. > [javac] Note: Some input files use unchecked or unsafe operations. > [javac] Note: Recompile with -Xlint:unchecked for details. > [mkdir] Created dir: /home/angel/builds/harmony/suse-10.1-em64t > /clean/classlib/trunk/deploy/jdk/jre/lib/boot > > call-modules-all: > > compile-java: > [echo] Compiling ACCESSIBILITY classes > > copy-resources: > [copy] Copying 1 file to /home/angel/builds/harmony/suse-10.1-em64t > /clean/classlib/trunk/build/classes > > svn-info: > > build-jar: > > BUILD FAILED > /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/build.xml:108 > : > The following error occurred while executing > this line: > /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/make/build- > java.xml:183: The following error occurred while executing > this line: > /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/make/properti > es.xml:249: > The following error occurred while executing > this line: > /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/make/properti > es.xml:259: > The following error occurred while executing > this line: > /home/angel/builds/harmony/suse-10.1-em64t/clean/classlib/trunk/modules/acces > sibility/build.xml:90: > No supported regular expression ma > tcher found > > Total time: 56 seconds > > Linux_x86_64 (bigbox): /home/angel/builds/harmony/suse-10.1-em64t > /clean/classlib/trunk > 14:36:02 $ > > - > - > It seems as an ant bug. > Could someone help me? I've never seen this error, but it looks like you are missing a regex implementation. The ant regexp glob mapper has some dependencies described at: http://ant.apache.org/manual/CoreTypes/mapper.html#regexp-mapper But basically it says you need: Ant comes with implementations for the java.util.regex package of JDK 1.4 or higher, jakarta-regexp and jakarta-ORO. I'm kind of surprised you don't have the first of these? Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and recommend to add them to fetch-depends target
On 11 October 2006 at 3:14, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > On Monday 09 October 2006 19:54 Oliver Deakin wrote: > > I see that you already said pretty much the same thing I did on another > > thread [1]. > > > > IMHO we should make sure that if the fetch-depends target finds it > > cannot sym > > link to preinstalled system libraries, then the user is clearly informed > > so they have > > the choice to install them without having the archived file versions > > unpacked. So > > perhaps the fetch-depends step should still fail with a message saying > > something like > > "Could not resolve these dependencies, either build/install these > > packages manually > > or you can run this other target to have the archived versions unpacked > > into your > > dependency tree". (Hopefully a little clearer than that ;) ) > > This sounds very much like a configure script. Indeed, and we may well end up with one of those at some point. > Check for installed libraries, fail if something is missing. I like it :) I would like to be more helpful if we can. Yesterday, I added the details of the required packages for Fedora Core 5. Hopefully others will help get the instructions up dated for distributions they use. Otherwise, I will try to add instructions for recent SLES and RHEL in the next week or so. > On Linux however all libraries are present in distributions (I buy you > a beer if you name a single Linux distribution which doesn't include > necessary development packages, knoppix not counted). I'll get my better half to start making more room in the fridge while I go through the list of distros at: http://lwn.net/Distributions/ I reckon I should get at least a six-pack just out of the embedded section alone. ;-) > Only Windows distribution doesn't include them, so for convenience > windows binaries may be cached for download on harmony site. In time I expect we'll do the same for others like MacOS X, Aix, etc. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] [tests] Can anyone explain what these are for?
I've come across a couple of tests with things like:
public void test_getInetAddress() {
assertTrue("Used to test", true);
}
Can anyone explain why we have these?
Regards,
Mark.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] version of gcc and other tools
On 10 October 2006 at 20:32, "Alexey Petrenko" <[EMAIL PROTECTED]> wrote: > 2006/10/10, Geir Magnusson Jr. <[EMAIL PROTECTED]>: > > I'm so sick of this gcc problem. > > > > Lets decide on the versions for GCC and other tools that "will work". I > > feel the same way that mark does re that being able to build on multiple > > versions gives a better feeling of goodness and harmony in the universe > > and I encourage people to work on other versions (I will), but it's > > gotta be the case that we have a "reference toolchain" - that no matter > > what, it will work on there, and probably a list of tested versions > > > > So, what tools and what versions are people working with ? here's a > > partial list of mine : > > > > 1) WinXP : Visual Studio .NET 2003 > > > > 2) Linux x86 : > > GCC : 3.4.6 > > g++ : 3.4.6 > > make : 3.81b4 > > > > What are you using? what other tools should we list? > ant binutils is pretty important (and for compiling drlvm, the binutils development package is required - many people, even developers, wouldn't normally have this). Regards, Mark. > > I recently setup a new machine (linux) and now have the complete list of > > stuff that has to be installed (starting from fresh ubuntu6) and will > > post that on the getting started document on teh website. > > > > > > geir > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Alexey A. Petrenko > Intel Middleware Products Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][build] Failed to build classlib on r454714
On 10 October 2006 at 12:23, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > Muahaha... didn't you just say this was something that never changed, > was geological in stability, etc, etc? :) :-) Well, yeah, and I was worried until I saw that: a) the change to introduce this variable happened over two years ago, and b) my lucky guess was enough to fix it -Mark. > Mark Hindess wrote: > > On 10 October 2006 at 16:22, "Oleg Khaschansky" <[EMAIL PROTECTED] > om> wrote: > >> It looks like you don't have lcms.h and, probably, other lcms stuff in > >> \enhanced\classlib\trunk\depends\libs\build\lcms\. > > > > I think the problem is more likely that they do have lcms but that they > > don't have the same version as everyone else. > > > > At a guess, I'd say that the version they are using doesn't have the > > cache that the cmsFLAGS_NOTCACHE flag is intended to switch off and > > that: > > > > #ifndef cmsFLAGS_NOTCACHE > > #define cmsFLAGS_NOTCACHE (0) > > #endif > > > > after the #include for lcms.h would solve the problem. > > > > But this is a complete guess. > > > > -Mark. > > > >> Recently awt/swing build was enabled by default and it requires this > >> dependency as well as png and jpeg. > >> > >> Read the instructions in > >> \enhanced\classlib\trunk\depends\libs\build\README.txt. > >> > >> Or check the recent posts about this. E.g. the following recent thread: > >> [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and > >> recommend to add them to fetch-depends target > >> > >> On 10/10/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote: > >>> I'm seeing the same problem. > >>> > >>> Thanks, > >>> Pavel > >>> > >>> On 10/10/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > >>>> Got the following compilation error (SLES 9 gcc 3.3.3): > >>>> > >>>> build-native: > >>>> [exec] cc -O1 -march=pentium3 -DLINUX -D_REENTRANT > >>>> -DIPv6_FUNCTION_SUPPORT -DHYX86 -I/e > >>>> xport/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/include > >>>> -I/export/users2/avarlamo/l > >>>> inux.ia32/svn-repo/classlib/deploy/jdk/include -I. -I../shared/ -fpic > >>>> -Icommon -I../shared//i nclude > >>>> -I/export/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/../depends > / > >> libs/build/lc > >>>> ms -c -o ../shared//cmmxforms.o ../shared//cmmxforms.c > >>>> [exec] ../shared/cmmxforms.c: In function `cmmCreateMultiprofileTran > s > >> form': > >>>> [exec] ../shared/cmmxforms.c:150: error: `cmsFLAGS_NOTCACHE' > >>>> undeclared (first use in th is function) > >>>> [exec] ../shared/cmmxforms.c:150: error: (Each undeclared > >>>> identifier is reported only on ce > >>>> [exec] ../shared/cmmxforms.c:150: error: for each function it appear > s > >> in.) > >>>> [exec] ../shared/cmmxforms.c:181: warning: passing arg 2 of > >>>> `cmsSample3DGrid' from incom patible pointer type > >>>> [exec] make: *** [../shared//cmmxforms.o] Error 1 > >>>> > >>>> BUILD FAILED > >>>> > >>>> - > >>>> Terms of use : http://incubator.apache.org/harmony/mailing.html > >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >>> - > >>> Terms of use : http://incubator.apache.org/harmony/mailing.html > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >> - > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-1813) [classlib][awt][test] java.awt test resources are located in wrong place
On 10 October 2006 at 19:00, "Denis Kishenko" <[EMAIL PROTECTED]> wrote: > Hi committers > > Could someone look at this issue. Because I am going to make another > fix which is depend on this patch. The diff looks like it contains some moves. In order to keep the history, please submit moves as a recipe (batch/shell script) rather than as part of a diff. Regards, Mark. > 2006/10/10, Denis Kishenko (JIRA) <[EMAIL PROTECTED]>: > > [classlib][awt][test] java.awt test resources are located in wrong place > > > > > > Key: HARMONY-1813 > > URL: http://issues.apache.org/jira/browse/HARMONY-1813 > > Project: Harmony > > Issue Type: Bug > > Components: Classlib > >Reporter: Denis Kishenko > >Priority: Minor > > > > > > There are several moments to be fixed > > 1. Serialization and shape resources necessary for junit test are located i > n wrong places. > > modules\awt\src\test\api\java\common\java\awt\serialization > > modules\awt\src\test\api\java\common\java\awt\shapes > > modules\awt\src\test\api\java\common\java\awt\geom\serialization > > modules\awt\src\test\api\java\common\java\awt\geom\shapes > > 2. Tests use TEST_SRC_DIR parameter to find resources. > > 3. DimensionTest serialization test failed (test excluded). > > > > > > -- > > This message is automatically generated by JIRA. > > - > > If you think it was sent incorrectly contact one of the administrators: htt > p://issues.apache.org/jira/secure/Administrators.jspa > > - > > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > > > > > > > -- > Denis M. Kishenko > Intel Middleware Products Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][build] Failed to build classlib on r454714
On 10 October 2006 at 20:09, "Alexey Varlamov" <[EMAIL PROTECTED]> wrote: > Got 1 error of 17940 tests: > javax.swing.text.GapContent_PositionTest.testShiftGapLeft(): > java.lang.IndexOutOfBoundsException at > java.util.ArrayList.get(ArrayList.java:335) at > javax.swing.text.GapContent_PositionTest.checkPositions(GapContent_PositionTe > st.java:83) > at javax.swing.text.GapContent_PositionTest.testShiftGapLeft(GapContent_Posit > ionTest.java:59) > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) > at javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:115) > at javax.swing.BasicSwingTestCase.runBareImpl(BasicSwingTestCase.java:120) > at javax.swing.BasicSwingTestCase$1.run(BasicSwingTestCase.java:133) > at java.lang.Thread.run(Thread.java:872) Hmm... that doesn't look like it is related to lcms to me. -Mark. > 2006/10/10, Mark Hindess <[EMAIL PROTECTED]>: > > > > On 10 October 2006 at 19:46, "Alexey Varlamov" <[EMAIL PROTECTED] > > wrote: > > > 2006/10/10, Alexey Varlamov <[EMAIL PROTECTED]>: > > > > 2006/10/10, Mark Hindess <[EMAIL PROTECTED]>: > > > > > > > > > > On 10 October 2006 at 16:22, "Oleg Khaschansky" <[EMAIL PROTECTED] > mail > > > .com> wrote: > > > > > > It looks like you don't have lcms.h and, probably, other lcms stuff > in > > > > > > \enhanced\classlib\trunk\depends\libs\build\lcms\. > > > > > > > > > > I think the problem is more likely that they do have lcms but that th > ey > > > > > don't have the same version as everyone else. > > > > > > > > I have lcms 1.0.12 and it worked fine this morning %) > > > > > > > > > > At a guess, I'd say that the version they are using doesn't have the > > > > > cache that the cmsFLAGS_NOTCACHE flag is intended to switch off and > > > > > that: > > > > > > > > > > #ifndef cmsFLAGS_NOTCACHE > > > > > #define cmsFLAGS_NOTCACHE (0) > > > > > #endif > > > > > > > > > > after the #include for lcms.h would solve the problem. > > > > > > It hepls, thanks Mark! > > > > Can you let me know if the tests pass too? > > > > Regards, > > Mark. > > > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][build] Failed to build classlib on r454714
On 10 October 2006 at 19:46, "Alexey Varlamov" <[EMAIL PROTECTED]> wrote: > 2006/10/10, Alexey Varlamov <[EMAIL PROTECTED]>: > > 2006/10/10, Mark Hindess <[EMAIL PROTECTED]>: > > > > > > On 10 October 2006 at 16:22, "Oleg Khaschansky" <[EMAIL PROTECTED] > .com> wrote: > > > > It looks like you don't have lcms.h and, probably, other lcms stuff in > > > > \enhanced\classlib\trunk\depends\libs\build\lcms\. > > > > > > I think the problem is more likely that they do have lcms but that they > > > don't have the same version as everyone else. > > > > I have lcms 1.0.12 and it worked fine this morning %) > > > > > > At a guess, I'd say that the version they are using doesn't have the > > > cache that the cmsFLAGS_NOTCACHE flag is intended to switch off and > > > that: > > > > > > #ifndef cmsFLAGS_NOTCACHE > > > #define cmsFLAGS_NOTCACHE (0) > > > #endif > > > > > > after the #include for lcms.h would solve the problem. > > It hepls, thanks Mark! Can you let me know if the tests pass too? Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][build] Failed to build classlib on r454714
On 10 October 2006 at 19:41, "Alexey Varlamov" <[EMAIL PROTECTED]> wrote: > 2006/10/10, Mark Hindess <[EMAIL PROTECTED]>: > > > > On 10 October 2006 at 16:22, "Oleg Khaschansky" <[EMAIL PROTECTED] > om> wrote: > > > It looks like you don't have lcms.h and, probably, other lcms stuff in > > > \enhanced\classlib\trunk\depends\libs\build\lcms\. > > > > I think the problem is more likely that they do have lcms but that they > > don't have the same version as everyone else. > > I have lcms 1.0.12 and it worked fine this morning %) Were you building with -Dwith.awt.swing=true this morning? So if you roll back to revision 454652, does it work? I did change some files in that module today - but mostly adding newlines to the ends of files to get rid of compiler warnings - and I doubt that would break it. -Mark. > > At a guess, I'd say that the version they are using doesn't have the > > cache that the cmsFLAGS_NOTCACHE flag is intended to switch off and > > that: > > > > #ifndef cmsFLAGS_NOTCACHE > > #define cmsFLAGS_NOTCACHE (0) > > #endif > > > > after the #include for lcms.h would solve the problem. > > > > But this is a complete guess. > > > > -Mark. > > > > > Recently awt/swing build was enabled by default and it requires this > > > dependency as well as png and jpeg. > > > > > > Read the instructions in > > > \enhanced\classlib\trunk\depends\libs\build\README.txt. > > > > > > Or check the recent posts about this. E.g. the following recent thread: > > > [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and > > > recommend to add them to fetch-depends target > > > > > > On 10/10/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote: > > > > I'm seeing the same problem. > > > > > > > > Thanks, > > > > Pavel > > > > > > > > On 10/10/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > > > > > Got the following compilation error (SLES 9 gcc 3.3.3): > > > > > > > > > > build-native: > > > > > [exec] cc -O1 -march=pentium3 -DLINUX -D_REENTRANT > > > > > -DIPv6_FUNCTION_SUPPORT -DHYX86 -I/e > > > > > xport/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/include > > > > > -I/export/users2/avarlamo/l > > > > > inux.ia32/svn-repo/classlib/deploy/jdk/include -I. -I../shared/ -fpic > > > > > -Icommon -I../shared//i nclude > > > > > -I/export/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/../depe > nds/ > > > libs/build/lc > > > > > ms -c -o ../shared//cmmxforms.o ../shared//cmmxforms.c > > > > > [exec] ../shared/cmmxforms.c: In function `cmmCreateMultiprofileT > rans > > > form': > > > > > [exec] ../shared/cmmxforms.c:150: error: `cmsFLAGS_NOTCACHE' > > > > > undeclared (first use in th is function) > > > > > [exec] ../shared/cmmxforms.c:150: error: (Each undeclared > > > > > identifier is reported only on ce > > > > > [exec] ../shared/cmmxforms.c:150: error: for each function it app > ears > > > in.) > > > > > [exec] ../shared/cmmxforms.c:181: warning: passing arg 2 of > > > > > `cmsSample3DGrid' from incom patible pointer type > > > > > [exec] make: *** [../shared//cmmxforms.o] Error 1 > > > > > > > > > > BUILD FAILED > > > > > > > > > > - > > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > g > > > > > > > > > > > > > > > > > > - > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > - > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][build] Failed to build classlib on r454714
On 10 October 2006 at 19:36, "Pavel Ozhdikhin" <[EMAIL PROTECTED]> wrote: > I have a symlink > trunk/working_classlib/depends/libs/build/lcms/liblcms.ia32 -> > /usr/lib/liblcms.a and a good symlink to lcms.h in the same directory. > png and jpeg dirs also contain valid symlinks. Do you think I still > need to compile the libraries? I suspect you have an old version of lcms - that is, one that dates from before 2004(!) when the cmsFLAGS_NOTCACHE flags was added. Can you check what version you have installed? Regards, Mark. > Thanks, > Pavel > > On 10/10/06, Oleg Khaschansky <[EMAIL PROTECTED]> wrote: > > It looks like you don't have lcms.h and, probably, other lcms stuff in > > \enhanced\classlib\trunk\depends\libs\build\lcms\. > > > > Recently awt/swing build was enabled by default and it requires this > > dependency as well as png and jpeg. > > > > Read the instructions in > > \enhanced\classlib\trunk\depends\libs\build\README.txt. > > > > Or check the recent posts about this. E.g. the following recent thread: > > [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and > > recommend to add them to fetch-depends target > > > > On 10/10/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote: > > > I'm seeing the same problem. > > > > > > Thanks, > > > Pavel > > > > > > On 10/10/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > > > > Got the following compilation error (SLES 9 gcc 3.3.3): > > > > > > > > build-native: > > > > [exec] cc -O1 -march=pentium3 -DLINUX -D_REENTRANT > > > > -DIPv6_FUNCTION_SUPPORT -DHYX86 -I/e > > > > xport/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/include > > > > -I/export/users2/avarlamo/l > > > > inux.ia32/svn-repo/classlib/deploy/jdk/include -I. -I../shared/ -fpic > > > > -Icommon -I../shared//i nclude > > > > -I/export/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/../depend > s/libs/build/lc > > > > ms -c -o ../shared//cmmxforms.o ../shared//cmmxforms.c > > > > [exec] ../shared/cmmxforms.c: In function `cmmCreateMultiprofileTra > nsform': > > > > [exec] ../shared/cmmxforms.c:150: error: `cmsFLAGS_NOTCACHE' > > > > undeclared (first use in th is function) > > > > [exec] ../shared/cmmxforms.c:150: error: (Each undeclared > > > > identifier is reported only on ce > > > > [exec] ../shared/cmmxforms.c:150: error: for each function it appea > rs in.) > > > > [exec] ../shared/cmmxforms.c:181: warning: passing arg 2 of > > > > `cmsSample3DGrid' from incom patible pointer type > > > > [exec] make: *** [../shared//cmmxforms.o] Error 1 > > > > > > > > BUILD FAILED > > > > > > > > - > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > - > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][build] Failed to build classlib on r454714
On 10 October 2006 at 16:22, "Oleg Khaschansky" <[EMAIL PROTECTED]> wrote: > It looks like you don't have lcms.h and, probably, other lcms stuff in > \enhanced\classlib\trunk\depends\libs\build\lcms\. I think the problem is more likely that they do have lcms but that they don't have the same version as everyone else. At a guess, I'd say that the version they are using doesn't have the cache that the cmsFLAGS_NOTCACHE flag is intended to switch off and that: #ifndef cmsFLAGS_NOTCACHE #define cmsFLAGS_NOTCACHE (0) #endif after the #include for lcms.h would solve the problem. But this is a complete guess. -Mark. > Recently awt/swing build was enabled by default and it requires this > dependency as well as png and jpeg. > > Read the instructions in > \enhanced\classlib\trunk\depends\libs\build\README.txt. > > Or check the recent posts about this. E.g. the following recent thread: > [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and > recommend to add them to fetch-depends target > > On 10/10/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote: > > I'm seeing the same problem. > > > > Thanks, > > Pavel > > > > On 10/10/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > > > Got the following compilation error (SLES 9 gcc 3.3.3): > > > > > > build-native: > > > [exec] cc -O1 -march=pentium3 -DLINUX -D_REENTRANT > > > -DIPv6_FUNCTION_SUPPORT -DHYX86 -I/e > > > xport/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/include > > > -I/export/users2/avarlamo/l > > > inux.ia32/svn-repo/classlib/deploy/jdk/include -I. -I../shared/ -fpic > > > -Icommon -I../shared//i nclude > > > -I/export/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/../depends/ > libs/build/lc > > > ms -c -o ../shared//cmmxforms.o ../shared//cmmxforms.c > > > [exec] ../shared/cmmxforms.c: In function `cmmCreateMultiprofileTrans > form': > > > [exec] ../shared/cmmxforms.c:150: error: `cmsFLAGS_NOTCACHE' > > > undeclared (first use in th is function) > > > [exec] ../shared/cmmxforms.c:150: error: (Each undeclared > > > identifier is reported only on ce > > > [exec] ../shared/cmmxforms.c:150: error: for each function it appears > in.) > > > [exec] ../shared/cmmxforms.c:181: warning: passing arg 2 of > > > `cmsSample3DGrid' from incom patible pointer type > > > [exec] make: *** [../shared//cmmxforms.o] Error 1 > > > > > > BUILD FAILED > > > > > > - > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] define pre-commit testing configs to gain the stability
On 10 October 2006 at 18:52, "Pavel Ozhdikhin" <[EMAIL PROTECTED]> wrote: > Oh, again! Classlib is broken on Linux right now! :( > And it was not me who did this to illustrate the problem. :) You are obviously using the wrong version of gcc! It compiles and all tests pass for me. ;-) -Mark. > On 10/10/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote: > > I also think the diversity is generally good. Let's test Harmony on as > > many platfroms as possible and find as many problems as we can. But I > > also think that having at least one stable configuration is very > > important for those who wants to work on the new features. Doing this > > kind of work I'd prefer to have, say, 1 platfrom stable 99% of time > > than 99 platforms stable 1% of time. > > > > I deeply appreciate the responsible committers like you who test the > > patches thoroughly. But the overall process seems is not perfect since > > the workspace breaks up again and again. Unfortunately tightening > > pre-commit criteria seems to me the only way to prevent breakage. > > > > Thanks, > > Pavel > > > > On 10/9/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > > > > On 9 October 2006 at 16:12, "Pavel Ozhdikhin" <[EMAIL PROTECTED]> > wrote: > > > > On 10/9/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > > > Rana Dasgupta wrote: > > > > > > We need to check both release and debug builds...the binaries and t > iming > > > > > > characteristics are too different. At this immediate stage of the > > > > > > project, I > > > > > > would suggest leaving out EM64T as part of mandatory testing( unles > s it i > > > > s > > > > > > EM64T specific functionality, eg., codegen ). Too few contributors > and > > > > > > committers have access to it. We are not yet at a stage where we ca > n make > > > > > > this mandatory. > > > > > > > > > > > > If possible all submissions should be tested( by submitters ) on al > l the > > > > > > combinations identified . It is actually more urgent for submitters > to do > > > > > > this. We should stop patches by email. Also, at this point, it is a > n hono > > > > r > > > > > > system, we can't attach 6 before and after test logs to each JIRA > > > > > > submission. The committer could randomly check on one or more combi > nation > > > > , > > > > > > ...the more the better obviously. > > > > > > > > > > > > In some cases, submissions will be platform specific ( eg., very ne > w code > > > > > > like GC V5, platform specific bug fixes or a simple case of develop > er not > > > > > > having all the machines ). I would leave these to the committers' > > > > > > discretion. > > > > > > > > > > Mandating that patches are pre-tested on a wide variety of machines i > s > > > > > not conducive to building a broad community of contributors since ver > y > > > > > few people have access to all the machines and configurations we are > > > > > interested in. I'd much prefer that we work optimistically and have > > > > > lots of people regularly building and testing the code to get the > > > > > broadest possible coverage. We can backtrack if problems arise. > > > > > > Agreed. Broadest possible coverage is much more important. > > > > > > > Even is a committer does't have a wide variety of machines I think we > > > > can still mandate that his/her commits are checked on the right > > > > configuration. > > > > > > You'd also need to mandate linker versions and assembler versions too. > > > > > > > If the majority works on GCC 4.0.3 checking the patch on GCC 3.3.2 > > > > might not reveal the problems. Regular testing will, but the time > > > > spend on backtracking is lost. The proposal is not only about variety > > > > of configurations but is also about configurations themselves. Rana > > > > proposed to exclude EM64T and add debug configs, so for now the list > > > > is following: > > > > > > > > - Windows / IA32 / MSVS .NET 2003 / release > > > > - Windows / IA32 / MSVS .NET 2003 / debug > > > > - Linux / IA32 / GCC 4.0.3 / release > > > > - Linux / IA3
Re: [build] DRLVM build on Windows
Perhaps it is a windows path length problem? Does it work if you rename C:\Work\Harmony\drlvm\trunk to: C:\drlvm ? Regards, Mark. On 10 October 2006 at 12:03, "Alexey Petrenko" <[EMAIL PROTECTED]> wrote: > Guys, > > I have not built DRLVM for a few days. > But after last update it fails with the following error on Windows: > > BUILD FAILED > C:\Work\Harmony\drlvm\trunk\build\make\build.xml:406: The following > error occurred while executing this line: > C:\Work\Harmony\drlvm\trunk\build\make\build.xml:413: The following > error occurred while executing this line: > C:\Work\Harmony\drlvm\trunk\build\make\build_component.xml:72: The > following error occurred while executing this line: > C:\Work\Harmony\drlvm\trunk\build\win_ia32_msvc_debug\semis\build\targets\bui > ld > native.xml:75: Command line is over maximum length without specifying > source file > > "build clean" and removing downloaded dependencies does not help. > > Is there any ideaas how ti fix this? > > Thanks in advance. > > SY, Alexey > > -- > Alexey A. Petrenko > Intel Middleware Products Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][test] Failure in swing test
On 10 October 2006 at 8:53, Mark Hindess <[EMAIL PROTECTED]> wrote: > > On 10 October 2006 at 14:19, "Mikhail Loenko" <[EMAIL PROTECTED]> wrote: > > Please wait. > > Too late. Back out r454633 if you wish. > > I asked people to test this and report back last week. No one said > don't do it. And lots of people said '+1'. > > > what are you going to do with linux? > > I've talked about this on and off for several months, but ... > > Libraries such as libpng, libjpeg, and liblcms are stable and rarely > change significantly between distributions, so we should use the > versions provided by OS vendors. > > AFAIK, no one seems to have figured out which packages are required on > any non-debian based distribution. I asked for this information months > ago, but I assumed that no one was using other distributions or that > they simply thought it easier to build it themselves. > > I am in the process of creating chroot/vmware/qemu images of recent > versions of both Red Hat and SuSE in order to derive the correct > instructions. > > The reason I believe that using system versions is the right way to > go is that I believe we should be using shared libraries for these > dependencies and not statically linking them. > > Of course, some libraries are developing too quickly for distributions > to keep up so we will end up distributing them - ICU for instance. > > Everyone seems happy enough with the solution on Debian-based distros > and it should be just as trivial to resolve the problem on RedHat and > SuSE. It just takes someone with those distributions to figure out > the appropriate packages/commands. For instance, I'm reliably informed that: yast --install libpng-devel libjpeg-devel liblcms-devel works on SLES 10 if you have a yast source configured correctly. The RHEL4 equivalent probably involves up2date. I think FC5 has yum so that should be a similar "yum install" command. (I think this means that RHEL5 when it arrives while have yum too.) Regards, Mark. > > 2006/10/10, Mark Hindess <[EMAIL PROTECTED]>: > > > > > > On 9 October 2006 at 16:02, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > > Works for me too now ... > > > > > > > > Unless anyone objects I suggest that we make the 'with.awt.swing' > > > > default behavior (and we'll see the failure if it happens again). > > > > > > Excellent. I'll dump the property unless anyone else beats me > > > to it. > > > > > > -Mark. > > > > > > > Regards, > > > > Tim > > > > > > > > Oleg Khaschansky wrote: > > > > > Tim, > > > > > > > > > > I can't see this failure at r454268. Anyone else see it? Maybe rebuil > d > > > > > will help? > > > > > > > > > > I also looked into SpinnerDateModelTest source and it doesn't seems t > o > > > > > me that it could be related to the TransferHandler. > > > > > > > > > > -- > > > > > Oleg > > > > > > > > > > On 10/9/06, Oleg Khaschansky <[EMAIL PROTECTED]> wrote: > > > > >> I will take a look at this. > > > > >> > > > > >> On 10/8/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > > >> > I see a failure on IA32 Win XP tests at r454168 (after applying th > e > > > > >> > TransferHandler patch). > > > > >> > > > > > >> > The walkback is: > > > > >> > > > > > >> > junit.framework.AssertionFailedError: expected:<0> but was:<7> at > > > > >> > > > > > >> javax.swing.SpinnerDateModelTest.testSpinnerDateModel(SpinnerDateMod > el > > Test > > > > .java:59) > > > > >> > > > > >> > at > > > > >> > > > > > >> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) > a > > t > > > > >> > > > > > >> javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java: > 11 > > 5) > > > > >> > at > > > > >> > > > > > >> javax.swing.BasicSwingTestCase.runBareImpl(BasicSwingTestCase.java:1 > 20 > > ) > > > > >> at > > > > >> > javax.swing.BasicSwingTestCase$1.run(BasicSwingTestCase.java:133) > a >
Re: [classlib][test] Failure in swing test
On 10 October 2006 at 14:19, "Mikhail Loenko" <[EMAIL PROTECTED]> wrote: > Please wait. Too late. Back out r454633 if you wish. I asked people to test this and report back last week. No one said don't do it. And lots of people said '+1'. > what are you going to do with linux? I've talked about this on and off for several months, but ... Libraries such as libpng, libjpeg, and liblcms are stable and rarely change significantly between distributions, so we should use the versions provided by OS vendors. AFAIK, no one seems to have figured out which packages are required on any non-debian based distribution. I asked for this information months ago, but I assumed that no one was using other distributions or that they simply thought it easier to build it themselves. I am in the process of creating chroot/vmware/qemu images of recent versions of both Red Hat and SuSE in order to derive the correct instructions. The reason I believe that using system versions is the right way to go is that I believe we should be using shared libraries for these dependencies and not statically linking them. Of course, some libraries are developing too quickly for distributions to keep up so we will end up distributing them - ICU for instance. Everyone seems happy enough with the solution on Debian-based distros and it should be just as trivial to resolve the problem on RedHat and SuSE. It just takes someone with those distributions to figure out the appropriate packages/commands. Regards, Mark. > 2006/10/10, Mark Hindess <[EMAIL PROTECTED]>: > > > > On 9 October 2006 at 16:02, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > Works for me too now ... > > > > > > Unless anyone objects I suggest that we make the 'with.awt.swing' > > > default behavior (and we'll see the failure if it happens again). > > > > Excellent. I'll dump the property unless anyone else beats me > > to it. > > > > -Mark. > > > > > Regards, > > > Tim > > > > > > Oleg Khaschansky wrote: > > > > Tim, > > > > > > > > I can't see this failure at r454268. Anyone else see it? Maybe rebuild > > > > will help? > > > > > > > > I also looked into SpinnerDateModelTest source and it doesn't seems to > > > > me that it could be related to the TransferHandler. > > > > > > > > -- > > > > Oleg > > > > > > > > On 10/9/06, Oleg Khaschansky <[EMAIL PROTECTED]> wrote: > > > >> I will take a look at this. > > > >> > > > >> On 10/8/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > >> > I see a failure on IA32 Win XP tests at r454168 (after applying the > > > >> > TransferHandler patch). > > > >> > > > > >> > The walkback is: > > > >> > > > > >> > junit.framework.AssertionFailedError: expected:<0> but was:<7> at > > > >> > > > > >> javax.swing.SpinnerDateModelTest.testSpinnerDateModel(SpinnerDateModel > Test > > > .java:59) > > > >> > > > >> > at > > > >> > > > > >> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) a > t > > > >> > > > > >> javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:11 > 5) > > > >> > at > > > >> > > > > >> javax.swing.BasicSwingTestCase.runBareImpl(BasicSwingTestCase.java:120 > ) > > > >> at > > > >> > javax.swing.BasicSwingTestCase$1.run(BasicSwingTestCase.java:133) a > t > > > >> > java.lang.Thread.run(Thread.java:872) > > > >> > > > > >> > I'll take a look later unless somebody picks it up. > > > >> > > > > >> > Regards, > > > >> > Tim > > > >> > > > > >> > > > > >> > -- > > > >> > > > > >> > Tim Ellison ([EMAIL PROTECTED]) > > > >> > IBM Java technology centre, UK. > > > >> > > > > >> > > - > > > >> > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > >> > For additional commands, e-mail: [EMAIL PROTECTED] > rg > > > >> > > > > >> > > > > >> >
Re: [classlib] [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 Build/Test
On 8 October 2006 at 5:38, Tim Ellison <[EMAIL PROTECTED]> wrote: > Mark Hindess wrote: > > FYI: I've changed the way our builds are reported to the -commits > > list. Now, the reports go to my apache.org email address where they are > > compressed and stored. The url in the message is then modified to point > > to the compressed version in my people.apache.org web space and the > > first 10k of the message is sent on to the -commits list. > > Is it possible to send the first ~5k (so we get the report URL and > change set part) and the last 10k which is more likely to show the > compile error / test failure? I've improved the trimming. It now sends first 10k plus five lines of context either side of any lines that look like warnings, errors or failures. Hopefully this will be sufficient but if not I'm open to further suggestions. -Mark. > > This should mean: > > > > a) all messages reach the list (no more size limit issues) > > > > b) the full logs are available via the web - at least for a week or two > > > > Currently the trimming of the logs to send to the list is very crude and > > usually the first 10k isn't very useful. Hopefully I'll get some time > > to improve the trimming shortly to, for instance, include lines which > > match /(error/fail/warn)/i plus a few lines of context above/below. > > > > Regards, > > Mark. > > > > On 4 October 2006 at 9:36, [EMAIL PROTECTED] wrote: > >> Online report : http://people.apache.org/~hindessm/continuum/classlib/linu > x.i > >> a32/2006/10/04/20061004-083606.successful.log.gz > >> Build statistics: > >> State: Ok > >> Previous State: Failed > >> Started at: Wed, 4 Oct 2006 09:03:31 +0100 > >> Finished at: Wed, 4 Oct 2006 09:36:04 +0100 > >> Total time: 32m 33s > >> Build Trigger: Schedule > >> Exit code: 0 > >> Building machine hostname: hy2 > >> Operating system : Linux(unknown) > >> Java version : 1.5.0_06(Sun Microsystems Inc.) > >> > >> Changes > >> classlib/modules/auth/src/test/java/common/org > /ap > >> ache/harmony/auth/login/DefaultConfigParserTest.java > >> classlib/modules/auth/src/test/java/common/org/apache/harmony/ > aut > >> h/login/DefaultConfigurationTest.java > >> classlib/modules/auth/src/test/resources/auth.conf > >> classlib/make/properties.xml > >> > >> ** > ** > >> Output: > >> ** > ** > >> Buildfile: build.xml > >> > >> build: > >>[delete] Deleting directory /home/hybld/continuum-working-directory/6/c > las > >> slib/deploy > >> [echo] Classlib revision is 452787 > >> [echo] Post process: true > >> [echo] JAPI: true > >> [echo] Building with reference jdk/javac > >> [exec] Buildfile: build.xml > >> > >> [exec] clean-java: > >> > >> [exec] -copy-kernel-patternsets: > >> [exec] [mkdir] Created dir: /home/hybld/continuum-working-directo > ry/ > >> 6/classlib/deploy/build/patternsets > >> [exec] [copy] Copying 1 file to /home/hybld/continuum-working-di > rec > >> tory/6/classlib/deploy/build/patternsets > >> [exec] [copy] Copying 1 file to /home/hybld/continuum-working-di > rec > >> tory/6/classlib/deploy/build/patternsets > >> > >> [exec] -modules-clean-bin: > >> > >> [exec] call-modules-all: > >> > >> [exec] clean: > >> [exec][delete] Deleting 30 files from /home/hybld/continuum-worki > ng- > >> directory/6/classlib/build/classes > >> [exec][delete] Deleting 15 files from /home/hybld/continuum-worki > ng- > >> directory/6/classlib/modules/accessibility/bin/test > >> > >> [exec] clean: > >> [exec][delete] Deleting 13 files from /home/hybld/continuum-worki > ng- > >> directory/6/classlib/build/classes > >> > >> [exec] clean: > >> [exec][delete] Deleting 4 files from /home/hybld/continuum-workin > g-d > >> irectory/6/classlib/build/classes > >> [exec][delete] Deleting 1 files from /home/hybld/continuum-workin > g-d > >> irectory/6/classlib/modules/applet/bin/test > >> &g
Re: [classlib][test] Failure in swing test
On 9 October 2006 at 16:02, Tim Ellison <[EMAIL PROTECTED]> wrote: > Works for me too now ... > > Unless anyone objects I suggest that we make the 'with.awt.swing' > default behavior (and we'll see the failure if it happens again). Excellent. I'll dump the property unless anyone else beats me to it. -Mark. > Regards, > Tim > > Oleg Khaschansky wrote: > > Tim, > > > > I can't see this failure at r454268. Anyone else see it? Maybe rebuild > > will help? > > > > I also looked into SpinnerDateModelTest source and it doesn't seems to > > me that it could be related to the TransferHandler. > > > > -- > > Oleg > > > > On 10/9/06, Oleg Khaschansky <[EMAIL PROTECTED]> wrote: > >> I will take a look at this. > >> > >> On 10/8/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > >> > I see a failure on IA32 Win XP tests at r454168 (after applying the > >> > TransferHandler patch). > >> > > >> > The walkback is: > >> > > >> > junit.framework.AssertionFailedError: expected:<0> but was:<7> at > >> > > >> javax.swing.SpinnerDateModelTest.testSpinnerDateModel(SpinnerDateModelTest > .java:59) > >> > >> > at > >> > > >> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) at > >> > > >> javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:115) > >> > at > >> > > >> javax.swing.BasicSwingTestCase.runBareImpl(BasicSwingTestCase.java:120) > >> at > >> > javax.swing.BasicSwingTestCase$1.run(BasicSwingTestCase.java:133) at > >> > java.lang.Thread.run(Thread.java:872) > >> > > >> > I'll take a look later unless somebody picks it up. > >> > > >> > Regards, > >> > Tim > >> > > >> > > >> > -- > >> > > >> > Tim Ellison ([EMAIL PROTECTED]) > >> > IBM Java technology centre, UK. > >> > > >> > - > >> > Terms of use : http://incubator.apache.org/harmony/mailing.html > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > > Tim Ellison ([EMAIL PROTECTED]) > IBM Java technology centre, UK. > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] define pre-commit testing configs to gain the stability
On 9 October 2006 at 16:12, "Pavel Ozhdikhin" <[EMAIL PROTECTED]> wrote: > On 10/9/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > Rana Dasgupta wrote: > > > We need to check both release and debug builds...the binaries and timing > > > characteristics are too different. At this immediate stage of the > > > project, I > > > would suggest leaving out EM64T as part of mandatory testing( unless it i > s > > > EM64T specific functionality, eg., codegen ). Too few contributors and > > > committers have access to it. We are not yet at a stage where we can make > > > this mandatory. > > > > > > If possible all submissions should be tested( by submitters ) on all the > > > combinations identified . It is actually more urgent for submitters to do > > > this. We should stop patches by email. Also, at this point, it is an hono > r > > > system, we can't attach 6 before and after test logs to each JIRA > > > submission. The committer could randomly check on one or more combination > , > > > ...the more the better obviously. > > > > > > In some cases, submissions will be platform specific ( eg., very new code > > > like GC V5, platform specific bug fixes or a simple case of developer not > > > having all the machines ). I would leave these to the committers' > > > discretion. > > > > Mandating that patches are pre-tested on a wide variety of machines is > > not conducive to building a broad community of contributors since very > > few people have access to all the machines and configurations we are > > interested in. I'd much prefer that we work optimistically and have > > lots of people regularly building and testing the code to get the > > broadest possible coverage. We can backtrack if problems arise. Agreed. Broadest possible coverage is much more important. > Even is a committer does't have a wide variety of machines I think we > can still mandate that his/her commits are checked on the right > configuration. You'd also need to mandate linker versions and assembler versions too. > If the majority works on GCC 4.0.3 checking the patch on GCC 3.3.2 > might not reveal the problems. Regular testing will, but the time > spend on backtracking is lost. The proposal is not only about variety > of configurations but is also about configurations themselves. Rana > proposed to exclude EM64T and add debug configs, so for now the list > is following: > > - Windows / IA32 / MSVS .NET 2003 / release > - Windows / IA32 / MSVS .NET 2003 / debug > - Linux / IA32 / GCC 4.0.3 / release > - Linux / IA32 / GCC 4.0.3 / debug > - Linux / EM64T / GCC 4.0.3 / release > - Linux / EM64T / GCC 4.0.3 / debug (the last two are questionable, > but at least Geir has a machine) I'm a committer. I test most patches on my ia32 thinkpad, which is running Debian/testing (mostly). I've got the following compilers installed: gcc-2.95 gcc-3.0 gcc-3.2 gcc-3.3 gcc-3.4 gcc-4.0 gcc-4.1 It turns out that my gcc-4.0 despite belonging to a package with a version number of "4.0.3-3" might not be gcc-4.0.3 because "gcc -v" says: gcc-4.0 (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3) So I guess my 4.0.3 and, for example, Geir's on ubuntu are probably different. I don't plan to compile a new version of 4.0.3 from fresh sources (or install the ubuntu version or anything like that) because: 1) I don't think it matters that much 2) Next week we'd probably find a binutils problem and I'm definitely not changing that. 3) I actually think diversity is ok. I've not really seen a huge amount of problems with different gcc versions. And if there are problems with compiler incompatibilities then I want them to receive focus quickly - breaking is a good way to get peoples attention. What I'd really not want is for problems to go unnoticed because all the committers have spent time setting up their machines to be identical. > Assuming you are testing you commits on one of the machines above, do > you agree it make sense all committers to use the same configuration? No. > For example, if you use Linux/IA32 and another committer uses > Linux/IA32, do you agree that it makes sense to use the same compiler > versions for pre-commit testing? No. I agree that if all committers used exactly the same versions of compilers, linkers, etc. then we would most likely *see* fewer problems. However, I wouldn't sleep better because I'd know that the problems were still there waiting to bite us later. Personally I'd rather see problems as soon as possible. > Contributors are still free to check their patches whenever they want > or don't test them at all, but they should know what to expect from > the committers. Why? If a contributor submits a patch that they tested with gcc 4.0.3 but that doesn't work for me with my gcc 4.0.[3/4] whatever it really is then I'm really not going to be upset about it. It just means we've learnt a valuable lesson that we'd not have learnt if I was running the identical 4.0.3. "Contributors don't have to test
Re: [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and recommend to add them to fetch-depends target
On 8 October 2006 at 16:39, "Leo Li" <[EMAIL PROTECTED]> wrote: > > Hi, all > Current harmony build script on linux requires liblcms.a libpng.a and > several .h files such as png.h but not installed on my redhat linux > platform. Although as the script prompts out, ubuntu can download such files > seperately, while other platform such as my redhat or suse, rpm might be the > only source to get new softwares from internet which leads to a lot of > troubles. For examples, the dependency between those rpms and the default > installation destinations of these rpms are not the places Harmony script > expects. > So, I think, it will be good if the build script can download these > required files automatically when they are absent. Can you not just use yum or whatever tools Red Hat provides? Can you document what you had to do? Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] build problem.... I'm forgetting something obvious...
Nathan, yeah that's probably it. It's caught me out a couple of times. Is that swing test fix ready? If not perhaps we should just exclude it, and then I can dump the with.awt.swing property for good? Regards, Mark. On 7 October 2006 at 14:29, "Nathan Beyer" <[EMAIL PROTECTED]> wrote: > Are you running build with "-Dwith.awt.swing=true"? I had some weird > problems yesterday and it just seemed that I wasn't consistently using > that property for all ant runs. > > -Nathan > > On 10/7/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > still on that new machine. > > > > classlib builds fine, but "ant test" results in it appearing to be very, > > very confused when trying to compile, with the first module, > > accessibility. > > > > It can't find things like "BasicSwingTestCase", although I can confirm > > that it was build in test_support... > > > > I figure I forgot something obvious... > > > > geir > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
On 6 October 2006 at 9:41, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > > > Vladimir Ivanov wrote: > > While nobody objects :) the right place for coverage scripts is 'buildtest' > > module. > > > > Seems, that this module should be a little bit reorder: new top level > > directories should be created: > > > > - 'cc' - for cruise control script (and move current stuff to this dir); > > > > - 'coverage' - for coverage scripts (It will nice if somebody also placed > > here data from issue 564); > > > > - 'japi' - for script to run 'japi'-tool. > > Agreed on all three. Do we have a japi script? I have one but it's a little specific to the wrapper we use for the builds that report to the -commits list. But I can provide it if it will help. -Mark. > > Seems, that directory 'tests' also should be created in this module to > > place non-unit tests when we will have one. > > > > > > > > thanks, Vladimir > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (HARMONY-1317) [classlib][internationalization]Internationalization of the rmi module
On 6 October 2006 at 9:57, Tim Ellison <[EMAIL PROTECTED]> wrote: > Mark beat me to it, so you are in good hands. And slightly regretting it... it's a big patch and one that's worth being careful with ... mixing up messages would be very confusing. It is interesting to note that many of the messages are for logging and output to the console. > When it comes to some of the other big modules you could do it > incrementally, i.e. submit patches that migrate packages to the new > framework; they should work fine in parallel during the transition. Agreed. That might make it easier to check the patches too. > Keep up the good work. Yes. These must be even more painful to generate than they are too read. Many thanks for doing this. I've spotted a couple of minor issues reading the patch[0] but I'll probably submit it as is unless I spot anything serious and fix them in a later commit. Regards, Mark. [0] Such as rmi.log.8D which is only used in an exception not a logging call. I wouldn't want this to break if/when Tim removes the logging. > Ilya Okomin wrote: > > Hi committers! > > > > Could someone look into the patch with [rmi] internationalization > > HARMONY-1317? > > Patch affects many source files and it would be great to apply it ASAP (if > > it is OK of course:)) to avoid conflicts with another changes in the > > Harmony > > svn. > > > > Thanks, > > Ilya. > > > > > > On 10/4/06, Ilya Okomin (JIRA) <[EMAIL PROTECTED]> wrote: > >> > >> [ http://issues.apache.org/jira/browse/HARMONY-1317?page=all ] > >> > >> Ilya Okomin updated HARMONY-1317: > >> - > >> > >>Attachment: rmi.diff > >> > >> Wow, it was really hard work! > >> Please try this patch. > >> > >> > [classlib][internationalization]Internationalization of the rmi module > >> > -- > >> > > >> > Key: HARMONY-1317 > >> > URL: http://issues.apache.org/jira/browse/HARMONY-1317 > >> > Project: Harmony > >> > Issue Type: Sub-task > >> > Components: Classlib > >> >Reporter: Ilya Okomin > >> >Priority: Trivial > >> > Attachments: rmi.diff > >> > > >> > > >> > [rmi] module should be internationalized with the scheme suggested in > >> HARMONY-1308 issue [1]. > >> > [1] http://issues.apache.org/jira/browse/HARMONY-1308 > >> > >> -- > >> This message is automatically generated by JIRA. > >> - > >> If you think it was sent incorrectly contact one of the administrators: > >> http://issues.apache.org/jira/secure/Administrators.jspa > >> - > >> For more information on JIRA, see: http://www.atlassian.com/software/jira > >> > >> > >> > > > > > > -- > > Tim Ellison ([EMAIL PROTECTED]) > IBM Java technology centre, UK. > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Print module tests
On 5 October 2006 at 23:25, "Alexey Petrenko" <[EMAIL PROTECTED]> wrote: > 2006/10/5, Mark Hindess <[EMAIL PROTECTED]>: > > > > On 5 October 2006 at 19:51, "Alexey Petrenko" > > <[EMAIL PROTECTED]> wrote: > > > Mark, > > > > > > I've finished with the build files. At least I hope so :) > > > > > > Check the HARMONY-1729 issue. > > > > > > I've also added a comment to HARMONY-1609. > > > > Excellent! > > > > This is trivial but I noticed that the MANIFEST files need a few tweaks. > > The import and export lines should be something like: > > > > Import-Package: java.awt, > > java.awt.color, > > java.awt.image, > > java.io, > > java.net, > > java.nio, > > java.util, > > org.apache.harmony.awt.datatransfer, > > org.apache.harmony.awt.gl.image > > Export-Package: javax.imageio, > > javax.imageio.event, > > javax.imageio.metadata, > > javax.imageio.plugins.jpeg, > > javax.imageio.spi, > > javax.imageio.stream > > > > [snip] > > how did you produce these lists? Do you have some tool? I just used a quick find/xargs/perl command on the command line. Now I look at it in my history, I notice it wouldn't even have worked for some of the bigger modules. Not really worth sharing IMHO. -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Print module tests
On 5 October 2006 at 19:51, "Alexey Petrenko" <[EMAIL PROTECTED]> wrote: > Mark, > > I've finished with the build files. At least I hope so :) > > Check the HARMONY-1729 issue. > > I've also added a comment to HARMONY-1609. Excellent! This is trivial but I noticed that the MANIFEST files need a few tweaks. The import and export lines should be something like: Import-Package: java.awt, java.awt.color, java.awt.image, java.io, java.net, java.nio, java.util, org.apache.harmony.awt.datatransfer, org.apache.harmony.awt.gl.image Export-Package: javax.imageio, javax.imageio.event, javax.imageio.metadata, javax.imageio.plugins.jpeg, javax.imageio.spi, javax.imageio.stream Import-Package: java.awt, java.awt.RenderingHints, java.awt.event, java.awt.font, java.awt.geom, java.awt.image, java.awt.image.renderable, java.io, java.lang.reflect, java.net, java.nio, java.security, java.text, java.util, javax.swing, javax.swing.border, javax.swing.event, javax.swing.text Export-Package: javax.print, javax.print.attribute, javax.print.attribute.standard, javax.print.event Import-Package: java.awt, java.awt.event, java.io, java.net, java.security, java.util, javax.accessibility, org.apache.harmony.awt, org.apache.harmony.kernel.vm Export-Package: java.applet and the Bundle-SymbolicName for org.apache.harmony.imageio has a spurious .x in it. Regards, Mark. > 2006/10/5, Mark Hindess <[EMAIL PROTECTED]>: > > > > On 5 October 2006 at 16:39, "Alexey Petrenko" <[EMAIL PROTECTED]> > wrote: > > > Guys, > > > > > > I'm working on build files for Applet/ImageIO/Print modules contribution. > .. > > > > > > Number of print modules tests fails if there is no printer in the > > > system. Should I exclude such tests? > > > > Yes. Please. > > > > I got impatient (because of the vote) and started a build patch too. > > I've got pretty far but imageio needs more work. How far have you got > > with yours? I can attach mine to the jira if it might help. > > > > Regards, > > Mark. > > > > > SY, Alexey > > > > > > -- > > > Alexey A. Petrenko > > > Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Print module tests
On 5 October 2006 at 17:21, "Alexey Petrenko" <[EMAIL PROTECTED]> wrote: > Easiest way will be to move JpegEncoder.c from awt to imageio module. > Since awt does not really use it. Yes. That's what I did. ;-) (And is why I noticed it was broken.) -Mark. > > 2006/10/5, Mark Hindess <[EMAIL PROTECTED]>: > > > > On 5 October 2006 at 14:02, Mark Hindess <[EMAIL PROTECTED]> wrot > e: > > > > > > On 5 October 2006 at 16:39, "Alexey Petrenko" <[EMAIL PROTECTED] > m> w > > > rote: > > > > Guys, > > > > > > > > I'm working on build files for Applet/ImageIO/Print modules contributio > n... > > > > > > > > Number of print modules tests fails if there is no printer in the > > > > system. Should I exclude such tests? > > > > > > Yes. Please. > > > > > > I got impatient (because of the vote) and started a build patch too. > > > I've got pretty far but imageio needs more work. How far have you got > > > with yours? I can attach mine to the jira if it might help. > > > > Another observation, JpegEncoder.c in the awt module seems more up to > > date than the version included in the contribution. (It uses the > > exception unified exception methods from the luni common module and > > doesn't include the jpegint.h header for example.) > > > > Can we use the awt one please? > > > > Regards, > > Mark. > > > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Alexey A. Petrenko > Intel Middleware Products Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1609 - bulk contribution of Applet, ImageIO and Print modules
+1 On 3 October 2006 at 12:34, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > BCC and ACQs in place. > > [ ] +1 Yes, accept the contribution > [ ] -1 No, don't. reason : > > > As usual, 3 days or until all committers vote, or there is an > objection/request for continuance > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Print module tests
On 5 October 2006 at 18:48, "Alexey Petrenko" <[EMAIL PROTECTED]> wrote: > It will not easier actually... > Because JpegEncoder.c from awt need few fixes too :) I thought I'd fixed it an hour ago in r453231. ;-) -Mark. > 2006/10/5, Mark Hindess <[EMAIL PROTECTED]>: > > > > On 5 October 2006 at 15:03, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > > > > To maintain unbroken traceability we should commit the original > > > contribution first then massage it. No objection to the plan. > > > > Agreed. I mentioned it because the build code that Alexey is working on > > is easier with the new version. For example, because he doesn't need to > > put jpegint.h (that we took out) back into fetch-depends. > > > > -Mark. > > > > > Mark Hindess wrote: > > > > On 5 October 2006 at 14:02, Mark Hindess <[EMAIL PROTECTED]> > wrot > > > e: > > > >> On 5 October 2006 at 16:39, "Alexey Petrenko" <[EMAIL PROTECTED] > .com > > > > w > > > >> rote: > > > >>> Guys, > > > >>> > > > >>> I'm working on build files for Applet/ImageIO/Print modules contribut > ion. > > > .. > > > >>> > > > >>> Number of print modules tests fails if there is no printer in the > > > >>> system. Should I exclude such tests? > > > >> Yes. Please. > > > >> > > > >> I got impatient (because of the vote) and started a build patch too. > > > >> I've got pretty far but imageio needs more work. How far have you got > > > >> with yours? I can attach mine to the jira if it might help. > > > > > > > > Another observation, JpegEncoder.c in the awt module seems more up to > > > > date than the version included in the contribution. (It uses the > > > > exception unified exception methods from the luni common module and > > > > doesn't include the jpegint.h header for example.) > > > > > > > > Can we use the awt one please? > > > > > > > > Regards, > > > > Mark. > > > > > > > > > > > > > > > > - > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > -- > > > > > > Tim Ellison ([EMAIL PROTECTED]) > > > IBM Java technology centre, UK. > > > > > > - > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Alexey A. Petrenko > Intel Middleware Products Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Print module tests
On 5 October 2006 at 15:03, Tim Ellison <[EMAIL PROTECTED]> wrote: > > To maintain unbroken traceability we should commit the original > contribution first then massage it. No objection to the plan. Agreed. I mentioned it because the build code that Alexey is working on is easier with the new version. For example, because he doesn't need to put jpegint.h (that we took out) back into fetch-depends. -Mark. > Mark Hindess wrote: > > On 5 October 2006 at 14:02, Mark Hindess <[EMAIL PROTECTED]> wrot > e: > >> On 5 October 2006 at 16:39, "Alexey Petrenko" <[EMAIL PROTECTED] > > w > >> rote: > >>> Guys, > >>> > >>> I'm working on build files for Applet/ImageIO/Print modules contribution. > .. > >>> > >>> Number of print modules tests fails if there is no printer in the > >>> system. Should I exclude such tests? > >> Yes. Please. > >> > >> I got impatient (because of the vote) and started a build patch too. > >> I've got pretty far but imageio needs more work. How far have you got > >> with yours? I can attach mine to the jira if it might help. > > > > Another observation, JpegEncoder.c in the awt module seems more up to > > date than the version included in the contribution. (It uses the > > exception unified exception methods from the luni common module and > > doesn't include the jpegint.h header for example.) > > > > Can we use the awt one please? > > > > Regards, > > Mark. > > > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > > Tim Ellison ([EMAIL PROTECTED]) > IBM Java technology centre, UK. > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Trying to catch patternset errors earlier
On 5 October 2006 at 10:05, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > Before you do that... you would be putting similar information in the > build.xml file? Or am I misunderstanding something? having it in the > patternset does make it easy to find stuff :) I'll be putting something in the build.xml file ... the ant from the accessibility example below. That is a patternset that just figures everything out from the source tree. Essentially it's just saying include build/classes/blah if: 1) blah is also in the source tree - a resource file for example 2) there is a corresponding blah.java file in the source tree I've never really looked in the patternset files when trying to find something. I'd just look in the src/main/java tree or the jar table of contents. What do you use the patternsets for? Regards, Mark. > Mark Hindess wrote: > > Ok. There haven't been any shouts against it so. I'm going to split > > the .java files that contain two classes and then dump the patternsets. > > > > Regards, > > Mark. > > > > On 3 October 2006 at 11:27, Oliver Deakin <[EMAIL PROTECTED]> wr > ote: > >> Mark Hindess wrote: > >>> On 28 September 2006 at 14:58, "Alexey Petrenko" <[EMAIL PROTECTED] > .c > >> om> wrote: > >>> > >>>> 2006/9/28, Mark Hindess <[EMAIL PROTECTED]>: > >>>> > >>>>> On 28 September 2006 at 14:30, "Alexey Petrenko" <[EMAIL PROTECTED] > il > >> .c > >>>>> > >>>> om> wrote: > >>>> > >>>>>> I think that it will be better to add another target to build for > >>>>>> this check. > >>>>>> Because of two reasons: > >>>>>> 1. It is unclear that clean is also checks something > >>>>>> > >>>>> This simple check can only happen part way through the clean target - > >>>>> after the modules have done their cleaning and before the top-level > >>>>> cleanup is done. > >>>>> > >>>> I see your point. > >>>> > >>>> But let's review the sitatuation from another viewpoint... > >>>> What do we need in general? > >>>> We need up-to-date list of all packages in the specified module. Right? > >>>> If so we can create simple script to update patternset files... Or > >>>> even create them at build time. But will cost us build time itself :) > >>>> > >>> That's a reasonable point. I had a look at what it would take to get > >>> rid of the patternsets completely. It's quite easy for some modules. > >>> For example, for accessibility, we can just replace the "classes" > >>> fileset with: > >>> > >>> > >>> > >>> > >>> > >>> >>> from="^(.*?)(\$$[^/\\\.]*)?\.class$$" > >>> to="\1.java"/> > >>> > >>> > >>> > >>> > >>> Which basically says include files if they are also present in > >>> the source directory - typically resource files - or if they are > >>> .class files and have an obviously-named source file in the source > >>> directory[0]. > >>> > >> +1 to building the patternset on the fly rather than relying on file > >> lists being manually > >> kept up to date. I can't see any reason for keeping the patternset files. > >> > >>> This works for most modules. The present tags are duplicated for > >>> modules with platform source directories. > >>> > >>> However, it doesn't work very well for awt, beans, jndi, luni, and > >>> security. Why? Because they have some source files defining two > >>> classes. For instance, java.awt.ContextImpl defined in: > >>> > >>> modules/awt/src/main/java/common/java/awt/Component.java > >>> > >>> We could hardcode these special case - there are only a few. Or perhaps > >>> we could split them in to distinct source files? > >>> > >> I'd go for splitting them out into separate files - hardcoding them > >> means that you're still > >> keeping a manual fi
Re: [jira] Bugs priorities
On 5 October 2006 at 20:05, "Mikhail Fursov" <[EMAIL PROTECTED]> wrote: > > The priority of the bug could be the priority of the scenario this bug > affects. > So, we need to select some applications/scenarios and if one of these > applications failed - the bug is blocker or critical. > > Major as default priority is OK (imo) because it's in the middle of the > list. That logic only really works for me if the distribution of bugs by priority is even. So for example we'd have as many 'critical' bugs as 'trivial' ones. I don't think (I hope!) that we do. Most of our JIRA are classified as major. Most of the bugs described in the JIRA issues are actually minor or trivial. I honestly think the classifications would better reflect reality if we changed this. Regards, Mark. > On 10/5/06, Anton Luht <[EMAIL PROTECTED]> wrote: > > > > Hello, Salikh, > > > > I just suggest rules to be written explicitly. Every bug submitter > > tends to think that his bug or his application is the most important - > > some limits should be put to avoid 90% of bugs being major and > > critical. > > > > On 10/5/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote: > > > Anton Luht wrote: > > > > Hello, > > > > > > > > Maybe it's worth to explicitly specify priorities for various kinds of > > > > bugs? The advice that appears now near 'priority' drop-down in JIRA > > > > list is general and not Harmony-specific. Bug submitters make decision > > > > mostly by his/her intuition. > > > > > > > > An example of rule set: VM hangs & crashes - critical, Junit tests > > > > failures - major, application failures - major, exception > > > > incompatibility - minor. > > > > > > And what guidelines would you recommend for the corner cases, > > > when something is important for some people, and does not matter for > > others? > > > > > > For example, some people are trying to get Harmony to run x86_64 and > > ia64 platforms, > > > while most of the project participants just do not care. > > > > > > > > > - > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Regards, > > Anton Luht, > > Intel Middleware Products Division > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Mikhail Fursov > > --=_Part_20534_19790021.1160053532326-- > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Print module tests
On 5 October 2006 at 14:02, Mark Hindess <[EMAIL PROTECTED]> wrote: > > On 5 October 2006 at 16:39, "Alexey Petrenko" <[EMAIL PROTECTED]> w > rote: > > Guys, > > > > I'm working on build files for Applet/ImageIO/Print modules contribution... > > > > Number of print modules tests fails if there is no printer in the > > system. Should I exclude such tests? > > Yes. Please. > > I got impatient (because of the vote) and started a build patch too. > I've got pretty far but imageio needs more work. How far have you got > with yours? I can attach mine to the jira if it might help. Another observation, JpegEncoder.c in the awt module seems more up to date than the version included in the contribution. (It uses the exception unified exception methods from the luni common module and doesn't include the jpegint.h header for example.) Can we use the awt one please? Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Print module tests
On 5 October 2006 at 16:39, "Alexey Petrenko" <[EMAIL PROTECTED]> wrote: > Guys, > > I'm working on build files for Applet/ImageIO/Print modules contribution... > > Number of print modules tests fails if there is no printer in the > system. Should I exclude such tests? Yes. Please. I got impatient (because of the vote) and started a build patch too. I've got pretty far but imageio needs more work. How far have you got with yours? I can attach mine to the jira if it might help. Regards, Mark. > SY, Alexey > > -- > Alexey A. Petrenko > Intel Middleware Products Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][depends] missing liblcms +em64t
On 5 October 2006 at 15:20, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote: > On 10/5/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > > On 5 October 2006 at 13:48, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote > : > > > Readme is quite helpful. Yesterday, I used google to locate thouse lcms l > ibra > > > ry. > > > > > > IMHO, if the build system displayed the link to the README.txt it > > > could be much easier to deal with the issue. > > > > Hmm... it should already? I checked a fix yesterday. > > > > -Mark. > > Yes, it is already there. > > BTW, to build on EM64T with 32-bit JDK, I need to add one additional > command line switch now: >ant -Dos.arch=x86_64 -Dhy.arch=x86_64 Hmm... You have to see hy.arch too? That's not right. Should be better in r453201. -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch][drlvm] Fix compilation on Linux/x86_64
On 5 October 2006 at 13:57, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote: > On 10/4/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote: > > > Salikh Zakirov wrote: > > >> The patch turned out to be exact duplicate of HARMONY-1571. > > >> Besides, there exist a patch with fixes for unit tests: HARMONY-1574. > > >> > > >> The following change is needed on top of already committed HARMONY-1551 > > >> to make DRLVM start on Linux/x86_64. > > >> > > >> However, it still doesn't work properly, failing with > > >> java: /files/sszakiro/harmony/drlvm/trunk/vm/gc/src/gc_types.h:167: > > >> Partial_Reveal_VTable* Partial_Reveal_Object::vtable(): Assertion > > >> `!(vt() & 1)' failed. > > > > The assertion failure were caused by the leftover patch from HARMONY-1372, > > which didn't make it to SVN (gcv41_em64t_vm_changes.diff) > > Yes, looks like I forget the change when I have made the last patch in > the HARMONY-1372. The patch gcv41_em64t_vm_changes.diff is still in > the JIRA. I can create new JIRA issue or one of the commiters can add > this missing piece to svn. Geir? Unless Geir gets there first I was planning to look at this in the new JIRA http://issues.apache.org/jira/browse/HARMONY-1698 -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Bugs priorities
On 5 October 2006 at 14:37, "Anton Luht" <[EMAIL PROTECTED]> wrote: > Hello, > > Maybe it's worth to explicitly specify priorities for various kinds of > bugs? The advice that appears now near 'priority' drop-down in JIRA > list is general and not Harmony-specific. Bug submitters make decision > mostly by his/her intuition. > > An example of rule set: VM hangs & crashes - critical, Junit tests > failures - major, application failures - major, exception > incompatibility - minor. Good call. And I still stand by what I suggested the other day that the default should be minor as too many trivial issues are submitted with the current default of 'major'. If it isn't important enough for the submitter to use the drop-down it must be minor. ;-) -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][depends] missing liblcms +em64t
On 5 October 2006 at 13:48, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote: > Readme is quite helpful. Yesterday, I used google to locate thouse lcms libra > ry. > > IMHO, if the build system displayed the link to the README.txt it > could be much easier to deal with the issue. Hmm... it should already? I checked a fix yesterday. -Mark. > On 10/4/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > Ivan, > > I went through all this a few minutes ago ( on 32 bit RedHat enterprise > > Linux ). The summary is that if you don't have the littlecms package, you > > need to download it from > > http:// www.littlecms.com > > and build and deploy it in your dependencies. See the README in > > depends/libs/build. > > > > Rana > > -- > Ivan > Intel Middleware Products Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Trying to catch patternset errors earlier
Ok. There haven't been any shouts against it so. I'm going to split the .java files that contain two classes and then dump the patternsets. Regards, Mark. On 3 October 2006 at 11:27, Oliver Deakin <[EMAIL PROTECTED]> wrote: > Mark Hindess wrote: > > On 28 September 2006 at 14:58, "Alexey Petrenko" <[EMAIL PROTECTED] > om> wrote: > > > >> 2006/9/28, Mark Hindess <[EMAIL PROTECTED]>: > >> > >>> On 28 September 2006 at 14:30, "Alexey Petrenko" <[EMAIL PROTECTED] > .c > >>> > >> om> wrote: > >> > >>>> I think that it will be better to add another target to build for > >>>> this check. > >>>> Because of two reasons: > >>>> 1. It is unclear that clean is also checks something > >>>> > >>> This simple check can only happen part way through the clean target - > >>> after the modules have done their cleaning and before the top-level > >>> cleanup is done. > >>> > >> I see your point. > >> > >> But let's review the sitatuation from another viewpoint... > >> What do we need in general? > >> We need up-to-date list of all packages in the specified module. Right? > >> If so we can create simple script to update patternset files... Or > >> even create them at build time. But will cost us build time itself :) > >> > > > > That's a reasonable point. I had a look at what it would take to get > > rid of the patternsets completely. It's quite easy for some modules. > > For example, for accessibility, we can just replace the "classes" > > fileset with: > > > > > > > > > > > > > from="^(.*?)(\$$[^/\\\.]*)?\.class$$" > > to="\1.java"/> > > > > > > > > > > Which basically says include files if they are also present in > > the source directory - typically resource files - or if they are > > .class files and have an obviously-named source file in the source > > directory[0]. > > > > +1 to building the patternset on the fly rather than relying on file > lists being manually > kept up to date. I can't see any reason for keeping the patternset files. > > > This works for most modules. The present tags are duplicated for > > modules with platform source directories. > > > > However, it doesn't work very well for awt, beans, jndi, luni, and > > security. Why? Because they have some source files defining two > > classes. For instance, java.awt.ContextImpl defined in: > > > > modules/awt/src/main/java/common/java/awt/Component.java > > > > We could hardcode these special case - there are only a few. Or perhaps > > we could split them in to distinct source files? > > > > I'd go for splitting them out into separate files - hardcoding them > means that you're still > keeping a manual file list for those classes. Does anyone have an issue > with separating > these classes out? > > > I have some patches ready to make this change but I've not committed > > anything. > > > > Personally I think getting rid of the patternsets would be a good idea > > since it reduces the coupling - although really the coupling is only > > strictly necessary for luni and security. > > > > It is important to note that even if we do something like this, leaving > > the catch-all check in the clean target still helps stop problems - if > > people forget to add the hardcoded special cases or if we split them > > people add new source defining two classes in one file. > > > > Agreed - keeping the clean target check helps us make sure that no one > breaks the > jar packaging in the future. As long as it completes the clean before > failing, that's > fine. > > Regards, > Oliver > > > Regards, > > Mark. > > > > [0] The simpler '' > > doesn't work because it misses inner classes. > > > > > >>>> 2006/9/28, Mark Hindess <[EMAIL PROTECTED]>: > >>>> > >>>>> On 28 September 2006 at 11:07, Tim Ellison <[EMAIL PROTECTED]> wrot > >>>>> > >> e: > >> > >>>>>> Sounds reasonable. The alternative is to not make clean fail, just > >>&g
Re: Fwd: [jira] Created: (HARMONY-1707) find_stack_* signals_em64t.cpp patch
On 5 October 2006 at 3:02, Naveen Neelakantam <[EMAIL PROTECTED]> wrote: > > Mark (or whomever), > > This patch should be applied. It fixes a bug introduced by another > one of my patches. Whoops. Fixed. Thanks. -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch][drlvm] Linux/ia32 fix for Intel Compiler
Salikh, I've applied this fix in r453130. But in future please raise a JIRA. (As it happens I need this fix to workaround problems I was having on x86_64 otherwise I'd have probably been more hesitant about applying it.) Regards, Mark. On 4 October 2006 at 17:25, Salikh Zakirov <[EMAIL PROTECTED]> wrote: > Hi, > > DRLVM compiled with Intel Compiler 9.0 on Linux/ia32 currently > does not work due to symbol 'clock_gettime' not being found. > > A simple build file fix is needed to solve the problem. > It does not affect DRLVM built with gcc. > (Gcc build still works with this modification). > > Could anyone commit this change? > Thanks a lot! > > --- a/build/make/components/vm/hythr.xml > +++ b/build/make/components/vm/hythr.xml > @@ -95,6 +95,7 @@ vm.port,extra.log4cxx, extra.aprutil" /> > > > > + > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][x86_64] libhythr.so linking problem
I get compilation problems on x86_64. It looks to me like a gcc/binutils issue: [exec] cc -shared -Wl,--version-script,libhythr.exp \ [exec] -Wl,-soname=libhythr.so -o ../libhythr.so \ [exec] ../shared/thread_copyright.o x86_64/thrhelp.o x86_64/thrspinlock.o hythread.o ../shared/hythreadinspect.o linuxonexit.o priority.o rasthrsup.o ../shared/rwmutex.o thrcreate.o thrdsup.o ../shared/thrprof.o -lpthread \ [exec] -Xlinker --start-group /home/beanz/hy/Harmony.new/deploy/lib/libhypool.a /home/beanz/hy/Harmony.new/deploy/lib/libhycommon.a -Xlinker --end-group \ [exec] -lc -lm -ldl [exec] /usr/bin/ld: x86_64/thrspinlock.o: relocation R_X86_64_PC32 against `hythread_yield' can not be used when making a shared object; recompile with -fPIC [exec] /usr/bin/ld: final link failed: Bad value [exec] collect2: ld returned 1 exit status [exec] make: *** [../libhythr.so] Error 1 Anyone any ideas? Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][depends] missing liblcms +em64t
On 4 October 2006 at 16:10, Mark Hindess <[EMAIL PROTECTED]> wrote: > > On 4 October 2006 at 18:26, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote: > > Working on a patch, I've just wanted to check wether it works on em64t. > > It is not that easy as I expected. Yesterday, I have filed > > HARMONY-1676 to have classlib built. > > Today, I have: > > > > Missing dependency. The file from: > > /usr/lib/liblcms.a > > should be linked to: > > depends/libs/build/lcms/liblcms.ia32 > > > > But /usr/lib/liblcms.a doesn't exist. > > liblcms development package not installed > > For Debian/Ubuntu try: apt-get install liblcms1-dev > > > > > > First of all, why 'ia32' prefix for em64t build? > > One second look, this seems to be a different problem. It looks like I > accidentally hardcode ia32 - but since that's all that we really support > at the moment then I'm not that sorry. > > The wider issue is that for historical reasons the awt build still uses > ia32 and ipf where as it should probably be fixed to use the hy.arch > defines of x86 and x86_64 (and ia64 if necessary but we don't really > cover that yet anyway). > > Patches welcome or I'll try to take a look in the next day or so. I've checked in a quick hack (r452910) that should workaround the problem until we resolve the wider issue with the inconsistent architecture variables. Let me know how you get on with the x86_64 building. (It fails for me with a compiler/binutils bug sadly.) Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][depends] missing liblcms +em64t
On 4 October 2006 at 18:26, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote: > Working on a patch, I've just wanted to check wether it works on em64t. > It is not that easy as I expected. Yesterday, I have filed > HARMONY-1676 to have classlib built. > Today, I have: > > Missing dependency. The file from: > /usr/lib/liblcms.a > should be linked to: > depends/libs/build/lcms/liblcms.ia32 > > But /usr/lib/liblcms.a doesn't exist. > liblcms development package not installed > For Debian/Ubuntu try: apt-get install liblcms1-dev > > > First of all, why 'ia32' prefix for em64t build? One second look, this seems to be a different problem. It looks like I accidentally hardcode ia32 - but since that's all that we really support at the moment then I'm not that sorry. The wider issue is that for historical reasons the awt build still uses ia32 and ipf where as it should probably be fixed to use the hy.arch defines of x86 and x86_64 (and ia64 if necessary but we don't really cover that yet anyway). Patches welcome or I'll try to take a look in the next day or so. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (HARMONY-1676) [classlib][depends] Missing em64t version of icu libraries
On 4 October 2006 at 18:41, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote: > On 10/4/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > > On 4 October 2006 at 12:59, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote > : > > > On 10/4/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > > > > > > On 3 October 2006 at 8:12, "Ivan Volosyuk (JIRA)" <[EMAIL PROTECTED]> > > > > wro > te: > > > > > [ http://issues.apache.org/jira/browse/HARMONY-1676?page=comments > #act > > > ion_ > > > > > 12439536 ] > > > > > > > > > > Ivan Volosyuk commented on HARMONY-1676: > > > > > > > > > > > > > > > copy these files into depends/libs/linux.x86_64 > > > > > build with 'ant -Dos.arch=x86_64' > > > > > > > > I've just checked in a change to make/properties.xml (as r452774) that > > > > should add os.arch normalization for x86_64. (This basically duplicate > s > > > > what we did to handle the way the os.arch variables differ between > > > > reference jdks.) > > > > > > > > So, hopefully, you shouldn't need -Dos.arch=x86_64 any more. If it > > > > doesn't work, can you let me know what os.arch says for the jdk you are > > > > using. > > > > > > > > Thanks, > > > > Mark. > > > > > > Well, I didn't download 64 bit version jdk, so I've just used the 32 > > > bit version which works just fine on 64 bit version of linux. > > > Jdk I use is: > > > jrockit-jdk1.5.0-linux-ia32 (build 1.5.0-b64) > > > > And what is os.arch is set to? x86 or i386 or something? > > > > Probably not much we can do about that. Except perhaps create a user > > preferences file. > > I don't know, looks like that. Well, I am happy with current state. It > is often quite painful for me to have number of property files. I'm not sure I understand your pain, but don't worry any user properties files will be entirely optional. You could always run a x86_64 jdk? Regards, Mark. > -- > Ivan > Intel Middleware Products Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/depends.xml
Since most (all?) distributions provide versions of these libraries (and
maintain them - "regular" security fixes for example) why would we want
to maintain them ourselves? It's not a job I'd want.
Really the same is true for zlib and to an extent icu. If someone
else is doing the work maintaining them, we should use what they are a
providing not make more work for ourselves. We should also try to use
the dynamic libraries if possible.
With the exception of icu, most of these libraries change very little
over time so there should be few if any interoperability issues.
I can only really see a good argument for maintaining icu binaries since
it is changing more frequently and many distributions seem to have
rather old versions.
Regards,
Mark.
On 4 October 2006 at 10:40, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
> Any reason why we couldn't do the same thing for linux that we're doing
> for windows in terms of having these libraries pre-compiled and easy to
> drop in?
>
> geir
>
> Mark Hindess wrote:
> > With this change, the awt dependencies should now be automated for
> > windows and at least fairly trivial (installing a few packages on
> > Linux[0]). I think it is time we removed the with.awt.swing flag.
> > Anyone object?
> >
> > Please test the current setup with -Dwith.awt.swing=true and report any
> > problems.
> >
> > Regards,
> > Mark.
> >
> > [0] Details of the required packages for distributions other than
> > Debian/Ubuntu would be welcome.
> >
> > On 4 October 2006 at 10:24, [EMAIL PROTECTED] wrote:
> >> Author: hindessm
> >> Date: Wed Oct 4 03:24:29 2006
> >> New Revision: 452826
> >>
> >> URL: http://svn.apache.org/viewvc?view=rev&rev=452826
> >> Log:
> >> Update check/fetch depends targets to handle the awt dependencies.
> >>
> >> Modified:
> >> incubator/harmony/enhanced/classlib/trunk/depends/libs/build/ (props
> ch
> >> anged)
> >> incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x86/
> (pr
> >> ops changed)
> >> incubator/harmony/enhanced/classlib/trunk/make/depends.properties
> >> incubator/harmony/enhanced/classlib/trunk/make/depends.xml
> >>
> >> Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
> >> --
> ---
> >> -
> >> --- svn:ignore (original)
> >> +++ svn:ignore Wed Oct 4 03:24:29 2006
> >> @@ -1,3 +1,4 @@
> >> jpeg
> >> lcms
> >> png
> >> +winxp_2006-09-28.txt
> >>
> >> Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/windows
> .x8
> >> 6/
> >> --
> ---
> >> -
> >> --- svn:ignore (original)
> >> +++ svn:ignore Wed Oct 4 03:24:29 2006
> >> @@ -1 +1,2 @@
> >> msvcr71.dll
> >> +swing_awt_deps_winxp_2006-09-28.tgz
> >>
> >> Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.propertie
> s
> >> URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trun
> k/m
> >> ake/depends.properties?view=diff&rev=452826&r1=452825&r2=452826
> >> ==
> ===
> >> =
> >> --- incubator/harmony/enhanced/classlib/trunk/make/depends.properties (ori
> gin
> >> al)
> >> +++ incubator/harmony/enhanced/classlib/trunk/make/depends.properties Wed
> Oct
> >> 4 03:24:29 2006
> >> @@ -98,3 +98,11 @@
> >> servlet-api.jar=${jetty.dir}/servlet-api-2.5-6.0.0.jar
> >> servlet-api.md5=c27c02fb0a00cc3a7d05ea993a9bf56e
> >> servlet-api.url=${ibiblio.base}/maven2/jetty/servlet-api/2.5-6.0.0/servle
> t-a
> >> pi-2.5-6.0.0.jar
> >> +
> >> +people.apache.base=http://people.apache.org/~geirm/harmony/
> >> +awtdeps.dir=${depends.dir}/libs/windows.x86
> >> +awtdeps.tar=${awtdeps.dir}/swing_awt_deps_winxp_2006-09-28.tgz
> >> +awtdeps.url=${people.apache.base}swing_awt_deps_winxp_2006-09-28.tgz
> >> +awtdeps.md5=d61a27e4b305d9fcabaaacf34f8f534a
> >> +awtdeps.extract.dir=${depends.dir}/libs/build
> >> +awtdeps.testfile=${awtdeps.extract.dir}/winxp_2006-09-28.txt
> >>
> >> Modified: incubator/harmony/enhanced/classlib/trunk/make/depends
Re: [classlib] enabling AWT/Swing by default (was: Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/d
On 4 October 2006 at 15:41, Tim Ellison <[EMAIL PROTECTED]> wrote:
> Excuse the change in subject line...
No problem. I was just cursing myself for having forgotten to change
it.
> Mark Hindess wrote:
> > With this change, the awt dependencies should now be automated for
> > windows and at least fairly trivial (installing a few packages on
> > Linux[0]). I think it is time we removed the with.awt.swing flag.
> > Anyone object?
>
> To the contrary, ditch it.
>
> > Please test the current setup with -Dwith.awt.swing=true and report any
> > problems.
>
> Problem 1: My machine is too slow running all these tests.
Mine too. And I have wondered if the hourly builds will finish within
the hour now. We really should see if we can avoid the need to fork
for every test.
Regards,
Mark.
> Regards,
> Tim
>
> > [0] Details of the required packages for distributions other than
> > Debian/Ubuntu would be welcome.
> >
> > On 4 October 2006 at 10:24, [EMAIL PROTECTED] wrote:
> >> Author: hindessm
> >> Date: Wed Oct 4 03:24:29 2006
> >> New Revision: 452826
> >>
> >> URL: http://svn.apache.org/viewvc?view=rev&rev=452826
> >> Log:
> >> Update check/fetch depends targets to handle the awt dependencies.
> >>
> >> Modified:
> >> incubator/harmony/enhanced/classlib/trunk/depends/libs/build/ (props
> ch
> >> anged)
> >> incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x86/
> (pr
> >> ops changed)
> >> incubator/harmony/enhanced/classlib/trunk/make/depends.properties
> >> incubator/harmony/enhanced/classlib/trunk/make/depends.xml
> >>
> >> Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
> >> --
> ---
> >> -
> >> --- svn:ignore (original)
> >> +++ svn:ignore Wed Oct 4 03:24:29 2006
> >> @@ -1,3 +1,4 @@
> >> jpeg
> >> lcms
> >> png
> >> +winxp_2006-09-28.txt
> >>
> >> Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/windows
> .x8
> >> 6/
> >> --
> ---
> >> -
> >> --- svn:ignore (original)
> >> +++ svn:ignore Wed Oct 4 03:24:29 2006
> >> @@ -1 +1,2 @@
> >> msvcr71.dll
> >> +swing_awt_deps_winxp_2006-09-28.tgz
> >>
> >> Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.propertie
> s
> >> URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trun
> k/m
> >> ake/depends.properties?view=diff&rev=452826&r1=452825&r2=452826
> >> ==
> ===
> >> =
> >> --- incubator/harmony/enhanced/classlib/trunk/make/depends.properties (ori
> gin
> >> al)
> >> +++ incubator/harmony/enhanced/classlib/trunk/make/depends.properties Wed
> Oct
> >> 4 03:24:29 2006
> >> @@ -98,3 +98,11 @@
> >> servlet-api.jar=${jetty.dir}/servlet-api-2.5-6.0.0.jar
> >> servlet-api.md5=c27c02fb0a00cc3a7d05ea993a9bf56e
> >> servlet-api.url=${ibiblio.base}/maven2/jetty/servlet-api/2.5-6.0.0/servle
> t-a
> >> pi-2.5-6.0.0.jar
> >> +
> >> +people.apache.base=http://people.apache.org/~geirm/harmony/
> >> +awtdeps.dir=${depends.dir}/libs/windows.x86
> >> +awtdeps.tar=${awtdeps.dir}/swing_awt_deps_winxp_2006-09-28.tgz
> >> +awtdeps.url=${people.apache.base}swing_awt_deps_winxp_2006-09-28.tgz
> >> +awtdeps.md5=d61a27e4b305d9fcabaaacf34f8f534a
> >> +awtdeps.extract.dir=${depends.dir}/libs/build
> >> +awtdeps.testfile=${awtdeps.extract.dir}/winxp_2006-09-28.txt
> >>
> >> Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.xml
> >> URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trun
> k/m
> >> ake/depends.xml?view=diff&rev=452826&r1=452825&r2=452826
> >> ==
> ===
> >> =
> >> --- incubator/harmony/enhanced/classlib/trunk/make/depends.xml (original)
> >> +++ incubator/harmony/enhanced/classlib/trunk/make/depends.xml Wed Oct 4
> 03:
> >> 24:29 2006
> >> @@ -72,17 +72,22 @@
> >>
> >>
> >>
> >> -
> >> + >> +depends="-really-check-win,-awt-tar-extract" />
> &g
Re: [classlib][depends] missing liblcms +em64t
On 4 October 2006 at 18:26, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote: > Working on a patch, I've just wanted to check wether it works on em64t. > It is not that easy as I expected. Yesterday, I have filed > HARMONY-1676 to have classlib built. > Today, I have: > > Missing dependency. The file from: > /usr/lib/liblcms.a > should be linked to: > depends/libs/build/lcms/liblcms.ia32 > > But /usr/lib/liblcms.a doesn't exist. > liblcms development package not installed > For Debian/Ubuntu try: apt-get install liblcms1-dev > > > First of all, why 'ia32' prefix for em64t build? What does: j9 ant properties|grep arch give you? (Aside: I mentioned that these properties might not get set correctly for everyone in a note earlier today, but they are easy to fix with the output from the above generated with a jdk for em64t.) > Secondly, I'm happy for debian users, but not all of the users use > debian. Much informative would be to have a URL with the sources where > I can get the library. I expected that users of other distributions would be able to also have packages available for all of these things. I have asked for details of the package for other distributions in the past but I assumed everyone must use Debian since no one provided any details. Suggesting users build from source should be a last resort. Personally, I'd like to take this further and use the .so versions of the system libraries rather than the static versions. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/depends.xml
With this change, the awt dependencies should now be automated for
windows and at least fairly trivial (installing a few packages on
Linux[0]). I think it is time we removed the with.awt.swing flag.
Anyone object?
Please test the current setup with -Dwith.awt.swing=true and report any
problems.
Regards,
Mark.
[0] Details of the required packages for distributions other than
Debian/Ubuntu would be welcome.
On 4 October 2006 at 10:24, [EMAIL PROTECTED] wrote:
> Author: hindessm
> Date: Wed Oct 4 03:24:29 2006
> New Revision: 452826
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=452826
> Log:
> Update check/fetch depends targets to handle the awt dependencies.
>
> Modified:
> incubator/harmony/enhanced/classlib/trunk/depends/libs/build/ (props ch
> anged)
> incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x86/ (pr
> ops changed)
> incubator/harmony/enhanced/classlib/trunk/make/depends.properties
> incubator/harmony/enhanced/classlib/trunk/make/depends.xml
>
> Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
> -
> -
> --- svn:ignore (original)
> +++ svn:ignore Wed Oct 4 03:24:29 2006
> @@ -1,3 +1,4 @@
> jpeg
> lcms
> png
> +winxp_2006-09-28.txt
>
> Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x8
> 6/
> -
> -
> --- svn:ignore (original)
> +++ svn:ignore Wed Oct 4 03:24:29 2006
> @@ -1 +1,2 @@
> msvcr71.dll
> +swing_awt_deps_winxp_2006-09-28.tgz
>
> Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.properties
> URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
> ake/depends.properties?view=diff&rev=452826&r1=452825&r2=452826
> =
> =
> --- incubator/harmony/enhanced/classlib/trunk/make/depends.properties (origin
> al)
> +++ incubator/harmony/enhanced/classlib/trunk/make/depends.properties Wed Oct
> 4 03:24:29 2006
> @@ -98,3 +98,11 @@
> servlet-api.jar=${jetty.dir}/servlet-api-2.5-6.0.0.jar
> servlet-api.md5=c27c02fb0a00cc3a7d05ea993a9bf56e
> servlet-api.url=${ibiblio.base}/maven2/jetty/servlet-api/2.5-6.0.0/servlet-a
> pi-2.5-6.0.0.jar
> +
> +people.apache.base=http://people.apache.org/~geirm/harmony/
> +awtdeps.dir=${depends.dir}/libs/windows.x86
> +awtdeps.tar=${awtdeps.dir}/swing_awt_deps_winxp_2006-09-28.tgz
> +awtdeps.url=${people.apache.base}swing_awt_deps_winxp_2006-09-28.tgz
> +awtdeps.md5=d61a27e4b305d9fcabaaacf34f8f534a
> +awtdeps.extract.dir=${depends.dir}/libs/build
> +awtdeps.testfile=${awtdeps.extract.dir}/winxp_2006-09-28.txt
>
> Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.xml
> URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
> ake/depends.xml?view=diff&rev=452826&r1=452825&r2=452826
> =
> =
> --- incubator/harmony/enhanced/classlib/trunk/make/depends.xml (original)
> +++ incubator/harmony/enhanced/classlib/trunk/make/depends.xml Wed Oct 4 03:
> 24:29 2006
> @@ -72,17 +72,22 @@
>
>
>
> -
> + +depends="-really-check-win,-awt-tar-extract" />
> +
> +
>
>
>
> -
> +
> +
> + + srcfile="${awtdeps.tar}"
> + targetfile="${awtdeps.testfile}" />
>
> -
> -
>
>
> -
> +
>
> value="liblcms development package not installed
> @@ -214,6 +219,10 @@
>md5="${msvcr71.md5}" />
>
> +
> + + md5="${awtdeps.md5}" />
> +
>
>
>
> @@ -298,6 +307,14 @@
> manifest="${bcprov.dir}/temp/META-INF/MANIFEST.MF" />
>
> +
> +
> +
> +Extracting awt dependencies
> + + compression="gzip" />
> + + message="${awtdeps.tar} extracted${line.separator}" />
>
>
>
>
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (HARMONY-1676) [classlib][depends] Missing em64t version of icu libraries
On 4 October 2006 at 12:59, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote: > On 10/4/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > > On 3 October 2006 at 8:12, "Ivan Volosyuk (JIRA)" <[EMAIL PROTECTED]> wrote: > > > [ http://issues.apache.org/jira/browse/HARMONY-1676?page=comments#act > ion_ > > > 12439536 ] > > > > > > Ivan Volosyuk commented on HARMONY-1676: > > > > > > > > > copy these files into depends/libs/linux.x86_64 > > > build with 'ant -Dos.arch=x86_64' > > > > I've just checked in a change to make/properties.xml (as r452774) that > > should add os.arch normalization for x86_64. (This basically duplicates > > what we did to handle the way the os.arch variables differ between > > reference jdks.) > > > > So, hopefully, you shouldn't need -Dos.arch=x86_64 any more. If it > > doesn't work, can you let me know what os.arch says for the jdk you are > > using. > > > > Thanks, > > Mark. > > Well, I didn't download 64 bit version jdk, so I've just used the 32 > bit version which works just fine on 64 bit version of linux. > Jdk I use is: > jrockit-jdk1.5.0-linux-ia32 (build 1.5.0-b64) And what is os.arch is set to? x86 or i386 or something? Probably not much we can do about that. Except perhaps create a user preferences file. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 Build/Test
FYI: I've changed the way our builds are reported to the -commits list. Now, the reports go to my apache.org email address where they are compressed and stored. The url in the message is then modified to point to the compressed version in my people.apache.org web space and the first 10k of the message is sent on to the -commits list. This should mean: a) all messages reach the list (no more size limit issues) b) the full logs are available via the web - at least for a week or two Currently the trimming of the logs to send to the list is very crude and usually the first 10k isn't very useful. Hopefully I'll get some time to improve the trimming shortly to, for instance, include lines which match /(error/fail/warn)/i plus a few lines of context above/below. Regards, Mark. On 4 October 2006 at 9:36, [EMAIL PROTECTED] wrote: > Online report : http://people.apache.org/~hindessm/continuum/classlib/linux.i > a32/2006/10/04/20061004-083606.successful.log.gz > Build statistics: > State: Ok > Previous State: Failed > Started at: Wed, 4 Oct 2006 09:03:31 +0100 > Finished at: Wed, 4 Oct 2006 09:36:04 +0100 > Total time: 32m 33s > Build Trigger: Schedule > Exit code: 0 > Building machine hostname: hy2 > Operating system : Linux(unknown) > Java version : 1.5.0_06(Sun Microsystems Inc.) > > Changes > classlib/modules/auth/src/test/java/common/org/ap > ache/harmony/auth/login/DefaultConfigParserTest.java > classlib/modules/auth/src/test/java/common/org/apache/harmony/aut > h/login/DefaultConfigurationTest.java > classlib/modules/auth/src/test/resources/auth.conf > classlib/make/properties.xml > > > Output: > > Buildfile: build.xml > > build: >[delete] Deleting directory /home/hybld/continuum-working-directory/6/clas > slib/deploy > [echo] Classlib revision is 452787 > [echo] Post process: true > [echo] JAPI: true > [echo] Building with reference jdk/javac > [exec] Buildfile: build.xml > > [exec] clean-java: > > [exec] -copy-kernel-patternsets: > [exec] [mkdir] Created dir: /home/hybld/continuum-working-directory/ > 6/classlib/deploy/build/patternsets > [exec] [copy] Copying 1 file to /home/hybld/continuum-working-direc > tory/6/classlib/deploy/build/patternsets > [exec] [copy] Copying 1 file to /home/hybld/continuum-working-direc > tory/6/classlib/deploy/build/patternsets > > [exec] -modules-clean-bin: > > [exec] call-modules-all: > > [exec] clean: > [exec][delete] Deleting 30 files from /home/hybld/continuum-working- > directory/6/classlib/build/classes > [exec][delete] Deleting 15 files from /home/hybld/continuum-working- > directory/6/classlib/modules/accessibility/bin/test > > [exec] clean: > [exec][delete] Deleting 13 files from /home/hybld/continuum-working- > directory/6/classlib/build/classes > > [exec] clean: > [exec][delete] Deleting 4 files from /home/hybld/continuum-working-d > irectory/6/classlib/build/classes > [exec][delete] Deleting 1 files from /home/hybld/continuum-working-d > irectory/6/classlib/modules/applet/bin/test > > [exec] clean: > [exec][delete] Deleting 51 files from /home/hybld/continuum-working- > directory/6/classlib/build/classes > [exec][delete] Deleting 41 files from /home/hybld/continuum-working- > directory/6/classlib/modules/archive/bin/test > > [exec] clean-native-includes: > [exec][delete] /home/hybld/continuum-working-directory/6/classlib/de > ploy/include not found. > > [exec] clean: > [exec][delete] Deleting 106 files from /home/hybld/continuum-working > -directory/6/classlib/build/classes > [exec][delete] Deleting 218 files from /home/hybld/continuum-working > -directory/6/classlib/modules/auth/bin/test > > [exec] clean: > [exec][delete] Deleting 901 files from /home/hybld/continuum-working > -directory/6/classlib/build/classes > [exec][delete] Deleting 570 files from /home/hybld/continuum-working > -directory/6/classlib/modules/awt/bin/test > > [exec] clean: > [exec][delete] Deleting 107 files from /home/hybld/continuum-working > -directory/6/classlib/build/classes > [exec][delete] Deleting 233 files from /home/hybld/continuum-working > -directory/6/classlib/modules/beans/bin/test > > [exec] clean: > [exec][delete] Deleting 122 files from /home/hybld/continuum-working > -directory/6/classlib/build/classes > [exec][delete] /home/hybld/continuum-working-directory/6/classlib/mo > dules/concurrent/bin/test not found. > > [exec] clean: > [exec][delete] Deleting 49 files from /home/hybld/continuum-working- > directory/6/classlib/build/class
Re: [jira] Commented: (HARMONY-1676) [classlib][depends] Missing em64t version of icu libraries
On 3 October 2006 at 8:12, "Ivan Volosyuk (JIRA)" <[EMAIL PROTECTED]> wrote: > [ http://issues.apache.org/jira/browse/HARMONY-1676?page=comments#action_ > 12439536 ] > > Ivan Volosyuk commented on HARMONY-1676: > > > copy these files into depends/libs/linux.x86_64 > build with 'ant -Dos.arch=x86_64' I've just checked in a change to make/properties.xml (as r452774) that should add os.arch normalization for x86_64. (This basically duplicates what we did to handle the way the os.arch variables differ between reference jdks.) So, hopefully, you shouldn't need -Dos.arch=x86_64 any more. If it doesn't work, can you let me know what os.arch says for the jdk you are using. Thanks, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
On 3 October 2006 at 21:08, "Vladimir Ivanov" <[EMAIL PROTECTED]> wrote: > > I have one more question about coverage: should it be the part of the B&T > infrastructure or integrated to the current classlib build system? > > From my point of view it should be a part of B&TI while it is rarely used > functionality and no needs to waste regular build by this data (it does not > required to duplicate code while coverage depends on regular build and we > should describe it in the readme.txt). > > > > By the way, we (at least I :) ) going to have some different scripts in the > B&I modules: > > - code coverage (issue 564); > > - cruise control (issue 995); > > - japi script (In progress); > > - script to simple download and run tests against HDK. > > > > Seems, that it will OK to have some wrapper for these scripts and one set of > properties. > > Something like: 'ant cc' - to run cruise control, 'ant coverage' - to > calculate coverage etc. > > If no objections I will try to implement it after 'run japi' script. Regarding the 'run japi' script what are you planning to do here? The IBM Build/test builds also run japi (on linux only since we get enough information using one platform and linux is easier). We might as well share ant code. Also note that to get anything like reasonable data you need to be running the latest japi from CVS. Regards, Mark. > Thanks, Vladimir > > > > On 10/2/06, Vladimir Ivanov <[EMAIL PROTECTED]> wrote: > > > > The coverage information was updated on the wiki to current state (issue > > 564 also was updated): > > http://wiki.apache.org/harmony/Coverage_information > > > > thanks, Vladimir > > > > > > > > --=_Part_60236_8031756.1159884501259-- > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] AWT/Swing deps
On 3 October 2006 at 9:33, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > > > Mark Hindess wrote: > > On 3 October 2006 at 19:16, "Mikhail Loenko" <[EMAIL PROTECTED]> wrote: > >> 2006/10/3, Geir Magnusson Jr. <[EMAIL PROTECTED]>: > >>> > >>> Alexey Petrenko wrote: > >>>> I agree that downloading of prebuilt libraries is better choice. > >>>> > >>>> So we got only two options: > >>>> 1. Find prebuilt libraries somewhere. > >>>> 2. Build them ourselves and store them somewhere. > >>>> > >>>> I've tried to find prebuilt libraries but I was not successful. So it > >>>> seems that the only option is to build them ourselves. > >>>> And the only question is: Where to store them? > >>>> > >>>> Any ideas? > >>> As I threatened in my original post, I put them in > >>> > >>> http://people.apache.org/~geirm/harmony/ > >>> > >>> I could move them to the snapshot directory too, but I figure no one is > >>> going to assume that we are formally distributing them if they are in a > >>> personal directory. > >> Interesting statement. IANAL, but I'd assume we are > > > > Certainly we are in that sense but I don't think that is the issue Geir > > was trying to address. (This certainly means we needed to meet the > > license requirements for distribution - though IIRC they are fairly > > minimal for these particular packages.) > > > > The issue is whether the Apache Software Foundation is considered > > to be formally responsible or if it is just something Geir is doing > > personally. > > > Well, if the project build is tied to it, it should be considered > something we are doing as a project *for ourselves*. > > In the same way that we stuff things into SVN for our use, we aren't > claiming to be a distributor of those things. Sure, it's available to > evereyone, but that's because of the open way we work. That seems a reasonable argument. I'll start looking at the fetch-depends tweaks. -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] AWT/Swing deps
On 3 October 2006 at 19:16, "Mikhail Loenko" <[EMAIL PROTECTED]> wrote: > 2006/10/3, Geir Magnusson Jr. <[EMAIL PROTECTED]>: > > > > > > Alexey Petrenko wrote: > > > I agree that downloading of prebuilt libraries is better choice. > > > > > > So we got only two options: > > > 1. Find prebuilt libraries somewhere. > > > 2. Build them ourselves and store them somewhere. > > > > > > I've tried to find prebuilt libraries but I was not successful. So it > > > seems that the only option is to build them ourselves. > > > And the only question is: Where to store them? > > > > > > Any ideas? > > > > As I threatened in my original post, I put them in > > > > http://people.apache.org/~geirm/harmony/ > > > > I could move them to the snapshot directory too, but I figure no one is > > going to assume that we are formally distributing them if they are in a > > personal directory. > > Interesting statement. IANAL, but I'd assume we are Certainly we are in that sense but I don't think that is the issue Geir was trying to address. (This certainly means we needed to meet the license requirements for distribution - though IIRC they are fairly minimal for these particular packages.) The issue is whether the Apache Software Foundation is considered to be formally responsible or if it is just something Geir is doing personally. -Mark. > > > 2006/10/3, Geir Magnusson Jr. <[EMAIL PROTECTED]>: > > >> > > >> > > >> Mikhail Loenko wrote: > > >> > For the short term it sounds good. > > >> > For the long term the deps would better be built on the fly IMHO > > >> > > >> Why? We don't build other deps on the fly. By using a binary distro, we > > >> all have the same, predictable thing. > > >> > > >> And seems like some of this code hasn't changed since last century :) > > >> > > >> geir > > >> > > >> > > > >> > Thanks, > > >> > Mikhail > > >> > > > >> > 2006/9/28, Geir Magnusson Jr. <[EMAIL PROTECTED]>: > > >> >> Ok, that was fun. Not. > > >> >> > > >> >> We need to finish making this easier for developers to build by > > >> >> having pre-built binaries somewhere. To start, I'm going to put a > > >> >> well-documented tree that contains the stuff needed for /png, /lcms > > >> >> and /jpg on my personal account and note it. > > >> >> > > >> >> If we can then make that part of fetch-depends, all will be well. > > >> >> > > >> >> Comments? Other ideas? > > >> >> > > >> >> - > > >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html > > >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> >> For additional commands, e-mail: [EMAIL PROTECTED] > g > > >> >> > > >> >> > > >> > > > >> > - > > >> > Terms of use : http://incubator.apache.org/harmony/mailing.html > > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> > For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > > >> > > >> - > > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > > > > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] AWT/Swing deps
On 3 October 2006 at 7:49, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > > > Alexey Petrenko wrote: > > I agree that downloading of prebuilt libraries is better choice. > > > > So we got only two options: > > 1. Find prebuilt libraries somewhere. > > 2. Build them ourselves and store them somewhere. > > > > I've tried to find prebuilt libraries but I was not successful. So it > > seems that the only option is to build them ourselves. > > And the only question is: Where to store them? > > > > Any ideas? > > As I threatened in my original post, I put them in > >http://people.apache.org/~geirm/harmony/ > > I could move them to the snapshot directory too, but I figure no one > is going to assume that we are formally distributing them if they are > in a personal directory. Agreed. In a personal directory is a bit better. But if we point 'ant fetch-depends' at it on an apache server even in a personal directory, that seems be a bit more like distributing them formally to me. BTW, I made changes to move the unix fetch-awt-depends.sh[0] to the "ant fetch-depends" target in anticipation of doing some downloads to fetch them for windows. If you want me to add the windows downloads, where ever they end up, just ask. I've left a warning in the now obsolete script. I'll remove the script next week, so please test the new ant code - which is currently protected by with.awt.swing property. I'll remove this property completely[0] when we've added the windows downloads to 'ant fetch-depends'. -Mark. [0] Though we need to think about headless/non-headless tests. > > 2006/10/3, Geir Magnusson Jr. <[EMAIL PROTECTED]>: > >> > >> > >> Mikhail Loenko wrote: > >> > For the short term it sounds good. > >> > For the long term the deps would better be built on the fly IMHO > >> > >> Why? We don't build other deps on the fly. By using a binary distro, we > >> all have the same, predictable thing. > >> > >> And seems like some of this code hasn't changed since last century :) > >> > >> geir > >> > >> > > >> > Thanks, > >> > Mikhail > >> > > >> > 2006/9/28, Geir Magnusson Jr. <[EMAIL PROTECTED]>: > >> >> Ok, that was fun. Not. > >> >> > >> >> We need to finish making this easier for developers to build by > >> >> having pre-built binaries somewhere. To start, I'm going to put a > >> >> well-documented tree that contains the stuff needed for /png, /lcms > >> >> and /jpg on my personal account and note it. > >> >> > >> >> If we can then make that part of fetch-depends, all will be well. > >> >> > >> >> Comments? Other ideas? > >> >> > >> >> - > >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >> For additional commands, e-mail: [EMAIL PROTECTED] > >> >> > >> >> > >> > > >> > - > >> > Terms of use : http://incubator.apache.org/harmony/mailing.html > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > >> - > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][JIRA] Can 1594 be committed?
After posting, I noticed that Geir has pick up this JIRA so, while I'll still take a look, I wont steal the JIRA or commit any changes. Geir feel free to re-assign it if you decide you don't want it. ;-) -Mark. On 3 October 2006 at 12:02, Mark Hindess <[EMAIL PROTECTED]> wrote: > > I'll take a look. > > -Mark. > > On 3 October 2006 at 14:42, "Pavel Pervov" <[EMAIL PROTECTED]> wrote: > > > > Dear committers, > > > > please, commit HARMONY-1594 to fix gcc 4.* build for Jitrino and jet > > sources. Otherwise, it is a bit more complex to live on a linux with > > compiler version 4.0 and above. > > > > Regards, > > Pavel Pervov. > > Intel Middleware Products Division. > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm][JIRA] Can 1594 be committed?
I'll take a look. -Mark. On 3 October 2006 at 14:42, "Pavel Pervov" <[EMAIL PROTECTED]> wrote: > > Dear committers, > > please, commit HARMONY-1594 to fix gcc 4.* build for Jitrino and jet > sources. Otherwise, it is a bit more complex to live on a linux with > compiler version 4.0 and above. > > Regards, > Pavel Pervov. > Intel Middleware Products Division. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] jre and hdk snapshots posted to general snapshot site
On 2 October 2006 at 16:36, Oliver Deakin <[EMAIL PROTECTED]> wrote: > Alexei Zakharov wrote: > > If we plan to use HDK for supporting developers who work on single > > module (that is a good idea IMHO) then we definitely need to supply > > jar with tests. > > Can I suggest that we have a separate test jar for each module? So > we'd have luni-tests.jar, security-tests.jar etc. This means that if a > developer > working on a single module creates a bug fix and a new test case, they only > need to rebuild the test jar for that particular module (they may only > have that single > module checked out, after all). > > In fact, we will need to create separate test jars for bootclasspath and > classpath > tests, unless there is a way in Ant to specify which subsets of the file > tree within > a jar are on the bootclasspath/classpath - it's probably simpler to just > have > -api-tests.jar and -impl-tests.jar (or whatever naming > convention). It feels like I have an echo. I said pretty much the same things on the renamed "Using the HDK" thread earlier in the day. ;-) I should mention that modules like security actually have four distinct types of tests. api, api.injected, impl, and impl.injected - in other words some api tests are run on the bootclasspath and some impl tests are not. So perhaps we need 4 jars! -Mark. > So IMHO we should: > 1) Add bundling of --tests.jar into the HDK to each module's > build.xml as a standard step of the test build process. > 2) Alter the test execution Ant targets to always run the tests using > the prebuilt > --test.jar's on the (boot)classpath - on the bootclasspath > we put "*-impl-test.jar" and on the classpath we put "*-api-test.jar". > > This way running the tests against a prebuilt HDK will work without > rebuilding any > tests (because the test run targets will only expect the prebuilt jars) > and the > developer can easily rebuild a single module's set of tests by running its > compile-tests target (or something similar). > > Does this sound reasonable? > > Regards, > Oliver > > > We may also supply the build file with placeholders > > for user classes & tests dirs that will be prepended to > > classpath/bootclasspath. > > > > Regards, > > > > 2006/9/27, Vladimir Ivanov <[EMAIL PROTECTED]>: > >> On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > >> > > >> > > >> > > >> > If I recall, the point of the test.jar was to have a pre-built jar of > >> > tests in the HDK so that someone could setup the build-test infra > >> > using the HDK so they could run tests on their platform w/o having to > >> > build everything. Good idea. > >> > >> > >> Yes, you are correct. This idea implemented in the jira 964. > >> > >> If that's so, then something would > >> > have to be configured to have the classlib "test" target use that > >> > jar. All I'm saying is that how we do this is important, as we don't > >> > want to cause pain for classlib developers who use the HDK for > >> > development support. > >> > >> > >> > >> Seems, we think about different use cases. > >> > >> In my case, user can download the HDK for own platform (if we have > >> one) run > >> tests and look on results (also, may be upload it to the harmony > >> site). Also > >> it can be used for application run to check 'enable' status. But if this > >> user interested in Harmony development he should checkout ws and use > >> built-in ant targets to build and test updated ws. > >> > >> > >> > >> How you plan to use HDK? It looks like initial miscommunication :) > >> thanks, Vladimir > >> > >> > >> > >> > geir > >> > > >> > > > >> > > Thanks, Vladimir > >> > > > >> > > > >> > > > >> > > > >> > > > >> > >> > Thanks, Vladimir > >> > >> > > >> > >> > geir > >> > >> >> > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > Thanks, Vladimir > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > On 7/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > >> > >> >> >> > >> > >> >> >> They are at the regular place > >> > >> >> >> > >> > >> >> >> http://people.apache.org/dist/incubator/harmony/snapshots > >> > >> >> >> > >> > >> >> >> I moved all the old classlib snapshots into /old and I'll > >> > >> >> update the > >> > >> >> >> website accordingly. I'll be automating this. Also, lets > >> not > >> > >> >> >> make much > >> > >> >> >> noise about this for a little while so we can test to make > >> sure > >> > >> >> >> there's > >> > >> >> >> no major errors. Things seem good. I have a list of more > >> > >> >> things to > >> > >> >> >> fix, but I realized today that I was obsessing over the > >> > >> snapshot > >> > >> >> >> contents - it's not a release, and it's "good enough". > >> > >> >> >> > >> > >> >> >> I'd like to ditch both /old and the remaining classlib > >> > >> >> snapshots, as > >> > >> >> >> > >> > >> >> >> 1) they are snapshots - history doesn't matter > >> > >> >> >> > >> > >> >> >> 2) the classlib is now in the HDK, so we just need to adjust > >> > >> the > >> >
Re: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
On 2 October 2006 at 8:52, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > > > I wonder if we can generate some kind of dependency graph as part of the > build, so that if testing in a module, it can figure out the set of > modules to test that are "n-away" dependent. (IOW, test module + 1-away > because it's quick, then before checkin test module + 2-away [or all]) I wondered about this for a different reason... I think it might be interesting to be able to automate this even in a fairy rough way since I'm interested to see what dependencies we are adding between our modules over time. Since my impression (based on no real evidence) is that we perhaps aren't really giving it much thought. -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][test] Test input/output files location
On 28 September 2006 at 15:44, "Denis Kishenko" <[EMAIL PROTECTED]> wrote: > I am going to fix some commented tests from java.awt.geom package. I > have several organizational questions before start to do. > > 1. Where is the best place to put test resource files (golden files)? > Testing conventions [1] keep silence about this. There are many such > files located near the tests, for example > modules\awt\src\test\api\java\common\java\awt\geom\shapes\* > modules\awt\src\test\api\java\common\java\awt\shapes\* As someone else said, these should be in the parallel resources tree. At build time, they should be copied to modules\awt\bin\test so that they can be located at run time using the classpath. (This will allow them to be packaged as a jar of tests.) > 2. Where is the best place to put test output files? Now it is > modules\awt\bin\test\java\awt\shapes\output > modules\awt\bin\test\java\awt\geom\shapes\output A temp directory - preferably not $HOME as some tests seem to at the moment. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
On 29 September 2006 at 15:26, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
> Just renaming the thread
>
> On Sep 29, 2006, at 9:17 AM, Vladimir Ivanov wrote:
>
> > today I tries to build and test one module with HDK. It almost works
> > :). Small instruction to reproduce:
> >
> > 1) checkout trunk -N, make and modules/ dirs. Note, /
> > build.xml
> > refers to some staff in the make dir. Also, the luni-kernel and
> > security-kernel modules should be checkout to hide errors:
> > trunk\modules\beans\build.xml:80: Excludesfile
> > trunk\deploy\build\patternsets\luni-kernel.txt not found.
> > and
> > C:\tmp\tmp30\trunk\modules\beans\build.xml:80: Excludesfile
> > trunk\deploy\build\patternsets\security-kernel.txt not found.
> >
> > 2) run something like "ant -Dhy.jdk=C:\harmony\hdk\jdk -
> > Dbuild.module=beans"
> > from the 'trunk' directory to copy patternsets to the deploy dir.
> > Note, this
> > command will be failed on the check-dependency task.
> >
> > 3) set CLASSPATH=junit.jar;hdk\build\test\support.jar
> >
> > 4) go to the module dir (modules/beans in my case). That's all:
> > module ready
> > to use. You can press: ant -Dhy.jdk=hdk\jdk clean/build/test. Note,
> > actually, the beans.jar in the HDK will be updated. It is OK?
> >
> > To do in the build system:
> > - remove dependency on the luni-kernel and security-kernel modules
I assumed that the dependency was on the patternsets (which could
be removed see thread "[classlib] Trying to catch patternset errors
earlier") and the stub jars. These should just be part of the HDK.
> > - add mode to rebuild module without HDK update (?)
"add mode to rebuild without JDK update" might be simpler[0]? would it
be sufficient? if not, why not? (Some modules do update the hdk but
these are generally files that would not change often - such as C
header files that define an API which should be fairly stable.)
> > - add mode to run tests with build html-report for each module.
Definitely +1.
> > - add mode to run all tests from tests.jar over HDK+ updated classes.
> > - ?
I think we need more than one tests.jar. In fact, I think we need
more than one tests.jar per module since some tests need to be on the
bootclasspath while others do not (and should not). At the moment
it might be necessary to have more since there isn't really a way to
distinguish api/internal tests (this might change if/when we move to
testng).
We also need to ensure that properties.xml is available in the hdk -
for access to the properties and the make macro. (This is already
on my todo list.) I think we should probably create other macros
to simplify the module build.xml files. (For example, share the
compile-tests/run-tests macros that are already defined in crypto, luni,
rmi, security and x-net.) This is also on my todo list.
Also, since we've stated that when a module is change tests should
be run on the module itself and it's immediate dependent modules, we
really need a way to run other modules tests from a module. This will
be interesting due to the complexity of the test setup but might be
slightly easier if the define common macros. This is probably something
to keep in the back of our minds - I wouldn't let it stop us making
progress.
Regards,
Mark.
[0] Start of build would need to do:
if ${hy.jdk} != ${hy.hdk}/jdk then copy ${hy.hdk}/jdk to ${hy.jdk}
and only deploy jdk files in to ${hy.jdk} - I think/hope this is
true already.
> > thanks, Vladimir
> >
> > On 9/28/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
> >>
> >> Good point. +1 from me.
> >>
> >> SY, Alexey
> >>
> >> 2006/9/27, Alexei Zakharov <[EMAIL PROTECTED]>:
> >> > If we plan to use HDK for supporting developers who work on single
> >> > module (that is a good idea IMHO) then we definitely need to supply
> >> > jar with tests. We may also supply the build file with placeholders
> >> > for user classes & tests dirs that will be prepended to
> >> > classpath/bootclasspath.
> >> >
> >> > Regards,
> >> >
> >> > 2006/9/27, Vladimir Ivanov <[EMAIL PROTECTED]>:
> >> > > On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> >> > > >
> >> > > >
> >> > > >
> >> > > > If I recall, the point of the test.jar was to have a pre-
> >> built jar
> >> of
> >> > > > tests in the HDK so that someone could setup the build-test
> >> infra
> >> > > > using the HDK so they could run tests on their platform w/o
> >> having
> >> to
> >> > > > build everything. Good idea.
> >> > >
> >> > >
> >> > > Yes, you are correct. This idea implemented in the jira 964.
> >> > >
> >> > > If that's so, then something would
> >> > > > have to be configured to have the classlib "test" target use
> >> that
> >> > > > jar. All I'm saying is that how we do this is important, as we
> >> don't
> >> > > > want to cause pain for classlib developers who use the HDK for
> >> > > > development support.
> >> > >
> >> > >
> >> > >
> >> > > Seems, we think about different use cases.
> >> > >
> >> > > In my ca
Re: [classlib] Trying to catch patternset errors earlier
On 28 September 2006 at 14:58, "Alexey Petrenko" <[EMAIL PROTECTED]> wrote: > 2006/9/28, Mark Hindess <[EMAIL PROTECTED]>: > > > > On 28 September 2006 at 14:30, "Alexey Petrenko" <[EMAIL PROTECTED] > om> wrote: > > > I think that it will be better to add another target to build for > > > this check. > > > Because of two reasons: > > > 1. It is unclear that clean is also checks something > > This simple check can only happen part way through the clean target - > > after the modules have done their cleaning and before the top-level > > cleanup is done. > I see your point. > > But let's review the sitatuation from another viewpoint... > What do we need in general? > We need up-to-date list of all packages in the specified module. Right? > If so we can create simple script to update patternset files... Or > even create them at build time. But will cost us build time itself :) That's a reasonable point. I had a look at what it would take to get rid of the patternsets completely. It's quite easy for some modules. For example, for accessibility, we can just replace the "classes" fileset with: Which basically says include files if they are also present in the source directory - typically resource files - or if they are .class files and have an obviously-named source file in the source directory[0]. This works for most modules. The present tags are duplicated for modules with platform source directories. However, it doesn't work very well for awt, beans, jndi, luni, and security. Why? Because they have some source files defining two classes. For instance, java.awt.ContextImpl defined in: modules/awt/src/main/java/common/java/awt/Component.java We could hardcode these special case - there are only a few. Or perhaps we could split them in to distinct source files? I have some patches ready to make this change but I've not committed anything. Personally I think getting rid of the patternsets would be a good idea since it reduces the coupling - although really the coupling is only strictly necessary for luni and security. It is important to note that even if we do something like this, leaving the catch-all check in the clean target still helps stop problems - if people forget to add the hardcoded special cases or if we split them people add new source defining two classes in one file. Regards, Mark. [0] The simpler '' doesn't work because it misses inner classes. > > > 2006/9/28, Mark Hindess <[EMAIL PROTECTED]>: > > > > > > > > On 28 September 2006 at 11:07, Tim Ellison <[EMAIL PROTECTED]> wrot > e: > > > > > Sounds reasonable. The alternative is to not make clean fail, just > > > > > print the warning and tidy up the remainder. That may be too easy to > > > > > ignore though. > > > > > > > > Yes. I considered that and had the same concern. Even if I wrote the > > > > code to print the warning, I think I'd ignore it since it would scroll > > > > too quickly off the top of my screen at the beginning of the build. > > > > > > > > -Mark. > > > > > > > > > Regards, > > > > > Tim > > > > > > > > > > Mark Hindess wrote: > > > > > > Yesterday, while looking at something unrelated, I noticed that som > e > > > > > > of the patternsets that are used to select the jars for the classli > b > > > > > > modules were not up to date with the result that some classes would > be > > > > > > missing from the resulting jars[0]. > > > > > > > > > > > > While it makes me slightly uneasy having a clean target that might > fail > > > , > > > > > > it turns out that this is one place where it is quite easy to check > > > > > > whether the patternsets are out of date. (Because if after the mod > ules > > > > > > have cleaned classes in their patternsets there are still files lef > t > > > > > > over then something is being create that isn't accounted for by the > > > > > > patternsets.) > > > > > > > > > > > > So the clean target will now fail with a message like (tested > > > > > > by reverting yesterdays change to the sound patternset): > > > > > > > > > > > > Built files still exist after module clean targets have run. Thi > s > > > > > > probably means that one or
