Android is a Java fork, yeah so?

I'm finding it very interesting how a number of articles in the blogosphere are attacking the Google Android platform. I guess it is easy to criticize given it's only been in the public for 6 weeks. Yeah it looked like it would be vaporware until we got a hold of the actual running emulator and SDK. And yeah, the quality of the SDK could be better and there could be more for building native apps. But I think the Android team has done a great job of getting something in developers hands early so that they can start coming up with some money-making ideas and feedback any issues that they do run into.

The issue that I think people are getting caught in is the claim that Android is a fork of the Java standards. You know, I could really care less about that. If the Android platform is truly open with a commercial friendly license and is available on a lot of platforms, it will succeed. And if that means you'll have to port your Java ME or even your Java SE apps to it, the market will tell you that you should invest in that. I'd rather see the community decide what the best platform for mobile should be, not Sun who has little experience with it.

And I'm sure many at Eclipse would feel the same. Believe it or not, Eclipse is a fork of the Java standards as well and for much the same reasons. The Java standards didn't cut it when building great desktop applications. SWT and the Eclipse Platform have really kept Java alive where I thought it would never survive. It's a fork for all the right reasons. And so is Android as an embedded platform.

One thing you will see though is that Google, or at least the Open Handset Alliance (OHA) of which Google is the most powerful member, will dictate what the Android standard will be, much like Sun does with Java standards and much like the Eclipse Platform team does with the Eclipse Platform. And there is nothing wrong with that. If you're in the business of making money writing applications for these platforms, you want them to be as successful, i.e stable, as they can be.

But what it does mean is that if we want changes, we'd better the requests in now before we start debating whether there will ever be an Android 4.0...

Oh, My Spinning Head

It's been a great first week at Wind River. I spent 3 of the first 4 hours there in conference calls which has given me a hint at how things are going to go. Wind is a very dispersed company and everything is managed over the phone, through IM and e-mail, and the occasional travel. It should be very dynamic and a really cool environment to insert myself into it.

And while that was going on, the debate raged in CDT-land over how to deal with projects sitting on top of file systems that may be spread all over hell's acre. The good news is that we have a lot of momentum and all the right people in place looking at it and talking about it. I think EFS is the key and how well it works hiding away the details of the actually layout of the files and directories from the rest of the CDT and Eclipse in general will tell how well we succeed.

I'm going to spend some time over the Christmas holidays working on my flexible file system. I have a good idea of how to do it, I just need to sit down and get it done. Once I'm finished, I'm hoping it'll work a lot like other major IDEs, Visual Studio included, and that you can add/exclude files and directories from anywhere your machine has access. And that should help us test all these other scenarios as well, including having your project distributed between machines.

It's going to be cool stuff, and I'm sure other projects will be interested in it as well. Our challenge will be to engage them and make sure we come up with a solution that works well for all of the Eclipse community.

Winds of Change

So I've started my new job. For those who haven't seen yet, I am now working for Wind River as an engineering manager in charge of a small team. From the meetings I've already had this morning it's going to be an interesting challenge and I have a lot of new technology to learn and people to meet.

On the Eclipse side, I will stay on as the CDT project lead. I've been very impressed with the team at Wind that is responsible for a lot of the good work that went into CDT 4.0 as well as the DSDP projects. And I'm excited to be able to continue working with them and the rest of the CDT community.

Of course, I am who I am, and none of my philosophies change with this move. I am still devoted to the grassroots of the open source world. You get them excited about your technology with a low barrier to entry, they become great customers in the future. And Wascana continues to play an important role there.

And I see Google Android filling the same role for embedded. It is an exciting platform for mobile devices (and not just cell phones) and I've been blown away by the energy of the community that's growing around it. There are guys who have even figured out how to build native applications with out having any of the header files and compilers available to them.

It'll be interesting to watch the parallels between Android and Eclipse. They look very similar in philosophy of commercialized open source and the power of community in making a successful platform and that's something the mobile space really needs to bring it to the next level.

Thank You QNX

I have an announcement. Today is my last day at QNX Software Systems. Now, for the Eclipse CDT community, no worries. I won't be going far and you won't see much of a change from me. But I do prefer to hold off announcing where I'll end up until I get there. Today, I want to pay tribute to QNX for whom we owe so much for where the CDT is today.

I'll always remember the first CDT summit in 2002. It was held here in one of the larger meeting rooms. We had people from Red Hat, MontaVista, Rational, and of course QNX. I remember the QNX gang being giddy as if they were proud parents. It was that day that the CDT project was born (or more historically accurate, reborn, but anyway).

The CDT that QNX gave to us was exactly what I was looking for. Something that fit in well with the rest of the Eclipse plug-ins, and the JDT especially. Even then we considered mixed language development with JNI as the holy grail that we were seeking, which we still are seeking BTW. The whole thing was a tribute to the small band of great developers that were locked away in an offsite building charged with coming up with an Eclipse based IDE in 6 months. They made all the right choices and most of them are still in effect today.

QNX also had the vision of what a commercial open source co-operative could accomplish in the right environment. IDE's are not QNX's core competency, and that is true for most platform and tool vendors. Very few IDE's have been successful in the market because they require a huge amount of investment to do right. But if we all banded together, put away our competitive anxieties, and focused on the common good, we could and did pull it off.

I also have to thank QNX for giving me the opportunity to "finish" what I started at IBM/Rational. When we lost the group there, we lost a hand full of really good developers, and friends, that were working on the CDT. But we clearly did not have a "successful" indexing strategy at that point and I really feared for the future of the CDT. I sincerely have to thank the management team here for talking me into coming over. It gave me the opportunity to set things right, and they helped me build my career as a leader in the Eclipse community.

I'm very happy with how the CDT and its community have evolved over the last two years. We owe a lot to QNX and QNX will always hold a special place in our community. I wish all the people I've worked here all the best and I look forward to continue working with them in the spirit of friendly co-opetition.

Wascana, Still Going Strong

I got an note on one of the forums for Wascana, my packaging of the CDT and GNU toolchain and assorted libraries for Windows development. The question brought up again the need of the community to support the Microsoft toolchain, and debugging in particular. Unfortunately I've been busy with other things and really need to do a reset on this work to figure out the best way to proceed that will be the most successful. So not much progress has been made.

While I was on the Wascana site, I thought I would check to see how the download numbers were doing. It's been three months now since I made the last release and it's probably time to do another one, especially if the numbers had dropped to nothing.

But to my pleasant surprise, we have apparently passed the 3300 mark. The numbers have been strong with around 30-50 downloads a day but are now starting to dip below 20. So guess it is getting time. I need to figure out how best to package the boost library, and then get the latest Eclipse Platform and CDT. It would be really nice to figure out how to use the update manager to install these components nicely for you but I think that'll have to wait until next summer when the new Equinox provisioning work is ready and I've figured out how to use it.

But it is good to see Wascana is still seen as an interesting alternative for Windows developers.

AGR is dead, apparently

One issue we've always struggled with on the CDT is how to do GUI testing of the CDT's UI components. A number of us looked at different open-source solutions that would allow anyone contributing to the CDT to also contribute GUI tests. Some community members do use commercial tools for their internal testing. But we'd prefer something generally available for everyone.

Two solutions seemed to come out tops, albeit a very low tops. AGR from TPTP and the SWT port of Abbot. However each of these had two severe problems that prevented us from using them.

First, the Abbot/SWT port has been progressing very slowly to the point where we're not sure it's even alive. We do have one committer, though, that is looking at supplying them with patches and maybe that'll bring it back to life.

AGR also had one big stumbling block, it's dependence on the TPTP test framework. The CDT releng test run is a simple JUnit setup and we wanted to run our GUI tests as part of that without having to spend the effort of integrating the framework. Bug 138369 was raised to see if someone in the community could make AGR work in such a simple environment.

Well, today, we were notified that AGR has gone into an As-Is state (i.e. dead) and the bug was marked won't fix. I personally recommend against marking bugs in the CDT as won't fix, because, who's to say someone won't come along and try and fix it. Why shut the door like that. At any rate, it does point out that the community hasn't really rallied behind AGR as a GUI testing solution.

So what is the current state of open source GUI testing frameworks for Eclipse? Is there something else out there? Or is there still hope for either of these technologies? Is there an EclipseCon talk on this subject?

Using CDT for MySQL

I recently got a note from a Hakan at MySQL who wrote a tutorial on how to use the CDT to build and debug a component of MySQL called Falcon. I'm always glad to see when other open source communities have found the CDT useful for their work. It's one of the best ways to show publicly the different capabilities of the CDT, and its a lot easier to get co-operation between open communities.

The tutorial shows MySQL being debugged on a Mac. I didn't realize how slick the CDT looked in that environment. And I guess I didn't realize that MySQL ran on a Mac, but it makes sense that it does. And it really shows the value of the CDT for cross platform development. They follow the same steps on Linux. Now if we could do Windows just as easily...

Camping the Eclipse Way

Hmmm. Instead of huddling around a campfire, we were huddled around a projector screen, and there was lots of beer, so I guess it qualifies as my kind of camping. I attended the Ottawa Demo Camp last night and it was a pretty interesting evening. There were around 30-40 people there and we had 7 demos by various people who work on Eclipse technologies that live in the Ottawa area. Only a couple were from IBM, which kinda dominates the scene here, so it was good to see the diversity.

