Stopping the Project

Due to time constraints I am stopping the my GSoC involvement.

Recently an interesting debugger extension for Adobe’s brackets Editor has been published, called Theseus[1]. Theseus seems to achieve my goals for Chrome and Node.js. If I would reopen the project I would check out the taken approach for Theseus and would probably steel, i mean reuse, the debugger UI.


Posted in Uncategorized

Getting to know Orion (again)

I have started to make myself familiar with Orion. Although I already worked with parts of it, in particular the editor, I basically have to start from scratch. It has been some time, since I was playing around with the Orion installation, it was still version 0.5 when I started to use it.

The first things I did was to get a recent version and make it run. For that it is also necessary to download a complete build. A comprehensive how-to can be found here.

The next thing I tried was to write some plug-ins, see what the extension mechanism of Orion offers me and whether it would be enough to build my idea completely through using the extensions. I started with the simple plug-in example which uses the orion.edit.command extension. Then I moved on to provide some highlighting and content assist for Markdown. This turned out to be more cumbersome then expected. The content assist (orion.edit.contentAssist) worked once I figured out, that I also need to provide the content type Markdown, which specifies the files to be interpreted as Markdown (orion.core.contenttype). I wasn’t able to create a working highlighting extension, although the example to build one seems easy enough. Since I have no further knowledge of how the Orion plug-in mechanism works, which in turn makes it hard for me to debug anything at this point, I decided to move on and get to know Orion better.

My conclusion so far is, that I will have to provide a separate page, which will have to be hosted from the Orion server and will be another client-side Eclipse plug-in for the Orion build.

Posted in Uncategorized

GSoC Proposal: Browser-based Debugger for Eclipse Orion

I want to develop a debugger plug-in for Eclipse Orion and the Google Summer of Code offers the perfect venue for doing that. I already collected some experience while writing my master’s thesis. There I implemented a proof of concept debugger that uses the Orion Editor and supports basic debugging operations to control Chrome’s JavaScript debugger as well as the Rhino Debugger. I am confident, that I can develop an Orion plugin that offers support to control Google Chrome’s JavaScript debugger and is extensible in a way, that other debuggers can be supported simply by writing a connector module.


Debugging of web-applications is typically made using different debugger tools for the client- and server- side. On the client-side advanced AJAX debugger, e.g. chromeDevTools or FireBug are available. On the server-side the debugging-tool depends on the specific language and framework in use. Web developers switch between different debugging tools depending on what side of the web application they are currently working on. This context switch is time-consuming and produces an overhead, because on every switch a developer needs to adjust to the current tool-set. Eclipse and Visual Studio offer great support for server-side technologies. Additionally they support remote debugging of JavaScript running in a browser. This enables a developer to use the same development environment for debugging of client- and server-side code, which again lessens the problem of constantly switching between different tools.

But even the development just for the client-side is cumbersome. A typical approach is to use an editor to edit the client code and then run it in the browser, where the browser debugger is used to inspect the behavior. If a problem is encountered the code has to be adjusted in the editor, refreshed in the browser and can than be debugged again. Although some debugger also provide live-edit, this functionality only provides temporary edit of code that only lives as long as the web page is managed in the browser. Paul Rouget describes this problem in a recent post [5], where he points out possible alternatives to the mentioned development process, which he appropriately names editor-browser-devtools workflow. The Firefox devtools are developing into a direction, where they can be integrated with other development tools, hence providing tool-developers with the possibility to break the cumbersome workflow.

Eclipse Orion advocates the approach “Tools for the web, on the web”. As it is, it already stands out as a great Online-IDE. An important tool which is still missing [1] and not planned for the near future [2] is a runtime debugger. The debugger is extensively used by web developers. An integration into Eclipse Orion would enhance development experience. There would be no more need to

  • switch between different tools for the client and server side development
  • and no need to switch between browser and devtools to debug and edit the client-side code. 

Goal for Google Summer of Code 2013

  • Getting involved with the open source community
  • Understand development process for Eclipse Orion
  • Learn about plug-in mechanism and how to extend Orion
  • Learn about UI design and user experience
  • Implement a browser-based debugger for at least one client- and one server-side technology.


The implemented debugger should have basic debugger functionalities, source editing functionality and support for one client- and one server-side technology.

Basic Functionalities

Following basic functionalities should be implemented

  • step-by-step execution
  • expression evaluation (chrome offers evaluation at runtime and when the debugger is paused).
  • visualization of and navigation through the callstack

This functionalities should be realizable for a client and a server-side connection.

The implementation might be very simplisitic if it turns out, that not enough time is available. For example the expression evaluation might turn out to be nothing more than an input field, as opposed to the widespread behavior that an element is evaluated when the mouse is moved over it.

Source Editing

The next important feature would be source editing, by which I mean, that code execution can be followed and edited persistently in the same editor view. This would break the necessity to switch between editor and browser debugger, when one wants to edit code or debug the code execution.

Supported client- and server-side technology

I plan to support the Google Chrome JavaScript debugger (V8 JS engine) for the client-side and the Rhino-debugger for the server-side. I am not sure about the support for the server-side, it might be more reasonable/useful to support the Rhino-successor Nashorn or Node.js (likewise V8).


While working on the proof-of-concept implementation for my master’s thesis, I made myself familiar with web development in general and the chrome extension mechanism. But I am not yet proficient with those technologies. Before that I have been mostly involved in Java-based projects. The last one being Tigerseye, an Eclipse plugin, which is hosted on Github [4].


April: Getting familiar with Orion, provide some simple bug-fixes or enhancements.

May: I collected enough knowledge about Orion and the debugger I want to support, to be able to write a timeline for my project.

June through September: To be worked out.

The implementation months actually clash with the time I would have to prepare for exams in Germany. But I only have three exams left, worth a third of a semester. So I should be able start working on the project half-time from April through June and full-time during the coding season. Apart from a few days off to get fit for my exams, which shouldn’t be more than two weeks all together.







Tagged with: ,
Posted in Uncategorized
In Archive

Get every new post delivered to your Inbox.