Aug 03

A Great Movie Idea

So here’s an idea for a movie that I just thought up: a comedy movie along the lines of Home Alone, but instead of breaking into somebodies house, they try to break into the Wonka factory to steal the secret recipe for chocolate or something like that.  Then they get into all sorts of wacky hijinks because it’s, you know, the Wonka factory.  You’ve got seltzer that lifts you up to the ceiling, gum that makes you fat, people getting stuck in tubes, the list goes on and on!

May 07

Java Scanner and Input Streams

This just took me a stupid long time to figure out, so I’m leaving it here for future reference.

In Java, the easiest way to read lines is using Scanner.  For work, I had written a quick Linux-only serial port implementation, with which I then took ideas from that for use in my cross-platform JavaSerial library.  What I was doing before was simply using a scanner to look for text coming in on the serial port, and splitting it up based on the lines using the scanner.  This worked fine.

Then I used JavaSerial.  And the Scanner wouldn’t work.

AT ALL.

As it turns out, Scanner doesn’t like using the normal read() method found in InputStream.  It instead uses the read() method which takes in a byte[] array.

If this was documented anyplace in the Javadocs, that would be good.  But it’s not.

UPDATE: 

I’ve figured out what the problem was. According to the Javadocs for the read( byte[], off, len ) method, it will block until it reads the entire length requested, which is stupid.  My implementation reads until either the end is reached OR there is no more data available(using the available() method).  See my implementation here.

Apr 28

C Enums

Enums in C are something special.  They’re not strongly typed at all.  As it’s pointed out, sometimes enums are used for making bit values, which is rather convenient.  However, it would be very good if enums could be strongly typed.  So, here’s my thought on how to make enums in C better.

Enums should be strongly typed.  The following should throw a compile error about assigning an integer to an enum:

enum MyEnum{ Value1 = 0, Value2 = 1 };
enum MyEnum variable = 0;

However, since this is C, casting should be allowed. So you could do this:

enum MyEnum{ Value1 = 0, Value2 = 1 };
enum MyEnum variable = (enum MyEnum)0;

Now about the bitset. I think that the best way to do this is to create a new enum-like type, called bitfield. It would have a syntax nearly itentical to enum, and the compiler could auto-increment the bitfields as well, so that you can ensure bitfields are always good:

bitfield MyBitfield{ Value1 = 0, Value2 = 1, Value3 = 3, Value4 = Value2 | Value3 };

The compiler would then go through and ensure that all bitfields are valid. You could also put more than one bitfield value into a bitfield, and the compiler would ensure that they’re both of the same type. So, this would be valid:

bitfield MyBitfield{ Value1 = 0, Value2 = 1, Value3 = 3, Value4 = Value2 | Value3 };
bitfield variable = Value1;  /* Works */

/* When passing in a method */
void foo( bitfield parameter ){
  if( parameter & Value2 ){
    /* Do something */
  }
}

This would create a much more type-safe form of enums for C. While not backwards-compatible, it’s not a dramatic shift in how enums are used, so it wouldn’t require huge changes.

Apr 18

Software Licences

So I came across this article via Slashdot today, and I figured that I’d post some thoughts on my programming utils and their license.

The part that I really noticed was:

…younger developers may be choosing more permissive licenses as a way of pushing back against what they see as a “permission culture.” They prefer to let other developers just do whatever they want with their code – and, rightly or wrongly, this might be a reason why many projects are released with no license whatsoever.

This is basically what I was going for.  I don’t care what people use my software for.  It is there for people to use.  In that regard, the WTFPL may be a better choice, but I’m comfortable enough with the MIT license.  As long as proper credit is given, that is good enough for me.  The code is released in the hope that it will make other people’s lives easier.

Apr 03

Auto-generation of environments

So I’ve been re-playing GTAIII lately, and I thought of something.  How would one make a full city, with full interiors for every building that is there?  Couldn’t we just generate all this stuff at run-time?

This makes a lot of sense.  The code size becomes larger, but the code size is generally pretty insignificant compared to the size of the assets of the game.  If we define basic things such as how things go together, we could get something cool here.  For example, an office environment could have desks and chairs, and chairs should normally be next to desks.  Cubicle walls follow the same general footprint.  You don’t even need to randomly generate these things per-se; in order for everybody to have the same room, just have a function call which takes an int as an argument all the time; like a pseudo-random number generator, you’d get the same output every time that you ran it.  Ideally, what you would have is each floor of a building being a certain input to this generator of floors.  You don’t need to run through the code to generate the floor unless the player actually goes up to the floor. The environment artist also doesn’t have to create the floor at all, all he would have to do is to say “Okay, these are the floor dimensions. Here is the number.  Generate!” and it would do it.