The one I found most interesting was a new start-up called Protecode. They demoed the product they are building that helps secure any IP issues that can be introduced as developers are working in the code. I'm sure some of those developers would be creeped-out by a tool watching you cut and paste code and recording if you pasted code you shouldn't have. But for large firms that have strict IP policies, this would be a great tool to help them find issues early in the development cycle when there is still time to address them. I had some nice comments talking to their CTO after about how great it was to have the CDT available to them so that they could get some C/C++ developers using their tooling and help them get to market quickly. And that's what the Eclipse ecosystem is all about.

For my demo, I had to quickly put something together. Things have been pretty busy for me lately and the demo slots were only 10 minutes anyway. So I decided to show a side by side comparison of the features in the newly released Visual C++ Express 2008 and Wascana's CDT 4.0. Even I was little surprised at how evenly we are matched with the "Goliath" in our space. And, of course, to show the real benefit of Eclipse and the CDT, I showed how I extended the CDT to generate new project code and build settings for wxWidgets using CDT's extension points and the Plug-in Development Environment. Not something you can do with the free, or even the paid, version of Visual Studio.

All in all it was a great evening. I got to catch up with some old colleagues of mine and got to see the diversity of interest in Eclipse here in Ottawa. And from what I hear, the other Demo Camps being planned are just as big if not bigger. It would be cool to be able to see what everyone is doing in Budapest...

EclipseCon Submission deadline approaches

Time is flying and we can't stop it. The submission deadline for EclipseCon talks and tutorials is fast approaching, i.e. Nov 19. We have been allocated a number of tutorials and talks to talk about Eclipse in the C/C++ world. If you are planning on attending EclipseCon anyway, you might as well talk while you're there, and get some or all of your registration fee paid for. Feel free to submit any ideas you may have, no matter how crazy they are to the EclipseCon submission system.

A Linux Desktop Battle Brewing?

O.K. I'm on record as saying I hate Linux because it looks ugly. Windows has much cleaner fonts and UI responsiveness (unless you're doing a lot of disk access in which case you get tons of hesitation, but I digress). That being said, the development tools in Linux are way better, as is traditional with the *nixes of the past. Heck, any operating system that lets me mount a file as a pseudo file system can't be beat.

So, as the story goes, my laptop is starting to get flaky. It overheats when plugged into my port replicator and shuts down at random times. And I don't feel like going without it for a few days to get fixed, at least not right now. So I'm just using it without the replicator, meaning I have my LCD screen and keyboard freed up. So with all the hype surrounding Ubuntu 7.10, I upgraded my little Linux box and plugged the LCD into it. I'm now using it as my main development environment leaving my laptop for e-mail and internet radio and stuff.

One thing I noticed right away is that my Linux box has a video card that supports OpenGL (vmware does not). That allowed me to enable the cool compiz desktop enhancements. Now my windows jump onto the screen and scamper off when they're done. When I move them, they flap in the wind (which is pretty annoying after a while). I managed to get the fonts to the point where I don't mind them, but they're still miles away from Windows. But you know, it's not that bad an environment.

Now I see that Fedora 8 has been released with a whack of new desktop features. Of course, given that both distros are taking software from the same base, it's not too surprising that Fedora 8 looks just as good. Ubuntu is apparently still better for laptops, especially when plugging and unplugging external displays all the time (which actually worked when I ran vmware on my laptop in full screen mode). I saw a note in the Fedora 9 plan about trying to be as good or better than Ubuntu at that.

So I have to eat my words a bit now on Linux desktop. It's starting to look pretty good and probably time for me to start taking seriously, especially when Eclipse and the CDT are becoming a favorite IDE for Linux. And with the little competition between Fedora and Ubuntu, the user experience should only get better too.

You want to do what with EFS?

In my last entry, I dropped a quick note about a feature I'm planning for CDT 5.0 due out with Ganymede next summer. We are getting more and more requests from users moving over from Microsoft's Visual Studio that the CDT should do things like in Visual Studio. One of the high runners is to be able to add files and directories from anywhere in the file system to projects, and to be able to exclude files and directories from other directories. You could use Linked Resources to do the 'add' today. But there's no mechanism to do the 'exclude'.

After playing around with EFS for remote project support, I got the feeling that I could do this add/exclude functionality using EFS by implementing my own file system that would map paths requested from IResources into real file system paths the users wants them to map to. I've decided to call this the Flexible File System (or ffs for short and as the schema name).

I'm not sure if this is going to work out yet. The simple things like opening files and building the resource tree should work. I really want to get the Team system working as well so you can keep the files in source control. That will be the really tricky part. I also think there is going to be a lot of issues we uncover where we're assuming we know the layout of the file system. And we got to figure out how to tell the external tools the real file locations they need.

For now, I'm only looking at this from a CDT project perspective. I know there are a lot of other projects that could use this and I hope we can move this to the platform at some point. And it won't do some other things with the resource system we've always wanted, like nested projects. But now that we've reached a good level of maturity with the CDT, we need to start addressing these issues and remove those final big objections to moving to the CDT and Eclipse.

Guess what I missed most...

For some reason, I've gotten interested in ray tracing (like I don't have enough in my life to do right now). So when I found out about a project some guy is working on called Arauna, I had to go look.

It was pretty cool. It looked great as far as lighting and shadows and reflections go, which is one of the best things about ray tracing. And it was rendering a scene with 70K triangles in real time with frame rates on my Core Duo laptop between 7 and 25, pretty reasonable. And with the algorithm exploiting both of the cores, it looks pretty promising as well in our near future of highly parallel architectures.

The guy had the source code for download as well. Of course, being a Windows app using DirectX, it came with Visual Studio project files. Once I figured out how to work around the project setup for Intel's C++ Compiler, I was able to load up the projects into Visual Studio Express 2008 Beta 2. Not only was I interested in looking at the ray tracing algorithms, I also wanted to check out the state of the art that Visual Studio is coming out with compared to the CDT.

VS does have a few things that we have now with CDT 4. It has a pretty fast search for declaration, definition, and references. It seems pretty accurate, although I did notice the had the same problem we did when opening the definition of a constructor. It went to the class definition instead. Also, they have a call hierarchy tree, just like CDT 4 introduced. I guess we're reaching some kind of parody as far as features go.

But the feature I missed most, especially when trying to learn someone-else's code, is the Outline View. We sure do take it for granted in Eclipse-land. It's been there forever with the CDT, starting with the original drop from QNX. With VS, I kept finding myself looking over the the right hand side of the screen to see the outline every time I opened a new file. Instead I had some useless property page staring back at me.

We're getting more and more feedback from CDT users that are coming from the Visual Studio world. There are a few things that Eclipse and the CDT are missing and we are looking at trying to address those. The biggest one is that they want the ability to add any files and directories to a project that they want. I'm looking into a way to do that with the Eclipse File System (EFS). We'll see if I can get my ideas working. But it's cool to see the trend developing.

Do we need Eclipse "Products?"

There has been an interesting discussion on the Eclipse Planning Council mailing list over the last few days. We are planning the Ganymede release scheduled for June of '08 and as part of that, we are trying to integrate an expressed desire by the Eclipse Board of Directors via the Eclipse Foundation that projects meet a number of requirements that raise the quality of Eclipse across the board.

This has caused some confusion and some misdirected passion (of sorts). Given that the Eclipse governance model has the committers, the people elected to make code changes, as the only people who have the power to make code changes, and that the Foundation and Board have no real power over the committers, other than those employed by Board members, and other than to hold up the IP review process that governs getting 3rd party submissions into Eclipse, how do we get these requirements to happen?

My favorite solution at the moment is to create a "carrot" instead of some sort of "stick". Something for projects to aspire to. Something that gets a bit of glory in the community. That idea is to take the existing Eclipse packages, such as the Eclipse C/C++ IDE, possibly adding others, and treat them as real commercial products (still free and open mind you). For those of you who aren't heavily involved in software product development, there is a whole set of tools you get with the field of product management. Some of my best friends in this industry are product managers. These are the guys who take a look at the market, talk to existing and potential customers, figure out what a successful product in that marketplace would look like, and then drive those requirements through the engineering team to make it happen.

There are a number of benefits to this, including giving the industry something to focus on when they talk about Eclipse and a higher quality product base on which vendors contributing to Eclipse can build their own products on, without having to duplicate the "productization" effort. And being the showcase of Eclipse technology, projects that want to show off their wears would put in the extra effort of complying with product requirements so that they could be included in that show case. (In theory, anyway).

But I also think that the challenge of making this work is daunting. My product manager friends will be the first to complain that they don't have a lot of power over the engineering teams anyway, but with the Eclipse contributor co-operative that we have I don't see much hope. There has to be a commitment from the community that this is important for Eclipse and important for themselves. But I do think we need something like it, because I do think it's important for Eclipse and for every vendor making products based on it.

The community never ceases to surprise me

I hate blogging more than once a day. But as soon as I posted my last one I checked the CDT bug reports to see what was coming in. I ran into this one, 207482, raising the issue that the option to intermix header and source files in the Projects explorer isn't working. That's no good since I hate that we separate them now. But I didn't realize we had put in that option and will have to try it out and see what's wrong.

