EclipseCon Day 0

Knock on wood, I still don't have horror stories from business travel. Today was another good day. We were delayed in Toronto for a couple hours due to a wind storm, but that just meant I missed the beers Sunday night. No biggy. I'm sure there will be plenty of that starting Monday.

On the flight from Ottawa to Toronto, I sat a couple of rows behind Joe Clark. Joe Who? (Canadians will get that one). He was a popular politician in Canada during the 80's and 90's. He's retired now and was traveling alone. He followed us through US customs so I guess he was traveling to the states to give a talk or something. Oh, by the way, he's a former prime minister of Canada and later the foreign minister. Only in Canada would we figure it isn't a big deal to let a former leader of our country travel around without security.

Then on the flight from Toronto to San Fran, we had an more important person on our flight, Mike Milinkovich himself. (Of course, Mike being Canadian would be the first to say he doesn't deserve such accolades). But he did get the royal treatment, much more than poor Joe Clark did our our little regional jet to Toronto. Mike got through the airport quickly and by the time we got to our car, he was long gone.

Anyway, I'm happy to be here and it's going to be a fun week. I already met some CDT people who were sitting in the bar when we got into the hotel. I hope a lot of the CDT community is here so I can meet them all and find out how they're doing. If you are here, feel free to stop me and say hi!

Oh, yeah, and it's a phone...

As part of my planning for next week, I recorded all the sessions I am thinking of attending in my Outlook calendar. Well, that's fine, but my laptop won't always be available during the week, especially given the rumoured power shortage down there.

Recently I switched mobile phone providers. I did this mainly because in my recent visits to Europe, I really missed having a phone. Luckily one of the major providers here in Canada has switched to GSM, so now I have a phone that should work over there, too.

I picked up one of the latest phones. I won't say brand names, but let's say CDT committer Ken Ryall would be proud ;). I wasn't really looking at features, I just wanted a phone that was really inexpensive, but not cheap, on a three year contract, and this was on the top of the list on my provider's web site.

The more I get into this thing, the less I am thinking of it as a phone. First of all, I learned that I qualified for a free 1 GB MicroSD stick (which unfortunately hasn't arrived yet for my EclipseCon trip). What would I use that for? Well, this thing is also an MP3 player. So that's kind of cool, I've been wanting one recently but didn't want to fork out $100+ for one (yes, call me cheap). And from my last blog entry, you can see it has the now standard camera feature, which I will probably use a lot next week. Playing with it, I see it is also a video camera too (now I see why I need a 1 GB stick). And of course, it does all the latest games, apps, what have you that run on mobile devices these days.

Now back to my original problem of accessing my calendar during EclipseCon, I was playing with the PC software that does various things with the phone over my laptop's Bluetooth connection, and I noticed a Synchronize app. I fired it up, and found out I can synchronize my Outlook calendar to my phone. (It just beeped with a reminder for a meeting I have in 5 minutes, I'd better wrap this up). So this thing is a PIM, too.

I'm not sure if I'll be come a mobile phone power user. I still hate that the screen is so tiny. But I have the chance now to give it a try, I guess...

Way ready for EclipseCon

I'm sitting here planning my schedule for EclipseCon next week and looked up to see a wicked winter storm a-happening. California here I come...

Getting ready for EclipseCon

Well, I just got my "EclipseCon" haircut and I'm starting my final preparations for next week's EclipseCon. If you've never been to one, these things are more than just a conference where people go to hook up with the Eclipse crowd, it's a celebration of everything we work hard for over the year. It's a lot of work to prepare for but it's always a week to remember.

This year, with the help of the growth of the CDT community, we've managed to get a higher profile in the program with a C/C++ Development track. Here's what you can expect to see next week.

Monday
Short Tutorial, Extending CDT To Support Your Compiler (Chris Recoskie, IBM). Learn how to make your own Managed Build integration.

Tuesday
Short Talk, CDT 4.0: easy to use and integrate (Mikhail Voronin, Intel). Get up to date on the new project model changes coming in CDT 4.0.

Demo, What's New in CDT 4.0 (Doug Schaefer, QNX and Markus Schorn, Wind River). Demo of all the cool new features that are coming in CDT 4.0, or at least the ones we have working right now.

Short Talk, Intelligent Command Line Processing for the CDT, (Chris Mead, ARM). Shows an integration with the Apache CLI library for adding cool tool integration features.

Wednesday
Long Talk, Assembling your open C and C++ workbench (Phillipe Ombredanne and Francois Grenade, nexb/EasyEclipse). A great look at how to leverage a number of open source components to create a complete C/C++ IDE.

Long Talk, C/C++ Source Code Introspection using the CDT (Chris Recoskie and Beth Tibbits, IBM). Show how you too can take advantage of the CDT's parser and code models to do some cool analysis of your code.

Short Talk, Multi-platform development with the CDT (Graeme Johnson and Gabriel Castro, IBM). Show how they use the CDT to build IBM's J9 for over 50 different configurations.

BOF, CDT Project Meeting (everyone!). We'll have our regular monthly meeting during BOF time. Everyone is invited to see what's going on in the CDT project and to provide input for any issues we need to discuss.

Thursday
Short Talk, Autotools Demo (Jeff Johnston, Red Hat). Shows the autotools integration with the CDT.

Poster (up all week - Poster Reception Wednesday evening)
Extending CDT Debugger to Support Device Software Development (Mikhail Khodjaiants, ARM). Shows how ARM extends the CDT to support their gnu toolchain, gdb, and JTAG.

Hello C#

Not to get anyone excited, especially a particular executive director of a popular foundation, but I've managed to enter, build, and run my first C# program using the CDT.

I had previously did a language extension for C# that provides syntax coloring for the C# keywords and associated the CEditor with .cs files. In the last hour (while trying to watch a poorly played curling game on TV - yes, they broadcast curling games on the national sports cable channel in Canada), I took everything I learned from my exercise of getting my other build integrations working this week and thought I'd give a build integration for the Microsoft C# compiler a try. After a little tweaking to handle this special case where there is only one tool that takes all .cs files and produces a .exe, I hit the build button and an exe came out.

Luckily for us, Microsoft has reused their PE executable format for .Net apps, so the CDT immediately recognized the end .exe file as an executable file, so I created a launch config for it and hit the run button. "Hello World" it said in the Console view. Tres cool!

Now there's a lot of functionality that's not there. There's no debugger and there's no parser to fill the outline view and index. So there's a long way to go. But it was cool to see.

Wild Week in CDT-land

Wow, it's Friday. I'm glad. This week, once M5 was out the door, Intel committed their long awaited rework of the CDT build model. The idea is to make much of the good things we've done with the Managed Build System build model available to all CDT builders, and also available to the rest of the CDT that could really use this information. The parsers really need to know what compilers and settings are being used to parse properly. I can also see a use by the debug system to default to the best debugger given the currently active build configuration/toolchain.

As well, we get an upgrade to the New Project Wizard. I think the old approach of forcing users to select a language, C or C++, and then a build system, standard versus managed, was pretty intimidating to new users. How are new users supposed to know what a builder is anyway? With the new New Project Wizard, the selection of builder is hidden at least. It's starting to look more like my previous favorite IDE...

What made the week busy was that to do this, a lot of the underlying architecture of both build systems changed. Of course, with any major architectural change, a lot of things broke. Mikhail S from Intel is working hard on all the bugs that are getting raised, and I was able to figure out how to get my MinGW and Windows SDK build integrations working in the new way, so we're getting there. All the other committers are also measuring the impact of the change.

I think the biggest challenge is to get vendors who depend on these systems to take a look at the changes as soon as they can. Mikhail has been talking about these changes for a long time and has been publishing patches for everyone to look at for over a month. And it was still a surprise to many how vast the changes were.

