Jog Jajcusia

PyXMPP — coraz poważniej

31 grudnia 2004 23:21:26 | kategorie: cjc, programowanie, python, pyxmpp,

Zrobiłem w końcu stronę WWW dla PyxMPP. To dopiero początek, ale na jakiś czas powinno starczyć. Zacząłem też robić zestawy testów jednostkowym (opartych o PyUnit — moduł unittest) do testowania całości. Na pierwszy ogień poszło pyxmpp.jabber.vcard do którego już jakieś testy były i trzeba było je tylko przerobić na PyUnit i uzupełnić. Oczywiście wyszło parę błędów, które poprawiłem. Później pyxmpp.jabber.disco, w którym chciałem uzupełnić API, testy miały mi pomóc zrobić to tak, żeby nic nie zepsuć. Pomogły, a przy okazji poprawiłem w testowanym module sporo błędów. Ogólnie fajna rzecz takie testy i wbrew pozorom nie tak bardzo upierdliwa (mniej niż uzupełnianie docstringów).

Dzisiaj zrobiłem jeszcze małą rewolucję. Wkurzało mnie już to, że importowanie jakiegokolwiek modułu z pyxmpp powodował importowanie całości (prawie). Wynikało to z tego, że dla wygody developerów pakiet pyxmpp importował najważniejsze obiekty ze swoich modułów. Od dłuższego czasu głowiłem się na tym, jak to rozwiązań nie tracąc tej wygody i nie psując za bardzo kompatybilności wstecz i w końcu coś wymyśliłem. Teraz samo z siebie nic niepotrzebnie się nie importuje, ale jak ktoś chce po staremu, to wystarczy że raz sobie zaimportuje pyxmpp.all, i/lub pyxmpp.jabber.all albo pyxmpp.jabber.all (jeśli któregoś z nich używa). W ten sposób chyba i wilk syty i owca cała.

Następnie zabrałem się za CJC. Wkurzało mnie długie ładowanie konfiga, okazało się, że to przez częste wywoływanie logging.debug() — wywaliłem i jest lepiej. Potem postanowiłem porawić pewnego upierdliwego i często zgłaszanego buga — część wpisów w rosterze pojawiało się przed zamiast za nazwą grupy. Okazało się, że porównywanie JIDów z innymi obiektami było w PyXMPP spieprzone i niektóre JIDy były mniejsze od None. I znowu testy jednostkowe się przydały, a zgłoszenie mogłem zamknąć.

I po cholerę to wszystko piszę? Nie wiem... może, żebyście wiedzieli jak wygląda prawdziwie geekowski sylwester... Nie, żebym nie imprezował — specjalnie z tej okazji mam tu colę (z cytrynką) i chipsy ;-).

9 komentarzy do wpisu „ PyXMPP — coraz poważniej”

Doczego to doszło...

19 grudnia 2004 12:11:41 | kategorie: programowanie, python, pyxmpp,

... portuję PyXMPP na Windows. To znaczy gościu mi pisze co mu nie działa, a ja poprawiam. Wczoraj wymieniłem swój resolver (który nie umiał znaleźć serwerów nazw na Windows) na dnspython. Dzisiaj poprawiłem streambase, żeby na sockecie używało recv() zamiast read (Windows sucks, POSIX rulez! ;-)). I podobno zadziałało.

Oprócz tego pracuję nad dokumentacją. Docstringi są już w całym kodzie, HTML jakiś się z tego generuje. Właśnie kończę skrypt tworzący z drzewa dokumentacji wyciągniętego przez epydoc plik XMI, który mogę załadować do Umbrello aby narysować diagramy UML. Jeszcze tylko stworzyć stronę WWW z tym wszystkim i może wreszcie jacyś developerzy się tym PyXMPP zainteresują i ostatecznie pogrążę XMPPPY (konkurencję) ;-).

5 komentarzy do wpisu „ Doczego to doszło...”

Bye-bye, CVS

26 października 2004 17:05:19 | kategorie: cjc, pyxmpp,

Miam na tyle dość CVS, że postanowiłem przenieść moje Jabberowe projekty do Subversion. Okazało się to łatwiejsze niż przypuszczałem. Na JabberStudio jest zainstalowany SVN, skonfigurowany svnserve, a nawet jakiś ViewCVS do tego.

Wczoraj wieczorem przemigrowałem repo PyXMPP. Dodałem skrypt do generacji ChangeLog (tym razem nie po stronie serwera) oraz automatykę do generowania snapshotów — dla tych co uparcie bronią się przez SVN, a chcieli by spróbować świeżego PyXMPP czy CJC.

