IDE in the Cloud

There's been a lot of talk at EclipseCon here about the "IDE in the Cloud". I missed it but apparently the Mozilla Bespin demo at the e4 talk was quite impressive. It is easy to set up, and it's pretty fast as a code editor. I guess that makes sense since browsers have been heavily optimized for fast display of textual and graphical content. So I have to admit, it's led me to reconsider this technology. Rational tried this many years ago, remember Catapulse?, to build hosted development environments. The idea, and the company, collapsed in the high-tech bust of 2001. Maybe they were just too early.

But as we start to rely on the cloud, what happens when the sky's are clear? I just heard Kevin McGuire say that, hey, my e-mail is on the server, why shouldn't my code be there too. I use Outlook and Thunderbird in a mode that downloads my e-mail to my machine so I can access it disconnected. I don't always have access to the cloud. Until the cloud is omni-present, through things like metropolitan wireless schemes, and cheep, $10/day at my hotel wasn't cheep, then I don't see it really taking off as the typical way you do software development.

I just worry that the whole "Cloud" paradigm is being pushed by the people that can profit most from it, not from an inherit need of potential users.

CDT Code Introspection APIs

I'm just sitting in Markus's talk on the APIs the CDT provides to create code models, ASTs, the Indexer and ways of getting information out of there. These facilities are used to implement features such as content assist and open declaration and searching, etc. And you can use it too for all your static analysis needs. A copy of his presentation is available from the EclipseCon site by following the link to gPublication. It's a great reference on how to get started.

http://www.eclipsecon.org/2009/sessions?id=685

Slides from my Talk on the CDT Community

I'm not sure why the EclipseCon submission system isn't accepting this but here are the slides from my talk on the Rise and Fall and Rise of the CDT, Lessons on Building Communities. I had a lot of fun creating and presenting this talk. I guess it's a passion of mine and people seemed to like it. The slides have few words on it and I'd be happy to give more details if you have any questions. Feel free to add comments here.

Rise and Fall and Rise of CDT

View more presentations from dschaefer1.

A Great EclipseCon Already

I've been here at EclipseCon for 48 hours and it's been great already. I've met a lot of people here, like I always do, and it's a good sign that vendors still see Eclipse as important, enough to spend the money in these tough times to send their technical experts.

EclipseCon is an important conference, especially for those who are looking to get started with Eclipse and to grow their expertise. There's probably not enough time to learn it all, but at least you know where to go look when you get home.

It's also important for projects to get the word out about the great work their doing and to grow their community. I was pretty disappointed about the number of submissions I had for the C/C++ category. But we're making due. And it's good to see the number of DSDP contributors here giving talks so we're still showing the world that Eclipse is more than just a Java IDE.

Other things to report:
- work on ObjectiveC is starting and the guys managed to get a prototype running based on CDT late last night.
- the Ada project is looking to reboot.
- e4 talks are the hottest ticket in town
- adding git continues to be controversial and we really need to get a bigger ground swell of contributors who care about making this happen

Anyway, beer time. More later.

POWERVR goes MP

I was just reading up on the news that Imagination Technologies has launched a new generation of their architecture that drives POWERVR. What's POWERVR, you ask? It's a good question, but chances are, if you have a mobile device that has 3D accelerated graphics, it's driven by this hugely popular silicon IP.

The big news is that even they're going multi-core to achieve scalable graphics. They claim they rival the performance of discrete graphics chipsets, which I assume means the nVidias and ATI's of the world. That's a pretty interesting combination when you look at the latest chips that have multi-core ARM processors combined with DSPs (digital signal processors) for audio/video processing, which can then be combined with these powerful 3D cores.

I can imagine some really powerful handheld and other mobile devices based on these things. I just wonder about power consumption, the eternal challenge for mobile developers. We'll see how that plays out, but the power of these things also blurs the gap between mobile and x86 based "netbooks" and even set-top boxen. Interesting times ahead, indeed.

But as good as the hardware is, you still need the software to make them come to life. It's going to be an exciting time for developers that target this market. I just wonder if there are enough of them. This is one area where I'm hoping the Eclipse DSDP and CDT projects can help. We need an easy to setup package to give the students and hobbyists, the future commercial developers for these platforms, the tools they need to get them started. This is something I'd be happy to talk about at EclipseCon and see if we can get a community to start putting this together.

Should Wascana get Qt?

I've been working on my EclipseCon talk and tutorial, which I'm really looking forward to now. Especially the talk where I hope to share some of the things I learned being involved with the CDT project for almost seven years now. And I'm hopeful it's useful to others working in open source, especially the things that didn't work as well as I hoped...

Anyway, while doing that, I've started playing with Qt, which was recently released with LGPL as one of the choices for licensing. That eliminates one of the hurdles I have for including it into Wascana, my CDT for Windows distribution. So now the question is, should I include it? Should I also keep wxWidgets? Since the Wascana plan is to become a p2-based distribution, there should be no harm in having both. It's just that I don't use wxWidgets so I'm not sure whether what I'm producing works or not.

Why that matters is because I build the libraries for Wascana myself using the gcc/g++ I distribute with it. I've switched over to tdragon.net as my supplier for gcc, mainly because they (or he?) provides the latest releases from gcc (and the mingw.org community is a bit of a mess). And I want to make sure these libraries are built with the latest and greatest optimization algorithms gcc is providing.

At any rate, I'm learning how to build Qt and it's running right now. I hope it doesn't melt my laptop. They have a ton of example and demo projects that I can use to test so it's a pretty good environment for producing quality distros.

I should also look at their Eclipse plug-ins. They provide an installer for the Windows version which installs into an existing Eclipse. I wish they had a p2 repo that I could use instead. But I'll have to see what they're laying down and understand their licensing to see whether I can make these available in Wascana as well. I still find it weird they have their own IDE, Qt Creator, when it should be pretty easy to put together an Eclipse-based IDE that does almost the same, if not more...

Emulation versus Multi-Platform

Over the last little while, when I could steal away a few minutes from my busy day job as of late, I've been thinking more about open platforms for handheld and set top consoles that makes good use of the 3D hardware that is becoming common place in these platforms. Of course, being open, I'm talking about open source and royalty free APIs like Linux and OpenGL and OpenGL ES.

I've been very excited about the LGPL'ing of the Qt C++ application framework. The programming paradigm is very clean and the library set is huge, including my favorite, the WebKit browser, and, of course, OpenGL support.

One angle I've been following is my other favorite piece of open source software, the qemu CPU emulator. The community is very active there and they're are more and more platforms and hardware components being emulated making it a nice platform to play with some of the concepts I'm thinking of.

But the one critical piece missing is 3D hardware emulation. I would be great if someone could put that together, and given the comments on my previous blog entries, it would be very popular. I could do it, but I have the bigger picture in mind and have some other things I'd like to work on, in particular, a port of the Clutter concepts to Qt (and no, the QGraphicsView is close but not quite what I was thinking of).

Thinking about it tonight, it struck me. Since Qt is multi-platform and the tools I use, gcc and the CDT are multi-platform too, why don't I just start this work on Windows using Wascana, the Eclipse CDT/mingw gcc package I am also trying to work on. I could even use the OpenGL ES emulation libraries that are out there to make sure these ideas work with OpenGL ES, another multi-platform component. And as my work here progresses, I will have the opportunity to use the same tools to make it work on real hardware.

It's this type of environment that motivates my work on the CDT and what makes it so powerful. It's time to put it to work for me.

Qemu 0.10.0 now available