While we do want grow the functionality and the architecture of the CDT, it is important that we don't make too much work for those who are integrating. All I can do is encourage them to get in early and get in their feedback to cdt-dev and bugs in bugzilla as early as possible. I'm sure there are surprises in store for them, and for us on how they are integrating with the CDT in weird yet intriguing ways...

Watch what you blog

This has happened a few times now. I blog something and it ends up somewhere like here. Definitely makes me want to be careful what I say. But at least they are helping to spread the word.

The Teraflop 'CUDA

It's interesting how the big vendors play off each other when some cool new idea gets close to becoming product. The latest one was Intel with their 80 core research chip for highly parallel teraflop computing. Now we see NVidia has released their CUDA SDK and C-like compiler that does the same with their latest 8800 series video cards.

Apparently, you can get 520 gigaflops (billion floating point operations per second) with their top end 8800 card which features as many as 128 single precision floating point cores. Combine two such cards in an SLI configuration and you can hit the teraflop mark, theoretically. They have a compiler that compiles programs written in C with some CUDA specific extensions that gets downloaded to the card which runs as a co-processor to your main processor.

I can see the applications for such technology being pretty much limited to scientific simulation type things, not general purpose computing, at least not in the short term. The main issue is that not every will have these specific cards in their systems, and it really is NVidia specific. But it looks like they'll provide a huge amount of horsepower at a decent cost.

One of the reasons I blog about these things, other than I think they're cool, is to show that C/C++ development is still alive and well and growing. I remember seeing a study a couple of years back that showed it on the decline with everyone moving to Java or .Net. But there will always be applications that need to run as close to the hardware as possible to run efficiently as possible, either because the computing resources are limited such as with mobile devices, or because they are very specialized such as the NVidia processors. Languages such as C and C++ that compile directly to executable object code is still the best way to achieve these efficiencies, and why we see the CDT as popular as it is.

CDT 4.0 M5 Now Available

I am pleased to announce the availability of the first "public" milestone of CDT 4.0, M5. CDT 4.0 is going to be a huge release for us and bugzilla is telling me that we already have 265 bugs/enhancements that have been addressed (more than we did in all of CDT 3.1.0 BTW). With all the new committers working on it, it is important that we get these milestones out to the community for feedback and testing.

So feel free to give it a try. Instructions and links are available by following the CDT website, http://www.eclipse.org/cdt. Note that you require Eclipse 3.3 M5 to run it.

Unfortunately, we don't have a New & Noteworthy. But things to look out for include new Views like the Include Browser, Call Hierarchy View, Type Hierarchy View, and improvement in performance for Open Declaration and Content Assist. The managed build internal builder works better by getting dependency info out of the index. There hasn't been much change with debug and the standard builder.

New Face

For those who follow the Planet, I have a face finally. Thanks to Ian Bull for putting it together for me. For those that don't follow Planet Eclipse, boy are you missing out!

Also, I am honoured to be named as a finalist for the Top Ambassador award in this year's Eclipse Community Awards. It's funny since I had a hard time deciding between the other two finalists when I voted, Alex for is great work on EclipseZone and Chris zx for constantly hooking me up with cool things happening in the greater Eclipse community. Good luck to both of them!

Old news is good news

I have to admit, I am one of the worst committers when it comes to responding to newsgroups. I have a tough time just keeping up with cdt-dev and bugzillas and writing code and ... that I never seem to have time to go to the CDT newsgroup to see what people are talking about. Don't vote for me in the Top Committer category, that's for sure.

But I went there today to announce CDT 3.1.2. I guess this is the first time I did since I got my new laptop a couple of months ago (see!) and it downloaded all the messages since the beginning of time. It was interesting. There are over 12000 messages since the first one where John Duimovich launched it on December 10, 2001. The talk then was on today's CDT's predecessor from IBM which was very different (and some lives on today in the Remote Systems Explorer from DSDP/TM).

