So, the time spent for pre-commit checks won't be a big problem in this
case. Enabling JIT to be built in debug by default (what I think we should
do) will add just 20-30% to this time.
Thanks,
Pavel
On 11/10/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
Well I am always testing patches in
On 11/10/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Sure, contributors should check debug or even both debug and release
builds
and comment about this in JIRA.
As far as I understand the only person who answers for the commit is a
committer. So I don't think that establishing a policy that
Any assert(expr) can change a control flow of the debug build
On 11/12/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote:
On 11/10/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Sure, contributors should check debug or even both debug and release
builds
and comment about this in JIRA.
As
When the spec doesn't specify expression evaluation order debug and
release can behave differently. I got into such situation once... :-(
On 11/13/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Any assert(expr) can change a control flow of the debug build
On 11/12/06, Pavel Ozhdikhin [EMAIL
Sure, contributors should check debug or even both debug and release builds
and comment about this in JIRA.
As far as I understand the only person who answers for the commit is a
committer. So I don't think that establishing a policy that shifts a
part of responsibility from the committer is a
Well I am always testing patches in _default_ mode which debug for VM,
release for JIT and whatever it is for classlib. If defaults change then
it will be some other conditions. Average time to run build test is
~60 minutes.
Pavel Ozhdikhin wrote:
Sure, contributors should check debug or
I do the same - I tend to only generally test in debug mode when doing
series of things, and then doing a release for fun later.
I expect this to be much less of an issue when build-test is up and
running with debug + release + .
geir
Gregory Shimansky wrote:
Well I am always testing
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
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
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
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
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
Geir Magnusson Jr. wrote:
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
On 11/9/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
Actually it is more than that. In debug mode TRACE statements are
compiled and therefore produce executable code. There may also be some
bugs in compiler generating code in different modes (although this
usually happens for release).
I
Well, since the problem is repeatable :)
Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
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
+1 for debug testing before submitting a patch.
But, for pre-commit testing we should be careful saying we'll test all the
patches in debug mode. Though it imprves quality of checks, debug build is
significantly slower then release, especially when running with interpreter
or Jitrino.OPT. I ran
I can understand that the contributor may not have access to multiple
platforms, but surely he can test using both debug and release builds :-)
What do we gain by asking the contributor to test less?
Rana
On 11/9/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote:
+1 for debug testing before
Sure, contributors should check debug or even both debug and release builds
and comment about this in JIRA.
I'm talking about committers, will they test debug build which takes 5 times
more time? And does it mean they will be able to apply 5 times less patches?
Actually I'm fine if the
18 matches
Mail list logo
