August 29, 2013

Behind the scenes with Theseus, an open source JavaScript debugger for Brackets

Recently, Adobe released Theseus 0.4, a JavaScript debugger extension for Brackets. The above link will lead you to its home in Adobe Research organization on GitHub, which is home to a number of seriously cool projects.  Theseus is released under the MIT license.

a debug trace from Theseus, an open source Brackets extension

I sat down with Adobe intern Tom Lieber, the developer for Theseus. Tom is an MIT grad student and intern working with Adobe Research on problems relating to the development and understanding tools for software engineering, end-user programming and user interface design.

So, what is Theseus?

Theseus is a debugger for JavaScript that tries to make debugging as easily accessible as possible. It’s part of a collaboration between the User Interface Design Group at MIT CSAIL and Adobe Research.  

The goal of Theseus is to let you see what your program is doing by looking at the code, without having to make as many guesses by simulating the code in your head.

How does someone get started with Theseus?

First, grab the latest version of Brackets. Then, in Brackets, click the menu item File, choose Extension Manager. Pick the Available tab, type Theseus in the search box and click the install button in the search results for Theseus. There are also a couple of great videos demonstrating Theseus on the Brackets blog.

And starting with version 0.4, you can use Theseus to debug Brackets itself, as well as any extensions Brackets has loaded, in just two steps:

  1. Open the source code for Brackets or the source code for your extension, in Brackets.
  2. Click the menu item Debug > Debug Brackets with Theseus.

There are additional places to learn more about Theseus:

Theseus v0.4 Announcement

Theseus intro video

Extended Theseus video demo

Brackets Blog introduction

The Theseus README

Theseus paper from CHI’13

How does Adobe use this?

Well, one of the goals of this release was to get the code robust enough for debugging the Brackets editor itself. Since Brackets is written in HTML and in JavaScript, there is a natural synergy in having  Theseus support a significant piece of code. In fact, we’ve already seen bug reports that use the debugger to debug the debugger.

Why did you do this?

Part of it is a personal desire. It’s always fascinated me how we can interact with the application by poking at, trying things out. However the code itself is rather stagnant and somewhat arcane. My goal was to make it as easy as possible to work with the code. In fact, I want people to be able to play with the code as if it was the live application. This is part of my goal to create more usable programming environments.

How would you like others to get involved?

The best way to get involved is to use Theseus on your own projects and give me feedback. I’m looking for when/where it is useful as well as when/where it isn’t useful. The feedback will help me expand my academic research and make Theseus better for everyone.

Contributions to the code are quite welcome. It is a research project and thus, research code, but it’s fairly robust. I’m more than willing to support anyone who’d like to extend the code, or use it for their own purposes.

It would be great to see Theseus expand to project level discovery and project scope exposure. It would be useful to see events, or be able to ask questions like “What modules were involved in initialization?” It would be great to have visualization of data and elements so when things go out of range you understand the cause and impact.

Theseus was created for JavaScript, but the code is written in small modules, and separates the language specific items out so it would be possible to create debuggers for other languages. 

Anything to add?

