I'm having a hard time getting into writing my paper for the upcoming Embedded Systems Conference. So I figured I'd spend some time writing here where I seem to never have writer's block, at least once I find a topic to talk about and a second to do it.
But it's a sign of the time of year. EclipseCon is just over two weeks away and then this year the Embedded Systems Conference and the Eclipse PluginFest for Mobile/Embedded are happening in the same week in April. Time to get prepared.
The PluginFest is a special event that we started last year. It was a pretty interesting time. Part of it was the thrill of spending some time in London, England (which I hear is nicer than London, Ontario, Canada but I've never been to the latter :). But I think it was mainly the chance to get together with Eclipse people again. We have a great community that have some really interesting and passionate individuals that make these events a must attend.
The PluginFest is a bit different than your average Eclipse event, in that you are encouraged to talk about your commercial product and work with other commercial vendors as we prove that the concept of plug-in truly does enable the interoperability between these products that we promise.
And a key component of the interoperability story is the Eclipse platform projects that everyone works to extend. These projects, which include the CDT and DSDP projects, become a bit of a focus as well. I talked to a number of people last year who had questions and ideas for me and the CDT. And I hear there's a keen interested in having project members present again this year.
But that left me a little concerned. EclipseCon is actually a month earlier than the PluginFest this year. And in many ways EclipseCon is meant to be the venue for people working on projects to gather and discuss and ask. For some reason, though, we've always had trouble getting a strong program and attendance from the embedded community for EclipseCon.
It really shows that there is still a lot of work to be done to boost that community. Which is odd, since they are a community that I think desperately needs Eclipse technology to work for them. But then maybe that's one reason why. It doesn't necessarily work for them.
Thursday, February 28, 2008
Monday, February 25, 2008
Eclipse Board Election Under Way
It's been a quiet campaign, I guess, at least relative to other elections that are going on right now. Thanks to Ed Merks who we can always expect to stir up the pot :) We did end up have a really healthy debate over the way the Committer reps are elected. One thing we're not short of at Eclipse is passionate contributors and that's good for everyone concerned.
I encourage all the committers to take the time to vote. It's a pretty complicated ballot and voting scheme and the choices are pretty hard to make since all the candidates are worthy or representing you. I think the next couple of years are going to be critical for Eclipse as contributing vendors shift their investment. We need to make sure the board does what it can to help ensure the continued success of the projects and of the vendors that contribute to and adopt the works of those projects. So make sure you vote for the person who you think can best represent you're needs.
I have no idea how I'm going to fare since my campaign budget didn't allow for any polling ;), but I'm glad I had the opportunity to share my vision for Eclipse and will continue to work with whoever gets elected to help turn that vision into a reality. I'm not sure we'll get CNN to cover the results, but it'll be fun to see how it all unfolds.
I encourage all the committers to take the time to vote. It's a pretty complicated ballot and voting scheme and the choices are pretty hard to make since all the candidates are worthy or representing you. I think the next couple of years are going to be critical for Eclipse as contributing vendors shift their investment. We need to make sure the board does what it can to help ensure the continued success of the projects and of the vendors that contribute to and adopt the works of those projects. So make sure you vote for the person who you think can best represent you're needs.
I have no idea how I'm going to fare since my campaign budget didn't allow for any polling ;), but I'm glad I had the opportunity to share my vision for Eclipse and will continue to work with whoever gets elected to help turn that vision into a reality. I'm not sure we'll get CNN to cover the results, but it'll be fun to see how it all unfolds.
Thursday, February 21, 2008
A Voting Scheme That Promotes Diversity
I was going to leave a comment on Ed Merks blog entry on "One Committer, One Vote?", but I found I filled up the space. That probably means I should do it in my own blog.
For those who haven't read Ed's blog, he reminds us of the Eclipse voting rule that all committers voting in the board elections get their votes lumped together with others working for the same organization. One organization, one vote. And yeah, if you work at IBM like I did when I learned about this, it leaves you feeling pretty insignificant in these things since you only get such a small fraction of one vote.
But I like this rule. I think it does a great job at promoting diversity. When the Eclipse Foundation was started the board went through a huge effort of making sure that Eclipse was seen as independent from its creator, IBM. To do that, they really needed, and still do need, to ensure as many organizations have a voice on the board as feasible. And this rule helps that by giving people outside IBM more of a chance of winning a board seat.
Now, it doesn't shut out people working for large organizations. The other good thing it does is encourage committers working for those organizations to reach out to the greater Eclipse community and not stay hidden behind the corporate walls. And I look at the IBMers running for the board this year and I can say they do just that. So even with this rule, I'm not sure I have much more of a chance of winning than they do. And that's good for Eclipse all round.
For those who haven't read Ed's blog, he reminds us of the Eclipse voting rule that all committers voting in the board elections get their votes lumped together with others working for the same organization. One organization, one vote. And yeah, if you work at IBM like I did when I learned about this, it leaves you feeling pretty insignificant in these things since you only get such a small fraction of one vote.
But I like this rule. I think it does a great job at promoting diversity. When the Eclipse Foundation was started the board went through a huge effort of making sure that Eclipse was seen as independent from its creator, IBM. To do that, they really needed, and still do need, to ensure as many organizations have a voice on the board as feasible. And this rule helps that by giving people outside IBM more of a chance of winning a board seat.
Now, it doesn't shut out people working for large organizations. The other good thing it does is encourage committers working for those organizations to reach out to the greater Eclipse community and not stay hidden behind the corporate walls. And I look at the IBMers running for the board this year and I can say they do just that. So even with this rule, I'm not sure I have much more of a chance of winning than they do. And that's good for Eclipse all round.
Code like you won't be there tomorrow
One of the things that we deal with on most software projects that continue on for a few years is turnover. People come and go. I'm not sure it's more prevalent with the software industry than others, but it is painful. As managers we spend a lot of effort making sure transition plans are put in place when it happens so that the asset that is the developer's knowledge isn't lost.
Unfortunately, we haven't done a good job of that with the CDT. We have a number of instances now where developers work hard and put in a great complex framework to solve a really complicated problem. We really appreciate the contributions to make the CDT better.
But stuff happens. The developer gets put on other projects or leaves the company that was paying him to work on the CDT, and poof, the detailed knowledge of what they were working on is gone. But since we don't really have a manager/employee relationship with them, it doesn't really cross our mind that we need to manage the transition and make sure we capture that knowledge. And maybe we should.
The other side of the coin, though, is that developers love what they do and want to do it forever, especially on exciting projects like the CDT that are doing good for the world (or something). I'm not sure they consider the possibility that they may get pulled off the project and they don't spend the time to properly document what they are doing so others can pick up the pieces. Or worse, they try to be very clever in their solution making it more complicated than maybe it could be, and certainly difficult for downstream maintainers to understand.
The concern I often hear from them is that, since it's open source, their employers don't give them enough time to do everything you would on a commercial project. And we were also going through a phase where we needed contributions badly and didn't consider it prudent to enforce that documentation be provided. But we're definitely paying for it now as we have a pretty big bulk of undocumented code that we're trying to fix bugs in.
So the lesson of the day is to code like you won't be there tomorrow. You can create the best system ever, and people will appreciate it while you're there, but they may end up cursing you if you disappear and leave it in their laps. At the very least, they'll be wishing you could come back.
Unfortunately, we haven't done a good job of that with the CDT. We have a number of instances now where developers work hard and put in a great complex framework to solve a really complicated problem. We really appreciate the contributions to make the CDT better.
But stuff happens. The developer gets put on other projects or leaves the company that was paying him to work on the CDT, and poof, the detailed knowledge of what they were working on is gone. But since we don't really have a manager/employee relationship with them, it doesn't really cross our mind that we need to manage the transition and make sure we capture that knowledge. And maybe we should.
The other side of the coin, though, is that developers love what they do and want to do it forever, especially on exciting projects like the CDT that are doing good for the world (or something). I'm not sure they consider the possibility that they may get pulled off the project and they don't spend the time to properly document what they are doing so others can pick up the pieces. Or worse, they try to be very clever in their solution making it more complicated than maybe it could be, and certainly difficult for downstream maintainers to understand.
The concern I often hear from them is that, since it's open source, their employers don't give them enough time to do everything you would on a commercial project. And we were also going through a phase where we needed contributions badly and didn't consider it prudent to enforce that documentation be provided. But we're definitely paying for it now as we have a pretty big bulk of undocumented code that we're trying to fix bugs in.
So the lesson of the day is to code like you won't be there tomorrow. You can create the best system ever, and people will appreciate it while you're there, but they may end up cursing you if you disappear and leave it in their laps. At the very least, they'll be wishing you could come back.
Monday, February 18, 2008
Sun Buys My VirtualBox
One of the issues I have to deal with when building Eclipse-based software is the need to test on a number of different platforms. Yeah, "Write Once, Run Everywhere", whatever. To build a proper IDE and especially the new Installer stuff I'm working on, you need to access the native platform. There's no getting away from it. And with that, you need to deal with all the "special" behaviors that these platforms offer you.
And when you're dealing with many platforms, it's gets pretty expensive and noisy and hot to have all that hardware stacked in your office, so it makes a ton of sense to use software virtualization for test environments. I've mainly used vmware over the years but before going through the hassle of purchasing a new copy for my new job, I thought I'd try alternatives.
One I found that worked pretty good was VirtualBox built by German company innotek. It's got a weird license. It's "Free for personal use". It has an open source aspect to it but it's a subset of the whole thing that's free for personal use so it's pretty confusing. But it performs really well, leveraging the virtualization hardware in new Intel and AMD CPUs. And has guest drivers that make the integration with the host work better too, just like vmware.
So today, I went to their web site to see if there was an update to the software and I found a link to this announcement: New Feb 12, 2008 - innotek to be acquired by Sun Microsystems. What?!? I thought this was just a small outfit that was building a nice VM for fun with hopes of making it big one day. Well, I guess they made it big. Congrats to them!
I'm not sure how to interpret Sun's motives or what will happen to VirtualBox once it's in their hands. But just like MySQL, I hope they keep the open/free aspects of it alive and well and invest in it to make it even better.
And when you're dealing with many platforms, it's gets pretty expensive and noisy and hot to have all that hardware stacked in your office, so it makes a ton of sense to use software virtualization for test environments. I've mainly used vmware over the years but before going through the hassle of purchasing a new copy for my new job, I thought I'd try alternatives.
One I found that worked pretty good was VirtualBox built by German company innotek. It's got a weird license. It's "Free for personal use". It has an open source aspect to it but it's a subset of the whole thing that's free for personal use so it's pretty confusing. But it performs really well, leveraging the virtualization hardware in new Intel and AMD CPUs. And has guest drivers that make the integration with the host work better too, just like vmware.
So today, I went to their web site to see if there was an update to the software and I found a link to this announcement: New Feb 12, 2008 - innotek to be acquired by Sun Microsystems. What?!? I thought this was just a small outfit that was building a nice VM for fun with hopes of making it big one day. Well, I guess they made it big. Congrats to them!
I'm not sure how to interpret Sun's motives or what will happen to VirtualBox once it's in their hands. But just like MySQL, I hope they keep the open/free aspects of it alive and well and invest in it to make it even better.
Monday, February 11, 2008
MinGW gcc 4.3 - not quite dead yet?
As I march into the exciting world of Virtual Instruments and VST and using the CDT build something I think is really cool, I keep running into the question: what toolchain should I be using for Windows development. Without a debugger, what's the point of using the Visual C++ compiler. My gut tells me that it's probably got a better optimizer than the old 3.4 that MinGW has at the moment, and that will be key to building a high performance plug-in for digital audio workstations.
At the end of a recent blog entry I whined about the lack of progress with MinGW. On reflection, I really need to stick with my guns. As a lead for an open source project you know the first thing I would do with someone complaining something like that is to ask them where their contribution was. So I turned it around. How can I help MinGW move up to the latest gcc and gdb and get it all working nicely?
I kept hearing that the gcc had listed mingw as a secondary platform for the upcoming gcc 4.3, yet in the changelog and gcc mailing list, I haven't really seen much progress. But maybe I'm just looking in the wrong places. So I set out to see if I can build it and run some tests. Building gcc is not for the meek and requires the exact right build environment. I was actually able to build it with a simple configure and got a C++ hello world to work. Very cool, and a great sign that someone out there in gcc-land is taking mingw seriously.
So searching around for instructions on how to build the gcc libraries (libgcc and libstdc++) as DLLs, I ran across the mingw-users mailing list (duh, why hadn't I singed up for that list before?). It appears that there is progress being made in this area. I was kindly provided with build instructions from the former gcc guru on mingw who appears to be taking a closer look again. So I'm going to try to reproduce the build and help him out. If we can get another couple of guys doing the same thing and providing patches where things are broken, we should be able to get this into release shape.
In my mind that would be huge. With gcc 4.3 with it's strong optimizer along with other goodies like OpenMP, we'll have a great compiler for Windows development and for Wascana. And then I can focus on gdb, which also appears to be making progress at mingw. Things might not be as stark as I had made things out to be, especially if I put some effort in helping out.
At the end of a recent blog entry I whined about the lack of progress with MinGW. On reflection, I really need to stick with my guns. As a lead for an open source project you know the first thing I would do with someone complaining something like that is to ask them where their contribution was. So I turned it around. How can I help MinGW move up to the latest gcc and gdb and get it all working nicely?
I kept hearing that the gcc had listed mingw as a secondary platform for the upcoming gcc 4.3, yet in the changelog and gcc mailing list, I haven't really seen much progress. But maybe I'm just looking in the wrong places. So I set out to see if I can build it and run some tests. Building gcc is not for the meek and requires the exact right build environment. I was actually able to build it with a simple configure and got a C++ hello world to work. Very cool, and a great sign that someone out there in gcc-land is taking mingw seriously.
So searching around for instructions on how to build the gcc libraries (libgcc and libstdc++) as DLLs, I ran across the mingw-users mailing list (duh, why hadn't I singed up for that list before?). It appears that there is progress being made in this area. I was kindly provided with build instructions from the former gcc guru on mingw who appears to be taking a closer look again. So I'm going to try to reproduce the build and help him out. If we can get another couple of guys doing the same thing and providing patches where things are broken, we should be able to get this into release shape.
In my mind that would be huge. With gcc 4.3 with it's strong optimizer along with other goodies like OpenMP, we'll have a great compiler for Windows development and for Wascana. And then I can focus on gdb, which also appears to be making progress at mingw. Things might not be as stark as I had made things out to be, especially if I put some effort in helping out.
Friday, February 08, 2008
You're Running for What?
I guess if you look through the history of this blog, I've complained the odd time about how frustrating it can be to work in the Eclipse environment. Now don't get me wrong, the frustration is incredibly minor compared to they success I've had in helping create a successful C/C++ IDE in the CDT. We've been able to put together a solution that has been very well received by the community and is having good commercial success as well. It's all good, well at least for the most part.
But there are things that I think need to be fixed to make life easier for the committers. With the committer rep Eclipse Board elections coming up, I've decided to throw my hat into the ring. It's not an easy decision. I wonder how successful I'll be at representing the committer community at the board level. And I wonder how the sometimes competing forces between the committer community and the strategic members plays out. But I think it'll be a great personal challenge that will help me grow professionally, and if things work out, will help improve the ability of committers to do their job.
So what are the kind of things I'm talking about? Well, the foremost is the ability for committers to mold Eclipse as a whole into something that their customers can be happy with. There are a lot of interdependencies starting to emerge amongst projects and, of course, we have the big one between everyone and the Eclipse Platform. I've seen a lot of frustration but I think the solutions are available and don't require that we institute anarchy in the projects. Ensuring good inter-project communication channels is the main thing and really requires that projects be diverse and open. All projects need to be as transparent as much as possible so that committers can tell what's going on and can figure out how to influence and contribute in order to get their jobs done. There are guidelines set out by the board for this and I'd be interested in finding ways to ensuring that these guidelines are respected.
Of course I have other things that I've mentioned in this blog before. I still am saddened that we can't have complete IDE solutions hosted and branded as Eclipse distributions. I'd love to find a way to bring GPL/LGPL and other non EPL-licensed code into these solutions in such a way as to minimize the legal risk by adopters and the Foundation itself. I really hope that total prohibition isn't the only solution here.
And, of course, being a committer representative means just that, representing committers. I have a great relationship with the committers on the CDT, DSDP, PTP, Photran projects. These guys have been under-represented at the board level in the past and I hope to rectify that. And at the same time I seek to represent all committers and that means ensuring I have an open door policy to their needs. And I look forward to working with them to get a real sense of the diversity of Eclipse.
I am certainly honored to have the opportunity to participate in this election. As I said being a board member would be a great challenge that would help me focus my passion for Eclipse in new ways. The election itself will be a challenge as there are 7 other very strong candidates. No matter who ends up winning, you can be assured that the committers will be well represented.
But there are things that I think need to be fixed to make life easier for the committers. With the committer rep Eclipse Board elections coming up, I've decided to throw my hat into the ring. It's not an easy decision. I wonder how successful I'll be at representing the committer community at the board level. And I wonder how the sometimes competing forces between the committer community and the strategic members plays out. But I think it'll be a great personal challenge that will help me grow professionally, and if things work out, will help improve the ability of committers to do their job.
So what are the kind of things I'm talking about? Well, the foremost is the ability for committers to mold Eclipse as a whole into something that their customers can be happy with. There are a lot of interdependencies starting to emerge amongst projects and, of course, we have the big one between everyone and the Eclipse Platform. I've seen a lot of frustration but I think the solutions are available and don't require that we institute anarchy in the projects. Ensuring good inter-project communication channels is the main thing and really requires that projects be diverse and open. All projects need to be as transparent as much as possible so that committers can tell what's going on and can figure out how to influence and contribute in order to get their jobs done. There are guidelines set out by the board for this and I'd be interested in finding ways to ensuring that these guidelines are respected.
Of course I have other things that I've mentioned in this blog before. I still am saddened that we can't have complete IDE solutions hosted and branded as Eclipse distributions. I'd love to find a way to bring GPL/LGPL and other non EPL-licensed code into these solutions in such a way as to minimize the legal risk by adopters and the Foundation itself. I really hope that total prohibition isn't the only solution here.
And, of course, being a committer representative means just that, representing committers. I have a great relationship with the committers on the CDT, DSDP, PTP, Photran projects. These guys have been under-represented at the board level in the past and I hope to rectify that. And at the same time I seek to represent all committers and that means ensuring I have an open door policy to their needs. And I look forward to working with them to get a real sense of the diversity of Eclipse.
I am certainly honored to have the opportunity to participate in this election. As I said being a board member would be a great challenge that would help me focus my passion for Eclipse in new ways. The election itself will be a challenge as there are 7 other very strong candidates. No matter who ends up winning, you can be assured that the committers will be well represented.
Monday, February 04, 2008
Yearning for a good Windows toolchain
I've really started to get into this software synthesizer thing with VST albeit the older 2.4 version since most digital audio workstations don't support the new one (they could learn a lesson from Eclipse about keeping a community happy with API stability). There is a pretty good community sharing ideas and tips and examples. And it's a pretty low overhead activity that has a better chance of turning into a hobby than some of my other grand schemes. Most free software synths seem to be build by individuals (versus my desire to explore game development - ever see the credits at the end of a game?).
So I've started with the basic VST headers and threw away their SDK since my ego says I can do better (just kidding :). I've got enough so that I have a synthesizer that produces silence. ZeroMemory() is your friend. I'm using the CDT, of course, with the Microsoft Visual C++ build integration I'm working on. It builds fine once I figured out how to get DLL export files (.def) so that the right symbol gets exported. In a bizarre twist, they look for a function called main with a different signature than the usual C main, which causes a compile error with the MSVC compiler.
At any rate the biggest stumbling block I ran into was the lack of a CDT debug integration for Windows. I've had to resort to sprintf and popping up MessageBox dialogs to see if code gets hit and to show values. That's fine for simple things, but I found myself missing a real debugger integration as I've started to get interested in the more complex data structures I need to deal with.
Maybe working on a Windows debugger would make a good Google SOC project. And any student looking for ideas, feel free to make a proposal. Ideally, with all the talent working on gcc and gdb, I'd love to see gcc 4.x for MinGW and I'd love to see (or maybe I just need to figure out) how gdb can be used to debug gcc created DLLs with MSVC created applications. But I find it really disappointing that there isn't a bigger community working on better gnu tools for Windows development.
So I've started with the basic VST headers and threw away their SDK since my ego says I can do better (just kidding :). I've got enough so that I have a synthesizer that produces silence. ZeroMemory() is your friend. I'm using the CDT, of course, with the Microsoft Visual C++ build integration I'm working on. It builds fine once I figured out how to get DLL export files (.def) so that the right symbol gets exported. In a bizarre twist, they look for a function called main with a different signature than the usual C main, which causes a compile error with the MSVC compiler.
At any rate the biggest stumbling block I ran into was the lack of a CDT debug integration for Windows. I've had to resort to sprintf and popping up MessageBox dialogs to see if code gets hit and to show values. That's fine for simple things, but I found myself missing a real debugger integration as I've started to get interested in the more complex data structures I need to deal with.
Maybe working on a Windows debugger would make a good Google SOC project. And any student looking for ideas, feel free to make a proposal. Ideally, with all the talent working on gcc and gdb, I'd love to see gcc 4.x for MinGW and I'd love to see (or maybe I just need to figure out) how gdb can be used to debug gcc created DLLs with MSVC created applications. But I find it really disappointing that there isn't a bigger community working on better gnu tools for Windows development.
Tuesday, January 29, 2008
Nokia gets Qt
Sorry, I had to use this title. No one else seems to have picked up on it. But then maybe most people are like I was until I actually met a couple of developers from Trolltech at Eclipse Summit Europe in October and learned that it's actually pronounced 'Qute', Not Q.T.
At any rate, the big news in the mobile software industry today was Nokia's purchase of Trolltech. It's another piece of news that struck me as potentially game changing. Certainly Nokia has been under the gun with all the hype behind Google's Android platform. I think this is a strong move by Nokia to firm up their story.
Now, I've been a little luke warm to Qt. I've received a number of requests to include it in Wascana. I can't. And it violates one of the policies I have for Wascana. That is the open source version of their library uses the GPL license. That means only GPL applications can use that version of it and I don't want to get into that game. "Free" software is a paradox. You can't have freedom of users to do what they want with it, and freedom of developers to license their software how they see fit at the same time. And, of course, being a developer, I tend to side with the developers on this equation.
At the same time, though, I really like the architecture and look of Qt. And I understand Trolltech's need to make money and fund development of Qt. (Remember, I side with the developer). And they do have a pretty good Eclipse/CDT integration for Qt. And the commercial licenses aren't that much of a barrier if you're already used to paying for the libraries you use.
But I always secretly hoped that circumstances would change and we could use Qt without worrying about licensing. Does the transaction with Nokia lead to that circumstance. Apparently not according to the news release and letters to Trolltech's community. But I really think that if Qt had a free commercial license, like the Eclipse Public License, the whole KDE/Qt versus GTK wars would have ended long ago and we'd have peace and unity on the Linux desktop, and maybe on mobile devices too. At the very least, you would have seen a Qt SWT port.
At any rate, the big news in the mobile software industry today was Nokia's purchase of Trolltech. It's another piece of news that struck me as potentially game changing. Certainly Nokia has been under the gun with all the hype behind Google's Android platform. I think this is a strong move by Nokia to firm up their story.
Now, I've been a little luke warm to Qt. I've received a number of requests to include it in Wascana. I can't. And it violates one of the policies I have for Wascana. That is the open source version of their library uses the GPL license. That means only GPL applications can use that version of it and I don't want to get into that game. "Free" software is a paradox. You can't have freedom of users to do what they want with it, and freedom of developers to license their software how they see fit at the same time. And, of course, being a developer, I tend to side with the developers on this equation.
At the same time, though, I really like the architecture and look of Qt. And I understand Trolltech's need to make money and fund development of Qt. (Remember, I side with the developer). And they do have a pretty good Eclipse/CDT integration for Qt. And the commercial licenses aren't that much of a barrier if you're already used to paying for the libraries you use.
But I always secretly hoped that circumstances would change and we could use Qt without worrying about licensing. Does the transaction with Nokia lead to that circumstance. Apparently not according to the news release and letters to Trolltech's community. But I really think that if Qt had a free commercial license, like the Eclipse Public License, the whole KDE/Qt versus GTK wars would have ended long ago and we'd have peace and unity on the Linux desktop, and maybe on mobile devices too. At the very least, you would have seen a Qt SWT port.
Sunday, January 27, 2008
C Dj Trance
Believe or not I'm a big fan of hard rock music. It started with Iron Maiden, etc. in the 80s and moved to Nirvana, etc. in the 90's and with The Cure all throughout. It's what I call my "angry music". Not that I'm an angry guy, but I just love music that challenges me that way. But these days, no one knows how to play guitar anymore so I need to find my angry music elsewhere.
I have to thank my former colleague Johnny C for introducing me to Trance music. Electronic music has also always been an side interest of mine, but I'm a guitar hack first (a favorite memory recently is jamming with Eclipse's very own Steve Northover one night). However, I'm a geek firstest, so any chance to involve my passion for music with computers, I'll all over it. And I just love the rhythms and textures of Trance.
So I had this notion that I could make my own Trance music. There's is actually some good low cost digital audio workstation (DAW) software solutions, including a decent one called REAPER, that I've been playing with to see if I want to get into it. The challenge with these solutions is finding the right software synthesizers and effects to make it all sound good. But I was floored by the number of free DAW plug-ins out there. It's quite the huge underground ecosystem.
The main facilitator of this seems to be a free SDK put out by Steinberg called Virtual Studio Technology or VST. (BTW, there's a Microsoft equivalent called DXi, of course). It was build for their own DAW solution, but they openned up the licensing to allow anyone to take advantage of it, like REAPER. I'm not sure if that makes business sense, but it is helping me get interested in digital music so I may become a customer one day.
I checked out the SDK and even got the sample plug-in to compile using Wascana. Unfortunately, they've released a new version of the SDK that isn't backwards compatible so I couldn't try the plug-in in REAPER which doesn't support it yet. But I was able to launch the plug-in in the test host that comes with the SDK. Everything seemed to work except for the bitmap resources since I don't think we have the gnu resource compiler hooked up in our managed build integration. And unfortunately I ran into trouble getting it to debug at all under gdb. Yet another reason to get the Microsoft debug APIs integrated I guess.
But it does look like the CDT would be a nice IDE for applications like this. With the kind of processor power and multimedia assembly instructions you need to make these audio plug-ins work well in large setups, this is another area where I don't see C++ going away. The experience on Windows could be improved with a nicer Microsoft compiler and debugger integration. And it's a cool way to mix my passion for software with my passion for sound in one place.
I have to thank my former colleague Johnny C for introducing me to Trance music. Electronic music has also always been an side interest of mine, but I'm a guitar hack first (a favorite memory recently is jamming with Eclipse's very own Steve Northover one night). However, I'm a geek firstest, so any chance to involve my passion for music with computers, I'll all over it. And I just love the rhythms and textures of Trance.
So I had this notion that I could make my own Trance music. There's is actually some good low cost digital audio workstation (DAW) software solutions, including a decent one called REAPER, that I've been playing with to see if I want to get into it. The challenge with these solutions is finding the right software synthesizers and effects to make it all sound good. But I was floored by the number of free DAW plug-ins out there. It's quite the huge underground ecosystem.
The main facilitator of this seems to be a free SDK put out by Steinberg called Virtual Studio Technology or VST. (BTW, there's a Microsoft equivalent called DXi, of course). It was build for their own DAW solution, but they openned up the licensing to allow anyone to take advantage of it, like REAPER. I'm not sure if that makes business sense, but it is helping me get interested in digital music so I may become a customer one day.
I checked out the SDK and even got the sample plug-in to compile using Wascana. Unfortunately, they've released a new version of the SDK that isn't backwards compatible so I couldn't try the plug-in in REAPER which doesn't support it yet. But I was able to launch the plug-in in the test host that comes with the SDK. Everything seemed to work except for the bitmap resources since I don't think we have the gnu resource compiler hooked up in our managed build integration. And unfortunately I ran into trouble getting it to debug at all under gdb. Yet another reason to get the Microsoft debug APIs integrated I guess.
But it does look like the CDT would be a nice IDE for applications like this. With the kind of processor power and multimedia assembly instructions you need to make these audio plug-ins work well in large setups, this is another area where I don't see C++ going away. The experience on Windows could be improved with a nicer Microsoft compiler and debugger integration. And it's a cool way to mix my passion for software with my passion for sound in one place.
Wednesday, January 23, 2008
24 is the new 20
Well, I'm sitting here typing away looking at my new 24" widescreen monitor. Pidgin running on one side talking to my kind boss who ordered it for me, Internet Exploder on the other with me typing right here, and a monster Eclipse looking at IResource implementations sitting behind them. It's great.
Way back I blogged about my new widescreen laptop and commented on how liberating it was running Eclipse where had no problem seeing the Package/Project Explorer, editors, and Outline View in their full glory. Now at 24" at 1920x1200, it goes to a new level. The only problem is that I have to turn my head now to go between the Outline View and the left edge of the editor. Oh well. I'm sure if I had anything bigger, it might be too big (did I say that?).
And this size of monitor is getting pretty cheep. This is a good one at only $700. The 20" 4:3 monitors we used to druel about were more than that not so long ago. So if you're in the market for a new monitor for working in Eclipse, 24" is highly recommended.
Way back I blogged about my new widescreen laptop and commented on how liberating it was running Eclipse where had no problem seeing the Package/Project Explorer, editors, and Outline View in their full glory. Now at 24" at 1920x1200, it goes to a new level. The only problem is that I have to turn my head now to go between the Outline View and the left edge of the editor. Oh well. I'm sure if I had anything bigger, it might be too big (did I say that?).
And this size of monitor is getting pretty cheep. This is a good one at only $700. The 20" 4:3 monitors we used to druel about were more than that not so long ago. So if you're in the market for a new monitor for working in Eclipse, 24" is highly recommended.
Monday, January 21, 2008
How slow is Java? Not as much as you may think.
I was reading an article on the D programming language (more on that in an upcoming post). At the end of it, the guy claimed it was close in performance to C++. And he used this benchmarking site as evidence. It measures a number of different programming languages on a couple of x86 platforms at performing various algorithms. Most of the algorithms are pretty intense, so it's a good measure of the raw compute power of their runtimes.
Now any such measure is easy to dispute. Did the programmers have sufficient knowledge in the languages to build implementations that would be efficient? They do allow you to play with different weightings for different factors that may be important to you. But the results are interesting non-the-less.
So, a couple of things caught my eye with the default results. First, C++ is faster than C. That I can see if you use C++ inlining a lot which is not always easy to do in C. But it is only slightly faster so I'd call it a draw.
Second, if you preallocate 64MB of heap (-Xms), which we often do, Java is only 1.7 times slower than C++. I think that is a very important result. We often wondered if the CDT's parsers were slow because they were written in Java. The IBM J9 guys said that was crazy talk and these numbers somewhat show their point. Well written Java that really benefits from JIT should be less than 2 times slower than C++. We were looking for a 10 times performance improvement and would probably have been disappointed if we had rewritten everything in C++ (and I mean disappointed in the career limiting aspects of that decision ;).
I don't know whether to fully trust the numbers on this site, but it does reaffirm my belief that Java isn't that much slower than C++. I still don't like Java, though. Show me something as powerful as the Standard Template Library in Java and I might change my mind. Or the 'foreach' from D...
Now any such measure is easy to dispute. Did the programmers have sufficient knowledge in the languages to build implementations that would be efficient? They do allow you to play with different weightings for different factors that may be important to you. But the results are interesting non-the-less.
So, a couple of things caught my eye with the default results. First, C++ is faster than C. That I can see if you use C++ inlining a lot which is not always easy to do in C. But it is only slightly faster so I'd call it a draw.
Second, if you preallocate 64MB of heap (-Xms), which we often do, Java is only 1.7 times slower than C++. I think that is a very important result. We often wondered if the CDT's parsers were slow because they were written in Java. The IBM J9 guys said that was crazy talk and these numbers somewhat show their point. Well written Java that really benefits from JIT should be less than 2 times slower than C++. We were looking for a 10 times performance improvement and would probably have been disappointed if we had rewritten everything in C++ (and I mean disappointed in the career limiting aspects of that decision ;).
I don't know whether to fully trust the numbers on this site, but it does reaffirm my belief that Java isn't that much slower than C++. I still don't like Java, though. Show me something as powerful as the Standard Template Library in Java and I might change my mind. Or the 'foreach' from D...
Sunday, January 20, 2008
Hey Buddy, Want a Job?
Now that I'm playing manager, certain things occupy my thoughts more than they used to. One of them will be my ability to hire good Eclipse talent as opportunities open up for me to do so. Knowing who I know in the Eclipse community, there is a lot of good talent out there, just none of them really looking for new opportunities. And I'm not the only one who would be interested, I've talked to two other managers who also work for large vendors in the Eclipse community who are struggling finding Eclipse experts.
Now, I wonder if that's just a facet of the industry I am in, i.e., embedded development. The big issue we face is that most of the developers that work in our companies are C/C++ developers, not Java developers let alone Eclipse developers. Not only that, but there is a distinct bias against Java, especially from the guys who have been through the trenches with customers complaining about size/performance in resource critical devices. So needless to say, if we need tools developers, we can no longer really depend on growing them from inside the ranks like we have in the past.
So I wonder what solutions are available to help us poor souls looking for help. Certainly there are job sites out there where potential candidates can post resumes. But with those, I've found it difficult to weed through the masses looking for the right skills. Everyone seems to know enough Eclipse to put it on their listings, but how many know how to make Eclipse plug-ins.
One interesting idea I came up with this weekend is whether having such a job listing site as a part of eclipse.org would be useful. It could be something similar to Plug-in Central that vendors use to advertise their wares. We do have the helpwanted newsgroup, but I'd like to see one where it's more a two way street. Obviously we would need some sort of optional discretion to allow vendors or candidates to be quiet about their searches. But it could make it easier for Eclipse experts and Eclipse managers to find each other.
Now, I wonder if that's just a facet of the industry I am in, i.e., embedded development. The big issue we face is that most of the developers that work in our companies are C/C++ developers, not Java developers let alone Eclipse developers. Not only that, but there is a distinct bias against Java, especially from the guys who have been through the trenches with customers complaining about size/performance in resource critical devices. So needless to say, if we need tools developers, we can no longer really depend on growing them from inside the ranks like we have in the past.
So I wonder what solutions are available to help us poor souls looking for help. Certainly there are job sites out there where potential candidates can post resumes. But with those, I've found it difficult to weed through the masses looking for the right skills. Everyone seems to know enough Eclipse to put it on their listings, but how many know how to make Eclipse plug-ins.
One interesting idea I came up with this weekend is whether having such a job listing site as a part of eclipse.org would be useful. It could be something similar to Plug-in Central that vendors use to advertise their wares. We do have the helpwanted newsgroup, but I'd like to see one where it's more a two way street. Obviously we would need some sort of optional discretion to allow vendors or candidates to be quiet about their searches. But it could make it easier for Eclipse experts and Eclipse managers to find each other.
Thursday, January 10, 2008
Android for gamers on the go
I haven't posted much here lately. I guess starting a new job that's to be expected. I'm having a great time, though, and am learning more about install and licensing (the team I'm managing at Wind) than I've ever have. And I think there are some opportunities to do some cool things in this critical area that doesn't get much of the spotlight. And of course, I still have a lot of CDT work I want to do for Ganymede.
At any rate, one thing you will fine me post more about is Google Android. I've mentioned in the past my passing interest in game development. I've never had the opportunity to do any, but with my teenage sons at that ripe video gaming age, I can't help but think of the cool software that goes into these games and how much fun my boys have with it.
And being a development tools kind of guy and Eclipse in particular, I can't help but think that Eclipse would make an awesome environment to build games including everything from modeling characters and building levels to writing the code to make it all happen. That's my dream for Eclipse anyway.
Now the reason I love Android, is that I think it would make a great mobile gaming platform. And the Android gang must think so to since the SDK already comes with OpenGL ES support for 3D rendering with both a native library and a Java layer. It will be interesting to see what game developers can come up with and how well actual hardware will work. But it'll be fun to watch. And it would be really cool if they used Eclipse to build it.
In the meantime, I see that a Russian game developer has ported their 2D game to Android already. For a look at the YouTube video and article, check here.
At any rate, one thing you will fine me post more about is Google Android. I've mentioned in the past my passing interest in game development. I've never had the opportunity to do any, but with my teenage sons at that ripe video gaming age, I can't help but think of the cool software that goes into these games and how much fun my boys have with it.
And being a development tools kind of guy and Eclipse in particular, I can't help but think that Eclipse would make an awesome environment to build games including everything from modeling characters and building levels to writing the code to make it all happen. That's my dream for Eclipse anyway.
Now the reason I love Android, is that I think it would make a great mobile gaming platform. And the Android gang must think so to since the SDK already comes with OpenGL ES support for 3D rendering with both a native library and a Java layer. It will be interesting to see what game developers can come up with and how well actual hardware will work. But it'll be fun to watch. And it would be really cool if they used Eclipse to build it.
In the meantime, I see that a Russian game developer has ported their 2D game to Android already. For a look at the YouTube video and article, check here.
Saturday, December 29, 2007
Android is a Java fork, yeah so?
I'm finding it very interesting how a number of articles in the blogosphere are attacking the Google Android platform. I guess it is easy to criticize given it's only been in the public for 6 weeks. Yeah it looked like it would be vaporware until we got a hold of the actual running emulator and SDK. And yeah, the quality of the SDK could be better and there could be more for building native apps. But I think the Android team has done a great job of getting something in developers hands early so that they can start coming up with some money-making ideas and feedback any issues that they do run into.
The issue that I think people are getting caught in is the claim that Android is a fork of the Java standards. You know, I could really care less about that. If the Android platform is truly open with a commercial friendly license and is available on a lot of platforms, it will succeed. And if that means you'll have to port your Java ME or even your Java SE apps to it, the market will tell you that you should invest in that. I'd rather see the community decide what the best platform for mobile should be, not Sun who has little experience with it.
And I'm sure many at Eclipse would feel the same. Believe it or not, Eclipse is a fork of the Java standards as well and for much the same reasons. The Java standards didn't cut it when building great desktop applications. SWT and the Eclipse Platform have really kept Java alive where I thought it would never survive. It's a fork for all the right reasons. And so is Android as an embedded platform.
One thing you will see though is that Google, or at least the Open Handset Alliance (OHA) of which Google is the most powerful member, will dictate what the Android standard will be, much like Sun does with Java standards and much like the Eclipse Platform team does with the Eclipse Platform. And there is nothing wrong with that. If you're in the business of making money writing applications for these platforms, you want them to be as successful, i.e stable, as they can be.
But what it does mean is that if we want changes, we'd better the requests in now before we start debating whether there will ever be an Android 4.0...
The issue that I think people are getting caught in is the claim that Android is a fork of the Java standards. You know, I could really care less about that. If the Android platform is truly open with a commercial friendly license and is available on a lot of platforms, it will succeed. And if that means you'll have to port your Java ME or even your Java SE apps to it, the market will tell you that you should invest in that. I'd rather see the community decide what the best platform for mobile should be, not Sun who has little experience with it.
And I'm sure many at Eclipse would feel the same. Believe it or not, Eclipse is a fork of the Java standards as well and for much the same reasons. The Java standards didn't cut it when building great desktop applications. SWT and the Eclipse Platform have really kept Java alive where I thought it would never survive. It's a fork for all the right reasons. And so is Android as an embedded platform.
One thing you will see though is that Google, or at least the Open Handset Alliance (OHA) of which Google is the most powerful member, will dictate what the Android standard will be, much like Sun does with Java standards and much like the Eclipse Platform team does with the Eclipse Platform. And there is nothing wrong with that. If you're in the business of making money writing applications for these platforms, you want them to be as successful, i.e stable, as they can be.
But what it does mean is that if we want changes, we'd better the requests in now before we start debating whether there will ever be an Android 4.0...
Saturday, December 22, 2007
Oh, My Spinning Head
It's been a great first week at Wind River. I spent 3 of the first 4 hours there in conference calls which has given me a hint at how things are going to go. Wind is a very dispersed company and everything is managed over the phone, through IM and e-mail, and the occasional travel. It should be very dynamic and a really cool environment to insert myself into it.
And while that was going on, the debate raged in CDT-land over how to deal with projects sitting on top of file systems that may be spread all over hell's acre. The good news is that we have a lot of momentum and all the right people in place looking at it and talking about it. I think EFS is the key and how well it works hiding away the details of the actually layout of the files and directories from the rest of the CDT and Eclipse in general will tell how well we succeed.
I'm going to spend some time over the Christmas holidays working on my flexible file system. I have a good idea of how to do it, I just need to sit down and get it done. Once I'm finished, I'm hoping it'll work a lot like other major IDEs, Visual Studio included, and that you can add/exclude files and directories from anywhere your machine has access. And that should help us test all these other scenarios as well, including having your project distributed between machines.
It's going to be cool stuff, and I'm sure other projects will be interested in it as well. Our challenge will be to engage them and make sure we come up with a solution that works well for all of the Eclipse community.
And while that was going on, the debate raged in CDT-land over how to deal with projects sitting on top of file systems that may be spread all over hell's acre. The good news is that we have a lot of momentum and all the right people in place looking at it and talking about it. I think EFS is the key and how well it works hiding away the details of the actually layout of the files and directories from the rest of the CDT and Eclipse in general will tell how well we succeed.
I'm going to spend some time over the Christmas holidays working on my flexible file system. I have a good idea of how to do it, I just need to sit down and get it done. Once I'm finished, I'm hoping it'll work a lot like other major IDEs, Visual Studio included, and that you can add/exclude files and directories from anywhere your machine has access. And that should help us test all these other scenarios as well, including having your project distributed between machines.
It's going to be cool stuff, and I'm sure other projects will be interested in it as well. Our challenge will be to engage them and make sure we come up with a solution that works well for all of the Eclipse community.
Monday, December 17, 2007
Winds of Change
So I've started my new job. For those who haven't seen yet, I am now working for Wind River as an engineering manager in charge of a small team. From the meetings I've already had this morning it's going to be an interesting challenge and I have a lot of new technology to learn and people to meet.
On the Eclipse side, I will stay on as the CDT project lead. I've been very impressed with the team at Wind that is responsible for a lot of the good work that went into CDT 4.0 as well as the DSDP projects. And I'm excited to be able to continue working with them and the rest of the CDT community.
Of course, I am who I am, and none of my philosophies change with this move. I am still devoted to the grassroots of the open source world. You get them excited about your technology with a low barrier to entry, they become great customers in the future. And Wascana continues to play an important role there.
And I see Google Android filling the same role for embedded. It is an exciting platform for mobile devices (and not just cell phones) and I've been blown away by the energy of the community that's growing around it. There are guys who have even figured out how to build native applications with out having any of the header files and compilers available to them.
It'll be interesting to watch the parallels between Android and Eclipse. They look very similar in philosophy of commercialized open source and the power of community in making a successful platform and that's something the mobile space really needs to bring it to the next level.
On the Eclipse side, I will stay on as the CDT project lead. I've been very impressed with the team at Wind that is responsible for a lot of the good work that went into CDT 4.0 as well as the DSDP projects. And I'm excited to be able to continue working with them and the rest of the CDT community.
Of course, I am who I am, and none of my philosophies change with this move. I am still devoted to the grassroots of the open source world. You get them excited about your technology with a low barrier to entry, they become great customers in the future. And Wascana continues to play an important role there.
And I see Google Android filling the same role for embedded. It is an exciting platform for mobile devices (and not just cell phones) and I've been blown away by the energy of the community that's growing around it. There are guys who have even figured out how to build native applications with out having any of the header files and compilers available to them.
It'll be interesting to watch the parallels between Android and Eclipse. They look very similar in philosophy of commercialized open source and the power of community in making a successful platform and that's something the mobile space really needs to bring it to the next level.
Friday, December 14, 2007
Thank You QNX
I have an announcement. Today is my last day at QNX Software Systems. Now, for the Eclipse CDT community, no worries. I won't be going far and you won't see much of a change from me. But I do prefer to hold off announcing where I'll end up until I get there. Today, I want to pay tribute to QNX for whom we owe so much for where the CDT is today.
I'll always remember the first CDT summit in 2002. It was held here in one of the larger meeting rooms. We had people from Red Hat, MontaVista, Rational, and of course QNX. I remember the QNX gang being giddy as if they were proud parents. It was that day that the CDT project was born (or more historically accurate, reborn, but anyway).
The CDT that QNX gave to us was exactly what I was looking for. Something that fit in well with the rest of the Eclipse plug-ins, and the JDT especially. Even then we considered mixed language development with JNI as the holy grail that we were seeking, which we still are seeking BTW. The whole thing was a tribute to the small band of great developers that were locked away in an offsite building charged with coming up with an Eclipse based IDE in 6 months. They made all the right choices and most of them are still in effect today.
QNX also had the vision of what a commercial open source co-operative could accomplish in the right environment. IDE's are not QNX's core competency, and that is true for most platform and tool vendors. Very few IDE's have been successful in the market because they require a huge amount of investment to do right. But if we all banded together, put away our competitive anxieties, and focused on the common good, we could and did pull it off.
I also have to thank QNX for giving me the opportunity to "finish" what I started at IBM/Rational. When we lost the group there, we lost a hand full of really good developers, and friends, that were working on the CDT. But we clearly did not have a "successful" indexing strategy at that point and I really feared for the future of the CDT. I sincerely have to thank the management team here for talking me into coming over. It gave me the opportunity to set things right, and they helped me build my career as a leader in the Eclipse community.
I'm very happy with how the CDT and its community have evolved over the last two years. We owe a lot to QNX and QNX will always hold a special place in our community. I wish all the people I've worked here all the best and I look forward to continue working with them in the spirit of friendly co-opetition.
I'll always remember the first CDT summit in 2002. It was held here in one of the larger meeting rooms. We had people from Red Hat, MontaVista, Rational, and of course QNX. I remember the QNX gang being giddy as if they were proud parents. It was that day that the CDT project was born (or more historically accurate, reborn, but anyway).
The CDT that QNX gave to us was exactly what I was looking for. Something that fit in well with the rest of the Eclipse plug-ins, and the JDT especially. Even then we considered mixed language development with JNI as the holy grail that we were seeking, which we still are seeking BTW. The whole thing was a tribute to the small band of great developers that were locked away in an offsite building charged with coming up with an Eclipse based IDE in 6 months. They made all the right choices and most of them are still in effect today.
QNX also had the vision of what a commercial open source co-operative could accomplish in the right environment. IDE's are not QNX's core competency, and that is true for most platform and tool vendors. Very few IDE's have been successful in the market because they require a huge amount of investment to do right. But if we all banded together, put away our competitive anxieties, and focused on the common good, we could and did pull it off.
I also have to thank QNX for giving me the opportunity to "finish" what I started at IBM/Rational. When we lost the group there, we lost a hand full of really good developers, and friends, that were working on the CDT. But we clearly did not have a "successful" indexing strategy at that point and I really feared for the future of the CDT. I sincerely have to thank the management team here for talking me into coming over. It gave me the opportunity to set things right, and they helped me build my career as a leader in the Eclipse community.
I'm very happy with how the CDT and its community have evolved over the last two years. We owe a lot to QNX and QNX will always hold a special place in our community. I wish all the people I've worked here all the best and I look forward to continue working with them in the spirit of friendly co-opetition.
Thursday, December 13, 2007
Wascana, Still Going Strong
I got an note on one of the forums for Wascana, my packaging of the CDT and GNU toolchain and assorted libraries for Windows development. The question brought up again the need of the community to support the Microsoft toolchain, and debugging in particular. Unfortunately I've been busy with other things and really need to do a reset on this work to figure out the best way to proceed that will be the most successful. So not much progress has been made.
While I was on the Wascana site, I thought I would check to see how the download numbers were doing. It's been three months now since I made the last release and it's probably time to do another one, especially if the numbers had dropped to nothing.
But to my pleasant surprise, we have apparently passed the 3300 mark. The numbers have been strong with around 30-50 downloads a day but are now starting to dip below 20. So guess it is getting time. I need to figure out how best to package the boost library, and then get the latest Eclipse Platform and CDT. It would be really nice to figure out how to use the update manager to install these components nicely for you but I think that'll have to wait until next summer when the new Equinox provisioning work is ready and I've figured out how to use it.
But it is good to see Wascana is still seen as an interesting alternative for Windows developers.
While I was on the Wascana site, I thought I would check to see how the download numbers were doing. It's been three months now since I made the last release and it's probably time to do another one, especially if the numbers had dropped to nothing.
But to my pleasant surprise, we have apparently passed the 3300 mark. The numbers have been strong with around 30-50 downloads a day but are now starting to dip below 20. So guess it is getting time. I need to figure out how best to package the boost library, and then get the latest Eclipse Platform and CDT. It would be really nice to figure out how to use the update manager to install these components nicely for you but I think that'll have to wait until next summer when the new Equinox provisioning work is ready and I've figured out how to use it.
But it is good to see Wascana is still seen as an interesting alternative for Windows developers.
Monday, December 10, 2007
AGR is dead, apparently
One issue we've always struggled with on the CDT is how to do GUI testing of the CDT's UI components. A number of us looked at different open-source solutions that would allow anyone contributing to the CDT to also contribute GUI tests. Some community members do use commercial tools for their internal testing. But we'd prefer something generally available for everyone.
Two solutions seemed to come out tops, albeit a very low tops. AGR from TPTP and the SWT port of Abbot. However each of these had two severe problems that prevented us from using them.
First, the Abbot/SWT port has been progressing very slowly to the point where we're not sure it's even alive. We do have one committer, though, that is looking at supplying them with patches and maybe that'll bring it back to life.
AGR also had one big stumbling block, it's dependence on the TPTP test framework. The CDT releng test run is a simple JUnit setup and we wanted to run our GUI tests as part of that without having to spend the effort of integrating the framework. Bug 138369 was raised to see if someone in the community could make AGR work in such a simple environment.
Well, today, we were notified that AGR has gone into an As-Is state (i.e. dead) and the bug was marked won't fix. I personally recommend against marking bugs in the CDT as won't fix, because, who's to say someone won't come along and try and fix it. Why shut the door like that. At any rate, it does point out that the community hasn't really rallied behind AGR as a GUI testing solution.
So what is the current state of open source GUI testing frameworks for Eclipse? Is there something else out there? Or is there still hope for either of these technologies? Is there an EclipseCon talk on this subject?
Two solutions seemed to come out tops, albeit a very low tops. AGR from TPTP and the SWT port of Abbot. However each of these had two severe problems that prevented us from using them.
First, the Abbot/SWT port has been progressing very slowly to the point where we're not sure it's even alive. We do have one committer, though, that is looking at supplying them with patches and maybe that'll bring it back to life.
AGR also had one big stumbling block, it's dependence on the TPTP test framework. The CDT releng test run is a simple JUnit setup and we wanted to run our GUI tests as part of that without having to spend the effort of integrating the framework. Bug 138369 was raised to see if someone in the community could make AGR work in such a simple environment.
Well, today, we were notified that AGR has gone into an As-Is state (i.e. dead) and the bug was marked won't fix. I personally recommend against marking bugs in the CDT as won't fix, because, who's to say someone won't come along and try and fix it. Why shut the door like that. At any rate, it does point out that the community hasn't really rallied behind AGR as a GUI testing solution.
So what is the current state of open source GUI testing frameworks for Eclipse? Is there something else out there? Or is there still hope for either of these technologies? Is there an EclipseCon talk on this subject?
Subscribe to:
Posts (Atom)