Hypervisors drive Heterogeneity

I have put together a pretty neat little lab here under my desk. As I always say, you have to use the tools to understand the needs of the users. You have to get into their shoes and see what you like and don't like. Then you have a good chance of building tools they'll actually use and like.

My lab includes two "embedded" systems on the right. The top is a board that has a Freescale PowerPC P4080 8-core chip in it. I have attached my Wind River ICE JTAG unit to it to test some really heavy duty multi-core scenarios. On the bottom right, I have what looks like a basic PC, and it is, but it runs Wind River's hypervisor hosting three operating systems: Wind River Linux, vxWorks, and of all things Windows. I don't have the P4080 system booted up yet, but my intention is to run the Hypervisor there too with random combinations of wrLinux and vxWorks.

As I put this together, it really drove home the need for an IDE platform that is heterogeneous. That's a hard word to pronounce, but what I really mean is an IDE that can target any operating system that can run in a hypervisor configuration, which is pretty much all of them. And that means an IDE that has plug and play support that lets you create the source for applications that can run on them all, build that source for any and all of the target platforms, and debug the application as it runs on one ore more of them.

And, you guessed it, the Eclipse CDT C/C++ IDE is a great platform to do that with. We have build and debug support for the GNU toolchain for Linux and from Wind River we have commercial support for vxWorks and Wind River Linux, and upcoming in the next release of CDT, we'll have support for Microsoft's Windows SDK which includes Visual C++.

As well, I'm about to embark on a very interesting journey with the Target Communication Framework as we advance it's debug capabilities to cover all of these platforms as well. With a common framework for agents that run in all these environments, we'll have the ability to plug 'n play capabilities into these agents and come up with tooling we haven't even dared to consider before. Am I pumped about it? You betcha. We've long had the advantage of plug-in architectures with our Eclipse-based tooling, and now we'll get that advantage all the way down to the target as well.

And it's really these hypervisor scenarios that have brought me here. It's finally a concrete example where you really need the heterogeneous capabilities that have driven my work on the CDT. And, it's something to sell our employers with too :).

Fitting Eclipse into my world

As I blogged a few days ago, I've started working on a game engine using open source bits. Part of it is just to satisfy my hunger to learn more about game development, but the more practical benefit of this effort is to better understand the plight of the C/C++ developer using the CDT on a real and fairly sizable project.

And I have my first lesson. It came about thanks to git. I have the source checked into a git repository out on github. Now, since the root of the game engine is open source libraries, I was working in the command line to extract them into the git repository. As a result I got used to using git from the command line, including adding a .gitignore so that git wouldn't check in my Eclipse .metadata directory and any directories containing build output.

I then started setting up the projects as CDT projects and started working in Eclipse. And I gave the Helios egit plug-ins a try. Unfortunately, they currently don't support .gitignore and as a result I got weird results that caused me to lose trust in egit, like ?'s on the folders I have listed in my .gitignore. Or did I forget to add them there? Not sure. I have to go back to the command line to look. At any rate, I ended up staying there and now I just use git from the command line. At least until egit 0.9 comes out with .gitignore support and I'll try again.

But this article isn't about egit. It's about Eclipse and how developers who do C/C++, especially experienced ones, work. The command line and command line tools are still a very important part of the development cycle and Eclipse and the CDT need to deal with that.

I see a lot of functionality in Eclipse assuming that projects are the root of your life. Well, it's not in my case. I have a git repo which contains directories that contain projects and there are some that do not. There's even a README file at the root and some files to help me build for Android using CMake.

I think there's a concept missing in Eclipse. We can equate the root of my git repo as a workspace. But then there are things in that workspace, files and folders, that aren't projects. I would like to be able to browse them, and maybe even edit the files, without having to go to the file explorer. Essentially I need a file navigator rooted at the workspace. I'm not sure whether we need a separate view for that, or to just allow Workspace roots to have IFiles and IFolders and make them navigable in the project navigator.

I'd like to hear other people's experiences, especially those who try to mix Eclipse with command line development. Is this something that would be useful? Are there other things?

