I Love Tcl

So, I have been grinding through a lot of GUI code (NewStars update coming soon!)...

In the process, I have been shifting code from C++ to direct XML access. Part of this involves something called "XPath" (which I had never heard of before).

The key is, you can query an XML document like a database (including wildcard and logical test patterns). So, if I want the node with the planet with object id stored in variable 'pid', I can do:

set n [$nsGui::turnRoot selectNodes //PLANET_LIST/PLANET\[OBJECTID=$pid\]]

'//' means a relative search (not necessarily from the root). I need "PLANET_LIST" because there is another list of planets, called "UNIVERSE_PLANET_LIST". The outer square bracked "[]" are part of Tcl (execute this part, and resolve it to the string that is returned). The inner (escaped) brackets are part of XPath (return nodes which satisfy "[logical_condition]").

Of course, any language can support XPath. But, in Tcl, I can open a console session, source the stars.tcl, and start issuing XPath commands against the turn file. That allows me to rapidly tune my request to get the results I want (eliminating the compile/re-run steps). Especially since the W3C XPath docs are unreadable...

Then, once I have the planet node, I can pick off attributes:
set concs [$n selectNodes string(MINERALCONCENTRATIONS/text())]

That replaces:
set planXML [xml2list [newStars $::ns_planet $id $::ns_getXML]]
set mainXML [lindex $planXML 2]
set cargoXML [findXMLbyTag "CARGOMANIFEST" $mainXML 2]
set tuple [lindex $cargoXML 1]

Especially since that used "xml2list", which can't always parse some XML...

Const Fail

I only recently discovered an oddity in the C++ "const" feature. Consider this code:

class Foo
{
 int *i;

 void foo(void) const
 {
    *i = 4;
 }
};

(I've left out some boiler plate)

Anyone see it? A const function is changing the state of the object!

Oops, turns out C++ const is not "transitive" (the D docs call it "head const").

This bit me big time on my previous project. To the point that I developed a "const pointer" class to wrap all my pointers (only got partially deployed into the project).

D 1.0 lacks const (because it is hard to get right, witness C++). D 2.0 wants const done right.

Also, there is a great slam on Java and const. (I can't help myself when it comes to slams on Java! :) Yea, no const for you Java-kins!

New Stars Status

I've been struggling with whether to extend the regression, or to get things into shape for a pre-Beta test. I like the regression (being repeatable and all), but it takes as much work as playing the game (more, since I have to play both players).

Of course, shaping things up for a live test requires different sorts of GUI programming...


Here we can see the major changes:

• I added the icons for two of the planet views (ship view - mostly implemented, and planet value view - next to be implemented)
• Lots of production queue stuff...
• Shift and control with Add/Remove (10 and 100 respectively, 1000 together). 889 = 1000 - 100 - 10 - 1
• Added "End of queue" (add is "add before", so we need end - original Stars uses "add after", oops!)
• Fixed quirks in selection (previously, I deleted the queue and reconstructed it from the current orders - now the C++ code communicates queue changes and the GUI selectively rebuilds the view)
• Added a binding to the "q" key
• Fixed a bug related to pressing "Change" queue button multiple times

Fixes that can't be seen here:

• Fixed a bug in the max usable factories calculation (population was divided by 1000 instead of 10,000 before multiplying by race factory operation factor)
• Fixed a typo in the component map for Interspace 10. This caused a Tcl error when opening the Ship Design Wizard for players with that access to that component.
• Fixed key bindings for '-' and '+' on the numeric keypad (linked to zoom) for Linux. On Windows, <plus> and <minus> catches both versions. On Linux, the keypad keys generate <KP_Add> and <KP_Subtract>. May be an X server thing...
• Fixed transport amount carrying over between different fleets (and players!). The most confusing thing was - a player could order a load 2500 colonists, save and load another turn, and see that load 2500! Except, the order wasn't given, so they'd launch with no colonists! Ops!
  
• Unlinked open file command from "Find" operations (it was intended as a place holder, I find "" makes a better one!)
  

I'm pretty sure there is a bug in "Remove" multiple, when there are not enough to satisfy the remove (for example, remove 1000 - when there are only 999). The remove will probably remove more stuff, until the count is satisfied! I will fix that...

I also need to implement the hab view.

And fleet split/merge. Fleet numbers. Fleet (friendly and other) and planet list.

Stuff I've read lately

"The Sovereign Grace of God In Salvation" (John Roden) - Reviewed on my faith blog.

New Stars Status

BOOM!



Further work on the battle VCR.

First, I ran through this battle in the original Stars, and noticed that the Warmonger Armed Probe should be crossing the board faster. I found that the Warmonger did not have his +.5 move bonus. Fixed.

That gave me a test case for a "FIRE" token in the battle report (missles still not supported).

I also updated the selection logic, so that changing the current event (next and previous buttons) selects the acting token.

Stuff I've read lately

"Murder in the Solid State" (Wil McCarthy) - Interesting pun. When you think of "solid state" you think of "state of the art" and "cutting edge". But, in the age of nanotech (full of tiny machines and their moving parts), "solid state" is the failure mode (your tiny machines have jammed)!

This book is a murder mystery. Things go pretty well (very suspenseful) for the most part. Although, the ending was a little confusing and unsatisfying.

Stuff I've read lately

"The Sky Road" (Ken Macleod) - Wikipedia says that this book presents an alternate time-line in the "Stone Canal", "Cassini Division" series. I'm not so sure. It's certainly not obvious. One character, "Ellen May" seemed younger than I remember, but I can't be sure. The "Sheenisov" are still marching across the earth, and the "tinker" society seems a believable precursor to the communes in "Cassini". Overall, ok. I still like "Cassini" the best.

"Why I am So Wise" (Friedrich Nietzsche) - Reviewed on my faith blog.

Aluminum + 1000 resources

= Space Elevator! (thank you Civ 4). Of course, if you build in in the city with the Iron Works (excellent Texas barbecue results in double resource output!), it's only 500 resources; a good city can do that in ten or eleven years.

I've been following discussions on building a space elevator for some time now. I was surprised to see CNN discussing it!

There are two primary challenges connected with building a space elevator:

1. The cable (or tether) - Spans 100,000 kilometers from the surface of the earth, up past geosynchronous orbit (the center of mass is at the geosynch point)
   
• This cable need not be one single piece. This is a confusion many people have ("We can't build a carbon nanotube that long!!111eleven!").
• The cable need not be of super materials (100% carbon nanotubes, positronium, etc.) You can make it out of bubble gum, although you'd probably need enough to alter the center of mass of the earth-moon system :)
• Better materials translate into less mass for the initial tether. That means fewer rockets to get all the materials into space.
• Once the initial tether is up, the first cargo can be more tether, to increase the capacity of your elevator (and build new ones).
  
2. The cars (or climbers)
• The tether does not move, instead, the cars pull themselves up or down.
• The climbers are actually the hard problem!
• They must travel the hundred miles or so into the edge of space, and possibly, the 36,000 km to geosync orbit (especially if they are going to be used to add on to the tether).
• It is unlikely we will want to carry enough fuel for a 36,000 km journey (at 200 mph, that's about a five day trip - one way).
• That means we need a means of power distribution to generate power on the ground, and get it to the climbers (most likely lasers and solar panels).
  

The dangers of the space elevator (terrorist attacks on the base, the tether, or the geosync station) are largely exaggerated. Breaking the tether would cause pieces of it to burn up or fall to earth. It is relatively small, and would do little damage. If the base were destroyed, the tether would slowly rise (there is slight pressure up, to keep the tether tight).

The hazard to lower orbiting satellites is more than offset by the increased launch efficiency. (There would need to be a workforce assigned to pushing satellites out of the way, or a way to shift the tether around them - such a shift might even be useful in dodging meteors or terrorist suicide attacks).

The good news is that the space elevator used to be considered a tech level 9 or 10 achievement. It appears, it will be completed easily within the tech 8 time frame.

C-piphany

(rhymes with epiphany)

At some point, I realized why C++ is so unwieldy.

It is really three (or four) different languages:

1. Macro preprocessing language. #define, #include, etc. Mostly deprecated in C++, except for #include, and #ifndef protection in header files. Except when someone drops 300k lines of 15 year old code on you, and it is filled with all sorts of "horrors man was not meant to know" (TM).


2. Base C language (and C++ extensions, which can be considered a language unto themselves). What we normally think of as the language, with declarations and operators. I think this is where C++ shines, with lots of tools to wedge things together (operator overloading, references, etc.).


3. Template programming language. This is needed for the standard library (arrays, etc.). Except, it becomes all to easy to start coding everything in templates. Then, you're hardly using C at all. It's all bizarre template stuff. It's all in header files, and it's all ugly and hard to understand...
   

Hopefully D fixes this. I know the macro preprocessing is gone (integrated into the language). The D template syntax looks much cleaner.

Stuff I've read lately

"The Stone Canal" (Ken Macleod) - This is the precursor to "The Cassini Division", which I read first. I find it didn't add much, although it was ok.

"Why God Won't Go Away" (Andrew Newberg, Eugene D'Aquili, Vince Rause) - Reviewed on my faith blog.

New Stars Status

Big landmark! The Battle VCR!



It also includes the battle report window (very small, just left of the top of the VCR). This allowed me to find an interesting bug. Scan was comparing pointers, so the same ships were getting scanned over and over.

I also added the detailed scan for ships in battle (still need to make this the behavior for WM scans).

This check-in also includes a top level Tcl XML DOM. That's a complicated way of saying Tcl now has access to the parsed XML file at any point. Previously, it required C++ to parse the XML, and could only query the XML for individual objects. This should allow me to migrate to an all Tcl client (or at least one independent of server code).

The Horror, the Horror

(Continuing my rant on g++ 4, which is a part of my musings on D)

Ok, take the code from last time, and add this after the "class Par" definition:

template<typename T>
class Child : public Par<T>
{
public:
void fun(void)
{
   x_ = 4;
}
};

This code should compile on on gcc 3.4 or in Visual Studio. g++ 4 gives the following error:

main.cpp: In member function 'void Child::fun()':
main.cpp:22: error: 'x_' was not declared in this scope

Err, excuse me! x_ is inherited from the parent. Just look, it's 'int x_'. It's protected, that means it's visible to any children! How can I fix this! I don't know what to do!

After about five minutes of careful Googling, I found a site that seems to understand what's going on. They say:

"The C++ standard prescribes that all names that are not dependent on template parameters are bound to their present definitions when parsing a template function or class."

There is actually a good reason behind this. People were having problems where templates were full of buggy code, but no one knew it until you tried to use them (because the compilers were just turning off error checking when interpreting template code). So now, compilers are trying to understand the template code, and check it for errors. The only problem is good code is now wrongly flagged as erroneous code. Oops!

There is a fix:
this->x_ = 4;

Ok, I can see how that helps the compiler figure stuff out. However, it hurts my brain... If somebody else sees this code (and isn't familiar with this change in the compiler, like say they've been programming C++ for the last ten years and never seen it - like I was until this week) they are going to say, "Oh, that 'this' isn't needed. I'll just remove it." Let's say it's in some utility header (like a good template should be). And that it takes an hour to recompile (like my project does). And they change a lot of other stuff before starting a full recompile (because you don't want to wait an hour between every one line change). And then they get that bizarro error. Yea, they're gonna be mad. And they're going to have to back track through all the changes they've made, google for the page above (assuming they can find it, I only found it by looking for "two stage name lookup" - yea, that's intuitive), and recompile another hour or two.

Enjoy! :..(

Note: apparently, it went into g++ 3.4, only 3.2 is safe!

c++->fail()

(Continuing my musings on D)
(that code actually works, try (assuming C has a method fail):
C cAry[2];

C *c = cAry;
c++->fail();
)

I got bit by several very ugly bugs in g++ 4 this week. This is about code that works in gcc 3.2, 3.4, and Visual Studio. But breaks in g++ 4.

This is because g++ 4 is more closely matching the C++ spec!

See below for the exact code.

The first problem is mixing implementations of template member functions. This might be because you need to specially handle certain types (like strings), while having a generic implementation for the standard types (int, bool, float, etc.).

The notation in pre g++ 4 is straightforward (if ugly)

returnType ClassName<SpecificType>::functionName(args) { specific implementation }

and

template<args>
returnType ClassName<args>::functionName(args) { generic implementation }


When I compile under g++ 4, I get this error:

main.cpp:16: error: too few template-parameter-lists


In the code below, line 16 is:

void Par<std::string>::fun(void)


Well, there is the template parameter! Right there! "std::string", it's string! What more do you want from me!

Here is the working code:

template<>
void Par<std::string>::fun(void)


Oh! Of course! Duh! I should of known that. The earlier code was obviously so ambiguous that only every compiler before g++ 4 could figure it out. I'm so glad they fixed that for me!

Here is the total code:

#include <cstdio>
#include <string>

template<typename>
class Par
{
protected:
 int x_;

public:
 Par(void) {}

 virtual void fun(void);
};

void Par<std::string>::fun(void)
{
 printf("String ver\n");
}

template<typename T>
void Par<T>::fun(void)
{
 printf("Generic ver\n");
}

int main(int argc, char **argv)
{
 Par<std::string> p1;
 p1.fun();

 Par<int> p2;
 p2.fun();

 return 0;
}

Stuff I've read lately

"The Cassini Division" (Ken Macleod) - This is actually the third book in a series. I am really enjoying Macleod. His writing is reminiscent of the "good ole days" of science fiction; with big ideas and epic happenings. And there is a good amount left to be mined here (Cassini is from 1998). Stross is writing too much fantasy (Merchants), and horror (Atrocity Archives). Scalzi has just gotten started.

The Cassini Division is a military unit stationed near Jupiter (and, apparently, a gap in the rings of Saturn). They are charged with protecting Earth (and the orbital settlements) from "post-humans", a group of people who uploaded themselves into computers and set off runaway technological progress (the "singularity").

Macleod has an interesting take on the STL/FTL problem. He uses the "hard" sci-fi notion of wormholes (paired creations, which must be moved apart at STL). However, he also allows that the moving end of the wormhole keeps its own time frame - thus, you can travel 10,000 light years (to a point 10,000 years in the future) fairly soon after the wormhole is created. Interesting stuff.

Decoys

(Continuing my musings on D)

Garbage collection:

• Although it's always fun to mock people who fail due to memory leaks while using a garbage collected language...
  
• I think D simultaneously defeats C++ and Java/C# here...
• But, but, C++ has garbage collection libraries! Yea, in ten years of programming I haven't used a C++ garbage collection library. I have used Purify, Valgrind, and even overloading new and delete; looking for memory leaks (not to mention the NewStars code is loaded with memory leaks...)
  
• Java has garbage collection, and only garbage collection - unless you use Embedded Java, then you get no garbage collection! Enjoy!
  
• D "makes the easy case work". The default is garbage collection, with overrides for self-managed memory (of various forms).

Built-in documentation:

• Doxygen ('///' and '/***/') works on C++ and Java (it's an extension of JavaDocs)
• However, it needs to run as a separate step of the build.
• This can be confusing. For example, I ran the debug build, and didn't see Doxygen (although it might be in there, with make spewing thousands of pages of output...). Some of the code uses it, some doesn't. So, I started converting everything to not use it (it's ugly and confusing, if you're not going to generate the docs). Until I discovered than there is a build that does use it (and the code not using it, needs it)
• Less ugly Doxygen style comments are built into the D spec. There is a compiler switch to do the docgen run.

Design by Contract (DBC):

• Programming is all about assumptions. When writing new code, you've got some idea of what's going on in the program, and what the inputs will be, and what sort of outputs you can create.
• Of course, assumption are made to be broken. That's why I'm always sprinkling my code with plenty of 'asserts'.
• DBC formalizes all of this. 'assert' is part of the spec (rather than being an ugly macro). Also, there are 'in' and 'out' blocks for functions (to check inputs and outputs). Classes have 'invariant' statements, which are processed before and after functions (to ensure class invariants are maintained).
  

Duck Hunt

(Continuing my thought process for considering a new language)

Nine to five, I hack C++. Not just any C++. Imagine hundreds of thousands of lines of code, spread across dozens of directories in a twisty maze. Make takes from twenty to thirty minutes (that's a parallel make, serial is over an hour), and sometimes fails in odd ways.

The program has to run on about five different compiler/platform environments (Windows, plus various forms of UNIX - including a Sparc).

Over the past few weeks, I've been running into all sorts of nasty C++ problems (weird template problems, compiler mismatches, spaghetti recompilation).

As I've been looking for solutions to the problems on the Internet, the C++ Frequently Questioned Answers keeps coming up.

The guy makes a lot of good points. And I started to wonder, does he have some constructive recommendation (besides, "Don't use C++").

It's called D.

I think, what I'm looking for isn't Python or Ruby to replace Tcl. I need something to replace C++. With features like Python or Ruby (rapid development, functional programming).

That's D.

Things are still a little fresh (spec is rapidly moving, environment issues). But considering that, it is working remarkably well. I mean, C++ is way older, and still has issues!

A good place to start is with the overview.

New Stars Status

Finally getting to the point where I can start on the battle VCR!



It took a lot of bug fixes to get to this point...

• Implemented ship to ship scanning
• Fixed bug causing battle messages between fleets the player owns
  
• Fixed a bug where planets could not see enemy ships in orbit
  
• Added a speed spinner to fleet move orders
  
• Fixed a bug when right-clicking on mixed friendly and enemy fleets in one point
  
• Fixed a bug where some fleet GUI items would appear in view planet mode
  
• Fixed widths of some widgets to fix jumpy universe view size
  
• Added previous and next buttons to the message pane
• Removed ship object id from ship names (just in fleet)
• Improvements to the scripting interface

The JOAT player is pretty well into colonizing a second planet. The War monger has no orders beyond scanning...

The battle was really anti-climatic. The current battle engine has the JOAT scout escape without a shot fired. I will need to investigate that outcome...

Need a New Duck

And show me how to get down
How to get down baby
Get it?!

Quack, Quack, Quack!

I've probably forgotten more about programming languages than most people know (since most people know zero programming! :)

Basic, Pascal, Visual Basic, C, C++, Perl, Verilog, Java, various assembly languages (including PipeWrench, don't ask), Awk, Tcl, Lex, Yacc, ML (which we all thought stood for "My Language"), VHDL.

At this point, I've pretty much settled on C++ and Tcl. (plus Perl for text processing).

Tcl is great for rapid development, and GUI design.

C++ is great for interface definition, large projects, and general hacking. I don't know Bjarne's background, but it must include a lot of hacking.

But I've been getting the feeling I need a new language.

I tried Ruby. But "everything is an object" doesn't seem any better than "everything is a string" (Tcl).

I've played with Python, but again, it doesn't really replace Tcl for me.

I've used Darcs, which is the poster child of Haskell. That's pretty much turned me off that... The other functional languages are even more obscure.

Erlang seems to have potential for the multicore future. But it seems to be different in annoying ways, "just cause".

Stuff I've read lately

"The Birth of Christianity" (John Dominic Crossan) - Reviewed on my faith blog.

"Patriots" (David Drake) - Not your typical Drake. Ok, but more character focused. He should stick to tanks and such :)

New Stars Status

Trying to work up to a battle in the two player game. I am trying to actually walk the players through their turns as they would be doing them (i.e. spending a lot of time micro-managing).

Part of that is implementing the "accelerated BBS" option (so I don't have to generate 30 turns before reaching colonization pop).

Then, I added the research tax option (visible in the dialog below). This uncovered several bugs in communicating this information from the player file to the server.



I also fixed the scanner pane so that it resizes itself to fill up the window. There is a somewhat annoying flicker as you click from explored to unexplored planets (due to different widths on the left)...

I also found/fixed a bug for JOAT w/o IFE getting Quick Jump 5 instead of Long Hump 6 (IFE properly gives the Fuel Mizer).

As well as a bug in the growth formula when planets exceed 25% capacity (aided by AccBBS).

Interesting note, on Linux, the two players are right next to each other. That means I can use it for some quick battles (and I need to fix the homeworld placement logic...)