Jak naprawić GRUB-a

Jeśli oprócz systemu okienkowego rodem z Microsoftu mamy też jakiegoś *niksa, to reinstalacja Windows będzie dla nas miała jeden nieprzyjemny efekt uboczny. Otóż instalatory Okienek radośnie nadpisują sektor startowy dysku (czyli MBR – Master Boot Sector), przez co Windows staje się jedynym systemem dającym się uruchomić w zwykły sposób. Ot, zwyczajowe MS-owe praktyki monopolistyczne ;-)

Jak temu zaradzić? Trzeba oczywiście przywrócić boot sector do właściwego stanu, co oznacza ponowne zainstalowanie używanego przez nas wcześniej bootloadera. W większości przypadków (jeśli mówimy o Linuksie jako drugim systemie) jest nim GRUB; w takim wypadku jego ponowne zainstalowanie wymaga:

1. Uruchomienia Linuksa przy użyciu płytki typu LiveCD, dystrybucji uruchamianej z pendrive‘a, itp. Graficzny interfejs jest niepotrzebny, bo jak to zwykle w Linuksie, wszystko można zrobić z konsoli.
2. Następnie należy uruchomić GRUB-a – koniecznie z prawami roota, a więc np. poprzez sudo grub.
3. Z poziomu jego wiersza poleceń należy najpierw ustawić partycję, w której znajdują się pliki z danymi bootloadera. Jeśli nie wiemy, która to, najlepiej użyć polecenia find /boot/grub/stage1. Potem rezultat przekazujemy do komendy root, np. root (hd0,5).
4. Na koniec komendą setup instalujemy GRUB-a na wybranym dysku fizycznym – zazwyczaj jest to setup (hd0).

Tyle powinno wystarczyć, by po ponownym uruchomieniu komputera z tego dysku pojawiło się nam menu bootowania GRUB-a. Przy odrobinie szczęścia oba systemy będą więc uruchamiały się normalnie ;)

Lepszy pasek przewijania

Zorientowanie się w dużym pliku z kodem (gdzie przez ‘duży’ rozumiem przynajmniej taki, który przekracza tysiąc linii) może niekiedy przysparzać kłopotów. W IDE są oczywiście narzędzia nawigacyjne, pozwalające na przejście do poszczególnych klas, metod czy deklaracji, o ile tylko znamy chociaż ich nazwy. Nie zawsze jednak tak jest. Jeśli o danej metodzie pamiętamy tylko to, że “była długa i skomplikowana”, a o jakiejś właściwości jedynie tyle, iż “jest gdzieś wśród parunastu innych deklaracji”, to najpewniej oznacza, że w ich poszukiwaniu będziemy musieli przeglądnąć cały plik od początku do końca.
Chyba że… No właśnie – chyba że dałoby się spojrzeć na kod z daleka, by zobaczyć jego ogólną strukturę. Wiadomo bowiem, że metoda “długa i skomplikowana” będzie miała najpewniej sporą ilość wcięć, a długi ciąg deklaracji, jedna pod drugą, też były łatwy do odróżnienia od innych kawałków kodu. W książce o wiele mówiącej nazwie Czytanie kodu znalazłem kiedyś radę, że do uzyskania takiego ogólnego spojrzenia można wykorzystać edytor tekstu typu Word, pozwalający na podgląd wydruku wielu stron naraz.

O wiele wygodniej byłoby jednak mieć podobną możliwość wprost w IDE. NetBeans posiada namiastkę czegoś takiego, jednak za jej pomocą można tylko szybko stwierdzić, gdzie w kodzie znajdują się błędy kompilacji (pisałem zresztą o tym trochę ponad rok temu). Porządną, wielkoskalową, a w dodatku całkiem funkcjonalną “mapę kodu” da się za to znaleźć w… Visual Studio.
Mówię tu o darmowym pluginie o nazwie RockScroll, będącym zresztą początkowo wewnętrznym narzędziem Microsoftu. Tym, co wtyczka ta robi, jest zastąpienie standardowego pionowego paska przewijania przez szerszy pionowy pasek, pokazujący podgląd aktualnie edytowanego w postaci długiej “miniaturki” z kolorowaną składnią. RockScroll działa przy tym podobnie jak zwyczajny pasek przewijania, a więc pozwala na przejście kliknięciem do wybranego miejsca w pliku. Ponadto potrafi też zaznaczać breakpointy oraz koloruje wszystkie wystąpienia wskazanego (dwukrotnie klikniętego) słowa w danym pliku – całkiem przydatne. Jedynym mankamentem jest chyba tylko brak wsparcia dla zwijanych i rozwijanych regionów kodu oraz ewentualnie fakt, że w poziomie plugin zajmuje jakieś cztery razy więcej miejsca niż standardowy pasek przewijania. Na szerokoekranowych monitorach ciężko jednak uznać to za wadę :)

