Ponton's site

Ostatnimi czasy miałem okazję bliżej przyjrzeć się dwóch narzędziom do projektowania interfejsu. Postaram się w skrócie opisać, co mi się w nich podobało, a co nie.

Na początek Qt Designer, bo jego wcześniej się nauczyłem. Interfejs jest podobny do GIMP-a, czyli dużo niezadokowanych okienek: z kontrolkami, z właściwościami, ze slotami, z hierarchią kontrole i oczywiście okno naszego projektu. Glade natomiast to w całości jedno okno. Wiele osób narzeka na ten “gimpowy” interfejs, jednak w tym przypadku Qt Designer ładnej wygląda, chociaż może niestaranności wykonania Glade’a (głównie chodzi o okno z właściwościami, które, jak to trafnie pan w video tutorialu ujął, it’s never wide enough).

Wśród kontrolek Designera mamy pełen zasób biblioteki Qt (w tym np. kontrolka przeglądarki WWW opartej na WebKicie), jednak są to tylko stricte widżety. Nie będziemy mogli zdefiniować modelu dla *View (TreeView, ListView, etc.), a na tych kontrolkach miałem oparte oba interfejsy projektów (w sumie obie były pewnym interfejsem bazy danych). Glade potrafi tworzyć modele (o ile oczywiście wybierzemy projekt GtkBuilder, ale libglade nie jest już rozwijana, więc wybór tego pierwszego powinien być jasny), jednak chwilę musiałem pogooglać, jak to się robi. Jest to póki co mało intuicyjne (przynajmniej dla mnie). Natomiast w Designerze łatwiej udało mi się ustawić “sortowalność” kolumn (w sumie to w Glade jeszcze do tego nie doszedłem, choć próbowałem).

Ogólnie lepsze wrażenie sprawia jednak Designer. Jest bardziej intuicyjny, pozwala przenosić kontrolki myszką (nie trzeba ich wycinać albo zmieniać albo wpisywać pozycji we właściwościach) i edytować je na oknie. Od razu mamy także podgląd naszego okna. O wiele prościej się też moim zdaniem obsługuje kontenery, choć na początku miałem trochę trudności. W Glade trzeba trochę się namęczyć, żeby stworzyć pożądany efekt na okienku, żeby wszystko było równiutko.

To, co mi się jeszcze spodobało w Designerze, to sloty, chociaż to bardziej kwestia Qt niż samego Designera. Sloty bardzo ułatwiają podpinanie sygnałów. Możemy np. sygnał “clicked()” przycisku podpiąć pod slot “show()” okienka bez pisania żadnej procedury obsługi. Natomiast sygnały niestandardowe, które wymagają odrobiny naszego kodu, trzeba podpinać ręcznie (w kodzie). Glade potrafi zapamiętać nazwy naszych handlerów i automatycznie je podpiąć (w Pythonie trzeba jednak podać mu słownik odwzorowań nazw na funkcje jako argument).

Kiedy już stworzymy interfejs, nadchodzi etap programowania. Sama obsługa naszego interfejsu lepsza jest jednak w Glade. Tworzymy obiekt GtkBuilder i ładujemy nasz plik *.glade. Następnie wywołujemy funkcję, której podajemy nazwę widżetu, a ona zwraca nam wskaźnik (w Pythonie referencję) do niego i już możemy go używać. W Qt Designerze musimy odpowiednim narzędziem skonwertować nasz plik *.ui na kod źródłowy z klasą, od której nasze okno dziedziczy (lub enkapsuluje jej obiekt).

Co zatem jest lepsze? Oba programy są dobre. Na obu oparto potężne środowiska graficzne, zatem oba nadadzą się do stworzenia Twojego projektu. Każda ma swoje mocne i słabe strony, więc wybór w tym przypadku będzie indywidualny i często przypadkowy (tzw. kwestia gustu).

UPDATE: Glade jednak potrafi przenosić kontrolki, a Qt dynamicznie ładować interfejs.

Krótki wstęp do semantyki gier, który przygotowałem w ramach projektu końcowego z Semantyk Języków Programowania.

prezentacja, notatki

Update: notatki pozostałych studentów.

95% muzyki w sieci to nielegalne pobrania.

When you have six million people breaking the law, it’s the law that needs changing, not the people.

