Varför svenska?

Ja, varför? Man kan ju inte kommunicera data världsvitt med hjälp av svenska språket. Jag vet inte ärligt talat – kanske är det det att det finns ett förakt mot svenska språket som är fullkomligt omotiverat: svenska är ett av de få språk där begrepp såsom spårvagnsförarhandbok blir ett enda ord utan ett jättelikt antal stavelser, på engelska blir det tram drivers manual, på tyska blir det Strassenbahnführerhandbuch vilket är litet längre men också ganska bra. Poängen är alltså att man kan skapa kompakta enordsbegrepp som kan fungera som termer i en avancerad vetenskaplig eller teknisk miljö såsom programmeringsvärlden som har ett starkt undertryckt behov av avancerad enhetlig terminologi. Konstruktörer av konstruerade språk brukar fästa sig vid helt fel detaljer: grammatik, en godtycklig känsla för "naturlighet" och annat sidotrams som inte har med språkets användning som kommunikationsöverförare att göra.

Efter litet eftertanke tror jag att det blir bäst att jag behåller bloggen på svenska, och startar en ny blogg för sternons, när tiden är mogen. Det främsta skälet för att bedriva bloggen på svenska är dels att attrahera svenskspråkiga programmerarnördar, dels att skapa en mer tydligt svensk datajargong: engelska är faktiskt inte riktigt så bra som man i längden behöver och med en svensk datajargong kan svenska datanördar stärka sin konkurrens gentemot omvärlden.

Sternons Wiki

Sternons Wiki inlagd här. Man kan ju direkt säga att google codes wikispråk är starkt handikappat jämfört med Wikipedias wikispråk, och extremt handikappat jämfört med rak HTML som jag använder här på Haccationes. Jag får fundera på var och hur dokumentationen skall ligga, PDF eller HTML är ju trevliga saker, men jag vet inte om de går att visa ofiltrerade på google code.

HTML5

HTML5, denna nästa webstandard som skall komma – den är bara så fruktansvärt fel! Ett stort gäng nya taggar <nav> och <section>, <article> tillför ingen egentlig ny semantik som inte lika gärna kan klassas in. <canvas> gör i princip bara samma sak som object, parsningsreglerna relaxas så att det blir lättare att skriva skit-HTML, man lägger till två alternativa databas-access-interface Web SQL och Indexed DB. Vilken dj-a mishmash! Man tillåter inbäddning av SVG och MathML och det är bra men fem år för sent. Vad är det för fel på XHTML/CSS/SVG/MathML och SMIL? Kanske att dessa ännu inte funkar för alla browsers, men den eviga eftersläntraren är ju Internet Explorer, och de kommer ju inte att stödja HTML5 heller. Jag tror att man i stället borde börja om från scratch, och bygga ett nytt ML runt en referensimplementation som är MIT-licensierad.

Alla hajpar

Med anledning av mitt föregående inlägg drar man sig lätt till minnes alla hajpar och felaktiga föreställningar som graserar i datavärlden:

Det som äger marknaden är kvalitetsmässigt bäst! Fel! Enstaka marknadsstandarder och program är OK, men det som är mest spritt är det som haft öppna olicensierade standarder eller det som marknadsförts mest. Exempel är PC (olicensierad) och Windows (marknadsförd), Mac var/är tekniskt mer genomtänkt, Windows hade en bättre konkurrent OS/2 som var uselt marknadsförd, och som dess ägare IBM inte trodde på.

Objektorienterade programspråk: Jo OOPL:s är OK, men man kan objektorientera in absurdum, tills man inte hittar koden på grund av alla objekt, och så finns det ett stort gäng problem som är viktiga för programmering och där objekt eller inte objekt är helt irrelevant fråga, speciellt då det gäller strömmar, pluggar, parallellism, backtracking i sökprocesser, lazy-eval och sådant – att ha sina prylar som objekt hjälper något men själva jobbet kvarstår.

Java: Java uppfann det knaggliga trähjulet på nytt, i det ekrade cykelhjulets tidevarv, först efter 5-10 år återuppfanns generiska klasser som redan fanns i C++ och Ada, och detta i en lika dålig form som C++. Att snatta upp C#:s generiska klasser hade varit något bättre. Java har ett jättefint API som gör det lätt att programmera, Java's strängar är såvitt jag kan se helt obegripliga för alla andra än erfarna C- och C++-programmerare: de hänger sig och beter sig lika underligt som om de varit C-strängar. (Denna kritik riktas bara mot språket: JRE är en bra sak)