Podłączanie debugera VS do procesu

Kiedy piszemy aplikację będącą już w na tyle zaawansowanym stadium, że nie objawia ona błędów przy pierwszym lepszym uruchomieniu, to zdarza się, iż uruchamiamy ją bez wsparcia debugera (co można zrobić standardowym skrótem klawiszowym Ctrl+F5 w Visual Studio). Mimo tego zawsze może się jednak zdarzyć jakiś nieprzewidziany wyjątek, błąd czy inna nieprawidłowość. Ba, może się tak zdarzyć w programie, który już dawno uznaliśmy za skończony!
Co wtedy? Przecież warunki powstania błędu mogą być trudne i pracochłonne do odtworzenia, jeślibyśmy uruchomili program ponownie – już w trybie debugowania. Nierzadko zresztą po takiej próbie błąd nagle w “magiczny” sposób zniknie, bo okaże się, że albo coś przeoczyliśmy, albo dany bug zależy od jakichś nieznanych jeszcze okoliczności, albo że całkiem niedeterministyczny (heisenbug).

Dlatego też lepiej posłużyć się już tą instancją programu, w której problem wystąpił, i przy jej pomocy poszukać błędu. W tym celu można użyć przydatnej opcji Visual Studio, pozwalającej na przyłączenie debugera do działającego procesu i dostępnej poprzez menu Debug > Attach to Process. Tam możemy wybrać po prostu naszą aplikację z listy działających procesów.
Jakie możliwości nam to daje? To zależy od tego, czy w pliku wykonywalnym docelowej aplikacji znajdują się odpowiednie symbole debugowe . W najlepszym wypadku będziemy mogli śledzić kod programu tak samo, jak przy uruchamianiu go z asystą debugera od samego początku (o ile, rzecz jasna, wcześniej otworzymy projekt, z którego kompilowaliśmy nasz program). Jeśli zaś nie dysponujemy źródłem aplikacji lub docelowy plik .exe nie posiada żadnych symboli debugowych, to oczywiście nadal możemy wykonywać działania typowe dla każdego debugera – jak krokowe wykonywanie instrukcji maszynowych czy ustawianie breakpointów na konkretnych adresach w pamięci.

Podwójne skróty klawiszowe w VS

W takiej dużej aplikacji jak IDE ilość opcji jest na tyle spora, że część z nich pochowana jest głęboko w czeluściach wielopoziomowego menu. Często nie znaczy to jednak, że są one mniej przydatne; na pewno jednak są trudniej dostępne. Dodatkowo też ilość klawiszy na klawiaturze jest ograniczona, więc nie wszystkie opcje mogą mieć przypisane skróty klawiszowe… Chyba że zastosuje się jakieś sztuczkę :)

W vimie i jego pochodnych taką sztuczką były polecenia wpisywane od dwukropka (na czele z najbardziej przydatnym, czyli :q! ;]). W Visual Studio mamy za to podwójne skróty klawiszowe, (chords) dzięki którym możemy z palca wywołać nie tylko, powiedzmy, polecenie otwarcia pliku, ale też pewne rzadziej używane narzędzia – które paradoksalnie bywają o wiele przydatniejsze.
Jak to działa? Otóż bardzo prosto: po wciśnięciu specjalnej kombinacji ‘aktywującej’ (np. Ctrl + K) nic się wprawdzie nie dzieje, ale aplikacji przełącza się w tryb pozwalający na wykrycie drugiej kombinacji (np. Ctrl + C), która odpowiada już konkretnej akcji. Całość można więc zapisać jako Ctrl + K,C; oznacza to po prostu: wciśnij i przytrzymaj Ctrl, a potem naciśnij kolejno K i C. Nic specjalnie trudnego, prawda? :)

