Eudyptula-utmaningen

Who is behind this?

A set of convoluted shell scripts that are slow to anger and impossible to debug.

I slutet av november fick jag höra om Eudyptula-utmaningen, och har sedan dess försökt beta av de uppgifter som har tickat in över e-post.

Den stora utmaningen från början var att konfigurera e-posten korrekt. Html-formaterade e-postmeddelanden är förbjudna och gmails webmail rekommenderas inte. Det slutade med att jag installerade Mutt, kommandoradsbaserad e-postklient. (Bitvis besvärlig men fullt fungerande.)

Efter det lilla skriptet hade godkänt min förfrågan om att deltaga började uppgifterna trilla in. Jag kan inte gå in i detaljer om uppgifterna eftersom det skulle bryta mot reglerna. Lite svävande kan jag säga att jag hitintills har genomfört fyra uppgifter av varierande slag. Jag har fått bygga en enkel modul och kompilera min egen kärna utifrån Linus git-repository. Jag har blivit tvungen att läsa lång torr dokumentation och jag har fått söka på nätet.

Jag har inte alltid lämnat in en acceptabel lösning på första försöket utan fått kritik och ledtrådar för att kunna fortsätta arbetet. Kritiken kommer alltid på ett bra sätt som inte fått mig att känna mig dum utan endast pekar ut knasigheter eller brister. Hela utmaningen är väldigt rolig och trots det lugna tempot i början lär jag mig mer än jag trodde.

Det som är bitvis problematiskt är att ibland tar det tid innan feedback lämnas eller att en korrekt lösning godkänns. Uppgift fem lämnades in den 15:e Januari och jag väntar fortfarande med spänning på att få reda på ifall jag klarat den eller inte.

Remember, this is not a race, there is no rush, if tasks take a while to
be graded, enjoy the time to go do something else.  There is a lot more
in life other than Linux kernel programming.

… Ett litet skript med svar på allt …

C64-programmering

För ett par veckor sedan hittade jag cc65, en c kompilator för 6502-processorn. 6502-chip och dess varianter hittas i många retro-datorer däribland Commodores C64 (MOS6510). Tillsammans med boken Programming the Commodore 64, ett antal hjälpsamma hemsidor kom jag snabbt igång med ett litet hello world-program.

Installationen är relativt enkel:

Klona git-arkivet

git checkout https://github.com/cc65/cc65.git

gå till katalogen och bygg kompilatorn

cd cc65
make

Ifall man vill kan man installera den i systemet

sudo make install prefix=/usr/local/

När kompilatorn är installerad är det bara att börja programmera

#include 

int main(void)
{
    printf("Hello World!");
    return 0;
}

Programmet kompileras sedan enklast med

cl65 -t c64 hello.c -o hello.prg

När programmet är kompilerat kan det föras över till en fysisk c64 (exempelvis med uberCasette eller 1541 Ultimate). Dock har jag inte kommit så långt ännu utan kör mina program i vice.

När man lär sig mer om c64ans olika minnes regioner kan man börja med diverse enkla effekter på texten:

Text som blinkar i regnbågens färger är inte alls lika imponerande som stillbild.

Se koden här, den är kort och ganska enkel men har ett par rader assembler.

Nästa steg blir att utforska bitmap mode, avrottshantering och kanske lite sköna vågformer i SID-chippet.

Pycon Sweden 2015

I tisdags gick den numera årliga python konferensen pycon sweden av stapeln. Likt förra året var det en fantastiskt trevlig upplevelse.

Första dagen

En stor del av föredragen behandlade data-analys och datorinlärning. Mycket av detta gick mig över huvudet men intressant att få lite insikt i vilka möjligheter det moderna samhället ger till att samla och analysera data. Också intressant var att gå igenom hur man tränar upp ett neuralt nätverk för bildanalys. Föredragen var väldigt tekniska och eftersom de var relativt korta var de rätt övergripande och gick inte jättedjupt.