Happy 100K CDT!

I originally sent this in an e-mail to cdt-dev. But it's info others might find interesting.

Hey gang,

Just to let you know we passed 100,000 downloads of CDT today and to pass along congrats!

And, looking at the stats, there's some interesting information there.

First, where do people get the CDT?
- 74,300 from the Eclipse C/C++ IDE package
- 6,400 from the Eclipse Linux C/C++ IDE package which includes the Linux Tools stuff as well
- 13,700 from the Helios train repository
- 2,200 from the CDT repository
- 2,700 from the CDT master zip
- 1,000 from Wascana (w00t!)

So that's about 80% from the Eclipse packages. There are a couple of things I get from that.
- People want a quick and easy way to get the CDT and the Eclipse web site funnels them there.
- People who use CDT with Eclipse are CDT users first. Much fewer start with a different Eclipse package and add CDT to it.

And for the platform breakdown.
- 59% Windows
- 34% Linux
- 7% Mac

Again, the Linux number continues to be much higher than we've had in the past, which could be attributed to more developers moving to Linux, or people are moving back to Visual Studio on Windows. I'm pretty happy with the 1K so far for Wascana. And I'm hopeful at getting a Windows debug solution with Visual C++ support for Indigo (thanks to work Eugene from Wind River has done in TCF) which may change things.

Also the Mac number is only slightly higher than in the past. Other than fixing a few bugs this release, I think we're still missing the big carrot, Objective-C. Unfortunately, there isn't enough investment in this area for that to change any time soon, so it is what it is.

All-in-all, pretty good numbers for the summer. We usually get an explosion in the fall when the kids head back to school which validates my grassroots strategy. We're getting a hold of the kids early and making them Eclipse savvy so that when they enter the workplace, they'll carry forward the word there and give our employers money :).

Next report at 200K. We'll see if things change as we go.

R-Evolve or Die

"Evolve or die!". I've heard that sentiment a few times lately related to existing technologies that are coming under fire for being too old and ugly in the face of "up and comers" with fancy interfaces and social connectivity. But the more I think of it, is "Evolve" the right answer?

I don't think so. The pace of evolution tends to be slow. At the start, you look more "different" than "evolutionary" and no one cares about that. No, I think you need to be "revolutionary" if you want to make a difference. And that's hard for veteran organizations that fear risk to pull off.

A great mentor of mine once told me: "Don't be tied to the technology". The example he came up with was Smalltalk. We had a whole product written in Smalltalk and it was awesome. And it would still be awesome today except for one thing. The UI didn't fit in with any other applications you may have been using. That and the companies that supported Smalltalk eventually died off. So what did we do? Well, we rewrote the whole thing with the help of standard desktop tools and languages and a huge code base we inherited in a takeover. Unfortunately the result was a big Windows app, but it got the job done and saved the product.

So what am I getting at? Well, I've got a renewed interest in the "IDE in the Cloud", somewhat sparked by Google's new experimental App Inventor for Android. I'm not a fan of the puzzle metaphor they picked, but it just got me thinking again of the power of the new browsers and web technologies and how we can apply them to the tools space. It does make the behemoth desktop IDE we have in Eclipse look old fashioned. But instead of thinking evolutionary, what would a revolutionary IDE look like in this new world?

Exploring Game Development with CDT

Well, it's holiday time. I'm off this week and next and it's filled up with a family union my wife and I are hosting, but I am stealing away some time now and then and my hobby time going forward with one of my dreams, building a game engine.

Of course, it's impossible to build a game engine yourself. So instead I am putting together a number of open source pieces and integrating them. The amount of code I need to write should be pretty small but should be significant enough to help me get some real world experience using CDT. The best way to get into the mind of some one who uses your tools and understand their needs is to actually be one for a while.

The key part of the CDT angle is multi-target development. The plug-in nature of Eclipse and CDT's support for tool chains allows it to be used to write applications for multiple platforms. In this case I'm going to do a mix of desktop and mobile featuring Windows and Linux on the desktop side and Android and eventually MeeGo on the mobile side. Android and MeeGo are particularly interesting in that I firmly believe these platforms could eventually find their way onto desktops one day. So writing a game that targets them and Windows and regular Linux desktop isn't really that much of a stretch. (BTW, yes, I'm purposely leaving out Apple for fear of getting trapped in the "walled garden").

