mmazur.7thguard.net

1. Nagranie jest mocno przeedytowane pod kątem przydatności do słuchania. Jeśli ktoś pamięta, że coś się wydarzyło inaczej, niż jest nagrane, to wysoce prawdopodobne, że dobrze pamięta.
2. Wyciąłem co najmniej kilka minut swoich mlasknięć (co mikrofon bardzo ładnie ponagrywał), chrząknięć, eeeeeyyyyeeeeeania, za długich pauz, przerw technicznych oraz najzwyklejszych wpadek. Więc nie, wcale tak płynnie nie mówię.
3. W środę miałem depresję, że poszło tragicznie. Po przesłuchaniu stwierdzam, że aż tak strasznie tragicznie wcale nie poszło. Nic czego nie może naprawić kreatywna sesja z edytorem dźwięku.
4. Acz kilka rzeczy jest oczywistych -- po pierwsze, wcale nie mówię tak płynnie i poprawnie technicznie, jak mi się wydawało, że mówię :(
5. Po drugie -- miałem nadzieję zrobić super zajebistą prezentację. Poświęciłem na nią z dwa-trzy razy więcej czasu, niż zwykle poświęcam na takie rzeczy. Wyszło niewiele lepiej, jeśli w ogóle. Jedno staje się dla mnie jasne -- jedyny sposób na idealnie płynną prezentację, to po prostu usiąść, napisać całość słowo w słowo i później albo czytać, albo wyryć całość na blaszkę. Nie ma siły, żebym z kartką opisującą tylko schemat wystąpienia był w stanie przeprowadzić je płynnie -- bez zacięć, bez pauz, bez niepotrzebnego powtarzania się. Po prostu się nie da. Może są jacyś geniusze, którzy potrafią, ale generalnie wątpię, żeby to było w zasięgu normalnego człowieka. Mowa ludzka tak nie działa. Zapomina się słów, robi pauzy, gubi wątki, różne rzeczy rozpraszają.
6. Po trzecie -- jeśli chcę zrobić płynną integrację tego co mówię, z tym co jest na rzutniku, to powinienem mieć w zasięgu wzroku swój laptop, żebym nie musiał się odwracać w celu upewnienia się co właściwie w danym momencie jest na rzutniku (mam ten bezprzewodowy dynks do obsługi prezentacji, więc mogę zmieniać slajdy patrząc się na publiczność). Takie odwracanie psuje płynność, a i mnie dekoncentruje.
7. Po czwarte -- różne techniczne drobiazgi o zwracaniu uwagi na które człowiek się uczy z wykładu na wykład.

Link do ogga. Jutro jeszcze powinien być nius na stronie oplugowej wraz z jakimiś fotkami.

A, disclaimer: mówiąc zrobiłem sporo uproszczeń, a i wykład był dosyć konkretnie stargetowany (na studentów, którzy nie wiedzą jak takie rzeczy ugryźć). Dodatkowo co najmniej kilka razy powtarzałem, że coś jest moim poglądem na sprawę i na pewno są miejsca, gdzie to działa (z powodzeniem) kompletnie inaczej. Także wiem, że nie opisałem wszystkiego, co było do opisania. Był to świadomy wybór.

Niedoszacowałem czasochłonności projektu. Ale tym nie jestem zdziwiony, jeszcze wiele wody w rzece upłynie, zanim będę w stanie w miarę dokładnie terminy przewidywać. Popełniłem inny błąd -- nie zadbałem, by możliwie wcześnie skonsultować odpowiednie fragmenty dokumentacji z osobą, która byłaby kompetentna nam wykazać rozjazdy z rzeczywistym modelem biznesowym. Szczyt kretynizmu jak teraz na to patrzę. Grrr.

Skutek? Kilka mniejszych i niestety kilka większych dziur wymagających poprawek w kodzie. Przy czym ja, jako szef, za swoje błędy płacił nie będę. Nadmiarową robotę będzie miał programista.

Niskoopłacany niedoświadczony programista, który chyba dopiero na tym projekcie zaczyna rozumieć, że "naiwna ocena czasochłonności", typowa dla początkujących koderów ("Ten projekt? Tydzień, maks dwa.") nijak się ma do rzeczywistego mozolnego kodowania. Programista, który zaczyna się wypalać na moich oczach. Programista, którego potrzebuję na zaraz do następnego projektu.

Szlag by to. Przydałoby się zrobić coś konkretnego, tylko co. Na początek niech będzie zapewnienie, że terminy są bardzo fajne, gdy wydają pocieszne dźwięki przelatując nad naszymi głowami. I że nie ma się nimi za bardzo po co przejmować.

Facet ma point. W pracy zastanawiając się nad wyborem języka, stanęło na stackless pythonie, ale w pracy miałem systemy bardziej zbliżone do google'owych, gdzie wszyscy wiedzieli, że od razu trzeba pisać z myślą o maksymalnej skalowalności, bo drugiego podejścia nie będzie. Więc nikt się specjalnie nie obruszał, że nie będzie można pójść na łatwiznę z normalnymi wątkami.

Ale wątki to jest mainstream, a im dalej w czas, tym więcej systemów wieloprocesorowych na rynku. I jeśli python pozostanie poza mainstreamem, to może się to dla niego źle skończyć, a tego bym nie chciał.

Z drugiej strony, co potrafię dopiero docenić z perspektywy lat, python w dużej ilości sytuacji stara się być mądrzejszy od programisty i podsuwać mu pod nos najlepsze rozwiązanie, utrudniając korzystanie z innych. I może Guido ma rację zniechęcając do korzystania z wątków. A może nie. Na razie wygląda na to drugie.

Padaka. Jedyny SCM, który ma windowsowe GUI z prawdziwego zdarzenia (tzn. integrację z Windows Explorerem), to subversion via tortoisesvn. Więc chcąc nie chcąc, będę w firmie używał scentralizowanego SCM-a, bo alternatywy są jeszcze bardzo niedopracowane: bzr-tortoise, tortoisehg i tortoisedarcs są albo stare, albo niedopracowane, albo masakrycznie trudne w instalacji. A zazwyczaj po trochu z każdego. (Patrzcie i płaczcie.)

Za to tortoisesvn jest po prostu miły. I widać, że się autorom chce.

Przeczytałem "Pragmatycznego Programistę". Większość rzeczy tam zawartych była mi w większym lub mniejszym stopniu znana, więc część podrozdziałów albo tylko przeskanowałem, albo w ogóle zignorowałem [1]. Tak czy siak książka zdecydowanie dobra i polecałbym wszystkim początkującym (i nie tylko) programistom. Zwłaszcza żałuję, że nie przeczytałem jej jakieś dwa-trzy lata temu (co najmniej; preferowalnie znacznie wcześniej), zanim zabrałem się za pisanie pldzianej automatyki ftpowej. Wtedy zacząłem po raz pierwszy bawić się na serio obiektami w pythonie i tak sobie klepiąc przyszło mi do głowy, że ok, samo tworzenie obiektów jest proste, tyle, że nie mam zielonego pojęcia w jaki sposób dzielić różne rzeczy na obiekty. Szkoda, że wtedy nie postanowiłem coś bardziej doczytać na ten temat.

[1] Jak byłem mały, to potrafiłem przeczytać od deski do deski praktycznie dowolną knigę. Teraz niestety już nie potrafię -- znacznie spadła mi tolerancja na książki techniczne -- za dużo tam słów, za mało przydatnej treści. Nawiasem mówiąc będę musiał pomyśleć w jaki sposób dałoby się napisać książkę tak, żeby zaawansowani nie mieli wrażenia, że tracą czas, a jednocześnie ci nie do końca zaawansowani byli w stanie z niej coś wynieść. Bo zdecydowanie powinno się dać.

Jedna rzecz jest w tym wszystkim mocno przerażająca -- ogrom materiału. Wszyscy znają przypowieść o archetypicznym 'informatyku', który kiedyś nauczył się jakiegoś visual basica i do tej pory wszystko robi przy jego pomocy. No i prawdę mówiąc ja się nie dziwię. Takie rozwiązanie jest bardzo kuszące.

Naczelną zasadą tej książki jest, że programista powinien wiedzieć wszystko o swoim fachu, bo tylko dzięki temu może dobierać właściwe narzędzia do zastanych problemów i używać ich w prawidłowy sposób.

Tylko ile tego wszystkiego jest! Ekosystem uniksiany (shelle, skrypty, szybkie przetwarzanie tekstu), ekosystem javowy (eclipse, javadoc, jUnit, jBoss, jAdziękuję), ekosystem .netowy, języki dynamiczne (trza by przynajmniej z dwa teraz znać, tj. pythona i ruby'ego), a to tylko same narzędzia. Do tego dochodzi jeszcze masakryczna ilość wiedzy, żeby z tego sensownie korzystać. Już te lata wymagane na zdobycie doświadczenia w tym wszystkim pominę -- poznęcam się trochę nad samą suchą wiedzą odnośnie programowania (obiektowego). Na niskim poziomie trza znać jakiś język (maluteńki język zwany javą na przykład). Do tego dochodzą te wszystkie narzędzia i frameworki. Do tego na najwyższym poziomie jakieś typowe architektury, MVC, klient-serwer, etc. A żeby nie było zbyt różowo, to taki UML (z którego olewamy 99%, bierzemy tylko podstawy) i jeszcze jakieś wymysły typu design patterns.

Brrr. W przypadku tych ostatnich zdecydowanie zgadzam się z krytykami -- jeśli przy rozwiązywaniu określonych typów problemów koduje się w sposób, który "zasługuje" na stworzenie wzorca, to znaczy, że nie powinno się robić wzorców, tylko (a) rozszerzyć język o nowe abstrakcje i (b) zrobić jakiś framework/zestaw modułów do niego. To co już jest, jest i tak cholernie skomplikowane, więc zupełnie nie podnieca mnie przedzieranie się przez formalne opisy wzorców projektowych, żeby znaleźć ten, przypominający akurat to, co mam zamiar robić. W takich przypadkach zdecydowanie powinienem mieć gotowy framework, który prowadzi mnie za rączkę krok po kroku, minimalizując przy okazji szansę, że sobie odstrzelę nogę.

Ja jestem leniem. Ja się nie lubię uczyć nowych rzeczy zbyt często. Ilość wiedzy jaka w tym wszystkim jest zawarta mnie przeraża.

(A jak ktoś już jest kompletnie pokręcony, to może spróbować się nauczyć htmla, cssa i jsa w stopniu zaawansowanym, tzn. takim, który wystarczy do stworzenia jakiejś bardziej zaawansowanej strony działającej we wszystkich popularniejszych przeglądarkach. Good luck.)

Dobra rada -- refucktoryzując jakiś kawałek kodu, najpierw należy przeprowadzić wszystkie kosmetyczne zmiany, typu zmiana kolejności jakiśtam linii, dodawanie nagłówków, a zwłaszcza zmiana nazw struktur/pól w strukturach, etc. i doprowadzić to do takiej postaci, żeby się kompilowało na starym kodzie. Mimo, że to jest więcej roboty, to znacznie później ułatwia szukanie błędów, bo można sobie bez zbędnej kosmetyki wstawiać wywołania starych funkcji bez martwienia się o to, że nie zadziałają, bo jakaś struktura się inaczej nazywa.

Btw: czy ja już wspominałem jak ja kurwa nienawidzę R&D?

Dzisiaj miałem egzamin z inżynierii oprogramowania (UML do obiektówki i klasyczna analiza strukturalna jak za papy Yourdona). A ponieważ właściwie nie umiem ani jednego, ani drugiego, to nie zaliczyłem.

Próbując cośtam wymodzić w trakcie, dotarła do mnie jedna rzecz -- ja tak naprawdę nie rozumiem czym się różni model obiektowy, relacyjny i strukturalny (nie, nie chodzi mi o to, że nie wiem co to obiekt, albo jak zrobić kilka tabelek w bazie danych; chodzi mi o dogłębne zrozumienie fundamentalnych różnic w tych modelach i jak to się ma do projektowania przy ich pomocy). Też moja wina, bo mogłem to zauważyć wcześniej, gdybym się był bardziej do projektu przykładał, ale faktem jest, że nie było takiego mądrego dwa semestry wstecz, żeby nam to spróbował jakoś konkretnie wytłumaczyć.

Prawdę mówiąc ja nadal nie wiem jak powinienem się uczyć (w jaki konkretnie sposób, w jakiej kolejności, etc.) i mnie to drażni, ale spróbuję rzucić jak najlepszym przybliżeniem na to, co mi w tym momencie potrzeba.

1. Książka/tekst tłumaczące w jak najlepszy sposób te trzy (no, dwa, ale powiedzmy, że model strukturalny ze względu na tradycję) obecnie najważniejsze modele. Nie wiem jak to najlepiej zrobić, domyślam się, że poprzez krótką charakterystykę obu, która przechodzi w opis najbardziej reprezentacyjnych różnic w nich na konkretnych przykładach. Tzn. chcę zamodelować rzecz A i teraz gdzie są najważniejsze różnice dla tych trzech modeli oraz jak konkretnie moje malunki (uml, dfd, czy co tam) by się przekładały na fizyczny kod/zawartość bazy danych. To wszystko okraszone konkretnym opisaniem co, gdzie i w jaki sposób jest używane (tzn. strukturalny tu, patrzaj sql, modeluje się to tym, sialalalala).

2. Konkretne kursy użycia tych trzech modeli (kurs umla, kurs strukturalnej i zapewne kurs projektowania relacyjnych do kupy od razu z sql reference). Z konkretnymi odniesieniami do użycia i jak największym nastawieniem na hands-on, ale bez omijania co ważniejszych części teoretycznych. Jak byłem mały, to potrafiłem czytać (i czytałem) te knigi ala Knuth, które się zazwyczaj używa jako podręczniki na studiach, natomiast teraz mi wybitnie szkoda czasu, bo 99,9% treści tam zawartej i tak nie zapamiętam, a tylko stracę w cholerę czasu (kilka miesięcy temu próbowałem przeczytać analizę strukturalną Yourdona; bleee). Potrzebuję minimum konkretnie sprezentowanej wiedzy, która pozwoli mi jak najszybciej sobie w głowie stworzyć model... modelu. Żebym mógł modelować. A modelując będę sobie już sam łatał luki w wiedzy i dorabiał własne spostrzeżenia.

Najgorsze u mnie jest to, że ja myślę kodem. Mam problem z myśleniem o reprezentacji danych w formie strukturalnej, bo mam od razu w mózgu sprzeciw, że przecież nie jestem tego w stanie wstawić do mojego mysqla. Albo mam problem z modelowaniem relacji w umlu, bo ja tak naprawdę nie znam języków obiektowych (obiektowość pythona i c++ rozumiem tylko w stopniu podstawowym, czyli wiecie, obiekty, dziedziczenie i takie tam). Dlatego też bardzo ważne w tym wszystkim byłoby, żeby opisawszy jakiś związek w danym modelu, od razu było pokazane jak to wygląda zaimplementowane w jakimś konkretnym języku.

(Co do sqla, znaczy relacyjnych baz, to chyba wiem te najważniejsze rzeczy. Ale nie jestem tego pewien. I mnie to wybitnie drażni, bo o ile nie jest zbrodnią nie umieć czegoś zrobić, o tyle tragiczne jest nie wiedzieć nawet o istnieniu czegoś. Później kończy się takimi potworkami, jakie wyprodukowałem w pracy dwa lata temu, jak jeszcze nie umiałem nic poza prostym selectem. Mam jakąś niewielką książkę o bazach z WNT, będzie trza przejrzeć, mam nadzieję, że znajdę co trzeba przynajmniej z sqla.)

Za każdym razem, gdy gdzieś tam pisali o problemach z dodaniem reiserfsa czwórki do jądra, oczywiste dla mnie było, że rację mają jądrowcy. Tak, Hans mógł sobie do woli gadać o tym, że jego filesystem non stop przechodzi miliardy zautomatyzowanych testów, ma super rozszerzalną i super zajebistą architekturę pluginową i wogle wogle cuda wianki, ale prawda jest i była taka, że z punktu widzenia kernelowców najważniejsza jest maintainowalność danego podsystemu. I nie chodzi tu o to, że autor się zaklina, że będzie maintainował, ale że w razie czego sami kernelowcy będą mogli tam jakieś mniejsze i większe poprawki wstawiać. To jest tzw. 'Linus got hit by a bus problem', czyli co robimy, jak maintainera przejedzie autobus.

Szczerze wątpię, żeby to się przyjęło, ale w sumie od teraz powinno się to nazywać "Linus got hit by a bus/Hans got jailed for killing his wife problem".

Poza tym mam nadzieję, że jeśli ktoś do tej pory nie rozumiał dlaczego Linus&friends byli tacy uparci przy mergowaniu reiserfsa4, to ten, fakt faktem mocno ekstremalny przypadek wystarczy za uzasadnienie. Gdyby ten filesystem został mergnięty dłuższy czas temu w stanie, w jakim był, to teraz kernelowcy mieliby na głowie potencjalnie martwy filesystem zawierający sporo różnych interfejsów (własne wbudowane pluginy), o których nikt nic nie wie. Afaik podobny problem jest już teraz z reiserem trójką, bo ilość osób znających się na rzeczy jest bardzo ograniczona, a sam autor stwierdził, że system jest w maintainance mode i żadnych większych zmian robił w nim nie będzie. A jądro się cały czas zmienia i czasami jednak trzeba...

Python pythonem, ale jednak są takie zadania, które zdecydowanie wygodniej załatwić mi szybkim skryptem shellowym. Czasami użycie i jednego i drugiego narzędzia razem jest sensowne, a czasami nie, więc w tym drugim przypadku muszę się męczyć z robieniem niektórych rzeczy w pythonie.

Z samej swej natury shell jest takim wynalazkiem, że nic go nie zastąpi jeśli idzie o łatwość używania narzędzi shellowych (sed, grep, cut, sort, uniq, żeby wymienić te najpopularniejsze), a użycie tychże jest często jednak znacznie sensowniejsze, niż tworzenie danej funkcjonalności w pythonie.

(Ostatnio ktoś mówił, że ruby ma to fajniej rozwiązane, nie wiem, możliwe, ciekawym jak.)

Chętnie bym zobaczył w pythonie jakiś moduł "shell", czy podobnie nazwany, który po zrobieniu "from shell import *" nie zaśmieciłby mi przestrzeni nazw żadnymi zbędnymi rzeczami, ale jednocześnie dałby mi dostęp do zestawu prostych funkcji, dzięki którym mógłbym bezproblemowo odpalać narzędzia shellowe, łączyć je w potoki, przechwytywać potoki, przekierowywać im wejście i wyjście, mieć łatwy dostęp do zmiennych środowiskowych i w ogóle robić wszystkie te rzeczy, dzięki którym shell w pewnych zastosowaniach jest jednak najwygodniejszy.

Wymagałoby to pewnie sporo pomyślunku, żeby jakoś sensownie zrobić, ale imho jednak byłoby do zrobienia.

W mojej robocie generalnie kluczowym jest dobre opanowanie C i różnego rodzaju kombinacje, jak duże ilości bardzo ciężkich serwerów w owym C napisanych, ze sobą w jakiś wydajny sposób zsynchronizować (z jednego konkretnego swojego rozwiązania jestem szczególnie dumny, bo działa bardzo ładnie :).

Międzymordzie usera jest napisane w pehapie z użyciem smarty'ego, oryginalnie przeze mnie (choć w rzeczywistości pehapa praktycznie nie znam; i nie chcę znać ;), a obecnie jest to rozwijane przez mojego znajomego.

Do tego dochodzi kawałek kodu odpowiedzialny za zasysanie 'logów' z poszczególnych serwerów, obrabianie ich lekko i wsadzanie do lokalnej bazy danych. To postanowiłem zrobić w pythonie i od już gdzieś roku działa bez problemów. Znajomy nawiasem mówiąc w przerwach od pehapienia też coś podobnego robi. Też w pythonie :)

Ostatnio natomiast przyszło mi przerobić jeden z serwerów na coś zbierającego i analizującego dane. Więc kod w C przerobiłem na zbierający dane, natomiast kombinacją pythona i shella zarządzam odpalaniem owego serwera, po czym obrabiam wynikowe dane. Działa pięknie i pozwala na wręcz gigantyczną swobodę.

Ostatnio natomiast szef mi kazał doprowadzić do jakiegoś stanu mieszaninę kodu C i C++ w wersji bardzo bardzo alpha (ledwo proof of concept). Powiedziałem mu, że to będzie duuużo roboty i będzie to długo trwało, na co odpowiedział, że mam to tylko na szybko przyciąć, coby było zdatne na demo dla potencjalnych klientów.

Python rządzi! Robienie w nim gluecodu po prostu wymiata. Zamiast martwić się przerabianiem wnętrzności tego kodu C/C++, po prostu podzieliłem go logicznie na coś w rodzaju modułu synchronizującego i programik 'kliencki' robiący jak najprostszą rzecz, a sterowany z linii komend. A synchronizację jednemu i drugiemu zapewniłem przy pomocy dwóch skryptów pythonowych i kawałka shella. Miodzio. Gdyby nie python, to bym się pewnie posiekał, bo musiałbym to robić nie dość, że w C/C++, co samo z siebie byłoby powolne, to jeszcze cały czas by mi w paradę wchodził oryginalny kod.

Luuudzie! Uczcie się (dobrych) języków skryptowych, bo bez nich jak bez fujarki, znaczy, wróć, bez ręki. Nawet sobie nie wyobrażam co by ze mną było, gdybym się te bodajże dwa lata temu owego pythona nie nauczył.

MoinMoin wygląda całkiem nieźle. A że jest w pythonie i ma standardowo system pluginów, to w razie czego zrobienie rozszerzeń nie powinno być zbyt kłopotliwe. Jest tylko jeden problem, mianowicie coś ma spaprane z wyświetlaniem 'akcji' (porównajcie sobie jak zakładanie strony powinno wyglądać i jak wygląda). Ale to się pewnie jakoś poprawi. Trzeba tylko powywalać przy pomocy cssa wszystkie opcje do edytowania stron (zarejestrowani użytkownicy będą sobie mogli wybrać inną skórkę z tymi rzeczami widocznymi) i zobaczyć jak tam są rozwiązane ACLe. No i tego nowego cssa zunifikować z tym, co będzie na forum.

Im więcej kilobajtów ma mój kod, tym mam większe wrażenie, że duże klasy w pythonie są nieczytelne. Nie wiem z czego to wynika - chyba z tego, że brakuje mi nawiasów otaczających poszczególne bloki kodu. W pythonie robi się to samym identowaniem kodu, ale takie nagle się kończące kawałki mocno wyidentowanego kodu mi dziwnie wyglądają... takie wiszące w przestrzeni.
Już wiem! Po prostu w C przy odpowiednim kodowaniu wszystko musi się kończyć optycznie 'łagodnie'. Tzn. jeśli kończę jakiegoś ifa w pętelce w pętelce w pętelce, to kod wygląda tak:

                    koniecmojegoifa();
                }
            }
        }
    }
    itutajdalejkod();

