Stuff I've read lately

"Vorpal Blade" (John Ringo) - This is the second book in the series starting with "Into the Looking Glass". Ringo is doing an excellent job of building up a rather unique space opera universe. Pretty hard SF, with good characters and the right mix of humor (like, a giant alien squid trying to eat their space going submarine!). I'm looking forward to more.

Stuff I've read lately

"The Family Trade" (Charles Stross) - I have been loathe to start in to these, as they are marked "Fantasy". I haven't read any fantasy in a long time (in all starts to be the same after a while). Sadly, Stross seems determined to continue this series...

That said, this book feels a lot like a hard SF version of "Chronicles of Amber" - so, that's good. For example, once the main character gets back from her first "hell ride", she starts planning all sorts of experiments and evidence gathering!

New Stars Status

Some big changes in store (not much visually...)



Here we can see the recent files list. It does not re-sort when you select a previous file (I am undecided whether that is a good feature or if some sort of better LRU might be nice).

I also fixed the C++ code to use 64 bit numbers when interfacing to Tcl. I think that just went in to Tcl 8.4. That will get things ready for the object id redux.

Finally, I fixed the new game wizard to actually generate the turn files when you start a new game. That is much better than having to save out the new game def, switch to a terminal, and do a 'newStars -n', then switching back to the client...

Stuff I've read lately

"Into the Looking Glass" (John Ringo) - This is the first book by Ringo that I have read. It was pretty good. Kind of a mix of David Drake and some harder SF guy (Niven?). The story is about a physics experiment gone horribly wrong. The initial experiment blows up UCF, and starts opening stargates to all sorts of different places. Soon, evil aliens start pouring through some of them. Lots of action. In the end, they have to nuke Eustis.

Ringo had an interesting weapon system, a "quarkium bomb" or "quark ray". The exact mechanics weren't clear, but it was supposed to be more powerful than anti-matter. So, it can't be that the quarks are the direct objects converting to energy at the target (that would be equally powerful). Perhaps there is some way a form of quarks could trigger a chain reaction of disrupting nuclei. That would be scary...

Tcl and Ini files

The NewStars client GUI is proceeding pretty well. I am finally getting tired of navigating from the client start directory to the regression directory (up two! src/testfiles/twop).

This is the implementation for the "Recent file list" in Tcl:

Create the resource file if it doesn't exist, or process it if it does:

if {![file exists [file join ~ $resourceFileName]]} {
   close [open [file join ~ $resourceFileName] w]
} else {
   eval [read [open [file join ~ $resourceFileName]]]
}

The ini file is a series of Tcl statements. That way, I can just "eval" the file to bring it in.

Then to handle saving the preferences:

rename exit origExit
proc exit {} {
   set f [open [file join ~ $::resourceFileName] w]
   foreach n [lsort [array names nsGui::prevFiles]] {
      puts $f "set nsGui::prevFiles($n) \{$nsGui::prevFiles($n)\}"
   }
   origExit
}

The previous files is a map from the numbers ("1" to "9") to full path filenames. I can grab all the set values (which may be none) and write them out to that file.

By renaming "exit", I can trap any point in the program that is trying to exit. That way, I'm sure that the preferences are saved.

Improving C

A lot of programming languages have been inspired by C. I can easily list C++, Java, and D; there's probably more (Wikipedia lists Perl, I think Perl is a very different sort of C - and Python and Ruby feel more like cleaned up Perl. I always thought of JavaScript as more like VisualBasic, which is more Pascal-ish - Pascal being a sibling of C, both derived from Algol). There is a pretty cool family tree of programming languages, which shows Python as independent of Perl. I'm not too familiar with Python...

C is a pretty good language. Developed in 1972, it served as a sort of "cross platform assembly language". It allowed UNIX to spread to many different computer systems and provided fertile ground for thousands of hackers.

The main problem with C is the lack of support for object inheritance (you can actually do object oriented programming, but it is kind of a pain). But to implement object inheritance, you must relax pointer conversion warnings (I'm not sure how strict modern C compilers are on pointer conversion, C is classically very relaxed).

The other problem is the lack of generic programming, sometimes called template programming. This allows one set of code to work with various underlying types. The most obvious application is in basic data structures and common algorithms (vector, map, sort). Sorting through void* and size is kind of a pain...

Language is a Tool

Is it right to make fun of a programming language? I mean, "it's just a tool". That's what everyone says. You don't mock a hammer for not being a screwdriver (although screwdrivers can be usable hammers ;)

Of course, language is more than a tool.

It is also a means of communication, which means that you've got multiple entities involved.

The main communication is from the programmer to the computer. That means:

• The programmer needs to be able to express himself efficiently (in a matter which makes sense to him, in a reasonable amount of time)


• The computer needs to be able to understand (computers are really bad at English! and not just because English is a terrible language for specifications!)

But, programmers also communicate with one another. If I write all my programs in Tcl, not many other programmers can read them. That's a big part of the "more than a tool". If someone develops the "super monkey hammer" that can build a house in a day, but only super-monkey-hammer technicians can change the light bulbs; people are going to be frustrated.

Steam INNN SPAAACE!

So, I've been thinking about the space elevator, mostly about powering the climbers. Everyone seems to be backing laser power (using ground based lasers to shine on solar panels on the climber).

And, I've been reading Ken Macleod's "Fall Revolution" books, which have "steam launched spaceships". I read them completely out of order, so I never got any details. There is a little in "The Space Fraction".

After looking into it more, I found an excellent source. "Steam" propulsion is somewhat of an exaggeration. The recommended propellants are hydrogen and nitrogen. Water is possible, but not optimal.

But pretty cool, for small scale, high volume launch capacity.

New Stars Status

Tada!


A lot of visual changes!

• Fixed a bug in the defenses calculation (max at 100, please!)
• Implemented hab view mode (circles represent current hab value, flags show ownership)
• Fixed unexplored planets to show gray (both views)
• Fixed the bug I knew would be there when removing too much
• Fixed a bug when adding multiple items to the top of the queue (visual bug, data was ok)
• Fixed the mineral labels to be colored (iron - blue, etc). I made the germanium one more gold than yellow. I find that yellow hard to read...
• Added view planet window (shown, missing mining rates, capacity, hab value, and production queue right now...)
  

Stuff I've read lately

"The Star Fraction" (Ken Macleod) - This is apparently the first in the "Fall Revolution" series. I didn't find anything new and incredible in here. It did give a little more insight into the "steam rockets" mentioned in the other books. That is worthy of its own research...

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.