Monthly Archives: August 2009

Time to break down the Silos between the *DT’s?

What started out as a personal need for writing and debugging JNI-based applications, both based on Eclipse and for Android, has turned into something bigger, a lot bigger. The hardest problem we face for what I’m doing is supporting multiple debugger technologies in the same debug session and ensuring a nice seamless experience. Showing both Java and C/C++ stacks merged together and stepping back and forth between them would be the cat’s meow.

As I’m starting to hear from the greater Eclipse community, there is need for cross language/cross technology debugging in other areas as well. One example is Rhino which is being used by the e4 team to support writing plugins in JavaScript. Having a debug session with JavaScript and Java in the same stack would also be awesome. Similarly, we have JavaScript or ActionScript running in the browser interacting with a Equinox server, or maybe PHP running in Apache. Web applications are the manifestation of distributed applications and, as promised, those applications tend to involve multiple languages.

Traditionally, the language tooling projects at Eclipse have lived in silos. The CDT team has have very little interaction with the JDT team, for example. And that’s not generally the fault of the team members. It’s just a symptom of the lack of investment in Eclipse towards common technologies. Being an engineer, I have no idea how to solve that except to ineffectively whine about it. πŸ˜‰

But one objective we’ve had with the CDT was to ensure that the C wasn’t just for C/C++. Many of our frameworks are language independent as much as we practically could. We haven’t had enough investment to be able to push that out to the general Eclipse community, but we do have projects like Photran (Fortran) and the fledgling Hibachi (Ada) and the new but remote ObjectivEclipse (Objective-C) doing that.

I think in particular, our new debug framework, DSF, could be used for much more than C and related languages. DSF started out as a solution for the difficult debug environments we face in the embedded space and actually started as the Device Debug project of DSDP. We’ve migrated it down into the CDT in 6.0. We’ve often quipped that it really should be down in the Eclipse platform itself. There will be challenges, technically and otherwise, to make that happen.

What I want to do is start prototyping multi-language, multi-debugger debug sessions based on DSF. That would initially include Java and C/C++. I’ll also take a peak at JavaScript debugging and consider how that impacts it. I’m confident the flexibility we brought with DSF can be leveraged to make the Eclipse side of this relatively straightforward. The bigger challenge will be co-ordinating the different debuggers.

If others are interested in this work, we should co-ordinate our efforts. Let me know and we could set up a mailing list to talk about this area, and hopefully we can start breaking down the silos.

Using Git GUI with Eclipse

Here’s my next set of screencasts showing how I use git and git gui in particular with my Eclipse projects. There are two parts. The first shows how to set up a workspace based on a git clone repository, i.e. copying a remote repository to your local machine and setting up an Eclipse workspace for that repository. The second part is how I commit and push my changes to the remote server as I develop code. Hope this is useful.

BTW, This is best viewed by clicking on the YouTube link and watching it full screen in HD mode.

Part 1 – Creating your Workspace

Link to YouTube

Part 2 – Committing and pushing a code change

Link to YouTube

The JNI Debug Problem

