Decision to add luxcaeli

Once upon a time I made another program called luxcaeli ("the light of the sky"). While there have been no release for a time, I'm actually working pretty intensely with creating star maps for all the 88 constellations. One could say that I have taken a vacation from coding sternons, but in the background I'm preparing for an astronomy book of mine, while all the same experimenting with a prototypical database manager that happenstance contain stars ... I've decided that this luxcaeli will be added as next tool in the sternons toolkit, since I'm using it as a reference when making my star maps. Luxcaeli currently looks like the image at the right.

R160 – Doc improvements, more star maps

Ara constellation

New release R160 containing more star maps, some superficial code documentation, and a minuscule SVG generation improvement on star grid at high declinations.

R159 = V 0.0.1.1 α, Valpurgis 2013

The First Alpha Release!

At last: sternons reached version 0.0.1.0 α (in revision R159). I immediately had to update it to 0.0.1.1 α because of some minor pressing fixes. The release contains:

• a mkmap that can actually generate SVG maps from the MKM files,
• instructions on how to write MKM files.
• the first ever download here!

R158 – road to α, step 2

Fixed the minus problem so to be able to draw southern hemisphere constellations:

• R158 (Apr 26, 2013): Implement negative constants

The problem was fixed by creating a rule:

⟨constexpr⟩ ::= ('+'|'-') ⟨numexpr⟩

by the function parse_constexpr. I was forced into accepting the idea of using token ** args to by side effects appoint constants.

R155–R157 – road to α, step 1

The project is approaching alpha, which is so defined that it is possible to generate maps for all 88 official Delporte-constellations. The goal isn't reached yet. Minus cannot be given in mkm-file constant number literals, which essentially impossibilizes¹) making southern hemisphere constellations.

• R155 (Apr 21, 2013): Minor fix to make mbf self selecting svg output moved many functions from mkmap.c to vmcode.c, inserted VM instruction for opening the output file,
• R156 (Apr 23, 2013): Functional null-parser, mkm revisions creation of parser compile-mkm.uc intended to compile new file orion-v1.mkm to maps/ori3.mbf,
• R157 (Apr 25, 2013): Compiler implemented, alpha stage soon to come semicompletion of compile-mkm.uc allowing northern hemisphere constellations to be compiled

¹) "impossibilizes" (makes impossible) is probably not legal English, but being a linganarchist, I made it up here to counterpart the Swedish quite legal "omöjliggör". Swedish is a little superior to English, so why fully adapt to the inferior language? Carl von Linné didn't invent binomial nomenclature by following Latin word formation rules, he applied the Swedish word composition rules on a Macaronic mixture of Greek and Latin.

R154 – MBF (v1) stabilization

MBF format stabilization – allow usage of labels, that are recognized by starting with :.

• R154 (Mar 7, 2013): MBF format improvement.

The solution is of the-fastest-hack kind, but since it is a VM assembly format, this should be acceptable: VM assembly format is intended to be 1. read by the debugging programmer, 2. autogenerated by a parser. The VM assembly format is not intended to be written or modified by the normal programmer. Part of MBF format:

:SETTINGS
   :NewImage
   :ustr 00 :ImgSetName
   :int 1F4 :int 1F4 :ImgSetSize
   :dbl 3FF66666 66666666 :ImgSetScale
   :dbl 4054A000 00000000
   :dbl 40140000 00000000
   :dbl 402E0000 00000000
   :dbl 40390000 00000000 :ImgSetLambert -

R153 – MBF (v1) loadability

A major progress.

• R153 (Mar 6, 2013): The pseudo-binary format MBF (mkmap binary format) is now loadable and runnable.

The make call make mbr calls ./mkmap map/ori2.mbf which generates the file orion2.svg which of now is identical to the file orion.svg, that (currently) is generated by hard code in mkmap.uc:main().

The MBF format is not yet stabilized, it is

• defined through vmcode.h
• and through VM_exec in mkmap.uc
• called in main in mkmap.uc
• and encoded in ori2.mbf