Well again, this is a research project and I would particularly enjoy hearing back from anyone who’s using it. We need to get a clearer view of how people want to use it and what people are doing with it to make sure Theseus expands and matures to make it an even better tool for asynchronous language debugging. I can be reached at, so feel free to drop me a note to let me know how you are using Theseus. (Tom is also on Twitter and on Github.

Thanks for your time Tom and good luck with your continuing studies at MIT. We are quite taken with the capabilities of Theseus and look forward to seeing how it grows in future releases.

For more information on open source projects at Adobe, please visit our github portal and the Open@Adobe information page with links to even more open source from Adobe.

Please follow OpenAtAdobe on Twitter

6:00 AM Permalink
August 16, 2013

GCview, an open source visualization framework for memory management systems


Recently, Adobe released GCview, a web application that was developed to visualize and monitor memory usage in the V8 JavaScript engine, as an open source technology. The above link will lead you to its home in the Adobe Research organization on Github, which is also home to a number of seriously cool projects. GCview is released under the Apache Software License.

Recently, I sat down with engineering director John Pampuch and engineering manager David Cox. The major developer, Tony Printezis, was unfortunately unavailable.

So, what is GCview?

John: GCview  is a tool for people to look at virtual machines like V8 to analyze internal heap operations.

David:  It’s a framework to monitor and visually percent any memory management technology like garbage collection.

In discussion, it seems that GCview is a generic and easily adaptable visualization and monitoring framework targeted (but not limited) to memory management systems (garbage collectors, malloc/free implementations, hardware caches, etc.).  A  system can be visualized by mapping its operation, data structures, heap layout, and other attributes onto GCView abstractions.

David: Its roots come from a similar tool known as GCspy, of which Tony was the original author. GCview is a  new design and a completely separate code base.

What is GCview  used for?

David: It’s for VM developers to get a deep dive into the activities of garbage collection. It allows knowledgeable developers to also help understand performance aspects of web applications.

John:  It’s important to note that this tool does require some level of expertise to make the best use and looking at memory management systems. It helps identify the underlying causes, but the memory management system itself is responsible for offering the tweakable parameters to improve the identified problems.

In some ways, GCview  seems (to me) similar to the Check Engine light on my car. When it appears, I understand I have a problem but may not know what the problem is. A monitoring tool allows me to see the diagnostic code that caused the problem, but doesn’t necessarily allow me to directly correct it. That may take expertise and tools that I may not have available.  GCView shows me more than just simple diagnostic code, but fixing the problem still requires expertise and tools.

Why did Adobe build GCview?

John:  We believe there is a need for deeper understanding of how memory management systems work in browsers today. We also think that there is room for significant improvement in web VMs.

David:  It’s in everyone’s best interest to see the performance of web applications improve. Building GCview, particularly in tying to open source will allow this to innovate and grow for improvement of the web.

So, what’s inside GCview?

David: The GCview core consists of three parts which can be hosted in the same place and be easily adopted in the required system:

A) Data Stream Spec - A JSON specification that defines the format of a data stream representing the state of the system being monitored over time as mapped onto GCview abstractions. The data stream can either be written to a file for future analysis or transmitted over the network for online monitoring.

B) Visualizer – A visualizer, written in HTML and JavaScript, that interprets and displays the above data stream.

C) Data Tracking Code – C++ code that keeps track of the data needed to monitor a particular system after it has been mapped onto GCview abstractions along with facilities to export this data in the  appropriate format.

How do I get started?

David: Well, the easiest way is to grab the source and point your browser at the index.html file. That will  start GCview where you can load one of the sample traces in the source as well and begin to play and understand what GCview  is showing you.

What’s next for the project?

John:  We hope the open source community will help improve and expand the GCview features and capabilities. Some obvious directions would be inclusion into the Chrome dev tools. Perhaps a great next step would be to see this picked up and baked into Chrome together data on V8. The area covered by GCview today is just the beginning and we can’t wait to see what innovations other developers can bring to it.

Any final comments?

John:  Releasing GCview under open source makes this tool and framework available for all sorts of interesting memory management systems.

David:  We can’t wait to see what this develops into and where the community will take it.

Thanks for your time today guys. We appreciate the effort behind GCview and, honestly, the coolness factor that GCview offers to the web application community.

For more information on open source projects at Adobe, please visit our github portal and the Open@Adobe information page with links to even more open source from Adobe.

11:00 AM Permalink
July 30, 2013

Open Intelligence and Dancing Robots at OSCON 2013

“The future us already here. It’s just unevenly distributed.” –William Gibson

Well, it’s the week after the OSCON 2013 conference held in sunny and warm Portland. And as usual, there was more activity at the show that is possible for one person to encompass.

First, some general observations about the show. This may have been the strongest program across all categories in the last seven OSCON events I have attended. With very few exceptions, the speakers were knowledgeable and informative, able to present meaningful information in a concise, retainable manner.

Naturally, Adobe had sessions on  PhoneGap and on Brackets. The introduction to  PhoneGap by Renaun Erickson, @renaun was surprisingly detailed. I say surprisingly, because PhoneGap is quite complex and yet this 40 minute presentation managed to cover both the highlights as well as dive into specific examples. PhoneGap, is an open source project better known as Cordova, found at the Apache foundation. Renaun’s slides can be found at Intro to PhoneGap.

