RE: [Testing Convention] Stress tests: requirements review needed
Hi Alexander, Let me question the following requirement from your list: o System should have a possibility to vary test behavior and stress conditions using arguments Actually I'm thinking here about a test suite built from a simple blocks like small and fast unit tests, or functional tests Do you have in mind some standard glue for these simple building blocks as well? See examples below. * Loop generator If we have some simple unit or functional test, the reasonable stress is to execute this test in a loop. * Thread generator It makes sense to put GC-stressing activity in a loop in parallel with some test. * Stress precondition We can fill most of the memory, and run a simple test afterwards. * Wildcards in test names We may like to stress in some way each test from the package of tests. Do you mean all this rich set of possibilities should be passed via command line arguments? How can we make this notation compact and understandable? With best regards, Alexei Fedotov, 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: [classlib] Testing
Paulex, Mikhail, all, Do I understand the proposed directory structure for stress tests correctly? src/test/ | +- impl/ | +- compliant/ | +- stress/ | | | +- org | | | +- apache | | | +- harmony | | | +- test | | | +- stress | | | +- generator | | | | | +- Loop.java | | | | | +- Thread.java | | | | | \- Package.java | | | +- gc | | | \- more packages | \- etc/ 1) We will run compliant to validate test suite 2) We will not run stress before commit I think pre-commit checks should be done according to a test list, not a directory structure. The reason is simple: number of compliant tests in a directory will constantly grow while the pre-commit check must take a reasonable time. With best regards, Alexei Fedotov, 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: Stress tests generator
Mark, Please, find it here: http://wiki.apache.org/ Shouldn't this go in a JIRA rather than on the wiki? If I understand Alexander correctly, currently this is not yet a contribution, but a prototype. Alexander has presented a concept sketch and awaits a design review from the community. My 2 cents about HowTo.txt * My Eclipse imported and compiled unpacked content * Examples worked (a minor correction is to put a class name after classpath in the first example). With best regards, Alexei Fedotov, 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: [DRLVM] build process improvement
Vladimir, Therefore there are no needs to compile them each of participants. It'd be fine to have these sources pre-compiled (another snapshot?) Working with Geronimo, I've got acquainted with Maven http://maven.apache.org/ build system, which solves this issue for pure-java projects: Dependency management: Maven encourages the use of a central repository of JARs and other dependencies. Maven comes with a mechanism that your project's clients can use to download any JARs required for building your project from a central JAR repository much like Perl's CPAN. This allows users of Maven to reuse JARs across projects and encourages communication between projects to ensure that backward compatibility issues are dealt with. Probably we should split our VM into modules with well-documented interfaces and take advantage of this Apache product to deploy them separately in pre-built binaries. With best regards, Alexei Fedotov, 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: [DRLVM] build process improvement
Ivan, Andrey, The main thing I vote for is to evaluate and to take the best from other distribute dependency management systems before starting relatively easy to modify the DRLVM building system. I like Ivan's list, though Apache Maven has a domestic priority :-). Let me address two real problems you have mentioned: * Update only when needed to avoid unpleasant surprises We solved this problem by keeping local Maven repository. Maven gurus can say if this is a correct way to handle this issue. * Mixed builds Maven supports anything with ANT builds - we can have pre-built binaries for basic configurations, for others Maven will load source distributions and build in their environments. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, May 18, 2006 1:44 PM To: harmony-dev@incubator.apache.org Subject: Re: [DRLVM] build process improvement Right. 2006/5/18, Andrey Chernyshev [EMAIL PROTECTED]: On 5/18/06, Alexey Petrenko [EMAIL PROTECTED] wrote: 2006/5/18, Gregory Shimansky [EMAIL PROTECTED]: If you talk about developers only there is no need for swing.jar or tweaks like that. Developers already have some kind of java SDK installed and the place to solve missing dependencies is rt.jar from an external party. I don't see why it is not a good way to follow in development environment. Yep, it is probably true :) But Harmony can run ant and Eclipse compiler right now. So we do not need any kind of SDK except of Harmony for building it. In this case we need to produce something like Harmony binary builds. As we discussed before. Yes, I think it was the idea of HDK to have the build snapshot somewhere on web and then let developers be able to build specific modules against that snapshot. Returning back to the subject of this discussion, I guess it should be relatively easy to modify the DRLVM building system such that it would get the binary HDK from web and use it for compilation of a single module. And this approach would assume that the HDK snapshots include the DRLVM as well (?) :) Thanks, Andrey. -- 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] -- 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: [classlib] Layout of tests in crypto module
Mikhail, For me is hard to differentiate between X509CertImplTest and X509CertImplITest. So I vote for inventing something different. Why moving implementation-independent tests into a separate package (like org.apache.harmony.test.tested_package) is no longer discussed? BTW, in this case we can remove excessive Test suffix. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: George Harley [mailto:[EMAIL PROTECTED] Sent: Thursday, May 18, 2006 4:34 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] Layout of tests in crypto module Mikhail Loenko wrote: There are classes like X509CertImpl.java in this case impl test for it would be X509CertImplImplTest which does not look very good. How about ITest ? Thanks, Mikhail Hi Mikhail, Sure, that works for me. Best regards, George 2006/5/18, George Harley [EMAIL PROTECTED]: Hi Mikhail, That is a very good point and your suggestion of supplementing the class or package name sounds like a very straightforward way around the problem. Because there will be a number of tests that must be in an identical package name to the type under test then it seems that the differentiating mark needs to be added to the test class name. Not really sure what this could be. Given that we are all settled on the convention that a test type has the Test suffix, how about just add Impl to that suffix for implementation tests giving us an ImplTest suffix. e.g. class under test : java.lang.SomeClassTest implementation-independent test class : o.a.h.module.tests.java.lang.SomeClassTest Harmony-specific test class : o.a.h.module.tests.java.lang.SomeClassImplTest My 2 Euro cents... George Mikhail Loenko wrote: That sounds very reasonable, but I have a problem: I tried to implement it and found that as far as we put all test results into a single directory and generate a single report, we can't have different tests with the same name. For example we can't have impl and api tests of o.a.h.module.tests.java.lang.SomeClassTest Looks like we should put some differentiating mark to a class or package name. Thanks, Mikhail 2006/5/18, George Harley [EMAIL PROTECTED]: Mikhail Loenko wrote: Hi George, I use ant to build and run the tests, so I'm likely unaware of some Eclipse problems. If we put classpath test classes to impl/java and api/java and bootclasspath ones to something like impl/java.injected and api/java.injected will it solve the problem you describe? Thanks, Mikhail Hi Mikhail, Yes, I think that compiling to separate bin folders would do the trick ; a bin for stuff that will go on the classpath and a bin for stuff that will be loaded on the bootclasspath. In order to reach that goal the test source itself will AFAIK need to be laid out in a similar manner. That is, the directory tree will look something like the following (may need to be viewed in wide-screen): src/test/api/java --- implementation-independent tests intended to be loaded by system class loader, compiled to bin src/test/api/java.injected--- implementation-independent tests intended to be loaded by boot class loader, compiled to bin.injected src/test/impl/java --- Harmony-specific tests intended to be loaded by system class loader, compiled to bin src/test/impl/java.injected--- Harmony-specific tests intended to be loaded by boot class loader, compiled to bin.injected Does that sound reasonable ? Best regards, George 2006/5/17, George Harley [EMAIL PROTECTED]: Mikhail Loenko wrote: 2006/5/16, George Harley [EMAIL PROTECTED]: Mikhail Loenko wrote: Hi George, see below 2006/5/16, George Harley [EMAIL PROTECTED]: Hi Mikhail, I have a couple of minor comments about your proposal for a test layouts. I should have responded sooner, I know, but I have suffered from a number of hardware problems in the past few weeks that slowed things down somewhat for me. Anyway, it's all great but it would be nice to get answers to the following ... 1) The section on Location of the tests in the directory tree proposes modulename/src/tests/impl for Harmony specific tests and modulename/src/tests/api for implementation-independent tests. Where would tests go for Harmony API's that are not part of the J2SE spec but are still accessible ? Strictly speaking they are API as well as being specific to Harmony. The main idea is to separate tests that must pass on any conformant implementation from the tests passing on Harmony only. When these are separated we can e.g. easily validate implementation- independent tests by running them against RI. Actually I would not like to start an
[Stress tests] generator: looking forward
Alex, Please, find the new version (0.2) and all previous versions here: http://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12340105 Good. I like it (everyone likes when his suggestions are implemented :-). So let me try to outline where we are in Harmony stress testing. === TEST DESIGN === * Stress tests are built from simple building blocks according to configuration strings. * Tests have junit interface. [Case study] Imagine someone puts tests into SVN which implements different test interface. To reuse them we can add another generator to convert these tests to junit interface. * Configuration string list is maintained manually. If we plan to use junit runner to launch a sequent of the stress tests, then the most straightforward model is to wrap configuration strings into junit test cases and put documentation into javadoc for these test cases. === FURTHER STEPS === * You wrote, stress test suite should generate relevant bugs. Since usually stress behavior is unspecified, we need to introduce something measurable instead of pass/fail result for the stress tests. See my thoughts about a comparative approach below. * I will continue code reviews. * All should create tests and run them against Harmony VM and RI. This would be a real-life testing for our approach. === COMPARATIVE APPROACH === The simplest example of comparative apporach is the following. Tester: My test fails on Harmony VM and passes on RI. Please, fix Harmony VM. This usually does not work for stress tests. Developer: Who told you that OutOfMemoryError should be thrown in your thread? My finalizer thread is just a normal java thread, like yours, and it can fail as well. You have a bug in your test. There are multiple reasons why we always will have such bugs in the tests. * These bugs keep showing up. The time to fix all these bugs regularly is too high. * Stress testing reuses tests which are usually not designed for stress execution, for example, multithread execution. * These bugs are dependent on VM internal structure. Test authors do not posess sufficient knowledge of the problem and the structure. * Sometimes Java is not rich enough. How can we have a maintainable test product takung all this limitation into account? We need to learn how to live with occasional failures of the stress tests. This means, instead of fail, the test should better report how good it is on Harmony VM compared to RI: * Failures with the worst relative metric can be evaluated first. * We can detect that a relative metric for a test worsened on the recent build. Developers are better convinsed to fix the worst issue or dergadation instead of some issue. Now let me list here several metrics for each test. * Pass rate: assuming the test is 100% reliable on RI we can calculate a percentage of failures. * Number of times the test can be executed sequentionally before a fail. * Memory consumption: a generator can preallocate more and more memory before launching the test in a loop. * Max threads supported: a generator can exponentially increase number of threads launching the test in parallel. * Here is your metric. * Execution time: have you noticed that all this apparatus is quite close to performance testing methodology? There is no need to compete with them in their field though. :-) The thing I like most about this approach is it can be introduced on a stress test generator level. With best regards, Alexei Fedotov, 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: [build-test-infra] Build Test Infrastructure
Vladimir,
I was trying a buildtest module from svn repository.
You wrote,
When I tried to run it for the first time I saw problems with get
and svn commands - they did not work in my environment due to:
- no proxy settings for get and exec svn command.
- some problems with my certificate for apache site.
Is there any progress with making get command work? I tried to make it
work.
1. I succeed to make get work through proxy by changing cc/config.xml
(= config/config-full.xml) in a following way:
schedule interval=300
ant antWorkingDir=projects/classlib/trunk
target=fetch-depends
jvmarg arg=-Dhttp.proxyHost=***.com/
jvmarg arg=-Dhttp.proxyPort=***/
/ant
/schedule
2. Setting CC_OPTS (like ANT_OPTS) doesn't help me to rewrite the
configuration file in a following way.
schedule interval=300
ant antWorkingDir=projects/classlib/trunk
target=fetch-depends
jvmarg arg=-Dhttp.proxyHost=${http.proxyHost}/
jvmarg arg=-Dhttp.proxyPort=${http.proxyPort}/
/ant
/schedule
So I've created config/cc.properties and used
?xml version=1.0 encoding=UTF-8?
cruisecontrol
+property file=cc.properties/
Using this approach I managed to make classlib-deps and drlvm-deps. Do
you think this is a correct direction to develop proxy support?
BTW, why the config file is called config-full.xml? I prefer to call it
cc-config.xml.
With best regards,
Alexei Fedotov,
Intel Middleware Products Division
-Original Message-
From: Vladimir Ivanov [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 27, 2006 3:56 PM
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Subject: Re: [build-test-infra] Build Test Infrastructure
On 7/26/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
That's what the buildtest subproject is for. Have you looked at it?
Yes. When I tried to run it for the first time I saw problems with
get
and
svn commands - they did not work in my environment due to:
- no proxy settings for get and exec svn command.
- some problems with my certificate for apache site.
I propose to do the following:
- specify in README.txt that if you work via proxy, then, specify in
property file values for proxy host/port and checks proxy settings into
your
SVN configuration files.
- specify in README.txt that the certificate to work with apache site
should be accepted.
Does it make sense?
Issue 995 was created to support proxy settings for the 'get' target.
4. Full testing - the whole set of Harmony tests are run on
regular
builds, results are published.
Goal: to see what happened with Harmony quality on the whole set of
automated tests, see new bugs, see quality of Harmony runtimes.
Users should be able to do this kind of testing on their specific
platforms
and publish results on Harmony web site.
This script (prototype) I implemented, see issue 984.
I thought that the classlib tests are run as well w/ the CC script
right
now, but will check.
Yes, but I hope in the future we will have more test suites
(functional,
stress etc).
Will we run all of them in code integrity testing? - I suppose no, once
we
see that running all tests takes more then hour.
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]
RE: [build-test-infra] Build Test Infrastructure
Anton, I'm looking at http://www.harmonytest.org/testapp.do?method=showrunid=4name=result=2 jira=0 http://www.harmonytest.org/testapp.do?method=showrunid=4name=result=3 jira=0 I see 5 errors and 14 failures. I just want to double check that we have less than 20 problems with running unit tests on DRLVM. Is it correct statement or some failures are missed? With best regards, Alexei Fedotov, Intel Middleware Products Division BTW, I have a small request for enhancement: the following request hides search options by the right margin of my screen. I would suggest reordering table rows in a way fixed width fields go first. http://www.harmonytest.org/testapp.do?method=showrunid=4name=result=1 jira=0 -Original Message- From: Anton Luht [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 26, 2006 7:44 PM To: harmony-dev@incubator.apache.org Subject: Re: [build-test-infra] Build Test Infrastructure I think we'd want this to be registered user can add user Done. I'm still the only person with login - send me your login/password to register. -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [build-test-infra] Build Test Infrastructure
Anton, Thank you for a prompt reply! I have one more comment concerning a site design: it would be great to see a number of records in the current search request. For example, if I chose nothing, I would a total number of tests in the report. Actually I want to see a total number of passed tests. Why? Since the number of fails gives us an optimistic estimate due to report misses, I may calculate a number of fails as a total amount - number of passes. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Anton Luht [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 2:01 PM To: harmony-dev@incubator.apache.org Subject: Re: [build-test-infra] Build Test Infrastructure Alexei, VM hanged in the process of test execution - I killed it and tests proceeded - I'm not sure whether this crash is recorded as error or those tests are not included in the report. The report on site is the similar to the one I see in my local test_result/html report . On 9/28/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: Anton, I'm looking at http://www.harmonytest.org/testapp.do?method=showrunid=4name=result=2 jira=0 http://www.harmonytest.org/testapp.do?method=showrunid=4name=result=3 jira=0 I see 5 errors and 14 failures. I just want to double check that we have less than 20 problems with running unit tests on DRLVM. Is it correct statement or some failures are missed? With best regards, Alexei Fedotov, Intel Middleware Products Division BTW, I have a small request for enhancement: the following request hides search options by the right margin of my screen. I would suggest reordering table rows in a way fixed width fields go first. http://www.harmonytest.org/testapp.do?method=showrunid=4name=result=1 jira=0 -Original Message- From: Anton Luht [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 26, 2006 7:44 PM To: harmony-dev@incubator.apache.org Subject: Re: [build-test-infra] Build Test Infrastructure I think we'd want this to be registered user can add user Done. I'm still the only person with login - send me your login/password to register. -- 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] - 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] - 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-100) text/BidiWrapper issue?
Alexey (Ivanov), Alexey (Petrenko), All,
Could anyone please volunteer to resolve this issue
(http://issues.apache.org/jira/browse/HARMONY-100)? Not only it has a
very nice number, but also blocks a fair amount of unit tests.
This shouldn't be incredibly hard - Tim added an excellent comment to
the issue description which contains an idea of a suggested fix.
With best regards,
Alexei Fedotov,
Intel Middleware Products Division
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Friday, February 17, 2006 3:45 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Created: (HARMONY-100) text/BidiWrapper issue?
congratulations -- you are our 100th customer! Step over here for your
special gift.
(Too bad Svetlana, you missed out after all that hard work :-) ).
Tim
Vladimir Gorr (JIRA) wrote:
text/BidiWrapper issue?
---
Key: HARMONY-100
URL: http://issues.apache.org/jira/browse/HARMONY-100
Project: Harmony
Type: Bug
Reporter: Vladimir Gorr
Let's consider the following test:
import java.text.Bidi;
public class Test {
public static void main(String[] args) throws Exception {
Bidi bd = new Bidi(new char[] { 's', 's', 's' }, 0,
new byte[] { (byte) -7, (byte) -2,
(byte) -3 },
0, 3,
Bidi.DIRECTION_DEFAULT_LEFT_TO_RIGHT);
System.out.println(Expected 7, real + +
bd.getLevelAt(0));
}
}
In my opinion the JNI implementation of Bidi (text/BidiWrapper.c
file,
ubidi_1setPara() function) contains a potential bug, namely:
1. If the embeddingLevels argument is not NULL then
_embeddingLevels
variable is initialized with the JNI GetByteArrayElements() function;
2. ICU function (ubidi_setPara) initializes ICU inner structure and
puts
the _embeddingLevels into it;
3. If _embeddingLevels pointer is not NULL then the JNI
ReleaseByteArrayElements() function (with 0 as fourth parameter) is
called.
This function releases the memory (according to JNI
specification)
the _embeddingLevels pointer refers to;
4. After that ICU inner structure isn't initialized properly. Call of
ICU
ubidi_getLevels() function can return incorrect values (see java test
above).
It seems the JNI_COMMIT parameter instead of 0 should be passed to
the
ReleaseByteArrayElements() to avoid this problem.
I'd like to underline the test mentioned above works w/o any issues
for
Harmony-14 contribution (although it shouldn't sometimes IMHO).
Therefore if there are any doubts in my argumentation this issue can
be
closed as invalid.
--
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]
Test bugs are very easy to fix, especially when you have a patch! Was: [vm] IBM VME related issues
Dear committers, I have noticed that the following related issues http://issues.apache.org/jira/browse/HARMONY-1309 http://issues.apache.org/jira/browse/HARMONY-1670 contain patches already - thanks to Alexey Varlamov! These patches are quite safe to integrate - they even didn't affect the class library code. Don't you mind to integrate them? With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 2:18 PM To: harmony-dev@incubator.apache.org Subject: Re: [vm] IBM VME related issues Thanks for pointing them out Alexey. Alexey Varlamov wrote: Here is the list of JIRA issues which should not slip attention of IBM engineers: HARMONY-1596 HARMONY-1309 HARMONY-813 These are just the ones I'm aware of, please extend this list if you know some :) -- Regards, Alexey - 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]
[drlvm][thread] Could you please fix race conditions?
Artem, Andrey, Nikolay, Let me attract your attention the following recent issue: http://issues.apache.org/jira/browse/HARMONY-1669. Please, could any of you volunteer to make a patch? Thank you in advance. With best regards, Alexei Fedotov, 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]
[drlvm][interpreter] ChoiceFormatTest.test_parseLjava_lang_StringLjava_text_ParsePosition() fails on interpreter
Hello, Ivan!
You wrote,
why my authorship was discarded from interpreter.cpp?
The authorship is not easily discarded - there are times when others are
painfully trying to recall who have written that code. :-) Could you
please look into the following issue with the interpreter, reported by
Alexey Varlamov?
http://issues.apache.org/jira/browse/HARMONY-1672
Thank you in advance!
With best regards,
Alexei Fedotov,
Intel Middleware Products Division
-Original Message-
From: Ivan Volosyuk [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 06, 2006 6:17 PM
To: harmony-dev@incubator.apache.org
Subject: Re: svn commit: r419557 - in
/incubator/harmony/enhanced/drlvm/trunk/vm:
interpreter/src/interpreter.cpp
vmcore/src/init/vm.cpp vmcore/src/jit/jit_runtime_support.cpp
vmcore/src/verifier/Verifier.cpp
It is good to see that we finally have java1.5 support in DRLVM.
One small question, why my authorship was discarded from
interpreter.cpp?
:)
--
Ivan
On 7/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: geirm
Date: Thu Jul 6 07:02:51 2006
New Revision: 419557
URL: http://svn.apache.org/viewvc?rev=419557view=rev
Log:
HARMONY-677
minimal 1.5 class support - DRLVM can handle v49 classfiles
Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/interpreter/src/interpreter.c
pp
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/vm.cpp
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/jit/jit_runtime_su
ppor
t.cpp
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/verifier/Verifier.
cpp
Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/interpreter/src/interpreter.c
pp
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/
inte
rpreter/src/interpreter.cpp?rev=419557r1=419556r2=419557view=diff
===
===
---
incubator/harmony/enhanced/drlvm/trunk/vm/interpreter/src/interpreter.c
pp
(original)
+++
incubator/harmony/enhanced/drlvm/trunk/vm/interpreter/src/interpreter.c
pp
Thu Jul 6 07:02:51 2006
@@ -13,10 +13,6 @@
* See the License for the specific language governing permissions
and
* limitations under the License.
*/
-/**
- * @author Ivan Volosyuk
- * @version $Revision: 1.61.4.15.4.4 $
- */
#include interpreter.h
#include interpreter_exports.h
#include interpreter_imports.h
@@ -955,18 +951,22 @@
#ifndef NDEBUG
switch(cp_tag(cp, index)) {
-case 8:
+case CONSTANT_String:
DEBUG_BYTECODE(# dec (int)index String: \
cp[index].CONSTANT_String.string-bytes \);
break;
-
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] NPE is thrown when the kernel tests are run on Windows at revision 448448
Hi, Nadya, I tried to build DRLVM, faced the issue from the thread below, and filed a JIRA issue: https://issues.apache.org/jira/browse/HARMONY-1730. Does the patch worth to be applied to the README.txt? With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Spark Shen [mailto:[EMAIL PROTECTED] Sent: Friday, September 22, 2006 9:56 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 Thank you, I am trying :-). 2006/9/22, Vladimir Gorr [EMAIL PROTECTED]: On 9/22/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: When I roll away the latest changes for Character.java (H-1500 *Refactor some methods in java.lang.Character*) this issue disappears. It means a clue is here. Sorry for the late reply. JIRA 1500 is due to discussion [1] on the dev mailing list. I can not build DRLVM on my desktop. (Windows XP, RI JDK1.5.0, ant 1.6.5). So I could not reproduce the bug The prompted error message is: C:\spark\drlvm\trunk\build\make\build.xml:238: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:289: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:291: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:462: Warning: Could not find file C:\spark\drlvm\trunk\build\make\no_settings_in_config_or_environment to copy. This is the first time I build DRLVM, would you give me some hint about this error message. It seems you didn't run the *build.bat update* before starting the build. We need to run the following steps (sorry if you're aware about this): - svn checkout classlib - svn checkout drlvm - build classlib (cd classlib/trunk; ant fetch-depend; ant) - cd drlvm/trunk/build - build.bat update (you need to slightly some time here :-) ) - build.bat Thanks, Vladimir. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony- dev/200609.mbox/[EMAIL PROTECTED] com%3e Best regards Gang, it'd be not bad to run DRLVM testing for any commits to SVN repository. Otherwise we will be very hard to catch any errors like this. Any thoughts? Thanks, Vladimir. On 9/21/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/21/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: NPE is thrown for all kernel tests when testing is run on Windows at revision 448448: build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test ... [echo] RUNNING : java.lang.Class1_5Test [junit] java.lang.NullPointerException [junit] at com.ibm.icu.lang.UCharacter.getProperty ( UCharacter.java :6073) [junit] at com.ibm.icu.lang.UCharacter.getType(UCharacter.java :2974) [junit] at com.ibm.icu.lang.UCharacter.isWhitespace( UCharacter.java :3162) [junit] at java.lang.Character.isWhitespace(Character.java:3091) [junit] at java.lang.Character.isWhitespace(Character.java:3078) [junit] at java.util.Properties.load(Properties.java:378) [junit] at java.util.PropertyResourceBundle .init( PropertyResourceBundle.java:44) snipped Does anybody observe this issue? As for Linux all works fine. I am looking into this issue. Is there any progress here? Did you managed to reproduce it? Same issue is also mentioned for other thread (*Trouble Building DRLVM*). Thanks in advance, Vladimir. Best regards Thanks, Vladimir. -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
README.txt patch Was: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448
BTW, I really enjoyed the last item of the Quick Start section: 7. If building the DRLVM fails, read this README and follow building instructions to the point. A hardcore programmer can loop infinitely here. :-) With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Fedotov, Alexei A Sent: Friday, October 06, 2006 12:20 AM To: =SMTP:[EMAIL PROTECTED] Cc: harmony-dev@incubator.apache.org Subject: RE: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 Hi, Nadya, I tried to build DRLVM, faced the issue from the thread below, and filed a JIRA issue: https://issues.apache.org/jira/browse/HARMONY-1730. Does the patch worth to be applied to the README.txt? With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Spark Shen [mailto:[EMAIL PROTECTED] Sent: Friday, September 22, 2006 9:56 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] NPE is thrown when the kernel tests are run on Windows at revision 448448 Thank you, I am trying :-). 2006/9/22, Vladimir Gorr [EMAIL PROTECTED]: On 9/22/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: When I roll away the latest changes for Character.java (H-1500 *Refactor some methods in java.lang.Character*) this issue disappears. It means a clue is here. Sorry for the late reply. JIRA 1500 is due to discussion [1] on the dev mailing list. I can not build DRLVM on my desktop. (Windows XP, RI JDK1.5.0, ant 1.6.5). So I could not reproduce the bug The prompted error message is: C:\spark\drlvm\trunk\build\make\build.xml:238: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:289: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:291: The following error occurred while executing this line: C:\spark\drlvm\trunk\build\make\setup.xml:462: Warning: Could not find file C:\spark\drlvm\trunk\build\make\no_settings_in_config_or_environment to copy. This is the first time I build DRLVM, would you give me some hint about this error message. It seems you didn't run the *build.bat update* before starting the build. We need to run the following steps (sorry if you're aware about this): - svn checkout classlib - svn checkout drlvm - build classlib (cd classlib/trunk; ant fetch-depend; ant) - cd drlvm/trunk/build - build.bat update (you need to slightly some time here :-) ) - build.bat Thanks, Vladimir. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony- dev/200609.mbox/[EMAIL PROTECTED] . com%3e Best regards Gang, it'd be not bad to run DRLVM testing for any commits to SVN repository. Otherwise we will be very hard to catch any errors like this. Any thoughts? Thanks, Vladimir. On 9/21/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 9/21/06, Spark Shen [EMAIL PROTECTED] wrote: Vladimir Gorr 写道: NPE is thrown for all kernel tests when testing is run on Windows at revision 448448: build.bat -Djunit.jar=%JUNIT_HOME%/junit-4.0.jar kernel.test ... [echo] RUNNING : java.lang.Class1_5Test [junit] java.lang.NullPointerException [junit] at com.ibm.icu.lang.UCharacter.getProperty ( UCharacter.java :6073) [junit] at com.ibm.icu.lang.UCharacter.getType(UCharacter.java :2974) [junit] at com.ibm.icu.lang.UCharacter.isWhitespace( UCharacter.java :3162) [junit] at java.lang.Character.isWhitespace(Character.java:3091) [junit] at java.lang.Character.isWhitespace(Character.java:3078) [junit] at java.util.Properties.load(Properties.java:378) [junit] at java.util.PropertyResourceBundle .init( PropertyResourceBundle.java:44) snipped Does anybody observe this issue? As for Linux all works fine. I am looking into this issue. Is there any progress here? Did you managed to reproduce it? Same issue is also mentioned for other thread (*Trouble Building DRLVM*). Thanks in advance, Vladimir. Best regards Thanks, Vladimir. -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Spark Shen China Software Development Lab, IBM
RE: [general] Dynamic class loading
Hello, Nathan, Had Nikolay said anything about JVM modification? As far as I understand him the class library should be just enhanced with this smart class loader. Now imagine how our reproducers would look in JIRA: java -cp http://svn.apache.org/... -Djava.system.class.loader=org.apache.harmony.Nikolagent TestClass Just cut paste it in your console with Harmony JRE in PATH! Nikolay's class loader will manage dependencies in the class path (or should I call it source path now?), download required source files to the temporary cache, compile them and execute. This class loader can even decide should it launch the test via TestNG runner or JUnit. It can understand OSGi bundles. It can download binary modules from maven repositories worldwide. We can even think of distributed test execution over computers of Harmony community members. This can be a protocol for you to test your changes on Pavel's Linux if Pavel sets some security checkbox in his Harmony JRE allowing a trust mode for test requests from Harmony committers. Doesn't this sound cool? With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Saturday, October 07, 2006 3:04 AM To: harmony-dev@incubator.apache.org Subject: Re: [general] Dynamic class loading Stefano is correct, this doesn't require anything special in the VM. In fact, the basics of this already exist -- JavaServer Pages. Is compiling code a big problem? -Nathan On 10/6/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Nikolay Chugunov wrote: From the beginning of learning Java and till now I hate to compile java source code before run it. I propose to develop easy solution for this problem: compile java sources on fly. Command to do it can look like: java -cp ...:mytool.jar -Djava.system.class.loader=classloader.MyClassLoaderHelloWorld When executing any application, if MyClassLoader does not find compiled class in class path, it will try to find file-source of this class with java extension in class path. If MyClassLoader finds this file, then MyClassLoader will compile source on fly and load class to MyClassLoader using *defineClass* method. The second improvement which I propose to develop is to load jar file from internet, if user specify URL to jar file in command line. MyClassLoader may cache compiled classes and loaded jars. MyClassLoader may use standard and Eclipse compiler to compile sources. Also MyClassLoader may compile on fly other sources (like Jasmin). The base of my tool will be existing URLClassLoader in Harmony. What do you think about my proposals? hmmm, I've thought about implementing something like this several times myself but I don't think you need to modify a JVM to achieve that, you can just execute a loader class that than knows your source path and has access to a nice compiler and does compilation at class loading time. or am I wrong? -- Stefano. - 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] Non-bug difference HARMONY-1688?
Egor, You wrote, The root cause is somewhere beyond the JIT. Have you agreed with Mikhail suggestion to fix http://issues.apache.org/jira/browse/HARMONY-1688 on JIT side? With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Alexey Varlamov [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 4:16 PM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] Non-bug difference HARMONY-1688? 2006/10/9, Alexey Varlamov [EMAIL PROTECTED]: 2006/10/9, Alexey Varlamov [EMAIL PROTECTED]: 2006/10/9, Pavel Pervov [EMAIL PROTECTED]: Commenting on (1) I should note, that VM generally can't determine the fact of initiating class loading; it can only be done in Java (except bootstrap class loader, of course). I presume you mean cases of direct calls to loadClass() from executed Java code. Well, the same way VM loads array classes on its own, not resorting to Java loader instance. So AFAIU, neither VM nor Java have 100% chance to register initiating loading singly on their own. Hey, I found the clear specification on (1)! Look at JVMS 2nd ed, Para 5.3.2 - 5.3.3, it reads: First, the Java virtual machine determines whether L has already been recorded as an initiating loader of a class or interface denoted by N. If so, this class or interface is C, and no class creation is necessary. Otherwise the Java virtual machine invokes loadClass(N ) on L. [0] http://java.sun.com/docs/books/vmspec/2nd- edition/html/ConstantPool.doc.html#79441 So this is definitely bug of DRLVM, which should be fixed mainly on VM side. And we may want to think how to avoid data duplication in VM and kernel classes on this matter... AFAIK, there is the bug: DRLVM does not record initiating class loader of a class. (1) is just the consequence. Not really. After H-1363 (aka BBC), j.l.ClassLoader records initiated classes. There may be some holes in impl (e.g. for array classes), but kernel classes fulfill API contract in general. On 10/9/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Folks, Would you mind to spend some time looking at HARMONY-1688? Good knowledge of classloading and security machinery is an advantage :) In short, we face 2 issues in DRLVM: 1) DRLVM itself is not aware of classes initiated (in contrast to defined ones) by a loader, and always delegates to Java classes for lookup (except bootstrap loader, of course). This is not really queer behaviour, but seems incompartible with most VMs. BTW, currently this affects implementation of jvmtiGetClassLoaderClasses(), which I believe has a bug - it returns defined classes only. 2) j.s.AccessController of DRLVM treats system classes (i.e. loaded by bootstrap loader) equally with application classes while examining execution stack, while RI seems to be simply skipping them. In other words, DRLVM would always perform ProtectionDomain.checkPermission() with AllPermission for bootstrap classes, and RI will omit such check if no user classes on stack. This potentially may produce subtle effects in security-exigent areas. Also, both can be considered from performance perspective, probably having somewhat negative impact. What do you think, how will we resolve this? [0] http://issues.apache.org/jira/browse/HARMONY-1688 --- -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [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] Thread Manager jvmti related issues fixes (was: Re: [jira] Commented: (HARMONY-1421))
Artem, Have you noticed http://issues.apache.org/jira/browse/HARMONY-1741? It also address suspend problems. My humble comment about wasn't correct: the patch for http://issues.apache.org/jira/browse/HARMONY-1669 was windows-specific, so probably this was a different issue. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Artem Aliev [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 20, 2006 8:34 PM To: harmony-dev@incubator.apache.org Subject: Re: [DRLVM] Thread Manager jvmti related issues fixes (was: Re: [jira] Commented: (HARMONY-1421)) Ivan, We do a lot for this cyclic suspend problem, I hope we does it right. I think the problem is in typo that was done in last patch. Fix attached. Could you please verify it. I will also attach it to the HARMONY-1421 we already try to has global lock for suspend_other(). Here is a deadlock scenario: thread1: thread2 assert(hythread_is_suspend_enabled()); global_lock(); supend(thread2); global_unlock(); ... assert(hythread_is_suspend_enabled()); global_lock(); supend(thread1); global_unlock(); safe_point() // stop heresafe_point() // stop here Thanks Artem On 9/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: I have found one fundamental design flow in implementation of: hythread_suspend_other() hythread_suspend_all() The functions should be called only from suspend enabled state, because the should be itself a valid point of suspension to prevent deadlocks. The other problem is: hythread_suspend_other() should also utilize hythread_global_lock() as the hythread_suspend_all() do via hythread_iterator_create(), otherwise this two functions can deadlock either. I have made a patch, but the assertion for suspend_disable_count fails almost in every test. I'm continue hunting the bug. -- Ivan On 9/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Artem, it looks like two thread mutually suspended each other. This is only reproducible when jvmti.patch from the JIRA is applied. -- Ivan On 9/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: I have reproduced the problem with the stack trace same as reported by Gregory. Here is the stack trace of thread starting GC: #4 0xb7af84bc in sched_yield () from /lib/libc.so.6 #5 0xb7bd5efd in hythread_yield () at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_basic.c:296 #6 0xb7bd8360 in wait_safe_region_event (thread=0x863e470) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_suspend.c:226 #7 0xb7bd8580 in hythread_suspend_all (t=0xbfce15d4, group=0x0) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_suspend.c:401 #8 0xb6eb2872 in stop_the_world_root_set_enumeration () at /home/ivan/svn/drlvm/trunk/vm/vmcore/src/gc/stop_the_world_root_set_enu m.cp p:89 #9 0xb6eb2b89 in vm_enumerate_root_set_all_threads () at /home/ivan/svn/drlvm/trunk/vm/vmcore/src/gc/stop_the_world_root_set_enu m.cp p:141 #10 0xb6c845aa in enumerate_universe () at /home/ivan/svn/drlvm/trunk/vm/gc/src/collect.cpp:127 #11 0xb6c8584a in force_gc () at /home/ivan/svn/drlvm/trunk/vm/gc/src/collect.cpp:363 #12 0xb6c9503b in select_force_gc () at /home/ivan/svn/drlvm/trunk/vm/gc/src/selector.cpp:287 #13 0xb6c9007e in gc_force_gc () at /home/ivan/svn/drlvm/trunk/vm/gc/src/gc_for_vm.cpp:336 #14 0xb6e289e1 in Java_java_lang_VMMemoryManager_runGC () Two other threads: #3 0xb7be9704 in tm_tls_size () from /home/ivan/svn/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/defa ult/ libhythr.so #4 0xb7af84bc in sched_yield () from /lib/libc.so.6 #5 0xb7bd5efd in hythread_yield () at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_basic.c:296 #6 0xb7bd8360 in wait_safe_region_event (thread=0x805ce50) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_suspend.c:226 #7 0xb7bd83e0 in hythread_suspend_other (thread=0x805ce50) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_suspend.c:286 #8 0xb7bd8b22 in unreserve_lock (lockword_ptr=0xa65da07c) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_thin_monitor.c:1 68 #9 0xb7bd8ece in hythread_thin_monitor_try_enter (lockword_ptr=0xa65da07c) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_thin_monitor.c:3 13 #4 0xb7b792be in __lll_mutex_lock_wait () from /lib/libpthread.so.0 #5 0xb7b76074 in _L_mutex_lock_150 () from /lib/libpthread.so.0 #6 0xb7fdb290 in fixup () from /lib/ld-linux.so.2 #7 0xb7bd79e4 in hymutex_lock (mutex=0x805d150) at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_mutex.c:71 #8 0xb7bd6d29 in hythread_monitor_enter (mon_ptr=0x805d118) at
RE: [jira] Commented: (HARMONY-1670) [classlib][luni] invalid testcase in ClassTest
Mikhail, I already got several personal feedbacks about these comments. I accept that they are not good. I tried to express an idea that JIRAs marked with this comment prevent getting 100% pass rate on DRLVM. When I search for Unit_Tests_Pass_on_DRLVM in comments I will get a list of bugs to fix. Any suggestions how the comment should like? My only requirement is to keep Unit_Tests_Pass_on_DRLVM lexem in this comment. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Mikhail Loenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 2:37 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Commented: (HARMONY-1670) [classlib][luni] invalid testcase in ClassTest Hi Alexei I'm sorry I comlpetely don't understand your comment (as well as a number of similar comments in other JIRAs) Thanks, Mikhail 2006/10/7, Alexei Fedotov (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY- 1670?page=comments#action_12440591 ] Alexei Fedotov commented on HARMONY-1670: - [drlvm][unit] Blocks http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM This is a low risk test fix. [classlib][luni] invalid testcase in ClassTest -- Key: HARMONY-1670 URL: http://issues.apache.org/jira/browse/HARMONY-1670 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey Varlamov Priority: Trivial Attachments: H-1670.patch The test_getDeclaredMethodLjava_lang_String$Ljava_lang_Class of modules/luni/src/test/java/org/apache/harmony/luni/tests/java/lang/Clas sTes t.java checks if IllegalAccessException is thrown during invokation of private method of inner class. This is bad due to: 1) the check is invalid, see HARMONY-1309 for details; 2) The ClassTest is not appropriate for testing reflection, and this is already covered in j.l.reflect.* tests. -- 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 - 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: Hello everyone
Hello, Alex, Welcome aboard! If you are looking for the task, please, don't miss the page http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM. You can join fixing DRLVM bugs. Another interesting thing to do is to start your favorite Java app using Harmony - this probably would require a fair amount of bug fixing as well. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Alex luo [mailto:[EMAIL PROTECTED] Sent: Thursday, October 12, 2006 12:39 PM To: harmony-dev@incubator.apache.org Subject: Hello everyone Hello everyone: I am a student from Nanjing University of China. I have great interest in Harmony project, and I want to make contribution to this project. Could anyone tell what I can do now. By the way, I have signed the CLA. -- Alex Luo Department of Computer Science and Technology, Nanjing University 210093 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JIRA/Tomcat problem Was: [classlib][util.prefs] Implementation should be compatible with RI
Dear admins, We are experiencing the following problem while attaching patches to HARMONY-1751. Errors Exception trying to establish attachment directory. Check that the application server and JIRA have permissions to write to it: com.atlassian.jira.web.util.AttachmentException: Cannot write to attachment directory. Check that the application server and JIRA have permissions to write to: /usr/local/tomcat/tomcat-jira/attachments/HARMONY/HARMONY-1751 Could you please help? With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Elena Semukhina [mailto:[EMAIL PROTECTED] Sent: Thursday, October 12, 2006 12:20 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][util.prefs] Implementation should be compatible with RI I prepared the patch for the test and a sample patch for implementation which enables the test passing on IBM VME. As I'm not an expert in util.prefs, I'd like someone to review the patch and add a warning message. Unfortunately I did not manage to upload attachments to H-1751; got the mesage: Exception trying to establish attachment directory. Check that the application server and JIRA have permissions to write to it: com.atlassian.jira.web.util.AttachmentException: Cannot write to attachment directory. Check that the application server and JIRA have permissions to write to: /usr/local/tomcat/tomcat-jira/attachments/HARMONY/HARMONY-1751 Are there any problems with attachment directory? I'll make another try later. On 10/12/06, Nathan Beyer [EMAIL PROTECTED] wrote: Can you provide a patch for the test case that correctly asserts the specification's contract and passes on the RI? This may help for someone to provide a fix for the issue. -Nathan On 10/11/06, Elena Semukhina [EMAIL PROTECTED] wrote: Hi all, org.apache.harmony.prefs.tests.java.util.prefs.PreferencesTest fails on some machines when there are restrictions in access to system registry. https://issues.apache.org/jira/browse/HARMONY-1751 describes the issue. It looks like Harmony implementation does not follow spec for Preferences.systemNodeForPackage(). Besides, the test is incorrect as well because it does not expect java.util.prefs.BackingStoreException on Preferences.childrenNames() and fails on RI. Could anyone look into the issue? -- Thanks, Elena - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Elena - 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]97.16% tests of Apache Ant passed on Harmony
Tony, I tried a substring (package name) in Search for test: field. This solved test lookup by category for me. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Tony Wu [mailto:[EMAIL PROTECTED] Sent: Thursday, October 12, 2006 1:44 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib]97.16% tests of Apache Ant passed on Harmony Hi I have a try and notice that it lists all the test results in one page. my suggestion is to add a column like category in order to showing the results by category, or just show the result by specified submitter? I think it is necessary when there are many results posted. On 10/12/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: the my results were upload to the http://www.harmonytest.org/testapp.do as runs 28 and 29. thanks, Vladimir On 10/12/06, Tony Wu [EMAIL PROTECTED] wrote: yes, I'm working on collecting the detail of these failures. On 10/12/06, Paulex Yang [EMAIL PROTECTED] wrote: Nice work, Tony! Any more description on what happened to these failures/errors? Spark, you must not clicked that link, it shows one error on RI:) Spark Shen wrote: Tony Wu 写道: I have tried the Apache ant 1.6.5 on lateset harmony classlib on Win32 system. It got 97.16% passed, seems not bad ;-) I'll go ahead to run on other vm and other platform and analyse the failure and fix them if possible. What I have done was updated on the wiki page http://wiki.apache.org/harmony/Apache_Ant Anyone have interest are welcome to join me:) Hi Tony: What is pass rate of RI? Best regards -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Tony Wu China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tony Wu China Software Development Lab, IBM - 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] Commented: (HARMONY-1670) [classlib][luni] invalid testcase in ClassTest
Mikhail, Alexey, I have double checked reasoning about H-1309, H-1670. Alexey's solution is good with me, though I see one more option. If RI and J9 have a bug, shouldn't we correct the test in a way it would fail on these VMs? What do you think? With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Alexey Varlamov [mailto:[EMAIL PROTECTED] Sent: Thursday, October 12, 2006 10:22 AM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Commented: (HARMONY-1670) [classlib][luni] invalid testcase in ClassTest Too many Alexe[i|y]s on the list %). [snip] BTW, what is the reason to remove a part of the test? Are the checks invalid or VM-specific? OK, let me answer this particular question: Yes, the removed check is invalid but passes on some JREs (VMs). In short, top level class permitted to access any members of a nested class, including private ones, while the check expects IllegalAccessException to be thrown. There is a comment in JIRA's description: 1) the check is invalid, see HARMONY-1309 for details; Indeed, the HARMONY-1309 contains exhaustive information, including reference to JLS and Sun's bug database. If there are other misunderstandings, I hope we can resolve them privately. -- Regards, Alexey Thanks, Mikhail 2006/10/12, Fedotov, Alexei A [EMAIL PROTECTED]: Mikhail, I don't understand either: This is a low risk test fix. Here should be the following text: This is a fix of the test. Test fixes rarely affect more than one test, they are local. Hence, they wouldn't produce painful errors which took many geek/weeks to locate. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Mikhail Loenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 5:57 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Commented: (HARMONY-1670) [classlib][luni] invalid testcase in ClassTest I don't understand either: This is a low risk test fix. 2006/10/11, Fedotov, Alexei A [EMAIL PROTECTED]: Mikhail, I already got several personal feedbacks about these comments. I accept that they are not good. I tried to express an idea that JIRAs marked with this comment prevent getting 100% pass rate on DRLVM. When I search for Unit_Tests_Pass_on_DRLVM in comments I will get a list of bugs to fix. Any suggestions how the comment should like? My only requirement is to keep Unit_Tests_Pass_on_DRLVM lexem in this comment. IMHO It makes sense to discuss it on a separate thread with different subject, so that other people could notice that discussion and participate Thanks, Mikhail With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Mikhail Loenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 2:37 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Commented: (HARMONY-1670) [classlib][luni] invalid testcase in ClassTest Hi Alexei I'm sorry I comlpetely don't understand your comment (as well as a number of similar comments in other JIRAs) Thanks, Mikhail 2006/10/7, Alexei Fedotov (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY- 1670?page=comments#action_12440591 ] Alexei Fedotov commented on HARMONY-1670: - [drlvm][unit] Blocks http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM This is a low risk test fix. [classlib][luni] invalid testcase in ClassTest -- Key: HARMONY-1670 URL: http://issues.apache.org/jira/browse/HARMONY-1670 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey Varlamov Priority: Trivial Attachments: H-1670.patch The test_getDeclaredMethodLjava_lang_String$Ljava_lang_Class of modules/luni/src/test/java/org/apache/harmony/luni/tests/java/lang/Cla s sTes t.java checks if IllegalAccessException is thrown during invokation of private method of inner class. This is bad due to: 1) the check is invalid, see HARMONY-1309 for details; 2) The ClassTest is not appropriate for testing reflection, and this is already covered in j.l.reflect.* tests. -- 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 - Terms of use : http://incubator.apache.org/harmony
RE: [jira] Problem attaching patch
Geir, I've just checked that the problem still exists. The error message is the same: --- Errors Exception trying to establish attachment directory. Check that the application server and JIRA have permissions to write to it: com.atlassian.jira.web.util.AttachmentException: Cannot write to attachment directory. Check that the application server and JIRA have permissions to write to: /usr/local/tomcat/tomcat-jira/attachments/HARMONY/HARMONY-1670 --- One with a proper access should check a disk space and permissions for /usr/local/tomcat/tomcat-jira/attachments/. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Thursday, October 12, 2006 10:23 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Problem attaching patch Oleg Khaschansky wrote: I've just attached patch to JIRA You are a committer, that doesn't count :-) Being a committer doesn't matter. Do we have a JIRA problem or not? geir On 10/12/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I've just attached patch to JIRA 2006/10/12, Tim Ellison [EMAIL PROTECTED]: Ivanov, Alexey A wrote: Then it looks more like JIRA configuration problem since many issues can't be attached files to. Does anyone know how to fix it? Committers? No, I don't. We share JIRA with other projects, so we need infra help. 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] -- 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] - 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][unit tests] the goal is to achieve 100% pass rate
Geir, I reviewed the patches for HARMONY-1816 (non-daemon thread counting is done more accurately) and for HARMONY-1823 - the fix is to clean patches are good. I believe the patches worth to be committed: I've tried the patches for running tests from luni module 162 times and get the following results: $ grep FAILED luni.log | sort | uniq -c 63 [junit] TEST org.apache.harmony.tests.internal.net.www.protocol.http .HttpURLConnectionTest FAILED 162 [junit] TEST tests.api.java.lang.reflect.FieldTest FAILED 6 [junit] TEST tests.api.java.net.InetAddressTest FAILED The following tests were excluded: Index: modules/luni/build.xml === --- modules/luni/build.xml (revision 463342) +++ modules/luni/build.xml (working copy) @@ -325,6 +325,14 @@ exclude name=tests/api/java/net/URLConnectionTest.jav a / exclude name=tests/api/java/net/URLTest.java / exclude name=tests/api/java/net/SocketPermissionTest. java / + +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadGroupTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadLocalTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ClassTest.java / +exclude name=tests/api/java/util/FormatterTest.java / + /fileset /batchtest With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006 9:58 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm][unit tests] the goal is to achieve 100% pass rate great work - we'll get those applied ASAP. Elena Semukhina wrote: Yesterday I tried the following patches: http://issues.apache.org/jira/browse/HARMONY-1592 http://issues.apache.org/jira/browse/HARMONY-1816 http://issues.apache.org/jira/browse/HARMONY-1823 https://issues.apache.org/jira/browse/HARMONY-1741 They work fine. The first three patches restore recent classlib tests pass rate degradation. On 10/11/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Excellent. As appreciative as I am of J9, I can't wait to work in all-Harmony code :) geir Elena Semukhina wrote: Hello all, I think that the goal of running classlib unit tests on DRLVM with 100% pass rate could be worth to achieve. Actually today we have 99% (without awt/swing) but still have about 30 failures/errors. Most of them have been evaluated and corresponding JIRAs filed. There is a page on Harmony Wiki which lists those JIRA issues: http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM Are there any volunteers to help with DRLVM bugs fixing? Thanks, Elena - 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][unit tests] the goal is to achieve 100% pass rate
Oops, review of HARMONY-1823 should be: The fix is to clean an interrupt flag. Patches are good. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Fedotov, Alexei A Sent: Friday, October 13, 2006 6:12 PM To: [EMAIL PROTECTED] Cc: harmony-dev@incubator.apache.org Subject: RE: [drlvm][unit tests] the goal is to achieve 100% pass rate Geir, I reviewed the patches for HARMONY-1816 (non-daemon thread counting is done more accurately) and for HARMONY-1823 - the fix is to clean patches are good. I believe the patches worth to be committed: I've tried the patches for running tests from luni module 162 times and get the following results: $ grep FAILED luni.log | sort | uniq -c 63 [junit] TEST org.apache.harmony.tests.internal.net.www.protocol.http .HttpURLConnectionTest FAILED 162 [junit] TEST tests.api.java.lang.reflect.FieldTest FAILED 6 [junit] TEST tests.api.java.net.InetAddressTest FAILED The following tests were excluded: Index: modules/luni/build.xml === --- modules/luni/build.xml (revision 463342) +++ modules/luni/build.xml (working copy) @@ -325,6 +325,14 @@ exclude name=tests/api/java/net/URLConnectionTest.jav a / exclude name=tests/api/java/net/URLTest.java / exclude name=tests/api/java/net/SocketPermissionTest. java / + +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadGroupTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ThreadLocalTest.java / +exclude name=org/apache/harmony/luni/tests/java/lang/ClassTest.java / +exclude name=tests/api/java/util/FormatterTest.java / + /fileset /batchtest With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006 9:58 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm][unit tests] the goal is to achieve 100% pass rate great work - we'll get those applied ASAP. Elena Semukhina wrote: Yesterday I tried the following patches: http://issues.apache.org/jira/browse/HARMONY-1592 http://issues.apache.org/jira/browse/HARMONY-1816 http://issues.apache.org/jira/browse/HARMONY-1823 https://issues.apache.org/jira/browse/HARMONY-1741 They work fine. The first three patches restore recent classlib tests pass rate degradation. On 10/11/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Excellent. As appreciative as I am of J9, I can't wait to work in all-Harmony code :) geir Elena Semukhina wrote: Hello all, I think that the goal of running classlib unit tests on DRLVM with 100% pass rate could be worth to achieve. Actually today we have 99% (without awt/swing) but still have about 30 failures/errors. Most of them have been evaluated and corresponding JIRAs filed. There is a page on Harmony Wiki which lists those JIRA issues: http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM Are there any volunteers to help with DRLVM bugs fixing? Thanks, Elena - 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]97.16% tests of Apache Ant passed on Harmony
Tony, Let's try and converge our visions. BTW, I really like your work about ANT unit tests. What I want is a more flexible one Could you please give more details on that? I just tried looking for '.ant.' and got your results separated. What would be a use case to add more search capabilities? I could imagine enhancing our system with something differentiating class library tests and ANT tests, say a pointer to a test source repository. Is it what you are talking about? With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Tony Wu [mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006 4:03 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib]97.16% tests of Apache Ant passed on Harmony not sure I catch you, do you mean search the *substring* as keywords in the *Search for test:* ? It shows me all results whose name contains a *substring*. What I want is a more flexible one, not only designed for recording test of harmony itself, but also for other applications. So the category may includes harmony, ant, derby, etc. Or let's input it ourselves. BTW, is it a good idea to add an option - RI into the JVM column? ;-) On 10/12/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: Tony, I tried a substring (package name) in Search for test: field. This solved test lookup by category for me. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Tony Wu [mailto:[EMAIL PROTECTED] Sent: Thursday, October 12, 2006 1:44 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib]97.16% tests of Apache Ant passed on Harmony Hi I have a try and notice that it lists all the test results in one page. my suggestion is to add a column like category in order to showing the results by category, or just show the result by specified submitter? I think it is necessary when there are many results posted. On 10/12/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: the my results were upload to the http://www.harmonytest.org/testapp.do as runs 28 and 29. thanks, Vladimir On 10/12/06, Tony Wu [EMAIL PROTECTED] wrote: yes, I'm working on collecting the detail of these failures. On 10/12/06, Paulex Yang [EMAIL PROTECTED] wrote: Nice work, Tony! Any more description on what happened to these failures/errors? Spark, you must not clicked that link, it shows one error on RI:) Spark Shen wrote: Tony Wu 写道: I have tried the Apache ant 1.6.5 on lateset harmony classlib on Win32 system. It got 97.16% passed, seems not bad ;-) I'll go ahead to run on other vm and other platform and analyse the failure and fix them if possible. What I have done was updated on the wiki page http://wiki.apache.org/harmony/Apache_Ant Anyone have interest are welcome to join me:) Hi Tony: What is pass rate of RI? Best regards -- Paulex Yang China Software Development Lab IBM -- --- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Tony Wu China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Tony Wu China Software Development Lab, IBM - 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] -- Tony Wu China Software Development Lab, IBM - 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: [j9][testing] some classlib unit tests fail
Hello Boris,
I'm not an expert in security. I even couldn't keep a pin of my credit
card secured from my wife. :-)
Anyway, few weeks ago I faced a problem with tests which failed due to
java.policy file forgotten by a release engineer in his home directory.
We decided that changing the java.security.policy property and invoking
refresh() is a hacker style, so we had to write our security manager
implementation. I have just checked that the guy who actually made the
fix implemented the property hack.
That is why I vote for the second choice. It is much simpler and we can
migrate to the first method later if needed.
Does it make sense?
With best regards,
Alexei Fedotov,
Intel Middleware Products Division
-Original Message-
From: Boris Kuznetsov [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 04, 2006 1:24 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [j9][testing] some classlib unit tests fail
The tests mentioned in HARMONY-1674
http://issues.apache.org/jira/browse/HARMONY-1674 depend on default
system policy file.
But if user policy file exists than, according to the spec, it is
added to system policy. It leads to the tests failures.
There are two options:
1. Rewrite the tests.
2. Use '-Djava.security.policy' to specify policy file and ignore
all
others:
-Djava.security.policy==${java.home}/lib/security/java.policy
I suggest the second one.
Comments?
On 10/4/06, Elena Semukhina [EMAIL PROTECTED] wrote:
Hello, all,
AFAIK, ant test should give 100% pass rate on j9 but I have 5
failures
which seem to be dependent on environment.
I've uploaded the results at
http://harmonytest.org/testapp.do?method=showrunid=9perPage=100page=
1na
me=result=0jira=0
There are also two JIRA issues detailing this:
HARMONY-1664http://issues.apache.org/jira/browse/HARMONY-1664 and
HARMONY-1674 http://issues.apache.org/jira/browse/HARMONY-1664
Can anyone help in analyzing the problem?
--
Thanks,
Elena
--
Best regards,
Boris Kuznetsov
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] [testing] Excluding commit tests until the problem is fixed
We have mighty guys on this list. Why cannot we just fix these tests instead of excluding them? I suggest starting with basic threading issues such as org.apache.harmony.luni.tests.java.lang.ThreadTest, org.apache.harmony.luni.tests.java.lang.ThreadGroupTest - they reliably fail in my environment. I volunteer for checking reliability of fixes. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 12:01 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] [testing] Excluding commit tests until the problem is fixed Gregory Shimansky wrote: Hello After reading several threads about drlvm tests failing for quite a while I decided we need to exclude them temporarily until the bugs are fixed. When on test fails, it means that other are not run after it because drlvm has several sets of tests which run in different modes, so there are many test runs in one build test command. When some test doesn't work for quite some time it means that other may not be ran for this period and we can get more failures accidently. That's actually not true. I never commit unless all tests (minus some kernel tests) run. The Finalizer and PhanRefQueueTest are flakey - I always repeat until the passed, so the rest could run. I'm just sick of it, so i did the magic @keyword attribute and committed. Excluding tests is not good, but not running some basic commit checks is worse, so I think we need to disable them until the bugs are fixed. So far I know about 3 tests which fail for sure: gc.LOS - stably hangs on windows XP gc.Finalizer and gc.PhantomReferenceQueue - fail because of incorrect CCE condition detected, fail with rate less than 100%. Ok I've just read that Geir has excluded them already Are there any other tests which don't work perfectly to do a clean tests run? I think we need it do make minimal commit checks for drlvm. I've seen java.lang.ThreadTest in kernel tests to output something that it has failed on reference JRE. Is this test correct if it doesn't work on RI? The failure however doesn't seem to make test run to fail so maybe we could leave this test for now. I also have a question about 15 smoke tests excluded with XXX or X_int keywords. They've been disabled since I remember. Is there any reason why they aren't included in test runs? I tried to put some back. StackTest still doesn't work. It's hard to believe... so I gave up and just kept going :) 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: [classlib]97.16% tests of Apache Ant passed on Harmony
Vladimir, I've noticed that CruiseControl automatic uploads to http://harmonytest.org don't have SVN revision as well. Do you think of adding SVN revisions or probably even DRLVM builds to your uploads? With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Tony Wu [mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006 2:53 PM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib]97.16% tests of Apache Ant passed on Harmony done On 10/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Nice - could you please put the SVN revision you built from? java -version That will help us track how old a set of results is... geir Tony Wu wrote: I have tried the Apache ant 1.6.5 on lateset harmony classlib on Win32 system. It got 97.16% passed, seems not bad ;-) I'll go ahead to run on other vm and other platform and analyse the failure and fix them if possible. What I have done was updated on the wiki page http://wiki.apache.org/harmony/Apache_Ant Anyone have interest are welcome to join me:) - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tony Wu China Software Development Lab, IBM - 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] [testing] Excluding commit tests until the problem is fixed
Hello Gregory, I'm ok to exclude the tests. From the other side I believe we can achieve a fair progress against deadlocks just by applying patches http://issues.apache.org/jira/browse/HARMONY-1741 (understood), http://issues.apache.org/jira/browse/HARMONY-1823 (tried). There is also a Windows-specific patch at http://issues.apache.org/jira/browse/HARMONY-1669 which can result in deadlock, though I haven't tried it myself yet. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Gregory Shimansky [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 12:23 AM To: Fedotov, Alexei A Cc: [EMAIL PROTECTED]; Ivan Volosyuk; Artem Aliev; Nikolay Kuznetsov; harmony- [EMAIL PROTECTED] Subject: Re: [drlvm] [testing] Excluding commit tests until the problem is fixed On Tuesday 17 October 2006 00:13 Fedotov, Alexei A wrote: We have mighty guys on this list. Why cannot we just fix these tests instead of excluding them? Because a test like gc.LOS hangs on windows for a month or more as far as I remember. AFAIK (excuse me if I missed something, I've caught up with emails skipping some) the problems come from APR implementation on windows, but I am not sure if there is a patch for APR to fix the problem. I hoped for a quick fix too because I don't like tests exclusion myself. But when the problem proves to be hard to solve it is better to put the test aside and have clean test runs to make development easier for everyone. I suggest starting with basic threading issues such as org.apache.harmony.luni.tests.java.lang.ThreadTest, org.apache.harmony.luni.tests.java.lang.ThreadGroupTest - they reliably fail in my environment. I volunteer for checking reliability of fixes. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 12:01 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] [testing] Excluding commit tests until the problem is fixed Gregory Shimansky wrote: Hello After reading several threads about drlvm tests failing for quite a while I decided we need to exclude them temporarily until the bugs are fixed. When on test fails, it means that other are not run after it because drlvm has several sets of tests which run in different modes, so there are many test runs in one build test command. When some test doesn't work for quite some time it means that other may not be ran for this period and we can get more failures accidently. That's actually not true. I never commit unless all tests (minus some kernel tests) run. The Finalizer and PhanRefQueueTest are flakey - I always repeat until the passed, so the rest could run. I'm just sick of it, so i did the magic @keyword attribute and committed. Excluding tests is not good, but not running some basic commit checks is worse, so I think we need to disable them until the bugs are fixed. So far I know about 3 tests which fail for sure: gc.LOS - stably hangs on windows XP gc.Finalizer and gc.PhantomReferenceQueue - fail because of incorrect CCE condition detected, fail with rate less than 100%. Ok I've just read that Geir has excluded them already Are there any other tests which don't work perfectly to do a clean tests run? I think we need it do make minimal commit checks for drlvm. I've seen java.lang.ThreadTest in kernel tests to output something that it has failed on reference JRE. Is this test correct if it doesn't work on RI? The failure however doesn't seem to make test run to fail so maybe we could leave this test for now. I also have a question about 15 smoke tests excluded with XXX or X_int keywords. They've been disabled since I remember. Is there any reason why they aren't included in test runs? I tried to put some back. StackTest still doesn't work. It's hard to believe... so I gave up and just kept going :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Shimansky, 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: [drlvm] [testing] Excluding commit tests until the problem is fixed
Sorry for my English - http://issues.apache.org/jira/browse/HARMONY-1669 Artem told this patch fixes a deadlock on Windows. I haven't tried the fix. As far as I understand we put SuspendThread() check and ResumeThread() action under one critical section when trying to flush memory. It's ok not to risk the integrity of the whole operation. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 1:30 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] [testing] Excluding commit tests until the problem is fixed Fedotov, Alexei A wrote: Hello Gregory, I'm ok to exclude the tests. From the other side I believe we can achieve a fair progress against deadlocks just by applying patches http://issues.apache.org/jira/browse/HARMONY-1741 (understood), http://issues.apache.org/jira/browse/HARMONY-1823 (tried). Maybe - i tried 1823 and didnt' see the failure. I'll look at both again. There is also a Windows-specific patch at http://issues.apache.org/jira/browse/HARMONY-1669 which can result in deadlock, though I haven't tried it myself yet. Do you mean the fix results in deadlock? or the fix fixes the deadlock? geir With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Gregory Shimansky [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 12:23 AM To: Fedotov, Alexei A Cc: [EMAIL PROTECTED]; Ivan Volosyuk; Artem Aliev; Nikolay Kuznetsov; harmony- [EMAIL PROTECTED] Subject: Re: [drlvm] [testing] Excluding commit tests until the problem is fixed On Tuesday 17 October 2006 00:13 Fedotov, Alexei A wrote: We have mighty guys on this list. Why cannot we just fix these tests instead of excluding them? Because a test like gc.LOS hangs on windows for a month or more as far as I remember. AFAIK (excuse me if I missed something, I've caught up with emails skipping some) the problems come from APR implementation on windows, but I am not sure if there is a patch for APR to fix the problem. I hoped for a quick fix too because I don't like tests exclusion myself. But when the problem proves to be hard to solve it is better to put the test aside and have clean test runs to make development easier for everyone. I suggest starting with basic threading issues such as org.apache.harmony.luni.tests.java.lang.ThreadTest, org.apache.harmony.luni.tests.java.lang.ThreadGroupTest - they reliably fail in my environment. I volunteer for checking reliability of fixes. With best regards, Alexei Fedotov, Intel Middleware Products Division -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 12:01 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] [testing] Excluding commit tests until the problem is fixed Gregory Shimansky wrote: Hello After reading several threads about drlvm tests failing for quite a while I decided we need to exclude them temporarily until the bugs are fixed. When on test fails, it means that other are not run after it because drlvm has several sets of tests which run in different modes, so there are many test runs in one build test command. When some test doesn't work for quite some time it means that other may not be ran for this period and we can get more failures accidently. That's actually not true. I never commit unless all tests (minus some kernel tests) run. The Finalizer and PhanRefQueueTest are flakey - I always repeat until the passed, so the rest could run. I'm just sick of it, so i did the magic @keyword attribute and committed. Excluding tests is not good, but not running some basic commit checks is worse, so I think we need to disable them until the bugs are fixed. So far I know about 3 tests which fail for sure: gc.LOS - stably hangs on windows XP gc.Finalizer and gc.PhantomReferenceQueue - fail because of incorrect CCE condition detected, fail with rate less than 100%. Ok I've just read that Geir has excluded them already Are there any other tests which don't work perfectly to do a clean tests run? I think we need it do make minimal commit checks for drlvm. I've seen java.lang.ThreadTest in kernel tests to output something that it has failed on reference JRE. Is this test correct if it doesn't work on RI? The failure however doesn't seem to make test run to fail so maybe we could leave this test for now. I also have a question about 15 smoke tests excluded with XXX or X_int keywords. They've been disabled since I remember. Is there any reason why they aren't included in test runs? I tried to put some back. StackTest still doesn't work. It's hard to believe... so I gave up and just kept going :) geir - Terms of use
RE: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
Guys, My best wishes! Keep doing a great job! With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 7:59 AM To: harmony-dev@incubator.apache.org Subject: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov 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]
RE: ECJ set as default compiler (WAS: [general] version of gcc and other tools)
Nathan, I've got two following stacks compile-support: [javac] Compiling 56 source files to /opt/harmony/classlib/build/test_support [javac] Since fork is false, ignoring memoryMaximumSize setting # An unexpected error has been detected by HotSpot Virtual Machine: # Java VM: Java HotSpot(TM) Server VM (1.5.0_06-b05 mixed mode) Stack: [0xbfe0,0xc000), sp=0xbfffbcdc, free space=2031k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libc.so.6+0x686dc] memcpy+0x1c C [libzip.so+0x10272] ZIP_GetNextEntry+0x54 C [libzip.so+0x3782] Java_java_util_zip_ZipFile_getNextEntry+0x30 j java.util.zip.ZipFile.getNextEntry(JI)J+0 j java.util.zip.ZipFile.access$700(JI)J+2 j java.util.zip.ZipFile$3.nextElement()Ljava/util/zip/ZipEntry;+54 j java.util.zip.ZipFile$3.nextElement()Ljava/lang/Object;+1 j org.eclipse.jdt.internal.compiler.batch.ClasspathJar.isPackage(Ljava/lan g/St ing;)Z+53 I start thinking about DRLVM to have this fixable. :-) With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 7:15 PM To: harmony-dev@incubator.apache.org Subject: Re: ECJ set as default compiler (WAS: [general] version of gcc and other tools) IMHO the correct ECJ jar should be located at classlib/trunk/depends/jars/ecj_3.2/ecj.jar You may also try to increase java heap size by setting ANT_OPTS variable to something like -Xmx512M. Regards, 2006/10/17, Weldon Washburn [EMAIL PROTECTED]: All, I did a fresh svn checkout an hour ago. During build, I saw the message, ...please place ECJ.JAR in ANT_HOME/lib and did what it said. Given a JAVA_HOME=.../jdk1.5.0_07, there may be more to it than just copying a jar file. My guess is that adding ECJ.JAR to Sun javac is now causing the following error message: [javac] -- [javac] 1. ERROR in C:\t_harmony\classlib\trunk\modules\archive\src\main\jav a\java\util\jar\Pack200.java [javac] (at line 0) [javac] /* [javac] ^ [javac] Internal compiler error [javac] java.lang.OutOfMemoryError: Java heap space I looked for a README file that says something about which Eclipse compiler to download and where to get it. Or if it is already downloaded, where to find it on my local drive. A find of README files on classlib/trunk turns up 2052 instances. If its in a README, its well obscured! Please tell me where the instructions are for downloading the correct version of Eclipse compiler. It might be good to add where to find Eclipse compiler to the, ...please place EJC.JAR message. On 10/16/06, Nathan Beyer [EMAIL PROTECTED] 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. -Nathan -- Forwarded message -- From: Geir Magnusson Jr. [EMAIL PROTECTED] Date: Oct 16, 2006 12:38 PM Subject: Re: [general] version of gcc and other tools To: harmony-dev@incubator.apache.org None from me, but please also add some useful message for people if not found like ECJ not found. Please copy useful info to useful info... Nathan Beyer wrote: On 10/15/06, Tim Ellison [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: I suppose that as a temporary solution, we can just get people to drop ECJ into ant/lib... Yes, that would be my preferred solution too, until Ant support comes along. Any objections to setting the harmony default compiler (in the build scripts) to Eclipse then? The 'fetch-depends' already downloads the necessary JAR, so copying it over should be a trivial task for now. -- Alexei Zakharov, Intel Enterprise Solutions Software Division, Russia - 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
HARMONY-1752: patch review
Hello Ilya,
I really like your patch from
http://issues.apache.org/jira/browse/HARMONY-1752. Let me participate in
a way I'm able to.
I cannot say why calling free(send_buf) when send_buf == NULL makes me
feel a bit uncomfortable. I also prefer a descriptive name for a label
cleanup1 (eg cleanup_buf).
I tried to track that guy who used cleanup labels in his C code.
modules/luni/src/main/native/luni/linux/OSNetworkSystemLinux.c:
The Linux version seems to contain exactly the same problem as you fix
in modules/luni/src/main/native/luni/windows/OSNetworkSystemWin32.c
modules/luni/src/main/native/luni/shared/luniglob.c
cleanup:
if (props) {
properties_free(PORTLIB, props);
}
if (bootDirectory) {
hymem_free_memory(bootDirectory);
}
The first if always fails if we come here using goto - we can put the
label after the first if. I suggest replacing the second if with
assert(!bootDirectory)
modules/archive/src/main/native/archive/shared/jarfile.c:
zip_freeZipEntry is not called on some paths - is it a memory leak?
modules/luni/src/main/native/launcher/shared/main.c
if (vm_args.options)
{
hymem_free_memory (vm_args.options);
}
Should we put here assert(!vm_args.options)?
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
RE: HARMONY-1752: patch review
Ilya,
Shouldn't we change OSNetworkSystemLinux.c as well?
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Andrew Zhang [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 19, 2006 2:05 PM
To: harmony-dev@incubator.apache.org
Subject: Re: HARMONY-1752: patch review
On 10/19/06, Ilya Okomin [EMAIL PROTECTED] wrote:
On 10/19/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 10/19/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote:
Hello Ilya,
I really like your patch from
http://issues.apache.org/jira/browse/HARMONY-1752. Let me
participate
in
a way I'm able to.
I cannot say why calling free(send_buf) when send_buf == NULL
makes
me
feel a bit uncomfortable.
It's safe to free NULL pointer.
I also prefer a descriptive name for a label
cleanup1 (eg cleanup_buf).
Alexei, you are right. I was thinking about 'cleanup_all' but for
some
inexplicable reasons forgot to rename it :)
I tried to track that guy who used cleanup labels in his C code.
Let the author speak for himself, but I think it's ok. It's a
frequentely
used error handling sytle in C programming. There's a logical
problem
in
OSNetworkSystemWin32.c, the cleanup may free an invalid pointer
fdset_read.
But I perfer to add NULL initiliazation when declaring fdset_read,
say,
fd_set * fdset_read = NULL;
comments?
Thanks, Andrew, IMO it is more convenient way that I've suggested.
The
problem was really that existed code was trying to free fdset_read,
that
wasn't NULL (we went to the 'cleanup' label before fdset_read
initialization).
I'll update patch for H-1752.
The updated patch looks fine. :)
Regards, Ilya.
modules/luni/src/main/native/luni/linux/OSNetworkSystemLinux.c:
The Linux version seems to contain exactly the same problem as
you
fix
in
modules/luni/src/main/native/luni/windows/OSNetworkSystemWin32.c
modules/luni/src/main/native/luni/shared/luniglob.c
cleanup:
if (props) {
properties_free(PORTLIB, props);
}
if (bootDirectory) {
hymem_free_memory(bootDirectory);
}
The first if always fails if we come here using goto - we can
put
the
label after the first if. I suggest replacing the second if with
assert(!bootDirectory)
modules/archive/src/main/native/archive/shared/jarfile.c:
zip_freeZipEntry is not called on some paths - is it a memory
leak?
modules/luni/src/main/native/launcher/shared/main.c
if (vm_args.options)
{
hymem_free_memory (vm_args.options);
}
Should we put here assert(!vm_args.options)?
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
--
Best regards,
Andrew Zhang
--
--
Ilya Okomin
Intel Middleware Products Division
--
Best regards,
Andrew Zhang
-
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] Configuration dependent test of InetAddress.getHostName
Denis,
Can we consider a patch from
http://issues.apache.org/jira/browse/HARMONY-73 as a fourth option?
Simply speaking, the patch adds a conditional operator which forces API
to returning localhost in this case.
Paulex,
This is your patch. What do you think?
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Denis Kishenko [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 19, 2006 3:44 PM
To: harmony-dev@incubator.apache.org
Subject: [classlib][test] Configuration dependent test of
InetAddress.getHostName
I have researched issue H-1664 and found one more difference with RI.
I run simple test on Windows Server 2003 SP1
=== Test =
import java.net.InetAddress;
import java.net.UnknownHostException;
public class Test {
public static void main(String[] args) throws UnknownHostException
{
System.out.println(by name (127.0.0.1) - +
InetAddress.getByName(127.0.0.1).getHostName());
System.out.println(by name (localhost) - +
InetAddress.getByName(localhost).getHostName());
System.out.println(by address - +
InetAddress.getByAddress(new byte[]{127, 0, 0, 1}).getHostName());
System.out.println(localhost - +
InetAddress.getLocalHost());
}
}
Windows Server 2003 SP1
=== RI ==
by name (127.0.0.1) - 127.0.0.1
by name (localhost) - localhost
by address - 127.0.0.1
localhost - nstdrlew21/10.125.122.60
= Harmony ==
by name (127.0.0.1) - nstdrlew21.ins.intel.com
by name (localhost) - localhost
by address - nstdrlew21.ins.intel.com
localhost - nstdrlew21/10.125.122.60
WinXP
= Both ===
by name (127.0.0.1) - localhost
by name (localhost) - localhost
by address - localhost
localhost - pbwdmkishen/10.125.132.226
Actually Harmony use native call of getnameinfo() to get host name
(which is reasonable IMHO). MSDN says The getnameinfo function
provides name resolution from an address to the host name.
InetAddressTest.test_getHostName (see H-1664) failed on WinServer
because InetAddress.getByName(127.0.0.1).getHostName() returned
nstdrlew21.ins.intel.com while localhost expected. So this test
looks like configuration dependent.
I see three possible options
1. Stay test as is. Just keep in mind that on specific configurations
this one fails.
2. Rewrite test to be configuration dependent. Test has to do the same
native call.
3. Exclude localhost checking from test_getHostName.
What do you think about this situation?
--
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: HARMONY-1752: patch review
Ilya,
Sorry, my fault. I was confused by the line 41.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Ilya Okomin [mailto:[EMAIL PROTECTED]
Sent: Friday, October 20, 2006 11:07 AM
To: harmony-dev@incubator.apache.org
Subject: Re: HARMONY-1752: patch review
On 10/19/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote:
Ilya,
Shouldn't we change OSNetworkSystemLinux.c as well?
Alexei, I'm watching at the latest sources from the svn and I'm not
sure we
need make changes to OSNetworkSystemLinux.c. The problem was in freeing
uninitialized fdset_read pointer. In the OSNetworkSystemWin32.c initial
value was undefined and in the OSNetworkSystemLinux.c it is set to
NULL.
Thus linux native looks fine for me.
Thanks, Ilya.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Andrew Zhang [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 19, 2006 2:05 PM
To: harmony-dev@incubator.apache.org
Subject: Re: HARMONY-1752: patch review
On 10/19/06, Ilya Okomin [EMAIL PROTECTED] wrote:
On 10/19/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 10/19/06, Fedotov, Alexei A [EMAIL PROTECTED]
wrote:
Hello Ilya,
I really like your patch from
http://issues.apache.org/jira/browse/HARMONY-1752. Let me
participate
in
a way I'm able to.
I cannot say why calling free(send_buf) when send_buf == NULL
makes
me
feel a bit uncomfortable.
It's safe to free NULL pointer.
I also prefer a descriptive name for a label
cleanup1 (eg cleanup_buf).
Alexei, you are right. I was thinking about 'cleanup_all' but for
some
inexplicable reasons forgot to rename it :)
I tried to track that guy who used cleanup labels in his C
code.
Let the author speak for himself, but I think it's ok. It's a
frequentely
used error handling sytle in C programming. There's a logical
problem
in
OSNetworkSystemWin32.c, the cleanup may free an invalid pointer
fdset_read.
But I perfer to add NULL initiliazation when declaring
fdset_read,
say,
fd_set * fdset_read = NULL;
comments?
Thanks, Andrew, IMO it is more convenient way that I've suggested.
The
problem was really that existed code was trying to free
fdset_read,
that
wasn't NULL (we went to the 'cleanup' label before fdset_read
initialization).
I'll update patch for H-1752.
The updated patch looks fine. :)
Regards, Ilya.
modules/luni/src/main/native/luni/linux/OSNetworkSystemLinux.c:
The Linux version seems to contain exactly the same problem as
you
fix
in
modules/luni/src/main/native/luni/windows/OSNetworkSystemWin32.c
modules/luni/src/main/native/luni/shared/luniglob.c
cleanup:
if (props) {
properties_free(PORTLIB, props);
}
if (bootDirectory) {
hymem_free_memory(bootDirectory);
}
The first if always fails if we come here using goto - we
can
put
the
label after the first if. I suggest replacing the second if
with
assert(!bootDirectory)
modules/archive/src/main/native/archive/shared/jarfile.c:
zip_freeZipEntry is not called on some paths - is it a memory
leak?
modules/luni/src/main/native/launcher/shared/main.c
if (vm_args.options)
{
hymem_free_memory (vm_args.options);
}
Should we put here assert(!vm_args.options)?
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
--
Best regards,
Andrew Zhang
--
--
Ilya Okomin
Intel Middleware Products Division
--
Best regards,
Andrew Zhang
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
--
Ilya Okomin
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] Incubator graduation update
A *real* unix hacker
Two years of release engineering is more than enough:
find . -name .svn -exec grep -H name {}/entries \; | sed -e
's/\.svn\/entries: name=//; s/$//' | egrep -i
'\.(gif|jar|png|dat|class|tif|jpg|jpeg|ico|dll|so|exe|doc|wav|pdf|zip)$'
:-)
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Friday, October 20, 2006 8:52 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [general] Incubator graduation update
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.
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.)
Otay.
geir
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]
-
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]
Thoughtless fixes considered harmful Was: [OT] Automated fixes considered harmful
Alex, This is a great letter! I cannot compete. I agree with the main point that no change should be done until the proper understanding of consequences is achieved. Nevertheless, from my perspective automatic tools are pretty good for locating problematic places, and each place usually worth deletion or simplification. I agree that if a part of the code is kept for purpose, automatic tools can destroy it. From the other side, if we check your example, the following commenting solves the problem. // int i; // i=someMethod() TODO Fix the bug in someMethod() I have even a stronger suggestion - we should remove the commented code leaving only a message for human beings. I was convinced once that it is always better to remove all dead and commented code. There are many guys who will spend time traversing dead code, while usually only one guy benefits from keeping it. His tangible benefit is measured in saved efforts from retrieving a previous revision from a version control system. I suggest that we better save the time for many readers instead of the time of one lazy writer. I'm ok with leaving a human readable message in a place of a bug or exceptional behavior. For example, in our case I would write: // TODO someMethod() behaves weirdly in case of OutOfMyResourceError. // Fix the behavior. The example about conditional statements is even better. I remember that reordering if statements sometimes decreased my code size to quarter. Here goes the rule number two. If an automatic tool corrupted a part of my code, I would either reconfigure the tool, or stop using it for this part of the code. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Alex Blewitt [mailto:[EMAIL PROTECTED] Sent: Saturday, October 21, 2006 1:59 AM To: harmony-dev@incubator.apache.org Subject: [OT] Automated fixes considered harmful There have been a few messages recently regarding build warnings that complain about e.g. local variables not being used or missing annotations, and work going on to 'fix' them. However, in most cases, the only thing that is being 'fixed' is that the compiler warnings no longer appear. Realistically, it's not a problem in the code; in fact, the code works fine with those warnings in place. Arguably, therefore, the code is being fixed to suit the compiler, rather than the compiler being configured to be more useful (i.e. less verbose). Of particular beef are the kind of automated clean-ups that IDEs such as Eclipse will offer. These are mostly incredibly dangerous, and offer no significant benefit to Harmony as a whole. Some of them are benign (for example, updating the list of imports) and some of them aren't (deleting private methods, unused variables etc.). The problem is that unless you've got a good idea of the code at any one point, performing automatic transformation of the codebase is not a sensible plan. Whilst the fact of the matter is true that it doesn't affect code execution (because private methods *aren't* being called, or a local variable *isn't* being read), it doesn't make sense to do it necessarily. For example, one could argue that removing all the JavaDoc from the source files has no effect on the code, and has the added advantage that the size of the source code is smaller -- but that doesn't make it a sensible thing to do. In particular, there's a lot of areas in the code that are pretty dynamic, and are still evolving. For example, I could be writing something like: int i; i=someMethod(); and then want to commit it to the repository. Let's say I discover a bug in someMethod(), so I instead do: int i; //i=someMethod() //TODO Fix the bug in someMethod() Now, automated tools will complain that i is being unreferenced (possibly even uninitalised too :-) and volunteer to take it out. The problem is then, after I've committed and worked on my code, I have: int i; i=someMethod() // Fixed bug and someone else has committed Auto-Delete, so that when I update it becomes: i=someMethod() // Compiler error, i doesn't exist The problem is that the person who ran Auto-Delete only saw a snapshot of the source code. Yes, *at that point in time* the variable wasn't being defined, but by removing it, you've effectively removed it from versions in the future, too. It's even worse with a private method, because then you've lost a lot more than a simple variable declaration. The same thing is true of the Auto-Generics that some people have become fond of. Really, get over it: generics don't save anything that you wouldn't have in code anyway (they're pretty much all compile-time restrictions anyway; there's still no type safety at run-time like there is in C#). Worse, Generics can only be used with Java 5 onwards, so by introducing generics into a library you're preventing that same library being used on anything older than Java 5. Granted, most of Harmony is working towards the Java 5 goal, but I'm sure there will be reusable parts of
RE: [vote] Graduate Apache Harmony podling from the Incubator
+1 As far as I understand the main goal of incubation is creation of healthy community. It means that all these non-binding +1 votes do bind us to this project. :-) With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Wessendorf Sent: Saturday, October 21, 2006 1:47 AM To: harmony-dev@incubator.apache.org Subject: Re: [vote] Graduate Apache Harmony podling from the Incubator Since I am not a committer or ppmc of this podling, my vote is non-binding. +1 hope to get the Trinidad Podling build done by Harmony soon! ;) -Matthias On 10/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote: +1 from me! On 10/21/06, Alex Blewitt [EMAIL PROTECTED] wrote: On 20/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: [ ] +1 Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status +1 from me too. Alex. - 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 -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Thoughtless fixes considered harmful Was: [OT] Automated fixes considered harmful
Alex, I see and accept your point. I believe that partial commits are a must - we should be a community. My point is simple - the code under active development shouldn't be a subject of beautification - it just should be safe for other Harmony modules. The first goal is to make it work. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Alex Blewitt [mailto:[EMAIL PROTECTED] Sent: Saturday, October 21, 2006 3:06 AM To: harmony-dev@incubator.apache.org Subject: Re: Thoughtless fixes considered harmful Was: [OT] Automated fixes considered harmful On 20/10/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: I agree that if a part of the code is kept for purpose, automatic tools can destroy it. From the other side, if we check your example, the following commenting solves the problem. // int i; // i=someMethod() TODO Fix the bug in someMethod() This was a contrived example; the point is, I might be submitting a checkpoint for the work that I'm doing, and have put the var in there for a good purpose. For example, it might be a field of a class that has been put together by design/necessity, even if it's not being used as of the checkpoint that you're looking at. As an obvious case, there are some fields that are defined in the pack200 class that aren't used yet, mostly because I haven't got around to the parts in which those aspects are being parsed out. However, I put them in there as part of the analysis of what was needed, and I know that they will be used in the near future. There's no point having them commented out; in fact, whilst coding, I want to be able to use them via code assist. I shouldn't have to sanity check and defend against what others might do to the code. There's also a similar danger that someone would remove those comments :-) I have even a stronger suggestion - we should remove the commented code leaving only a message for human beings. Indeed, that's the big problem. I'm working on that set of code -- it shouldn't be deleted. It's a work-in-progress. Deleting it and leaving a message Your Code Was Here is counterproductive. I suggest that we better save the time for many readers instead of the time of one lazy writer. I'm ok with leaving a human readable message in a place of a bug or exceptional behavior. For example, in our case I would write: // TODO someMethod() behaves weirdly in case of OutOfMyResourceError. // Fix the behavior. So, you'd prefer it if I didn't submit code which wasn't 100% complete? I'm fine with that ... but it'll be a long time before I complete the spec -- and if someone in the meantime removes some of the fields that I haven't yet parsed, it will still break when I update (or any of my further changes are committed). A warning does *not* indicate laziness. Nor does wanting to submit smaller regular patches of incomplete work for others to look at or improve. However, improvement doesn't include deleting code that people are still working on. Alex.
RE: [classlib][test] Configuration dependent test of InetAddress.getHostName
Hello, All,
Paulex wrote,
the test needs to be rewritten or excluded
+1, and the option to exclude the test is pretty understandable.
I wonder about the first option. Is there any way to check that symbolic
name corresponds to the local computer? I can imagine the following
condition to check this.
InetAddress.getByName(InetAddress.getByName(127.0.0.1).getHostName()).
isLoopbackAddress()
Thoughts?
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Alexei Zakharov [mailto:[EMAIL PROTECTED]
Sent: Monday, October 23, 2006 6:47 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][test] Configuration dependent test of
InetAddress.getHostName
I think Harmony does the right thing as spec requires, the difference
is
caused by underlying system call, so it should be acceptable, i.e.,
the
test needs to be rewritten or excluded.
+1 from me
Thanks,
2006/10/20, Paulex Yang [EMAIL PROTECTED]:
Denis Kishenko wrote:
I have researched issue H-1664 and found one more difference with
RI.
I run simple test on Windows Server 2003 SP1
=== Test =
import java.net.InetAddress;
import java.net.UnknownHostException;
public class Test {
public static void main(String[] args) throws
UnknownHostException {
System.out.println(by name (127.0.0.1) - +
InetAddress.getByName(127.0.0.1).getHostName());
System.out.println(by name (localhost) - +
InetAddress.getByName(localhost).getHostName());
System.out.println(by address - +
InetAddress.getByAddress(new byte[]{127, 0, 0, 1}).getHostName());
System.out.println(localhost - +
InetAddress.getLocalHost());
}
}
Windows Server 2003 SP1
=== RI ==
by name (127.0.0.1) - 127.0.0.1
by name (localhost) - localhost
by address - 127.0.0.1
localhost - nstdrlew21/10.125.122.60
= Harmony ==
by name (127.0.0.1) - nstdrlew21.ins.intel.com
by name (localhost) - localhost
by address - nstdrlew21.ins.intel.com
localhost - nstdrlew21/10.125.122.60
WinXP
= Both ===
by name (127.0.0.1) - localhost
by name (localhost) - localhost
by address - localhost
localhost - pbwdmkishen/10.125.132.226
Actually Harmony use native call of getnameinfo() to get host name
(which is reasonable IMHO). MSDN says The getnameinfo function
provides name resolution from an address to the host name.
InetAddressTest.test_getHostName (see H-1664) failed on WinServer
because InetAddress.getByName(127.0.0.1).getHostName() returned
nstdrlew21.ins.intel.com while localhost expected. So this test
looks like configuration dependent.
I see three possible options
1. Stay test as is. Just keep in mind that on specific
configurations
this one fails.
2. Rewrite test to be configuration dependent. Test has to do the
same
native call.
3. Exclude localhost checking from test_getHostName.
I think Harmony does the right thing as spec requires, the difference
is
caused by underlying system call, so it should be acceptable, i.e.,
the
test needs to be rewritten or excluded. But this issue worth a
non-bug
difference together with getHostName()'s different behavior when
SecurityManager presents[1](thanks Alexei Fedotov helped to find this
link and commented to HARMONY-1664:))
Harmony-73 is another issue, which is actually caused by HARMONY-84
and
irrelevant with getHostName() method.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-
dev/200602.mbox/[EMAIL PROTECTED]
What do you think about this situation?
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
RE: [general] Announcing newest members of the Harmony PPMC
Guys, You were doing a great job. Congratulations! With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 2:42 AM To: harmony-dev@incubator.apache.org Subject: [general] Announcing newest members of the Harmony PPMC 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][test] Configuration dependent test of InetAddress.getHostName
Denis wrote, It's possible but it will be another test Agreed +1 exclude this test (not whole test but localhost check) +1 With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Denis Kishenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 24, 2006 3:31 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][test] Configuration dependent test of InetAddress.getHostName 2006/10/24, Fedotov, Alexei A [EMAIL PROTECTED]: I wonder about the first option. Is there any way to check that symbolic name corresponds to the local computer? I can imagine the following condition to check this. InetAddress.getByName(InetAddress.getByName(127.0.0.1).getHostName()). isLoopbackAddress() This test failed because isLoopbackAddress() expected 127.X.X.X 2006/10/24, Fedotov, Alexei A [EMAIL PROTECTED]: Andrew, I agree that test should be fixed. I suggested using one of the following checks to validate that the host is localhost. InetAddress.getByName(host).isLoopbackAddress() InetAddress.getByName(host).isSiteLocalAddress() It's possible but it will be another test IMHO +1 exclude this test (not whole test but localhost check)
RE: [general] Board resolution for Apache Harmony project
Sounds great! Tools or tests fit into category of related software, so we probably don't need to mention them explicitly. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 3:35 AM To: harmony-dev@incubator.apache.org Subject: [general] Board resolution for Apache Harmony project I've been anticipating this moment for 2 years now... :) While it doesn't seem possible given infrastructure issues that are interfering with mail to get something in front of the board tomorrow (plus the fact that the board likes things in advance) if a miracle happens I'd like to try, and if not, we need this anyway for next month, so we should get this put to bed (and back to work). Here's a proposed resolution to put before the board to create Apache Harmony as a Top Level Project (TLP) of the ASF. As per a discussion on the -private list, it's been suggested that I be offered as the candidate to the board as the PMC chair, so I filled in that blank, but that's open for discussion like everything else in this proposal. (The board chooses a chair - we just make the suggestion). There's no real rush to get this in tomorrow - as I said, it's really unlikely anyway - so please speak up with comments or concerns. - 0 - Establish the Apache Harmony project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software implementing Java virtual machines, related class libraries, and other software that is commonly associated with Java platforms, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Harmony PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Harmony PMC be and hereby is responsible for the creation and maintenance of software related to Java virtual machines, related class libraries, and other software commonly associated with Java platform implementations; and be it further RESOLVED, that the office of Vice President, Harmony be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Harmony PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Harmony PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Harmony PMC: * Nathan Beyer ([EMAIL PROTECTED]) * Tim Ellison([EMAIL PROTECTED]) * Mark Hindess ([EMAIL PROTECTED]) * George Harley ([EMAIL PROTECTED]) * Mikhail Loenko ([EMAIL PROTECTED]) * Geir Magnusson Jr. ([EMAIL PROTECTED]) * Stepan Mishura ([EMAIL PROTECTED]) * Weldon Washburn([EMAIL PROTECTED]) * Paulex Yang([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Geir Magnusson Jr be appointed to the office of Vice President, Harmony, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Harmony PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Harmony Project; and be it further RESOLVED, that the initial Harmony PMC be and hereby is tasked with the migration and rationalization of the Apache Incubator Harmony podling; and be it further RESOLVED, that all responsibility pertaining to the Apache Incubator Harmony podling encumbered upon the Apache Incubator PMC are hereafter discharged. - 0 - Comments please? geir
[drlvm][crash] Cannot run anything on Linux
Guys, Last two days I cannot run the simplest things on DRLVM on Linux: drlvm/build/lnx_ia32_gcc_debug/deploy/jre/bin/java -cp . NoSuchClass free(): invalid pointer 0x808d800 [launcher crash dump follows] Is it my local problem? Or someone have faced this as well? With best regards, Alexei Fedotov, Intel Java XML Engineering
RE: [classlib][luni] signalis interruptus in hysock
Guys,
Could you please help me to understand the following?
1. Is HARMONY-1904 actually a duplicate of my HARMONY-1879?
2. Ivan, do I remember correctly that you've already fixed that bug once
when debugging Eclipse long run failures? Where is that patch?
Thank you in advance.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Weldon Washburn [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 5:36 PM
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Subject: Re: [classlib][luni] signalis interruptus in hysock
On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still
open
perhaps it makes sense to put a counter in the while (...) {
select...}
loop. And after every N loops, print a warning/diagnostic message.
For whom and to what end? Why not just return EINTR (in hysock
speak)?
The
value for N would have to be tuned. I don't know what the best
number
would
be. Given that 1904 patch is not the final solution, at least a
diagnostic
that hints at where the system hangs would be useful. It might
make
sense
to even print a stack trace. Also, I agree with Ivan below.
Signals
bugs
are very hard to debug. And diagnostics can help us all understand
the
corner cases better.
But so far, no one has shown that the system hangs, or can hang,
simply
because we return EINTR
Sorry for not being clear. I was reacting to the patch in 1904 itself.
Not
the bigger issue of fixing the upper layers to comprehend EINTR. My
understanding is that this patch does not fix the problem. This patch
does
not return EINTR. If for whatever reason this patch is committed, I
recommend adding the above diagnostic code so that we don't dig
ourselves
an
even deeper hole.
If it is decided 1904 should not be committed, it might make sense to
close it with won't fix.
geir
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution is what Geir suggests. One
think
which
bothers me is following. EINTR can happen in different places
and
the
situations can be quite rare in some circumstances. It can
lead to
hard to reproduce stability bugs (race conditions).
Can you give an example?
Half a year ago, I was working on the problem. Socket operations
get
sometimes interrupted. We have found out that it occurs sometime
after
GC. It was not quite easy as the application was quite big and
situation - quite rare.
Given the fact, that current implementation of monitor reservation
code can stop other thread in quite random fashion we should have
rock
solid support of EINTR handling everywhere the select(), poll()
calls
is used.
--
Ivan
Intel Enterprise Solutions Software Division
We should find a
way how to test the implementation.
+1!
:)
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Weldon Washburn
Intel Middleware Products Division
RE: [classlib][luni] signalis interruptus in hysock
Geir,
Do I understand correctly that you suggest the following?
1. hysock_select as its name says should mimic a behavior of select, i.
e. return the error code from select without changing it. It's ok to
print a rare debug message.
2. The correct place for the loop is the module where hysock_select is
called, or, let me be precise, class lib guys are to fix our networking
code.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 10:01 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] signalis interruptus in hysock
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still open
perhaps it makes sense to put a counter in the while (...) {
select...}
loop. And after every N loops, print a warning/diagnostic message.
For whom and to what end? Why not just return EINTR (in hysock speak)?
The
value for N would have to be tuned. I don't know what the best
number
would
be. Given that 1904 patch is not the final solution, at least a
diagnostic
that hints at where the system hangs would be useful. It might make
sense
to even print a stack trace. Also, I agree with Ivan below.
Signals
bugs
are very hard to debug. And diagnostics can help us all understand
the
corner cases better.
But so far, no one has shown that the system hangs, or can hang, simply
because we return EINTR
geir
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution is what Geir suggests. One think
which
bothers me is following. EINTR can happen in different places
and
the
situations can be quite rare in some circumstances. It can lead
to
hard to reproduce stability bugs (race conditions).
Can you give an example?
Half a year ago, I was working on the problem. Socket operations get
sometimes interrupted. We have found out that it occurs sometime
after
GC. It was not quite easy as the application was quite big and
situation - quite rare.
Given the fact, that current implementation of monitor reservation
code can stop other thread in quite random fashion we should have
rock
solid support of EINTR handling everywhere the select(), poll()
calls
is used.
--
Ivan
Intel Enterprise Solutions Software Division
We should find a
way how to test the implementation.
+1!
:)
geir
-
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] yoko.jar is missed
All, I've got the following problem. September Yoko builds are vanished from http://people.apache.org/maven-snapshot-repository/org/apache/yoko/ Only the build from 2006.08.10 remains. Any ideas where have the newer build gone? With best regards, Alexei Fedotov, Intel Java XML Engineering
RE: [classlib][build] yoko.jar is missed
Sorry, Tim already answered this: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200610.mb ox/[EMAIL PROTECTED] -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Friday, October 27, 2006 3:26 PM To: harmony-dev@incubator.apache.org Subject: [classlib][build] yoko.jar is missed All, I've got the following problem. September Yoko builds are vanished from http://people.apache.org/maven-snapshot-repository/org/apache/yoko/ Only the build from 2006.08.10 remains. Any ideas where have the newer build gone? With best regards, Alexei Fedotov, Intel Java XML Engineering
RE: JIRA/Tomcat problem Was: [classlib][util.prefs] Implementation should be compatible with RI
Great! Jeff, thanks! With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Jeff Turner [mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006 6:14 AM To: Fedotov, Alexei A Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; harmony- [EMAIL PROTECTED] Subject: Re: JIRA/Tomcat problem Was: [classlib][util.prefs] Implementation should be compatible with RI On Thu, Oct 12, 2006 at 01:29:12PM +0400, Fedotov, Alexei A wrote: Dear admins, We are experiencing the following problem while attaching patches to HARMONY-1751. Errors Exception trying to establish attachment directory. Check that the application server and JIRA have permissions to write to it: com.atlassian.jira.web.util.AttachmentException: Cannot write to attachment directory. Check that the application server and JIRA have permissions to write to: /usr/local/tomcat/tomcat-jira/attachments/HARMONY/HARMONY-1751 This should now be fixed. The directory and files (and many others) were owned by root (people occasionally start JIRA as root which breaks things). There's also now a cronjob to detect this in future. Cheers, Jeff Could you please help? With best regards, Alexei Fedotov, Intel Middleware Products Division
RE: [drlvm][crash] Cannot run anything on Linux
Geir, I'm not very happy to report that after some class library patch around 23 of October DRLVM no longer works on SUSE Linux 9.0. This happened before you committed that big set of DRLVM patches. All works fine on Ubuntu. I tried two SUSE computers and built from scratch. All, Are there any success stories about recent SUSE builds? With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Friday, October 27, 2006 4:42 PM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm][crash] Cannot run anything on Linux did you figure this out? I don't have a problem... Fedotov, Alexei A wrote: Guys, Last two days I cannot run the simplest things on DRLVM on Linux: drlvm/build/lnx_ia32_gcc_debug/deploy/jre/bin/java -cp . NoSuchClass free(): invalid pointer 0x808d800 [launcher crash dump follows] Is it my local problem? Or someone have faced this as well? With best regards, Alexei Fedotov, Intel Java XML Engineering
RE: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)
Premature optimization is the root of all evil Donald Knuth Just a small idea: Let teach JIT to purge this code unless special option is ON +1 I believe a computer should adapt to my way of thinking. I prefer a simple and readable code to an efficient one since the former one saves the time of my life, why the latter one saves some electricity. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Mikhail Fursov [mailto:[EMAIL PROTECTED] Sent: Sunday, October 29, 2006 8:56 PM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method) On 10/29/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: 1) The Logging Debate That Won't Die - we don't want to encumber our production code with logging or even with runtime enablement checks for logging i.e. if (logging.isDebugEnabled()) but it's clear that some people still want to use it for debugging. Just a small idea: Let teach JIT to purge this code unless special option is ON ? Doing this we solve performance issue at least . If we did this, I assume that our build becomes a two step process, first pre-process the code to create separate buildable source, which would go into source jars and such for debugging purposes. Then our current javac/jar process. I'd also like to be able to work in an IDE with the pre-proc stuff invisible if possible... This is the main problem. Backporting of your changes from the buildable source to the source with preprocessor could have more overhead then support of a separate branch for different Java version. -- Mikhail Fursov
RE: [classlib][luni] signalis interruptus in hysock
Geir, All,
I have examined class library code. It seems that the solution we
invented (return EINTR, then loop) was always in place. :-)
Few comments on understanding:
1. EINTR (=4) is renamed to HYPORT_ERROR_SOCKET_INTERRUPTED (=-9).
2. The loop is coded by means of goto select.
3. The same pattern is dupdupduplicated several times.
I have not examined all places, though there could be paths which do not
fit the pattern. Honestly, I have examined the only path:
pollSelectRead() -
hysock_select_read() -
hysock_select()
Summary:
We can keep this issue open or close it as won't fix. Meanwhile we
should look for the real problem.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 26, 2006 6:21 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] signalis interruptus in hysock
Fedotov, Alexei A wrote:
Geir,
Do I understand correctly that you suggest the following?
1. hysock_select as its name says should mimic a behavior of select,
i.
e. return the error code from select without changing it. It's ok to
print a rare debug message.
Yes, that's what I had the other do (and no, I see no reason to print a
debug message, as upper layers can print if they find an EINTR)
2. The correct place for the loop is the module where hysock_select
is
called, or, let me be precise, class lib guys are to fix our
networking
code.
My plan is to fix it as fixed the other one. It turns out that there
are several layers between java and the OS...
geir
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 10:01 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] signalis interruptus in hysock
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still
open
perhaps it makes sense to put a counter in the while (...) {
select...}
loop. And after every N loops, print a warning/diagnostic message.
For whom and to what end? Why not just return EINTR (in hysock
speak)?
The
value for N would have to be tuned. I don't know what the best
number
would
be. Given that 1904 patch is not the final solution, at least a
diagnostic
that hints at where the system hangs would be useful. It might
make
sense
to even print a stack trace. Also, I agree with Ivan below.
Signals
bugs
are very hard to debug. And diagnostics can help us all understand
the
corner cases better.
But so far, no one has shown that the system hangs, or can hang,
simply
because we return EINTR
geir
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution is what Geir suggests. One think
which
bothers me is following. EINTR can happen in different places
and
the
situations can be quite rare in some circumstances. It can lead
to
hard to reproduce stability bugs (race conditions).
Can you give an example?
Half a year ago, I was working on the problem. Socket operations
get
sometimes interrupted. We have found out that it occurs sometime
after
GC. It was not quite easy as the application was quite big and
situation - quite rare.
Given the fact, that current implementation of monitor reservation
code can stop other thread in quite random fashion we should have
rock
solid support of EINTR handling everywhere the select(), poll()
calls
is used.
--
Ivan
Intel Enterprise Solutions Software Division
We should find a
way how to test the implementation.
+1!
:)
geir
-
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] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)
Geir wrote, Not only that, we create a class library that places **weird** requirements on any VM that wants to use it. Ok, I believe this was honest. :-) As far as I know the optimization Mikhail is talking about is nearly standard for any optimizing JIT. Isn't it just a simple inlining? I accept that inlining in Java is a bit more complex, than in C, since you can load classes and redefine methods on fly. Anyway optimizing JIT recompiles the whole thing when such event happens and an appropriate callback is called. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, October 30, 2006 9:29 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method) Alexei Zakharov wrote: Hi all, Well, as an individual who has the tendency to pure Java programming I will be happier if I can control things on the source-code level. I can't say I don't like the idea about sophisticated JIT with the powerful AI inside, but if we are talking about logging then IMHO a good preprocessor is the thing that we need (but we may also continue to JIT away stuff if we like). Not only that, we create a class library that places weird requirements on any VM that wants to use it. No thanks. At the same time I don't feel completely comfortable with the idea of using preprocessor to separate J2SE sources from J2ME. I'm not overjoyed either, but I can't think of many ways that allow fairly clear readability without don't require tons of IDE-specific tooling. This is what bothers me about aspects - can you get a real clue what's going to happen looking at the source code? geir No clue about particular technology. It can be SableCC, something custom-made, velocity or whatever. Thanks, 2006/10/30, Fedotov, Alexei A [EMAIL PROTECTED]: Premature optimization is the root of all evil Donald Knuth Just a small idea: Let teach JIT to purge this code unless special option is ON +1 I believe a computer should adapt to my way of thinking. I prefer a simple and readable code to an efficient one since the former one saves the time of my life, why the latter one saves some electricity. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Mikhail Fursov [mailto:[EMAIL PROTECTED] Sent: Sunday, October 29, 2006 8:56 PM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method) On 10/29/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: 1) The Logging Debate That Won't Die - we don't want to encumber our production code with logging or even with runtime enablement checks for logging i.e. if (logging.isDebugEnabled()) but it's clear that some people still want to use it for debugging. Just a small idea: Let teach JIT to purge this code unless special option is ON ? Doing this we solve performance issue at least . If we did this, I assume that our build becomes a two step process, first pre-process the code to create separate buildable source, which would go into source jars and such for debugging purposes. Then our current javac/jar process. I'd also like to be able to work in an IDE with the pre-proc stuff invisible if possible... This is the main problem. Backporting of your changes from the buildable source to the source with preprocessor could have more overhead then support of a separate branch for different Java version.
RE: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)
Alexey wrote, At the same time I don't feel completely comfortable with the idea of using preprocessor to separate J2SE sources from J2ME. A preprocessor looks a possible choice for maintaining several profiles (eg Java ME vs Java SE). We need compact and preferably precompiled sources to be efficient on small devices. There is one more option. Can we use a good source control system instead? Java ME workspace could be a child of Java SE one. I believe something like BitKeeper or Teemware can keep things different when needed and propagate bug fixes and patches painlessly for the common part. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Monday, October 30, 2006 8:05 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method) Hi all, Well, as an individual who has the tendency to pure Java programming I will be happier if I can control things on the source-code level. I can't say I don't like the idea about sophisticated JIT with the powerful AI inside, but if we are talking about logging then IMHO a good preprocessor is the thing that we need (but we may also continue to JIT away stuff if we like). At the same time I don't feel completely comfortable with the idea of using preprocessor to separate J2SE sources from J2ME. No clue about particular technology. It can be SableCC, something custom-made, velocity or whatever. Thanks, 2006/10/30, Fedotov, Alexei A [EMAIL PROTECTED]: Premature optimization is the root of all evil Donald Knuth Just a small idea: Let teach JIT to purge this code unless special option is ON +1 I believe a computer should adapt to my way of thinking. I prefer a simple and readable code to an efficient one since the former one saves the time of my life, why the latter one saves some electricity. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Mikhail Fursov [mailto:[EMAIL PROTECTED] Sent: Sunday, October 29, 2006 8:56 PM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method) On 10/29/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: 1) The Logging Debate That Won't Die - we don't want to encumber our production code with logging or even with runtime enablement checks for logging i.e. if (logging.isDebugEnabled()) but it's clear that some people still want to use it for debugging. Just a small idea: Let teach JIT to purge this code unless special option is ON ? Doing this we solve performance issue at least . If we did this, I assume that our build becomes a two step process, first pre-process the code to create separate buildable source, which would go into source jars and such for debugging purposes. Then our current javac/jar process. I'd also like to be able to work in an IDE with the pre-proc stuff invisible if possible... This is the main problem. Backporting of your changes from the buildable source to the source with preprocessor could have more overhead then support of a separate branch for different Java version. -- Alexei Zakharov, Intel Enterprise Solutions Software Division
RE: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
Gregory wrote, I need is probably smoke tests category. I need to add building native code part and add a custom command line setting somewhere. +1 I believe you need one or two test with a good coverage to check your changes regularly. This is enough for acceptance testing. This doesn't inhibit the separate category - it would be quite useful for thorough testing. But from my perspective this is not the first thing to do. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Gregory Shimansky [mailto:[EMAIL PROTECTED] Sent: Monday, October 30, 2006 11:25 PM To: harmony-dev@incubator.apache.org Subject: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks Hello JVMTI implementation is quite a big piece of drlvm code which doesn't have any tests that are ran regularly. This may create regressions in JVMTI implementation which won't be caught early. So I want to add several small tests for JVMTI which would cover most of the currently implemented functionality. The specific of such tests is that they have to have a custom command line, to specify -agentlib:agent name library. They also require to build native code. They need to be run in default (JIT) mode and on interpreter. Current tests which we have for commit checks for drlvm don't have these features out of the box. Cunit tests build native code, but don't run java executable. Smoke and kernel tests don't have native code and don't have a custom command line. So I should either create a new 4th category for tests with custom build file, or extend one of the current categories which we have. The most close to what I need is probably smoke tests category. I need to add building native code part and add a custom command line setting somewhere. Or do you think I should go with completely new tests category? -- Gregory Shimansky, Intel Middleware Products Division
RE: [classlib] Preprocessor
Geir, We use SVN. How do you propose to do it cleanly in SVN? I believe it is possible to maintain branches cleanly in SVN. Let me claim that the only significant difference between SVN and advanced source control systems is a set of scripts which help merging and moving files around. Why do I call it a set of scripts? For example, the file movement history in S*n TeamWare is kept in specially formatted commit comments. Three way merge was a separate program, which was invoked instead of vi for merge. I liked that product because they really thought about user experience when were creating it, and not because of a questionable implementation of that product. If we miss a specific desired user experience working with SVN, we better start looking for a system on the top of SVN which has this feature implemented, or tune our environment with a minor script. This would cost us less than creating a completely new stack for a preprocessor. Let me also add that people are always the key. I completely stopped using all IDE decorators for ST and switched to the command line interface after two years of putbacks and bringovers. From the other side it wasn't hard at all for a newbie to break that system. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 1:50 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] Preprocessor Fedotov, Alexei A wrote: Geir, I tried this preprocessor staff for Java in my previous life. From my experience the maintenance effort is higher for this solution than for Source Control. We use SVN. How do you propose to do it cleanly in SVN? 1. I faced first time how slow regular expressions on Java could be. 2. Perl worked fine but no one around me could understand my pre-processing scripts and maintain them. 3. The girl from Ireland beat my clever scripts with Sun's TeamWare and text editor. +1 for Source Control With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 12:28 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] Preprocessor Tim Ellison wrote: Mikhail Fursov wrote: What are the reasons to exclude the most standard solution here: branching. Do you think we need a lot of them? I don't think we are excluding any option for maintaining similar code streams (5.0 6.0, SE ME, etc.) it's just a discussion at the moment. Similarly, I'm not advocating the use of aspects for maintaining different code streams; but rather I was saying that IDE support is likely going to be a requirement for any technology (apt, preprocessor, post-processing, aspects, ...) that we choose to solve the problem. I'm sure we wouldn't even want simple branching without a decent merge tool to keep things in sync. Yes - that's what I'm scared of. A branch solution sounds like it leads to much misery and woe, because i think all the factors that make this such an interesting problem for which a pre-processor is a valid solution this implies the requirement of some kind of conditional merge I agree with Geir that we should endeavour to choose a technology that has broad tooling support. Regards, Tim
RE: 235 tests are missed at DRLVM test run for Windows
Anton, This is wonderful! This is brilliant! I LOVE IT. Few ideas: 1. To get the picture offline I added perPage attribute wget http://harmonytest.org/ diff.do?method=viewid=72id2=80perPage=10 2. This can be used to compare our results against RI when the quality of the test base is unknown. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Anton Luht [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 4:37 PM To: harmony-dev@incubator.apache.org Subject: Re: 235 tests are missed at DRLVM test run for Windows Hello, Alexei, Vladimir and others: Please enjoy the new runs comparing functionality: http://harmonytest.org/diff.do?method=viewid=72id2=80 :) The support for tags that was discussed few weeks ago has been implemented. Now every run has a set of tags associated with it. Registered users can edit list of tags. When you view a run result, you can search for run to compare this run with using tags . For example, when you view run with tags drl, msvc, windows, xp it is possible to search for run with tags ibm, msvc, windows, xp and see the difference between two VMs. Please excuse the mess in the order of the results - I've noticed the effect only after deploy :) It is possible to specify the list of tags when uploading new results. I've tagged ~20-30 runs to experiment with. I've also implemented a request to save user name between results upload. Please report bugs and send feature requests. -- Regards, Anton Luht, Intel Java XML Engineering
RE: [doc] No Doxygen reference for code :(
Nadya, All, Suggestion to generate Doxygen from DRLVM code sounds very interesting. I posted a quick solution for Linux to http://issues.apache.org/jira/browse/HARMONY-2024 If you want to have this integrated into build.xml, it would be great to define a correct scope. Could you please give more details what do you expect from the documentation build file? A volunteer can try doing some things important for you first, and then add new features gradually. * Should doxygen build documentation for inter-component interfaces? * What are components? I assume vm, jit, gc are out of the question. Is am execution manager or an interpreter a separate component? * Should doxygen build documentation for each component like vm, jit, interpreter, gc? * Should we put documentation into doc/component_doc dirs as class library code does? * Should we use the same formatting as a class library documentation? * We don't need to process .cpp files in DRLVM source tree, do we? * Would each of these choices (inter-component documentation, component interface documentation) be a separate configuration? If yes, should we put each result into the separate directory? * Should doxygen process .java files in DRLVM source tree? * Should the doxygen documentation be integrated with class library documentation? * Do you expect to have inheritance diagrams? Do we need to download Graphviz, or should we expect it preinstalled? * A related question is how many platforms should we support. For example, should I add downloading and compilation of Graphviz for my SuSE Linux? * Should we have different documentation for Windows and Linux? * If something is optional for now, what should be added in future? * Is there any choice for user to affect resulting documentation? With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 4:34 PM To: harmony-dev@incubator.apache.org Subject: [doc] No Doxygen reference for code :( Hi everyone, I've noticed that there's no API reference documentation for Harmony code - generated by Doxygen/Javadoc. I guess many will agree that having API reference is very useful and convenient. This issue was discussed a while ago [1] for kernel classes and vmi interface in classlib. We agreed to store the Doxygen docs on the website by generating them manually from code and placing there. It seems that the old version of the docs was removed from SVN but never made its way to the website, so it's just NOWHERE now :-(. Let's fix it! AFAIU, we want to have the following: 1. Ability to generate docs locally from source code as part of build - need to change existing build files or write new ones. 2. Ability to see docs on the website - manually copy a local bundle of docs to the website and add a link. Geir has been planning to include the website into the next snapshot; supplying ready reference with it seem nice. Volunteers? I can work on item 2 for sure to get a nice config file and patch the website to link to our new Doxygen API. Item 1 -fixing the build - might be more extravagant, so your aid's welcome ;) [1] mail thread http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.m b ox/[EMAIL PROTECTED] Thanks, Nadya Morozova
RE: [general] Re: svn commit: r469512 - in /incubator/harmony/standard/site: docs/contributors.html xdocs/contributors.xml
Alexey, My congratulations! :-) BTW, could you please look once again at http://issues.apache.org/jira/browse/HARMONY-100 text/BidiWrapper issue, now from committer's point of view? With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 9:49 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] Re: svn commit: r469512 - in /incubator/harmony/standard/site: docs/contributors.html xdocs/contributors.xml Yep. Hurray! It works... finally :) SY, Alexey 2006/10/31, Tim Ellison [EMAIL PROTECTED]: Hurray! [EMAIL PROTECTED] wrote: Author: apetrenko Date: Tue Oct 31 06:57:44 2006 New Revision: 469512 URL: http://svn.apache.org/viewvc?view=revrev=469512 Log: I've added myself to the list of committers. -- Tim Ellison ([EMAIL PROTECTED]) -- Alexey A. Petrenko Intel Middleware Products Division
RE: 235 tests are missed at DRLVM test run for Windows
Anton, 1. Thank you for your suggestion. It's nice to have data in CSV but certainly it's not a P1 issue for me. 2. If I suggested an enhancement, this would be an addition of a test name filter for comparison results. I mean that if I'm interested in Bidi tests comparison, I put Bidi into form field (name=Bidi) and see a comparison for the tests which names contain the specified substring. 3. When I use Open in a new window for a list of tags, IE opens a copy of the initial window. When I do a left click, there is no scroll bar at the pop up window, and the list of tags doesn't fit the window. 4. I vote for one of the following renamings: a) Rename ibm tag to j9 b) Rename drl tag to intel :-). With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Anton Luht [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 7:51 PM To: harmony-dev@incubator.apache.org Subject: Re: 235 tests are missed at DRLVM test run for Windows Hello, Alexei, Thanks for the kind words. Few ideas: 1. To get the picture offline I added perPage attribute wget http://harmonytest.org/ diff.do?method=viewid=72id2=80perPage=10 Maybe it's worth to add link 'download diff' that will allow to save data in TSV format? I prefer TSV not CSV because it doesn't require smart escaping. It's also possible to create tricky HTML files that can be imported in Excel - this may look better - headers in bold, multiple worksheets, etc. 2. This can be used to compare our results against RI when the quality of the test base is unknown. Yes - I've added option 'RI' for results uploading. Tag 'ri' can also be added so one will be able to compare run having 'windows, xp, sp2, msvc, drl' tags with 'windows, xp, sp2, ri', etc. I also think about about having tags for different test suites, for example, 'axis' for Axis tests (already uploaded by Tony), 'eut' for Eclipse Unit Tests, etc. This will allow to add new test suites to the site with little efforts and make suites co-existing in parallel so if someone is investigating failures of one suite, he doesn't see results of others. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Anton Luht [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 4:37 PM To: harmony-dev@incubator.apache.org Subject: Re: 235 tests are missed at DRLVM test run for Windows Hello, Alexei, Vladimir and others: Please enjoy the new runs comparing functionality: http://harmonytest.org/diff.do?method=viewid=72id2=80 :) The support for tags that was discussed few weeks ago has been implemented. Now every run has a set of tags associated with it. Registered users can edit list of tags. When you view a run result, you can search for run to compare this run with using tags . For example, when you view run with tags drl, msvc, windows, xp it is possible to search for run with tags ibm, msvc, windows, xp and see the difference between two VMs. Please excuse the mess in the order of the results - I've noticed the effect only after deploy :) It is possible to specify the list of tags when uploading new results. I've tagged ~20-30 runs to experiment with. I've also implemented a request to save user name between results upload. Please report bugs and send feature requests. -- Regards, Anton Luht, Intel Java XML Engineering -- Regards, Anton Luht, Intel Java XML Engineering
RE: [classlib][luni] signalis interruptus in hysock
Geir,
Tanks for your reply!
In code that calls the wrapper for the lowest-level select(), right?
Yes
pollSelectRead() // loop is here
hysock_select_read() // return code is propagated
hysock_select() // EINTR is renamed to
HYPORT_ERROR_SOCKET_INTERRUPTED
I don't understand this - what do you see as the real problem?
Interruption from select due to signals is a fact of life under linux.
This is a good question. 100% agree with your statement. I will try to
reproduce connection failures on Linux right after overcoming my SuSE
Linux problems with running DRLVM. If there are no connection failures,
than there is no problem.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 31, 2006 2:30 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] signalis interruptus in hysock
Fedotov, Alexei A wrote:
Geir, All,
I have examined class library code. It seems that the solution we
invented (return EINTR, then loop) was always in place. :-)
Few comments on understanding:
1. EINTR (=4) is renamed to HYPORT_ERROR_SOCKET_INTERRUPTED (=-9).
Yes, I did that in one place to have it fit into the portlib error code
set. Someone may have done it in another.
2. The loop is coded by means of goto select.
In code that calls the wrapper for the lowest-level select(), right?
3. The same pattern is dupdupduplicated several times.
That's another issue entirely :)
I have not examined all places, though there could be paths which do
not
fit the pattern. Honestly, I have examined the only path:
pollSelectRead() -
hysock_select_read() -
hysock_select()
Summary:
We can keep this issue open or close it as won't fix. Meanwhile we
should look for the real problem.
I don't understand this - what do you see as the real problem?
Interruption from select due to signals is a fact of life under linux.
geir
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 26, 2006 6:21 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] signalis interruptus in hysock
Fedotov, Alexei A wrote:
Geir,
Do I understand correctly that you suggest the following?
1. hysock_select as its name says should mimic a behavior of
select,
i.
e. return the error code from select without changing it. It's ok
to
print a rare debug message.
Yes, that's what I had the other do (and no, I see no reason to
print a
debug message, as upper layers can print if they find an EINTR)
2. The correct place for the loop is the module where hysock_select
is
called, or, let me be precise, class lib guys are to fix our
networking
code.
My plan is to fix it as fixed the other one. It turns out that
there
are several layers between java and the OS...
geir
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 10:01 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] signalis interruptus in hysock
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still
open
perhaps it makes sense to put a counter in the while (...) {
select...}
loop. And after every N loops, print a warning/diagnostic
message.
For whom and to what end? Why not just return EINTR (in hysock
speak)?
The
value for N would have to be tuned. I don't know what the best
number
would
be. Given that 1904 patch is not the final solution, at least a
diagnostic
that hints at where the system hangs would be useful. It might
make
sense
to even print a stack trace. Also, I agree with Ivan below.
Signals
bugs
are very hard to debug. And diagnostics can help us all
understand
the
corner cases better.
But so far, no one has shown that the system hangs, or can hang,
simply
because we return EINTR
geir
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution is what Geir suggests. One
think
which
bothers me is following. EINTR can happen in different places
and
the
situations can be quite rare in some circumstances. It can
lead
to
hard to reproduce stability bugs (race conditions).
Can you give an example?
Half a year ago, I was working on the problem. Socket operations
get
sometimes interrupted. We have found out that it occurs sometime
after
GC. It was not quite easy as the application was quite big and
situation - quite rare.
Given the fact, that current implementation of monitor
reservation
code can stop other thread in quite random fashion we should
have
rock
solid support of EINTR handling everywhere the select(), poll()
calls
is used.
--
Ivan
Intel Enterprise
RE: [drlvm][crash] Cannot run anything on Linux
Mikhail, I'm still able to reproduce the problem on the following configuration. $ cat /etc/SuSE-release SUSE LINUX Enterprise Server 9 (i586) VERSION = 9 Probably I just need to increase a SuSE patch level to overcome this problem. $ set BASH_VERSINFO=([0]=2 [1]=05b [2]=0 [3]=1 [4]=release [5]=i586-suse-linux) COLUMNS=80 EUID=54305 LINES=39 PIPESTATUS=([0]=134) PPID=24369 SHELLOPTS=braceexpand:emacs:hashall:histexpand:interactive-comments:moni torUID=54305 _=n $ drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/java n free(): invalid pointer 0x8089ee0! free(): invalid pointer 0x808af18! An unhandled error (4) has occurred. HyGeneric_Signal_Number=0004 Signal_Number=000b Error_Value= Signal_Code=0001 Handler1=0804A830 Handler2=40026651 InaccessibleAddress= EDI=415DFEA0 ESI= EAX= EBX=4063DC6C ECX=40629F4C EDX=BFFFE6D0 EIP=405D864D ES=007B DS=007B ESP=BFFFE6A0 EFlags=00010206 CS=0073 SS=007B EBP=BFFFE6B8 Module=/usr/lib/libstdc++.so.5 Module_base_address=40587000 Symbol=_ZNSt6localeaSERKS_ Symbol_address=405D8620 Aborted A symbol name mentioned locale - Gregory mentioned we could have problems here on compilation stage. I tried to debug this using gdb, set LD_LIBRARY_PATH to bin:bin/default, and got the following: (gdb) run Starting program: /nfs/ims/proj/drl/mrt/users/af/ws/1/drlvm/trunk/build/lnx_ia32_gcc_debug /deploy/jre/bin/java n [Thread debugging using libthread_db enabled] [New Thread 1080382112 (LWP 17283)] [New Thread 1083587504 (LWP 17284)] Cannot find user-level thread for LWP 17283: generic error (gdb) bt #0 0x4990 in _start () from /lib/ld-linux.so.2 With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Mikhail Fursov [mailto:[EMAIL PROTECTED] Sent: Friday, October 27, 2006 5:09 PM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm][crash] Cannot run anything on Linux SUSE ES Linux 9. GCC 3.3.3 [EMAIL PROTECTED]:/export/users/mfursov/harmony_build/drlvm/trunk ./build/lnx_ia32_gcc_debug/deploy/jre/bin/java -cp . NoSuchClass Uncaught exception in main: java.lang.NoClassDefFoundError: NoSuchClass Caused by: java.lang.ClassNotFoundException: NoSuchClass at java.net.URLClassLoader.findClass(URLClassLoader.java:625) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader$SystemClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) I see no problem (build Linux version every day) On 10/27/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: Geir, I'm not very happy to report that after some class library patch around 23 of October DRLVM no longer works on SUSE Linux 9.0. This happened before you committed that big set of DRLVM patches. All works fine on Ubuntu. I tried two SUSE computers and built from scratch. All, Are there any success stories about recent SUSE builds? -- Mikhail Fursov
RE: 235 tests are missed at DRLVM test run for Windows
Tim, As far as I know IBM has at least four different JVMs. This makes me think it would be more precise to name JVM exactly. If blue giant guys like current tags, let's leave the tags as is. I don't really think that any tag name would be a reason for researchers from the Jikes team not to join us in using http://harmonytest.org. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 2:13 AM To: harmony-dev@incubator.apache.org Subject: Re: 235 tests are missed at DRLVM test run for Windows Fedotov, Alexei A wrote: 4. I vote for one of the following renamings: a) Rename ibm tag to j9 b) Rename drl tag to intel :-). That looks like a strange suggestion to me. I think the tags are fine as they are. What is you thinking? Regards, Tim -- Tim Ellison ([EMAIL PROTECTED])
RE: [classlib] Preprocessor - CHECKPOINT
Regardless, I think we need to settle on our exact requirement first, before spending too much time on looking for a solution. +1 This exactly matches my morning metro thoughts. Nathan, thanks for catching this point. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 4:06 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] Preprocessor - CHECKPOINT What's the concern about just using the prescribed branching pattern for SVN? There are some other nice tricks like externals for pulling in common files into the working copies of other branches (ala the 'concurrent' code in 'standard' that's pulled into 'enhanced' on checkout). I would propose we at least attempt to go down a path of investigating a branching. Regardless, I think we need to settle on our exact requirement first, before spending too much time on looking for a solution. For example, if logging is a real requirement, but everyone agrees it can be done via instrumentation (AspectJ, java.lang.instrument, etc), then are there any other requirements that affect the actual source files internally? If not, then could all of the other requirements be fulfilled by judicious SCM use? So, I would suggest we back up a little and just layout all of the requirements first, so we can make sure everyone's in agreement about the needs. -Nathan On 10/31/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: So we all agree that it's not an ideal solution. Can anyone think of anything else? No one said this was going to be easy... geir
RE: [classlib] Preprocessor - CHECKPOINT
Etienne, The example is quite interesting. But the idea of selling comment space for advertising really rocks! :-) With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Etienne Gagnon [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 2:25 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] Preprocessor - CHECKPOINT Tim Ellison wrote: IMO it's not ideal that the preprocessed source still contains all the streams, albeit in comments. It wouldn't make the source very 'consumable' to the Mrs. SE or ME developer. Hmmm... It's always possible to have a special output mode that puts empty (or advertizing, hehe) comments, instead of other stream code (thus, preserving line numbers). To continue on my earlier example: Java source = j2se end-developer --- ... // Download Harmony[tm] from // // http://the.nice.harmony.url/download // // :-) @Processor(Not in j2me!) int some_field = some + initializing() code; ... Or, more likely: Java source = j2se end-developer --- ... // Please ignore this comment. It has been // intentionally left here to preserve line numbers // for bug reporting purpose. // // Please report bugs to http://bugs.of.harmony.url/... @Processor(Not in j2me!) int some_field = some + initializing() code; ... So, J2ME J2SE end-developers are kept happy. As a bonu$, you can al$o $tart a nice busine$$ $elling advertizing $pace in $ource code. ;-P Etienne -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
RE: [classlib] Preprocessor - CHECKPOINT
Sorry for spam, I bet if you could convince some investor that it was a web2.0 thing, you could get it funded I believe I know one investor - just convince G**gle to distribute AJAX modules for his code search engine which would automatically insert comments with code sensitive advertisement. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 4:39 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] Preprocessor - CHECKPOINT Etienne Gagnon wrote: Tim Ellison wrote: IMO it's not ideal that the preprocessed source still contains all the streams, albeit in comments. It wouldn't make the source very 'consumable' to the Mrs. SE or ME developer. Hmmm... It's always possible to have a special output mode that puts empty (or advertizing, hehe) comments, instead of other stream code (thus, preserving line numbers). To continue on my earlier example: Java source = j2se end-developer --- ... // Download Harmony[tm] from // // http://the.nice.harmony.url/download // // :-) @Processor(Not in j2me!) int some_field = some + initializing() code; ... Or, more likely: Java source = j2se end-developer --- ... // Please ignore this comment. It has been // intentionally left here to preserve line numbers // for bug reporting purpose. // // Please report bugs to http://bugs.of.harmony.url/... @Processor(Not in j2me!) int some_field = some + initializing() code; ... So, J2ME J2SE end-developers are kept happy. I'm still not quite getting the importance of preserving the line numbers like that if we have some minimal tooling to let us work with it in eclipse or IDEA invisibly users would report bug at line X, and we'd either look at the transformed code that they are actually using, and translate backwards, or have a plugin that lets us A/B between transformed and original. The key is to play with some examples, I guess. As a bonu$, you can al$o $tart a nice busine$$ $elling advertizing $pace in $ource code. ;-P It's our idea - you run with it. let us know how that works out. (I bet if you could convince some investor that it was a web2.0 thing, you could get it funded) Etienne
RE: [doc] No Doxygen reference for code :(
Nadya, Thanks for answers. You have a nice approach to the requirement engineering for the documentation build system. It would be great if you also add priorities for your requirements. Looking into your original list of requirements, I've noticed I haven't addressed the second one: 2. Ability to see docs on the website Yesterday I'd added an archive with documentation to HARMONY-2024 http://issues.apache.org/jira/browse/HARMONY-2024, so committers could now put documentation to the web site and everyone could contribute to the documentation quality. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 9:02 PM To: harmony-dev@incubator.apache.org Subject: RE: [doc] No Doxygen reference for code :( Alexei, Thanks for meaningful and numerous questions, Alexei. I have thought of some of these, but you give it a systematic touch :) Others' opinions are welcome, mine in below - marked with [NM]. Related question: do we want to have some version of API doc on the site now? I've experimented with building docs, and could produce a working bundle. We can work to enable the build create API docs locally in parallel with that. PS: Geir, there's a specific question for you below. Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 7:49 PM To: harmony-dev@incubator.apache.org Subject: RE: [doc] No Doxygen reference for code :( Nadya, All, Suggestion to generate Doxygen from DRLVM code sounds very interesting. I posted a quick solution for Linux to http://issues.apache.org/jira/browse/HARMONY-2024 [NM] great news, I'll see if I can do smth similar for Windows. If you want to have this integrated into build.xml, it would be great to define a correct scope. Could you please give more details what do you expect from the documentation build file? [NM] I'd give it a try. Please don't expect me to write a design doc for you A volunteer can try doing some things important for you first, and then add new features gradually. [NM] yeah, I like the idea of a gradual step-by-step process. * Should doxygen build documentation for inter-component interfaces? [NM] sure, and I guess it's the better-documented part ;) * What are components? I assume vm, jit, gc are out of the question. Is am execution manager or an interpreter a separate component? [NM] see dev guide; we've thought components roughly match to top-level folders: EM, Interpreter, TM are all components. Not sure what to do with the three GCs now, though. * Should doxygen build documentation for each component like vm, jit, interpreter, gc? [NM] It's my dream and very convenient. Getting Doxygen to run for half-hour and get hung doesn't seem an attractive prospect. However, I guess we can get some primitive build as a start and add component-specific build targets later. For me, an ideal list of targets for Doxygen would be something like: all - all headers for DRLVM/classlib (one of two, not both in one bundle) inter-component - headers in include/ folder basically. Do we have any high-level interfaces in other places? This could show the big picture and somehow map to the arch description. component - headers for the component name specified. We might concentrate on the first two now for simplicity and smaller scope. * Should we put documentation into doc/component_doc dirs as class library code does? [NM] this is a complex issue. I know Geir has wanted to add website to the snapshot. *Geir*, could you express your view on where to place docs? I guess separating normal docs and autogenerated docs would be good, like the /doc/ folder for all files, with /doc/Doxygen/ subfolder for API reference. When we are ready to build component-specific reference, /doc/Doxygen/ can have subfolders for each. * Should we use the same formatting as a class library documentation? [NM] why not? as I've noticed, default formatting is ok, but there are many options you can enable/disable, e.g. diagram for class hierarchy. * We don't need to process .cpp files in DRLVM source tree, do we? [NM] no, I guess not. A developer that needs explanation in .cpp would rather look into the code, I guess. * Would each of these choices (inter-component documentation, component interface documentation) be a separate configuration? If yes, should we put each result into the separate directory? * Should doxygen process .java files in DRLVM source tree? * Should the doxygen documentation be integrated with class library documentation? [NM] I hope we can have two different bundles. Otherwise, it'd take our poor Doxygen a day to compile the docs :) we can cross-reference the two index.html files. Can you estimate, how often you'd want to link from a vm header description into classlib? * Do you expect to have inheritance diagrams? [NM] I don't know. From what I see, you
RE: [doc] No Doxygen reference for code :(
Nadya, Sorry, I supposed to say the same thing. By requirement engineering I meant a discussion of requirements. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 5:09 PM To: harmony-dev@incubator.apache.org Subject: RE: [doc] No Doxygen reference for code :( Alexei, One note: I'm *not* writing requirements for engineering on the doc build system. I'm just sharing my thoughts on an issue that interests me. Discussion is welcome. Please don't consider my ideas as the way it should be. Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 4:52 PM To: harmony-dev@incubator.apache.org Subject: RE: [doc] No Doxygen reference for code :( Nadya, Thanks for answers. You have a nice approach to the requirement engineering for the documentation build system. It would be great if you also add priorities for your requirements. Looking into your original list of requirements, I've noticed I haven't addressed the second one: 2. Ability to see docs on the website Yesterday I'd added an archive with documentation to HARMONY-2024 http://issues.apache.org/jira/browse/HARMONY-2024, so committers could now put documentation to the web site and everyone could contribute to the documentation quality. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 9:02 PM To: harmony-dev@incubator.apache.org Subject: RE: [doc] No Doxygen reference for code :( Alexei, Thanks for meaningful and numerous questions, Alexei. I have thought of some of these, but you give it a systematic touch :) Others' opinions are welcome, mine in below - marked with [NM]. Related question: do we want to have some version of API doc on the site now? I've experimented with building docs, and could produce a working bundle. We can work to enable the build create API docs locally in parallel with that. PS: Geir, there's a specific question for you below. Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 7:49 PM To: harmony-dev@incubator.apache.org Subject: RE: [doc] No Doxygen reference for code :( Nadya, All, Suggestion to generate Doxygen from DRLVM code sounds very interesting. I posted a quick solution for Linux to http://issues.apache.org/jira/browse/HARMONY-2024 [NM] great news, I'll see if I can do smth similar for Windows. If you want to have this integrated into build.xml, it would be great to define a correct scope. Could you please give more details what do you expect from the documentation build file? [NM] I'd give it a try. Please don't expect me to write a design doc for you A volunteer can try doing some things important for you first, and then add new features gradually. [NM] yeah, I like the idea of a gradual step-by-step process. * Should doxygen build documentation for inter-component interfaces? [NM] sure, and I guess it's the better-documented part ;) * What are components? I assume vm, jit, gc are out of the question. Is am execution manager or an interpreter a separate component? [NM] see dev guide; we've thought components roughly match to top-level folders: EM, Interpreter, TM are all components. Not sure what to do with the three GCs now, though. * Should doxygen build documentation for each component like vm, jit, interpreter, gc? [NM] It's my dream and very convenient. Getting Doxygen to run for half-hour and get hung doesn't seem an attractive prospect. However, I guess we can get some primitive build as a start and add component-specific build targets later. For me, an ideal list of targets for Doxygen would be something like: all - all headers for DRLVM/classlib (one of two, not both in one bundle) inter-component - headers in include/ folder basically. Do we have any high-level interfaces in other places? This could show the big picture and somehow map to the arch description. component - headers for the component name specified. We might concentrate on the first two now for simplicity and smaller scope. * Should we put documentation into doc/component_doc dirs as class library code does? [NM] this is a complex issue. I know Geir has wanted to add website to the snapshot. *Geir*, could you express your view on where to place docs? I guess separating normal docs and autogenerated docs would be good, like the /doc/ folder for all files, with /doc/Doxygen/ subfolder for API reference. When we are ready to build component-specific reference, /doc/Doxygen/ can have subfolders for each. * Should we use the same formatting as a class library documentation? [NM] why not? as I've noticed, default formatting is ok, but there are many options you can enable/disable, e.g. diagram for class hierarchy
RE: [classlib] Preprocessor - CHECKPOINT
I am really offering to develop this custom tool. +1 For me this is a key message. For sure that would be a nice tool. Does it worth to dig use cases even more? Do we plan to develop j2me here at Harmony? Etienne, I wonder if it worth to have SableCC itself exposed as a part of Harmony. Say, you post a JSR for compiler generation API and add an appropriate package to Harmony JRE. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Etienne Gagnon [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 4:51 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] Preprocessor - CHECKPOINT Geir Magnusson Jr. wrote: There's caching too, I think. LogCache4J What I meant was that it didn't seem like we came to a conclusion on it - that if we had a general pre-processing solution, we could use that too for logging, rather than have two. The actual use-cases will help figure this out. Here two typical some use cases, and some proposed solutions: Problem --- logging, and other situations where you really don't want to put the additional source code in the main source files Solution use aspects (Plug: you might want to give a look at the optimizing abc compiler) Problem --- supporting a different API specifications/versions, such as j2me and j2se1.4, in addition to the main version (e.g. j2se1.5) Solution This is a trickier problem. We can divide the problem at two main levels: 1- file/directory level 2- source-code level At the file/directory level, each version (e.g. j2me, j2se1.4, ...) might include additional files (relative to the main version), and might not include some files of the main version. In other words, j2me might not contain database APIs. Managing file inclusion/exclusion can be done in various ways. a) ant based: use distinct ant (sub-)files for each version. The problem is that IDEs (e.g. Eclipse) will most likely show some of the excluded files in its class/files browser. This wouldn't be very elegant. It also implies always compiling through ant files. Of course, one could develop Eclipse-specific configuration files to mimic the inclusion/exclusion of ant files, but then, this opens the door for discrepancies between ant vs eclipse inclusion/exclusion lists. I don't like it. b) custom-tool based: the custom processing tool I proposed could also parse inclusion/exclusion lists, and use these lists to move files around, in addition to processing the content of unmoved files. For example, if class X of the main version is not part of j2me, process(j2me) would move this file to a subdirectory .streams/. If a class Y is not in the main version (the one used for svn ci), it resides in subdirectory .streams in the trunk. process(j2me) moves this file into the normal directory. As for IDEs, now you can configure them to automatically exclude .stream/ directories. Inclusion/exclusion could be managed in two ways: 1- the processing tool could look for inclusion/exclusion list files, such as j2me.inclusion, j2me.exclusion, main.inclusion, main.exclusion, etc. This would lead to the best performance (for process(X)), yet it does require much manual update of inclusion/exclusion lists, with all the discrepancies that result from human mistakes while updating these files. 2- (my preferred way), directives, at the beginning of the source code would indicate whether a file is included in a version or not. Depending on target, the file would be moved to the appropriate directory (normal, .streams). Of course, there's also the problem of non-source files, i.e. resources. IMO, resources could be managed using specific directories (.main/, .j2me, .j2se1.4) and a .shared/ directory with symbolic links in the specific directories. As for source-level management, you would use my proposed processing tool to view the source files with the right spectacles [as Tim said so elegantly:-)]. For development targets, it is important that: revert(process(X, target)) = X By development target I mean a target that is meant for Harmony developers in prevision of reverting modified code to a format suitable for svn ci (i.e. revert to main target). For comfortable IDE development, one could imagine that the IDE editor can reduce to one-line visible comments (or better, specially formatted ones) so that it gives you the impression that you are really wearing target-specific spectacles. [I know Eclipse allows for such things already]. To release code, one would apply: process(X, release-target) = Y Now, it is important to understand that Y, in this case, is NOT suitable for doing any modification as revert(Y) = Kaboom! (The tool will simply report that it can't do it; it won't crash.) Yet, I think that it would be important that the
RE: Programmer Volunteering (sorry if I should read a FAQ before)
So, you are very welcome. :-) I enjoyed the quotes at the end of your post. Recently Sveta and Geir updated http://incubator.apache.org/harmony/quickhelp_contributors.html - I believe it worth to take a look at. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Nilseu Padilha JMiB [mailto:[EMAIL PROTECTED] Sent: Friday, May 13, 2005 8:15 PM To: harmony-dev@incubator.apache.org Subject: Programmer Volunteering (sorry if I should read a FAQ before) Greetings. I am a cmomercial Systems Architect and would like to volunteer myself as a developer to the Harmony Project. Sorry if I should read any FAQ before, but I like to know how I could contribute to the project. Thank you. Regards, Padilha id=Nilseu name=Nilseu Perside Ortiz Padilha Junior jCert=SCEA P1 - Sun Certified Enterprise Architect for J2EE Part 1 aka=JMiB jobTitle=J2EE Hardcore Architect jobMainAssignment=Omnipres Co-Architect - Solution for Distributed Enterprise Data jobOffice=Immediate Consultoria e Sistemas jobPhone=+55-051-3233-8495 jobPage=http://www.immediate.com.br; association=Association for Computing Machinery - ACM education=Bachelor\'s in Computer Science - ULBRA Quote author=Colonel Samuel Trautman And one more thing, what you choose to call hell, he calls home. /Quote Quote author=Cha-ka Oganza bi sasa! /Quote Quote author=E. W. Dijkstra Computer science is no more about computers than astronomy is about telescopes. /Quote Quote author=General Zod Son of Jor-el, kneel before Zod /Quote Quote author=Dave Clark We reject kings, presidents and voting. We believe in rough consensus and running code. /Quote Quote author=Vilfredo Pareto A minority of input produces the majority of results. /Quote Quote author=Daffy Duck You\'re...You\'re despicable! /Quote Quote author=Sophocles It is a painful thing To look at your own trouble and know That you yourself and no one else has made it. /Quote Quote author=T-101 John Connor, It is time. /Quote Quote author=Master Yoda One exam does not a (J2EE) architect make. /Quote Scorea href=http://www.nerdtests.com/ft_nq.php?im; img src=http://www.nerdtests.com/images/ft/nq.php?val=8792; alt=I am nerdier than 97% of all people. Are you nerdier? Click here to find out! /a/Score/Padilha
[doc] What should be improved in DRLVM Doxygen documentation?
Nadya, All, I have ranked the quality of Doxygen-generated DRLVM documentation and posted it to the following Wiki page: http://wiki.apache.org/harmony/DRLVM_Documentation_Quality All are welcome to check masterpieces of our documentation. All volunteers are welcome to improve page ranks by editing comments in DRLVM sources. With best regards, Alexei Fedotov, Intel Java XML Engineering
RE: Re: [doc] What should be improved in DRLVM Doxygen documentation?
Nadya wrote, we could check for required Doxygen tags in certain elements. I wasn't asked, but cannot resist, sorry. You may achieve this right now without additional coding. Doxygen warns about many problems you describe, when you have the following option set. # If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings # for undocumented members. If EXTRACT_ALL is set to YES then this flag will # automatically be disabled. WARN_IF_UNDOCUMENTED = YES The resulting log consists of warning messages about different problems. My DoxygenDrlvmLog.txt, for example, contains the following one: drlvm/trunk/vm/MMTk/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk/ Scanning.java:47: Warning: The following parameters of org::apache::HarmonyDRLVM::mm::mmtk::Scanning::precopyChildren(TraceLoca l trace, ObjectReference object) are not documented: parameter trace With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 6:26 PM To: harmony-dev@incubator.apache.org Subject: RE: Re: [doc] What should be improved in DRLVM Doxygen documentation? Egor, I agree with you on the idea of simplicity: documented vs. non-documented. An additional point: do you think we need/want to evaluate quality of comments? we could check for required Doxygen tags in certain elements. For example, a function is almost certain to include @param and @return. Surely, this is heuristics and does not solve all our problems. But the Doxygen quality check sometimes shows that the file does have comments, but they are not processed properly by Doxygen - which results in a low rating for an html file. Maybe this is a crazy idea - I'd be glad to know your opinion. Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 03, 2006 12:18 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] What should be improved in DRLVM Doxygen documentation? On the 0x216 day of Apache Harmony Alexei Fedotov wrote: Egor, Thank you for your interest. We definitely need to improve our documentation. Necessity is not a real interest :) Here is an algorithm: 1. Create a list of words from HTML files. 2. Merge a dictionary of all words used in documentation. 3. Remove a half of the most frequently used words from the dictionary - I believe they do not add much sense. 4. Remove misspelled words (including identifiers) from the dictionary. 5. Give a page +1 for each rare, correctly spelled word according to the dictionary. 6. Divide to the total number of words on the page. hm, strange heuristic. More unique correctly spelled words is beneficial. It does not give a clue on the overall quality of documentation, which is rather confusing.. I thought of something more natural. Number of documented items vs. number of non-documented. Plus a penalty to the relative number of misspelled words. I've collected nice RFEs from your letter. Most of them make me think and I like them. a. Update an ASF block comment b. Improve readability. Some things are really easy - like removing awk and rewriting most things in perl. Others are a bit more complex - I targeted script performance when created auto-generated perl script. Also, initial algorithm was a bit more complex - different words had a different cost based on their popularity. c. Use junit test output format to integrate with http://harmonytest.org. I believe I need a feature request for that site as well - we need some way to import performance-like rankings to the site. Yes, I thought of the RFE to harmonytest. At least, put the doc items on a separate page from the build items. d. I will think of parsing sources. But I don't think we need to maintain both scripts. The generic rule is simple - improve your .h and .java files - .cpp files don't count. I suggest better to link .html files to contributors. can you calculate a list of relevant filenames from a doc page? give filename +1 for each documented item, give a -1 for each undocumented, divide on the number of items. Is it easy to implement? Maybe doxygen has some features to assist this? Thank you for ideas. I will certainly update the script. I just want to wait a bit - many scripts die just because people are not interested to run them a second time. Also, if anyone suggest any changes in algorithm or any other RFEs, I want to implement them all at once. Nadya, could you please point us a good documentation file so we can use it as a pattern? -- Egor Pasko
RE: Re: [doc] What should be improved in DRLVM Doxygen documentation?
Never mind, I think this type of info is not necessary at this stage:) +1 -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 7:42 PM To: harmony-dev@incubator.apache.org Subject: RE: Re: [doc] What should be improved in DRLVM Doxygen documentation? Alexei, I think we're talking about different things here :) I fully support your idea and I know about the Doxygen config options you have mentioned. I was just curious to know: is there interest to produce/evaluate produce Doxygen-style comments. My case was that, say, a function can have a line of text, we consider it documented, etc. however, the function comment is only a draft that does not produce meaningful documentation. A sign of better comment is @param and/or @return tag included in the function comment. Never mind, I think this type of info is not necessary at this stage:) Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 7:36 PM To: harmony-dev@incubator.apache.org Subject: RE: Re: [doc] What should be improved in DRLVM Doxygen documentation? Nadya wrote, we could check for required Doxygen tags in certain elements. I wasn't asked, but cannot resist, sorry. You may achieve this right now without additional coding. Doxygen warns about many problems you describe, when you have the following option set. # If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings # for undocumented members. If EXTRACT_ALL is set to YES then this flag will # automatically be disabled. WARN_IF_UNDOCUMENTED = YES The resulting log consists of warning messages about different problems. My DoxygenDrlvmLog.txt, for example, contains the following one: drlvm/trunk/vm/MMTk/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk / Scanning.java:47: Warning: The following parameters of org::apache::HarmonyDRLVM::mm::mmtk::Scanning::precopyChildren(TraceLoc a l trace, ObjectReference object) are not documented: parameter trace With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 6:26 PM To: harmony-dev@incubator.apache.org Subject: RE: Re: [doc] What should be improved in DRLVM Doxygen documentation? Egor, I agree with you on the idea of simplicity: documented vs. non-documented. An additional point: do you think we need/want to evaluate quality of comments? we could check for required Doxygen tags in certain elements. For example, a function is almost certain to include @param and @return. Surely, this is heuristics and does not solve all our problems. But the Doxygen quality check sometimes shows that the file does have comments, but they are not processed properly by Doxygen - which results in a low rating for an html file. Maybe this is a crazy idea - I'd be glad to know your opinion. Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 03, 2006 12:18 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] What should be improved in DRLVM Doxygen documentation? On the 0x216 day of Apache Harmony Alexei Fedotov wrote: Egor, Thank you for your interest. We definitely need to improve our documentation. Necessity is not a real interest :) Here is an algorithm: 1. Create a list of words from HTML files. 2. Merge a dictionary of all words used in documentation. 3. Remove a half of the most frequently used words from the dictionary - I believe they do not add much sense. 4. Remove misspelled words (including identifiers) from the dictionary. 5. Give a page +1 for each rare, correctly spelled word according to the dictionary. 6. Divide to the total number of words on the page. hm, strange heuristic. More unique correctly spelled words is beneficial. It does not give a clue on the overall quality of documentation, which is rather confusing.. I thought of something more natural. Number of documented items vs. number of non-documented. Plus a penalty to the relative number of misspelled words. I've collected nice RFEs from your letter. Most of them make me think and I like them. a. Update an ASF block comment b. Improve readability. Some things are really easy - like removing awk and rewriting most things in perl. Others are a bit more complex - I targeted script performance when created auto-generated perl script. Also, initial algorithm was a bit more complex - different words had a different cost based on their popularity. c. Use junit test output format to integrate with http://harmonytest.org. I believe I need a feature request for that site as well - we need some way to import performance-like rankings to the site. Yes, I thought of the RFE to harmonytest. At least, put the doc items on a separate page from the build items. d. I will think of parsing sources. But I
RE: [doc] What should be improved in DRLVM Doxygen documentation?
] :( 6. Today the community discussed removing GC V4. This would immediately decrease GC documentation size. It would also decrease a number of well documented pages on garbage collection, since new GCs don't have as much comments in their code as old GC V4. [NM] yeah, I read the news :) Thank you for nice catches, Alexei On 11/2/06, Morozova, Nadezhda [EMAIL PROTECTED] wrote: Wow! Alexei, great start! ... and so many pages marked with 0 rank. I really appreciate your effort - it sets me back on earth and to work. I hope this rating would also make owners of code more ambitious, and would inspire them to write more/better comments to get a better rating :) Question on output measurement: can we rate source files or code elements (structure, functions, etc) instead of html files? My concerns: - Many html files are autogenerated, their rating is N/A. examples: todo.html, functions_vars_0x68.html (listing of links to functions in alphabetical order - there are many pages like that) - Some results are duplicated, because each struct/function has an individual rating + rating of the file/group reference it belongs to. - Some files have a high rating (see the top candidate, for example), but it's generated from comments marked with @page. These don't belong to specific code, but create a narrative section. Evaluating these is complex, and perhaps, should not be done. My personal preference would be to move such generic explanations to component docs on the website and reserve Doxygen docs to API reference as much as possible (this is a subject for further discussion). - the listing of files is SO LONG... grouping them by file/component/type or otherwise organizing the output would make the whole rating more readable. I mean, from the current version, I can only make out the leaders (not files even, individual bits of them), and understand that the majority have 0 rating. This has its instructional impact, but I cannot see the areas where we are the best - bearable - worst, or see the approx distribution of powers... missing that info leaves me without direction on what to do. Question on data presentation: do you think we can have some post processing of the raw data that your script produces - to see the big picture? We have some metrics: graphics, pie charts, anything. This would instantly show the most important conclusions. I could do such metrics and post them regularly on Wiki. If anybody says they need such kind of info, I'd volunteer to help. Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 11:33 PM To: harmony-dev@incubator.apache.org Subject: [doc] What should be improved in DRLVM Doxygen documentation? Nadya, All, I have ranked the quality of Doxygen-generated DRLVM documentation and posted it to the following Wiki page: http://wiki.apache.org/harmony/DRLVM_Documentation_Quality All are welcome to check masterpieces of our documentation. All volunteers are welcome to improve page ranks by editing comments in DRLVM sources. With best regards, Alexei Fedotov, Intel Java XML Engineering
RE: [classlib][nio] SocketChannelTest fails on Windows 2003 server
I suggest the latter: comment assertSocketAction_NonBlock_BeforeConnect in testSocket_NonBlock_ActionsBeforeConnect. Because the test scenario is a kinda abnormal case, and I guess the test author didn't run the test on the windows 2003 server, therefore, the test itself is invalid. +1 for excluding the test case With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Andrew Zhang [mailto:[EMAIL PROTECTED] Sent: Friday, October 27, 2006 5:56 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][nio] SocketChannelTest fails on Windows 2003 server On 10/27/06, Elena Semukhina [EMAIL PROTECTED] wrote: On 10/27/06, Andrew Zhang [EMAIL PROTECTED] wrote: On 10/26/06, Elena Semukhina [EMAIL PROTECTED] wrote: Hello, I ran classlib tests on Windows 2003 server and saw the org.apache.harmony.nio.tests.java.nio.channels.SocketChannelTest test failure. I've reported this at https://issues.apache.org/jira/browse/HARMONY-1977. Hi Elena, does this test always fail on windows 2003 server? Can RI pass this test? Andrew, the test fails on RI too. iirc, there're some other tests in nio are platform dependent. We're waiting for TestNG. :) These tests are marked with FIXME. If the test you found is also platform-dependent, maybe mark it with FXIME and comment the assert is a simple workaround now. :) Thanks! We are talking about testSocket_NonBlock_ActionsBeforeConnect() test. It uses special assertion method assertSocketAction_NonBlock_BeforeConnect() which, in turn, contains a few assertions and is called not from this test only but from another test as well. And that test passes this assertion. I'm not sure that I know which is better: to commented out the whole assertion in the test or a particular assertion in the assert method :( I suggest the latter: comment assertSocketAction_NonBlock_BeforeConnect in testSocket_NonBlock_ActionsBeforeConnect. Because the test scenario is a kinda abnormal case, and I guess the test author didn't run the test on the windows 2003 server, therefore, the test itself is invalid. However, keeping the test there is still valuable to record the platform differences. Could anyone look at the issue? -- Thanks, Elena -- Best regards, Andrew Zhang -- Thanks, Elena -- Best regards, Andrew Zhang
[ant] ant --noconfig helps disabling pre-installed ant rpm on Linux Was: [ant][classlib][em64t]Problems during classlib on em64t (revision 462753)
Hello, Since my Linux died due to hardware problem I now abide at computers of my friends. Pavel's computer showed the same ANT problem with missing regular expression matcher. After some digging I found out that ANT installed from RPM package has a priority over my ant from $ANT_HOME: http://www.jayasoft.org/node/820 The problem happens because $ANT_HOME/bin/ant reads /etc/ant.conf which sets rpm_mode=true unless --noconfig is set. If you are not a root, you have a little chance to change /etc/ant.conf or add something to pre-installed ANT's lib directory. I started looking for workaround. Supplying --noconfig option for $ANT_HOME/bin/ant worked for me. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Valentin Al. Sitnick (Moscow) [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 7:41 PM To: harmony-dev@incubator.apache.org Subject: Re: [ant][classlib][em64t]Problems during classlib on em64t (revision 462753) Sorry I have not experience to send long logs... svn-info: [exec] Current OS is Linux [exec] Output redirected to property: svn.info.tmp [exec] Executing 'svn' with arguments: [exec] 'info' [exec] [exec] The ' characters around the executable and arguments are [exec] not part of the command. Override ignored for property svn.info build-jar: [subant] Exiting /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/modules/accessibility/build.xml. [antcall] Exiting /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/make/build-java.xml. [ant] Exiting /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/make/build-java.xml. 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/bu ild- java.xml:183: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1- em64t/clean/classlib/trunk/make/properties.xml:249: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1- em64t/clean/classlib/trunk/make/properties.xml:259: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1- em64t/clean/classlib/trunk/modules/accessibility/build.xml:90: No supported regular expression ma tcher found at org.apache.tools.ant.ProjectHelper.addLocationToBuildException( ProjectHelper.java:539) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:384) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java :275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java :1216) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets( DefaultExecutor.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67) Caused by: /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/properties.xml:249: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1- em64t/clean/classlib/trunk/make/properties.xml:259: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1- em64t/clean/classlib/trunk/modules/accessibility/build.xml:90: No supported regular expression ma tcher found at org.apache.tools.ant.ProjectHelper.addLocationToBuildException( ProjectHelper.java:539) at org.apache.tools.ant.taskdefs.MacroInstance.execute( MacroInstance.java:380) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java :275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java :1216) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets( SingleCheckExecutor.java:37) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382) ... 12 more Caused by: /home/angel/builds/harmony/suse-10.1- em64t/clean/classlib/trunk/make/properties.xml:249: The following
RE: [drlvm] [testing] Excluding commit tests until the problem is fixed
Rana, Pavel (Afremov), All, Geir's comment on r443504 (fix for http://issues.apache.org/jira/browse/HARMONY-1363 [drlvm] Java 1.5, 64 bit support, JVMTI improvements) reads: 1) Stack overflow exception stuff is broken. I had to remove the assert in signals_ia32.cpp line 336. Rana knows and will look. I also disabled the StackTest. I have noticed that the patch added a new function exn_raise_by_name_internal which fails on the first invocation checking an assertion about thread state, see http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][unit] org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest crashes DRLVM. I also have noticed that this function is called to create java.lang.StackOverflowError. Could you help me to understand the current status of the problem? With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Rana Dasgupta [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 18, 2006 4:27 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] [testing] Excluding commit tests until the problem is fixed I fixed the StackOverflow functionality problem by going back and mapping all pages ( guard, alternate stack ) meticulously before trying to protect them. I think we should have done this in the first place. I also cleaned up the previous initialization workarounds and asserts Geir and I had discussed on the JIRA. The Stacktest and all other stack related tests now pass. I'll submit the patch against 1786 in the next few hours after running acceptance tests. Rana On 10/16/06, Rana Dasgupta [EMAIL PROTECTED] wrote: On 10/16/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Tuesday 17 October 2006 00:01 Geir Magnusson Jr. wrote: I tried to put some back. StackTest still doesn't work. It's hard to believe... so I gave up and just kept going :) I wonder if the test or the implementation are wrong. Maybe someone who added the test initially could know the answer. There is nothing wrong with the stacktest test itself. The implementation is not quite 100%complete( I think ), but has enough functionality and the test passes on Windows. On Linux, it fails. I am not sure if this is a regression, or if this ever worked. There is a JIRA issue 1786. In summary, memory protection setup for the guard page fails on the main thread(only). So the guard does not work and the overflow is not detected. mprotect fails with an ENOMEM which is either a mapping failure or a kernel failure. mprotect() has some known flakiness it seems, as per literature. The basic implementation on Linux is sound. There are secondary design issues,but we can only get to them later after we have figured out why the guard setup fails on the main thread.
[drlvm][unit] Closing H-1679, H-1722
Anton, Is it ok to close the following issues? * HARMONY-1679 Timer.schedule(TimerTask, delay, period) doesn't cause repetitive invocation of task * HARMONY-1722 notify() in synchronized section makes wait(long) wait forever I cannot reproduce them on the latest build. With best regards, Alexei Fedotov, Intel Java XML Engineering
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Alexey, I started looking into this thread. Are guidelines on the web site already? I failed to find them. I thought about adding them to get-involved.html. Here are few problems I've noticed: 1. The detail level of your instruction is somewhat different from get-involved.html. This text is formal, while the text on the page is quite informal. 2. If a guy has a test in a separate file, should he produce a patch from such file and submit the patch? According to guidelines, the answer is yes. According to my common sense patches are good when you modify existing files. 3. Why it is not suggested for an issue reporter to try localizing a buggy module or even fixing the problem? 4. Item 4. of issue reporter guidelines doesn't contain enough details for my taste. I believe links should be descriptive: Link the issue to previous posts, JIRAs, RI bugs, etc. 5. The item 2.1 of resolution provider guidelines contains too many details to my mind. Here should be something like a following text (for all roles): a. Update JIRA once per day reporting your progress. b. Always keep the community posted. 6. The item 2.4 refers to class library build.xml as a main build.xml. 7. You do not specify which unit tests should pass and which VM should be used. Since the changes could affect DRLVM, I would say that all unit tests should pass for DRLVM unless the fall into exclude list. 8. I believe a verification stage should happen before committer commits a patch - this would save his time if the issue doesn't resolve the problem. Overall the text is great and worth to be posted in any case. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 5:02 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) :) Yes, I'll prepare a patch. 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug. If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue and send a message to dev list. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it. 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment. 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/ classlib/trunk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. Remember to use issue links if applicable. Committer: Depending on the issue type, do: 1. Issue is a non-bug difference, not a bug or invalid: Close the issue. 2. Issue is a bug: 2.1. If a
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Alexey, Thank you for your answer. Yesterday I tried to prepare an appropriate patch for get-involved.html but faced several things I couldn't resolve myself. I didn't criticize your text - I was thinking how to fit it into get-involved.html. That is why I raised all these questions. I still have one question which is important, to my mind. You wrote, DRLVM is not the only Harmony VM. I think that developer can choose which VM to use. 1. As Geir says, we are small community, and we need to keep ourselves concentrated. Can we give a recommendation to concentrate on one specific VM assuming that VM which is shipped with Harmony 1.0? 2. What is the status of DRLVM smoke tests? As any tests written in java they have a dependency from a class library. Do you think they should be skipped while testing the patch? With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Monday, November 06, 2006 2:03 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) 2006/11/6, Fedotov, Alexei A [EMAIL PROTECTED]: Alexey, I started looking into this thread. Are guidelines on the web site already? I failed to find them. No, this guideline is not published yet. I'll do this in the nearest future. I thought about adding them to get-involved.html. Here are few problems I've noticed: First of all As you know patches are always welcome in Harmony :) 1. The detail level of your instruction is somewhat different from get-involved.html. This text is formal, while the text on the page is quite informal. I do not see problem here. 2. If a guy has a test in a separate file, should he produce a patch from such file and submit the patch? According to guidelines, the answer is yes. Do you mean in a new file? Yes, a new file should be provided as a patch too. Why not? According to my common sense patches are good when you modify existing files. Yes, they are good for modified files. And they also can be used for adding and removing files. 3. Why it is not suggested for an issue reporter to try localizing a buggy module I think that points 2 and 3 are saying this. or even fixing the problem? Nobody said that an issue reporter can not be a resolution provider. 4. Item 4. of issue reporter guidelines doesn't contain enough details for my taste. I believe links should be descriptive: Link the issue to previous posts, JIRAs, RI bugs, etc. Probably your sentence is better. Need to think. 5. The item 2.1 of resolution provider guidelines contains too many details to my mind. Here should be something like a following text (for all roles): a. Update JIRA once per day reporting your progress. b. Always keep the community posted. What for? Why do you want to have DAILY posts on ALL the working issues? I think that we do not need to change anything here since comunity has agreed on the list of notifications it wants to see. And all these cases are described there. 6. The item 2.4 refers to class library build.xml as a main build.xml. Patches are welcome :) 7. You do not specify which unit tests should pass and which VM should be used. Since the changes could affect DRLVM, I would say that all unit tests should pass for DRLVM unless the fall into exclude list. DRLVM is not the only Harmony VM. I think that developer can choose which VM to use. 8. I believe a verification stage should happen before committer commits a patch - this would save his time if the issue doesn't resolve the problem. Yes, and nobody argue with this. SY, Alexey -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 5:02 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) :) Yes, I'll prepare a patch. 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior
RE: [ant] ant --noconfig helps disabling pre-installed ant rpm on Linux Was: [ant][classlib][em64t]Problems during classlib on em64t (revision 462753)
Alexey, As you suggested I put is the resolution to http://wiki.apache.org/harmony/ANT_FAQ With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Monday, November 06, 2006 12:18 PM To: harmony-dev@incubator.apache.org Subject: Re: [ant] ant --noconfig helps disabling pre-installed ant rpm on Linux Was: [ant][classlib][em64t]Problems during classlib on em64t (revision 462753) I remember that we faced the same problem long time ago. So it is probably a good candidate for mentioning on wiki. SY, Alexey 2006/11/5, Fedotov, Alexei A [EMAIL PROTECTED]: Hello, Since my Linux died due to hardware problem I now abide at computers of my friends. Pavel's computer showed the same ANT problem with missing regular expression matcher. After some digging I found out that ANT installed from RPM package has a priority over my ant from $ANT_HOME: http://www.jayasoft.org/node/820 The problem happens because $ANT_HOME/bin/ant reads /etc/ant.conf which sets rpm_mode=true unless --noconfig is set. If you are not a root, you have a little chance to change /etc/ant.conf or add something to pre-installed ANT's lib directory. I started looking for workaround. Supplying --noconfig option for $ANT_HOME/bin/ant worked for me. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Valentin Al. Sitnick (Moscow) [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 7:41 PM To: harmony-dev@incubator.apache.org Subject: Re: [ant][classlib][em64t]Problems during classlib on em64t (revision 462753) Sorry I have not experience to send long logs... svn-info: [exec] Current OS is Linux [exec] Output redirected to property: svn.info.tmp [exec] Executing 'svn' with arguments: [exec] 'info' [exec] [exec] The ' characters around the executable and arguments are [exec] not part of the command. Override ignored for property svn.info build-jar: [subant] Exiting /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/modules/accessibility/build.xml. [antcall] Exiting /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/make/build-java.xml. [ant] Exiting /home/angel/builds/harmony/suse-10.1-em64t /clean/classlib/trunk/make/build-java.xml. 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/bu ild- java.xml:183: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1- em64t/clean/classlib/trunk/make/properties.xml:249: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1- em64t/clean/classlib/trunk/make/properties.xml:259: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1- em64t/clean/classlib/trunk/modules/accessibility/build.xml:90: No supported regular expression ma tcher found at org.apache.tools.ant.ProjectHelper.addLocationToBuildException( ProjectHelper.java:539) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:384) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java :275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java :1216) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets( DefaultExecutor.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67) Caused by: /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/properties.xml:249: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1- em64t/clean/classlib/trunk/make/properties.xml:259: The following error occurred while executing this line: /home/angel/builds/harmony/suse-10.1- em64t/clean/classlib/trunk/modules/accessibility/build.xml:90: No supported regular expression ma tcher found at org.apache.tools.ant.ProjectHelper.addLocationToBuildException( ProjectHelper.java:539) at org.apache.tools.ant.taskdefs.MacroInstance.execute
RE: [DRLVM] General stability
Alexey Petrenko wrote, The only release I can imagine is Harmony Java5SE 100% compatible. To be Java5SE 100% compatible we need TCK first. +1 I hesitate to say that again, but we also need to decide about VM we will use for that release. I like the following mission: Class library and DRLVM pass TCK on Ubuntu 6. I'm open for any other mission which is challenging, understandable and short enough. Writing down this mission certainly shouldn't inhibit individuals from achieving other goals at Harmony. But it would help the rest of community to concentrate on the common task. 1. http://wiki.apache.org/harmony/Platforms_to_Run_Harmony_Development_Kit_ on With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 10:36 AM To: harmony-dev@incubator.apache.org Subject: Re: [DRLVM] General stability 2006/11/8, Mikhail Fursov [EMAIL PROTECTED]: On 11/8/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Probably it's time to create some release plan :) So let's start this discussion? Good idea! The only release I can imagine is Harmony Java5SE 100% compatible. To be Java5SE 100% compatible we need TCK first. So we could think about some less impressive goal for the first release :) SY, Alexey
Tests scores on http://harmonytest.org Was: [DRLVM] General stability
Geir, I like the overall letter. Anton, I have related question. How can we improve http://harmonytest.org to make it possible to publish not just pass, fail, or error but numeric test scores? How this is related to the letter? I believe that stress tests which were mentioned in the letter may have scores in a way performance tests do, see http://incubator.apache.org/harmony/subcomponents/stresstest/index.html BTW, Egor Pasko requested scores to report documentation quality. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 4:51 AM To: harmony-dev@incubator.apache.org Subject: Re: [DRLVM] General stability Fedotov, Alexei A wrote: Alexey Petrenko wrote, The only release I can imagine is Harmony Java5SE 100% compatible. To be Java5SE 100% compatible we need TCK first. +1 Yes - and I still think that talk of a release is a bit premature right now. The key things that I believe we need to focus on are a) stability and b) completeness. c) reliability (which may be 'stability') (and not always in that order :) Things I'd like to see us do : 1) We need to drive to fully working unit tests for both DRLVM and classlib (using DRLVM). Great progress has been made in this area, and we should probably make this a campaign for DRLVM as we did for classlib. 2) Add stress tests 3) Get our CC-based build-test framework patched and running on as many platforms as possible, reporting breakage into the list. 4) Identify problem areas and focus on them. For example, threading in DRLVM... I do think of us having a 'zero regression' policy except in cases where we make the explicit decision to break. (like we did with TM, for example) I hesitate to say that again, but we also need to decide about VM we will use for that release. I like the following mission: Class library and DRLVM pass TCK on Ubuntu 6. I'm open for any other mission which is challenging, understandable and short enough. Well, we'll need Windows XP and RHEL as well. Writing down this mission certainly shouldn't inhibit individuals from achieving other goals at Harmony. But it would help the rest of community to concentrate on the common task. 1. http://wiki.apache.org/harmony/Platforms_to_Run_Harmony_Development_Kit_ on With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 10:36 AM To: harmony-dev@incubator.apache.org Subject: Re: [DRLVM] General stability 2006/11/8, Mikhail Fursov [EMAIL PROTECTED]: On 11/8/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Probably it's time to create some release plan :) So let's start this discussion? Good idea! The only release I can imagine is Harmony Java5SE 100% compatible. To be Java5SE 100% compatible we need TCK first. So we could think about some less impressive goal for the first release :) SY, Alexey
RE: [drlvm] building jitrino in release mode
As I reported at http://issues.apache.org/jira/browse/HARMONY-1969 I
succeeded by making two changes:
* Changed build.sh
* Needed to comment a fatal warning flag
But this was on SuSE, not Ubuntu.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 09, 2006 4:32 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] building jitrino in release mode
Well, I have problems. I was on a short trip this week - I'll be back
at home tomorrow morning, and can revisit...
geir
Mikhail Fursov wrote:
It looks very strange to me. I've just checked linux debug build with
the
only change in build.sh (replaced -Dvm.jitrino.cfg=releaase to -
Dvm.jitrino.cfg=debug) and debug version of library was built without
any
problems.
On 11/6/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Geir Magnusson Jr. wrote:
Alex Astapchuk wrote:
Geir Magnusson Jr. wrote:
I've been having some problems getting some test cases to
exhibit
misbehavior for DRLVM, and it turns out that jitrino is built in
release mode no matter what BUILD_CFG is set to.
Yes, this is a long-long story.
Was done as 'we-will-change-it-back-soon' thing, but remains till
this
moment. :-)
When I get it to build, I'll change it back today :)
Putting this inconsistency aside for a moment, how do I get
jitrino
to build in debug?
Here it is: http://tinyurl.com/yxjp4v
This are patches for jitrino.xml build.bat, the same change
(remove
-Dvm.jitrino.cfg=release) need to be done for build.sh as well.
k (I made the change in build.sh, as I never work on windows...).
I'll
look at jitrino.xml (I can't see your URL... I'm in a car at the
moment...)
If it helps, then here is the copy:
=
project name=vm.jitrino
-target name=init
+target name=init depends=common_vm
property name=build.depends
value=extra.apr,vm.vmcore,vm.encoder /
property name=outtype value=shared /
property name=libname value=jitrino /
@@ -48,7 +48,8 @@
patternset id=java.classes.pattern
includes=empty_pattern/
!-- the compiler doesn't extend common compiler --
-compiler name=${build.cxx} id=cpp.compiler
+compiler id=cpp.compiler extends=common.cpp.compiler
=
--
Thanks,
Alex
RE: [drlvm] release vs. debug
debug :) don't sweep the problems under the rug... +1 A special +1 for Jitrino.OPT dll -Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 7:17 PM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [drlvm] release vs. debug I would think it's just an assertion firing... Yes, but why it hangs? 2006/11/9, Geir Magnusson Jr. [EMAIL PROTECTED]: Alexei Zakharov wrote: Hi DRLVM fans, I encountered a rather strange problem while working on some class library tests. At least two tests from the beans module hang (or crash) while running on DRLVM debug builds but work fine on DRLVM release builds. I thought that debug build is something about adding debug symbols to VM binaries and this should not affect the functionality. Can someone shed a light on this? I would think it's just an assertion firing... This is the first question. The second question - what we should do with such tests. The tests pass on the downloadable HDK and JRE snapshots as well as on classlib + j9. What should be the commit criteria for DRLVM - i.e. what is the *true* build? :) I think many people here currently use snapshots to test their patches. debug :) don't sweep the problems under the rug... -- Alexei Zakharov, Intel Enterprise Solutions Software Division
RE: Re: [doc][drlvm] The document Getting started with DRL is outdated
Guys, I like good tutorials. I learned VIM using a tutorial. I don't need the VIM tutorial any longer, but at the beginning it was useful. +1 for maintain Getting Started as is with minor changes Why Eclipse was chosen for the tutorial? Our goal was to use Harmony for Harmony development. I liked that idea. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 1:29 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Pavel Ozhdikhin wrote: Nadya, One more proposal about Getting Started: let's remove all current content and write something like following: To the moment we got rid of all major differences from other Java implementations, so to use DRLVM you can just build it (here goes link to readme with build instructions) and run as any other Java VM. For commonly used command-line options please look into the Wiki page (link to Salikh's page or to the document). What do you think? 1 page to hold only 4 lines of text? :) Thanks, Pavel On 10 Nov 2006 14:29:59 +0600, Egor Pasko [EMAIL PROTECTED] wrote: On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Good day to you, Egor! evening, dark and snowy evening :) What do you say about the getting started doc? I expressed it recently. General idea is that Harmony operates near the same as other JSE implementations. Almost all specifics is in extra options which we started collecting on Wiki for an extra HOWTO-like page (BTW, thanks to Salikh for starting the page). I believe, it is time to remove the Getting Started. So, +1 to Pavel Ozhdikhin here. BTW, I asked my dad to look at the website. Ideas for improvement from him: 1) site-local search is useful for a beginner. Hm, Tomcat has it with links to google search. We can have something as soon as we get to the desired TLP :) 2) it is not obvious that site misprints/problems should be reported to the mailing list. Commercial websites have something like support/suggestions mailto. We can point mailto to the mailing list :) Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 8:55 AM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Egor, I generally like the idea of improving navigation over the site - there's never too much of that. However, I am not sure whether we need yet another separate page for introductory/guidance info. I hope the starting page + the generic pages we have are mostly fine. However, adding a link here and there to lead site visitors. Getting started could be a more specific project-oriented page. There, you can tell people to go linkdownload/link, linkbuild/link the code. After which, they can start using it just as any other linkRI-compatible/link jdk. With the exceptions, see our linkwiki/link pages. To use the vm, readers might need to use the following options... If they want to read more on our VM, they can visit the linkcomponent/link page. If no website page contains an answer - they can read linkwiki faqa/link. .. or something like that :) Nadya, I really appreciate our efforts :) But this morning I woke up and looked the site structure with the eye of a beginner. And could not find any obvius flaws in the main structure. Left-side collection of links is in a very good shape, good for beginner-level navigation and contains almost all links you listed here. This was a really refreshing morning :) I'll ask some guys who are new to the project, how they feel about the site. And will report back, if I find something. Refreshing morning is over, now back to work.. Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Thursday, November 09, 2006 5:33 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21C day of Apache Harmony Pavel Ozhdikhin wrote: On 11/9/06, Morozova, Nadezhda [EMAIL PROTECTED] wrote: Egor, +1 for Just idea: Getting Started may contain a collection of links to the main website and other resources with short descriptions (Site Map or something) so that people are comfortable floating around in the web. We already have one page having links to the resources about DRLVM: http://incubator.apache.org/harmony/subcomponents/drlvm/index.html
Please set a Patch available flag for H-1669 Was: [drlvm] [testing] Excluding commit tests until the problem is fixed
Elena, Could you please set Patch available flag for the following issue to attract committer's attention to this issue? http://issues.apache.org/jira/browse/HARMONY-1669 Classlib test tests/api/java/io/PipedInputStreamTest hangs on Windows 2003 (After the last JIRA configuration changes a submitter can edit her issues). With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Elena Semukhina [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 18, 2006 3:56 PM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] [testing] Excluding commit tests until the problem is fixed On 10/17/06, Gregory Shimansky [EMAIL PROTECTED] wrote: My 2003 server is installed on a single core P4 with HT. The test attached to HARMONY-1669 works fine for me both with and without patch :) I may get an access to dual core server as described in JIRA but I am afraid it will take a few days. Probably we can just apply the patch since it doesn't seem to do any harm. Indeed the attached test passes and PipedInputStream test passes being run separately now but when I ran the whole luni module, it hung. I applied the patch and it helped. 2006/10/17, Geir Magnusson Jr. [EMAIL PROTECTED]: Rana Dasgupta wrote: On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: So since I don't have Win 2003, I gotta just commit and let someone else test? Any committer have win 2003? I think that it may be hard to find a test at this point that fails on Windows Server 2003, but passes on XP. But perf etc. characteristics will be different. At some point, gc_v5 etc. is likely to have server specific variations, eg., parallel gc may be on server only. Are we talking of tests in general? I am sorry, but I may not have understood the comment. There is a test that demonstrates a Win 2003 bug... I can just commit it and let someone confirm since I don't have a win 2003 machine geir -- Gregory Shimansky, Intel Middleware Products Division -- Thanks, Elena
RE: [drlvm][unit] 100% of class library tests pass
Pavel, All, Let me add one pro for the second approach: it works already. Vladimir's scripts daily upload test results to http://harmonytest.org. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, November 16, 2006 12:37 PM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm][unit] 100% of class library tests pass Pavel Ozhdikhin wrote: We have to evolving systems - classlib and DRLVM. To check commits to classlib we need a stable DRLVM which can pass 100% of HUT. Otherwise it's impossible to use DRLVM for pre-commit testing - you never know whether your test fail because of your patch or due to latest changes in DRLVM. I remember the time when DRLVM and Jitrino actively evolved - for some time JIT had to use an older version of DRLVM which could pass all commit criteria because newer versions suffered from regressions. And finally we came to comon strict commit criteria which prevented regressions in both VM and JIT. To avoid regressions using DRLVM in classlib testing I see 3 possible solutions: 1. Use one fixed DRLVM version which can pass 100% HUT test. Update this version from time to time. Pros: + Less time to run DRLVM pre-commit tests + Classlib does not suffer from regressions in DRLVM Cons: - DRLVM will suffer from regressions - Classlib can not use the latest DRLVM - Need additional efforts to regain stability on DRLVM when we want to update the version for classlib testing 2. Add HUT to CruiseControl testing on DRLVM and rollback commits causing regressions Pros: + Less time to run DRLVM pre-commit tests + Classlib can use the latest DRLVM Cons: - Classlib can suffer from DRLVM regressions (time lag before rollback) - It is not always clear which commit caused a regression - Rollbacks are costly 3. Add HUT to the commit criteria for DRLVM Pros: + Classlib always can use the latest DRLVM + DRLVM has no regressions regarding to HUT Cons: - More time to run DRLVM pre-commit tests (I was told that HUT take 25 minutes running in single JVM mode) I think that preventing a problem is better than solving it afterwards. So, I personally would choose the 3rd approach, don't mind against the second and dislike the first one. Probably some combination of these is possible. While I appreciate the desire to keep things stable, I think it is unreasonable to ask developers to run the entire test suite each time. As we have seen in the classlib code, running targeted tests before commit and leaving the build machines to run continuous tests ensures that we are productive and are notified of breakages in time to easily back out a patch and re-evaluate. With the amount of machine time we have running harmony tests on different cpu's/os's/compilers/etc we are getting better coverage than any individual could be expected to provide. Which is a long way of saying I think option (2) above is best -- and relies on the bid machines letting us know if things break, and the commitment from all of us to go straight in and fix it. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
RE: [drlvm][unit] 100% of class library tests pass
Geir wrote, I'd prefer if we didn't spam the lists with every good result Ok, the alternative which comes to my mind next is the following. If I understand correctly, Anton's site gets uploaded zip archives, processes them and populates a database. From the outside we can see result sets for database selections. Anton, If you add a possibility to browse and download uploaded archives, this would help to detect problems from the outside. One can compare uploaded archives and selection results. The only possible problem is if you don't keep archives after they are processed. I don't think we should keep them for long either. I think this worth to be done if you found this useful for debug feature for yourself. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Friday, November 17, 2006 3:05 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm][unit] 100% of class library tests pass Alexei Fedotov wrote: Pavel, The life started showing that you were correct. Today there were no report on http://harmonytest.org. Even if I would like to be a living notification, I couldn't. Vladimir, The thing which concerns me most is not an absence of results - I believe this is just a technical problem. For me the main problem is that without you there is no way to understand what happens. I don't understand that. The goal here is to establish the build-test framework as the thing that everyone uses- we aren't dependent only upon Vladimir. I'll have a version running on 64-bit ubuntu whenever it works, and probalby 32-bit as well reporting in... Can we made a process of reporting more open? For example, can we tune CC to send a notification on upload status? If there is a successful notification, then the file is uploaded successfully, and we need to ask Anton why it is not visible. Otherwise we'll know the problem is in CC. Um. I'd prefer if we didn't spam the lists with every good result - we only want to know when there's breakage or fixage. geir Thanks! On 11/16/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: Sorry to say but it actually does not work until there is no notifications to the mailing list and no immediate reaction to the regressions. thanks, Pavel On 11/16/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: Pavel, All, Let me add one pro for the second approach: it works already. Vladimir's scripts daily upload test results to http://harmonytest.org. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, November 16, 2006 12:37 PM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm][unit] 100% of class library tests pass Pavel Ozhdikhin wrote: We have to evolving systems - classlib and DRLVM. To check commits to classlib we need a stable DRLVM which can pass 100% of HUT. Otherwise it's impossible to use DRLVM for pre-commit testing - you never know whether your test fail because of your patch or due to latest changes in DRLVM. I remember the time when DRLVM and Jitrino actively evolved - for some time JIT had to use an older version of DRLVM which could pass all commit criteria because newer versions suffered from regressions. And finally we came to comon strict commit criteria which prevented regressions in both VM and JIT. To avoid regressions using DRLVM in classlib testing I see 3 possible solutions: 1. Use one fixed DRLVM version which can pass 100% HUT test. Update this version from time to time. Pros: + Less time to run DRLVM pre-commit tests + Classlib does not suffer from regressions in DRLVM Cons: - DRLVM will suffer from regressions - Classlib can not use the latest DRLVM - Need additional efforts to regain stability on DRLVM when we want to update the version for classlib testing 2. Add HUT to CruiseControl testing on DRLVM and rollback commits causing regressions Pros: + Less time to run DRLVM pre-commit tests + Classlib can use the latest DRLVM Cons: - Classlib can suffer from DRLVM regressions (time lag before rollback) - It is not always clear which commit caused a regression - Rollbacks are costly 3. Add HUT to the commit criteria for DRLVM Pros: + Classlib always can use the latest DRLVM + DRLVM has no regressions regarding to HUT Cons: - More time to run DRLVM pre-commit tests (I was told that HUT take 25 minutes running in single JVM mode) I think that preventing a problem is better than solving it afterwards. So, I personally would choose the 3rd approach, don't mind against the second and dislike the first
RE: [drlvm][unit] New regression? org.apache.harmony.auth.tests.javax.security.auth.kerberos.serialization.KrbDelegationPermissionCollectionTest
DRLVM, Failed 3 times from 6 test runs With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Friday, November 17, 2006 7:00 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm][unit] New regression? org.apache.harmony.auth.tests.javax.security.auth.kerberos.serializatio n.Kr bDelegationPermissionCollectionTest what VM? Alexei Fedotov wrote: Folks, Has anyone seen the following problem in the whole test run? I cannot reproduce the problem for standalone test. (SuSE 9) testcase classname=org.apache.harmony.auth.tests.javax.security.auth.kerberos.s eria lization.KrbDelegationPermissionCollectionTest name=testGolden time=0.047 error type=java.io.IOExceptionjava.io.IOException at java.io.IOException.lt;initgt;(IOException.java:35) at org.apache.harmony.luni.platform.OSFileSystem.close(OSFileSystem.java:2 03) at java.io.FileInputStream.close(FileInputStream.java:174) at org.apache.harmony.nio.internal.FileChannelImpl.implCloseChannel(FileCh anne lImpl.java:102) at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterr upti bleChannel.java:98) at java.io.FileInputStream.close(FileInputStream.java:167) at java.io.FilterInputStream.close(FilterInputStream.java) at java.io.BufferedInputStream.close(BufferedInputStream.java:121) at java.io.FilterInputStream.close(FilterInputStream.java) at java.io.ObjectInputStream.close(ObjectInputStream.java) at org.apache.harmony.testframework.serialization.SerializationTest.getObj ectF romStream(SerializationTest.java:201) at org.apache.harmony.testframework.serialization.SerializationTest.getObj ect( SerializationTest.java:520) at org.apache.harmony.testframework.serialization.SerializationTest.verify Gold en(SerializationTest.java:428) at org.apache.harmony.testframework.serialization.SerializationTest.verify Gold en(SerializationTest.java:402) at org.apache.harmony.testframework.serialization.SerializationTest.testGo lden (SerializationTest.java:146) at java.lang.reflect.VMReflection.invokeMethod(Native Method) at org.apache.harmony.testframework.serialization.SerializationTest.runBar e(Se rializationTest.java:111) /error /testcase
RE: [general] Announcing Melody
Great! I like the pictures. Sorry for a dumb question, does CruiseControl actually work, or is it a site design sketch? With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: Friday, November 17, 2006 4:04 AM To: harmony-dev@incubator.apache.org Subject: [general] Announcing Melody I'm proud to announce Melody, a testing dashboard for Harmony. Melody is currently hosted in Geir's office at the currently transient URL http://67.86.14.213:1/ My goal is to move part of this into the Harmony zone. The main feature of Melody is a graphical history, which is automatically generated every night out of fresh data. The past has been 'reconstructed' by taking a snapshot of harmony every week over the entire history of the project, compile it and running the latest japitools over it. I also run japitools without the checks for the SerialUI checks which generate a lot of false positives for Swing stuff. Plans for the future include: 1) add a chart for the number of subscribers to the various lists (I already have a script for this, but I need somebody with apmail karma to run it on the apache machine that handles our mail) 2) add a chart for email traffic 3) start performing static analysis on the code using tools like findbugs, PMD and CPD Comments, suggestions and criticism welcome! -- Stefano.