As of now, it is pseudo-binary that should preferrably be redeveloped to a VM-assembly, and/or a real binary format.

R152 – asleep project woke up: yet a step towards VM

Project "revived" after having been dead more than half a year. My life changed somewhat, I began studying Java and JSP, a horrible programming language that has some market support and that enables easy coding of client server systems. That is: I have a real important and interesting application of this handicaped programming language, but the philosophy behind Java reveals a horrible ignorance and real stupidity. My angriest criticism against Java is the very inferior parameter system of methods/functions, my next most angry criticism is that it is impossible in code to explicitly deallocate an object, if it be needed. The Java programmer is "for simplicity" condemned to no control. The "simplicity" is often a badly hidden alibi for a bad Java/JDK/JRE architectural design and convenient avoidance of heavy technical decisions, rather than simplicity for the developers.

• R152 (Mar 4, 2013): yet another, preparation step for loading/running mkmap VM code, here concentrating on making the image_program object data complete by storing strings (8b/32b) and code.

R151 – more API funcs for VM exec

A "pre-vacation" release that made yet another VM setup call preparing for VM code loading and execution (see R153).

• R151 (Jul 30, 2012): Parseprep 1: vmcode module

The project fell asleep as a result of changes in my private life and a general disgust over that the coding experiment took a too bombastic and non-simplistic course – something that is quite in accordance with my skepticism against the modern nonsential trends of programming language design, but which also make me pretty exasperated with myself, since architectural deliberations are massive compared to achieving the goals of the program.

In fact the project is programmed in discord with what C dictates, implementing objects that don't exist, creating a program language that is dictated by praxis, not by programming paradigms (that I regard as mostly learned prejudicies). I'll make an analysis the day when the project is frozen, which is a day when map files may arbitrarily be written to generate star maps.

R149-R150.

Ignore them!

R144–R148 – VM implementation advances

The're were two trivial changes adding and deleting an email address file. The intent was to use it on the sternons project page. It failed.

The purpose of the following restructurings is to prepare image program structures, that can be executed by an interpreter:

• r148 (Jul 25, 2012): Refactoring 10: VM prep – this revision removed arguments from functions in image.[ch] in order to adapt to the intended map format, where an image is first created and then its values set up;
• r147 (Jul 20, 2012): Refactoring 9: VM prep, minor, completed the setup of static image program structs;
• r146 (Jul 20, 2012): Refactoring 8: VM prep, setup Monoceros code into a static image program struct;
• r145 (Jul 20, 2012): Refactoring 7: VM prep, setup Orion code into a static image program struct;
• r144 (Jul 12, 2012): Refactoring 6: VM prep, added a few missing map files, otherwise a massive rewrite where VM-embryonic function calls were replaced by program structures containing the VM-codes.

R143 – Added release plan

Also added a release plan sketching some most important things needed to be able to run an OpenSource project much more elemental than personal home hacks (such as my glossary checker, text editor and such private experimental stuff).

2013-04-25 update: note the discrepancy between the 0.0.1 R143 and the R130-R141 – Heavy refactoring 0.0.1.0, which was originally 0.1.0! I conventionally choose 0.0.X.R for alpha stages, where R is added in order to get in a revision.

R142 – Refactoring 5

Preparing the VM yet another time by refactoring in revision 142. Now the code is prepared for storage in short ints, which is going to be the storage format for the virtual machine. The storage of the literals is yet undetermined.

R130-R141 – Heavy refactoring

Apology – database exam

Not reported about the development for a while. I studied for an SQL Server "exam" on the MCITP (Microsoft Certified IT Professional) level, meaning that I have a hunch on what might be wrong, how to diagnose it and probably fix it when an Microsoft SQL Server fails. I like database, but I'm not knowledgeable to compare different RDBMS:es (Relational DataBase Management System, the English language favors ridiculous acronyms before Swedish-styled noun clusters like relationsdatabashanteringssystem). The only thing I know is that MySQL is the only one specifically built for massive load-balanced active/active access clusters, while something similar might be achievable through Windows Server Clustering, rather than RDBMS clustering. Regarding PostgreSQL, it's on the same level as Microsoft SQL Server, which means less than MySQL.