Ostatnio miałem ponowną styczność z TeX-em, tym razem konkretnie z Beamerem (całkiem fajne narzędzie do tworzenia ładnych i profesjonalnych prezentacji; być może wrzucę tę, którą zrobiłem na zajęcia). Jest to jeden z programów, które są owiane dla mnie lekką tajemnicą… Już sam fakt że został napisany przez legendarnego Donalda Knutha, powoduje bojaźn i trwogę podczas używania. No dobra, przesadzam, ale TeX to program wyjątkowy. Nie dlatego, że jest bezbłędny (ma już ze 30 lat chyba, a ostatni błąd wykryto w nim kilkanaście lat temu), ale dlatego, że jest napisany… literacko.

Donald Knuth napisał książkę-program pod tytułem TeX: The Program (ISBN: 0201134373). Następnie (a może uprzednio?) napisał narzędzie, które nazwał WEB. WEB pozwalał mu automatycznie skonwertować książkę-program do poprawnego programu w Pascalu (w tamtych czasach był to bardzo popularny język), który po skompilowaniu robił to, co opisano w książkoprogramie. Oprócz tego, pozwalał też wygenerować… książkę. Z nagłówkami, sekcjami, stronami — ot, PDF lub PostScript, nadający się do wydrukowania.

Książkoprogram to tak naprawdę dokumentacja i kod w jednym. Programista pisze na przemian kod i tekst. Może przy pisaniu kodu korzystać ze wszystkich dobrodziejstw TeX-a do opisywania swojego kodu, tworzyć odnośniki do innych fragmentów kodu, etc. Lepiej to zobaczyć na przykładzie: kwadrat.w. Użyłem wesji WEB dla C/C++, która nazywa się CWEB. Aby otrzymać program C, wystarczy polecnie:

$ ctangle kwadrat
This is CTANGLE, Version 3.64 (Web2C 7.5.6)
 
Writing the output file (kwadrat.c):
Done.
(No errors were found.)
$ gcc -o kwadrat kwadrat.c -lm
$ ./kwadrat
Podaj a: 1
Podaj b: 10
Podaj c: 5
x = -9.472136
x = -0.527864

Aby otrzymać dokument TeX-a, należy napisać:

$ cweave kwadrat
This is CWEAVE, Version 3.64 (Web2C 7.5.6)
 
Writing the output file...
Writing the index...
Done.
(No errors were found.)
$ pdftex kwadrat.tex
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
(...)
Output written on kwadrat.pdf (3 pages, 63651 bytes).
Transcript written on kwadrat.log.

Oto wygenerowane pliki: kwadrat.tex, kwadrat.pdf i kwadrat.c. Niestety nie wiem jak zmusić czystego TeX-a do poprawnego czytania UTF-8, dlatego w PDF-ie nie ma polskich liter.

Szczerze mówiąc nie mam zdania na temat literate programming. Jeśli ktoś lubi tak pisać, to proszę bardzo — całkiem przyjemnie się czyta taki dokument. Jednak ja nie lubię się rozpisywać nad kodem, dla mnie sam kod (z komentarzami) stanowi wystarczającą dokumentację. ;)

Warto jeszcze dodać, że wsparcie dla literate programming jest zaimplementowane w Haskellu. Ale to już lepiej poczytać na Haskell Wiki.

Ze względu na ciekawość:

serwisant komputerowy < nauczyciel informatyki < administrator < programista nudnych rzeczy (biznes, banki, przemysł, itp.) < programista ciekawych rzeczy < pracownik naukowy

Przez 4 miesiące pracowałem przy tworzeniu gry, w końcu mogę się czymś pochwalić. Na stronie www.tanadu.com można się już zapisać do wstępnych testów tytułowej gry. Póki co jeszcze nie można zagrać, ale można poczytać o samej grze oraz dowiedzieć się, że dla najlepszego testera jest przewidziana nagroda.

Tak to wygląda mniej więcej.

Mój nowy plan może wyglądać naprawdę groźnie, jednak buddyzm, IO (inżynieria oprogramowania) i PO (praktyka optymalizacji) powinny być w miarę łatwe, więc tak naprawdę zostaje tylko NLP (natural language processing) i SJP (semantyki języków programowania). Oba na szczęście nie wymagają jakiejś większej wiedzy (w szczególności JFiZO i AiSD). W tym semestrze potrzebuję dużo, dużo punktów… Kto mnie zmobilizuje?

Jedną z “dziwnych” rzeczy, które potrafią mi “zająć” czas, gdy się “nudzę”, jest “umieszczanie” losowych “słów” w cudzysłowy i “obserwowanie”, jak zdanie “zmienia” przez to swoje “znaczenie”.

Nie mieliśmy kości na sesję, to trzeba było coś napisać. NWOD-owy rzucacz kośćmi w Pythonie:

#!/usr/bin/python
 
import time
import random
import sys
 
