Skip to content

Iloggable

Simple OutSim & OutGauge samples

Version 0.13b is finished, just cleaning up the docs, and packaging everything (switching to sandcastle for docs kind of added a new complication). Should have that out tomorrow, I hope.

In the meantime, especially, since the Tester app I include is really just something to exercise the lib, not to learn coding from (i.e. worst winforms code patterns example), I thought i'd throw out some simple code examples until i build a proper test suite. Now, these samples, with their use of straight up static methods are also nothing to learn program design from -- they're just API illustration. These examples work with the current and new release, so they're not tied to 0.13b.

The tricky thing to note about both OutSim and OutGauge is that the cfg.txt values take precedence. I.e. you can get both sent via InSim, but not if they are already set in the configuration file. Generally, I suggest sticking to manually configuring these two and going through the dedicated handlers for both and keeping them separate from your InSim handler.

OutGauge

This little Console app, just subscribes to OutGauge being sent once a second and refreshes the terminal with the new values:

static void Main(string[] args)
{
  // Assumes the following settings in LFS cfg.txt:
  //    OutGauge Mode 1
  //    OutGauge Delay 100
  //    OutGauge IP 127.0.0.1
  //    OutGauge Port 26020
  //    OutGauge ID 1

  OutGaugeHandler outGauge = new OutGaugeHandler(26020);
  outGauge.Updated += new OutGaugeHandler.GaugeEvent(outGauge_Updated);
  Console.WriteLine("created handler");
  outGauge.Initialize();
  Console.WriteLine("initialized handlers");
  Console.WriteLine("Press RETURN to exit");
  Console.ReadLine();
  outGauge.Close();
}

static void outGauge_Updated(object sender, FullMotion.LiveForSpeed.OutGauge.Events.Gauge gauge)
{
  Console.Clear();
  Console.WriteLine("OutGauge -----------------------");
  Console.WriteLine("Time:     {0}", gauge.Time);
  Console.WriteLine("ID:       {0}", gauge.Id);
  Console.WriteLine("Car:      {0}", gauge.Car);
  Console.WriteLine("RPM:      {0}", gauge.RPM);
  Console.WriteLine("Speed:    {0}", gauge.Speed);
  Console.WriteLine("Message1: {0}", gauge.DisplayMessage1);
  Console.WriteLine("Message2: {0}", gauge.DisplayMessage2);
}

OutSim

The OutSim version is virtually the same for setup, just that the eventargs contain different data

static void Main(string[] args)
{
  // Assumes the following settings in LFS cfg.txt:
  //  OutSim Mode 1
  //  OutSim Delay 100
  //  OutSim IP 127.0.0.1
  //  OutSim Port 26010
  //  OutSim ID 1
  OutSimHandler outSim = new OutSimHandler(26010);
  outSim.Updated += new OutSimHandler.PhysicsEvent(outSim_Updated);
  Console.WriteLine("created handlers");
  outSim.Initialize();
  Console.WriteLine("initialized handlers");
  Console.WriteLine("Press RETURN to exit");
  Console.ReadLine();
  outSim.Close();
}

static void outSim_Updated(object sender, FullMotion.LiveForSpeed.OutSim.Events.PhysicsState physicsState)
{
  Console.Clear();
  Console.WriteLine("OutSim -----------------------");
  Console.WriteLine("Time:     {0}", physicsState.Time);
  Console.WriteLine("ID:       {0}", physicsState.Id);
  Console.WriteLine("X:        {0}", physicsState.PositionX);
  Console.WriteLine("Y:        {0}", physicsState.PositionY);
  Console.WriteLine("Z:        {0}", physicsState.PositionZ);
}

Moonlight at Remix 07

Miguel de Icaza just posted a long entry on a Hackathon the mono team did in the last 21 days to get some version of Moonlight ready for Remix 07 and it looks like they succeeded. Further progress information can also be found on the Moonlight site.

Next to the Silverlight 1.1 alpha which exposes the CLR, Moonlight is probably one of my favorite tech project to follow at this time. I don't even run X anywhere anymore, just using linux for servers, so I don't think i'll ever need Moonlight. But its the availability that has me excited. I am personally rooting for a web programming model that doesn't force javascript on you for client side programming, but I don't think Win/MacOS is "cross-platform" enough to establish this as a norm, rather than a specialty plug-in. I hope Moonlight tips the adoption likelihood in Silverlight's favor.

Currently, I'm mostly waiting for a Socket API to make it into Silverlight 1.1. Once that's available, I'm going to make sure that my LFSLib can run under silverlight. This would open the door for some very cool in-brower LFS admin tools. I also have an internal DirectX implementation of the LFS smx and pth formats for rendering top down views. I've been looking at porting that to WPF, since i don't required 3D and just rendering a plane at this point. If I can reduce it further to the Silverlight Xaml subset, I could easily produce a Silverlight equivalent of LFS Spectator. But I'm getting ahead of myself. Right now I just need to get full patch X support out the door for LFSLib.NET. The protocol is complete now, I just need to complete the TCP code, do some doc clean-up and testing.

LFSLib.NET v0.12b (this is a test version)

I've just put v0.12b on the server. This version does bring LFS 0.5X compatibility, but it does not expose the new functionality. The goal of this version is primarily to let 0.11b code work against LFS 0.5X with the least amount of changes (some data just isn't represented the same anymore and caused breaking changes). This version is also ill tested, as I'm not going to go through an exhaustive set of tests until i get full 0.5X feature exposure (yeah, I know, i should be doing this test driven.. But that means a mock LFS or an LFS test harness and I haven't had the patience for that).

So what has changed? Here are the notes:

  • Moved to .NET 2.0 and Visual Studio 2k5
  • Swapped out back-end for dealing with InSim packets to more closely resemble the native LFS formats and removed the intermediate Msg* classes (all internal changes)
  • Finally mostly functional Unicode support for LFS message in and out transfers
  • Updated existing functionality to work against patch X, with some breaking changes in what is available in Events and how that data is represented.
  • Full patch X protocol implemented, just not yet exposed, so new packets don't come across as unknown packets

An extra note on "mostly function Unicode support". Basically for conversion of unicode to LFS encoding, I am using a lookup table from unicode to codepage+byte and there are a couple of LFS specific characters that screw up under Japanese encoding. And split messages have some issues. This will be fixed in 0.13b.

The new version can be found here and the home of the lib is here

How to do Control Flow via Polymorphism

Let's say you have n objects implementing an interface. Call these message, implementing IMessage. Each message may cause a different action when given to another object, the receiver. Sounds like the perfect scenario for Polymorphism. Create a method Handle() for each of the n messages specifying the concrete type in the signature. Now, let's say you receive that message from a MessageFactory and, obviously, that factory hands you the message via the interface. So here's the pseudo code:

public interface IMessage
{
}

public class MessageA : IMessage
{
}

public class MessageB : IMessage
{
}

public class Receiver
{
  public void Handle(MessageA msg)
  {
  }

  public void Handle(MessageB msg)
  {
  }
}

public class MessageFactory
{
  public static IMessage GetMessage()
  {
  }
}

Now, how do you pass this message off to the appropriate Handle() version? You can't just call Handle() with your message because you message is actually an IMessage not the concrete type. I can think of three workarounds and don't like any of them. Is there another way, or is this just a limitation of C#? In the meantime, here are the three ways I can think of solving this:

The Switch

The traditional way, use if/else or switch to examine the incoming object and dispatch it. Just create a method Handle(IMessage msg) and have it dispatch each to the proper Handle(). Traditional, simple. But as n increases it becomes less and less readable and dispatch is now a runtime decision. It could just fail, if you overlooked a concrete class.

The Reflection

At runtime examine the actual type of the message and then inspect your receiver to dynamically invoke the appropriate methods. No worries about maintaining the code or readability. It's just magic... but runtime magic which may yet fail if you overlooked a concrete class.

The Self-Dispatcher

There is probably a named pattern that goes with this approach. It shares some aspects with the Visitor pattern (that's what inspired me actually), but I don't know what this pattern is actually called. The idea is that each message doesn't get passed to the receiver but passes itself. I.e. it calls the appropriate method. For this to work, we add a method to our interface:

public interface IMessage
{
  void Dispatch(Receiver receiver);
}

public class MessageA : IMessage
{
  public void Dispatch(Receiver receiver)
  {
    receiver.Handle(this);
  }
}

This works perfectly. After getting the message from the factory, you just call msg.Dispatch(receiver). Since each message implements its own dispatch for itself, we get compile time checking. Yay. But we basically copy and paste the Dispatch() method into every message class and we can't factor it into a common base-class, because that would break the flow control again. So it achieves the ends I'm after, but I don't like the implementation.

What other options are there?

Generic return values and explicit casting

Came across an artifact with generics that confused me. Let's say you had an interface IFoo:

public interface IFoo
{
  [...]
}

and a class Foothat implements IFoo:

public class Foo : IFoo
{
  [...]
}

then a given method returning IFoo doesn't have to explicitly cast Foo to the interface:

public IFoo Foo()
{
  return new Foo();
}

So, I figured that the same would be true for a generic method returning T with a constraint to IFoo. However, it seems that the constraint is not considered for implicit casting to T. So you have to explicitly cast Foo to IFoo and then cast that to T:

public T Foo<T>() where T : IFoo
{
  return (T)(IFoo)new Foo();
}

That just seems a bit strange to have to do.

Eclipse "resource out of sync" needs refresh

Ok, I've now twice wasted time on trying to figure this out and this time I'm writing it down, so I don't do it a third time :)

I recently added an eclipse project to SVN (it's already in perforce, my usual SC of choice) and after that my JAR export would fail with a bunch of "Resource is out of sync" errors. Since all the resources were .svn related, I blamed SVN and chased this down the wrong path for a bit.

Here's the simple solution: If you see a jar export fail because of "resource is out of sync", try doing a Refresh on the project before anything else. That should solve it.

ISecurableChannel in TcpChannel not ready on mono

I was just trying to move a remoting service from .NET 2.0 to mono and ran into problems with Interop. The client & server would work fine if running on the same architecture, but fail when crossing architectures. Turns out that the secure portion of TcpChannels isn't completed yet on mono, throwing an AuthenticationException when a Windows client tried to connect to a Linux server. The culprit is ISecurableChannel. To avoid this, simply, don't use the security feature for now (i.e. use at own risk, best on a private net).

To get it working replace

ChannelServices.RegisterChannel(chan, _**true**_);

with

ChannelServices.RegisterChannel(chan, _**false**_);

Silverlight, Moonlight and a true VM for your browser

Considering my previous rant about RIA platforms, I'm a bit slow out the gate with my Silverlight comments. But there was a lot to digest before making half-baked comments.

While I was at MEDC, Mix07 was going on next door. I didn't even hear the cool Silverlight announcements until I got back from Vegas. But now that i've played with it, it's exactly what I had hoped for (minus a disconnected use model): We have a true VM to code against on the client side. That means the full breadth of .NET languages to control the reduced WPF presentation layer, plus with the DLR true scripting support at near-compiled performance.

As I expected, there was no linux support announced by MS and neither does it appear that they've opened a channel to the mono team. But Miguel de Icaza has addressed this issue independently with the Moonlight project and listening to the chatter on the dev list and following the wiki updates, that project is getting serious attention. I may even be better this way. I think a firefox plug-in coming from the mono team would be more willingly installed by linux users than something coming directly from MS.

We'll have to see how much more of the WPF set of Xaml gets supported by Silverlight as 1.1 moves to beta and RTM. Obviously, the way custom controls are done is not ideal right now--the way properties are acting against implementationRoot (haven't gotten deep enough to understand why it's not using the DependencyObject/Property pattern) and the shadowing of inherited properties just make for a strange experience compared to Controls in WPF, Windows Forms or even ASP.NET. Hopefully that morphs into a better model as we move along. If nothing else, the development of the promised suite of UI controls provide internal motivation to refine the model. Not that I think that DependencyObject/Property is an elegant coding pattern (at least not until that legwork moves into code generation).

But while everyone is busy committing the same UI crimes that many Flash developers have been guilty of for years, I think the real significance of Silverlight is not it's Xaml and rich media support. In my opinion the most amazing feat of Silverlight is its DOM interoperation. The Silverlight VM is accessible in both directions, complete with object serialization across boundaries. This means you can have managed code attached to DOM events, and managed code modifying the DOM itself or calling javascript in the page. With a minimum of glue, you could move all your code inside of Silverlight and even if you don't care about C# et al., you'd at least get a much higher performance javascript out of the deal. Then add the rich communications infrastructure and the hinted at socket level networking in future versions and suddenly you can have very fast, very interactive web applications that could be truly stateful and have better event handling for asynchronous operation etc.

Right now, you need some 1x1 pixel Silverlight object that everything gets channeled through, but MS has already promised that that dependency is going away. So what you really have is a VM and rich framework addressable with bytecode compiled from a huge number of potential languages in the browser. Whether you use that VM to drive your HTML, Silverlight's presentation layer or even the canvas tag is up to you. It's what I hoped that the browser manufacturers would do themselves, but as a plug-in, the chance of this capability becoming ubiquitous is even better, imho.

Silverlight 1.1 alpha is clearly a very early peek into the tech, but it works just great already. I'm curious what it will look like by the time it's an official release. And I certainly hope that by that time, MS has given the disconnected, self-hosted option some consideration. After all, when competing with Flash/Flex, one shouldn't ignore Apollo.

Running third party vmware images

Trying to reconfigure mail once again (a rant for another time) and trying out a couple of VMware Virtual Appliances. But every appliance I tried on my server would just appear to hang. Black screen, no bios, no nothing. Finally found a post on the VMware forums talking about permissions, so I compared my working images to the non-working ones and the problem was simply that the .vmx file needed to have execute permissions.

Reading a resource in eclipse or jar

Disclaimer: I've been trying to store some text resources in my jar so that i can easily package uncompiled content with my executable. This course of action seemed like the natural thing to do. However what I had to do to actually access this file and allow for different environments like running from eclipse vs. executing the jar makes me wonder if I'm missing some essential facilities. I.e. can eclipse build the jar and execute it instead of running it's class files, so that you can test jar stored executions as part of eclipses normal debug and excution? And is there some facility that let's you just say InputStream res = App.GetResourceStream()?. Well, in the meantime here's what i cobbled together to get this working, since my googling didn't come up with a single source that put it all together.

First thing, we need to determine where we are executing, both because its the base for finding our resource and because it tells us whether we're dealing with a directory hierarchy or a jar file:

ProtectionDomain protectionDomain = this.getClass().getProtectionDomain();
CodeSource codeSource = protectionDomain.getCodeSource();
URL location = codeSource.getLocation();
File f = new File(location.getFile());

Now we get an InputStream, depending on what environment we're in:

String resourcePath = "resources/xsl/register.xsl";
InputStream resourceStream = null;
if (f.isFile()) {
    // it's a file, so we assume it's a jar and look for our
    // resource as a JarEntry
    JarFile jar = new JarFile(f);
    JarEntry xslEntry = jar.getJarEntry(resourcePath);
    resourceStream = jar.getInputStream(xslEntry);
} else {
    // it's a directory, so we just append our relative resource
    // path
    resourceStream = new FileInputStream(f.getAbsolutePath() + "/"
            + resourcePath);
}

Now we have an InputStream and can ingest the file anyway we like.