The refactorings

My mind flerped about two days ago, meaning that my passivity regarding mkmap ended. I had previously decided that any refactorings should come before 0.0.1.0 alpha stage, but adding a few intended VM code executors, I finally (reluctantly) decided that

1. a VM was necessary because of my way of defining maps first, modifiying them afterwards, and only then executing them,
2. while register VM:s are generally regarded faster than stack based, the code becomes simpler perusing a stack based VM,
3. I must refactor and cleanup to get an overview over my program (other than the usual intuitive one).

The flerp implied that I on a whim moved away all code into CH program pairs, making a so called "object orientated" packaging of most functions according to their main struct ("object"). In spite of the hybris speach of "object orientation", this is more like stupid packages without interfaces.

• r141 (20 maj, 2012): Refactoring 4: ch-splitoff most
• r140 (19 maj, 2012): Refactoring 3: ch-splitoff much
• r139 (19 maj, 2012): Updated copyrights to 2010-2012 (in lead comment of all c- and h-files)
• r138 (19 maj, 2012): Added missing GPL copyrights (in lead comment of relevant c- and h-files)
• r137 (19 maj, 2012): Refactoring 2: ch-splitoff valstack (the first of the real splitoffs)
• r136 (19 maj, 2012): Refactoring 1: renaming methods (preparative for valstack splitoff)
• r135 (19 maj, 2012): Moving mkmap towards VM executor – it was here that I finally decided that there was no way to avoid implementing a VM before alpha 0.1.0
• r134 (19 maj, 2012): New string type for MKMAP programs with UTF-8 characters
• r133 (17 maj, 2012): dummy change to fix my locally changed gnome keyring (on Linux)
• r132 (17 maj, 2012): More preparations for virtual machine code
• r131 (24 feb, 2012): Preparation for virtual machine code
• r130 (24 feb, 2012): DB fixes, preps and new map format

Future

The goal 0.0.1.0 alpha is reached when maps can be prepared for all official 88 constellations. In order to achieve that, the parser in parse_prog2 should be able to parse programs like maps/generic.mkm and generate VM code from them, while mkmap takes VM code and executes it to generate SVG. parse_prog2 is not complete, but the most of the necessary data structures are there. mkmap does simply and stupidly generate Orion and Monoceros as it has been for a couple of years now, but the state when it's able to run VM code is slowly approaching. I'm a little frustrated, but in time...

R128, R129 – pushing and popping

I now have kind of a plan, more than the one that always was in my head. Current efforts are directed towards implementing just any program file reading – with scanning and parsing – that makes it possible to generate all constellations. But the pushing and popping of program states must be implemented first.

• R128 (4 dec, 2011) starts with this pushing and popping, although it is not tested yet.
• R129 (4 dec, 2011) The code for this pushing and popping called in the main program. Works for the hard-coded star map generation in the main.

Constellation Monoceros, the Unicorn

R126, R127 – finally woke up again

I finally woke up again, after some tough months of studies. The pedagogical quality of Microsoft teaching material have some deficiencies. Still studying MCTS 70-640 and MCTS 70-680, but the material needs lots of analysis to be comprehensible on a deeper level. It's easy to imagine that Microsoft doesn't really want people to know how their Active Directory is designed, although I cannot find anything wrong (except some immature rigidities) in the design. They have made a pretty good job about it, however much I'm negative against attaining religious software stances. The only feature that looks weird and unlikely to succeed in MCTS 70-640 is AD RMS.

• R126 (Dec 2, 2011): The latest sternons change is more of this "carving plaster" stuff, where dynamically setup objects are to be created. The current change is just a minuscule change setting up the classes by using my 4b wide uchar strings in the function init_star_class.
• R127 (Dec 3, 2011): More of the same.

R123–R125 – Still not dead in Reinfeldt Hell