Ett annat föredrag som jag tyckte var intressant var föredraget om U2F, en standard för tvåfaktor-autentisering. Dain Nilsson som stod för föredraget arbetar för Yubico och därför var särskild fokus på deras lösning YubiKey. YubiKey är en usb-dongel som agerar som ena faktorn i autentiseringen och verkar vara mycket smidig.

Kvällen

Efter sista föredraget bjöds det på en gratis drink i baren och folk minglade. Jag pratade med diverse människor, en amerikan, en finländare som jobbade med databaser och ett helt gäng andra. Vi åt middag ett gäng och hamnade i slutändan på Oliver Twist.

Dag Två

Andra dagen inleddes med ett föredrag av Kate Heddleston om etik och moral. Vad är vårt ansvar som programmerare när tekniken vi bygger används för hatbrott, förföljelse, riktad reklam, etc? Inga raka svar gavs men det är frågor som måste lyftas fram och diskuteras öppet.

I övrigt var andra dagen lite mer blandad än den första. Ett av de mer intressanta föredragen handlade om Python i inbyggda system. Presentatören använde python i produktionskod men listade mest problem användningen av python resulterade i. Generellt kändes det ganska negativt.

Konferensens sista föredrag var Python for Humans, en diskussion om hur pythonmoduler bör skrivas. Föredraget grundades i PEP20, som är språkets riktlinje men som frångåtts i mångt och mycket. Tanken är att det ska finnas ett (och gärna endast ett) intuitivt, lätt sätt att åstadkomma något. Mycket tankeväckande och nästan inspirerande.

Föredragen spelades in och kommer inom kort läggas ut på hemsidan.

pickle

Dillinlagda gurkor*

Till mitt lilla spel ville jag lägga in möjligheten att spara och ladda spel och funderade länge på hur man gjorde det på bästa sätt. Jag hittade efter ett tag pickle i pythons standardbibliotek som visade sig vara ett enkelt sätt att hantera detta på.

Det pickle-modulen gör är att serialisera python-objekt till en fil. Med detta menas att pickle omvandlar objektet till en serie bytes som sedan kan skrivas till fil. Man kan jämföra det med att i C dumpa en struct via

typedef struct {
int pos[2];
int size[2];
char name[256];
} data_t

data_t d;
write(file, d, sizeof(d));

Detta fungerar för struct:ar som enbart innehåller data, men innehåller den referenser blir det hela mer komplicerat och kräver särskild implementation. Eftersom python ser allt som objekt, blir Pickle lite mer intelligent och serialiserar all data som lagras i objektet samt alla andra objekt som objektet hänvisar till (rekursivt hela vägen ner till basobjektet object) samt funktionerna (kod är också objekt) som ingår i objektet.

För att spara all data i mitt spelarobjekt räcker det med

pickle.dump(player, open(player.save_slot + "/player.data", 'wb'))

vilket ser ganska enkelt ut, tyvärr finns det komplikationer. När jag försökte detta första gången fick jag följande felmeddelande

TypeError: can’t pickle Surface objects

Detta beror på att objektet måste ha bland andra metoderna __getstate__() och __setstate__() för att läsa ut samtliga objekt i objektet och pygame-objekten saknar detta (åtminstone Surface och Sound och i dessa fall är det nog vettigt att hantera utanför pickle pga. datamängden).

För att gå runt det här problemet måste de felande objekten raderas från listan av objekt som sparas och sedan manuellt återställas när objekten laddas in igen. Detta görs genom att implementera en egen variant av __getstate__() och __setstate__():

def __getstate__(self):
print 'getting state!'
state = dict(self.__dict__)
#remove unpicklables
state = {s:state[s] for s in state if s != pygame.Surface and s != pygame.Sound}
return state

def __setstate__(self, state):
self.__dict__ = state
self.a = animate.animationGroup()
self.restore_unpicklables()