For the engine components, I'm using the OGRE 3D rendering engine that is currently being ported to Android already (very cool to see). It uses freetype for fonts for displaying text and freeimage for loading images. I'll use bullet physics for the physics engine. There doesn't seem to be a common audio package so this may be custom per target with my own API over top. The same may be true for input, although the OGRE samples use OIS but that would need to be ported to Android.

The final piece of the puzzle will be the blender 3d editor which is going through a re-architecture right now and is extensible using python. Create your content using blender, export it with the help of python scripts and load it up into the game engine on all four platforms. Sounds like a dream that only the pros can pull off.

We'll see how far I get. But I benefit from it in two ways - living that dream, and getting some real life experience using Eclipse for serious application development that should lead to some ideas on making it better and maybe I'll come up with ideas for new tools. Sounds like a win-win.

I'm not anti-e4, I'm just busy with other things

As we start the discussion about CDT and e4 on the cdt-dev list, I just want to make sure people are clear when I make statements that appear anti-e4 that I'm not anti-e4. If you like e4 and you want to use it in your project, go for it. There's some really cool things there and the guys are doing a great job of pulling it together.

But I have other important problems to solve higher up the stack than I see e4 trying to solve. In CDT-land, our biggest issue is getting people to even use Eclipse who are using emacs or vi and gdb just fine and who struggle adapting to the world of IDEs. We need to focus on enhancing the value of Eclipse and simplifying adoption to make it more appealing for these people to buy into our wares.

At the top of our list are some workflow issues and the flexible resources work that started in e4 but moved in to 3.x is a start on that. I think we still need some work on build to support multiple build configurations per project, and for build to work just as it does from the command-line. And the launch UI is over complicated for what our users need. But those things are all the platform stuff we really need. And we do have people trying to make contributions in those areas.

And, we have some things to work out in our own kitchen. We need to fix up the CDT build system so that vendors aren't so frustrated by it that they end up writing their own. Then there's the world of debug and systems analysis where I think we really need some innovative UI approaches. As starters, I don't think you can visualize a massive multi-core system using a 2 dimensional UI that assumes a single context. I'd love to see something like Clutter in SWT.

So while the world is rushing towards HTML5 and the cloud, that's great and everything, but we still have a lot of work to do to make Eclipse a great IDE on the engineer's desktop.

My own little PluginFest

This is a bit of a follow up to a blog entry done by my product manager partner in crime here at Wind River, Emeka. I spent a couple of weeks recently (in the middle of the Helios rush too) to put together a demo he is giving today at IBM's Innovate Conference. It was great because it reminded us of what we're really trying to do here creating IDEs using Eclipse, *Integrating* tools.

The the code in the demo is quite small but that's a good thing thanks to good APIs. It's a menu item associated with the editor for Wind River Workbench's Memory Analysis database. The item takes that database and zips it up and attaches it to a newly created Work Item from IBM's Rational Team Concert, i.e. Jazz, product. The story goes that you see a problem in the memory analysis and you want to record it for someone to look at later. And that person takes the attached zip and opens it up in the editor to start his investigation, using the other information recorded in the work item and documenting his findings there as well.

The value of the integration becomes greater than the combined value of tools that Wind River and IBM have built on their own. And that's the promise of Eclipse and it was great to see that promise in action. But it also brought home that we don't see that happening enough. As we solidify the platform and the first layer of tooling, we need to keep driving the solutions and build up a bigger and better stack and sell our collective customers on the value of Eclipse and the solutions we're building for them.

A few years ago we held a PluginFest where we brought together a number of embedded tooling vendors and tried to plug and play their products. In the end, it was more to test that they co-existed with each other than anything. A few had real integrations to show. But I think we fell short of the goal and dropped the ball on the potential. Maybe it's time to bring us back together, not to test interoperability, but to explore opportunities to build real value add integrations that we can work on together. Emeka and I and the IBM RTC gang have started down that path. Hopefully it can be used as an example of the real value of Eclipse as an IDE and rejuvenate the ecosystem a bit.

