Przejdź do pierwszej, poprzedniej, następnej, ostatniej sekcji, spisu treści.

C. Uwagi implementacyjne

W tym dodatku zawarto informacje istotne głównie dla osób tworzących i rozwijających gawk. Całość jest swoista dla gawk i nie odnosi się do innych implementacji.

C.1. Zgodność w dół i debuggowanie

Zob. 17.5. Rozszerzenia gawk poza POSIX awk, gdzie podsumowano rozszerzenia GNU w stosunku do programu i języka awk. Wszystkie te możliwości można wyłączyć wywołując gawk z opcją `--traditional' lub z opcją `--posix'.

Jeżeli gawk skompilowano do diagnostyki z `-DDEBUG', to w wierszu poleceń jest dostępna jeszcze jedna opcja:

-W parsedebug
--parsedebug: Wypisuje informacje stosu analizatora podczas analizy składniowej programu.

Opcję tę przewidziano tylko dla poważnych twórców gawk, a nie dla przypadkowego użytkownika. Prawdopodobnie nie została nawet wkompilowana w twoją wersję gawk, gdyż spowalnia wykonywanie.

C.2. Tworzenie uzupełnień `gawk`

Jeżeli masz zamiar w znaczący sposób poszerzyć gawk, masz pełną swobodę w tej kwestii. To właśnie jest zasadniczą cechą wolnego oprogramowania: kod źródłowy jest dostępny i możesz bez swobodnie zmieniać go jak zechcesz (zob. 18. Powszechna Licencja Publiczna GNU).

W tej sekcji omówiono dziedziny, w jakich można zmienić gawk, i warunki, o których powinno się pamiętać.

C.2.1. Dodawanie nowych możliwości

Jeżeli chcesz, możesz swobodnie dodawać nowe możliwości do gawk. Jeśli jednak chciałbyś, by te zmiany zostały zawarte w dystrybucji gawk, to jest kilka kroków, jakie powinieneś podjąć, bym mógł wcielić twoje zmiany.

Pobierz najnowszą wersję. Znacznie łatwiej mi scalać zmiany jeśli odnoszą się do najświeższej rozpowszechnianej wersji gawk. Jeśli twoja wersja gawk będzie bardzo stara, mogę nie być w stanie zintegrować jej w ogóle. Zob. B.1.1. Pozyskiwanie pakietu dystrybucyjnego gawk, gdzie opisano pozyskiwanie najnowszej wersji gawk.
Przestrzegaj Standardów Kodowania GNU. Dokument ten opisuje w jaki sposób powinno być pisane oprogramowanie GNU. Jeśli go nie czytałeś, proszę przeczytaj, najlepiej przed rozpoczęciem modyfikowania gawk. (Standardy Kodowania GNU są częścią pakietu dystrybucyjnego Autoconf, z FSF.)
Korzystaj ze stylu kodowania gawk. Kod C użyty do budowy gawk kieruje się instrukcjami zawartymi w Standardach Kodowania GNU, z pomniejszymi wyjątkami. Kod sformatowano korzystając z tradycyjnego stylu "K&R", szczególnie tyczy się to umieszczania nawiasów klamrowych i zastosowania tabulacji. W skrócie, reguły kodowania użyte w gawk są następujące:
- Przy definiowaniu funkcji stosujemy nagłówki w starym stylu (bez prototypowania funkcji).
- Nazwę funkcji umieszczamy na początku wiersza.
- Typ zwracany przez funkcję, nawet jeśli jest to int, umieszczamy w wierszu powyżej wiersza z nazwą i argumentami funkcji.
- Deklaracje argumentów funkcji nie powinny być wcięte.
- Wokół nawiasów używanych w strukturach sterujących (if, while, for, do, switch i return) umieszczamy spacje.
- Nie umieszczamy spacji przed nawiasami stosowanymi w wywołaniach funkcji.
- Umieszczamy spacje wokół wszystkich operatorów C i po przecinkach w wywołaniach funkcji.
- Nie używamy operatora przecinkowego do tworzenia wielu efektów ubocznych, z wyjątkiem części inicjujących i inkrementujących pętli for, oraz w ciałach makr.
- Do wcięć używamy prawdziwych tabulacji, nie spacji.
- Używamy rozmieszczenia nawiasów klamrowych w stylu"K&R".
- Używamy porównań z NULL i '\0' w warunkach instrukcji if, while i for oraz w przypadkach case instrukcji switch, zamiast zwykłego, jawnego wskaźnika czy wartości znakowej.
- Zamiast 1 i 0 stosujemy, gdzie jest to właściwe, stałe symboliczne TRUE, FALSE i NULL i stałą znakową '\0'.
- Każdą funkcję zaopatrujemy w jednowierszowy opisowy komentarz.
- Nie używamy `#elif'. Wiele starszych kompilatorów Unix C nie potrafi go obsłużyć.
- Do alokacji pamięci ze stosu nie stosujemy funkcji alloca. Korzystanie z niej powoduje więcej kłopotów z przenośnością niż daje niewielkich korzyści brak konieczności zwalniania przydziału pamięci. Zamiast tego, używamy malloc i free.
Jeśli będę musiał ponownie formatować twój kod, by dostosować go do stylu kodowania stosowanego w gawk, być może nie będzie mi się chciało.
Bądź przygotowany na podpisanie odpowiednich papierów. Aby FSF mogła rozprowadzać twoje zmiany, musisz albo zamieścić je jako public-domain i dostarczyć podpisane oświadczenie to stanowiące, albo przyznać prawa autorskie FSF. Obie te rzeczy łatwo wykonać i wiele osób już to zrobiło. Jeśli masz pytania, proszę skontaktuj się ze mną (zob. B.7. Zgłaszanie problemów i błędów) lub gnu@gnu.org.
Zaktualizuj dokumentację. Proszę, dostarcz razem ze swym nowym kodem nowe sekcje czy rozdziały do tej książki. Jeśli to możliwe, proszę użyj prawdziwego Texinfo zamiast dawać po prostu niesformatowany tekst ASCII (mimo to, nawet to jest lepsze niż brak dokumentacji w ogóle). Konwencje, jakie powinny być stosowane w Efektywne programowanie w AWK podano po `@bye' na końcu pliku źródłowego Texinfo. Jeśli to możliwe, proszę też zaktualizować stronę dokumentacji systemowej man. Będziesz także musiał podpisać odpowiednie papiery dotyczące zmian w dokumentacji.
Zmiany wysyłaj jako pliki różnic kontekstowych diff lub zunifikowane diff. Do porównania oryginalnego drzewa źródłowego gawk ze swoją wersją zastosuj `diff -c -r -N' lub `diff -u -r -N'. (Pliki różnic kontekstowych są dla mnie czytelniejsze, ale pliki w formacie zunifikowanym mają mniejsze rozmiary.) Polecam wykorzystywanie diff w wersji GNU. Dostarczając zmiany prześlij mi, proszę, wyjście utworzone przez któryś z podanych przebiegów diff. Zob. B.7. Zgłaszanie problemów i błędów, gdzie podano informacje o poczcie elektronicznej. Stosowanie tego formatu ułatwia mi nanoszenie twoich zmian na główną wersję kodu źródłowego gawk (za pomocą patch). Jeśli będę musiał nanosić zmiany ręcznie, korzystając z edytora tekstów, mogę tego nie zrobić, szczególnie jeśli to wiele zmian.
Do dostarczonej pracy dołącz wpis przeznaczony do umieszczenia w `ChangeLog'. Pomoże to później w minimalizacji ilości pracy, jaką muszę wykonać, ułatwiając mi zaakceptowanie poprawek.

Chociaż wygląda to na mnóstwo pracy, proszę pamiętaj, że choć ty sam piszesz nowy kod, ja muszę się nim opiekować i obsługiwać, a jeżeli nie będę mógł tego robić przy minimum dodatkowej pracy, to prawdopodobnie nie będę robił.

C.2.2. Przenoszenie `gawk` na nowy system operacyjny

Jeżeli chciałbyś przenieść gawk na nowy system operacyjny, to należy przestrzegać kilku zasad.

Przestrzegaj wskazówek z C.2.1. Dodawanie nowych możliwości, dotyczących stylu kodowania, dostarczania plików diff, i tak dalej.
Wykonując przeniesienie, pamiętaj, że twój kod musi zgodnie współżyć z resztą gawk i wersjami na inne platformy. Unikaj nieuzasadnionych zmian w częściach kodu niezależnych od systemu. Jeżeli jest to możliwe, unikaj rozsiewania `#ifdef'-ów tylko dla swojej wersji po całym kodzie. Jeżeli niezbędne dla danego systemu zmiany będą zbytnio wpływać na kod, prawdopodobnie ich nie zaakceptuję. W takim przypadku, będziesz mógł, oczywiście, rozpowszechniać zmiany na własną rękę, dopóki będziesz działać zgodnie z GPL (zob. 18. Powszechna Licencja Publiczna GNU).
Wieloma plikami dostarczanych z gawk opiekują się inni ludzie z Free Software Foundation. Nie powinieneś zatem ich zmieniać, chyba że masz bardzo mocne uzasadnienie. Tzn. zmiany nie są wykluczone, ale zmiany w tych plikach będą analizowane szczególnie uważnie. Plikami tymi są: `alloca.c', `getopt.h', `getopt.c', `getopt1.c', `regex.h', `regex.c', `dfa.h', `dfa.c', `install-sh' i `mkinstalldirs'.
Bądź gotów kontynuować opiekę nad swoim przeniesieniem. Nieuniksowe systemy operacyjne wspierane są przez ochotników, którzy pielęgnują kod potrzebny do kompilacji i uruchomienia gawk na ich systemach. Jeżeli żaden z ochotników nie opiekuje się wersją na daną platformę, przeniesienie takie staje się nieobsługiwane, i może być konieczne usunięcie go z dystrybucji.
Zapewnij odpowiedni plik `gawkmisc.???'. Każda z przeniesionych wersji posiada własny `gawkmisc.???', który implementuje pewne funkcje specyficzne dla danego systemu operacyjnego. Jest to przejrzystsze niż multum instrukcji `#ifdef' rozrzuconych po całym kodzie. `gawkmisc.c' w głównym katalogu źródłowym dołącza odpowiedni plik `gawkmisc.???' z każdego z podkatalogów. Upewnij się, że to także zaktualizowałeś. Plik `gawkmisc.???' każdej z przeniesionych wersji posiada przyrostek wskazujący odpowiednią nazwę maszyny czy systemu operacyjnego. Na przykład, `pc/gawkmisc.pc' i `vms/gawkmisc.vms'. Zastosowanie osobnych przyrostków, zamiast zwykłego `gawkmisc.c', umożliwia przesuwanie plików z podkatalogu danego systemu do głównego podkatalogu, bez ryzyka przypadkowego zniszczenia faktycznego pliku `gawkmisc.c'. (Obecnie dotyczy to tylko przenoszenia gawk na MS-DOS i OS/2.)
Dostarcz `Makefile' i ewentualne inne pliki źródłowe i nagłówkowe C, które są niezbędne dla twojego systemu operacyjnego. Całość twego kodu powinna być w osobnym podkatalogu, o nazwie takiej jak, lub przypominającej, nazwę systemu operacyjnego albo komputera. Jeżeli to możliwe, spróbuj zorganizować to tak, by nie było konieczne przesuwanie plików z podkatalogu do głównego katalogu źródłowego. Jeśli nie jest to możliwe, upewnij się, że nie używasz dla swoich plików nazw dublujących nazwy plików z głównego katalogu źródłowego.
Zaktualizuj dokumentację. Napisz, proszę, sekcję (czy sekcje) do tej książki opisującą etapy instalacji i konfiguracji potrzebne do zainstalowania i/lub skompilowania gawk w twoim systemie.
Bądź przygotowany na podpisanie odpowiednich papierów. Aby FSF mogła rozprowadzać twoje zmiany, musisz albo zamieścić je jako public-domain i dostarczyć podpisane oświadczenie to stanowiące, albo przyznać prawa autorskie FSF.

Przestrzeganie tych wskazań znacznie ułatwi zintegrowanie twoich zmian z gawk i umożliwi szczęśliwe współistnienie z kodem przeznaczonym do innych systemów operacyjnych, który już tu jest.

W kodzie, jaki dostarczasz i którym się opiekujesz, możesz swobodnie stosować taki styl kodowania i układ nawiasów klamrowych, jaki ci odpowiada.

C.3. Prawdopodobne przyszłe rozszerzenia

AWK jest językiem podobnym do PERLA, tylko znacznie bardziej eleganckim.
Arnold Robbins

Hey!
Larry Wall

W tej sekcji wymieniono pokrótce rozszerzenia i możliwe usprawnienia, wskazujące kierunki rozwoju gawk, jakie obecnie rozważamy. Plik `FUTURES' w pakietach dystrybucyjnych gawk również podaje te rozszerzenia.

