Bazaar is a funny concept. :) I think it'll work assuming we have a
bazaar police - something constantly checking integrity of our code on
some target platforms. These may be the community members reporting
failures or a tool constantly testing some target platforms. But this
tool is another topi
Ivan Volosyuk wrote:
> What an interesting discussion! I have just read this out. :)
>
> IMHO, all of the discussion is focused on the scalability of
> bazar-like development as it exists here in harmony incubator:
>
> If something wrong is commited, then everyone has broken build or
> something
Ivan Volosyuk wrote:
What an interesting discussion! I have just read this out. :)
IMHO, all of the discussion is focused on the scalability of
bazar-like development as it exists here in harmony incubator:
If something wrong is commited, then everyone has broken build or
something doesn't wo
What an interesting discussion! I have just read this out. :)
IMHO, all of the discussion is focused on the scalability of
bazar-like development as it exists here in harmony incubator:
If something wrong is commited, then everyone has broken build or
something doesn't work. - This is bad. Syste
Tim Ellison 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
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,
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
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:
Weldo
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, c
Once every file is started with /* */ like comment (Apache license) the line
endings are not a problem :)
On 13 Oct 2006 14:05:17 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote:
On the 0x201 day of Apache Harmony Mike Ringrose wrote:
> If I remember correctly doesn't gcc only issue a warning. I be
On the 0x201 day of Apache Harmony Weldon Washburn wrote:
> On 10/12/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> >
> > Weldon Washburn wrote:
> > > On 10/12/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> > >>
> > >>
> > >>
> > >> Weldon Washburn wrote:
> > >> > A word of caution to tho
On the 0x201 day of Apache Harmony Mike Ringrose wrote:
> 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.
we treat warnings as errors in DRLVM, which is useful. Is there an
option in GC
On 10/12/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Weldon Washburn 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++
this I can believe :)
Mike Ringrose wrote:
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. <[EMA
Weldon Washburn 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
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
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
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 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.
To reduce svn HEAD problems, it would be gr
On 10/11/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
A better solution would be if he sends us a patch which fixes his problem.
It
is open source, isn't it? If it doesn't work for you, fix it yourself. The
more people care about some platform or configuration, the better it
works.
May b
On Tuesday 10 October 2006 17:28 Mikhail Fursov wrote:
> Nope, just the fact that there always will configurations we do not
> support. And the best we can do is to sum all of those we do support.
> For example: Linux user may read the configuration we do support, install
> all of the needed enviro
Nope, just the fact that there always will configurations we do not support.
And the best we can do is to sum all of those we do support.
For example: Linux user may read the configuration we do support, install
all of the needed environment and run the VM happily. It could better
solution (or al
On the 0x1FE day of Apache Harmony Mikhail Fursov wrote:
> On 10 Oct 2006 19:29:06 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote:
> >
> > why hide from problems? let's fix 'em all (jokingly)
> >
>
> Is it possible with Linux? :)
holy war? :)
--
Egor Pasko, Intel Managed Runtime Division
---
On 10 Oct 2006 19:29:06 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote:
why hide from problems? let's fix 'em all (jokingly)
Is it possible with Linux? :)
--
Mikhail Fursov
On the 0x1FE day of Apache Harmony Pavel Ozhdikhin wrote:
> On 10/10/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
> >
> > On 10 October 2006 at 18:52, "Pavel Ozhdikhin" <[EMAIL PROTECTED]> wrote:
> > > Oh, again! Classlib is broken on Linux right now! :(
> > > And it was not me who did this to illus
On 10/10/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
On 10 October 2006 at 18:52, "Pavel Ozhdikhin" <[EMAIL PROTECTED]> wrote:
> Oh, again! Classlib is broken on Linux right now! :(
> And it was not me who did this to illustrate the problem. :)
You are obviously using the wrong version of gcc!
On 10 October 2006 at 18:52, "Pavel Ozhdikhin" <[EMAIL PROTECTED]> wrote:
> Oh, again! Classlib is broken on Linux right now! :(
> And it was not me who did this to illustrate the problem. :)
You are obviously using the wrong version of gcc! It compiles and all
tests pass for me. ;-)
-Mark.
>
Oh, again! Classlib is broken on Linux right now! :(
And it was not me who did this to illustrate the problem. :)
On 10/10/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote:
I also think the diversity is generally good. Let's test Harmony on as
many platfroms as possible and find as many problems as
Please note that the concrete version of OS is also important. I.e.
something that works on WinXP can break on ws2003 or win2000. I have
already seen such problems.
Regards,
2006/10/10, Pavel Ozhdikhin <[EMAIL PROTECTED]>:
On 10/9/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> Hi Pavel,
>
> I'
I also think the diversity is generally good. Let's test Harmony on as
many platfroms as possible and find as many problems as we can. But I
also think that having at least one stable configuration is very
important for those who wants to work on the new features. Doing this
kind of work I'd prefe
Yes, It is reasonable and obvious.
And I believe that committers are using it already.
SY, Alexey
2006/10/10, Pavel Ozhdikhin <[EMAIL PROTECTED]>:
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
> o
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 reason
On Oct 9, 2006, at 8:52 AM, Mark Hindess wrote:
On 9 October 2006 at 16:12, "Pavel Ozhdikhin"
<[EMAIL PROTECTED]> wrote:
On 10/9/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Rana Dasgupta wrote:
We need to check both release and debug builds...the binaries
and timing
characteristics are t
On 9 October 2006 at 16:12, "Pavel Ozhdikhin" <[EMAIL PROTECTED]> wrote:
> On 10/9/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> > Rana Dasgupta wrote:
> > > We need to check both release and debug builds...the binaries and timing
> > > characteristics are too different. At this immediate stage of
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?
Thanks,
Mikhail
2006/10/9, Pavel Ozhdikhin <[EMAIL PROTECTED]>:
On 10/9/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> Rana Dasgupta wrote:
> > We need to check both relea
On 10/9/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Rana Dasgupta wrote:
> We need to check both release and debug builds...the binaries and timing
> characteristics are too different. At this immediate stage of the
> project, I
> would suggest leaving out EM64T as part of mandatory testing( unles
Tim Ellison wrote:
Rana Dasgupta wrote:
We need to check both release and debug builds...the binaries and timing
characteristics are too different. At this immediate stage of the
project, I
would suggest leaving out EM64T as part of mandatory testing( unless it is
EM64T specific functionality,
Rana Dasgupta wrote:
> We need to check both release and debug builds...the binaries and timing
> characteristics are too different. At this immediate stage of the
> project, I
> would suggest leaving out EM64T as part of mandatory testing( unless it is
> EM64T specific functionality, eg., codegen
Rana Dasgupta wrote:
On 10/6/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote:
>If we agree on common testing configs we can make sure the Harmony
>will be stable on at least this set of configurations. This does not
>mean we won't fix problems on other configurations. The goal is to
>gain and
On 10/6/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote:
>If we agree on common testing configs we can make sure the Harmony
>will be stable on at least this set of configurations. This does not
>mean we won't fix problems on other configurations. The goal is to
>gain and maintain general stabil
On 10/7/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
2006/10/6, Pavel Ozhdikhin <[EMAIL PROTECTED]>:
> What would you do if you need to commit a patch to some Linux-specific
> code in VM?
And I do not have Linux?
I will not commit this patch of course. And will ask another committer
to do this.
Pavel Ozhdikhin wrote:
What would you do if you need to commit a patch to some Linux-specific
code in VM?
Ask someone w/ a linux box to check it.
The commit criteria my be either as simple as a list of configs or
have also some exclusions. For example, there is no much sense to test
on Linu
2006/10/6, Pavel Ozhdikhin <[EMAIL PROTECTED]>:
What would you do if you need to commit a patch to some Linux-specific
code in VM?
And I do not have Linux?
I will not commit this patch of course. And will ask another committer
to do this.
Pavel, again. I understand your concern and I think that
On 10/7/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote:
What would you do if you need to commit a patch to some Linux-specific
code in VM?
The commit criteria my be either as simple as a list of configs or
have also some exclusions. For example, there is no much sense to test
on Linux a patch for
What would you do if you need to commit a patch to some Linux-specific
code in VM?
The commit criteria my be either as simple as a list of configs or
have also some exclusions. For example, there is no much sense to test
on Linux a patch for a source file which is not even compiled on
Windows.
On
I'm also not sure that ALL the commiters has Windows and Linux at the
same time...
And Nathan is an example :)
SY, Alexey
2006/10/6, Pavel Ozhdikhin <[EMAIL PROTECTED]>:
Alexey,
No, I'm not sure the committers have all the configurations. I think
most of all have Windows and Linux IA32, but I
I only have Windows/MSVC2003/IA32, if you're looking for anecdotal evidence.
On 10/6/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote:
Alexey,
No, I'm not sure the committers have all the configurations. I think
most of all have Windows and Linux IA32, but I doubt all of them have
EM64T. This is i
Alexey,
No, I'm not sure the committers have all the configurations. I think
most of all have Windows and Linux IA32, but I doubt all of them have
EM64T. This is indeed the problem and I hope together we will find the
solution. For example, we may not require classlib commits to be
tested on EM64
Pavel,
Your idea has sence. But... Are you sure that all the committers has
all the mentioned configurations?
SY, Alexey
2006/10/6, Pavel Ozhdikhin <[EMAIL PROTECTED]>:
Hello all,
This thread is about a way to improve stability in the environment of
growing patch flow in Harmony. Originally I
Hello all,
This thread is about a way to improve stability in the environment of
growing patch flow in Harmony. Originally I though about DRLVM issues
but this may be helpful for classlib too.
Currenly, before committing a patch a committer checks it on his
favorite configurations (I mean archit
50 matches
Mail list logo