It could work.  I’m not going to try and implement this, because it’s probably hard and I don’t really have anything to use it for anyway.  But it could be cool.

Jan 15

FTDI Drivers

So I figured that I’d talk about FTDI’s Linux D2XX drivers for a little bit, and about some odd things that they do.

First of all, FTDI makes really nice chips.  We use them at work.  The problem came about as follows: we tried to have both an SPI device and a normal serial port on an FTDI 4232H, since it has 4 possible serial ports.  So, we figured that using the FTDI D2XX drivers would work, in conjunction with their MPSSE drivers to communicate with the SPI device.

Wrong.

As it turns out, FTDI tries to be clever with their drivers.  That, or they have no idea how Linux works(I don’t know if this affects Windows as well.)

You see, what FTDI does is to dynamically load the methods that they are going to call.

That is not the right way to do it.

You know why?

Because that’s the job OF THE LINKER.

This is why when linking with D2XX drivers, you need to pass -ldl to the linker.

Also, this is done in the initializer of the drivers, which happens to be name my_init, presumably because they simply copied whatever example they found on the internet in order to do this.  There are very few occasions where it is appropriate to use an initializer in a library.  This is not one of them.  You know why?  Because their library is built on top of libusb.  So there isn’t even anything special going on.

Now, FTDI’s MPSSE library also has an initializer named my_init.  So you can’t statically link the libraries in.  Dynamic linking links cleanly, but the program doesn’t work.  And as it turns out, you just send MPSSE commands to the serial port once you put it into MPSSE mode.  So libraries are being duplicated now.

So what can be done to fix this problem?

Well, it’s very simple.

You can link shared libraries to each other.

So, when creating libFTD2XX, FTDI should remove the initializer, and pass in -lusb to the linker.  Sure, those of us who link to the library may also have to link to libusb, but it’s a small price to pay to be able to use the software properly.  It also has the nice side effect of having a linking error when compiling, instead of a runtime segfault in the initializer which would happen with earlier versions of the library.

Dec 04

Linux & Simplicity

A while ago, I posted some thoughts on Linux installing.  Just today, I came across this blog post, which covers kindof the same things.  The problem that seems to exist now is that there are multiple ways to do things.  Not that it’s a bad thing; but there’s no real standard way to do it.  Everybody wants to come up with their own way of doing things, as commented on in this article.  New tools are fine, but what should be happening is have these new tools simply provide new ways of accessing/modifying information, not as replacements.  Why is there a separate service that runs for adding users?  That utility has existed ever since UNIX came around.  It’s impossible to actually figure out what file is actually being used at any point in time.

This lack of standardization is really killing me here.  Just today, I was trying to install gnome-common for some development work, and it put it in /usr/local/share/aclocal.  Which is fine, except that the way aclocal is configured on Ubuntu 12.04 it should actually be /usr/share/aclocal.  WHY IS THIS DIFFERENT?!

This is, again, where Windows is better.  Each program has its own, special folder, typically in Program Files.  All the .exes, dlls, images, etc. go in there.  It’s essentially a self-contained unit.  You have the system registry to tell you information about programs, some variables needed, and where they are.  Granted, the system registry is abused quite often.

So, here’s basically what I think needs to happen:

  • Programs should have their own folder that they store all of their .so, executables, images, etc in.
  • Paths need to be better defined, i.e. where to put something, does it go in /usr, /etc, /local, what?  Currently, programs are scattered all over the place, and shared libs also
  • The only shared libraries that should go in the shared library folder(i.e. /usr/local/lib ) are actually shared libraries,  stuff that is used by more than one program.  If you use it only for your program, that goes in your program folder
  • There should be some kind of registry.  This would probably hold information like where to find something, and would essentially be an extension of environment variables, but for all users.  For example, let’s say that you have two different daemons that provide some service.  This registry would point at the daemon that you want to use – as long as their APIs are standardized, it shouldn’t matter which one you’re using.
  • APIs need to be standardized.  There doesn’t seem to be one “true” way to do anything.  As we can see, you can use one of several interfaces to do the same task, which all do something slightly different.

Maybe this would be a good time to split off something new from Linux.  In addition to doing the above standardization, this is also what I would like to see:

  • Get rid of X.  Sure, X is fine and all, but maybe Wayland would be better?  X is annoying to use, and it was designed for something else than what it is being used for now.  Something simpler, with built-in support for modern APIs(such as OpenGL) would be great.
  • Get rid of the SysV init interface.  Use Upstart instead, completely deprecate it.
  • Any new programs and APIs should not replace old programs, such as useradd or usermod.  They should simply provide a new way of doing it.

Well, that’s a mostly disorganized post.  Braindump complete.