W pythonie natomiast to samo by wyglądało tak:

                    koniecmojegoifa()
    itutajdalejkod()

Podświadomie (a teraz już świadomie, bo żem się pokapował o co mi chodzi) gryzie mnie w oczy taki nagły skok o parę poziomów identacji. Wniosek - jak słoń ma trąbę, żeby się tak gwałtowanie nie zaczynał, tak C ma swoje nawiasiki, żeby się bloki kodu tak gwałtownie nie kończyły.

Ja rozumiem, że do założeń pythona pasują te struktury danych, które on ma, ale mi się coś robi, jak zamiast zrobić sobie po ludzku strukturę, to ja generuję jakieś wielopoziomowe słowniki. Zaraz tym walnę i zrobię sobie jakiś normalny strukturowaty obiekt do tego.

Jednak kodowanie w pythonie jest szybkie. Bardzo szybkie. Jak nie trzeba się użerać z obsługą podstawowych typów danych, a całą potrzebną 'lowlevelową' funkcjonalność zapewniają gotowe moduły, to wszystko idzie jak z płatka.
Moje międzymordzie www do ftpa pldowego potrafi mnie zautoryzować i wyświetlić mi jakie są dostępne w drzewku testowym paczki. Teraz zrobienie tak, żeby to potrafiło cokolwiek sensownego zrobić, to kwestia kilkunastu dodatkowych linijek kodu. Tyle, że teraz się zaczyna problematycznie - primo muszę od razu wymyślić jakiś sposób cachowania metadanych, żeby każde zalogowanie na www nie oznaczało wczytywania 1,5 mega danych z 300 plików, a secundo muszę być w stanie atomowo lockować. Kto wie jak w pythonie sobie atomowo zlockować np. jakiś katalog? (jak się nie da, to się skończy jakimś małym demonem lockującym w C pewnie)
No a jak to skończę, to będzie najciekawsza część zabawy - zintegrowanie tego z poldkiem, żeby automatycznie testował spsute zależności. Znowu będzie przekopywanie się przez tony nieokomentowanego i zawiłego kodu w C :/

