missing org.eclipse.cdt.debug.mi.core in Neon?

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: missing org.eclipse.cdt.debug.mi.core in Neon?

Marc Khouzam
To be clear, this is an API change.  Part of it puts back a constructor that was removed,
while the other part adds a new method.  The changes don't break the current API.

+1 on this change to support the CDT community.

Thanks Jonah for making this happen in such a short time.

Marc

From: [hidden email] [[hidden email]] on behalf of Jonah Graham [[hidden email]]
Sent: May 25, 2016 7:10 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] missing org.eclipse.cdt.debug.mi.core in Neon?

Hi all,

I would request approval and review of https://git.eclipse.org/r/#/c/73574 for CDT 9.0 please.

There is a corresponding pull request downstream that consumes these changes: https://github.com/gnuarmeclipse/plug-ins/pull/120

Thanks,
Jonah

~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com

On 25 May 2016 at 02:39, Doug Schaefer <[hidden email]> wrote:
On Tue, May 24, 2016 at 9:30 PM, Marc Khouzam <[hidden email]> wrote:

Right.
The missing plugin will not be put back. That can be fixed without changing CDT.
What needs CDT's help is a removed constructor in DSF-GDB.
Jonah has been kind enough to figure all this out and may be able to post a fix by tomorrow.

And that is the right way to put it. Thank you Jonah!
 

I'm expecting 5 to 10 lines tops.


From: Doug Schaefer <[hidden email]>
Sent: May 24, 2016 21:21
To: CDT General developers list.
Subject: Re: [cdt-dev] missing org.eclipse.cdt.debug.mi.core in Neon?

On Tue, May 24, 2016 at 7:40 PM, Liviu Ionescu <[hidden email]> wrote:

> On 25 May 2016, at 01:51, Marc Khouzam <[hidden email]> wrote:
>
> ... I'm willing to look into reintroducing the removed API

if you can reintroduce org.eclipse.cdt.debug.mi.core alone, and this does not have other dependencies, then for now I don't have to remove any dependencies, and we can delay doing it properly in a future version.

I understand the race conditions in multi-launches situations, but the impact on the GNU ARM plug-in users is minimal. and considering that the alternative is to not be able to install the plug-ins on Neon, I think it is perfectly acceptable.

Just make sure CDI is not reintroduced. From what I understand from the discussion, the problem isn't about that.

Thanks,
Doug.
 


regards,

Liviu

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: missing org.eclipse.cdt.debug.mi.core in Neon?

Marc Khouzam
In reply to this post by John Cortell-4
This one is on me.
I removed APIs that were not deprecated.  I new this was a risk but I made
a judgement call that in this particular case, it was better for extenders in the long run.
I asked for opinions here: https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg30262.html
and here: https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg30265.html

To be clear, I feel this approach should be the _exception_ and not the rule.  But exceptions
are sometimes valuable. All the more so, when opportunities to improve API come every 5 years
or so.  To be fully transparent, there probably still are one or two removals of non-deprecated
APIs as part of CDT 9.0.

Doug had the foresight to move up API-breaking freeze to M6, which gave extenders ample
time to try to compile with CDT 9.0 and notice anything particularly disturbing to them; giving
us time to react and fix things.  But I understand that with contributors'/extenders' time
being limited, just as our time is limited, it is often difficult to test as early as we would wish.
I'm glad this particular issue was reported in time for us to react.
And I'm glad Jonah jumped on this so quickly to resolve it.

The comforting thought is that the next API-breaking version of CDT is probably not
before 5 years in the future :)

BR,

Marc


From: [hidden email] [[hidden email]] on behalf of John Cortell [[hidden email]]
Sent: May 25, 2016 11:18 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] missing org.eclipse.cdt.debug.mi.core in Neon?

> As far as deprecating API, CDT does not have a deprecation policy, certainly

> nothing like the quite heavyweight one the platform does. The reality is if

> we did have such a policy, I don't think this kind of code clean-up would

> ever happen. The removal of CDI and the code cleanup was announced

> well in advance on the mailing list.

 

