I've always been intrigued by programming languages and what makes them tick, and what is the best one for what situation. That's why Dave Thomas's keynote at ESE still has me thinking about the mix of JavaScript and C++. So much so that I spent a few hours this weekend while waiting out the snow storm to get Google's V8 JavaScript VM building under MinGW for Wascana. I think it would be an intriguing addition to have the VM DLL available for developers using Wascana. With a few changes, I have it building and passing the unit tests and I have a patch into the V8 project. I'll make V8 available in the Wascana 1.0 alpha in the next couple of days.
Now that I have it, I have to ask myself - what the heck do you do with it? I've thought about building wrappers for the wxWidgets library to let you build thick client apps in JavaScript. wxWidgets also comes with Wascana, and thick client apps is kinda what Wascana is all about (aside from dreams of using it for game development, which could also benefit from a fast JavaScript engine).
But it's not clear where one would draw the line between JavaScript and C++. Given a C++ library like wxWidgets, or SDL, or what have you, is it enough to wrap it with JavaScript and have the developer do everything in JavaScript. Or should JavaScript just be this thing on the side that allows for extensibility of some larger application written in C++.
It makes me wonder if I'm following some crazy idea that some madman sold me in a bar in Germany. Or maybe this is challenging me to give it deeper thought, to think about how scripting and native languages are supposed to mix. Where in all this is the sweet spot of architectural balance. Or is there one? Either way, it'll be on my mind over the Christmas holiday season.
Monday, December 22, 2008
Friday, December 19, 2008
Fun with FEEDJIT
I'm not sure if you noticed, or are reading this blog from one of the syndication sites it gets copied too (like Planet Eclipse, or the Wind River Blog Network). But if you check back to the original site and scroll down a bit, you'll see a new panel called the FEEDJIT Live Traffic Feed. I know people express concerns about web things following them, and if I get enough negative response to it I'll pull it off. But in the meantime, I'm spellbound by this feature.
I'm learning quite a lot about the audience for this blog. The traffic feed gives me the city that where the person was, which is spread throughout the world, as well as a hint at how they got to my site. A few people come directly, I guess from an RSS reader where they've subscribed one way or another (Thank you!). More often, though, people end up here based on google searches, and I get the snippet that they were searching for! Creepy, but very useful.
So what are people searching for that pulls up my site? Well a lot of it lately has been the topics I'm most interested in lately, and that's CDT for Windows development, including Windows cross to Linux. It's good to see the interest from the community on that and I am continuing working on Wascana 1.0 as I write this (SDL is building in the background). I also often get a few queries on the Subversion Eclipse plug-in wars (I hate both right now, go git!). And you get the odd one looking for help, like today's "eclipse CDT autocomplete crap" (yeah, it has issues if you're environment isn't set up).
Anyway, it's pretty interesting to watch, and it humbles me immensely to see people from around the world reading what I write, especially when the google search reveals they searched for me by name. But I love to write and share my thoughts and I really appreciate it when people leave comments. Whether I agree with them or not, I always learn something from what they put there. It's a lot of fun and I encourage everyone to do the same. There will always be someone out there interested in what you have to say.
I'm learning quite a lot about the audience for this blog. The traffic feed gives me the city that where the person was, which is spread throughout the world, as well as a hint at how they got to my site. A few people come directly, I guess from an RSS reader where they've subscribed one way or another (Thank you!). More often, though, people end up here based on google searches, and I get the snippet that they were searching for! Creepy, but very useful.
So what are people searching for that pulls up my site? Well a lot of it lately has been the topics I'm most interested in lately, and that's CDT for Windows development, including Windows cross to Linux. It's good to see the interest from the community on that and I am continuing working on Wascana 1.0 as I write this (SDL is building in the background). I also often get a few queries on the Subversion Eclipse plug-in wars (I hate both right now, go git!). And you get the odd one looking for help, like today's "eclipse CDT autocomplete crap" (yeah, it has issues if you're environment isn't set up).
Anyway, it's pretty interesting to watch, and it humbles me immensely to see people from around the world reading what I write, especially when the google search reveals they searched for me by name. But I love to write and share my thoughts and I really appreciate it when people leave comments. Whether I agree with them or not, I always learn something from what they put there. It's a lot of fun and I encourage everyone to do the same. There will always be someone out there interested in what you have to say.
Tuesday, December 16, 2008
Fun with my little VIA console
At the Embedded Systems Conference in San Jose this year they handed out little VIA embedded EPIA systems to the attendees. I'm not sure everyone got one, but I was thrilled. It has a embedded VIA processor with a chipset that includes Unichrome 3D graphics, and also include a hard drive, ethernet, VGA, four USB ports, and audio in and out. It's a cool little unit.
I haven't done too much with it, but thinking about this Open Console concept (set top box with 3D graphics running Linux), I thought I'd try setting it up with some of the things I had in mind. I started by putting the Debian lenny installer onto a USB stick and installing from it. That was a little tricky until I reformated my USB stick and put syslinux on it properly. I installed enough packages to get X running with the openchrome driver for 3D graphics. glxgears ran pretty smoothly which gave me some hope I could actually use this thing to run games.
So I got adventurous and installed Nexuiz, an open source first person shooter. To my surprise, this and other open source 3D games are available from the Debian package repository. So a quick little 'apt-get' which brought down around 450MB of game, and I was off and running. We'll off anyway. I got about 20 seconds per frame, which makes it a little hard to even notice the thing was running.
Anyway, I tried a few other simpler games and they actually worked. I had to force myself to go to bed while hooked on billards-gl. It was fun. But I've slowly begun to realize that games built for the desktop aren't really ready to be played with only a joystick as you'd likely only have in a set top box scenario. So there would be work to be done.
I also started to understand first hand the commercial opportunity behind Linux, embedded Linux especially. Sure you can install a Linux distro and get a desktop environment up without too much effort. But try to do anything off that beaten path and you're in for a lot of work. If you can share in that work, fine. If you can pay someone to do it for you for cheaper than you could do, even better.
I also gave up on using this little VIA box for my play-totyping (hmm, new word). I need to start getting ready for my EclipseCon tutorial which will help me get back into the guts of qemu. Maybe I can do a little work there to bring GLX emulation to it, play time permitting, of course. Or maybe I'll shell out the $500 bucks to build a real system. Though playing in qemu would be funner...
I haven't done too much with it, but thinking about this Open Console concept (set top box with 3D graphics running Linux), I thought I'd try setting it up with some of the things I had in mind. I started by putting the Debian lenny installer onto a USB stick and installing from it. That was a little tricky until I reformated my USB stick and put syslinux on it properly. I installed enough packages to get X running with the openchrome driver for 3D graphics. glxgears ran pretty smoothly which gave me some hope I could actually use this thing to run games.
So I got adventurous and installed Nexuiz, an open source first person shooter. To my surprise, this and other open source 3D games are available from the Debian package repository. So a quick little 'apt-get' which brought down around 450MB of game, and I was off and running. We'll off anyway. I got about 20 seconds per frame, which makes it a little hard to even notice the thing was running.
Anyway, I tried a few other simpler games and they actually worked. I had to force myself to go to bed while hooked on billards-gl. It was fun. But I've slowly begun to realize that games built for the desktop aren't really ready to be played with only a joystick as you'd likely only have in a set top box scenario. So there would be work to be done.
I also started to understand first hand the commercial opportunity behind Linux, embedded Linux especially. Sure you can install a Linux distro and get a desktop environment up without too much effort. But try to do anything off that beaten path and you're in for a lot of work. If you can share in that work, fine. If you can pay someone to do it for you for cheaper than you could do, even better.
I also gave up on using this little VIA box for my play-totyping (hmm, new word). I need to start getting ready for my EclipseCon tutorial which will help me get back into the guts of qemu. Maybe I can do a little work there to bring GLX emulation to it, play time permitting, of course. Or maybe I'll shell out the $500 bucks to build a real system. Though playing in qemu would be funner...
Saturday, December 13, 2008
Time for Distributed Source Control is Now
Imagine this scenario. You're part of a small team that's been following the CDT closely and have adopted it as the IDE for your commercial platform. You grab the CDT source at times convenient to your product deliver schedule and work on a local copy fixing bugs you find as you go through product testing. You're not a committer but you do submit patches from time to time and hope that the CDT team picks them up. But they're often busy with their own delivery schedules and the patches often grow stale and fall off everyone's radar.
So you live with your CDT fork and struggle every time you have to update to a new CDT version, so you don't do that very often. And since you're busy struggling in that environment, you really don't end up with time to get more involved with the CDT. You are a small team and you only have so much time in the day. You run into Doug once in a while at the Eclipse conferences and talk about what you do and promise you'll figure out some way to get more involved, but he knows your story too well and doesn't put much faith in it despite his appreciate for your intentions.
Sounds like I have experience with this, don't I. This scenario is too real and I'd bet is very common across all open source projects. Relying on CVS and Subversion at Eclipse with access controls limited to the select few committers makes it very difficult for those on the fringes to get more involved. It truly is a have/have not environment. The committers have it easy, checking in their changes whenever they want and those that aren't are struggling to keep up, or simply fork and go their own direction.
I've learned that the new Symbian Foundation as selected Mercurial as their source control system. Along with Linus's git, it's one of the new breed of distributed source control systems. These systems allow for multiple repositories and provide mechanism to pull and push changes between them. The introduction chapter of the Mercurial on-line book provides a great description of why this architecture works well for large globally distributed projects.
I invite everyone to read it, especially the Eclipse community. Because I think we need this kind of capability now. CDT needs an infusion of new blood and I know there are a lot of people who work with the CDT code base but have only a limited time to contribute back. If we had the infrastructure to better support them and make it easier to pull their changes into the CDT main line, and easier for them to keep up with everyone else's changes, it could be the formula we need to grow.
So you live with your CDT fork and struggle every time you have to update to a new CDT version, so you don't do that very often. And since you're busy struggling in that environment, you really don't end up with time to get more involved with the CDT. You are a small team and you only have so much time in the day. You run into Doug once in a while at the Eclipse conferences and talk about what you do and promise you'll figure out some way to get more involved, but he knows your story too well and doesn't put much faith in it despite his appreciate for your intentions.
Sounds like I have experience with this, don't I. This scenario is too real and I'd bet is very common across all open source projects. Relying on CVS and Subversion at Eclipse with access controls limited to the select few committers makes it very difficult for those on the fringes to get more involved. It truly is a have/have not environment. The committers have it easy, checking in their changes whenever they want and those that aren't are struggling to keep up, or simply fork and go their own direction.
I've learned that the new Symbian Foundation as selected Mercurial as their source control system. Along with Linus's git, it's one of the new breed of distributed source control systems. These systems allow for multiple repositories and provide mechanism to pull and push changes between them. The introduction chapter of the Mercurial on-line book provides a great description of why this architecture works well for large globally distributed projects.
I invite everyone to read it, especially the Eclipse community. Because I think we need this kind of capability now. CDT needs an infusion of new blood and I know there are a lot of people who work with the CDT code base but have only a limited time to contribute back. If we had the infrastructure to better support them and make it easier to pull their changes into the CDT main line, and easier for them to keep up with everyone else's changes, it could be the formula we need to grow.
Thursday, December 11, 2008
x86, the ultimate applet engine?
I need to watch out or people will start calling me a Google fan boy or something (well, too late). It seems everything they come up with lately grabs my attention. And I guess it makes sense, because they seem to be heading in a different direction than a lot of people, and more in a direction that appeals to me. First Android (open mobile handset), then Google Chrome (Webkit-based browser), then the V8 C++ friendly JavaScript VM, and now, Native Client.
If you haven't heard of it, it appears to be a Google research project into running secured native x86 code in a browser. Yes, we have tried that before with ActiveX and it was a security disaster. But the underlying need for high performance interactive web pages is pretty intriguing. If you could write browser applets in C++, why wouldn't you? I suppose...
I had to try it myself. The install instructions are for Firefox, but I dumped Firefox for Chrome a while ago. It's good that Chrome has some Firefox in it, because all I had to do was copy the plugins for Firefox into my Chrome Plugins directory (it's hidden in Local Settings, Application Data, Google, Chrome, Application, Plugins).
I was then able to go through their little demos and tests. They're cute and the Mandlebrot demo shows some of the power. There's also a demo of the open source SDL version of id's Quake. It's pretty complicated to build and I couldn't get it working on my Windows box (mainly because I'm Cygwin-free and it seems to need it). But it's an interesting idea, taking an SDL-based application and converting it to run in a browser (Native Client uses SDL to do audio and video). Maybe, they'll even expose OpenGL through SDL to the native code as well. That would be more interesting.
One thing though that burst my bubble with this whole experience were the results of the performance tests that they have. The C++ version of the tests were only marginally better than the JavaScript ones. I think that's thanks to the great job they've done with the V8 VM. If that's the case, I really wonder whether this stuff actually makes sense, other than porting old software rendered games to your browser, I guess. I need to stew on that one a little before buying into this idea.
If you haven't heard of it, it appears to be a Google research project into running secured native x86 code in a browser. Yes, we have tried that before with ActiveX and it was a security disaster. But the underlying need for high performance interactive web pages is pretty intriguing. If you could write browser applets in C++, why wouldn't you? I suppose...
I had to try it myself. The install instructions are for Firefox, but I dumped Firefox for Chrome a while ago. It's good that Chrome has some Firefox in it, because all I had to do was copy the plugins for Firefox into my Chrome Plugins directory (it's hidden in Local Settings, Application Data, Google, Chrome, Application, Plugins).
I was then able to go through their little demos and tests. They're cute and the Mandlebrot demo shows some of the power. There's also a demo of the open source SDL version of id's Quake. It's pretty complicated to build and I couldn't get it working on my Windows box (mainly because I'm Cygwin-free and it seems to need it). But it's an interesting idea, taking an SDL-based application and converting it to run in a browser (Native Client uses SDL to do audio and video). Maybe, they'll even expose OpenGL through SDL to the native code as well. That would be more interesting.
One thing though that burst my bubble with this whole experience were the results of the performance tests that they have. The C++ version of the tests were only marginally better than the JavaScript ones. I think that's thanks to the great job they've done with the V8 VM. If that's the case, I really wonder whether this stuff actually makes sense, other than porting old software rendered games to your browser, I guess. I need to stew on that one a little before buying into this idea.
Tuesday, December 09, 2008
A busy day for Khronos
My Khronos.org News feed filled up all of a sudden today. Looks like they've been busy and had a couple of announcements to make.
They released a new version of the 2D OpenVG spec. They added some APIs for text glyphing to make it easier to draw good looking text. I'm not sure anyone really uses OpenVG, especially when you are most likely to be drawing 2D in a web browser with Adobe Flash or SVG (and even then, most likely Flash). From the news release, this is probably most interesting to the mobile crowd.
The more interesting announcement for me was the release of the first OpenCL spec. OpenCL is a standard for running general algorithms on the newer GPUs in video cards. It'll also be ported to other multi-core systems like Cell and DSPs, but most likely you'll be using it with a video card. Of course AMD and nVidia were quick to announce their support for this spec, which gives it some immediate momentum.
OpenCL specifies a C-based language for parallel processing as well as APIs that drive them. Up until now, nVidia and AMD had proprietary solutions that didn't work cross platform. OpenCL opens the door to make parellel programming available to more and more programmers and I'm dieing to see what they'll do with it...
They released a new version of the 2D OpenVG spec. They added some APIs for text glyphing to make it easier to draw good looking text. I'm not sure anyone really uses OpenVG, especially when you are most likely to be drawing 2D in a web browser with Adobe Flash or SVG (and even then, most likely Flash). From the news release, this is probably most interesting to the mobile crowd.
The more interesting announcement for me was the release of the first OpenCL spec. OpenCL is a standard for running general algorithms on the newer GPUs in video cards. It'll also be ported to other multi-core systems like Cell and DSPs, but most likely you'll be using it with a video card. Of course AMD and nVidia were quick to announce their support for this spec, which gives it some immediate momentum.
OpenCL specifies a C-based language for parallel processing as well as APIs that drive them. Up until now, nVidia and AMD had proprietary solutions that didn't work cross platform. OpenCL opens the door to make parellel programming available to more and more programmers and I'm dieing to see what they'll do with it...
Sunday, December 07, 2008
Wascana 1.0 in Alpha Testing
Well, that didn't take very long. I've spent a few hours building my special p2 artifact repository that manages installed files, including extracting them from an archive and deleting at uninstall time, along with it's associated p2 touchpoint that hooks it all up. It's not a lot of code and you can see it in CDT's CVS space (repo: /cvsroot/tools, module: org.eclipse.cdt/p2).
I've also created a generator that creates p2 repositories that use that touchpoint to install remote artifacts from various locations, mostly on SourceForge. Currently I only have support for the MinGW toolchain and the MSYS shell environment. I'll add libraries as I build them with the 4.2.3 compiler I'm using here. I'll start with SDL and also do wxWidgets and boost. We can always add more later.
It's working very well. Managed build picks up the mingw toolchain and uses it when you select the MinGW toolchain. MSYS doesn't work yet for Makefile projects but managed is usable now. And here's how:
Once you're done, you can go to the directory containing eclipse.exe and you'll see the mingw and msys directories there, ready to go. Well at least the mingw dir is, I still need to set up msys correctly to find the mingw compilers, but it is only an alpha :).
Feel free to give it a try and let me know what you think. I'm pretty excited with how this is going. While creating this, a new version of the win32 API component came out and I added it to the repo and the Update... feature found and installed it. Very cool!
It's a very interesting path where this is going. The ability to incrementally add in libraries and update new versions of the components will be a great showcase on how p2 can manage more than just bundles. Not to mention help me build one heck of a Windows development environment based on the CDT and open source tools and libraries.
I've also created a generator that creates p2 repositories that use that touchpoint to install remote artifacts from various locations, mostly on SourceForge. Currently I only have support for the MinGW toolchain and the MSYS shell environment. I'll add libraries as I build them with the 4.2.3 compiler I'm using here. I'll start with SDL and also do wxWidgets and boost. We can always add more later.
It's working very well. Managed build picks up the mingw toolchain and uses it when you select the MinGW toolchain. MSYS doesn't work yet for Makefile projects but managed is usable now. And here's how:
- Unzip the Eclipse IDE for C/C++ Developers anywhere you'd like on your machine. You can also start with any other Eclipse install as long as you have the CDT installed.
- In Software Updates, expand out the tools/cdt/releases/ganymede site into CDT Optional Features and install the Eclipse CDT p2 Toolchain Installer feature. Allow Eclipse to restart to make sure things are initialized (I'm not sure if you really have to do this, I'm just paranoid).
- Go back to Software Updates and add the Wascana repo site at http://wascana.sourceforge.net/repo. Install everything under the MinGW Toolchain category. This time you don't need to restart. You don't even need to apply changes.
Once you're done, you can go to the directory containing eclipse.exe and you'll see the mingw and msys directories there, ready to go. Well at least the mingw dir is, I still need to set up msys correctly to find the mingw compilers, but it is only an alpha :).
Feel free to give it a try and let me know what you think. I'm pretty excited with how this is going. While creating this, a new version of the win32 API component came out and I added it to the repo and the Update... feature found and installed it. Very cool!
It's a very interesting path where this is going. The ability to incrementally add in libraries and update new versions of the components will be a great showcase on how p2 can manage more than just bundles. Not to mention help me build one heck of a Windows development environment based on the CDT and open source tools and libraries.
Friday, December 05, 2008
Linux Kernel Debugging with CDT
Just ran into this awesome tutorial on how to use the CDT for debugging the Linux kernel using qemu's gdb remote debug service that makes it work much like a standard hardware/JTAG debugger.
This was something I played with a while ago when I looked at adding hardware debugging support to the CDT as an optional service. And I believe Elena from QNX has continued on with that work and we should hopefully see it completed for Galileo (if not before that).
But it further solidifies for me how important qemu is as a tool in the belt of the embedded software developer. We've seen it as a key enabler for Android without which I'm not sure it would have achieved the momentum it has. I think there are still issues with it, and of course one I'm looking at is ease at adding new hardware emulation and 3D graphics support. But I think there is plenty of opportunity there and being an open source project, the door is open to help make that happen.
This was something I played with a while ago when I looked at adding hardware debugging support to the CDT as an optional service. And I believe Elena from QNX has continued on with that work and we should hopefully see it completed for Galileo (if not before that).
But it further solidifies for me how important qemu is as a tool in the belt of the embedded software developer. We've seen it as a key enabler for Android without which I'm not sure it would have achieved the momentum it has. I think there are still issues with it, and of course one I'm looking at is ease at adding new hardware emulation and 3D graphics support. But I think there is plenty of opportunity there and being an open source project, the door is open to help make that happen.
Monday, December 01, 2008
The Future of Wascana
For those that don't know, I've been working on the side on a complete open source IDE distribution for Windows called Wascana Desktop Developer. It includes the CDT and the MinGW tool chain and a handful of libraries that enable cross platform development. I did the original "beta" release over a year ago and have over 12,000 downloads to date. But it's getting long in the tooth and I really need to respin with Ganymede Eclipse/CDT and gcc 4.x.
The question I'm dealing with now is what Wascana should look like going forward. My Wind River team and I are just wrapping up a p2-based installer for our Wind River products that are similar to Wascana but on a much bigger scale and targeting our Wind River platforms. We've learned a lot about how to extend p2 to manage the install, update, and removal of archived binary files into an install tree.
I want to bring that similar experience to Wascana and have started working on an open source version of these extensions. I'm starting doing it as part of the CDT since I need to support CDT 5.0.x with it and want to release around Christmas time. Once I check it in, the p2 team can look and see if the want something like this and give feedback on changes that would be needed to get it into an upcoming platform release.
In the end, Wascana will mainly be a p2 repository that ensures you have all the plug-ins installed to get a working CDT for MinGW, and that will allow you to download and install the MinGW tool chain and libraries, either from their home locations, or from the Wascana SourceForge download area if I need to rebuild for whatever reason. Updates and new components would be done by adding them to the repository.
So the question becomes, do I need an old time installer for this, or would the community be happy simply downloading the Eclipse C/C++ IDE package and working with the Software Updates tool to get everything they need. I have a feeling people will still be looking for that single setup.exe download to set everything up. Then I need to ask whether laying down the bits is sufficient, or whether I need to do a p2 director thing.
The good news is that I sense MinGW is maturing. Despite having an unmanaged release cycle (and I do have a second source for the mingw gcc tool chain thank goodness), it looks like it's ready for prime time, at least for my little distro. Enough so, I'm giving up on Windows debug support. My focus is cross platform, and my time is limited and building a pure Windows debugger is hard and without a significant contribution it won't happen, so I'm not counting on it. Wascana will do just fine without it.
The question I'm dealing with now is what Wascana should look like going forward. My Wind River team and I are just wrapping up a p2-based installer for our Wind River products that are similar to Wascana but on a much bigger scale and targeting our Wind River platforms. We've learned a lot about how to extend p2 to manage the install, update, and removal of archived binary files into an install tree.
I want to bring that similar experience to Wascana and have started working on an open source version of these extensions. I'm starting doing it as part of the CDT since I need to support CDT 5.0.x with it and want to release around Christmas time. Once I check it in, the p2 team can look and see if the want something like this and give feedback on changes that would be needed to get it into an upcoming platform release.
In the end, Wascana will mainly be a p2 repository that ensures you have all the plug-ins installed to get a working CDT for MinGW, and that will allow you to download and install the MinGW tool chain and libraries, either from their home locations, or from the Wascana SourceForge download area if I need to rebuild for whatever reason. Updates and new components would be done by adding them to the repository.
So the question becomes, do I need an old time installer for this, or would the community be happy simply downloading the Eclipse C/C++ IDE package and working with the Software Updates tool to get everything they need. I have a feeling people will still be looking for that single setup.exe download to set everything up. Then I need to ask whether laying down the bits is sufficient, or whether I need to do a p2 director thing.
The good news is that I sense MinGW is maturing. Despite having an unmanaged release cycle (and I do have a second source for the mingw gcc tool chain thank goodness), it looks like it's ready for prime time, at least for my little distro. Enough so, I'm giving up on Windows debug support. My focus is cross platform, and my time is limited and building a pure Windows debugger is hard and without a significant contribution it won't happen, so I'm not counting on it. Wascana will do just fine without it.
Saturday, November 29, 2008
Javascript and C++, eh?
I can't get my mind off of Dave Thomas's keynote at Eclipse Summit Europe. His words made so many things crystallize in my mind. I've stated many times before in this blog and in my day job, I hate Java. It's an incredible irony that I do my day to day coding in Java to support developers who focus so much on efficiency and performance and use C mainly to accomplish that with a sprinkling of C++ for good measure. And then to hear their constant complaints that Eclipse is too slow. My good friends in Java VM land tell me not to blame Java for that, but you know, it's so tempting.
Dave mentioned that applications should be written in C++ and JavaScript. I dunno. C++ has it's difficulties, there is no doubt. It's hard to write good C++ programs. That's why the mix with JavaScript made me think. Does it make sense to build an application where your hard core performance focused code and code that interfaces with the underlying system is written in C++, but all the code that manages interactions with the user is done in JavaScript?
I've started to take a look at Google's V8 JavaScript engine. As they say in their videos, they're built for embedding in C++ applications and they have implemented some interesting tricks to get JavaScript to run fast, such as a JIT compiler and some heuristics to make class property access faster. As well, they have an efficient memory management system which includes being able to persist snapshots of the heap, including the JITed code, out to the file system for faster startup.
That got me thinking of Eclipse, of course, or really IDE's in general. What if you take a cross platform GUI toolkit like wxWidgets, add in a component model to allow for dynamic extensions, plus rewrite the CDT parsers in C++ for speed, plus ..., and throw in a JavaScript engine like V8 to make it easy for users to program, wouldn't that make for an interesting architecture? But we already have Eclipse so why would we do that all again? Just a question...
Dave mentioned that applications should be written in C++ and JavaScript. I dunno. C++ has it's difficulties, there is no doubt. It's hard to write good C++ programs. That's why the mix with JavaScript made me think. Does it make sense to build an application where your hard core performance focused code and code that interfaces with the underlying system is written in C++, but all the code that manages interactions with the user is done in JavaScript?
I've started to take a look at Google's V8 JavaScript engine. As they say in their videos, they're built for embedding in C++ applications and they have implemented some interesting tricks to get JavaScript to run fast, such as a JIT compiler and some heuristics to make class property access faster. As well, they have an efficient memory management system which includes being able to persist snapshots of the heap, including the JITed code, out to the file system for faster startup.
That got me thinking of Eclipse, of course, or really IDE's in general. What if you take a cross platform GUI toolkit like wxWidgets, add in a component model to allow for dynamic extensions, plus rewrite the CDT parsers in C++ for speed, plus ..., and throw in a JavaScript engine like V8 to make it easy for users to program, wouldn't that make for an interesting architecture? But we already have Eclipse so why would we do that all again? Just a question...
Friday, November 28, 2008
An Interesting Ottawa Demo Camp
The Ottawa Eclipse Demo camp was tonight and I thought I'd write about it before I went to bed. The demos were quite interesting, a different mix than before which keeps it fresh. And the hospitality of the Foundation staff was awesome again.
I was especially intrigued by Nick Edgar's embedded web UI demo that he's working on as part of Jazz. This is something I thought of doing for my talk at ESE. Present information in a web page using Eclipse's embedded browser. And then have JavaScript on that page interact with the surrounding Eclipse environment. The workflow he showed was very clean and I think there are some pretty cool things we can do with this. The technique he used was quite a kludge and even he admits it (communicating through the status bar?) But the SWT guys are thinking of better ways and I can't wait to try this myself.
The other interesting demo was from the Zeligsoft gang. I worked with some of the fellows that started Zeligsoft. We were part of the Rose RealTime development team. It was interesting to see the product they've come up with and the simularities it has with the stuff we did back then. They're betting the farm on model driven development. I can't say whether they'll succeed or not, but they've done a few things better, but a lot is the same.
I also have to thank Boris and Eric for their demos on e4 and the model-based UI in particular. I have a better sense of what they are trying to accomplish. Whether it's better or not than what we have today, I'm not sold yet. But I'll have to give it some hands on before making a final judgement.
I also got some interesting feedback on my article on IBM and Eclipse. (BTW, it's not whether we can survive, it's that we better plan and make sure we can, which I think we're finally doing). There were a lot of IBMers at the Demo Camp which was good to see. And there were as many ex-IBMers there too. I think it's pretty healthy. The Eclipse expertise is spreading throughout our small and tight knit town and Ottawa has a great concentration of Eclipse expertise, which makes it a great place to be.
I was especially intrigued by Nick Edgar's embedded web UI demo that he's working on as part of Jazz. This is something I thought of doing for my talk at ESE. Present information in a web page using Eclipse's embedded browser. And then have JavaScript on that page interact with the surrounding Eclipse environment. The workflow he showed was very clean and I think there are some pretty cool things we can do with this. The technique he used was quite a kludge and even he admits it (communicating through the status bar?) But the SWT guys are thinking of better ways and I can't wait to try this myself.
The other interesting demo was from the Zeligsoft gang. I worked with some of the fellows that started Zeligsoft. We were part of the Rose RealTime development team. It was interesting to see the product they've come up with and the simularities it has with the stuff we did back then. They're betting the farm on model driven development. I can't say whether they'll succeed or not, but they've done a few things better, but a lot is the same.
I also have to thank Boris and Eric for their demos on e4 and the model-based UI in particular. I have a better sense of what they are trying to accomplish. Whether it's better or not than what we have today, I'm not sold yet. But I'll have to give it some hands on before making a final judgement.
I also got some interesting feedback on my article on IBM and Eclipse. (BTW, it's not whether we can survive, it's that we better plan and make sure we can, which I think we're finally doing). There were a lot of IBMers at the Demo Camp which was good to see. And there were as many ex-IBMers there too. I think it's pretty healthy. The Eclipse expertise is spreading throughout our small and tight knit town and Ottawa has a great concentration of Eclipse expertise, which makes it a great place to be.
Thursday, November 27, 2008
Long Live the Benevolent Dictator
The last few weeks I've been nose to the grindstone finishing up our first Wind River product release with a new p2-based installer. It's been a while since I've been involved in commercial development and, though it's been grueling and has taken me away from my CDT project lead duties, I can see the light at the end of the tunnel and it looks like we'll be able to ship on time and with good quality, but maybe without all the bells and whistles I had hoped for when we started.
It's good to work in the corporate structure again too. If there are any decisions to be made, we have the processes and organization in place to make sure those decisions get made and that all the loose ends get tied up. It's the only way to succeed. You need that structure to make sure everyone is going in the same direction and has the same objectives.
So that got me thinking. Looking at my involvement with the CDT, I have had feedback that people looked to me as the guy to make the decisions, or at least to adjudicate any conflicts. To be the benevolent dictator at times. And we ended up getting a lot of things done over the years and everyone working on the CDT was going in the same direction. We sort of made up a structure where one didn't really exist, because we needed it to be successful.
I have big fears for e4 on that front. McQ and the IBM gang has made it clear over and over again, including on today's e4 call, that they are working on what they find important, and everyone else should do the same, or nothing will get done. And there are a few things going on. I'm leading the resources effort and we're working on things that individually are important to us and our employers. And clearly the SWT team is doing the same. But as hard as I try, I can't figure out what the UI guys are trying to accomplish. And then there are lots of things in the Eclipse Platform that no one is looking at. Debug, for example.
I firmly believe that even with open source projects, you need that benevolent dictator to actually deliver things. Where would Linux be without Linus? Where would Eclipse be without the early dictatorship of IBM? And there are countless examples. Where you see a successful open source project, you find an individual, or a small team, who make decisions and ensures everyone is working together. I get the sense that people think that's anti-open, but I can't see how a project, open or not, can succeed with out one.
It's good to work in the corporate structure again too. If there are any decisions to be made, we have the processes and organization in place to make sure those decisions get made and that all the loose ends get tied up. It's the only way to succeed. You need that structure to make sure everyone is going in the same direction and has the same objectives.
So that got me thinking. Looking at my involvement with the CDT, I have had feedback that people looked to me as the guy to make the decisions, or at least to adjudicate any conflicts. To be the benevolent dictator at times. And we ended up getting a lot of things done over the years and everyone working on the CDT was going in the same direction. We sort of made up a structure where one didn't really exist, because we needed it to be successful.
I have big fears for e4 on that front. McQ and the IBM gang has made it clear over and over again, including on today's e4 call, that they are working on what they find important, and everyone else should do the same, or nothing will get done. And there are a few things going on. I'm leading the resources effort and we're working on things that individually are important to us and our employers. And clearly the SWT team is doing the same. But as hard as I try, I can't figure out what the UI guys are trying to accomplish. And then there are lots of things in the Eclipse Platform that no one is looking at. Debug, for example.
I firmly believe that even with open source projects, you need that benevolent dictator to actually deliver things. Where would Linux be without Linus? Where would Eclipse be without the early dictatorship of IBM? And there are countless examples. Where you see a successful open source project, you find an individual, or a small team, who make decisions and ensures everyone is working together. I get the sense that people think that's anti-open, but I can't see how a project, open or not, can succeed with out one.
Can Eclipse Survive Without IBM?
I bet you this title got your attention...
Let me tell you a story. It's one a lot of us Eclipse "insiders" know from our trip to Ludwigsburg, Germany. If you look at the program for Eclipse Summit Europe, you'll notice a distinct lack of Eclipse Platform committers, i.e. IBMers, presenting. And one of them was lucky enough to get his travel approval the Friday afternoon before the conference. The Summit was a resounding success despite that. The Eclipse community in Europe has gone well past caring about the traditional Platform and are looking at really cool technologies like OSGi with Equinox and Modeling (despite Dave Thomas' decree that modeling sucks, which it does, at least UML-like modeling).
Now, I'm not sure if this year is any different from previous ESE's. But with the discussions we're having on the EclipseCon program committee about how many IBMers will be able to attend to give their presentations, it's got me thinking. What happens if this apparent trend continues and we loose the commitment IBM has made to Eclipse. Can Eclipse survive without IBM?
Well, I can say Wind River is doing their part to help out. We have myself and Martin O working on the Platform Resources evolution for e4. And we have Pawel who's now a Platform Debug committer. And as always, we're doing major contributions to the CDT and DSDP projects. And the numbers show the Eclipse committer community continues to grow and a lot of projects are healthy.
So can we survive without IBM? Absolutely. In fact, I'd consider the Eclipse Platform feature complete, at least for the needs of IDE and RCP/OSGi vendors. Yeah, things could be cleaned up, and yeah, we could make Eclipse work with Web 2.0 (although I really question whether SWT is the right technology for that). But from what I saw in Germany, Eclipse is alive and well. There are some really cool things that are going on and while the platforms are stabilizing and are probably becoming less interesting (and I'll sadly include the CDT in that list), I get the sense that those relying on the platforms will keep them alive. They have too.
Let me tell you a story. It's one a lot of us Eclipse "insiders" know from our trip to Ludwigsburg, Germany. If you look at the program for Eclipse Summit Europe, you'll notice a distinct lack of Eclipse Platform committers, i.e. IBMers, presenting. And one of them was lucky enough to get his travel approval the Friday afternoon before the conference. The Summit was a resounding success despite that. The Eclipse community in Europe has gone well past caring about the traditional Platform and are looking at really cool technologies like OSGi with Equinox and Modeling (despite Dave Thomas' decree that modeling sucks, which it does, at least UML-like modeling).
Now, I'm not sure if this year is any different from previous ESE's. But with the discussions we're having on the EclipseCon program committee about how many IBMers will be able to attend to give their presentations, it's got me thinking. What happens if this apparent trend continues and we loose the commitment IBM has made to Eclipse. Can Eclipse survive without IBM?
Well, I can say Wind River is doing their part to help out. We have myself and Martin O working on the Platform Resources evolution for e4. And we have Pawel who's now a Platform Debug committer. And as always, we're doing major contributions to the CDT and DSDP projects. And the numbers show the Eclipse committer community continues to grow and a lot of projects are healthy.
So can we survive without IBM? Absolutely. In fact, I'd consider the Eclipse Platform feature complete, at least for the needs of IDE and RCP/OSGi vendors. Yeah, things could be cleaned up, and yeah, we could make Eclipse work with Web 2.0 (although I really question whether SWT is the right technology for that). But from what I saw in Germany, Eclipse is alive and well. There are some really cool things that are going on and while the platforms are stabilizing and are probably becoming less interesting (and I'll sadly include the CDT in that list), I get the sense that those relying on the platforms will keep them alive. They have too.
Friday, November 21, 2008
Code Analysis and Refactoring with the CDT
For those that missed my talk at Eclipse Summit Europe, here are my slides. Unfortunately, that's pretty much all the documentation we have on this capability, as I mention in the next steps slide. The community needs to step up and help with this if we want this capability to grow.
Code Analysis and Refactoring with CDT
View SlideShare presentation or Upload your own.
Thursday, November 20, 2008
CDT at Eclipse Summit Europe
Well, the closing session is about to start and the vendors are packing up their displays. Another successful Eclipse Summit Europe is about to go off into the sunset. For me, it was proof again why I love coming to this show. The CDT community in Europe is strong and a lot of them are doing and want to do interesting things with the CDT.
The talk I gave was on the code analysis capabilities of the CDT introducing the things you can do with the CDT's parsers and indexing framework. I also introduced the new refactoring engine that we have which really opens up a lot of cool automations you can do to analyze and refactor your code. The best part is that I had a few guys come up to me after to ask about certain analysis things they wanted to do. I'm glad I gave that talk and I hope more people take a look at what the CDT has to offer in this area.
I also had a number of people ask about the CDT managed build system. This is an area in a bit of trouble right now with the CDT. One of the key developers has left and we're struggling understanding the code that he left behind. Hopefully these vendors who have concerns about the build system will join us and get us rolling again. The CDT build model can do some pretty cool things and I look forward to seeing the different build integrations people are thinking of working.
I had a discussion with someone interested in working on the Windows debug integration I have on my wish list. I've given it a couple of tries and there is a start of one in the Target Communication Framework (TCF) agent. Hopefully we can finally get this together and have full support for the Visual C++ compiler with the CDT.
Speaking of TCF, there was a lot of interest in it from various embedded system vendors. It's a really good technology for building target agents with a clean communication protocol back to Eclipse and a services oriented architecture. I've been interested in component models for C/C++ applications and I can see how this agent could use something like that. I'll have to give it some thought and see if others are interested in getting involved in that.
It's been a fun and interesting week. Hopefully I talked to everyone who wanted to talk CDT with me. And hopefully we can get some momentum off of that to continue the growth of the CDT community. Those late nights in the hotel bar with the Eclipse gang was part of that community building and I'm going to sleep well on the flight home but it was worth it.
The talk I gave was on the code analysis capabilities of the CDT introducing the things you can do with the CDT's parsers and indexing framework. I also introduced the new refactoring engine that we have which really opens up a lot of cool automations you can do to analyze and refactor your code. The best part is that I had a few guys come up to me after to ask about certain analysis things they wanted to do. I'm glad I gave that talk and I hope more people take a look at what the CDT has to offer in this area.
I also had a number of people ask about the CDT managed build system. This is an area in a bit of trouble right now with the CDT. One of the key developers has left and we're struggling understanding the code that he left behind. Hopefully these vendors who have concerns about the build system will join us and get us rolling again. The CDT build model can do some pretty cool things and I look forward to seeing the different build integrations people are thinking of working.
I had a discussion with someone interested in working on the Windows debug integration I have on my wish list. I've given it a couple of tries and there is a start of one in the Target Communication Framework (TCF) agent. Hopefully we can finally get this together and have full support for the Visual C++ compiler with the CDT.
Speaking of TCF, there was a lot of interest in it from various embedded system vendors. It's a really good technology for building target agents with a clean communication protocol back to Eclipse and a services oriented architecture. I've been interested in component models for C/C++ applications and I can see how this agent could use something like that. I'll have to give it some thought and see if others are interested in getting involved in that.
It's been a fun and interesting week. Hopefully I talked to everyone who wanted to talk CDT with me. And hopefully we can get some momentum off of that to continue the growth of the CDT community. Those late nights in the hotel bar with the Eclipse gang was part of that community building and I'm going to sleep well on the flight home but it was worth it.
Thoughts on Dave Thomas' Keynote
Ed Merks already gave a summary of Dave Thomas' keynote yesterday morning here at Eclipse Summit Europe. It was the first time I saw Dave speak and I was warned he tended to say things that offended the audience. And to Dave's point, that is kind of what a keynote speaker should do. Spark thought. Break through the assumptions that we tend to fall into when we get comfortable in our skin. And I think he raised some serious points that are making me wonder about what's really happening in our industry.
I guess his main point is that Java for embedded has missed the boat. If you haven't gone through the pain of doing Java for embedded devices, don't worry, you didn't miss anything. I've been waiting to see when I need to care about Java in this space and I've talked to some of the people here at Eclipse Summit Europe about this. I think they quietly agree with Dave. Those that have figured out how to do Java on embedded are doing OK with it. But there are a lot of issues to face. The worst of them is the bloat that the Java VM continues to grow from release to release. The embedded VMs are horribly crippled, and if you want to use the Sun VM, you are crippled from paring down that bloat. The discussion is interesting, and we may still be proven wrong, but for now, I can ignore Java for embedded and I can sleep at night.
There were some other messages from Dave that hit home as well. Programming is horribly complicated. Normal people will never be able to figure it out. Which means if you have figured it out, you're not normal, and I guess that includes me. But it is true. I've blogged a lot about this in the past. We can barely get our programs to work as it is. Wait until you're trying to program 100 threads running through your mess all at the same time. We're doomed.
But there are some things we can do to give us a chance to survive. Dave talked a bit about how the lack of a software component model is making us look like fools in the eyes of the engineering community. Can you imagine if automakers had to custom build all the components that make up a car? Imagine now if we could go to a shop and pick up high quality software components and tie them together will few lines in a script.
Now Dave was be extreme in his position. There are a number of areas where component models are being used, OSGi is an obvious one, all these "Mash-ups" are doing things like this. But coming back to embedded, we can't rely on Java to provide the solution. Dave's answer was C++ with JavaScript. And I think that's a great idea. Build components in C++ and tie them together with a scripting engine. Dave picked JavaScript, which is OK but he did mention he's working with Google on their V8 JavaScript engine. Lua is another good choice. And actually Domain Specific Languages offer solutions as well (and I'm not just saying that because I'm sitting in Rich Gronback's DSL talk right now ;).
It was really interesting to spend time with Dave Thomas in his keynote and with a group of us at the hotel bar. I could learn a lot from him. This week it was to open up my mind and challenge the assumptions. If you read this blog regularly you find that I tend to do that anyway, but it's an important reminder to keep doing that and make sure we don't make the same mistakes over and over again.
I guess his main point is that Java for embedded has missed the boat. If you haven't gone through the pain of doing Java for embedded devices, don't worry, you didn't miss anything. I've been waiting to see when I need to care about Java in this space and I've talked to some of the people here at Eclipse Summit Europe about this. I think they quietly agree with Dave. Those that have figured out how to do Java on embedded are doing OK with it. But there are a lot of issues to face. The worst of them is the bloat that the Java VM continues to grow from release to release. The embedded VMs are horribly crippled, and if you want to use the Sun VM, you are crippled from paring down that bloat. The discussion is interesting, and we may still be proven wrong, but for now, I can ignore Java for embedded and I can sleep at night.
There were some other messages from Dave that hit home as well. Programming is horribly complicated. Normal people will never be able to figure it out. Which means if you have figured it out, you're not normal, and I guess that includes me. But it is true. I've blogged a lot about this in the past. We can barely get our programs to work as it is. Wait until you're trying to program 100 threads running through your mess all at the same time. We're doomed.
But there are some things we can do to give us a chance to survive. Dave talked a bit about how the lack of a software component model is making us look like fools in the eyes of the engineering community. Can you imagine if automakers had to custom build all the components that make up a car? Imagine now if we could go to a shop and pick up high quality software components and tie them together will few lines in a script.
Now Dave was be extreme in his position. There are a number of areas where component models are being used, OSGi is an obvious one, all these "Mash-ups" are doing things like this. But coming back to embedded, we can't rely on Java to provide the solution. Dave's answer was C++ with JavaScript. And I think that's a great idea. Build components in C++ and tie them together with a scripting engine. Dave picked JavaScript, which is OK but he did mention he's working with Google on their V8 JavaScript engine. Lua is another good choice. And actually Domain Specific Languages offer solutions as well (and I'm not just saying that because I'm sitting in Rich Gronback's DSL talk right now ;).
It was really interesting to spend time with Dave Thomas in his keynote and with a group of us at the hotel bar. I could learn a lot from him. This week it was to open up my mind and challenge the assumptions. If you read this blog regularly you find that I tend to do that anyway, but it's an important reminder to keep doing that and make sure we don't make the same mistakes over and over again.
Friday, November 14, 2008
You want to see a busy mailing list?
Just check here: http://lists.gnu.org/archive/html/qemu-devel/2008-11/threads.html
I was looking to see when qemu, a very cool virtual machine for many hosts and many target CPU architectures, was going to come out with a new release. As part of that, I was checking to see if it was under active development. Well, with 55 e-mails on November 13'th when I looked, I guess it is :).
I did find a conversation back in October about 0.9.2 which will likely include some new technology called TCG that will eliminate qemu's dependency on the gcc 3.x compiler. That's good news since I want to release Wascana 1.0 with the gcc 4.x compiler and I want to use Wascana 1.0 as the base IDE for my EcilpseCon tutorial on working with cross-development environments. I hope it all comes together by March.
Speaking of which, only 11 more days until submissions close for EclipseCon. Get them in early and get them in often. And soon!
I was looking to see when qemu, a very cool virtual machine for many hosts and many target CPU architectures, was going to come out with a new release. As part of that, I was checking to see if it was under active development. Well, with 55 e-mails on November 13'th when I looked, I guess it is :).
I did find a conversation back in October about 0.9.2 which will likely include some new technology called TCG that will eliminate qemu's dependency on the gcc 3.x compiler. That's good news since I want to release Wascana 1.0 with the gcc 4.x compiler and I want to use Wascana 1.0 as the base IDE for my EcilpseCon tutorial on working with cross-development environments. I hope it all comes together by March.
Speaking of which, only 11 more days until submissions close for EclipseCon. Get them in early and get them in often. And soon!
Wednesday, November 12, 2008
Now that's small.
Just ran into this article on LinuxDevices.com. It talks about a tiny computer that looks like this:
That's all there is to it. This ethernet jack has an ARM9 processor in it with 8 MB RAM, 4 MB Flash, and some interfaces that you can hook up electronic devices to. The idea is to add network connectivity to devices that normally don't, like air conditioners and stuff. Apparently there's even a WiFi version of the thing.
I found a couple of neat things about this device. First it gives you network access to pretty much anything allowing for centralized controllers to manage those things. This is probably old news to guys who work on building maintenance automation systems and stuff like that. But this device somehow made it all real for me.
The other thing to note is the memory size here. 4 MB Flash for the file system isn't very big. And neither is the 8MB RAM you run with. If anyone ever asks if C is still important, I'll just point to this thing.
And finally, I had to have a chuckle when I saw this: "the kit includes an IDE based on Eclipse 3.1.2 and CDT 3.0.2. It supports C/C++ devlopment, CVS code management, and visual debugging via Ethernet." Yet another vendor using the CDT to build cool things :).
That's all there is to it. This ethernet jack has an ARM9 processor in it with 8 MB RAM, 4 MB Flash, and some interfaces that you can hook up electronic devices to. The idea is to add network connectivity to devices that normally don't, like air conditioners and stuff. Apparently there's even a WiFi version of the thing.
I found a couple of neat things about this device. First it gives you network access to pretty much anything allowing for centralized controllers to manage those things. This is probably old news to guys who work on building maintenance automation systems and stuff like that. But this device somehow made it all real for me.
The other thing to note is the memory size here. 4 MB Flash for the file system isn't very big. And neither is the 8MB RAM you run with. If anyone ever asks if C is still important, I'll just point to this thing.
And finally, I had to have a chuckle when I saw this: "the kit includes an IDE based on Eclipse 3.1.2 and CDT 3.0.2. It supports C/C++ devlopment, CVS code management, and visual debugging via Ethernet." Yet another vendor using the CDT to build cool things :).
Tuesday, November 11, 2008
Design like you'll be there in 10 years
I probably blogged about this a long time ago. I remember watching the news conference for the landing of the Mars Spirit rover. I had watched the landing live over the web and remember the jubilation of the team members as they received the first signal alerting to the safe landing. At the news conference one of the project managers mentioned he had been working on the project for 10 years (through one previous cancellation that is, but still pretty darn good). He was beaming to see the success. And it was well deserved.
That idea entered into my book of software design philosophy: design like you'll be working on the project for 10 years. Think of the responsibility that would mean. In 10 years, you'll be paying for the short cuts and short sightedness. So don't.
Well preparing for my talk on static analysis and refactoring for Eclipse Summit Europe next week (yeah a bit of a late start, it'll be great, though), I finally have my own version of this story to tell.
6 years ago, my good colleague and friend, John and I started down the road of building a C++ parser for the CDT. My mentor at the time thought it was a crazy idea but we had a feeling that we could do it and we plowed ahead and actually got it to work. The parser allowed us to build a more accurate way of populating the Outline View (via the CModel). It then lead the way to indexing to allow for C/C++ Search and Open Declaration to work well. It was tough and we fought the performance battles for most of it, but we soldiered on.
Somewhere along the way we started dreaming of C/C++ refactoring a la JDT. Everyone thought that was a crazy idea (despite secretly wanting it too). With all the madness of the C preprocessor mucking with the source code before it gets to the parser, how could you properly create the TextEdits that the LTK (which the JDT guys generously pushed into a common plug-in, BTW), needed to do the refactoring?
Well John put in a lot of effort and forethought and created a way to map AST nodes to location objects which allowed you to unravel where all the text came from to create the node. It wasn't perfect, but it was a start. And unfortunately due to the untimely end of our funding, we never got to finish it.
Well, I finally got a deep look at the work that Emanuel and is team at the HSR Hochschule für Technik Rapperswil have done on the CDT refactoring engine and early refactorings. Following it through the debugger, I hit it, IASTNodeLocation - that work that John had started years ago but never got to see in action for what it was intended for. It's been fixed up by Emanuel and CDT Indexer Master Markus, but it was doing what we had dreamed about many years ago. Weird, but it actually brought a tear to my eye.
But it really does prove the point. Design as if you'll be working on a project for 10 years. Even if you end up not being there, someone will be, and your work will live on, and it will be much appreciated.
That idea entered into my book of software design philosophy: design like you'll be working on the project for 10 years. Think of the responsibility that would mean. In 10 years, you'll be paying for the short cuts and short sightedness. So don't.
Well preparing for my talk on static analysis and refactoring for Eclipse Summit Europe next week (yeah a bit of a late start, it'll be great, though), I finally have my own version of this story to tell.
6 years ago, my good colleague and friend, John and I started down the road of building a C++ parser for the CDT. My mentor at the time thought it was a crazy idea but we had a feeling that we could do it and we plowed ahead and actually got it to work. The parser allowed us to build a more accurate way of populating the Outline View (via the CModel). It then lead the way to indexing to allow for C/C++ Search and Open Declaration to work well. It was tough and we fought the performance battles for most of it, but we soldiered on.
Somewhere along the way we started dreaming of C/C++ refactoring a la JDT. Everyone thought that was a crazy idea (despite secretly wanting it too). With all the madness of the C preprocessor mucking with the source code before it gets to the parser, how could you properly create the TextEdits that the LTK (which the JDT guys generously pushed into a common plug-in, BTW), needed to do the refactoring?
Well John put in a lot of effort and forethought and created a way to map AST nodes to location objects which allowed you to unravel where all the text came from to create the node. It wasn't perfect, but it was a start. And unfortunately due to the untimely end of our funding, we never got to finish it.
Well, I finally got a deep look at the work that Emanuel and is team at the HSR Hochschule für Technik Rapperswil have done on the CDT refactoring engine and early refactorings. Following it through the debugger, I hit it, IASTNodeLocation - that work that John had started years ago but never got to see in action for what it was intended for. It's been fixed up by Emanuel and CDT Indexer Master Markus, but it was doing what we had dreamed about many years ago. Weird, but it actually brought a tear to my eye.
But it really does prove the point. Design as if you'll be working on a project for 10 years. Even if you end up not being there, someone will be, and your work will live on, and it will be much appreciated.
Friday, November 07, 2008
Cross Compiling Fun for EclipseCon
It's been a busy couple of weeks for me as we get our commercial Eclipse p2-based installer into product testing. It's looking good but there's always those last minute fires (i.e. bugs) to fight.
In the background I've been trying to set up an environment that will allow me to use the CDT to build Linux applications from my Windows box, and then run and debug those applications on a customized version of the Qemu emulator that is also built using the CDT. Once I get this environment together, I plan on presenting how to do it at EclipseCon as either a tutorial or long talk. It's a great demonstration on how well the CDT works for multi-platform development.
My first step was to put together a cross compiler. The gcc compiler suite is great at it, but it's not obvious how to do it on Windows. Most GNU packages are hard to build on Windows, even with the MSYS environment from the MinGW gang, or Cygwin.
I first tried with MSYS. I copied over the C library headers and libraries and then tried to build binutils to get the assembler and linker, and gcc itself for C and C++. I was generally following the instructions here. I got really close, but unfortunately I ended up with a linker error when creating the gcc compiler support library (libgcc). Grrr.
Thinking about my reference article a little more, I remembered that even the MinGW developers build MinGW on Linux. I then discovered that the Linux distribution I am using (Debian lenny) already has the MinGW cross-compiler and libraries as a package. So I installed that and I suddenly had the ability to build Windows executables on Linux. So given that, I built binutils and gcc on Linux so that it would run on Windows to build executables for Linux. Wow. That's quite a few levels of indirection. But it worked!
Now all I need to do is build a CDT integration that puts the i686-linux-gnu- prefix on gcc and puts the location of the tools in the PATH and I'm ready to build Linux apps from my Windows laptop.
I'm looking forward to showing this off at EclipseCon. It's talks like this that show practical uses of the CDT and extensions people can build for it that we really need to highlight to the community at EclipseCon. Mine is only one, we need a few more. So if you have an idea, feel free to go to the EclipseCon site and submit a proposal.
In the background I've been trying to set up an environment that will allow me to use the CDT to build Linux applications from my Windows box, and then run and debug those applications on a customized version of the Qemu emulator that is also built using the CDT. Once I get this environment together, I plan on presenting how to do it at EclipseCon as either a tutorial or long talk. It's a great demonstration on how well the CDT works for multi-platform development.
My first step was to put together a cross compiler. The gcc compiler suite is great at it, but it's not obvious how to do it on Windows. Most GNU packages are hard to build on Windows, even with the MSYS environment from the MinGW gang, or Cygwin.
I first tried with MSYS. I copied over the C library headers and libraries and then tried to build binutils to get the assembler and linker, and gcc itself for C and C++. I was generally following the instructions here. I got really close, but unfortunately I ended up with a linker error when creating the gcc compiler support library (libgcc). Grrr.
Thinking about my reference article a little more, I remembered that even the MinGW developers build MinGW on Linux. I then discovered that the Linux distribution I am using (Debian lenny) already has the MinGW cross-compiler and libraries as a package. So I installed that and I suddenly had the ability to build Windows executables on Linux. So given that, I built binutils and gcc on Linux so that it would run on Windows to build executables for Linux. Wow. That's quite a few levels of indirection. But it worked!
Now all I need to do is build a CDT integration that puts the i686-linux-gnu- prefix on gcc and puts the location of the tools in the PATH and I'm ready to build Linux apps from my Windows laptop.
I'm looking forward to showing this off at EclipseCon. It's talks like this that show practical uses of the CDT and extensions people can build for it that we really need to highlight to the community at EclipseCon. Mine is only one, we need a few more. So if you have an idea, feel free to go to the EclipseCon site and submit a proposal.
Subscribe to:
Posts (Atom)