Project Plan For technology.dltk, version 1.0
- DLTK source code release , available as versions tagged "R1_0" in the project's
DLTK Core Frameworks:
- DLTK Core (runtime and SDK) (downloadable).
- Ruby IDE (runtime and SDK) (downloadable).
- TCL IDE (runtime and SDK) (downloadable).
- Incr TCL (runtime and SDK) (downloadable).
- XOTcl (runtime and SDK) (downloadable).
- DLTK Remote Projects via DSDP TM (runtime and SDK) (downloadable).
- DLTK Mylyn Integration (runtime and SDK) (downloadable).
- Python IDE (runtime and SDK) (downloadable).
Release milestones will be occurring at roughly 6 week intervals, and will be aligned with the Galileo Simultaneous Release train. Milestone names start with M2 in order to clarify this relationship.
1.0M7 (API/Feature Freeze)
The target date for availability of Dynamic Languages Toolkit 1.0 is:
- Wednesday June 26, 2009 - DLTK 1.0 Release date (with Galileo)
In order to remain current, each Eclipse release is designed to run on reasonably current versions of the underlying operating environments.
The DLTK 1.0 depends upon on the Eclipse Platform 3.4. Various sub components also depend on other Eclipse Projects, namely the the Eclipse Modeling Framework (EMF) 2.3 or later and DSDP TM. For this release, the core sources will be written and compiled against version 5.0 of the Java Platform APIs and designed to run on version 5.0 of the Java Runtime Environment, Standard Edition.
Source/binary Compatibility: Due to active refactoring/optimization/improvement of the core DLTK frameworks DLTK 1.0 will not be source/binary compatible with DLTK 0.95.
Workspace Compatibility: We intend to keep DLTK 1.0 upwards workspace-compatible with DLTK 0.95 unless noted. This means that workspaces and projects created with DLTK 0.95 can be successfully opened by DLTK 1.0 and upgraded to a 1.0 workspace. A workspace created (or opened) by a product based on DLTK 1.0 will be unusable with a product based on DLTK 0.95.
API Contract APIs published for the DLTK 1.0 release will be carefully reviewed prior to release, making use of "internal" packages for unsupported and variable implementation classes. Client plug-ins that directly depend on anything other than what is specified in the published API are inherently unsupportable and receive no guarantees about future compatibility.
Project Building and Indexing
- Mixin indexing should be performed independently from the builder
- Move error reporting from the editor to the ProjectBuilder.
- Unsaved changes in the editor should not be reported as markers in the Problems view.
- Project isolation for the the Selection, Completion, Type Inference, etc engines.
- Introduce API to easily implement additional semantic checks
- Indexing and search should be moved from the core to separate plugins.
- Indexing should be configurable for each language separately, and only if required.
- Support of multi-pass indexing and resource dependencies.
- API to implement pluggable indexers
Core Frameworks improvements
- Fix Type Hierarchy bugs
- Review public API Internal packages should be rarely used.
- Switch to EMF
- Improve extensibility
- API simplifications
External application management
Implement EMF based application management:
- External checker tools
- Type inferencing engine improvements
- Remove AST from core and allow each language to use it is own AST classes
- Implement persistent AST caching to speed up all operations
- Support of different kind of expressions
- Support of different kind of breakpoints
- Support of async dbgp.
- Support of consoles over debug protocol.
- Improve DBGP implementation quality and reliability
- Code assistance APIs needs improvements. Context information (AKA argument hinting) calls should be fairly separated from code completion calls. API should allow the addition of language specific features.
- Implement proper Runtime Model based on the current mixin model
- Hyperlink navigation
- Display documentation form multiple sources and ability to switch from one source to another
- Ability to display documentation for multi-word commands (e.g. "package require ...." in TCL)
- User-defined templates for the new script files
Ruby IDE improvements
- Ruby source code formatter
- Testing frameworks support (Test::Unit, Shoulda, RSpec)
- package management (list, install, etc.)
- ability to add installed gems to the project buildpath
- Implement own parser based on XRuby with automatic error recovery, correct positions for all elements, etc. Implement 2 modes of parser operations: FAST for building internal models and error reporting and EXTENDED with detailed information of every source token for use in editor and formatter
- Cache parsed ASTs for all modules to optimize performance of the search/content assist operations
- Syntax highlighting improvements fix some cases with incorrect syntax highlighting. Deep use of semantic highlighting to correctly highlight all the sources.
- Rake runnner
- Checks for the common code errors (need to clarify what could be checked)
- Regular Expression Tester
- Spell Checking Support
- Mark Occurrences
- Refactoring support
- Rubygems suppport
New TCL parser
TCL everything-is-a-string concept is cool but it makes difficult any tooling support (particulary ones dealing with
code analysis). TCL code is also string so to parse TCL source properly any tool must know parameter types at least to
follow execution flow in the source. Consider TCL statement
if a b c
Tool must know that for the case above b and c strings are source code which may be executed and shall be handled
appropriately by the tool. Real life is much complex and written above is true only if c string is not equal to else
value... This rules (proc metadata) can not be derived (inferred) from program source, and the only way is to supply
this rules externally.
Current parser has hard-coded metadata for widely used control-flow TCL procs, such as if,
switch, while, etc. This allow DLTK to
walk through large part of user program, but this is not enough to cover user
- Standard library metadata
- Initial implementation of TCL parser based on provided metadata
- Initial bundle of TCL сode checks (procedure redefinition, unreachable code, wrong arguments, etc)
- Build metadata for user-defined commands
- Infer argument types for metadata of the user-defined commands
- ITCL support by the new parser and metadata
- XOTCL support by the new parser and metadata
- Update model element parser to use new parser
- Update indexing to use new parser
- Update search to use new parser
- Update CompletionEngine to use new parser
- Update SelectionEngine to use new parser
- Update semantic highlighting to use new parser
- Advanced TCL checks (undefined variable, unused command or variable, more detailed reporting of the mismatched command arguments, etc)
TCL ActiveState tools support
- tclchecker: quickfix support, pretty message formatting, incremental project checks, support new options
- debugger: hotswap, watchpoints, configuration function instrumentation, enhance debugging of threads or spawned processes
- Teapot package management support
- Better license management to avoid potential licensing issues with ActiveState
Powerful Script Console
As a Java oriented IDE (initially) Eclipse lack of powerful Console support. But developers using interpreted languages like TCL expect good interactive (console, shell) support from tooling. Current Eclipse Console is a simple stream-based output to the the window, with some coloring and pattern matching features, which is not enough for good interactive console.
- Syntax highlighting
- Code assist
- API Documentation
- Show variable values on hover
- Proper OS streams handling
- Available for local and remote processes
TCL IDE improvements
- TCL source code indenter (formatter)
Man-pages and documentation should be tied to the code
- At the moment tcl documentation is configured globally instead the user should be able to specify different documentation for each interpreter/library