In a message from Anthony Liguori to the qemu-devel mailing list, "The QEMU team is pleased to announce the availability of the 0.10.0 release. This release has been a year in the making and is the result of almost 3,000 changesets from around 80 developers." The release was quickly put together in the last few days (i.e. in Eclipse terms, there wasn't much of a ramp down). And the resulting build is actually pretty hard to find, at least until it gets propagated to all the mirrors, but it's a milestone anyway.

There's a pretty long list of new targets and hardware emulation. There's also improvements to the VNC support. The biggest news is the new code generator for translating op codes into runnable code. It's called TCG (Tiny Code Generator according to Wikipedia) and removes the dependency qemu had on gcc 3.x, which means it gets to take advantage of the huge performance improvements of gcc 4.x. I think I read somewhere that the Android qemu was running 1.5 times faster thanks to that. And my copy is humming using the gcc 4 I'm integrating into the future Wascana 1.0.

This release is a good sign that the qemu developers are getting serious about formal releases. It's been quite a while since the last release and there has been huge architectural change. That has led to a some difficulties co-ordinating with the other projects that use it, like the kvm Linux virtualization platform. Having quality releases more often will make it easier to get changes from forks into the mainline, which is good for everyone.

For me, it's just good fun to be able to have a virtual platform to try different ideas with C/C++ libraries that target mobile devices that I could easily target to real hardware some day. And I think it's intriguing the Eclipse integrations we could do to make it easier to work in that environment. A lot we have already, like CDT (of course) and the Remote System Explorer for launching, and there is work on more coming from the Tools for mobile Linux project. Interesting indeed.

Qt 4.5 Full of Surprises

Qt 4.5 was released today. As expected, it comes with the adoption of the LGPL license which should make Qt free for commercial development if you so choose. I think this will be a huge boost to the adaptability of Qt and hopefully make an impact in the Gnome versus KDE Linux desktop wars (mind you the KDE gang are really shot themselves in the foot when they released 4.x as a planned regression from 3.x).

There were a couple of big surprises that came with the release announcement. First was the discontinuation of Qt's embedded product, formerly and lovingly known as Qtopia, the best product name in the business ;). The plan I understand is to fold that functionality into the Qt mainline releases with the intention of making Qt a truely cross platform API for both desktop and mobile. And they've started by introducing an OpenGL ES paint engine into this release, which if I understand correctly will allow you to use Qt to create apps for mobile devices now.

The other big surprise, isn't really a surprise since I've known about and wondered what was going to happen, but they've released a 1.0 version of their IDE, Qt Creator. It appears they are going forward with this IDE as a key offering, and have released it as LGPL as well. Which means, theoretically, a community could form behind it and it could start to compete with Eclipse. We'll need to do a thorough analysis and understand what it all means. Especially since they also uprev'ed their Eclipse integration and have a beta of their Visual Studio integration available. How does Qt Creator fit into this world?

The only thing that really bugged me in their news release on Qt Creator is their claim that "it provides the first IDE designed specifically for cross-platform development". Uh, guys. The CDT is 7 years old and counting...

Way too much fun with qemu

As I've been blogging about lately, I'm getting ready for my EclipseCon tutorial which will walk the attendees through adding support for a cross-compile environment to the CDT. The target of this environment will be qemu running a tiny Linux platform which includes the latest release kernel, busybox, dropbear with sftp-server from OpenSSH, using the free glibc C run-time and gcc cross compile tools from CodeSourcery.

I'm using the default ARM target for the latest qemu which unfortunately has a bug in the FIFO emulation that interfaces with the emulated SecureDigital card where I want my root file system. I asked on the qemu-devel list and someone there sent me a patch they had posted a couple of weeks ago. Checking out the qemu source from svn into the CDT, I was able to fix up the function where this was done and I was quickly up and running with my root file system on the SD card image. Very, very cool!

The next highlight was when I got the ssh components running and I was able to connect to the qemu target using the Remote System Explorer from the Eclipse Target Management project. Also, very, very cool. I want to use RSE and the CDT remote launch to get the results of the build up and running on the target.

So now that I know how to build stuff from the command line, the next step will be the meat of the tutorial, creating the managed build integration for the cross compiler. Of course, you'll have to come to the tutorial to see the result, and actually work with me though the process. But it should be fun!

And now that I've actually started working with qemu in the CDT, I'm starting to get that itch to add 3D graphics support again...

Subversive vs. Subclipse

One of the most common Google searches I see in my Feedjit log is from people looking for help in the whole Subversive versus Subclipse debate. It has always dumbfounded me why we have two efforts building Eclipse team providers for Subversion. But I've long given up on fighting that battle.

So as I start to dive into the code for qemu, I found myself in need of making that choice again. Some would say go with Subversive since it's an Eclipse project. I would, but they are mired in provisioning hell with a key component for making it work being on another site due to licensing/IP reasons. That didn't turn me on much so I'm going with Subclipse.

And so far so good, but I've only just checked out the repository. We'll see how it goes if I need to make any patches, and as I keep updating. But my hope is that as it has aged, all the issues I saw a couple of years ago have been addressed.

My heart is still with distributed version control and git in particular. And there is discussions on the qemu list about moving to git. And in particular, I'm very interested in how these team providers work with the CDT and how they work with the changes were doing for e4 on the IResource front. And it's pretty clear that these plug-ins, no matter what version control system they target, need to work well to keep our users and customers engaged.

CDT 6.0 M5 is Available, BTW

I've been "nose to the grindstone" since the holiday break getting our Wind River Installer out the door, twice. But the good news is that the CDT contributors have been very busy working on CDT 6.0 while I wasn't looking very hard. I have been waiting for the C/C++ IDE Package for M5 to be built. In the meantime, we do have the bits up on the CDT Galileo update site for you to try. Just download the Eclipse Platform or SDK 3.5M5 and add the following URL as an update site:

http://download.eclipse.org/tools/cdt/releases/galileo

Most people will want the "Tools" feature in the "Main" group, which will give you everything you need to work with the gnu toolchain. And yes, the features say 5.1.0, but we're tricking the API tooling with that to keep track of API changes. We'll be 6.0 when we go out the door in June.

I've actually been using CDT 6 for some technical investigations I've been doing lately, the qemu source being one of them. One of the biggest issues with the CDT that we've been fighting forever has been taking projects that have been developed without an IDE, that don't have any real structure to them, bringing them into the CDT, and having our indexer parse and create useful search information for them. And this is especially bad if we can't figure out the include paths to find the header files needed to parse properly.

One common pattern we have noticed with the include path was where all the user specified include paths were actually folders in the workspace. Everything else came from the built-in include path. At the very least, if we could search the workspace when looking for header files that were unresolved, we could probably resolve them.

Well in CDT 6.0M5, that functionality if finally there (thanks, Markus!) and it works superbly! Many of the unresolved headers I saw in this one project I was looking at, which targeted many different OS's, were magically resolved, and features like Open Definition (F3) worked great. Sure, if you have multiple header files with the same name in your project, we may pick the wrong one to resolve, and there will still be issues if you don't specify external include paths, but it's huge step forward for CDT usability.

There are other interesting things in M5, including the Debug Services Framework which has moved from the Device Debugging project to the CDT and should become our "official" debug framework over time. You'll notice the major issue we have with having two debug frameworks when you go to launch (double the launch configs :( ), but we are working on a solution to that.

We're still making great improvements to the CDT as we go. Most of them are under the hood as the feature set we have is working quite well already. And there are still things to clean up, like our managed build system and the underlying build model and the need to integrate that with our debug models. But I know I'm a happy CDT customer myself, and I hope you get a chance to try out CDT 6.0 M5 and give us your feedback.

Eclipse in the Clouds?

I'm not going to say much with this one. I'll just refer you to the comments people are adding to Boris's blog entry on his work with Mozilla to get an experimental IDE running in a browser with an Eclipse-based server back-end. Is this what developers working in the embedded and desktop space are asking for? Not that I've heard. And neither do a number of the commenters on Boris's article. Some of them are putting it in much prettier words than I could say without getting into trouble...

That's why it is so critical for those of us in the Eclipse community who support such users to make sure Eclipse continues to work well and to improve in the areas that cause them pain. Is the future of enterprise development so different from desktop and embedded that it requires such radical architectures? Maybe so. If that's true, we need to hold our ground and ensure we don't get dragged down a path we can't be going.

An ARM on Family Day

It's "Family Day" here in Ontario, Canada, and while my one son is over at his buddy's house and my other son is watching game trailers and my wife is out for lunch with the girls, I'm sitting here enjoying the day off. I'm sure we'll do something family-ish later today...

Anyway, I just read about TI's new family of chips, the OMAP4. The big news is that this is the first time TI has jumped on ARM's multi-core bandwagon and the mixture of parts going into these SOCs is quite impressive. You have PowerVR's venerable SXG OpenGL ES 2.0 engine, image processing, and enough power to play 1080p video. As the TI guys says in the LinuxDevices.com article, this type of architecture really will start to blur the lines between smartphones and MIDs (and even makes me wonder about the set-top box market). It looks like we'll be seeing some pretty exciting products ahead.

Speaking of TI, I'm still looking at the BeagleBoard community-based development board kinda thing. The more I look into what the community is doing with it, I really see it's potential as a vehicle for learning embedded development. But I'm cheap, so my attention turned towards whether the qemu emulator could emulate the BeagleBoard so I can run it on my laptop. And apparently someone is working on it. But then I started doing the math. How much is my time worth? Versus forking out the $300 or so to get set up. Makes me think...

Mucking around with all this has led me back to my EclipseCon tutorial on integrating a cross-compiler toolchain for the CDT. I really want to show how easy it is to get up and running with qemu and a cross-compiler and the freely available embedded Linux run-time goodies all under the CDT as the IDE. And given all the hype about ARM and mobile, I think I'll go with ARM as the target CPU. Should be a fun 4 hours, which should be plenty of time to get at least a hello world running. I can't wait and I really hope you can make it too.

IANAL, BSD, GPL, LGPL, ABCs

Slashdot pointed me to this article by Bruce Parens aimed at clearing some of the air around using GPL and LGPL and commercially licensed product on the same device. Of course, the summary of the article is "Check with your lawyer" as it should be. But I hope it alleviates fears over the FSF licenses that I know people have.

I especially like the description of the motivation that open source developers use to license their software. BSD is a "gift" software license. The developer is giving it to you as a gift, do with it as you wish, just give him some of the credit. LGPL is "non-gift". And I get it. They essentially don't want you using their stuff for free unless you help with it. And then you have GPL, which falls into the category that they just don't want you using their stuff for free, unless you're doing your stuff for free too. This categorization puts a little bit of a human face on it, and I appreciate that.

This also made me think about our situation at Eclipse. It's very difficult to get third party software approved at Eclipse. I'd love to be able to host the GNU tool chain binaries along with the CDT to help new developers get started. Now, I am not a lawyer, but Bruce's article doesn't mention restrictions on distributing binaries, only the run-time requirements. Maybe I'm missing something there, and maybe lawyers are reading more into the license than what I see. So be it, they're professionally responsible for their opinions, I tend not to be.

But there is no mistaking it. Despite whatever legal issues surround open source software, it's popularity can't be denied, especially in the embedded world.

Beagle Board and Eclipse Distros

We had a meeting a few days ago amongst interested parties in an Eclipse IDE distribution for embedded. The idea would be to do something like I'm doing with Wascana which is supposed to make it easy for developers using open source tools, students especially, to get them up and running on Windows, and in turn showcase the features of the CDT in that environment. The idea of doing this for embedded would be to do the same for embedded systems developers and to show case the features of the DSDP project at Eclipse as well as CDT's embedded development support.

One thing I think we noticed quite quickly is the diversity of the embedded community at Eclipse. We have Web services applications for embedded, we have J2ME Java for embedded, we have deeply embedded systems like microkernels and DSPs that have no OS per se, and, of course, we have the more traditional RTOS systems. I think it'll be hard to showcase Eclipse support for all these things in one distro, and maybe it deserves it's a few such distros, or maybe we have RTOS versus not RTOS. It's an interesting initiative and I'm excited to see where it goes.

One of the platforms that came up in the meeting was the Beagle Board. Checking out their web site, it looks like an interesting target for hobbyist and student embedded developers. It's a cheap little board at around $150 US (a little more once you add the needed cables and a power supply to use it properly). The community there is working on getting the Angstrom embedded Linux distro running on the board and there are some cool videos of it working. Don't doubt it, this is being driven by Texas Instruments, who makes the chips for this board, so it's not purely a community driven project, but it looks like an independent community has formed and is running with it.

I think this would be a good choice to target an Eclipse for Embedded distro. I think a case could be made for qemu as well and the various CPUs and boards it emulates. And I assume you'd target Linux for these platforms. But then you open up the questions, which distro do you support, or do you make your own? And what about the other free or quasi-free RTOSes that have Eclipse support. At a minimum you need a cross compile and debug tool chain to integrate Eclipse with but what else would you need?

I get the feeling that this could turn into a pretty big project on it's own. Which, of course means it won't happen without a community behind it and maybe vendors to sponsor it. I'm interested in hearing your opinions on what this all should mean and what you would like to see in an open source Eclipse for Embedded IDE.

MinGW frustrations

Um, yeah, Wascana 1.0 keeps slipping. Work has been very busy leaving little time for me to work on it, but that should be clearing up in the next few weeks (I hope!). But as I did my testing for the release candidate of CDT 5.0.2, as I expected, I ran headlong into the gdb 6.8 issue that everyone seems to run into. I don't know how many people I see on my Feedjit log searching for: "gdb eclipse No source available for "ntdll!LdrAccessResource()". And I hope those people now find this blog entry instead.

The issue is that before gdb 6.8, there was no way to issue pending breakpoints using the MI protocol we use to talk to gdb. I think it was introduced in 6.7 from the CLI, but that doesn't help us. To support breakpoints in shared libraries, we need to keep retrying to set those breakpoints on every shared library load event. That worked for many years. But now, the break on shared library event in the MinGW gdb 6.8 really messes up the CDT. And it's mainly because it doesn't work in gdb any more.

So the solution is to add support for pending breakpoints, at least into the MinGW debugger target. But, alas, I think that's going to be a lot of work. And given I'm having trouble finding time to even get the p2 support for Wascana done, let alone dive into debug which I don't really have expertise on.

At any rate, the experience is so bad, I'm starting to think of holding off Wascana 1.0 until Galileo in June. I can make the p2 repo available so people can download the same thing I'm testing with. But until this debug issue is resolved, it's not an environment I'm happy to send out to the world.

That and there was an interesting conversation on the mingw users mailing list recently about the state of gcc 4.x for MinGW. I've lost faith that it's ready for prime time as well.

It's enough to make me wish we had a Windows debugger available and to complete our Visual C++ support (wink, wink, nudge, nudge to people who know who they are ;). For now, bear with me.

TV's are small, plus a little Clutter

So I was sitting watching my 40" HDTV the other day, and started thinking about why web browsing on a TV pretty much sucks, even with all the pixels you get at 1080i or what have you. And trust me, I tried it with our PS3 and other than watching YouTube videos, it's not a good experience.

But while I was sitting there on my couch (or sofa, depending on your English dialect) a pretty normal distance from the TV, I held my hands up to frame the size of the picture at arms length. Then lowering it to may lap, it struck me. The size of the picture isn't any bigger than a handheld gaming box, maybe slightly bigger than an iPod Touch (as I try to find one for my son's birthday on Thursday :( ).

The reality of the situation is that even with the higher pixel count, you still need to treat set top boxes as mobile, but not mobile, internet devices and entertainment units. And that especially goes for the UI. Don't try running GNOME on it, that's going to be brutal.

So I'm off taking another look at mobile devices and the user interfaces they present. The newest one is the 2.0 alpha release of Moblin, Intel's effort at a Linux distro for mobile internet devices and netbooks running their chips. The video in the LinuxDevices.com article is intriguing, and made me go look at what technology they were using to present their 3D animated GUI.

Well, it turns out to be another open source project called Clutter. They produce a library that abstracts away the grunge of OpenGL and OpenGL ES to build user interfaces. You create Actors that have images and such and declare their animation and event handling and then fire off into an event/display loop. You get pretty cool effects with not too much code.

Now, I have to pick at the choice of GTK as their paradigm mentor and, yes, if you're used to GTK programming, doing Clutter will be natural, but if you're like me and fell in love with the Qt and it's elegant use of C++, then you'll be a little put off. I did find a clutter-qt integration in their repo, so maybe you'll be able to do both in the future.

Someone once said, and I think he lived in Redmond, Washington, that there was no innovation in open source. This is a pretty significant counter to that. This project has been around for a while, sprouting out of the need to add GUIs on top of the new fancy 3D graphic chips appearing in handheld devices. They have a innovative and game changing solution. The just need people to discover them, and Intel, who also happens to be their new boss, is helping with that.

Can an LGPL Qt give C++ a lift?

Black Duck recently announced their top Rookie Open Source projects for 2008 which using a bit of a weird metric, revealed the top 10 open source projects that were created in 2008 that had the highest number of releases. More releases makes you good? O.K...

Anyway, the most interesting information from their news release was the stats they gathered on what programming languages these new projects were using. To the surprise of many, 47% of them were written in C (C Rules!). That was followed by 28% in Java and 20% in JavaScript. It's pretty interesting there was so much JavaScript usage. And again, these were projects that have just been created. But when you look at it, most open source projects target Linux, and by far the most popular language for Linux is still C.

One thing I noted, though, was that C++ wasn't even mentioned. It could be that they lumped C++ in with C, but I have my doubts. I rarely do see C++ in open source. The large open source game engines, like Ogre and Irrlicht as well as Firefox (of course), are in C++, and OpenOffice is written in every language imaginable including C++, but I see C way, way more.

[Watch out, bad segue ahead...]

I spent part of last weekend taking a deeper look at Qt, with its upcoming spanking new LGPL license. I have to admit I'm a GPL library bigot and kept away from Qt because of that, but boy do I regret that now that I've seen it. It's an incredibly complete C++ library for building apps of all kinds. And it has everything I've been looking at lately, WebKit, JavaScript (well ECMAScript but that's the same thing), and OpenGL, and incredibly smooth integrations between those and many more components.

So as Qt makes this transition, I have a feeling it's going to gain in popularity everywhere. And I think it'll show the power of C++ and pull a lot of the developers writing for the C-based GTK away. Heck even Ubuntu is thinking of switching to it for their mobile platform.

Kudos to Nokia for making this decision. I think it's going to pay dividends for them as developers take a fresh look at a great framework. Which, BTW, means there will be more developers working in the same environment that also happens to run on Nokia's phones ;).

J2ME? Why?

I was just reading the slides presented from the kick-off meeting of the Eclipse Mobile Industry Working Group. I believe this is the first working group at Eclipse and I think it's a great concept. Bring groups of companies together that are interested in the same or similar technologies and do some planning. Hopefully that will result in new investments in various Eclipse projects.

Anyway, one of the examples of work environments shown was for a J2ME developer. The first thing that jumped into my head, and of course I'm writing this entry without thinking more so I may come off a bit misinformed here but hey I'm just the dumb C++ guy, but who cares about J2ME any more? With the rich mobile development environments provided with Android, the iPhone, the new Palm Pre, and even Qt for mobile devices, why would you do J2ME development any more. Isn't there much more opportunity for greater riches writing apps for these new and wildly popular environments?

Anyway, feel free to comment and tell me the way it is. And I'm sure the J2ME people over in DSDP are the right people to do that ;), since they know that community. But I am curious about whether the J2ME community is still on the rise, or whether there is a migration happening to these new technologies.

Time to Get Qt?

Now this is interesting. I've mentioned a few times in my blog that the world would be a different place if Qt was given a free commercial friendly license, like LGPL. Of course when Trolltech was an independent company, that would have killed all their revenue. But now that they're owned by Nokia, I guess the time has come for them to make the change.

And I think this will open people's eyes to Qt. It's certainly a very rich framework giving pretty much everything you need to make a truly cross platform application, i.e. #ifdef free. And it's used in some very popular applications like Skype, Google Earth, and the VirtualBox manager. And, of course, it's the foundation of the Linux KDE desktop environment, which has it's devoted fans.

And again, being LGPL, I'd expect to see it used by more commercial applications. Heck, it will now pass my policy and I'll be able to include it in Wascana, and the SWT developers will also be allowed by their lawyers to write the port against it. Who knows...

But as I scout the horizon of desktop and mobile apps, I wonder if the apparent momentum away from C/C++ has become too great for this to make a significant splash, or will it just be a ripple. Maybe my head is too deep in WebKit these days and my view is getting tainted, but the web is slowly taking over. I guess the one thing Qt has going for it is a decent WebKit integration so maybe they can get the best of both worlds. Either way, it's definitely time for me to take a deeper look at Qt (and it's CDT integration, of course ;)).

