Reaching new heights in geekness, I watched the landing of the Phoenix spacecraft on Mars last night live over the web via NASA TV. I don't know, I find there's lots of drama in space missions. It's an incredible task. One of the mission managers compared it to hitting a hole in one in Australia from a tee in Ottawa (ok, he said Washington but Ottawa is about the same distance :). Another manager closer to the action added, "with Australia moving". The good news is that they pinned it, relatively, missing only by 20km, rimming it around the hole before dropping it if you will.
The highlight for me was watching the jubilation as the guy called out that the spacecraft had reported a touchdown detected event. The gratification of years of work wrapped up in a single (probably) 2 byte event report is well deserved. That little report required so much technology to be working, it's mind boggling.
That feeling of jubilation is what I call a woo-hoo moment. Mind you nothing I've done compares to the moment these guys had, but I think it's an important aspect of all software development. It's these little moments that help you realize all that hard work you've put into the project actually works and you can do a little celebration (usually throwing my hands into the air for me and yelling "yes" :). It helps get the adrenalin going and really gives you the energy to start working towards the next one.
In my career I've had a number of these moments and I always try to schedule them into the projects I'm working on. And these moments I don't soon forget: the first run of an external code generated state machine from ObjecTime Developer happened a long time ago and I still remember when it happened. My work on the CDT has had a few too. The first outline view from CDT's first parser, the first content assist (which was a surprise since the Neifer just did a couple of tweaks to the binding resolution code and it just worked), and the first complete index of the Firefox source using the new Fast indexer that beat my set goal of 20 minutes (it's now around 13 minutes the last I looked). And more recently, I have the first install of Wind River product based on p2 (the DVD is hanging on my wall :).
I'm sure we all have moments like this throughout our lives. For software development, this is why I think iterative development is the only way to go. Not only does it give you a chance to show your customers progress and get their feedback, it lets you schedule in gratuitous woo-hoo moments.
Monday, May 26, 2008
Monday, May 19, 2008
Just call me a p2 fanboy
There's been a lot of bashing of p2 lately by blogs on Planet Eclipse. They seem to revolve around the lack of support for extension locations. I've never used extension locations, and I hate the fact that for whatever reason you would need to manage installs yourself by hacking around the file system.
p2, IMHO, is awesome. It manages installs as good as any install management system I've seen. It tracks versions, it manages dependencies with capabilities which is absolutely the right way to do it. It allows you to install things other than eclipse plug-ins thanks to the extensibility provides by touch points and repositories. When we're done you'll be able to everything your favorite install manager can do and more. From where I sit p2 will change the install industry.
So yeah, extension locations aren't supported any more. And I'm probably not the best person to speak on whether losing them matters. But someone needs to stand up for p2 because it is much needed. And I'm sure you can live without extension locations. I think the worse mistake was providing them to begin with.
p2, IMHO, is awesome. It manages installs as good as any install management system I've seen. It tracks versions, it manages dependencies with capabilities which is absolutely the right way to do it. It allows you to install things other than eclipse plug-ins thanks to the extensibility provides by touch points and repositories. When we're done you'll be able to everything your favorite install manager can do and more. From where I sit p2 will change the install industry.
So yeah, extension locations aren't supported any more. And I'm probably not the best person to speak on whether losing them matters. But someone needs to stand up for p2 because it is much needed. And I'm sure you can live without extension locations. I think the worse mistake was providing them to begin with.
Friday, May 16, 2008
CDT 5.0 looks good, now looking ahead
The CDT gang has put together a list of new features that are coming out with CDT 5.0 in a few weeks. Check it out here. There has been a lot of work further improving the indexer and we have a new refactoring framework with a few refactorings available. And there has been a little work on the build and debug side as well.
It was a good sign this release that we had no major architectural changes and got to focus on quality. There is a new scanner/preprocessor for the CDT's parsers but, trust me, that was much needed and Markus S did such a great job that we hardly noticed the change. Compared to the new indexer framework in 3.1 and the new build framework in 4.0 things went much more smoothly this time.
As I start to work on Wascana 1.0 based on this great work, I still notice a couple of areas that we need to work on for next year's 5.1. First of all is the tighter intergration of the Debug Services Framework (DSF) that is being built by the Device Debugging project. This is a pretty cool framework that is highly asynchronous and extendible. I am working on integrating MinGW's gdb with it as an exemplary integration both to help me learn DSF and to show others how to use it.
But to make this integration seamless, we really need to do something about the Launch Configurations. Right now DSF provides it's own set, meaning if you have CDT's current debug framework and DSF installed at the same time you get two sets. That's going to be terribly confusing. And, from what I hear, every vendor that integrates their own debuggers with the CDT add in their own sets. I'd like to see if we can get a common launch framework in place to help solve this, assuming there's support from the community for that.
The other big issue we've got to address is the CDT build system. We've tried to support two modes of build, using external build systems, and using Visual Studio-like internal build. External is easy. But, unfortunately, my feeling is that we've made things too complicated on the "managed" build side. There has been some great work done up until now by the committers, but we need to make sure we're meeting the needs of the community and either address them or provide the extensibility to allow them to do what they need but still provide a common user experience.
My real objective is to provide a common user experience for all CDT users whether they're using a commercial product or the standard open one. That means unifying the workflows for everyone. Maybe then it'll make financial sense for someone or a group of someones to write a CDT book to serve all of the CDT community.
It was a good sign this release that we had no major architectural changes and got to focus on quality. There is a new scanner/preprocessor for the CDT's parsers but, trust me, that was much needed and Markus S did such a great job that we hardly noticed the change. Compared to the new indexer framework in 3.1 and the new build framework in 4.0 things went much more smoothly this time.
As I start to work on Wascana 1.0 based on this great work, I still notice a couple of areas that we need to work on for next year's 5.1. First of all is the tighter intergration of the Debug Services Framework (DSF) that is being built by the Device Debugging project. This is a pretty cool framework that is highly asynchronous and extendible. I am working on integrating MinGW's gdb with it as an exemplary integration both to help me learn DSF and to show others how to use it.
But to make this integration seamless, we really need to do something about the Launch Configurations. Right now DSF provides it's own set, meaning if you have CDT's current debug framework and DSF installed at the same time you get two sets. That's going to be terribly confusing. And, from what I hear, every vendor that integrates their own debuggers with the CDT add in their own sets. I'd like to see if we can get a common launch framework in place to help solve this, assuming there's support from the community for that.
The other big issue we've got to address is the CDT build system. We've tried to support two modes of build, using external build systems, and using Visual Studio-like internal build. External is easy. But, unfortunately, my feeling is that we've made things too complicated on the "managed" build side. There has been some great work done up until now by the committers, but we need to make sure we're meeting the needs of the community and either address them or provide the extensibility to allow them to do what they need but still provide a common user experience.
My real objective is to provide a common user experience for all CDT users whether they're using a commercial product or the standard open one. That means unifying the workflows for everyone. Maybe then it'll make financial sense for someone or a group of someones to write a CDT book to serve all of the CDT community.
Wednesday, May 14, 2008
It's all good, but not enough D's
Well, I think I'm finished my journey into Flash-land. It was an interesting experience. I'm glad I took a deeper look at it and gained an understanding about what the fuss was all about. The deeper look also left me wondering how free the Flash run-time components for devices will really be and how they'll actually deliver bits that will run on your favorite device without really opening the source, or at least making it public. But the technology is very interesting and I'd love to see animated UIs on devices become more common place.
But at the end of it, it left me wanting. The big new thing we're seeing on the desktop is 3D enabled UIs. 2D is good, but I think there are some really exciting things you can do when you add another D to the mix. You can see some of the potential in the UIs presented by console video games. I'll never forget my first eye opener with the old Rogue Squadron Star Wars game on our first video console, the Nintendo 64, and entering your name with the 3D spinning wheel of letters. It was fun and since you didn't have a keyboard it made the arduous task a little more pleasant.
What I think is missing, though, is a commonly available widget set that makes it easy to program 3D UIs. There may be some out there, but I'd like to see them become more mainstream. And as more and more devices come with 3D hardware accelerated graphic circuitry embedded in their processors and OpenGL ES 3D graphics API for devices becoming more ubiquitous, I'm hoping the industry can take a more serious look at this. Devices are becoming less resource constrained as we go, but they'll always be UI constrained. Maybe 3D can help.
But at the end of it, it left me wanting. The big new thing we're seeing on the desktop is 3D enabled UIs. 2D is good, but I think there are some really exciting things you can do when you add another D to the mix. You can see some of the potential in the UIs presented by console video games. I'll never forget my first eye opener with the old Rogue Squadron Star Wars game on our first video console, the Nintendo 64, and entering your name with the 3D spinning wheel of letters. It was fun and since you didn't have a keyboard it made the arduous task a little more pleasant.
What I think is missing, though, is a commonly available widget set that makes it easy to program 3D UIs. There may be some out there, but I'd like to see them become more mainstream. And as more and more devices come with 3D hardware accelerated graphic circuitry embedded in their processors and OpenGL ES 3D graphics API for devices becoming more ubiquitous, I'm hoping the industry can take a more serious look at this. Devices are becoming less resource constrained as we go, but they'll always be UI constrained. Maybe 3D can help.
Wednesday, May 07, 2008
Flash on the Brain
I hate it when that happens. A shiny object flies by and I can't sleep until I catch it. So I was up until 3 a.m. last night trying to figure out what Adobe Air/Flex/Flash/ActionScript was all about. It's actually pretty interesting stuff technically. But as a number of people commented when I brought it up a couple of days ago, you do get the sense of vendor lock in, at least for now. But the specs are all open now, so open source implementations of this stuff at least have a fighting chance.
So why do I care about Flash (other than my insatiable need to learn as much as I can about the software industry)? Well, it fits in with my interest in mobile devices, especially those based on embedded Linux. As these devices get more powerful and have bigger screens, the line between laptop and mobile device is going to blur. And I think the expectations of users on the UI for these devices is going to grow as well. Everyone oos and ahs over the iPhone UI. It's setting the bar.
But looking at a traditional embedded Linux box with a UI, does it make sense to run X Windows on it? X is horrible and antiquated. And it's very hard to build flashy (sorry about the pun) UIs with it. It certainly wasn't intended for resource constrained devices. Mind you the old X Terminals were pretty much embedded devices, but then where are they now...
So what are the alternatives? DirectFB looks very promising and is growing in popularity in the embedded world. It gives you an nice API over the graphics hardware and input devices that let you build your UI as low level as you need. But it does require you to build a UI from scratch.
So this is the architecture that piqued my interest: Adobe AIR (which include Flash and the WebKit browser) running on DirectFB. Which then opens up other interesting architectures. Like mobile devices turning into web appliances that let you work connected or disconnected (is there a Flash office suite app?). And with Flash's animation, video, and audio capabilities, you could build a pretty lively UI. And, from what I hear, there are a lot of graphic artists who have learned Flash who could give us a hand.
Now, I have no links to Adobe and this only crossed my mind as they "opened" up the technology with the Open Screen project. But if this move helps them build momentum in the mobile space, it opens up a lot of opportunities for mobile software developers, and graphic artists for that matter...
So why do I care about Flash (other than my insatiable need to learn as much as I can about the software industry)? Well, it fits in with my interest in mobile devices, especially those based on embedded Linux. As these devices get more powerful and have bigger screens, the line between laptop and mobile device is going to blur. And I think the expectations of users on the UI for these devices is going to grow as well. Everyone oos and ahs over the iPhone UI. It's setting the bar.
But looking at a traditional embedded Linux box with a UI, does it make sense to run X Windows on it? X is horrible and antiquated. And it's very hard to build flashy (sorry about the pun) UIs with it. It certainly wasn't intended for resource constrained devices. Mind you the old X Terminals were pretty much embedded devices, but then where are they now...
So what are the alternatives? DirectFB looks very promising and is growing in popularity in the embedded world. It gives you an nice API over the graphics hardware and input devices that let you build your UI as low level as you need. But it does require you to build a UI from scratch.
So this is the architecture that piqued my interest: Adobe AIR (which include Flash and the WebKit browser) running on DirectFB. Which then opens up other interesting architectures. Like mobile devices turning into web appliances that let you work connected or disconnected (is there a Flash office suite app?). And with Flash's animation, video, and audio capabilities, you could build a pretty lively UI. And, from what I hear, there are a lot of graphic artists who have learned Flash who could give us a hand.
Now, I have no links to Adobe and this only crossed my mind as they "opened" up the technology with the Open Screen project. But if this move helps them build momentum in the mobile space, it opens up a lot of opportunities for mobile software developers, and graphic artists for that matter...
Happy Day in Linux-land
Thanks to everyone for their great comments on yesterday's entry on the frustrations I had getting ClearCase running on my new Linux machine. It gave me renewed hope that I could get this to work.
And I did. After reinstalling Fedora 8 as the host OS, I started getting a KVM virtual machine ready. I figured I'd try the new Virtual Machine Manager GUI to do it just like I do with VirtualBox. But when they say it's not ready for prime time, believe them. They're on the right track but to do anything serious, I think you still need to use the command line.
Another hurdle I ran into was running the 32-bit version of RHEL. I guess I should have looked harder at the KVM web page that said SMP was unstable in this configuration. It was. So jumping to the 64-bit version, I was good to go, 4 CPUs and a bridged network connection and all! I installed ClearCase and I'm in business. Now it's time to get some real work done. It was fun and I did learn a lot and gained an appreciation for virtualization, so it was well worth it.
And I did. After reinstalling Fedora 8 as the host OS, I started getting a KVM virtual machine ready. I figured I'd try the new Virtual Machine Manager GUI to do it just like I do with VirtualBox. But when they say it's not ready for prime time, believe them. They're on the right track but to do anything serious, I think you still need to use the command line.
Another hurdle I ran into was running the 32-bit version of RHEL. I guess I should have looked harder at the KVM web page that said SMP was unstable in this configuration. It was. So jumping to the 64-bit version, I was good to go, 4 CPUs and a bridged network connection and all! I installed ClearCase and I'm in business. Now it's time to get some real work done. It was fun and I did learn a lot and gained an appreciation for virtualization, so it was well worth it.
Tuesday, May 06, 2008
Frustrating Day in Linux-land
So I'm busy working with my team at Wind on some new installer work and I need to set up ClearCase to get access to the bits that go into the install. I have this spanking new machine, Quad-core Intel, 4GB RAM, 750GB drive. I really got it so I can run multiple virtual machines on it for testing. But if I could run ClearCase on it too, then I could use it for install builds too.
But my issue is that ClearCase is only supported on certain enterprise versions of Linux. But I want to try the latest KVM support in Ubuntu. So I first installed Ubuntu 64-bit and gave it a try. Ubuntu's 32-bit support in 64-bit installs is horrible. You have to manually install the 32-bit libraries. That probably should be automatic, but then they are trying to fit on a single CD so maybe it's too much. Unfortunately even with the 32-bit libraries, the perl engine ClearCase ships with crashes. So forget that.
So next up, I tried Fedora 8. It's much closer to the supported Red Hat Enterprise and might have a better chance. And besides, there are some good Eclipse guys at Red Hat and I should be supporting them. The 32-bit libraries were automatically installed (but then it is a 3+ GB DVD). So I got a lot farther. After tricking the ClearCase install scripts into accepting Fedora as a "supported" kernel, I got as far as building the MVFS kernel module.
As I tried to fix those errors, I started to feel like I was porting their module for them. And it was a lot of work. We were going from version 2.6.18 of the Linux kernel to 2.6.24, but given how many APIs changed, it felt like I was going to 3.0 or something. At any rate, it doesn't feel like something I should be investing my time in so I gave up on that.
So I tried the supported RHEL 5. You know what, after installing it and rebooting it. No network. RHEL 5 didn't have a driver for the ethernet on the new machine. For crying out loud (again...). Unfortunately, it's back to Windows for me. At least for now. Hopefully I can tweak ClearCase to make it fast enough to be usable.
But my issue is that ClearCase is only supported on certain enterprise versions of Linux. But I want to try the latest KVM support in Ubuntu. So I first installed Ubuntu 64-bit and gave it a try. Ubuntu's 32-bit support in 64-bit installs is horrible. You have to manually install the 32-bit libraries. That probably should be automatic, but then they are trying to fit on a single CD so maybe it's too much. Unfortunately even with the 32-bit libraries, the perl engine ClearCase ships with crashes. So forget that.
So next up, I tried Fedora 8. It's much closer to the supported Red Hat Enterprise and might have a better chance. And besides, there are some good Eclipse guys at Red Hat and I should be supporting them. The 32-bit libraries were automatically installed (but then it is a 3+ GB DVD). So I got a lot farther. After tricking the ClearCase install scripts into accepting Fedora as a "supported" kernel, I got as far as building the MVFS kernel module.
As I tried to fix those errors, I started to feel like I was porting their module for them. And it was a lot of work. We were going from version 2.6.18 of the Linux kernel to 2.6.24, but given how many APIs changed, it felt like I was going to 3.0 or something. At any rate, it doesn't feel like something I should be investing my time in so I gave up on that.
So I tried the supported RHEL 5. You know what, after installing it and rebooting it. No network. RHEL 5 didn't have a driver for the ethernet on the new machine. For crying out loud (again...). Unfortunately, it's back to Windows for me. At least for now. Hopefully I can tweak ClearCase to make it fast enough to be usable.
Monday, May 05, 2008
MinGW gcc 4.3 lives!
This just in, Aaron LaFramboise has just released an alpha version of gcc 4.3 for MinGW. And, of course, they are looking for testers. I know I will be. You can give it a try to by downloading it off of mingw.org. I've been following the mingw-users mailing list and it's been a great place to discuss issues. It's not too busy but it's been busy enough to be useful.
gcc 4.3 in combination with the new gdb 6.8 really brings the MinGW port for native Windows up to snuff with the gnu toolchain enjoyed by Linux developers. And I think it has a chance to give Visual C++ a run for it's money. Time will tell of course, and I am wearing my open source colored glasses. But as with the CDT for Windows development, all we're trying to be is a respected alternative and a valid path for multi-platform development.
Speaking of which, it's getting time to start working on Wascana 1.0. It'll be based on the Eclipse Ganymede with the latest tools from MinGW as well as a handful of libraries to help build platform independent apps. And it will use the Eclipse p2 provisioning framework so you can install and update the tools and libraries using the same UI you use for plug-ins. And with 7000 downloads of the last Wascana prerelease, it's worth the extra time I have to put in to make it happen.
gcc 4.3 in combination with the new gdb 6.8 really brings the MinGW port for native Windows up to snuff with the gnu toolchain enjoyed by Linux developers. And I think it has a chance to give Visual C++ a run for it's money. Time will tell of course, and I am wearing my open source colored glasses. But as with the CDT for Windows development, all we're trying to be is a respected alternative and a valid path for multi-platform development.
Speaking of which, it's getting time to start working on Wascana 1.0. It'll be based on the Eclipse Ganymede with the latest tools from MinGW as well as a handful of libraries to help build platform independent apps. And it will use the Eclipse p2 provisioning framework so you can install and update the tools and libraries using the same UI you use for plug-ins. And with 7000 downloads of the last Wascana prerelease, it's worth the extra time I have to put in to make it happen.
Friday, May 02, 2008
Open Screen, Another Game Changer?
I just went through some blogs and the Adobe Open Screen web site to try and understand what's going on. If you haven't heard, Adobe is removing licensing restrictions on it's SWF and FLV/F4V file formats that serve us Flash content and all those crazy videos on YouTube and such. In the past, the license on the specs restricted the reader from creating competing players, which has resulted in some pretty weak open source players that relied on the developers reverse engineering and guessing at what the spec is.
Opening the specs makes that no longer an issue. But the other announcement, that Adobe is going to make its player free for embedded devices as it does with desktops should really remove the need to have other players (which appears to be the true objective of this project), except for the open source bigots who must have their apps served open sauce, I guess. Bringing a free Flash player to devices is huge in my books and with their porting layer APIs made public, that should make it really easy for device developers to port the player to their devices. I think that's pretty game changing and you'll start seeing more Flash-based user interfaces on devices over time.
So it seems like pretty exciting news and it'll be interesting to see where it goes. But, I do hate the fact they're using the term "Open". This is one of my dogmas as colleagues that I've worked with in the past are painfully aware ;). "Open" is too tied to the word "source". And especially when the project is called "Open Screen" it's to easy to jump to the conclusion that they are actually open sourcing their player technology. But from what I can understand from the brief FAQ's they have on their site, I don't think they are. Which then begs the question how do you get their player running on your device. Do they have pre-compiled binaries? Which libc? Which OSes? Which compiler? At any rate it has left me confused and I'm sure others are. I wish people wouldn't use the word "Open" unless they really mean Open Source.
Opening the specs makes that no longer an issue. But the other announcement, that Adobe is going to make its player free for embedded devices as it does with desktops should really remove the need to have other players (which appears to be the true objective of this project), except for the open source bigots who must have their apps served open sauce, I guess. Bringing a free Flash player to devices is huge in my books and with their porting layer APIs made public, that should make it really easy for device developers to port the player to their devices. I think that's pretty game changing and you'll start seeing more Flash-based user interfaces on devices over time.
So it seems like pretty exciting news and it'll be interesting to see where it goes. But, I do hate the fact they're using the term "Open". This is one of my dogmas as colleagues that I've worked with in the past are painfully aware ;). "Open" is too tied to the word "source". And especially when the project is called "Open Screen" it's to easy to jump to the conclusion that they are actually open sourcing their player technology. But from what I can understand from the brief FAQ's they have on their site, I don't think they are. Which then begs the question how do you get their player running on your device. Do they have pre-compiled binaries? Which libc? Which OSes? Which compiler? At any rate it has left me confused and I'm sure others are. I wish people wouldn't use the word "Open" unless they really mean Open Source.
Monday, April 28, 2008
Building Windows apps on Linux?
I had this interesting feature request on the Wascana forum. This user would like to use Wascana on Linux to build applications that run on both Linux and Windows. You know, that's an idea that could fly.
I noticed that a number of the MinGW developers develop the MinGW tools on Linux. I think they are targeting Wine, the Windows emulation layer for Linux (and if any of them are reading, feel free to fill in the details). And I've seen a number of howto pages describing how to build the MinGW toolchain on Linux. It shouldn't be too much of a leap to build libraries such as wxWidgets in a cross development mode, although if you make too many assumptions that target == host, that won't work.
It's one of the big advantages to the GNU compiler suite, it's ability to build in a cross-compile mode. It's what makes it so popular in embedded. And it's one of the benefits of CDT, to be able to target multiple architectures from the same machine. You wouldn't have to change the CDT at all other than to avoid trying to find MinGW in the Windows registry. Now if only someone would come help make it happen...
I noticed that a number of the MinGW developers develop the MinGW tools on Linux. I think they are targeting Wine, the Windows emulation layer for Linux (and if any of them are reading, feel free to fill in the details). And I've seen a number of howto pages describing how to build the MinGW toolchain on Linux. It shouldn't be too much of a leap to build libraries such as wxWidgets in a cross development mode, although if you make too many assumptions that target == host, that won't work.
It's one of the big advantages to the GNU compiler suite, it's ability to build in a cross-compile mode. It's what makes it so popular in embedded. And it's one of the benefits of CDT, to be able to target multiple architectures from the same machine. You wouldn't have to change the CDT at all other than to avoid trying to find MinGW in the Windows registry. Now if only someone would come help make it happen...
Sunday, April 27, 2008
Help! I'm not connected...
I mentioned a couple of weeks ago that I have this idea for a visual programming language with inspiration from UML Action Semantics and the SynthMaker virtual instrument programming environment that came with my Fruity Loops thing.
So on my flight down to San Fran for the Embedded Systems Conference last week, I thought I'd take a stab at learning GMF and maybe start plugging away at the idea. I haven't used GMF recently and it looks like there's a lot more automation these days that should help me get going quickly. I downloaded the new Modeling EPP package before I left and gave it a try.
Now, I learn best by walking through examples with the help of tutorials. I fired up the Help system and opened the page for GMF tutorials and it said: "A tutorial that covers the tooling and generative components of GMF is maintained on the GMF Wiki site here." Uh, I'm on a plane. No tutorial for me. So I shut it down and did something else.
Again tonight, I go to start again and clicking the link I get: "Wiki.eclipse.org is currently down for maintenance. We apologize for the inconvenience, but expect to have the site back online shortly." For crying out loud...
So on my flight down to San Fran for the Embedded Systems Conference last week, I thought I'd take a stab at learning GMF and maybe start plugging away at the idea. I haven't used GMF recently and it looks like there's a lot more automation these days that should help me get going quickly. I downloaded the new Modeling EPP package before I left and gave it a try.
Now, I learn best by walking through examples with the help of tutorials. I fired up the Help system and opened the page for GMF tutorials and it said: "A tutorial that covers the tooling and generative components of GMF is maintained on the GMF Wiki site here." Uh, I'm on a plane. No tutorial for me. So I shut it down and did something else.
Again tonight, I go to start again and clicking the link I get: "Wiki.eclipse.org is currently down for maintenance. We apologize for the inconvenience, but expect to have the site back online shortly." For crying out loud...
Friday, April 25, 2008
C/C++ Top of the Heap, Sort of
The latest TIOBE Programming Community Index has been released. I don't put a lot of weight into surveys like this, especially if I don't know the methodology behind it. As far as I can tell it's based on the popularity of different programming languages as found on the web. I guess it's an all right measure and it co-incides somewhat with my personal observations.
At any rate, Java comes out on top with a 20% rating which is up 2% from a year ago which is healthy. I'd like to believe the popularity of Eclipse as a tools and application platform has something to do with that.
C was second at close to 15% which is down 1/4%. I still see a whole lot of C, especially in the GNU/Linux community. Almost everything there is still C. And, of course, C is still huge in embedded.
C++ was fifth at close to 10% and a drop of 3/4%. I think C++'s complexity is really hurting it. C++ is built for large scale applications. But Java and C#/VisualBasic (which are 8th and 3rd in the ranking) with their automated memory management are probably better suited for that. Which is too bad since I still believe C++ with its generic programming support is still the most powerful language in common use today.
One thing to consider is that the two languages that CDT supports add up to 25% which makes it top of the heap (see, you can craft any message you want with stats :). But it is pretty obvious that JDT has much more share of the Java market than we do with the C/C++ market. But we're trying.
One thing I did notice with this survey too is that the variety of languages being used is growing over the last five years. I wonder if that speaks to unrest we're having with the languages we have at our disposal. C++ is too complicated, Java is too simple, C doesn't scale, C# is too Microsoft, Basic is too, well, basic. I think the time is coming for something new to rejuvenate us like objects did two decades ago. I wonder what it'll be.
At any rate, Java comes out on top with a 20% rating which is up 2% from a year ago which is healthy. I'd like to believe the popularity of Eclipse as a tools and application platform has something to do with that.
C was second at close to 15% which is down 1/4%. I still see a whole lot of C, especially in the GNU/Linux community. Almost everything there is still C. And, of course, C is still huge in embedded.
C++ was fifth at close to 10% and a drop of 3/4%. I think C++'s complexity is really hurting it. C++ is built for large scale applications. But Java and C#/VisualBasic (which are 8th and 3rd in the ranking) with their automated memory management are probably better suited for that. Which is too bad since I still believe C++ with its generic programming support is still the most powerful language in common use today.
One thing to consider is that the two languages that CDT supports add up to 25% which makes it top of the heap (see, you can craft any message you want with stats :). But it is pretty obvious that JDT has much more share of the Java market than we do with the C/C++ market. But we're trying.
One thing I did notice with this survey too is that the variety of languages being used is growing over the last five years. I wonder if that speaks to unrest we're having with the languages we have at our disposal. C++ is too complicated, Java is too simple, C doesn't scale, C# is too Microsoft, Basic is too, well, basic. I think the time is coming for something new to rejuvenate us like objects did two decades ago. I wonder what it'll be.
Friday, April 18, 2008
Eclipse for Embedded in San Jose
I'm back in the valley and gave a talk on Eclipse for Embedded at the Embedded Systems Conference. Unfortunately it was at 8:30 in the morning today (Friday) when the exhibition, where all the fun happens, is all over. But I had around 40 people there which was good to see. I also did a shop talk session yesterday at 7:15 which had close to the same number. It was good to see that they made the effort to be there, and it was good to see that almost all of them use the CDT in their daily work.
I did a walk of the show floor on Wednesday to check out the Eclipse displays. They're still pretty hard to find at least displayed prominently. But all the regulars that I know about at least had Eclipse up on their monitors. I also ran into a new one, ThreadX which has just released a CDT based product. It really does leave Green Hills as the last hold out in the RTOS/embedded tooling community.
The other cool thing that came up is the need for p2 to be a general installer technology. I'm looking at it for Wind River product and I ran into a couple of other vendors who want to do the same. That really confirms that we should be able to build momentum to make this happen. As someone said today on the equinox-dev list, we've always needed an installer for Eclipse. And we've always needed that installer to install everything in our development environment and p2 has that capability.
I wasn't sure I was going to come back next year, but given the number of people I talked to I'm glad I came this year. And given the interest in Eclipse in the embedded developer community, I know they need more classes at this conference to help get them going. We've always struggled to get an Eclipse presence here and it was good to see confirmation that we need to be here.
I did a walk of the show floor on Wednesday to check out the Eclipse displays. They're still pretty hard to find at least displayed prominently. But all the regulars that I know about at least had Eclipse up on their monitors. I also ran into a new one, ThreadX which has just released a CDT based product. It really does leave Green Hills as the last hold out in the RTOS/embedded tooling community.
The other cool thing that came up is the need for p2 to be a general installer technology. I'm looking at it for Wind River product and I ran into a couple of other vendors who want to do the same. That really confirms that we should be able to build momentum to make this happen. As someone said today on the equinox-dev list, we've always needed an installer for Eclipse. And we've always needed that installer to install everything in our development environment and p2 has that capability.
I wasn't sure I was going to come back next year, but given the number of people I talked to I'm glad I came this year. And given the interest in Eclipse in the embedded developer community, I know they need more classes at this conference to help get them going. We've always struggled to get an Eclipse presence here and it was good to see confirmation that we need to be here.
Friday, April 11, 2008
I love the open source spirit
I came across the web site for the GCC and GNU toolchain developers summit. It's being held here in Ottawa and I am wondering if it might be a good idea to go and get more involved with this community. I do fit into the "enthusiast" category with my work on Wascana and my interest in MinGW. We'll see. I also don't want to take up space that someone more of an enthusiast would like to take.
At any rate, I came accross this in the FAQ for the event.
Q. What is the legal drinking age in Canada?
A. In Ontario (the provice that Ottawa is in) the legal drinking age is 19. In Quebec (located across the bridge) the legal drinking age is 18.
Well, if that question is frequently asked, either there are a lot of young people coming to this (which is probably true), or it's going to be a great party. It's probably both.
In some ways, the Eclipse culture is quite different than the GNU culture. I think it comes to the fact that Eclipse is much more commercial. But in other ways it's very similar. When you get together at a community event, outside of our suits, the atmosphere is so energetic and positive, you can't help but have a good time.
At any rate, I came accross this in the FAQ for the event.
Q. What is the legal drinking age in Canada?
A. In Ontario (the provice that Ottawa is in) the legal drinking age is 19. In Quebec (located across the bridge) the legal drinking age is 18.
Well, if that question is frequently asked, either there are a lot of young people coming to this (which is probably true), or it's going to be a great party. It's probably both.
In some ways, the Eclipse culture is quite different than the GNU culture. I think it comes to the fact that Eclipse is much more commercial. But in other ways it's very similar. When you get together at a community event, outside of our suits, the atmosphere is so energetic and positive, you can't help but have a good time.
Friday, April 04, 2008
MinGW entering it's prime?
I have a monitor on files that get released by the MinGW project and I just got a notice that the alpha release of gcc 4.3 for MinGW has just arrived. This follows quite closely behind a tech preview of gdb 6.8 for MinGW which includes a number of improvements to gdb for native Windows development.
I had almost given up hope that proper GNU toolchain support for native Windows development would arrive, but these recent events and the good work by the contributors of these works has reinvigorated my excitement.
Of course, these new packages will feed into the 1.0 release of Wascana Desktop Developer this summer. I am also working on a p2 based installer for Wascana to help keep users up to date with new releases of the toolchain and libraries. This all gives me hope again that Wascana will become a serious player with the Windows desktop developers. Which will also give our efforts at building a grassroots movement behind the CDT a healthy boost.
I had almost given up hope that proper GNU toolchain support for native Windows development would arrive, but these recent events and the good work by the contributors of these works has reinvigorated my excitement.
Of course, these new packages will feed into the 1.0 release of Wascana Desktop Developer this summer. I am also working on a p2 based installer for Wascana to help keep users up to date with new releases of the toolchain and libraries. This all gives me hope again that Wascana will become a serious player with the Windows desktop developers. Which will also give our efforts at building a grassroots movement behind the CDT a healthy boost.
Sunday, March 30, 2008
Unexpected surprise in my Fruity Loops
As I mentioned previously here, I am starting to get into making my own electronic music. I've played guitar for many years as a hobby (and I'm nowhere near as good as Steve Northover) but wanted something that I could play with on the road (yes, I was creating music on my flight down and back to EclipseCon). That and it gave me a way to mix hobby and work since I could build software synthesizers using the CDT and Wascana.
I purchased a copy of FL Studio, which has been previously known as Fruity Loops when I first heard about it a few years ago. It's a goofy name you'd associate with a kids product, but it's now a full fledged digital audio workstation and deserves a grown up name. They just came out with a new version and one of the hidden gems is the inclusion of a product called SynthMaker that lets you build your own software synths using a visual programming environment.
O.K. creating your own synths without having to write C++ code. I guess not all musicians know C++ so I get it. And creating them visually is an interesting approach that newbies should be able to figure out.
But what struck me as I started digging into the sample synths it ships with (which sound awesome BTW) was exactly how powerful a programming environment this is. You create modules which have built in algorithms for everything from audio processing to IO handling to the rendering of the graphics for the synth UI. And then you hook them all up using interface ports and data flow lines.
OMG (the pun is unintended but now that I look at it, it's pretty funny), this is UML Action Semantics in action! Ever since I was involved in the review process for action semantics (including a very awkward call with Jim Rumbaugh - man, was I intimidated by the legend!), I had a vision of a visual programming language based on the concepts. You essentially declare objects and actions that you perform on those objects and link the actions together with data flows and control flows. And now that multi-core computing is becoming all the rage, I figure it's even more important. I think it's the only way programmers will be able to grasp multi-threaded programming, by forcing the code to flow in multiple dimensions instead of the single dimension text streams we have today.
So while I'm taken aback that I found this vision manifested in such a niche product, it helps me realize that this vision could be practical. I can't wait to start diving into it further and getting real experience at programming this way. If it works well, then I can really see the need to manifest this as a general language. And wouldn't this look great written using the Eclipse Modeling projects.
I purchased a copy of FL Studio, which has been previously known as Fruity Loops when I first heard about it a few years ago. It's a goofy name you'd associate with a kids product, but it's now a full fledged digital audio workstation and deserves a grown up name. They just came out with a new version and one of the hidden gems is the inclusion of a product called SynthMaker that lets you build your own software synths using a visual programming environment.
O.K. creating your own synths without having to write C++ code. I guess not all musicians know C++ so I get it. And creating them visually is an interesting approach that newbies should be able to figure out.
But what struck me as I started digging into the sample synths it ships with (which sound awesome BTW) was exactly how powerful a programming environment this is. You create modules which have built in algorithms for everything from audio processing to IO handling to the rendering of the graphics for the synth UI. And then you hook them all up using interface ports and data flow lines.
OMG (the pun is unintended but now that I look at it, it's pretty funny), this is UML Action Semantics in action! Ever since I was involved in the review process for action semantics (including a very awkward call with Jim Rumbaugh - man, was I intimidated by the legend!), I had a vision of a visual programming language based on the concepts. You essentially declare objects and actions that you perform on those objects and link the actions together with data flows and control flows. And now that multi-core computing is becoming all the rage, I figure it's even more important. I think it's the only way programmers will be able to grasp multi-threaded programming, by forcing the code to flow in multiple dimensions instead of the single dimension text streams we have today.
So while I'm taken aback that I found this vision manifested in such a niche product, it helps me realize that this vision could be practical. I can't wait to start diving into it further and getting real experience at programming this way. If it works well, then I can really see the need to manifest this as a general language. And wouldn't this look great written using the Eclipse Modeling projects.
Friday, March 28, 2008
Eclipse p2, sweet!
As we hinted at EclipseCon last week, my team has been evaluating p2 as the framework for our new installer technology. We're essentially coming from an InstallShield world where we have these big monolithic setup.exe type things and we are looking to make our installs more flexible and open the door to electronic distribution. It's an exciting vision and we're pumped to be working to make it happen.
I've talked to the p2 team off an on over the last while trying to get a sense of what they were doing. But it really took Pascal's p2 long talk for it to really hit me. p2 is the new Update Manager (duh, that's what they've been saying all along). But as I look under the hood, it's an Update Manager on steroids (good thing there's no drug testing of software). And it's really got us excited.
The beauty of it is the extensibility. The underlying concepts are sound and based on some pretty standard notions albeit with weird names. InstallableUnits and Artifacts, what's the difference? Once you get past that you're fine. But the fact that you can override how things are installed with Touchpoints, and the fact that you can override how the Repositories are stored opens the door to some really exciting opportunities.
Aside from my internal work, I am looking to make a p2 based installer for Wascana. Yes, it can be used to install the Eclipse bits for the Platform, CDT and other plug-ins I need. But it should also be possible to use it to install the toolchain and libraries as well. What also struck me is that I should also be able to install the bits directly from their own download sites. This will allow me to quickly make available new releases of the components. The flexibility will still allow me to create off-line installs as well.
Another thing that popped into my head was whether p2 could be adapted to install Linux packages. Every distribution pretty much has it's own package manager. It would be very interesting if we could get p2 to install RPMs for example allowing us to use the same UI to set up Eclipse as well as packages, or even allow us to set up dependencies between them. Then we could create a Linux toolchain integration plug-in that depends on the compilers and have the p2 installer install the whole thing.
So as you can see I have big dreams for p2, probably more than the p2 team can handle at the moment. But it's an area that I really want to get involved in and contribute. And we'll see where we end up.
I've talked to the p2 team off an on over the last while trying to get a sense of what they were doing. But it really took Pascal's p2 long talk for it to really hit me. p2 is the new Update Manager (duh, that's what they've been saying all along). But as I look under the hood, it's an Update Manager on steroids (good thing there's no drug testing of software). And it's really got us excited.
The beauty of it is the extensibility. The underlying concepts are sound and based on some pretty standard notions albeit with weird names. InstallableUnits and Artifacts, what's the difference? Once you get past that you're fine. But the fact that you can override how things are installed with Touchpoints, and the fact that you can override how the Repositories are stored opens the door to some really exciting opportunities.
Aside from my internal work, I am looking to make a p2 based installer for Wascana. Yes, it can be used to install the Eclipse bits for the Platform, CDT and other plug-ins I need. But it should also be possible to use it to install the toolchain and libraries as well. What also struck me is that I should also be able to install the bits directly from their own download sites. This will allow me to quickly make available new releases of the components. The flexibility will still allow me to create off-line installs as well.
Another thing that popped into my head was whether p2 could be adapted to install Linux packages. Every distribution pretty much has it's own package manager. It would be very interesting if we could get p2 to install RPMs for example allowing us to use the same UI to set up Eclipse as well as packages, or even allow us to set up dependencies between them. Then we could create a Linux toolchain integration plug-in that depends on the compilers and have the p2 installer install the whole thing.
So as you can see I have big dreams for p2, probably more than the p2 team can handle at the moment. But it's an area that I really want to get involved in and contribute. And we'll see where we end up.
Monday, March 24, 2008
The community gets it
I just read Mike Milinkovich's post and it summarizes really well what Eclipse is all about. I'm going to use it as a reference whenever someone asks. And I'm going to add Cory Doctorow's quote to my list of mantras. "Ideas are cheap. Execution is hard". How true is that!
I often hear people wonder why the Eclipse Foundation staff doesn't step in and "fix" all of our conflicts. Well, that's not their job. That's not what Eclipse is all about. The Foundation is there to provide an environment that (hopefully) enables communities to succeed. They are facilitators. No, if there are conflicts happening it really is up to the community itself to do the heavy lifting to resolve those conflicts. And if there are projects that are dying, or suffering from a lack of diversity, it is up to the community to step in and fix it.
And the great news is that I really saw last week at EcilpseCon in the many discussions I had with members of the community, they get it. One guy asked me and I have no idea who he was, "so is AGR really dead"? I said, "yeah, as far as I know". Then he said back, "even if I try to contribute to it?" Wow. He gets it.
I passed Mike in the bar and he was talking to some of the guys and he was noticing that there were many more conversations happening in the hallways than in previous years. I have first hand experience at that. And I really think it's because the community is coming to EclipseCon to work. In previous years, many were coming just to see what was going on, maybe see what fancy new projects people were working on that they could use. I'm not saying that they are now coming to see how they can contribute. But they are realizing that if there's something that needs done, they have the power to step in and help make it happen. And that's an exciting trend.
The area that still has me concerned though is with the Eclipse Platform and the new e4 initiative. And, maybe a surprise to some, my problem isn't with the Platform committers. They worked very hard last week to make me feel at home and to push me to contribute to the platform, especially with the flexible resource model that we have been working to resolve in the CDT. And for that I am truly grateful.
No, my problem was with some of the questions and "ideas" that came up from the audience at the e4 BOF. We have been blessed with the Platform team's great work at providing us with a technology base that has enabled this rich community to grow. So much so that we've grown accustomed to receiving gifts of new features and fixes on a regular basis. That's got to stop. The feeling that I brought home with me is exactly what I had hoped. The Eclipse project is the same as any other project and needs to be treated as so. "Ideas are cheap. Execution is hard." If we as a community need things from the platform, it is up to us to do the heavy lifting to make change happen. We do have the power if we do the hard work necessary to make it happen.
I often hear people wonder why the Eclipse Foundation staff doesn't step in and "fix" all of our conflicts. Well, that's not their job. That's not what Eclipse is all about. The Foundation is there to provide an environment that (hopefully) enables communities to succeed. They are facilitators. No, if there are conflicts happening it really is up to the community itself to do the heavy lifting to resolve those conflicts. And if there are projects that are dying, or suffering from a lack of diversity, it is up to the community to step in and fix it.
And the great news is that I really saw last week at EcilpseCon in the many discussions I had with members of the community, they get it. One guy asked me and I have no idea who he was, "so is AGR really dead"? I said, "yeah, as far as I know". Then he said back, "even if I try to contribute to it?" Wow. He gets it.
I passed Mike in the bar and he was talking to some of the guys and he was noticing that there were many more conversations happening in the hallways than in previous years. I have first hand experience at that. And I really think it's because the community is coming to EclipseCon to work. In previous years, many were coming just to see what was going on, maybe see what fancy new projects people were working on that they could use. I'm not saying that they are now coming to see how they can contribute. But they are realizing that if there's something that needs done, they have the power to step in and help make it happen. And that's an exciting trend.
The area that still has me concerned though is with the Eclipse Platform and the new e4 initiative. And, maybe a surprise to some, my problem isn't with the Platform committers. They worked very hard last week to make me feel at home and to push me to contribute to the platform, especially with the flexible resource model that we have been working to resolve in the CDT. And for that I am truly grateful.
No, my problem was with some of the questions and "ideas" that came up from the audience at the e4 BOF. We have been blessed with the Platform team's great work at providing us with a technology base that has enabled this rich community to grow. So much so that we've grown accustomed to receiving gifts of new features and fixes on a regular basis. That's got to stop. The feeling that I brought home with me is exactly what I had hoped. The Eclipse project is the same as any other project and needs to be treated as so. "Ideas are cheap. Execution is hard." If we as a community need things from the platform, it is up to us to do the heavy lifting to make change happen. We do have the power if we do the hard work necessary to make it happen.
Friday, March 21, 2008
Another EclipseCon in the Books
Well, it's finally over. EclipseCon that is. But I think it also marks a beginning for me. I was able to meet so many people and accomplish so much this week, it was definitely the best EclipseCon for me.
I'm just going to drop a quick note here since I really need to get to sleep to catch the 7 a.m. flight out of SFO to Toronto on my way home to Ottawa. It's my wife's birthday and I need to get home in time for at least part of it.
So here are a few quick notes on my experiences here:
* e4 isn't so scary. What's scary is that I appear to have volunteered to drive the flexible resource model in the platform. It's a huge responsibility but it needs to get done and I look forward to keeping the momentum going to make sure we get the right solution in place for everyone who uses platform resources (which is quite a few people I hear!). And a big thank you to McQ and Szymon from the Platform Core team for helping us get this going.
* Embedded at EclipseCon is alive and well. I first ran into this at Eclipse Summit Europe where I met a lot of CDT adopters from the embedded space. I thought it was just a European phenomena. Apparently not. I met even more this week here. This is another thing we need to keep the momentum going.
* We need a grassroots embedded development IDE just like we have with Wascana. From the DSDP BOF there appears to be interest in this. And you can count me in with helping it out. And even more reason to figure out how to ship GPL code from eclipse.org since so much of the common embedded tool chain is GPL.
* Speaking of Wascana, the Microsoft announcement was very underwhelming. I need help interfacing the CDT to the Windows debug APIs. Microsoft, come help me!
* Not only did I learn about it, I learned how to spell Mylyn (sorry again Mik!)
* p2 is the future. Well, it's actually the present and it's great to see it coming together quickly. Given my new role at Wind River, expect to see Wind River participating and contributing.
* I'm getting old. I was in bed before midnight both Monday and Tuesday. Wednesday not so much, but I did feel good when I did. Having said that, I did consume a lot of beer this week, all in the name of community building :)
Well, I'll have more to say later.
I'm just going to drop a quick note here since I really need to get to sleep to catch the 7 a.m. flight out of SFO to Toronto on my way home to Ottawa. It's my wife's birthday and I need to get home in time for at least part of it.
So here are a few quick notes on my experiences here:
* e4 isn't so scary. What's scary is that I appear to have volunteered to drive the flexible resource model in the platform. It's a huge responsibility but it needs to get done and I look forward to keeping the momentum going to make sure we get the right solution in place for everyone who uses platform resources (which is quite a few people I hear!). And a big thank you to McQ and Szymon from the Platform Core team for helping us get this going.
* Embedded at EclipseCon is alive and well. I first ran into this at Eclipse Summit Europe where I met a lot of CDT adopters from the embedded space. I thought it was just a European phenomena. Apparently not. I met even more this week here. This is another thing we need to keep the momentum going.
* We need a grassroots embedded development IDE just like we have with Wascana. From the DSDP BOF there appears to be interest in this. And you can count me in with helping it out. And even more reason to figure out how to ship GPL code from eclipse.org since so much of the common embedded tool chain is GPL.
* Speaking of Wascana, the Microsoft announcement was very underwhelming. I need help interfacing the CDT to the Windows debug APIs. Microsoft, come help me!
* Not only did I learn about it, I learned how to spell Mylyn (sorry again Mik!)
* p2 is the future. Well, it's actually the present and it's great to see it coming together quickly. Given my new role at Wind River, expect to see Wind River participating and contributing.
* I'm getting old. I was in bed before midnight both Monday and Tuesday. Wednesday not so much, but I did feel good when I did. Having said that, I did consume a lot of beer this week, all in the name of community building :)
Well, I'll have more to say later.
Tuesday, March 18, 2008
Mylin & CDT destiny
It's an interesting phenomena at Eclipse how bug reports get to be famous. It's how issues are raised, where discussions on solutions take place, and patches get attached. There are famous bugs in Eclipse that I've heard about and finally, I think we've got one on the go for the CDT. It's bug 162558, the Mylin bridge to the CDT.
I've heard great things about Mylin for a long time. An old colleague of mine raved about it. I tried it and it has a great Eclipse interface to a number of different bug systems. But today, I learned from Mik's talk about the task management features that Mylin provides and how it cleans up the UI to help you focus on what you are working on. It's a different way of working, but I can see that once you adopt it, it'll give developers a huge boost in productivity especially when they are working on multiple things at a time.
We've had bug 162558 around for a long time which asks for CDT support in Mylin's task management system. I think there was concern that it would be a lot of work and CDT developers have always had other things to work on. But Mik promised on the report that it would only take 2-4 weeks. And now we have Jeff Johnston from Red Hat who has signed up to help and has a new plug-in ready to show.
I really think that this is a hugely important development for the CDT. In the C/C++ world, our biggest competitor is still emacs/vi and make, i.e., the command line. It's too easy for new CDT users to get frustrated and throw it away and go back. Much more so than Java developers, for example. Ever write java code with command line tools? It's a lot easier with C/C++ where the tools have been optimized to work well on the command line.
We really need to show the value that will pull users through the learning pains of adopting Eclipse (mind you we need to address those too) and tools such as Mylin can do that. You won't find a command line version of Mylin. So we'll work hard to get the CDT Mylin bridge into CDT 5.0 for Ganymede. It'll be a fun thing to add to my CDT demos and hopefully can convince more people to use the CDT.
I've heard great things about Mylin for a long time. An old colleague of mine raved about it. I tried it and it has a great Eclipse interface to a number of different bug systems. But today, I learned from Mik's talk about the task management features that Mylin provides and how it cleans up the UI to help you focus on what you are working on. It's a different way of working, but I can see that once you adopt it, it'll give developers a huge boost in productivity especially when they are working on multiple things at a time.
We've had bug 162558 around for a long time which asks for CDT support in Mylin's task management system. I think there was concern that it would be a lot of work and CDT developers have always had other things to work on. But Mik promised on the report that it would only take 2-4 weeks. And now we have Jeff Johnston from Red Hat who has signed up to help and has a new plug-in ready to show.
I really think that this is a hugely important development for the CDT. In the C/C++ world, our biggest competitor is still emacs/vi and make, i.e., the command line. It's too easy for new CDT users to get frustrated and throw it away and go back. Much more so than Java developers, for example. Ever write java code with command line tools? It's a lot easier with C/C++ where the tools have been optimized to work well on the command line.
We really need to show the value that will pull users through the learning pains of adopting Eclipse (mind you we need to address those too) and tools such as Mylin can do that. You won't find a command line version of Mylin. So we'll work hard to get the CDT Mylin bridge into CDT 5.0 for Ganymede. It'll be a fun thing to add to my CDT demos and hopefully can convince more people to use the CDT.
Subscribe to:
Posts (Atom)