But never mind that. What really made my day was the e-mail address of who raised it, whirlpool.com. You know, I suppose that appliances are so advanced these days that they have a processor and a hunk of firmware that runs them. And why not use the CDT to develop that firmware, it's one of the things we're really good at. Assuming that's what this guy is doing (and I don't think it's my place to ask since that's probably proprietary information), Cool!

Ever rising expectations

You know there was a time when I though syntax highlighting was a cool feature. It made it easier to see your code by allowing you to focus on the things that are important, like the names of functions you call and variables you have. With the correct coloring, keywords tend to slip into the background where they belong.

Well, content assist with STL iterators doesn't work. If you define a Class A with a member x and you have a list<A> of them, you want the iterator i-> to give you the x. No, really, it's the cat's meow of content assist - interpreting the i to find out it's a iterator template instantiated on A then resolving A to find out what it's members are. The unfortunate thing is that this used to work up until CDT 4 when we moved content assist to use the new index framework instead of always doing a complete parse. It's much faster now, but we don't have all the necessary information about templates in the index yet.

And, of course, with our active CDT community, people are starting to raise bugs on various things that aren't working with templates. For C++ developers, the Standard Template Library is an awesome tool. It greatly simplifies the code you have to write to use generic collection classes and it does it with all the type-safety and performance that C++ is famous for. I guess I shouldn't be surprised that people expect the CDT to work with them as well as it does regular C++ classes.

But, under the hood, this is an incredibly complex beast. When we got it working first in CDT 3.0, despite the somewhat slow performance, I was proud of the team that we were able to make something like this work. It was a lot of effort by some really smart people, who unfortunately have moved onto other projects. And luckily we have a new set of really smart people who will continue the effort as we move to the new index. So we will get it working again.

It is very interesting to see, though, the expectations that IDE users have now. It certainly has come a long way. Once we get the template thing done, our next biggest demand is C/C++ refactoring and we have some more smart people lined up to look at that. If you were to start a new C/C++ IDE today, it would be a daunting task to meet these expectations. I'm glad we have the history and the team we have now on the CDT so that we have a chance.

Assert.isTrue(false) never works

In case you were wondering, this pretty much throws an exception every time. Although, I one of my first mentors often tried to blame stray electrons on some bugs so, I guess if he was right, there could be times when this does work. But I wouldn't put money on it.

I ran across this particular piece of code when it showed up in a bug report recently. It came at the end of a if-then-else chain as the else that the author didn't expect to ever run. Well, this one unfortunate user found some way to make it run. Maybe it was a stray electron, or maybe it was just a corrupt preference store. We'll have to see.

But this did bring up another of my mantras for software development. Don't throw an exception that you don't plan on catching. Sometime we use exceptions as a crutch. If we get to some point where we can't figure out how to continue, we just throw an exception and don't need to worry about it any more. At least until the exception bubbles up to the UI and the poor user has to deal with it.

It's a tough job to put in all the possible error handling for a given situation. If you're building a safety critical system, you get a whole boat load of funding to pay for that effort. But when you're building a software development tool, you often feel that you don't have the time to work on code that you don't think will ever run. But it really does pay off in the end. When you have hundreds of thousands of users of your software, there's a pretty good chance one of them will run into a stray electron or two.

Trust Matters

I just finished reading this article on a recent failure with the International Space Station. Something caused all three Russian-built computers on the ISS to fail at once while the Space Shuttle was docked and the Americans were installing a solar panel. I love reading post-mortems like this and wish we did more of them in the software industry. You certainly learn a lot about what can go wrong on a project.

In this case, they found the problem to be with condensation causing corrosion of power lines and an eventual short. That caused an unfortunate chain events that activated an unfortunate feature, a single command that would turn off all three computers, nullifying the triple redundancy. Once that was identified it was easily and "creatively" corrected and everything is fine now.

But the thing I got most out of the article is that one of the bigger problems was the original incorrect assumptions made by the team that caused the determination of the real problem to take longer. Being from different countries, they team started out by blaming each other for the failure instead of taking a non-partisan approach and trying to solve the real problem.

This is something I try to do as much as I can, which is unfortunately not often enough some times. If there's a problem, start with the assumption that I screwed something up. None of us are perfect and that group starts with me. That helps me take an honest look at the situation and if it is my fault, we can find it quicker. If not, then the fact that I'm not trying to hide from the problem should help there too.

When you are involved in an open source project with contributors from different companies, especially when the companies are competitors, you can end up in the same scenario. It is hard to build trust in those situations, and when your building something complex and run into problems, that trust becomes very important. To be successful, you need to trust that the other people are doing a great job. If you fall too quickly into the "blame game", you'll only get the project, and yourself into deeper trouble.

ESE 2007, another great Summit in the books

Well ESE is over for another year. I found this one much better for me than the last. This is a real tribute to the growing strength of the CDT community in Europe and the effort people made to come here and introduce themselves. I had a lot of fun with them and my peers in the Eclipse community. It really reminds me why we make this effort to contribute where we can.

Here are a few more points I took home from the week:

• There were a lot more people from the embedded space at ESE this year than last. So many of the vendors in this space see the value the CDT has provided them. Hopefully this will also lead to continued growth in our contributions :)


• The guys from BMW CarIT gave a great presentation on how they are using the CDT in their tool chains. They have a really cool target system comprising of 70 processors working together and are trying to get them all to do more work. It's a great real life example of using the CDT for complex embedded systems. Hopefully they'll post their slides to the ESE pages soon.


• The BMW guys also let out a secret that I'm glad got out. Building an integration to a compiler with the CDT for managed build is really easy. A day's work tops. I wouldn't mind seeing a concerted effort to co-ordinate these, maybe make a public repository of them. That'll also push some CDT vendors to add more to their products than just a managed build plug-in.


• The BMW guys and others I talked to also showed me that there really are end users of the CDT that also write plug-ins to do the specialized tasks that they do. One of them even said this was getting to be a problem since there are getting to be a lot of them and is getting hard to manage version line ups. This is one of the great promises of Eclipse and part of what is supposed to make our Eclipse-based products so good. I'm excited to finally see it really happen.


• Being without wireless LAN for almost all of the conference was really inconvenient and left me to writing blog entries late at night. But it did help me pay attention more to the speakers, which I guess is really a good thing. But lets hope it doesn't happen again :).

Well I should get to bed so that I can get to the airport at a good time tomorrow. Thanks to everyone I met here at Ludwigsburg for making me feel welcome and I hope to see you all at another Eclipse event soon.

CDT day at ESE

Now that I get to one of these things, i.e. Eclipse Summit Europe, I really get why I need to be here. I've met a number of people that were interested in the CDT who were very glad to meet me. I got some really good questions from many of them who are extending the CDT for their own build and debug tool chains. CDT in Europe is very much alive and thriving and it was a great opportunity for me to see what all was going on and to help where I could.

The day got started very late as my talk wasn't until 5 p.m. It was great to see around 30 or 40 people attend, more than last year. We then followed it up with a BOF late in the evening where we had a great discussion from a number of different people using the CDT on areas where it could improve and where thing are working better than expected.

I really got a feel for the diversity of the people interested in the CDT as well. I had a number of silicon vendors ask me questions on how to integrate their specialized toolchains with the CDT. This is definitely a hot spot with the CDT and something I didn't really anticipate. I'm much more used to RTOS vendors working with the CDT, but these bare metal guys are doing some pretty cool stuff.

I also learned that there not one, but two groups looking at C/C++ refactoring for the CDT. It's a very tough area and our current AST implementation presents a lot of challenges for them, but give the number of people who showed interested in having that functionality at the summit, it could be the next great step for the CDT. I hope things work out there.

The day closed off with a nice social closing with a number of the Eclipse Foundation staff. They are a very cool bunch of folk that have a lot of passion for what they do and in growing the Eclipse community in all directions. As Mike presented in his opening, he wants the Foundation to be around for 50 years doing something interesting. If they pass on their passion down the line, I'm sure this can be achieved. As long as they don't get too many German bartenders mad for bringing in Burger King even though the restaurant was closed. Oops, I guess what happens in Germany should stay in Germany, oh well...

Hello from Ludwigsburg!

I'm here in Ludwigsburg, Germany already a day into my Eclipse Summit Europe experience. I'm glad I'm here. Looking at the CDT contributor community, I'd say we get half of our contributions from developers based in Europe. And given the number of people that have come up and introduced themselves to me, there is a lot of CDT interest here and it should be a busy week for me.

I'm watching Erich Gamma's talk as I type this. He's giving a very refreshing look at the history of Eclipse and how we got here. It's really a tribute to the vision from him and the gang at OTI that an effective development organization could form in the open source community. We've had our growing pains, but a number of projects are now thriving in this environment, especially IMHO the CDT.

I have my talk on CDT 4.0 later today and tonight we have a CDT BOF. I look forward to seeing who will be at the BOF and if you're here, please feel free to stop me and introduce yourself. I'm finding my picture on my blog is making easy for people to spot me :)

Multi-core everywhere

I was just reading about ARM's latest announcement for their new A9 processor core. I'm a bit of a fan of ARM and not just because they have a committer on the CDT :). They have a very interesting strategy when it comes to their market and rely fairly heavily on open source tools to enable software developers to use their small low power cores.

What struck me about the A9 core is that it comes with built-in support for multi-core configurations of up to four cores on a single System-on-Chip (SOC). One of the concerns I have heard of ARM in the past is the performance of their cores, particularly their earlier versions. Going multi-core makes a lot of sense to help alleviate that without too much of a power overhead. And it opens up a new class of software application that can take advantage of it.