A jakież to wspaniałe opcje IDE są dostępne w ten sposób? Ano jest ich całkiem sporo, spośród których wylistuję kilka:

1. Komentowanie kodu. Tak tak, nie trzeba już ręcznie wstawiać /* */ czy #if 0/#endif, żeby wyłączyć jakiś kawałek kodu z kompilacji :) Mamy bowiem takie oto skróty:
   • Ctrl + K,C – komentuje (w stylu C++) każdą linijkę zaznaczonego fragmentu
   • Ctrl + K,U – odkomentowuje zaznaczony fragment (usuwa // z początku każdej linijki)
2. Edycja kodu:
   • Ctrl + K,X – pozwala na wstawienie predefiniowanych wzorców (snippets) różnych konstrukcji językowych (np. pętli for), pozwalając przy tym na łatwą zmianę ich szczegółów (np. nazwy zmiennej będącej licznikiem pętli).
   • Ctrl + K,S – pozwala otoczyć zaznaczony fragment kodu jakimś nazwanym blokiem, np. try-catch, if, itd.
3. (Ro)zwijanie bloków. W VS bloki kodu mogą być rozwijane lub ukrywane poprzez klikanie w mały plusik z lewej strony ich pierwszego wiersza. Opcja ta nazywa się outlining lub folding i można ją kontrolować m.in. przy pomocy poniższych skrótów:
   • Ctrl + M,O – zwija wszystkie bloki tak, że widoczne są tylko nagłówki definicji funkcji i metod
   • Ctrl + M,L – (ro)zwija wszystkie bloki
   • Ctrl + M,P – wyłącza automatyczny outlining całkowicie
4. Zmiana sposobu przeglądania kodu:
   • Ctrl + R,W – w(y)łącza wyświetlanie białych znaków (spacji jako kropek, tabulatorów jako strzałek, itd.)
   • Ctrl + E,W – w(y)łącza zawijanie wierszy

Polecam przynajmniej jednokrotne spróbowanie każdej z powyższych opcji. Możliwe, że w ten sposób odkryjecie coś, czego brakowało wam przez cały czas :) Nie jest to też kompletna lista – więcej skrótów/opcji można znaleźć przeglądając menu Edit.

Nowsze solucje w starym VS

Visual Studio 2008 zasadniczo służy do pracy z .NET Framework w wersji 3.5, ale ma tę przyjemną cechę, że pozwala określić używaną przez projekt wersję frameworka. A to oznacza, że można zdecydować się na wersję 2.0, co pozwala na współpracę także z edycją 2005.

Pewnym problemem pozostaje jednak fakt, że próba załadowania w Visual Studio 2005 solucji stworzonej w edycji 2008 kończy się takim oto uroczym komunikatem:

Co z tym zrobić?… Można oczywiście utworzyć nową, pustą solucję, a potem dołączyć do niej projekty z tej oryginalnej. To dość kłopotliwe, a VS wymaga też, aby solucje tworzyć zawsze w pustym lub nieistniejącym katalogu. Ostatecznie musielibyśmy więc przekopiować ją wpierw w docelowe miejsce, a potem zająć się przyłączaniem doń naszych projektów. Warto też zauważyć, że stworzenie zupełnie nowej solucji oznacza utratę wszelkich niestandardowych konfiguracji budowania projektów; w gruncie rzeczy bowiem właśnie te konfiguracje to – poza samą listą projektów – jedyna istotna rzecz przechowywana w pliku .sln.
Na szczęście jednak ów plik jest zwykłym plikiem tekstowym, którego format tak naprawdę nie zmienił się od dawna (jak sądzę co najmniej od wersji 2001). Dlatego całkiem prawdopodobne jest to, że jedyną przeszkodą przy wczytywaniu nowej solucji w starszym VS jest… numer wersji zapisany w pierwszym wierszu pliku:

Microsoft Visual Studio Solution File, Format Version 10.00

Nie zaszkodzi więc zmienić owe 10.00 (VS 2008) na 9.00 (VS 2005) i ponownie spróbować otworzyć solucję. Jeśli próba się powiedzie, oszczędzimy sobie pracochłonnego kombinowania. A jeśli nie… to pewnie warto pomyśleć o upgrade ;]

