A dzisiaj trochę typowego blogowania, czyli linki.
Na pierwszy ogień, Weebl & Bob. Bo, jak się wczoraj okazało, taki da.killa na przykład nigdy wcześniej o tym nie słyszał. No jak można nie znać tych animacyjek? Ech. Więc link do pierwszego odcinka. Polecam. Nie można się tylko zrażać pierwszymi animacjami, potem się robi coraz fajniejsze. Mogą być niezrozumiałe jeśli zacznie się oglądać jakieś wyrwane z kontekstu fragmenty, dlatego radzę oglądać po kolei, wszystkie. Fajny język, bardzo alternatywna muzyka w tle - jednym słowem, dobra rozrywka.
Komiks The Flipside. Milutki, rysowany w stylu który uwielbiam, bardzo dobry i warsztatowo, i pod względem dialogów/fabuły. Nie przegap "Book Zero!".
Drugi komiks który polecę dziś, TwoKinds. Mniej udany technicznie, ale za to kolorowy i bardziej na luzie. Czyta się bardzo miło, a humor miejscami jest naprawdę, naprawdę dobrze zaserwowany. No i fabuła trzyma w napięciu - tzn. śledzi się z niecierpliwością, a przecież o to właśnie chodzi.
Nie komiks, ale... a zresztą, sam zobaczysz. Szadoki pokazał mi lanrat, no i wydaje mi się, że warto polecać to dalej. Więc polecam!
Metapixel to zabawka którą wskazał mi również lanrat, tyle że jakiś czas temu. Znikoma przydatność praktyczna, ale można obejrzeć - efekty są całkiem ciekawe. Programowi serwuje się duży (jak największy) zbiór zdjęć, z których tworzy sobie bazę danych. Następnie używając tych zdjęć jako miniaturek jest w stanie skonstruować dowolne inne podane zdjęcie. Brzmi skomplikowanie? No ale tak to działa.
Układanki z monet to coś, co muszę samemu kiedyś wypróbować. Mam świnkę-skarbonkę pełną groszówek, jeśli dadzą się wyciągnąć bez szlachtowania zwierzaczka, to może sam ułożę sobie wieżę?
No i Last.fm - podobno bardzo fajne radio. Podobno. Tak mówią. Nie próbowałem jeszcze, bo z tego co widzę wymaga własnego klienta (ale jest wersja linuksowa na qt4, kod źródłowy na licencji BSD), więc nie jest źle - a jeśli używa w miarę normalnego strumienia, to pewnie by się dało uzyskać dane potrzebne do pożenienia tego np. z mplayerem? A na razie nie sprawdzałem, bo u mnie ichnia binarka klienta nie działa. Tzn. działa, ale zamiast tekstu mam same kwadraciki. da.killa na swoim MDK zresztą też. A że mam na razie inne rzeczy na głowie, to i nie interesowałem się tym. Może powinienem przekompilować kod na własnym systemie?
Na razie założyłem na last.fm sobie konto, włączyłem odpowiedni plugin w Quod Libet i system zbiera informacje o moich preferencjach muzycznych :) Bo last.fm działa właśnie w oparciu o preferencje - tzn. chyba generuje różne wersje strumieni w zależności właśnie od gustów ludzi, więc łatwo jest znaleźć sobie coś pasującego. Dlatego też trzeba założyć sobie konto, chyba dlatego też mają własnego klienta. Nie wiem, zgaduję, nie miałem czasu się przyjrzeć. No ale konto już mam, ciekawscy mogą je podejrzeć.
BTW, wysłałem niedawno cztery tickety na buglistę Quod Libet, wszystkie cztery zostały zignorowane :) No dobra, jeden uznano - okazało się, że to bug którego nie potrafili namierzyć i dostał już w przeszłości status "closed", po moim narzekaniu widać uwierzyli, że to błąd na styku pygtk/gtk+, a nie sprawa błędów w gtk+ engines, jak sugerował któryś z developerów, i sprawa jednak została załatwiona :) No to jeden błąd mniej dzięki mnie ;)
A, w gtk+-2.8.0 jest błąd. Nie radzę kompilować z --enable-debug=no. Coś mają popsute chyba w assertach w okolicy gdk-pixbuf (tak to przynajmniej wygląda mi na pierwszy rzut oka). Ale nie mam czasu teraz tego śledzić ani patchować, liczę że do 2.8.1 ktoś inny to wykryje i napisze łatkę. Aha, poza tym samo gtk+-2.8.0 działa bardzo dobrze, zgodne wstecznie z 2.6.x, nie sprawia problemów z pygtk, wxGTK czy Azureusem. Wnikliwi obserwatorzy dostrzegą w kodzie gtk+ też zalążki zestawu do testowania wydajności - tak, coś jak prosty benchmark. Czyżby wreszcie w ekipie GTK+ ktoś postanowił wziąć się za prędkość?
A na koniec polecę Gimpa 2.3.3. Tak, to gałąź devel. Potencjalnie niestabilna (choć u mnie 2.3.2 i 2.3.3 działają fajnie i stabilnie). A dlaczego polecę tego gimpa? Bo fajny jest :) No dobra, jest trochę drobnych usprawnień, jest też trochę usprawnień większego kalibru. Np. historię undo można teraz wyczyścić (tzn. kazać gimpowi zapomnieć o możliwości undo dla jakiegoś obrazka - przydatne przy edycji dużych obrazów, czasem miałem już tak, że musiałem co parę operacji obrazek zapisywać i ładować na nowo, bo historia undo zżerała mi wolny ram). Doszło nowe narzędzie do zaznaczeń prostokątnych, pozwala zmieniać wymiary istniejącego zaznaczenia przez przeciąganie krawędzi ramki myszą, albo wpisywanie parametrów w odpowiednie okienko. Ma też tryb "highlight" znakomicie ułatwiający kadrowanie zdjęć (przyciemnia obszary leżące poza zaznaczeniem). Jest też wreszcie "align tool", pozwalający łatwiej wyrównywać i pozycjonować warstwy względem siebie. Rany, jak mi tego brakowało kiedyś!
Doszło też nowe narzędzie do zaznaczania obiektów na pierwszym planie (foreground select). Oparte na algorytmie SIOX, działa bardzo ładnie. Oznacza się najpierw z grubsza cały obiekt, potem retuszuje - przypomina to trochę malowanie maski, zmienia się wielkość pędzla zgodnie z potrzebami... wygodne, IMO dużo lepsze niż cudowanie z różdżką i korygowanie usterek przez freehand selection, ale warto obejrzeć ten prosty filmik pokazowy żeby załapać jak to działa (btw, ten niemiecki akcent lektora... ^_^).
Zdecydowanie w dobrym kierunku ten cały Gimp idzie. Teraz jeszcze żeby clone tool dostał funkcje automatycznego dopasowywania koloru/jasności... i Gimp będzie się coraz bardziej zbliżał do Photoshopa. Co jest pozytywną rzeczą. Oczywiście samo UI też jest coraz sensowniejsze, np. zniknęło już bodajże menu script-fu, teraz jest zintegrowane z menu filters (co ma sens, bo co kogo obchodziło czy funkcja była robiona skryptem, czy binarką? Dla usera liczy się efekt, a nie sposób w jaki został zrealizowany...), więc GUI zaczęło to w końcu odzwierciedlać.
Ale jest też menu python-fu, zawierające np. konsolkę pythonową. Która działa! Czyli byłbym teraz pewnie w stanie napisać jakiś pythonowy plugin. To miłe, prawdopodobnie wsparcie dla pythona przyspieszy powstawanie nowych pluginów dla gimpa - ja wiem, że wielu ludzi radzi sobie z używaniem języków lispowatych (gimpowe script-fu to jakaś trochę okrojona odmiana Scheme IIRC), ale są też tacy, których litanie nawiasów, wieczne rekurencje i skrajne skrzywienie w kierunku języków funkcyjnych raczej odstraszają. No i tak między nami, do oskryptowania gimpa python jest idealny. Ta jego obiektowość i prostota doskonale pasują do takich zadań.
Ciekawe czy python-fu wygryzie script-fu?
Dopiski:
Od: Paweł Lasek
Data: 20050823, 22:52
Że python-fu raczej Script-Fu nie wygryzie ;-)
Nie, żebym bronił Script-Fu. Ale podobno Pythonowi brakuję już tylko zmiany składni a otrzymamy nowego Lispa ;-)
Od: Anonimowy Czytelnik Repo
Data: 20050824, 18:56
dzęki za linka do last.fm
Od: bies
Data: 20050906, 02:27
Hoppke, Ty piszesz w Pythonie. Skomentuj jakoś to porównanie do Lispa. Jak ostatnio oglądałem Pythona to miał z Lispem niewiele wspólnego, coś się zmieniło? Swoją drogą, Lisp... brrr, paskudztwo, obrzydlistwo, paskudztwo.
Od: Hoppke
Data: 20050906, 19:02
@bies: nie, składniowo i ideowo python to python. Lisp jest "specyficzny", bo jest mocno zafiksowany na programowaniu funkcyjnym, do tego te wszystkie nawiasy... Python to inny rodzaj języka.
Ma kilka popularnych w lispie (i innych podobnych) konstrukcji, ale nie zmieniają one bazowych cech pythona - jeśli chcesz, to możesz nadal pisać w stylu podobnym do basica, pascala czy jakiejś wysokopoziomowej obiektówki. Ale jeśli chcesz, to możesz definiować funkcje "in place" za pomocą lambdy, albo organizować zwięzłe obróbki serii danych za pomocą map(). Tyle, że masz wybór.
Python tak się rozwija i tyle - korzysta z tego co najlepsze u starszych braci i składa z tego własną mieszankę. To, że mam np. map() nie znaczy, ze nie mogę już używać "for". Wybieram to co mi pasuje.
Od: bies
Data: 20050907, 02:10
@Hoppke: czyli nic się nie zmieniło, i dobrze. Co do pisania w Pythonie, to raczej nie. Ze skryptowych wolę Tcl/Tk. A z ogólnego przeznaczenia zbyt dobrze znam C++ aby szukać czegokolwiek innego. Choć Pythona lubię za jego główną cechę: elegancję. Elegancje i wysokopoziomowość. Jego dwie główne cechy: elegancję i wysokopoziomowość. I rozszerzenia funkcyjne. Jego trzy główne cechy... jeśli wiesz co mam na myśli.
A Lisp nie jest "specyficzny", Lisp jest Zły(TM). Znasz ten dowcip o hakerze chwalącym się wykradzionym kodem źródłowym z Departamentu Obrony. Kod był napisany w Lispie a jako dowód haker udostępnił cztery ostatnie wiersze. Wyglądały jakoś
Od: bies
Data: 20050907, 02:17
Ech, ucięło puentę. Ale to nic, teraz Ty czytelniku możesz ją sobie zrobić sam w domowym zaciszu! Potrzebujesz tylko: paczki zapałek, sznurka, łopaty i g++! Rzeczoną puentę otrzymasz stosując przepis:
for (int i = 0; i < 4; ++i) {
for (int j = 0; j < 50; ++j) cout << "(";
cout << endl;
}
Od: Hoppke
Data: 20050907, 19:49
Ja ze skryptowych długo używałem Perla (np. cały engine robiący statystyki usenetu itp. na Repo właśnie w perlu skrobałem), potem poznałem pythona i rzuciłem perla w cholerę.
A C++ nigdy nie poznałem. Nie wiem, jakoś nie mogłem się przekonać. Chociaż ostatnio u szwagra przeglądałem jakiś stary manual do Borland C++ i doszedłem do wniosku, że z porządnym podręcznikiem i C++ bym sobie oswoił. Z kompilowanych nie wychodziłem chyba nigdy poza asembler i C.
@bies: w tej puencie chyba dałeś nie ten nawias co trzeba :)
I czy dobrze rozumiem, że ten sam efekt co ten kod C++ w pythonie by dało:
print (")"*50+"\n")*4
? :)
Od: bies
Data: 20050911, 02:42
@Hoppke: Ech, oczywiście, że nie ten nawias. :) I tak, ten sam efekt. Swoją szosą ciekawy sposób ten Pythonowy, mocno mi Vima przypomina. Choć jak na mój gust trochę zbyt runiczny jak na język programowania. Ale sądzę, że jestem w stanie napisać coś podobnego w C++, dokładniej wyglądałoby to pewnie jakoś tak:
cout << (")" * print_multiplier(50) + "\n") * print_multiplier(4);
Wystarczy zdefiniować typ print_multiplier i dodać mu odpowiednie operatory mnożenia z napisami. Z resztą, czemu nie - popatrz na a w C++ się da. :)
Od: bies
Data: 20050911, 02:43
Ech, pomiędzy "popatrz na" a "a w C++" powinien być adres:
http : // bies. risp. pl / varia / print_multiplier . cpp