Oto zestawienie prawdopodobnych przyszłych zmian do użytku programujących w języku awk.

Lokalizacja: Projekt GNU zaczyna obsługiwanie wielu języków. Możliwe będzie co najmniej wypisywanie przez gawk ostrzeżeń i komunikatów o błędach w językach innych niż angielski. Możliwe, że, prócz samego gawk, programy awk będą mogły korzystać ze programów wspomagających z obsługą wielu języków.
Bazy danych: Być może możliwe będzie odwzorowywanie pliku GDBM/NDBM/SDBM na tablicę awk.
Tablica PROCINFO: Pliki specjalne, zapewniające dostęp do informacji dotyczących procesu (zob. 6.7. Specjalne nazwy plików w gawk) zostaną zastąpione tablicą PROCINFO, która dostarczy tych samych danych, w sposób łatwiejszy w dostępie.
Więcej ostrzeżeń lint: Istnieje więcej rzeczy, które mogłyby być sprawdzane z uwagi na przenośność.
Kontrola nad środowiskiem podprocesu: Zmiany poczynione w gawk w tablicy ENVIRON mogą przenosić się na procesy uruchamiane przez gawk.

Oto lista prawdopodobnych ulepszeń, które spowodują, że gawk będzie miał lepszą wydajność.

Udoskonalona wersja dfa: Dopasowywacz wzorców dfa z programu GNU grep na pewne problemy. Nowa lub poprawiona wersja będzie sobie radzić z niektórymi ważnymi kwestiami dotyczącymi dopasowywania wyrażeń regularnych.
Wykorzystanie GNU malloc: malloc w wersji GNU może potencjalnie przyspieszyć gawk, gdyż w dużym stopniu opiera się na stosowaniu dynamicznej alokacji pamięci.