But once again, the spectre of doing multi-threaded development is starting to take hold in another sector of the industry. Are embedded tools ready to handle this? Even more important, are embedded developers ready to handle it. This is a recurring theme in my blogs and I still haven't found the answer.

My gut tells me the best way for programmers to deal with the complexity of multi-threaded development is to introduce a new programming paradigm that simplifies the thought process and puts doing multiple things at the same time as a first class citizen. This is what we did when programs became gigantic and the old functional approach didn't scale. Objects were our saviour.

The era of multi-core brings new challenges and I wonder out loud, is there a better paradigm to help us deal take advantage of all power it brings while allowing C and C++ developers to leverage their skills at embedded development? Is OpenMP the answer? Or does it go far enough as a new paradigm? Something to look into.

Hey-lo, the software industry on center stage

I can't really get too far away from it without talking a little about Halo 3. I'm pretty sure most of you weren't up watching live coverage of the Halo 3 launch last week for 4 1/2 hours on cable TV. My son Alex made sure I did. He was so excited he could hardly stand it. And as if by co-incidence, the next day our new XBOX 360 Elite and our copy of Halo 3 Legendary Edition, ordered from two different sources, arrived with in hours of each other. He was in heaven and we've been a Halo house since.

I was fascinated by it all, and not because of my fascination with Master Chief, whose helmet is on display in our family room (for now). It wasn't partly because I couldn't believe there would be 4 1/2 hours of live TV coverage of a video game launch (what the heck was that), or that people would be lined up for hours on end waiting for a copy when they could probably walk in later that afternoon and get one in 10 minutes.

No, it was because when you tear away the layers of marketing and packaging and 3D models and animation, you had a pretty sophisticated chunk of software. Whether it was coded in C++ or C#, I'm not sure. But it is code and the developers could have easily used the CDT to build it, although I'm pretty sure they used Visual Studio ;).

It's hard to imagine what the programmers at Bungie were thinking that day. When you're busy mucking with class definitions and for loops and trying out everything you can to squeeze out every bit of performance out of your latest algorithm, I'm sure you don't consider that you'd have thousands of people camping out overnight waiting to get a copy. Hell, you're probably sitting there sick that someone will run into some latent bug in that mess you made.

But there is no doubting how cool it is to be in this industry and to see the affects that software has on everyday people's lives. Most of us get into it because we love the challenge of making computers do stuff. But whether you're building the latest block buster video game, or the next generation C/C++ IDE, you are making a difference in the world.

Another CDT Summit in the Books

By the end of the three days, it really hit home why we go through the effort of organizing and traveling to the CDT Fall Contributors Summit. While it got off to a slow start, by the last two days we were busy getting deep technically and on Thursday afternoon even browsing through source code to see how to implement some of the new features. That's something that is pretty hard to do if you don't have 7 or 8 guys huddled around the projector screen. And with the CDT, those 7 or 8 people come from different continents.

Aside from the Debug features I mentioned in my previous post, we got into a few key areas. The team at IBM Toronto are working on new parser frameworks that should make it much easier for the CDT to handle language variants. In CDT 4.0, we released support for Unified Parallel C (UPC) that was built as an extension to a new C99 parser. They are also looking at techniques for making the indexer even faster. I think this will be great for the C environment. I still am worried about how this will scale into the C++ world and the crazy template libraries people create and use.

We also talked a bit about remote development and how we could support it with the CDT. This is the scenario where the source code, build, and debug all happen on monster remote machines while the developer accesses them from a workstation. I think we're still pretty cautious about making sure we don't do too much damage to the CDT architecture to make this happen. But one key feature I think we're all mainly in agreement on is to make sure the CDT works while all file access occurs through the Eclipse File System (EFS). I am also hoping use that to add support for Visual Studio style Add File/Exclude File so that users coming from that environment, which a lot of CDT users do, can continue to manage their projects somewhat independent of the file system.

At the end, it looks like we have a pretty good plan for Ganymede, the newly numbered CDT 5.0. There aren't a lot of big architectural changes like we've had in the past. That will definitely go a long way towards bringing the CDT to a new level of maturity where we have documented and trustworthy APIs and can focus more on quality, cleaning up the Bugzilla backlog and adding more automated tests.

It really felt to me that the CDT has grown up a lot in the last year, and that's a big thanks to our contributor community and the great collection of committers that have been involved with the CDT. Our team has really stabilized and everyone knows each other now and we really do work together well. And, of course, there's always room for more...

CDT Summit Half-way Point

Well, we're half done the CDT summit. We started with some general discussion on CDT project management and planning for Ganymede. We've picked 5.0 for the CDT version number. That comes with the commitment to finally manage our APIs so that the community can rely on them and read documentation about them.

We've had a long discussion on various aspects of debugging. The good news is that the Debug Services Framework that the Device Debugging project is working on will become much more tightly integrated with the CDT. There's been some good work on the GDB/MI integration with DSF and we'll have an interesting decision to make around the February timeframe whether to make this the default gdb integration mechanism for the CDT packages at Eclipse.org.

Another interesting requirement we are hearing a lot is the need to reduce the dependency that Eclipse has on Projects and Resources. Features like project-less debugging are important to users in both embedded and desktop communities. The focus is on the activity, i.e debugging, and less on working with projects and build settings. The debugger drives what files you are working with, not the user. Along with the need to support Visual Studio's ability to add to and remove files from projects without changing the underlying operating system in an easy manner are very important.

So while we really don't have any big new features coming, other than refactoring which we haven't heard to much about yet and the people working on it unfortunately weren't able to make it. We are becoming more focused on making users feel more comfortable with the CDT. And that includes users who are coming from the emacs/vi world as well as other IDEs. That'll be a good challenge.

CDT Summit Eve

Twas the night before the CDT summit and all through the house not a creature was stirring, except for my son waiting for the Halo 3 launch. Luckily I pre-ordered and it'll be arriving by mail so I don't have to stay out all night. Which is good since the CDT summit starts tomorrow and it looks to be three days of hard work while we plan for the next release of the CDT next summer for Ganymede.

Every summit seems to have a different atmosphere and I have no idea how this one will go. We've gone from being desperate for contributions two years ago to a whole pile of features landing at once last year. I think this year will be the search for maturity, at least I hope so. We're five years into it and we still don't have firm (or as my good friend Michael Scharf says, "crisp") APIs. We need to get this right soon or we'll start missing the window where the current mess is acceptable.

We also need to take a good look at everything to do with Debug. Little has changed here in five years either and we're still dealing with a paradigm, while fine for Java developers, is foreign to C/C++ developers. We had a good code camp today with the Device Debug folk and the good news is that we're all feeling the pain and have the desire to do something about it.

We also need to work on other workflows as well that are driving our users mad (and more importantly our customers). The whole IResource system has never worked the way C/C++ users want, especially those who've used other IDEs. All they want is to be able to add files to projects from anywhere and to exclude files under project folders. This is getting to be very high in my list of complaints I've been getting recently. I have some ideas on this and we'll see if they can fly.

It should be a good week, and I think were going to walk out of it with a lot of work items. Interestingly, the toughest ones will require changes in the Eclipse Platform and we know how challenging that can be, and not necessarily for technical reasons...

Take the high road

Just a hint. If you are a key player in a project promoting open source tools for native Windows, stop calling them Microsnot and stop calling the API Woe32. You're really just hurting your project's credibility especially when the tools are in such need of some.

Anyways. Just a knee jerk reaction to watching one of the "real" open source project mailing lists. I hear about the rawness that people on these lists can show but to experience it first hand, really makes me wonder what they are trying to prove. Yeah they are hard core techies and for a lot of these projects that's what's needed to be as good as they are. Maybe I've been in the corporate world too long, but it really turns me off. Especially when I'm worried whether the project will survive and am thinking of helping out. It's certainly something that's not acceptable on the Eclipse mailing lists I peruse.

As much as people bash Microsoft and as much as I love Linux and other alternative platforms (including QNX Neutrino ;), I can't join in the bashing. What's the point? What are you hoping to achieve. Microsoft changed this industry. The vast majority of developers I know are running Windows as their main development platform. That wasn't true 10 years ago when Solaris (or rather SunOS) and Unix in general ruled the shops I worked at. Give Microsoft the credit their due. We all know open source is a better development model for core technologies. We don't need to rub their noses in it.

BTW, I'm sitting outside on a nice 21 degree Celsius evening here in the outskirts of Ottawa enjoying the fire on my deck with my favorite beverage in hand listening to a Trance Internet radio station and surfing the net on my laptop via my wireless router after spending a nice evening with my wife and sons. Life can't better than that for this techno geek who always seeks to take the high road...

Microsoft's everywhere

Someone asked on the MinGW-users mailing list about editors that they could use with the MinGW tools. People do have a few choices and, of course, I offered up Wascana as an option. I'm not sure if Microsoft was really answering the question, though ;)

> Hello...
>  
> I'm thinking in create an editor of C/C++ code
> Integrated to MinGW.
>  

There's also Wascana based on the Eclipse CDT.

    http://wascana.sourceforge.net

Doug.

------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
------------------------------------------------------

Defy all challenges? That's my moto :)