Kopiuj-i-wklej kod

Gdy znajdziemy w sieci kawałek kodu, który chcemy przeanalizować, to nie zawsze jest on ładnie sformatowany czy pokolorowany. Wtedy możemy sobie pomóc, wklejając rzeczony kod do naszego środowiska programistycznego; w większości znajdzie się opcja pozwalająca np. wyrównać wcięcia (w Visual Studio jest to Edit | Advanced | Format Selection), że o kolorowaniu nie wspomnę ;]

O powyższym wiedzą pewnie wszyscy. Jednak czasami kopiujemy też kod w drugą stronę, z IDE. Jeśli korzystamy z Visual Studio, to możemy wykorzystać przy okazji fakt, że jest on kopiowany jako… tekst formatowany typu RTF.
Na pierwszy rzut oka może to wydawać się co najmniej dziwne. Przecież kod z założenia jest zwykłym tekstem, więc po co dodatkowe informacje o czcionkach czy wyglądzie znaków?… Otóż odpowiedź jest bardzo prosta: w ten sposób zachowana jest bowiem informacja o kolorowaniu składni. Jeśli teraz wkleimy nasz kod do dowolnego edytora tekstu formatowanego (czyli od WordPada wzwyż), to zobaczymy z słowami kluczowymi i innymi elementami zakolorowanych dokładnie w ten sam sposób, jak w środowisku programistycznym.

Do szczęścia brakowało by pewnie jest możliwości szybkiej konwersji takiego kodu do formatu HTML… ale cóż, nie można mieć wszystkiego ;-)

Find & Replace i wyrażenia regularne

Przy wyszukiwaniu czegoś w kodzie czasami przydają się wyrażenia regularne. Pozwalają one na znajdowanie nie tyle dokładnie określonych ciągów znaków, ale ciągów pasujących do określonego wzorca. Przy odrobinie wprawy można na przykład wyszukać wszystkie deklaracje zmiennych danego typu, wszystkie wywołania funkcji przeciążonej wyłącznie w wersji z trzema parametrami, i tak dalej.

Zwykle takich rzeczy szukamy jednak nie dla samego znajdowania, lecz po to, aby je potem zmodyfikować. Czasem można to zrobić ręcznie, ale jeśli oznacza to konieczność wykonania tych samych poprawek kilkanaście czy kilkadziesiąt razy, to szybko może nam to się znudzić. Pamiętajmy zresztą, że każdy programista dysponuje tylko skończonym czasem przeznaczonym na kodowanie :)
Wtedy może przydać się zastosowanie wyrażeń regularnych nie tylko do wyszukiwania (find), ale też do zastępowania (replace). Każde porządne IDE powinno bowiem oferować możliwość dopasowywania podwyrażeń (subexpressions lub tagged expressions) w znajdowanym ciągu. Nie inaczej jest w Visual Studio.

Załóżmy przykładowo, że piszemy w C++ i mamy klasę działającą jak abstrakcyjny interfejs (wszystkie metody czysto wirtualne) i chcemy go zaimplementować. Kopiujemy więc całą definicję klasy i chcielibyśmy teraz zmienić deklaracje jej metod: ze wszystkich usunąć słówko 'virtual' i frazę '= 0'.
Jak to zrobić? Dość łatwo skonstruować wyrażenie regularne, które wyszuka nam wszystkie deklaracje:

Co jednak z polem Replace with? Tam chcielibyśmy wstawić wszystkie te znaki, które dopasują się do wyrażenia .*. W tym celu powinniśmy wpierw zmienić tę frazę na tagged expression, otaczając ją nawiasami klamrowymi:

Teraz stało się ono podwyrażeniem i możemy odwołać się do dopasowanych do niego znaków poprzez sekwencję \1. Zatem jako wyrażenie docelowe wstawimy po prostu:

Jak nietrudno się domyślić, podwyrażeń może być więcej; możemy wtedy odwoływać się do nich za pomocą kolejnych numerków: \2, \3, itd. (są one numerowane oczywiście od lewej). Dodatkowo symbol \0 odpowiada za cały znaleziony ciąg.
Widać więc, że przy użyciu tego mechanizmu można automatycznie dokonywać zmian, które bez niego zajęłyby nam dużo czasu i były dość żmudne.