First, the good news: I've made a new release of WinROTT. It was a difficult release, involving multiple files. I ported the actor and action table functions to cpp.

Second, the bad news: I've been morbidly watching the economic reports and the stock market. I'm wondering where all of this will end up. I am amazed at the number of so called investors that think they can all wait for the stock markets to react rationally and start going back up. I don't think it will work this way.

If 90% of investors are waiting gleefully for capitulation so that the market will go back up, then we have not reached capitulation. In fact we are not close to true capitulation in the real sense of the word. The market will not allow 90% of investors to be winners and 10% to be losers. Investors watching patiently don’t realize they are simply marking time until they too, reach a state of panic. In an expanding market, it's not a zero sum game; in a contracting market, it rapidly approaches a zero sum game. (I wish I had paid more attention to my one and only course in game theory so I could explain this a little better.)

If every investor is using the same playbook, executing the same strategy and expecting the textbook outcome, then the outcome will be different. I am not too sure of the math, but I am pretty sure that the greater the population adhering to actions that should cause a particular outcome, the less likely that outcome will be obtained. In a zero sum game, you are not likely to have an outcome where 90% of the players "win".

In this market, the only thing we know is that it is not like anything any of us have seen in our lives.

I've run into an interesting problem with the WinROTT port. WinROTT using structures similar to the following to control single user enemies:

When moving to C++, you need to be aware that the following assignments are allowed in C, but not in C++:

The way I changed the code is to cast everything to a void pointer, and then make sure a cast exists in the function to correct the variable pointer type. There are about 160 of these functions. It turned out to be quite tedious and error prone. If you get on a roll with cut and paste, you are likely to create more problems that you solve.

Thank goodness for the weekend. This was a long work week. No horse shows this weekend, but my wife's bell choir is playing at church, so it means an early rise this Sunday. My daughter's been busy with 4H and homework. I basically have avoided all work, watched football, worked on WinROTT and generally lead an unhealthy lifestyle of fatty foods and no exercise - felt good to goof off. I cheered Alabama's victory over Mississipi state. I cheered for Troy, but LSU came back.

I have some good news on the WinROTT port. It looks like I only have 18 .c files to complete. I'm looking forward to being able to get started on some C++ housekeeping chores after the port of all the component files are complete. The old C code interchanged pointers and integers in most parts of the code. There are a lot of places where an integer is used to hold a pointer to the screen buffer. When I ported rt_game.c, the conversion logic doesn't work correctly and the status bars appear garbled in some instances. I decided to hold off repairing the status bar code until all of the .C files are ported and I can get rid of all the extern "C" declarations. I made this decision due to a variable initialization problem I've run into when mixing blocks of variable declarations and initializations around extern "C" blocks. I'll try to post what I have tonight.

I've been able to make quite a bit of progress converting C modules to C++ modules in WinROTT. Most of the problems I encounter at this stage are missing link symbols. It is time consuming rearranging code and inserting extern "C" blocks. As always, testing consumes the most amount of time. I hope to have a significant (to me) release this weekend. I am down to about 30 modules that need converting. This is down from roughly 60 when I started.

I've had a couple of inquiries regarding my porting strategy. I employ a concept of "least dependency" when selecting modules to move over to C++ from C. In practice, you simply choose the last C module in the compile process. In theory, the last C module to compile has the fewest dependencies and should require the smallest amount of fixes for missing symbols. The occasionally doesn't work, but it's simple to implement. I try to never port more than one module between testing. For me, testing entails playing several game levels to verify code execution. When I complete the C to CPP migration, I want to implement some unit testing, which should significantly speed up future modifications.

When the migration is complete, I intend to scrub the code of extern "C" blocks and create proper header files for the modules. Currently, the code has a number of places where I simply threw in the function prototypes to get the code to compile and execute. You'll often see multiple prototypes for the same function included in the source. This is a result of not having proper header files that can be included as needed in source modules.

I managed to get my bugs cleaned up in beta_rcomp. There's a new release for download here.

I'll publish some notes on the problem I had with beta_rcomp. My daughter had a horse show this weekend and I am just gassed this evening. I'll try to publish my findings in the next day or so. What I found while trying to get rid of some goto statements may aid future program ports.

I made a heartbreaking discovery last night. I've been working on a new release of dcdflib, with significant rearrangement of several routines to remove labels and goto statments. I had been performing limited testing and I was also checking in often. It's a slow process, it's easy to make a mistake and when you're tired, shortcuts are tempting. I took a testing shortcut after modifying beta_rcomp. I only tested a couple of subroutines in the demonstration program, thinking I had covered all routes that depended on beta_rcomp. I missed a dependency.

I was in the process of cleaning up the code when I ran a complete test set in order to review the entire output.  Right off the bat, I noticed two errors in routines I knew I had not touched. A little manual checking and I saw the dependency to the function beta_frac, which calls beta_rcomp. Drat.

Fortunately, I was able to review the source check-ins and located the problem. I was able to paste in the unchanged version of beta_rcomp and the program produced the proper output. beta_rcomp is fairly complex, and it was disappointing to lose my changes.

The moral of this story is:

Don't skimp or shortcut your testing and check in your source code often. I could have lost several days worth of changes with this bug. Instead, I only lost one routine, which I should be able to trace through and repair.

Update

Even if you are working on public code, you need to have a test plan. It's hard to maintain discipline 100% of the time, but you still need a plan. When things go a little wrong, like they did for me, the plan can help you get back on track.

You also need to check in often. I can't tell you how much more secure you will be in changing your source code if you practice good version control technique. I always check in after a full test. I don't like going days without checking in. It takes time, but it also enables other people using your software to trust your work more than if you are just cowboy coding.

The American Republic will endure until the day Congress discovers that it can bribe the public with the public's money.

- Alexis de Tocqueville

The only problem with this statement is, the American people seem not to care.

- Gene Harris