2010-08-17

Det knogar på

Så kan man ju inte säga. Hursomhelst, knogar på gör det! Min build environment dog av någon anledning, så nu har jag inte längre någon REPL inbyggd i min editor. Klarar mig fortfarande bra med programmeringen av applikationen, men slösade typ en dag på att försöka få det att fungera. Roligt nog tror jag att min ändra-kompilera-testa cykeltid har minskat, för att använda SBCL i en separat terminal är snabbare än att ha den kopplad innifrån editorn.

Har börjat programmera på månadsvyn, och det går fint. Har brottats mycket med att få text att skrivas ut på korrekt plats utan att för den delen krocka undan grafiska komponenter... bråk med CLIM-standarden eller McClim som vanligt, med andra ord. Nu fungerar det dock och jag kan använda det jag gjort här i dags-vyn när jag sätter igång med den senare.

Har också byggt en del funktionalitet så att jag kan visa flera almanackor samtidigt i månadsvyn, men behöver refactora lite så att jag använder en explicit struktur för att tala om för vyer vilken information de ska visa innan jag fortsätter med lite mer av månadsvyns funktionalitet.

Såhär ser månadsvyn ut nu:

2010-08-03

År nästan färdigt

Nu skriver jag ut totalt bokade tider för året och månaderna, kan komma att ändra lite på hur de ser ut men funktionaliteten finns i alla fall.

Har också fixat så att dagar där överlapp finns blir röda, och har man implementerat överlapp så ser man tydligt var på dagen överlappet finns.

Såhär ser det ut:





















Nu återstår att fixa så att man kan se ledighet istället för det som är bokat.

2010-08-01

So far so good, 20 arbetsdagar kvar

Äntligen äntligen äntligen! Nu känner jag att bollen är i rullning, så att jag inte längre behöver jobba med att bygga upp momentum utan kan arbeta med saker som direkt ger resultat.

Har ju suttit och behöver läsa in mängder med dokumentation så fort jag försökt göra någonting tidigare, men nu har jag:


  • Konvertering från almanackans typer till CLOS-objekt
  • Kan upptäcka funktionalitet och förändra beteende därefter
  • Rita ut grafik från data, representera objekt
  • Välja vad som ska vara klickbart och reagera på klickningar


Med detta har jag nästan byggt färdigt års-vyn, och bör inte behöva mycket mer för månads- och dagsvyerna. Det återstår en del att göra, men så här ser det ut nu:



Här finns funktionen längd-av-tidsperiod implementerad, vilket almavis reagerar på genom att färga dag-rutorna efter hur många minuter som är bokade.


Jämför med när almanackan inte har längd-av-tidsperiod implementerad. Nu räknar jag istället antal möten under dagen, och har bara fyra nyanser att välja mellan. Resultatet blir att januari månad, där det bara ligger ett möte per dag, förlorat all sin lyster.

Framtida problem:
McClim, som jag använder, är utvecklat av obetalda entusiaster. De har för det mesta gjort ett bra jobb, men det huvudsakliga sättet att byta layout på fungerar inte på den här implementationen. Folk löser det genom att inte använda flera layouter och byta mellan dem, utan istället ha en layout där man byter ut innehållet. Eftersom jag ändå ska porta över mitt jobb till Allegros Clim så tänker jag inte hålla på med sådant.

Jag har planerat att göra en test-integrering när år-funktionaliteten är färdig, för att se vilka problem som uppstår och bättre kunna uppskatta när jag behöver börja med den slutgiltiga integreringen. Förhoppningsvis kan jag skriva lite kod som automatiserar det värsta av portningsjobbet, vi får se hur generaliserbart det problemet är. Hur som helst så garanterar det ju också att det i alla fall faller något användbart i studenternas knän. Integreringen ger också tillfälle att testa om jag kan använda den vanliga metoden för layout-byten, så jag väntar med allt sådant till dess.

Push-pull problemet som jag ordat om många gånger bör gå att lösa på något sånt-här vis:

(let ((old-boka (fdefinition 'boka)))
   (setf (fdefinition 'boka)
      (lambda (&rest argument)
         (prog1
             (apply old-boka argument)
             (meddela-almavis-om-uppdatering)))))

Återstår att försäkra sig om att fdefinition-grejjerna kommer fungera som de ska, och att fundera ut just hur det är lämpligt att informera en CLIM-applikation om att den behöver rita om displayen (den verkar dock göra det nästan varje sekund, så det är inte säkert att det behövs, dock) - man vill inte bara kalla på redraw-funktionen utifrån eftersom applikationen har ett eventsystem man inte vill pajja.

Ska också hälsa från Robert Strandh, den första utexaminerade D:aren. Han jobbar som professor nere i Frankrike (Bordeaux, har jag för mig) och hänger på #lisp på freenode. Han har implementerat en hel del av McClim och har svarat på många frågor och hjälpt mig otroligt mycket med att orientera mig i ramverket, och har även hjälpt till med annat (fdefinition-hacket var hans idé). Jag beundrar honom för att han står ut med mina frågor på sin fritid, och uppskattar det högt.

2010-07-23

Kodkvalitet

Insåg att jag ofta känner mig osäker på om min kod fortfarande kommer att fungera när jag använder lisp, mycket djup rekursion, lambdauttryck och annat häftigt som kan gå fel. Så jag skrev en unit-test-modul. Den tog längre tid än jag trodde att skriva, runt 1½ dag.

Även om det ger mig större självsäkerhet i att nyttja och utöka kodbasen så känns det som om tiden rinner mig ur händerna. Jag har ännu inte fått någon vy att fungera, och vecka 29 tog just slut. Enligt min planering borde jag bli färdig med den grundläggande funktionaliteten nästa vecka - det kommer jag inte vara. Utöver det har jag en vecka till avancerad funktionalitet och tre till dokumentation och integrering. Tur det, för det kommer att bli tight om tid.

Jag har alltså ungefär 5 veckor på mig, totalt. Jag är inte riktigt säker på hur det kommer att te sig med att få det grafiska att fungera, det verkar antingen som om det ska gå som en dans efter att man fattat galoppen - eller som om det kommer bli som att kräla på glas med bakbundna händer. Jag hoppas att det kommer ta max 1 vecka per vy (tot. 3 v.) så att jag får två veckor till integrering och dokumentation - det kommer nog behövas.

Det känns alltså dåligt. Samtidigt känns det bra, för jag har ju i alla fall äntligen fått en hel del kod skriven - det gör saken lättare att bära.

2010-07-21

Almanackasobjekt -> CLOS, check

Spenderade gårdagen och idag med att skriva kod för att traversera almanacksobjektsträden (år->månad->dag->möte) och konvertera dem till CLOS-objekt.

Anledningen till att jag vill mappa almanackans objekt till CLOS-objekt istället för att använda dem ad-hoc är att Clim utgår från att man har CLOS-objekt som man vill visualisera med presenters. Det går, tekniskt sett, att skriva presenters utan CLOS-objekten, men jag vill kunna följa det som är mest common-case för att lättare kunna ta till mig hjälp från manualer, guider och andra programmerare.

Så som det ser ut nu så har jag objekt som heter clim-år, clim-månad, clim-dag och clim-möte. Egentligen hade jag kunnat effektivisera det hela genom att bara ha clim-möte, som håller reda på när det sker. Det hade dock gjort det svårare i framtiden. När jag (imorgon) börjar med att skapa år-vyn så vill jag ju inte visa varje enskiljt möte, utan vill visualisera dagar (nestlade i månader - det finns stöd för men verkar lite småklurigt). Jag var lite orolig över att det kan bli ineffektivt att behöva traversera igenom alla årsalmanackor varje gång vi behöver uppdatera vår information, men det verkar inte så farligt - vi får se hur IDA-burkarna klarar av det.

Koden ser ut såhär: http://dl.dropbox.com/u/6174666/almavis.lisp

Har fortfarande inte fått klarhet i om push går att använda med :after funktioner, men det är någonting jag tar i tu med först när jag har någonting visuellt att uppdatera.

Kan också nämna att jag ännu inte har koden i något VCS, utan använder mitt DropBox account. Där har jag hyfsad versionering, tillgång till koden från alla mina olika datorer och säker backup. Personen som skulle fixa en dev-server åt mig är just nu ganska upptagen med de konsultjobb han har, men det har ju som märkts inte påverkat så mycket.

Det känns som om jobbet går bra. Närhelst jag sitter och får kod gjord känns det mysigt, medan jag känner mig lite hopplös när jag sitter och läser Clim-dokumentation. Nu känns det dock bättre än det gjorde när jag började med att försöka implementera års-vyn, då visste jag inte var jag skulle börja. Nu vet jag att jag behöver fixa presenters för mina objekt, och att de behöver klara nesting.

2010-07-15

Clim är svårt

För att vara så flexibelt så behöver Clim såklart också vara svårt. Det finns massor av exempelapplikationer med, så jag har kollat på en del av dem för att se om jag kan imitera för att snabbt bygga min applikation. Verkar inte så, allt för många macron används så det blir svårt att se vad som är funktionskod som kan kopieras och klistras, och det är mycket jag inte vet hur eller varför det används - trots att jag läst en del av manualen. Att de gör avancerade applikationer på väldigt få rader kod är ju lovande, men nu ska jag gräva ner mig i lite guider och manualer för att förstå grunderna lite bättre.

En ok dag

Har fightats mycket med ASDF-systemet och uppdelning av projektet i olika filer idag. Den mesta av tiden gick åt till att lära mig hur paket fungerar i CL. Fixat så att mitt system kan se vilken funktionalitet studenten implementerat, det var inte speciellt svårt - mest anrop av typen (find-symbol "överlapp" 'common-lisp-user). Det krävde dock också krävde att jag lärde mig pakethantering.

Anledningen till att pakethantering behöver användas är för att man väldigt starkt rekommenderas att göra det när man programmerar Clim. Clim använder nämligen ett eget paket för sina egna funktioner, och antingen så gör man sitt eget eller så skriver man sin kod i det paketet - inte nice. Detta medförde att jag behövde fixa en visa-grafiskt funktion i default-paketet (common-lisp-user) som almanackan kommer vara definerad i, vilket gjorde det svårt att fixa dependencies och sånt utan att ha ett ordentligt ASDF-paket. Hittade dock en väldigt bra irc-kanal (#lisp på freenode.net) där erfarna lisp-användare kvickt svarade på mina frågor. De dirigerade mig till bra information om paket och hur man utformar dem smidigast.

Det kan hända att jag behöver ändra en del av de här sakerna när jag kör på IDA (ASDF finns med i AllegroCL sedan 7.0, vet ej vilken version IDA kör) men det är ganska trivialt att fixa. Det finns större problem att se upp för: CLIM standarden är lite tvetydig ibland, så McClim och Allegros implementationer av standarden är tydligen inte alltid de samma - därför tycker jag att det är trevligt med den extra veckan planerad för dokumentation jag gav mig själv i min milestone-plan i en tidigare blogpost.

Imorgon kommer jag sätta igång med att implementrera års-vyn. När jag är färdig med den så tänker jag först se om det fungerar att köra på IDAs datorer, sedan forstätta med månads- och dagsvyerna.