Sorry to extend this thread even further. IMO, the best mechanism for giving a heads-up on API cleanup is through annotations. That is far more effective and reliable than mailing lists, EclipseCON presentations and BOFs, wikis, etc. You are advertising your intentions directly to every developer that is integrating CDT into a product, injecting the notification directly into his development workflow. If the developer has turned off such warnings/errors, or fails to act on the markers…oh, well. Not your fault; it’s his.

 

This isn’t about a heavyweight process. It’s mostly about being patient and taking due diligence. If today you decide you’d like to remove a public type, method or field, annotate it “@Deprecated // in Neon”. In every future major release cycle, you would grep the codebase for these annotations and see which ones are suitable for executing on based on when they were deprecated (recorded in the comment) and whether it has crossed the acceptable threshold (2 or 3 years, e.g.).

 

If it feels heavyweight, OK. But I guess that’s the price you pay when you’ve created SW that exposes API that hundreds of developers have latched on to. The only acceptable alternative, IMO, is to never clean up API, which is not a good solution in my book. Anyway, I’m butting in here only because I think it would be good if we do more than just avert this particular break of GNU ARM Eclipse. Hopefully there will be some process/behavioral change that will make this situation less likely to happen again.

 

John

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Jonah Graham
Sent: Wednesday, May 25, 2016 6:10 AM
To: CDT General developers list. <[hidden email]>
Subject: Re: [cdt-dev] missing org.eclipse.cdt.debug.mi.core in Neon?

 

Hi John,

 

I agree with what you say. This is our chance to cleanup API and we have to do it now (and regularly in the future) to keep CDT maintainable. 

 

As far as deprecating API, CDT does not have a deprecation policy, certainly nothing like the quite heavyweight one the platform does. The reality is if we did have such a policy, I don't think this kind of code clean-up would ever happen. The removal of CDI and the code cleanup was announced well in advance on the mailing list.

 

That said, we (CDT devs) have a responsibility to people who are active in the community to not make life unnecessarily hard for them. I think this is a perfect test case (as was TCF a couple of months ago). Someone depending on CDT came along, tried out the new release before it was released, and found their code didn't work. Working with them (GNU ARM now and TCF earlier) we determined that the cleanup had to mostly happen on their side to keep up to date with the APIs.

 

In the case of TCF, the review led mostly to removing some defunct dependencies. Then we were left with one awkward API change. The decision was to copy the new code from http://eclip.se/456116#c10 from CDT 9 into TCF so that TCF could continue to work with CDT 8 and CDT 9 from a single source and binary distribution.

 

In the case of GNU ARM the issues were almost identical to TCF. In addition though there was another class that needed to be copied, but copying it is not straightforward http://eclip.se/488909#c3 as it has lots of dependencies too. Therefore I think the best solution is to clean up the code as was done in Bug 488909, but maintain the original API too. That resurrection is covered by http://eclip.se/494504.

 

I hope I have done enough to satisfy everyone that careful consideration has been undertaken on these changes and that there are no objections to http://eclip.se/494504 for CDT 9.0.

 

Jonah

 

~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com

 

On 25 May 2016 at 02:58, John Cortell <[hidden email]> wrote:

> mark them as deprecated, and just keep them there for a while,
> until everything will be migrated to 9.0 and compatibility with 8.x
> will no longer be required.

If I understand this correctly, the request is to defer API cleanup until GNU ARM Eclipse no longer supports CDT 8.x. When will that be? And who's to say that at that point, another CDT product isn't caught off guard by the cleanup and requests the same thing--another deferral. And let's keep in mind that API cleanup (breakage) can only happen on a major release, which does not happen every year. It's happening this summer, but who knows when the next opportunity will be. I'm just wondering if this effectively comes down to a request to never clean up API if its breaks backward compatibility. Products that deploy different versions for different Eclipse release trains is not unheard of. It's for sure a pain for both consumer and producer, but it's doable and many have done it.

That said, API that is removed should have been marked deprecated for at least 2-3 years, IMO. If that wasn't the case here, it seems reasonable to cry foul.

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 


_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: missing org.eclipse.cdt.debug.mi.core in Neon?

Jonah Graham
Thank you Marc for explaining everything clearly. I think it is key to reassure extenders that we aren't doing this again for a while.

~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com

