Repo moved to GitHub

The repository at googlecode was moved to GitHub since googlecode was closed for almost all projects. Now everything is at TomasKindahl/sternons. Git is considerably different from subversion, but now I found out how to export my changes from local to the GitHub repo:

$ git do the stuff
$ git commit -m "I did the stuff!"
$ git push origin master
Username for 'https://github.com': LoginName
Password for 'https://LoginName@github.com': ∙∙∙∙∙∙∙∙∙
Räknar objekt: 2, klart.
Delta compression using up to 4 threads.
Komprimerar objekt: 100% (2/2), klart.
Skriver objekt: 100% (2/2), 234 bytes | 0 bytes/s, klart.
Total 2 (delta 1), reused 0 (delta 0)
To https://github.com/LoginName/yourblodyprogram.git
   b0a273a..888b076  master -> master

User hofmannsven has a nice My simply Git Cheatsheet which I read when finding this out.

So far, I've changed the latest links of this blog to point to the relevant page on GitHub, but most links herefrom still points to googlecode which is empty. Sorry for all inconveniences!

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.

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

Free PC Speed Test

Here behold the ultraphantastique Free PC Speed Test it disables a lot of "unnecessary" operating system features, such as the ridiculous IPv6 ...

I recommend not using it, unless you want to reinstall your operating system (I mean Windows, optimizing Linux is more complicated) when you discover that this or that disabled feature is necessary for the operating system to work in the future.

The normal way to optimize Windows 7 safely is to disable unnecessary GUI features by opening Computer Properties, entering Advanced system settings and clicking on Performance to regulate in detail the visual effects. Some of those effects are neurophysiologically advantageous, such as windows' shadows and font anti-aliasing, but most of it is visual blows-and-whistles of no use.

Nice and tolerant advocacy

Here's Paul L. Rogers' Canons of Conduct that I recommend for any kind of advocacy:

• Advocacy-HOWTO: 6. Canons of Conduct

JavaScript rage

To my horrified surprise, both Windows 8 and Gnome 3 intends to use a JavaScript engine for Silverlight (Windows) and Gnome shell (Gnome 3). Good luck to them, when hords of furious users ragingly will attack them in order to lynch them – but I'll silently be walking in another direction.

About Gnome 3, take a look here:

• debian-user Nov 2011 by thread

JavaScript is the language that eats all your memory when you surf with a web browser, it is designed to make massive memory allocation for ordinary execution, but it garbs only when the memory starts to be consumed by the JavaScript engine. Of course this competes with all other programs on your computer: a nonimportant program, such as the web, eats up resources for important programs. Fair? No! Polite? No!