OMG

I am watching (if you can call it that -- I'm just refresh-reading the live blog) the release of the Apple iPhone SDK as I write.

Oh. My. God.                  

I just peed my pants. (^_^)

Really, really nice

Just a quick one today.

After my previous qemu post, I found this really cool article on how to debug the linux kernel itself running on the emulator. It even uses Eclipse CDT so you have a nice IDE while debugging the kernel code.

Great stuff...

Fork/exec while redirecting I/O

Here's a common problem in (POSIX) C applications: let's say you want to execute another application, but you want to redirect this application's standard I/O (i.e., stdin, stdout, stderr) to a file descriptor(s) of your choice. Perhaps you want to log the output to a file, or stream the application's input from a file you just created, or collect error messages (stderr) for parsing later.

The function below illustrates how to do this:

pid_t
exec_redirect(
const char *path, char *const args[],
int new_in, int new_out, int new_err
)
{

pid_t child;

// Fork new process
child = fork();

if (child == 0) {

// Child process

// Redirect standard input
if (new_in >= 0) {
 close(STDIN_FILENO);
 dup2(new_in, STDIN_FILENO);
}

// Redirect standard output
if (new_out >= 0) {
 close(STDOUT_FILENO);
 dup2(new_out, STDOUT_FILENO);
}

// Redirect standard error
if (new_err >= 0) {
 close(STDERR_FILENO);
 dup2(new_err, STDERR_FILENO);
}

// Execute the command
execv(path, args);
}

// Parent process
return child;

}

This function takes the parameters path and args which is the same as what you would normally pass to execv(3). In addition, there are three parameters, new_in, new_out, and new_err which are (optional) file descriptors where the new application's standard input, output, and error, respectively, will be redirected from/to. To make redirection optional, we specify that if the descriptor parameter is -1, then no redirection will take place.

So how do we use this? The code snippet below executes the command line /bin/myapp -l -p, with input redirected from in.txt, output redirected to out.txt, and error redirected to err.txt:

    ...
 char *cmd = "/bin/myapp";
 char *args[] = { "/bin/myapp", "-l", "-p", NULL };

 in = open("in.txt", O_RDONLY);
 out = open("out.txt", O_WRONLY|O_CREAT|O_TRUNC,S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH);
 err = open("err.txt", O_WRONLY|O_CREAT|O_TRUNC,S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH);

 exec_redirect(cmd, args, in, out, err);
 ...

On a closing note, it's also probably a good idea to close() the file handles in the parent process, after exec_redirect(), just to prevent "inadvertently" accessing them while the child process is also doing the same. Yes, the pun was intended ;-)

[Update: fixed some typos]

A Quick Eclipse-based XML Editor Using EMF, Part I

Introduction

I've recently been dabbling in OSGi technology and found DS (Declarative Services) feature neat for automagically registering and finding/consuming services. Basically, instead of having to call OSGi APIs for registering Java objects(services), you will just need to "declare" these provided services in an XML file and the DS framework will take care of registering it for you. Similarly, if your application needs a service, instead of finding (and tracking) it yourself in code, just declare it in the XML file and DS will take care of "injecting" it into your object and tracking dynamic registration/unregistration. It is very reminiscent of Spring Dependency Injection and in fact, Spring has a very similar technology called Spring DM (Dynamic Modules). In the end, these technologies are all about decoupling your business logic from framework/container (e.g.OSGi) APIs, which promotes greater code reusability.

Anyway, like I said, the configuration is XML-based and being the lazy (in a good way ;-)) developer that I am, I wanted an integrated editor in Eclipse to edit these DS files. Nowadays, whenever I see and XML<->Java binding (plus Eclipse integration) problem my neurons automatically fire "EMF!", and so I set about trying to use this technology to create my own editor.

Which brings us to our first box-looking thingie:

What is EMF?

1. A (meta-)modeling language (ecore)
2. A Java code generator for your model
3. An (extensible) XML<->Java binding framework

In addition to the above, you also get the following:

• Reflective API (e.g., eGet("sandwich") method in addition to getSandwich() method)
• Change notification
• Base adapter & adapter factory classes for most model editing needs (providing content, labels, etc. for your model)
• Command-based editing, undo/redo support
• A sample Eclipse editor which you can customize or study
• An option to export the editor as a standalone RCP app (cool!)
  

As a modeling technology, EMF is pretty solid and feature-rich. However, for this case, we don't need to create models because there is already a schema available - it's in the OSGi specs. EMF already has the ability to convert any XSD schema to an ecore model, and vice-versa.

The DS schema looks something like this:


I just copied it from the specs and saved it to a file in my system.

Here, then, is the quick procedure for creating the editor. Are you ready? Don't blink your eyes because this will be F-A-S-T! :-)