Garbage Collection: jättebra om man har en garbage-collection-algoritm inbyggd i programspråket, för då slipper man – som programmerare – att tänka på sådana saker som att allokera och deallokera minne. Tyvärr är garbage-collection-algoritmerna illa eller värre än illa implementerade: Java för Linux (Sun-versionen) stannar världen helt plötsligt så att man bara sitter och glor på programmet i upp till en minut – samma med den förskräckliga browsern Google Chrome, andra garbar läcker långsamt (Mozilla?) ytterligare andra gör programmet segt som sirap. Man kan i teorin tillverka bra garbar, men det är extremt svårt, och "marknadsstandard" tycks vara en garb som förorsakar en massa problem och irritation. Användaren blir inte glad!!

Google code och browsers

Filkatalogbläddringen funkar inte på Google Code med vissa browsrar. Testat:

Epiphany-browse	2.22.3 / Gecko 1.9	funkar inte	trol Gjs, ett SpiderMonkey-derivat
Google Chrome	5.0.375.55 beta	funkar	V8
Iceweasel	3.0.6	funkar	SpiderMonkey
Konqueror	3.5.9	funkar inte	??
Opera	10.00 (build 4585)	funkar	Futhark?

En källkodsbläddring på sidan visar att det är något i JavaScript som bara funkar för vissa browsrar. Lägger till namnet på JavaScript-motorn.

Jag blir tvungen att köra Iceweasel: den version jag kör har en subprocess kallad xulrunner-stub som kan börja skena och äta mer och mer minne – jag har inte testat alla browsers än, men det här suger precis lika botten som Google Chrome och Epiphany. Återstår senare att testa Opera.

Finns på webben.

Efter ett stort fruktansvärt slagsmål med svn så fick jag ut min källkod för mkmap till sternons repository. Man kan väl säga att det är ett första steg i att slippa slarva med en minnespinne, samt att göra koden tillgänglig för gemene.

Slagsmålet

Vad jag gjorde för att importera en katalog mkmap till sternons:

1. gjorde en katalog sternons (kommer inte att användas på sternons.googlecode.com) i katalogen dumps
2. i detta directory en underkatalog mkmap
3. gick upp till katalogen dumps
4. gjorde en svn import sålunda:

          svn import sternons https://sternons.googlecode.com/svn/trunk \
              -m 'initial import'

Sedan tog jag bort sternons/mkmap, och gjorde en checkout:

    svn checkout https://sternons.googlecode.com/svn/trunk/ sternons \
        --username tomki923

När jag skulle ändra en fil och committa:

    svn commit

så fick jag följande vansinniga felmeddelande:

    svn-commit.tmp: forward host lookup failed: Unknown host : Connection timed out
    svn: Arkiveringen misslyckades (mer information följer):
    svn: system("nc svn-commit.tmp") returnerade 256

Vilket verkar vara ett allvarligt jättefel, man kan lika gärna skrika

    SYNTAX ERROR: ERRNO #666

Men det berodde bara på att jag inte hade en texteditor konfigurerad. Så här skall man anropa om man inte har en texteditor konfigurerad:

    svn commit -m 'subst tabs for spaces'

alltså skicka med ändringskommentar från kommandoraden, i detta fall bara för att ge snyggare källkod.

Kvällshack

Orion i Lamberts koniska projektion

Kvällshack mkmap med en rast med snabb promenad igår. Åstadkom:

• kan, genom omkompilering, titta mot godtycklig plats på himlen,
• efter brottningsmatch med egenheter hos Lambert-konisk projektion och rektascensions-intervall fick jag underliga artefakter som visade halva himlar att försvinna,

Därmed är programmet förberett för konfigurationsfiler likt PP3, men där skall jag ta en annan väg än PP3: jag scannar tokens UTF-8 som tidigare nämnts, medan PP3 troligen rakt läser in kommandorader och direktinterpreterar dem.

Reflektion över utvecklingsarbete: Agile brukar framhålla refaktorerande utvecklingsmodeller i oftast ytterst små steg ("faktoreringar" eller något?) - detta följer jag också naturligen: men det finns fall

