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!
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 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.
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.
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.
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.
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…
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 🙂
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.
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.