Re: Behaving differently than RI
ICU would not see this as a bug, because it is a feature of their
implementation of DecimalFormat. The pattern ".1" for ICU means to round the
value to the nearest tenth, while the RI takes it literally. If you look at
the JavaDocs for ICU, you'll see the following message:
*This is an enhanced version of DecimalFormat that is based on the standard
version in the JDK. New or changed functionality is labeled NEW or CHANGED.
[1]
This is why I chose my example, the ICU version is an "enhanced" version of
DecimalFormat that extends the RI implementation. I'm not sure if this
should be deviation from the RI should be considered a bug. However, if it
is, then this issue could be problematic for Harmony using the ICU's
implementation.
[1]
http://icu.sourceforge.net/apiref/icu4j/com/ibm/icu/text/DecimalFormat.html
Mike Ringrose
*On 11/6/06, Spark Shen <[EMAIL PROTECTED]> wrote:
Alexey Petrenko 写道:
> Hi, Mike.
>
> You can find compatybility guideline for Harmony here:
>
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
>
>
> According to your testcase. I think it is a bug and you should file it
> to JIRA.
AFAIK, ICU has its own mailing list[1]. If that incompatibility is
considered a bug, delegate to ICU development team may be more efficient.
[1] "ICU support mailing list" <[EMAIL PROTECTED]>
>
> SY, Alexey
>
> 2006/11/4, Mike Ringrose <[EMAIL PROTECTED]>:
>> Before submitting a bug to JIRA, I was curious to know, how exact
should
>> Harmony behave when compared to the RI. For example, the code below
>> produces
>> different results when compared to the RI.
>>
>>DecimalFormat f = new DecimalFormat(".1");
>>System.out.println(f.format(17.16));
>>
>> Harmony outputs 17.2, while the RI outputs 17.1. The reason for the
>> difference is that Harmony's underlying implementation is taken from
ICU
>> which supports options other than what is specified by the RI.
>>
>> Should this difference be considered a bug?
>>
>> Thanks,
>> Mike Ringrose
>>
>>
>
--
Spark Shen
China Software Development Lab, IBM
Behaving differently than RI
Before submitting a bug to JIRA, I was curious to know, how exact should
Harmony behave when compared to the RI. For example, the code below produces
different results when compared to the RI.
DecimalFormat f = new DecimalFormat(".1");
System.out.println(f.format(17.16));
Harmony outputs 17.2, while the RI outputs 17.1. The reason for the
difference is that Harmony's underlying implementation is taken from ICU
which supports options other than what is specified by the RI.
Should this difference be considered a bug?
Thanks,
Mike Ringrose
Re: [general] POLL : supported platforms
Ubuntu 6 x86, Debian 3.1 x86, Mac OSX ia32 and ia64 (as I will be upgrading in a few months). Mike Ringrose On 10/16/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Stefano Mazzocchi wrote: > Geir Magnusson Jr. wrote: >> We're a volunteer project, so "supported" is based on interest in >> community. Lets be clear by writing down a set of platforms that we as >> a community commit to support. >> >> I think we can define "support" as - "one or more people in the >> community tests on that platform on a regular basis, there are users >> that use that platform, and we have people volunteering to find and fix >> bugs that specifically affect that platform" >> >> Just throw things out there and we'll gather the results and see what's >> popular. We'll summarize in 3 days. Please be clear in indicating what >> you think should be reported. Don't vote against anything. To start, >> using a broad brush : >> >> >> Windows >> === >> Windows XP x86 >> >> Linux >> = >> Ubuntu 6 x86 >> Ubuntu 5 x86 >> RHEL (version ?) x86 >> FC (version ?) x86 >> SUSE (verion ?) x86 > > is this for "platforms we currently support" or for "platforms that we > aim to support"? Yes :) It's a wishlist - we support what people want. Since we don't formally support anything... (to that end, I want OS X PPC and OS X x86 on my wishlist) geir > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] define pre-commit testing configs to gain the stability
I couldn't have said it better. :) On 10/14/06, Tim Ellison <[EMAIL PROTECTED]> wrote: Geir Magnusson Jr. wrote: > If it turns out to be a big deal, we can simply add a pre-commit target > to the build that checks for things like that. It could also check for > things like tabs. If possible, it could be a pre-commit hook for svn, > but if not, in the build would be useful for those creating patches... Jeepers! Just hit return at the end of the file. If you screw-up the build system will slap you, we don't need scripts to fix this for us during commit/build. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] define pre-commit testing configs to gain the stability
Here's a reference that I found. http://gcc.gnu.org/ml/gcc/2003-11/msg01568.html Here's a link to ISO C 1999 standard. Look at section 5.1.1.2, item #3. http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf Mike Ringrose On 10/13/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Weldon Washburn wrote: > >> Have you tried it on another version? >> No I have not tried it on another version. If Mike Ringrose is correct >> about the ISO spec, the basic problem is that MSVC compiler is not ISO >> compliant. I have hit this specific problem multiple times over the >> years. >> That is, code developed on windows laptop w/o a blank new line at the end >> will not compile on gcc. > > > No I have not tried it on another version. If Mike Ringrose is correct > about the ISO spec, the basic problem is that MSVC compiler is not ISO > compliant. I have hit this specific problem multiple times over the years. > That is, code developed on windows laptop w/o a blank new line at the end > will not compile on gcc. > > The real issue is that there are a bunch of "minor" incompatibilities > between MSVC and gcc. I would not recommend holding one's breath waiting > for them to go away. My approach to the above is to simply test on both > linux and windows before committing. > If it turns out to be a big deal, we can simply add a pre-commit target to the build that checks for things like that. It could also check for things like tabs. If possible, it could be a pre-commit hook for svn, but if not, in the build would be useful for those creating patches... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] define pre-commit testing configs to gain the stability
If I remember correctly doesn't gcc only issue a warning. I believe the ISO C standard states that there shall be a new line at the end of a non-empty file. On 10/12/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: On 10/12/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > > Weldon Washburn wrote: > > A word of caution to those who are committing C/C++ code. There are > unique > > features of Microsoft C/C++ that will cause a build failure on Linux and > > vice versa. For example, gcc expects that the end of a C/C++ file is a > > blank line. Microsoft does not. > > That's gotta be a bug. What version are you using? gcc 3.4.5. If its a bug, its unlikely we will fix gcc or wait for gcc to be fixed. The pragmatic approach would be to simply open the *.cpp files, go to the bottom and hit the "return" key. The point is simply beware that committing even platform independent code may break the build/test on an untested platform. The biggest disconnect seems to be between (surprise) windows and linux. Testing on one of each will go a long way to reducing problems. > > > To reduce svn HEAD problems, it would be great if committers can test > all > > commits on at least some windows box and some linux box. > > > > > > On 10/9/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote: > >> > >> On 10/9/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > >> > Hi Pavel, > >> > > >> > I'm sorry I did not catch how for example Nathan's commits will be > >> checked > >> > on the configurations he does not have? > >> > >> Since we have the problem with diversity of the hardware the > >> committers own the following procedure might be reasonable: > >> > >> - If the commit does not depend on platform/OS, for example, a patch > >> to some OS-independent Java API, he checks it only Windows with > >> definite configuration. > >> > >> - If the commit may depend on the platform, for example, a patch to > >> the system-dependent native code, he checks it on Windows with > >> definite configuration and ask another committer to check it on other > >> system. > >> > >> > > >> > Thanks, > >> > Mikhail > >> > > >> > >> Thanks, > >> Pavel > >> > >> > >> > >> -- > >> Weldon Washburn > >> Intel Middleware Products Division > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Weldon Washburn Intel Middleware Products Division
Re: [drlvm] Using latest linux snapshot[hdk]...
Do you have multiple versions of gcc installed? What do you get when you run `gcc -dumpversion`? On 10/10/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: On Tuesday 10 October 2006 13:02 Ilya Okomin wrote: > On 10/9/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > Yeah, I would have been surprised it that worked. > > > > Why not just install v 6? > > I have libstdc++.so.6 on my system. > Nevertheless I have the same results as Dmitry described: > > bash-2.05b$ ./java -version > Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software > Foundation or its licensors, as applicable. > Failed to open JVM DLL: > /work/Harmony/builds/harmony-jre-latest/bin/default/harmonyvm > (/lib/ssa/libstdc++.so.6: version `GLIBCXX_3.4' not found (required by > /work/Harmony/builds/harmony-jre-latest/bin/default/libharmonyvm.so)) > > I used harmony-jre-r450941 snapshot. > Should I do anything else to resolve this issue? It is probably because your custom libstdc++ is still compiled against an older glibc version of your distribution. Geir uses more modern version. Can you run /lib/libc.so.6 and show the output? -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] version of gcc and other tools
On Debian based Linux machines, you need the packages binutils and binutilts-dev (pretty sure this is needed). Mike R. On 10/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Mark Hindess wrote: > On 10 October 2006 at 20:32, "Alexey Petrenko" < [EMAIL PROTECTED]> wrote: >> 2006/10/10, Geir Magnusson Jr. <[EMAIL PROTECTED]>: >>> I'm so sick of this gcc problem. >>> >>> Lets decide on the versions for GCC and other tools that "will work". I >>> feel the same way that mark does re that being able to build on multiple >>> versions gives a better feeling of goodness and harmony in the universe >>> and I encourage people to work on other versions (I will), but it's >>> gotta be the case that we have a "reference toolchain" - that no matter >>> what, it will work on there, and probably a list of tested versions >>> >>> So, what tools and what versions are people working with ? here's a >>> partial list of mine : >>> >>> 1) WinXP : Visual Studio .NET 2003 >>> >>> 2) Linux x86 : >>> GCC : 3.4.6 >>> g++ : 3.4.6 >>> make : 3.81b4 >>> >>> What are you using? what other tools should we list? >> ant > > binutils is pretty important (and for compiling drlvm, the binutils > development package is required - many people, even developers, wouldn't > normally have this). Agreed - part of my "how to setup a debian box for harmony" list... > > Regards, > Mark. > >>> I recently setup a new machine (linux) and now have the complete list of >>> stuff that has to be installed (starting from fresh ubuntu6) and will >>> post that on the getting started document on teh website. >>> >>> >>> geir >>> >>> - >>> Terms of use : http://incubator.apache.org/harmony/mailing.html >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> -- >> Alexey A. Petrenko >> Intel Middleware Products Division >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: unsuscribe
Try [EMAIL PROTECTED] On 5/12/06, hugo F. <[EMAIL PROTECTED]> wrote: unsuscribe - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
