Project Plan For Dynamic Languages Toolkit, version 1.0


Some xhtml content here. Make sure to use the prefix before the elements

Release Deliverables

  • DLTK source code release , available as versions tagged "R1_0" in the project's
  • DLTK Core Frameworks:
    • DLTK Core (runtime and SDK) (downloadable).
  • Stand-alone components:
    • Ruby IDE (runtime and SDK) (downloadable).
    • TCL IDE (runtime and SDK) (downloadable).
  • DLTK extensions:
    • Incr TCL (runtime and SDK) (downloadable).
    • XOTcl (runtime and SDK) (downloadable).
  • Integration Components:
    • DLTK Remote Projects via DSDP TM (runtime and SDK) (downloadable).
    • DLTK Mylyn Integration (runtime and SDK) (downloadable).
  • Incubating components:
    • Python IDE (runtime and SDK) (downloadable).
    • Javascript IDE (runtime and SDK) (downloadable).

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
M3 12-Nov-2008
M4 29-Dec-2008
M5 06-Feb-2009
M6 18-Mar-2009
M7 06-May-2009
1.0M7 (API/Feature Freeze)
RC1 19-May-2009
RC2 26-May-2009
RC3 02-Jun-2009
RC4 09-Jun-2009
RC5 16-Jun-2009

The target date for availability of Dynamic Languages Toolkit 1.0 is:

  • Wednesday June 26, 2009 - DLTK 1.0 Release date (with Galileo)

Table of Contents

Target Environments

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.

Table of Contents

Compatibility with Previous Releases

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.

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

view raw xml of project plan
from project meta-data key "projectplanurl"