Writing Games for Android ... and other app stores.

Tools is my passion, especially tools for native programming. Being a game developer wannabe, I'm especially excited when I see game developers using the tools I help build. And that's one reason why I'm closely following and helping out with tooling for the Android Native Development Kit. There's a great community there that could really benefit from a good CDT integration, and maybe who will come help make that integration great.

At any rate, I watched Chris Pruett's session on Android game development from Google I/O and found it very educational. The first half was about technical details and tips behind Android game development, but the second half was just about good game development for mobile platforms. It's a great view and I've embedded it at the end of this post.

The real game changer (sorry to use the pun :) in my mind is the growth of app stores or markets. Pretty much every mobile platform vendor is creating some sort of one stop shopping experience for their devices and it's a great vehicle for app developers to quickly get their wares into the hands of paying customers. And with systems like Valve's Steam, you also get this great experience on your desktops and laptops.

The biggest advantage of markets, as Chris illustrated, is that it's also a great way to keep in touch with your customers. Customers tend to be brutally honest about what you've provided them, and it's good to get first hand looks at that feedback. And also, thanks to the markets, it's also easy to get updates and fixes into their hands. It's a win/win.

Anyway, it's a great view. Take a look.

Update: The embed didn't work very well. Just click this link instead.

My take on Android Keynote at Google I/O

No, I'm not at Google I/O, despite my twitter traffic during today's keynote. Mind you that was probably a give away that I wasn't there as even the Googlers struggled with wifi connectivity during their demos. At any rate, I was glued to see where Google was taking Android. And, to be honest, they didn't really surprise me much as pretty much everything they announced had a rumor associated with it. It's hard to keep secrets in this industry.

Despite the lack of surprises, there were a few interesting points that were made, and a couple that were not which gave me pause.

First, was Google TV. Yes it too was rumored and came out pretty much as was rumored. There were two things I found interesting about it. And no, a set top box based on Android isn't one of them as we pretty much expected that eventually. No, first was confirmation that the initial Google TV boxes will be based on Intel Atom chips. What that means is the real first confirmation of an x86 port of Android from Google officials. The new Android Native Development kit r4 that also came out today also confirms it with an x86 port of the native libraries. It's not quite cooked yet as there's no toolchain to build with and no image to run on, but they're there and a sign of things to come.

I guess the other thing that struck me about Google TV that I think was even more interesting was that they were running Google Chrome on top of Android on top of x86. I've heard rumbling about the lack of information about Chrome OS at the conference. Now, if they have Chrome running on Android for Google TV, why not run it on netbooks too? And then why have Chrome OS at all. That's where I'm guessing there won't be one or if it does appear, we'll all be wondering why when you can get all that plus Android apps to boot just like on Google TV. Or, maybe, that is what Chrome OS is. We'll see (or maybe not)...

So there were a few new things in the Android NDK for me to chew on. One that will make the CDT build integration I've been working on easier to do is the ability to build outside of the NDK directory tree (weird, yeah, but they previously reused the build system from the platform that is done that way). So look for that sometime in the near future. There's also gdb support for native applications. I'll need to see what's needed to hook that up to CDT's debug interfaces. In the end it'll be a great public example of how to use the CDT in a cross compile and remote debug scenario. Not to mention it'll be fun to use :).

CDT, Towards World Domination

Big smiley planted in the title of this one BTW.

I've been working on the CDT for coming up on 8 years now. It's been quite a long journey, and what keeps me motivated is that I don't see the end in sight yet. For CDT to be successful, the companies and individuals using CDT need to be successful. And until I see everyone happy with it, our job isn't done.