Palm Pre and WebKit

I've been following the Palm Pre story a bit the last few days. While the technical details are still pretty sparse, it appears that one of my predictions for 2009 is already starting to happen.

My understanding, and I hope it isn't coming from sources who are also using the same technique to guess at the architecture of this thing, is that the UI for the Palm is rendered totally using WebKit. It appears that the applications for this device are written in JavaScript and use HTML and maybe WebKit's SVG support to render the graphics. Hell, maybe it's even using Dojo to make things look really sharp.

If this is true, then it's going to be a great test of how well this architecture works. I have my worries about how JavaScript scales and how easy it is to write traditional GUI apps, even handheld ones, using HTML as a rendering engine. But looking at the screenshots, it looks pretty awesome.

The other thing I notice is that there is a continuing trend of making it very difficult to build native apps that draw on the screen with these things. It started with JavaME in the "old days" and is continuing today with Google's Dalvik Java VM and now Palm's WebOS WebKit thing. They promise the power and openness of Linux and then shut the door. It's too bad, since a lot of these handhelds have 3D graphic acceleration in their SOCs, and you really need to go native to build a good 3D game or what have you.

I can't wait to see what the Pre SDK looks like, and whether developers buy into this architecture of GUIs based on web technology. And it'll be interesting to see how good the apps can be with it. But if they're as good as the prerelease demos, it's something to pay attention to.

