# harmony-dev mailing list archives

##### Site index · List index
Message view
Top
Subject Re: [build] status
Date Thu, 20 Jul 2006 07:56:54 GMT
```On 7/20/06, Mark Hindess <mark.hindess@googlemail.com> wrote:
>
>
> This was the build break I tried to own up to yesterday.  It was caused
> by my refactoring of exception function - to have one set not several.
> (I missed the extern "C" clause and included it in some C++ code.)

Thanks for this clarification, Mark. Now I have no any puzzles:-).

-Mark.
>
> On 20 July 2006 at 14:30, "Vladimir Gorr" <vvgorr@gmail.com> wrote:
> >
> >  The issue mentioned below disapperead after the latest changes for
> class
> > library.
> > Nevertheless I'm not clear a clue for this build error. In any case
> thanks
> > for this fix.
> >
> >
> >
> >
> > On 7/19/06, Vladimir Gorr <vvgorr@gmail.com> wrote:
> > >
> > >  Can anybody say about the build status on Windows we have now?
> > > Unfortunately, I cannot build for the recent sources due to the
> following
> > > issue:
> > >
> > >      [exec] winFont.obj : error LNK2019: unresolved external symbol
> "void
> > > __cde
> > > l throwNPException(struct JNIEnv_ *,char const *)" (
> > > ?throwNPException@@YAXPAUJN
> > > Env_@@PBD@Z) referenced in function
> > > _Java_org_apache_harmony_awt_gl_font_Native
> > > ont_enumSystemFonts@8
> > >      [exec] ..\fontlib.dll : fatal error LNK1120: 1 unresolved
> externals
> > >      [exec] NMAKE : fatal error U1077: 'link' : return code '0x460'
> > >      [exec] Stop.
> > >
> > > Any ideas?
> > >
> > > Thanks,
> > >
> > > On 7/19/06, Geir Magnusson Jr <geir@pobox.com> wrote:
> > > >
> > > >
> > > >
> > > > Nathan Beyer wrote:
> > > > >> -----Original Message-----
> > > > >> From: Geir Magnusson Jr [mailto: geir@pobox.com]
> > > > >> Paulex Yang wrote:
> > > > >>> I think Richard's patch is fine, i.e., specify a locale to
the
> test,
> > > > >>> what we want to test is toPattern()'s logic, not the locale
data
> or
> > > > >>> something, and the specified locale is OK to test the logic.
And
> I
> > > > also
> > > > >>> think maybe one locale is not enough, so we may want to include
> some
> > > > >>> more exceptional locale, say, en_UK in this case, by which,
we
> can
> > > > try
> > > > >>> to follow RI as possible. Loose the test by removing the
> assertion
> > > > here
> > > > >>> is dangerous, just like any other cases without clear spec.
> > > > >> I think what this proved to us is that our testing matrix must
> > > > include
> > > > >> WinXP en_US, en_UK, en_RU etc.
> > > > >
> > > > > Locale-sensitive testing is pragmatically only necessary on a
> small
> > > > subset
> > > > > of Harmony's modules (for example, text); this could be isolated
> to
> > > > the
> > > > > build scripts of those modules. A trivial implementation would be
> to
> > > > setup a
> > > > > list of locales to test, iterate the modules suite of tests for
> each
> > > > locale
> > > > > and set the default locale respective to the iteration.
> > > >
> > > > Sure, although I don't know how to flip locale programmatically from
> ant
> > > >
> > > > in windows :)
> > > >
> > > > I do know how to ask Tim, Stephan, Paulex and myself to run the same
> > > > tests :)
> > > >
> > > > geir
> > > >
> > > > >
> > > > > -Nathan
> > > > >
> > > > >> IOW, we want to run our test suite on as many locale's as
> possible,
> > > > and
> > > > >> have it pass on every one of them.  We may choose local-specific
> > > > tests,
> > > > >> btw, which is what I think you are suggesting.
> > > > >>
> > > > >> geir
> > > > >>
> > > > >>>
> > > > >>> Geir Magnusson Jr wrote:
> > > > >>>> What do you suggest then?
> > > > >>>>
> > > > >>>> Paulex Yang wrote:
> > > > >>>>
> > > > >>>>> Geir Magnusson Jr wrote:
> > > > >>>>>
> > > > >>>>>> Then I guess we just fix the test.
> > > > >>>>>>
> > > > >>>>> Agree, just think we should not "fix" the test by
removing the
> > > > >>>>> assertion.
> > > > >>>>>
> > > > >>>>>> geir
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> Paulex Yang wrote:
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>> Tim Ellison wrote:
> > > > >>>>>>>
> > > > >>>>>>>> Geir Magnusson Jr wrote:
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>> Now, on my windows box I got a clean
build, no
> > > > failures....  hm.
> > > > >>>>>>>>>
> > > > >>>>>>>> The test works on en_US locale and fails
on en_UK.  I'm
> > > > guessing
> > > > >> that
> > > > >>>>>>>> your machine is set up as en_US.
> > > > >>>>>>>>
> > > > >>>>>>>> Richard offered a patch that sets the
locale to en_US for
> all
> > > > >>>>>>>> MessageFormatTest-s, but I suggested
that was not a
> suitable
> > > > >>>>>>>> solution.
> > > > >>>>>>>>
> > > > >>>>>>>> For now I suggest we remove the assertion,
since it is
> beyond
> > > > the
> > > > >>>>>>>> spec
> > > > >>>>>>>> requirements for this type.
> > > > >>>>>>>>
> > > > >>>>>>> Tim,
> > > > >>>>>>>
> > > > >>>>>>> Should we also consider the principle of
> > > > here?  I
> > > > >>>>>>> think
> > > > >>>>>>> it is a sample of unclear spec, and we should
assert if our
> > > > >>>>>>> implementation follows RI, i.e., the assert
> value
> > > > of
> > > > >>>>>>> toPattern() is necessary. The issue here
is just that the
> > > > testcase
> > > > >>>>>>> assumes the return value is locale-independent,
so I think
> > > > Richard's
> > > > >>>>>>> patch is OK. Further, from the test perspective,
maybe(just
> > > > maybe)
> > > > >>>>>>> test
> > > > >>>>>>> case on only one locale is not enough to
check Harmony's
> > > > toPattern()
> > > > >>>>>>> logic, tests on more different locale(especially
the
> > > > 'exceptional'
> > > > >>>>>>> case
> > > > >>>>>>> like en_UK) are better.
> > > > >>>>>>>
> > > > >>>>>>> Also FYI, I tried the original test case
with RI on en_UK
> > > > locale,
> > > > >>>>>>> and it
> > > > >>>>>>> failed exactly as Harmony.
> > > > >>>>>>>
> > > > >>>>>>>> Regards,
> > > > >>>>>>>> Tim
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>> Geir Magnusson Jr wrote:
> > > > >>>>>>>>>
> > > > >>>>>>>>>> This is nuts.  We need to chase
down the commit that
> broke
> > > > this,
> > > > >>>>>>>>>> and
> > > > >>>>>>>>>> reverse it.  We can't have a
broken build persisting this
> > > > long.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> geir
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Tim Ellison wrote:
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> (1) Linux build/tests are
passing again, but for some
> reason
> > > > the
> > > > >>>>>>>>>>> 'BUILD SUCCESSFUL' note didn't
go to the commit list?
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> (2) Windows build/test is
still failing with:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Wrong full date pattern expected:<...full...>
but
> > > > >> was:<...long...>
> > > > >>>>>>>>>>> junit.framework.ComparisonFailure:
Wrong full date
> pattern
> > > > >>>>>>>>>>> expected:<...full...>
but was:<...long...> at
> > > > >>>>>>>>>>>
> > > > >>
> > > >
> org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatte
> > r
> > > > >> nLjava_lang_String(MessageFormatTest.java:244)
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> at
> > > > >>>>>>>>>>>
> > > > >> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java
> :205)
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Regards,
> > > > >>>>>>>>>>> Tim
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > -----------------------------------------------------------------
> > > > >> ----
> > > > http://incubator.apache.org/harmony/mailing.html
> > > > >>>>>>>>>> To unsubscribe, e-mail:
> > > > >>>>>>>>>> harmony-dev-unsubscribe@incubator.apache.org
> > > > >>>>>>>>>> For additional commands, e-mail:
> > > > >>>>>>>>>> harmony-dev-help@incubator.apache.org
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>
> > > > ------------------------------------------------------------------
> > > > >> ---
> > > > http://incubator.apache.org/harmony/mailing.html
> > > > >>>>>>>>> To unsubscribe, e-mail: harmony-dev-
> > > > >> unsubscribe@incubator.apache.org
> > > > >>>>>>>>> For additional commands, e-mail:
> > > > >>>>>>>>> harmony-dev-help@incubator.apache.org
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>
> > > >
> ---------------------------------------------------------------------
> http://incubator.apache.org/harmony/mailing.html
> > > > >>>>>> To unsubscribe, e-mail:
> > > > harmony-dev-unsubscribe@incubator.apache.org
> > > > >>>>>> For additional commands, e-mail: harmony-dev-
> > > > >> help@incubator.apache.org
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>
> > > >
> ---------------------------------------------------------------------
> > > > >>>> To unsubscribe, e-mail:
> > > > harmony-dev-unsubscribe@incubator.apache.org
> > > > >>>> For additional commands, e-mail:
> > > > harmony-dev-help@incubator.apache.org
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > > >>
> ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail:
> harmony-dev-unsubscribe@incubator.apache.org
> > > > >> For additional commands, e-mail:
> > > > harmony-dev-help@incubator.apache.org
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> harmony-dev-unsubscribe@incubator.apache.org
> > > > > For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
> > > >
> > > >
> > >
> >
> > ------=_Part_4963_12864818.1153380636819--
>
>
>
> ---------------------------------------------------------------------