• där man måste hoppa och ta mycket långa utvecklingssteg ("hopp"), oftast med tung matematik inblandad,
• där man kastar koden och gör en ny (som i extreme programming XP), oftast där man faktorerat sig in till ett felaktigt kodläge,
• där man bygger transplanterbara moduler att ersätta befintliga moduler,
• och så emotsätter jag mig förstås emotionell laddning av begrepp som att kalla programutvecklingsmetodik för best practice – det där kan vi väl kalla en löjlig kärringism ...

Jag kommer att börja formulera en plan för utvecklingsarbetet nu.

Pinnen!!

Retade gallfeber på mig själv genom att glömma minnespinnen när jag for till Norrköping i helgen, där jag hade fått chans att testkompilera min PP3-ersättare på Windows Cygwin¹ – mkmap skall den heta, och den skall ligga på sternons på Google Code. I alla fall, efter en del abstinens i att endast sitta och surfa efter källkod till stdio och bedöma om wide_char-versionerna av printf är "porterbara" till att bli locale-oberoende, så hackade jag igång igen igår kväll och förberedde med att göra utstyrningsparametrarna av stjärnkartan inläsningsbara från en konfigurationsfil likt i PP3. Förberedelserna bestod i att jag gjorde en klass för själva kartan – jo "klass", det är inte lätt att skriva objektorienterat i C, och koden blir knappast vacker, men det går².

¹

min egna Windows är död p.g.a. en skraltig hårddisk, där min primära första partition snabbt sönderfaller och blir oläslig för varje operativsystem efter formateringen.

²

en fördel med att skriva objektorienterad C framför C++ är att i C har man inga virtuella tabeller likt i C++ – alltså globalt utpekade klasstabeller för en given objektinstans – vill man ha trubbel i C++ skall man anropa new samtidigt som man kör parallella trådar, pthreads eller fork, det ger mardrömslika fel som man kan offra veckor på att felsöka... ... man kan, med viss möda, skapa ett motsvarande klassobjekt i C som dock är ett minnesallokerat objekt som levereras med till funktioner, snarare än att de ligger globalt för trådar att rycka bort under fötterna på programmeraren under kodens exekvering...

PP3 del III

(kopierat från siderespector)

Så här skall det bli (Jakthundarna):
Men så här långt har det kommit hittills:

Hackar vidare med min ersättare till PP3. Jag bet i det sura äpplet och gjorde en fristående utf8_file-struct med en sparning av inläst uchar-värde. Finns bara inläsningsfunktioner, samt några konverterare från 32b uchar till UTF-8, vilket används i utskrift med vanliga stdio.h-rutiner företrädesvis printf och company. Jag ogillar att göra kloner av hela clib, eftersom man moraliskt måste implementera allt som clib har. Men när jag gjort och filat på denna stdio.h-klon kallad usio.h och en string.h-klon kallad ucstr.h, så gick det ganska bra att göra samma med 32b uchars som med 8b chars.

Nu gjorde jag en assimpel SVG-dumparfunktion som bara läser en stjärnkatalog, närmre bestämt ett urval ur Hipparcos-katalogen som jag drog ut positionsdata magnitud och litet annat ur, bilden nere till höger. Jag lade också till en testprojektion av typen Lamberts konforma koniska projektion, som används för flygkartor med hög upplösning. Det är inte ens det riktiga programmet, utan en utvärderande programsnutt som skall användas för att tänka ut hur man ställer in en stjärnkarta. Det gråaktiga rastret (rutnätet) har inget med himmelskoordinater att göra utan är papperskoordinater – himmelskoordinater antyds med blå punkter. Andra brister är att dumparkartan egentligen presenterar himmelskoordinater rektangulärt (Cartesiskt) medan målkartan är ett s.k. konsnitt. Till skillnad från i PP3, som använder ekvidistant altazimutalprojektion (källa här), tänker jag konsekvent använda en konisk projektion som Will Tirion.

Nu får det här duga så länge, jag måste nu hitta på ett namn till mitt program som inte ger något stort antal träffar.

PP3 del II

(flyttat från siderespector)