Zune 30, Killed by Complexity

I first heard of it early New Years Eve, I guess. Hoards of Microsoft Zunes were committing mass suicide (a gruesome thought but the actual quote from the Slashdot article). Fears rose that some Y2K thing was happening, mind you things like that didn't happen in Y2K, at least not on this scale. Microsoft finally confirmed the issue as such though, a device driver hang on the 366'th day of a leap year. I'd love to see that code...

Well, thanks to the wonders of the internet, here it is! (I imagine this link will fall dead as soon as the Microsoft cronies make the rounds, as they should. It does have a Microsoft copyright). I actually found it through another blog where the guy put together a pretty good analysis of the problem.

The root cause? A brain fart. Either someone was in a hurry, or they couldn't handle the complexity of the algorithm once they started dealing with leap years. People blame testing for not testing all the paths. But, if you don't take the time to test all the paths, or don't have the skills to properly enumerate all the paths, testing isn't going to matter. At any rate, another great software engineering lesson learned for us all, just like the unhandled exception in the Ariane-5 rocket, except this one is recoverable and isn't as expensive (unless the Zune market share dives as a result, which could happen).

I spend a lot of my time these days working on software architectures and trying to come up with the most simple, extensible, and future proof. But none of that matters if you have code like this. And I've seen code like this all through my career. Hell, I've written some of it. But one thing I learned early from one of my great profs back at the U of S, was on code complexity. It is even measurable by counting the number of paths through your code. Complexity bad. Which implies that having more paths than you need is bad. As we see here, it becomes too difficult to test fully.

And that is certainly the case here. Too many 'if's. How do you convert days since 1980 into a time structure? Well in the Zune code (which is actually a common device driver in a number of Windows CE platforms), one of the paths leads to an infinite loop, when days is 366 and IsLeapYear is true. The author of the blog proposes a much simpler algorithm that works correctly but reduces the paths thus eliminating the bad one. I think you can make it even simpler.

One of my mantras is "I hate typing!". Of course it has nothing to do with typing (much). It's about producing simple elegant solutions to simple problems. Yes, Keep it Simple S(favorite ending here). Saves time. Saves money. Saves embarrassment. Saves your job. I'd hate to be the guy who wrote this code...

Predictions for 2009

I'm not usually one to make predictions. It's hard for me to tell the difference between a prediction and wishful thinking. But this article over at the Inquirer (still the best place to get an honest take on the industry along with /.) got me thinking about a couple of things I think are going to be important in 2009. So here we go...

2009: The Year of the GPGPU

This is more a continuation of a trend but the Inq article made some great points that I think will put some spotlight on general purpose programming with GPUs. The key one, is the recent standardization of a cross platform way of programming these things, OpenCL. ATI and nVidia have already signed up to provide OpenCL support for their chips and look for Intel's Larrabee platform to come with the same. I think there is still some software and hardware architectural things that need to be done to make GPGPU more efficient and easier to program. Look for LLVM (which needs an article on it's own) to play a role, as it already is with OpenGL, and look for one of the chip vendors to put a GPU on the memory bus shared with the CPU and make these things sing.

2009: The year of WebKit