När pickle.dump sparar objektet anropas mitt objekts __getstate__() och innan uppslagsverket med alla objekt returneras plockas alla objekt som inte kan serialiseras bort (här pygame.Surface-objekt och pygame.Sound-objekt). När sedan objektet skall återställas kallar pickle.load() på __setstate__() för att återställa objektets interna uppslagsverk anropas funktioner för att återskapa de borttagna objekten.

Det här metoden att hantera sparfiler på har både brister och fördelar men fungerar bra under utvecklingen och tog en halvtimme att skriva ihop. Den stora fördelen var att jag snabbt kunde komma igång och få någonting som fungerar. Den stora nackdelen är att spelarobjektets blir exakt som det var när det sparades och ifall variabler eller nya funktioner tillkommit kommer dessa saknas vilket kan leda till strul. Sedan bör man nämna att picklade objekt är relativt osäkra i och med att allt lagras i ett helt öppet format och inga kontroller genomförs innan datan laddas in.

* Bilden kommer härifrån, rekommenderas för inspiration för heminlagda gurkor!

Kodtäckning i vim

Jag börjar sakta men säkert komma igång med enhet/integrationstest av den kod jag skriver. Det hjälper och är inte allt för besvärligt när man kommit in i tankesättet. Jag använder mig av gtest och lär mig sakta men säkert dess funktioner.

13 Test och allt funkar, men vad säger det?

Frågan man bör ställa sig är hur mycket av koden som faktiskt körs av mina tester och vilka olika vägar genom funktionerna som testas, dvs vilken kodtäckning har mina test.

gcc inkluderar verktyget gcov för att generera den här typen av information. Efter att ha lagt till kompilatorflaggorna -fprofile-arcs -ftest-coverage genereras gcov-filer när mina tester körs. Och när man sedan kör

gcov [filnamn.c]

får man en kort sammanfattning samt en gcov-fil

File 'filnamn.c'
Lines executed:64.90% of 510
viacode.c:creating 'viacode.c.gcov'

Den skapade *.gcov filen innehåller information om hur många gånger varje kodrad i filen har exekverats. För att gör det smidigare att använda ville jag ha in resultatet i min editor vim. Efter lite googlande hittade jag ett vim-skript som med lite modifieringar resulterade i detta:

" Based on Gautier DI FOLCO's vcov.vim found in
" https://groups.google.com/forum/#!msg/vim_use/tk9sG714b3I/LyMnXOQAqpMJ
"
" Modified by Åke Forslund <ake.forslund@gmail.com>

hi gcovCovered ctermbg=2
hi gcovNotCovered ctermbg=1

function! Setcov(filename)
exe ":sign unplace *"
for line in readfile(a:filename)
let d = split(line, ':')
let c = substitute(d[0], " *", "", "")
let l = substitute(d[1], " *", "", "")
if c >= 100
let c = '*'
endif
if '-' != c && c !~ '#'
exe ":sign define c" . c . " text=" . c . " texthl=gcovCovered"
exe ":sign place " . l . " line=" . l . " name=c" . c . " file=" . expand("%:p")
elseif c =~ '#'
exe ":sign define cd text=# texthl=gcovNotCovered"
exe ":sign place " . l . " line=" . l . " name=cd file=" . expand("%:p")
endif
endfor
endfunction

function! Unsetcov()
exe ":sign unplace *"
endfunction

map <F11> :call Setcov(expand(@%).".gcov")<cr>
map <F12> :call Unsetcov()<cr>

Skriptet finns på github med.

När jag nu trycker på F11 får jag in information om hur många gånger en viss rad anropas, alla rader som inte exekveras överhuvudtaget markeras i rött och rader som inte räknas in markeras i vitt.

gcov-data Visualiserat i vim.

Det fungerar finfint och hjälper mig extremt mycket i mina taffliga försök att skriva relevanta testfall. Ytterligare funktioner kan med all säkerhet vara önskvärt och min plan är att slipa det ytterligare. T.ex hantera en saknad .gcov-fil på ett snyggt sätt.

