21 września 2004
22:09:11
|
kategorie:
programowanie,
python,
pyxmpp,
Gdy w CJC użyłem osobnej klasy (nazwijmy ją A) do
rozszerzenia funkcjonalności innej klasy (B), ale tak, że to
B dziedziczyło po A, to myślałem że stosuję jakiś dziwny,
brudny
trik dla własnej wygody. Później czytając dokumentację do
pylinta spotkałem się z określeniem mix-in class
, nie
wiedziałem co to jest, ale tak jakoś mi się skojarzyło z tym co zrobiłem w
CJC.
Teraz coś podobnego chcę zrobić w PyXMPP, aby podzielić
jeden wielki moduł pyxmpp.stream na mniejsze kawałki.
Przypomniałem sobie o mix-in class
i wrzuciłem to w Google. Okazało się,
że miałem rację. Dowiedziałem, że to znana technika programowania
obiektowego, która wcale nie jest zła. Znalazłem nawet artykuł o tym jak używać mix-ins w
Pythonie. Rzeczywiście Python bardzo ułatwia stosowanie tej techniki.
No to teraz, gdy się podszkoliłem, mogę z czystym sumieniem wziąć się za
wydzielanie StreamSASLMixIn i StreamTLSMixIn.
:-)
21 września 2004
10:05:03
|
kategorie:
programowanie,
python,
Podczas dłubania w jednym skrypcie wyszło mi coś takiego (no tam było trochę czytelniej,
na potrzeby Joggera upiększyłem
:
x=[x for x in x if x]
Każdy Pythonowiec od razu zrozumie, że ta instrukcja usuwa puste
(None, "", 0, itp.) elementy z listy
:-). Wiem, w Perlu dałoby się jeszcze mniej czytelnie, pewnie krócej
i na 100 różnych sposobów, ale na pewno nie tak ładnie ;-)
Oczywiście nie polecam takiego programowania — wypadałoby przynajmniej
zmienić jedno x
na coś innego.
20 września 2004
13:08:45
|
kategorie:
praca,
spam,
From: jakiś_luser
Subject: Luser
To: "Mail Delivery System" <MAILER-DAEMON@mój-server>
Wróciliśmy cali i zdrowi . Jak na nasze polskie warunki drogowe - udało się
przejechać w ciagu jednego dnia 800 km. Wyjechaliśmy 4.20 rano a wróciliśmy
20.30 wieczorem . Byliśmy na grobach rodziny w Bygdoszczy i po drodze
odwiedziliśmy Licheń . Nie wiem czy się orientujesz , jest to miejscowość koło
Konina , gdzie wybudowano duże Sanktuarium . Muszę kończyć póżniej napiszę
więcej.
narazie
Luser
16 września 2004
22:25:49
|
kategorie:
html itp.,
pyxmpp,
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.
16 września 2004
09:09:22
|
kategorie:
transport gg,
Przed chwilą ktoś się mnie spytał, czy to normalne, że transport GG zżera 64MB pamięci
(pole VIRT na topie). No normalne to nie jest, ale sprawdziłem u siebie... odpaliłem top,
dałem u jabber
i moim oczom ukazało się
913MB w polu VIRT
procesu jggtrans
. Hmmm...
chyba mamy mały wyciek... Tylko kiedy ja to zbadam i poprawię?
14 września 2004
22:19:42
|
kategorie:
programowanie,
python,
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ę?
![[szpieg]](http://stats.jajcus.net/record.png?site=jogger_jajcus&page=index)
Jesteście obserwowani...