Ok, yes, I'm playing it safe with these predictions. WebKit is already the base for Apple Safari, Google Chrome, and a host of Linux based browsers, so it already has a ton of momentum. The reason I think WebKit is going to the next level, is first of all the top of the class performance of it's new JavaScript VM (and I can't imagine why Google would continue with V8 in Chrome). But also, I am impressed with how easy it is to create your own WebKit based browser, and how easy it is to create a Linux based platform that uses WebKit as it's front end (launch X, launch a simplified WebKit shell in fullscreen, done). I expect to see a lot more mobile internet devices built this way. At the very least, it gives a reason for embedded developers to care about AJAX.

C++0x won't be C++09

I think that's a forgone conclusion but no one really wants to admit it yet. But look for the vote to finish this year at least. C++0x will be an exciting evolution of C++ into the next generation. No it doesn't have garbage collection, yet, but it does have smart pointers that do the job better if you use them right. C++0x makes it easier to do a lot of things, and the introduction of closures and lambda functions and expressions will breath some life into this stalwart of the software engineering community.

Well, that's it for now. If I think of more over the next couple of days I'll post them. There are a lot of things I hope will happen, but i'm not sure they will. But one thing is for sure, open source is here to stay and is becoming a core business model that companies still need to understand and learn to use effectively and I will continue with my work with Eclipse and Wind River to help figure that out and spread the word.

Have a safe and happy New Year! See you on the other side.

A look at WebKit

A few days ago, I was playing with Google's V8 JavaScript VM library and got it compiling with MinGW in Wascana. I submitted the patch to make it work but I haven't heard back. I guess it could be the Christmas break.

But one thing that struck me odd recently was an announcement that the next rev of Android would include WebKit's SquirrelFish Javascript VM. I guess that shouldn't be too surprising since SquirrelFish comes with Webkit. But then why is there ARM support (the CPU for Android) in V8? And if they are using SquirrelFish for Android, why don't they use the souped up SquirrelFish Extreme for Chrome? Especially since there are benchmarks showing it beating V8. I'm confused and can only chalk it up to Google being a big company and maybe the Android people don't hang out with the Chrome people.

Anyway, that got me looking into this whole WebKit business. I downloaded the latest nightly source build to my Debian Linux VM and after installing a boat load of packages needed to build it, I built it. I had heard the JavaScriptCore library which implements the VM was embeddable in C++ apps. The header files are there, but it looks like you actually have to embed the whole WebKit library to get at the VM.

That got me thinking back to an earlier idea I had. Use HTML with JavaScript as your main GUI framework. With Webkit, you can embed the whole browser into your application, and you can hook up new JavaScript classes to your C++ classes to provide scripting and to give access to them to the UI. Interesting to see how that would work in action.

I think I'm starting to figure out this whole JavaScript and C++ thing, with thanks partly to something a commenter said on a previous entry. Use scripting for quick turnaround, when you want to whip up a prototype or allow for easy extension of functionality. But use C++ for areas where you need to engineer functionality. Part of your architecture design is deciding what that means. And maybe something like WebKit might be the right platform to get you off the ground.

VirtualBox 2.1 and assorted Christmas Fun

Just some random thoughts on this Saturday after Christmas. My family and I had a good Christmas, despite a little "Fun with Autism" moment with my Autistic son, but it's all better now (patience is a key survival technique in our household). Yesterday was Boxing Day in Canada, which is a holiday here despite all the stores being open for your shopping pleasure. If you don't feel like going out, you are free to sit around, well, like boxes, which we did for the most part.

I'm spending a little time today while everyone is playing on the PS3 and various PCs around the house getting ready for my EclipseCon tutorial. I'm really looking forward to it. By the end of the tutorial, you'll walk away with Wascana which you use to build qemu, a little Debian Linux image running in that qemu, and a cross-compile toolchain and CDT integration that you also get to build to create apps for Debian from Windows (and maybe Linux). Lots of hands on and hopefully an appreciate of why the CDT is the first class cross-platform C/C++ development environment.

Before I get back into playing with qemu, it was cool to see a new version of the VirtualBox emulator come out, 2.1. It's a minor version increase but there are two significant features added. One, is 64-bit support on 32-bit platforms. This is critical for me and my installer work at Wind River, where I need to test and debug on 32-bit and 64-bit platforms. I don't trust 64-bit Linux enough yet to make it my main Linux environment, not to mention downright fear of 64-bit Windows.

The other cool thing is more on my personal interest front. They have an initial release of OpenGL support. If you read this blog regularly, you'll know I have a dream of an open Linux-based game console/multimedia set top box. I'd like to try some ideas out on a Linux platform with 3D hardware without actually buying any and this is the first emulator to have OpenGL support.

Unfortunately, they only have Windows guest drivers at the moment but have promised Linux/X drivers soon. I can't wait, but it does lead me to drop my plans for working on OpenGL support for qemu. Instead, I really need to spend what little hobby time I have learning how to write an X window manager, using a cross-compile environment with the CDT, of course ;)

I could have had a V8, oh wait, I do

I've always been intrigued by programming languages and what makes them tick, and what is the best one for what situation. That's why Dave Thomas's keynote at ESE still has me thinking about the mix of JavaScript and C++. So much so that I spent a few hours this weekend while waiting out the snow storm to get Google's V8 JavaScript VM building under MinGW for Wascana. I think it would be an intriguing addition to have the VM DLL available for developers using Wascana. With a few changes, I have it building and passing the unit tests and I have a patch into the V8 project. I'll make V8 available in the Wascana 1.0 alpha in the next couple of days.

Now that I have it, I have to ask myself - what the heck do you do with it? I've thought about building wrappers for the wxWidgets library to let you build thick client apps in JavaScript. wxWidgets also comes with Wascana, and thick client apps is kinda what Wascana is all about (aside from dreams of using it for game development, which could also benefit from a fast JavaScript engine).

But it's not clear where one would draw the line between JavaScript and C++. Given a C++ library like wxWidgets, or SDL, or what have you, is it enough to wrap it with JavaScript and have the developer do everything in JavaScript. Or should JavaScript just be this thing on the side that allows for extensibility of some larger application written in C++.

It makes me wonder if I'm following some crazy idea that some madman sold me in a bar in Germany. Or maybe this is challenging me to give it deeper thought, to think about how scripting and native languages are supposed to mix. Where in all this is the sweet spot of architectural balance. Or is there one? Either way, it'll be on my mind over the Christmas holiday season.

Fun with FEEDJIT

I'm not sure if you noticed, or are reading this blog from one of the syndication sites it gets copied too (like Planet Eclipse, or the Wind River Blog Network). But if you check back to the original site and scroll down a bit, you'll see a new panel called the FEEDJIT Live Traffic Feed. I know people express concerns about web things following them, and if I get enough negative response to it I'll pull it off. But in the meantime, I'm spellbound by this feature.

I'm learning quite a lot about the audience for this blog. The traffic feed gives me the city that where the person was, which is spread throughout the world, as well as a hint at how they got to my site. A few people come directly, I guess from an RSS reader where they've subscribed one way or another (Thank you!). More often, though, people end up here based on google searches, and I get the snippet that they were searching for! Creepy, but very useful.

So what are people searching for that pulls up my site? Well a lot of it lately has been the topics I'm most interested in lately, and that's CDT for Windows development, including Windows cross to Linux. It's good to see the interest from the community on that and I am continuing working on Wascana 1.0 as I write this (SDL is building in the background). I also often get a few queries on the Subversion Eclipse plug-in wars (I hate both right now, go git!). And you get the odd one looking for help, like today's "eclipse CDT autocomplete crap" (yeah, it has issues if you're environment isn't set up).

Anyway, it's pretty interesting to watch, and it humbles me immensely to see people from around the world reading what I write, especially when the google search reveals they searched for me by name. But I love to write and share my thoughts and I really appreciate it when people leave comments. Whether I agree with them or not, I always learn something from what they put there. It's a lot of fun and I encourage everyone to do the same. There will always be someone out there interested in what you have to say.

Fun with my little VIA console

At the Embedded Systems Conference in San Jose this year they handed out little VIA embedded EPIA systems to the attendees. I'm not sure everyone got one, but I was thrilled. It has a embedded VIA processor with a chipset that includes Unichrome 3D graphics, and also include a hard drive, ethernet, VGA, four USB ports, and audio in and out. It's a cool little unit.

I haven't done too much with it, but thinking about this Open Console concept (set top box with 3D graphics running Linux), I thought I'd try setting it up with some of the things I had in mind. I started by putting the Debian lenny installer onto a USB stick and installing from it. That was a little tricky until I reformated my USB stick and put syslinux on it properly. I installed enough packages to get X running with the openchrome driver for 3D graphics. glxgears ran pretty smoothly which gave me some hope I could actually use this thing to run games.

So I got adventurous and installed Nexuiz, an open source first person shooter. To my surprise, this and other open source 3D games are available from the Debian package repository. So a quick little 'apt-get' which brought down around 450MB of game, and I was off and running. We'll off anyway. I got about 20 seconds per frame, which makes it a little hard to even notice the thing was running.

Anyway, I tried a few other simpler games and they actually worked. I had to force myself to go to bed while hooked on billards-gl. It was fun. But I've slowly begun to realize that games built for the desktop aren't really ready to be played with only a joystick as you'd likely only have in a set top box scenario. So there would be work to be done.

I also started to understand first hand the commercial opportunity behind Linux, embedded Linux especially. Sure you can install a Linux distro and get a desktop environment up without too much effort. But try to do anything off that beaten path and you're in for a lot of work. If you can share in that work, fine. If you can pay someone to do it for you for cheaper than you could do, even better.

I also gave up on using this little VIA box for my play-totyping (hmm, new word). I need to start getting ready for my EclipseCon tutorial which will help me get back into the guts of qemu. Maybe I can do a little work there to bring GLX emulation to it, play time permitting, of course. Or maybe I'll shell out the $500 bucks to build a real system. Though playing in qemu would be funner...

Time for Distributed Source Control is Now

Imagine this scenario. You're part of a small team that's been following the CDT closely and have adopted it as the IDE for your commercial platform. You grab the CDT source at times convenient to your product deliver schedule and work on a local copy fixing bugs you find as you go through product testing. You're not a committer but you do submit patches from time to time and hope that the CDT team picks them up. But they're often busy with their own delivery schedules and the patches often grow stale and fall off everyone's radar.

So you live with your CDT fork and struggle every time you have to update to a new CDT version, so you don't do that very often. And since you're busy struggling in that environment, you really don't end up with time to get more involved with the CDT. You are a small team and you only have so much time in the day. You run into Doug once in a while at the Eclipse conferences and talk about what you do and promise you'll figure out some way to get more involved, but he knows your story too well and doesn't put much faith in it despite his appreciate for your intentions.

Sounds like I have experience with this, don't I. This scenario is too real and I'd bet is very common across all open source projects. Relying on CVS and Subversion at Eclipse with access controls limited to the select few committers makes it very difficult for those on the fringes to get more involved. It truly is a have/have not environment. The committers have it easy, checking in their changes whenever they want and those that aren't are struggling to keep up, or simply fork and go their own direction.

I've learned that the new Symbian Foundation as selected Mercurial as their source control system. Along with Linus's git, it's one of the new breed of distributed source control systems. These systems allow for multiple repositories and provide mechanism to pull and push changes between them. The introduction chapter of the Mercurial on-line book provides a great description of why this architecture works well for large globally distributed projects.

I invite everyone to read it, especially the Eclipse community. Because I think we need this kind of capability now. CDT needs an infusion of new blood and I know there are a lot of people who work with the CDT code base but have only a limited time to contribute back. If we had the infrastructure to better support them and make it easier to pull their changes into the CDT main line, and easier for them to keep up with everyone else's changes, it could be the formula we need to grow.

x86, the ultimate applet engine?

I need to watch out or people will start calling me a Google fan boy or something (well, too late). It seems everything they come up with lately grabs my attention. And I guess it makes sense, because they seem to be heading in a different direction than a lot of people, and more in a direction that appeals to me. First Android (open mobile handset), then Google Chrome (Webkit-based browser), then the V8 C++ friendly JavaScript VM, and now, Native Client.

If you haven't heard of it, it appears to be a Google research project into running secured native x86 code in a browser. Yes, we have tried that before with ActiveX and it was a security disaster. But the underlying need for high performance interactive web pages is pretty intriguing. If you could write browser applets in C++, why wouldn't you? I suppose...

I had to try it myself. The install instructions are for Firefox, but I dumped Firefox for Chrome a while ago. It's good that Chrome has some Firefox in it, because all I had to do was copy the plugins for Firefox into my Chrome Plugins directory (it's hidden in Local Settings, Application Data, Google, Chrome, Application, Plugins).

