Subtle Shift In Emphasis

erlide blog moved to erlide.org

2013-02-21T08:46:00.000+01:00

There's not been a lot of activity on this blog, but for the benefit for all that did read it after all, I moved the erlide-related stuff to the erlide.org site, where it fits better. I copied a couple of old posts that are still somewhat relevant and I will try to keep posting updates.

If anyone has suggestions for topics of interests, please let me know.

Improving erlide project structure

2011-02-08T11:29:00.000+01:00

[cross-posted from the erlide-devel mailing list]

We have discovered that it is more and more difficult for us to introduce new features in erlide without breaking anything and realized that one of the reasons is because assumptions about the project structure are spread throughout the code and some times are even implicit. New features that don't follow these assumptions get weird errors and when the apparent problem is fixed, other problems appear in other parts.

The way to improve the situation is by:

getting a picture of what we'd like things to work like
using unit tests as "live specifications" for the desired functionality. Note that this is slightly different than introducing unit tests for current functionality.
changing the code in small steps until it conforms to the tests/spec

There should be only one source of information in the system - the model of the projects and of the source code. The basic model should be possible to extend by extra tools (for example, a test framework may specify additional source code directories). These tools might also specify their own processing of the sources (for example, a coverage tool might require special arguments for the compiler; or a code-generation tool might require a script to be executed before compilation). The basic model should not have to be changed to accommodate for these extensions.

More about this later.

Mikado method to help refactorings

2010-08-26T22:29:00.000+02:00

I found a very interesting method described at http://mikadomethod.wordpress.com/ about how to decompose a large refactoring into manageable chunks, so that it can be done safely (code is never broken).

Eclipse 3.6 is here

2010-06-23T08:48:00.000+02:00

The Helios release train is here and with it the new Marketplace that allows users to install plug-ins in the comfort of their homes... er, cubicles. Of course, Erlide 0.8.4 is available from there too!

Erlide update site upgraded

2010-06-19T22:23:00.000+02:00

The regular update site at http://erlide.org has been updated to the now not so new p2 update manager format. Only the latest 0.8.3 build is available there.

Older stable releases are to be found at http://erlide.org/update_classic, if you need one of those.

This is so that we can appear on the Eclipse marketplace, which will be integrated in Eclipse in the upcoming 3.6 version.

Retrieving a feature's version number in Eclipse

2010-06-19T00:00:00.003+02:00

I wanted to print in the log my feature's version number, but was stumped because features aren't OSGi bundles and there wasn't an obvious way to find them. After realizing that the About dialog displays the features, I looked at its code and extracted this snippet:

IBundleGroupProvider[] providers = Platform.getBundleGroupProviders();
if (providers != null) {
  for (IBundleGroupProvider provider : providers) {
    IBundleGroup[] bundleGroups = provider.getBundleGroups();
      for (IBundleGroup group : bundleGroups) {
        if (group.getIdentifier().equals(featureId)) {
          version = group.getVersion();
        }
      }
    }
  }
}

History of programming

2010-05-11T21:20:00.001+02:00

A hilarious post about the history of programming languages: http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html.

Google Wave invitation!

2009-10-13T13:51:00.003+02:00

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.

Towards erlIDE 2.0: it's not only about code

2009-08-26T09:34:00.009+02:00

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.

erlIDE 0.6.3 supports R13B01

2009-06-11T09:38:00.001+02:00

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!

erlIDE 0.6.1

2009-05-18T11:28:00.001+02:00

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.

erlIDE 0.6.0 released

2009-04-29T09:06:00.004+02:00

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.

Towards erlide 2.0: a service-oriented approach

2009-04-06T12:52:00.007+02:00

"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.

Book: The Ascent of Humanity (Charles Einsenstein)

2009-03-26T15:16:00.002+01:00

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! :-)

erlIDE internals: What is a backend?

2009-03-12T10:16:00.004+01:00

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.

erlIDE internals: Introduction

2009-03-09T14:08:00.010+01:00

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)

2009-03-09T12:47:00.004+01:00

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.

Enjoy!
/Vlad, Jakob and György

Erlide 0.5.0 (stable) released!

2009-03-09T12:28:00.006+01:00

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.

Enjoy!

/Vlad and Jakob