Time for an Eclipse Corp?

I'm not sure why, but Mozilla has been floating around my world a lot in the last few days. First was Ian's conjecture that Eclipse should sometimes be more like Mozilla. That led me to take a look at what the fuss was about where it finally hit me what Mozilla.com was. It's actually a real company that funds development of Firefox with revenue generated by Firefox's search engine integrations. Apparently they get a ton of money, well $50M+ annually, to spend that way.

Now today, I read that Mozilla is going to try out that formula with Thunderbird. Firefox was probably the right thing at the right time. I'm not sure Thurderbird is, although I'm thinking of tossing Yahoo's slow mail, I mean web mail, interface and switching to T-bird for my home mail. Although, I still love Outlook (especially after a couple years of not using Outlook ;) for my work e-mail. But the idea of funding Thunderbird development to improve it's chances in the market is an intriguing idea.

This is something I've been thinking about in the last couple of years that would be good for Eclipse. The Platform versus IDE wars flame up once in a while and the underpinnings of the Eclipse Foundation and the way most Eclipse projects gets staffed really does force the Open Source version of Eclipse to be a platform, and not necessarily the technically best IDE in the market. And, although we don't run up to them much in the C/C++ space, Netbeans is apparently jumping by leaps and bounds and is starting to be recognized as the more user friendly IDE.

So I wonder out loud. Could a not-for-profit Eclipse Corp. fund an independent collection of developers that could focus on making Eclipse both a great IDE and a great Platform while still providing value for the Board members who would most likely need to fund this venture, at least at the beginning? What would the scope of this corporation be? It couldn't fund every Eclipse project since not all Board members get value out of all of the projects. But there may be a logical place to start and grow as more funding became available. Or would this create a poisonous community of have's and have not's. Interesting to wonder about anyway...

SCO loses, innocense already lost

You know a year ago or two or three, SCO filling for bankruptcy would have been a huge headline. Nothing has shaken the open source world more than SCO's lawsuit on IBM for allegedly stealing their intellectual property and putting it into Linux. Open source went from the innocence of sharing to a mine field of hurt over night. Communities like Eclipse understand the balance between commercial and open. Many do not, and SCO certainly did not. Open source was a threat and instead of finding a way to leverage it for their own good, they chose to attack.

But in a mess of technicalities, it ends up they didn't have a leg to stand on in the first place. The apparent good heart of Novell, who apparently actually owns the legs, saved the day. Now we can rest and look forward to golden times. Or can we?

I actually think we got lucky. If SCO had been successful, what would that have meant to corporations contributing to and relying on open source software for their products. We certainly got a glimpse of that world as corporate legal teams maneuvered to protect their corporations' interests. Pretty much all of the legal safety mechanisms in place at Eclipse is there for that reason. It's frustrating at times, but they're there for good reason.

There is still a lot of fear over the use of open source and I don't think SCO filing for Chapter 11 is going to change that. New "villains" are on the horizon. Many will stay on the horizon visible enough to make people think. But I don't think they'll go away.

SCO has changed us forever. And maybe we'll look back and say it was a good thing. But you have to wonder what the world would have been like if everyone embraced open source for the mutual good that it can be. But then, maybe it would still have looked a lot like Eclipse anyway...

Wascana article and a Windows focus

There's a good article on the Every Flavour Beans blog about Wascana. It gives a pretty accurate overview of what I'm trying to achieve and some pretty good suggestions. This is then followed by some screenshots showing what Wascana is all about. I definitely appreciate the exposure and the suggestions.

One of the suggestions which I'm running with is to refocus Wascana back on Windows development. I haven't received much positive feedback on my plan to provide the same environment for Linux and Mac. And I need to honestly evaluate what I can do with the limited time I have available to spend on it. Windows has the most need from both the CDT's perspective and users who want to use the CDT there.

The Linux distros have been doing a great job of including the CDT and necessary library development packages that I don't think we need extra help for that, other than to test it out and make sure these packages work. And I would really need to spend time on a Mac to understand what's needed there, but that isn't going to happen any time soon. We can always revisit these platforms if people step up and want to help get Wascana working there.

This should also give me a chance to get deeper into the MinGW toolchain. It's screaming for a 4.x gcc and a debugger that can understand both Windows and GCC world. I'm not sure how I can help there yet but I should spend some time figuring that out. But given the feedback that I'm getting on Wascana, we are heading down the right path with it.

High tech isn't always the answer

I have two sons, one of whom, Alex, is Autistic. That presents its own challenges in our life but my wife and I are getting to be seasoned veterans in that battle now that he's 14, and our "typical" 13 year old son is getting that teenager attitude which is a whole ball of wax on it's own.

At any rate, Alex has an obsession with a few things like most Autistic kids do and I appreciate most of them. Two of them are video games and Star Wars. And, of course, that means we have pretty much every Star Wars video game that's out there. The latest addition was one he found on eBay Canada called Star Wars Dark Forces. I wasn't sure what it was, but given the $6.95 price, I was sure it was pretty old. But it was cheap enough, so I ordered it for him.

Well, when it arrived I looked at the CD and found it was copyright 1994. Will this thing even work on our XP box at home? Well after I found and installed a Sound Blaster emulator, it runs like a charm. And you know what? He loves it! It looks like DOOM II and probably uses the same engine from id Software. It's pretty well done for 1994 but cheesy as all hell.

But I felt a lesson in all this. We often work hard in the software industry to pile features into our boxes and provide the latest bleeding edge of technology. But we often lose site of what this hole industry is about. It's about the people who use this stuff. If they're not happy with the end product, they we just wasted a lot of our time and money. And probably a lot of theirs.

And I guess that's what's led me in the last little while with the CDT. I don't work on the indexer much any more. I'm glad that we have a few other guys looking at it. And that's given me more time to focus on cleaning up the user experience. Because, no matter how fancy our stuff is under the hood, if people feel that the CDT is too hard to use, they won't even get far enough to try out the fancy stuff. And sometimes, at least in my house, 1994 technology is plenty fancy enough :).

A new era for QNX

So how to you take a great technology and bring it to a wider audience? For those of us working on open source projects, we know what to do. You create a community for it. And that's what QNX is doing starting today with the introduction of the Foundry27 portal.

Now lets get something straight from the start. This isn't open source. We've taken great pains to make sure we didn't mislead anyone into thinking that it is (unfortunately some members of the press haven't). But it does give everyone access to the source code and to the developers via forums. And, as long as you are using it for non-commercial use, you have free access to the tools and the SDK to play with it. We are even working on ways for people to contribute any of their cool work through the portal to others that may be interested. But, commercial users still have to pay for development seats and run-time royalties.

The idea is really to lower the barriers that people feel when they approach commercial software. Cut through the sales people and lawyers and just let me play with your stuff to see if I like it. This is something that many companies, even Microsoft, are trying to do to woo developers. QNX is going pretty far though by giving a public face to its staff, which is a pretty major culture change that I remember going through when I started working on the CDT. But we're intent on making sure developers get what they need and feel comfortable in this new community.

As with all communities, this one will need to be nurtured and it'll take a bit of time to work out some of the kinks just a Eclipse did in the early days. But we have learned from that experience and there is a lot more software out there to support something like this. But the focus really is on people as it should be with communities and this is a much friendler face on some really good technology.

Hibachi, a lesson in diversity

I've always been interested in Ada. Unfortunately, I've never had the opportunity to work on a project that required me to use it. But from studying it over the years, I can immediately appreciate it's strong type system, inherent support for multi-tasking, and focus on helping the programmer write quality systems. I can think of many projects that would benefit from Ada, especially in the safety critical embedded systems arena.

As part of my vision for the CDT (or dream, I guess) has always been to support multiple programming languages and Ada was one I wanted to see. But with a lot of ideas I have for the CDT, I neither had the time or real community support for it. So when Tom Grosman from Aonix approached me proposing they contribute their ADT code to Eclipse, I jumped at the chance to help.

And I'm glad I did. The Hibachi project is the result of Tom's work and is nearing it's creation review. I have been trilled at how Tom had gone about talking to his competitors and other vendors and interested parties and built up a strong community, even before it got started. They have a firm plan that immediately focuses on meeting objectives that would enable all vendors to get value out of Hibachi. This will then promote additional contributions to make Hibachi the best Ada IDE in the business. I can't wait to see them in action.

There are a lot of things at play here that is a trend I've seen with successful Eclipse projects. In many ways the forces are there to make it happen. Customers are demanding high quality IDEs based on Eclipse, the free community would love to see Eclipse support for their favorite tools, vendors would love to provide it all but to do a good job of it, they really need to work together and share the burden. If you can harness all this energy and make your project a friendly place to participate, then I think you have the clear formula for success.

Eclipse vs VS on Slashdot

A pointer to an article comparing Visual Studio and Eclipse has been posted to Slashdot. The article isn't really strong, but I am finding a ton of value reading the comments on Slashdot. The people there make a lot of good points and there is even some discussion on the CDT.

It's interesting to see that the number of pro-Eclipse versus pro-VS comments is pretty even. One thing that I did pick up from it for Eclipse, other than a bunch of usability concerns, is that if we truely want to be compared to VS, Eclipse really needs to support .Net development. That and we really need a GUI builder. I wish I had more time to take a look at NAB and see if we can use it more generally as the NAB team suggests.

Wascana Back to School Special