I was then able to go through their little demos and tests. They're cute and the Mandlebrot demo shows some of the power. There's also a demo of the open source SDL version of id's Quake. It's pretty complicated to build and I couldn't get it working on my Windows box (mainly because I'm Cygwin-free and it seems to need it). But it's an interesting idea, taking an SDL-based application and converting it to run in a browser (Native Client uses SDL to do audio and video). Maybe, they'll even expose OpenGL through SDL to the native code as well. That would be more interesting.

One thing though that burst my bubble with this whole experience were the results of the performance tests that they have. The C++ version of the tests were only marginally better than the JavaScript ones. I think that's thanks to the great job they've done with the V8 VM. If that's the case, I really wonder whether this stuff actually makes sense, other than porting old software rendered games to your browser, I guess. I need to stew on that one a little before buying into this idea.

A busy day for Khronos

My Khronos.org News feed filled up all of a sudden today. Looks like they've been busy and had a couple of announcements to make.

They released a new version of the 2D OpenVG spec. They added some APIs for text glyphing to make it easier to draw good looking text. I'm not sure anyone really uses OpenVG, especially when you are most likely to be drawing 2D in a web browser with Adobe Flash or SVG (and even then, most likely Flash). From the news release, this is probably most interesting to the mobile crowd.

The more interesting announcement for me was the release of the first OpenCL spec. OpenCL is a standard for running general algorithms on the newer GPUs in video cards. It'll also be ported to other multi-core systems like Cell and DSPs, but most likely you'll be using it with a video card. Of course AMD and nVidia were quick to announce their support for this spec, which gives it some immediate momentum.

OpenCL specifies a C-based language for parallel processing as well as APIs that drive them. Up until now, nVidia and AMD had proprietary solutions that didn't work cross platform. OpenCL opens the door to make parellel programming available to more and more programmers and I'm dieing to see what they'll do with it...

Wascana 1.0 in Alpha Testing

Well, that didn't take very long. I've spent a few hours building my special p2 artifact repository that manages installed files, including extracting them from an archive and deleting at uninstall time, along with it's associated p2 touchpoint that hooks it all up. It's not a lot of code and you can see it in CDT's CVS space (repo: /cvsroot/tools, module: org.eclipse.cdt/p2).

I've also created a generator that creates p2 repositories that use that touchpoint to install remote artifacts from various locations, mostly on SourceForge. Currently I only have support for the MinGW toolchain and the MSYS shell environment. I'll add libraries as I build them with the 4.2.3 compiler I'm using here. I'll start with SDL and also do wxWidgets and boost. We can always add more later.

It's working very well. Managed build picks up the mingw toolchain and uses it when you select the MinGW toolchain. MSYS doesn't work yet for Makefile projects but managed is usable now. And here's how:

1. Unzip the Eclipse IDE for C/C++ Developers anywhere you'd like on your machine. You can also start with any other Eclipse install as long as you have the CDT installed.


2. In Software Updates, expand out the tools/cdt/releases/ganymede site into CDT Optional Features and install the Eclipse CDT p2 Toolchain Installer feature. Allow Eclipse to restart to make sure things are initialized (I'm not sure if you really have to do this, I'm just paranoid).


3. Go back to Software Updates and add the Wascana repo site at http://wascana.sourceforge.net/repo. Install everything under the MinGW Toolchain category. This time you don't need to restart. You don't even need to apply changes.

Once you're done, you can go to the directory containing eclipse.exe and you'll see the mingw and msys directories there, ready to go. Well at least the mingw dir is, I still need to set up msys correctly to find the mingw compilers, but it is only an alpha :).

Feel free to give it a try and let me know what you think. I'm pretty excited with how this is going. While creating this, a new version of the win32 API component came out and I added it to the repo and the Update... feature found and installed it. Very cool!

It's a very interesting path where this is going. The ability to incrementally add in libraries and update new versions of the components will be a great showcase on how p2 can manage more than just bundles. Not to mention help me build one heck of a Windows development environment based on the CDT and open source tools and libraries.

Linux Kernel Debugging with CDT

Just ran into this awesome tutorial on how to use the CDT for debugging the Linux kernel using qemu's gdb remote debug service that makes it work much like a standard hardware/JTAG debugger.

This was something I played with a while ago when I looked at adding hardware debugging support to the CDT as an optional service. And I believe Elena from QNX has continued on with that work and we should hopefully see it completed for Galileo (if not before that).

But it further solidifies for me how important qemu is as a tool in the belt of the embedded software developer. We've seen it as a key enabler for Android without which I'm not sure it would have achieved the momentum it has. I think there are still issues with it, and of course one I'm looking at is ease at adding new hardware emulation and 3D graphics support. But I think there is plenty of opportunity there and being an open source project, the door is open to help make that happen.

The Future of Wascana

For those that don't know, I've been working on the side on a complete open source IDE distribution for Windows called Wascana Desktop Developer. It includes the CDT and the MinGW tool chain and a handful of libraries that enable cross platform development. I did the original "beta" release over a year ago and have over 12,000 downloads to date. But it's getting long in the tooth and I really need to respin with Ganymede Eclipse/CDT and gcc 4.x.

The question I'm dealing with now is what Wascana should look like going forward. My Wind River team and I are just wrapping up a p2-based installer for our Wind River products that are similar to Wascana but on a much bigger scale and targeting our Wind River platforms. We've learned a lot about how to extend p2 to manage the install, update, and removal of archived binary files into an install tree.

I want to bring that similar experience to Wascana and have started working on an open source version of these extensions. I'm starting doing it as part of the CDT since I need to support CDT 5.0.x with it and want to release around Christmas time. Once I check it in, the p2 team can look and see if the want something like this and give feedback on changes that would be needed to get it into an upcoming platform release.

In the end, Wascana will mainly be a p2 repository that ensures you have all the plug-ins installed to get a working CDT for MinGW, and that will allow you to download and install the MinGW tool chain and libraries, either from their home locations, or from the Wascana SourceForge download area if I need to rebuild for whatever reason. Updates and new components would be done by adding them to the repository.

So the question becomes, do I need an old time installer for this, or would the community be happy simply downloading the Eclipse C/C++ IDE package and working with the Software Updates tool to get everything they need. I have a feeling people will still be looking for that single setup.exe download to set everything up. Then I need to ask whether laying down the bits is sufficient, or whether I need to do a p2 director thing.

The good news is that I sense MinGW is maturing. Despite having an unmanaged release cycle (and I do have a second source for the mingw gcc tool chain thank goodness), it looks like it's ready for prime time, at least for my little distro. Enough so, I'm giving up on Windows debug support. My focus is cross platform, and my time is limited and building a pure Windows debugger is hard and without a significant contribution it won't happen, so I'm not counting on it. Wascana will do just fine without it.

Javascript and C++, eh?

I can't get my mind off of Dave Thomas's keynote at Eclipse Summit Europe. His words made so many things crystallize in my mind. I've stated many times before in this blog and in my day job, I hate Java. It's an incredible irony that I do my day to day coding in Java to support developers who focus so much on efficiency and performance and use C mainly to accomplish that with a sprinkling of C++ for good measure. And then to hear their constant complaints that Eclipse is too slow. My good friends in Java VM land tell me not to blame Java for that, but you know, it's so tempting.

Dave mentioned that applications should be written in C++ and JavaScript. I dunno. C++ has it's difficulties, there is no doubt. It's hard to write good C++ programs. That's why the mix with JavaScript made me think. Does it make sense to build an application where your hard core performance focused code and code that interfaces with the underlying system is written in C++, but all the code that manages interactions with the user is done in JavaScript?

I've started to take a look at Google's V8 JavaScript engine. As they say in their videos, they're built for embedding in C++ applications and they have implemented some interesting tricks to get JavaScript to run fast, such as a JIT compiler and some heuristics to make class property access faster. As well, they have an efficient memory management system which includes being able to persist snapshots of the heap, including the JITed code, out to the file system for faster startup.