Hackade en del på min ersättare till PP3, men hamnade i de klassiska språksvårigheterna: om man vill göra en parser för ett flexibelt kartspråk måste man ha en parser med lookahead. Nu hade jag skapat en simpel UTF-8-variant av de i C vanligt förekommande primitiva funktionerna fgetc och ungetc, vilket är ett kuggproblem: man läser in snuttar från en till sex st 8-bitars char men funktionerna producerar en 32-bitars int som representerar ett utökat tecken drygt täckande in fulla Unicode. En ungetc måste man göra om man läser in ett tecken som man inte tänker sig att använda i den nuvarande operationen: om man till exempel håller på att samla ihop tecken till ett ord bestående av bokstäver allena, låt oss säga "Ανδρομέδη", och vi samlar ihop tecken till och med "η" och därefter finner ".", då vill vi använda hela "Ανδρομέδη" till ordet - dock ej "." - men vi vill heller inte bara kasta bort ".", eftersom den används i texten som en annan senare tecken-grupp bestående av ett tecken. Således måste vi lägga tillbaka tecknet, men i min UTF-8-klon av ungetc kan jag inte utnyttja min fil att skriva tillbaka på eftersom man i C-filer endast kan skriva tillbaka ett enda 8-bitars-tecken, och sannerligen inte en till sex 8-bitars-tecken. Om jag nu förresten har ett 32-bitars så vill jag hellre spara undan denna, inte backa tillbaka ett större antal 8-bitars-tecken och i min första version av ungetc använde jag helt enkelt en variabel att spara undan på. Det gick alldeles utmärkt ett tag tills jag med hjälp av dessa ville bygga en ordläsarfunktion fgetw med vilken man kan läsa hela ord åt gången och på samma sätt som ovan göra en motsvarande tillbakaskrivningsfunktion ungetw! Då måste jag ge alldeles för många argument till dessa fgetw och ungetw, en för att spara undan ett 32-bitars-tecken, en för att spara undan ett helt ord. Det är sådant som gör att man relativt snabbt kör fast i quick-n-dirty-programmering. Jag fick göra en helt ny typ av fil i form av en struct där det finns både återsparningsplatser för ett 32-bitars-tecken och ett helt ord. Det ser ut sålunda:

typedef struct _token_file_S {
    /* specialized token file allowing token get and unget */
    FILE *tok_file;
    uchar uchar_lah;
    token *tok_lah;
} token_file;

men detta strider, i viss mån mot den allmänna Unix-principen KISS, Keep It Simple and Stupid. Dessutom är det en osund tanke att både ha sparningsplats för enstaka 32-bitars-tecken och hela ord i samma filtyp! Ett "rent och vackert" program skall i stället ha

typedef struct _utf8_file_S {
    /* specialized token file allowing token getuc and ungetuc */
    FILE *_file;
    uchar uchar_lah;
} utf8_file;

med sina "metoder" och

typedef struct _token_file_S {
    /* specialized token file allowing token getw and ungetw */
    utf8_file *tok_file;
    token *tok_lah;
} token_file;

med sina "metoder" - vilket dubblerar antalet funktioner och filstructar, men gör koden "återanvändbar" - ren och klar och tyvärr oöverskådlig.

Övergav Google-Chrome

(kopierat från siderespector)

Den überfantastiska Google-Chrome de Luxe Professional med Billy Joe Bob extension är egentligen avsett som trojanspridare. Efter att ha surfat med Google-Chrome GC ett bra tag kom jag på att fördelarna inte uppväger nackdelarna. Fördelar:

• En GC-laddad websida verkar ta mindre plats än en motsvarande Epiphany, anledningen tros vara att GC baseras på WebKit och Epiphany på gecko – samma layout engine som i Mozilla – och gecko är slösaktig med minne,
• GC har en snabbare(?) och säkrare JavaScript-engine än Epiphany, Epiphany kan sätta igång och vrålköra och samtidigt dra en massa processorkraft, och det är en indikation på att man måste handdräpa kill -KILL eller något annat hårt, för att operativet (Linux alltså) inte skall börja sega,
• GC är känt för att ha ett enkelt GUI, och det måste vara bra,

Men, men, men:

• En av de värsta prestandatjuvarna – alltså en slags trojan – som brukar användas av stora websajter, t.ex. sverigesradio.se, för att analysera och omoraliskt spionera på användarens surfvanor kommer från Google Analytics ... Google-Chrome ... Google Analytics. Det går naturligtvis inte att stänga av "urchins" (trojaner) i Google-Chrome, och därmed kan man aldrig vara säker på en sajt som man surfar in på med Google-Chrome, det kan vara en sajt som plötsligtvis får operativsystemet att sega, samtidigt som det skickar över info om allt man surfat på till den sajt man surfar emot...
• GC skryter om sin fina nya JavaScript engine med sin ultrasnabba stop-the-world garbage collector vid namn V8, notera "stop-the-world". Världen stoppar verkligen: plötsligt stannar GC och man kan sitta där och hoppa i en minut innan något händer och hela OS:et segar. Då föredrar jag långsammare osäkrare garbage collectors som inte kör med stop-the-world. Den idiot som kom på att skryta om en "stop-the-world garbage collector" borde gå till psykdoktorn och be om medicin – en stark sort!