Tuesday is the first day of school here in Ottawa. Other places have already started but it does make more sense to start right after the labour day weekend instead of a day or two before it.

This has co-incided with a marked increase in the downloads of my previous CDT for Windows release (now numbering over 800). So it hit me that if I want students to use the new rebranded version of Wascana I'd better get it out now. And interestingly enough one of the people on the forums is an instructor who has chosen to use Wascana over VS Express (thanks!).

So I took a couple of hours out of my weekend and put together Wascana, MinGW Edition 0.9.3. You can download it from the Wascana web site. It includes the 3.4.5 MinGW gcc and all the current MinGW and MSYS packages. It includes the SDL and now the wxWidget libraries so you can build multi-platform applications. Stay tuned for tutorials on using these libraries with Wascana, and hopefully some project templates that set things up for you.

Does "Eclipse Europa Needs Some Polishing"?

I ran across this review of Eclipse Europa on eWeek that came out yesterday. It confirms almost every concern and hope that I had for the Europa C/C++ package that people have been downloading in droves from eclipse.org. And it was really interesting that this guy is a former Windows C++ developer who is very familiar with Visual Studio who is now doing Mobile development, the exact scenario that we see a lot of and is the biggest growth area for Eclipse on the C/C++ side.

The first thing that hit me was his summary: "Eclipse Europa is a solid IDE, but it could use more refined packaging for the Windows platform". If you're a regular reader of my blog, what more can I say.

The sore points that he ran into really home for me. His biggest complaint was the install. He had expected the C/C++ IDE package to include the gcc compiler. There are still way too many steps to getting this package to be useful for C++ developers. "Nothing leaves a more sour taste in a Windows user's mouth than an application not working properly, or requiring additional manual configurations, after clicking finish on the installation wizard's final panel."

He also had trouble dealing with the Eclipse workspace paradigm. Visual Studio is much more flexible about what files are included/excluded from a project. This is an area we really need to deal with to make these guys comfortable.

He had some good things to say too, though, and he really showed why I think Eclipse will be attractive to Windows developers once we clean things up. The CVS integration is unbeatable. He loved the CDT editor and navigation features including CDT's new Call Hierarchy view. It's these features that really bring the CDT into the mainstream.

One thing to notice, though, is that the title of the article seems to address all of Europa, at least that's what readers will see first. That's why we really need to be careful when we present Eclipse as an IDE. It isn't an IDE accross the board (not to open that debate again). But users see the word IDE and have pretty high expectations. And when it falls short, it looks bad on everyone.

The Need for Diversity

I'm in shock. Amongst other emotions that I'm still trying to figure out.

I came into work this morning and checked my e-mail to find that Danny Smith from the MinGW project had sent an e-mail "Bye" to the mingw users and developers mailing list. Bye? What do you mean bye?! Just as I was getting excited about the future of MinGW with it's spanking new modern compiler, the only guy working on it has quit. I don't know what to think. Is it a bad joke? Has someone broke into his e-mail account and sent the message. The responses from the other MinGW developers leads me to believe not as they politely wished him well in his future endeavors as well as expressing their fear for the future of the project.

And fear we should. I was always concerned over the lack of progress with the MinGW compilers. The seemed stuck on 3.4.2 as the official release for a long time (and now, probably even longer). Danny had come to the rescue and offered hope that the wait was over and we'd soon be able to enjoy all the great improvements to gcc in recent years. But now it appears someone else will need to take on this challenge. And it appears to be a big challenge as there were a number of bug reports flowing in (one of which was mine) and I was getting worried that Danny would get overwhelmed.

The timing of this is interesting, especially after my blog entry yesterday. But I've also been in a number of discussions in Eclipse lately over the need for diversity for projects to succeed. If contributors to a project all come from one company, what happens to that project when the company needs those resources elsewhere. The CDT was able to survive such an incident because we had contributors from many organizations who stepped up to fill in the holes (and I still can't thank them enough :). But there are projects at Eclipse who haven't worked hard enough to make sure they diversify like this and it is something to worry about if you rely on such projects.

And that's the position I find myself in. I was relying on MinGW's 4.2 compiler to make Wascana a super appealing environment for Windows development, even for commercial use. Now, I'm not sure what I'll do. Maybe it's time to apply some focus again on the Windows SDK compiler and debugger integrations. Although, unless by some miracle Microsoft let's me redistribute their SDK, it violates Wascana's primary mission as a simple to install complete IDE. And I doubt I would have ample time to contribute to MinGW and I don't really have the expertise anyway. And I have QNX work piling up. And CDT stuff to prepare for. Like I said, I'm still trying to figure this whole thing out...

The True Meaning of Wascana

While the progress on Wascana has been slower than I may have liked, it is progressing. And I've been very pleased with the positive feedback I've received on it. Almost everyone I've heard from says it's the right solution at the right time. A complete CDT IDE is hard for people to set up themselves, especially for noobs, and that is Wascana's primary mission in life, to make this easier.

But there is another reason for Wascana, and one I use to justify spending some of my work time on it. I've often seen marketing staff from various vendors promote their Eclipse-based tools as, well, Eclipse-based tools. Now in the Java space, that definitely means something. But in the embedded world, it doesn't have the same punch. It's almost like customers are saying "yeah, so?".

This has been the main driver behind my work on improving the CDT for the "grassroots" segment of our industry. These are the guys just getting into programming, or are doing it as a hobby, or people working in a start-up. People who don't have a lot of money to spend on expensive tooling but who would benefit from a good free IDE. And while there are good IDEs out there for free, there is so much more upside to Eclipse.

But I had reached a road block in my pursuit of supporting the grassroots. We had reached the point that their biggest hurdle was setting up the CDT with a good compiler and debugger and set of run-time libraries. This is the stuff that Microsoft's Visual C++ has always been good at. And if you look around, thanks mainly to the growth of Linux, there is getting to be a pretty good set of open source tools and libraries.

And I guess that's why the time is right for Wascana. I think we can build a pretty good free open source IDE from all this, and the feedback I've received is that it will be very popular. And if that becomes true, then commercial products based on Eclipse will benefit from the extra visibility and the investment will have be worth it. So while I've had to pursue Wascana out on SourceForge due to licensing and IP requirements on Eclipse projects, I consider Wascana to be an important part of the CDT, both for the desktop developers who want a good open source IDE based on it, and for commercial vendors who want their CDT-based IDEs to be successful.

Too clever for me...

