No i stało się

Przed chwilą dokonałem zmian w PyXMPP w kierunku który doradził Jarek,
ostatecznie zrobiłem tak:

  • fr -> from_jid
  • to -> to_jid
  • typ -> stanza_type
  • sid -> stanza_id

Dla ułatwienia życia sobie, a także innym developerom używającym PyXMPP
(są tacy?) przygotowałem też skrypt poprawiający kod pythona używający starych
nazw. Mnie nawet ten skrypt nic nie popsuł.

A w pracy wkurzałem się na interfejs WWW zarządzania switchy DLink
i access-pointów Proxima. Chcę dać na zewnątrz (żebym miał w domu,
czy gdzieś w terenie) dostęp do tych urządzeń. Że urządzenia nie mają SSL, to
nie mogę tego po prostu przeroutować, więc robię to przez reverse-proxy na
Apache z mod_ssl. Pierwszy problem to bezwzględne linki na stronach tych
interfejsów. Ale to załatwia (teoretycznie) mod_proxy_html.
Tylko, że mod_proxy_html parsuje otrzymany HTML, poprawia co
trzeba i serializuje od nowa. Ale jak to ma działać na czymś co do HTMLa jest
tylko miejscami podobne (tak jest w przypadku Proxima — po prostu
koszmar)? No nie całkiem działa. Do przeglądarki dochodzi już poprawny HTML,
ale wyrażający nie całkiem to co autor miał na myśli. Miejscami prześwituje
kod JavaScript, inne rzeczy poprzestawiane itp. Z tym pewnie będę jeszcze
długo walczył.

mod_proxy_html poprawia też skrypty JavaScript w kodzie
HTML, robi to na głupa, ale jak się postarać, to można uzyskać ciekawe
efekty. Gorzej ze skryptami zewnętrznymi, w osobnych dokumentach. W przypadku
switchy nie jest niby źle, bo w zewnętrznych skryptach nie ma zaszytych
żadnych ścieżek, ale za to są serwowane jako text/html, a co za
tym idzie mod_proxy_html próbuje z nich robić poprawnego
HTMLa. No i taki skrypt po dodaniu <html><body> na początku
i po przetworzeniu tagów w środku nie bardzo chciał działać. Musiałem więc tak
skonfigurować mod_proxy_html, aby zajął się jedynie
dokumentami *.html.

Proximy za to mają zaszyte ścieżki w plikach *.js, jednak
serwowanych poprawnie, jako text/javascript.
mod_proxy_html w ogóle tego nie rusza, za to znalazłem
jeszcze mod_ext_filter (standardowa część Apache 2.x). Przy pomocy tego
moduliku można serwowane dokumenty przepuścić przez zewnętrzny program. A więc
przepuściłem przez seda i poprawiłem ścieżki gdzie trzeba.
Nawet zadziałało. Chyba tego samego modułu wraz z sedem, albo
jakimś mądrzejszym skryptem w
perlu/awku/pythonie będę
musiał użyć do tego paskudnego HTMLa z Proxima. To jest do zrobienia,
ale może być z tym kupa roboty i nie wiem czy się wcześniej nie poddam.

Czyszczenie PyXMPP

Najwyraźniej jest jakieś zainteresowanie moją pythonową biblioteką
XMPP. Ludzie (przynajmniej paru) chcą tego używać, ale wielu od razu się
zniechęca brakiem dokumentacji, inni po próbach zrozumienia o co w tym biega.
Nie dziwię się — kod zamotany jak rzadko, a dokumentacji praktycznie brak.
Bardziej dziwię się ludziom takim jak pete, czy Zgoda, którzy tego używają i nawet mnie
z tego powodu nie męczą. Jednak uznałem, że trzeba coś z tym zrobić…

Więc od paru dni zamiast dodawać nowe ficzery do CJC, poprawiać
w nim bugi, czy implementacje protokołów w PyXMPP to ślęczę nad kodem PyXMPP
i, terroryzowany przez pylinta czyszczę kod,
co jakiś czas robiąc: cvs commit -m "cleaning up...". Przy jakiś
czas coś psuję głupimi literówkami, albo zamierzonymi zmianami w API PyXMPP
(sorry developerzy), np. zamiana nazwy parametru konstruktora klasy Stanza
z type na typ, bo ta pierwsza nazwa zakrywała nazwę wbudowanej
funkcji. Jak już wspominałem większość marudzenia pylinta dotyczy braku
docstringów, a więc je dodawałem na bieżąco. Oczywiście nie
"", ale w miarę konkretną dokumentację, która się może jakiemuś
developerowi przydać. I tu wkracza Epydoc