The first message after John's was from 'dominic' who started a thread of fans that were drewling over the idea of a C/C++ tool in Eclipse. There were a few posts from people who had great feature ideas, like ant support and UML modeling (which funny enough is what got me into the CDT). People were concerned that the team wasn't testing using the funky new GTK support on Linux available in early access form with Eclipse 2.0. And, of course, people were asking, if you can do C/C++ how about supporting Cobol and Objective C too.

It's pretty good reading and gives a great historical background on the evolution of the CDT. And it's a bit spooky since I hadn't even heard of the CDT at the time and all this activity was happening. But the coolest thing is the diversity of people that posted then and post today. It certainly is a great way to keep in touch with the community outside the cdt-dev walls. And I'm probably the last committer to see the value in participating, which is now my late new year's resolution...

CDT 3.1.2 Now Available

It's been a pretty busy week as we are getting two releases together pretty much at the same time. The first is the release of our latest maintenance release CDT 3.1.2. Bugzilla tells me there were 101 bugs fixed in this release, which is a pretty good number given that we have been very busy working on CDT 4.0 at the same time.

The biggest fix that I put in was to move away from using memory mapped files for the Index (also known in some circles as the PDOM). Memory mapped files worked well until we started running into very large workspaces where we started to run into limits on Windows. I've switched it to regular files that read in chunks at a time and use a least recently used (LRU) cache to make sure we don't take up too much memory. It did cost us some in performance, but I'm still within the targets I had set out for CDT 3.1, i.e. indexing Firefox in under 20 minutes.

More information can be found on the CDT Website.

Stay tuned for our first real milestone for 4.0 early next week...

OpenKODE: Cross Platform Mobile Gaming in C

I blogged a while back about an open source mobile gaming device, the GP2X. It's a pretty simple and inexpensive unit with a dual core ARM configuration. I think a lot of people are using it for simple 2D games and there are ports of the arcade machine simulator, MAME, to it. It's not a very powerful machine, but I thought the idea was pretty powerful.

It got me thinking about whether the industry would be interested in a similar platform but with 3D gaming support. And if not, why not. Maybe these things cost too much to build. Maybe the business case isn't there. I haven't seen too much interest from the big gaming houses on porting their titles to OpenGL ES, a standard 3D API for mobile. But then, there isn't really a high volume platform out there that supports it to the scale of the Sony PSP and Nintendo DS. Unless you count phones, but you can't do serious gaming on a 1" screen...

But it looks like the gang at Khonos.org are trying to do something about that. They recently ratified a draft specification for a common platform API called OpenKODE. It's a collection of C APIs, most of which they've already specified for video and audio. But it also has a OS abstraction layer so you can compile applications against any OS, or so goes the theory. The intent is to provide a platform for content providers that will allow them to hit as big a market as possible.

They are accepting comments from the industry and I see vendors starting to do press releases announcing support for it. My hope is that you'd start seeing mobile gaming platforms like you see with MP3 players, i.e., a lot of vendors making different types of devices but all supporting common standards. That would sure change the face of the industry a bit.

The CDT Can Help you See!

Well, not really, the NASA Vision Workbench can and this guy is using the CDT to work with it. After all the hard work we've put into the CDT, I'll take "Eclipse’s CDT plugin (which has definitely gotten alot better)" as a compliment.

What do you use for UI testing?

The TPTP gang were adjusting version info in an enhancement request I raised against their Automated GUI Recorder (AGR) and it reminded me I need to look into this issue again. I remember seeing a demo of the AGR back when I snuck into an Eclipse Architecture Council meeting a year or so ago. It looked pretty good and appeared to do what we've needed for the CDT since forever, i.e., something to automate testing the GUI.

The issue I have had with the AGR is that I want to integrate the test cases that AGR generates into our existing JUnit framework. Unfortunately, that was impossible, or more realistically, was a lot of work to do. And, also unfortunately, the word I hear through the grapevine is that the AGR really isn't staffed well enough to evolve it this significantly. It met the needs it was created for, i.e. test TPTP, and if it is to fulfill a larger role in Eclipse, it really needs more Eclipse developers contributing to it.