Brian Kernighan, of Kernighan and Richie fame, or K&R (if you did't know, Richie created the C language and Kernighan helped him right the book on it). At any rate, Brian has this famous quote which I can't seem to find the root source but I found it quoted many times:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

And that perfectly explains my frustration in the last couple of weeks trying to understand two very clever code bases. Not only is debugging twice as hard, but being a new guy trying to understand the code is at least twice as hard. Hmm, maybe here's a new quote for people:

"Learning code is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, the only one who'll be able to understand it."

Unless the person learning the code is twice as smart as you. Or something... At any rate, I'm not twice as smart as most people so I get to struggle trying to figure this stuff out.

BTW, as I was searching around for the source of the Brian's quote, I ran across this interesting interview with him that gives a glimpse of the human side of Unix and C as they were created at Bell Labs many years ago now.

Lunar Eclipse filling my Inbox

Hey gang, there's a lunar eclipse Tuesday beginning at 3:51 CDT. I personally can't wait until it's over so that my google alert on "eclipse cdt" can stop reporting this thing...

From Old to New

I was hunting and pecking around looking to see what is happening in the industry as I do probably too regularly (I really got to get some code done...). At any rate, I ran across some slide shows that ZDNet were showing on old computers. I still remember the buzz and excitement us young geeks had as computers hit our neighbourhood streets. I don't think I'll ever see something like it again.

Anyway, one of the pictures was of the first computer I ever typed a program into. It was an HP-85 (click here for the real site that ZDNet borrows the pictures from) that my best friend's dad used at his work for the Fisheries Department at Government of Manitoba office in town. And it was where it all started for me and it was cool to see the picture. Yeah the thing had a tiny screen and a proprietary CPU, but it did speak BASIC and I remember being excited trying to figure it out.

Of course that is contrast to the latest computer, or at least processor, that caught my eye, Tilera's TILE64, a monster 64-core machine organized as a System-on-Chip (SoC, peripheral interfaces included). It especially sparked my interest because of the market it's trying to address, embedded systems for video and advanced networking. Intel can go on about their server and desktop monster multi-core machines, but there is a real need in the embedded space for this technology too. I can imagine some pretty wicked things that embedded devices could do with automation and robotics and such with this kind of horse power.

But as with all monster multi-core machines coming out, I still think we need a better way to program them so that we don't get lost in the complexity of getting our programs to do multiple things at exactly the same time. Hell, I spent a good part of the last couple of days solving a deadlock issue in the CDT, and that was just two threads colliding...

A lesson in scalability

I just read the Skype blog where a Skypian describes (well glossed over, but we get the gist) what happened with their two day outage last week. I don't use Skype very much but I know a few people that use it for their work and were at least inconvenienced by it. I read the report with somewhat the same reasoning that one watches Nascar, to see the big wreck and find out how it happened. But reading these things helps you think about how you could avoid such wrecks in your day job, so it's useful reading.

The story goes that 30 million computers around the world running Skype all downloaded a Windows Update and did a restart, all at the same time. I always wondered how Microsoft's servers could keep up with that, but I guess they did very well. But when those 30 million Skype users all tried to log into Skype after their restart all at the same time, bad things started to happen and everyone got booted off the system.

Now, being a software professional, it's not clear to me how this outage could last two days. Normally, you get a timeout if the server is busy and after some amount of time you retry. You'd think there would be a variability in the timeout so that everyone doesn't retry all at once, but maybe that was the flaw they found.

But the lesson of the day is to always consider the "impossible" since sooner or later, it may not be impossible. We run into that with the CDT. We find users who take the CDT and import any old project they may have and expect the CDT's parsers to find everything. In a lot of cases, we're fine, but we definitely don't take into consideration all possible scenarios. And I think that will be the next phase of CDT's lifecycle, to reach that maturity where our feature set does work on more and more projects and we can have more and more happy users added to our community. Openning our minds to the impossible will help us get there.

Just when you needed a Boost

I've been aware of the Boost C++ library for quite a while, but in the context I had to deal with it, it was painful. The Boost library is a collection of C++ templates intended as a trial ground for additions to the Standard Template Library that is part of the C++ standard. Some of them according to Bjarne, have made it into the next standard C++0x. But they stretch C++ templates to the limits, and as such, stretched the CDT's C++ parser to it's limits and broke it. In the early days of the CDT, we eventually just skipped it.

But lately, Markus on the CDT team has been testing his indexer work with Boost, and I've had a number of requests from people to include it in Wascana. So I decided to take a fresh new look at it.

Now I was expecting some simple container templates and utilities and such. And there were things that are much needed like a threads package for multi-threading your app and a regular expression utility class.

But I was amazed at some of the big constructs they have there. The first thing I ran into is a complete lexer/parser subsystem including a preprocessor. With that, it wouldn't take to long to build parsers in C++, and maybe even a C++ parser.

As well, there is a Statechart engine. This is something I've dealt with a lot in my past and it was cool to see a solution that involved templates and States as objects and some of the neat tricks it used to implement action code. Whether it scales to real size state machines, I'd have to dig deeper to see.

I've always been amazed at how powerful C++ templates can be and how the compilers can take all this template code and specializations and such and optimize it down to some pretty efficient code that you probably would have written by hand. But with templates, you work at a higher level of abstraction, meaning higher productivity. Boost gives you some pretty powerful abstractions. We'll see how easy they are to use in practice.

Debugging the Debugger

I've been trying out MinGW's new 4.2.1 gcc compilers. As I mentioned previously, they're experimental. But I've gotten really good feedback from people that moving to 4.2.1 is a great move and will help make MinGW a serious choice for developers.

They actually have two variants of gcc that they're working on. One of them supports exception handling based on the debug information gathered using the DWARF standard. It's apparently much more efficient than the default one based on setjmp/longjmp. I'm not sure what that all means, but my take is that the dwarf version is better.

At any rate, I had a problem using the dwarf version that I didn't have using the default (sjlj) version. If I specify the path to a file using Windows traditional back slashes, e.g. ..\main.cpp, gdb got confused and I couldn't set a breakpoint on a line. And, unfortunately, CDT's builder builds files this way and I my breakpoints failed to get set.

So, I downloaded the source to MinGW's gdb, configure and built it and set up a debug session, all within the CDT (this worked since configure generates forward slashes). I was able to set breakpoints, look at the dwarf symbol data that gdb was trying to use and found where the line number info was missing. And with that information, I was able to generate a hopefully helpful bug report that the MinGW developers can take, or if I find the time, I can try out different solutions. The only trouble I had was making sure which gdb was which :).

At any rate, this brought home again why I love using IDEs for development (which gave me a great intro for an article I'm writing). The productivity of using a debug environment that provides point and click visualization of debug information has to be at least ten-fold over using command line debuggers, and maybe a hundred-fold over using printfs. Once you start using it, you'll never go back.

The Master Speaks, Bjarne's vision of the future

I'm not sure whether you'd call him a Jedi master, or a Dark Lord. I guess that depends on your opinion of C++. To me, I've always affectionately called him Barney (which I'm sure he'd hate), and, of course, I treasure my copy of "The C++ Programming Language", the "Barney Book".

Bjarne Stroustrup, the inventor of C++, recently gave a rare public talk at the University of Waterloo, Canada's top university for computer science. The topic of the talk is the new version of C++ called currently C++0x (he mentions that if it slides into 2010, they may just call it C++0xa, and yes he has a pretty good sense of humour). But he also talked a lot about the past and present of C++. You can download the talk here but be warned it's huge and you may want to use the bittorent.

I'm a long term fan of C++ since I used it for my grad studies work back in 1989. It was a no brainer to me that it became so popular. Bjarne was able to bring object-oriented constructs and generics to C programmers without compromising on performance. And C++0x has performance square in it sites as it works to clean up some of the complexities of the language and bring new concepts that desperately need standardization like threads.

He also had some great examples why performance is criticial, even in today's world of fast computers with lots of memory. Embedded systems have always had performance as high priority, and in the world of mobile, high performance also means using less power, which makes power consumption a performance issue. Also, if your application uses less memory and is faster, that leaves more resources available to add more functionality and making the system even more useful.

So while the world still seems to be jumping on the Java/C# or Ruby/PHP/Python bandwagons, C++ still and always will have it's place. 3 million C++ programs can't be all that wrong...

Can we help these guys be successful?

I received a Google alert pointing at from this developer who is making the transition from Windows to Linux. Obviously, to do so, he has to drop Visual Studio as his IDE of choice and has picked Eclipse and the CDT for his Linux work. Despite some of the difficulties in setting up the CDT, he picked it as "rivaling Linux's best IDEs".

This transition was one of the scenarios we thought about in the early days of the CDT that would make the CDT successful for desktop development. But it is really only recently that I am starting to see this become more and more common. I think Ubuntu was desktop Linux's tipping point. And as Linux becomes more popular there, as the momentum in the press seems to be showing, I think there will be more and more developers looking at Linux when building their applications. And the CDT, technically, is positioned well here.

But the one thing that made me disappointed with the gentleman's post was the frustration he had setting up the CDT to work properly for him. And, you know, this frustrates me as much as it does these people. We've made long strides at improving the CDT, especially in this area, but it appears the message isn't getting out, and maybe we missed something.

And to be honest, the people that are getting the CDT from Eclipse directly and trying to make it work like this aren't getting the support they need to be truly successful with the CDT. If you get your CDT from a commercial vendor, then you have a much better chance since the vendors generally make sure the environments work properly for their customers (we do our best at QNX to do so for our customers). But the committers working on the CDT are kept very busy by their employers, as they should, and that is making it very difficult to get a focused effort to make the CDT truly work well out of the "open source" box.

And this comes back to the Platform versus IDE debate. The CDT at Eclipse.org is a Platform. It's not an IDE. It misses several components that make it a true IDE. Support for people trying to use it as an IDE is probably the biggest one missing. I'm trying to do something about it in open source with the Wascana project, but sometimes I get the feeling that I'm fighting a losing battle. And without success on the desktop, I don't think the CDT can truly be Uber.

Or maybe I'm just feeling down since my holidays are over and I have a ton of work piled up...

MinGW gcc 4.2.1 now available

Danny Smith from the MinGW project has posted his work on porting gcc-4 to the MinGW platform. From the mingw-user mailing list, it looks like a lot of people were waiting patiently for it. One thing I've learned in my days working in open source, it really makes you mad when someone complains that a release or some feature isn't ready yet. But, I know I'm glad it's finally here, even if it is currently experimental (with the target of 4.3 being the official version).

So what's the big deal with gcc-4 versus gcc-3? The biggest thing is a new optimization framework which promises to be able to generate faster code even accross functions. This is an area where commercial compilers excel. And gcc-4 brings MinGW into the mainstream being releases only days after the official 4.2.1.

The other interesting thing is that the port also supports OpenMP, a standard API and language extensions to support parallel programming. I know the PTP people will be very interested in that. Also, there is support for Objective-C++, which we've had numerous requests to support with the CDT.

I've started updating the Wascana installer to include this new compiler and a couple of other updates it requires. Tune into the web site to find out when 0.9.3 will arrive (with all it's fancy new branding too :)

Man, I could use a paint shop plug-in

So I'm stealing away a couple of hours here and there on my second set of holidays to work on Wascana. One of the things I've done is created a logo. You can see it on the home page. It's pretty simple, an orange moon to represent a lunar eclipse, and a blue 'W' for Wascana. I made it using Paint.Net, a photo editor written in C# (for some reason...). But it was pretty handy since it supported layers and let me draw simple shapes like the circle and text.

The next phase of the exercise was to then use the logo to create images for the icons and bitmaps in Eclipse. I wasn't too happy with how Paint.Net scaled the images and I wanted more control over the properties of the circle and text. I tried a number of different programs, an old version of Paint Shop Pro (when it was still owned Jasc) and GIMP for Windows. Neither did what I wanted.

But that got me thinking. Why isn't there a plug-in for Eclipse which does this. I am making bitmaps for my .product file. Eclipse is for everything and nothing in particular, why not image editing? (And this plays into one of my dreams for Eclipse - and why not take to the next level and do 3D model editing too, both needed for game development - but I digress.) Does anyone know of any activity in that area?

Eclipse CDT, More than Just for Writing Code

I think I've gotten more Google Alerts about "Eclipse CDT" in the last couple of weeks than I ever have. It's a great sign that people want to talk about their experiences, good or bad.

The latest one I got was from something called the "Reality Factory 2 Development Weblog". The author had struggled with the performance of CDT's content assist in Callisto, and I understand why. In Callisto it did a full parse including all the header files included by the file in the editor, which for C++ with lots of templates and stuff, it took quite a while. In Europa, one of the features my intern worked on over the winter was to migrate this to use the index for the contents of the header files. It's way faster, and the author was very happy to see it.

It's also interesting to see the comparisons with Visual Studio. The author states that in many cases, Eclipse and the CDT are actually faster than VS and he's switched back to Eclipse. That's cool to hear. It's been a while since I used Visual Studio regularly but it's looking like we're reaching one of the bars we set for ourselves of being as good as VS (being as good as JDT is the other one, BTW). This makes me believe even more that Wascana is important as a path for VS users who want to switch to Eclipse with all the components they'd expect of an IDE. This is definitely one of the main growth areas for the CDT I see in the coming years.

And the author of the blog entry really brought home why that's true. It's not just Eclipse and CDT's support for writing code. It's all the other plug-ins available to developers to help them in all areas of software development, including managing bugs with Mylin and source code repositories with Subversive. Even the built-in web browser gets kudos for helping out. Taking a look at the big picture of the Eclipse ecosystem, you really do get a sense of the value proposition of Eclipse. Embedded and enterprise developers get it, and we just need a vehicle to get that to the desktop developer too.

Using Eclipse CDT for MySQL C Development

I got a pointer to this blog entry in my Google Alerts this morning. It's an article on how to write a C application that talks to a MySQL database. And it's done using the CDT. Very cool!

This is exactly the kind of article we need more of, showing the CDT in action solving real world problems. The CDT can be used for anything but a lot of people still don't know that yet.

Baby's first "Hello, World!"

(Warning! Major geekness in this one :)

My youngest son is 13 now and his report card looks a lot like mine did. Good in math and science, sucks at literature. He's pretty much a twin, although he's way more interested in sports than I was at that age. And looking back, I guess I was about that age when I started getting interested in programming. My best friend's dad had an HP "portable" computer he used at work and we used to fool around on it trying to make it do stuff.

It was a pretty exciting time back then in the late 70's as home computers were born. TRS-80's came into existence and were the first machines I wrote for, or at least typed my first programs into while hanging out at the local Radio Shack (and, yes, that was in Regina, too). There was no way my family could afford one. And taking a look around my house now with three laptops and two desktops for four people, my kids are way spoiled!

So, I was at the book store the other day, looking to see what people were writing books about (in case the urge to write one ever overcomes my wife's objections :), I saw a copy of "Game Programming for Teens". It looked simple enough for a 13 year old to pick up and it uses a version of BASIC, just like I did when I started. And it's about making games, which he has expressed interest in, so I picked it up. Yesterday, he typed in his first program, the same program everyone types in when learning a new language. The eternal "Hello, World!". I was a proud papa, in the geekiest way a dad could be I guess. And I can tell by his enthusiastic "This stuff is confusing (meaning complicated), but I get it!", he's started down that same path that I did.

But what makes me a little upset, though, is that there isn't such a book to get kids started using Eclipse. The BlitzBasic demo that came with the book is one ugly IDE. I showed my son the CDT and it looks way more impressive. This is one reason I'd like to see Wascana become the IDE of choice for desktop hobbyists, and why I focus so much on supporting the grassroots of our industry with the CDT. If we can get people using Eclipse early in their careers, then it should be a much easier sell when those people come shopping for our products that are built on Eclipse. At least that's the dream, but I fear we still have a long way to go before making that a reality.

Introducing ... Wascana Desktop Developer

As I reported earlier, I have to change the name of "CDT for Windows" to something else. While doing so, I want to try address a big sector that I think we've kept trying but kept missing, and that's the C/C++ desktop application developer.

So here it is, the Wascana Desktop Developer, or simply Wascana. What's a Wascana? Well, since I was in Regina and I had some people comment on my last blog entry to name it after Regina, I did. Wascana is the Cree word for "Pile O' Bones", and was the original name for Regina. The beautiful park and lake in the center of Regina is called Wascana Park. They just finished a cool redevelopment project of the lake, which was an impressive engineering achievement on a tight budget. And this distribution really is a pile of bones, a collection of open source components that we're bringing together to make a skeleton that desktop application developers can dress up. Or something like that :).

I originally planned on addressing the needs of the Windows developer, but, given the strenghts of CDT at cross platform development, I'd like to expand this to cover all desktop operating systems, including Linux and Mac OS X. And I'd like to provide a set of open source cross-platform libraries that support a variety of desktop applications. The wxWidgets library is a natural. I'd also like to support the hobbyist game developer, one of probably the most interesting area of desktop development. Something like Ogre and SDL would fit that bill.

I am also making my Microsoft C++ compiler and Windows debugger support a part of this project to try and get more interest (i.e. help) with it. I've been disappointed in the progress of MinGW, e.g., there's still no gcc 4 port. And gdb is still gdb and has a lot of issues on Windows. So I think MSVC support needs to be there to for Wascana to make any serious inroads on Windows.

Linux will be interesting. Ideally, we'd like to leverage the tools and libraries as they come with the distributions. We'll need to make sure we get the right versions lined up, maybe with some super packages or something. We'll have to see.

And as for Mac, well I'll need help with that but I know there are a lot of Mac developers using the CDT.

BTW, I've renamed the CDT for Windows project at SourceForge and unfortunately, the didn't forward the old name to the new name so I apologize for the confusion and hope you can find us at http://wascana.sourceforge.net.

What's in a Name?

Well, I've been in this business long enough to realize that naming a product is tricky business. I had fears that calling the distribution of the CDT, tools and libraries for Windows, "CDT for Windows", that I'd get a letter from Microsoft one day telling me not to use the word Windows. Well, what I got first was a letter from Eclipse about the word CDT. As per Eclipse's new Trademark Usage Guidelines, CDT is a trademark of the Eclipse Foundation, and using it in the product name "CDT for Windows" is a violation. (Even though it is open source, you can still consider it a product, I guess).

Now no one get upset. I have a great relationship with the Foundation staff, and I can clearly see the need to protect the CDT brand. It wouldn't take much to clone the CDT and make some tweaks and still call it MyCDT (which has been done, BTW), and if not done well, could do harm to the work we've done at building up that brand. So while, I'm disappointed about the prospect of losing the most natural name for the CDT for Windows distribution (which took me about 5 minutes to come up with), I will comply.

The name change also triggers something else that has crossed my mind as I received feedback and looked at the state of the CDT. We are sorely lacking in contributions from the desktop developer space. Despite this, there is a huge contingent of CDT users that are using it for that purpose. And as the need for cross platform development tools grows with the growth of Mac and desktop Linux, we really need to start addressing that shortfall.

So to help with both problems, I would like to shift the focus of the CDT for Windows distribution, more towards CDT for Desktop Development and open the door to building a complete IDE that targets all desktop operating systems. If I can grow a community around that, and maybe even attract commercial interest, then hopefully we can close the loop and build momentum into that potentially lucrative space.

But first, I need a name for such a project that keeps all the lawyers happy...

BTW, at the moment, I'm visiting my birth place of Regina, Saskatchewan in the heart of the Canadian prairies. I didn't realize how beautiful a place it can be, at least in the summer :). If you ever get a chance, it's an interesting place to visit.

SourceForge vs. Eclipse

As you may know, I've started up an open source Eclipse distribution called CDT for Windows out on SourceForge. (If you haven't, feel free to take a look ;). My top objective for this distribution is to help out people who have Windows machines and who want to try out using Eclipse for C/C++ development. We've received numerous complaints and bug reports from people who've tried to make something like this on their own. And so far the reception for this distribution has been warm and I'm pretty happy with it and excited about its future.

