Visual c++ och pragmatik

Jag fick inte uttrycket

std::numeric_limits::max()

att kompilera i microsoft visual c++. Det visar sig bero på att makrot max är definierat!
Det betyder att alla variabler eller funktioner som heter max fallerar med mystiska kompilatorfel.
Helt otroligt. Jag undrar vad mer som är definierat på liknande sätt...

Mer info finns här.

Små, små framsteg med utf-8

Jag har försökt att lösa mina filsynkroniseringsproblem på macen.
Spår 1: afp via netatalk. (tack för tips, anders j!)
Gick inte, fick autentiseringsfel. Bort med leopards regel om krypterat lösenord, funkar ej (trots två omstarter). Väldigt intressant kombo-binärt/text-format apple använder, skumt.
Nytt försök. omkompilering av netatalk enligt standardreceptet. funkar ej heller. Får fortfarande det irriterande "error -5002" från macen. Gaaahh!! Svårt att felsöka en dialogruta från operativsystemet. (5002 är alltså att lösenord i klartext inte stöds)

Spår 2: loopbackmontering med fuse+unison.
Det förinstallerade fuse är för gammalt och stöder inte modulen iconv. In med det nya, tar mig förbi den skumma modulsyntaxen och får monteringen att funka med
./loopback ~/otherhosts/voltaire-as-utf8 -omodules=iconv:subdir,subdir=$HOME/otherhosts/voltaire,from_code=UTF-8-MAC,to_code=UTF-8
efter att jag passerat det irriterande felet att _iconv_open() inte hittats av dynlib.

Spår 2 verkade funka ända till dess att unison klagar på att mina kataloger innehåller filer som är lika bortsett från stora/små bokstäver. Detta trots att jag formaterat om volymen till case insensitive via macs diskverktyg. suck.

Debian-Mac 1-0, igen.

Om att välja antal aktier

Vilket antal aktier ska man välja för att det ska gå att dela upp jämnt på flera?
Om man väljer 100 går det bra att dela på 2 eller i hela procent. Om man vill dela på tre blir det svårare, då får man välja mellan 33 eller 34 aktier.
Det här frågan löses med least common multiple (minsta gemensamma multipeln).

Om man t ex vill kunna dela aktierna jämnt på 2, 3, 4 personer måste man välja antalet aktier till lcm(2,3,4)=12 eller en multipel av 12.
Här finns en webapplikation för att beräkna lcm:
Jag föreställer mig att jag vill kunna dela på 2,3,4,5,6,7,8,9,10,100 (det sista för att kunna välja ett heltal procent) och får då 12600 aktier.

Flera intressanta följdfrågor dyker upp:

• går lcm för ett godtyckligt antal värden att beräkna genom att börja med de två första och därefter beräkna lcm för det föregående resultatet och nästa tal? alltså lcm(a,b,c,d,...,x)=lcm(...lcm(lcm(a,b),c),...),x)
• går det att hitta en mer effektiv algoritm att beräkna lcm om man kan utnyttja ovanstående? vissa par av tal kanske är lättare att hitta en lösning till.

Kompilera boost med visual c++ studio 2008 express

Jag håller just nu på att försöka få igång en applikation jag skrivit i windowsmiljö.
För att kunna köra samma kod på flera plattformar använder jag boost på diverse ställen.
Det är inte helt lätt att använda de bibliotek i boost som inte enbart består av templates. I instruktionerna på boosts hemsida används kommandona bootstrap följt av bjam.
Det fungerade inte för mig.

Efter att ha manuellt ha lagt till pathen till kompilatorprogrammen fungerar det betydligt bättre.
I kontrollpanelen, system, avancerat, miljövariabler lägger jag till variabeln path
;%c:\Program\Microsoft Visual Studio 9.0\VC\bin
som är den sökväg som innehåller filerna cl.exe etc.

Fuse och teckenkodning

