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.

wstring vs. ustring

The problem with Windows cygwin gcc using 16 bits' strings instead of the hard coded 32 that I use is solved in the only way possible within C.

The problem is about the following: I rely on wide characters being signed, irrespective of what the local C implementation uses for wide characters. As a means to (in future) allow Unicode upper plane code points¹) I also implement wide characters with signed integers (assuming them to use 4 byte). The normal wcs string functions – f.ex. the comparison wcscmp instead of strcmp for old narrow characters – varies according to implementation, so I provide my own counterparts in ucstr.h. They're not complete, but they work for my purposes, including others that aren't on the web.

Fine, so far – but since cygwin use 16 bits internally for wide chars, the wide string literals, f.ex. L"ψ⁶ Aur" ²) won't work for my personal 32 bits wide chars. Therefore I have to replace them with uchar array declarations like

   uchar _L_psi_e6_Aur[] = {L'ψ',L'⁶',L' ',L'A',L'u',L'r',0}.

and replacing all occurrences of L"ψ⁶ Aur" with _L_psi_e6_Aur. It's not beautiful, but it's the only way to make the code portable.

---

1)	ponder f.ex. using a Mesopotamian Cuneiform glyph here, which is realistic, since there was Cuneiform star catalogues, f.ex. MUL.APIN, then such a Cuneiform glyph is implemented in plane 1 of Unicode, which needs 21 bits, which is so odd that 32 bits is provided by integer is the best match,
2)	a star in the eastern Auriga, formerly Telescopium Herscheli

---

A crucial question: why not use another programming language than C. Yes, why not, but the languages not to use for this kind of application are Java and C# (and all .NET languages), because they require loading of a heavy virtual machine that are not used for the conversion process. Other not-to-use-for-this languages are JavaScript and PHP, because of their web oriented implementations. Relevant languages are Python and C++. The current implementation will stick to C because of lib spinoffs that can be used in implementation of programming language experiments of mine – C++ won't do for parallel programming – until a full set of star maps can be generated: nothing is impossible in C, but many solutions require ugly-like-h*ck code.