|
Addition of Mach-O 64 Binary Parser to 6.0.2
Hi, There is a contribution of Mach-O binary parser for Mac 64 bit. In CDT 6.1 it is being added as a new parser. I believe it would be valuable addition to 6.0.X stream as well. Technically it introduces new API and API changes for maintenance stream are not allowed but in this case I would advocate to add it there.
Does anybody have an objection?
Andrew _______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
|
Re: Addition of Mach-O 64 Binary Parser to 6.0.2
Coming from a _user_ this would be great!. Currently have to switch to
Xcode to debug my apps.
--
Mike Jackson <www.bluequartz.net>
On Nov 3, 2009, at 12:18 PM, Andrew Gvozdev wrote:
> Hi,
> There is a contribution of Mach-O binary parser for Mac 64 bit. In
> CDT 6.1 it is being added as a new parser. I believe it would be
> valuable addition to 6.0.X stream as well. Technically it introduces
> new API and API changes for maintenance stream are not allowed but
> in this case I would advocate to add it there.
>
> Does anybody have an objection?
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=270790>
> Andrew
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
|
 Re: Addition of Mach-O 64 Binary Parser to 6.0.2
I don't believe new API is a problem, even for a maintenance
release. I think stability is the key. Any significant amount of code,
API-related or not, that can destabilize existing features is what we
should avoid. I think a new binary parser is a safe addition, as long as
it hasn't mucked around much with the underlying support code.
John
At 11:18 AM 11/3/2009, Andrew Gvozdev wrote:
Hi,
There is a contribution of Mach-O binary parser for Mac 64 bit. In CDT
6.1 it is being added as a new parser. I believe it would be valuable
addition to 6.0.X stream as well. Technically it introduces new API and
API changes for maintenance stream are not allowed but in this case I
would advocate to add it there.
Does anybody have an objection?
https://bugs.eclipse.org/bugs/show_bug.cgi?id=270790
Andrew
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
|
Re: Addition of Mach-O 64 Binary Parser to 6.0.2
The problem with adding new API on the maintenance stream is that any client bundle that wants to use this new API needs a new minor version (x.y) of the bundle that supplies the API, in order to sensibly express a new lower bound in its dependency range. However, the supplier bundle can't actually raise its version to the next minor number because then (a) it will conflict with the minor version increment of the next release and (b) it will no longer look like a service release, so user installs performing service updates won't get anything.
If this really is new public API, then adding it in the maintenance stream is certain to break some client workflows.
Cheers,
Christian
On Tue, 2009-11-03 at 11:27 -0600, John Cortell wrote:
I don't believe new API is a problem, even for a maintenance release. I think stability is the key. Any significant amount of code, API-related or not, that can destabilize existing features is what we should avoid. I think a new binary parser is a safe addition, as long as it hasn't mucked around much with the underlying support code.
John
At 11:18 AM 11/3/2009, Andrew Gvozdev wrote:
Hi,
There is a contribution of Mach-O binary parser for Mac 64 bit. In CDT 6.1 it is being added as a new parser. I believe it would be valuable addition to 6.0.X stream as well. Technically it introduces new API and API changes for maintenance stream are not allowed but in this case I would advocate to add it there.
Does anybody have an objection?
https://bugs.eclipse.org/bugs/show_bug.cgi?id=270790
Andrew
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
|
Re: Addition of Mach-O 64 Binary Parser to 6.0.2
I am all for stable codes and APIs and such but CDT is rapidly
becoming useless on OS X. Between the lack of a 64 bit parser (which
means no 64 Bit debugging) and the severe issues with the debugger and
threads I would like to see these items fixed sooner rather than
later, but I am probably the vocal minority here so I'll just say it
once and leave it to whomever makes the decisions.
CDT is a great IDE to use. The Indexer, Syntax Highlighting, macro
expansion and code navigation features have not been matched with any
of the other major IDEs that I use (MS VS 2008 with V Assist X and
Xcode). Since Apple has moved to x86_64 as the default arch for GCC to
create this has added even more problems for OS X C/C++ developers to
use CDT. Add to that the other debugging issues as laid out above and
you get a really bad experience on OS X. I'll now step off the soap
box..
--
Mike Jackson <www.bluequartz.net>
On Nov 3, 2009, at 12:41 PM, Christian W. Damus wrote:
> The problem with adding new API on the maintenance stream is that
> any client bundle that wants to use this new API needs a new minor
> version (x.y) of the bundle that supplies the API, in order to
> sensibly express a new lower bound in its dependency range.
> However, the supplier bundle can't actually raise its version to the
> next minor number because then (a) it will conflict with the minor
> version increment of the next release and (b) it will no longer look
> like a service release, so user installs performing service updates
> won't get anything.
>
> If this really is new public API, then adding it in the maintenance
> stream is certain to break some client workflows.
>
> Cheers,
>
> Christian
>
>
> On Tue, 2009-11-03 at 11:27 -0600, John Cortell wrote:
>> I don't believe new API is a problem, even for a maintenance
>> release. I think stability is the key. Any significant amount of
>> code, API-related or not, that can destabilize existing features is
>> what we should avoid. I think a new binary parser is a safe
>> addition, as long as it hasn't mucked around much with the
>> underlying support code.
>>
>> John
>>
>> At 11:18 AM 11/3/2009, Andrew Gvozdev wrote:
>>> Hi,
>>> There is a contribution of Mach-O binary parser for Mac 64 bit. In
>>> CDT 6.1 it is being added as a new parser. I believe it would be
>>> valuable addition to 6.0.X stream as well. Technically it
>>> introduces new API and API changes for maintenance stream are not
>>> allowed but in this case I would advocate to add it there.
>>>
>>> Does anybody have an objection?
>>>
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=270790>>>
>>> Andrew
>>> _______________________________________________
>>> cdt-dev mailing list
>>> cdt-dev@...
>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@...
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev>
>
> Christian W. Damus
> Software Developer, IDE Team
> QNX Software Systems
>
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
|
RE: Addition of Mach-O 64 Binary Parser to 6.0.2
Adding new API to a maintenance stream is a problem. However, I do not
see
(without being the expert for this) why that should keep you from adding
a
new Binary Parser. Does the parser have to be API?
Markus.
> -----Original Message-----
> From: cdt-dev-bounces@...
> [mailto: cdt-dev-bounces@...] On Behalf Of Michael Jackson
> Sent: Tuesday, November 03, 2009 6:56 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Addition of Mach-O 64 Binary Parser to 6.0.2
> Importance: Low
>
> I am all for stable codes and APIs and such but CDT is
> rapidly becoming useless on OS X. Between the lack of a 64
> bit parser (which means no 64 Bit debugging) and the severe
> issues with the debugger and threads I would like to see
> these items fixed sooner rather than later, but I am probably
> the vocal minority here so I'll just say it once and leave it
> to whomever makes the decisions.
>
> CDT is a great IDE to use. The Indexer, Syntax
> Highlighting, macro expansion and code navigation features
> have not been matched with any of the other major IDEs that I
> use (MS VS 2008 with V Assist X and Xcode). Since Apple has
> moved to x86_64 as the default arch for GCC to create this
> has added even more problems for OS X C/C++ developers to use
> CDT. Add to that the other debugging issues as laid out above
> and you get a really bad experience on OS X. I'll now step
> off the soap box..
>
> --
> Mike Jackson <www.bluequartz.net>
>
> On Nov 3, 2009, at 12:41 PM, Christian W. Damus wrote:
>
> > The problem with adding new API on the maintenance stream
> is that any
> > client bundle that wants to use this new API needs a new
> minor version
> > (x.y) of the bundle that supplies the API, in order to
> > sensibly express a new lower bound in its dependency range.
> > However, the supplier bundle can't actually raise its
> version to the
> > next minor number because then (a) it will conflict with the minor
> > version increment of the next release and (b) it will no
> longer look
> > like a service release, so user installs performing service updates
> > won't get anything.
> >
> > If this really is new public API, then adding it in the maintenance
> > stream is certain to break some client workflows.
> >
> > Cheers,
> >
> > Christian
> >
> >
> > On Tue, 2009-11-03 at 11:27 -0600, John Cortell wrote:
> >> I don't believe new API is a problem, even for a
> maintenance release.
> >> I think stability is the key. Any significant amount of code,
> >> API-related or not, that can destabilize existing features
> is what we
> >> should avoid. I think a new binary parser is a safe
> addition, as long
> >> as it hasn't mucked around much with the underlying support code.
> >>
> >> John
> >>
> >> At 11:18 AM 11/3/2009, Andrew Gvozdev wrote:
> >>> Hi,
> >>> There is a contribution of Mach-O binary parser for Mac
> 64 bit. In
> >>> CDT 6.1 it is being added as a new parser. I believe it would be
> >>> valuable addition to 6.0.X stream as well. Technically it
> introduces
> >>> new API and API changes for maintenance stream are not
> allowed but
> >>> in this case I would advocate to add it there.
> >>>
> >>> Does anybody have an objection?
> >>>
> >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=270790> >>>
> >>> Andrew
> >>> _______________________________________________
> >>> cdt-dev mailing list
> >>> cdt-dev@...
> >>> https://dev.eclipse.org/mailman/listinfo/cdt-dev> >> _______________________________________________
> >> cdt-dev mailing list
> >> cdt-dev@...
> >> https://dev.eclipse.org/mailman/listinfo/cdt-dev> >
> >
> > Christian W. Damus
> > Software Developer, IDE Team
> > QNX Software Systems
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev>
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
|
Re: Addition of Mach-O 64 Binary Parser to 6.0.2
On Tue, Nov 3, 2009 at 1:13 PM, Schorn, Markus <Markus.Schorn@...> wrote:
Adding new API to a maintenance stream is a problem. However, I do not see
(without being the expert for this) why that should keep you from adding a
new Binary Parser. Does the parser have to be API?
Well the classes are public and in theory one could extend or use them which I don't think is likely. I suppose we could add @noextend @noinstantiate tags for a good measure. The binary parser class itself (from cdt.core) is also used as an extension in managedbuilder.gnu.ui plugin.xml.
Christian, thanks for the insightful comment, that is definitely something to keep in mind.
Andrew
Markus.
> -----Original Message-----
> From: cdt-dev-bounces@...
> [mailto: cdt-dev-bounces@...] On Behalf Of Michael Jackson
> Sent: Tuesday, November 03, 2009 6:56 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Addition of Mach-O 64 Binary Parser to 6.0.2
> Importance: Low
>
> I am all for stable codes and APIs and such but CDT is
> rapidly becoming useless on OS X. Between the lack of a 64
> bit parser (which means no 64 Bit debugging) and the severe
> issues with the debugger and threads I would like to see
> these items fixed sooner rather than later, but I am probably
> the vocal minority here so I'll just say it once and leave it
> to whomever makes the decisions.
>
> CDT is a great IDE to use. The Indexer, Syntax
> Highlighting, macro expansion and code navigation features
> have not been matched with any of the other major IDEs that I
> use (MS VS 2008 with V Assist X and Xcode). Since Apple has
> moved to x86_64 as the default arch for GCC to create this
> has added even more problems for OS X C/C++ developers to use
> CDT. Add to that the other debugging issues as laid out above
> and you get a really bad experience on OS X. I'll now step
> off the soap box..
>
> --
> Mike Jackson < www.bluequartz.net>
>
> On Nov 3, 2009, at 12:41 PM, Christian W. Damus wrote:
>
> > The problem with adding new API on the maintenance stream
> is that any
> > client bundle that wants to use this new API needs a new
> minor version
> > (x.y) of the bundle that supplies the API, in order to
> > sensibly express a new lower bound in its dependency range.
> > However, the supplier bundle can't actually raise its
> version to the
> > next minor number because then (a) it will conflict with the minor
> > version increment of the next release and (b) it will no
> longer look
> > like a service release, so user installs performing service updates
> > won't get anything.
> >
> > If this really is new public API, then adding it in the maintenance
> > stream is certain to break some client workflows.
> >
> > Cheers,
> >
> > Christian
> >
> >
> > On Tue, 2009-11-03 at 11:27 -0600, John Cortell wrote:
> >> I don't believe new API is a problem, even for a
> maintenance release.
> >> I think stability is the key. Any significant amount of code,
> >> API-related or not, that can destabilize existing features
> is what we
> >> should avoid. I think a new binary parser is a safe
> addition, as long
> >> as it hasn't mucked around much with the underlying support code.
> >>
> >> John
> >>
> >> At 11:18 AM 11/3/2009, Andrew Gvozdev wrote:
> >>> Hi,
> >>> There is a contribution of Mach-O binary parser for Mac
> 64 bit. In
> >>> CDT 6.1 it is being added as a new parser. I believe it would be
> >>> valuable addition to 6.0.X stream as well. Technically it
> introduces
> >>> new API and API changes for maintenance stream are not
> allowed but
> >>> in this case I would advocate to add it there.
> >>>
> >>> Does anybody have an objection?
> >>>
> >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=270790
> >>>
> >>> Andrew
> >>> _______________________________________________
> >>> cdt-dev mailing list
> >>> cdt-dev@...
> >>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >> _______________________________________________
> >> cdt-dev mailing list
> >> cdt-dev@...
> >> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> >
> > Christian W. Damus
> > Software Developer, IDE Team
> > QNX Software Systems
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
|
RE: Addition of Mach-O 64 Binary Parser to 6.0.2
Adding @noextend and @noinstantiate tags is another way of
breaking API. My thought just was that
even if the current parsers are API, this does not prevent
you from adding an additional parser that is
not public API, does it?
Markus.
On Tue, Nov 3, 2009 at 1:13 PM, Schorn, Markus <Markus.Schorn@...>
wrote:
Adding
new API to a maintenance stream is a problem. However, I do
not see
(without being the expert for this) why that should keep you
from adding a
new Binary Parser. Does the parser have to be
API?
Well the classes are public and in theory one could extend or use them
which I don't think is likely. I suppose we could add @noextend @noinstantiate
tags for a good measure. The binary parser class itself (from
cdt.core) is also used as an extension
in managedbuilder.gnu.ui plugin.xml.
Christian, thanks for the insightful comment, that is definitely
something to keep in mind.
Andrew
Markus.
> -----Original Message----- > From: cdt-dev-bounces@...>
[mailto: cdt-dev-bounces@...]
On Behalf Of Michael Jackson > Sent: Tuesday, November 03, 2009 6:56
PM > To: CDT General developers list. > Subject: Re: [cdt-dev]
Addition of Mach-O 64 Binary Parser to 6.0.2 > Importance:
Low > > I am all for stable codes and APIs and such but
CDT is > rapidly becoming useless on OS X. Between the lack of a
64 > bit parser (which means no 64 Bit debugging) and the
severe > issues with the debugger and threads I would like to
see > these items fixed sooner rather than later, but I am
probably > the vocal minority here so I'll just say it once and leave
it > to whomever makes the decisions. > > CDT
is a great IDE to use. The Indexer, Syntax > Highlighting, macro
expansion and code navigation features > have not been matched with
any of the other major IDEs that I > use (MS VS 2008 with V Assist X
and Xcode). Since Apple has > moved to x86_64 as the default arch for
GCC to create this > has added even more problems for OS X C/C++
developers to use > CDT. Add to that the other debugging issues as
laid out above > and you get a really bad experience on OS X. I'll now
step > off the soap box.. > > -- > Mike Jackson
< www.bluequartz.net> > > On Nov 3, 2009, at
12:41 PM, Christian W. Damus wrote: > > > The problem with
adding new API on the maintenance stream > is that any > >
client bundle that wants to use this new API needs a new > minor
version > > (x.y) of the bundle that supplies the API, in order
to > > sensibly express a new lower bound in its dependency
range. > > However, the supplier bundle can't actually raise
its > version to the > > next minor number because then (a)
it will conflict with the minor > > version increment of the next
release and (b) it will no > longer look > > like a service
release, so user installs performing service updates > > won't get
anything. > > > > If this really is new public API, then
adding it in the maintenance > > stream is certain to break some
client workflows. > > > > Cheers, > > >
> Christian > > > > > > On Tue, 2009-11-03 at
11:27 -0600, John Cortell wrote: > >> I don't believe new API is
a problem, even for a > maintenance release. > >> I think
stability is the key. Any significant amount of code, > >>
API-related or not, that can destabilize existing features > is what
we > >> should avoid. I think a new binary parser is a
safe > addition, as long > >> as it hasn't mucked around
much with the underlying support code. > >> > >>
John > >> > >> At 11:18 AM 11/3/2009, Andrew Gvozdev
wrote: > >>> Hi, > >>> There is a contribution
of Mach-O binary parser for Mac > 64 bit. In > >>> CDT
6.1 it is being added as a new parser. I believe it would be >
>>> valuable addition to 6.0.X stream as well. Technically
it > introduces > >>> new API and API changes for
maintenance stream are not > allowed but > >>> in this
case I would advocate to add it there. > >>> >
>>> Does anybody have an objection? > >>> >
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=270790>
>>> > >>> Andrew > >>>
_______________________________________________ > >>> cdt-dev
mailing list > >>> cdt-dev@...>
>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev>
>> _______________________________________________ > >>
cdt-dev mailing list > >> cdt-dev@...> >>
https://dev.eclipse.org/mailman/listinfo/cdt-dev>
> > > > > Christian W. Damus > > Software
Developer, IDE Team > > QNX Software Systems > > >
_______________________________________________ > cdt-dev mailing
list > cdt-dev@...> https://dev.eclipse.org/mailman/listinfo/cdt-dev> _______________________________________________ cdt-dev
mailing list cdt-dev@...https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
|
Re: Addition of Mach-O 64 Binary Parser to 6.0.2
Hi, Andrew,
No problem! As Markus indicates, it's only an issue if the parser is published as API. AFAIK, the only API-like aspect of a binary parser would be the ID under which it is registered on the parsers extension point, right? Because that is used by toolchain integrators to reference it as, e.g., a default parser for tool definitions.
Probably simply neglecting to "publish" this parser ID is all that is required to satisfy the API concern and to give OS X users (of which I am one) what they desperately need :-) The parser code would be internal anyways, I suspect.
cW
On Tue, 2009-11-03 at 13:29 -0500, Andrew Gvozdev wrote:
On Tue, Nov 3, 2009 at 1:13 PM, Schorn, Markus <Markus.Schorn@...> wrote:
Adding new API to a maintenance stream is a problem. However, I do not see
(without being the expert for this) why that should keep you from adding a
new Binary Parser. Does the parser have to be API?
Well the classes are public and in theory one could extend or use them which I don't think is likely. I suppose we could add @noextend @noinstantiate tags for a good measure. The binary parser class itself (from cdt.core) is also used as an extension in managedbuilder.gnu.ui plugin.xml.
Christian, thanks for the insightful comment, that is definitely something to keep in mind.
Andrew
Markus.
> -----Original Message-----
> From: cdt-dev-bounces@...
> [mailto:cdt-dev-bounces@...] On Behalf Of Michael Jackson
> Sent: Tuesday, November 03, 2009 6:56 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Addition of Mach-O 64 Binary Parser to 6.0.2
> Importance: Low
>
> I am all for stable codes and APIs and such but CDT is
> rapidly becoming useless on OS X. Between the lack of a 64
> bit parser (which means no 64 Bit debugging) and the severe
> issues with the debugger and threads I would like to see
> these items fixed sooner rather than later, but I am probably
> the vocal minority here so I'll just say it once and leave it
> to whomever makes the decisions.
>
> CDT is a great IDE to use. The Indexer, Syntax
> Highlighting, macro expansion and code navigation features
> have not been matched with any of the other major IDEs that I
> use (MS VS 2008 with V Assist X and Xcode). Since Apple has
> moved to x86_64 as the default arch for GCC to create this
> has added even more problems for OS X C/C++ developers to use
> CDT. Add to that the other debugging issues as laid out above
> and you get a really bad experience on OS X. I'll now step
> off the soap box..
>
> --
> Mike Jackson <www.bluequartz.net>
>
> On Nov 3, 2009, at 12:41 PM, Christian W. Damus wrote:
>
> > The problem with adding new API on the maintenance stream
> is that any
> > client bundle that wants to use this new API needs a new
> minor version
> > (x.y) of the bundle that supplies the API, in order to
> > sensibly express a new lower bound in its dependency range.
> > However, the supplier bundle can't actually raise its
> version to the
> > next minor number because then (a) it will conflict with the minor
> > version increment of the next release and (b) it will no
> longer look
> > like a service release, so user installs performing service updates
> > won't get anything.
> >
> > If this really is new public API, then adding it in the maintenance
> > stream is certain to break some client workflows.
> >
> > Cheers,
> >
> > Christian
> >
> >
> > On Tue, 2009-11-03 at 11:27 -0600, John Cortell wrote:
> >> I don't believe new API is a problem, even for a
> maintenance release.
> >> I think stability is the key. Any significant amount of code,
> >> API-related or not, that can destabilize existing features
> is what we
> >> should avoid. I think a new binary parser is a safe
> addition, as long
> >> as it hasn't mucked around much with the underlying support code.
> >>
> >> John
> >>
> >> At 11:18 AM 11/3/2009, Andrew Gvozdev wrote:
> >>> Hi,
> >>> There is a contribution of Mach-O binary parser for Mac
> 64 bit. In
> >>> CDT 6.1 it is being added as a new parser. I believe it would be
> >>> valuable addition to 6.0.X stream as well. Technically it
> introduces
> >>> new API and API changes for maintenance stream are not
> allowed but
> >>> in this case I would advocate to add it there.
> >>>
> >>> Does anybody have an objection?
> >>>
> >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=270790
> >>>
> >>> Andrew
> >>> _______________________________________________
> >>> cdt-dev mailing list
> >>> cdt-dev@...
> >>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >> _______________________________________________
> >> cdt-dev mailing list
> >> cdt-dev@...
> >> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> >
> > Christian W. Damus
> > Software Developer, IDE Team
> > QNX Software Systems
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
|
Re: Addition of Mach-O 64 Binary Parser to 6.0.2
On Tue, Nov 3, 2009 at 1:40 PM, Schorn, Markus <Markus.Schorn@...> wrote:
Adding @noextend and @noinstantiate tags is another way of
breaking API. My thought just was that
even if the current parsers are API, this does not prevent
you from adding an additional parser that is
not public API, does it?
Yes, I agree. I was talking about adding @noextend @noinstantiate tags to the new classes as the way to make them not public API. Not sure if I should do it in 6.0.X only or in 6.1 as well. I still have to expose the binary parser itself for managedbuild plugin though.
Andrew
Markus.
From: cdt-dev-bounces@...
[mailto:cdt-dev-bounces@...] On Behalf Of Andrew
Gvozdev
Sent: Tuesday, November 03, 2009 7:30 PM
To: CDT
General developers list.
Subject: Re: [cdt-dev] Addition of Mach-O
64 Binary Parser to 6.0.2
Importance: Low
On Tue, Nov 3, 2009 at 1:13 PM, Schorn, Markus <Markus.Schorn@...>
wrote:
Adding
new API to a maintenance stream is a problem. However, I do
not see
(without being the expert for this) why that should keep you
from adding a
new Binary Parser. Does the parser have to be
API?
Well the classes are public and in theory one could extend or use them
which I don't think is likely. I suppose we could add @noextend @noinstantiate
tags for a good measure. The binary parser class itself (from
cdt.core) is also used as an extension
in managedbuilder.gnu.ui plugin.xml.
Christian, thanks for the insightful comment, that is definitely
something to keep in mind.
Andrew
Markus.
> -----Original Message----- > From: cdt-dev-bounces@...>
[mailto: cdt-dev-bounces@...]
On Behalf Of Michael Jackson > Sent: Tuesday, November 03, 2009 6:56
PM > To: CDT General developers list. > Subject: Re: [cdt-dev]
Addition of Mach-O 64 Binary Parser to 6.0.2 > Importance:
Low > > I am all for stable codes and APIs and such but
CDT is > rapidly becoming useless on OS X. Between the lack of a
64 > bit parser (which means no 64 Bit debugging) and the
severe > issues with the debugger and threads I would like to
see > these items fixed sooner rather than later, but I am
probably > the vocal minority here so I'll just say it once and leave
it > to whomever makes the decisions. > > CDT
is a great IDE to use. The Indexer, Syntax > Highlighting, macro
expansion and code navigation features > have not been matched with
any of the other major IDEs that I > use (MS VS 2008 with V Assist X
and Xcode). Since Apple has > moved to x86_64 as the default arch for
GCC to create this > has added even more problems for OS X C/C++
developers to use > CDT. Add to that the other debugging issues as
laid out above > and you get a really bad experience on OS X. I'll now
step > off the soap box.. > > -- > Mike Jackson
< www.bluequartz.net> > > On Nov 3, 2009, at
12:41 PM, Christian W. Damus wrote: > > > The problem with
adding new API on the maintenance stream > is that any > >
client bundle that wants to use this new API needs a new > minor
version > > (x.y) of the bundle that supplies the API, in order
to > > sensibly express a new lower bound in its dependency
range. > > However, the supplier bundle can't actually raise
its > version to the > > next minor number because then (a)
it will conflict with the minor > > version increment of the next
release and (b) it will no > longer look > > like a service
release, so user installs performing service updates > > won't get
anything. > > > > If this really is new public API, then
adding it in the maintenance > > stream is certain to break some
client workflows. > > > > Cheers, > > >
> Christian > > > > > > On Tue, 2009-11-03 at
11:27 -0600, John Cortell wrote: > >> I don't believe new API is
a problem, even for a > maintenance release. > >> I think
stability is the key. Any significant amount of code, > >>
API-related or not, that can destabilize existing features > is what
we > >> should avoid. I think a new binary parser is a
safe > addition, as long > >> as it hasn't mucked around
much with the underlying support code. > >> > >>
John > >> > >> At 11:18 AM 11/3/2009, Andrew Gvozdev
wrote: > >>> Hi, > >>> There is a contribution
of Mach-O binary parser for Mac > 64 bit. In > >>> CDT
6.1 it is being added as a new parser. I believe it would be >
>>> valuable addition to 6.0.X stream as well. Technically
it > introduces > >>> new API and API changes for
maintenance stream are not > allowed but > >>> in this
case I would advocate to add it there. > >>> >
>>> Does anybody have an objection? > >>> >
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=270790>
>>> > >>> Andrew > >>>
_______________________________________________ > >>> cdt-dev
mailing list > >>> cdt-dev@...>
>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev>
>> _______________________________________________ > >>
cdt-dev mailing list > >> cdt-dev@...> >>
https://dev.eclipse.org/mailman/listinfo/cdt-dev>
> > > > > Christian W. Damus > > Software
Developer, IDE Team > > QNX Software Systems > > >
_______________________________________________ > cdt-dev mailing
list > cdt-dev@...> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________ cdt-dev
mailing list cdt-dev@...https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
|
Re: Addition of Mach-O 64 Binary Parser to 6.0.2
For 6.0.2 I was able to get around most formal API problems except public class MachOParser64 and (new) public constructor StabsReader. For those I created API filter. I also stated in JavaDoc that they are not to be used in CDT 6.0.X which makes them officially non-API.
Andrew On Tue, Nov 3, 2009 at 1:40 PM, Schorn, Markus <Markus.Schorn@...> wrote:
Adding @noextend and @noinstantiate tags is another way of
breaking API. My thought just was that
even if the current parsers are API, this does not prevent
you from adding an additional parser that is
not public API, does it?
Markus.
From: cdt-dev-bounces@...
[mailto:cdt-dev-bounces@...] On Behalf Of Andrew
Gvozdev
Sent: Tuesday, November 03, 2009 7:30 PM
To: CDT
General developers list.
Subject: Re: [cdt-dev] Addition of Mach-O
64 Binary Parser to 6.0.2
Importance: Low
On Tue, Nov 3, 2009 at 1:13 PM, Schorn, Markus <Markus.Schorn@...>
wrote:
Adding
new API to a maintenance stream is a problem. However, I do
not see
(without being the expert for this) why that should keep you
from adding a
new Binary Parser. Does the parser have to be
API?
Well the classes are public and in theory one could extend or use them
which I don't think is likely. I suppose we could add @noextend @noinstantiate
tags for a good measure. The binary parser class itself (from
cdt.core) is also used as an extension
in managedbuilder.gnu.ui plugin.xml.
Christian, thanks for the insightful comment, that is definitely
something to keep in mind.
Andrew
Markus.
> -----Original Message----- > From: cdt-dev-bounces@...>
[mailto: cdt-dev-bounces@...]
On Behalf Of Michael Jackson > Sent: Tuesday, November 03, 2009 6:56
PM > To: CDT General developers list. > Subject: Re: [cdt-dev]
Addition of Mach-O 64 Binary Parser to 6.0.2 > Importance:
Low > > I am all for stable codes and APIs and such but
CDT is > rapidly becoming useless on OS X. Between the lack of a
64 > bit parser (which means no 64 Bit debugging) and the
severe > issues with the debugger and threads I would like to
see > these items fixed sooner rather than later, but I am
probably > the vocal minority here so I'll just say it once and leave
it > to whomever makes the decisions. > > CDT
is a great IDE to use. The Indexer, Syntax > Highlighting, macro
expansion and code navigation features > have not been matched with
any of the other major IDEs that I > use (MS VS 2008 with V Assist X
and Xcode). Since Apple has > moved to x86_64 as the default arch for
GCC to create this > has added even more problems for OS X C/C++
developers to use > CDT. Add to that the other debugging issues as
laid out above > and you get a really bad experience on OS X. I'll now
step > off the soap box.. > > -- > Mike Jackson
< www.bluequartz.net> > > On Nov 3, 2009, at
12:41 PM, Christian W. Damus wrote: > > > The problem with
adding new API on the maintenance stream > is that any > >
client bundle that wants to use this new API needs a new > minor
version > > (x.y) of the bundle that supplies the API, in order
to > > sensibly express a new lower bound in its dependency
range. > > However, the supplier bundle can't actually raise
its > version to the > > next minor number because then (a)
it will conflict with the minor > > version increment of the next
release and (b) it will no > longer look > > like a service
release, so user installs performing service updates > > won't get
anything. > > > > If this really is new public API, then
adding it in the maintenance > > stream is certain to break some
client workflows. > > > > Cheers, > > >
> Christian > > > > > > On Tue, 2009-11-03 at
11:27 -0600, John Cortell wrote: > >> I don't believe new API is
a problem, even for a > maintenance release. > >> I think
stability is the key. Any significant amount of code, > >>
API-related or not, that can destabilize existing features > is what
we > >> should avoid. I think a new binary parser is a
safe > addition, as long > >> as it hasn't mucked around
much with the underlying support code. > >> > >>
John > >> > >> At 11:18 AM 11/3/2009, Andrew Gvozdev
wrote: > >>> Hi, > >>> There is a contribution
of Mach-O binary parser for Mac > 64 bit. In > >>> CDT
6.1 it is being added as a new parser. I believe it would be >
>>> valuable addition to 6.0.X stream as well. Technically
it > introduces > >>> new API and API changes for
maintenance stream are not > allowed but > >>> in this
case I would advocate to add it there. > >>> >
>>> Does anybody have an objection? > >>> >
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=270790>
>>> > >>> Andrew > >>>
_______________________________________________ > >>> cdt-dev
mailing list > >>> cdt-dev@...>
>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev>
>> _______________________________________________ > >>
cdt-dev mailing list > >> cdt-dev@...> >>
https://dev.eclipse.org/mailman/listinfo/cdt-dev>
> > > > > Christian W. Damus > > Software
Developer, IDE Team > > QNX Software Systems > > >
_______________________________________________ > cdt-dev mailing
list > cdt-dev@...> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________ cdt-dev
mailing list cdt-dev@...https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
|
RE: Addition of Mach-O 64 Binary Parser to 6.0.2
Creating API problem filters just hides the problems. And
if you create a problem filter, very soon others will
follow.
You can put the MachOParser64 into an internal
package, if necessary it can be made public in 6.1.
Markus.
For 6.0.2 I was able to get around most formal API problems
except public class MachOParser64 and (new) public
constructor StabsReader. For those I created API filter. I also stated in
JavaDoc that they are not to be used in CDT 6.0.X which makes them officially
non-API.
Andrew
On Tue, Nov 3, 2009 at 1:40 PM, Schorn, Markus <Markus.Schorn@...>
wrote:
Adding
@noextend and @noinstantiate tags is another way of breaking API. My thought
just was that
even if
the current parsers are API, this does not prevent you from adding an
additional parser that is
not
public API, does it?
Markus.
From: cdt-dev-bounces@... [mailto:cdt-dev-bounces@...] On Behalf Of Andrew
Gvozdev
Sent: Tuesday, November 03, 2009 7:30 PM
To: CDT General developers
list.
Subject: Re: [cdt-dev] Addition of Mach-O 64 Binary Parser
to 6.0.2
Importance: Low
On Tue, Nov 3, 2009 at 1:13 PM, Schorn, Markus
<Markus.Schorn@...> wrote:
Adding
new API to a maintenance stream is a problem. However, I do
not see
(without being the expert for this) why that should keep
you from adding a
new Binary Parser. Does the parser have to be
API?
Well the classes are public and in theory one could extend or use
them which I don't think is likely. I suppose we could add @noextend
@noinstantiate tags for a good measure. The binary parser class
itself (from cdt.core) is also used as an extension
in managedbuilder.gnu.ui plugin.xml.
Christian, thanks for the insightful comment, that is definitely
something to keep in mind.
Andrew
Markus.
> -----Original Message----- > From: cdt-dev-bounces@...> [mailto: cdt-dev-bounces@...] On Behalf Of Michael
Jackson > Sent: Tuesday, November 03, 2009 6:56 PM > To: CDT
General developers list. > Subject: Re: [cdt-dev] Addition of
Mach-O 64 Binary Parser to 6.0.2 > Importance: Low > >
I am all for stable codes and APIs and such but CDT is >
rapidly becoming useless on OS X. Between the lack of a 64 > bit
parser (which means no 64 Bit debugging) and the severe > issues
with the debugger and threads I would like to see > these items
fixed sooner rather than later, but I am probably > the vocal
minority here so I'll just say it once and leave it > to whomever
makes the decisions. > > CDT is a great IDE to
use. The Indexer, Syntax > Highlighting, macro expansion and code
navigation features > have not been matched with any of the other
major IDEs that I > use (MS VS 2008 with V Assist X and Xcode).
Since Apple has > moved to x86_64 as the default arch for GCC to
create this > has added even more problems for OS X C/C++
developers to use > CDT. Add to that the other debugging issues as
laid out above > and you get a really bad experience on OS X. I'll
now step > off the soap box.. > > -- > Mike
Jackson < www.bluequartz.net> > > On Nov 3, 2009,
at 12:41 PM, Christian W. Damus wrote: > > > The problem
with adding new API on the maintenance stream > is that
any > > client bundle that wants to use this new API needs a
new > minor version > > (x.y) of the bundle that supplies
the API, in order to > > sensibly express a new lower bound in
its dependency range. > > However, the supplier bundle can't
actually raise its > version to the > > next minor number
because then (a) it will conflict with the minor > > version
increment of the next release and (b) it will no > longer
look > > like a service release, so user installs performing
service updates > > won't get anything. > > >
> If this really is new public API, then adding it in the
maintenance > > stream is certain to break some client
workflows. > > > > Cheers, > > > >
Christian > > > > > > On Tue, 2009-11-03 at
11:27 -0600, John Cortell wrote: > >> I don't believe new
API is a problem, even for a > maintenance release. >
>> I think stability is the key. Any significant amount of
code, > >> API-related or not, that can destabilize existing
features > is what we > >> should avoid. I think a new
binary parser is a safe > addition, as long > >> as it
hasn't mucked around much with the underlying support code. >
>> > >> John > >> > >> At
11:18 AM 11/3/2009, Andrew Gvozdev wrote: > >>>
Hi, > >>> There is a contribution of Mach-O binary parser
for Mac > 64 bit. In > >>> CDT 6.1 it is being
added as a new parser. I believe it would be > >>>
valuable addition to 6.0.X stream as well. Technically it >
introduces > >>> new API and API changes for maintenance
stream are not > allowed but > >>> in this case I
would advocate to add it there. > >>> >
>>> Does anybody have an objection? >
>>> > >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=270790>
>>> > >>> Andrew > >>>
_______________________________________________ > >>>
cdt-dev mailing list > >>> cdt-dev@...> >>> https://dev.eclipse.org/mailman/listinfo/cdt-dev>
>> _______________________________________________ >
>> cdt-dev mailing list > >> cdt-dev@...> >> https://dev.eclipse.org/mailman/listinfo/cdt-dev>
> > > > > Christian W. Damus > > Software
Developer, IDE Team > > QNX Software Systems >
> > _______________________________________________ >
cdt-dev mailing list > cdt-dev@...> https://dev.eclipse.org/mailman/listinfo/cdt-dev> _______________________________________________ cdt-dev
mailing list cdt-dev@...https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev
mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
|
Re: Addition of Mach-O 64 Binary Parser to 6.0.2
On Wed, Nov 4, 2009 at 12:36 PM, Schorn, Markus <Markus.Schorn@...> wrote:
Creating API problem filters just hides the problems. And
if you create a problem filter, very soon others will
follow.
You can put the MachOParser64 into an internal
package, if necessary it can be made public in 6.1.
Markus.
I do not see how I can put it in internal package. I see 2 problems with that:
1. The class is referenced from another plugin. Should I export the internal package in manifest with x-internal? 2. Even if I manage to do that it uses a new constructor from class in different package which I have to make public to get access to it. How do I get around that?
Hmm, even if I create API problem filters the tooling still complains that I have to increment minor version after I recompile from scratch. Isn't the filters supposed to get API problems ignored?
Andrew
Sent: Wednesday, November 04, 2009 5:11 PM
To: CDT
General developers list.
Subject: Re: [cdt-dev] Addition of Mach-O
64 Binary Parser to 6.0.2
Importance: Low
For 6.0.2 I was able to get around most formal API problems
except public class MachOParser64 and (new) public
constructor StabsReader. For those I created API filter. I also stated in
JavaDoc that they are not to be used in CDT 6.0.X which makes them officially
non-API.
Andrew
On Tue, Nov 3, 2009 at 1:40 PM, Schorn, Markus <Markus.Schorn@...>
wrote:
Adding
@noextend and @noinstantiate tags is another way of breaking API. My thought
just was that
even if
the current parsers are API, this does not prevent you from adding an
additional parser that is
not
public API, does it?
Markus.
From: cdt-dev-bounces@... [mailto:cdt-dev-bounces@...] On Behalf Of Andrew
Gvozdev
Sent: Tuesday, November 03, 2009 7:30 PM
To: CDT General developers
list.
Subject: Re: [cdt-dev] Addition of Mach-O 64 Binary Parser
to 6.0.2
Importance: Low
On Tue, Nov 3, 2009 at 1:13 PM, Schorn, Markus
<Markus.Schorn@...> wrote:
Adding
new API to a maintenance stream is a problem. However, I do
not see
(without being the expert for this) why that should keep
you from adding a
new Binary Parser. Does the parser have to be
API?
Well the classes are public and in theory one could extend or use
them which I don't think is likely. I suppose we could add @noextend
@noinstantiate tags for a good measure. The binary parser class
itself (from cdt.core) is also used as an extension
in managedbuilder.gnu.ui plugin.xml.
Christian, thanks for the insightful comment, that is definitely
something to keep in mind.
Andrew
Markus.
> -----Original Message----- > From: cdt-dev-bounces@...> [mailto: cdt-dev-bounces@...] On Behalf Of Michael
Jackson > Sent: Tuesday, November 03, 2009 6:56 PM > To: CDT
General developers list. > Subject: Re: [cdt-dev] Addition of
Mach-O 64 Binary Parser to 6.0.2 > Importance: Low > >
I am all for stable codes and APIs and such but CDT is >
rapidly becoming useless on OS X. Between the lack of a 64 > bit
parser (which means no 64 Bit debugging) and the severe > issues
with the debugger and threads I would like to see > these items
fixed sooner rather than later, but I am probably > the vocal
minority here so I'll just say it once and leave it > to whomever
makes the decisions. > > CDT is a great IDE to
use. The Indexer, Syntax > Highlighting, macro expansion and code
navigation features > have not been matched with any of the other
major IDEs that I > use (MS VS 2008 with V Assist X and Xcode).
Since Apple has > moved to x86_64 as the default arch for GCC to
create this > has added even more problems for OS X C/C++
developers to use > CDT. Add to that the other debugging issues as
laid out above > and you get a really bad experience on OS X. I'll
now step > off the soap box.. > > -- > Mike
Jackson < www.bluequartz.net> > > On Nov 3, 2009,
at 12:41 PM, Christian W. Damus wrote: > > > The problem
with adding new API on the maintenance stream > is that
any > > client bundle that wants to use this new API needs a
new > minor version > > (x.y) of the bundle that supplies
the API, in order to > > sensibly express a new lower bound in
its dependency range. > > However, the supplier bundle can't
actually raise its > version to the > > next minor number
because then (a) it will conflict with the minor > > version
increment of the next release and (b) it will no > longer
look > > like a service release, so user installs performing
service updates > > won't get anything. > > >
> If this really is new public API, then adding it in the
maintenance > > stream is certain to break some client
workflows. > > > > Cheers, > > > >
Christian > > > > > > On Tue, 2009-11-03 at
11:27 -0600, John Cortell wrote: > >> I don't believe new
API is a problem, even for a > maintenance release. >
>> I think stability is the key. Any significant amount of
code, > >> API-related or not, that can destabilize existing
features > is what we > >> should avoid. I think a new
binary parser is a safe > addition, as long > >> as it
hasn't mucked around much with the underlying support code. >
>> > >> John > >> > >> At
11:18 AM 11/3/2009, Andrew Gvozdev wrote: > >>>
Hi, > >>> There is a contribution of Mach-O binary parser
for Mac > 64 bit. In > >>> CDT 6.1 it is being
added as a new parser. I believe it would be > >>>
valuable addition to 6.0.X stream as well. Technically it >
introduces > >>> new API and API changes for maintenance
stream are not > allowed but > >>> in this case I
would advocate to add it there. > >>> >
>>> Does anybody have an objection? >
>>> > >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=270790>
>>> > >>> Andrew > >>>
_______________________________________________ > >>>
cdt-dev mailing list > >>> cdt-dev@...> >>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>> _______________________________________________ >
>> cdt-dev mailing list > >> cdt-dev@...> >> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
> > > > > Christian W. Damus > > Software
Developer, IDE Team > > QNX Software Systems >
> > _______________________________________________ >
cdt-dev mailing list > cdt-dev@...> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________ cdt-dev
mailing list cdt-dev@...https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev
mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
|
Re: Addition of Mach-O 64 Binary Parser to 6.0.2
Markus, you are making me to think how it still can be done. It appears that I can gather all the new API classes including copy of the one with the new constructor into one internal package and it works. The reference from another plugin turns out to be just a reference to parser ID so it is not a problem. I think I'll go with that workaround (in 6.0.2 only), thanks.
Andrew On Wed, Nov 4, 2009 at 12:53 PM, Andrew Gvozdev <angvoz.dev@...> wrote:
On Wed, Nov 4, 2009 at 12:36 PM, Schorn, Markus <Markus.Schorn@...> wrote:
Creating API problem filters just hides the problems. And
if you create a problem filter, very soon others will
follow.
You can put the MachOParser64 into an internal
package, if necessary it can be made public in 6.1.
Markus.
I do not see how I can put it in internal package. I see 2 problems with that:
1. The class is referenced from another plugin. Should I export the internal package in manifest with x-internal? 2. Even if I manage to do that it uses a new constructor from class in different package which I have to make public to get access to it. How do I get around that?
Hmm, even if I create API problem filters the tooling still complains that I have to increment minor version after I recompile from scratch. Isn't the filters supposed to get API problems ignored?
Andrew
Sent: Wednesday, November 04, 2009 5:11 PM
To: CDT
General developers list.
Subject: Re: [cdt-dev] Addition of Mach-O
64 Binary Parser to 6.0.2
Importance: Low
For 6.0.2 I was able to get around most formal API problems
except public class MachOParser64 and (new) public
constructor StabsReader. For those I created API filter. I also stated in
JavaDoc that they are not to be used in CDT 6.0.X which makes them officially
non-API.
Andrew
On Tue, Nov 3, 2009 at 1:40 PM, Schorn, Markus <Markus.Schorn@...>
wrote:
Adding
@noextend and @noinstantiate tags is another way of breaking API. My thought
just was that
even if
the current parsers are API, this does not prevent you from adding an
additional parser that is
not
public API, does it?
Markus.
From: cdt-dev-bounces@... [mailto:cdt-dev-bounces@...] On Behalf Of Andrew
Gvozdev
Sent: Tuesday, November 03, 2009 7:30 PM
To: CDT General developers
list.
Subject: Re: [cdt-dev] Addition of Mach-O 64 Binary Parser
to 6.0.2
Importance: Low
On Tue, Nov 3, 2009 at 1:13 PM, Schorn, Markus
<Markus.Schorn@...> wrote:
Adding
new API to a maintenance stream is a problem. However, I do
not see
(without being the expert for this) why that should keep
you from adding a
new Binary Parser. Does the parser have to be
API?
Well the classes are public and in theory one could extend or use
them which I don't think is likely. I suppose we could add @noextend
@noinstantiate tags for a good measure. The binary parser class
itself (from cdt.core) is also used as an extension
in managedbuilder.gnu.ui plugin.xml.
Christian, thanks for the insightful comment, that is definitely
something to keep in mind.
Andrew
Markus.
> -----Original Message----- > From: cdt-dev-bounces@...> [mailto: cdt-dev-bounces@...] On Behalf Of Michael
Jackson > Sent: Tuesday, November 03, 2009 6:56 PM > To: CDT
General developers list. > Subject: Re: [cdt-dev] Addition of
Mach-O 64 Binary Parser to 6.0.2 > Importance: Low > >
I am all for stable codes and APIs and such but CDT is >
rapidly becoming useless on OS X. Between the lack of a 64 > bit
parser (which means no 64 Bit debugging) and the severe > issues
with the debugger and threads I would like to see > these items
fixed sooner rather than later, but I am probably > the vocal
minority here so I'll just say it once and leave it > to whomever
makes the decisions. > > CDT is a great IDE to
use. The Indexer, Syntax > Highlighting, macro expansion and code
navigation features > have not been matched with any of the other
major IDEs that I > use (MS VS 2008 with V Assist X and Xcode).
Since Apple has > moved to x86_64 as the default arch for GCC to
create this > has added even more problems for OS X C/C++
developers to use > CDT. Add to that the other debugging issues as
laid out above > and you get a really bad experience on OS X. I'll
now step > off the soap box.. > > -- > Mike
Jackson < www.bluequartz.net> > > On Nov 3, 2009,
at 12:41 PM, Christian W. Damus wrote: > > > The problem
with adding new API on the maintenance stream > is that
any > > client bundle that wants to use this new API needs a
new > minor version > > (x.y) of the bundle that supplies
the API, in order to > > sensibly express a new lower bound in
its dependency range. > > However, the supplier bundle can't
actually raise its > version to the > > next minor number
because then (a) it will conflict with the minor > > version
increment of the next release and (b) it will no > longer
look > > like a service release, so user installs performing
service updates > > won't get anything. > > >
> If this really is new public API, then adding it in the
maintenance > > stream is certain to break some client
workflows. > > > > Cheers, > > > >
Christian > > > > > > On Tue, 2009-11-03 at
11:27 -0600, John Cortell wrote: > >> I don't believe new
API is a problem, even for a > maintenance release. >
>> I think stability is the key. Any significant amount of
code, > >> API-related or not, that can destabilize existing
features > is what we > >> should avoid. I think a new
binary parser is a safe > addition, as long > >> as it
hasn't mucked around much with the underlying support code. >
>> > >> John > >> > >> At
11:18 AM 11/3/2009, Andrew Gvozdev wrote: > >>>
Hi, > >>> There is a contribution of Mach-O binary parser
for Mac > 64 bit. In > >>> CDT 6.1 it is being
added as a new parser. I believe it would be > >>>
valuable addition to 6.0.X stream as well. Technically it >
introduces > >>> new API and API changes for maintenance
stream are not > allowed but > >>> in this case I
would advocate to add it there. > >>> >
>>> Does anybody have an objection? >
>>> > >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=270790>
>>> > >>> Andrew > >>>
_______________________________________________ > >>>
cdt-dev mailing list > >>> cdt-dev@...> >>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>> _______________________________________________ >
>> cdt-dev mailing list > >> cdt-dev@...> >> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
> > > > > Christian W. Damus > > Software
Developer, IDE Team > > QNX Software Systems >
> > _______________________________________________ >
cdt-dev mailing list > cdt-dev@...> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________ cdt-dev
mailing list cdt-dev@...https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev
mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
|
Re: Addition of Mach-O 64 Binary Parser to 6.0.2
All public classes in an internal package are internal, as are its public
methods/fields. So all you need to do is #1.
John
At 11:53 AM 11/4/2009, Andrew Gvozdev wrote:
On Wed, Nov 4, 2009 at 12:36 PM,
Schorn, Markus
<Markus.Schorn@...> wrote:
- Creating API problem filters just hides
the problems. And if you create a problem filter, very soon others will
follow.
- You can put the MachOParser64 into an internal package, if necessary
it can be made public in 6.1.
- Markus.
I do not see how I can put it in internal package. I see 2 problems with
that:
1. The class is referenced from another plugin. Should I export the
internal package in manifest with x-internal?
2. Even if I manage to do that it uses a new constructor from class in
different package which I have to make public to get access to it. How do
I get around that?
Hmm, even if I create API problem filters the tooling still complains
that I have to increment minor version after I recompile from scratch.
Isn't the filters supposed to get API problems ignored?
Andrew
- From:
cdt-dev-bounces@...
[cdt-dev-bounces@...] On Behalf Of Andrew
Gvozdev
- Sent: Wednesday, November 04, 2009 5:11 PM
- To: CDT General developers list.
- Subject: Re: [cdt-dev] Addition of Mach-O 64 Binary Parser to
6.0.2
- Importance: Low
- For 6.0.2 I was able to get around most formal API problems except
public class MachOParser64 and (new) public constructor StabsReader. For
those I created API filter. I also stated in JavaDoc that they are not to
be used in CDT 6.0.X which makes them officially non-API.
- Andrew
- On Tue, Nov 3, 2009 at 1:40 PM, Schorn, Markus
<Markus.Schorn@...> wrote:
- Adding @noextend and @noinstantiate tags
is another way of breaking API. My thought just was that
- even if the current parsers are API, this does not prevent you from
adding an additional parser that is
- not public API, does it?
-
- Markus.
- From:
cdt-dev-bounces@...
[cdt-dev-bounces@...] On Behalf Of Andrew
Gvozdev
- Sent: Tuesday, November 03, 2009 7:30 PM
- To: CDT General developers list.
- Subject: Re: [cdt-dev] Addition of Mach-O 64 Binary Parser to
6.0.2
- Importance: Low
- On Tue, Nov 3, 2009 at 1:13 PM, Schorn, Markus
<Markus.Schorn@...> wrote:
- Adding new API to a maintenance stream is a problem. However, I do
not see
- (without being the expert for this) why that should keep you from
adding a
- new Binary Parser. Does the parser have to be API?
- Well the classes are public and in theory one could extend or use
them which I don't think is likely. I suppose we could add @noextend
@noinstantiate tags for a good measure. The binary parser class itself
(from cdt.core) is also used as an extension in
managedbuilder.gnu.ui plugin.xml.
- Christian, thanks for the insightful comment, that is definitely
something to keep in mind.
- Andrew
-
- Markus.
- > -----Original Message-----
- > From:
cdt-dev-bounces@...
- >
[cdt-dev-bounces@...] On Behalf Of Michael Jackson
- > Sent: Tuesday, November 03, 2009 6:56 PM
- > To: CDT General developers list.
- > Subject: Re: [cdt-dev] Addition of Mach-O 64 Binary Parser to
6.0.2
- > Importance: Low
- >
- > I am all for stable codes and APIs and such but CDT
is
- > rapidly becoming useless on OS X. Between the lack of a 64
- > bit parser (which means no 64 Bit debugging) and the severe
- > issues with the debugger and threads I would like to see
- > these items fixed sooner rather than later, but I am
probably
- > the vocal minority here so I'll just say it once and leave
it
- > to whomever makes the decisions.
- >
- > CDT is a great IDE to use. The Indexer,
Syntax
- > Highlighting, macro expansion and code navigation features
- > have not been matched with any of the other major IDEs that
I
- > use (MS VS 2008 with V Assist X and Xcode). Since Apple has
- > moved to x86_64 as the default arch for GCC to create this
- > has added even more problems for OS X C/C++ developers to
use
- > CDT. Add to that the other debugging issues as laid out
above
- > and you get a really bad experience on OS X. I'll now step
- > off the soap box..
- >
- > --
- > Mike Jackson
<www.bluequartz.net>
- >
- > On Nov 3, 2009, at 12:41 PM, Christian W. Damus wrote:
- >
- > > The problem with adding new API on the maintenance
stream
- > is that any
- > > client bundle that wants to use this new API needs a
new
- > minor version
- > > (x.y) of the bundle that supplies the API, in order to
- > > sensibly express a new lower bound in its dependency
range.
- > > However, the supplier bundle can't actually raise its
- > version to the
- > > next minor number because then (a) it will conflict with
the minor
- > > version increment of the next release and (b) it will
no
- > longer look
- > > like a service release, so user installs performing service
updates
- > > won't get anything.
- > >
- > > If this really is new public API, then adding it in the
maintenance
- > > stream is certain to break some client workflows.
- > >
- > > Cheers,
- > >
- > > Christian
- > >
- > >
- > > On Tue, 2009-11-03 at 11:27 -0600, John Cortell wrote:
- > >> I don't believe new API is a problem, even for a
- > maintenance release.
- > >> I think stability is the key. Any significant amount of
code,
- > >> API-related or not, that can destabilize existing
features
- > is what we
- > >> should avoid. I think a new binary parser is a
safe
- > addition, as long
- > >> as it hasn't mucked around much with the underlying
support code.
- > >>
- > >> John
- > >>
- > >> At 11:18 AM 11/3/2009, Andrew Gvozdev wrote:
- > >>> Hi,
- > >>> There is a contribution of Mach-O binary parser for
Mac
- > 64 bit. In
- > >>> CDT 6.1 it is being added as a new parser. I
believe it would be
- > >>> valuable addition to 6.0.X stream as well.
Technically it
- > introduces
- > >>> new API and API changes for maintenance stream are
not
- > allowed but
- > >>> in this case I would advocate to add it there.
- > >>>
- > >>> Does anybody have an objection?
- > >>>
- > >>>
https://bugs.eclipse.org/bugs/show_bug.cgi?id=270790
- > >>>
- > >>> Andrew
- > >>>
_______________________________________________
- > >>> cdt-dev mailing list
- > >>>
cdt-dev@...
- > >>>
https://dev.eclipse.org/mailman/listinfo/cdt-dev
- > >> _______________________________________________
- > >> cdt-dev mailing list
- > >>
cdt-dev@...
- > >>
https://dev.eclipse.org/mailman/listinfo/cdt-dev
- > >
- > >
- > > Christian W. Damus
- > > Software Developer, IDE Team
- > > QNX Software Systems
- > >
- > _______________________________________________
- > cdt-dev mailing list
- >
cdt-dev@...
- >
https://dev.eclipse.org/mailman/listinfo/cdt-dev
- >
- _______________________________________________
- cdt-dev mailing list
- cdt-dev@...
-
https://dev.eclipse.org/mailman/listinfo/cdt-dev
- _______________________________________________
- cdt-dev mailing list
- cdt-dev@...
-
https://dev.eclipse.org/mailman/listinfo/cdt-dev
- _______________________________________________
- cdt-dev mailing list
- cdt-dev@...
-
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
|
Re: Addition of Mach-O 64 Binary Parser to 6.0.2
Additionally, the x-internal attribute allows named bundles to be "friends," not subject to the visibility restriction. This is common amongst a group of related bundles in a component (e.g., letting UI bundles see the internals of their Core counterparts).
It might also be worth noting that the general recommendation for Eclipse projects is to export all packages, even if they are internal, for the benefit of those clients that want to take their chances with internals. Does the CDT project implement this recommendation as policy?
Cheers,
Christian
On Wed, 2009-11-04 at 13:39 -0600, John Cortell wrote:
All public classes in an internal package are internal, as are its public methods/fields. So all you need to do is #1.
John
At 11:53 AM 11/4/2009, Andrew Gvozdev wrote:
On Wed, Nov 4, 2009 at 12:36 PM, Schorn, Markus <Markus.Schorn@...> wrote:
Creating API problem filters just hides the problems. And if you create a problem filter, very soon others will follow.
You can put the MachOParser64 into an internal package, if necessary it can be made public in 6.1.
Markus.
I do not see how I can put it in internal package. I see 2 problems with that:
1. The class is referenced from another plugin. Should I export the internal package in manifest with x-internal?
2. Even if I manage to do that it uses a new constructor from class in different package which I have to make public to get access to it. How do I get around that?
Hmm, even if I create API problem filters the tooling still complains that I have to increment minor version after I recompile from scratch. Isn't the filters supposed to get API problems ignored?
Andrew
From: cdt-dev-bounces@... [cdt-dev-bounces@...] On Behalf Of Andrew Gvozdev
Sent: Wednesday, November 04, 2009 5:11 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Addition of Mach-O 64 Binary Parser to 6.0.2
Importance: Low
For 6.0.2 I was able to get around most formal API problems except public class MachOParser64 and (new) public constructor StabsReader. For those I created API filter. I also stated in JavaDoc that they are not to be used in CDT 6.0.X which makes them officially non-API.
Andrew
On Tue, Nov 3, 2009 at 1:40 PM, Schorn, Markus <Markus.Schorn@...> wrote:
Adding @noextend and @noinstantiate tags is another way of breaking API. My thought just was that
even if the current parsers are API, this does not prevent you from adding an additional parser that is
not public API, does it?
Markus.
From: cdt-dev-bounces@... [cdt-dev-bounces@...] On Behalf Of Andrew Gvozdev
Sent: Tuesday, November 03, 2009 7:30 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Addition of Mach-O 64 Binary Parser to 6.0.2
Importance: Low
On Tue, Nov 3, 2009 at 1:13 PM, Schorn, Markus <Markus.Schorn@...> wrote:
Adding new API to a maintenance stream is a problem. However, I do not see
(without being the expert for this) why that should keep you from adding a
new Binary Parser. Does the parser have to be API?
Well the classes are public and in theory one could extend or use them which I don't think is likely. I suppose we could add @noextend @noinstantiate tags for a good measure. The binary parser class itself (from cdt.core) is also used as an extension in managedbuilder.gnu.ui plugin.xml.
Christian, thanks for the insightful comment, that is definitely something to keep in mind.
Andrew
Markus.
> -----Original Message-----
> From: cdt-dev-bounces@...
> [cdt-dev-bounces@...] On Behalf Of Michael Jackson
> Sent: Tuesday, November 03, 2009 6:56 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Addition of Mach-O 64 Binary Parser to 6.0.2
> Importance: Low
>
> I am all for stable codes and APIs and such but CDT is
> rapidly becoming useless on OS X. Between the lack of a 64
> bit parser (which means no 64 Bit debugging) and the severe
> issues with the debugger and threads I would like to see
> these items fixed sooner rather than later, but I am probably
> the vocal minority here so I'll just say it once and leave it
> to whomever makes the decisions.
>
> CDT is a great IDE to use. The Indexer, Syntax
> Highlighting, macro expansion and code navigation features
> have not been matched with any of the other major IDEs that I
> use (MS VS 2008 with V Assist X and Xcode). Since Apple has
> moved to x86_64 as the default arch for GCC to create this
> has added even more problems for OS X C/C++ developers to use
> CDT. Add to that the other debugging issues as laid out above
> and you get a really bad experience on OS X. I'll now step
> off the soap box..
>
> --
> Mike Jackson <www.bluequartz.net>
>
> On Nov 3, 2009, at 12:41 PM, Christian W. Damus wrote:
>
> > The problem with adding new API on the maintenance stream
> is that any
> > client bundle that wants to use this new API needs a new
> minor version
> > (x.y) of the bundle that supplies the API, in order to
> > sensibly express a new lower bound in its dependency range.
> > However, the supplier bundle can't actually raise its
> version to the
> > next minor number because then (a) it will conflict with the minor
> > version increment of the next release and (b) it will no
> longer look
> > like a service release, so user installs performing service updates
> > won't get anything.
> >
> > If this really is new public API, then adding it in the maintenance
> > stream is certain to break some client workflows.
> >
> > Cheers,
> >
> > Christian
> >
> >
> > On Tue, 2009-11-03 at 11:27 -0600, John Cortell wrote:
> >> I don't believe new API is a problem, even for a
> maintenance release.
> >> I think stability is the key. Any significant amount of code,
> >> API-related or not, that can destabilize existing features
> is what we
> >> should avoid. I think a new binary parser is a safe
> addition, as long
> >> as it hasn't mucked around much with the underlying support code.
> >>
> >> John
> >>
> >> At 11:18 AM 11/3/2009, Andrew Gvozdev wrote:
> >>> Hi,
> >>> There is a contribution of Mach-O binary parser for Mac
> 64 bit. In
> >>> CDT 6.1 it is being added as a new parser. I believe it would be
> >>> valuable addition to 6.0.X stream as well. Technically it
> introduces
> >>> new API and API changes for maintenance stream are not
> allowed but
> >>> in this case I would advocate to add it there.
> >>>
> >>> Does anybody have an objection?
> >>>
> >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=270790
> >>>
> >>> Andrew
> >>> _______________________________________________
> >>> cdt-dev mailing list
> >>> cdt-dev@...
> >>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >> _______________________________________________
> >> cdt-dev mailing list
> >> cdt-dev@...
> >> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> >
> > Christian W. Damus
> > Software Developer, IDE Team
> > QNX Software Systems
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
