25 more star maps

Forgot to mention R161 as of February 10 2016.

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!

Choices: star maps versus doc?

Just now I'm pondering about redefining my release plan. The problem is that, as defined in the link, it requires me to generate all 88 modern constellations in order to reach alpha level, but that's not the usual meaning of "alpha level" in software development. Alpha usually means something that works but may have bugs, and also don't necessarily have all the planned facilities. Also: it is overdue to startup some kind of documentation – it's very fun (and funny) for me to sit here programming, but it's of no use to generate nifty star maps if others cannot use the program according to their wishes, or, perhaps take the code and modify it for other purposes. According to my opinion, there's a lot of free software out there having quite inferior documentation, that are failing just because of inferior documentation and nothing else. Gnome and other desktop systems on Linux have very clearly inferior documentation, documenting exactly what anyone with at least a little brains can infer without documentation. That s*x!!

Here another star map (the constellation Aquarius):

I'll be back!

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.