Project Plan For technology.dltk, version 1.0

Introduction

Release Deliverables

Table of Contents

Release Milestones

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.

M2	01-Oct-2008	1.0M2
M3	12-Nov-2008	1.0M3
M4	29-Dec-2008	1.0M4
M5	06-Feb-2009	1.0M5
M6	18-Mar-2009	1.0M6
M7	06-May-2009	1.0M7 (API/Feature Freeze)
RC1	19-May-2009	1.0RC1
RC2	26-May-2009	1.0RC2
RC3	02-Jun-2009	1.0RC3
RC4	09-Jun-2009	1.0RC4
RC5	16-Jun-2009	1.0RC5

Table of Contents

Target Environments

Table of Contents

Compatibility with Previous Releases

Table of Contents

Themes and Priorities

Project Building and Indexing

• Committed
  • 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

• Proposed
  • 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

• Committed
  • Fix Type Hierarchy bugs

• Proposed
  • Review public API Internal packages should be rarely used.
  • Project/buildpath management
    • Switch to EMF
    • Improve extensibility
    • API simplifications
  • External application management Implement EMF based application management:
    • Interpreters
    • Debuggers
    • 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
  • Debugger improvements
    • 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
  • Documentation view improvements:
    • 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

• Committed
  • Ruby source code formatter
  • Testing frameworks support (Test::Unit, Shoulda, RSpec)

• Proposed
  • Rubygems suppport
    • 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

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 programs well.

• Committed
  • 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)

• Proposed
  • 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

• Proposed
  • 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.

• Proposed
  • Syntax highlighting
  • Code assist
  • API Documentation
  • Show variable values on hover
  • Proper OS streams handling
  • Available for local and remote processes

TCL IDE improvements

• Proposed
  • 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

Table of Contents