So if the need isn't there to trigger this investment, it got me wondering what people use to automate their GUI testing. Of course there are commercial products out there that do the trick and we've used those here at QNX. But for open source development, it would be nice if we had an even playing field so that anyone could contribute tests without having to purchase the "standard" tool, assuming we could even agree on which "standard" tool to use.

I heard of the Abbot GUI tester and the Costello GUI recorder, still the best names in open source IMHO, a number of years ago. While built for Swing/AWT, they started working on SWT support a long time ago but it has been slow going. I have heard of some people using it for their Eclipse testing, but I'd like to see an official release of it before committing to it. But it does what I want, though, i.e. integrate with normal JUnit.

So I'd like to hear people's opinions on this, especially on where they would like to see developers invest their time if they indeed wanted to contribute to an Eclipse open source GUI testing tool. I think the need is there, but that means "beans" if no one else does.

Now what am I supposed to do with 80 cores?

Yesterday, Intel announced a research project they've been working on to produce a core capable of reaching teraflop (a zillion floating point operations, or something...) performance. The chip they've come up with has 80 cores. Sounds like a lot, and it is. Now, this is a research chip and it is missing things like a memory controller which makes it impractical for anything. But it is serving it's purpose of helping us understand what such an environment of the future would be like. The benefits will be paradigm shifting, but we have a long way to go before we get there.

Of course, being a tools guy, I think the tools industry needs to jump on this. Without proper tools, developers just won't be able to deal with the complexity of the software that takes advantage of such scalability. This is one of the reasons I'm very interested in the Parallel Tools Platform (PTP) project at Eclipse. They are trying to deal with such environments today by providing tools that support developers working with supercomputers used for scientific research.

The challenges are enormous and include the whole edit/build/debug programming cycle. What libraries and programming language enhancements do you need to write an 80 thread or process application, how do you build and deploy such a thing, how do you debug it? I can still picture the problem of setting a breakpoint, having 10,000 threads hit that breakpoint and then trying to find the one that you are interested in. Sounds impossible. But there are some pretty smart people working on PTP and it'll be very interesting to see the solutions they come up with.

Open Source Translations?

Well, it was a busy week for conference calls. The latest was on an initiative to start an Eclipse project to take care of the translations for the Eclipse project. I went into it being mistaken that the initiative was simply trying to spread the translation work around for Europa so that IBM didn't have to do it all. It's a pretty expensive endeavour to translate all of Europa to 23 languages. But the intention is indeed to be more than that.

Now, for the CDT, translations haven't been a priority. We haven't released language packs for the CDT since the 2.x days. We still get a healthy 20% of our downloads to China and I haven't received feedback that they miss them. But I imagine we'd grow even more internationally if we had them.

Despite my original skepticism, I think a translations project is a great idea. Technically, making the translations isn't very complicated so you don't need to be a hard core developer to help with them. And, apparently there are some tools that have been made to help make it even easier. It would be cool for the users of Eclipse around the world to help out with this and would probably result in better quality as they actually use Eclipse.

My skepticism right now comes from the current focus on getting the Eclipse member companies to contribute rather than on building a community. I think if you focus too much on short term goals, like translating Europa, you won't solve much when the next release comes around. Hopefully, this project will find an inspired leader that break new ground in international community building. It certainly won't be an easy task. But it could be another great step forward for Eclipse.

CDT: An Open Culture

After today's CDT conference call, the gang here at QNX got to talking about how interesting these calls can be. Apparently, the CDT has something special going with how open we are.

The topic we were discussing was my mention of our plans with Momentics and CDT 3.1.2 and CDT 4.0. I did it just to let the community know that if I'm doing something weird, it's because I'm trying to get the CDT 3.1.2 into the next Momentics maintenance release and to set expectations on when we'd be trying to integrate our custom bits with CDT 4.0 to provide feedback on the new frameworks.

