13 October 2009

Google Wave invitation!

I had lost hope that I would make it among the Wave beta testers, but it looks that it just took that long for them to get to the bottom of the list! :-) So now I have an account, I can give it a spin and I'll have to come up with some cool ideas for applications.

26 August 2009

Towards erlIDE 2.0: it's not only about code

I've been sketching some ideas for erlIDE 2.0 before, but that was only about the tools needed to handle the source code. Writing code is of course an important part of the development process. In other languages, it is one of the two pillars, the other one being debugging the code. Erlang, however, is different: an Erlang system is alive, and thus it's just as important to be able to architect and monitor it.

Of course these activities could be placed under the two other categories, but I dare to claim that they are sufficiently different from "normal" coding and "normal" debugging that they can stand on their own.

"What's the fuss about? We have that already!" I hear someone mutter there in the back. Um, yes, sort of. There are tools to visualize the process structure, but IMHO they are far from what they can be. There are no tools to help with the architecture of the system and there are almost none to watch it running. Here are some examples:
  • visualize and edit the supervisor structure as well as the links and monitors between processes. With a graphical tool, I mean something like right click and add a child, drag and drop from it to create a link to another process, mark the process as trapping exits, and so on. This would of course get saved into the appropriate code modules.
  • freeze execution of all application processes and inspect them without fearing that timeouts will kill them
  • "sandboxes" for processes, allowing all to be killed and the application restarted without affecting unrelated processes
  • trace messages live, at full or reduced speed or step-by-step. This could also be done offline, from the logs, but then the processes' data can't be accessed.
Some of these features require extensive support from the VM, so it becomes a matter of how useful these tools will prove themselves at paying customer's site. Which is difficult to find out before having a tool to test, but I am hopeful that there will be a way out of the deadlock (maybe we can build a good enough tool without VM support to use as demo).

I will explore this path further, I think we can get more developer productivity gains from this kind of tooling than from the usual coding and debugging support.

11 June 2009

erlIDE 0.6.3 supports R13B01

We discovered that R13B01 created some incompatibilities and this release fixes them. There is also an assortment of small bug fixes (but not many, this time).

Get it from http://erlide.org/update!

18 May 2009

erlIDE 0.6.1

A maintenance release.

Fixed issues:
322 Debugger - Keep debug context even if the process is killed (works in OTP debugger)
150 Show multiple nodes in debug tree when debugging is distributed
343 debugger - breakpoints - group on type gives Others (type unspecified)
360 runtimes - add default runtime after installation of erlide
361 crash when indenting region with c-i when text contains tab
363 macro completion not working
365 hover over non-folded comment shows popup
367 completion - better layout of documentation
369 command to reset scanner and parser caches
344 navigation - F3 goes wrong if call contains fun -> a/1.
plus some other minor bugs.

29 April 2009

erlIDE 0.6.0 released

We are glad to announce version 0.6.0 of erlIDE, featuring a lot of fixed bugs and also
  • Eclipse 3.4 only
  • Support for Erlang R13
  • Greatly improved debugger
  • Refactoring with Wrangler

The full changelog can be found in the CHANGES document.

If you encounter problems, please follow these steps:
  • Go to Window->Preferences->Erlang->Report problems
  • Fill in a summary and a description of what you did when the problem occurred
  • Press "Send" and a file will be created in your home directory, attach it to a bug report at the tracker or to a mail to erlide-bugs@lists.sourceforge.net.

06 April 2009

Towards erlide 2.0: a service-oriented approach

"What, you're not even have a 1.0 out and are already talking about 2.0?", you ask. Well, yes! It's much more fun to think about the future!

One of my goals has always been to have as much as possible of the functionality on the Erlang side. This is simply because I prefer to code Erlang than Java. The reality of having to learn coding for Eclipse has made it difficult to pursue, one of the main reasons being that a lot of the boilerplate code is loaned from the Java Development Tools plug-in.

We have been slowly refactoring functionality to Erlang, but for 2.0 I see a different approach: implement a code handling engine in Erlang that really could use anything as a GUI. The API will probably be heavily influenced by the Eclipse way, but I can live with that.