One thing I noticed the other day was that I’m doing a lot of JNI coding lately. In our Wind River Installer, based on p2 BTW, I have native code for doing a few things like compression and getting at the Windows registry. The CDT has native code for doing advanced process management, and getting at the Windows registry. I’ve played with Android native development which is all based on JNI. And I was thinking of hooking up the ALSA library to do Audio management with my prototype “Eclipse OS”. That’s a lot of Java/C coding. And, unfortunately, all without a debug solution :(.

JNI debugging was one of the early goals of the CDT. Unfortunately, it has never really materialized, at least not generically in a way we could incorporate into Eclipse. And given that I see a strong symbiotic relationship between Java and C/C++, I am getting more motivated to tackle this problem and see if we couldn’t come up with a solution that we can integrate into the JDT and CDT (or maybe just the CDT).

But the first thing you run into when looking at the code, where do you start? I’d like to be able to step into native methods, hit breakpoints in native code and see up the stack all the way into the Java stack. And really have an integrated debug experience where you don’t have to do much of a paradigm shift when going between the two worlds. And given the way the Debug platform is structured, that should be possible.

So there’s different ways to slice the cat (not that I slice cats, I like cats). You could add an extension point to be able to plug in native handling into the JDT debugger. I’m not sure what the JDT gang feel of that, or whether they’ve hopefully thought of that. Another solution would be to build a new Eclipse Java debugger component, but base it on CDT’s Debug Services Framework. That may make a more natural solution, but I fear it would be a lot of work and it would take a lot of investment to reach parity with JDT’s debug solution.

I’d like to hear what the community thinks. What is the right solution. Hopefully we can come together, find the development resources, and finally reach this Holy Grail for the CDT.

What could an Eclipse OS be?

I got some really positive feedback on my quick little demo of the “Eclipse OS” prototype that I’ve started building. So I’ve started to capture ideas on the github wiki for the repository that I created there. Feel free to add your thoughts there, or here. Maybe if there’s enough interest we could grow a little community around the idea. If not, that’s fine too. I’m really just exploring a role Eclipse technologies could play in a browser based “OS” such as the announced Google Chrome OS.

Here’s the link to the wiki and here is what I’ve started with: http://wiki.github.com/dschaefer/eclipseos

What should the Eclipse OS be? Take one of those new fancy 10″ netbooks. Install enough Fedora to xinit the Google Chrome browser with the Flash plugin (necessary in my books for a full web experience) and launch an Equinox standalone server. What local web applications would you need to manage your netbook? Feel free to add to this list.

  • Power Off. To shutdown the OS and power down, i.e. run the poweroff command. (Update: this is the first app and is now working).
  • Install Manager. To install new web apps into the server using p2. Integrate p2 with yum to install native components that the web apps may need.
  • Audio Manager. Similar to ALSA mixer but as a web app. To control the volume of the audio in the least. This could be a good first test of writing native code to help implement the service.
  • File Manager. To look at and manipulate the files on the system, maybe even open them in the browser.
  • Connectivity Manager. To manage wireless and wired network connections.
  • Power Manager. To manage power saving modes.
  • Office β€œSuite”. To prepare documentation and presentations while disconnected, like on long flights.
  • E-mail. For those who would like offline access to e-mail.
  • An IDE so I can build my web apps locally (thus the connection with my Web IDE (W-IDE) prototype).

Screencast Test

After asking around twitter, I had a number of people recommend TechSmith’s Jing for doing screencasts. These are the same guys that do the masterful Camtasia which is a more full featured, i.e. expensive, solution. Jing does a good job at capturing my screen and audio. It’s limited to 5 minute videos, but give that my main purpose is to share quick ideas with my blog readers, I think that’s fine.

So here’s my first screencast test. I’m showing the current state of my “Eclipse OS”, i.e. Fedora minimal install + X + Chrome Browser + OpenJDK + a standalone Equinox app server. There’s not much new here. But I’m really just learning how to use this media. One thing I learned as you’ll hear half way through, is that my laptop fan kicks in. Drives me nuts, but anyway. Expect a lot more of these in the upcoming weeks. And hopefully, I’ll improve the quality as I go to (like talking louder :).

Update: uploaded to Youtube which gives a much better viewing experience, especially in fullscreen mode.

Update 2: Planet Eclipse seems to filter out the embed object. Click on the title to come to blogger to see the real thing.

Eclipse OS?

I left a pretty cryptic entry last time. Essentially, I am trying see how easy it is to build a Chrome OS using Fedora as a base. It was pretty easy, and I have the instructions on how to do it. I’m going to put together a series of Jing screencasts (my new favorite screencasting tool), to show you how. That’ll take a few days to get together, especially given the beautiful weather we’re finally getting here in Ottawa.

But I wanted to show you a screenshot of the final result. Because, not only am I doing a Chrome OS look-a-like thing, I’m also putting Fedora’s OpenJDK and an Equinox server application on it to run applications locally. In this case, it’s the GWT Greetings app that you get when you create a new GWT project in Eclipse.

As I mentioned when I first heard of Chrome OS that it would be great if we could put Equinox on there to run local apps. Now I have a chance to expand on that idea and see whether it makes sense. Once I get the instructions together you can try it to. Could this be a start of an Eclipse OS?

Chrome OS Preview?

I’ll be posting more on this later, especially how you can do it yourself. But I’ve built what could be the upcoming Chrome OS. I did it starting from the Fedora 11 net install and added what I needed, which wasn’t much. Here’s a teaser screenshot until I can firm up the recipe πŸ™‚

Web apps make me think MVC

I’m blogging more than I’m coding lately, so I’ll try to keep this brief. But I noticed someone mention MVC while I was googling around for practical information on GWT. After I thought about it a while, building a web app is a great example of the Model-View-Controller paradigm.

The model is data you store or derive on the server. You can use GWT’s RPC mechanism to get at this data. The Controller is also on the server. You can send commands, like build my project, to it via GWT RPC too. The server may then farm that out to other specialized servers to actually perform the action. The View is the JavaScript code running in your browser that takes the data and draws it using GWT’s widgets and invokes the control using GWT’s Handler mechanisms. Having a well defined RPC mechanism, and having a requirement to reduce the traffic over the wire to help with responsiveness, you get pushed to keep your web app MVC clean.

Now, relating this back to my mobile app interests, I can easily see the View portion of the app being replaced by the native widget framework for the particular platform. As I’ve mentioned in previous posts, I don’t think running a web app in a browser in a smartphone is a good idea. I know the browser on my Android phone is really slow. You’re better off using Android’s native widget set in Java to accommodate the form factor. That’s what mobile app building is all about. What I need now is an implementation of GWT’s RPC mechanism in Java using Android’s communication APIs, and really interesting things jump into mind.

What this leads you to is having three View implementations for my web-based IDE, that I’m now calling W-IDE. One in the web browser using full GWT, one in Android using Android’s native widgets but still communicating with the services defined in GWT, and one using the regular Eclipse desktop UI, theoretically using those services as well.

Now, yes, that’s three implementations of the same thing, and I know how that rubs people the wrong way. But my theory is that they are, in fact, not the same thing. Depending on which of the three you have, you are likely to need different workflows. Running Eclipse in a 24″ monitor, it’s OK to have all those views and taskbars and such visible all at once. In a browser running in a 10″ netbook, not so much, and you’d really like to make it page based to take advantage of the browser’s history mechanism. And in a 4″ smartphone, I really struggle with any workflows that make sense, but they certainly would be limited to one view or editor at a time.

At any rate, this is sure turning into an interesting journey of exploration. In the end, we may decide that this is all crap and IDEs are meant to run on desktops only and that using RAP’s server-centric architecture is OK to render in the browser (which if you can’t tell yet, I’m not sure I agree with). But this is a 5 year journey and we have time for the different technologies involved to mature and we’ll see. I think we have a lot of time to figure this out.

And, yeah, I guess I failed at keeping this short.

Are we de-evolving or on a natural evolution?

Talking around the office about a future with web-based IDEs, it was interesting that people are starting to get it, or at least, not scoff that it’s something we’ll ever to deal with. There are some good aspects to it for the tools business. At the least it’s a great way to quickly get our products out to customers with minimal install fuss (the bane of my existence these days at work), and it’s a great way to get immediate feedback on what they find valuable.

The question that needs to be answered is why now? I remember back in the 90’s we were clamoring to get away from the client/server model. Everyone wanted a PC or workstation on their desk and former stars of the server world, DEC in particular comes to mind, faded away. Servers found a new life thanks to the web and it seems now, about 20 years later, we starting to climb back onto the client/server bandwagon. Why did we get away from that architecture and what’s happening to make us want to go back.

From what I know, looking back, I think one of the biggest problems with servers in the 80’s and early 90’s was their sheer cost. They were expensive machines. You could buy 100 PCs for the cost of one of these things. Worse, yet, they didn’t provide 100 times the compute power. The price/performance ratio made PCs a smart bet. They are both cheep and powerful. That, and they provided freedom to the user. If the server went down, they could keep working, and if they wanted to install some “forbidden” software, they could do it. It was really refreshing come to think of it.

But as any IT professional, or installer guy, would tell you, maintenance of all these machines is a nightmare, for the admin, and for the bottom line. As employees of larger companies well know, there are companies making money on software that beaver away in the background making sure all the other software is kept up-to-date and on the up-and-up. And, of course, some of the more rogue employees know how to uninstall that software and get it out of the way ;).

What the old server model provided was that ease of maintenance. You installed software on one machine and all your users had instant access to it. Of course there are risks to that as all of us tweeters had to deal with today, but with an improved focus on security and robustness with these critical server apps, like we had in the server era, those should become rare.

That, and looking at the cost of servers these days, the costs are way down. I would think that the price/performance curve is turning towards the server side. And just look around your workplace and count the number of CPUs sitting idly. It would be an interesting study to figure out what percentage of CPU power companies have is actually being used. It might make more sense to spend more on servers and less on desktops. You don’t need that much power to run a web browser, especially with the ever improving JavaScript VMs that we are finding in them these days.

It’s not really far fetched today to see a future, say five years away, where all of our apps are running on servers, in the “cloud” say, and we are accessing them through “dumb” terminals running web browsers, which is what Google’s Chrome OS and I’m sure others will provide. The economics are right. The culture though is something else. Are users ready to give up the freedom that traditional desktops provide? I think so, but only if the applications provide significant new value. Tools that integrate with other web apps to allow collaboration over the web could provide that value. Running desktop-style apps that simply display themselves in a web browser, will not.