R115

See R113 — R117: carving plaster.

R114

See R113 — R117: carving plaster.

R113

See R113 — R117: carving plaster.

R112: Labels

Star labels added in R112: this is intended to be the last cosmetic fix before a general "refactoring" phase preparing for:

1. synergic mergers of similar structures according to C object orientation techniques – perusing similarities in struct declarations using a type tag and perhaps a virtual table implementation providing real dynamic method dispatch, such as generally invisible in C++
2. thereafter program loading and map setup.

I would have liked to sprinkle my star maps to Wikipedia sites (and Citizendium where there are no images at all), but it won't happen before program loading becomes beta and so mkmap becomes alpha.

R111: Delporte 1930 area

Constellation Orion again: darker background for the Delporte 1930 constellation area. This was accomplished in R111 of Mar 5, 2011.

A note on Streaming theory – r87: that theory is dead and buried — mkmap cannot use streams because loaded data is reused again and again, and some loaded data peruses earlier loaded data. No streams, but instead database like queries.

R107 — R110: Constellations and asterisms

The maps that were exhibited in posting "Example maps" were generated from R110 adding Constellation bounds. Revisions from R106:

• R107 (Feb 8, 2011): ripout of star struct into star.[ch],
• R108 (Feb 17, 2011): microscopic struct attribute and function renames,
• R109 (Feb 26, 2011): adding asterism line drawing,
• R110 (Mar 3, 2011): adding code for loading and drawing constellations' bounds.

The project is as alive as possible, given the current life conditions. I'm doing "practice work" in my church¹), full time, and some voluntary works at that church in the evenings, whenever I'm not applying for jobs that none is going to give me. This blog and the sternons project is designed to be a "job application merit", but it doesn't matter, because I'm 50 years old and nobody in Sweden is going to employ me anyways ²). My real purpose with this blog and the project are the star maps, just the star maps ... and to whatever use one may put star maps ...

¹)	Willingly: it's my church, just not the nearest church.
²)	Capitalism sucks, truly: any system that refuses to employ a well educated healty computer engineer with full working capacity under a hot boom when there's a shortage of computer engineers, is a sociopathic system (I'm hereby mild and reconsiling).

Example maps

Monoceros, a constellation that formally is overlapping the galactic equator but still pretty devoid of bright stars like the neighboring Orion. Lot's of deep-sky objects, most prominently the Rosette Nebula near the "head", and the sparse but bright open cluster NGC 2244 that have blown up a cavity in this HII bright nebula, which is excited by the hot young stars of that open cluster. The constellation seems to have been formed from stellae informata by Petrus Plancius near the turn of the 16th to the 17th century.

Orion is the heavenly hunter that boasted that he could kill every possible animal on this planet. Gaia, Mother Nature, then became pretty upset, and sent the Scorpion to kill the blasphemer. Orion the constellation is in direction of a real star craddle of Milky Way. Young bright stars are numerous. M42 and M43, the Orion nebula is part of one of the most studied star formation areas of the heaven, containing protoplanetary disks and young protostars cocooned in dust and dark hydrogen gas and thence only visible in the IR range of electromagnetic radiation.

R109

See R107 — R110: Constellations and asterisms.

R108

See R107 — R110: Constellations and asterisms.

R107

See R107 — R110: Constellations and asterisms.

R102 — R106: Docs and DB

Log of changes since last report:

• R102 (Jan 30, 2011): minor restructurings inspired by the program loading experiments previous early winter,
• R103 (Jan 30, 2011): more of the same,
• R104 (Feb 5, 2011): added my hand copied version of Tabulae Rudolphinae on a whim, probably the only one in database format on the entire web,
• R105 (Feb 5, 2011): doc cleanup,
• R106 (Feb 6, 2011): major rehaul to prepare for a novel database model (ADBMS) and to allow the struct program_state to be pushed/poped as procedure enviroments, added data and code for constellation lines.

R104 and R105

See R102 — R106: Docs and DB.

R102 and R103

See R102 — R106: Docs and DB.

Ada and UTF-8 literals

To my delighted astonishment, I found the following code quite legal in Ada05:

pragma Wide_Character_Encoding(UTF8);
with Ada.Text_IO, Ada.Integer_Text_IO;
procedure Read_Write_Loop is
    use Ada.Text_IO, Ada.Integer_Text_IO;
    β : String(1..40);
    N : Integer;