That got me thinking of Eclipse, of course, or really IDE's in general. What if you take a cross platform GUI toolkit like wxWidgets, add in a component model to allow for dynamic extensions, plus rewrite the CDT parsers in C++ for speed, plus ..., and throw in a JavaScript engine like V8 to make it easy for users to program, wouldn't that make for an interesting architecture? But we already have Eclipse so why would we do that all again? Just a question...

An Interesting Ottawa Demo Camp

The Ottawa Eclipse Demo camp was tonight and I thought I'd write about it before I went to bed. The demos were quite interesting, a different mix than before which keeps it fresh. And the hospitality of the Foundation staff was awesome again.

I was especially intrigued by Nick Edgar's embedded web UI demo that he's working on as part of Jazz. This is something I thought of doing for my talk at ESE. Present information in a web page using Eclipse's embedded browser. And then have JavaScript on that page interact with the surrounding Eclipse environment. The workflow he showed was very clean and I think there are some pretty cool things we can do with this. The technique he used was quite a kludge and even he admits it (communicating through the status bar?) But the SWT guys are thinking of better ways and I can't wait to try this myself.

The other interesting demo was from the Zeligsoft gang. I worked with some of the fellows that started Zeligsoft. We were part of the Rose RealTime development team. It was interesting to see the product they've come up with and the simularities it has with the stuff we did back then. They're betting the farm on model driven development. I can't say whether they'll succeed or not, but they've done a few things better, but a lot is the same.

I also have to thank Boris and Eric for their demos on e4 and the model-based UI in particular. I have a better sense of what they are trying to accomplish. Whether it's better or not than what we have today, I'm not sold yet. But I'll have to give it some hands on before making a final judgement.

