Ian hinted at it in the recent flurry on Planet Eclipse and Mike just offered an extra teaser. For me, the concept of an Eclipse forge, or "Eclipse Labs" is set to change the way open source developers see, consume, and contribute to Eclipse, and more importantly, to dramatically change the culture at Eclipse.
Everyone seems to be looking for a technical solution to keeping Eclipse relevant, e4 case in point. In the end, that's not enough. We need to grow the Eclipse community beyond it's traditional realm of corporate engineers, into what we more traditionally think an open source community should be, free. Free to work on what you want, free from someone saying no to your contributions (within reason, of course). To be free as you are when working with SourceForge, but still be a member of the Eclipse community.
I'm still waiting to hear the details on the rules and mechanisms for the Labs. But if it turns out like I think it should, ;), then I'm super pumped. Pumped enough to bring Wascana out from the freezer and make the real Eclipse C/C++ IDE for Windows that should rightfully be an Eclipse community project, not hidden out on SourceForge. That will require the Lab to ship GPL'ed software, i.e. the GNU tools, and LGPL libraries. Is Eclipse ready for that? I'm hoping.
Monday, December 07, 2009
Thursday, December 03, 2009
Multi-Core Programming, Paradigm Shift Required
I just caught myself sending 4 tweets in a row on the same subject. That's probably a sign I have a blog entry topic at my finger tips.
I was reading an article entitled "Microsoft's top developers prefer old-school coding methods". Whoever picked that title clearly missed the point of the panel discussion he was covering, but it's an awesome read.
The panel involved a handful of distinguished engineers from Microsoft and they were discussing the future of programming technologies. And hilarity ensued! It reminded me so much of the discussion we had about JavaScript at the end of the Ottawa Eclipse DemoCamp last week. There was much hilarity ensuing there as well.
At any rate, I totally agree with what these guys are saying. Everything we're doing to innovate in programming around graphical programming languages and concurrent programming is crap. Here's some of my favorite quotes from the article:
re graphical programming: "when you have 500 things, graphical programming is completely unusable. You zoom in and zoom out and you lose all context. I think it's just smoking dope." (a similar comment was made about using JavaScript to build complete apps at the Camp).
re managed code: "lets developers perform above their level of competence. It's like antilock brakes". (They were talking about CLR, but I'd include Java in that).
re abstractness: "programming is getting so abstract, developers will soon have to use Microsoft's Natal to write programs through interpretive dance." (That I don't want to see).
But the one quote that really confirmed what I had been thinking about multi-core programming: "It will be a long time before parallel programming becomes mainstream. Because of the bias towards sequention programming, we'll still be reinventing ourselves as parallel programmers 12 years from now."
This was a classic Ward Cunningham "A-ha" moment for me. I had hoped graphical programming could be an answer to break the sequential rut we're stuck in. But the usability of building complex programs graphically kills that. I think at the end of the day, we still need to look at hardware description languages such as Verilog and SystemC as holding the key. They are all about concurrency since the hardware they model is too.
I was reading an article entitled "Microsoft's top developers prefer old-school coding methods". Whoever picked that title clearly missed the point of the panel discussion he was covering, but it's an awesome read.
The panel involved a handful of distinguished engineers from Microsoft and they were discussing the future of programming technologies. And hilarity ensued! It reminded me so much of the discussion we had about JavaScript at the end of the Ottawa Eclipse DemoCamp last week. There was much hilarity ensuing there as well.
At any rate, I totally agree with what these guys are saying. Everything we're doing to innovate in programming around graphical programming languages and concurrent programming is crap. Here's some of my favorite quotes from the article:
re graphical programming: "when you have 500 things, graphical programming is completely unusable. You zoom in and zoom out and you lose all context. I think it's just smoking dope." (a similar comment was made about using JavaScript to build complete apps at the Camp).
re managed code: "lets developers perform above their level of competence. It's like antilock brakes". (They were talking about CLR, but I'd include Java in that).
re abstractness: "programming is getting so abstract, developers will soon have to use Microsoft's Natal to write programs through interpretive dance." (That I don't want to see).
But the one quote that really confirmed what I had been thinking about multi-core programming: "It will be a long time before parallel programming becomes mainstream. Because of the bias towards sequention programming, we'll still be reinventing ourselves as parallel programmers 12 years from now."
This was a classic Ward Cunningham "A-ha" moment for me. I had hoped graphical programming could be an answer to break the sequential rut we're stuck in. But the usability of building complex programs graphically kills that. I think at the end of the day, we still need to look at hardware description languages such as Verilog and SystemC as holding the key. They are all about concurrency since the hardware they model is too.
Monday, November 30, 2009
Diversity is not the only answer
Dave Carver started it and Pascal fed the fire. If you missed it, there are confusing and highly inaccurate statistics captured by the Eclipse Foundation that measure diversity in the Eclipse projects. Stats or not, there are a lot of projects where it's clear, there is one vendor paying a very disproportionate number of comitters that work on the project. And it's not always IBM.
But I think that misses the point. For open source projects to survive you need one key ingredient. Be OPEN! Simple, no? One reason that non-diverse projects suffer is that most of the decisions are made behind closed doors at that company. How many times has some feature or project just showed up one day, all the key decisions leading to their creation happening hidden in meeting rooms instead of out on the mailing lists. What kind of trust does that build?
A couple of Eclipse Summit Europes ago, I received the biggest insult I ever recieved working in open source. Having just joined Wind River, one of the attendees suggested that the CDT was just a Wind River project. After all the work I've done and career limiting decisions I've made to be as vendor neutral as possible in my work on CDT, I was hurt. But it drove home the point. Wind River was the elephant in the room, at least by perception, and that hurts trust.
I think Eclipse has a lot to learn from other successful open source projects. If we truely want to continue the success, we need to be real open source projects, not only in governance, but in culture too. That starts by dropping the vendor centric nature of the Eclipse projects and opening them up to everyone.
But I think that misses the point. For open source projects to survive you need one key ingredient. Be OPEN! Simple, no? One reason that non-diverse projects suffer is that most of the decisions are made behind closed doors at that company. How many times has some feature or project just showed up one day, all the key decisions leading to their creation happening hidden in meeting rooms instead of out on the mailing lists. What kind of trust does that build?
A couple of Eclipse Summit Europes ago, I received the biggest insult I ever recieved working in open source. Having just joined Wind River, one of the attendees suggested that the CDT was just a Wind River project. After all the work I've done and career limiting decisions I've made to be as vendor neutral as possible in my work on CDT, I was hurt. But it drove home the point. Wind River was the elephant in the room, at least by perception, and that hurts trust.
I think Eclipse has a lot to learn from other successful open source projects. If we truely want to continue the success, we need to be real open source projects, not only in governance, but in culture too. That starts by dropping the vendor centric nature of the Eclipse projects and opening them up to everyone.
Tuesday, November 24, 2009
Linux Distros, The Great Melting Pot
I've been talking a deeper look at Fedora lately as Fedora 12 was just released and I was checking out all the MinGW cross-development packages available there. While I was there I looked across all the packages included in the "Everything" folder. I even gave eclipse-cdt a try and was impressed to see 6.0.0 there (although 6.0.1 would have been more impressive ;)). It's also impressive to see so many of the Eclipse projects represented there. And just looking at the breadth of open source content, almost every open source project I've looked at is included, including the bullet physics engine, OGRE and Irrlicht game engines, blender the 3D modeling tool, clutter and mutter and even an early preview of the new Gnome Shell.
It's an incredibly rich set of libraries and tools, and it's got me jazzed for Linux again. And given the corporate virus scanner has finally found my Windows 7 install and is doing it's best effort to kill performance, I'm thinking again of going back. Windows 7 is pretty and I'm very productive in it, but I can see that the Gnome Shell has some of those same characteristics as I played with it on the Dell Mini.
The Linux distros are a great melting pot of open source technologies, and I think Eclipse is perfectly positioned to be the IDE of choice to work with those treasures. But playing with it, there are still a lot of architectural challenges we need to overcome to get there. Even just loading Photran (the Fortran tooling) and CDT together is a mess as both projects try to present pages for the properties. The big challenge we face in the Eclipse community is working together to make this better. I've mentioned this before, but the projects really do operate as silos, even Photran and CDT and we've tried hard not to do that, it's just too easy.
But it takes a group of people with the vision and the gumption to drive that vision home. I'd like the Eclipse Architecture Council to be that but as with all things Eclipse, it's really up to committers and the vendors that pay them to make this happen. Here's hoping someone does.
It's an incredibly rich set of libraries and tools, and it's got me jazzed for Linux again. And given the corporate virus scanner has finally found my Windows 7 install and is doing it's best effort to kill performance, I'm thinking again of going back. Windows 7 is pretty and I'm very productive in it, but I can see that the Gnome Shell has some of those same characteristics as I played with it on the Dell Mini.
The Linux distros are a great melting pot of open source technologies, and I think Eclipse is perfectly positioned to be the IDE of choice to work with those treasures. But playing with it, there are still a lot of architectural challenges we need to overcome to get there. Even just loading Photran (the Fortran tooling) and CDT together is a mess as both projects try to present pages for the properties. The big challenge we face in the Eclipse community is working together to make this better. I've mentioned this before, but the projects really do operate as silos, even Photran and CDT and we've tried hard not to do that, it's just too easy.
But it takes a group of people with the vision and the gumption to drive that vision home. I'd like the Eclipse Architecture Council to be that but as with all things Eclipse, it's really up to committers and the vendors that pay them to make this happen. Here's hoping someone does.
Friday, November 20, 2009
Chrome OS, it is what it is
I guess I got caught up in all the hype over Chrome OS. It's an idea I've bounced around for years as I mucked around learning about embedded Linux. Replace the standard Linux desktop UI with only a browser and throw it on a mobile device. With everything on the web these days, or at least a minimal amount to do something useful, why not?
But I could never escape the idea that you had to have at least some local applications to do things when disconnected, or to take advantage of the CPU and graphics power using native tools for things like games and multimedia.
So I downloaded a build of Chrome OS from gdgt.com to give it a try under VirtualBox. And, BTW, you got to love the tech community and how quickly they get activated when something cool comes along. While the release is about a year away, and the build shows it, you do get a sense of what Chrome OS, or Chromium OS which is it's proper name, is.
But I could never escape the idea that you had to have at least some local applications to do things when disconnected, or to take advantage of the CPU and graphics power using native tools for things like games and multimedia.
So I downloaded a build of Chrome OS from gdgt.com to give it a try under VirtualBox. And, BTW, you got to love the tech community and how quickly they get activated when something cool comes along. While the release is about a year away, and the build shows it, you do get a sense of what Chrome OS, or Chromium OS which is it's proper name, is.
You log in with your Google account and, bang, you're in the Chrome browser looking at your Google stuff.
But it is what it is. There's no application menu, no app market, or anything like that. Everything you do is over the web. I did notice an extensions mechanism, and maybe that's how you take advantage of the native environment, maybe not.
When I had thought of a Web OS, this summer, my thoughts turned to the Eclipse Run-Time and using that in conjunction with the browser to have local apps written for the Eclipse platform. I would also think you'd want to launch 3D and multimedia content full screen, or something. But that's not what Chromium OS is. It's web or bust.
So while Chromium OS is interesting, I'm way less excited about it. I think the door is still open for a netbook Linux platform that combines local native apps with the Web experience. Moblin is certainly making strides there for the consumer space. And I've been trying out the GNOME Shell which offers an experience much like Windows 7 for the power users. This story isn't finished yet.
Tuesday, November 10, 2009
Visual Programming for Multi-Processing
I spent a little time on the weekend taking a deeper look at the Unreal Development Kit (www.udk.com), and I continue to be shocked that they are giving out all this great technology to you and me to play with. And it really blew me away when I saw their Materials editor. There's a tutorial here, http://udn.epicgames.com/Three/MaterialsTutorial.html.
Take a look at how you program the materials algorithms. You lay them out graphically and hook up data flows between components. The order of execution or the parallelization of the algorithm is automatically inferred by the declarative nature of the model. When you're ready, these get generated into optimized shader programs that download to your graphics card when drawing the 3D models that these materials wrap. Very cool and very efficient.
This is very similar to what I found with the SynthMaker program that came with the FL Studio audio workstation software I've been playing with too. There you define the algorithm for software DSPs and GUI controls that change values using the same paradigm.
To see it in two places now, I'd love to have this available to the general public for any kind of application. Would it really be more efficient to write general multi-threaded and multi-process algorithms that way or would the modeling tools get in the way. Epic and SynthMaker felt it was right for their users, is it right for everyone? You know, I bet we could build this using Eclipse modeling tools and try it out...
Take a look at how you program the materials algorithms. You lay them out graphically and hook up data flows between components. The order of execution or the parallelization of the algorithm is automatically inferred by the declarative nature of the model. When you're ready, these get generated into optimized shader programs that download to your graphics card when drawing the 3D models that these materials wrap. Very cool and very efficient.
This is very similar to what I found with the SynthMaker program that came with the FL Studio audio workstation software I've been playing with too. There you define the algorithm for software DSPs and GUI controls that change values using the same paradigm.
To see it in two places now, I'd love to have this available to the general public for any kind of application. Would it really be more efficient to write general multi-threaded and multi-process algorithms that way or would the modeling tools get in the way. Epic and SynthMaker felt it was right for their users, is it right for everyone? You know, I bet we could build this using Eclipse modeling tools and try it out...
Saturday, November 07, 2009
Openness Shades of Grey
Motorola's newest phones are hitting the streets and promise Android goodness thanks to the latest Android release 2.0. Now if you think of Android as an open souce platform, you may have run over to the Android Open Source Project and tried to download the 2.0 source to see how they made it.
Uh, no. Android isn't that open. In fact, neither is it really a project. Android developement is really done on internal trees at Google and at the various device vendors. And the Android gang are pretty open about that on their mailing lists. I just wish they'd drop the open and project and just call it Android Source.
The unfortunate thing is that many in the community are naive to the shades of grey that exist in our industry. And complaints in the open tend to give projects a black eye. But each level of greyness has its purpose. For Android and most other projects that Google does, they want the flexibility to evolve the platforms quickly. Like it or not, truely open developement is slower.
Other projects need to be open to help grow the popularity of their technologies and to find people to help them build it. That's certainly what drives us on the CDT to be as open as we can.
The Eclipse Platform is an example of how projects change as their needs changed. No one complained when IBM started the Platform project 8 years ago and maintained almost full control of the project. It was necessary to ensure a great start, which it did. But over time, they've opened up as they realized they couldn't do it on their own any longer. So you change to maintain success.
I think the shades of grey are fine, as long as the licensing allows downstream projects to be as open as they'd like. And I see that happening with Android with the Android x86 project, for example, which is very open and just incorporated someone's code for better 3D support.
It's all good. People need to take a good look at the projects they follow and understand why they are structured the way they are to manage their expectations.
Uh, no. Android isn't that open. In fact, neither is it really a project. Android developement is really done on internal trees at Google and at the various device vendors. And the Android gang are pretty open about that on their mailing lists. I just wish they'd drop the open and project and just call it Android Source.
The unfortunate thing is that many in the community are naive to the shades of grey that exist in our industry. And complaints in the open tend to give projects a black eye. But each level of greyness has its purpose. For Android and most other projects that Google does, they want the flexibility to evolve the platforms quickly. Like it or not, truely open developement is slower.
Other projects need to be open to help grow the popularity of their technologies and to find people to help them build it. That's certainly what drives us on the CDT to be as open as we can.
The Eclipse Platform is an example of how projects change as their needs changed. No one complained when IBM started the Platform project 8 years ago and maintained almost full control of the project. It was necessary to ensure a great start, which it did. But over time, they've opened up as they realized they couldn't do it on their own any longer. So you change to maintain success.
I think the shades of grey are fine, as long as the licensing allows downstream projects to be as open as they'd like. And I see that happening with Android with the Android x86 project, for example, which is very open and just incorporated someone's code for better 3D support.
It's all good. People need to take a good look at the projects they follow and understand why they are structured the way they are to manage their expectations.
Friday, November 06, 2009
Unreal Development Kit
Wow. Unreal Development Kit. Free. Or at least free for free content. I've always wondered how developers create content for the big game engines, id and Unreal. And now I know and I have it installed on my laptop. For free. Can you tell I'm beside myself here. Check it out: http://www.udk.com.
At any rate, Epic has released their development kit for free. It's a great gesture and a great way to get hobbyists and students and even small start-up shops using their engine. It seems to be complete, including their famous editor, amongst a plethora of other tools that help you create full games that you can distribute (for free, of course, otherwise you'll need to pay for a license as you should).
Looking back at the archives, my second blog entry after saying "Hi", was on digital content creation tools for Eclipse. I conjectured that having such tools would be very cool. And I think it still would be.
And playing with the UDK, I don't see any technical reason why such tools couldn't be created using Eclipse technologies. With integrations with the various programming language and domain modeling frameworks and tools, and being able to run on Windows, Linux, and Mac, and target those and game consoles and mobile devices, what a great game development environment that would be.
That was my dream for Eclipse back in 2005, and it's still a dream I have for it today. All it takes is a community of like minded dreamers to make it happen. Oh, and some money to pay for the dreamers. Thus the dream...
At any rate, Epic has released their development kit for free. It's a great gesture and a great way to get hobbyists and students and even small start-up shops using their engine. It seems to be complete, including their famous editor, amongst a plethora of other tools that help you create full games that you can distribute (for free, of course, otherwise you'll need to pay for a license as you should).
Looking back at the archives, my second blog entry after saying "Hi", was on digital content creation tools for Eclipse. I conjectured that having such tools would be very cool. And I think it still would be.
And playing with the UDK, I don't see any technical reason why such tools couldn't be created using Eclipse technologies. With integrations with the various programming language and domain modeling frameworks and tools, and being able to run on Windows, Linux, and Mac, and target those and game consoles and mobile devices, what a great game development environment that would be.
That was my dream for Eclipse back in 2005, and it's still a dream I have for it today. All it takes is a community of like minded dreamers to make it happen. Oh, and some money to pay for the dreamers. Thus the dream...
Thursday, October 22, 2009
It's Crunch Time
I haven't blogged in a while so while I have my head above water, here's a few notes on what's happening lately.
It's crunch time for me and my Wind River Installer team as we put the final touches on our next release of our p2-based installer. Our focus now is on on-line updates and installs which is a pretty exciting capability for our customers and support teams. I haven't blogged much about what we're doing there but I think it's time to start spreading the word. p2 is a great install engine. It can be used for more things than just OSGi bundles.
Unfortunately, our p2 stuff is intermingled with older install technology and what I can only describe as "legacy" UI framework. So we can't contribute much from that yet, but I want to switch focus and replace our legacy with a more modern framework, that we can use to replace the p2 UI that exists today. You really need to understand p2 to use the current one, and that's not something most end users do.
There are a few other things I have my fingers in. I'm still mucking with Android and my wife gave me the idea to build puzzle games. I think that's a great mobile app, something you can do while waiting for your next flight, or what have you. I'm still following native development for Android and plan to write a plug-in that automates the project conversion step to add CDT capabilities to Android projects.
I am also taking a look at Moblin. I bought a Dell Mini 10 and installed Moblin on it. It gives me another native platform that's actually GNU/Linux (Android is just Linux, BTW) to understand better how to use the CDT with it. That feeds into my technical focus on the CDT which will be on build. But I need to get out of the product release crunch before I get further with that.
I also am trying to find some time to look at a WebKit SWT Browser widget. There has been some work there for the embedded web project, Blinki, and I'd like to see if we can make it more generally available. Everyone who's deployed Eclipse on Linux knows the pain of the ever changing versions of XULrunner. I'm hoping standardizing on WebKit would solve that, but we need to see how well it works first.
Anyway, back to bug fixing.
It's crunch time for me and my Wind River Installer team as we put the final touches on our next release of our p2-based installer. Our focus now is on on-line updates and installs which is a pretty exciting capability for our customers and support teams. I haven't blogged much about what we're doing there but I think it's time to start spreading the word. p2 is a great install engine. It can be used for more things than just OSGi bundles.
Unfortunately, our p2 stuff is intermingled with older install technology and what I can only describe as "legacy" UI framework. So we can't contribute much from that yet, but I want to switch focus and replace our legacy with a more modern framework, that we can use to replace the p2 UI that exists today. You really need to understand p2 to use the current one, and that's not something most end users do.
There are a few other things I have my fingers in. I'm still mucking with Android and my wife gave me the idea to build puzzle games. I think that's a great mobile app, something you can do while waiting for your next flight, or what have you. I'm still following native development for Android and plan to write a plug-in that automates the project conversion step to add CDT capabilities to Android projects.
I am also taking a look at Moblin. I bought a Dell Mini 10 and installed Moblin on it. It gives me another native platform that's actually GNU/Linux (Android is just Linux, BTW) to understand better how to use the CDT with it. That feeds into my technical focus on the CDT which will be on build. But I need to get out of the product release crunch before I get further with that.
I also am trying to find some time to look at a WebKit SWT Browser widget. There has been some work there for the embedded web project, Blinki, and I'd like to see if we can make it more generally available. Everyone who's deployed Eclipse on Linux knows the pain of the ever changing versions of XULrunner. I'm hoping standardizing on WebKit would solve that, but we need to see how well it works first.
Anyway, back to bug fixing.
Thursday, October 08, 2009
A Good Leader is a Good Architect
I've been whining (yeah, that's pretty much the word) a lot recently about the state of contributions to the CDT and about the struggles I face even internally to get more time to spend on open source. I've been pretty frustrated and depressed about that and it's showing in my writing.
But the conference calls we've been holding to plan for CDT 6.1 are definitely a bright spot, and they're something I will get some energy and inspiration from. The gang that is contributing, while generally being individuals instead of the teams of people we had in the past, are really smart and have some great ideas. And that's something we can definitely build upon.
Analyzing my participation in these calls and in my day job at Wind River, I am really coming full circle to something I decided a few years ago around the time the CDT was just starting. I am an architect, not a project manager. I love technology and building things and making them good. With the CDT, the indexer was my main challenge and I had a good team to work with and mentor and at the end of the day, it's really good.
I had the same idea with the build model, but I chose to be a project manager for that portion and not get involved technically. I regret that now since I see a few bad decisions that are leading to the current mass of issues people are having with it on the cdt-dev list. Working with Leo from Intel who was there at the beginning too, we are trying to piece together what we were trying to do and I think if we step back to that time and move forward again, we can straighten things out.
So, I think that's how I get out of my current funk. I plan on doing less project management and do more technical architecture work and lead the CDT that way. The team that we have now are very new and there are others hovering around looking for ways to get started. They could benefit from the experience of the few that are still around from the early days when we had a good vision of what we're trying to achieve. And maybe we can grow some new leaders to help the next generation.
Looking around at projects that are successful, those projects get that way because they are lead by good designers that can communicate well, empathize with the customer, and mentor others to do the same. When you don't have a "Sugar Daddy", as I refer to the companies that invest heavily in open source projects (see Google and IBM), you need to lead in ways that make the open source team successful. And almost always, that means focusing on technology and architecture. A good leader is a good architect. And good leaders make good projects. And good projects attract contributors. And that's the answer to my riddle.
But the conference calls we've been holding to plan for CDT 6.1 are definitely a bright spot, and they're something I will get some energy and inspiration from. The gang that is contributing, while generally being individuals instead of the teams of people we had in the past, are really smart and have some great ideas. And that's something we can definitely build upon.
Analyzing my participation in these calls and in my day job at Wind River, I am really coming full circle to something I decided a few years ago around the time the CDT was just starting. I am an architect, not a project manager. I love technology and building things and making them good. With the CDT, the indexer was my main challenge and I had a good team to work with and mentor and at the end of the day, it's really good.
I had the same idea with the build model, but I chose to be a project manager for that portion and not get involved technically. I regret that now since I see a few bad decisions that are leading to the current mass of issues people are having with it on the cdt-dev list. Working with Leo from Intel who was there at the beginning too, we are trying to piece together what we were trying to do and I think if we step back to that time and move forward again, we can straighten things out.
So, I think that's how I get out of my current funk. I plan on doing less project management and do more technical architecture work and lead the CDT that way. The team that we have now are very new and there are others hovering around looking for ways to get started. They could benefit from the experience of the few that are still around from the early days when we had a good vision of what we're trying to achieve. And maybe we can grow some new leaders to help the next generation.
Looking around at projects that are successful, those projects get that way because they are lead by good designers that can communicate well, empathize with the customer, and mentor others to do the same. When you don't have a "Sugar Daddy", as I refer to the companies that invest heavily in open source projects (see Google and IBM), you need to lead in ways that make the open source team successful. And almost always, that means focusing on technology and architecture. A good leader is a good architect. And good leaders make good projects. And good projects attract contributors. And that's the answer to my riddle.
Monday, October 05, 2009
Android Notes and Ideas for Eclipse
Here's a few notes on things I've been doing with Android. I'm under no delusion that I can actually create an app for Android. My wife wouldn't be too happy if I spend the time it would need. But I am finding that this is a great exercise getting into the mind of a mobile developer and is giving me ideas on how to improve the CDT and the Eclipse platform.
I've been working towards constructing a game engine, something I've always dreamed of doing. I am starting with the physics/collision detection engine and looking to open source for solutions. I started with box2d and wrote a little demo that had 20 "marbles" (ok they look more like squares, but squares are easier to render with OpenGL :) that rolled around the screen as you tilted the phone. Essentially, I configured it to alter the gravity of the "world" to match the orientation of the phone. It's a neat demo and gave me a hint at how to use engine and how much horsepower it needed.
But in the long term, I'd like to support the 3rd dimension (love the Simpsons episode when Homer fell into the 3rd dimension :). There's another open source engine called bullet that does it. Interestingly it's very similar to box2d and maybe a bit more mature. So I ported that and got it working with the marbles demo. I was worried about performance, especially since bullet uses floating point instead of box2d's fixed point and my phone doesn't have hardware float. But it was fine, and it allows me to march ahead with bullet for both 2D and 3D physics.
Now, doing this all in Eclipse using Android's plug-in and the CDT for the native code has been generally a good experience. There are a couple of things that are still needed. One is a way to automate the steps adding the CDT nature and builders to Android. And there are some things that don't work. CDT's scanner discovery, which scans build output looking for include path options, no longer works for my projects since I upgraded to CDT 6.0.1. Setting it up for cross compilers has always been a pain, and now it just seems to not work :(.
The other thing that bugs me now, is something that has always bugged us in the CDT community, and despite raising several bugs, has never been satisfactorily addressed is the Eclipse build system. I've set my Android project to reference the physic engine library project to control the build order. But when I go to clean my Android project, which is small, it cleans the referenced projects too, which aren't so small. What makes it worse is that it kicks a rebuild right away so you can't just clean your project and leave it that way.
Hopefully with the new openness shown by the platform team we can get something done there. But we're all a little jaded from the history and we need to overcome that first.
I've been working towards constructing a game engine, something I've always dreamed of doing. I am starting with the physics/collision detection engine and looking to open source for solutions. I started with box2d and wrote a little demo that had 20 "marbles" (ok they look more like squares, but squares are easier to render with OpenGL :) that rolled around the screen as you tilted the phone. Essentially, I configured it to alter the gravity of the "world" to match the orientation of the phone. It's a neat demo and gave me a hint at how to use engine and how much horsepower it needed.
But in the long term, I'd like to support the 3rd dimension (love the Simpsons episode when Homer fell into the 3rd dimension :). There's another open source engine called bullet that does it. Interestingly it's very similar to box2d and maybe a bit more mature. So I ported that and got it working with the marbles demo. I was worried about performance, especially since bullet uses floating point instead of box2d's fixed point and my phone doesn't have hardware float. But it was fine, and it allows me to march ahead with bullet for both 2D and 3D physics.
Now, doing this all in Eclipse using Android's plug-in and the CDT for the native code has been generally a good experience. There are a couple of things that are still needed. One is a way to automate the steps adding the CDT nature and builders to Android. And there are some things that don't work. CDT's scanner discovery, which scans build output looking for include path options, no longer works for my projects since I upgraded to CDT 6.0.1. Setting it up for cross compilers has always been a pain, and now it just seems to not work :(.
The other thing that bugs me now, is something that has always bugged us in the CDT community, and despite raising several bugs, has never been satisfactorily addressed is the Eclipse build system. I've set my Android project to reference the physic engine library project to control the build order. But when I go to clean my Android project, which is small, it cleans the referenced projects too, which aren't so small. What makes it worse is that it kicks a rebuild right away so you can't just clean your project and leave it that way.
Hopefully with the new openness shown by the platform team we can get something done there. But we're all a little jaded from the history and we need to overcome that first.
Sunday, October 04, 2009
No where's that open source hat?
One of the points from my EclipseCon talk on building communities was "Wear two hats." Essentially, to successfully attract new contributions, you have to show that you are working in the best interest of the project as a whole. Of course, you also need to make sure the project is meeting the commercial needs of the vendor you work for or else that might not last long.
This is something I've done always in my life at Eclipse. At times, I may have been too much with the open source hat and not enough commercial, but I always had a team with me to compensate for that so it worked out. I do believe that has been one of the main reasons the CDT project has been so successful growing a diverse community.
But as the CDT matures and the vendors who have made big investments in CDT reduce that investment to allow their developers to work on other things that are more important now, I get worried about how we're going to finish off things off. The CDT build system still needs a lot of work to undo and clean up some of the architectural decisions of the past. There are a few guys interested in helping, but these guys are just part-timers, not the dedicate investment we need to be successful.
All I have to hope on is that vendors will put on their open source hat and work for the common good. In theory, working with other such vendors to build a kick-ass build system would help them in the long run and should be cheaper, since they are benefiting from the investment from the other vendors.
But "theory" isn't a place we all live in and few vendors have the vision and long term planning to see that formula work. In fact, what makes it worse, is that vendors tend to see their "improvements" over base Eclipse functionality as a competitive advantage over the free Eclipse. And, trust me, I have seen first hand the view that the freely available Eclipse eats at the bottom line. And there is some validity in that since you can't charge the premiums for development tools that you used to, or so customers believe anyway.
It was a lot easier in the early days of Eclipse when everything was new and everyone needed development tools, especially on the C/C++ space. The vendors that kicked off the CDT found it easy to wear the open source hat because they really needed the help. Everyone fears the elephant in the room, so don't be one.
But now that the development tools are "good enough" the investment is no longer there to take it to the next level to make them "best in class". And as much as users of the free Eclipse see the deficiencies and raise bugzillas to have those deficiencies fixed, I have to feel for them.
As long as Eclipse is staffed solely by vendors making money on Eclipse-base product, the free one isn't going to be great. Now, also in that magical place called "theory", an Eclipse.com funded to do development would help as much as Mozilla.com helps Firefox. But it doesn't work that way in the Eclipse ecosystem and that makes the poor project lead who likes to wear the open source hat wonder whether it's worth it anymore.
This is something I've done always in my life at Eclipse. At times, I may have been too much with the open source hat and not enough commercial, but I always had a team with me to compensate for that so it worked out. I do believe that has been one of the main reasons the CDT project has been so successful growing a diverse community.
But as the CDT matures and the vendors who have made big investments in CDT reduce that investment to allow their developers to work on other things that are more important now, I get worried about how we're going to finish off things off. The CDT build system still needs a lot of work to undo and clean up some of the architectural decisions of the past. There are a few guys interested in helping, but these guys are just part-timers, not the dedicate investment we need to be successful.
All I have to hope on is that vendors will put on their open source hat and work for the common good. In theory, working with other such vendors to build a kick-ass build system would help them in the long run and should be cheaper, since they are benefiting from the investment from the other vendors.
But "theory" isn't a place we all live in and few vendors have the vision and long term planning to see that formula work. In fact, what makes it worse, is that vendors tend to see their "improvements" over base Eclipse functionality as a competitive advantage over the free Eclipse. And, trust me, I have seen first hand the view that the freely available Eclipse eats at the bottom line. And there is some validity in that since you can't charge the premiums for development tools that you used to, or so customers believe anyway.
It was a lot easier in the early days of Eclipse when everything was new and everyone needed development tools, especially on the C/C++ space. The vendors that kicked off the CDT found it easy to wear the open source hat because they really needed the help. Everyone fears the elephant in the room, so don't be one.
But now that the development tools are "good enough" the investment is no longer there to take it to the next level to make them "best in class". And as much as users of the free Eclipse see the deficiencies and raise bugzillas to have those deficiencies fixed, I have to feel for them.
As long as Eclipse is staffed solely by vendors making money on Eclipse-base product, the free one isn't going to be great. Now, also in that magical place called "theory", an Eclipse.com funded to do development would help as much as Mozilla.com helps Firefox. But it doesn't work that way in the Eclipse ecosystem and that makes the poor project lead who likes to wear the open source hat wonder whether it's worth it anymore.
Monday, September 28, 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?
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?
Sunday, September 27, 2009
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.
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.
Thursday, September 24, 2009
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 :).
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 :).
Monday, September 21, 2009
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.
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.
Friday, September 18, 2009
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).
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).
Saturday, September 12, 2009
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.
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.
Thursday, September 10, 2009
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
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
Monday, August 31, 2009
Time to break down the Silos between the *DT's?
What started out as a personal need for writing and debugging JNI-based applications, both based on Eclipse and for Android, has turned into something bigger, a lot bigger. The hardest problem we face for what I'm doing is supporting multiple debugger technologies in the same debug session and ensuring a nice seamless experience. Showing both Java and C/C++ stacks merged together and stepping back and forth between them would be the cat's meow.
As I'm starting to hear from the greater Eclipse community, there is need for cross language/cross technology debugging in other areas as well. One example is Rhino which is being used by the e4 team to support writing plugins in JavaScript. Having a debug session with JavaScript and Java in the same stack would also be awesome. Similarly, we have JavaScript or ActionScript running in the browser interacting with a Equinox server, or maybe PHP running in Apache. Web applications are the manifestation of distributed applications and, as promised, those applications tend to involve multiple languages.
Traditionally, the language tooling projects at Eclipse have lived in silos. The CDT team has have very little interaction with the JDT team, for example. And that's not generally the fault of the team members. It's just a symptom of the lack of investment in Eclipse towards common technologies. Being an engineer, I have no idea how to solve that except to ineffectively whine about it. ;)
But one objective we've had with the CDT was to ensure that the C wasn't just for C/C++. Many of our frameworks are language independent as much as we practically could. We haven't had enough investment to be able to push that out to the general Eclipse community, but we do have projects like Photran (Fortran) and the fledgling Hibachi (Ada) and the new but remote ObjectivEclipse (Objective-C) doing that.
I think in particular, our new debug framework, DSF, could be used for much more than C and related languages. DSF started out as a solution for the difficult debug environments we face in the embedded space and actually started as the Device Debug project of DSDP. We've migrated it down into the CDT in 6.0. We've often quipped that it really should be down in the Eclipse platform itself. There will be challenges, technically and otherwise, to make that happen.
What I want to do is start prototyping multi-language, multi-debugger debug sessions based on DSF. That would initially include Java and C/C++. I'll also take a peak at JavaScript debugging and consider how that impacts it. I'm confident the flexibility we brought with DSF can be leveraged to make the Eclipse side of this relatively straightforward. The bigger challenge will be co-ordinating the different debuggers.
If others are interested in this work, we should co-ordinate our efforts. Let me know and we could set up a mailing list to talk about this area, and hopefully we can start breaking down the silos.
As I'm starting to hear from the greater Eclipse community, there is need for cross language/cross technology debugging in other areas as well. One example is Rhino which is being used by the e4 team to support writing plugins in JavaScript. Having a debug session with JavaScript and Java in the same stack would also be awesome. Similarly, we have JavaScript or ActionScript running in the browser interacting with a Equinox server, or maybe PHP running in Apache. Web applications are the manifestation of distributed applications and, as promised, those applications tend to involve multiple languages.
Traditionally, the language tooling projects at Eclipse have lived in silos. The CDT team has have very little interaction with the JDT team, for example. And that's not generally the fault of the team members. It's just a symptom of the lack of investment in Eclipse towards common technologies. Being an engineer, I have no idea how to solve that except to ineffectively whine about it. ;)
But one objective we've had with the CDT was to ensure that the C wasn't just for C/C++. Many of our frameworks are language independent as much as we practically could. We haven't had enough investment to be able to push that out to the general Eclipse community, but we do have projects like Photran (Fortran) and the fledgling Hibachi (Ada) and the new but remote ObjectivEclipse (Objective-C) doing that.
I think in particular, our new debug framework, DSF, could be used for much more than C and related languages. DSF started out as a solution for the difficult debug environments we face in the embedded space and actually started as the Device Debug project of DSDP. We've migrated it down into the CDT in 6.0. We've often quipped that it really should be down in the Eclipse platform itself. There will be challenges, technically and otherwise, to make that happen.
What I want to do is start prototyping multi-language, multi-debugger debug sessions based on DSF. That would initially include Java and C/C++. I'll also take a peak at JavaScript debugging and consider how that impacts it. I'm confident the flexibility we brought with DSF can be leveraged to make the Eclipse side of this relatively straightforward. The bigger challenge will be co-ordinating the different debuggers.
If others are interested in this work, we should co-ordinate our efforts. Let me know and we could set up a mailing list to talk about this area, and hopefully we can start breaking down the silos.
Subscribe to:
Posts (Atom)