1. From Eclipse, click New->Other..., then select EMF Project as below:


You will be prompted for a project name. Type, e.g., org.example.ds.

2. Select a Model Importer. For now we use XML Schema:


Then, browse to where you saved the DS schema file (.xsd).



3. In the next page you will be asked what packages to import. EMF tries to generate a model filename from the schema contents but it's sometimes not nice (e.g. _0.ecore). You can rename it if you want, like here I renamed it to ds.ecore.


4. When the wizard is finished, you will have a new project in your workspace, with the generated ecore model (ds.ecore). Also, there will be a ds.genmodel file which is a generator model for your model: it tells EMF about code-generator-specific stuff like where to put the generated files, what base package name to use, etc.

You can view and edit these files via the Ecore and GenModel editors already bundled with EMF:



Again, the package name derived from the schema might not look nice ("_0"), so here we can rename it. In the Ecore editor, select the package _0, and in the Properties View, set the Name property to "ds".


5. Now that that's out of the way, we can configure the code generator. First, double-click the ds.genmodel file. It will open the GenModel editor:


We can set the Base Package property to org.example so that the generated package will start with org.example.ds. And also rename the Prefix property to "Ds" (previously it was "_0").

6. Code generation time!

Select the root genmodel (Ds), right-click, then click the Generate Model Code, Generate Edit Code, and Generate Editor Code commands successively.


If successful, it will generate the Java code for your model, as well as 2 new projects: a UI-agnostic .edit project which you can re-use outside of the Eclipse environment, and an Eclipse-specific .editor project which is tightly bound to (you guessed it) the Eclipse environment.

The editor application is complete!

7. You can test it by launching a new Eclipse instance from the workbench:


It will run a new Eclipse environment with your core, edit, and editor plug-ins included. In it you can try to create a new DS file via New->Other...->Example EMF Model Creation Wizards->Ds Model.


If you try to double-click this new file, it will invoke the .editor plugin you just created, and show a nice tree-based editor for you!


The great thing is, if you try to look at My.ds using a text editor, you will see the underlying data is fully compliant XML!


What's Next

We've gone from zero (editing XML by hand) to hero (editing the same XML by a neat, integrated, GUI-based editor) in just a few mouse clicks. But that is not all that EMF can do! I just hope this article has gotten you interested enough to want to have a deeper look. :-)

From here, where can our DS Editor application go? Well, I can see a few things for improvement already:

1. The generated class names are ugly!

Did you have a look at the generated model/Java code? There are classes whose names are Tservice, Tproperties, and so on (fugly!). These are a direct consequence of the <complexType name="xxx"> declarations in the schema. It would be nice if the generated class names were more, hmm... how you say... Java-ish? :-p Like Service and Properties, respectively, for example.

In the next parts I will show how to "coax" EMF to generate (nicer, if you wish) class names, so you won't be forced to use the schema's type names if you don't want to. :-)

2. I want more Eclipse IDE integration!

For example, when I edit the attribute interface, I don't want to type the Java interface name in a text box. I want something similar to those nice JDT dialogs where I can search and select for the Java interface:


In the next posts, we'll see how this can be done.

3. I want it to make me coffee & toast!

Okay, EMF is cool.. but not that cool :-)

Stay tuned!!!

Read...+ Write?

In a previous post I mentioned the possibilities opened up by having access to a C/C++ project's DOM AST within Eclipse. Now there's a new bugzilla in CDT to work on making this AST writable. Aside from the obvious benefit (aka "refactoring"), I can imagine a whole new bunch of neat features that can be made possible by this work: more intelligent C/C++ code generation, quick fix, among others.

Eclipse CDT is becoming more and more like the excellent JDT in terms of features and API, and this is great news for us C/C++ developers and Eclipse plug-in developers alike.

Installing Ubuntu 7.04 Server on QEMU

I was able to install and run an Ubuntu 7.04 Linux (Server Edition) on a Windows XP host using QEMU. Installation was pretty straightforward, what required some extra research was getting the Linux guest OS to communicate with the host OS using TCP/IP.

Here are the steps:

Ubuntu Installation

1. Download and install QEMU for Windows

2. (Optional) Download and install KQEMU for Windows

This will greatly speed up the virtual machine running in QEMU.

3. You will also need to download the Ubuntu server .iso file.

4. Once these are ready, you can create the disk image that will be used by the virtual machine.

The command line below will create a disk image 3GB-large in the file ubuntu.img:

qemu-img.exe create ubuntu.img 3G

5. Boot the virtual machine with the Ubuntu .iso as CD-ROM drive

qemu.exe -cdrom ubuntu-7.04-server-i386.iso -boot d -m 256 -L . ubuntu.img

You should see a window with the Ubuntu installation screen.
Proceed with the installation as per normal.