I also got some interesting feedback on my article on IBM and Eclipse. (BTW, it's not whether we can survive, it's that we better plan and make sure we can, which I think we're finally doing). There were a lot of IBMers at the Demo Camp which was good to see. And there were as many ex-IBMers there too. I think it's pretty healthy. The Eclipse expertise is spreading throughout our small and tight knit town and Ottawa has a great concentration of Eclipse expertise, which makes it a great place to be.

Long Live the Benevolent Dictator

The last few weeks I've been nose to the grindstone finishing up our first Wind River product release with a new p2-based installer. It's been a while since I've been involved in commercial development and, though it's been grueling and has taken me away from my CDT project lead duties, I can see the light at the end of the tunnel and it looks like we'll be able to ship on time and with good quality, but maybe without all the bells and whistles I had hoped for when we started.

It's good to work in the corporate structure again too. If there are any decisions to be made, we have the processes and organization in place to make sure those decisions get made and that all the loose ends get tied up. It's the only way to succeed. You need that structure to make sure everyone is going in the same direction and has the same objectives.

So that got me thinking. Looking at my involvement with the CDT, I have had feedback that people looked to me as the guy to make the decisions, or at least to adjudicate any conflicts. To be the benevolent dictator at times. And we ended up getting a lot of things done over the years and everyone working on the CDT was going in the same direction. We sort of made up a structure where one didn't really exist, because we needed it to be successful.

I have big fears for e4 on that front. McQ and the IBM gang has made it clear over and over again, including on today's e4 call, that they are working on what they find important, and everyone else should do the same, or nothing will get done. And there are a few things going on. I'm leading the resources effort and we're working on things that individually are important to us and our employers. And clearly the SWT team is doing the same. But as hard as I try, I can't figure out what the UI guys are trying to accomplish. And then there are lots of things in the Eclipse Platform that no one is looking at. Debug, for example.

I firmly believe that even with open source projects, you need that benevolent dictator to actually deliver things. Where would Linux be without Linus? Where would Eclipse be without the early dictatorship of IBM? And there are countless examples. Where you see a successful open source project, you find an individual, or a small team, who make decisions and ensures everyone is working together. I get the sense that people think that's anti-open, but I can't see how a project, open or not, can succeed with out one.

Can Eclipse Survive Without IBM?

I bet you this title got your attention...

Let me tell you a story. It's one a lot of us Eclipse "insiders" know from our trip to Ludwigsburg, Germany. If you look at the program for Eclipse Summit Europe, you'll notice a distinct lack of Eclipse Platform committers, i.e. IBMers, presenting. And one of them was lucky enough to get his travel approval the Friday afternoon before the conference. The Summit was a resounding success despite that. The Eclipse community in Europe has gone well past caring about the traditional Platform and are looking at really cool technologies like OSGi with Equinox and Modeling (despite Dave Thomas' decree that modeling sucks, which it does, at least UML-like modeling).

Now, I'm not sure if this year is any different from previous ESE's. But with the discussions we're having on the EclipseCon program committee about how many IBMers will be able to attend to give their presentations, it's got me thinking. What happens if this apparent trend continues and we loose the commitment IBM has made to Eclipse. Can Eclipse survive without IBM?

Well, I can say Wind River is doing their part to help out. We have myself and Martin O working on the Platform Resources evolution for e4. And we have Pawel who's now a Platform Debug committer. And as always, we're doing major contributions to the CDT and DSDP projects. And the numbers show the Eclipse committer community continues to grow and a lot of projects are healthy.

So can we survive without IBM? Absolutely. In fact, I'd consider the Eclipse Platform feature complete, at least for the needs of IDE and RCP/OSGi vendors. Yeah, things could be cleaned up, and yeah, we could make Eclipse work with Web 2.0 (although I really question whether SWT is the right technology for that). But from what I saw in Germany, Eclipse is alive and well. There are some really cool things that are going on and while the platforms are stabilizing and are probably becoming less interesting (and I'll sadly include the CDT in that list), I get the sense that those relying on the platforms will keep them alive. They have too.

Code Analysis and Refactoring with the CDT

For those that missed my talk at Eclipse Summit Europe, here are my slides. Unfortunately, that's pretty much all the documentation we have on this capability, as I mention in the next steps slide. The community needs to step up and help with this if we want this capability to grow.

Code Analysis and Refactoring with CDT

View SlideShare presentation or Upload your own.

CDT at Eclipse Summit Europe

Well, the closing session is about to start and the vendors are packing up their displays. Another successful Eclipse Summit Europe is about to go off into the sunset. For me, it was proof again why I love coming to this show. The CDT community in Europe is strong and a lot of them are doing and want to do interesting things with the CDT.

The talk I gave was on the code analysis capabilities of the CDT introducing the things you can do with the CDT's parsers and indexing framework. I also introduced the new refactoring engine that we have which really opens up a lot of cool automations you can do to analyze and refactor your code. The best part is that I had a few guys come up to me after to ask about certain analysis things they wanted to do. I'm glad I gave that talk and I hope more people take a look at what the CDT has to offer in this area.

I also had a number of people ask about the CDT managed build system. This is an area in a bit of trouble right now with the CDT. One of the key developers has left and we're struggling understanding the code that he left behind. Hopefully these vendors who have concerns about the build system will join us and get us rolling again. The CDT build model can do some pretty cool things and I look forward to seeing the different build integrations people are thinking of working.

I had a discussion with someone interested in working on the Windows debug integration I have on my wish list. I've given it a couple of tries and there is a start of one in the Target Communication Framework (TCF) agent. Hopefully we can finally get this together and have full support for the Visual C++ compiler with the CDT.

Speaking of TCF, there was a lot of interest in it from various embedded system vendors. It's a really good technology for building target agents with a clean communication protocol back to Eclipse and a services oriented architecture. I've been interested in component models for C/C++ applications and I can see how this agent could use something like that. I'll have to give it some thought and see if others are interested in getting involved in that.

It's been a fun and interesting week. Hopefully I talked to everyone who wanted to talk CDT with me. And hopefully we can get some momentum off of that to continue the growth of the CDT community. Those late nights in the hotel bar with the Eclipse gang was part of that community building and I'm going to sleep well on the flight home but it was worth it.

Thoughts on Dave Thomas' Keynote

Ed Merks already gave a summary of Dave Thomas' keynote yesterday morning here at Eclipse Summit Europe. It was the first time I saw Dave speak and I was warned he tended to say things that offended the audience. And to Dave's point, that is kind of what a keynote speaker should do. Spark thought. Break through the assumptions that we tend to fall into when we get comfortable in our skin. And I think he raised some serious points that are making me wonder about what's really happening in our industry.

I guess his main point is that Java for embedded has missed the boat. If you haven't gone through the pain of doing Java for embedded devices, don't worry, you didn't miss anything. I've been waiting to see when I need to care about Java in this space and I've talked to some of the people here at Eclipse Summit Europe about this. I think they quietly agree with Dave. Those that have figured out how to do Java on embedded are doing OK with it. But there are a lot of issues to face. The worst of them is the bloat that the Java VM continues to grow from release to release. The embedded VMs are horribly crippled, and if you want to use the Sun VM, you are crippled from paring down that bloat. The discussion is interesting, and we may still be proven wrong, but for now, I can ignore Java for embedded and I can sleep at night.

There were some other messages from Dave that hit home as well. Programming is horribly complicated. Normal people will never be able to figure it out. Which means if you have figured it out, you're not normal, and I guess that includes me. But it is true. I've blogged a lot about this in the past. We can barely get our programs to work as it is. Wait until you're trying to program 100 threads running through your mess all at the same time. We're doomed.

But there are some things we can do to give us a chance to survive. Dave talked a bit about how the lack of a software component model is making us look like fools in the eyes of the engineering community. Can you imagine if automakers had to custom build all the components that make up a car? Imagine now if we could go to a shop and pick up high quality software components and tie them together will few lines in a script.

Now Dave was be extreme in his position. There are a number of areas where component models are being used, OSGi is an obvious one, all these "Mash-ups" are doing things like this. But coming back to embedded, we can't rely on Java to provide the solution. Dave's answer was C++ with JavaScript. And I think that's a great idea. Build components in C++ and tie them together with a scripting engine. Dave picked JavaScript, which is OK but he did mention he's working with Google on their V8 JavaScript engine. Lua is another good choice. And actually Domain Specific Languages offer solutions as well (and I'm not just saying that because I'm sitting in Rich Gronback's DSL talk right now ;).

It was really interesting to spend time with Dave Thomas in his keynote and with a group of us at the hotel bar. I could learn a lot from him. This week it was to open up my mind and challenge the assumptions. If you read this blog regularly you find that I tend to do that anyway, but it's an important reminder to keep doing that and make sure we don't make the same mistakes over and over again.

You want to see a busy mailing list?

Just check here: http://lists.gnu.org/archive/html/qemu-devel/2008-11/threads.html

I was looking to see when qemu, a very cool virtual machine for many hosts and many target CPU architectures, was going to come out with a new release. As part of that, I was checking to see if it was under active development. Well, with 55 e-mails on November 13'th when I looked, I guess it is :).

I did find a conversation back in October about 0.9.2 which will likely include some new technology called TCG that will eliminate qemu's dependency on the gcc 3.x compiler. That's good news since I want to release Wascana 1.0 with the gcc 4.x compiler and I want to use Wascana 1.0 as the base IDE for my EcilpseCon tutorial on working with cross-development environments. I hope it all comes together by March.

Speaking of which, only 11 more days until submissions close for EclipseCon. Get them in early and get them in often. And soon!

Now that's small.

Just ran into this article on LinuxDevices.com. It talks about a tiny computer that looks like this:



That's all there is to it. This ethernet jack has an ARM9 processor in it with 8 MB RAM, 4 MB Flash, and some interfaces that you can hook up electronic devices to. The idea is to add network connectivity to devices that normally don't, like air conditioners and stuff. Apparently there's even a WiFi version of the thing.

I found a couple of neat things about this device. First it gives you network access to pretty much anything allowing for centralized controllers to manage those things. This is probably old news to guys who work on building maintenance automation systems and stuff like that. But this device somehow made it all real for me.

The other thing to note is the memory size here. 4 MB Flash for the file system isn't very big. And neither is the 8MB RAM you run with. If anyone ever asks if C is still important, I'll just point to this thing.

And finally, I had to have a chuckle when I saw this: "the kit includes an IDE based on Eclipse 3.1.2 and CDT 3.0.2. It supports C/C++ devlopment, CVS code management, and visual debugging via Ethernet." Yet another vendor using the CDT to build cool things :).

Design like you'll be there in 10 years

I probably blogged about this a long time ago. I remember watching the news conference for the landing of the Mars Spirit rover. I had watched the landing live over the web and remember the jubilation of the team members as they received the first signal alerting to the safe landing. At the news conference one of the project managers mentioned he had been working on the project for 10 years (through one previous cancellation that is, but still pretty darn good). He was beaming to see the success. And it was well deserved.

That idea entered into my book of software design philosophy: design like you'll be working on the project for 10 years. Think of the responsibility that would mean. In 10 years, you'll be paying for the short cuts and short sightedness. So don't.

Well preparing for my talk on static analysis and refactoring for Eclipse Summit Europe next week (yeah a bit of a late start, it'll be great, though), I finally have my own version of this story to tell.

6 years ago, my good colleague and friend, John and I started down the road of building a C++ parser for the CDT. My mentor at the time thought it was a crazy idea but we had a feeling that we could do it and we plowed ahead and actually got it to work. The parser allowed us to build a more accurate way of populating the Outline View (via the CModel). It then lead the way to indexing to allow for C/C++ Search and Open Declaration to work well. It was tough and we fought the performance battles for most of it, but we soldiered on.

Somewhere along the way we started dreaming of C/C++ refactoring a la JDT. Everyone thought that was a crazy idea (despite secretly wanting it too). With all the madness of the C preprocessor mucking with the source code before it gets to the parser, how could you properly create the TextEdits that the LTK (which the JDT guys generously pushed into a common plug-in, BTW), needed to do the refactoring?

Well John put in a lot of effort and forethought and created a way to map AST nodes to location objects which allowed you to unravel where all the text came from to create the node. It wasn't perfect, but it was a start. And unfortunately due to the untimely end of our funding, we never got to finish it.

Well, I finally got a deep look at the work that Emanuel and is team at the HSR Hochschule für Technik Rapperswil have done on the CDT refactoring engine and early refactorings. Following it through the debugger, I hit it, IASTNodeLocation - that work that John had started years ago but never got to see in action for what it was intended for. It's been fixed up by Emanuel and CDT Indexer Master Markus, but it was doing what we had dreamed about many years ago. Weird, but it actually brought a tear to my eye.

But it really does prove the point. Design as if you'll be working on a project for 10 years. Even if you end up not being there, someone will be, and your work will live on, and it will be much appreciated.

Cross Compiling Fun for EclipseCon

It's been a busy couple of weeks for me as we get our commercial Eclipse p2-based installer into product testing. It's looking good but there's always those last minute fires (i.e. bugs) to fight.

In the background I've been trying to set up an environment that will allow me to use the CDT to build Linux applications from my Windows box, and then run and debug those applications on a customized version of the Qemu emulator that is also built using the CDT. Once I get this environment together, I plan on presenting how to do it at EclipseCon as either a tutorial or long talk. It's a great demonstration on how well the CDT works for multi-platform development.

My first step was to put together a cross compiler. The gcc compiler suite is great at it, but it's not obvious how to do it on Windows. Most GNU packages are hard to build on Windows, even with the MSYS environment from the MinGW gang, or Cygwin.

I first tried with MSYS. I copied over the C library headers and libraries and then tried to build binutils to get the assembler and linker, and gcc itself for C and C++. I was generally following the instructions here. I got really close, but unfortunately I ended up with a linker error when creating the gcc compiler support library (libgcc). Grrr.

Thinking about my reference article a little more, I remembered that even the MinGW developers build MinGW on Linux. I then discovered that the Linux distribution I am using (Debian lenny) already has the MinGW cross-compiler and libraries as a package. So I installed that and I suddenly had the ability to build Windows executables on Linux. So given that, I built binutils and gcc on Linux so that it would run on Windows to build executables for Linux. Wow. That's quite a few levels of indirection. But it worked!

Now all I need to do is build a CDT integration that puts the i686-linux-gnu- prefix on gcc and puts the location of the tools in the PATH and I'm ready to build Linux apps from my Windows laptop.

I'm looking forward to showing this off at EclipseCon. It's talks like this that show practical uses of the CDT and extensions people can build for it that we really need to highlight to the community at EclipseCon. Mine is only one, we need a few more. So if you have an idea, feel free to go to the EclipseCon site and submit a proposal.

Why a good platform can't be free

I sure am having fun thinking about OpenConsole, i.e., a Linux based set top box that plays in the same space as Microsoft and Sony and Nintendo, but is really an evolution of the Home Theater PC (HTPC) into gaming, but all using open licensing so you don't have to pay the big boys to write applications for this platform. The underlying technologies are pretty cool as I play with adding OpenGL graphics to the qemu emulator. But the business side of it is interesting as well.

In particular, my thoughts turned to multimedia support on open platforms. This is where the insistence on Linux being free is really biting the hand that feeds you. Not all good software can be free. We do live in a world of patents and a lot of the key technology that goes into a multimedia system is protected by patents and require a license to legally distribution implementations of that technology.

You know, I have no problem with that. As I've stated in the past, complex algorithms are hard to get right and multimedia is complex to get good quality results. And I don't blame the creators of this work wanting to get something out of it. If they didn't, they probably wouldn't have created it to begin with and we'd be waiting for some kind soul to donate this for free. Wishful thinking I'd think.

But you know, the costs aren't that bad. One I was looking at was the DVD format licensing. There is a company in Japan that controls this and their pricing information is here. It's about $5K for the book (under NDA), $15K for the license, then another $10K or so for verification. That's not too bad if you're selling thousands of units. But it's also not zero. And the NDA also prevents the implementation from being open source to begin with anyway.

And there are similar fees for the very popular MP3, (minimum $15K). Blu-ray is similar. And some of these are yearly fees. So as you can see, if you want to produce a multimedia platform you can redistribute, the costs are non-zero. So why do people expect these platforms to cost zero...