The tutorials I attended this year were Xtext and Xtend specific. Having said that, I was jealous of others in Benjamin Cab&eaccute;'s talk which was on Raspberry Pi and Arduino programming; however, whilst that's just a passing interest to me personally the Xtend and Xtext basics were ones that I had been meaning to investigate in more detail for some time but never put the time aside to spend any significant amount of time learning them.
First up was the Xtext tutorial. For those that don't know, Xtext is a parser generator/DSL/editor which can spit out not only a model of the code but also associated text renderers. There's a lot of machinery under the hood to making such things work seamlessly, and many more API hooks for performing things like validation and generation than I would have thought possible.
I also now understand some of the syntactic elements in the Xtext grammars,
which aren't immediately obvious, such as foo+=bar* means that 'foo' will
be a list of zero or more 'bar' elements, and option?=something? means
a boolean value 'option' which is true iff 'something' is present. I've
never seen those explained before, and having it come to light suddenly
makes sense of a lot of things in the past.
What I didnt also appreciate was Xtext's ability to generate content based on both a validator and a generator step. The default project has placeholders for both of these, though they default to no-ops.
There was also a lot of detail in how Xtext raises its suggestions and valid entries for scopes; unfortunately, the exercises took the group slightly longer than planned and so there was a cursory glance over these implementation details. There's some documentation at the xtext site which makes about as much sense as before the talk ...
Still, at least I got to talk to a few of the Xtext guys, and managed to put my view across that whilst whitespace-sensitive grammars are technically possible (and needed for languages such as Python, Makefiles and YAML) there are no open-source examples of using such a whitepsace-senstiive grammar. There's a difference between 'technically feasible' and 'practical' which is just a little too big a chasm to cross at this point.
Still: mission accomplished; I know a lot more about Xtext than when I started, even if I now know that there's more that I don't know.
The next tutorial was on Xtend, this time on active cnnotations (a new feature in 2.4) and a functional programming quiz. Xtend is based upon the Xtext parsing suite, and translates into Java and then hands off compilation to the Java compiler -- meaning none of the headaches usually seen with Scala and none of the blisteringly fast Perl-like performance of Groovy. It also helps that the language is statically typed, yet uses inference (like Scala) so that you don't have to write repeated boilerplate code.
Active annotations are really very cool indeed; they provide a way of
annotating a class with an interface (like existing Java annotations) but
allows you to hook in a translation rule to say how the generated Java class
should be amended. In this way, it's possible to define a @Serializable
annotation that will automatically generate a serialVersionUID field, or
a @ToString generator based on the field contexts.
The exercises then jumped a few levels and dived right into a functional programming exercise. Xtend, it seems, depends on Guava (version 10, if anyone is interested) which I wonder what would happen if a program used a more recent version of Guava as well as Xtend functionality.
The probelm with the gear shift is that many features of Xtend becamse assumed,
such as the integration of the guilement quotes and template FOR statements.
There were also some aspects left unexplained, like extension methods and
how functions like 10.minutes were actually evolved (there's a minutes()
method elsewhere in the example which takes an int, so 10.minutes is an
implicit extension method on int values).
One thing I did learn was that functions which take a lambda as their last
argument don't have to specify it in the argument list, but can simply place
the lambda after the expression in question. So a call to foo(1,[3]) can
also be written as foo(1) [3], on the basis that lambdas often span multiple
lines and thus you don't have to worry about bracket nesting. It looks tempting
to think of it as a partial function, but Xtend doens't have those; it's
just syntactic sugar to make it prettier.
I'm still pretty excited with Xtend in general; it's no Scala killer yet (though Scala is doing a good enough job of killing itself) -- but I think the killer feature of Xtend is going to get IntelliJ support. JetBrains have no interest in doing this, so I wonder if a port of Xtend to IntelliJ will have to happen, and essentially port the Eclipse editor into a runtime instance of IntelliJ. Without it, I think Xtend will remain a power tool for Eclipse users and Eclipse plug-in developers, but probably not in the wider JVM replacement language category just yet.
One of the nice things about Eclipse is that despite being a large community, events like these really bring everyone together. In this case, the awards ceremony awarded several projects and committers for their work, including a lifetime achievement award for Chris Aniszczyk, who has worked tirelessly promoting Eclipse and projects for all of the time that I've been involved with the Eclipse community. I think it's an achievement well deserved.
There was also a 'family fortunes' (aka 'family feud' in American) in which I took part, and which our team lost. Oh well, it's the taking part that counts ...
Another great part of EclipseCon is the after-hours events. In this case, the Birds of a Feather sessions get like-minded people in a room to talk about or investigate a particular piece of software/technology. In my case, I went to the Raspberry Pi hackathon, in which I got my hands on an Arduino and a Raspberry Pi and actually did some programming/wiring between the two. Unfortunately I got a duff Pi, which meant that it took ages to do anything, but the Arduino was especially easy to program and hook up with a few hardware buttons and LEDs with a mini breadboard.
I also think I finally understand why a combination of Raspberry Pi and
Arduino makes sense, as opposed to an either-or. The Raspberry Pi is a
standalone computer, and can drive an HDMI screen, make network connections
and do general purpose programming, as well as a few pins for digital I/O.
However, the I/O pins on the Pi are directly connected to the CPU, so if you
do something wrong and fry the Pi then you're out of luck. On the other hand,
an Arduino is quite hardy, and is able to deal with more rough treatment.
The program is less flexible, in that it needs to be connected to an EEROM
type programmer in order to be programmed. The Arduino makes this trivial,
as you can connect it to a USB port and then flash it with a new program
(they're called 'sketches' for some bizzare reason) but on the plus side
the event loop is capable of polling for changes to any of the pins and
read them in as values, from which you can do simple processing and
manipulation. To do anything serious, you can punt the resulting values by
either serial port (cleverly, you can plug the Arduino Uno into the Pi's
USB port and both power it and have a /dev/tty for bidirectional communication
between the two). The Pi can then read these from the standard terminal,
and do more extensive programming and/or network transmission of the data
to a central location.
It's also possible to hook up a Pi and an Arduino using more low-level technical methods, such as an I2C bus. I didn't explore these but if a Pi needs to drive several Arduino boards then the I2C bus offers that possibility.
The Arduino kits also come packaged with several 'shields', which are really just daughter boards that can plug into the expansion slot. The shields are stackable, so it's possible to plug one into the top of another, and then another on top. Each one has its own personality; some are used for controlling electronic motors, others can provide networking capabilities, and others still have just pins to which specially crafted backpacks or tinkerset items can be used to provide real plug-and-play electronics.
So, when I get back to the UK it's time to get ordering some new miniature hardware.
]]>The other piece of good news -- and the reason why my blogging has dropped off a cliff over the last year or so -- is that I have finally finished writing a book on Eclipse plug-in development. This covers the basics (creating views and so forth) as well as up-to-date content like the differences introduced in E4 as well as how to build and deploy update sites with Tycho and run tests with SWTBot. It doesn't aim to be all things to all people -- in fact, I'd imagine that many reading this post will already know all there is to know about the content of the book -- but it's aimed at those who are starting out their plug-in journey and want to be able to build Eclipse based plug-ins for now and future use. It's written in a step-oriented tutorial style (somewhat different to my usual colloquial posts) so I'm curious to see if this helps or hinders adoption.
The book should be out by the end of next month, and I'd like to thank those who have contributed reviews so far (and those who have said they will) -- I'll make sure that the Acknowledgements chapter is up-to-date with any feedback received.
Anyway, having finished the bulk of the book and going into a proof-reading and typo-spotting phase, I hope to have enough time to be able to get back to blogging in a more meaningful way than conference write-ups. And speaking of conference write-ups, expect to see my thoughts not only here but also on InfoQ -- and hopefully a few video-recorded interviews with some of the fellow EclipseCon attendees.
In any case, if you spot me at EclipseCon and want to say hi, please do so. My Twitter (or App.Net) avatar looks much like I do, except he's got less grey hair and no body.
]]>The arguments of 'Maybe this would cause problems' don't really seem to be borne out by the Maven repository, which has over 400G of versioned artefacts that have gone through the -SNAPSHOT process during development and rarely, if ever, has any problems in versioned code. (That's not to say mistake can never happen; but it's easy enough to publish a new asset with a new patch version if required, as has been done occasionally before such as the javax.jms releases.)
The problem with the existence of the OSGi build qualifier is that it means Eclipse developers don't actually take care to version code properly. Instead, the build process just spits out recompiled bundles, often without a corresponding bump in version number where required or needed.
]]>The issue is whether or not SNAPSHOTs shold be built in a 'lower' numerical
namespace using 1.2.3-456 which sorts less than 1.2.3. By encouraging
a difference between 'unreleased' and 'released' versions, it becomes clear
whether there are changes which are important, and allows developers to report
bugs against a specific version (instead of just 'the latest version').
According to both the Semantic Versioning and the Eclipse Version Numbering rules, the patch number (third segment) should be changed whenever there is a difference between build artefacts. As I've listed on the InfoQ article, that plainly doesn't happen in some cases:
The point of showing the cross-section of the above is not to highlight
specific projects, but to show this is a widespread problem that goes
across all projects. The problem is, there is no 'penalty' for leaving a
1.2.3.qualifier as the Manifest entry and just spinning out builds with
new build qualifiers in place.
The key advantage of having a different version numbering format between release versions and pre-release versions is to ensure that at release, the version number is updated appropriately. This means that the development process generally follows:
The decision as to what to call the next number can either be tracked by updates to the -SNAPSHOT itself (e.g. moving to 1.1.0-SNAPSHOT) or can be deferred to later in the process. There's even tooling to help you do that (the mvn release plugin) -- though this just removes the -SNAPSHOTS for you rather than doing any semantic analysis.
This pattern is so common that it's even codified as a bullet point in the Semantic Versioning specification:
A pre-release version MAY be denoted by appending a dash and a series of dot separated identifiers immediately following the patch version. Identifiers MUST be comprised of only ASCII alphanumerics and dash [0-9A-Za-z-]. Pre-release versions satisfy but have a lower precedence than the associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
The 'pre-release versions satisfy but have a lower precedence than' sums
up the rule in a nutshell: in other words, anywhere a 1.2.3 is valid then
all 1.2.3- are valid as well; anywhere a 1.2.3 is not valid then
all 1.2.3- are not valid. So, in a range like [1.2.3,4.5.6) then any
pre-release state of 1.2.3- is included, but any pre-release state of
4.5.6- is not included.
This was even implemented successfully in Equinox, with an implementation in 3.8M6.
Unfortunately, the concerns listed by the CPEG were out of touch with how developers work outside of the OSGi space, and instead of reaching out with a mechanism which would have been compatible for released artifacts (whilst providing a SNAPSHOT style build system that would not be loadable on older OSGi runtimes) it has been removed from the specification. Given that OSGi R5 is a major release of the runtime, this would have been the ideal time for introducing a new version syntax, and one that would have been quickly adopted elsewhere.
So instead of having 'memorable' artifact names like org.eclipse.ui_3.7.0.jar
we'll be stuck with unmemorable names like
org.eclipse.ui_3.7.0.v20110928-1505.jar for the forseeable future in
the OSGi world. This causes more cognitive work for humans (trying to
remember the name) whilst introducing more opportunity for mistakes (by
releasing the same major/minor/patch with different builds).
This is what I refer to as humans solving the tooling problem, rather than the other way around.
]]>Today's keynote is on the Future of ALM, a look at how the recent advances in application lifecycle management tools have enabled much tighter integration between developers and the IDEs themselves. Should be an interesting view as to where these tools are going over the next few years.
Today's OSGi experience kicks off with a
modular and extensible OSGi shell,
which is a look at the new
Gogo shell
from Apache Felix. This shell will become the default one for Eclipse Juno,
and is already available in the existing milestone builds. Gogo is a powerful
shell and can do a much wider range of things than the old Equinox one, but
takes a bit of retraining the muscle memories when it comes to controlling it
(for example, lb instead of ss to list bundles instead of show status).
There's also a couple of presentations on
Virgo Experience and
a Path to Modularity with Eclipse Virgo,
both of which provide a managed OSGi runtime environment (with web admin tools)
and can be used as a replacement for existing Apache Tomcat engines thanks
to the integration with the Tomcat web bundle.
Another must-see presentation is the one on Eclipse Xtend. This is a language, built upon the runtime tools of Xtext, which 'compiles' down to Java source code, and thus fits in with existing Java build tools. Although it's possible to commit in the Java code (and just use a headless Java compiler) it is also possible to commit the Xtend source files and use the Maven plugin to compile the code as part of the build. The upcoming 2.3 release provides a way of debugging from source (rather than the generated Java code) as well as some refactoring support. Unlike other languages, since Xtend doesn't have its own compiler it has less bugs and faster build times than more complex languages. And, it's backwardly compatible across JVMs and releases, something which can't be said for some popular JVM based languages. There's a follow up on Xtext best practices later in the day as well.
There's a talk on News from Git in Java Land which is by a couple of the core EGit/JGit developers, whose only problem is that it overlaps with the talk above. Still, if you're into Git then this will be a good state of the union; there's also a talk on automatic remote project synchronisation using Git later as well.
My final pick for the day is on the time travelling debugger, which won the best tool at this year's award winners. If you've never seen this in action before, then this talk is going to open your eyes as to how much data it's possible to derive from a runtime system.
As this year's EclipseCon comes to a close later on today, I'd like to once again echo my thanks for the community award. Hopefully I'll be able to be back one day for EclipseCon!
]]>