To select an item in a list view create an LVITEM structure, change a few of it’s fields and pass it to LVM_SETITEMSTATE:

// Select current item in the list
LVITEM item = {0};
item.mask = LVIF_STATE;
item.state = item.stateMask = LVIS_SELECTED;
SendMessage(mhProductList, LVM_SETITEMSTATE, mCurrentSettings, (LPARAM)&item);

Oh and if you’re trying to turn on whole line section you’ll need to use the extended styles:

// Set extended styles
SendMessage(hWndListView, LVM_SETEXTENDEDLISTVIEWSTYLE, 0, LVS_EX_FULLROWSELECT);

"--start-group", "--end-group", aternatively "-(" "-)"

See the man page for LD for more info

Unfortunately this argument comes with the following little warning:

Using this option has a significant performance cost. It is best to use it only when there are unavoidable circular references between two or more archives.

The particular case I was dealing with was the havok version 6 libraries on linux. I was advised that there may be way to link them but hadn’t been worked out. In order to test this theory I hacked together a little bit of ruby to show library dependencies. I feel this may be of some use to someone else so I present it here:

require 'find'

$symbs = {}
$archives = []

class Archive
    attr_reader :name, :symbs, :depends, :undef
    def initialize name
        @name = name
        @symbs = {}
        @undef = {}
        @depends = Hash.new(0)
    end

    def add_definition loc, name
        @symbs[name] = loc
        $symbs[name] = self
    end

    def add_undefined name
    @undef[name] = 0
    end

    def resolve_undefined
        @undef.each do |k,v|
            archive = $symbs[k]
           if not archive or archive == self then
                next
            end
            @undef[k] = archive
            @depends[archive] = @depends[archive] + 1
        end
    end
end

Find.find('.') do |path|
    next if not /.a$/.match(path)

    io = IO.popen("nm #{path}")
    archive = Archive.new(path)
    $archives << archive
    while (str = io.gets) do
        case str
        when /\w+\.a/
            archive = Archive.new(str)
            puts "archive: #{str}"
        when /[A-F0-9]+ [A-Za-z] \w+/
            parts = str.split
            archive.add_definition parts[0], parts[2]
        when /\s+U\s+\w+/
            archive.add_undefined str.split[1]
        end
   end
   puts "processed #{path}, #{archive.symbs.count} defined, #{archive.undef.count} undefined"
end

$archives.each do |archive|
    archive.resolve_undefined
end

$archives.sort! {|a,b| a.depends.count <=> b.depends.count }

puts "dependency list:"
$archives.each do |archive|
    puts "#{archive.name}: #{archive.depends.count}"
    archive.depends.each do |depend,count|
        puts "    #{depend.name}: #{count}"
    end
end

The final solution was to simply remove the object files from the static libraries and put them into a single combined library:

rm *.o
find . -name \*.a -exec ar x {} \;
ar rcs libHavok.a *.o
ranlib libHavok.a
rm *.o

The quote at the beginning of the article is perfect:

     Procedural code gets information then makes decisions. Object-oriented code tells objects to do things.
     — Alec Sharp 

This is a great example of taking a complex concept and boiling it down to one phrase. That is something that I try to do as much as possible. It forms a great foundation for effective communication.

Recursive Make Considered Harmful Google HTMLized Version

Also the discussion page is full of gems.

The DSL that I’m using is pretty small right now, which lends itself to easier understanding and explanation.

Ruby code tarball can be downloaded here.

A FSM is defined in a ruby script file without any class definition using the following rules:

1. All attributes are specified in a method named ‘setup’. Setup takes an argument hash which may contain arguments that can be used to setup a FSM entity.
2. All states are specified by defining top level methods with the name ‘while<statename>’. These methods are called in a tick update while that state is active.
3. All transitions are initiated by saying start :statename

def whileidle

target_nearest

start :chasing if @target

end

World#load uses the Object#instance_eval method to evaluate the contents of the FSM definition in terms of a FSM base instance. The FSM class defines some methods that can be called within the FSM definition to control state transitions and to access common methods.

Practically speak this is a very simple way to enable easy extension of a system. It provides an easier path to refactor the individual state machines and lowers the barrier to entry for writing state machine code. Additionally, it would be nice to include certain types of behavior from modules so that state machine authors could have easy access to some of the methods currently defined in creature FSM. This would include methods like target_nearest.  You could also mix in native C modules to get access to things like a path finding grid.

Ideas for playing with the code:

1. Make creatures pick up the ‘ammo’ entities
2. Make creatures compete for the ‘fark’ entities
3. Add a new term to the FSM for state transitions. The method names should be named ‘whenchangingfrom<statename>, whenchangingto<statename>, whenchangingfrom<statename>to_<statename>’ and should be executed when those state change patterns are matched.
4. Allow entities to die

