Evgueni,
1) Which of the patches is a final?
2) It looks like you do not find a way to remove hythread_library_t
from parameters
and JavaVM from thread manager code. Well, leave it as is, I will try
to fix this later.
2)
Is the following global variable is necessary?
extern
Yes, I am really upset. Code formater is ok, any means are good. :)
Thanks.
2006/10/2, Tim Ellison [EMAIL PROTECTED]:
if it is upsetting you so much, I'll run the code formatter over beans
tests -- that will do the whitespace replacements. We have been
replacing them incrementally to date.
On 10/2/06, Denis Kishenko [EMAIL PROTECTED] wrote:
Seems this is RI bug.
Apparently, RI doesn't comply with spec this time. But I think
IllealArgumentException is also acceptable. Therefore, I suggest to follow
RI and mark this issue as Non-bug differences from spec as
exception-throwing
I see. This IMHO is another argument why \t is bad. My script will not
be able to handle this, it just replaces one string pattern with
another. So such cases should be handled manually or with the code
formatter. However, the drawback of the code formatter is that it
removes the author's
On 10/3/06, Artem Aliev [EMAIL PROTECTED] wrote:
Evgueni,
Artem,
1) Which of the patches is a final?
invocation_api.4.patch is final. so far :-)
2) It looks like you do not find a way to remove hythread_library_t
from parameters
and JavaVM from thread manager code. Well, leave it as
Andrew thanks for answer.
I have checked RI 1.4 behavior and spec, it's the same -
IllegalArgumentException. May be it's just JavaDoc mistake.
RI and mark this issue as Non-bug differences from spec as
exception-throwing guideline[1] suggests. Thanks!
Unfortunatelly JIRA hasn't such category.
On 10/2/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Andrey,
Just to be clear I agree with you it is more convenient if
jthread_create takes JNIEnv instead of JavaVM. It reflects that
current thread has been attached already. Do you think it makes sense
to get rid of JNIEnv and use
Nathan,
I've seen you dropped many TODOs in - Code cleanup - series of commits;
I'd like to know what reasoning was behind this? I think it's a bit
early to erase TODOs without appropriate consideration...
In particular, could you please undo the following change, it produces
garbage messages
Dear committers,
I filed recently the HARMONY-1573, -1650, -1651, -1654 issues with the
suggested patches.
So, to avoid redoubling efforts or superposition of commits because of delay
could somebody take them under a control to estimate and apply if it is
necessary?
All the more, the 1650
Mark Hindess wrote:
On 28 September 2006 at 14:58, Alexey Petrenko [EMAIL PROTECTED] wrote:
2006/9/28, Mark Hindess [EMAIL PROTECTED]:
On 28 September 2006 at 14:30, Alexey Petrenko [EMAIL PROTECTED]
om wrote:
I think that it will be better to add another target to build
I had a quick look at the Ant website - I can't see anything obvious in
1.7 that
will make a big difference to us. Most of the information I found was
concerned
with antlibs.
Anyone spotted anything we could use?
Regards,
Oliver
Geir Magnusson Jr. wrote:
Also, should we update to ant 1.7?
+1
Geir Magnusson Jr. wrote:
BCC and ACQs are in.
What say ye? Would it be nice to debug using eclipse debugger in DRLVM?
[ ] + 1 accept this contribution into the project
[ ] -1 don't accept (please give reason)
Vote runs usual 3 days unless protest or early completion.
geir
Dear committers,
please, commit HARMONY-1594 to fix gcc 4.* build for Jitrino and jet
sources. Otherwise, it is a bit more complex to live on a linux with
compiler version 4.0 and above.
Regards,
Pavel Pervov.
Intel Middleware Products Division.
I'll take a look.
-Mark.
On 3 October 2006 at 14:42, Pavel Pervov [EMAIL PROTECTED] wrote:
Dear committers,
please, commit HARMONY-1594 to fix gcc 4.* build for Jitrino and jet
sources. Otherwise, it is a bit more complex to live on a linux with
compiler version 4.0 and above.
Ok. I'll look. It must be the case that the whole thing can compile w/
GCC 4.*, not just Jitrino and jet, including classlib.
This isssue, the version of GCC, is one of the things that snags people.
Are there any backwards compat issues if we make it all 4.x
compatible?
geir
Pavel
After posting, I noticed that Geir has pick up this JIRA so, while I'll
still take a look, I wont steal the JIRA or commit any changes.
Geir feel free to re-assign it if you decide you don't want it. ;-)
-Mark.
On 3 October 2006 at 12:02, Mark Hindess [EMAIL PROTECTED] wrote:
I'll take a
Serguei Zapreyev wrote:
Dear committers,
I filed recently the HARMONY-1573, -1650, -1651, -1654 issues with the
suggested patches.
I was looking at 1573 last night, but was too tired to follow the
instructions :) (Take the third attachment, combine with the first, to
produce the second
yes, I saw - thanks for that.
I was trying to get 1531 to work yesterday, and I seemed to do something
wrong.
Can you look at 1531 and comment?
geir
Ivan Kollegov wrote:
Hi,
I opened new JIRA
http://issues.apache.org/jira/browse/HARMONY-1586
and attach my contribution
to keep things
I've committed the reformatted code in r452415.
Now you can feel calm again :-)
The other modules are being cleaned-up piece by piece.
Regards,
Tim
Alexei Zakharov wrote:
I see. This IMHO is another argument why \t is bad. My script will not
be able to handle this, it just replaces one
2006/10/3, Serguei Zapreyev [EMAIL PROTECTED]:
Dear committers,
I filed recently the HARMONY-1573, -1650, -1651, -1654 issues with the
suggested patches.
So, to avoid redoubling efforts or superposition of commits because of delay
could somebody take them under a control to estimate and
Mikhail Loenko wrote:
For the short term it sounds good.
For the long term the deps would better be built on the fly IMHO
Why? We don't build other deps on the fly. By using a binary distro, we
all have the same, predictable thing.
And seems like some of this code hasn't changed since
On 10/3/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Serguei Zapreyev wrote:
Dear committers,
I filed recently the HARMONY-1573, -1650, -1651, -1654 issues with the
suggested patches.
I was looking at 1573 last night, but was too tired to follow the
instructions :) (Take the third
Congratulations! You're the proud owner of 1594!
Please make sure things still compile w/ 3.4 :)
geir
Mark Hindess wrote:
After posting, I noticed that Geir has pick up this JIRA so, while I'll
still take a look, I wont steal the JIRA or commit any changes.
Geir feel free to re-assign it
I agree that downloading of prebuilt libraries is better choice.
So we got only two options:
1. Find prebuilt libraries somewhere.
2. Build them ourselves and store them somewhere.
I've tried to find prebuilt libraries but I was not successful. So it
seems that the only option is to build them
On 10/3/06, Andrey Chernyshev [EMAIL PROTECTED] wrote:
On 10/2/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Andrey,
Just to be clear I agree with you it is more convenient if
jthread_create takes JNIEnv instead of JavaVM. It reflects that
current thread has been attached already. Do you
I haven't used MSVC in about 6 years, so where is the right place to put
the files from 1607 so that they are easily used by an MSVC user?
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe,
2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]:
Alexey Petrenko wrote:
I agree that downloading of prebuilt libraries is better choice.
So we got only two options:
1. Find prebuilt libraries somewhere.
2. Build them ourselves and store them somewhere.
I've tried to find prebuilt
On 10/3/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/10/3, Serguei Zapreyev [EMAIL PROTECTED]:
Dear committers,
I filed recently the HARMONY-1573, -1650, -1651, -1654 issues with the
suggested patches.
So, to avoid redoubling efforts or superposition of commits because of
delay
2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]:
Alexey Petrenko wrote:
I agree that downloading of prebuilt libraries is better choice.
So we got only two options:
1. Find prebuilt libraries somewhere.
2. Build them ourselves and store them somewhere.
I've tried to find prebuilt
Alexey,
Thanks for pointing to that test - I created my tests using this approach.
Please see HARMONY-1671 for tests. If you think that some more options
should be covered - please let me know - I'll try to make tests for
them.
On 9/29/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Anton,
Many
Alexey Petrenko wrote:
2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]:
Alexey Petrenko wrote:
I agree that downloading of prebuilt libraries is better choice.
So we got only two options:
1. Find prebuilt libraries somewhere.
2. Build them ourselves and store them somewhere.
I've tried
Egor,
HARMONY-1673 is filed. I've tried both -Xem:opt -Xem:jet.
Regards,
03 Oct 2006 00:06:16 +0700, Egor Pasko [EMAIL PROTECTED]:
On the 0x1F6 day of Apache Harmony Alexei Zakharov wrote:
The same result with the -Xem:opt.
Could you file a JIRA for that, please? With steps to
reproduce.
2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]:
Alexey Petrenko wrote:
2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]:
Alexey Petrenko wrote:
I agree that downloading of prebuilt libraries is better choice.
So we got only two options:
1. Find prebuilt libraries somewhere.
2. Build
On 3 October 2006 at 7:49, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Alexey Petrenko wrote:
I agree that downloading of prebuilt libraries is better choice.
So we got only two options:
1. Find prebuilt libraries somewhere.
2. Build them ourselves and store them somewhere.
I tend to agree. I think that it's a good idea to consider for the
future, but right now, if the fixes help stabilize, great. I think that
stabilization is key right now.
geir
Serguei Zapreyev wrote:
On 10/3/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/10/3, Serguei Zapreyev [EMAIL
On 3 October 2006 at 19:16, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]:
Alexey Petrenko wrote:
I agree that downloading of prebuilt libraries is better choice.
So we got only two options:
1. Find prebuilt libraries somewhere.
2.
Mikhail Loenko wrote:
2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]:
Alexey Petrenko wrote:
I agree that downloading of prebuilt libraries is better choice.
So we got only two options:
1. Find prebuilt libraries somewhere.
2. Build them ourselves and store them somewhere.
I've
nice work
Anton Luht wrote:
Alexey,
Thanks for pointing to that test - I created my tests using this approach.
Please see HARMONY-1671 for tests. If you think that some more options
should be covered - please let me know - I'll try to make tests for
them.
On 9/29/06, Alexey Varlamov [EMAIL
Mark Hindess wrote:
On 3 October 2006 at 19:16, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]:
Alexey Petrenko wrote:
I agree that downloading of prebuilt libraries is better choice.
So we got only two options:
1. Find prebuilt libraries
+1 (with apologies for taking so long to complete the review)
Tim
Geir Magnusson Jr. wrote:
BCC and ACQs are in.
What say ye? Would it be nice to debug using eclipse debugger in DRLVM?
[ ] + 1 accept this contribution into the project
[ ] -1 don't accept (please give reason)
Vote
I have one more question about coverage: should it be the part of the BT
infrastructure or integrated to the current classlib build system?
From my point of view it should be a part of BTI while it is rarely used
functionality and no needs to waste regular build by this data (it does not
On 3 October 2006 at 9:33, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
On 3 October 2006 at 19:16, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]:
Alexey Petrenko wrote:
I agree that downloading of prebuilt libraries is
On 3 October 2006 at 21:08, Vladimir Ivanov [EMAIL PROTECTED] wrote:
I have one more question about coverage: should it be the part of the BT
infrastructure or integrated to the current classlib build system?
From my point of view it should be a part of BTI while it is rarely used
Sure, this can wait - say, until classlib tests 100% pass on DRLVM, -
just to let current pace of major changes slow down.
Other than that, I see no compelling reasons to maintain duplicate
impl in DRLVM.
And you bet the reference impl in classlib is mature enough to not
affect VM stability ;)
On 10/3/06, Mark Hindess [EMAIL PROTECTED] wrote:
Regarding the 'run japi' script what are you planning to do here? The
IBM Build/test builds also run japi (on linux only since we get enough
information using one platform and linux is easier). We might as well
share ant code.
Also note that
Geir,
it looks like the commit
[r452245] HARMONY-698 This should be equivalent to what HARMONY-698
broken the downloading of junit.jar (which we used to take from Eclipse
distribution).
The below patch adds junit.jar as a separate download from ibiblio jar
repository.
--- 8 ---
added
Can't we just take junit.jar from classlib's depends (as we do with XALAN)?
2006/10/3, Salikh Zakirov [EMAIL PROTECTED]:
Geir,
it looks like the commit
[r452245] HARMONY-698 This should be equivalent to what HARMONY-698
broken the downloading of junit.jar (which we used to take from
Geir, my comment is in JIRA.
On 10/3/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
yes, I saw - thanks for that.
I was trying to get 1531 to work yesterday, and I seemed to do something
wrong.
Can you look at 1531 and comment?
geir
Ivan Kollegov wrote:
Hi,
I opened new JIRA
Alexey Varlamov wrote:
Can't we just take junit.jar from classlib's depends (as we do with XALAN)?
I agree, that would be a better solution.
It just didn't occur to me that we already have it in classlib's depends.
So, the below change seems to be sufficient.
--- build/make/setup.xml
+++
Ivan,
Thank you for the fix.
I checked the diff and it looks OK.
Actually, with this patch you remove the extra state from CFG - the special
behaviour of CFG without exit/entry nodes. And I think that this is right.
Now it's time to ask commiters to apply the patch.
On 10/3/06, Ivan Kollegov
Thanks, Tim :-)
Regards,
2006/10/3, Tim Ellison [EMAIL PROTECTED]:
I've committed the reformatted code in r452415.
Now you can feel calm again :-)
The other modules are being cleaned-up piece by piece.
Regards,
Tim
Alexei Zakharov wrote:
I see. This IMHO is another argument why \t is bad.
--- Alexey Varlamov [EMAIL PROTECTED]
wrote:
Guys,
I have a kind request for test target
customization:
1) need ability to pass extra arguments to tested
jre. This is useful
for testing various configurations of VM, e.g.
different execution
engines in DRLVM.
you mean like passing
1) Salikh - thanks for catching this
2) Alexey - yes, I think that would be better. Can someone offer a patch?
geir
Alexey Varlamov wrote:
Can't we just take junit.jar from classlib's depends (as we do with XALAN)?
2006/10/3, Salikh Zakirov [EMAIL PROTECTED]:
Geir,
it looks like the
so is my response :)
Mikhail Fursov wrote:
Geir, my comment is in JIRA.
On 10/3/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
yes, I saw - thanks for that.
I was trying to get 1531 to work yesterday, and I seemed to do something
wrong.
Can you look at 1531 and comment?
geir
Ivan
done
Mikhail Fursov wrote:
Ivan,
Thank you for the fix.
I checked the diff and it looks OK.
Actually, with this patch you remove the extra state from CFG - the special
behaviour of CFG without exit/entry nodes. And I think that this is right.
Now it's time to ask commiters to apply the patch.
fixed - thanks
Salikh Zakirov wrote:
Alexey Varlamov wrote:
Can't we just take junit.jar from classlib's depends (as we do with XALAN)?
I agree, that would be a better solution.
It just didn't occur to me that we already have it in classlib's depends.
So, the below change seems to be
There are a number of places in the class library code where we create
an object solely to use as a synchronized block 'lock'.
For example, in RandomAccessFile we define a
private Object repositionLock = new Object();
then in a number of methods
public int read()..
..
BCC and ACQs in place.
[ ] +1 Yes, accept the contribution
[ ] -1 No, don't. reason :
As usual, 3 days or until all committers vote, or there is an
objection/request for continuance
-
Terms of use :
Hello,
It's clear how to file issues for public API - write a test with
differend behaviour on RI and Harmony. It's not clear how to write
tests or report problems when JUnit impl test fail.
I see org.apache.harmony.security.tests.asn1.der.SequenceTest failing at
svn = r452457, (Oct 3 2006),
Tim Ellison wrote:
There are a number of places in the class library code where we create
an object solely to use as a synchronized block 'lock'.
For example, in RandomAccessFile we define a
private Object repositionLock = new Object();
then in a number of methods
public int read()..
+1
On 10/3/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
BCC and ACQs in place.
[ ] +1 Yes, accept the contribution
[ ] -1 No, don't. reason :
As usual, 3 days or until all committers vote, or there is an
objection/request for continuance
Hi all,
I have developed a tool to disassemble the java class files. Its
behavior is similar to the javap tool from J2SE 1.5.0. I would like it
to be included in the Harmony tools project.
The contribution can be found there:
http://issues.apache.org/jira/browse/HARMONY-1680
The contribution
Tim,
I suspect there may be some JVM internal lock design issues involved in what
you are suggesting. In specific, I vaguely remember a paper written by
David Bacon that describes lock optimization heuristics based on the
observation that most of the time, the object being locked is an instance
I don't think the goal is performance, but just being able to monitor
what sync blocks are hot via watching the sync objects.
geir
Weldon Washburn wrote:
Tim,
I suspect there may be some JVM internal lock design issues involved in
what
you are suggesting. In specific, I vaguely remember
Geir Magnusson Jr. wrote:
I don't think the goal is performance, but just being able to monitor
what sync blocks are hot via watching the sync objects.
What I meant to say was that it's not the performance of the lock
objects themselves, but the overall performance of the code that uses
Yep, you've got it.
Regards,
Tim
Geir Magnusson Jr. wrote:
Geir Magnusson Jr. wrote:
I don't think the goal is performance, but just being able to monitor
what sync blocks are hot via watching the sync objects.
What I meant to say was that it's not the performance of the lock
objects
Submit a JIRA with the failure and expected result (or am I missing
something?)
Regards,
Tim
Anton Luht wrote:
Hello,
It's clear how to file issues for public API - write a test with
differend behaviour on RI and Harmony. It's not clear how to write
tests or report problems when JUnit impl
+1 for creating a jdktools directory. The dependency on the classlib
launcher should be relatively light if we go with a simple tools
launcher that rewrites the tool invocation into a generic launcher
invocation. You may recall the idea was discussed a while ago.
So, for example,
I thought that perhaps a gdb backtrace may be helpful.
Note: I also tried to go into dll_jit.cpp:62 and hard code the name of the
dll_filename which is passed to apr_dso_load. And still when I step into
apr_dso_load that second argument path=0x102 Address 0x102 out of bounds.
Perhaps the stack
Sorry about the last email, but there is something I think I should mention.
I recently checked out a clean copy and rebuilt from scratch. I did not
notice BUT since then, helloworld does actually run!! It just hangs after
it runs. Now the behavior is very similar to when I run ./java
+1 from me too.
I'd like idea of having separate directory for all tools going to JDK
and including them into federal build.
Ivan.
On 10/4/06, Tim Ellison [EMAIL PROTECTED] wrote:
+1 for creating a jdktools directory. The dependency on the classlib
launcher should be relatively light if we
Initially I considered putting JDWP agent to classlib as part of JPDA
module, so its build is adjusted to the classlib build structure. But
I agree that putting it to tools directory (or to jdktools as
discussed in separate thread) should be better solution. JDWP agent is
not an implementation of
yep, that's the plan. And once we have that, we can simplify the
launcher as well...
Tim Ellison wrote:
+1 for creating a jdktools directory. The dependency on the classlib
launcher should be relatively light if we go with a simple tools
launcher that rewrites the tool invocation into a
Ivan Popov wrote:
--- I'd like to see JDWP unit tests included into regular tests runs,
they often reveal problems with JVMTI and JNI support when JVM
implementation is changed. I'm not sure that unit tests are provided
with other tools and included into tests run, and this can be a
separate
Sounds interesting.
Does this still include the hardware portability layer? Any synergies with
APR? Does it include the AWT code?
--- Noel
-Original Message-
From: Chris Gray [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 27, 2006 5:09
To: general@incubator.apache.org
On 10/3/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
On 10/3/06, Andrey Chernyshev [EMAIL PROTECTED] wrote:
On 10/2/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Andrey,
Just to be clear I agree with you it is more convenient if
jthread_create takes JNIEnv instead of JavaVM. It
If this is an event that should be logged, as the TODO indicated, then
why not just print out the stack trace and be done with it? If this
exception happens so often that you'd like it removed, then why would
we want to log a warning message, which I would presume would print to
the console just
On 10/4/06, Nathan Beyer wrote:
If this is an event that should be logged, as the TODO indicated, then
why not just print out the stack trace and be done with it? If this
exception happens so often that you'd like it removed, then why would
we want to log a warning message, which I would
On 10/3/06, Anton Luht wrote:
Hello,
It's clear how to file issues for public API - write a test with
differend behaviour on RI and Harmony. It's not clear how to write
tests or report problems when JUnit impl test fail.
Hi Anton,
At minimum you can just file a JIRA describing a failure
On Oct 3, 2006, at 12:29 AM, Egor Pasko wrote:
On the 0x1F7 day of Apache Harmony Naveen Neelakantam wrote:
Hello Egor,
I finally got a chance to read through your code. It is well
designed, and correct (as far as I can tell). I especially like the
way that the upper bounds solver works as
Hi,
I'm going to add a test for Keytool but I don't know how to name the
package for tests:
org.apache.harmony.tests.tools.keytool like it is done for javac or
org.apache.harmony.tools.keytool.tests like it was decided for
classlib?
--
Thanks,
Anton
On the 0x1F8 day of Apache Harmony Naveen Neelakantam wrote:
2) Also in updateMemDistanceWithPredecessors, I added an
optimization. Essentially, we can take advantage of ProveResult
being a lattice (i.e. is monotonic) to prevent some recursive proofs.
oh, the optimization is fine, but
82 matches
Mail list logo
