Tworzenie klas pochodnych: port programu SciMark2 - Revision history

Krashan: Another link redirected to Polish version.

2011-01-29T14:01:58Z

Another link redirected to Polish version.

Krashan: Link redirected to Polish version.

2011-01-29T13:59:19Z

Link redirected to Polish version.

Krashan: Formatting restored.

2011-01-28T12:50:28Z

Formatting restored.

Krashan: /* Final Port */ Translation finished.

2011-01-28T12:49:47Z

‎Final Port: Translation finished.

Krashan: /* Implementacja metod */ Translation finished.

2011-01-28T12:48:16Z

‎Implementacja metod: Translation finished.

Krashan: /* Implementacja metod */ Translation in progress.

2011-01-28T12:46:04Z

‎Implementacja metod: Translation in progress.

Krashan: /* Implementing Functionality */ Translation in progress.

2011-01-28T12:39:48Z

‎Implementing Functionality: Translation in progress.

Krashan: /* Metody i atrybuty */ Translated.

2011-01-28T12:22:08Z

‎Metody i atrybuty: Translated.

Krashan: /* Metody i atrybuty */ Translation in progress.

2011-01-28T12:14:34Z

‎Metody i atrybuty: Translation in progress.

Krashan: /* Methods and Attributes */ Translation in progress.

2011-01-28T12:02:10Z

‎Methods and Attributes: Translation in progress.

@@ Line 85: / Line 85: @@
+  }
-Metoda używa [[Locating Objects in the Object Tree|dynamicznego wyszukiwania obiektów]] w celu uzyskania dostępu do obiektów MUI.
+Metoda używa [[Wyszukiwanie obiektów w drzewie|dynamicznego wyszukiwania obiektów]] w celu uzyskania dostępu do obiektów MUI.
 Pierwszym krokiem jest ustalenie rozmiaru danych dla testu, zgodnie z wartością pola ''d->LargeData''. Pole to jest aktualizowane przy zmianie atrybutu ''APPA_LargeData'', który z kolei jest powiązany notyfikacją z przyciskiem "Large Data". Następnie jest kasowana zawartość paska stanu i wpisywana jest tam informacja dla użytkownika o wykonującym się teście. Pole wyniku testu jest również czyszczone.

← Older revision		Revision as of 13:59, 29 January 2011
Line 55:		Line 55:
	App, 3, MUIM_Set, APPA_LargeData, MUIV_TriggerValue);		App, 3, MUIM_Set, APPA_LargeData, MUIV_TriggerValue);

−	Obiekty źródłowe notyfikacji są [[~~Locating Objects in the Object Tree~~\|dynamicznie wyszukiwane]] w drzewie obiektów aplikacji (makro ''findobj()''). Zaoszczędza to potrzeby definiowania dla nich globalnych wskaźników.	+	Obiekty źródłowe notyfikacji są [[Wyszukiwanie obiektów w drzewie\|dynamicznie wyszukiwane]] w drzewie obiektów aplikacji (makro ''findobj()''). Zaoszczędza to potrzeby definiowania dla nich globalnych wskaźników.

@@ Line 19: / Line 19: @@
 To doświadczenie pokazuje jak bardzo ważne jest korzystanie z optymalizacji kodu, zwłaszcza w programach wykonujących dużo obliczeń. Zoptymalizowan kod jest '''ponad 4 razy szybszy'''!
 ==Przegląd kodu==
@@ Line 26: / Line 27: @@
 Bliższe przyjrzenie się plikowi ''scimark2.c'' ujawnia, że zawiera on obiekt ''Random'' (jest to struktura zdefiniowana w pliku ''Random.h''), który jest używany przez wszystkie 5 testów. W oryginalnym kodzie jest on tworzony funkcją ''new_Random_seed()'' na początku programu i usuwany funkcją ''delete_Random()'' na jego końcu. Najlepszym miejscem na ten obiekt w zMUI-fikowanej wersji są dane obiektu aplikacji. Wtedy można go zainicjalizować w konstruktorze aplikacji (metoda ''OM_NEW()'') a usunąć w destruktorze (metoda ''OM_DISPOSE()''). Te dwie metody należy więc w klasie pochodnej od ''Application'' przeciążyć.
 ==Projekt intrerfejsu graficznego==
@@ Line 36: / Line 38: @@
 * Zmniejszenie wielkości kodu. Zamiast powtarzać bardzo podobny kod wiele razy, na przykład przyciski różniące się jedynie etykietami, można wywołać podprogram z tekstem etykiety jako parametrem.
 * Debugowanie. Bywa, że MUI odmawia stworzenia obiektu aplikacji z powodu jakiegoś błędnego taga albo jego wartości. Jeżeli główne wywołanie ''MUI_NewObject()'', tworzące obiekt aplikacji, jest podzielone na szereg mniejszych funkcji, łatwo wyizolować błąd wstawiając kilka ''Printf()''-ów w tychże funkcjach.
 ==Metody i atrybuty==
