IDE Specs

This page lists the specifications for the IDE Project.

IDE Description

This project defines an integrated development environment (IDE) for introductory students studying computing. It contains two main components: the editor and the console. The editor should be simple, elegant, and intuitive interface for new students to edit programs, but allow experienced users to customize it for more sophisticated uses. The console is an interactive terminal (sometimes called a shell) for entering and executing commands.

The IDE will be for use with the new implementations of Python and Ruby from Microsoft, called IronPython and IronRuby. There are many examples of this kind of interface, including IDLE (which comes with Python), JES (Java for Students), DrScheme, and DrPython (see more details below). This IDE is targeting a new framework called the Dynamic Language Runtime (DLR). The DLR allows for languages written for .NET/Mono to share variables and data structures.

The IDE should be written in C# which is very similar to Java in a number of ways. First, the syntax is very similar to Java, but it also compiles to a virtual machine. More importantly, the IDE should run the same on Linux, Mac OS X, and Windows. This can be accomplished by using Mono version 1.9.1 or above. This cross-platform requirement restrict the project to using Windows Forms as there is no WPF on Mono. Also, GTK should not be used. The project build and run on any of the platforms, with Visual Studio or with makefiles on Linux and Mac.

Open Source

As this project is to be done in an open source manner, it should be designed in a collection of components. Each component should be as modular as possible. One possibility is to make the components (and perhaps the entire IDE) run in on-line and off-line modes. In on-line mode, a server application would be responsible for getting and saving files. A browser running Silverlight/Moonlight could interact with this server application. In off-line mode, the files would be handled by the native filesystem, and an application front-end would embed the components. At the least, it should be fully functional without needing access to the internet.

We want to make it available to everyone without any barriers. Each component could have its own license. This may be required if we build on existing projects that already have a license. As long as these components can be combined, the license of any particular component can be independent. To facilitate this, components should exist in their own subdirectory, and be loaded at runtime or linked-in at compile time.

For new code, suitable licenses would include: Microsoft Public-License, BSD New License or the MIT License.

Debugging

There should be support for debugging, including breakpoints, single stepping, and variable inspection. Debugging will be especially important for beginning students. Ideally, it would be as easy to use as playing a movie... with Pause, Step, and Play buttons. A nice feature to have would be the ability to introspect the values of variables in each stack frame - possibly modifying them as well. (Interactive console that allows you to execute code in the current stack frame like the Python pdb debugger.)

Screen Layout and Tabs

Each file should be edited in a tab. Not all languages may be text files, so there should be an Interface for interacting with each type of file editing. This user interface should open up in a new tab. Some languages may have a graphical editor. Python and Ruby will be text files, and should open up with text editing capabilities. See DrScheme for additional ideas on displaying syntax and variable relationships graphically.

CodeDOM

By walking a CodeDOM tree, the system could automatically go from one language to another. This could be handy if we had a language and interface like Alice and we want to automatically move up to Python.

Syntax-color highlighting and Command-completion

Syntax color highlighting is a must these days in order to give students some feedback about their program's structure. Command completion should be an option: is really useful when you have some experience, but can be a point of confusion for beginners.

Elegant interface to exploit the DLR languages

Should have a unified console and editor views so that languages can be explored dynamically and interactively. Create an object in Python but use it in Scheme or Ruby.

The IDE should be usable with non-DLR languages as well. For example, you should be able to edit and compile a C# program, or use the editor to edit other kinds of files, such as HTML or XML. Additionally, there may be some .NET languages that are not integrated with the DLR yet. They would have their own engine and console.

Project Management

Project management (start simple - see what IronEditor has done in this regard).

Project management is almost a requirement for an IDE to be used with languages that need to be compiled, and would be useful for editing sets of dynamic programs. A standard "project file format" might be nice to have work across different editors/environments. Initially a project could just be a directory. We could save a custom 'project settings file' in the top-level of the directory when we actually need it.

• Software developed will be released under an OSI-approved open source license.

Mono and IronPython

Mono is an open source implementation of the .NET standards and can be found at http://www.mono-project.com/.

IronPython is being written by Microsoft for .NET. It is not designed to run in Mono; however, the Mono group has used IronPython extensively to test (and fix) the Mono implementation of .NET and now fully supports and runs IronPython. You can use the Mono binaries found here.

Inspiration from other IDEs

The two-pane approach to a simplified, classroom-oriented IDE goes back many years and through many projects. Examples of this design include: DrScheme (see wikipedia), and DrJava (see main page).

DrPython

DrPython (screenshot) may in fact be closest to our layout goals for this IDE. However, it can still be too complex by offering too many options for beginning students. One the other hand, DrPython is very simplistic and has no real connection between the editor and evaluator. IDLE's simplicity and integration is a better target for functional requirements.

Wing

The editor Wing IDE (see screenshots) may also provide ideas, however, it is written in GTK rather than WinForms. See also http://www.wingware.com/doc/legal/other-licenses for details of other projects used by the Wing IDE.

IDLE

Error creating thumbnail: /bin/bash: /usr/bin/convert: No such file or directory

Error code: 127

IDLE Screens

IDLE is an editor/evaluator written in Python using the Tk graphics library. It is split into two processes: the editor and the evaluator. This was largely necessary because many users would like to edit and run Tk+Python code. Because the editor uses a Tk graphics loop, this was necessary to keep the user's Tk graphics loop separate.

For details on IDLE functionality, see http://hkn.eecs.berkeley.edu/~dyoo/python/idle_intro/.