So, what I have in mind is something like this:
  • the GUI sends notifications when there some editing event
  • the engine keeps a representation of the document in memory
  • the document is linked to a lexical scanner and a parser, for each change these will update their model of the source file
  • a higher-level model willl keep track of dependencies between files and their changes
Now, for the real work we will have extensible services, for example:
  • lexical info: tokens at a given position/range, ...
  • syntactic info: matching braces, ...
  • semantic info: language constructs at a given position (AST), ...
  • search: find definitions and uses of variables/functions/macros/records, ...
  • indentation
  • formatting
  • completion
  • annotations: warnings/errors from different tools (compiler, dialyzer,...)
  • refactoring
  • ...
The GUI will use these services and render them in an appropriate way, and of course will convert user input into the respective queries to these services.

Some of this functionality is already in place, but there's a lot of duplication and uncoordinated work. It's this that needs to get cleaned up.

26 March 2009

Book: The Ascent of Humanity (Charles Einsenstein)

I just found this book, which I find very interesting. It can be read online at http://www.ascentofhumanity.com/, but is available as a real book too.

I won't spoil the read, but will only say it really got me thinking and I'm not yet even half way through it. The facts are not new, but are put together perfectly to illuminate the point, which is... Well, you read about it! :-)

12 March 2009

erlIDE internals: What is a backend?

The term "backend" is used often in erlIDE, but it might be unclear what it really means.

What we call a backend is an Erlang runtime that we're connected to via an internal Java node. This connection requires some erlIDE code to be installed and running on the Erlang side.

There are two kinds of backends: managed and standalone. Managed ones have their lifecycle controlled by erlIDE. Standalone ones use already started runtimes.

Inside erlIDE, backends are used for several purposes:
  • for the IDE internals: scanning, parsing, etc. This is always a managed backend.
  • for compiling code
  • for running and debugging the applications
There are several reasons for having them separated. One is to isolate functionality (especially in early erlIDE varsions, it was easy to have the IDE hang for some crash in the builder, or the other way around). Another is that one might want to run the IDE on the latest and greatest Erlang version, but compile the project for some older version, while still testing it on all newer versions available.

09 March 2009

erlIDE internals: Introduction

I think it would be interesting to describe some of the internal workings of erlIDE. There is no better way to clear up one's thoughts that trying to explain them to someone else. Besides, once there will be readers, I'm sure there will be many good suggestions!

So, let's begin top-down.

erlIDE is comprised of several parts:
  • jinterface: we extended the OTP library with some things we needed, like generating Erlang terms from string descriptions (sprintf-like) and simple pattern matching.
  • the core: contains the management of Erlang runtimes and the model of the Erlang code. It includes services for scanning, parsing, compiling and evaluating Erlang code.
  • the UI: handles the editors, views, preferences and other Eclipse UI stuff.
We don't really want to write Java code, but since it's Eclipse we're talking about, there is little choice about that. But we can minimize the amount of Java by using Erlang as backend for our operations. So the main architectural vision is to let the Java part be only an adapter layer and implement in Erlang the core functionality. This will work well for the core functionality, but will be much more difficult for the UI parts.

Okay, this is a beginning. More to come later, stay tuned!

Erlide 0.5.1 (unstable)

This is the first release targeting Eclipse 3.4.

The big news is that we are now including experimental Wrangler refactoring support! György Orosz has put together the required Eclipse scaffolding and we will appreciate all the feedback we can get.

Otherwise, there are some bugs that have been fixed, see the ChangeLog for details.

/Vlad, Jakob and György

Erlide 0.5.0 (stable) released!

We have been working hard to fix bugs and add new functionality and today we are proud to be able to release version 0.5.0! Now you can do your Erlang development with less hassle, and the fun part is that there's a lot more to come in the pipeline.

The Eclipse update site is at http://erlide.org/update or http://erlide.sourceforge.net/update

For those that have been using out unstable releases, there are only few new things. For the others, a list of some of the new things can be found in the ChangeLog.

IMPORTANT: Please note that this is the last release that targets Eclipse 3.3. The answers (or more exactly, lack of) to our previous questions about which versions we should target tell us that everybody is running 3.4 or newer. If you're still stuck with 3.3 and will need continued support, please contact us.


/Vlad and Jakob