Mikhail Loenko wrote:
2006/10/16, Mikhail Fursov <[EMAIL PROTECTED]>:
On 10/16/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
>
>
> Isn't it time to define the official set of supported platforms? ;)
After reading the neighbour threads about hardware available for
commiters
and precommit cr
2006/10/16, Mikhail Fursov <[EMAIL PROTECTED]>:
On 10/16/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
>
>
> Isn't it time to define the official set of supported platforms? ;)
After reading the neighbour threads about hardware available for commiters
and precommit criteria I think that we have
On 10/16/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
Isn't it time to define the official set of supported platforms? ;)
After reading the neighbour threads about hardware available for commiters
and precommit criteria I think that we have no officially supported
platforms today (and IMO t
2006/10/16, Tim Ellison <[EMAIL PROTECTED]>:
Geir Magnusson Jr. wrote:
> Mikhail Loenko wrote:
>> 2006/10/16, Tim Ellison <[EMAIL PROTECTED]>:
>>> Mikhail Loenko wrote:
>>> > When we bring new platforms how will we make sure that a patch for
>>> some
>>> > rare platform would not break another on
2006/10/16, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
Mikhail Loenko wrote:
> 2006/10/16, Tim Ellison <[EMAIL PROTECTED]>:
>> Mikhail Loenko wrote:
>> > When we bring new platforms how will we make sure that a patch for some
>> > rare platform would not break another one?
>>
>> Beyond sniffing th
Geir Magnusson Jr. wrote:
> Mikhail Loenko wrote:
>> 2006/10/16, Tim Ellison <[EMAIL PROTECTED]>:
>>> Mikhail Loenko wrote:
>>> > When we bring new platforms how will we make sure that a patch for
>>> some
>>> > rare platform would not break another one?
>>>
>>> Beyond sniffing the patch to ensure
Mikhail Loenko wrote:
2006/10/16, Tim Ellison <[EMAIL PROTECTED]>:
Mikhail Loenko wrote:
> When we bring new platforms how will we make sure that a patch for some
> rare platform would not break another one?
Beyond sniffing the patch to ensure it looks reasonable, the best a
committer can do
2006/10/16, Tim Ellison <[EMAIL PROTECTED]>:
Mikhail Loenko wrote:
> When we bring new platforms how will we make sure that a patch for some
> rare platform would not break another one?
Beyond sniffing the patch to ensure it looks reasonable, the best a
committer can do is to test it on the plat
Mikhail Loenko wrote:
> When we bring new platforms how will we make sure that a patch for some
> rare platform would not break another one?
Beyond sniffing the patch to ensure it looks reasonable, the best a
committer can do is to test it on the platforms he or she has available.
After that we r
2006/10/16, Mikhail Loenko <[EMAIL PROTECTED]>:
2006/10/14, Tim Ellison <[EMAIL PROTECTED]>:
> Just to add my 2p -- I also agree with doing the work in the trunk. Of
> course the minimum cost of working there is that you do no harm to the
> other platforms. That is the zeroth level of integrati
2006/10/14, Tim Ellison <[EMAIL PROTECTED]>:
Just to add my 2p -- I also agree with doing the work in the trunk. Of
course the minimum cost of working there is that you do no harm to the
other platforms. That is the zeroth level of integration.
The first level of integration would then be to m
Just to add my 2p -- I also agree with doing the work in the trunk. Of
course the minimum cost of working there is that you do no harm to the
other platforms. That is the zeroth level of integration.
The first level of integration would then be to modify the build system
to build the IPF code, a
On 10/13/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
> > This is just one more argument for doing IPF porting in a separate
> branch,
> > at least since some point.
> >
> > I admit that maintaining quality and checking for regressions on new
> > platforms is a separate big problem but I
Slava Shakin wrote:
Geir,
The following scenario illustrates my point (just in case):
Let's assume that IPF porting group managed to run "hello world" on IPF in
the main trunk. The next goal might be a bit more sophisticated workload
(like Eclipse). For fast progress towards that goal the IP
If something can break IPF build it will break it during the merge. And in
this case it will take much more efforts and time to find the reason why the
build is broken. IMHO the main reason to make a separate branch is an
absolutely new implementation which will replace an existing one and this is
I'd like to mention that the vast majority of the classlib code is
buildable and executable on IPF without any additional changes. The
one exception I know, is assembler code from
luni module which supports threading. I think it could be sorted out
in the same way as it was done for em64t. Also th
Geir,
The following scenario illustrates my point (just in case):
Let's assume that IPF porting group managed to run "hello world" on IPF in
the main trunk. The next goal might be a bit more sophisticated workload
(like Eclipse). For fast progress towards that goal the IPF porting group
will no
Egor Pasko wrote:
On the 0x201 day of Apache Harmony Rana Dasgupta wrote:
I think that over time, we will start seeing IPF specific code files
appearing ... eg., quite a different jit, IPFhelpers.cpp,
IPFexception_filters.cpp, IPFnativestack.cpp, IPFprofiledrivers.cpp etc.
That is my impress
Slava Shakin wrote:
Hi,
I have an opposite concern: will the main trunk guarantee it always builds
and works on IPF.
Clearly not. It doesn't now.
IMO this will soon become critical for the IPF porting effort but will imply
passing certain pre-commit tests on IPF for any changes which pot
On the 0x201 day of Apache Harmony Rana Dasgupta wrote:
> I think that over time, we will start seeing IPF specific code files
> appearing ... eg., quite a different jit, IPFhelpers.cpp,
> IPFexception_filters.cpp, IPFnativestack.cpp, IPFprofiledrivers.cpp etc.
> That is my impression of how most
Hi,
I have an opposite concern: will the main trunk guarantee it always builds
and works on IPF.
IMO this will soon become critical for the IPF porting effort but will imply
passing certain pre-commit tests on IPF for any changes which potentially
affect working on this platform. Which relates
On 10/13/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
It's harmless now...given it's not interfering with the other stuff,
what's the problem?
Geir,
your proposal "to solve a problem only when you feel that it is a problem"
sounds reasonable.
Right now IPF code is harmless and we can tr
Mikhail Fursov wrote:
The current state of the IPF code in our codebase is "it won't build". So
there are a lot of things to do before running first test.
And for -every- commit of the IPF code IPF developers plus every commiter
have to check that their changes do not break IA32/EM64T build.
If
Rana Dasgupta wrote:
I think that over time, we will start seeing IPF specific code files
appearing ... eg., quite a different jit, IPFhelpers.cpp,
IPFexception_filters.cpp, IPFnativestack.cpp, IPFprofiledrivers.cpp etc.
That is my impression of how most IPF ports go. Even in the main codebas
The current state of the IPF code in our codebase is "it won't build". So
there are a lot of things to do before running first test.
And for -every- commit of the IPF code IPF developers plus every commiter
have to check that their changes do not break IA32/EM64T build.
If you even could not built
I think that over time, we will start seeing IPF specific code files
appearing ... eg., quite a different jit, IPFhelpers.cpp,
IPFexception_filters.cpp, IPFnativestack.cpp, IPFprofiledrivers.cpp etc.
That is my impression of how most IPF ports go. Even in the main codebase
they will virtually be
On Friday 13 October 2006 01:37 Geir Magnusson Jr. wrote:
> How about trying to do in main line for now, reserving branch until needed?
>
> We'd agree that committers put in the patches and test on supported
> platforms (not IPF) and those doing the IPF work test and adjust as
> necessary.
>
> That
How about trying to do in main line for now, reserving branch until needed?
We'd agree that committers put in the patches and test on supported
platforms (not IPF) and those doing the IPF work test and adjust as
necessary.
That way, we at least try to keep one codeline that we know works. It
Rana,
I support the first item: to have a separate branch for IPF with periodical
merges to the trunk. Do tests only on merge.
IMO it will simplify the startup for IPF contributors.
Once IPF is ready to run apps as our IA32 version does it will be the time
to move IPF into the trunk.
+ Are there
Hi,
There is incomplete support for IPF platforms in the DRLVM codebase, as
many may have seen. It would be nice to complete it. There are a couple of
issues on how to start this. IPF specific changes are likely to be quite
significant, including changes in the JIT, garbage collector(s), exceptio
30 matches
Mail list logo
