Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Google Summer of Code 2009 Ideas/SchemeIDE

This details my (Richard Gould) proposal for improvements to the SchemeLite IDE in the ide4edu project.

Features

Debugger

One of the main goals for this project is to provide support for debugging a scheme application. The interface will be modelled as closely as makes sense to the JDT debugger, with other possible influences coming from the DrScheme IDE, if they can be integrated in a user-friendly manner.

I can see this task being broken up as follows:

- learn about Eclipse debugging - in particular, the format of the input it accepts (two weeks)
- intercept interpreter state - may involve modifications to the interpreter interfaces (two weeks)

This task is hard for me to estimate, as I'm not that familiar with what is involved to implement debugging support. I'm making fairly conservative estimations here, but barring any strange complications, this should be plenty of time. User interface tweaks to the debugger may have to be allocated elsewhere.

Code Completion

The current SchemeLite editor provides no support for code completion. At a minimum level, support could be added for built-in scheme definitions and for other (define) forms that exist in the user's code.

Contour Model View

The contour models can be used to show a visualised representation of the inner state of the Scheme interpreter at a given breakpoint. An implementation could possibly be done using GEF. I would budget two weeks for to implement this.

One potential problem area I could imagine would be to make the view scalable to large environments. If the environment has a large or complex visual representation, it may be hard to show it cleanly.

User Interface Improvements

- Appropriate perspectives. Some UI design is needed here, but I could potentially create a different perspective for editing scheme and another for debugging.

- Currently the Editor and the Evaluator are crammed into two tabs into the editor pane. It might make sense to break them out so that they can be viewed simultaneously. Perhaps the Evaluator can be a view. The "Input and Eval" area in particular is a good candidate to be broken out into its own view.

- The current workflow could possibly be improved. Presently one enters definitions in the editor, loads these into the evaluator, and then provides code to be evaluated.

For all of these UI tasks, some design work to flesh out the details is required.

Schedule and Milestones

Milestone 1

- Debugger - four weeks

Milestone 2

- Code Completion - one week - Contour Model - two to three weeks

Milestone 3

- UI improvements - bug fixing

Back to the top