Now there are a lot of successes already today. CDT is still a key part of the IDE strategy for a huge handful of platform vendors, especially in the embedded and mobile space. And we have nearly 600,000 downloads of CDT, so I assume the downloaders are being successful (or they're having disk problems and need to download it all the time, maybe). But if things were so rosy, I wouldn't be hearing all the complaints about CDT and Eclipse in general that I do.

The biggest complaint I get from the user community is how hard it is to set up CDT for their platform, especially developers using Windows. That's where Wascana comes in. There's also a variety of environments that don't come with out of the box support, like Qt and Mac Cocoa.

Commercially, a lot of what I hear is about customers who would still rather use command line tools than our commercial IDEs. That tells me two things. One, that these people just don't like change or learning new things. But more importantly, it tells me we don't provide sufficient cost/benefit for them to make the jump. And really, the benefit has to be much greater than the cost and that means not simply doing the same things you can with the command line, but taking it to a next level that an Integrated Development Environment gives you. I joke with the product managers here at Wind that we need to put the capital back in the 'I' in integrated. I'm not joking...

So to help bring the nay-sayers on board, my strategy with the CDT is to make it ubiquitous. I'd like to see as many developers as possible in the world able to used it, and like to use it. That way, when we come to them with a commercial offering, CDT in the product becomes a value point.

Ensuring the CDT works out of the box is a big part of that strategy, especially for platforms that don't have commercial support. Linux is covered very well by the Linux Tools project at Eclipse, Wascana for Windows, and I am trying to find time to get it working well for Mac (Objective-C support included). Qt is a natural for cross platform development, so is CMake and Autotools build environments. And I'm helping with CDT support for Android native development. These are things CDT should support out of the box to enable my plan for world domination :). And that's what motivates me to keep plugging away.

Wascana Lives! on Eclipse Labs

When I first heard of Eclipse Labs, I was thrilled about the idea. Having a central hosting site where we can gather all the open source projects that skirt the official Eclipse site is a great way to build visibility for these projects and a great way to promote the creation of new ones.

Well, today, Eclipse Labs is a reality. And, as I was one of the beta testers for it, I'm pleased to announce that I have moved the Wascana Eclipse C/C++ IDE for Windows Developers over to it. I really struggled with Wascana over at SourceForge where there's a low signal to noise ratio, but thanks to Eclipse Labs, it should help people find it and realize it's place in the Eclipse community.

Right now, I'd consider Wascana still beta quality, mind you all of the packages are released open source projects so I know they work. But the key behind Wascana is a p2 repository and the org.eclipse.cdt.p2 plug-in that knows how to unpack tar.bz2 files. This plug-in is part of the Helios Eclipse C/C++ IDE package so all you need to do is get that and put the URL to the repo into p2 and install away. Feel free to hop on over and take a look at the Wascana site at Eclipse Labs.

In the future, I hope to figure out an even easier way to install, possibly similar to how Subversive gets it's SVN connectors. At the very least, I'll be posting an NSIS installer containing everything you need up to the Wascana site. This should all be in place for the Wascana 1.0 release around Helios release time.

Update: As I was writing this blog, an issue I was having with the downloads have been fixed. Wascana 1.0 Beta1 is now available on the site.

Thanks to Ian Skerrett and Google for getting Eclipse Labs together. As I mentioned in the blog post I posted when I first heard of it, this is going to be a game changer. I can't wait to see what projects pop up there.

Don't guilt contributions, enable them

This is a bit of a response to Dave Carver's post versus Alex Blewitt's and a bit of a topic I've dealt with mentoring projects, and how I operate on the CDT project.

Over my years in open source, I've seen time and time again where people on projects try to find ways of getting others to come help. A common one is to beg or guilt people into contributing. "You don't like how that works, then come fix it." That's easy to say. But I've seen that piss people off way more often than it works, and it only works in rare occasions. I think you need to be sensitive to the skill set and the ability for people to come fix it. Not everyone who uses Eclipse knows how to build plug-ins for it, or has the time to do it. Do you expect them to give up their family hours to come help you out? I sure hope not.

No, my preferred approach is to create an environment where contributions are naturally welcomed. Where those who do have the skills and the time can easily and quickly fix the things that are bugging your community. Creating such an environment isn't easy and it comes down to a number of factors. Probably the biggest one is to make everyone feel a part of the team. Everyone's opinion matters. And every contribution is treated like gold, whether accepted or not.

