Linuxy 1...2...3

SromotnikJadowity

Administrator

Dołączył: 2015-06-07

Liczba postów: 11

Kolos I

Debugger modyfikuje kod źródłowy programu
- FAŁSZ – nie modyfikuje tylko sprawdza
Scentralizowane systemy zarządzania wersjami (np. Subversion) oparte są na architekturze P2P
- FAŁSZ – bo na klient-server / server-klient
Refactoring powoduje modyfikacje w funkcjonalności programu
- FAŁSZ – tylko eliminuje powtarzające się linijki, funkcjonalność ta sama
W systemie Subversion w wyniku wysłania nowej wersji określonego pliku do repozytorium całe repozytorium
uzyskuje nowy numer rewizji
- PRAWDA - numer rewizji oznacza numer kolejnego wykonania Commita

W kodzie występuje przynajmniej jeden błąd kompilacji
- PRAWDA - powinno być

int [] tab

Błąd występujący w kodzie może ujawnić się w trakcie wykonania programu
-PRAWDA - Wyciek pamięci ZAWSZE może ujawnić się w trakcie działania programu. Np. Gdy zabraknie Ci w
końcu RAM.

Wycieki pamięci powstają w wyniku alokowania przez program zbyt małej ilości pamięci
- FAŁSZ - fałsz bo wycieki powstają kiedy nie zwalniamy pamięci
Nowy programista, który dołącza do projektu przechowywanego w repozytorium zarządzanym przez system
Subversion powinien znać adres url repozytorium
- PRAWDA - jezeli nie zna to nie polaczy sie z nim
Dostęp do repozytorium zarządzanego przez Subversion nie jest możliwy z wykorzystaniem protokołu ftp
- FAŁSZ - dostęp do repozytorium jest tylko przez http i ssh
Generowanie dokumentacji technicznej projektu za pomocą Javadoc polega na przetworzeniu specjalnych komentarzy
umieszczonych w kodzie Java na strony www
- PRAWDA - Wykorzystuje się do tego adnotacje w komentarzach
Scentralizowane systemy zarządzania wersjami (np. Subversion) oparte są na architekturze klient-server
- PRAWDA - bo po prostu są oparte ;D
TortoiseSVN jest tekstowym klientem systemu Subversion
- FAŁSZ - bo jest graficzną nakładką
Wycieki pamięci są automatycznie naprawiane przez Valgrind
- FAŁSZ - Valgrind tylko wskaże nam wyciek
Repozytorium kodu źródłowego zarządzane przez system Subversion powinno zawierać zgodnie z zaleceniami katalog
trunk przechowujący alternatywne gałęzie projektu
- FAŁSZ - przechowuje tylko wersję roboczą
Breakpoint w debugger’e oznacza miejsce rozpoczęcia wykonywania programu
- FAŁSZ - nie rozpoczęcia tylko zakończenia przebiegu
Klient Subversion może być oferowany przez środowisko programistyczne IDE
- PRAWDA - jak najbardziej, NetBeans oferuje
W systemie Git klonowanie zdalnego repozytorium powoduje powstanie pełnej kopi repozytorium na lokalnej
maszynie
- PRAWDA - no tak
Repozytorium kodu źródłowego zarządzane przez system Subversion powinno zawierać zgodnie z zaleceniami katalog
BRANCHES przechowujący główną linię rozwojową kodu źródłowego projektu
- FAŁSZ - Katalog branches jest na poboczne gałęzie projektu
Przykładem refectoringu kodu jest dodanie nowej metody (nowej funkcjonalności) do istniejącej klasy
- FALSZ - nie tworzy nowej funkcjonalności tylko minimalizuje powtarzające się
Sprawdzenie zawartości repozytorium zarzadzanego przez Subversion jest możliwe bez konieczności tworzenia lokalnej
kopi repozytorium
- PRAWDA - tak, przez protokól SSH lub HTTP
W systemie Git operacj push służy do wysłania lokalnych zmian do zdalnej kopi repozytorium
- PRAWDA - tak sie dzieje dokładnie
Błąd występujący w kodzie zostanie wykryty przez Dr Memory
- FAŁSZ - Program się nie skompiluje, wiec nie zostanie utworzony plik wykonywalny (a Dr Memory sprawdza pliki
wykonywalne)
Refaktoring powoduje zmiany w kodzie źródłowym oprogramowania
- PRAWDA - minimalizuje powtarzające się
Historia zmian w Subversion dostarcza informacji na temat kto wprowadzał zmiany w danej rewizji
- PRAWDA - można sprwdzić to w logach
Sprawdzenie zawartości repozytorium zarzadzanego przez Subversion nie jest możliwe bez konieczności tworzenia
lokalnej kopi repozytorium
- FAŁSZ - bo jest możliwe przez protokół SSH lub HTTP
Nowy programista, który dołącza do projektu przechowywanego w repozytorium zarządzanym przez system
Subversion może obejrzeć zawartość repozytorim w przeglądarce internetowej jeżeli dostęp do repozytorium
odbywa się poprzez protokół http
- PRAWDA - przez protokół HTTP
Przykładem refectoringu kodu jest zastąpienie podobnych albo takich samych fragmentów kodu przez procedurę
- PRAWDA - dokładnie tak to działa
Wycieki pamięci zostaną wykryte podczas kompilacji kodu za pomocą kompilatora, np. g++
- FAŁSZ - kompilator nie wykrywa co innego gdyby odpalić valgrind –leak
Konflikt w systemie Subversion może powstać podczas wykonywania komendy checkout
- FAŁSZ - pobiera aktualna wersja wiec chyba bez konfliktu, konflikt może być przy commit jeżeli ktoś już
wcześniej zatwierdzi zanim Ty to zrobisz
Dostęp do repozytorium zarządzanego przez Subversion może odbywać się przez protokół http
- PRAWDA – i przez SSH też
W systemie Git operacja COMMIT przenosi zmiany z kopi lokalnej do zdalnego repozytorium
- PRAWDA - po to jest właśnie by przenieść dane do zdalnego repozytorium komp -> repozyrotium
Analiza programu za pomocą Dr Memory nie wymaga wcześniejszej kompilacji kodu
- FAŁSZ - Dr Memory sprwadza pliki wykonawalne, wiec musi wczesniej byc skompilowany
Valgrind nie zasygnalizuje czytania poza zakresem statycznie alokowanej tablicy
- PRAWDA - wg wykładu "valgrind nie wykrwya błędów związanych ze statycznie alokowanymi obszarami
pamięci"
Jedną z możliwości debugger'a GDB jest wyświetlenie aktualnego stosu wywołań funkcji
- PRAWDA - pozwala na to komendą -bt
Środowisko wytwórcze Eclipse jest środowiskiem modułowym, rozszerzalnym poprzez plugin'y
- PRAWDA - mozna rozszerzac instalując dodatkowe pluginy
Debugger jest standardowym wyposażeniem większości środowisk programistycznych
- PRAWDA - większośc środowisk go posiada
Polecenie diff w systemie Subversion pozwala na porównanie kopi lokalnej i kopi znajdującej się w repozytorium
określonego pliku
- PRAWDA - tak to działa
TortoiseSVN jest graficznym klientem systemu Git
- FAŁSZ - TortoiseSVN jest gaficznym klientem SVN a nie GIT
Debugger może zostać uruchomiony mimo istnienia błędów kompilacji
- PRAWDA - po to jest
Operacja commit w systemie Subversion przenosi zmiany z repozytorium zdalnego do lokalnej kopi użytkownika
- FAŁSZ – przenosi z lokalnej do repo, komp -> repo a nie odwrotnie, do tego służy update lub /co/
Historia zmian w Subversion dostarcza informacji na temat plików zmodyfikowanych w poszczególnych rewizjach
- PRAWDA - TAK w logach
Historia zmian w Subversion dostarcza informacji na temat używanego przez użytkownika klienta SVN
- FAŁSZ - nie umieszcza takiej informacji, umieszcza jedynie datę, komentarz i co zostało zmodyfikowane

svnadmin create repo - tworzy repozytorium

svn mkdir trunk branches tags – tworzy 3 katalogi, sa niezbędne !

svn ci -m "blabla" – wystawia komentarz do potwierdzenia akcji

svn list – wyswietla zawartość repozytorium

svn co <ścieżka> - sprawdzasz zawartośc repozytorium i aktualizujesz na swoim kompie

svn update – zaktualizowanie projektu na kompie przez najnowsza wersje z repozytorium, można wskazać konkretny
numer rewizji(-r revision czyli wersji) która chcemy pobrać

System GIT - rozproszone repozytorium, każdy ma pełną kopię repozytorium, KAŻDY może być centralnym serwerem
git commit -m "Dodano" - potwierdź ale na swoim kompie
git push origin master - aktualizuj na serverze
r run - wypisanie linii do wystapienia pierwszego bledu (jego objaw)
l list - kontekst linii na której się zatrzymał
bt - stos wywołań do czasu wystapienia błędu
q - opuszczenie debuggera GDB
g++ -g toupper.cpp -o toupper – kompilacja z debuggerem