To reduce Harmony VM (DRLVM) is possible - and not very difficult. JIT
and GC are modules that you can easily replace with very simple ones.
Other modules can be largely reduced as well if you do not need them,
e.g., threading, verifier, profiler, etc. I don't know your
performance target, but my
Tim,
As for your willingness to create a lib, VM is a lib already [1], an
is successfully used in browser plug-ins.
[1] http://java.sun.com/j2se/1.4.2/docs/guide/jni/spec/invocation.html
On Mon, Nov 23, 2009 at 11:54 AM, Xiao-Feng Li xiaofeng...@gmail.com wrote:
To reduce Harmony VM (DRLVM) is
Looks like the commit at r882798 is causing some pack200 tests to fail:
org.apache.harmony.pack200.tests.ArchiveTest.testSQL
org.apache.harmony.pack200.tests.ArchiveTest.testStripDebug
org.apache.harmony.pack200.tests.ArchiveTest.testPassFiles
On 23/Nov/2009 15:36, Oliver Deakin wrote:
Looks like the commit at r882798 is causing some pack200 tests to fail:
org.apache.harmony.pack200.tests.ArchiveTest.testSQL
org.apache.harmony.pack200.tests.ArchiveTest.testStripDebug
org.apache.harmony.pack200.tests.ArchiveTest.testPassFiles
Yup; my bad. I can roll it back.
On Mon, Nov 23, 2009 at 7:36 AM, Oliver Deakin oliver.dea...@googlemail.com
wrote:
Looks like the commit at r882798 is causing some pack200 tests to fail:
org.apache.harmony.pack200.tests.ArchiveTest.testSQL
Cool, thanks Jesse!
Regards,
Oliver
Jesse Wilson wrote:
Yup; my bad. I can roll it back.
On Mon, Nov 23, 2009 at 7:36 AM, Oliver Deakin oliver.dea...@googlemail.com
wrote:
Looks like the commit at r882798 is causing some pack200 tests to fail:
Rolled back as r883400. I'll investigate the Pack200 test problems and push
this back in after code freeze.
That's fixed the failures for me. I'll do a full test rerun and post the
results here when it's complete.
Regards,
Oliver
Jesse Wilson wrote:
Rolled back as r883400. I'll investigate the Pack200 test problems and push
this back in after code freeze.
--
Oliver Deakin
Unless stated
Code freeze. No commits without a second committer's agreement until
the milestone is declared. Including excluded tests.
The goal is to ensure we have a stable codebase on which we are all testing.
The freeze is also an incentive for everyone to help with the testing
and get the milestone
On Mon, Nov 23, 2009 at 8:40 AM, Jesse Wilson jessewil...@google.comwrote:
Rolled back as r883400. I'll investigate the Pack200 test problems and push
this back in after code freeze.
FYI: The root problem is a bug in our ZIP decoding. It fails to cope with
Z_SYNC_FLUSH blocks and crashes.
My bad for committing during the code freeze.
Does it make sense to limit test changes during the code freeze? I don't see
any benefit.
On 23/11/2009, Jesse Wilson jessewil...@google.com wrote:
On Mon, Nov 23, 2009 at 8:40 AM, Jesse Wilson jessewil...@google.comwrote:
Rolled back as r883400. I'll investigate the Pack200 test problems and push
this back in after code freeze.
FYI: The root problem is a bug in our ZIP
On Mon, Nov 23, 2009 at 12:45 PM, sebb seb...@gmail.com wrote:
FYI:
I can open the jar using the RI jar application on WinXP, but Winzip
9.0 complains.
On people.apache.org the jar tool works but UnZip 6.00 reports:
6 extra bytes at beginning or within zipfile
(attempting to process
I'd like to request approval to revert the changes in r823479 that were
for an optimization in the archive code, but cause a regression in rmi.
This is the proposed fix for HARMONY-6381.
Regards,
Tim
+1
-Mark.
In message 4b0b0812.9070...@gmail.com, Tim Ellison writes:
I'd like to request approval to revert the changes in r823479 that were
for an optimization in the archive code, but cause a regression in rmi.
This is the proposed fix for HARMONY-6381.
Regards,
Tim
Committed at r883524.
On 23/Nov/2009 22:10, Mark Hindess wrote:
+1
-Mark.
In message 4b0b0812.9070...@gmail.com, Tim Ellison writes:
I'd like to request approval to revert the changes in r823479 that were
for an optimization in the archive code, but cause a regression in rmi.
This is the
On 23/Nov/2009 20:27, Jesse Wilson wrote:
My bad for committing during the code freeze.
So you're going to rollback, esp. so we don't exclude all the other
tests in that type?
Does it make sense to limit test changes during the code freeze? I don't see
any benefit.
We ensure that the tests
On Mon, Nov 23, 2009 at 2:29 PM, Tim Ellison t.p.elli...@gmail.com wrote:
On 23/Nov/2009 20:27, Jesse Wilson wrote:
My bad for committing during the code freeze.
So you're going to rollback, esp. so we don't exclude all the other
tests in that type?
I can certainly rollback the changes to
On 23/11/2009, Jesse Wilson jessewil...@google.com wrote:
On Mon, Nov 23, 2009 at 2:29 PM, Tim Ellison t.p.elli...@gmail.com wrote:
On 23/Nov/2009 20:27, Jesse Wilson wrote:
My bad for committing during the code freeze.
So you're going to rollback, esp. so we don't exclude all the
On Mon, Nov 23, 2009 at 5:08 PM, sebb seb...@gmail.com wrote:
On 23/11/2009, Jesse Wilson jessewil...@google.com wrote:
On Mon, Nov 23, 2009 at 2:29 PM, Tim Ellison t.p.elli...@gmail.com wrote:
On 23/Nov/2009 20:27, Jesse Wilson wrote:
My bad for committing during the code freeze.
On Mon, Nov 23, 2009 at 6:01 PM, Nathan Beyer ndbe...@apache.org wrote:
I'd love to see the exclude files dropped in favor of JUnit @Ignore +
reporting for those ignored tests. That would be extremely helpful in
pointing out all of the excluded tests.
Yes!
On Mon, Nov 23, 2009 at 4:40 PM, Jesse Wilson jessewil...@google.com wrote:
On Mon, Nov 23, 2009 at 2:29 PM, Tim Ellison t.p.elli...@gmail.com wrote:
On 23/Nov/2009 20:27, Jesse Wilson wrote:
My bad for committing during the code freeze.
So you're going to rollback, esp. so we don't exclude
Sounds good for use branching and freeze that code.
--
Regards,
Ray Chen
sebb wrote:
On 23/11/2009, Jesse Wilson jessewil...@google.com wrote:
On the other hand, if there are lots of failing tests, it can be
difficult to spot tests that fail occasionally.
Test cases that are known to fail could document this, e.g. by
printing a message to say that the failure is
24 matches
Mail list logo