PyCon Sweden 2014

Tisdag till Onsdag förra veckan gick första upplagan av PyCon Sweden av stapeln och ett par hundra python intresserade människor trängde ihop sig i KTHs Q-hus för att lyssna på föredrag och umgås. Jag var där, lyssnade på intressanta föredrag och pratade med ett gäng intressanta personer.

Administrativt fungerade det mesta bra, finfina luncher och bra info (även om schemat släpptes rätt sent). Inga katastrofer och stämningen var bra. Lunchuppehållen var rätt långa vilket gav tid till att umgås och prata med folk.

Pythonistas på grönbete.

Föreläsningarna var överlag intressanta och innefattade många olika ämnen, allt ifrån att bygga ett tag-in-system för ett gym till hur kryptografi fungerar på internet och vad svt pejl sysslar med.

Den i särklass bästa föreläsningen var Kenneth Reitz föredrag om den splittring som håller på att ske i Python. Skillnaderna mellan python2 och python3 skapar sprickor i python-gemenskapen. Dels mellan användare av de olika varianterna (min mjukvara kan inte köra på din dator för att du har en äldre version av python), och dels mellan användare och utvecklare (de flesta användare använder fortfarande python2 medan utvecklare är mer intresserade av python 3). Enligt en snabb överslagsräkning är det endast 4.3% av användarna som använder python3. Detta är problematiskt då det lämnar mycket buggar i bibliotek som portats till python3 till och med i standard biblioteket finns det mycket oegentligheter. Lösningen är enkel men svår, vi måste engagera oss. Vi måste göra vad vi kan för att ena vår gemenskap. Stöd python3, stöd python2, ansträng dig, rapportera de buggar du hittar!

På tåget hem reflekterade jag över hur fantastiskt det är med den gemenskap som finns. Alla dessa människor som rest in för att hålla ett föredrag utan att få mer än fri entré till konferensen. Alla dessa smarta människor som tar den tid det krävs för att utbilda och dela kunskap med sådana som mig. Alla dessa människor som har slitit i veckor för att fixa alla luncher, lokaler, scheman och alla andra detaljer som skall klaffa.

Ett stort tack till arrangörerna, föreläsare och deltagare!

Intervalometer på github

Min första Android-app Intervalometer ligger nu på github i ett någorlunda fungerande skick. Intervalometer skrevs för att hantera springintervaller (eller annan intervallträning), dvs man sätter en serie tider som genererar en larmsignal som indikerar att intervallet är slut.

En ganska simpel applikation men den krävde en del trixande och kanske viktigare förståelse för hur Android fungerar. Ett tag slogs jag med att få koll på hur Android’s services fungerar och hur man kommunicerar med dom. Sedan slogs jag en del med att få till det så min tjänst kunde exekvera medan skärmen är släckt.

Tanken är att jag ska putsa på den fixa buggar och lägga till de funktioner som jag anser saknas (radera intervall, välja ljud, olika kategorier på intervalltiderna) och sedan lägga ut den på Google Play. Känner jag lust funderar jag på att lägga till GPS-stöd och möjligheten att sätta intervallerna som sträckor istället för tid.

En annan sak jag slogs med rätt länge var att en Sony Xperia-telefon inte ville identifiera sig för Android studio. Detta var frustrerande men efter ett tag luskade jag ut att adb-tjänsten var tvungen att köra som root för att det ska fungera. För den med liknande problem hjälpte följande rader i terminalen mig

sudo adb kill-server
sudo adb start-server

Jag är hyggligt säker på att jag inte har gjort ”rätt”(TM) i alla lägen, senast idag lärde jag mig om att det finns en alarm-hanterare som kan göra underlätta en del och göra saker och ting enklare.

Eftersom jag både är Android- och Java-rookie mottar jag gärna kommentarer på min kod.

Första intrycket av Android Studio