And Alex's story is very disturbing to me. I'd rather he write about how well he and the rest of the Eclipse team have gotten Eclipse to work on the Mac.

We need a JNI helper plugin

Now that I'm back being an engineer/architect, I'm again thinking of too many projects that I want to do with the time I have. I'm getting involved in the Target Communication Framework (TCF) which has an exciting opportunity to standardize target (in this case mainly embedded targets) communication and services for the purposes of debug and data collection amongst other things.

I am also trying to make it easier to use CDT for specific platforms. Windows and Android and soon Qt are the main ones there. But I've run into problems with the complexity of CDT's build system that I need work with the community to clean up.

And there is another shiny object has caught my attention and I'd love to get time on that too. Our long term holy grail on the CDT has been to support developing native libraries for Java. The debug scenarios are scary, but I've been thinking of another area that should be a lot more attainable.

That's automating the creation of the code that JNI development requires. There's two paths. One is generating skeletal C code for Java native methods. And the other is generating wrapper Java classes for C++ classes. There used to be commercial products that did that, but I'm not sure if they're still around. And given the power of the Java and C++ parsers we have in Eclipse, and the code generation frameworks available, it shouldn't be that hard, you would think.

I think this would be a huge benefit to JNI developers, or at least me :). The interesting thing to note is that Android had the foresight to use JNI for their native interface so there's a new community who could use it. If anyone is interested in doing something like this, give me or the cdt-dev list a ping.

Mac gets no love

I should blog more. But twitter is so much faster. At any rate...

@timbray tweeted yesterday "Eclipse SPOD DIAF." After getting out my magic decoder ring, I soon learned that he was complaining about the performance of Eclipse on Macs. Apparently there were memory issues in Eclipse 3.5 Cocoa that causes a lot of garbage collection (assuming I'm interpreting that correctly). That causes the pause icon to pop up while Eclipse is locked down. The so called Spinning Pizza of Death, which is being asked to Die In A Fire, or at least so my magic decoder ring told me. Kids and their fancy lingo...

I hear that's fixed in Eclipse 3.6 and I haven't seen it in the few times I've run Eclipse Helios on Mac. But it's another episode in a long story of Mac not getting any love from the Eclipse community, or at least the contributors. The good news is that as more and more contributors are using Macs, these issues are getting addressed. But the perception has already been set free that Eclipse sucks on Macs and hopefully the Mac users are passionate about Eclipse to give it another try.

I ran into another case that confused the hell out of me last night. I was testing the new Android CDT integration I'm contributing to the Sequoyah project and had an NPE show up. So, as I do on Windows and Linux, I quickly tried to fire up my CDT workspace to take a look at the line of code the log was complaining about. You know, if you have an Eclipse running and you try to launch a second instance, it just pops up the one you have running.

From what I've been told, Mac applications are always singletons. You run one instance of the application and it's able to handle multiple documents. But that doesn't work in Eclipse because Eclipse can't handle multiple workspaces. I remember that coming up at the e4 summit as someone wanting to do that, but at the time I didn't get it. Now I do.

I imagine things like this will get solved over time (although the multi-workspace thing, I'm not sure). But it is a great example of how open source projects work. The only way features get done is if someone has a vested interest in getting it done. To date, there have been few Eclipse contributors with such an interest in Eclipse on Mac. Yes, that's changing, but pretty slowly.

Now, here comes the controversial part. What you don't see in open source much except for the few cases where projects are bankrolled by forward seeking companies with lots of money (i.e. Google) is projects investing before the need. We've known for a long time Mac was going to be important, the trends were pretty obvious. But open source doesn't work that way. The funding for development isn't strong enough to support risk like that.

Or so I think. I am curious if you agree and if you have a theory of why that is. I'm not sure how it can be changed, or if vendors who fund open source want it to change. I know of companies that don't want it to. But the companies that do easily trump that if they can figure out how.

No, I don't want to read e-mail on my dash

Ottawa has a small hi-tech community, at least relative to Silicon Valley South and all. So, of course, the talk still hasn't died from RIM's acquisition of QNX from Harman. For us ex-QNXers and lovers of the mobile space, it is good folly to try and figure out what it all means.

What it doesn't mean is that you'll see RIM bringing your e-mail into your car. Yes, QNX has a big chunk of the automotive operating system space, but I can't see how RIM fits into that, despite what most of the industry pundits have to say when they first heard the news. And frankly, I worry about how advanced applications running in your dashboard is going to impact safety. I'm not going to be catching up on my e-mail while driving, that's for sure.

No, the more interesting angle is how QNX's Neutrino operating system will look in RIM's smartphones. I don't know what's in one of those today, but my guess is that their incumbent OS is really holding them back. They have the branding to take on Apple, but I have to think there's some technical reason whey their application development stack is relatively weak.

And I think that's where Neutrino will help them. I'm not going to get into why I left QNX, but it certainly wasn't faith in their technology. The microkernel architecture definitely has advantages, and I think it's a no-brainer that they'll be able to run RIM's existing stack on it. And I have to assume that RIM is working on additional stacks to support things like native game development, much as Android has.

So I think this is an interesting twist in mobile and consumer electronics and could give RIM a boost. And for QNX, they achieve one of their long time dreams of running in handsets. And I'm glad for them. But I still think Linux and open systems is the better choice ;).

CDT on e4

I just got word of the available e4 Eclipse SDK test builds and thought I'd try out the CDT on it. The great news is that I had no build errors for the CDT base functionality (haven't tried our advanced debug views yet). And I was able to create a C++ project and build it. I had issues going into debug, but I am pretty happy on how far it has come.

There's still a lot missing, though, so there is much work ahead. And as I've feared the UI performance is quite bad, but there's a long way to go to clean these things up. I'll be keeping regular tabs on their progress and test as many of the CDT workflows as I can as the platform stabilizes.

Here's a teaser screenshot.

From Rocks Stars to Reality

"at #eclipsecon we were rock stars, now back to reality."

I was sitting waiting for my flight leaving SFO when this great tweet came across my Twitter feed. It came from Kim Moir, and hit on a very important issue that many of us committers face when working on Eclipse.

Many of us work for companies where open source is a means to an end. We continuously fight to explain the value of what we do to business managers driven by revenue and profit, where they measure the price they charge for product based on the value it brings to customers. And frankly, old school businesses struggle to understand that providing free open source does actually bring value to customers. So we are often under the microscope and under pressure to fight for something we dearly believe in.

But at EclipseCon, the world is upside down. People we meet there are very grateful for what we do. We are the experts they want to talk to to get the information they need. They are the people looking to join us on our mission working to each other's benefit creating great software. Yes, there we are rock stars, or at least the community makes us feel that way. And we dearly appreciate and are humbled by it.

It's an incredible high and one of the reasons EclipseCon is always one of the best times of my year. And, yeah, it is a bit of a depressing feeling as you start on your way home. The show has ended again for another year and it's time to go back to our quiet offices, fighting for what we believe in.

We all dream of a world where our work is appreciated there as much as it is in the community. But it is the reality we deal with year after year. And maybe why EclipseCon is such a great time as it brings us together to celebrate the fact we've survived another year. Here's to surviving again and seeing you there at EclipseCon 2011.

Next step in the Android Revolution

As everyone knows, Google has been working hard on amassing all human knowledge through their search engine, ad sense, their new DNS server, google books and many projects that haven't been made public. I was wondering what they were going to do with all that. It could be a pretty powerful tool.

Well, we finally learned today. Google has announced the next step in the Android revolution, Google Robot. They've been working on a robotics project and have Android running on a Beagleboard that animates the Android at the Googleplex. They've also been able to reduce all human knowledge onto a single SD card that is plugged into the board and the Android has come to life.

As it turns out, it's a pretty smart and powerful robot and has set it's sights on taking over all governments in the world. It's hard to argue with the strategy. At least they aren't using that knowledge for evil.

I love Android on my Nexus One. I love Android running in Google Robot. I for one welcome our new robot overlord. All hail our new benevolent leader!

Another EclipseCon in the Books

Wow, what a week. I don't even know where to start. There were a lot of old familiar faces here, there were a lot of new people who introduced themselves to me. The CDT community is thriving and I am more excited about CDT's future now than I ever have been.

The main reason for that I think is that we're starting to go beyond our basic set of features into some things you won't see in most IDEs. The big one for me that only made a little splash is CDT's new Codan static analysis framework and it's current small set of checkers. Today, CDT will detect syntax errors and highlight them. But with Codan, we can now detect logic errors. Things that have traditionally made C development hard, like finding unbalanced malloc and free's, or new's and delete's, that lead to memory leaks, can now be checked for with the appropriate checker. It's pretty new and will only be available for preview in CDT 7.0, but I can't wait to see where the community takes this.

The other big activity in CDT is our new built-in debugger that gives us the ability to debug without having to rely on an external debugger. It's also in a preview state, but companies with special debug needs that aren't being met by gdb, have an opportunity to use a debugger much more tightly integrated into Eclipse, and fully licensed EPL. And no, we're not planning on a EPL compiler, just dreaming of one :).

I am also seeing things happening on the periphery of CDT that extend Eclipse's C/C++ development beyond our traditional edit/build/debug. Tracing and profiling are maturing. Support for a "best in class" Linux IDE. Debugging for massive multi-core. It's as though we've now solved the basics and are now focusing on the hard problems, and doing it in the open. It'll be very interesting to see where things go and how we manage the community to make sure we're efficient.

Along with parallel tools and Linux communities, I'm getting more involved with the Mobile projects. It's part of my role as an Architecture Council mentor to help them out. But I think there will be some overlap between Mobile and the traditional embedded that the CDT community represents. There was some great discussions this week in that area and I'm happy with the progress they're making.

But it's time to go home and back to the grind. The CDT community and the communities it intersects with are thriving and I can't wait to see where we end up by next year's EclipseCon, same time, same place, in 2011.

Totally Pumped about EclipseCon

Well, it's coming quickly. EclipseCon for me starts with my 6 a.m. flight on Sunday in order to get to the Hyatt in time for Eclipse council meetings. EclipseCon is always a very busy week for me as there are always a few people that I want to run into and chat about CDT things. I made a conscious effort not to submit many talks this year to give me time to breath and to give others in the CDT community their time in the spotlight. It's going to be great.

The talks I am involved in are my own lightening talk on Wascana, my CDT for Windows effort that combines my work on CDT and my work with p2 to give Windows users a quick start using CDT for Windows programming. I'll be helping a few others including Ken Ryall on the CDT what's up standard talk, and Andrew Overholt with the Linux IDE long talk. And I'm involved in a couple of panels. Then we have the various BOFs that take place in the evenings including the CDT and Linux IDE BOFs. My calendar is almost full but there's enough space to meet the community and help prepare for all this.

Aside from the CDT things that I'm of course interested in, I have a couple of other things I'm looking out for. I'm curious to meet other people using p2 for their commercial install technology as we are doing at Wind River. It would be cool if we can standardize on some touchpoint actions and UI and such to share some of the work. I'll also be attending the git tutorial as I'd like to see the CDT being one of the early adoptors of git as our read/write repo, once it's ready, of course.

I'll also be getting more involved in the Target Communication Framework effort that Wind River has started and that is starting to get community interest. We'd love to work with the community to put together a standard communication framework that allows multiple tools to interact with targets of varying sizes and shapes. Martin O from Wind is giving a talk on that and we'll be holding a meeting somewhere along the way to plan out the next steps.

And, of course, there's the bar, the social focal point of every EclipseCon we've had, except maybe the DisneyLand one. We were so new then :). This is where the community cuts down the walls between the projects and we become the one bigger Eclipse community. It's quite a site to see the CDT guy talking to the XML Tools guy wondering what the Xtext guys are up to :). It's a blast. And I hope to see you there. And if you see me first, please stop me and say hi. That's what I'm there for.