On 25 May 2016 at 16:45, Marc Khouzam <[hidden email]> wrote:
This one is on me.
I removed APIs that were not deprecated.  I new this was a risk but I made
a judgement call that in this particular case, it was better for extenders in the long run.
I asked for opinions here: https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg30262.html
and here: https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg30265.html

To be clear, I feel this approach should be the _exception_ and not the rule.  But exceptions
are sometimes valuable. All the more so, when opportunities to improve API come every 5 years
or so.  To be fully transparent, there probably still are one or two removals of non-deprecated
APIs as part of CDT 9.0.

Doug had the foresight to move up API-breaking freeze to M6, which gave extenders ample
time to try to compile with CDT 9.0 and notice anything particularly disturbing to them; giving
us time to react and fix things.  But I understand that with contributors'/extenders' time
being limited, just as our time is limited, it is often difficult to test as early as we would wish.
I'm glad this particular issue was reported in time for us to react.
And I'm glad Jonah jumped on this so quickly to resolve it.

The comforting thought is that the next API-breaking version of CDT is probably not
before 5 years in the future :)

BR,

Marc


From: [hidden email] [[hidden email]] on behalf of John Cortell [[hidden email]]
Sent: May 25, 2016 11:18 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] missing org.eclipse.cdt.debug.mi.core in Neon?

> As far as deprecating API, CDT does not have a deprecation policy, certainly

> nothing like the quite heavyweight one the platform does. The reality is if

> we did have such a policy, I don't think this kind of code clean-up would

> ever happen. The removal of CDI and the code cleanup was announced

> well in advance on the mailing list.

 

Sorry to extend this thread even further. IMO, the best mechanism for giving a heads-up on API cleanup is through annotations. That is far more effective and reliable than mailing lists, EclipseCON presentations and BOFs, wikis, etc. You are advertising your intentions directly to every developer that is integrating CDT into a product, injecting the notification directly into his development workflow. If the developer has turned off such warnings/errors, or fails to act on the markers…oh, well. Not your fault; it’s his.

 

This isn’t about a heavyweight process. It’s mostly about being patient and taking due diligence. If today you decide you’d like to remove a public type, method or field, annotate it “@Deprecated // in Neon”. In every future major release cycle, you would grep the codebase for these annotations and see which ones are suitable for executing on based on when they were deprecated (recorded in the comment) and whether it has crossed the acceptable threshold (2 or 3 years, e.g.).

 

If it feels heavyweight, OK. But I guess that’s the price you pay when you’ve created SW that exposes API that hundreds of developers have latched on to. The only acceptable alternative, IMO, is to never clean up API, which is not a good solution in my book. Anyway, I’m butting in here only because I think it would be good if we do more than just avert this particular break of GNU ARM Eclipse. Hopefully there will be some process/behavioral change that will make this situation less likely to happen again.

 

John

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Jonah Graham
Sent: Wednesday, May 25, 2016 6:10 AM
To: CDT General developers list. <[hidden email]>
Subject: Re: [cdt-dev] missing org.eclipse.cdt.debug.mi.core in Neon?

 

Hi John,

 

I agree with what you say. This is our chance to cleanup API and we have to do it now (and regularly in the future) to keep CDT maintainable. 

 

As far as deprecating API, CDT does not have a deprecation policy, certainly nothing like the quite heavyweight one the platform does. The reality is if we did have such a policy, I don't think this kind of code clean-up would ever happen. The removal of CDI and the code cleanup was announced well in advance on the mailing list.

 

That said, we (CDT devs) have a responsibility to people who are active in the community to not make life unnecessarily hard for them. I think this is a perfect test case (as was TCF a couple of months ago). Someone depending on CDT came along, tried out the new release before it was released, and found their code didn't work. Working with them (GNU ARM now and TCF earlier) we determined that the cleanup had to mostly happen on their side to keep up to date with the APIs.

 

In the case of TCF, the review led mostly to removing some defunct dependencies. Then we were left with one awkward API change. The decision was to copy the new code from http://eclip.se/456116#c10 from CDT 9 into TCF so that TCF could continue to work with CDT 8 and CDT 9 from a single source and binary distribution.

 

