You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2006/05/17 16:35:40 UTC
Re: towards a new implementation of java.math
Daniel,
I've just contributed a JIRA,
http://issues.apache.org/jira/browse/HARMONY-471
that integrates the ITC rmi implementation as modules/rmi. (The jsr14
version. Only the code at the moment, I creating the scripts/patches
for the tests next.)
In this JIRA, I modified the build ant files to support a property,
'hy.rmi.module', which defaults to 'rmi'. I did this so that, if we
integrate the Intel implementationas modules/rmi-intel, developers can
easily build/test the different implementation just by overriding the
property on the ant command line. For example:
ant -f make/build.xml -Dhy.rmi.module=rmi-intel
It would be quite trivial to do the same for the math implementations
(and crypto I suppose). If we were to do this, perhaps the process of
analysis and creation of a combined implementation could be done within
the project? In public and with more potential contributions.
What do you think?
Regards,
Mark.
On 17 May 2006 at 11:19, "Daniel Fridlender" <df...@gmail.com> wrote:
> Hi,
>
> After a discussion we had a few weeks ago in this forum on the
> different implementations of java.math donated to Harmony
> (Harmony-(39+380) and Harmony-199) we (ITC) decided to voluteer for
> the task of integrating them into a single implementation which would
> benefit from the best features of Harmony-39, 380 and 199.
>
> We will consider comparing on a method-by-method level but also on
> ideas level so that the new implementation will probably require
> re-programming good ideas from the existing implementations. In the
> case of BigInteger we will also compare the benefits of the different
> internal representations.
>
> Right now we are analysing the two implementations. Once we are done
> with this analysis we will make it public and propose a way to proceed
> towards an integration.
>
> BTW, we had problems patching Harmony-380 over Harmony-39, it attempts
> to erase non-existing lines. Did we miss something? Is there any
> other intermediate patch that we have missed?
>
> Regards,
>
> Daniel Fridlender
> ITC
>
> ---------------------------------------------------------------------
> Terms of use : 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
---------------------------------------------------------------------
Terms of use : 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
Re: towards a new implementation of java.math
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Daniel Gandara wrote:
> Mark Hindess wrote:
>>
>> Daniel,
>>
>> I've just contributed a JIRA,
>> http://issues.apache.org/jira/browse/HARMONY-471
>> that integrates the ITC rmi implementation as modules/rmi. (The jsr14
>> version. Only the code at the moment, I creating the scripts/patches
>> for the tests next.)
>
> We've been working on improvements to the rmi test suite,
> I've contributed that at http://issues.apache.org/jira/browse/HARMONY-473
> (I created a new JIRA since previous one HARMONY-211 was closed-)
> so please take that test suite.
I think we should avoid adding too much to exsting JIRAs, because it can
get messy if some stuff is accepted, some isn't, etc.
There is little additional cost for adding a new JIRA, and we can link
them to keep track of related things...
geir
---------------------------------------------------------------------
Terms of use : 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
Re: towards a new implementation of java.math
Posted by Daniel Fridlender <df...@gmail.com>.
Hi Mark,
On 5/17/06, Daniel Gandara <da...@neosur.com> wrote:
> Mark Hindess wrote:
> >
> > It would be quite trivial to do the same for the math implementations
> > (and crypto I suppose). If we were to do this, perhaps the process of
> > analysis and creation of a combined implementation could be done within
> > the project? In public and with more potential contributions.
> >
> > What do you think?
>
> looks like a good and easy solution to handle packages with multiple
> contributions; I'll let Daniel (Fridlender) to answer since he is the one
> leading math :)
I agree. Would you create a new jira with this for math? Then I
would upload there a document with the result of our comparison and a
proposal for a combination of the two implementations.
Thanks
Daniel Fridlender
ITC
>
> >
> > Regards,
> > Mark.
>
> Thanks,
>
> Daniel Gandara
> BTW: we are a bunch of Daniels here at Cordoba :)))
>
> >
> > On 17 May 2006 at 11:19, "Daniel Fridlender" <df...@gmail.com>
> > wrote:
> >> Hi,
> >>
> >> After a discussion we had a few weeks ago in this forum on the
> >> different implementations of java.math donated to Harmony
> >> (Harmony-(39+380) and Harmony-199) we (ITC) decided to voluteer for
> >> the task of integrating them into a single implementation which would
> >> benefit from the best features of Harmony-39, 380 and 199.
> >>
> >> We will consider comparing on a method-by-method level but also on
> >> ideas level so that the new implementation will probably require
> >> re-programming good ideas from the existing implementations. In the
> >> case of BigInteger we will also compare the benefits of the different
> >> internal representations.
> >>
> >> Right now we are analysing the two implementations. Once we are done
> >> with this analysis we will make it public and propose a way to proceed
> >> towards an integration.
> >>
> >> BTW, we had problems patching Harmony-380 over Harmony-39, it attempts
> >> to erase non-existing lines. Did we miss something? Is there any
> >> other intermediate patch that we have missed?
> >>
> >> Regards,
> >>
> >> Daniel Fridlender
> >> ITC
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : 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
> >
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : 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
> >
>
>
>
> ---------------------------------------------------------------------
> Terms of use : 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
>
>
---------------------------------------------------------------------
Terms of use : 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
Re: towards a new implementation of java.math
Posted by Daniel Gandara <da...@neosur.com>.
Mark Hindess wrote:
>
> Daniel,
>
> I've just contributed a JIRA,
> http://issues.apache.org/jira/browse/HARMONY-471
> that integrates the ITC rmi implementation as modules/rmi. (The jsr14
> version. Only the code at the moment, I creating the scripts/patches
> for the tests next.)
We've been working on improvements to the rmi test suite,
I've contributed that at http://issues.apache.org/jira/browse/HARMONY-473
(I created a new JIRA since previous one HARMONY-211 was closed-)
so please take that test suite.
> In this JIRA, I modified the build ant files to support a property,
> 'hy.rmi.module', which defaults to 'rmi'. I did this so that, if we
> integrate the Intel implementationas modules/rmi-intel, developers can
> easily build/test the different implementation just by overriding the
> property on the ant command line. For example:
>
> ant -f make/build.xml -Dhy.rmi.module=rmi-intel
>
> It would be quite trivial to do the same for the math implementations
> (and crypto I suppose). If we were to do this, perhaps the process of
> analysis and creation of a combined implementation could be done within
> the project? In public and with more potential contributions.
>
> What do you think?
looks like a good and easy solution to handle packages with multiple
contributions; I'll let Daniel (Fridlender) to answer since he is the one
leading math :)
>
> Regards,
> Mark.
Thanks,
Daniel Gandara
BTW: we are a bunch of Daniels here at Cordoba :)))
>
> On 17 May 2006 at 11:19, "Daniel Fridlender" <df...@gmail.com>
> wrote:
>> Hi,
>>
>> After a discussion we had a few weeks ago in this forum on the
>> different implementations of java.math donated to Harmony
>> (Harmony-(39+380) and Harmony-199) we (ITC) decided to voluteer for
>> the task of integrating them into a single implementation which would
>> benefit from the best features of Harmony-39, 380 and 199.
>>
>> We will consider comparing on a method-by-method level but also on
>> ideas level so that the new implementation will probably require
>> re-programming good ideas from the existing implementations. In the
>> case of BigInteger we will also compare the benefits of the different
>> internal representations.
>>
>> Right now we are analysing the two implementations. Once we are done
>> with this analysis we will make it public and propose a way to proceed
>> towards an integration.
>>
>> BTW, we had problems patching Harmony-380 over Harmony-39, it attempts
>> to erase non-existing lines. Did we miss something? Is there any
>> other intermediate patch that we have missed?
>>
>> Regards,
>>
>> Daniel Fridlender
>> ITC
>>
>> ---------------------------------------------------------------------
>> Terms of use : 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
>
>
>
> ---------------------------------------------------------------------
> Terms of use : 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
>
---------------------------------------------------------------------
Terms of use : 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
Re: Moving forward with RMI and Math ( was Re: towards a new implementation of java.math)
Posted by Mikhail Loenko <ml...@gmail.com>.
I think that contribution authors and everyone who is interested in the areas
will control that their best ideas go to the merged version.
It seems that we do not need a special document about that
Thanks,
Mikhail
2006/5/24, Vladimir Gorr <vv...@gmail.com>:
> Who will control the accuracy of this process (I mean merging)?
> Obviously we need to have the document substantiating that or other choice.
> What do you think?
>
> Thanks,
> Vladimir.
>
> On 5/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
> >
> > 2006/5/24, Geir Magnusson Jr <ge...@pobox.com>:
> > > I'd like to propose that we choose what we judge to be the best RMI
> > > implementation, and the best math implementation now so we can move
> > > forward, with the understanding that anyone interested can continue to
> > > work to merge the additional contributions into whatever was chosen.
> > +1
> >
> > I suggest that as a base we take RMI from Intel as it seems to be
> > interoperable
> > with RI and take Math from ITC as it reportedly has better performance.
> >
> > Then we will aplly best ideas from counterparts implementations to the
> > base.
> >
> > Does it work for everyone?
> >
> > Thanks,
> > Mikhail
> >
> > >
> > > We then get out of the "cross patch between HARMONY-Y and HARMONY-X"
> > > stuff...
> > >
> > > I don't mind keeping rmi1, rmi2, rmi3, math1, math2, etc as long as we
> > > have "rmi" and "math" which are understood to be the ones we're moving
> > > with at this moment. it's kinda confusing right now...
> > >
> > > Thoughts?
> > >
> > > geir
> > >
> > >
> > > Mark Hindess wrote:
> > > > Daniel,
> > > >
> > > > I've just contributed a JIRA,
> > > >
> > > > http://issues.apache.org/jira/browse/HARMONY-471
> > > >
> > > > that integrates the ITC rmi implementation as modules/rmi. (The jsr14
> > > > version. Only the code at the moment, I creating the scripts/patches
> > > > for the tests next.)
> > > >
> > > > In this JIRA, I modified the build ant files to support a property,
> > > > 'hy.rmi.module', which defaults to 'rmi'. I did this so that, if we
> > > > integrate the Intel implementationas modules/rmi-intel, developers can
> > > > easily build/test the different implementation just by overriding the
> > > > property on the ant command line. For example:
> > > >
> > > > ant -f make/build.xml -Dhy.rmi.module=rmi-intel
> > > >
> > > > It would be quite trivial to do the same for the math implementations
> > > > (and crypto I suppose). If we were to do this, perhaps the process of
> > > > analysis and creation of a combined implementation could be done
> > within
> > > > the project? In public and with more potential contributions.
> > > >
> > > > What do you think?
> > > >
> > > > Regards,
> > > > Mark.
> > > >
> > > > On 17 May 2006 at 11:19, "Daniel Fridlender" <df...@gmail.com>
> > wrote:
> > > >> Hi,
> > > >>
> > > >> After a discussion we had a few weeks ago in this forum on the
> > > >> different implementations of java.math donated to Harmony
> > > >> (Harmony-(39+380) and Harmony-199) we (ITC) decided to voluteer for
> > > >> the task of integrating them into a single implementation which would
> > > >> benefit from the best features of Harmony-39, 380 and 199.
> > > >>
> > > >> We will consider comparing on a method-by-method level but also on
> > > >> ideas level so that the new implementation will probably require
> > > >> re-programming good ideas from the existing implementations. In the
> > > >> case of BigInteger we will also compare the benefits of the different
> > > >> internal representations.
> > > >>
> > > >> Right now we are analysing the two implementations. Once we are done
> > > >> with this analysis we will make it public and propose a way to
> > proceed
> > > >> towards an integration.
> > > >>
> > > >> BTW, we had problems patching Harmony-380 over Harmony-39, it
> > attempts
> > > >> to erase non-existing lines. Did we miss something? Is there any
> > > >> other intermediate patch that we have missed?
> > > >>
> > > >> Regards,
> > > >>
> > > >> Daniel Fridlender
> > > >> ITC
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> Terms of use : 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
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > Terms of use : 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
> > > >
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : 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
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > Terms of use : 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
> >
> >
>
>
---------------------------------------------------------------------
Terms of use : 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
Re: Moving forward with RMI and Math ( was Re: towards a new implementation of java.math)
Posted by Vladimir Gorr <vv...@gmail.com>.
Who will control the accuracy of this process (I mean merging)?
Obviously we need to have the document substantiating that or other choice.
What do you think?
Thanks,
Vladimir.
On 5/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
>
> 2006/5/24, Geir Magnusson Jr <ge...@pobox.com>:
> > I'd like to propose that we choose what we judge to be the best RMI
> > implementation, and the best math implementation now so we can move
> > forward, with the understanding that anyone interested can continue to
> > work to merge the additional contributions into whatever was chosen.
> +1
>
> I suggest that as a base we take RMI from Intel as it seems to be
> interoperable
> with RI and take Math from ITC as it reportedly has better performance.
>
> Then we will aplly best ideas from counterparts implementations to the
> base.
>
> Does it work for everyone?
>
> Thanks,
> Mikhail
>
> >
> > We then get out of the "cross patch between HARMONY-Y and HARMONY-X"
> > stuff...
> >
> > I don't mind keeping rmi1, rmi2, rmi3, math1, math2, etc as long as we
> > have "rmi" and "math" which are understood to be the ones we're moving
> > with at this moment. it's kinda confusing right now...
> >
> > Thoughts?
> >
> > geir
> >
> >
> > Mark Hindess wrote:
> > > Daniel,
> > >
> > > I've just contributed a JIRA,
> > >
> > > http://issues.apache.org/jira/browse/HARMONY-471
> > >
> > > that integrates the ITC rmi implementation as modules/rmi. (The jsr14
> > > version. Only the code at the moment, I creating the scripts/patches
> > > for the tests next.)
> > >
> > > In this JIRA, I modified the build ant files to support a property,
> > > 'hy.rmi.module', which defaults to 'rmi'. I did this so that, if we
> > > integrate the Intel implementationas modules/rmi-intel, developers can
> > > easily build/test the different implementation just by overriding the
> > > property on the ant command line. For example:
> > >
> > > ant -f make/build.xml -Dhy.rmi.module=rmi-intel
> > >
> > > It would be quite trivial to do the same for the math implementations
> > > (and crypto I suppose). If we were to do this, perhaps the process of
> > > analysis and creation of a combined implementation could be done
> within
> > > the project? In public and with more potential contributions.
> > >
> > > What do you think?
> > >
> > > Regards,
> > > Mark.
> > >
> > > On 17 May 2006 at 11:19, "Daniel Fridlender" <df...@gmail.com>
> wrote:
> > >> Hi,
> > >>
> > >> After a discussion we had a few weeks ago in this forum on the
> > >> different implementations of java.math donated to Harmony
> > >> (Harmony-(39+380) and Harmony-199) we (ITC) decided to voluteer for
> > >> the task of integrating them into a single implementation which would
> > >> benefit from the best features of Harmony-39, 380 and 199.
> > >>
> > >> We will consider comparing on a method-by-method level but also on
> > >> ideas level so that the new implementation will probably require
> > >> re-programming good ideas from the existing implementations. In the
> > >> case of BigInteger we will also compare the benefits of the different
> > >> internal representations.
> > >>
> > >> Right now we are analysing the two implementations. Once we are done
> > >> with this analysis we will make it public and propose a way to
> proceed
> > >> towards an integration.
> > >>
> > >> BTW, we had problems patching Harmony-380 over Harmony-39, it
> attempts
> > >> to erase non-existing lines. Did we miss something? Is there any
> > >> other intermediate patch that we have missed?
> > >>
> > >> Regards,
> > >>
> > >> Daniel Fridlender
> > >> ITC
> > >>
> > >> ---------------------------------------------------------------------
> > >> Terms of use : 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
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : 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
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : 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
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : 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
>
>
Re: Moving forward with RMI and Math ( was Re: towards a new implementation of java.math)
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/5/24, Stepan Mishura <st...@gmail.com>:
> On 5/24/06, Mikhail Loenko wrote:
> >
> > 2006/5/24, Geir Magnusson Jr :
> > > I'd like to propose that we choose what we judge to be the best RMI
> > > implementation, and the best math implementation now so we can move
> > > forward, with the understanding that anyone interested can continue to
> > > work to merge the additional contributions into whatever was chosen.
> > +1
> >
> > I suggest that as a base we take RMI from Intel as it seems to be
> > interoperable
> > with RI and take Math from ITC as it reportedly has better performance.
>
>
> Hmm, I guess that 'base implementation' is implementation that locates in
> modules/rmi. Right?
yes
> But I resolved HARMONY-471 5 days ago and ITC implementation is now in
> modules/rmi folder. Do you suggest moving it to another folder?
We now have three RMI implementations:
rmi - 1.4 implementation from ITC
rmi2 - 1.5 implementation from ITC
rmi3 - implementation from Intel
As it was discussed in the mail list (please correct me if it is no
more the case)
the only implementation interoperable with RI is rmi3.
As a first step I suggest taking it as a base - move rmi to rmi4 or
whatever and
move rmi3 to rmi.
Thanks,
Mikhail
>
> Then we will aplly best ideas from counterparts implementations to the base.
>
>
> I'd concentrate first on pulling out implementation-independent tests from
> both contributions and creating RMI test suite that can be used to evaluate
> both implementations.
>
> Thanks,
> Stepan.
>
> Does it work for everyone?
> >
> > Thanks,
> > Mikhail
> >
> > >
> > > We then get out of the "cross patch between HARMONY-Y and HARMONY-X"
> > > stuff...
> > >
> > > I don't mind keeping rmi1, rmi2, rmi3, math1, math2, etc as long as we
> > > have "rmi" and "math" which are understood to be the ones we're moving
> > > with at this moment. it's kinda confusing right now...
> > >
> > > Thoughts?
> > >
> > > geir
> > >
> > >
> > > Mark Hindess wrote:
> > > > Daniel,
> > > >
> > > > I've just contributed a JIRA,
> > > >
> > > > http://issues.apache.org/jira/browse/HARMONY-471
> > > >
> > > > that integrates the ITC rmi implementation as modules/rmi. (The jsr14
> > > > version. Only the code at the moment, I creating the scripts/patches
> > > > for the tests next.)
> > > >
> > > > In this JIRA, I modified the build ant files to support a property,
> > > > 'hy.rmi.module', which defaults to 'rmi'. I did this so that, if we
> > > > integrate the Intel implementationas modules/rmi-intel, developers can
> > > > easily build/test the different implementation just by overriding the
> > > > property on the ant command line. For example:
> > > >
> > > > ant -f make/build.xml -Dhy.rmi.module=rmi-intel
> > > >
> > > > It would be quite trivial to do the same for the math implementations
> > > > (and crypto I suppose). If we were to do this, perhaps the process of
> > > > analysis and creation of a combined implementation could be done
> > within
> > > > the project? In public and with more potential contributions.
> > > >
> > > > What do you think?
> > > >
> > > > Regards,
> > > > Mark.
> > > >
> > > > On 17 May 2006 at 11:19, "Daniel Fridlender" <df...@gmail.com>
> > wrote:
> > > >> Hi,
> > > >>
> > > >> After a discussion we had a few weeks ago in this forum on the
> > > >> different implementations of java.math donated to Harmony
> > > >> (Harmony-(39+380) and Harmony-199) we (ITC) decided to voluteer for
> > > >> the task of integrating them into a single implementation which would
> > > >> benefit from the best features of Harmony-39, 380 and 199.
> > > >>
> > > >> We will consider comparing on a method-by-method level but also on
> > > >> ideas level so that the new implementation will probably require
> > > >> re-programming good ideas from the existing implementations. In the
> > > >> case of BigInteger we will also compare the benefits of the different
> > > >> internal representations.
> > > >>
> > > >> Right now we are analysing the two implementations. Once we are done
> > > >> with this analysis we will make it public and propose a way to
> > proceed
> > > >> towards an integration.
> > > >>
> > > >> BTW, we had problems patching Harmony-380 over Harmony-39, it
> > attempts
> > > >> to erase non-existing lines. Did we miss something? Is there any
> > > >> other intermediate patch that we have missed?
> > > >>
> > > >> Regards,
> > > >>
> > > >> Daniel Fridlender
> > > >> ITC
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> Terms of use : 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
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > Terms of use : 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
> > > >
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : 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
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > Terms of use : 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
> >
> >
>
>
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
> ------------------------------------------------------
> Terms of use : 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
>
>
---------------------------------------------------------------------
Terms of use : 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
Re: Moving forward with RMI and Math ( was Re: towards a new implementation of java.math)
Posted by Stepan Mishura <st...@gmail.com>.
On 5/24/06, Mikhail Loenko wrote:
>
> 2006/5/24, Geir Magnusson Jr :
> > I'd like to propose that we choose what we judge to be the best RMI
> > implementation, and the best math implementation now so we can move
> > forward, with the understanding that anyone interested can continue to
> > work to merge the additional contributions into whatever was chosen.
> +1
>
> I suggest that as a base we take RMI from Intel as it seems to be
> interoperable
> with RI and take Math from ITC as it reportedly has better performance.
Hmm, I guess that 'base implementation' is implementation that locates in
modules/rmi. Right?
But I resolved HARMONY-471 5 days ago and ITC implementation is now in
modules/rmi folder. Do you suggest moving it to another folder?
Then we will aplly best ideas from counterparts implementations to the base.
I'd concentrate first on pulling out implementation-independent tests from
both contributions and creating RMI test suite that can be used to evaluate
both implementations.
Thanks,
Stepan.
Does it work for everyone?
>
> Thanks,
> Mikhail
>
> >
> > We then get out of the "cross patch between HARMONY-Y and HARMONY-X"
> > stuff...
> >
> > I don't mind keeping rmi1, rmi2, rmi3, math1, math2, etc as long as we
> > have "rmi" and "math" which are understood to be the ones we're moving
> > with at this moment. it's kinda confusing right now...
> >
> > Thoughts?
> >
> > geir
> >
> >
> > Mark Hindess wrote:
> > > Daniel,
> > >
> > > I've just contributed a JIRA,
> > >
> > > http://issues.apache.org/jira/browse/HARMONY-471
> > >
> > > that integrates the ITC rmi implementation as modules/rmi. (The jsr14
> > > version. Only the code at the moment, I creating the scripts/patches
> > > for the tests next.)
> > >
> > > In this JIRA, I modified the build ant files to support a property,
> > > 'hy.rmi.module', which defaults to 'rmi'. I did this so that, if we
> > > integrate the Intel implementationas modules/rmi-intel, developers can
> > > easily build/test the different implementation just by overriding the
> > > property on the ant command line. For example:
> > >
> > > ant -f make/build.xml -Dhy.rmi.module=rmi-intel
> > >
> > > It would be quite trivial to do the same for the math implementations
> > > (and crypto I suppose). If we were to do this, perhaps the process of
> > > analysis and creation of a combined implementation could be done
> within
> > > the project? In public and with more potential contributions.
> > >
> > > What do you think?
> > >
> > > Regards,
> > > Mark.
> > >
> > > On 17 May 2006 at 11:19, "Daniel Fridlender" <df...@gmail.com>
> wrote:
> > >> Hi,
> > >>
> > >> After a discussion we had a few weeks ago in this forum on the
> > >> different implementations of java.math donated to Harmony
> > >> (Harmony-(39+380) and Harmony-199) we (ITC) decided to voluteer for
> > >> the task of integrating them into a single implementation which would
> > >> benefit from the best features of Harmony-39, 380 and 199.
> > >>
> > >> We will consider comparing on a method-by-method level but also on
> > >> ideas level so that the new implementation will probably require
> > >> re-programming good ideas from the existing implementations. In the
> > >> case of BigInteger we will also compare the benefits of the different
> > >> internal representations.
> > >>
> > >> Right now we are analysing the two implementations. Once we are done
> > >> with this analysis we will make it public and propose a way to
> proceed
> > >> towards an integration.
> > >>
> > >> BTW, we had problems patching Harmony-380 over Harmony-39, it
> attempts
> > >> to erase non-existing lines. Did we miss something? Is there any
> > >> other intermediate patch that we have missed?
> > >>
> > >> Regards,
> > >>
> > >> Daniel Fridlender
> > >> ITC
> > >>
> > >> ---------------------------------------------------------------------
> > >> Terms of use : 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
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : 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
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : 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
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : 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
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
Terms of use : 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
Re: Moving forward with RMI and Math ( was Re: towards a new implementation of java.math)
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/5/24, Geir Magnusson Jr <ge...@pobox.com>:
> I'd like to propose that we choose what we judge to be the best RMI
> implementation, and the best math implementation now so we can move
> forward, with the understanding that anyone interested can continue to
> work to merge the additional contributions into whatever was chosen.
+1
I suggest that as a base we take RMI from Intel as it seems to be interoperable
with RI and take Math from ITC as it reportedly has better performance.
Then we will aplly best ideas from counterparts implementations to the base.
Does it work for everyone?
Thanks,
Mikhail
>
> We then get out of the "cross patch between HARMONY-Y and HARMONY-X"
> stuff...
>
> I don't mind keeping rmi1, rmi2, rmi3, math1, math2, etc as long as we
> have "rmi" and "math" which are understood to be the ones we're moving
> with at this moment. it's kinda confusing right now...
>
> Thoughts?
>
> geir
>
>
> Mark Hindess wrote:
> > Daniel,
> >
> > I've just contributed a JIRA,
> >
> > http://issues.apache.org/jira/browse/HARMONY-471
> >
> > that integrates the ITC rmi implementation as modules/rmi. (The jsr14
> > version. Only the code at the moment, I creating the scripts/patches
> > for the tests next.)
> >
> > In this JIRA, I modified the build ant files to support a property,
> > 'hy.rmi.module', which defaults to 'rmi'. I did this so that, if we
> > integrate the Intel implementationas modules/rmi-intel, developers can
> > easily build/test the different implementation just by overriding the
> > property on the ant command line. For example:
> >
> > ant -f make/build.xml -Dhy.rmi.module=rmi-intel
> >
> > It would be quite trivial to do the same for the math implementations
> > (and crypto I suppose). If we were to do this, perhaps the process of
> > analysis and creation of a combined implementation could be done within
> > the project? In public and with more potential contributions.
> >
> > What do you think?
> >
> > Regards,
> > Mark.
> >
> > On 17 May 2006 at 11:19, "Daniel Fridlender" <df...@gmail.com> wrote:
> >> Hi,
> >>
> >> After a discussion we had a few weeks ago in this forum on the
> >> different implementations of java.math donated to Harmony
> >> (Harmony-(39+380) and Harmony-199) we (ITC) decided to voluteer for
> >> the task of integrating them into a single implementation which would
> >> benefit from the best features of Harmony-39, 380 and 199.
> >>
> >> We will consider comparing on a method-by-method level but also on
> >> ideas level so that the new implementation will probably require
> >> re-programming good ideas from the existing implementations. In the
> >> case of BigInteger we will also compare the benefits of the different
> >> internal representations.
> >>
> >> Right now we are analysing the two implementations. Once we are done
> >> with this analysis we will make it public and propose a way to proceed
> >> towards an integration.
> >>
> >> BTW, we had problems patching Harmony-380 over Harmony-39, it attempts
> >> to erase non-existing lines. Did we miss something? Is there any
> >> other intermediate patch that we have missed?
> >>
> >> Regards,
> >>
> >> Daniel Fridlender
> >> ITC
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : 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
> >
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : 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
> >
> >
>
>
> ---------------------------------------------------------------------
> Terms of use : 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
>
>
---------------------------------------------------------------------
Terms of use : 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
Moving forward with RMI and Math ( was Re: towards a new implementation
of java.math)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
I'd like to propose that we choose what we judge to be the best RMI
implementation, and the best math implementation now so we can move
forward, with the understanding that anyone interested can continue to
work to merge the additional contributions into whatever was chosen.
We then get out of the "cross patch between HARMONY-Y and HARMONY-X"
stuff...
I don't mind keeping rmi1, rmi2, rmi3, math1, math2, etc as long as we
have "rmi" and "math" which are understood to be the ones we're moving
with at this moment. it's kinda confusing right now...
Thoughts?
geir
Mark Hindess wrote:
> Daniel,
>
> I've just contributed a JIRA,
>
> http://issues.apache.org/jira/browse/HARMONY-471
>
> that integrates the ITC rmi implementation as modules/rmi. (The jsr14
> version. Only the code at the moment, I creating the scripts/patches
> for the tests next.)
>
> In this JIRA, I modified the build ant files to support a property,
> 'hy.rmi.module', which defaults to 'rmi'. I did this so that, if we
> integrate the Intel implementationas modules/rmi-intel, developers can
> easily build/test the different implementation just by overriding the
> property on the ant command line. For example:
>
> ant -f make/build.xml -Dhy.rmi.module=rmi-intel
>
> It would be quite trivial to do the same for the math implementations
> (and crypto I suppose). If we were to do this, perhaps the process of
> analysis and creation of a combined implementation could be done within
> the project? In public and with more potential contributions.
>
> What do you think?
>
> Regards,
> Mark.
>
> On 17 May 2006 at 11:19, "Daniel Fridlender" <df...@gmail.com> wrote:
>> Hi,
>>
>> After a discussion we had a few weeks ago in this forum on the
>> different implementations of java.math donated to Harmony
>> (Harmony-(39+380) and Harmony-199) we (ITC) decided to voluteer for
>> the task of integrating them into a single implementation which would
>> benefit from the best features of Harmony-39, 380 and 199.
>>
>> We will consider comparing on a method-by-method level but also on
>> ideas level so that the new implementation will probably require
>> re-programming good ideas from the existing implementations. In the
>> case of BigInteger we will also compare the benefits of the different
>> internal representations.
>>
>> Right now we are analysing the two implementations. Once we are done
>> with this analysis we will make it public and propose a way to proceed
>> towards an integration.
>>
>> BTW, we had problems patching Harmony-380 over Harmony-39, it attempts
>> to erase non-existing lines. Did we miss something? Is there any
>> other intermediate patch that we have missed?
>>
>> Regards,
>>
>> Daniel Fridlender
>> ITC
>>
>> ---------------------------------------------------------------------
>> Terms of use : 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
>
>
>
> ---------------------------------------------------------------------
> Terms of use : 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
>
>
---------------------------------------------------------------------
Terms of use : 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