Dynamic classes

The dynamic classes are implemented as per above:

• class table: the class descriptor is just an attribute indexed (type, RA, RA_Δ, etc.) array with indexes pointing out to the relative offset of the attribute in question.
• all the attributes within the class table, their names and numbers, must either be hard-coded or loaded to be known at the time when the class arrays are allocated, since each class array must be indexed by all known attributes,
• object layout: objects are allocated to contain exactly what the class array allows, and just nothing more ¹).

¹)	with the natural exception for pointers to memchunks representing objects in a quite different way

R113 — R117: carving plaster

The latest functionality adding revision was R112 adding labels to make navigable constellations. The following revisions (currently R113 — R117) have the general intention to refactor the celestial objects in order to allow dynamical class creation to be perused in the mkmap language; the redevelopment was originally slow, actually I didn't know what class model to use.

For celestial objects, it is necessary to be able to define the classes in runtime. Therefore I'll prepare a class system with inheritance, where the class tables list what attributes are available, what types those attributes have, and in what bytes they are stored within an object of that class.

For map projections, it will suffice with hard coded projections defined in the mkmap code. I'll therefore peruse structs containing a pointer to the virtual table containing pointers to the function performing the projection on a position ⟨α, δ⟩ given certain projection parameters.

I'll document the implementations in better detail elsewhere.

The releases in chronorder:

• R113 (Mar 26, 2011): "REFACTORINGS: ..." is a self-glorifying name for: "I didn't do very much, except shuffle around the code arbitrarily"
• R114 (Apr 2, 2011): same thing also this revision
• R115 (Apr 14, 2011): added a Knobel list of star descriptors (≈ names) never used in West, but listed in Al Achsasi's calendar from 1534¹) as stars along the ecliptic, not very important
• R116 (May 7, 2011): "intermediary code chaos revision", the star struct partially replaced by plain allocated memory, working on Linux only.
• R117 (May 16, 2011): "Carving plaster" the star struct now fully replaced by plain allocated memory, working on Linux and Windows; the object types (classes) won't be readable as structs in the code.

"Carving plaster" means that I'm working outside the PL abstractions (f.ex. structs) to be compared with the furniture of the room, and working with the computer raw material "the walls": bits-n-bytes. Now the task at hand is to be directed towards documenting and coding so that I (and code readers) get a grip on how it is implemented.

¹)

Western star names are generally some kind of pronunciations of Arabic star names, f.ex. Rigel (α Orionis) is from Rijl Arabic for "foot", but those names were generally transcribed in the wake of the First Western Renaissance of circa 1100–1347, presumably from the newly conquered library of Toledo in the Reconquista where Spanish Christian powers conquered the islamic Al-Andalus step by step. Many transcriptions were severely obfuscated by misread Arabic letters.

R116

See R113 — R117: carving plaster.

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...