How bazaar - today Robin announced that the previous occupant of his desk at work had left a pair of handcuffs in the top draw. What is more, on inspection, it appears he was telling the truth - there really was a pair of handcuffs in his top draw. Hmmm… my mind truly boggles.
I’ve finally made the move. For some time now I’ve been using bash in vi mode - however there is just one little niggle with it, every now and then the display messes up and you start seeing things like this:
le/why/has/this/moved/here?puter ~ $ mplayer /some/long/path/to/some/fi
That is really really really annoying when it happens.
Anyway, a colleague mentioned some time ago that this was the reason he moved back to Korn Shell… so I figured I’d give it a go. So far the only thing I’ve not managed to get working is coloured ls output…. Everything else is working, tab completion (even though I’m trying to use Esc + \ instead), coloured PS1 prompt etc etc … most importantly though, vi mode hasn’t, as of yet, messed up! 
I’m starting to get a little concerned though - I’ve moved away from Gnome to Fluxbox at home and to fvwm2 at work… then on top of this I’ve now changed my shell from bash to ksh - what is happening!?!
Edit: I’ve now got coloured ls working… I was too involved reading the .bashrc files in Gentoo trying to work out how bash does it… instead I should have just typed man ls….
--color[=WHEN]
control whether color is used to distinguish file types. WHEN may be `never',
`always', or `auto'
Duh!
michaelfclarke@mikes-computer michaelfclarke $ alias ls ls='ls --color=always'
The other day I wrote a small tutorial on getting dynamic class loading working for Java. In that post I mentioned that it could also be done in C# - but that it was more difficult, and from my personal experience, there is less information available about it - so here is how to do it!
First, as with the Java, we need to create our API. However, unlike the Java there is an additional requirement - a ‘module manager’ class needs to be within the API. As such you will need to create these two files…
using System; using System.Reflection;
namespace com.michaelclarkeblog.api {
public static class ModuleManager {
public static Module getInstance(String fileName) {
/* Load in the assembly. */
Assembly moduleAssembly = Assembly.LoadFile(fileName);
/* Get the types of classes that are in this assembly. */
Type[] types = moduleAssembly.GetTypes();
/* Loop through the types in the assembly until we find
* a class that implements a Module.
*/
foreach (Type type in types) {
if (type.GetInterface("Module") != null) {
/* Create a new instance of the 'Module'. */
return (Module)Activator.CreateInstance(type);
}
}
return null;
}
}
}
using System;
namespace com.michaelclarke.dynamic.api {
public interface Module {
String getText();
}
}
Once you’ve got the two files you can compile them into a library….
api $ mcs -t:library Module.cs ModuleManager.cs
api $ ls -a | grep .dll
Module.dll
api $
Now that we’ve made the API the next thing to write is the application that is going to use it for loading modules. This is a very simple application…
using System; using com.michaelclarkeblog.dynamic.api;
namespace com.michaelclarkeblog.dynamic.application {
public class Application {
public static void Main(String[] args) {
if (args.Length > 0 ) {
Module module = ModuleManager.getInstance(args[0]);
Console.WriteLine(module.getText());
} else {
Console.WriteLine("Usage: mono Application module_name");
}
}
}
}
Now we can compile our ‘Application’ against the API…
application $ mcs -reference:../api/Module.dll Application.cs application $ ls -la | grep exe -rwxr-xr-x 1 michaelfclarke michaelfclarke 3072 Apr 5 19:32 Application.exe application $
And now finally we can write a couple of modules!
using System;
using com.michaelclarkeblog.dynamic.api;
namespace com.michaelclarkeblog.dynamic.modules {
public class Mike : Module {
public String getText() {
return "Hello from Mike's Module!";
}
}
}
using System;
using com.michaelclarkeblog.dynamic.api;
namespace com.michaelclarkeblog.dynamic.modules {
public class Another : Module {
public String getText() {
return "Hello from Another Module!";
}
}
}
Compile the modules…
modules $ mcs -t:library -reference:../api/Module.dll Another.cs modules $ mcs -t:library -reference:../api/Module.dll Mike.cs modules $ ls -la | grep dll -rwxr-xr-x 1 michaelfclarke michaelfclarke 3072 Apr 5 19:36 Another.dll -rwxr-xr-x 1 michaelfclarke michaelfclarke 3072 Apr 5 19:36 Mike.dll modules $
There is just one last thing we need to do before we can run our application. We need to copy the Module.dll API from the api directory into the application directory…
modules $ cd ../application application $ cp ../api/Module.dll .
And now lets try running our dynamic application…
application $ mono Application.exe ../modules/Mike.dll Hello from Mike's Module! application $ mono Application.exe ../modules/Another.dll Hello from Another Module! application $ mono Application.exe Usage: mono Application module_name
It’s been quite some time since my last post. This is down to a number of things - the first is that I’ve been really busy and so haven’t had that much time to write a blog post. The second is, with being so busy with mundane things, I’ve not really had anything worth while blogging about.
However, today I was on the phone with a friend (Anton) and our conversation slowly progressed to Dynamic Class Loading, specifically in Java. This made me remember that when I first heard about this technology (about three or four years ago) there wasn’t that much information available on the internet. So, I decided that I’d write a little (or perhaps not so little) post on how to go about getting Dynamically Loadable Classes in Java - it really is pretty easy.
The first thing you need to define is an interface for your modules. Mine is just going to be something simple that had a getText method to get some random text…
package com.michaelclarkeblog.dynamic.api;
public interface Module {
public String getText();
}
You can now compile your API…
~/src $ javac com/michaelclarkeblog/dynamic/api/Module.java ~/src $
The next thing to do is to write your main application that is going to do the module loading. Mine is going to be a simple main method that accepts a java class name as a run-time argument.
package com.michaelclarkeblog.dynamic.application; /* We must import the URLClassLoader and also our API. */ import java.net.URLClassLoader; import com.michaelclarkeblog.dynamic.api.*;
public class Application {
public static void main(String[] args) {
Module module;
if ( args.length > 0 ) {
try {
/* Create a new instance of the module.
* Think of this as:
* Module module = new Module()
* Except we're doing it at runtime 
*/
String path = "com.michaelclarkeblog.dynamic.modules." + args[0];
module = (Module)Class.forName(path).getConstructor().newInstance();
/* Run the modules 'getText()' method defined in the interface. */
System.out.println(module.getText());
} catch (Exception e) {
System.err.println(e);
}
} else {
System.out.println("Usage: java application module_name\n");
}
}
}
That’s pretty painless, we can compile it now…
~/src $ javac com/michaelclarkeblog/dynamic/application/Application.java ~/src $
Now all that is left it to make our modules. I’m just going to write two, but you can write as many as you want.
package com.michaelclarkeblog.dynamic.modules;
import com.michaelclarkeblog.dynamic.api.*;
public class Mike implements Module {
public String getText() {
return "Hello from Mike's Module!\n";
}
}
package com.michaelclarkeblog.dynamic.modules;
import com.michaelclarkeblog.dynamic.api.*;
public class Another implements Module {
public String getText() {
return "Hello from Another Module!\n";
}
}
And now we compile our modules - notice that we’re NOT re-compiling the main application.
~/src $ javac com/michaelclarkeblog/dynamic/modules/*.java ~/src $
Time to run our program…
~/src $ java com.michaelclarkeblog.dynamic.application.Application Usage: java application module_name
~/src $ java com.michaelclarkeblog.dynamic.application.Application Mike Hello from Mike's Module!
~/src $ java com.michaelclarkeblog.dynamic.application.Application Another Hello from Another Module!
~/src $
Easy eh?!
I know the above doesn’t look very powerful. However, you can make some really dynamic and customisable applications with this technique where your users can even write their own modules for the application - all they need is the api/*.class files (or depending on how many you have you can jar them up)!
Tomorrow (simply because I am no tired) I’m going to post the same application and modules but written in C# and compiled using Mono under Linux. When I said earlier that it was hard to originally find this information for Java (which it appears not to be anymore) it was even harder to find this information for C#, let alone get it working properly!