@@ Line 53: / Line 56: @@
 Obiekty źródłowe notyfikacji są [[Locating Objects in the Object Tree|dynamicznie wyszukiwane]] w drzewie obiektów aplikacji (makro ''findobj()''). Zaoszczędza to potrzeby definiowania dla nich globalnych wskaźników.
 ==Implementacja metod==
@@ Line 90: / Line 94: @@
 Metoda ''APPM_AllBenchmarks()'' jest znacznie dłuższa, dlatego jej kod nie został zamieszczony w artykule. Metoda ta wywołuje kolejno wszystkie 5 testów, gromadząc ich wyniki w tablicy. Po każdym wykonanym teście aktualizowany jest pasek postępu. Na zakończenie wyliczany jest łączny wynik testów i wyświetlany w polu wyników.
 ==Gotowy port programu==

@@ Line 91: / Line 91: @@
 Metoda ''APPM_AllBenchmarks()'' jest znacznie dłuższa, dlatego jej kod nie został zamieszczony w artykule. Metoda ta wywołuje kolejno wszystkie 5 testów, gromadząc ich wyniki w tablicy. Po każdym wykonanym teście aktualizowany jest pasek postępu. Na zakończenie wyliczany jest łączny wynik testów i wyświetlany w polu wyników.
-==Final Port==
+==Gotowy port programu==
-[http://krashan.ppa.pl/morphzone_tutorials/scimark2_mui.lha The complete source of SciMark2 MUI port]
+[http://krashan.ppa.pl/morphzone_tutorials/scimark2_mui.lha Kompletny kod źródłowy SciMarka2 w wersji MUI]
-The program may be built by running ''make'' in the source directory.
+Program można skompilować wydając polecenie ''make'' w katalogu z kodem źródłowym.

@@ Line 89: / Line 89: @@
 Następna linia kodu uruchamia właściwy test, wywołując funkcję ''kernel_measureFFT()'' z oryginalnego kodu SciMarka. Po zakończeniu testu otrzymany rezultat jest formatowany z użyciem funkcji ''NewRawDoFmt()''. Jest to funkcja systemowa z ''exec.library''. Użyta ze stałą ''RAWFMTFUNC_STRING'' działa tak samo jak standardowy ''sprintf()''. Do formatowania zastosowano bufor o stałej długości 128 bajtów, więcej od rzeczywistej możliwej długości tekstu, ale warto zawsze zostawić margines bezpieczeństwa. Sformatowany tekst wyświetlany jest w polu rezultatu testu. Następnie aplikacja jest "budzona z uśpienia" a tekst na pasku stanu jest zmieniany na "Ready."
-The ''APPM_AllBenchmarks()'' method code is longer so it is not repeated here. The method is very similar to the single benchmark method anyway. The difference is it runs all 5 tests accumulating their results in a table. It also updates the progress bar after every benchmark. Finally it calculates a mean score and displays it.
+Metoda ''APPM_AllBenchmarks()'' jest znacznie dłuższa, dlatego jej kod nie został zamieszczony w artykule. Metoda ta wywołuje kolejno wszystkie 5 testów, gromadząc ich wyniki w tablicy. Po każdym wykonanym teście aktualizowany jest pasek postępu. Na zakończenie wyliczany jest łączny wynik testów i wyświetlany w polu wyników.
 ==Final Port==

@@ Line 87: / Line 87: @@
 Z kolei aplikacja wprowadzana jest w stan zajętości (ang. ''busy''). Należy to czynić zasze, gdy aplikacja może nie reagować na poczynania użytkownika dłużej niż, powiedzmy, pół sekundy. Ustawienie atrybutu ''MUIA_Application_Sleep'' na wartość ''TRUE'' blokuje GUI i wyświetla "zajęty" wskaźnik myszy gdy okno programu jest aktywne. Oczywiście generalnie lepszym wyjściem byłoby uruchomienie testu w podprocesie, ale w teście wydajności nie ma to większego sensu. Tak czy inaczej użytkownik musi zaczekać na wykonanie testu zanim uruchomi kolejny. Jedynym problemem z punktu widzenia użytkownika jest to, że nie da się przerwać testu w trakcie jego wykonywania. Dla prostoty kodu pozostawiono ten problem nierozwiązany. Uruchamiając test mocy procesora oczekujemy, że obciąży on komputer całkowicie, kilka sekund zablokowania GUI programu nie jest w tym przypadku problemem.
-The next line of code runs the benchmark, by calling ''kernel_measureFFT()'' function from the original SciMark code. After the benchmark is done, the result is formatted and displayed in the result field using ''NewRawDoFmt()'', which is a low-level string formatting function from ''exec.library'' and with the ''RAWFMTFUNC_STRING'' constant, it works just like ''sprintf()''. It uses a fixed buffer of 128 characters (which is much more than needed, but adds a safety margin) located in the object instance data. Unsleeping the application and setting the status bar text to "Ready." ends the method.
+Następna linia kodu uruchamia właściwy test, wywołując funkcję ''kernel_measureFFT()'' z oryginalnego kodu SciMarka. Po zakończeniu testu otrzymany rezultat jest formatowany z użyciem funkcji ''NewRawDoFmt()''. Jest to funkcja systemowa z ''exec.library''. Użyta ze stałą ''RAWFMTFUNC_STRING'' działa tak samo jak standardowy ''sprintf()''. Do formatowania zastosowano bufor o stałej długości 128 bajtów, więcej od rzeczywistej możliwej długości tekstu, ale warto zawsze zostawić margines bezpieczeństwa. Sformatowany tekst wyświetlany jest w polu rezultatu testu. Następnie aplikacja jest "budzona z uśpienia" a tekst na pasku stanu jest zmieniany na "Ready."
 The ''APPM_AllBenchmarks()'' method code is longer so it is not repeated here. The method is very similar to the single benchmark method anyway. The difference is it runs all 5 tests accumulating their results in a table. It also updates the progress bar after every benchmark. Finally it calculates a mean score and displays it.

@@ Line 54: / Line 54: @@
 Obiekty źródłowe notyfikacji są [[Locating Objects in the Object Tree|dynamicznie wyszukiwane]] w drzewie obiektów aplikacji (makro ''findobj()''). Zaoszczędza to potrzeby definiowania dla nich globalnych wskaźników.
-==Implementing Functionality==
+==Implementacja metod==
-The five methods implementing single SciMark benchmarks are very similar, so only one, running the Fast Fourier Transform has been shown:
+Pięć metod, które zawierają główną funkcjonalność SciMarka, jest do siebie bardzo podobnych. Dlatego zacytowano tu tylko jedną, wykonującą test szybkiej transformaty Fouriera:
   IPTR ApplicationFastFourierTransform(Class *cl, Object *obj)
@@ Line 81: / Line 81: @@
+  }
-The code uses [[Locating Objects in the Object Tree|dynamic object tree search]] for accessing MUI objects.
+Metoda używa [[Locating Objects in the Object Tree|dynamicznego wyszukiwania obiektów]] w celu uzyskania dostępu do obiektów MUI.
-The method sets the benchmark data size first, based on the ''d->LargeData'' switch variable. This variable is set with the ''APPA_LargeData'' attribute, which in turn is bound to the "Large Data" button via a notification. Then the status bar progress is cleared and some text is set to inform the user what is being done. The result textfield for the benchmark is cleared as well.
+Pierwszym krokiem jest ustalenie rozmiaru danych dla testu, zgodnie z wartością pola ''d->LargeData''. Pole to jest aktualizowane przy zmianie atrybutu ''APPA_LargeData'', który z kolei jest powiązany notyfikacją z przyciskiem "Large Data". Następnie jest kasowana zawartość paska stanu i wpisywana jest tam informacja dla użytkownika o wykonującym się teście. Pole wyniku testu jest również czyszczone.
-The next step is to put the application in the "busy" state. It should be always done, when the application may not be responding to user input for anything longer than, let's say half a second. Setting ''MUIA_Application_Sleep'' to ''TRUE'' locks the GUI and displays the busy mouse pointer when the application window is active. Of course offloading processor intensive tasks to a subprocess is a better solution in general cases, but for a benchmark it makes little sense. A user has to wait for the benchmark result anyway before doing anything else, like starting another benchmark. The only usability problem is that a benchmark can't be stopped before it finishes. Let's leave it as is for now, for a benchmark, where the computer is expected to use all its computing power for benchmarking, a few seconds of GUI being unresponsive is not such a big problem.
+Z kolei aplikacja wprowadzana jest w stan zajętości (ang. ''busy''). Należy to czynić zasze, gdy aplikacja może nie reagować na poczynania użytkownika dłużej niż, powiedzmy, pół sekundy. Ustawienie atrybutu ''MUIA_Application_Sleep'' na wartość ''TRUE'' blokuje GUI i wyświetla "zajęty" wskaźnik myszy gdy okno programu jest aktywne. Oczywiście generalnie lepszym wyjściem byłoby uruchomienie testu w podprocesie, ale w teście wydajności nie ma to większego sensu. Tak czy inaczej użytkownik musi zaczekać na wykonanie testu zanim uruchomi kolejny. Jedynym problemem z punktu widzenia użytkownika jest to, że nie da się przerwać testu w trakcie jego wykonywania. Dla prostoty kodu pozostawiono ten problem nierozwiązany. Uruchamiając test mocy procesora oczekujemy, że obciąży on komputer całkowicie, kilka sekund zablokowania GUI programu nie jest w tym przypadku problemem.
 The next line of code runs the benchmark, by calling ''kernel_measureFFT()'' function from the original SciMark code. After the benchmark is done, the result is formatted and displayed in the result field using ''NewRawDoFmt()'', which is a low-level string formatting function from ''exec.library'' and with the ''RAWFMTFUNC_STRING'' constant, it works just like ''sprintf()''. It uses a fixed buffer of 128 characters (which is much more than needed, but adds a safety margin) located in the object instance data. Unsleeping the application and setting the status bar text to "Ready." ends the method.
 The ''APPM_AllBenchmarks()'' method code is longer so it is not repeated here. The method is very similar to the single benchmark method anyway. The difference is it runs all 5 tests accumulating their results in a table. It also updates the progress bar after every benchmark. Finally it calculates a mean score and displays it.
 ==Final Port==

@@ Line 42: / Line 42: @@
 Pisząc program warto umieszczać każdą klasę w oddzielnym pliku. Ułatwia to utrzymanie modułowości kodu, pozwala również na [[Rzut oka na BOOPSI#Klasy|ukrycie danych prywatnych klasy]]. Pociąga to sa sobą konieczność napisania ''makefile'', ale oryginalny kod SciMarka również składa się z kilku pilków, więc tak, czy inaczej, jest to nieuniknione. Stosując się do przedstawionych powyżej wskazówek projektowych można napisać [http://krashan.ppa.pl/morphzone_tutorials/scimark2_application.h plik nagłówkowy] klasy i jej [http://krashan.ppa.pl/morphzone_tutorials/scimark2_application.c kod]. Klasa w tej postaci nadal nic nie robi, po prostu zawiera puste metody akcji programu i przeciąża metody ''[[Przeciążanie metody OM_SET()|OM_SET()]]'', ''[[Przeciążanie konstruktorów|OM_NEW()]]'' i ''[[Przeciążanie destruktorów|OM_DISPOSE()]]''. Pisanie takiego szkieletu klasy jest nudną mechaniczną pracą, więc można ją zwalić na komputer. W istocie, przykładowy kod został wygenerowany narzędziem  [http://downloads.morphzone.org/find.php?find=chocolatecastle ChocolateCastle]. Niestety ChocolateCastle jest wciąż w wersji beta, więc kilka drobnych poprawek trzeba było wprowadzić ręcznie.
-The next step in the application design is to connect methods and attributes with GUI elements using [[Event Driven Programming, Notifications#Notifications in MUI|notifications]]. Notifications must of course be created after both source and target object are created. In the SciMark code they are just set up after executing ''build_gui()''. All the six action buttons have very similar notifications, so only one is shown here:
+Następnym krokiem w projektowaniu programu jest połączenie metod i atrybutów z elementami interfejsu graficznego używając [[Programowanie sterowane zdarzeniami, notyfikacje#Notyfikacje w MUI|notyfikacji]]. Notyfikacje można ustawiać dopiero gdy zarówno źródło jak i cel notyfikacji są istniejącymi obiektami. W kodzie SciMarka są one ustawiane po wykonaniu funkcji ''build_gui()''. Wszystkie przyciski testów mają bardzo podobne notyfikacje, dlatego tutaj pokazana jest tylko jedna:
   DoMethod(findobj(OBJ_BUTTON_FFT, App), MUIM_Notify, MUIA_Pressed, FALSE,
    App, 1, APPM_FastFourierTransform);
-The "Large Data" button has a notification setting the corresponding attribute:
+Przycisk "Large Data" ma notyfikację ustawiającą odpowiadający mu atrybut:
   DoMethod(findobj(OBJ_BUTTON_LDATA, App), MUIM_Notify, MUIA_Selected, MUIV_EveryTime,
    App, 3, MUIM_Set, APPA_LargeData, MUIV_TriggerValue);
-Notified objects are accessed with [[Locating Objects in the Object Tree|dynamic search]] (the ''findobj()'' macro), which saves the programmer from defining global variables for all of them.
+Obiekty źródłowe notyfikacji są [[Locating Objects in the Object Tree|dynamicznie wyszukiwane]] w drzewie obiektów aplikacji (makro ''findobj()''). Zaoszczędza to potrzeby definiowania dla nich globalnych wskaźników.
 ==Implementing Functionality==