In the case of GNU ARM the issues were almost identical to TCF. In addition though there was another class that needed to be copied, but copying it is not straightforward http://eclip.se/488909#c3 as it has lots of dependencies too. Therefore I think the best solution is to clean up the code as was done in Bug 488909, but maintain the original API too. That resurrection is covered by http://eclip.se/494504.

 

I hope I have done enough to satisfy everyone that careful consideration has been undertaken on these changes and that there are no objections to http://eclip.se/494504 for CDT 9.0.

 

Jonah

 

~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com

 

On 25 May 2016 at 02:58, John Cortell <[hidden email]> wrote:

> mark them as deprecated, and just keep them there for a while,
> until everything will be migrated to 9.0 and compatibility with 8.x
> will no longer be required.

If I understand this correctly, the request is to defer API cleanup until GNU ARM Eclipse no longer supports CDT 8.x. When will that be? And who's to say that at that point, another CDT product isn't caught off guard by the cleanup and requests the same thing--another deferral. And let's keep in mind that API cleanup (breakage) can only happen on a major release, which does not happen every year. It's happening this summer, but who knows when the next opportunity will be. I'm just wondering if this effectively comes down to a request to never clean up API if its breaks backward compatibility. Products that deploy different versions for different Eclipse release trains is not unheard of. It's for sure a pain for both consumer and producer, but it's doable and many have done it.

That said, API that is removed should have been marked deprecated for at least 2-3 years, IMO. If that wasn't the case here, it seems reasonable to cry foul.

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 


_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: missing org.eclipse.cdt.debug.mi.core in Neon?

Doug Schaefer-4
In reply to this post by Marc Khouzam
Thanks Marc, great words.

Though I don't think this is on you. We do as best we can as a contributor community to evolve the CDT to make sure it has the highest quality possible. We know there are dozens of external projects and vendors building on CDT that we never hear from. We can only guess at what they're doing. If they're not participating in the community, I can't help but feel we're doing their jobs for them. Frankly, I find that unfair.

I'm glad Liviu reached out to us before the release when we had a chance to help. I do hope this encourages everyone in his position to be more active. You don't have to contribute code, but you do have to participate in the mailing list and help guide the work that is being contributed. Open source isn't free. It's just open.

On Wed, May 25, 2016 at 11:45 AM, Marc Khouzam <[hidden email]> wrote:
This one is on me.
I removed APIs that were not deprecated.  I new this was a risk but I made
a judgement call that in this particular case, it was better for extenders in the long run.
I asked for opinions here: https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg30262.html
and here: https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg30265.html

To be clear, I feel this approach should be the _exception_ and not the rule.  But exceptions
are sometimes valuable. All the more so, when opportunities to improve API come every 5 years
or so.  To be fully transparent, there probably still are one or two removals of non-deprecated
APIs as part of CDT 9.0.

Doug had the foresight to move up API-breaking freeze to M6, which gave extenders ample
time to try to compile with CDT 9.0 and notice anything particularly disturbing to them; giving
us time to react and fix things.  But I understand that with contributors'/extenders' time
being limited, just as our time is limited, it is often difficult to test as early as we would wish.
I'm glad this particular issue was reported in time for us to react.
And I'm glad Jonah jumped on this so quickly to resolve it.

The comforting thought is that the next API-breaking version of CDT is probably not
before 5 years in the future :)

BR,

Marc


From: [hidden email] [[hidden email]] on behalf of John Cortell [[hidden email]]
Sent: May 25, 2016 11:18 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] missing org.eclipse.cdt.debug.mi.core in Neon?

> As far as deprecating API, CDT does not have a deprecation policy, certainly

> nothing like the quite heavyweight one the platform does. The reality is if

> we did have such a policy, I don't think this kind of code clean-up would

> ever happen. The removal of CDI and the code cleanup was announced

> well in advance on the mailing list.

 

Sorry to extend this thread even further. IMO, the best mechanism for giving a heads-up on API cleanup is through annotations. That is far more effective and reliable than mailing lists, EclipseCON presentations and BOFs, wikis, etc. You are advertising your intentions directly to every developer that is integrating CDT into a product, injecting the notification directly into his development workflow. If the developer has turned off such warnings/errors, or fails to act on the markers…oh, well. Not your fault; it’s his.

 

