Thursday 7 March 2013

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 -

Wednesday 6 March 2013

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

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

Monday 4 March 2013

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.

Sunday 3 March 2013

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.