PP3

(kopierat från siderespector)

Ibland måste man programmera. Nu är det en av veckans programmeringsräder: jag håller på med ett projekt att försöka ersätta användningen av PP3 på Wikipedia med ett annat program – som inte finns än. PP3 är ett stiligt program med vilken man har genererat stjärnkartor för Wikipedia, exempelvis Cygnus se till höger! Dock har programmet ett större antal brister: det genererar inte det filformat man vill ha, vilket är PDF, SVG, PNG eller JPG. Jovisst den genererar PDF, och den kan även generera PS, vilket alltid är något – men SVG är det primära som man vill ha på Wikipedia, eftersom SVG-filerna är lätta att ändra, medan PDF och PS är ändringsbart bara av experter, alltså av mig – idén är förresten dålig, då PDF genereras av något annat format – om jag patchar PDF, och sedan någon går in och ändrar originalformatet till filen, så måste jag göra om min patch en gång till – manuellt!

Andra brister med PP3 är:

• Den kräver LaTeX, då det är ett C++-program som genererar LaTeX, kod för stjärnbilderna! Denna LaTeX genererar sedan DVI som genererar PostScript, som genererar PDF om Ghostscript finns installerat. "Inga problem" på Linux, om man kan stå ut med att installera så mycket irrelevantia för att få ett stjärnprogram, men på Windows är det omåttligt svårt.
• Den är skriven i CWEB vilket kräver en version av CWEB för att programmet skall kompilera till C++!! CWEB är ett verktyg för Literate Programming enligt vilken man skall skriva ett dokument varmed man genererar programkod och programkodsdokumentation samtidigt. Idén är bara så förbannat galen eftersom CWEB-koden inte blir sekvensiell, och eftersom man i stället för att göra en snygg programkodsstruktur gör en slags löst odisciplinerat dokument med text i stället för kod och kommentarer, och det leder till allsköns programmeringsskändligheter och kodkopieringar. Själv läser jag hellre kommentarlös rak programkod i stället för detaljerad koddokumentation: en C-programmerare förväntas förstå C, såväl som att tala det.
• PP3 serverar allt på ett silverfat som det inte är speciellt lätt att rota i: man kan konfigurera utseendet på sina kartor jättefint, med färger och allting, men man har ingen öppning att direkt generera någonting annat än en obskyr LaTeX-kod som lika få behärskar som de som behärskar PostScript: man skulle vilja få den att generera en SVG som Inkscape direkt kan redigera, men det gör man alltså inte med någon lätthet i en fruktansvärt förvirrad CWEB-kod.

Jag har efter litet extraordinärt fulhackande gjort en funktion som ovillkorligt läser in UTF-8 i C: ett stort problem med C är bundenheten vid ASCII, och standard clib tillhandahåller en omgivningsberoende locale-baserad UTF-8-inläsning, vilket är ett djävla otyg och står i total strid med all sund programmeringspraxis. Om man hypotetiskt inte har sv_SE.UTF-8 installerat på sitt operativ så kan man inte använda programmet om det kompilerats i sv_SE.UTF-8. Att det sedan endast är UTF-8 per se man är ute efter spelar ingen cykel. De som gjorde Unicode-stödet i C måste varit några djäkla marknadsnissar som aldrig programmerat.

Den litet naiva frågan inställer sig: måste man verkligen ha UTF-8? Njaä, det måste man väl egentligen inte, men det är en fördel: stjärnor heter sådant som β Geminorum (Pollux) och α² Capricorni (Secunda Giedi). Dessutom blir det numera krångel med texteditorerna om man skall försöka spara filer på "8-bitars ASCII" som exempelvis ISO 8859-7 som innehåller grekiska. Om man lyckades med att använda ISO 8859-7, så skulle man ändå inte kunna göra sina stjärnkartor med ryska eller arabiska stjärnbildsnamn, vilket är en högst tänkbar kombination.