Archive for category Uncategorized

Build template

Dec 22

Posted by cout in Uncategorized | No Comments

I don’t like make.

The syntax is clunky, the semantics are unintuitive, it’s hard to get parallel builds to work well, and there are a million ways to shoot yourself in the foot.

Nevertheless, I stick with it, because it’s ubiquitous and it’s the simplest solution for what I do.

A simple Makefile might look like this:

all: main
 
OBJS = \
  Foo.o \
  Bar.o \
  Baz.o
 
main: $(OBJS)
  $(CXX) $(LDFLAGS) $^ -o $@

This says main depends on Foo.o, Bar.o, and Baz.o; each of these is built using one of the builtin rules.

I often want some extra build flags for debugging or optimization, so I add:

CFLAGS += -ggdb
CXXFLAGS += -fno-inline

If I’m using GCC and I want automatic dependency generation, I add this:

CFLAGS += -MMD -MP
DEP_FILES = $(patsubst %.o,%.d,$(OBJS))
-include $(DEP_FILES)

Now whenever I build Foo.o from Foo.cpp (or Foo.c), g++ will generate Foo.d at the same time. The next time I type make, it will read Foo.d to determine what Foo.o depends on.

And just in case something gets borked, I usually want a clean rule:

GENERATED_FILES += $(OBJS)
 
.PHONY: clean
clean:
  $(RM) $(GENERATED_FILES)

Now none of this is intuitive (I learned it all from trial-and-error), and there’s a whole lot more that build systems need to do (building shared libraries, finding where libraries are located on a system, etc.), but this really does solve 90% of the problems I hit in small-to-medium projects. I’ve even used a setup like this in a medium-large project (> 200K lines of code) with success.

Please, tell me why I should switch? I despise make just as much as the next guy, but it’s simple, and it works.

Color wiring diagrams

Nov 5

Posted by cout in Uncategorized | No Comments

Whenever I look at a car wiring diagram, I tend to get cross-eyed. The entire thing is usually black-and-white with labels to indicate wire color. When I see a loose wire in the engine bay, it often takes as much as twenty minutes to figure out where in the diagram that wire is located.

But what if the diagrams were in color? Would that not make it easier to locate the wire?

My first stab at this was to sit down with some colored pencils and start coloring away. This actually turns out to be quite relaxing (as one friend pointed out, it’s like kindergarten for adults). It’s not a good way to share the diagrams with others, though, and it’s time-consuming to recolor them if they get lost or damaged. (in my case, I left my binder of 1989 plymouth voyager turbo wiring diagrams on the top my my minivan while driving down a rural highway at 80mph).

This is why we invented computers. Some people may tell you it had to do with codebreaking or physical simulations or the internet, but the real reason they were invented was so we could have our wiring diagrams in color.

Step 1: Download wiring diagrams from here: http://www.oldschoolhotrodder.com/modules.php?name=Downloads&cid=2

Step 2: Load the pdf into acrobat and print it to a ps file

Step 3: Convert the entire ps file to a series of pgm (greyscale) images. The greyscale takes a little more processing time, but the text labels turn out a bit nicer this way.


gs -sDEVICE=pgm -r300x300 -dNOPAUSE -sOutputFile=page%03d.pgm wiring.ps

this will convert every page of the ps file to a file called pageXXX.pgm at a resolution of 300dpi. It should be possible to instead use a bitmap (black and white) at a higher resolution, but I got better results with less processing time using greyscale.

I also tried using greyscale at a higher resolution (600dpi), but this yielded worse quality. Presumably this is because the resolution of the image exceeded the resolution of my input file.

Step 4: I considered writing a script for this step, but it turns out someone’s already done all the hard work of vectorizing the pgm input file. Enter potrace. It takes a bitmap as input and produces a vectorized output in xfig, svg, or a variety of other formats. Beautiful!

I’ll start with one page for now:


potrace -b xfig -o page001.xfig page001.pgm

Coloring it is as easy as loading it up into skencil:

Screenshot-page001.xfig - Skencil

First I select the objects and then ungroup (in the Arrange menu). To color an object, click on it, and select the color. The image above highlights one small problem: potrace decided that the wires that connect in a single dot are a single object. That makes colorizing them a bit trickier.

Two options from here: 1. find a better drawing tool that will let me manually split the polygon, or 2. figure out what options to pass to potrace or autotrace to generate separate objects in the first place.

Tags: ,

A new project

Nov 5

Posted by cout in Uncategorized | No Comments

A difficult and unfortunate truth for any hobbyist is that there is only so much time in a single human lifespan. I have wanted to continue to play with JIT compilation, not only because it is useful and an interesting mental challenge, but because it’s a great way to disconnect from the world. Sadly, time does not permit this to happen.

I hope to one day again come back to the hobbyist programming world. It was a difficult decision this year to not attend RubyConf for the first time ever (until this year, I was one of four remaining nine-time attendees). But all good things must come to an end, and ends make way for new beginnings. In my case, new beginning include racing in the 24 Hours of Lemons, building a minivan drag car, and the possibility of entering medical school.

As for the minivan, I would like to make it ruby-powered. K-cars (including the caravan/voyager) are really simple machines, and for a few hundred dollars, every sensor in the vehicle can be datalogged. This is a must for building reliable power: if the engine is not running efficiently, then it’s not producing as much power as it potentially could; worse yet, at high boost it could damage the motor. (yes, you read that right — this minivan has a turbo).

Datalogging a drag-run should be straightforward. I’ve never done anything like this, so what sounds simple when I read about it may turn out to be a PITA. But once I get the datalogger hooked up, how much fun would it be to write a ruby library to intercept the data in real-time? And how much more fun would it be on top of that to visualize this data in real-time using an opengl frontend? Lastly, how slick would it be to take this opengl display and project it onto the windshield ala a heads-up-display?

I’ve wanted to get back into graphics programming for quite a while; now I have an excuse. All I need now is some spare time.

Tags: , , , , , ,

Converting stack-to-register

Dec 20

Posted by cout in Uncategorized | 2 Comments

Like many other virtual machines, the YARV machine is stack-based.  Because most modern CPUs are register-based, to compile YARV bytecode to efficient native code means the stack operations need to be converted to register operations.

Ludicrous does this by walking the instruction sequence and pushing and popping value objects onto and off of a stack at compile-time.  This completely eliminates the YARV stack (the machine stack is still used by libjit as necessary), but has some limitations: all control paths must produce an identical stack.  A conditional that produces a different size stack in one path than in another will break this scheme.

Ludicrous does its best to detect this situation if it ever comes up and will refuse to compile bytecode that tries to do evil things like this.  However, I recently discovered a case that wasn’t covered:


irb(main):001:0> require 'internal/method'
=> true
irb(main):002:0> def foo; return true ? 1 : 2; end
=> nil
irb(main):003:0> puts method(:foo).body.body.disasm
== disasm: <RubyVM::InstructionSequence:foo@(irb)>======================
0000 trace            8                                               (   8)
0002 putobject        1
0004 jump             8
0006 putobject        2
0008 trace            16
0010 leave
=> nil

Here YARV has made an optimization — true is always true, so a conditional branch is unnecessary. However YARV wasn’t smart enough to remove the dead code that pushes ‘2’ onto the stack. When Ludicrous compiles this, it gets confused because at the leave instruction the stack contains [ 1, 2 ] (remember that Ludicrous evaluates the stack at compile time).

I suspect this is a bug in the YARV optimizer, but it illustrates the case — converting code written for a stack machine to run on a register machine is no trivial task. I’m not sure yet how to handle this case. All control paths (there is only one) do produce the same stack, but Ludicrous does not have a mechanism to detect that the second pushobject instruction is dead code and does not modify the stack.

Perhaps the best solution is to raise an exception and fall back on the interpreter for functions that do this.

Tags: , , , , , ,