JES

Error creating thumbnail: /bin/bash: /usr/bin/convert: No such file or directory

Error code: 127

JES Screen

JES continues a tradition of interfaces designed for the classroom by implementing a two-pane editor/evaluator screen.

More information on JES can be found in this presentation.

Accessibility should be considered. Internationalization could be provided by gettext. See http://www.mono-project.com/I18N_with_Mono.Unix

DLR Hosting

The console should provide IronPython and IronRuby via hosting. A recent example of hosting IronPython version 2 can be found in the IronPython cookbook entry Hosting IronPython 2. See also examples on the IronPython page here.

Pedagogical Connections

The IDE should provide educators with support for doing a variety of tasks, including assessment and evaluation of teaching methods.

• classroom support
  • allow student/teacher interaction in the classroom (perhaps ideas similar to those in Richard Anderson's Classroom Presenter)
  • be able to use IDE for demos in class
    • large font size
    • important text (code, or shell) in top or middle of screen
    • (projectors make it hard to see at the bottom)
    • suggests tabbed pages, or top/bottom switch

Assessment

Consider instrumentation in other teaching platforms such as the results published in ICER.

• post-classroom analysis
• time on task support
  • login and store on server?
  • save and upload at end of semester?
• providing student help
• code templates/skeleton?
• handin and grading support?
• feedback support: highlight and comment student's papers (similar to Word's Trackchanges and Comments)
• links to demographic data
• installation time

We should make any data submission be optional, friendly, and easy. This could form the basis for more scalable assessment.

Links and Resources

These links are provided for references to IDE-related topics.

Editors

1. http://codeplex.com/DlrPad - console, rendered canvas, and xaml editor. selection box for language
2. http://softwareindustrialization.com/WebbasedIDEsAndDynamicLanguagesOnNET.aspx - overview of IDEs for the DLR
3. http://www.codeplex.com/sdlsdk/Release/ProjectReleases.aspx?ReleaseId=14254 - Jim Hugunin's DLR Console
4. http://ligaz.blogspot.com/2007/11/dlr-pad-interactive-programming-with.html - on DlrPad
5. IronEdit
   1. http://www.codeplex.com/IronEditor - IronEditor sources
   2. http://blog.benhall.me.uk/2008/07/announcing-ironeditor-editor-for.html - Ben Hall's blog (IronEditor)

Command-completion

1. http://code.google.com/p/silvershell/ - Daniel's Silvershell

Silverlight

1. http://blogs.msdn.com/shawnfa/archive/2007/05/09/the-silverlight-security-model.aspx - The Silverlight Security Model
2. http://silverlight.net/forums/t/20788.aspx - Silverlight security and the filesystem
3. http://www.silverlight.net/QuickStarts/IsoStore/StoreData.aspx - Silverlight limited to writing to the cache

Misc

1. http://devhawk.net/2008/07/17/IronPython+Post+20+Roadmap.aspx - on IronPython's roadmap
2. http://compilerlab.members.winisp.net/ - Compiler DevLab 2007. Meeting of Microsoft's CompilerDev team on the DLR.
3. http://www.voidspace.org.uk/ironpython/winforms/index.shtml - Tutorials on Winforms under Mono
4. http://www.go-mono.com/mono-downloads/download.html - Mono version 1.9 (Linux user's might want "other unixes" binary)
5. http://sourceforge.net/projects/xacc/ - possible starting place
6. http://msdn.microsoft.com/robotics/ - Microsoft Robotics Studio
7. http://www.roboteducation.org/ - IPRE main page
8. http://www.parallax.com/ - Parallax, makers of the Scribbler and the BOE-Bot
9. http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython IronPython
10. http://PyroRobotics.org/ - Pyro, Python Robotics
11. http://fepy.sourceforge.net/ - FePy and the IronPython Community Edition (IPCE)
12. http://forums.microsoft.com/MSDN/default.aspx?ForumGroupID=383&SiteID=1 MS Forums for MSRS
13. http://hkn.eecs.berkeley.edu/~dyoo/python/idle_intro/ - One Day of IDLE Toying, tutorial on IDLE
14. http://www.bluej.org/about/papers.html - Papers on BlueJ, environment for Java
15. http://www.cs.kent.ac.uk/events/conf/2006/icer/ - ICER publications on instrumentation in teaching platforms
16. http://www.mono-project.com/I18N_with_Mono.Unix - internationalization of text
17. http://tirania.org/blog//texts/cli-plugins.html - Tutorial on .NET plugin (dynamically loadable code)
18. http://www.mono-project.com/Mono:Windows - Mono on Windows
19. http://www.go-mono.com/docs/index.aspx?link=N%3AMono.Unix - Mono's documentation on classes
20. http://www.ironpython.info/index.php/Hosting_IronPython_2 - Hosting IronPython in C#
21. http://compilerlab.members.winisp.net/hosting-tour.doc - Discussion of Nessie, Hosting (old), Colorizing, etc.
22. http://code.google.com/p/monopad/source/diff?r=2&format=side&path=/trunk/Source/MonoPad.GladeGUI.cs - Similar codebase
23. http://msdn.microsoft.com/en-us/library/bb896703.aspx - Talking to MSRS without dsshost.exe
24. http://code.google.com/p/alsing/wiki/SyntaxBox - WPF color syntax highlighting
25. DrJava: A lightweight pedagogic environment for Java, by Eric Allen, Robert Cartwright, and Brian Stoler. Rice University, September 7, 2001.