Some xhtml content here. Make sure to use the prefix
before the elements
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).
Table of Contents
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)
Table of Contents
In order to remain current, each Eclipse release is designed to run on
reasonably current versions of the underlying
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
Due to active refactoring/optimization/improvement of the core DLTK frameworks
DLTK 1.0 will not be source/binary
compatible with DLTK 0.95.
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.
created (or opened) by a product based on DLTK 1.0 will be unusable
with a product based on DLTK 0.95.
APIs published for the DLTK 1.0 release will be carefully
reviewed prior to release, making use of "internal" packages
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
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
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
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
Syntax highlighting improvements
fix some cases with incorrect syntax highlighting. Deep use of semantic highlighting to correctly highlight all the
- 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
- 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
- debugger: hotswap, watchpoints, configuration function instrumentation, enhance debugging of threads or
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
like TCL expect good interactive (console, shell) support from tooling. Current Eclipse Console is a simple
output to the the window, with some coloring and pattern matching features, which is not enough for good
- 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
Table of Contents