Normalnie do przetwarzania dokumentacji w pythonie służy narzędzie
pydoc. Jednak jest ono głupie, bo traktuje docstringi jako
czysty tekst, bez formatowania czy hyperlinków. Taka dokumentacja jest mało
czytelna i niewygodna. Już jakiś czas temu szukałem informacji na temat
robienia porządnej dokumentacji do kodu Pythona i dowiedziałem się, że the
right way
to jest (lub raczej będzie) używanie w docstringsch reStructuredText.
Narzędzi do przetwarzania tego wtedy nie znalazłem (słabo szukałem, albo
jeszcze nie było), znalazłem tylko docutils które, między innymi,
takim narzędziem mają się stać, ale na razie umieją tylko parsować
reStructuredText i konwertować to do mądrzejszych formatów.
Mimo braku narzędzia do obróbki tego jednak już wtedy postanowiłem
reStructuredText używać. I nawet użyłem w tych skrawkach
dokumentacji które zdążyłem zrobić.

Teraz przy czyszczeniu kodu znowu szukałem narzędzia do generowania
dokumentacji z kodu. Tym razem znalazłem. Docutils wciąż nie
umieją wyciągać dokumentacji z kodu Pythona, ale mogą być wykorzystane
przez Epydoca, który to potrafi.
Ma on niby swój markup dla docstringów, ale potrafi, przy pomocy
docutils obsłużyć także reStructuredText (ale tylko tworząc
dokumentację w HTML). Więc to właśnie podpiąłem pod doc/Makefile.
Okazało się, że stare kawałki dokumentacji musiałem popoprawiać, żeby
Epydoc sobie z tym poradził. Nowe tworzyłem od razu pod
tandem Epydoc+docutils. I nawet są jakieś
efekty. Otrzymana dokumentacja wygląda nieźle, jest dość przejrzysta… tylko
ma olbrzymie braki. :-( Kiedy ja to wszystko opiszę?

Powydawałem trochę…

Powydawałem trochę oprogramowania. Hurtem:
PyXMPP 0.5
CJC 0.5
JJIGW 0.2.
Jeszcze do napisania anonsy na główną stronę JabberStudio, ale
na razie mi się nie chce ich pisać. Pewnie zaraz się okaże, że
w każdym z tych programów jest jakiś krytyczny błąd, z jakim
nie powinno się wydawać. Trudno, kolejny rilis pewnie i tak za
jakieś dwa miesiące lub pół roku, bo wcześniej nie będzie mi
się chciało.

W PyXMPP i CJC główną nowością jest obsługa rozmów grupowych,
w JJIGW poprawa stabilności i obsługa wielu sieci IRC. We
wszystkich poprawiona masa błędów i wprowadzonych nieco nowych.

A w pracy dzisiaj robię za tragarza… :-(

JJ i CIA

Napisali o mojej twórczości w Jabber Journal, ale moja
wrodzona skromność nie pozwala mi się tym chwalić. Więc się nie pochwalę
:-P

Aby moja sława nie zanikła postanowiłem też zadbać o regularne donosy do
CIA. Niestety na JabberStudio nie mam dostępu
do /CVSROOT/ i nie mogę bezpośrednio instalować commit-skryptów.
Mam jednak możliwość skierowania informacji od commita na dowolny JID lub adres
e-mail i z tej właśnie możliwości skorzystałem. Musiałem tylko napisać skrypt
do konwersji wiadomości z JS na XML zrozumiały dla CIA – niecała godzinka
roboty. Od dziś więc notowane będą moje commity nie tylko do
PLD,
ale także do:
PyXMPP,
CJC,
JJIGW
i
Transportu GG.

Obfalkać drzwi…

Gdy wychodziliśmy z Krysią na spacerek kichnąłem. Tak porządnie i w kierunku
drzwi sąsiadów. Krysię bardzo to rozśmieszyło. Zażartowałem, że obsmarkałem
drzwi sąsiadów
. Śmiała się jeszcze bardziej, powtarzając obfalkał
drzwi
. Później jej przeszło.

Gdy wracaliśmy, piętro pod naszymi drzwiami Krysia pociągnęła mnie w kierunku
drzwi, mówiąc: obfalkać drzwi!, ja na to nie obsmarkam drzwi sąsiadom,
ona: dzidzia obfalka!. Podeszła do drzwi i dmuchnęła nosem. Była bardzo
z siebie zadowolona.

A za chwilkę zabieram się za optymalizacją PyXMPP. Teraz w CJC jak napisze
/chat ktos@ i nacisnę dwa razy TAB, to ponad minutę muszę czekać aż
dostanę dwa pasujące JIDy do wyboru. Tak raczej być nie może. Myślę, że cache
JID-ów i wyników stringprep pomoże. Wcześniej muszę jednak z JID-ów
zrobić obiekty immutable i nie wiem czy dużo nie będę musiał poprawiać
(API się zmieni odrobinkę).

Porządki w kodzie i na Joggerze

Wywaliłem z PyXMPP wsparcie dla Pythona 2.2 i spróbowałem użyć modułu
datetime do obsługi timestampów. Okazało się, że jednak nie
rozwiązuje on moich problemów. Zapewnia interfejs do zamiany czasu
pomiędzy lokalnym a UTC, ale… tylko wtedy jak mu się poda klasy
reprezentujące odpowiednie strefy czasowe. A Python w module
datetime udostępnia jedynie abstrakcyjną klasę bazową.
Resztę trzeba sobie napisać. UTC to nie problem, ale przecież nie będę
pisał klas opisujących strefy czasowe wszystkich potencjalnych
użytkowników CJC! Jest gdzieś w sieci moduł zawierający gotowe klasy,
ale ja nie chcę dodawać kolejnej zależności, szczególnie, że przecież
w systemie już jest informacja o strefie czasowej użytkownika.

Zajrzałem do dokumentacji glibc, żeby zobaczyć jak się to w C robi. Jest
tam nawet potrzebna mi funkcja, nazywa się timegm,
ale:

*Portability note:* `mktime’ is essentially universally
available. `timegm’ is rather rare. For the most portable
conversion from a UTC broken-down time to a simple time, set the
`TZ’ environment variable to UTC, call `mktime’, then set `TZ’
back.

Fajnie, że podali przenośny sposób, ale zastosowanie jego w aplikacji
wielowątkowej to byłaby zbrodnia. A więc sposobu praktycznie nie ma.
Jednak nie będę przecież użytkownikom pokazywał czasu UTC, więc zacząłem
kombinować i nawet coś wykombinowałem: zamiana czasu UTC na lokalny
medodą kolejnych przybliżeń. Z moich testów — z czasem letnim
i zimowym z różnymi ustawieniami zmiennej $TZ
wynika że to nawet działa :-). Ciekawe jak bardzo
przekombinowałem.

Dzisiaj, nie mając wiele do roboty w pracy, urządziłem bug fixing
day
dla CJC. Poprawiłem już dwa błędy zgłoszone na JS oraz
kilka zgłoszonych przez Jabbera. Poczekam jeszcze na jakieś bugreporty
i może zrobię kolejne wydanie PyXMPP i CJC. MUC jeszcze dość
niekompletny, ale używalny, a wydać warto chociażby z powodu błędów
poprawionych w stosunku do 0.4.

Oprócz porządków w kodzie zrobiłem też porządki na Joggerze. Uzupełniłem
polecane Jogi o nowe pozycje i atrybuty title na linkach.
Usunąłem też linki erotycznie, ale nie dlatego że nagle sporządniałem
— po prostu nie chciało mi się ich uaktualniać. Poprawiłem jeszcze
ostatnią notkę — zamieniłem na w kilku
miejscach. Od dziś postaram się trzymać zasad typografii. Z poprawianiem
starszych notek byłoby za dużo roboty.

Zaginiona entropia i stary Python musi odejść

Wczoraj w firmie przeżyliśmy chwilę grozy. Zaczęło się niewinnie. Nie mogłem
commitnąć zmian w systemie zarządzania użytkownikami. svn commit
zawisał, strace pokazywało, że na dostępie do /dev/random. Nie
było to pilne, więc bardzo się tym nie przejąłem. Potem dzwonił gościu, że
poczty nie może odebrać. Chwila śledztwa wykazała, że zacina się na autoryzacji
DIGEST-MD5. Od razu skojarzyłem to z problemami z /dev/random.
Potem było już tylko gorzej — przy niedziałającym /dev/random posłuszeństwa
odmówił też PostgreSQL. A ja ciągle nie wiedziałem co się dzieje.
/proc/sys/kernel/random/entropy_avail pokazywało 0 i nie chciało
nawet drgnąć. Nie pomogło też wybicie procesów korzystających z /dev/random i
/dev/urandom. Wyglądało na to, że coś się zacieło. Ten serwer już długo działał,
a jeszcze nie było takich problemów.

Pomyślałem o sprzętowym generatorze liczb losowych — podobno niektóre płyty
takie coś mają. find /lib/modules -name "*rng*" pokazało dwa
moduły. Jeden (amd768_rng) miał nazwę podobną do chipsetu płyty.
Załadowałem i nawet działa — cat /dev/misc/amd768_rng pokazywało
krzaczki. Jednak aplikacje odwoływały się do /dev/random, a tam
dalej bez zmian. Spróbowałem ln -s /dev/misc/amd768_rng /dev/random
Permission denied, mv /dev/random /dev/random.orig — to
samo. Cholerny devfs – próbuje być mądrzejszy ode mnie! Zawsze lubiłem ideę
devfs — w /dev/ jest tylko to co mam w komputerze, a dysk o
konkretnym SCSI-id podłączony do konkretnego kontrolera ma zawsze tę samą nazwę,
a nie zależną od tego co jeszcze jest podłączone. Jednak implementacja jest
fatalne, a ten przypadek przeważył — devfs wyleciał z tego serwera. I tak
robiliśmy reboot, bo innych pomysłów nie było.

Po reboocie okazało się, że /dev/amd768_rng nie jest całkiem
zgodny z /dev/random — po podlinkowaniu niektóre aplikacje (w
szczególności SVN) zawisały przy próbie korzystania z tegoż. Jednak
/proc/sys/kernel/random/entropy_avail było już większe od zera,
więc problem chwilowo zniknął. Jednak nie na długo — entropy_avail
zaczęło się zmniejszać i znowu doszło do zera blokując wiele usług. Zamiany
/dev/random na /dev/urandom nie brałem pod uwagę – po
to używam SSL, SASL itp. żeby było bezpiecznie, a /dev/urandom bez
entropii generuje liczby bardzo pseudolosowe, a więc do kryptografii
niespecjalnie się nadające. Na szczęście kumpel znalazł winowajcę —
iptables -m random. Jedna taka regułka była w naszym firewallu i po
podłączeniu któregoś klienta najwyraźniej zabrakło na nią entropii. Po zamianie
tego na coś innego entropy_avail urosło do sensownej wartości i
wszystko zaczęło znowu działać. Ufff…

W PyXMPP i CJC obsługa MUC zaczyna działać. Można już wejść na takiego czata
i pogadać. Ale pierwszym felerem, który się rzuca w oczy, są niewłaściwe czasy
przy wiadomościach z historii pokoju. Jest tam czas aktualny, zamiast tego
podanego w <x xmlns="jabber:x:delay"/>. JEP-91 jest banalnie prosty,
więc postanowiłem go od razu zaimplementować. Oczywiste było, że przydałby się
typ opisujący czas, którego w Pythonie zawsze brakowało. Zwykle używałem
mx.Datetime, ale nie chciałem dla takiej dupereli do PyXMPP dodawać
kolejnej zależności. Więc użyłem modułu time, ale on jest do bani.
Można pobrać aktualny czas, przedstawić ją w postaci UTC, czy czasu lokalnego,
czy skonwertować tekst o znanym formacie na czas — ale tylko w czasie lokalnym.
Na zamianę czasu UTC w postaci tekstowej na czas lokalny nie znalazłem sposobu.
Poczytałem dokumentację — z niej wynikało że %Z w formacie
dla time.strptime czasem może działać — u mnie nie działa.
Pogooglałem i okazało się że moje wiadomości na temat braku typu dla czasu są
nieaktualne. W Pythonie 2.3 jest moduł datetime, który daje
wszystko co potrzebuję wraz z sensownym interfejsem. Dotychczas jednak PyXMPP
działało także na pythonie 2.2.x. Chyba przestanie — już dawno zastanawiałem się
nad porzuceniem wsparcia dla Pythona 2.2 — chociażby dlatego, że nie ma w nim
obsługi stringprep, czy IDN (oba standardy wymagane przez XMPP). Teraz PyXMPP
zawiera moją własną implementację stringprep dla Pythona 2.2 (wraz z wymaganą przez nią
normalizacją Unicode — to było sporo roboty), a IDN po prostu nie są obsługiwane gdy używany jest Python 2.2
(użycie znaku nie-ASCII w domenie JID powoduje bład). Ciekawe dla ilu
użytkowników takie podniesienie wymagań będzie dużym kłopotem. A może w ogóle
się tym nie przejmować? W końcu już teraz użytkownicy Debiana muszą kombinować,
żeby z PyXMPP skorzystać, bo standardowo mają historyczne wersje Pythona i
libxml2. Chyba jednak wywalę obsługę pythona 2.2 — kodowi wyjdzie to tylko na
dobre.