begin
    Put("> ");
    loop
        Get_Line(β,N);
    exit when β(1..N) = "quit";
        Put("Command: '" & β(1..N) & "'");
        Put(" ("); Put(β'Length,2); Put_Line(")");
        Put("> ");
    end loop;
    Put_Line("Bye");
end;

"Ridiculous", the most programmers use to say, one can write beta in Java/C# (which by the way is the most phantastiqual language ever constructed by the most intelligent godlike gurus, yada yada yada ...). Very nice when encoding mathematical formulae in Ada.

The above code works in GNAT if the data is stored in a file read_write_loop.adb and compiled with

gnat make read_write_loop

Other perceived advantages of using Ada for numeric parts of the sternons project are:

1. Ada is available wherever gcc is
2. The Ada programmer have a detailed control over data precision f.ex. being able to declare long reals by type My_Float is digits 12;

R101: License change

R101: just a license change in the code from GNU LGPL to GNU GPL. The reason was easier code pilfering from other projects, of which the vast majority is GPL. Now, Microsoft's CEO Steve Ballmer also consider my code "a cancer", which is maybe honorable coming from him, and "viral" according to Craig Mundie, also Microsoft. Microsoft is nice, nice doggie, do not bark on bearded men with turban!

R100 (new year revision)

R100 occured after some time of vacation from the project. My dive into program parsing made me get some intuitive plan in my head for in what direction the project is going to be developed, but I believe the mkmap program syntax needs some heavy revision after I've rehacked the main non-program-parsing code in accord with my vague intuitions. That's the life with theory and praxis: back and forth, nilly-willy over the border of the true and the functioning.

Semi-dead project

The project was semi-dead for about one and a half month, due to so called ordinary life. So called ordinary life irritates us, but the project was only semi-dead, which automatically implies zombielike. The revisions r98 and r99 where ueber-silently released, both of them designing some data structures to be constructed after the parsing of the map program. The program parse_program parses the program and constructs a program prototype. Nevertheless I'm considering yet another program redesign, that makes some assumption on the so called graphical layers: given a "fixed" sky layer (or for that part a "fixed" globe layer on any planet), there could be a conceptually different viewing window layer that applies filters on any fixed surface layer,

1. a selection, for example stars brighter than 5.5, galaxies brighter than 9.5,
2. a projection, for example lambert conic, simple conic, cylindric
3. an orientation, centering α₀, α₁, δ₀, δ₁, image rotation ν and some such...

Sexagesimal handling – R97

At last some real programming (again), although frustratingly slow (revision 97). In general I wish everything accomplished immediatelly!! I enabled some correct sexagesimal constant scanning allowing mkmap map programs to specify float constants as sexagesimals, f.ex.:

• 23ʰ12ᵐ03.14ˢ (a right ascension)
• 23ʰ12.17ᵐ (another)
• 48°34'16.07" (a declination without a sign)
• 33° (another)

The acceptable sequence of the sexagesimal markers are ʰᵐˢ, ʰᵐ, ʰ, °'", °' and °. All other sexagesimal marker sequences within a floating point literal constant are illegal. The code is also prepared for hexadecimal and octal constants, but correct scanning of those are not yet implemented.

CAVEAT 1: The scanner doesn't create a floating point value from the scanned token – that's up to the parser. A token "method" for creating a floating point value is to be added in the future.

CAVEAT 2: The scanner is not screaming (fprintf stderr) from the occurrence of erroneous sexagesimal tokens, the screaming philosophy is not yet determined.

Revision documentation

Added clarifying revision documentation from R1 to R51 and some general comments from R86 to the current R97. The point is that I'm successively learning some complex options of svn and the facilities (and lack thereof) of googlecode. The following pretty complex svn command generates a diff overview:

# svn diff --diff-cmd /usr/bin/diff -x '--brief'

In "the best of worlds" the syntax would instead have been

# svn diff --brief

or

# svn diff -B

Project mgmt on google code?

Q: Project mgmt on google code?
A: Not likely!

Actually, I examined the facilities on google code a while ago, added a few issues and deleted them again as experimental evaluations. My immediate reaction was that I could find no life cycle stages of a certain module – a module could attain any of the following intellectual stages:

• vapor: imagined, probably needed or possibly not, no implementation nor any evaluation supporting nor opposing the creation of the module,
• rejected: the module development is stopped at any of the pre-gamma stages, and stowed away for trackability and a possible future reevaluation, ¹)
• evaluated vapor: text, design and evaluations describing and underbuilding the creation of a module
• experimental: a code that implements some important aspect of a module, used for demonstration for further evaluation and a code base for the future module
• alpha: the module is implemented but unstable,
• beta: the module is pretty stable, but not systematically bug-tested
• gamma: stable and systematically bug-tested
• gamma-old: gamma but considered for replacement: replacement documentation exists
• delta: actively being replaced

These life cycle states are 'home hack' adapted, a test-based development enviroment should have a different set of stages: fulfilling this or that many test cases.

Whether google code usage can be adapted to an arbitrary life cycle management of individual modules is as yet undecided, but it is an infinitely important question for any opensource project.

1)

Extreme programmers and other modern project management use to dislike stowing away things for later reevaluation, but this is just an oversensitivity and disability to evaluate and correct oneself from own thought errors. The key points that makes stowing away problematic is keeping a database and any system of competition-by-blame.