| Incremental builder and search functionality questions. [message #16470] |
Tue, 12 February 2008 07:27  |
Eclipse User |
|
|
|
Hi,
I'm trying to investigate IMP features and capabilities and have questions:
1. I look at BuilderBase implementation and cannot find out if build state
and dependecies persisted over Eclipse sessions. If so could you point me
where it happens?
2. I do not completely understand how I can implement search functionality.
To my mind to support such feature AST for workspace must be indexed and
(may be) persisted. So has IMP such or other support for implementing search
features. Also I think refactoring must strongly rely on search
functionality, dosen't it?
Sergey Gomanyuk.
|
|
|
| Re: Incremental builder and search functionality questions. [message #16511 is a reply to message #16470] |
Sat, 16 February 2008 10:25  |
| Eclipse User |
|
|
|
Sergey Gomanyuk wrote:
> Hi,
>
> I'm trying to investigate IMP features and capabilities and have questions:
> 1. I look at BuilderBase implementation and cannot find out if build state
> and dependecies persisted over Eclipse sessions. If so could you point me
> where it happens?
The builder support does not currently handle persistence of build state
or dependencies. That's a significant hole in the design/implementation
that presently we have no one to help fill. Might you be interested in
lending a hand there?
> 2. I do not completely understand how I can implement search functionality.
> To my mind to support such feature AST for workspace must be indexed and
> (may be) persisted. So has IMP such or other support for implementing search
> features. Also I think refactoring must strongly rely on search
> functionality, dosen't it?
I had started to work on an indexed search mechanism, by generalizing
the JDT's search mechanism, which appears in org.eclipse.imp.runtime,
but I basically decided to abandon that work in lieu of a more general
mechanism (see below). The code doesn't even quite compile, because I
only got partway through the process of removing dependencies on the
JDT. On the bright side, it's "dead code" (nothing refers to it). :-)
You're right that refactoring relies heavily on the search mechanism.
We're in the process of building a general-purpose, persistent, program
"fact database" that's intended to support things like search, browsing
(e.g. the Type Hierarchy or Call Graph views), analysis, and particularly
refactoring. It's based on an extended relational model. It's work in
progress and very raw at the moment, but it's high on our priority list
and we are actively working on it. I expect we'll release some details
and a prototype within a month or so.
--
Cheers,
-- Bob
--------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center
IMP Team Lead (http://eclipse-imp.sourceforge.net)
X10: Productivity for High-Performance Parallel Programming (http://x10.sf.net)
|
|
|
| Re: Incremental builder and search functionality questions. [message #569235 is a reply to message #16470] |
Sat, 16 February 2008 10:25 |
| Eclipse User |
|
|
|
Sergey Gomanyuk wrote:
> Hi,
>
> I'm trying to investigate IMP features and capabilities and have questions:
> 1. I look at BuilderBase implementation and cannot find out if build state
> and dependecies persisted over Eclipse sessions. If so could you point me
> where it happens?
The builder support does not currently handle persistence of build state
or dependencies. That's a significant hole in the design/implementation
that presently we have no one to help fill. Might you be interested in
lending a hand there?
> 2. I do not completely understand how I can implement search functionality.
> To my mind to support such feature AST for workspace must be indexed and
> (may be) persisted. So has IMP such or other support for implementing search
> features. Also I think refactoring must strongly rely on search
> functionality, dosen't it?
I had started to work on an indexed search mechanism, by generalizing
the JDT's search mechanism, which appears in org.eclipse.imp.runtime,
but I basically decided to abandon that work in lieu of a more general
mechanism (see below). The code doesn't even quite compile, because I
only got partway through the process of removing dependencies on the
JDT. On the bright side, it's "dead code" (nothing refers to it). :-)
You're right that refactoring relies heavily on the search mechanism.
We're in the process of building a general-purpose, persistent, program
"fact database" that's intended to support things like search, browsing
(e.g. the Type Hierarchy or Call Graph views), analysis, and particularly
refactoring. It's based on an extended relational model. It's work in
progress and very raw at the moment, but it's high on our priority list
and we are actively working on it. I expect we'll release some details
and a prototype within a month or so.
--
Cheers,
-- Bob
--------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center
IMP Team Lead (http://eclipse-imp.sourceforge.net)
X10: Productivity for High-Performance Parallel Programming (http://x10.sf.net)
|
|
|
Powered by
FUDForum. Page generated in 0.03652 seconds
Home