A great article about some of the different types of DSL creation and the mindset from one of the coders at 37signals:

http://weblog.jamisbuck.org/2006/4/20/writing-domain-specific-languages

Careful of using missing_method, it bit me in the arse a number of times:

http://redhanded.hobix.com/inspect/theBestOfMethod_missing.html

It’s really hard to track down bugs related to methodmissing, any code you write inside an object implementing this needs to be carefully checked. It can also lead to blowing your stack when an error in methodmissing recalls method_missing.. and on and on.

This little gem is nice to keep in your back pocket when trying to raise a descriptive exception:

http://blog.nicksieger.com/articles/2006/09/06/rubys-exception-hierarchy

When I was first starting out in my career I relied a lot on the wisdom of my mentors and peers. This wasn’t a bad descision at all, learning by walking a path made by others is often the easiest way. There were certainly times when I went against the common wisdom and even if it was a dead-end, I still learned a great deal. As a newbie I spent a lot of time in ‘the shop’ trying out one new idea after another. I quickly found that once the first summit is mounted things take on a different look and one must plan their own ascent carefully.

I’m writing this post because I’m tending to forget the why behind some of the choices that I’ve made over the years in style and approach that have become habit over the years. Even though I feel that I’m well into my ascent I still find myself revisiting choices and thinking, ‘now why do I do that?’.

One small thing that just caught my attention is my habit of starting method names with an upper-case. I usually tend to do this more frequently in true object-oriented languages, Java (alghough doing this breaks standard), C#, Ruby, Python and C++ (not even in the same class of OO-ness, still there it is).

The reason that I codified this personal standard is so that I would tend to think of methods more as first class citizens in the object space. When naming methods with a lowercase they tend to be thought of more as values, parts or fields. In fact they are much more, you can think of them as classes of your program space, passing them around, storing them and transmitting them and giving them a proper name more easily promotes the semantics of this type of coding in an environment where usually only classes are capitalized. This was an early descision I made not because of style but to form a habit of something which would form a useful mental model.

Another habit which is more of a constant discipline is minimalization of all code that I create. This has absolutely nothing to do with KLOC or anything silly of that nature, in fact it runs contrary to anyone brought up in that type of coding culture.

As you ascend higher, oxygen becomes more scarce and harder to breath. You will find that code takes on a life of it’s own, sometimes spending more energy is a less effecient way to treach the top.

The code must be minimally specified, it must do what it says and no more. There are some general rules, avoid over branching, tend towards shorter code bodies. Whitespace and comments are more telling than the code they surround. On a larger scale prefer loose coupling and composition over strong interfaces and inheritance. Do not be scared of creating a small library. Prefer pull over push.

The last bit I wanted to write may be a bit controversial with some but I find that when presented two paths, one steep, rocky and trecherous and the other wide, mellow and gradual I always prefer the former. Personally in the long term I would rather look back on a lot of hard problems that were overcome it is much more satisfying for me personally and prepares me for even more technical challenges ahead.

While it’s nice to get rid of distractions, block off big chunks of time and lay out large chunks of work here’s some tips that can help if you work on large teams and just can’t really get rid of all the interruptions.

Keep a pad of paper and pencil by your keyboard. Write your thoughts down and what you’re currently working on. Write down small ideas you have to fix up the code. When you sit down in the morning or interrupted look over your notes to get back on task. If you’re having trouble getting started on some code draw some pictures of what you’re trying to build.

Open your editor. Sometimes all that you need to get yourself started is to actually open the code and look at it. If you’re working on something new sometimes a blank screen in your favorite editor is enough to launch you.

Write unit tests. Unit tests are a great way to give yourself some small bite size piece of code to get the juices flowing. I can’t emphasise enough how good this is for your thought process. This is a way of kicking off the little positive feedback loop that is instrumental in getting you in the zone. You can immediately transition into the code side with the right mindset and at the same time you’re reaping a huge net benefit to your code quality.

Lastly, take real breaks. That is breaks away from your office where you actually get your blood flowing to other parts of your body besides your brain. If you can do some pushups, do a brisk walk or engage in some other kind of physical activity for even 15 minutes you’ll find when you come back to your desk you’ll have a fresh perspective and you’ll feel much better. The endorphins you get from physical activity are great creativity boosters.

Feel free to leave comments if you have any more tips.

autotest.py

It’s very simple it relies on a static list of files and an internal cache of the last modified time via stat(). The tests are implemented using standard pyunit. Any time a test or implementation file is written to disk it re-runs the tests. If you’ve never had a tool like this give it a try and I think you’ll find that it’s an enjoyable way to work.