Yet a few other microscopic releases – the socioeconomic conditions as an unemployed in Reinfeldt the Cheater's Swedish Hell are complicated and requires more than 130% of full working time to fulfill, while the bureaucracy and income delays worsens. Since nobody's going to employ me, for irrational reasons, I have to beat up this quasi-dead donkey: preparing a book give me experience and some hope of getting away from these horrible Reinfeldtian conditions by my own writing and programming.

The still not dead donkey:

• R123 (Sep 2, 2011): Prep for dynamic class creation by func call – i.e. I'm working in minimalist steps towards a call in my mkmap language that dynamically creates an object type, f.ex.:

     class star { Bayer, HIP, HD, α, δ, π, RV, Mᵥ, SP };
  

  which defines a star to have a Bayer designation, a HIP Hipparcos number, a HD Henry draper number, an α/δ position (right ascension and declination), a parallax π, a radial velocity RV, a visual magnitude Mᵥ and a spectrum SP. The given attributes of the class are hardcoded, Bayer is presumed to be a string, HIP, HD integers, α and δ reals (floats) and so on.
• R124 (Sep 2, 2011): Fix bad object linking of allstrings.o – in fact the new object allstrings.o was introduced.
• R125 (Sep 3, 2011): Further object setup – making some default settings in object setup: first a type, then a pointer to previously loaded object.

R118 — R122: own string literals

Slow slow progress! I'm in the middle of a sequence of marketing improvement courses (CompTIA A+, Network+, ITIL, Windows 7, and Windows Server 2003/2008), so the progress at sternons mkmap is proceeding very slowly. I like learning courses, so there's no real trouble, but I also would like to develop my private astronomy book plans requiring star maps, and similar. Maybe also I'll be lucky enough to get a job that contains a little C programming beside the PC-administration or networking jobs I'm preparing for.

The releases r118 to r120 slowly continued the novel dynamical object system produced by "carving plaster" – let's call it the plaster object system – but then I realized how tedious it is lacking string literals for pure 32 bit int wide strings.

Lacking those, I hacked a converter (neither a parser nor scanner – more like an oversimplistic preprocessor) that scans a file, collects strings with the syntax u"example string" perusing an initial nonstandard u" as a string marker for my own string literals. Now the function ustring_to_attrib in file pointobj.uc is converted as follows

source pointobj.uc	target pointobj.c
int ustring_to_attrib(uchar *ustr) {   if (0 == ucscmp(ustr, u"RA"))     return POA_RA;   if (0 == ucscmp(ustr, u"R.A."))     return POA_RA;   if (0 == ucscmp(ustr, u"α"))     return POA_RA;   return POA_none; }	int ustring_to_attrib(uchar *ustr) {   if (0 == ucscmp(ustr, _UC_RA))     return POA_RA;   if (0 == ucscmp(ustr, _UC_R_2E_A_2E_))     return POA_RA;   if (0 == ucscmp(ustr, _UC__3B1_))     return POA_RA;   return POA_none; }

All such 32 bits wide string constants are then collected into the file allstrings.h, containing (among others):

static uchar _UC_R_2E_A_2E_[] = {'R','.','A','.',0}; /* R.A. */
static uchar _UC_RA[] = {'R','A',0}; /* RA */
static uchar _UC__3B1_[] = {0x3B1,0}; /* α */

The releases in chronorder:

• R118 (May 25, 2011): "More plaster carving towards dynamical classes" experimental refactorings directed from static defines to dynamic allocation
• R119 (Jun 13, 2011): "In the middle of refactoring" more mature refactorings in the same direction
• R120 (Jun 13, 2011): "More object class refactorings" more refactorings – removing a conceptual flaw: the object type identifier must (!) be stored at the same position in all objects, minor other code fixes
• R121 (Jul 22, 2011): "Further walking around Windows wide C-string limitations" novel invention – half-way wide string literal converter implemented: demo conversion seems OK
• R122 (Aug 1, 2011): "String literal converter - ucliterals" the above wide string literal converter implemented and perused in code generation

R121

See R118 — R122: own string literals.

R119 and R120

See R118 — R122: own string literals.