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.
21 February 2013
08 February 2011
Improving erlide project structure
[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:
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.
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.
Labels:
erlide,
erlide internals
26 August 2010
Mikado method to help refactorings
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).
Labels:
general
23 June 2010
Eclipse 3.6 is here
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!
Labels:
erlide
19 June 2010
Erlide update site upgraded
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.
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.
Labels:
erlide
Retrieving a feature's version number in Eclipse
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(); } } } } }
Labels:
eclipse
11 May 2010
History of programming
A hilarious post about the history of programming languages: http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html.
Subscribe to:
Posts (Atom)