Monthly Archives: September 2009

Remember PluginFest?

It’s been a while since it was held. The Eclipse PluginFest was a really cool event organized by Ian Skerrett and hosted by the folks at Symbian in London. It was part marketing event and part engineering event intended to show how off the promise of Eclipse as a platform by doing some interoperability testing between the different products, focusing at the time on the embedded/mobile market. For the most part, it was a success, especially for tools up the stack like analysis and modeling tools.

But one thing that was clear then and is still true today is that plug-ins from platform providers, generally vendors that provide tools for building applications and customizations for their operating systems, don’t mix. In fact most of them assume that you are not building for other platforms and many of them have their own version of the Eclipse platform.

But as I take a look at the mobile space, it is clear that an application developer if they want to hit the largest possible market, are going to have to target multiple platforms. I don’t see one winner taking hold yet. iPhone is in the lead, but Android is making progress, and the others are hungry for a piece of the pie.

The question is who owns that problem? I looks to me, anyway, that the platform vendors are actually more interested in locking developers into their platforms. That is most obvious with iPhone and the fact you can only use Macs as development hosts. The Android plug-in assumes you are using Eclipse only for Android development, breaking a number of UI guidelines along the way (I don’t want to hear from it if my current workspace has no Android content, damn SDK location dialog, grrr).

I have no answers. My hope is that the newly renamed Sequoyah project looking at tools for mobile can be a focal point. That will require more vendors to participate in it. I think it’ll also require the developer community to stand up and demand more from the vendors and maybe Sequoyah would be a good venue for that. At the end of the day, who is looking out for the poor app developer who needs to deal with all this?

Phone Games To Hurt Console Market?

Just read the NY Times article here that claims Apple is casting a shadow over the console game market. Of the 758 games shown at this week’s Tokyo Game Show, 168 were cell phone games. That’s a big number. I’m not sure if the premise is true, but it does open your eyes to a change that is underfoot.

And I think that’s were my excitement over the mobile software space is coming from. These cell phones, like my personal HTC Dream Android phone, are decent little gaming machines. Now you aren’t going to play first person shooters like I was earlier today with Halo 3 ODST, but for casual gamers they’re a hit. And we see it today with the iPhone. When someone shows me their iPhone, it’s usually to show off a game running on it.

Android has some growing to do to be a good software platform for mobile games. Good games need to get all the horsepower they can out of the phone without draining the battery, i.e. you need to write as much code to run natively as you can. Until Android gets support for OpenGL and other platform libraries needed to make games into their NDK, gaming on Android will be on a slow growth curve. But once it’s there, watch out.

The new platform that caught my eye this week was Moblin, and not just because Intel owns Wind River (my employer). There was a big teaser announcement on Moblin, which until now was a netbook OS, being ported to run on Atom-based phones of the future. Taking a deeper look, I was pleased to see that Moblin really is a Linux “standard” distro with all the gaming libs you need, like OpenGL, gstreamer for audio, SDL for IO, that you get on a desktop Linux distro. I can’t wait to see Atom in a phone and see how it compares to the iPhone and Android platforms of the day.

As I keep mentioning here in this blog, it’s a great time to be a programmer if you get into the mobile space. There’s so much innovation there, and so much opportunity to create something new. And being a non-traditional environment, it’s a great place for Eclipse based tools to become the defacto standard, especially the CDT with it’s flexible toolchain support and all around IDE goodness. There is activity going on in the community to bring that goodness to these platforms and I can’t wait to try them out.

CDT 6.1, We’re not done yet!

We had a couple of really good planning sessions so far this September as we put our plans together for the next release of the CDT, CDT 6.1 for Helios. We’ve been focused on Build and Debug. We’ll continue to move the sticks forward for the editor and parser based features, but build and debug still have some major work to do.

On the build side, we’re focused on improving the CDT Scanner Discovery mechanism that scans build output to try and figure out the include paths and defines that you are using for your build. That information is fed to CDT’s parser to replicate the parse your compiler does. And that gives us pretty good accuracy to enable things like open declaration and content assist. This work will be a big challenge as we have a bit of a rag-tag group of part timers to try and get this problem area for CDT integrators and users fixed up. But it’s a great challenge for me as a project lead to see if we can get as much done as we can.

On the debug side, there’s some exciting news. As Ken Ryall from Nokia has been blogging lately, they’ve been working on a new debugger that’s much more tightly integrated with the CDT, and they’re ready to contribute it. Essentially, it’s a replacement for gdb. Now you can argue whether that’s a good thing or a bad thing, but I think it’s a good opportunity to improve CDT’s debug ability. And of course, it’ll be able to sit along side our gdb support which continues to be important for a number of vendors.

But part of Nokia’s work that has me most excited, is the native Windows debug support. This is an important step towards finally getting a complete Visual C++ integration for the CDT. I have a build integration almost ready to go. All that was left was debug support. While it is still missing support for Visual C++, Nokia’s Windows debug API support gets us maybe half of the way there.

The other good thing about Nokia’s work is support for gdbserver as the small agent that does the bit twiddling. Those who’ve done embedded development know about gdbserver as that’s how you do remote debugging of targets using gdb. Reusing gdbserver gives Nokia’s work a huge leg up for embedded developers working on all platforms that support gdbserver.

So despite being 7 years into our program, there is still work to be done on CDT. The community is still vibrant. We don’t have the big vendor contributions like we used to, other than Nokia of course, but there is still a lot of work to be done and individuals and smaller vendors who are interested in helping. So to quote Monty Python, we’re not dead yet :).