Försökte göra en workaround på mitt unisonproblem genom att loopbackmontera en katalog som utf-8 "standard" och sedan köra unison mot denna katalogen. Iden är att använda den teckenkonvertering som finns inbyggd i macfuse via modulen iconv.
Se tråd här för detaljer.

Det funkade inte. Den fuse som är förinstallerad på macen i leopard (ja, jag nergraderade till leopard för att det kändes som att inget av det jag ville köra fungerar ännu i snow leopard) verkar inte stöda iconv. Det kanske är något annat. Suck.
Hur gör andra människor som vill synkronisera sina data på mac?

Mac os x och mittenknappen

Jag inser hur mycket jag vant mig vid att klistra in text med hjälp av mittenknappen i linuxmiljö. Finns något sätt att göra motsvarande i mac os x?

För övrigt misslyckades installation av xcode efter att jag uppgraderat till snow leopard. 1-0 till debian...

Unison, unicode och kompatibilitetsproblem

Jag har försökt att få synkroniseringsprogrammet unison att fungera i mac os x.
Min server använder utf-8 som teckenkodning på filsystemet. Vad mac använder verkar vara normaliserad utf-8 (se här för intressant läsning).
Unison funkar inte alls särskilt bra för mig på sökvägar som innehåller icke-ascii-tecken. En katalog som heter "företag" dupliceras till originalet och en kopia som renderas likadant med en annorlunda representation. Dvs filnamnet är binärt olika men bokstäverna är samma. Det är just detta som unicode-normalisering strävar efter att lösa.
Först trodde jag att det är unison som är boven i dramat, men det är snarare Apples fel! Citerat ur manualsidan för convmv:

Filesystem issues

Almost all POSIX filesystems do not care about how filenames are encoded, here are some exceptions:

HFS+ on OS X / Darwin

Linux and (most?) other Unix-like operating systems use the so called normalization form C (NFC) for its UTF-8 encoding by default
but do not enforce this. Darwin, the base of the Macintosh OS enforces normalization form D (NFD), where a few characters are
encoded in a different way. On OS X it’s not possible to create NFC UTF-8 filenames because this is prevented at filesystem layer.
On HFS+ filenames are internally stored in UTF-16 and when converted back to UTF-8, for the underlying BSD system to be handable,
NFD is created. See http://developer.apple.com/qa/qa2001/qa1173.html for defails. I think it was a very bad idea and breaks many
things under OS X which expect a normal POSIX conforming system. Anywhere else convmv is able to convert files from NFC to NFD or
vice versa which makes interoperability with such systems a lot easier.

Nog med inledning, detta fick mig att läsa på lite om unicode.
Jag använder mitt katalognamn "företag" som exempel.
Det kodas i utf-8 som
66 c3 b6 72 65 74 61 67

ö-et blir alltså hex c3-b6 eller binärt 11000011 10110110 där jag markerat utf-8-prefixen med fetstil. Payload är alltså 11 konkatenerat med 110110 villket är F6 hex som är "direktformen" för ö, eller "Latin Small Letter O with diaeresis" som det heter. Låter snarare som en sjukdom....

Om jag nu kollar vad som hänt på servern ser jag att det finns två mappar som heter företag.
$ls |grep retag
företag
företag
en undersökning av representationen (genom att pipa till hexdump -C) ger (jag har tagit bort newline 0a manuellt):
66 6f cc 88 72 65 74 61 67
66 c3 b6 72 65 74 61 67
ö-et kodas alltså som 6f cc 88 i det första fallet och c3 b6 i det andra (som jag förväntat mig.)
En avkodning enligt ovan ger att 6f är bokstaven o, och prickarna kommer till i efterhand genom cc 88 som binärt är 11001100 10001000 och lasten därmed 0x308 som betyder två prickar(leta efter rad med 0300 i vänstra kolumnen och kolumn med huvud "8").
Det som behövs för att unison ska förstå att dessa två filnamn egentligen är samma är normalisering.
Det är verkligen inte trivialt att hantera teckenkodning korrekt!