Correct. 15 tests passed. As for your suggestion of adding a
regression test, I'm not yet convinced we should duplicate VTS tests
as regression tests.

BTW, I have evaluated the other problem a bit. The problem is due to
the virtual method constant pool entry resolution. Does this ring a
bell?

#2: InterfaceMethodref class:
25=org.apache.harmony.vts.test.vm.jvms.instructions.invokeReturn.invokeinterface.invokeinterface07.invokeinterface0703.invokeinterface0703pInterface
name_and_type: 24=<virtualMethod (short)int>

This is still a regression, but probably an older one (since all your
runs use a release build).

On Thu, Apr 24, 2008 at 9:29 AM, Stepan Mishura
<[EMAIL PROTECTED]> wrote:
> On 4/24/08, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
>
> > I ran the tests locally and they passed.
>
>  So you applied your fix and all these 15 failed tests passed. Correct?
>
>
>  > Though, a number of other
>  > tests failed, I assumed, due to assertions absent in your release
>  > build.
>  >
>
>  Hmm, you assumed that tests results for debug and release builds are
>  different but this also IMHO may mean other regressions in verifier.
>
>  BTW, I don't see any regression test in the patch. Does it make sense
>  to create it and add it to DRLVM reg. test suite?
>
>  Thanks,
>
>
> Stepan.
>
>  > On Thu, Apr 24, 2008 at 9:01 AM, Stepan Mishura
>  > <[EMAIL PROTECTED]> wrote:
>  > > On 4/24/08, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
>  > >
>  > > > Stenan,
>  > >  > Sorry. I have fixed VTS verifier test failures:
>  > >  > 
> http://people.apache.org/~smishura/r650380/Windows_x86/vtsvm/junit/index.html
>  > >  >
>  > >
>  > >  So all 15 tests failed because of this bug. Correct?
>  > >
>  > >  -Stepan.
>  > >
>  > >
>  > >
>  > >  > On Thu, Apr 24, 2008 at 6:57 AM, Stepan Mishura
>  > >  > <[EMAIL PROTECTED]> wrote:
>  > >  > > Hi Alexei,
>  > >  > >
>  > >  > >
>  > >  > >  On 4/24/08, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
>  > >  > >  > Hello Stepan,
>  > >  > >  >
>  > >  > >  > I have fixed more verifier failures, see
>  > >  > >
>  > >  > >  Which failures did you fix? HARMONY-5785 description doesn't 
> mention any.
>  > >  > >
>  > >  > >  -Stepan.
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >  > https://issues.apache.org/jira/browse/HARMONY-5785
>  > >  > >  >
>  > >  > >  > Thanks!
>  > >  > >  >
>  > >  > >  > On Wed, Apr 23, 2008 at 7:28 AM, Stepan Mishura
>  > >  > >  > <[EMAIL PROTECTED]> wrote:
>  > >  > >  > > On 4/22/08, Tim Ellison <[EMAIL PROTECTED]> wrote:
>  > >  > >  > >  > Alexei Fedotov wrote:
>  > >  > >  > >  > > As far as I understand Eclipse IP committee needs a 
> revision number to
>  > >  > >  > >  > > be supplied (no binaries involved).
>  > >  > >  > >  > >
>  > >  > >  > >  >
>  > >  > >  > >  > Apologies, I missed that point in the discussions around 
> compiler level etc.
>  > >  > >  > >  >  If it is simply a well-defined revision of the verifier 
> code then that is
>  > >  > >  > >  > quite different.
>  > >  > >  > >  >
>  > >  > >  > >  > > The favour Vasily is asking about
>  > >  > >  > >  > > is providing him with a slightly tested revision. This 
> would suppress
>  > >  > >  > >  > > a normal work of committers for one day. Is it something 
> we cannot
>  > >  > >  > >  > > afford?
>  > >  > >  > >  > >
>  > >  > >  > >  >
>  > >  > >  > >  > Of course, in that area of the code I think it is quite 
> reasonable.  It
>  > >  > >  > >  > would not prevent people working in the other areas of 
> Harmony (such as GC,
>  > >  > >  > >  > JIT, and class library).
>  > >  > >  > >  >
>  > >  > >  > >
>  > >  > >  > >  OK, freezing only verifier code can be a compromise in this 
> case.
>  > >  > >  > >  But I think it makes sense for other areas to ask people not 
> commit
>  > >  > >  > >  risky changes (i.e. make feature freeze and commit only bug 
> fixes) -
>  > >  > >  > >  it will help with detection and resolution of possible 
> verifier
>  > >  > >  > >  regressions. I believe that this acceptable too.
>  > >  > >  > >
>  > >  > >  > >  Could I ask all folks interesting in M5.5_Eclipse_TPTP 
> release to look
>  > >  > >  > >  through tests failures to understand if there are regressions 
> in the
>  > >  > >  > >  verifier or not?
>  > >  > >  > >
>  > >  > >  > >  Tests results for r650380 are almost ready [1] (testing the 
> next
>  > >  > >  > >  r650564 snapshot will be launched in 2-3 hours).  If there 
> are no
>  > >  > >  > >  regressions then I think r650380 (or r650564) can be promoted 
> as
>  > >  > >  > >  M5.5_Eclipse_TPTP. If you find verifier regression please let
>  > >  > >  > >  everybody know ASAP - it should be fixed quickly.
>  > >  > >  > >
>  > >  > >  > >  [1] 
> http://people.apache.org/~mloenko/snapshot_testing/script/r650380/index.html
>  > >  > >  > >
>  > >  > >  > >  Thanks,
>  > >  > >  > >  Stepan.
>  > >  > >  > >
>  > >  > >  > >
>  > >  > >  > >
>  > >  > >  > >  > Of course, we cannot prevent the revision number of the 
> entire repository
>  > >  > >  > >  > changing over time, but you could nominate a givne revision 
> number for the
>  > >  > >  > >  > verifier code to be taken by Eclipse.
>  > >  > >  > >  >
>  > >  > >  > >  > Did I understand this right?
>  > >  > >  > >  >
>  > >  > >  > >  > Thanks,
>  > >  > >  > >  > Tim
>  > >  > >  > >  >
>  > >  > >  > >  >
>  > >  > >  > >  >
>  > >  > >  > >  > > On Tue, Apr 22, 2008 at 3:07 PM, Tim Ellison <[EMAIL 
> PROTECTED]>
>  > >  > >  > >  > wrote:
>  > >  > >  > >  > >
>  > >  > >  > >  > > > I'm really not convinced this is a good idea for 
> Harmony, and my
>  > >  > >  > >  > concerns
>  > >  > >  > >  > > > are in two parts:
>  > >  > >  > >  > > >
>  > >  > >  > >  > > >  1) Our schedule should not be dictated by an external 
> project,
>  > >  > >  > >  > especially
>  > >  > >  > >  > > > when it is their process that seems to be setting the 
> artificial time
>  > >  > >  > >  > limit.
>  > >  > >  > >  > > > Why not show some flexibility to meet our dates?
>  > >  > >  > >  > > >
>  > >  > >  > >  > > >  2) Our principle delivery mechanism is source code.  
> While we make
>  > >  > >  > >  > binaries
>  > >  > >  > >  > > > available as a convenience we should not encourage 
> dependents to put
>  > >  > >  > >  > > > dependencies on our build tools.  They should take 
> source and compile it
>  > >  > >  > >  > > > themselves for their own environment.
>  > >  > >  > >  > > >
>  > >  > >  > >  > > >  Regards,
>  > >  > >  > >  > > >  Tim
>  > >  > >  > >  > > >
>  > >  > >  > >  > > >  Vasily Levchenko wrote:
>  > >  > >  > >  > > >
>  > >  > >  > >  > > >
>  > >  > >  > >  > > > > $subj.
>  > >  > >  > >  > > > >
>  > >  > >  > >  > > > >
>  > >  > >  > >  > > > >
>  > >  > >  > >  > > >
>  > >  > >  > >  > >
>  > >  > >  > >  > >
>  > >  > >  > >  > >
>  > >  > >  > >  > >
>  > >  > >  > >  >
>  > >  > >  > >
>  > >  > >  >
>  > >  > >  >
>  > >  > >  >
>  > >  > >  > --
>  > >  > >  > With best regards,
>  > >  > >  > Alexei
>  > >  > >  >
>  > >  > >
>  > >  >
>  > >  >
>  > >  >
>  > >  > --
>  > >  > With best regards,
>  > >  > Alexei
>  > >  >
>  > >
>  >
>  >
>  >
>  > --
>  > With best regards,
>  > Alexei
>  >
>



-- 
With best regards,
Alexei

Reply via email to