Jag är som vanligt sen på bollen men jag tänkte ändå att App-utveckling kunde vara roligt att prova på. I ärlighetens namn provade jag att installera android-utvecklingsverktygen en gång tidigare men eclipse fick mig att vilja tugga på tangentbordet. Hela upplevelsen var seg och rätt rörig.

Installationen är relativt enkelt, jag laddade ner ett paket med Android-studio och android-SDK vilket bara var att starta efter jag hade installerat Java ordentligt. Att hitta rätt variant av Java var det mest besvärliga med installationen.

Android Studio är baserad på intelliJ, ett öppet Java IDE, och byggverktyget Gradle som uppenbarligen är bra på alla möjliga vis (men jag tänker inte gå närmare in på det eftersom detta är ett första intryck).

IDEt känns rappare än eclipse och upplägget är mer logiskt och en mindre uppsättning inställningar gör det hela mer lätt att greppa. Att skapa ett relativt vackert användargränssnitt går snabbt och lätt i layout-editorn.

Androids applikation med aktivitets-klasser vars olika funktioner anropas av Android är förvånansvärt lätt att sätta sig in i även för inbitna C-programmerare. För den som inte är insatt så skrivs android-applikationer traditionellt i Java. Ett objektorienterat högnivåspråk som skall vara helt plattformsoberoende (men har aldrig varit det på riktigt). Man kan säga att C är Javas farfar, C utvecklades vidare till C++ som Java sedan lånade mycket ifrån. Denna nära relation gör att det är lätt att sätta sig in i grunderna och Python har gett mig lite insikt i objekt orientering så det känns relativt intuitivt.

Efter ett par timmar med Android Studio och ett par googlingar har jag lyckats ta mig från en app som säger ”Hello World” till en app med en knapp som byter text när man trycker på den till ett stoppur. En stor fördel är att det går snabbt och enkelt att ladda ner sitt projekt till sin telefon och köra det. Vilket innebär att det går snabbt att prova saker.

Mitt Projekt ”Intervalometer”

Hastigheten att komma igång är ett plus med dessa avancerade programmeringsmiljöer, dock saknar jag fortfarande mycket förståelse för att vara helt bekväm med det hela. Men det kommer kanske?

Allt är inte guld och gröna skogar… Det mest frustrerande är att kompileringsprocessen tar makalöst lång tid, minst en minut. Sedan har jag stött på fall där visningen på min bildskärm skiljer sig från det som visas i telefonen när jag kör programmet där, detta är av mindre vikt men lite förvirrande.

Första intrycket är positivt, det är mest roligt att programmera och inte så mycket frustrerande alls. Jag har kommit igång oerhört snabbt och är redan produktiv även om jag måste googla en hel del ännu.

Resurs-cachning i python

I Pixel Wizard instansieras nya objekt relativt ofta under spelets gång, eldbollar och andra magier som spelaren skapar och projektiler som fiender skjuter iväg. Objekten skapas raskt men när grafik och ljud laddas märks en tydlig prestandaminskning. För att komma runt detta skrev jag ett mycket enkelt system för att cacha ljud och grafik:

"""Resource loader for images and sound"""

import pygame
import re

resource_dict = {}

def load(filename):
    if not filename in resource_dict:
        if re.match(".+\.wav", filename):
            r = pygame.mixer.Sound(filename)
        elif re.match(".+\.png", filename):
            r = pygame.image.load(filename)
        resource_dict[filename] = r
    return resource_dict[filename]

def clear():
    resource_dict = {}

Koden ovan utnyttjar pythons dictionary datatyp för att enkelt med väldigt få rader kod bygga ett caching system. resource_dict är en dictionary där en sökväg/filnamn används som nyckel och värdet är ett objekt som innehåller en referens till ett objekt för datat som filen innehåller.

load() kontrollerar ifall sökvägen filename är en nyckel i resource_dict, om den finns returneras objektet som är kopplat till nyckeln. Ifall den inte finns laddas datat från filen (en kontroll ifall det är en bild eller en ljudfil görs) och sökvägen läggs in i dictionaryn tillsammans med det nya objektet, efter detta returneras objektet.