This isn’t about a heavyweight process. It’s mostly about being patient and taking due diligence. If today you decide you’d like to remove a public type, method or field, annotate it “@Deprecated // in Neon”. In every future major release cycle, you would grep the codebase for these annotations and see which ones are suitable for executing on based on when they were deprecated (recorded in the comment) and whether it has crossed the acceptable threshold (2 or 3 years, e.g.).

 

If it feels heavyweight, OK. But I guess that’s the price you pay when you’ve created SW that exposes API that hundreds of developers have latched on to. The only acceptable alternative, IMO, is to never clean up API, which is not a good solution in my book. Anyway, I’m butting in here only because I think it would be good if we do more than just avert this particular break of GNU ARM Eclipse. Hopefully there will be some process/behavioral change that will make this situation less likely to happen again.

 

John

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Jonah Graham
Sent: Wednesday, May 25, 2016 6:10 AM
To: CDT General developers list. <[hidden email]>
Subject: Re: [cdt-dev] missing org.eclipse.cdt.debug.mi.core in Neon?

 

Hi John,

 

I agree with what you say. This is our chance to cleanup API and we have to do it now (and regularly in the future) to keep CDT maintainable. 

 

As far as deprecating API, CDT does not have a deprecation policy, certainly nothing like the quite heavyweight one the platform does. The reality is if we did have such a policy, I don't think this kind of code clean-up would ever happen. The removal of CDI and the code cleanup was announced well in advance on the mailing list.

 

That said, we (CDT devs) have a responsibility to people who are active in the community to not make life unnecessarily hard for them. I think this is a perfect test case (as was TCF a couple of months ago). Someone depending on CDT came along, tried out the new release before it was released, and found their code didn't work. Working with them (GNU ARM now and TCF earlier) we determined that the cleanup had to mostly happen on their side to keep up to date with the APIs.

 

In the case of TCF, the review led mostly to removing some defunct dependencies. Then we were left with one awkward API change. The decision was to copy the new code from http://eclip.se/456116#c10 from CDT 9 into TCF so that TCF could continue to work with CDT 8 and CDT 9 from a single source and binary distribution.

 

In the case of GNU ARM the issues were almost identical to TCF. In addition though there was another class that needed to be copied, but copying it is not straightforward http://eclip.se/488909#c3 as it has lots of dependencies too. Therefore I think the best solution is to clean up the code as was done in Bug 488909, but maintain the original API too. That resurrection is covered by http://eclip.se/494504.

 

I hope I have done enough to satisfy everyone that careful consideration has been undertaken on these changes and that there are no objections to http://eclip.se/494504 for CDT 9.0.

 

Jonah

 

~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com

 

On 25 May 2016 at 02:58, John Cortell <[hidden email]> wrote:

> mark them as deprecated, and just keep them there for a while,
> until everything will be migrated to 9.0 and compatibility with 8.x
> will no longer be required.

If I understand this correctly, the request is to defer API cleanup until GNU ARM Eclipse no longer supports CDT 8.x. When will that be? And who's to say that at that point, another CDT product isn't caught off guard by the cleanup and requests the same thing--another deferral. And let's keep in mind that API cleanup (breakage) can only happen on a major release, which does not happen every year. It's happening this summer, but who knows when the next opportunity will be. I'm just wondering if this effectively comes down to a request to never clean up API if its breaks backward compatibility. Products that deploy different versions for different Eclipse release trains is not unheard of. It's for sure a pain for both consumer and producer, but it's doable and many have done it.

That said, API that is removed should have been marked deprecated for at least 2-3 years, IMO. If that wasn't the case here, it seems reasonable to cry foul.

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 


_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: missing org.eclipse.cdt.debug.mi.core in Neon?

Liviu Ionescu-2

> On 25 May 2016, at 18:57, Doug Schaefer <[hidden email]> wrote:
>
> I'm glad Liviu reached out to us before the release when we had a chance to help.

me too, me too! :-)

and I apologies if my comments offended someone; I don't want to sound as an excuse, but I was quite concerned on the future of the GNU ARM Eclipse project.


thank you all,

Liviu

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: missing org.eclipse.cdt.debug.mi.core in Neon?

Doug Schaefer-4
On Wed, May 25, 2016 at 12:04 PM, Liviu Ionescu <[hidden email]> wrote:

> On 25 May 2016, at 18:57, Doug Schaefer <[hidden email]> wrote:
>
> I'm glad Liviu reached out to us before the release when we had a chance to help.

me too, me too! :-)

and I apologies if my comments offended someone; I don't want to sound as an excuse, but I was quite concerned on the future of the GNU ARM Eclipse project.


No worries. It's an important project to a lot of CDT users so we're happy to help. It's the other projects who haven't spoken up and I'm sure we'll hear from too late that I worry about :).
 

thank you all,

Liviu

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: missing org.eclipse.cdt.debug.mi.core in Neon?

Liviu Ionescu-2
> On 31 May 2016, at 05:09, Marc Khouzam <[hidden email]> wrote:
>
> the CDT 9.0/Neon RC3 build is now posted:
> http://download.eclipse.org/tools/cdt/builds/neon/milestones/rc3
>
> zipfile:
> http://download.eclipse.org/tools/cdt/builds/neon/milestones/rc3/cdt-9.0rc3.zip

I don't know why, but downloading from these urls is dead slow.

---

apart from the speed, the rest seems ok, I installed eclipse-4.6rc3, updated to cdt-9.0rc3, installed the GNU ARM Eclipse 3.1 beta, and ran a qemu debug session without problems.

so I confirm that Jonah patches got their way into the main distribution.

---

not related to the current issue, the log is very quiet, there was only one unexpected message:

!ENTRY org.eclipse.launchbar.core 2 0 2016-05-31 16:25:01.668
!MESSAGE Enablement expression is missing for config provider for org.eclipse.cdt.qt.core.launchDescriptorType



regards,

Liviu

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: missing org.eclipse.cdt.debug.mi.core in Neon?

Doug Schaefer-4
That's just a warning. The Qt plug-ins are only preview in this release. You probably didn't need to install them.

On Tue, May 31, 2016 at 9:50 AM, Liviu Ionescu <[hidden email]> wrote:
> On 31 May 2016, at 05:09, Marc Khouzam <[hidden email]> wrote:
>
> the CDT 9.0/Neon RC3 build is now posted:
> http://download.eclipse.org/tools/cdt/builds/neon/milestones/rc3
>
> zipfile:
> http://download.eclipse.org/tools/cdt/builds/neon/milestones/rc3/cdt-9.0rc3.zip

I don't know why, but downloading from these urls is dead slow.

---

apart from the speed, the rest seems ok, I installed eclipse-4.6rc3, updated to cdt-9.0rc3, installed the GNU ARM Eclipse 3.1 beta, and ran a qemu debug session without problems.

so I confirm that Jonah patches got their way into the main distribution.

---

not related to the current issue, the log is very quiet, there was only one unexpected message:

!ENTRY org.eclipse.launchbar.core 2 0 2016-05-31 16:25:01.668
!MESSAGE Enablement expression is missing for config provider for org.eclipse.cdt.qt.core.launchDescriptorType



regards,

Liviu

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: missing org.eclipse.cdt.debug.mi.core in Neon?

Liviu Ionescu-2

> On 31 May 2016, at 16:52, Doug Schaefer <[hidden email]> wrote:
>
> That's just a warning. The Qt plug-ins are only preview in this release. You probably didn't need to install them.

I didn't need, but I'm too lazy to select, I installed everything...

so, from my point of view, everything seems ok, I'll release GNU ARM Eclipse 3.1 right after Neon is out.


regards,

Liviu

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: missing org.eclipse.cdt.debug.mi.core in Neon?

Jonah Graham
Hi Liviu,

That is great to hear!

Jonah
~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com


On 31 May 2016 at 14:56, Liviu Ionescu <[hidden email]> wrote:

>
>> On 31 May 2016, at 16:52, Doug Schaefer <[hidden email]> wrote:
>>
>> That's just a warning. The Qt plug-ins are only preview in this release. You probably didn't need to install them.
>
> I didn't need, but I'm too lazy to select, I installed everything...
>
> so, from my point of view, everything seems ok, I'll release GNU ARM Eclipse 3.1 right after Neon is out.
>
>
> regards,
>
> Liviu
>
> _______________________________________________
> cdt-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
123