It's been a pretty busy week as we are getting two releases together pretty much at the same time. The first is the release of our latest maintenance release CDT 3.1.2. Bugzilla tells me there were 101 bugs fixed in this release, which is a pretty good number given that we have been very busy working on CDT 4.0 at the same time.
The biggest fix that I put in was to move away from using memory mapped files for the Index (also known in some circles as the PDOM). Memory mapped files worked well until we started running into very large workspaces where we started to run into limits on Windows. I've switched it to regular files that read in chunks at a time and use a least recently used (LRU) cache to make sure we don't take up too much memory. It did cost us some in performance, but I'm still within the targets I had set out for CDT 3.1, i.e. indexing Firefox in under 20 minutes.
More information can be found on the CDT Website.
Stay tuned for our first real milestone for 4.0 early next week...
Friday, February 16, 2007
Tuesday, February 13, 2007
OpenKODE: Cross Platform Mobile Gaming in C
I blogged a while back about an open source mobile gaming device, the GP2X. It's a pretty simple and inexpensive unit with a dual core ARM configuration. I think a lot of people are using it for simple 2D games and there are ports of the arcade machine simulator, MAME, to it. It's not a very powerful machine, but I thought the idea was pretty powerful.
It got me thinking about whether the industry would be interested in a similar platform but with 3D gaming support. And if not, why not. Maybe these things cost too much to build. Maybe the business case isn't there. I haven't seen too much interest from the big gaming houses on porting their titles to OpenGL ES, a standard 3D API for mobile. But then, there isn't really a high volume platform out there that supports it to the scale of the Sony PSP and Nintendo DS. Unless you count phones, but you can't do serious gaming on a 1" screen...
But it looks like the gang at Khonos.org are trying to do something about that. They recently ratified a draft specification for a common platform API called OpenKODE. It's a collection of C APIs, most of which they've already specified for video and audio. But it also has a OS abstraction layer so you can compile applications against any OS, or so goes the theory. The intent is to provide a platform for content providers that will allow them to hit as big a market as possible.
They are accepting comments from the industry and I see vendors starting to do press releases announcing support for it. My hope is that you'd start seeing mobile gaming platforms like you see with MP3 players, i.e., a lot of vendors making different types of devices but all supporting common standards. That would sure change the face of the industry a bit.
It got me thinking about whether the industry would be interested in a similar platform but with 3D gaming support. And if not, why not. Maybe these things cost too much to build. Maybe the business case isn't there. I haven't seen too much interest from the big gaming houses on porting their titles to OpenGL ES, a standard 3D API for mobile. But then, there isn't really a high volume platform out there that supports it to the scale of the Sony PSP and Nintendo DS. Unless you count phones, but you can't do serious gaming on a 1" screen...
But it looks like the gang at Khonos.org are trying to do something about that. They recently ratified a draft specification for a common platform API called OpenKODE. It's a collection of C APIs, most of which they've already specified for video and audio. But it also has a OS abstraction layer so you can compile applications against any OS, or so goes the theory. The intent is to provide a platform for content providers that will allow them to hit as big a market as possible.
They are accepting comments from the industry and I see vendors starting to do press releases announcing support for it. My hope is that you'd start seeing mobile gaming platforms like you see with MP3 players, i.e., a lot of vendors making different types of devices but all supporting common standards. That would sure change the face of the industry a bit.
The CDT Can Help you See!
Well, not really, the NASA Vision Workbench can and this guy is using the CDT to work with it. After all the hard work we've put into the CDT, I'll take "Eclipse’s CDT plugin (which has definitely gotten alot better)" as a compliment.
Monday, February 12, 2007
What do you use for UI testing?
The TPTP gang were adjusting version info in an enhancement request I raised against their Automated GUI Recorder (AGR) and it reminded me I need to look into this issue again. I remember seeing a demo of the AGR back when I snuck into an Eclipse Architecture Council meeting a year or so ago. It looked pretty good and appeared to do what we've needed for the CDT since forever, i.e., something to automate testing the GUI.
The issue I have had with the AGR is that I want to integrate the test cases that AGR generates into our existing JUnit framework. Unfortunately, that was impossible, or more realistically, was a lot of work to do. And, also unfortunately, the word I hear through the grapevine is that the AGR really isn't staffed well enough to evolve it this significantly. It met the needs it was created for, i.e. test TPTP, and if it is to fulfill a larger role in Eclipse, it really needs more Eclipse developers contributing to it.
So if the need isn't there to trigger this investment, it got me wondering what people use to automate their GUI testing. Of course there are commercial products out there that do the trick and we've used those here at QNX. But for open source development, it would be nice if we had an even playing field so that anyone could contribute tests without having to purchase the "standard" tool, assuming we could even agree on which "standard" tool to use.
I heard of the Abbot GUI tester and the Costello GUI recorder, still the best names in open source IMHO, a number of years ago. While built for Swing/AWT, they started working on SWT support a long time ago but it has been slow going. I have heard of some people using it for their Eclipse testing, but I'd like to see an official release of it before committing to it. But it does what I want, though, i.e. integrate with normal JUnit.
So I'd like to hear people's opinions on this, especially on where they would like to see developers invest their time if they indeed wanted to contribute to an Eclipse open source GUI testing tool. I think the need is there, but that means "beans" if no one else does.
The issue I have had with the AGR is that I want to integrate the test cases that AGR generates into our existing JUnit framework. Unfortunately, that was impossible, or more realistically, was a lot of work to do. And, also unfortunately, the word I hear through the grapevine is that the AGR really isn't staffed well enough to evolve it this significantly. It met the needs it was created for, i.e. test TPTP, and if it is to fulfill a larger role in Eclipse, it really needs more Eclipse developers contributing to it.
So if the need isn't there to trigger this investment, it got me wondering what people use to automate their GUI testing. Of course there are commercial products out there that do the trick and we've used those here at QNX. But for open source development, it would be nice if we had an even playing field so that anyone could contribute tests without having to purchase the "standard" tool, assuming we could even agree on which "standard" tool to use.
I heard of the Abbot GUI tester and the Costello GUI recorder, still the best names in open source IMHO, a number of years ago. While built for Swing/AWT, they started working on SWT support a long time ago but it has been slow going. I have heard of some people using it for their Eclipse testing, but I'd like to see an official release of it before committing to it. But it does what I want, though, i.e. integrate with normal JUnit.
So I'd like to hear people's opinions on this, especially on where they would like to see developers invest their time if they indeed wanted to contribute to an Eclipse open source GUI testing tool. I think the need is there, but that means "beans" if no one else does.
Now what am I supposed to do with 80 cores?
Yesterday, Intel announced a research project they've been working on to produce a core capable of reaching teraflop (a zillion floating point operations, or something...) performance. The chip they've come up with has 80 cores. Sounds like a lot, and it is. Now, this is a research chip and it is missing things like a memory controller which makes it impractical for anything. But it is serving it's purpose of helping us understand what such an environment of the future would be like. The benefits will be paradigm shifting, but we have a long way to go before we get there.
Of course, being a tools guy, I think the tools industry needs to jump on this. Without proper tools, developers just won't be able to deal with the complexity of the software that takes advantage of such scalability. This is one of the reasons I'm very interested in the Parallel Tools Platform (PTP) project at Eclipse. They are trying to deal with such environments today by providing tools that support developers working with supercomputers used for scientific research.
The challenges are enormous and include the whole edit/build/debug programming cycle. What libraries and programming language enhancements do you need to write an 80 thread or process application, how do you build and deploy such a thing, how do you debug it? I can still picture the problem of setting a breakpoint, having 10,000 threads hit that breakpoint and then trying to find the one that you are interested in. Sounds impossible. But there are some pretty smart people working on PTP and it'll be very interesting to see the solutions they come up with.
Of course, being a tools guy, I think the tools industry needs to jump on this. Without proper tools, developers just won't be able to deal with the complexity of the software that takes advantage of such scalability. This is one of the reasons I'm very interested in the Parallel Tools Platform (PTP) project at Eclipse. They are trying to deal with such environments today by providing tools that support developers working with supercomputers used for scientific research.
The challenges are enormous and include the whole edit/build/debug programming cycle. What libraries and programming language enhancements do you need to write an 80 thread or process application, how do you build and deploy such a thing, how do you debug it? I can still picture the problem of setting a breakpoint, having 10,000 threads hit that breakpoint and then trying to find the one that you are interested in. Sounds impossible. But there are some pretty smart people working on PTP and it'll be very interesting to see the solutions they come up with.
Friday, February 02, 2007
Open Source Translations?
Well, it was a busy week for conference calls. The latest was on an initiative to start an Eclipse project to take care of the translations for the Eclipse project. I went into it being mistaken that the initiative was simply trying to spread the translation work around for Europa so that IBM didn't have to do it all. It's a pretty expensive endeavour to translate all of Europa to 23 languages. But the intention is indeed to be more than that.
Now, for the CDT, translations haven't been a priority. We haven't released language packs for the CDT since the 2.x days. We still get a healthy 20% of our downloads to China and I haven't received feedback that they miss them. But I imagine we'd grow even more internationally if we had them.
Despite my original skepticism, I think a translations project is a great idea. Technically, making the translations isn't very complicated so you don't need to be a hard core developer to help with them. And, apparently there are some tools that have been made to help make it even easier. It would be cool for the users of Eclipse around the world to help out with this and would probably result in better quality as they actually use Eclipse.
My skepticism right now comes from the current focus on getting the Eclipse member companies to contribute rather than on building a community. I think if you focus too much on short term goals, like translating Europa, you won't solve much when the next release comes around. Hopefully, this project will find an inspired leader that break new ground in international community building. It certainly won't be an easy task. But it could be another great step forward for Eclipse.
Now, for the CDT, translations haven't been a priority. We haven't released language packs for the CDT since the 2.x days. We still get a healthy 20% of our downloads to China and I haven't received feedback that they miss them. But I imagine we'd grow even more internationally if we had them.
Despite my original skepticism, I think a translations project is a great idea. Technically, making the translations isn't very complicated so you don't need to be a hard core developer to help with them. And, apparently there are some tools that have been made to help make it even easier. It would be cool for the users of Eclipse around the world to help out with this and would probably result in better quality as they actually use Eclipse.
My skepticism right now comes from the current focus on getting the Eclipse member companies to contribute rather than on building a community. I think if you focus too much on short term goals, like translating Europa, you won't solve much when the next release comes around. Hopefully, this project will find an inspired leader that break new ground in international community building. It certainly won't be an easy task. But it could be another great step forward for Eclipse.
Thursday, February 01, 2007
CDT: An Open Culture
After today's CDT conference call, the gang here at QNX got to talking about how interesting these calls can be. Apparently, the CDT has something special going with how open we are.
The topic we were discussing was my mention of our plans with Momentics and CDT 3.1.2 and CDT 4.0. I did it just to let the community know that if I'm doing something weird, it's because I'm trying to get the CDT 3.1.2 into the next Momentics maintenance release and to set expectations on when we'd be trying to integrate our custom bits with CDT 4.0 to provide feedback on the new frameworks.
What I had forgotten was that in this highly competative industry, this is usually a no-no. Mentioning product plans could definitely cause a slap on the wrists. Product plans are high quality ammunition that the marketing teams use against each other. Not that I aspire to such tactics, mind you.
But with the CDT and even the DSDP, this hasn't really been a concern. We often drop hints on what we're doing commercially. It all comes back to "When is you problem my problem". If you at least know about my problem, you might make some effort to help me. But if I'm keeping my intentions secret, there is no trust, and I can't see how you can have any hope of co-operation from the community.
In the end, we concluded that the CDT was a pretty cool project to be a part of. There are a lot of projects at Eclipse now, and not all of them have realized the benefits that an open culture can bring them and their customers. And it's not just getting people to help you with your problems, either. It's just cool to be in touch with the rest of the industry and know what's going on out there.
The topic we were discussing was my mention of our plans with Momentics and CDT 3.1.2 and CDT 4.0. I did it just to let the community know that if I'm doing something weird, it's because I'm trying to get the CDT 3.1.2 into the next Momentics maintenance release and to set expectations on when we'd be trying to integrate our custom bits with CDT 4.0 to provide feedback on the new frameworks.
What I had forgotten was that in this highly competative industry, this is usually a no-no. Mentioning product plans could definitely cause a slap on the wrists. Product plans are high quality ammunition that the marketing teams use against each other. Not that I aspire to such tactics, mind you.
But with the CDT and even the DSDP, this hasn't really been a concern. We often drop hints on what we're doing commercially. It all comes back to "When is you problem my problem". If you at least know about my problem, you might make some effort to help me. But if I'm keeping my intentions secret, there is no trust, and I can't see how you can have any hope of co-operation from the community.
In the end, we concluded that the CDT was a pretty cool project to be a part of. There are a lot of projects at Eclipse now, and not all of them have realized the benefits that an open culture can bring them and their customers. And it's not just getting people to help you with your problems, either. It's just cool to be in touch with the rest of the industry and know what's going on out there.
Monday, January 29, 2007
Windows Vista versus OpenGL
I just finished reading Tom's Hardware's benchmarks comparing Vista and XP. I remember hearing that Microsoft was dropping OpenGL support and Tom's confirms it with their benchmark of OpenGL apps. I don't follow the graphics community as much as I'd like but this really has to be a blow for some of them. If not that, then it's a blow for them upgrading to Vista.
Back on my Digital Content Creation with Eclipse soap box, I guess this kind of spells doom for the OpenGL work that's been going on with Java and, by extension, SWT. I have always thought that it would be very cool to have a 3D modeler built on Eclipse and nicely integrated with the CDT to build games and such. Most of these modelers are built using OpenGL and probably don't work well on Vista.
So the question becomes, when will someone build DirectX support in Java in an SWT window?
It also provides a twist for the work I'm doing on Windows development. I've been torn between whether Windows developers should use the Windows SDK or MinGW with the CDT. I'm not sure how mature the DirectX support is with MinGW compared to their OpenGL support, so my feeling is that the Windows SDK with the DirectX SDK will be what developers will want to use. Which means I better get that Windows SDK integration done...
Back on my Digital Content Creation with Eclipse soap box, I guess this kind of spells doom for the OpenGL work that's been going on with Java and, by extension, SWT. I have always thought that it would be very cool to have a 3D modeler built on Eclipse and nicely integrated with the CDT to build games and such. Most of these modelers are built using OpenGL and probably don't work well on Vista.
So the question becomes, when will someone build DirectX support in Java in an SWT window?
It also provides a twist for the work I'm doing on Windows development. I've been torn between whether Windows developers should use the Windows SDK or MinGW with the CDT. I'm not sure how mature the DirectX support is with MinGW compared to their OpenGL support, so my feeling is that the Windows SDK with the DirectX SDK will be what developers will want to use. Which means I better get that Windows SDK integration done...
Saturday, January 27, 2007
My Take on Eclipse PluginFest
Well, I'm finally home from my trip out to the Eclipse PluginFest. I made a side trip to Karlsbad, Germany to visit a customer, where it was pretty cool to see them adding their own plug-ins. Eclipse is indeed everywhere. And I was met by a very Canadian-like snow storm there. While it was fun to drive in, I missed out on a lot of sleep with the late arrival. But it was still warmer there than the -20C here.
Ian has a really nice summary of the PluginFest event so you can read that to get the general gist of what happened. From my seat, it went way beyond my expectations. I found everyone who attended to be very open and we all filled up our laptops with trial versions of each other's products and tried them all together. I was concerned that being a commercial event there would be a lot of protectionism happening. But it turned out that most of us already knew eachother from past Eclipse events, so were instantly comfortable with each other.
For the most part everything worked, but that is to be expected given the clean plug-in architecture of Eclipse. But it did point out an important requirement that everyone be on the latest version of the Eclipse plug-ins. Happily we made that decision at QNX last year and it paid off for everyone who did. It was cool to see other plug-ins work with our product and that should open the door for some pretty cool environments for our customers. And the sentiment was shared by the other vendors there as well.
But as Ian mentioned, the value of the event went well beyond testing our plug-ins. It was a great opportunity to talk to everyone who was there. I had a lot of people ask me CDT questions, including a couple asking how to get involved and contribute the CDT changes they have had to make for their products. I also got a chance to talk to a couple of the CDT committers that were there to go over design issues we need to resolve. Meeting face-to-face this way is pretty expensive, but it certainly has a lot of value for the people that get to go.
We definitely need to do this again, maybe after a year to give us all a chance to get onto the Europa platform. The gang at Symbian were great hosts, but I have a feeling a lot more vendors will be interested in this next time and we'll probably need a bigger venue. This was our first try at bringing vendors together for inter-operability testing and it really shows the value of the Eclipse architecture. And I'm sure all vendors building on Eclipse would be interested in this. I see big things in the future for the Eclipse PluginFest.
Ian has a really nice summary of the PluginFest event so you can read that to get the general gist of what happened. From my seat, it went way beyond my expectations. I found everyone who attended to be very open and we all filled up our laptops with trial versions of each other's products and tried them all together. I was concerned that being a commercial event there would be a lot of protectionism happening. But it turned out that most of us already knew eachother from past Eclipse events, so were instantly comfortable with each other.
For the most part everything worked, but that is to be expected given the clean plug-in architecture of Eclipse. But it did point out an important requirement that everyone be on the latest version of the Eclipse plug-ins. Happily we made that decision at QNX last year and it paid off for everyone who did. It was cool to see other plug-ins work with our product and that should open the door for some pretty cool environments for our customers. And the sentiment was shared by the other vendors there as well.
But as Ian mentioned, the value of the event went well beyond testing our plug-ins. It was a great opportunity to talk to everyone who was there. I had a lot of people ask me CDT questions, including a couple asking how to get involved and contribute the CDT changes they have had to make for their products. I also got a chance to talk to a couple of the CDT committers that were there to go over design issues we need to resolve. Meeting face-to-face this way is pretty expensive, but it certainly has a lot of value for the people that get to go.
We definitely need to do this again, maybe after a year to give us all a chance to get onto the Europa platform. The gang at Symbian were great hosts, but I have a feeling a lot more vendors will be interested in this next time and we'll probably need a bigger venue. This was our first try at bringing vendors together for inter-operability testing and it really shows the value of the Eclipse architecture. And I'm sure all vendors building on Eclipse would be interested in this. I see big things in the future for the Eclipse PluginFest.
Friday, January 19, 2007
When is your problem my problem?
I just got off a conference call we hold semi regulary amongst the committers working on the CDT indexer. Now that we have people from four different organizations working on it, we need this level of co-ordination to ensure we don't trample on eachother. And it is a cool example of open source development at work.
Now when you get this many interests working on a common code base, you are likely to run into times when requirements start to conflict with each other, and you end up with conflict amongst the developers. This has started to happen with us and it is giving me an opportunity to really learn the right approach to take to make sure everyone walks away happy, or even whether it is possible for that to happen.
Taking a big step back, I think the first thing you have to do if you have a requirement you'd like the open source project to satisfy is to convince others in the community that it is their problem too. Now sometimes that isn't possible because the requirement really is particular to your customers. In that case, I think you need to convince the others that the changes you are proposing will have minimal impact on them and others who want to build on and use the project. There are times, especially with young projects, where people might bend over backwards to help you. But you certainly can't count on it, nor should you.
At the end of the day, what it really boils down to is that you have to convince people. Influencing is a critical skill that an open source developer must have to be successful working with open source. In a corporate environment, you have it easy since you can always go complain to management. But in open source, all the committers are peers, there are no managers, so they need to work out any conflicts with eachother. And that demands great people skills.
It is pretty interesting that our little indexing group has such great influencers and the discussions can become quite heated. But we do respect eachother and will continue to hammer out these issues and try to come up with the right solution for everyone.
And if this does work out for us, it'll make a great chapter for a book on working in open source. There may be a book out there already that I need to read, or maybe not and someone needs to write one. Because I see this happening on almost every open source project I see.
Now when you get this many interests working on a common code base, you are likely to run into times when requirements start to conflict with each other, and you end up with conflict amongst the developers. This has started to happen with us and it is giving me an opportunity to really learn the right approach to take to make sure everyone walks away happy, or even whether it is possible for that to happen.
Taking a big step back, I think the first thing you have to do if you have a requirement you'd like the open source project to satisfy is to convince others in the community that it is their problem too. Now sometimes that isn't possible because the requirement really is particular to your customers. In that case, I think you need to convince the others that the changes you are proposing will have minimal impact on them and others who want to build on and use the project. There are times, especially with young projects, where people might bend over backwards to help you. But you certainly can't count on it, nor should you.
At the end of the day, what it really boils down to is that you have to convince people. Influencing is a critical skill that an open source developer must have to be successful working with open source. In a corporate environment, you have it easy since you can always go complain to management. But in open source, all the committers are peers, there are no managers, so they need to work out any conflicts with eachother. And that demands great people skills.
It is pretty interesting that our little indexing group has such great influencers and the discussions can become quite heated. But we do respect eachother and will continue to hammer out these issues and try to come up with the right solution for everyone.
And if this does work out for us, it'll make a great chapter for a book on working in open source. There may be a book out there already that I need to read, or maybe not and someone needs to write one. Because I see this happening on almost every open source project I see.
Sunday, January 14, 2007
Eclipse is ... an Opportunity
Despite Doug Gaff's wish to have the last word on the Eclipse is You/Me/Who? issue, I do have one more thing to say on it (Sorry, Doug :). I was at the Device Debug meeting in Toronto last week, and for me it was deja-vu all over again. We had similar meetings on the CDT many times in the past, ones where a big number of people, 30-40 say, get together to talk about Eclipse projects, but in the end only 4 or 5 of them are actually planning on contributing anything to the project despite there being a need for many more.
Who are the rest? Well they are developers sent by their managers to make sure they keep tabs on what is going on. What it really tells me is that these companies don't really need anything from the project, not yet at least. But if something does come up that they can use, at least they know about it and can start making plans for it. But really, they are a long way off from having the compelling business reason that their managers need to allocate resources towards making any contributions back.
We've talked about the difficulty at making that leap from user to contributor. The biggest is just the expense of allocating developers to something that may not be their core competency. And, in fact, they may not have the Eclipse expertise on staff to actually do it. And it's really unfortunate, because without help, Eclipse projects have a hard time getting to the point where they would be useful enough to justify contribution. I feel Doug G's frustration at trying to start new projects in this environment.
So it got me wondering, looking at other examples in the industry, whether these companies would be willing to pool, not people, but money towards hiring shared developers. I know of a few small consulting companies that get paid to work on open source. I think this has the potential to solve some of the staffing problems that we're seeing on these projects. But I'm no expert on whether this is a good, or at least sustainable, business model. It would be interesting to see if people are willing to work together this way. And I encourage such consulting companies to ask around and see if they can make it work.
Who are the rest? Well they are developers sent by their managers to make sure they keep tabs on what is going on. What it really tells me is that these companies don't really need anything from the project, not yet at least. But if something does come up that they can use, at least they know about it and can start making plans for it. But really, they are a long way off from having the compelling business reason that their managers need to allocate resources towards making any contributions back.
We've talked about the difficulty at making that leap from user to contributor. The biggest is just the expense of allocating developers to something that may not be their core competency. And, in fact, they may not have the Eclipse expertise on staff to actually do it. And it's really unfortunate, because without help, Eclipse projects have a hard time getting to the point where they would be useful enough to justify contribution. I feel Doug G's frustration at trying to start new projects in this environment.
So it got me wondering, looking at other examples in the industry, whether these companies would be willing to pool, not people, but money towards hiring shared developers. I know of a few small consulting companies that get paid to work on open source. I think this has the potential to solve some of the staffing problems that we're seeing on these projects. But I'm no expert on whether this is a good, or at least sustainable, business model. It would be interesting to see if people are willing to work together this way. And I encourage such consulting companies to ask around and see if they can make it work.
Monday, January 08, 2007
EasyEclipse for C and C++, half way there
In my previous entry, I yearned for a single install of Eclipse, CDT, MinGW, and some libraries to get you "Kickstart"ed using the CDT on Windows. As Chris, zx, quickly pointed out, EasyEclipse already has some of this done and hooked me up with Phillipe Ombrédanne from nexB who created EasyEclipse. Of course I already know Phillipe who led the Google Summer of Code project for Eclipse and who is scheduled to give a talk on the C/C++ Eclipse ecosystem (amonst many others I see) at this year's EclipseCon.
EasyEclipse for C and C++ is definitely a great start at what I wanted to acheive. And I see from the comments on the site, there are people already asking for MinGW to be included.
So I've altered may plan and will work with the gang at EasyEclipse to complete EasyEclipse as a full fledged IDE offering. They already have a thriving community so it will be cool to build on that and get more C/C++ users involved.
EasyEclipse for C and C++ is definitely a great start at what I wanted to acheive. And I see from the comments on the site, there are people already asking for MinGW to be included.
So I've altered may plan and will work with the gang at EasyEclipse to complete EasyEclipse as a full fledged IDE offering. They already have a thriving community so it will be cool to build on that and get more C/C++ users involved.
Time for a CDT Kickstart?
I subscribe to Google Alerts and get notifications whenever something new pops up mentioning the CDT. I've been seeing a lot of blog entries lately which is a cool sign that people are talking about the CDT and spreading the word. Unfortunately some of the comments deal with the difficulty of getting the CDT up and running, especially on Windows.
So I think it's about time to do something about it. One thing I've wanted to do for a while now is to create a Windows installer that bundles up everything you need to start building applications with the CDT. As a product manager I used to work with said, "How do you call it an IDE when you don't bundle a compiler with it?"
So my plan is to bundle the Eclipse Platform and the CDT run-times with the MinGW gcc build tools and gdb debugger. I will bundle in SDL, Simple Directmedia Layer, as a library to start building multimedia apps. I may look at bundling wxWidgets for building traditional GUI apps. I will also look at bundling a JRE so users can get Eclipse up and running with minimal effort, although I'm not sure if the Sun redistributable license will let me do this with an open source app and I'm not sure what other options I have.
Unfortunately a bunch of these components are GPL and LGPL so I won't be able to release it from Eclipse itself given the IP rules. I'll also need to figure out how GPL affects the package and it would be very disappointing if it prevents me from doing this. Sourceforge is probably the best place for this. I plan on using the Nullsoft Installer since it seems to have the most flexibility in any of the other free Windows installer technologies and is used by other open source projects such as MinGW itself.
So I'm interested in peoples' opinions on this, if this is the right set of components for example. Is it worth my time putting together? The idea is to keep it simple so it doesn't take me too much time to start and keep up to date. But I think it'll be a boost to help new users get a start with the CDT, a Kickstart if you will.
So I think it's about time to do something about it. One thing I've wanted to do for a while now is to create a Windows installer that bundles up everything you need to start building applications with the CDT. As a product manager I used to work with said, "How do you call it an IDE when you don't bundle a compiler with it?"
So my plan is to bundle the Eclipse Platform and the CDT run-times with the MinGW gcc build tools and gdb debugger. I will bundle in SDL, Simple Directmedia Layer, as a library to start building multimedia apps. I may look at bundling wxWidgets for building traditional GUI apps. I will also look at bundling a JRE so users can get Eclipse up and running with minimal effort, although I'm not sure if the Sun redistributable license will let me do this with an open source app and I'm not sure what other options I have.
Unfortunately a bunch of these components are GPL and LGPL so I won't be able to release it from Eclipse itself given the IP rules. I'll also need to figure out how GPL affects the package and it would be very disappointing if it prevents me from doing this. Sourceforge is probably the best place for this. I plan on using the Nullsoft Installer since it seems to have the most flexibility in any of the other free Windows installer technologies and is used by other open source projects such as MinGW itself.
So I'm interested in peoples' opinions on this, if this is the right set of components for example. Is it worth my time putting together? The idea is to keep it simple so it doesn't take me too much time to start and keep up to date. But I think it'll be a boost to help new users get a start with the CDT, a Kickstart if you will.
Tuesday, January 02, 2007
The D Programming Language
Well, if you are keeping score at home, you know that I hate Java even though I spend 95% of my coding time in Java, really like C# as Java done right, but not as much as I love C++ which though tough to learn does almost everything right, but can never forget C which is used by most of my QNX customers. And also not to forget Ada which has the best type safety system I've seen. But even with all these choices, I'm still searching for the ultimate programming language that maximizes quality and productivity when building complex systems.
So, of course, I had to check out the D programming language when I learned that it will be releasing in a 1.0 version "real soon now". From the dates on the spec, the idea has been around for a couple of years now. To sum up this new language, it essentially takes the best from C, C++, Java, C#, Python and Ruby in an attempt to make the uber systems programming language.
It is a valiant effort and does have my favorite language features such as garbage collection, delegates, strong typedefs, templates, overloading, etc. It also compiles to native code eliminating the need for a Virtual Machine, although given that it has garbage collection, it still needs an extensive runtime library. But with that and with a smooth integration with C and with Windows C libraries especially, it stays true to the systems programming paradigm.
But the language is huge, almost rivaling the size of Ada. I can see why it's taken quite a while to come up with a 1.0 quality compiler. And we really need to ask the question whether the world needs another systems programming language, especially when it doesn't really add anything new to the collective pool, other than collecting the pool.
I'll keep an eye on its progress as it starts to take on the world. At the end of the day, of course, it'll be the programmer community that decides whether D is so good that it is worth climbing the learning curve and adopting a new toolchain and maybe even a CDT integration.
So, of course, I had to check out the D programming language when I learned that it will be releasing in a 1.0 version "real soon now". From the dates on the spec, the idea has been around for a couple of years now. To sum up this new language, it essentially takes the best from C, C++, Java, C#, Python and Ruby in an attempt to make the uber systems programming language.
It is a valiant effort and does have my favorite language features such as garbage collection, delegates, strong typedefs, templates, overloading, etc. It also compiles to native code eliminating the need for a Virtual Machine, although given that it has garbage collection, it still needs an extensive runtime library. But with that and with a smooth integration with C and with Windows C libraries especially, it stays true to the systems programming paradigm.
But the language is huge, almost rivaling the size of Ada. I can see why it's taken quite a while to come up with a 1.0 quality compiler. And we really need to ask the question whether the world needs another systems programming language, especially when it doesn't really add anything new to the collective pool, other than collecting the pool.
I'll keep an eye on its progress as it starts to take on the world. At the end of the day, of course, it'll be the programmer community that decides whether D is so good that it is worth climbing the learning curve and adopting a new toolchain and maybe even a CDT integration.
Tuesday, December 19, 2006
Stream Computing
And now for something completely different...
Enough about I am Eclipse, Eclipse I am. I actually think Steve Northover really is Eclipse, or is it not Steve's Widget Toolkit? Or is it Crazy Doug's Tooling? Or something...
Anyway, the talk at Tom's Hardware today, or at least this guy's opinion piece, is on AMD's insistence that multi-core is dead, long live Accelerated Processing Units. Actually, it sounds like almost the same thing as multi-core just with fancier hardware as some of the cores. The Opteron architecture makes the array of possibilities interesting and feasible and it'll be cool to see what they come up with now that they've teamed up with my fellow Canadians at ATI.
One possibility I find intriguing is integrating Stream Processors into the concoction. From my Google searches I see stream processing has been around for a couple of years now and it has hit the streets as the technology behind the latest generation of graphics cards. Stream processing is essentially parallel processing units that perform like SIMD processors but on streams of data. In that sense it can handle larger volumes of data like a DSP but with multiple processing units.
So why is that interesting to me. Well, as I am always looking for the next great programming paradigm. When object-oriented first came along when I was in university, I was an early adopter because I could see the benefits it gave me when organizing my programs. I am always looking out for the next big improvement in programmer productivity and we've been stuck now for quite a while with objects and classes and methods and such.
I am positive the next big thing will be parallel programming. The hardware guys are making these great multi-core/multi-processing-thingy machines. The question is what is the right programming paradigm. Is stream processing it? Maybe. But I am thinking that the next big thing has to be multi-dimensional programming in some form or other. I still wonder back to Action Semantics from UML as a possibility, but this stream thing is interesting too...
Enough about I am Eclipse, Eclipse I am. I actually think Steve Northover really is Eclipse, or is it not Steve's Widget Toolkit? Or is it Crazy Doug's Tooling? Or something...
Anyway, the talk at Tom's Hardware today, or at least this guy's opinion piece, is on AMD's insistence that multi-core is dead, long live Accelerated Processing Units. Actually, it sounds like almost the same thing as multi-core just with fancier hardware as some of the cores. The Opteron architecture makes the array of possibilities interesting and feasible and it'll be cool to see what they come up with now that they've teamed up with my fellow Canadians at ATI.
One possibility I find intriguing is integrating Stream Processors into the concoction. From my Google searches I see stream processing has been around for a couple of years now and it has hit the streets as the technology behind the latest generation of graphics cards. Stream processing is essentially parallel processing units that perform like SIMD processors but on streams of data. In that sense it can handle larger volumes of data like a DSP but with multiple processing units.
So why is that interesting to me. Well, as I am always looking for the next great programming paradigm. When object-oriented first came along when I was in university, I was an early adopter because I could see the benefits it gave me when organizing my programs. I am always looking out for the next big improvement in programmer productivity and we've been stuck now for quite a while with objects and classes and methods and such.
I am positive the next big thing will be parallel programming. The hardware guys are making these great multi-core/multi-processing-thingy machines. The question is what is the right programming paradigm. Is stream processing it? Maybe. But I am thinking that the next big thing has to be multi-dimensional programming in some form or other. I still wonder back to Action Semantics from UML as a possibility, but this stream thing is interesting too...
Eclipse is You and Here's Why
There's been some interesting points on the Planet following the "Eclipse is You" post by Bjorn. It has always rubbed me the wrong way when people criticize the committers for not meeting their requirements. And it is not just with these posts, we get it sometimes on the cdt-dev list and bugzilla too. But as I mentioned in my last post, I do appreciate the feedback as it helps me understand what I need to do to grow the community.
But people keep forgetting one thing about the committers. They don't work for the Eclipse Foundation. They are not contractually obligated to do anything, really. I work for QNX Software Systems. They pay me to work on the CDT because it is a fundamental piece of our Momentics IDE. Any work I do beyond that is on my own initiative and if my time is needed elsewhere by my employer, I have to drop those things.
So when people say that the Foundation, or the Eclipse Board for that matter, should get the projects to do this or that, they can't. There is no mechanism in the governance model for Eclipse to make that happen. It just doesn't work that way.
That's why Eclipse is You. Because if you want something done in Eclipse and no one wants to, you have to do it. And, unfortunately, simply submitting patches doesn't work all the time. Because it requires committer time to apply and as I've mentioned, the committers are at the whim of their employers whether they have the time. Not only that, but you may have to persuade the committers that you are doing the right thing.
So we do the best we can and we try to go beyond the call of duty to make sure the community is happy. And most of the time, it works out. But sometimes it doesn't, and I understand the frustration. Remember though that Eclipse is a meritocracy. Submit a number of great patches and help the community out, i.e. go beyond the call of duty yourself, and a committer would be happy to nominate you in as one too.
But people keep forgetting one thing about the committers. They don't work for the Eclipse Foundation. They are not contractually obligated to do anything, really. I work for QNX Software Systems. They pay me to work on the CDT because it is a fundamental piece of our Momentics IDE. Any work I do beyond that is on my own initiative and if my time is needed elsewhere by my employer, I have to drop those things.
So when people say that the Foundation, or the Eclipse Board for that matter, should get the projects to do this or that, they can't. There is no mechanism in the governance model for Eclipse to make that happen. It just doesn't work that way.
That's why Eclipse is You. Because if you want something done in Eclipse and no one wants to, you have to do it. And, unfortunately, simply submitting patches doesn't work all the time. Because it requires committer time to apply and as I've mentioned, the committers are at the whim of their employers whether they have the time. Not only that, but you may have to persuade the committers that you are doing the right thing.
So we do the best we can and we try to go beyond the call of duty to make sure the community is happy. And most of the time, it works out. But sometimes it doesn't, and I understand the frustration. Remember though that Eclipse is a meritocracy. Submit a number of great patches and help the community out, i.e. go beyond the call of duty yourself, and a committer would be happy to nominate you in as one too.
Monday, December 18, 2006
It's all about You!
According to Bjorn, Eclipse is You. Being on the receiving end of many "CDT doesn't do , or CDT is too slow doing ", I couldn't agree more. Say those words and you earn instant membership in the CDT community. And I appreciate every one of them, I actually do. It means you care and have spent the time to contribute your guidance to our collective knowledge. And it's the first step down the path to contributing even more.
Now, Time Magazine has selected the Person of the Year, and it also happens to be You. Coincidence? I think not!
Now, Time Magazine has selected the Person of the Year, and it also happens to be You. Coincidence? I think not!
Wednesday, December 13, 2006
Migrating from Visual C++ to CDT
I've put the finishing touches on the CDT's managed build support for the Windows SDK. Well, at least there's enough there for people to try with our upcoming CDT 4.0 milestone (M4, but it's really our first for this release). It auto-detects where you've installed the compilers, header files, libraries, etc., by looking it up in the registry. I've also updated the error parsers to more accurately parse compile and link errors. It works pretty good and I'm using it to build the native code for the Windows debugger integration.
But, you know, I forgot about the standard builder. It's funny how you get tied up in solving the hard problems when the easy ones are there staring you in the face. I have to give a big thanks to three guys from IBM India who have written a tutorial on how to import Visual C++ projects into the CDT. The solution is elegant in its simplicity and really shows the flexibility of CDT's standard make projects.
All you need to do is get Visual Studio to generate the makefile for you. This is a feature that they've always had to support external builds (although in recent versions you can run Visual Studio headless to do builds as well). Then you create a CDT project at the root directory containing your source. Of course you'll have to change the make command to use nmake, Microsoft's own nasty version of make, but that's pretty easy to do and works well.
Combine that with this guy's perception that the CDT has certain features that Visual Studio users would like, and the discussions I've had with embedded developers using CDT but using Visual Studio for emulation on Windows, gives me a warm fuzzy that supporting the Windows SDK is the right thing for the CDT. There are Windows developers who are looking for a migration path to get into the Eclipse ecosystem.
But, you know, I forgot about the standard builder. It's funny how you get tied up in solving the hard problems when the easy ones are there staring you in the face. I have to give a big thanks to three guys from IBM India who have written a tutorial on how to import Visual C++ projects into the CDT. The solution is elegant in its simplicity and really shows the flexibility of CDT's standard make projects.
All you need to do is get Visual Studio to generate the makefile for you. This is a feature that they've always had to support external builds (although in recent versions you can run Visual Studio headless to do builds as well). Then you create a CDT project at the root directory containing your source. Of course you'll have to change the make command to use nmake, Microsoft's own nasty version of make, but that's pretty easy to do and works well.
Combine that with this guy's perception that the CDT has certain features that Visual Studio users would like, and the discussions I've had with embedded developers using CDT but using Visual Studio for emulation on Windows, gives me a warm fuzzy that supporting the Windows SDK is the right thing for the CDT. There are Windows developers who are looking for a migration path to get into the Eclipse ecosystem.
Thursday, November 30, 2006
Fun with OpenGL ES
I've got two young teenage boys and like a lot of other young teenage boys, they love video games. The computer geek in me, of course, made me wonder how the games were made. So I spent a fair amount of my hobby time a couple years ago learning a bit about the games industry and the technological challenges they face making games look great with limited resources. It was very interesting and if I was a few years (o.k., a lot of years) younger I would have considered a career change in that direction.
But I still poke my head into gaming technology once in a while, especially when I have an excuse to test the CDT on it. One thing that I ran across in my investigation into the needs of embedded developers is support for the OpenGL ES standard. This is a cut-down yet still pretty powerful version of the OpenGL standard that lies at the heart of video games like Doom 3 and the cool desktop effects you see with Mac OS X. The ES version is used on many embedded devices such as cell phones and PDAs.
PowerVR is a chunk of 3D graphics silicon IP that is included in some pretty cool System-on-a-Chip (SoC) parts, often paired with Arm processors. I think you'll see these chips popping up in many new and exciting places. But as this happens, they'll need content to drive their 3D power. And that means a lot of people are going to need to learn how to program to the ES standard.
Imagination Technologies where PowerVR originates came up with a great way to get more people programming for their chips, a Windows OpenGL ES emulation environment. With this environment, you can program an OpenGL ES application and run it on your Windows box instead of having to fork out a lot of money for boards that have the PowerVR core until you get serious about it.
This is great example of why more embedded developers that I run into are excited about the Windows compiler and debugger support in the CDT I am working to deliver for CDT 4.0. With this environment you get a professional quality environment for Windows to build and debug your application with the emulator and then use the same development environment to work with the code as you polish it up for the end device. I'm really looking forward to getting this capability into developers hands so they can build some cool games. For the kids, you know...
But I still poke my head into gaming technology once in a while, especially when I have an excuse to test the CDT on it. One thing that I ran across in my investigation into the needs of embedded developers is support for the OpenGL ES standard. This is a cut-down yet still pretty powerful version of the OpenGL standard that lies at the heart of video games like Doom 3 and the cool desktop effects you see with Mac OS X. The ES version is used on many embedded devices such as cell phones and PDAs.
PowerVR is a chunk of 3D graphics silicon IP that is included in some pretty cool System-on-a-Chip (SoC) parts, often paired with Arm processors. I think you'll see these chips popping up in many new and exciting places. But as this happens, they'll need content to drive their 3D power. And that means a lot of people are going to need to learn how to program to the ES standard.
Imagination Technologies where PowerVR originates came up with a great way to get more people programming for their chips, a Windows OpenGL ES emulation environment. With this environment, you can program an OpenGL ES application and run it on your Windows box instead of having to fork out a lot of money for boards that have the PowerVR core until you get serious about it.
This is great example of why more embedded developers that I run into are excited about the Windows compiler and debugger support in the CDT I am working to deliver for CDT 4.0. With this environment you get a professional quality environment for Windows to build and debug your application with the emulator and then use the same development environment to work with the code as you polish it up for the end device. I'm really looking forward to getting this capability into developers hands so they can build some cool games. For the kids, you know...
Monday, November 27, 2006
printf-free Debugging
When people ask me who the CDT's biggest competitor is, they often expect me to say things like VisualStudio or one of the many Linux IDEs (and no, Netbeans isn't quite there yet). But the truth is that the biggest competitor to the CDT remains good ol' vi and make (or emacs and make for the more advanced developer). We are certainly working hard to make the CDT an easier environment to adopt, but there are still the masses that can not afford the time to climb the learning curve.
But the 'vi and make' answer addresses edit and build. As I've mentioned here before, my favorite IDE feature remains visual debugging. For me, nothing beats that quick glance at the stack and then moving over to the variables view to see what all their values are. Measure that against the number of gdb commands you'd have to enter to do the same, you just can't beat it (did I also mention that I hate typing?).
But looking around the industry, I finally figured out who our main competitor on the debug side is, good ol' printf. Now in some environments where it's hard to set up a debugger and all you got is console output, you have no choice. But how do these guys live with the edit/build/debug cycle every time they want to see a different variable output? And we've all done it at some point in our careers and likely very recently too. We need to make sure we have the right tools to put a stop to this.
At the very least, for the embedded developer, you have JTAG to drive things at the lowest level. And with many of the JTAG devices now supporting the GDB remote protocol, you can use gdb to debug at these levels. The next step is to see the CDT better support GDB running in that configuration. And that's what I'm working on today (sorry Windows debugger, you'll have to wait a couple of weeks).
Tools have an immense opportunity to improve developer productivity. But in order for the developer to benefit from this, the tools need to be easy to learn and use. I think that'll be the next big challenge for the CDT, and one we'll need to address to be truly 'Uber'.
But the 'vi and make' answer addresses edit and build. As I've mentioned here before, my favorite IDE feature remains visual debugging. For me, nothing beats that quick glance at the stack and then moving over to the variables view to see what all their values are. Measure that against the number of gdb commands you'd have to enter to do the same, you just can't beat it (did I also mention that I hate typing?).
But looking around the industry, I finally figured out who our main competitor on the debug side is, good ol' printf. Now in some environments where it's hard to set up a debugger and all you got is console output, you have no choice. But how do these guys live with the edit/build/debug cycle every time they want to see a different variable output? And we've all done it at some point in our careers and likely very recently too. We need to make sure we have the right tools to put a stop to this.
At the very least, for the embedded developer, you have JTAG to drive things at the lowest level. And with many of the JTAG devices now supporting the GDB remote protocol, you can use gdb to debug at these levels. The next step is to see the CDT better support GDB running in that configuration. And that's what I'm working on today (sorry Windows debugger, you'll have to wait a couple of weeks).
Tools have an immense opportunity to improve developer productivity. But in order for the developer to benefit from this, the tools need to be easy to learn and use. I think that'll be the next big challenge for the CDT, and one we'll need to address to be truly 'Uber'.
Subscribe to:
Posts (Atom)