clear() nyttjar pythons garbage collector och tar helt enkelt bort referensen till objektet, när alla andra referenser till objektet har tagits bort kommer det raderas automatiskt.

Detta system gör också att samma grafik inte laddas in flera gånger även om ett det finns 17 kopior av en fiende refererar grafiken (och ljuden) till ett och samma objekt.

Flera monster men ett grafikobjekt

Python i samväldet

Den 20-23:e september gick PyConUK av stapeln, och lyckades ta mig dit trots en tågresa från Gatwick med mängder av stopp. Ett längre stopp i Bletchley lät mig ta en snabb språngmarsch genom Museet på Bletchley Park.

En Enigma maskin

Själva konferensen började på fredagsmorgonen med frukost och välkomnande. Det genomgående temat var ”To be perfect is to change”, vilket innebar att mycket förändringar skedde med lite förvarning. Det var inte alltid åhörare hamnade på rätt föreläsning och det var inte alltid föreläsarna hamnade i rätt rum.

Zeth önskar oss välkomna.

Det var lite rörigt men det vara roligt hela tiden, en stackars föreläsare startade för tidigt men räddade upp situationen genom att dra föreläsningen en gång till.

Det var många bra och intressanta föreläsningar och mycket av dem finns upplagda här. Några personliga favoriter var

• Cooking high quality software -I denna föreläsning utsattes den brett flinande publiken för en serie dåliga skämt av en man med suspekt fransk brytning iförd kockkläder. Parallell efter krystad parallell mellan mjukvara och restaurangmatlagning levererades till åhörarnas jubel. Det var roligt men samtidigt tog den upp många av de moderna/trendiga mjukvara-utvecklingsteknikerna.
• All-singing all-dancing python bytecode – Larry Hastings gick igenom pythons byte-kod och förklarade hur den fungerade och varför det var en dålig idé att använda den. För att förstå pythons byte kod måste man ha en djup förståelse om hur språket fungerar, så mycket gick mig över huvudet. Detta till trots var det en väldigt intressant föreläsning.
• Turtles – Detta var två seminarier om olika förbättringar av turtle, ett ramverk för att underlätta undervisning av programmering med hjälp av sköldpaddor. I grunden kan man endast styra sköldpaddorna genom att rotera dem och förflytta dom framåt och bakåt. physical turtle ger sköldpaddorna möjlighet att kollidera med väggar och ninja turtle är ett projekt för att modularisera turtle och ge modulen ett fräschare utseende.
• Ubiqutous Larch: Ett ramverk för samarbete via webben. Anteckningsblock där dokumentation, python-kod och java script kan skrivas tillsammans med andra. Koden exekveras live och förändringar i koden slår igenom direkt. Uppenbarligen påminner den en del om iPython.

På lördag eftermiddag fanns möjligheten att delta i en kod-dojo, där man i grupp försöker lösa något problem. Vår uppgift var att implementera ett enkelt plattforms-spel i minecraft där man flyttades till startpositionen ifall man trillade ner från plattformen. Arbetsformen var väldigt intressant och alla deltog glatt. Jag skulle gärna vilja delta i fler sådana här dojos, möjligheten att lära är stor.

Konferensens var inte bara seminarier och övningar utan också en hel del socialiserande. På fredagen var det en enkel middag på en närbelägen pub och på lördagen var det en ordentlig middagsbjudning. Det diskuterades allt ifrån programmeringstekniska frågor till feminism till Monty Python.

Monty Python-referenser: The Larch, dead-parrot-state, Maynard och wafer thin mint.

Jag lärde mig mycket, den mest grundläggande upptäckten var unpack-tuple operatorn (*). Andra grundläggande upptäckter var pakethanteraren pypi samt det mycket praktiska virtualenv.

Det var en kul konferens och det har gett mig mersmak både för python och konferenser generellt.