# argumenty: 
ile_scian = int(sys.argv[1])    # ilusciennymi koscmi rzucamy
sukces = int(sys.argv[2])       # od ilu oczek jest sukces
ile_rzutow = int(sys.argv[3])   # ile razy rzucamy
 
def kostka(sciany):
    rzut = random.randint(1, sciany)
    print rzut
    return rzut
 
print '------------------------------'
 
random.seed()
 
sukcesy = 0
 
for i in range(0, ile_rzutow):
    rzut = kostka(ile_scian)
 
    if rzut >= sukces:
        sukcesy += 1
 
    while rzut == ile_scian:
        print 'Przerzut!'
 
        rzut = kostka(ile_scian)
 
        if rzut >= sukces:
            sukcesy += 1
 
print
print "Sukcesy: ", sukcesy

Debuggowanie potrafi niemal wykładniczo skrócić czas szukania błędów w programie, więc warto nauczyć się sprawnie obsługiwać debugger. Dotychczas GNU Debugger był dla mnie czarną magią, a wzorem — ten  z Visual Studio. Tylko gdzieś słyszałem/czytałem, że gdb ma takie same możliwości, ale nie dane mi było się o tym przekonać. Niedawno musiałem się nauczyć jego obsługi, dlatego napiszę sobie ściągawkę (nie, żeby z niej korzystać, ale żeby utrwalić).

Zanim zaczniesz

Musisz najpierw skompilować program z informacjami dla gdb. Robi opcja -g dla gcc.

Komendy

Zamiast miłego interfejsu graficznego, jest miły wiersz poleceń (co dla programisty jest wygodniejsze, bo nie musi odrywać rąk od klawiatury :>), w którym wpisujesz polecenia. Nie musisz podawać jej pełnej nazwy, wystarczy jednoznaczny początek (najczęstsze polecenia mają jedno/dwuliterowe synonimy). Działa dopełnienie tabulatorem! W razie czego: help komenda.

Start

Pierwszy paremtr to nazwa pliku wynikowego programu. Drugim może być numer procesu tego programu, jeśli chcesz zacząć debuggować już działający program.

Przydatne komendy:

• run [argumenty] –  uruchamia program z podanymi (opcjonalnymi) argumentami
• continue – jeśli program jest zatrzymany, wznawia jego działanie
• finish – program się wykonuje aż do napotkania “return”; innymi słowy program działa aż do końca aktualnej ramki stosu

Stop

Żeby się gdzieś zatrzymać, trzeba ustawić breakpointy:

• breakpoint funkcja – ustala breakpoint na początek funkcji
• breakpoint [plik:]linia – ustala breakpoint na określoną linię pliku
• info breakpoints – wypisuje utawione breakpointy
• delete n – usuwa n-ty breakpoint
• condition n cond – ustala warunek dla n-tego breakpointa (program zatrzyma się na nim, jeśli zostanie spełniony warunek cond)
• ^C - czyli przerwanie z klawiatury, również zatrzymuje działający program i oddaje kontrolę gdb

Co się dzieje?

Kilka przydatnych komend, aby zorientować się, co się aktualnie dzieje:

• list – listing kodu (10 linii obecnego kontekstu, podana nazwa funkcji, numer linii, etc.)
• frame – aktualna ramka stosu oraz aktualna instrukcja
• backtrace – ślad stosu
• print x – wypisanie wartości x (to może być dowolne wyrażenie, razem ze zmiennymi w programie)

Tropimy

To, co najważniejsze, czyli śledzimy program krok po kroku:

• next – następna instrukcja (lub n instrukcji), bez wchodzenia wgłąb procedur
• step – j/w, ale z wchodzeniem wgłąb

Psujemy

Można przetestować kilka rzeczy w trakcie trwania programu:

• set x wartość – ustawiamy zmiennej x wartość
• call f(x) – wywołujemy funkcję f z argumentami (w tym wypadku tylko x)

Format zapisu zmiennych, funkcji i adresów.

Czasem chcemy się odwołać do zmiennej z jakiegoś innego zakresu albo funkcji składowej, wtedy piszemy zakres::x, jeśli np. zakres jest klasą, a x jej metodą/polem, albo zakres jest funkcją, a x jej zmienną lokalną. Odwołanie do konkretnej linii ma składnię plik:linia, np. test.c:244. Adres zapisujemy z gwiazdką na początku, np. *0×000000.

A na koniec: quit. I tyle. To było zaledwie 1/5 możliwości gdb, mimo to spokojnie wystarczy do efektywnego debuggowania. Chociaż dziesiątki printfów mają swój urok. ;)