One thing that is bothering me, though, is that I can't release something like this from Eclipse itself. Mind you now, I didn't really try, but I think the feedback I got when I talked about it was that there was no way the Eclipse Board would allow the tools and libraries that are GPL and LGPL licensed and with uncertain pedigree to be released from an Eclipse server. And I am the first one to stand up and promote why these legal requirements are important to ensure the pedigree of products that would like to redistribute Eclipse. But, I wouldn't begin to expect vendors to redistribute CDT for Windows. So why does this still bother me?

I guess it comes back to the reason why I'm doing CDT for Windows in the first place. I'm trying to grow the CDT community into the Windows development space. If you've heard me speak, you know I've been trying to do this for years. Visual Studio obviously rules there, but I think Eclipse has a lot to offer Windows developers. And there are lots of them. If we can grow the CDT community there and make them happy, this should help the CDT. And having a good base of CDT users should also make developer products that target for other platforms, like the one from my employer ;), more attractive, making the Eclipse membership happy too.

So, I'm doing this for the benefit of Eclipse. But I can't do it at Eclipse. And the irony isn't lost on me. But at the same time, I'm really enjoying the freedom I'm having doing this at SourceForge. It may come around and bite me in the behind at some point. But for now, CDT for Windows users can benefit from it even if does come from SourceForge, which is where many of the packages I'm distributing are coming from anyway...