C.4. Sugestie usprawnień

Oto kilka projektów, jakie być może zechcą podjąć przyszli hakerzy gawk. Wielkość projektów waha się od kilku dni do kilku tygodni programowania, w zależności od tego, który wybierzesz i jak szybkim jesteś programistą. Wszystkie napisane ulepszenia proszę przesyłać do opiekunów w projekcie GNU. Zob. C.2.1. Dodawanie nowych możliwości, gdzie zamieszczono wytyczne, jakich należy przestrzegać dodając nowe możliwości do gawk. Zob. B.7. Zgłaszanie problemów i błędów, gdzie podano informacje o kontaktowaniu się z opiekunami gawk.

Kompilacja programów awk: gawk do konwersji podanego skryptu na drzewo składni wykorzystuje analizator składni Bison (podobny do YACC). Następnie drzewo składniowe wykonywane jest przez prosty rekurencyjny ewaluator. Odbywa to się sporym kosztem, gdyż ewaluator wykonuje wiele wywołań procedur do zrobienia nawet najprostszych rzeczy. Powinno być możliwe, by gawk przekształcał drzewo składniowe skryptu w program C, który użytkownik mógłby następnie skompilować, korzystając ze zwykłego kompilatora C i specjalnej biblioteki gawk, dostarczającej wszystkich niezbędnych funkcji (wyrażenia regularne, pola, tablice asocjacyjne, koercja typów, i tak dalej). Łatwiejszą możliwością może być faza pośrednia awk, konwersji drzewa składniowego na postać liniowego kodu bajtowego jak to jest w GNU Emacs Lisp. Ewaluator rekurencyjny można by wówczas zastąpić zwykłym interpreterem kodu bajtowego, co byłoby wypośrodkowane szybkością między uruchamianiem skompilowanego programu a robieniem tego, co gawk robi obecnie.
Programy z zestawu testowego mogłyby korzystać ze sposobu dokumentacji z tej książki.
Więcej pomysłów można znaleźć w pliku `FUTURES'. Skontaktuj się z nami jeśli chciałbyś poważnie zmierzyć się z którymś z wymienionych tu zadań.