Re: [cdt-dev] DSF/CDI Launchers weirdness

[Pawel Piech <pawel.piech@xxxxxxxxxxxxx>]

I think this is a fascinating discussion and I hope that as long as we refrain personal attacks and focus on constructive criticism it's OK to use our internal voices ;-)

>From my point of view I feel that we've committed the sin of a "grand redesign" against the CDT debugger. 

A little background: I really enjoyed the Uncle Bob keynote at EclipseCon, so I searched more on the speaker and found this video along the same lines as the keynote.  There's a hilarious passage in the video where Uncle Bob talks about the grand redesign which goes like this:  First the developers realize that their product is crap so a bunch of "architects" decide that it's time to throw the whole thing away and start over clean.  They form a tiger team to work on the new project. Meanwhile the rest of the developers are stuck supporting the old product and end up hating the tiger team.  But the punch line is that the old product is not a static, it keeps changing so the new and the old products get into a race for features (sound familiar?).  By the time the new product catches up, the original members or the tiger team are gone and a newer tiger team forms which decides that the old "new product" is actually a bunch of crap and they need to start over.

We say that "CDT is a product"  ("Eclipse is a product") is a myth, because we don't want to take responsibility for something that we're not paid to support.  I say that CDT is a product, because user's perception is reality.  It is a product of our communal effort, which actually amounts to a lot more in resources than most of our individual commercial efforts with the IDE.  We should make decisions wrt. to the CDT product with the same care that we make them wrt. our commerical products.

For Wind River's debugger product we did not take the "grand redesign" approach with DSF, or at least not the extent as we did in CDT.  Instead we've been absorbing in DSF in a piece meal fashion, migrating individual views as they mature enough to meet our requirements.  It's clear to me that we should have at least made an attempt to do the same with CDT's GDB integration.  It may have taken a lot more work and maybe we'd not be as far along with DSF-GDB if we took this route.  However, quite likely we would have had more and more satisfied users for our new technology.

Looking forward, I also see TCF as new architecture which could be disruptive to the CDT product.  I hope that we take the lessons from the DSF experience and manage the TCF adoption better. 

BTW, Uncle Bob's main message is that it's not the architecture that makes a great product.  Rather it's its test suite.  So as much as I can I'm going to try to commit my time to developing tests which will help us make sure that we don't leave our users stranded.

Cheers,
Pawel

Doug Schaefer wrote:

To grow a community, they have to have a vested interest in contributing. This is my opinion (and I'm full of them this week it seems), but making DSF the "default" didn't bring the contributions and will actually do quite little at bringing more. DSF has been there a long time and the community has had plenty of opportunity to contribute. They just haven't had the vested interest to do so. Changing the default created the perception that we were abandoning CDI, and that is what created the need. And, of course, once DSF-GDB is at parity, I fully anticipate that need will be gone again.

I do see a need for better target management, something we talked about years ago before DSDP was created and the unfortunate (my opinion again) decision to use RSE was made. TCF is the technology that people seem to be gathering around today. That is the next ground where I see we can grow a community. Of course, I don't expect the community with a vested interest in gdb to come assist with that. And that's fine. I don't have a vested interest in gdb either.

I'm probably using my inside voice too much here, but I want people clear on where I stand on this, so you can understand why I'm prioritizing the work I'll be doing.

On Tue, Apr 13, 2010 at 1:00 PM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:

Doug,  I'm really glad to read your last email.

I agree (and am kind of bummed) that the efforts on debug are being pulled from all sides

without a clear focus on usability.    My internal customers will also want to have

better usability and I'm sure I could convince my management to get some time on it.

 

However, I strongly believe that if we want to get more help from the community for debug

we need to get more people exposed to DSF.  That is my motivation to work so hard

on the feature-parity issues.  Already the effort has paid off as we've been getting many

new patch contributions (in fact, having time to review them has proved a pleasant challenge).

I feel we need to continue in those steps to build a stronger community for DSF.  This should

lead to more fixes, more features, more stability and more usability, eventually.

 

Of course, I know you are fully aware of all this, and in fact, you are one of the people that thought

me about open-source and community.  I'm just writing this to try to explain my current priorities.

 

Marc

 

---

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer

Sent: Tuesday, April 13, 2010 11:02 AM
To: elaskavaia.cdt@xxxxxxxxx; CDT General developers list.

Subject: Re: [cdt-dev] DSF/CDI Launchers weirdness

Yes, I am wishing for an ideal world. My problem is that such an ideal world wouldn't be that hard to implement. My perception is that everyone is fighting for their favorite debug integration solution versus the general good of the CDT user. That's harsh, but we do talk way more about things like parity than usability. As I switch my focus to TCF and dive deeper into the debug world, maybe that'll open up bandwidth for me to finally fix it next year.

Doug.

On Mon, Apr 12, 2010 at 3:16 PM, Alena Laskavaia <elaskavaia.cdt@xxxxxxxxx> wrote:

In ideal world that would be fine, so in this world we just replace
backend from CDI to DSF
and all features are only better and all bugs are fixed. Since it is
not that ideal we have no
choice but to involve user in the choosing - new features but some old
features not working and more bugs,
or old and more robust but less features.

On Mon, Apr 12, 2010 at 3:11 PM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
> My hope is that when the user hits run, it never asks him for anything, it
> just runs a local application determined by the context of the selection and
> assuming the application can run locally, which we should also be able to
> determine. There should never be a question on what debugger integration to
> use for run because it doesn't matter.
> I think the same should be true for Debug. We should be able to tell from
> the context of the selection what debugger to run. And that decides what
> integration to use, not the other way around. This is something I've stated
> before, and I still stand by it.
> I just think we've hijacked launch configuration types for debugger
> integrations. There should be only be one for Local Applications, and the
> choice of debugger integration is further down the pipe. We should never put
> the choice of debugger integration into the face of the user. There's no way
> they can understand the choice.
> On Mon, Apr 12, 2010 at 2:23 PM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
> wrote:
>>
>>
>> > -----Original Message-----
>> > From: cdt-dev-bounces@xxxxxxxxxxx
>> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
>> > Sent: Monday, April 12, 2010 2:18 PM
>> > To: CDT General developers list.
>> > Subject: Re: [cdt-dev] DSF/CDI Launchers weirdness
>> >
>> > I find the whole thing a bit weird. What this is showing is
>> > that the Eclipse Launch system, didn't anticipate that there
>> > would be multiple launch configurations types for a given way
>> > of launching. As there shouldn't be more than one config type
>> > to "Run" a C++ Local Application (they all do the same
>> > anyway, no?), there probably shouldn't be more than one
>> > config type to "Debug" a C++ Local Application. We've
>> > abstracted at the wrong level and that's just confusing as
>> > hell. Our users won't get it. And our vendors still won't use
>> > what we provide.
>>
>> The terminology always confuses me so I might have mis-understood
>> what you meant, but here goes:
>>
>> We only have one launch configuration type for Run:
>> "C/C++ local application".
>> After you've chosen this launch config type, you have to
>> choose which debugger integration using the hyperlink at the
>> bottom of the launch tabs.
>>
>> For Debug, it is not great but necessary.
>> But for Run?  Do we really need to have that extra step?
>> I say we have a single launch delegate when using Run.
>>
>> Does it make sense?
>>
>>
>> >
>> > Sorry, just venting, and a bit sad that the situation hasn't
>> > improved any in 7.0. It's still quite a mess.
>> >
>> >
>> > On Mon, Apr 12, 2010 at 2:09 PM, Marc Khouzam
>> > <marc.khouzam@xxxxxxxxxxxx> wrote:
>> >
>> >
>> >       I think the problem becomes visible because you have EDC.
>> >       When I don't have EDC and I select Run As, there is no prompt
>> >       and the program launches using CDI.  This is fine
>> >       because there is actually no debugging going on.
>> >
>> >       Once you have EDC, I believe the platform no longer knows
>> >       which between CDI and EDC to choose, and that is why
>> > you get the prompt.
>> >
>> >       So, maybe adding support in DSF-GDB for Run, may not be
>> > the right solution.
>> >       Do we really want to have the user need to choose a
>> > debugger integration
>> >       even for Run?  Why choose between CDI, DSF-GDB or EDC,
>> > when there will
>> >       be no debugging?
>> >
>> >       How about a single launch delegate for Run, for all of CDT?
>> >
>> >
>> >       > -----Original Message-----
>> >       > From: cdt-dev-bounces@xxxxxxxxxxx
>> >       > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of
>> > Alena Laskavaia
>> >       > Sent: Monday, April 12, 2010 12:39 PM
>> >       > To: Pawel Piech
>> >       > Cc: CDT General developers list.
>> >       > Subject: Re: [cdt-dev] DSF/CDI Launchers weirdness
>> >       >
>> >
>> >       > Well it has EDC there too in the list for Run. I
>> > don't know if it is
>> >       > different but it technically I pick EDC for run
>> > instead of standard
>> >       > launch.
>> >       >
>> >       > On Mon, Apr 12, 2010 at 12:35 PM, Pawel Piech
>> >       > <pawel.piech@xxxxxxxxxxxxx> wrote:
>> >       > > This appears to be a bug in the multiple launchers support
>> >       > in platform.
>> >       > >  Could you file it as a bug?
>> >       > >
>> >       > > I think the correct behavior would be for the launch
>> >       > framework to use CDI
>> >       > > without prompting you whenever you select the run.
>> >       > > -Pawel
>> >       > >
>> >       > > Alena Laskavaia wrote:
>> >       > >>
>> >       > >> I was playing a bit with debugger lately and work flow is
>> >       > really awkward
>> >       > >> for me.
>> >       > >> I don't have official build I am running from the trunk
>> >       > but what I see is
>> >       > >> weird.
>> >       > >> So looks like DSF does not have a "Launcher" (the
>> > stuff you switch
>> >       > >> using link in the bottom) for Run
>> >       > >> configuration, but does for Debug. So I have to pick
>> >       > different ones for
>> >       > >> Run
>> >       > >> and Debug. So I compile my app and do Run As->Local C++
>> >       > App - and it gives
>> >       > >> me list which does not include DFS - so I pick standard.
>> >       > When I debug
>> >       > >> I have to do it again to switch to DSF. If I do opposite -
>> >       > pick DFS from
>> >       > >> Debug -
>> >       > >> when I do Run - my launch for run - does not do
>> > anything, cannot be
>> >       > >> terminated and
>> >       > >> deleted, and if I open launch configuration it shows that
>> >       > I use DSF -
>> >       > >> which is not in the
>> >       > >> list if I click on link.
>> >       > >>
>> >       > >> Is it expected behaviour?
>> >       > >> _______________________________________________
>> >       > >> cdt-dev mailing list
>> >       > >> cdt-dev@xxxxxxxxxxx
>> >       > >> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>> >       > >>
>> >       > >
>> >       > >
>> >       > _______________________________________________
>> >       > cdt-dev mailing list
>> >       > cdt-dev@xxxxxxxxxxx
>> >       > https://dev.eclipse.org/mailman/listinfo/cdt-dev
>> >       > _______________________________________________
>> >       cdt-dev mailing list
>> >       cdt-dev@xxxxxxxxxxx
>> >       https://dev.eclipse.org/mailman/listinfo/cdt-dev
>> >
>> >
>> >
>> > _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev