Thanks for some clarification Rob. I’m
not convinced remote indexing is a good solution. You can chose to ignore that.
That’s part of price we all pay working in open source. It is almost
impossible to make everyone happy, although we’ve done a good job of that
up until now. If at the end of the day I am the only one concerned, I have no
problem letting Chris and his team proceed with this.
You mention that MIPS are expensive, yet
you are taking one of the most MIPS expensive components of the CDT, the
indexer, and running it there. I guess that’s why I’m having a hard
time understanding why you are doing what you are doing. Also, you say remote
indexing, yet the solution you are proposing is much more that that. You are
taking a collection of indexing clients and running them there as well. I have some
problem with remote indexes, but putting the computations for calculating things
like call hierarchy and content assist there hurts my head.
As I mentioned, I am only one opinion. We
have a tradition of openness in the CDT which is making us one of the most
successful projects at Eclipse. I will continue to share my opinion, as does
everyone. We’ve never had a committer use their veto and my hope is that
that tradition will continue as well. We will continue to work together to put
forward the best CDT we can make for ALL our users.
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Rob Cecco
Sent: Friday, March 16, 2007 11:51
AM
To: CDT
General developers list.
Subject: RE: [cdt-dev] Indexer
conf call?
Normally I let Chris Recoskie speak for IBM as he is in
charge of our technical contributions to CDT. Unfortunately the tone of
the discussion thread has changed. As for the comments related to IBM
tearing apart CDT, nothing could be further from the truth. We have
committed 5 resources long term to ensure that CDT progresses to the heights
that it is capable of reaching. A lot of hard work by the whole community
has gone into CDT over the years to provide the rich set of features we have
today. That said, CDT does not address an important C/C++ development
community well enough, namely the high performance computing community. Running
CDT locally on the type of hardware this community targets is not feasible due
to the high cost of the MIPS. Running CDT on a local workstation via a
remote share (as you propose) does not scale cross country or overseas when the
project and include paths span thousands of files. We have tried this
approach on various products and the bottleneck has always shown to be network
latency. We are in the process of generating the performance numbers
supporting our assertion. Remote indexing is a goal for a number of IBM
products but it is also a goal for the Eclipse Parallel Tools Platform project
that is built on CDT. We are committed to working with the community to
enhance CDT to the benefit of all companies who ship products based on CDT and
to do so under the community processes that are in place.
Robert Cecco
Development Manager, CDT
IBM Toronto Lab
|
Doug Schaefer <DSchaefer@xxxxxxx>
Sent
by: cdt-dev-bounces@xxxxxxxxxxx
03/15/2007 04:44 PM
|
Please
respond to
"CDT General developers list."
<cdt-dev@xxxxxxxxxxx>
|
|
|
To
|
"CDT General
developers list." <cdt-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
RE: [cdt-dev] Indexer conf call?
|
|
I'm
not totally sure what you guys are talking about. If you are talking
about the DAO thing, I don't consider that an API
of the CDT. In fact I'd
rather people not know about it. It is a hack to
allow the IBM to tear apart
the CDT at their whim while adding complexity to
an already too complex
architecture. No one else will benefit from it.
Did I mention I really don't
like this thing? ;) Until someone shows me the
real costs, I will continue
to believe that indexing locally and accessing the
files over the wire is
the correct architecture, especially now that the
CDT never parses an
unchanged file more than once.
So as such, the DAO interface can be changed
whenever.
Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead,
http://cdtdoug.blogspot.com
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Chris Recoskie
> Sent: Thursday, March 15, 2007 4:08 PM
> To: CDT General
developers list.
> Subject: Re: [cdt-dev] Indexer conf call?
>
> Hi Andrew,
>
> I'm not sure if you mean whether we (IBM)
have slack in terms of our
> schedule for getting the items in before the
freeze, or if you mean
> whether
> we have slack as to what release of CDT they
would go in.
>
> I'll try to answer both questions.
>
> If (big if...) we were going to move all the
clients to the DAO model
> (call
> hierarchy, type hierarchy, search, etc.), our
internal schedule says we
> would be done this in early to mid April (I
can break this down in detail
> if anyone is interested). If the work
only has to make the feature freeze
> then there is a couple of weeks of slack.
We didn't get consensus yet
> that
> everyone has a warm fuzzy feeling about
migrating all the clients though.
> For those clients that have already a good
separation of UI and back end
> such as the call hierarchy and type hierarchy
this would be a relatively
> simple process, but for other clients it
might or might not take more work
> to factor out the back end. For our
part we are very concerned with
> making
> sure that quality is maintained and we've
been rigorously running the UI
> tests to make sure we haven't been breaking
anything.
>
> In terms of CDT releases, that probably bears
some discussion and
> clarification...
>
> Markus was concerned about making it for API
freeze... I guess the
> questions we need to answer are what are our
(as in CDT's) APIs going to
> be
> and are we actually prepared to freeze them
in two weeks given that
> feature
> work is ongoing up until April 30th.
Some things are obviously going to
> be
> API (IIndex and the like, new project model
stuff, etc.) but in terms of
> the back end to the views and other index
based services it's not very
> clear to me what is going to be API and what
isn't.
>
> What is API and what is not has a lot of
ramifications...
>
> - What are we freezing for API freeze?
Are we in fact freezing at M6?
> Personally I'm not sure it's practical to
freeze API prior to feature work
> being done unless the system is very mature
(i.e., if you are the Eclipse
> Platform and are not implementing a
huge amount of features in this
> release you have a much easier time of
freezing API ahead of your feature
> delivery than we do). That's just my
$0.02 CDN though...
>
> - What can and cannot be put in between M6
and the feature freeze?
>
> - What can and cannot be done in CDT 4.1 that
doesn't make it into CDT
> 4.0?
> In a 4.1 we can add new API but can't break
existing API. To break
> existing API we'd need a CDT 5.0, which would
be a year from now.
>
> In terms of our own desires at IBM, a year is
a long time to wait because
> it doesn't line up well with our product
release cycle (it already takes
> almost a year for us to deploy products based
on CDT, so it would be
> basically two years before anything consuming
our proposed functionality
> would see the light of day if we had to wait
until CDT 5.0 to get the
> changes in). It likely suits our
purposes well enough if we can get
> something done this year, and we are not
entirely picky about which
> release
> that would be so long as the changes happen
and we are not restricted by
> the versioning rules.
>
> What are people's thoughts on the API issues?
>
> ===========================
>
> Chris Recoskie
> Team Lead, IBM CDT Team
> IBM Toronto
> http://www.eclipse.org/cdt
>
>
>
>
> From:
Andrew.Ferguson@xxxxxxxxxxx
>
> To: "CDT General developers list."
<cdt-dev@xxxxxxxxxxx>
>
> Date: 15/03/2007 03:06 PM
>
> Subject Re: [cdt-dev] Indexer conf
call?
> :
>
>
>
>
>
>
> hi,
>
> I've posted minutes for the meeting here:
> http://wiki.eclipse.org/index.php/CDT/calls/IndexingMar2007_1
> if I've missed anything then please add it
in.
>
> We ran out of time at the end, just as we
were discussing the scale of
> changes proposed. My next
> question was going to be if you have any
slack in terms of whether these
> changes make CDT 4.0?
>
> thanks,
> Andrew
>
>
>
>
>
>
**********************************************************************
> Symbian Software Ltd is a company registered
in England and Wales with
> registered number 4190020 and registered
office at 2-6 Boundary Row,
> Southwark, London, SE1 8HP,
UK. This
message is intended only for use by
> the named addressee and may contain
privileged and/or confidential
> information. If you are not the named
addressee you should not
> disseminate,
> copy or take any action in reliance on it. If
you have received this
> message in error please notify
postmaster@xxxxxxxxxxx and delete the
> message and any attachments accompanying it
immediately. Neither Symbian
> nor any of its Affiliates accepts liability
for any corruption,
> interception, amendment, tampering or viruses
occurring to this message in
> transit or for any message sent by its
employees which is not in
> compliance
> with Symbian corporate policy.
> **********************************************************************
>
_______________________________________________
> 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
|
