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!

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.

ITIL Foundation

I passed the ITIL Foundation test. That means I am a stone in the Foundation, so that any ITIL boss can put me in an ITIL box hole. The topic is very interesting indeed, although the typical ITIL (potentially destructive) box-thinking is at most 25% of the truth about group collaboration and organization – the missing truths are about psychology, sociology and the mystical part.

As a bad side of this test passing, two of my nearest classmates didn't pass. They were sad and irritated. I tried to encourage them to allocate one day in a week for ITIL reading, so that they pass the test at the next opportunity.

Lithium deficit primordial star

(Credit: ESO/Digitized Sky Survey 2)
SDSS J102915+172927
α(J2000): 10ʰ29ᵐ15.15ˢ
δ(J2000): +17°29'28"
Const: Leo
m: 16.92

SDSS J102915+172927 is one of the extremely metal poor stars in this universe, meaning it was formed "shortly" after Big Bang, but it contains only one fiftieth of the amount of lithium expected to be formed in the Big Bang. Stars have a tendency to destroy the fragile lithium nuclei, so the problem is not serious, but if the lack of lithium cannot be explained in that way, the Big Bang and current models of physics are in trouble.

The astronomers have a strong suspicion that there are many more of these extremely metal poor stars, and are planning to study them with the VLT.

ESO news release here.

Nature article here.

Preliminary devenv choice

The infinite blessings of C# and Java aside, I've for a while considered using mainly (mostly) C++/wxWidgets. The reasons are that

1. the combination presumably taxes the computer running the programs much less, and
2. that I, as a developer, have a freer choice of perusing whatever API I need for the application,
3. and at I at the same time am in full control of the memory allocation (garbage collection is not a good idea).

Garbage collection has been praised for years as a way to improve the program, make it easier to develop it, and to make a better, more glorious and generally überphantastique program that gleams like gold in the distance (the irrational emotional aspect of programming religions). In immediate contact with these überphantastique programs, the "gold" is revealed to be a cracked surface of shallow paint: Android the überphantastique operating system for übertelephones deLuxe professional, very much unprofessionally freezes (!) for minutes, while the somewhat not so boasted JavaScript engine in Mozilla by function eats up memory till it is full: it is some kind of least effort, most sloppiness garbage collection scheme. A worse case is google-viral-chrome that goddamn boasts about having an ultraüberführer fast stop-the-world garbage collector. This is criminally insane, like boasting about cleaning the city streets by blasting away all parked cars, and sweeping away the scrap in minutes!

Java is pretty good for producing executives that are portable. C# is not good for that, since it is quasi-strictly Windows-only. (Allegedly it's better than Java, but that matters naught if it's not portable). The problem with Java is it's virtual machine bloat: you don't need all of it, usually, and it eats your resources. Garbage collection is a bad thing, but one can choose garbage collector by using some runtime call; one might also write code to avoid it. Still it's overkill and not quite as portable as generally believed.

One disadvantage with my choice of C++/wxWidgets is that C++ have access only to the Boehm Conservative Collector, and I don't know its behavior. The second point is that wxWidgets provides 16 bits Unicode when I use 32 bits Unicode. Maybe it's rehackable, but I'm not sure.

Undesirable "feature" in string literals conversion

My own string literals conversion program contains an undesirable "feature", namely it converts also strings in comments. It would be better to keep the comments as they are, when a file is converted from .uc to .c, so that the .c keeps being more readable.

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.