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...
Tuesday, December 19, 2006
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'.
Wednesday, November 22, 2006
SystemC/qemu - Three Worlds Collide
Way back in February, I wrote about a really cool hardware description language called SystemC. It is essentially a C++ library that allows a programmer to model hardware concepts and included a run-time that simulates the hardware. This is one of the reasons I love C++, you can use templates and overloads and inlines to bring the abstraction layer up a few notches, essentially defining a new language, without having to build a new compiler. And it usually optimizes out to something very fast.
I've also been following the development of qemu, a processor emulator that runs on multiple targets and has extensibility to add emulation of peripherals as well. And, if you have a fast machine, you can almost get the same performance as the real hardware. The best thing I see about qemu is that it really lowers the barrier of entry for people who want to try out embedded development without having to spend real money on real hardware. And it is much easier to carry around to trade shows :).
Well, if you have two very cool simulation/emulation environments, wouldn't it make sense to combine them? Of course, and that's what a group from the Universitat Autonoma de Barcelona have done. They have implemented a bridge that appears on the qemu PCI bus for drivers to access and passes signals back and forth to the SystemC design. It's a great idea and really opens the door wider for hardware/software co-design.
I've also been following the development of qemu, a processor emulator that runs on multiple targets and has extensibility to add emulation of peripherals as well. And, if you have a fast machine, you can almost get the same performance as the real hardware. The best thing I see about qemu is that it really lowers the barrier of entry for people who want to try out embedded development without having to spend real money on real hardware. And it is much easier to carry around to trade shows :).
Well, if you have two very cool simulation/emulation environments, wouldn't it make sense to combine them? Of course, and that's what a group from the Universitat Autonoma de Barcelona have done. They have implemented a bridge that appears on the qemu PCI bus for drivers to access and passes signals back and forth to the SystemC design. It's a great idea and really opens the door wider for hardware/software co-design.
Friday, November 17, 2006
Gotta Love The Wide Screen
I got a new laptop last week after mentioning to my boss that I need to see what those Intel guys are up to with the multi-core support they are adding to the CDT. They already have parallel build for the managed build's internal builder and were discussing parallizing the CDT indexers. (Not to mention I always like to have the latest gadgets, shhh). And my boss obliged.
I was a bit concerned with getting the new laptop since our new standard is for a 15" 1680x1050 wide screen. I don't have the best eyes in the world and the fonts looked pretty small on it. But, hey, it would be cool for watching wide screen movies at home. And after setting things up, I got the fonts looking good enough.
But after setting up my Outlook to pane things vertically and firing up Eclipse on it , I can't believe we haven't been using this format before. What a difference! With Eclipse, I'm always dragging the splitters left or right to reveal the outline view or the navigator views or ^M'ing and sending the Editor full screen so I can see long lines of code. Not any more. I used to use my external 19" LCD for most of my Eclipse work, but now I'm finding enjoying working in either (the 19" is at eye height and has bigger pixels so I can see them better, though).
So my favorite tool of the week is now wide screen LCD monitors! Although qemu is still right up there, and they are now working on adding OpenGL support, more on that when I find out more...
Oh, and, BTW, Blogger has a new editor for creating blog entries. I love what it just did for spell checking.
I was a bit concerned with getting the new laptop since our new standard is for a 15" 1680x1050 wide screen. I don't have the best eyes in the world and the fonts looked pretty small on it. But, hey, it would be cool for watching wide screen movies at home. And after setting things up, I got the fonts looking good enough.
But after setting up my Outlook to pane things vertically and firing up Eclipse on it , I can't believe we haven't been using this format before. What a difference! With Eclipse, I'm always dragging the splitters left or right to reveal the outline view or the navigator views or ^M'ing and sending the Editor full screen so I can see long lines of code. Not any more. I used to use my external 19" LCD for most of my Eclipse work, but now I'm finding enjoying working in either (the 19" is at eye height and has bigger pixels so I can see them better, though).
So my favorite tool of the week is now wide screen LCD monitors! Although qemu is still right up there, and they are now working on adding OpenGL support, more on that when I find out more...
Oh, and, BTW, Blogger has a new editor for creating blog entries. I love what it just did for spell checking.
Monday, November 13, 2006
Sun GPL's Their Java
We've all been waiting to see what Sun will really do when it talks about open sourcing Java. I noticed there was a lot of mistrust amongst the open source communities, but I have no prejudices against Sun so I kept an open mind.
Today (well actually over the weekend some time), Sun officially turned on the pipes and you can download it. You can see it all at java.net. There you will find their implementations for J2ME and J2SE as well as J2EE which they had open sourced earlier. For J2SE, they only have the VM and compiler open sourced. I guess they are still working on 3rd party licensing issues to get the complete JDK contributed.
They have chosen GPL as the license with the classpath exception on the libraries so that you can link commercial code without being affected by the GPL license. I'm always a bit cautious about GPL and you really got to be careful when using it but I think it's a pretty good choice that will help avoid the forking that Sun has worried about and enable the JDK to be shipped as part of Linux distributions, which has been a pain in the you know where in the past.
Time will tell, however, how well Sun can build the community around it. If they begin to allow committers from outside of Sun, I think you'll see over time the mistrust fade. But if it becomes apparent that they aren't that serious about letting others play in the sandbox they've made, then it will all be for naught. But if it is successful, it'll be interesting to see how the Apache Harmony project is impacted since they are essentially duplicating effort but with a different license. We'll need a magic decoder ring to figure this all out...
So being the hacker that I am, I drove directly into the source tree to see what the code looked like. They are using subversion, which I really hope that we at Eclipse.org will switch to one day. I also see that the VM code is written in C++ and looks pretty clean. Which, of course, brings up the question on whether you can use the CDT to work on it. Of course you can! And I'll have to spend some time in the upcoming weeks putting a tutorial together to show how.
Interesting times ahead, of that there is no doubt.
Today (well actually over the weekend some time), Sun officially turned on the pipes and you can download it. You can see it all at java.net. There you will find their implementations for J2ME and J2SE as well as J2EE which they had open sourced earlier. For J2SE, they only have the VM and compiler open sourced. I guess they are still working on 3rd party licensing issues to get the complete JDK contributed.
They have chosen GPL as the license with the classpath exception on the libraries so that you can link commercial code without being affected by the GPL license. I'm always a bit cautious about GPL and you really got to be careful when using it but I think it's a pretty good choice that will help avoid the forking that Sun has worried about and enable the JDK to be shipped as part of Linux distributions, which has been a pain in the you know where in the past.
Time will tell, however, how well Sun can build the community around it. If they begin to allow committers from outside of Sun, I think you'll see over time the mistrust fade. But if it becomes apparent that they aren't that serious about letting others play in the sandbox they've made, then it will all be for naught. But if it is successful, it'll be interesting to see how the Apache Harmony project is impacted since they are essentially duplicating effort but with a different license. We'll need a magic decoder ring to figure this all out...
So being the hacker that I am, I drove directly into the source tree to see what the code looked like. They are using subversion, which I really hope that we at Eclipse.org will switch to one day. I also see that the VM code is written in C++ and looks pretty clean. Which, of course, brings up the question on whether you can use the CDT to work on it. Of course you can! And I'll have to spend some time in the upcoming weeks putting a tutorial together to show how.
Interesting times ahead, of that there is no doubt.
Monday, November 06, 2006
EclipseCon 2007 is (Unnecessarily) Fair
Here we go having a debate again on Planet Eclipse. I apologize to my readers who don't follow the Planet. But then you should. It's always great reading!
As a member the EclipseCon 2007 program committee, I had to take offense to Wassim's remarks about the "Contraversial" EclipseCon 2007. Now he has all rights to state his opinion and we should all respect it and take a good look at what's going on. If he's right, then it is something we need to take a look at and make sure it is corrected.
But I think his statements are a bit off the mark. Bjorn had a nice post that summed up a lot of how I felt about it and agree 100% with what he said there. I'd like to add a bit more from the C/C++ track perspective.
First of all, I submitted a proposal for a short tutorial to the C/C++ track that I supposedly control. I did so because, at the time, I didn't have any proposals and was afraid that the C/C++ community was going to miss out on the opportunity. After doing a little recruiting I was able to convince a few members of the community to put in much better proposals than mine and I plan on rejecting mine in favour of theirs.
Now, if I do run into the situation that I have too few proposals for the tracks that have been allocated, or they are too weak, I will propose to offer them up to the rest of the Eclipse community to make sure we get good quality content. My understanding from the other committee members is that they plan on doing the same.
You can't get much more open than actually showing the allocations that have been given to the various tracks. I was pleasantly surprised to see that we were being that open. I've never seen it before, and it does open us up for criticism so early in the process.
I guess what hasn't been made public is that these numbers aren't necessarily written in stone and that we already have mucked around a bit with them. And we have left the door open to do more of the same. As Bjorn mentioned, we are all focused on making the EclipseCon program the best it can be for the attendees, which will go a long way towards growing our community. And I think it's a great thing to be doing it in the open for others to comment on and help improve.
As a member the EclipseCon 2007 program committee, I had to take offense to Wassim's remarks about the "Contraversial" EclipseCon 2007. Now he has all rights to state his opinion and we should all respect it and take a good look at what's going on. If he's right, then it is something we need to take a look at and make sure it is corrected.
But I think his statements are a bit off the mark. Bjorn had a nice post that summed up a lot of how I felt about it and agree 100% with what he said there. I'd like to add a bit more from the C/C++ track perspective.
First of all, I submitted a proposal for a short tutorial to the C/C++ track that I supposedly control. I did so because, at the time, I didn't have any proposals and was afraid that the C/C++ community was going to miss out on the opportunity. After doing a little recruiting I was able to convince a few members of the community to put in much better proposals than mine and I plan on rejecting mine in favour of theirs.
Now, if I do run into the situation that I have too few proposals for the tracks that have been allocated, or they are too weak, I will propose to offer them up to the rest of the Eclipse community to make sure we get good quality content. My understanding from the other committee members is that they plan on doing the same.
You can't get much more open than actually showing the allocations that have been given to the various tracks. I was pleasantly surprised to see that we were being that open. I've never seen it before, and it does open us up for criticism so early in the process.
I guess what hasn't been made public is that these numbers aren't necessarily written in stone and that we already have mucked around a bit with them. And we have left the door open to do more of the same. As Bjorn mentioned, we are all focused on making the EclipseCon program the best it can be for the attendees, which will go a long way towards growing our community. And I think it's a great thing to be doing it in the open for others to comment on and help improve.
Friday, November 03, 2006
Microsoft Novell
I've been busy working on the CDT integration with the Windows SDK and, at the moment the Windows debug engine, to support C++ development using this SDK as a choice over cygwin/mingw for Windows development. As I've mentioned previously, I'm keen on getting Eclipse and the CDT in a state where it can be useful for Windows developers and open up a whole new community to this great thing we've got going with Eclipse.
Taking a break from debugging the debugger yesterday, I tripped over a Slashdot article that said there was going to be a press conference webcast at 5 p.m. EST announcing a partnership between Microsoft and Novell on Linux. After checking the calendar to mare sure it wasn't April 1, I tuned in. Watching the proceedings, I got that feeling I was watching history, like when Wayne Gretzky announced his retirement. Time will tell whether Microsoft entering the Linux/open source world will change anything, but today, it looks pretty significant.
What was clear was that it is more like Microsoft grudgingly admitting Linux is important with its customers, than Microsoft throwing in the towel. But I think that is an important admission that will change how the open source world views Microsoft and, more importantly, how the Microsoft world views open source and Linux in particular.
Which brings me back to my Windows SDK integration. One of the visions we had for the CDT in the early days, was for the CDT to be the cross platform development environment that eases the transition for Windows developers who want to start working on Linux apps. It was great in theory, but the demand didn't really materialize (and neither did the community). Time will tell whether this announcement changes that. But in the meantime, it has given me a little extra energy to try and make sure the Windows SDK integration happens for both C++ and C# (Mono may have been given a boost with this also) to at least make the path easier to follow.
Taking a break from debugging the debugger yesterday, I tripped over a Slashdot article that said there was going to be a press conference webcast at 5 p.m. EST announcing a partnership between Microsoft and Novell on Linux. After checking the calendar to mare sure it wasn't April 1, I tuned in. Watching the proceedings, I got that feeling I was watching history, like when Wayne Gretzky announced his retirement. Time will tell whether Microsoft entering the Linux/open source world will change anything, but today, it looks pretty significant.
What was clear was that it is more like Microsoft grudgingly admitting Linux is important with its customers, than Microsoft throwing in the towel. But I think that is an important admission that will change how the open source world views Microsoft and, more importantly, how the Microsoft world views open source and Linux in particular.
Which brings me back to my Windows SDK integration. One of the visions we had for the CDT in the early days, was for the CDT to be the cross platform development environment that eases the transition for Windows developers who want to start working on Linux apps. It was great in theory, but the demand didn't really materialize (and neither did the community). Time will tell whether this announcement changes that. But in the meantime, it has given me a little extra energy to try and make sure the Windows SDK integration happens for both C++ and C# (Mono may have been given a boost with this also) to at least make the path easier to follow.
Thursday, October 12, 2006
CDT at the Eclipse Summit Europe
I'm having a great time here at Eclipse Summit Europe. It's the first time I've been in Europe and it's a pretty darn cool place to be. Watching TV and walking around the area has made me really want to learn German, which is my heritage anyway. And the architecture in this area of Esslingen is unbelievably amazing throwback to early Germany. Someone mentioned that it's like something Disney would build.
Jet lag had kicked in hard just before my talk on the CDT DOM so I'll apologize to everyone who was there if it seemed disorganized. I was glad to be able to get the message out on how we are doing with the CDT and the cool things we are working on. The biggest feedback was the interest in the C#DT support I want to build on the CDT. I'm just trying to prove out CDT's multi-language capability but people are intrigued by the undertones of it all.
I also met a few people who were users of the CDT. Everyone gave me positive feedback on the performance improvements with the indexer. One group had even added a few UI features to make their lives easier and I encouraged them to contribute them back to the community, which the appeared happy to do. This is a general message I should remind everyone. If you have made little improvements to the CDT, feel free to contribute them. We're certainly interested in spending time looking at patches especially as it improves the user experience for all.
Given the liveliness of the discussions in the foyer where we had lunches and get togethers, I'd say Eclipse is live and well in Europe. Certainly looking at the list of people who attended the CDT summit, Europe is an important place that we need to focus on more and ensure the community can easily span the oceans, and time zones...
Jet lag had kicked in hard just before my talk on the CDT DOM so I'll apologize to everyone who was there if it seemed disorganized. I was glad to be able to get the message out on how we are doing with the CDT and the cool things we are working on. The biggest feedback was the interest in the C#DT support I want to build on the CDT. I'm just trying to prove out CDT's multi-language capability but people are intrigued by the undertones of it all.
I also met a few people who were users of the CDT. Everyone gave me positive feedback on the performance improvements with the indexer. One group had even added a few UI features to make their lives easier and I encouraged them to contribute them back to the community, which the appeared happy to do. This is a general message I should remind everyone. If you have made little improvements to the CDT, feel free to contribute them. We're certainly interested in spending time looking at patches especially as it improves the user experience for all.
Given the liveliness of the discussions in the foyer where we had lunches and get togethers, I'd say Eclipse is live and well in Europe. Certainly looking at the list of people who attended the CDT summit, Europe is an important place that we need to focus on more and ensure the community can easily span the oceans, and time zones...
Saturday, October 07, 2006
Qemu, my favorite tool of the week
I've been with QNX for over a year now and I continue to learn all I can about our Neutrino operating system, and development issues faced by embedded developers in general. If I'm going to focus on tools for embedded developers, I need to get inside their shoes and walk the talk.
I've worked with a couple of development boards and that was pretty cool, especially when lights started flashing and it started communicating out the serial and ethernet ports. But carrying around a board, even a little one, is a bit cumbersome and not very practical. I've been a long time fan of VMware and have used that. But, x86 is not where the excitement is at in the mobile embedded market, so I have been looking for something that was less desktop-y to use.
Recently I ran accross an article on using Qemu, an open source processor emulator that can emulate a number of different processors and peripheral devices, to run a Debian Linux ARM installation. It also claims that on faster machines, it can even be faster than the actual ARM processors it is emulating. This is exactly what I was looking for.
So I've started down a journey of writing a Neutrino BSP (Board Support Package) for Qemu, which emulates the ARM Versatile Platform Baseboard. I have the programmers guide for this board which is a pretty good help, but thanks to the fact that I have the source for the emulator, if I have any questions about how certain registers work, I can just look at the implementation in Qemu. The architecture is very clean so it makes these things very easy to find. It also includes a gdb remote interface that acts like a JTAG interface so I can step through my code.
With all these goodies, I think I'll have Neutrino up and running in this environment in no time. Very cool! There is a tutorial floating around by James Lynch on using the CDT with a tiny ARM-based board. I should write a similar tutorial on using Qemu's ARM emulation with the CDT and make sure these environments work well. It's a great learning tool if nothing else.
I've worked with a couple of development boards and that was pretty cool, especially when lights started flashing and it started communicating out the serial and ethernet ports. But carrying around a board, even a little one, is a bit cumbersome and not very practical. I've been a long time fan of VMware and have used that. But, x86 is not where the excitement is at in the mobile embedded market, so I have been looking for something that was less desktop-y to use.
Recently I ran accross an article on using Qemu, an open source processor emulator that can emulate a number of different processors and peripheral devices, to run a Debian Linux ARM installation. It also claims that on faster machines, it can even be faster than the actual ARM processors it is emulating. This is exactly what I was looking for.
So I've started down a journey of writing a Neutrino BSP (Board Support Package) for Qemu, which emulates the ARM Versatile Platform Baseboard. I have the programmers guide for this board which is a pretty good help, but thanks to the fact that I have the source for the emulator, if I have any questions about how certain registers work, I can just look at the implementation in Qemu. The architecture is very clean so it makes these things very easy to find. It also includes a gdb remote interface that acts like a JTAG interface so I can step through my code.
With all these goodies, I think I'll have Neutrino up and running in this environment in no time. Very cool! There is a tutorial floating around by James Lynch on using the CDT with a tiny ARM-based board. I should write a similar tutorial on using Qemu's ARM emulation with the CDT and make sure these environments work well. It's a great learning tool if nothing else.
Friday, October 06, 2006
Open Source, The Double Edge Sword
I know this has been talked about a lot in the open source industry, but I've personally started to see concrete examples of it. Commercial adoption of open source software is a double edge sword. One the one side, it is great to have the flexibility to be able to take open source solutions, adapt them to your particular problem domain, and add the value of those solutions to your product. On the other side, it is a lot of work to do that, and in a commercial setting, lot of work == big expense.
And, of course, you really have to watch the pointy end of the sword that could kill your project, and I think that pointy end is unrealistic expectations. But, I think the industry is really starting to get that open source != free. And, unfortunately, I think a lot of it comes from war wounds, but the lesson is getting learned.
This does, however, come back to the software as a service story I keep blabbing about. Now, you can either hire and train people to do the work, or you can contract out to a services company that (hopefully) already has the trained people to do the work for you (hopefully) cheaper. It was pretty interesting then when I noticed a little-advertised feature of the Eclipse.org web site, the Services section. It lists a few companies that are offering services to the Eclipse community. It is unfortunate that there are so few and very few with a non-Enterprise focus, but the opportunity is there for those who want to take it.
And, of course, you really have to watch the pointy end of the sword that could kill your project, and I think that pointy end is unrealistic expectations. But, I think the industry is really starting to get that open source != free. And, unfortunately, I think a lot of it comes from war wounds, but the lesson is getting learned.
This does, however, come back to the software as a service story I keep blabbing about. Now, you can either hire and train people to do the work, or you can contract out to a services company that (hopefully) already has the trained people to do the work for you (hopefully) cheaper. It was pretty interesting then when I noticed a little-advertised feature of the Eclipse.org web site, the Services section. It lists a few companies that are offering services to the Eclipse community. It is unfortunate that there are so few and very few with a non-Enterprise focus, but the opportunity is there for those who want to take it.
Tuesday, September 26, 2006
JDT/CDT, Can't we just get along?
So between putting the finishing touches on CDT 3.1.1, some QNX work items, and dealing with the various summits and stuff, I've started working a little on my CDT/Windows Debugger API integration. It didn't take too long before I got my workspace set up to work on it. I'm creating Java classes that will plug into the CDT's debug engine (or engines as the new Debug Services Framework comes together). I'm also creating C++ code to implement native methods that talk to the Windows APIs. I'm also about to figure out the right way to do callbacks from those APIs trough my C++ code up into the Java code.
I'm trying to follow as much as I can the SWT model by doing as little in the native code as possible and putting most of the logic in Java. As much as I prefer C++ to Java, I don't have a good answer to the question "How do you debug the debugger" so I'll be relying on the Java debugger and good ol' printfs to get me through.
But once you have a mix of CDT and JDT projects, the workflows aren't pretty. The first thing that hit me was when I was in the C/C++ Perspective and hit the New Class button to create a Java class. Uh, nope, that creates a C++ class. So I'm starting to find myself flipping back and forth between the Java and C/C++ perspectives to get the right navigator views and toolbar buttons at the right time. It's a pain and it would be nice if we had a "Code" perspective or something where we could write code without the context switching.
And then, there's the result of my work. When I do get the debugger integrated, I may just wish to debug my debugger or some other JNI application with it. The "Holy Grail" for us in CDT-land has always been to be able to step from Java code into C++ code and back and forth seamlessly.
We've talked about this since the first CDT get-together back in July 2002. I've tried to get it to work with some success but got sidetracked with other things. The guys at Intel presented a proposal on such an environment at our Spring summit, bit I haven't heard much about that since. I'm interested in hearing peoples' opinion on whether this is something they feel is important for Eclipse. And, of course, I'm interested in ideas on how we can build a community to help make this happen. If nothing, it will be a lot of work.
I'm trying to follow as much as I can the SWT model by doing as little in the native code as possible and putting most of the logic in Java. As much as I prefer C++ to Java, I don't have a good answer to the question "How do you debug the debugger" so I'll be relying on the Java debugger and good ol' printfs to get me through.
But once you have a mix of CDT and JDT projects, the workflows aren't pretty. The first thing that hit me was when I was in the C/C++ Perspective and hit the New Class button to create a Java class. Uh, nope, that creates a C++ class. So I'm starting to find myself flipping back and forth between the Java and C/C++ perspectives to get the right navigator views and toolbar buttons at the right time. It's a pain and it would be nice if we had a "Code" perspective or something where we could write code without the context switching.
And then, there's the result of my work. When I do get the debugger integrated, I may just wish to debug my debugger or some other JNI application with it. The "Holy Grail" for us in CDT-land has always been to be able to step from Java code into C++ code and back and forth seamlessly.
We've talked about this since the first CDT get-together back in July 2002. I've tried to get it to work with some success but got sidetracked with other things. The guys at Intel presented a proposal on such an environment at our Spring summit, bit I haven't heard much about that since. I'm interested in hearing peoples' opinion on whether this is something they feel is important for Eclipse. And, of course, I'm interested in ideas on how we can build a community to help make this happen. If nothing, it will be a lot of work.
Right Place, Right Time (part 2)
Having concluded that I haven't done anything really to help guarantee the CDT's success, I do have a few mantras that are hopefully contributing to a healthy community.
- Be open. This was actually pretty hard at first when it was only QNX and then only QNX and IBM/Rational when the only people who cared about what you were doing were sitting down the hall or across town. But with the CDT development community spread around the world, working in the open is critical. In the CDT we have healthy discussions in Bugzilla and on the cdt-dev list and are looking at ways to share ideas and work together more often and more fluidly.
- Equality. A lot of open source projects tend to be dominated by one or two organizations and unfortunately a lot of Eclipse projects are this way. In the CDT, no one dominates. No organization has more than around 5 developers and most are around 2. And there are over 10 organizations involved. We honor the veto committer voting system so we aim to get consensus before taking big steps and usually do.
- Spread the Word. At times I feel like I'm a part of our marketing team here at QNX, and I guess part of my role is that. You can hope people stumble onto your project and get interested, but the media has a role to play helping you spread the word. And with the number of online magazines and webinar services in business now, they are always looking for a new angle. Take advantage of it.
Monday, September 25, 2006
Right place, Right Time (part 1)
One thing I've been asked recently is to share why the CDT is successful in the Eclipse community. It's a really hard question for me to answer since I'm not sure I can trace anything I've done as a project lead to help with this success. That and I'm not sure whether it really is successful. I've been pretty happy with its popularity with over 340,000 downloads of CDT 3.0.2 and 35 developers attending last weeks CDT summit. I think we still have a long way to go to reach the quality levels of the JDT and VisualStudio, but now that we have so much attention on the CDT, we're trying to address that. So, I think the real question is - why is the CDT so popular, and what have we done as a project to help achieve that. My answer is in two parts so I'll make this a two part blog entry.
So the first part of my answer is this: "Dumb luck", or maybe slightly less self-deprecating, "Being at the right place at the right time". QNX started the CDT back in 2002 because we needed an IDE to help developers writing applications for our operating system be more productive. Now, we're not an IDE company and seeing what IBM had in store for building an open source community around Eclipse, we reckoned that would be the right way to go for the CDT as well. The hope was that lots of other non-IDE companies needed an IDE too and we could all share the development cost of it.
It was a gamble and it did take four years to reach this point, but in the end we were right. The reason the CDT is so popular is that there is a huge need in the non-Windows market for a universal IDE that vendors and users can easily leverage for their own needs. Given the huge popularity of Eclipse and with the CDT being the C/C++ solution for Eclipse, it just becomes natural that people gravitate to the CDT. That and the CDT promises to be a high quality, feature rich C/C++ development environment that you have had to pay money for in the past. Everyone like free stuff that's good.
So in the end, I don't think we've done anything in particular to help make the CDT as popular as it is other than simply having the right solution at the right time. I wish I can claim otherwise, but it is what it is. In the next part of this blog entry, though, I will try to list some of the things we've tried aimed at making sure the CDT is an open, welcoming community that will hopefully keep this momentum going. Having something good and free helps with consumption of your open source project, but it doesn't provide any guarantees that it'll attract developers to help you build and test it.
So the first part of my answer is this: "Dumb luck", or maybe slightly less self-deprecating, "Being at the right place at the right time". QNX started the CDT back in 2002 because we needed an IDE to help developers writing applications for our operating system be more productive. Now, we're not an IDE company and seeing what IBM had in store for building an open source community around Eclipse, we reckoned that would be the right way to go for the CDT as well. The hope was that lots of other non-IDE companies needed an IDE too and we could all share the development cost of it.
It was a gamble and it did take four years to reach this point, but in the end we were right. The reason the CDT is so popular is that there is a huge need in the non-Windows market for a universal IDE that vendors and users can easily leverage for their own needs. Given the huge popularity of Eclipse and with the CDT being the C/C++ solution for Eclipse, it just becomes natural that people gravitate to the CDT. That and the CDT promises to be a high quality, feature rich C/C++ development environment that you have had to pay money for in the past. Everyone like free stuff that's good.
So in the end, I don't think we've done anything in particular to help make the CDT as popular as it is other than simply having the right solution at the right time. I wish I can claim otherwise, but it is what it is. In the next part of this blog entry, though, I will try to list some of the things we've tried aimed at making sure the CDT is an open, welcoming community that will hopefully keep this momentum going. Having something good and free helps with consumption of your open source project, but it doesn't provide any guarantees that it'll attract developers to help you build and test it.
Friday, September 22, 2006
CDT Fall Summit Wrap-up
When I finalized the agenda for the Fall Summit this year, I didn't think there was any way we'd fill up 3 days. Thinking back to last year, we really ran out of things to talk about by noon on the third day. I also figured that it would be a great idea if we had some time to go through the code and work through some of the nitty gritty details with the gang huddled around a laptop. So I decided to set aside Thursday afternoon for that.
Well, at the end if it all, given the number of topics we had to chop out and the number of items where I had to say that we were running behind, we could have spent a whole week. Mind you our brains would have been mush. They were anyway after three days. It was great to see that we have a big development community that knows a lot about the CDT and want to make it even better. It also showed that we need to do this more often, maybe not travel, but find some way to share ideas and debate even virtually.
One of the best items we had, at least for me, was at the very end. I asked the group how we could improve how the CDT is run as a software project. The answer I got back was that we need to work hard on ensuring we have quality releases. In the past, we've been very accommodating to developers, accepting that they come and go and contribute what they can when they can. But that adhoc approach to project management isn't leading to high quality releases, especially at the x.x.0 releases. The team showed a strong desire to, well, be "managed" as a software development team, much like they are when working on their own commercial projects.
So that is now my number one challenge. We need to tighten down the processes, be more strict on quality, and start putting together guidelines that we need the developers to follow. We also need to ensure that our test coverage is managed and improved. Manage the CDT much like any software development project. To me the big challenge is that none of these developers have any contractual obligation to follow any of this. And we have developers from over 10 different organizations. This is open source and they are volunteers (or at least their organizations have volunteered them). So it is going to be a bit of a delicate balance to ensure we have the right mechanisms in place and that the developers honor them.
But at the end of the day, I think just having processes and guidelines will give the developers something to follow and they will probably feel naturally obliged to follow. And with the strength of the characters that we have working on the CDT, I'm sure a little peer pressure will help too. I am very excited about moving into this next stage in the maturing of the CDT project. If it all works, maybe I'll do an MBA thesis on it :).
Well, at the end if it all, given the number of topics we had to chop out and the number of items where I had to say that we were running behind, we could have spent a whole week. Mind you our brains would have been mush. They were anyway after three days. It was great to see that we have a big development community that knows a lot about the CDT and want to make it even better. It also showed that we need to do this more often, maybe not travel, but find some way to share ideas and debate even virtually.
One of the best items we had, at least for me, was at the very end. I asked the group how we could improve how the CDT is run as a software project. The answer I got back was that we need to work hard on ensuring we have quality releases. In the past, we've been very accommodating to developers, accepting that they come and go and contribute what they can when they can. But that adhoc approach to project management isn't leading to high quality releases, especially at the x.x.0 releases. The team showed a strong desire to, well, be "managed" as a software development team, much like they are when working on their own commercial projects.
So that is now my number one challenge. We need to tighten down the processes, be more strict on quality, and start putting together guidelines that we need the developers to follow. We also need to ensure that our test coverage is managed and improved. Manage the CDT much like any software development project. To me the big challenge is that none of these developers have any contractual obligation to follow any of this. And we have developers from over 10 different organizations. This is open source and they are volunteers (or at least their organizations have volunteered them). So it is going to be a bit of a delicate balance to ensure we have the right mechanisms in place and that the developers honor them.
But at the end of the day, I think just having processes and guidelines will give the developers something to follow and they will probably feel naturally obliged to follow. And with the strength of the characters that we have working on the CDT, I'm sure a little peer pressure will help too. I am very excited about moving into this next stage in the maturing of the CDT project. If it all works, maybe I'll do an MBA thesis on it :).
Wednesday, September 20, 2006
More Open Source Hardware
I've got Google Alerts notifying me when something comes up with Eclipse CDT and another one for Eclipse embedded. I'm starting to get a few of these a week, including two today. One came from Lattice Semiconductor. What was noteworthy in this case was they were also open sourcing the design for their 32-bit microcontroller. Now these guys are a lot smaller than Sun who open sourced the design for their Niagara 8-core Sparc chip. But I'm starting to wonder if there really is a trend happening here.
If this means we'll see more people customizing chip designs using hardware description languages and building the software that will run on them, then Eclipse is an obvious host for this kind of hardware/software codesign activity.
If this means we'll see more people customizing chip designs using hardware description languages and building the software that will run on them, then Eclipse is an obvious host for this kind of hardware/software codesign activity.
CDT Summit Day 1
Well we got off to a great start at the Summit today. The day went by real fast and we were all pretty burned out by the end of it so it must have been good :). One highlight for me was when I asked for hands on who was a committer. I got the 7 or so I was expecting. I then asked who had contributed patches. To my happy surprise, I got over 20. That explains why we have so many patches outstanding in bugzilla for the CDT. It is certainly one sign the CDT contributor community is healthy, but its also a sign that we have a lot of work ahead to keep up and to start nominating more committers.
We spend the day introducing eachother and then dug deep into the CDT DOM. I have to admit that one was really dry, and I was the one giving it. We then got an update from the Intel team on what they'd like to do with the build information in the new project wizard and the project properties. Looks like a big change that should hopefully smooth out some workflow issues that we have there. Another big day tomorrow as we review some of the new source navigation and indexing features and dig into debug.
Another thing I'm trying is Skypecast to broadcast the proceedings. You can check it out by following the link. It is definitely a technology preview and we had a hard time getting remote people hooked up to the sound system we have running without horrible echo and feedback. But the broadcast out sounds O.K. (as long as I mute the mic on my laptop, sorry Norbert!) I'm sure it would work better if everyone was working through headsets, instead of trying what we're doing with capturing the audio through a sound board. But it is an interesting way of communicating when working on open source projects.
We spend the day introducing eachother and then dug deep into the CDT DOM. I have to admit that one was really dry, and I was the one giving it. We then got an update from the Intel team on what they'd like to do with the build information in the new project wizard and the project properties. Looks like a big change that should hopefully smooth out some workflow issues that we have there. Another big day tomorrow as we review some of the new source navigation and indexing features and dig into debug.
Another thing I'm trying is Skypecast to broadcast the proceedings. You can check it out by following the link. It is definitely a technology preview and we had a hard time getting remote people hooked up to the sound system we have running without horrible echo and feedback. But the broadcast out sounds O.K. (as long as I mute the mic on my laptop, sorry Norbert!) I'm sure it would work better if everyone was working through headsets, instead of trying what we're doing with capturing the audio through a sound board. But it is an interesting way of communicating when working on open source projects.
Subscribe to:
Posts (Atom)