No więc ostateczna diagnoza. Jeśli na prawdziwym systemie jest Ra (pld 1.0 dla niewiedzących), a wewnątrz chroota jest Ac (pld 2.0 dla niewiedzących) i architekturą jest ppc, a do chroota wchodzimy odpalając z pythonowego skryptu os.system("sudo chroot chroot-ac"), to środowisko wewnątrz chroota będzie skażone i aplikacje wątkowe będą się wywalały. Co ciekawe skażenie występuje przy jakiejkolwiek aplikacji odpalanej przez pythona i jest dziedziczone w dół. Zrobiłem takiego testa polegającego na odpaleniu os.system("screen") z pythona. Spod tego screena jakiekolwiek wejście do chroota powodowało znany nam błąd i nie udało mi się tego obejść. Python coś psuł, ale owo psucie objawiało się tylko przy wejściu do środowiska różniącego się glibcem. Przekompilowałem pythona na wersję 2.3 i nie pomogło. Wniosek, że albo glibc 2.2.5 jest skopany, albo kompilacja pod gcc2 daje takie rezultaty (albo oba na raz), przy czym imho to raczej ten ryćkany gcc (który na wszystkim != x86 działa po prostu tragicznie).
Koniec końców jeśli na zewnątrz chroota nie będzie Ra, tylko Ac, to problem nie występuje. Przy obecnej lokalizacji buildera ppc upgrejd jest niemożliwy, ale na szczęście spidi ma mocny desktop, który będzie można zupgrejdować. Obiecał, że zrobi to w poniedziałek. No i git.

Dobiłem swojego segfolta w jggtrans i zrobiłem małą poprawkę na cośtam (i przy okazji stwierdziłem, że gdb nie jest takie złe). Za to Jajcuś rzucił się na głęboką wodę i od paru dni koduje jak szalony. Ja chcę nowe PSI, żeby móc potestować to co on zrobił! (poza tym mi trochę głupio, że przy nim to ja żaden developer jggtransa, tylko jakiś asystent pomocnika :)

Afera z Witkiem F. jest chyba bliska wyjaśnieniu, ale nadal nie wiem o co chodzi :). Przy odrobinie szczęścia coś pożytecznego z tego wyniknie... no ale ja się nie mieszam.

Poza tym kloczek coraz częściej i pewniej przebąkuje o zbudowaniu pakietów Acze. Przy okazji owego budowania oczywiście kilka osób zaczęło narzekać na to, że im cośtam popsuł, no ale co to by był za kloczek gdyby czegoś nie rozwalił od czasu do czasu :).

Jutro jeden segfolt i brak obsługi jednego komunikatu. A teraz spać.

Ależ robienie supportu do gettexta jest pasjonujące. Klepanie, klepanie, klepanie.
A Jajcuś zrobił data gathering i wybieranie języka per user. Trzeba będzie przetestować :)

