that stack related are not run...)
>
> kernel :
>
> w/ jet
>
> [junit] Test java.lang.ClassAnnotationsTest FAILED
> [junit] Test java.lang.reflect.FieldTest FAILED
> [junit] Test org.apache.harmony.lang.annotation.AllTypesTest FAILED
>
>
> w/ opt
>
>
I'll throw up a wiki page on this, but here's where we are now. I
committed H-2224, which excluded stack tests on x86_64 (and LOS on windows)
c-unit tests : pass
smoke : pass (now that stack related are not run...)
kernel :
w/ jet
[junit] Test java.lang.ClassAnnotationsT
I put a wiki page up :
http://wiki.apache.org/harmony/Automated_Testing
(reachable from the front page) to capture how we track and govern the
"community CI" effort that build-test is intended to be.
So I didn't set out any rules other than someone who's interested h
e
observed
>> > yesterday, I filed a
http://issues.apache.org/jira/browse/HARMONY-2204
>> > issue
>> > for that. I saw this failure quite long ago but cannot reproduce it
>> today
>> > trying different platforms/EMs. When the test failed, it reported
yesterday, I filed a
http://issues.apache.org/jira/browse/HARMONY-2204
>> > issue
>> > for that. I saw this failure quite long ago but cannot reproduce it
>> today
>> > trying different platforms/EMs. When the test failed, it reported
that
>> > actual wait
this failure quite long ago but cannot reproduce it
today
> trying different platforms/EMs. When the test failed, it reported that
> actual wait time is less than required.
>
> The spec for join() reads: "Waits at most millis milliseconds plus
> nanosnanoseconds for this thread to
y.dir has a bad value for some reason. This property is set
up in build.xml I believe. Running ant -d may help to see the value that
it has, and the compiler command line which it uses for compiling JVMTI
test.
Vladimir Ivanov wrote:
My CC report a problem in the drlvm module. Could somebody repr
My CC report a problem in the drlvm module. Could somebody reproduce/ fix
it?
Thanks, Vladimir
[exec] compile-jvmti-tests-native:
[exec] [echo] ## Compiling JVMTI natives in:
C:\harm_cc\buildtest\trunk\cc\projects\drlvm\trunk\vm\tests\jvmti\VMInit1
[exec][cc] 1 total fil
ong ago but cannot reproduce it
today
> trying different platforms/EMs. When the test failed, it reported that
> actual wait time is less than required.
>
> The spec for join() reads: "Waits at most millis milliseconds plus
> nanosnanoseconds for this thread to die. " There is an
+1 go for it
On 11/16/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Well the subject line was build-test (not the actual directory name) and
you talk about the testing framework -- so just being clear that you are
not talking about the JUnit test suites/structure.
Regards,
Tim
Geir Magnus
Well the subject line was build-test (not the actual directory name) and
you talk about the testing framework -- so just being clear that you are
not talking about the JUnit test suites/structure.
Regards,
Tim
Geir Magnusson Jr. wrote:
> Just curious... what else could it be?
>
&g
Just curious... what else could it be?
Weldon Washburn wrote:
On 11/16/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Just to be clear that you are referring to moving [1] from enhanced to
standard? If I understood that right, then +1.
+1, same assumptions as Tim.
[1] http://svn.apache.org/vi
On 11/16/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Just to be clear that you are referring to moving [1] from enhanced to
standard? If I understood that right, then +1.
+1, same assumptions as Tim.
[1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/buildtest/
Regards,
Tim
Geir
Tim Ellison wrote:
> Just to be clear that you are referring to moving [1] from enhanced to
> standard? If I understood that right, then +1.
>
> [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/buildtest/
+1 as well
>
> Regards,
> Tim
>
> Geir Magnusson Jr. wrote:
>> Does anyone ca
Elena Semukhina wrote:
As Gregory mentioned ThreadTest.testJoinlongint() failure he observed
yesterday, I filed a http://issues.apache.org/jira/browse/HARMONY-2204
issue
for that. I saw this failure quite long ago but cannot reproduce it today
trying different platforms/EMs. When the test
e when I saw exactly this
> sutiation few days ago; I just had no time to speak up. We definitely
> should fix this.
I fixed it in r475714.
Now whether you are running a single module's tests or the 'global'
classlib test target there will be a build failure shown if any J
As Gregory mentioned ThreadTest.testJoinlongint() failure he observed
yesterday, I filed a http://issues.apache.org/jira/browse/HARMONY-2204 issue
for that. I saw this failure quite long ago but cannot reproduce it today
trying different platforms/EMs. When the test failed, it reported that
2006 15:51 Elena Semukhina wrote:
>> > > On 10/26/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
>> > > > After H-1823 has been committed, I still see intermittent
failures
>> of
>> > > > drlvm kernel ThreadTest. Normally this test passes but today I
Just to be clear that you are referring to moving [1] from enhanced to
standard? If I understood that right, then +1.
[1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/buildtest/
Regards,
Tim
Geir Magnusson Jr. wrote:
> Does anyone care? This way, we can be freer about who and what g
+1
2006/11/16, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
Does anyone care? This way, we can be freer about who and what goes in
there.
Since we don't ship the testing frameworks with anything, this is
completely consistent with our IP policies and goals.
geir
2006/11/16, Tim Ellison <[EMAIL PROTECTED]>:
Rana Dasgupta wrote:
> I think that a problem with the junit tests is that some failures spit out
> to the console, but show up in the test run results as passed. I find this
> very confusing. So unless you are watching all the time, yo
Does anyone care? This way, we can be freer about who and what goes in
there.
Since we don't ship the testing frameworks with anything, this is
completely consistent with our IP policies and goals.
geir
Rana Dasgupta wrote:
> I think that a problem with the junit tests is that some failures spit out
> to the console, but show up in the test run results as passed. I find this
> very confusing. So unless you are watching all the time, you can miss them.
Hmm, this doesn't sound ri
er H-1823 has been committed, I still see intermittent failures
of
> > > drlvm kernel ThreadTest. Normally this test passes but today I got
> > > ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked()
failures.
> > > There is H-1789 for the first issue but it is not reprodiced
ber 2006 15:51 Elena Semukhina wrote:
> > On 10/26/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
> > > After H-1823 has been committed, I still see intermittent failures
of
> > > drlvm kernel ThreadTest. Normally this test passes but today I got
> > > ThreadTest.
2006/11/14, Gregory Shimansky <[EMAIL PROTECTED]>:
On Monday 13 November 2006 15:51 Elena Semukhina wrote:
> On 10/26/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
> > After H-1823 has been committed, I still see intermittent failures of
> > drlvm kernel ThreadTest
On Monday 13 November 2006 15:51 Elena Semukhina wrote:
> On 10/26/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
> > After H-1823 has been committed, I still see intermittent failures of
> > drlvm kernel ThreadTest. Normally this test passes but today I got
> > Thread
On 10/26/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
After H-1823 has been committed, I still see intermittent failures of
drlvm kernel ThreadTest. Normally this test passes but today I got
ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked() failures.
There is H-1789 for the
sts, I would suggest removing
smoke/classloader/ClassTestGetDeclaringClass as it is exact copy of kernel
test with the same name.
Also, smoke/classloader/ExceptionInInitializerTest must be returned to
acceptance runs.
Pavel.
On 10/25/06, Volynets, Vera <[EMAIL PROTECTED]> wrote:
>
>
In addition to excluding some tests, I would suggest removing
smoke/classloader/ClassTestGetDeclaringClass as it is exact copy of kernel
test with the same name.
Also, smoke/classloader/ExceptionInInitializerTest must be returned to
acceptance runs.
Pavel.
On 10/25/06, Volynets, Vera <[EM
I've reverted my changes and put the whole test back to the exclude list.
Thanks,
2006/11/8, Tim Ellison <[EMAIL PROTECTED]>:
Stepan Mishura wrote:
> Hi Alexei,
>
> Sorry, I don't understand your logic. Is the test case valid? If there was
> another bug (for examp
n DRLVM for those tests in debug?
I don't recall seeing any discussion here...
geir
Alexei Zakharov wrote:
> Eventually we get more and more arguments to start doing test grouping
> somehow. TestNG, JUnit TestSuites or whatever but be we definitely
> need it. And sooner is better.
&
That's fine.
Do we know what the problems are in DRLVM for those tests in debug?
I don't recall seeing any discussion here...
geir
Alexei Zakharov wrote:
Eventually we get more and more arguments to start doing test grouping
somehow. TestNG, JUnit TestSuites or whatever but be we
Eventually we get more and more arguments to start doing test grouping
somehow. TestNG, JUnit TestSuites or whatever but be we definitely
need it. And sooner is better.
Regards,
2006/11/9, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
Alexei Zakharov wrote:
> Let me rephrase my question
Gregory Shimansky wrote:
Ok I see now. I was just worried that it is something wrong with files
being locked undeletable.
Should continuum ignore this clean warning and try once more if it
happens instead of reporting build failure?
yes
Tim Ellison wrote:
Gregory Shimansky wrote:
I've
Alexei Zakharov wrote:
Let me rephrase my question a little bit. What should we do in this
particular case when some test passes on J9 and HDK (DRLVM with
BUILD_CFG=release) and fails/crashes on DRLVM with BUILD_CFG=debug? I
have two examples of such tests already.
1) Fix DRLVM.
2
Ok I see now. I was just worried that it is something wrong with files
being locked undeletable.
Should continuum ignore this clean warning and try once more if it
happens instead of reporting build failure?
Tim Ellison wrote:
Gregory Shimansky wrote:
I've seen the same failure of clean targ
Gregory Shimansky wrote:
> I've seen the same failure of clean target several times. Does anyone know
> why
> it happens? When I run clean again, it usually succeeds. The failure is 100%
> reproducible, clean usually works, but sometimes finds some files which
> weren't deleted.
We decided tha
Let me rephrase my question a little bit. What should we do in this
particular case when some test passes on J9 and HDK (DRLVM with
BUILD_CFG=release) and fails/crashes on DRLVM with BUILD_CFG=debug? I
have two examples of such tests already.
Thanks,
2006/11/9, Alexei Zakharov <[EMAIL PROTEC
solution I have chosen is not the best one. So I am open for
proposals here. Should we exclude the whole test? In my opinion DRLVM
is not just "another_VM" - it is something we should care about. IMHO.
Thanks,
2006/11/8, Tim Ellison <[EMAIL PROTECTED]>:
Stepan Mishura wr
Should we pull it out then? More test good!
Rana Dasgupta wrote:
On 11/5/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>>On 11/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>> first, can we also use this test for gcv4.1?
>>
Yes. The test is a
Hello
I've seen the same failure of clean target several times. Does anyone know why
it happens? When I run clean again, it usually succeeds. The failure is 100%
reproducible, clean usually works, but sometimes finds some files which
weren't deleted.
On Wednesday 08 November 2006 22:05 [EMAIL
Stepan Mishura wrote:
> Hi Alexei,
>
> Sorry, I don't understand your logic. Is the test case valid? If there was
> another bug (for example: "[another_VM][unit] half of classlib beans tests
> crashes VM"), would you agree to comment out a half of beans tests?
Than
Hi Alexei,
Sorry, I don't understand your logic. Is the test case valid? If there was
another bug (for example: "[another_VM][unit] half of classlib beans tests
crashes VM"), would you agree to comment out a half of beans tests?
Thanks,
Stepan.
-Original Message---
On 11/5/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>>On 11/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>> first, can we also use this test for gcv4.1?
>>
Yes. The test is a Java test. The reason I placed it in gc_gen is that it is
intend
On 11/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
first, can we also use this test for gcv4.1?
Second, shouldn't you test now to make sure that all is well? It will
be much harder to figure out later...
Rana, Xiao Feng,
Please test. I am not building GCv5 right now.
ge
first, can we also use this test for gcv4.1?
Second, shouldn't you test now to make sure that all is well? It will
be much harder to figure out later...
geir
weldon washburn (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-1993?page=all ]
weldon washburn closed HA
I'll check on 1830. Somehow the JIRA dropped my comments! I was debugging on
Windows since that was the original bug report.
An exception may be OK, since this is a resource intensive test, but it
should not crash when handling the exception. That part should have been
fixed. Also, we need t
I have a different problem with 1830 on
linux - after 160 iterations or so of the test program, I get a
j.n.SocketException - too many open files...
geir
Thanks,
Rana
On 10/25/06, Volynets, Vera <[EMAIL PROTECTED]> wrote:
Geir
Some tests launched by command "build test" f
chedule
> Exit code: 1
> Building machine hostname: hy2
> Operating system : Linux(unknown)
> Java version : 1.5.0_06(Sun Microsystems Inc.)
>
> Changes
>
> classlib/modules/beans/src/test/resources/serialization/java/beans/beancontext
AIL PROTECTED]> wrote:
Geir
Some tests launched by command "build test" fail.
The idea of "build test" is to run it before each commit. In this way you
can catch regressions.
In order to effectively catch regressions, i.e. tests that started to fail
after some change,
it'
Thanks, it fixed now.
Thanks, Vladimir
On 11/2/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
Fixed at r470318. Please verify.
-Stepan.
On 11/2/06, Vladimir Ivanov wrote:
>
> Could somebody look at new unit test failure (winXP, j9):
> Test: testGenKe
Fixed at r470318. Please verify.
-Stepan.
On 11/2/06, Vladimir Ivanov wrote:
Could somebody look at new unit test failure (winXP, j9):
Test: testGenKey_keyPair Class:
org.apache.harmony.tools.keytool.tests.GenKeyTest
junit.framework.AssertionFailedError: Cannot create a temporary file
C
Could somebody look at new unit test failure (winXP, j9):
Test: testGenKey_keyPair Class:
org.apache.harmony.tools.keytool.tests.GenKeyTest
junit.framework.AssertionFailedError: Cannot create a temporary file
C:\DOCUME~1\vivanov1\LOCALS~1\Temp\\GenKeyTestTemporaryFile. File with such
name
:)
cool
Anton Luht wrote:
Hello,
Queue appeared to be a stack :) Both requests are implemented, others
are pending.
On 11/1/06, Anton Luht <[EMAIL PROTECTED]> wrote:
Feature requests from Geir (multiple select for tags) and Alexey
(shortcut to compare two runs from the first page) are accept
n: java.lang.ClassGenericsTest$Mc009^Z^Z^Z
>> java.lang.NoClassDefFoundError: java/lang/ClassGenericsTest$Mc007^Z
>> java.lang.TypeNotPresentException: Type
>> java.lang.ClassGenericsTest$Mc009\0d5\0b6\0db\080\0db\0b1 not present
>>
>> For java.lang.ClassGenericsTest4:
>>
>> Some N
Hello,
Queue appeared to be a stack :) Both requests are implemented, others
are pending.
On 11/1/06, Anton Luht <[EMAIL PROTECTED]> wrote:
Feature requests from Geir (multiple select for tags) and Alexey
(shortcut to compare two runs from the first page) are accepted and
put in the implemetati
Feature requests from Geir (multiple select for tags) and Alexey
(shortcut to compare two runs from the first page) are accepted and
put in the implemetation queue.
--
Regards,
Anton Luht,
Intel Java & XML Engineering
2006/11/1, Anton Luht <[EMAIL PROTECTED]>:
Alexey,
> 1) allow to compare by exact id - e.g. I failed to compare #90 and #91
> due to missing tags.
First, you can obtain login (ask any registered user to add you) and
tag runs you are interested in.
Still I have to do extra steps while searching
Anton Luht wrote:
Alexei,
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 co
: 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
Alexey,
1) allow to compare by exact id - e.g. I failed to compare #90 and #91
due to missing tags.
First, you can obtain login (ask any registered user to add you) and
tag runs you are interested in.
Second - you can do it if you enter two result ids into URL:
http://harmonytest.org/diff.do
Alexei,
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
ilto:[EMAIL PROTECTED]
>Sent: Wednesday, November 01, 2006 9:40 AM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [classlib][swing][test] Excluded tests clean up
>
>Alexey,
>
>I'll take a look.
>
>SY, Alexey
>
>2006/10/20, Ivanov, Alexey A <[EMAIL PROTECTED
Anton,
Nice feature indeed, many thanks.
Please also consider the following:
1) allow to compare by exact id - e.g. I failed to compare #90 and #91
due to missing tags.
2) add filtering by tags on the main page - e.g. to see only drl or
only linux results.
2006/10/31, Anton Luht <[EMAIL PROTECT
Alexey,
I'll take a look.
SY, Alexey
2006/10/20, Ivanov, Alexey A <[EMAIL PROTECTED]>:
Hello,
I am working to clean up the excluded list and to make all the tests
run-able without failures.
I've created several JIRA issues.
https://issues.apache.org/jira/browse/HARMONY-1825
https://issues.ap
Tim Ellison wrote:
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?
Indeed... DRL is Apache Ha
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 PROTE
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
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
on of young
objects, so our algo is great. We can tune nursery size to some extent I
think.
But, better codegen is the key :-)
Rana
On 10/31/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
Rana,
With a helper inlined we have significantly better results in your
synthetic
test. I think we can
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=view&id=72&id2=80&perPage=10"
2. This can be used to compare our results against RI when the quali
Hello, Alexei, Vladimir and others:
Please enjoy the new runs comparing functionality:
http://harmonytest.org/diff.do?method=view&id=72&id2=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
Rana,
With a helper inlined we have significantly better results in your synthetic
test. I think we can outperform SUN here if we add some very primitive loop
optimizations into the JIT for TLS. I mean moving hythread_self out of the
loop as it's already done for BBP.
ps.
Well, the list of
thod=showrun&id=80.
I've noticed that the following tests are absent in DRLVM test run. Do
you have any thoughts why they are missed?
org.apache.harmony.luni.tests.java.lang.SystemTest
org.apache.harmony.luni.tests.java.lang.ThreadDeathTest
org.apache.harmony.lu
Vladimir,
I compared http://harmonytest.org/testapp.do?method=showrun&id=72 and
http://harmonytest.org/testapp.do?method=showrun&id=80.
I've noticed that the following tests are absent in DRLVM test run. Do
you have any thoughts why th
gs has been fixed [1], but the other was
> closed awaiting more information [2], but may be resolved as well.
>
> The fix should be available to test from a nightly build of the
> Eclipse 3.3 stream. Would someone like to verify that the discussed
> issues are resolved?
Nathan, I'
2006/10/30, Nathan Beyer <[EMAIL PROTECTED]>:
I see that one of the ECJ bugs has been fixed [1], but the other was
closed awaiting more information [2], but may be resolved as well.
The fix should be available to test from a nightly build of the
Eclipse 3.3 stream. Would someone like to
I see that one of the ECJ bugs has been fixed [1], but the other was
closed awaiting more information [2], but may be resolved as well.
The fix should be available to test from a nightly build of the
Eclipse 3.3 stream. Would someone like to verify that the discussed
issues are resolved
It's already done. I'll put it to JIRA on Monday.
On 10/29/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
As I can see we are far behind stock java implementation. This can
change after fast path for object allocation gets implemented.
Looking at the data received from stack java, I see that it i
, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
Hi,
I ran a simple test that allocates and discards a large number of objects
repeatedly on multiple threads. These should all be gen zero objects( none
survive ) that are repeatedly collected. So the test is of effective
allocation rate( I set hea
Rana, this would be very useful for us to understand the GC behavior.
Thanks for this.
There is a synthesis benchmark GCold that can be also used for this
study. We were using it for a while.
Thanks,
xiaofeng
On 10/28/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
Hi,
I ran a simple tes
Hi,
I ran a simple test that allocates and discards a large number of objects repeatedly on multiple threads. These should all be gen zero objects( none survive ) that are repeatedly collected. So the test is of effective allocation rate( I set heap size for all the gc's to 64M and 256 M
Error: java/lang/ClassGenericsTest$Mc007^Z
>> java.lang.TypeNotPresentException: Type
>> java.lang.ClassGenericsTest$Mc009\0d5\0b6\0db\080\0db\0b1 not present
>>
>> For java.lang.ClassGenericsTest4:
>>
>> Some NPEs from unobvious sources. I've attached two test reports
On the 0x20E day of Apache Harmony Mark Hindess wrote:
> Anyone else seeing:
try -Xem:jet and -Xem:opt here, please. They have different
implementations of 'arraycopy' which is probably critical here...
> testDateEditor_formatter Error N/A
>
> java.lang.ArrayIndexOutOfBoundsException
>
ally "en_US.UTF-8", but
I found "en_AU.UTF-8" on oner server).
I experimented a bit with this stuff and found out that these tests work
ok when locale is some sort of UTF-8 one, including ru_RU.UTF-8 one.
The result of test run is actually affected by locale set at compil
java.lang.ClassGenericsTest4:
Some NPEs from unobvious sources. I've attached two test reports to this
email. Anyways, it looks like timeout is not the case for these tests
failures.
Ok I think I've found the cause of problems with these two tests on
Linux which I had yesterday. On Gentoo I have russian
gupta wrote:
The ideal way would be for acceptance tests like "build test" to always
pass
and to catch and roll back the patch that breaks this invariant, rather
than
to disable the tests. But I agree with Vera, it is important to keep a
running set up as acceptance tests, so disabling
Volynets, Vera wrote:
Geir
Some tests launched by command "build test" fail.
The idea of "build test" is to run it before each commit. In this way you can
catch regressions.
Yes, that is what I do
In order to effectively catch regressions, i.e. tests that started
<[EMAIL PROTECTED]> wrote:
On 10/26/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>
> Elena Semukhina wrote:
> > After H-1823 has been committed, I still see intermittent failures of
> drlvm
> > kernel ThreadTest. Normally this test passes but today I got
>
No problem, that shows just how useful test coverage tools may be.
Best regards,
Gabriel.
2006/10/20, Ivanov, Alexey A <[EMAIL PROTECTED]>:
Gabriel,
See another thread for the answer:
http://thread.gmane.org/gmane.comp.java.harmony.devel/16591/focus=16591
Thanks for noticing that.
R
First of all, please excuse my late reply, Vladimir.
Right now I'm working in the tests for the implementation of jx.s.t.h.p.Parser,
but here we are using a different code coverage tool, which is Clover, sorry :)
When I found your post at harmony-dev, I realized that none of that tests were
com
Anyone else seeing:
testDateEditor_formatterError N/A
java.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(System.java:327)
at java.lang.System.arraycopy(System.java:237)
at com.ibm.icu.text.DigitList.set(DigitList.java:551)
at com.ibm.icu.text.DecimalFormat.f
t; Elena Semukhina wrote:
> > After H-1823 has been committed, I still see intermittent failures of
> drlvm
> > kernel ThreadTest. Normally this test passes but today I got
> > ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked() failures.
> > There is H-1789 for the
On 10/26/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Elena Semukhina wrote:
> After H-1823 has been committed, I still see intermittent failures of
drlvm
> kernel ThreadTest. Normally this test passes but today I got
> ThreadTest.testInterrupt_Sleeping() and testGetStateBlo
Elena Semukhina wrote:
After H-1823 has been committed, I still see intermittent failures of drlvm
kernel ThreadTest. Normally this test passes but today I got
ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked() failures.
There is H-1789 for the first issue but it is not reprodiced
n run this code fine, I'd be surprised if
>> this is considered a bug. I've been surprised before though. :)
>
>
> The test I submitted to Eclipse bugzilla fails on RI, IBM VM and DRLVM when
> compiled with ECJ and passes being compiled with javac.
>
> The fix su
increases
PASSED
Evgueni
On 10/26/06, Volynets, Vera <[EMAIL PROTECTED]> wrote:
>
>
> -Original Message-
> From: Pavel Ozhdikhin [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 26, 2006 10:18 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [drlvm][test]
dikhin [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 26, 2006 10:18 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm][test]Exclude some tests from "build test" target,
make 'build test' pass
On 10/26/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>
> O
-Original Message-
From: Pavel Ozhdikhin [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 26, 2006 10:18 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm][test]Exclude some tests from "build test" target,
make 'build test' pass
On 10/26/06, Grego
1 - 100 of 1204 matches
Mail list logo