Następne w kolejce jest oczywiście CJC, no i może Transport GG. Zobaczymy co z tego wyniknie.

19 komentarzy do wpisu „ Bye-bye, CVS”

Nowy ejabberd

11 października 2004 22:31:37 | kategorie: cjc, jabber, pyxmpp,

Niedawno wyszedł Ejabberd 0.7.5. Czekałem na niego, bo miał mieć StartTLS i ulepszony interfejs administracyjny. Wczoraj zainstalowałem go na jabber.bnet.pl. Przy okazji wyszły błędy (dotyczące AMD64, którego akurat używam na tym serwerze) w paczce dla PLD.

I rzeczywiście, na stronie administracyjnej pojawiła się opcja dodawania userów, a przy połączeniu możliwość użycia StartTLS. To ostatnie objawiło się w CJC pięknym tracebackiem i komunikatem błędu, że zły XML przyszedł. Na konsoli XML śmieci. Oczywiście coś spieprzyłem przy ostatnim oczyszczaniu kodu. Nie miałem StartTLS na serwerze, to nie zauważyłem.

Dzisiaj w pracy poprawiłem, wspomniane błędy w paczce ejabberd, a także problemy w budowie erlanga na builderach. W oficjalnym Ac oba pakiety powinny się niedługo pojawić. Wieczorem poprawiłem też obsługę StartTLS w PyXMPP i CJC (oba trzeba było poprawić) i już mogę się cieszyć szyfrowanymi połączeniami z serwerem. I to na normalnym porcie! :-)

6 komentarzy do wpisu „ Nowy ejabberd”

Nie tak całkiem leniuchuję...

08 października 2004 00:43:14 | kategorie: oprogramowanie, pld, pyxmpp,

Postanowiłem przenieść listy dyskusyjne moich projektów z Enemies of Carlotta na mailmana. To pierwsze nie bardzo się rozwija, a i możliwości ma skromne, a z mailmanem i tak się muszę męczyć przy innych listach (przy okazji się przekonałem, że od strony administratora jest nieco przyjemniejszy). No i nawet listy działają. Udało się to nawet pogodzić z moją SQLową bazą użytkowników synchronizowaną na zapasowym MX. Jednak stwierdzam, że mailman to gniot, szczególnie ten z paczki PLD (której jednak nie chciało mi się poprawiać). A już zupełnie obsługa wirtualnych domen dla postfixa (tak jak on to robi, to te domeny są średnio wirtualne, bo listy zaśmiecają przestrzeń nazw systemowych użytkowników). Ale przejście się chyba opłacało. Listy jak już ruszyły to działają, a archiwa wyglądają lepiej.

Jakiś czas temu jeden z Release Managerów PLD prosił mnie, abym dorobił ACLe na branche do automatyki builderów. Wczoraj więc się za to zabrałem: cvs up, poprawka, login na src-builder (najważniejszy z builderów), cvs up i sprawdzam jak to działa... W tym czasie inny developer PLD mnie informuje, że jak robię te poprawki na HEAD, to to się na nic nie zda, bo to co jest na HEAD i tak się na buildery nie nadaje, bo ów developer coś tam samemu psocił. No fajnie, ale przecież właśnie to na głównym builderze zainstalowałem...

Na szczęście psuja zostawił taga na ostatniej działającej wersji automatyki. Z taga zrobiłem brancha, przeniosłem tam swoje poprawki i z tego brancha zrobiłem cvs up na builderze. Jeszcze parę poprawek do mojej poprawki i ACLe na branche działają :-). Mogłem wreszcie pójść spać (0:30).

W przedpoprzednim wpisie, tam gdzie wspominałem o RFC 3920, 3921, 3922 i 3923, wspominałem, że dodam odwołania do tych RFC do dokumentacji PyXMPP. Jednak dopiero przed chwilą mi się to udało, przez te zabawy z automatyką builderów i listami dyskusyjnymi. Ale za to dopisałem też odwołania do wszelkich innych implementowanych RFC i JEPów. Będzie łatwiej znaleźć odpowiedni dokument jak będzie trzeba coś sprawdzić.

A jutro jadę na Jesień Linuksową :-).

3 komentarze do wpisu „ Nie tak całkiem leniuchuję...”

Mix-ins

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. :-)

3 komentarze do wpisu „ Mix-ins”