Eclipse Tools for Mobile Needs Some Buzz

I attended my first Sequoyah (Eclipse tools for mobile, except J2ME, but that’s another story) meeting today. Why am I? Well I’m getting more and more into mobile app development in my hobby time, at least for Android anyway, and I’m turning that into a personal focus on better support in CDT for mobile application development. We can then make this available for platform vendors who want to better support developers making applications for their platforms.

My plan is to start by building a set of plug-ins that automate at least the build setup for Android JNI development. Debug is another story and maybe someone else can help with that. And we can look at what’s needed for other open source mobile platforms down the road as well. And maybe some other vendor will come along and help out.

But, as I dig into what’s happening with mobile at Eclipse, I’m a bit surprised, and disappointed, about how little there actually is. Motorola is putting forth a great effort and contributed a significant amount. As with most vendors (almost all) that contribute to Eclipse it is mainly focused on their own commercial needs. But they also don’t seem to be getting much help from anyone else. It takes multiple companies to make a platform and it’s sad to see that isn’t really happening, despite all the marketing buzz surrounding Pulsar.

And I was also saddened to see Craig Setera’s blog for help for the Mobile Tools for Java project. MTJ is probably the project hardest hit from vendors coming and going that I’ve seen. And after the push to get Craig’s EclipseME project merged in for the reboot, I was hoping for greater things there.

On the Sequoyah call, I was asked for advice on how we could solve these things. Man, it’s tough. You really need a community, and in particular, a vendor community, that has a vested interest in contributing. We had it easy with the CDT. Everyone needed an extensible C/C++ IDE and it made business sense to invest a person or two to help make it happen. I had it pretty easy as a project lead, and I feel for Craig and the Motorola gang as they try to get this thing going.

The only thing I can come up with is a trick I used in the “dark” days of the CDT after my team at IBM were reallocated. “Create the need”. Find something that vendors will see the need to invest in. Usually, this is in the form of some platform piece that they know they need and that multiple vendors can work on, and then show that not enough people are working on it so it’s going to suck in their product too.

I’m not sure that’s going to work here since there seems to be a huge hesitation to make contributions from the vendors who could be contributing. But that was true with the CDT in the early days too. It was the QNX+Rational show for quite a while until Intel and TI broke the ice.

At any rate, I’m posting this as an attempt to help Eric C out. I’d really like to see Sequoyah succeed and for us to have a nice set of platforms and examplary tools for mobile app development at Eclipse. But that won’t happen without growing the community and we’d certainly be interested in your thoughts on how we can make that happen.

Apple leading the way in multi-core programming?

One of my pet study areas is programming paradigms, something I’ve done since my university days looking at SmallTalk (object-orientation) and Ada (safety critical). The next great next battle line is how to take advantage of multi-core machines to do parallel computing without blowing our poor programmer minds. Intel is doing a lot of work in this area and it’s really interesting that Apple is doing the same. I’m not sure why, but good on them.

The two technologies that seem to have sprouted from them and are supported in Snow Leopard are OpenCL, the Khronos standard for mixed GPU/CPU computing, and Apple’s Grand Central Dispatch, a task parallelism extension to C, C++, and Objective-C with something called Blocks. There is a recent report from Hardmac.com that shows some real significant improvement form these technologies.

I don’t know much about either, but this is definitely something I’m adding to my reading list for those nights I can’t get to sleep (which if you’re following me on twitter you’ll notice are happen regularly).

State of the Doug

I’ve been tweeting a lot, but tweets tend to be temporal things that disappear after a short time, so I figured I should blog some of those things. Assuming anyone really cares, but that’s part of the mystique and something I call the “cricket factor”, when you tweet or blog, and no one’s listening, and all you hear back are crickets in the night. But anyway, here’s what I’m up to lately.

I made quite a splash recently stating my frank opinion on e4. I had lots of good feedback on that and I pissed off a few people. But I met my objective of making people think about it. To summarize, I worry about the stability of the platform and how e4 will impact the hugely understaffed projects up the stack. And I don’t like RAP. If you’re running web apps, follow the investment in JavaScript engines and put your UI code in the browser. Which also means I don’t care much about the e4 UI work either. But as one e4 committer mentioned to me, “it’s fun”. I’m sure it is.

As cool and interesting my investigation into GWT has been, I barely get a day a week to do open source work and I still have a couple of things I want to do with the CDT, i.e., help clean up the build system, and support JNI debugging. And I want to spend my hobby time on other things. So enough of that. A lot of people get GWT and how it works well with Equinox, so it’ll live on without me.

As for my hobby time, I am getting more and more pumped by what’s happening in the Android space. So I’m turning back to that and hope to feed my curiosity on game development by making games for Android. Not sure I’ll ever get far enough along to get something on the Android Market, but it’ll make a good winter activity. And who knows, maybe we’ll see Android running natively on Intel chips some day.

So that’s where I am. I have way more ideas than time to work on them having a family and all. But I’ll continue to blog and tweet things as they come to me, at least as they relate to open source, and maybe that will help others, or maybe it’ll just feed the crickets.

Using CDT for Android Native

Android has a native development kit (NDK) which can be used to create JNI native code for Android applications. In this video, I show how I convert an Android project in Eclipse to add the C/C++ nature to it and set it up to build the shared library that gets included in your Android apk file. This gives you all the power of the CDT in combination with the JDT to build Android apps with native code. Except for debug, though, as JNI debug remains the lost holy grail for the CDT…

If you want to look at the code from the demo, you can clone or download from http://github.com/dschaefer/androidDemo.

Link to YouTube