I hope the folks at freedesktop.org don't mind all the traffic that davidr is causing, but anyone interested in the future of the Linux desktop have got to see this.
I have to admit that a lot of what he shows is eye candy, but to me the idea is to make the things on the desktop seem more real. This could ease the paradigm shift that happens between the real world and your computer screen, thus hopefully making people more productive. I'd have to try it out for real to be more sure and I can't wait! I just hope I don't need a Cray and a quad SLI to get the same effects shown in the demo :).
Demo video here.
So what is the CDT angle on all this? Well, one of the earliest uses we saw for the CDT was as a core development environment for Linux C/C++ apps. If something like Xgl can cause the demand for Linux to grow, we should see more Linux developers using the CDT, probably including former Windows developers who will be expecting a Visual Studio equivalent.
Tuesday, February 28, 2006
Wednesday, February 15, 2006
A Cool Eclipse CDT for Embedded Tutorial
I often hear the remark that the CDT isn't good for embedded development. I always find that odd since the majority of the contributors and commercial consumers of the CDT are embedded tools vendors and the CDT actually sprouted out from one such tool. Mind you there are a few things that the commercial vendors add to make things like board bring up and target management easier but these aren't huge additions.
But having been in the tools business for over a decade now, I find it much easier to sell such ideas if there is a grassroots movement that is driven by real users' needs. That's when I was thrilled when Wayne Beaton passed on a proposed Eclipse article based on a turorial on that very subject. The tutorial is written by James Lynch who has given me permission to pass it on to you. You can see the tutorial here. The objective of it is to show that you can do embedded development on an inexpensive environment for people who want to play and learn about the embedded world. Mission accomplied I'd say!
The tutorial walks the reader through how to set up their Eclipse environment and other tools including a special embedded version of the CDT that our friend Øyvind at Zylin Consulting has put together. He then shows how to code up an small image that strobes an LED on the board and how to build the image, download it using JTAG and debug it over a serial port. It's a very cool illustration of our point that "Eclipse is not just for Java".
Now, I'll need to take a look at the changes that Øyvind has made in his version of the CDT and see why we couldn't make them available in the base CDT. That would make it even easier for everyone who wants to try it out.
But having been in the tools business for over a decade now, I find it much easier to sell such ideas if there is a grassroots movement that is driven by real users' needs. That's when I was thrilled when Wayne Beaton passed on a proposed Eclipse article based on a turorial on that very subject. The tutorial is written by James Lynch who has given me permission to pass it on to you. You can see the tutorial here. The objective of it is to show that you can do embedded development on an inexpensive environment for people who want to play and learn about the embedded world. Mission accomplied I'd say!
The tutorial walks the reader through how to set up their Eclipse environment and other tools including a special embedded version of the CDT that our friend Øyvind at Zylin Consulting has put together. He then shows how to code up an small image that strobes an LED on the board and how to build the image, download it using JTAG and debug it over a serial port. It's a very cool illustration of our point that "Eclipse is not just for Java".
Now, I'll need to take a look at the changes that Øyvind has made in his version of the CDT and see why we couldn't make them available in the base CDT. That would make it even easier for everyone who wants to try it out.
Wednesday, February 08, 2006
Xgl - Desktop Linux's Savior?
I've followed the Linux on the Desktop thing for quite a while. At one point I had one of the distributions installed on my laptop and swore that there was nothing that I needed out of Windows that Linux didn't provide for me. And for the most part that was true, except for my corporate e-mail client, which I ended up running in a vmware session.
I trotted along with that for a while, but after a couple of months, I went back to Windows in frustration. Despite the promise of Desktop Linux, it just felt sluggish and blurry when compared to my Windows boxen. When working with reams of code in Eclipse, the desktop experience is critical to my productivity. And unfortunately, I'm just more productive in Windows that I was in Linux, which is too bad since I really prefer Linux for software development. I just seems to give me more control over my execution environment.
And then one day a Mac G5 landed in my office. There wasn't much installed on it so I didn't have much use for it, but the desktop environment sure looked cool. After a little investigation I found out that at the base of it all was OpenGL. The promise of using OpenGL, or 3D acceleration in general, for desktop environments had really peaked my interest. With the pending arrival of Microsoft Vista, I think we'll soon realize how clunky the ole' 2D desktops really are.
So if Mac OS X can do a 3D desktop on a *nix base, why can't Linux. That's when a few google searches brought me to the Xgl project going on in and around X.org. Xgl is an implementation of an X server on OpenGL, assuming I understand the documentation correctly. The progress on Xgl has been slow and I kind of lost track of it's progress until an article appeared on ZDNet the other day. I'm still not sure it's moving at a pace where we'll see it common place anytime soon, but with the backing of Novell, who hired the developer of Xgl, my hope has returned, at least a little bit.
I love Linux for software development and, if I had the right desktop experience and I had access to all the apps I needed to be super productive in my job, I'd switch again in an instant. Here's hoping that the Linux community sees the potential of Xgl and works on finishing it and bringing it into my favorite Linux distribution sometime soon.
I trotted along with that for a while, but after a couple of months, I went back to Windows in frustration. Despite the promise of Desktop Linux, it just felt sluggish and blurry when compared to my Windows boxen. When working with reams of code in Eclipse, the desktop experience is critical to my productivity. And unfortunately, I'm just more productive in Windows that I was in Linux, which is too bad since I really prefer Linux for software development. I just seems to give me more control over my execution environment.
And then one day a Mac G5 landed in my office. There wasn't much installed on it so I didn't have much use for it, but the desktop environment sure looked cool. After a little investigation I found out that at the base of it all was OpenGL. The promise of using OpenGL, or 3D acceleration in general, for desktop environments had really peaked my interest. With the pending arrival of Microsoft Vista, I think we'll soon realize how clunky the ole' 2D desktops really are.
So if Mac OS X can do a 3D desktop on a *nix base, why can't Linux. That's when a few google searches brought me to the Xgl project going on in and around X.org. Xgl is an implementation of an X server on OpenGL, assuming I understand the documentation correctly. The progress on Xgl has been slow and I kind of lost track of it's progress until an article appeared on ZDNet the other day. I'm still not sure it's moving at a pace where we'll see it common place anytime soon, but with the backing of Novell, who hired the developer of Xgl, my hope has returned, at least a little bit.
I love Linux for software development and, if I had the right desktop experience and I had access to all the apps I needed to be super productive in my job, I'd switch again in an instant. Here's hoping that the Linux community sees the potential of Xgl and works on finishing it and bringing it into my favorite Linux distribution sometime soon.
Update: Here's the news release from Novell. Includes some cool movies showing off a demo of Xgl's advanced capabilities.
Thursday, February 02, 2006
SystemC - two worlds collide
I used to sit across the cubicle wall from an ASIC designer back in the mid 90's. He was pretty friendly and was very interested in the future of software engineering, especially software modeling. I guess that makes sense since, as an ASIC designer, modeling hardware was second nature and he figured it should be the same for software.
That got me interested in what they were using to model hardware. He was using Verilog, one of the big two hardware description languages, VHDL being the other. I was starting to use ObjecTime, a graphical software modeling tool that I ended up helping build, and he found it very odd that we were moving into graphical modeling where the hardware guys were abandoning it for textual modeling.
Looking back now, I'm thinking he may have been on to something. I still think visual modeling has a long way to go before it becomes mainstream with every day developers, and even longer for modeling behavior. Maybe we're suckers for punishment and prefer to deal with reams of text, or maybe the tools aren't up to snuff yet for visual modeling (and I'm still holding out hope that GMF will get us much closer).
That's when I ran across SystemC yesterday, I had a famous Ward Cunningham "a-ha moment". Here's a system description language that software guys would love. It uses the power of C++'s type system and a small run-time to model the concurrency and timing of real-world systems. What a great mix of the two worlds with hardware and software guys working on the same code. I am just starting to scratch the surface of the potential of SystemC, but it's one of those technologies that I end up losing sleep over wondering about the possibilities. I'll write more on it once I do a bit more research and I'd love to hear peoples' opinions on it.
However, the important thing I am taking from SystemC has nothing to do with systems modeling. At the back of my mind is a new programming paradigm that was sparked when I first looked at UML action semantics. Hardware is inherently a huge collection of concurrent processes, which BTW is also a key feature that SystemC emulates. This concurrency is the reason why many algorithms are much faster to implement in hardware. Why can't software be that way? And with the new revolution of multi-core processing, will our current von Neumann paradigm scale to hundreds of concurrent threads? Maybe there's something we can take away from SystemC that we can use to build massively concurrent programs in C++. I sense another "a-ha moment" coming, or at least another few more late nights...
That got me interested in what they were using to model hardware. He was using Verilog, one of the big two hardware description languages, VHDL being the other. I was starting to use ObjecTime, a graphical software modeling tool that I ended up helping build, and he found it very odd that we were moving into graphical modeling where the hardware guys were abandoning it for textual modeling.
Looking back now, I'm thinking he may have been on to something. I still think visual modeling has a long way to go before it becomes mainstream with every day developers, and even longer for modeling behavior. Maybe we're suckers for punishment and prefer to deal with reams of text, or maybe the tools aren't up to snuff yet for visual modeling (and I'm still holding out hope that GMF will get us much closer).
That's when I ran across SystemC yesterday, I had a famous Ward Cunningham "a-ha moment". Here's a system description language that software guys would love. It uses the power of C++'s type system and a small run-time to model the concurrency and timing of real-world systems. What a great mix of the two worlds with hardware and software guys working on the same code. I am just starting to scratch the surface of the potential of SystemC, but it's one of those technologies that I end up losing sleep over wondering about the possibilities. I'll write more on it once I do a bit more research and I'd love to hear peoples' opinions on it.
However, the important thing I am taking from SystemC has nothing to do with systems modeling. At the back of my mind is a new programming paradigm that was sparked when I first looked at UML action semantics. Hardware is inherently a huge collection of concurrent processes, which BTW is also a key feature that SystemC emulates. This concurrency is the reason why many algorithms are much faster to implement in hardware. Why can't software be that way? And with the new revolution of multi-core processing, will our current von Neumann paradigm scale to hundreds of concurrent threads? Maybe there's something we can take away from SystemC that we can use to build massively concurrent programs in C++. I sense another "a-ha moment" coming, or at least another few more late nights...
Tuesday, January 31, 2006
LAMP & AJAX - The TSN Turning Point
If you were at EclipseCon last year, you may have seen the demo I gave of IBM's Rational Application Developer to build a Web app that monitored a C++ app. I used gsoap to present a web service that monitored some value. I thought this was pretty cool way to web enabling C/C++ apps and maybe bring these apps into the Internet mainstream.
Mind you, I kind of ignored the size impact that the gsoap libraries presented and the added complexity of having to figure out how to define my web service (WSDL is not for the meek and RAD helped me a ton). In the end, it was probably overkill when all I wanted to do provide access to some status data to apps on the web.
Recently I have become curious about all the hype behind AJAX and LAMP. While browsing through some tutorials on XMLHttpRequest, it struck me. Well, all this really is is a remote procedure call back to the server, the same thing I was trying to do with SOAP. The URL is simply the name of the function you want to call and the GET/POST parameters are the arguments. Could web enabling my C/C++ app be a simple as handling http requests and providing the properly formatted http responses? I'm on a mission to find out.
While I'm sure SOAP has it's purpose in the big SOA scheme of things, I am always cautious about oversolving the problem. Time will tell how big an impact AJAX and LAMP will have on the industry, but I've always found that the most successful architectures are the ones that are the easiest to learn and supported by free tools. With the recent announcements of Eclipse projects that address AJAX and PHP development and all the web presence these technologies have, they've definitely caught my attention.
(BTW, TSN is one of Canada's two main sports networks. Every game, no matter what the sport, they pick a moment that they think decided it for the winner, the TSN Turning Point).
Mind you, I kind of ignored the size impact that the gsoap libraries presented and the added complexity of having to figure out how to define my web service (WSDL is not for the meek and RAD helped me a ton). In the end, it was probably overkill when all I wanted to do provide access to some status data to apps on the web.
Recently I have become curious about all the hype behind AJAX and LAMP. While browsing through some tutorials on XMLHttpRequest, it struck me. Well, all this really is is a remote procedure call back to the server, the same thing I was trying to do with SOAP. The URL is simply the name of the function you want to call and the GET/POST parameters are the arguments. Could web enabling my C/C++ app be a simple as handling http requests and providing the properly formatted http responses? I'm on a mission to find out.
While I'm sure SOAP has it's purpose in the big SOA scheme of things, I am always cautious about oversolving the problem. Time will tell how big an impact AJAX and LAMP will have on the industry, but I've always found that the most successful architectures are the ones that are the easiest to learn and supported by free tools. With the recent announcements of Eclipse projects that address AJAX and PHP development and all the web presence these technologies have, they've definitely caught my attention.
(BTW, TSN is one of Canada's two main sports networks. Every game, no matter what the sport, they pick a moment that they think decided it for the winner, the TSN Turning Point).
Tuesday, January 10, 2006
December CDT Download Stats
I noticed the AspectJ guys posted their numbers, so I thought I'd go out and get the CDT's. For December we had 66,000 downloads. I think that's a healthy number, and enough for Webmaster to ask that we tell them when we are going to do our next release so that they can plan for the extra bandwidth that would be required.
Another interesting data point is the platforms that get downloaded. We are consistently showing the same numbers:
Another interesting data point is the platforms that get downloaded. We are consistently showing the same numbers:
- 64% Windows
- 30% Linux x86
- 3% Mac OS X
- 2% Linux x86_64
- 1% Solaris sparc
- less than 1% other
I find this most interesting since we really only support GNU on Windows so these people must be students or hobbyist, or my assumption is wrong and that you actually can do commercial development using MinGW or cygwin. I'd be interested in hearing what CDT users are building on Windows.
Sunday, January 08, 2006
.Net Framework SDK 2.0
So I've started getting interesting in C# again after initially looking at it when it first came out. It looks to me like a better Java than Java, although Java is starting to catch up with Java 1.5. And with support from the Novell lead Mono project, it has the potential to become another serious cross platform solution.
Looking inside the .Net Framework SDK 2.0, I notice that it includes Microsoft's C++ compiler. I was wondering if Microsoft was going to update their Visual C++ Toolkit, the free version of their VS2003 compiler. It appears that this is it, although I haven't seen it advertised as such.
Today the CDT has a lot of credibility for embedded development and on Linux. It is a little weak on Windows, despite that platform accounting for 2/3's of CDT downloads. Most of this, I assume, is by students and people kicking the tires where MinGW/cygwin is sufficient for them. Supporting a commercial quality compiler and full Windows development would definitely be a boost to the CDT's popularity there. All you need is the .Net and Platform SDKs, and DirectX SDK if you want to make games, and you'd be good to go.
Also, by adding some focus on .Net, we can look at C# as a potential addition to the languages that the CDT supports. For those who haven't heard, work is being done by the Fortran community through the Photran project to add Fortran support to the CDT. I have a feeling that C# be able to reuse more of the CDT than Photran does, especially the editor, since C# is more C-like. And it is more likely to be used than the Ada support I was thinking of adding.
As with everything open source, we'll have to see if there is anyone interested enough to work on this, but it would sure benefit the CDT's popularity.
Looking inside the .Net Framework SDK 2.0, I notice that it includes Microsoft's C++ compiler. I was wondering if Microsoft was going to update their Visual C++ Toolkit, the free version of their VS2003 compiler. It appears that this is it, although I haven't seen it advertised as such.
Today the CDT has a lot of credibility for embedded development and on Linux. It is a little weak on Windows, despite that platform accounting for 2/3's of CDT downloads. Most of this, I assume, is by students and people kicking the tires where MinGW/cygwin is sufficient for them. Supporting a commercial quality compiler and full Windows development would definitely be a boost to the CDT's popularity there. All you need is the .Net and Platform SDKs, and DirectX SDK if you want to make games, and you'd be good to go.
Also, by adding some focus on .Net, we can look at C# as a potential addition to the languages that the CDT supports. For those who haven't heard, work is being done by the Fortran community through the Photran project to add Fortran support to the CDT. I have a feeling that C# be able to reuse more of the CDT than Photran does, especially the editor, since C# is more C-like. And it is more likely to be used than the Ada support I was thinking of adding.
As with everything open source, we'll have to see if there is anyone interested enough to work on this, but it would sure benefit the CDT's popularity.
Tuesday, January 03, 2006
C++0x
Just when you thought the evolution of C++ was over, I spotted the following article discussed on Slashdot. It is from Bjarne Stroustrup, Mr. C++ himself, who I affectionately refer to as Barney (whether it has anything to do with a cuddly purple dinosaur taking care of my favorite programming language, I'll let my psychiatrist figure out). You can get the article here.
In the article, Bjarne discusses proposals to improve generic programming in C++ as well as additional libraries to fill out the offering of STL (things like even more generic containers and our beloved hash maps). The plan is to get this all together for standardization in 2009.
The part I found most interesting, being an open source project lead, is the fact that the C++ standards committee is also volunteer driven and their biggest challenge will be to get something together that is really enticing with the resources they have. Hopefully, the publicity will help.
In the article, Bjarne discusses proposals to improve generic programming in C++ as well as additional libraries to fill out the offering of STL (things like even more generic containers and our beloved hash maps). The plan is to get this all together for standardization in 2009.
The part I found most interesting, being an open source project lead, is the fact that the C++ standards committee is also volunteer driven and their biggest challenge will be to get something together that is really enticing with the resources they have. Hopefully, the publicity will help.
Thursday, December 08, 2005
Eclipse for Digital Content Creation?
At my first EclipseCon a couple of years ago, Sebastien Marineau and I met someone from the Sony Playstation development tools group. They apparently were interested in the CDT as a development environment. We're not sure what for and they didn't follow up, at least with me anyway. But we do see some bugs raised in bugzilla coming from playstation.sony.com.
That meeting got me thinking. Obviously most of game development, at least for PCs and the consoles, is done in C and C++. Using the CDT makes tons of sense in that environment. I even got an e-mail from someone in id Software, the DOOM people, who had some issues using the CDT (indexer performance, of course, what else?), but at least they had thought using the CDT would be a good idea.
So I looked around at how game development was done and gave some of the open source game engines a try, Ogre in particular. I was able to go through the tutorials and build a very simple game application using the CDT and importing all of the graphics files that were needed. I was able to bring the application up under the debugger and check up on things. It was fun and I wish that I had more time to play with game development and get something real working.
During my investigation, I ran accross shaders, which are little assembly language programs used to program graphic chips directly. Both nVidia and Microsoft have defined specialized programming languages that allow these shaders to be built using C-like languages. Of course, that pinged the parser dude in me and made me wonder if we could leverage the multi-language nature of the CDT to support writing these shaders. Of course, my real job prevented me from spending any time prototyping this out.
Then I took it one step further. What are all the artifacts that go into games. Not only is there C and C++ code and shader code, there are 3d models and 2d textures. My thinking is that it would be a pretty cool environment if we could bring editors for graphics and project management/build together under the Eclipse umbrella. The stuff we are seeing with OpenGL support in SWT makes this even easier. The only question that comes to mind is whether Java is the right language for this, but after trying out the snippets provided by the SWT gang, performance wasn't all that bad. So I really think building a complete game development environment using Eclipse and the CDT makes a ton of sense. All it takes is someone with enough interest and resources to start up a project to make it happen. And it would be very cool for Eclipse's image.
Then, why stop at game development. I thought about an old aquaintance at the University of Saskatchewan who went on to work at Pixar. Obviously they do 3d modeling there as well, so I went to their web site to look at what they were all about. To my surprise, it turns out that these guys were some of the first to use shaders. They have their own programming language for defining shaders for various things, much more than graphics boards support but very similar. And they have a super powerful rendering engine that puts it all together to make movies. I don't think it's a stretch to take a game development environment built on Eclipse and turn it into a digital movie production environment. Makes you go hmmm, no?
That meeting got me thinking. Obviously most of game development, at least for PCs and the consoles, is done in C and C++. Using the CDT makes tons of sense in that environment. I even got an e-mail from someone in id Software, the DOOM people, who had some issues using the CDT (indexer performance, of course, what else?), but at least they had thought using the CDT would be a good idea.
So I looked around at how game development was done and gave some of the open source game engines a try, Ogre in particular. I was able to go through the tutorials and build a very simple game application using the CDT and importing all of the graphics files that were needed. I was able to bring the application up under the debugger and check up on things. It was fun and I wish that I had more time to play with game development and get something real working.
During my investigation, I ran accross shaders, which are little assembly language programs used to program graphic chips directly. Both nVidia and Microsoft have defined specialized programming languages that allow these shaders to be built using C-like languages. Of course, that pinged the parser dude in me and made me wonder if we could leverage the multi-language nature of the CDT to support writing these shaders. Of course, my real job prevented me from spending any time prototyping this out.
Then I took it one step further. What are all the artifacts that go into games. Not only is there C and C++ code and shader code, there are 3d models and 2d textures. My thinking is that it would be a pretty cool environment if we could bring editors for graphics and project management/build together under the Eclipse umbrella. The stuff we are seeing with OpenGL support in SWT makes this even easier. The only question that comes to mind is whether Java is the right language for this, but after trying out the snippets provided by the SWT gang, performance wasn't all that bad. So I really think building a complete game development environment using Eclipse and the CDT makes a ton of sense. All it takes is someone with enough interest and resources to start up a project to make it happen. And it would be very cool for Eclipse's image.
Then, why stop at game development. I thought about an old aquaintance at the University of Saskatchewan who went on to work at Pixar. Obviously they do 3d modeling there as well, so I went to their web site to look at what they were all about. To my surprise, it turns out that these guys were some of the first to use shaders. They have their own programming language for defining shaders for various things, much more than graphics boards support but very similar. And they have a super powerful rendering engine that puts it all together to make movies. I don't think it's a stretch to take a game development environment built on Eclipse and turn it into a digital movie production environment. Makes you go hmmm, no?
Saturday, December 03, 2005
Welcome to my Blog
Mike Milinkovich recommended I get my own blog and start jotting down my thoughts. A brilliant man he is so I decided to finally follow up on it.
I've been the project lead for the CDT for a couple of months now but have really been heavily involved in the CDT since it was started at Eclipse, at least the QNX version, back in the summer of 2002. Back then I worked for Rational and we were looking for an Eclipse-based solution to support our C++ modeling products for markets that weren't using Visual Studio, of which of course there are many. Our needs were C++ parsing and code models for our translation frameworks. I've always been interested in programming languages and parsing so I couldn't pass up the opportunity when it floated by me in the hall one day and am very glad I did.
I've dedicated this segment of my career to the CDT, enough so that I made the move to QNX to allow me to continue my work on it and to do what ever I can to ensure it's success as an industry leading C/C++ IDE. We're getting close and I can see the point now where we will have what it takes get there and that drives me even more.
I am looking forward to sharing my thoughts here on the state of the industry, my passion for Eclipse and the community and ecosystem that drives it, and maybe some of the vision that I have on where the tools industry can go to help ensure the success of the software developers everywhere.
We've talked so much in the past about the crisis we have faced in software development as projects failed more often than they were successful. I think that tide has turned as the tools and frameworks that developers have at their fingertips today have allowed them to make smarter decisions and to react in a crisus fast enought to recover. I embrace the time when we have to try and think back to remember what all the fuss was about.
Stay tuned for more...
I've been the project lead for the CDT for a couple of months now but have really been heavily involved in the CDT since it was started at Eclipse, at least the QNX version, back in the summer of 2002. Back then I worked for Rational and we were looking for an Eclipse-based solution to support our C++ modeling products for markets that weren't using Visual Studio, of which of course there are many. Our needs were C++ parsing and code models for our translation frameworks. I've always been interested in programming languages and parsing so I couldn't pass up the opportunity when it floated by me in the hall one day and am very glad I did.
I've dedicated this segment of my career to the CDT, enough so that I made the move to QNX to allow me to continue my work on it and to do what ever I can to ensure it's success as an industry leading C/C++ IDE. We're getting close and I can see the point now where we will have what it takes get there and that drives me even more.
I am looking forward to sharing my thoughts here on the state of the industry, my passion for Eclipse and the community and ecosystem that drives it, and maybe some of the vision that I have on where the tools industry can go to help ensure the success of the software developers everywhere.
We've talked so much in the past about the crisis we have faced in software development as projects failed more often than they were successful. I think that tide has turned as the tools and frameworks that developers have at their fingertips today have allowed them to make smarter decisions and to react in a crisus fast enought to recover. I embrace the time when we have to try and think back to remember what all the fuss was about.
Stay tuned for more...
Subscribe to:
Posts (Atom)