After installation, you need to reboot with the disk image as boot disk. Just remove the -boot d option to do this.

qemu.exe -cdrom ubuntu-7.04-server-i386.iso -m 256 -L . ubuntu.img

Voila! A Linux box (with LAMP) right inside your Windows desktop.

Configuring the Network

There are a couple of ways to go about this, and it really depends on your network configuration (i.e., whether you use DHCP, whether you need to connect to the Internet, etc.). The steps below describe what I did in my set-up:

1. Download and install OpenVPN.

Actually you will just need the Tap-Win32 component, so you can go ahead and de-select the other components during installation.

2. After installation you will have a new "Local Area Connection" in your Network Settings folder. For convenience later, I suggest you rename this to something like tap0.

This interface will be used to connect to the guest OS. You can assign it an IP address, e.g. 192.168.1.1.

3. Boot the guest OS, but this time add the ff. parameters: -net nic -net tap,ifname=tap0

This will give the virtual machine a network interface, and connect that network interface to the host's tap0 interface.

4. After the Ubuntu server has booted, it should have an eth0 interface. You can assign an IP address to this using ifconfig.

$ ifconfig eth0 192.168.1.2

That's it. Your host OS and guest OS should have network connectivity! Try to ping each other. Your network should look like this:

192.168.1.2(eth0, linux) <----> 192.168.1.1(tap0, windows)

If you want to connect the linux box to the Internet then you can use the bridging function of Windows. I also suggest turning on the Samba server of the linux box so that transferring files between OSes will be very convenient.

Happy emulating!

vi plug-in for Eclipse

During the past few years, I've gotten so used to using vi that my fingers have memorized some of the key bindings. Now that I'm using the Eclipse as IDE, I'm having withdrawal symptoms... like constantly typing :wq to save current file, or '/' to perform a search. It's just so convenient to not have to lift my hand over to the mouse to do some common editing tasks.

Much as I love the convenience, though, I'm not willing to give up the powerful Java & C/C++ editing features of Eclipse: outline view, type hierarchy, continuous build, among many others. Given this dilemma, what is a developer to do?

Thankfully, Eclipse is an extensible IDE/platform and creating plug-ins has never been easier.
So I did the next best thing: I tried to create my own plug-in that emulates vi inside the Eclipse IDE (specifically, inside the text editors).

So, let me introduce to my own (pre-alpha) version of the Eclipse vi plug-in.

Here's how to install it:

1. Inside Eclipse, go to Help->Software Updates->Find and Install...->Search for new features to install
2. Click the New Remote Site button. Enter the information below when prompted:
• Name: Eclipse vi plug-in (or whatever suits you)
• URL: http://eclipseviplugin.sourceforge.net/update/0.x/
  
3. Click Finish. Eclipse will try to download the plug-in from the above site.
4. Once the download is finished, you will be asked to select the features to install. Just select All then hit Next.
   
5. Accept the license... blah blah blah.
   
6. Next. Then Finish. You will be prompted to restart Eclipse shortly afterwards. Please do.
   
7. After restarting, try opening a text, Java, or C/C++ file.
   
8. Press Ctrl+4 (my temporary equivalent of vi's ) inside the editor to go into vi command mode
9. From command mode, you can press i (insert), a (append), or o (insert line) to go back to edit mode. Or just click the mouse anywhere inside the document.
   

Voila! The convenience of vi at your fingertips. Literally.

Mind you, it is still pre-alpha (v0.0.1), and thus sorely lacking in features and probably ridden with bugs too. If you find some, please don't hesitate to report it in the project's Bugs or Feature Requests page. Please be kind as I am only doing this in my free time :-)

Here are some of the other commands that work so far:

• :w (save)
• :wq (save and close)
• :q (close)
• w (next word)
• b (previous word)
• $ (go to end of line)
• ^ (go to start of line)
• % (find matching bracket - you need to be in a Java or C/C++ editor for this)
• most navigational keys (h, j, k, l and arrow/pgup/pgdown keys)
• delete commands (x, dw, d$, dd, db)
• u (undo)
  

In the future, I plan to add support for:

• Find commands (/, ?, *, #)
• Repeat previous command (.)
  
• Command count (e.g., 3x to delete 3 characters)
• Other neat vi features
  
• Text editor (UI) enhancements such as status line, popup dialogs, preference pages, etc.
• Help pages
  

Members & contributors to the project are most welcome, especially those with Eclipse platform knowledge!

In the next posts, I will try to document some of the experiences in developing the plug-in, for the benefit of those who might also be interested in Eclipse plug-in development. Stay tuned!

[Update (12/05/2007) - Ack.. I forgot to set the compiler level to 1.5. As a consequence, v0.0.1 will not run on 5.0 JREs. It's fixed now in v0.0.2]