Adam Lehman, @adrocknaphobia also did an introductory session on Brackets. He managed to cover the highlights and the directions for Brackets, as well as provide insight into future directions. Adams slides can be found online as well.

However, the Wednesday keynote certainly stole the show. With Jeff Hawkins of @Numenta leading off in a discussion around open intelligence, machine intelligence, and neuroscience, the stage was set for an incredible journey into every aspect of open source, be it development or social. And to never forget that OSCON is a social experience. The hallway conference is equally important to the sessions you attend.

The other highlight in the keynotes was stolen by Carin Meier of Neo, who communicated The Joy of Flying Robots with Clojure. Everyone wants a robot friend,  and Carin introduced us to her robot friends. Not only did we see robots dance, fly, flip, we also saw robots working together, all tied together with quick scripting.

OSCON is one of those conferences that you must attend to realize the depth and breadth of the open source industry. Be it in learning to improve team dynamics with improv, diving into the legal side of  Personal Open Source Software and its potential risk, or learning how to automate testing for accessibility OSCON is full of new discoveries, new friends, and new opportunities.


11:05 AM Permalink
July 15, 2013

Just a manic Monday

Next week is OSCON in Portland and I will be there ready to learn the latest and greatest in the world of open source.

It’s, as always, a powerful program with more things I’d like to attend than I can attend. So where is my holographic multi-persona anyway? (and kudos to the folks who managed wade through several hundred abstracts to get to this lineup.)

So here are some of my personal schedule highlights:

Adobe has several talks going on that are worth your attendance.

In any case, I’ll be roaming around OSCON next week, so if you’d like a chance to meet up, shout out .


1:51 PM Permalink
July 12, 2013

Friday Philosophies

Companies these days are increasingly reliant on open source software. Whether it is external open source, or the planned release of internal technology under an open-source license, companies need to understand the rewards and risks involved. However, developers seldom like to follow intricate detailed checklist for quantifying risk within open source usage, or determining the needs for open source release. Therefore, a company needs to establish some basic structures or processes that help guide the decision-making process to a satisfactory conclusion, and as light a weight manner as possible.

Over the past six years, Adobe has developed and refined a process that strives to align within the company’s interest as well as meet the needs of our internal developer communities. Obviously, such a process walks quite a tight rope between the business of generating profits and the benefits of open source involvement. While our activities are both outbound and inbound, the decisions made in order to release technology under an open-source license and to an open source community are far more intriguing.

It is clear that most companies operate under some basic fundamental principles. Most companies are in the business of creating profit. Most companies consider the code developed by their engineers to be owned by the company. As companies grow larger and expand product offerings, multiple groups may be impacted by the release of such proprietary software as open source. And while it often appears that releasing code as open-source software is on a case-to-case basis, such decisions are best reached within the framework of an overall corporate strategy.

So let’s start with some basic rules for considering the release of technology as open source.

  1. Does anyone care that the technology is being released as open source?
  2. Do you have fundamental business and technology reasons for the open source release?
  3. Who owns the project? Does the project remain active within the company?
  4. Who pays for the project? (Open source isn’t free.)
  5. What shape is the code in?
  6. What makes this technology unique? Do competing open-source projects exist?
  7. What about the legal issues?

Most of these items are actually common sense, and not unique to a specific company. However, we often find that these common sense items are not considered or not taken seriously enough. Open source proposals often arise from product strategic needs, such as the ability to expand and create platforms for others to innovate upon. Additionally, the open source community often innovates, improves, and corrects the base release itself. Such activities can provide financial incentives for the release of technology into open source, however it is important to note that building a community and maintaining continuity is an ongoing effort and that integration itself can be costly.

Over the past years Adobe has created and improved its processes for release of technology or working with existing open source projects. While our process may not meet all needs, we believe that the basis of our decision criteria, approval aspects, legal, and community are useful for us in considering the impact of such technology releases as open source.

9:53 AM Permalink