Miałem ten tekst wysłać wczoraj, ale jogger nie działał :( No więc przedwczoraj Jajcuś dołożył do gg transportu poprawki na kilka segfoltów (c) venglin (tenże venglin poluje na jeszcze jednego babola co mu powinno zająć ca tydzień - trzymamy kciuki) oraz sam znalazł jeden potencjalny segfolt. Co ważne dołożył wstępne wsparcie dla gettexta! Nawet nie podejrzewałem, że dodanie podstawowej infrastruktury będzie na tyle nietrudne; jednak autoconf/automake to całkiem fajna rzecz pomijając, że oba narzędzia są do dupy. Teraz zostało jeszcze popoprawiać wszystkie odwołania do tekstów w kodzie programu. To już ja zrobię przy okazji paru drobnych fixów. A później trza tylko znaleźć kogoś kto całość przetłumaczy. Chyba nie powinno być z tym większych problemów :) Ja z kolei wreszcie zreanimowałem obsługę updejtu katalogu publicznego gg (tzn. przy rejestracji dane są znowu uaktualniane) przy okazji likwidując jedną niedogodność. Kod jest brzydki, ale to się później popoprawia :) btw: Teraz jest tak, że admin danego serwera może wprowadzić funkcję, że przy zmianie informacji o danym użytkowniku (vcard) jest updejtowany wybrany jabber user directory (nie wiem, czy admini z tego korzystają... bluszcz?). Może by tak zrobić opcję, że jeśli ktoś jest zarejestrowany w ggtransporcie to od razu updejtowane są też informacje w katalogu publicznym gg? (w sumie miało by to spory sens)