What I had forgotten was that in this highly competative industry, this is usually a no-no. Mentioning product plans could definitely cause a slap on the wrists. Product plans are high quality ammunition that the marketing teams use against each other. Not that I aspire to such tactics, mind you.

But with the CDT and even the DSDP, this hasn't really been a concern. We often drop hints on what we're doing commercially. It all comes back to "When is you problem my problem". If you at least know about my problem, you might make some effort to help me. But if I'm keeping my intentions secret, there is no trust, and I can't see how you can have any hope of co-operation from the community.

In the end, we concluded that the CDT was a pretty cool project to be a part of. There are a lot of projects at Eclipse now, and not all of them have realized the benefits that an open culture can bring them and their customers. And it's not just getting people to help you with your problems, either. It's just cool to be in touch with the rest of the industry and know what's going on out there.

Windows Vista versus OpenGL

I just finished reading Tom's Hardware's benchmarks comparing Vista and XP. I remember hearing that Microsoft was dropping OpenGL support and Tom's confirms it with their benchmark of OpenGL apps. I don't follow the graphics community as much as I'd like but this really has to be a blow for some of them. If not that, then it's a blow for them upgrading to Vista.

Back on my Digital Content Creation with Eclipse soap box, I guess this kind of spells doom for the OpenGL work that's been going on with Java and, by extension, SWT. I have always thought that it would be very cool to have a 3D modeler built on Eclipse and nicely integrated with the CDT to build games and such. Most of these modelers are built using OpenGL and probably don't work well on Vista.

So the question becomes, when will someone build DirectX support in Java in an SWT window?

It also provides a twist for the work I'm doing on Windows development. I've been torn between whether Windows developers should use the Windows SDK or MinGW with the CDT. I'm not sure how mature the DirectX support is with MinGW compared to their OpenGL support, so my feeling is that the Windows SDK with the DirectX SDK will be what developers will want to use. Which means I better get that Windows SDK integration done...

My Take on Eclipse PluginFest

Well, I'm finally home from my trip out to the Eclipse PluginFest. I made a side trip to Karlsbad, Germany to visit a customer, where it was pretty cool to see them adding their own plug-ins. Eclipse is indeed everywhere. And I was met by a very Canadian-like snow storm there. While it was fun to drive in, I missed out on a lot of sleep with the late arrival. But it was still warmer there than the -20C here.

Ian has a really nice summary of the PluginFest event so you can read that to get the general gist of what happened. From my seat, it went way beyond my expectations. I found everyone who attended to be very open and we all filled up our laptops with trial versions of each other's products and tried them all together. I was concerned that being a commercial event there would be a lot of protectionism happening. But it turned out that most of us already knew eachother from past Eclipse events, so were instantly comfortable with each other.

For the most part everything worked, but that is to be expected given the clean plug-in architecture of Eclipse. But it did point out an important requirement that everyone be on the latest version of the Eclipse plug-ins. Happily we made that decision at QNX last year and it paid off for everyone who did. It was cool to see other plug-ins work with our product and that should open the door for some pretty cool environments for our customers. And the sentiment was shared by the other vendors there as well.

But as Ian mentioned, the value of the event went well beyond testing our plug-ins. It was a great opportunity to talk to everyone who was there. I had a lot of people ask me CDT questions, including a couple asking how to get involved and contribute the CDT changes they have had to make for their products. I also got a chance to talk to a couple of the CDT committers that were there to go over design issues we need to resolve. Meeting face-to-face this way is pretty expensive, but it certainly has a lot of value for the people that get to go.

We definitely need to do this again, maybe after a year to give us all a chance to get onto the Europa platform. The gang at Symbian were great hosts, but I have a feeling a lot more vendors will be interested in this next time and we'll probably need a bigger venue. This was our first try at bringing vendors together for inter-operability testing and it really shows the value of the Eclipse architecture. And I'm sure all vendors building on Eclipse would be interested in this. I see big things in the future for the Eclipse PluginFest.