TinTin++, skrypty do arkadii v.1.0

[Ralandil]

W zaproponowanym przeze mnie macra alt/ctrl+num(1-9) działają.

[Torn]

Jako, że wyszła nowa wersja tt++ postanowiłem pobrać kod i samemu go skompilować. Jest to dla mnie pierwszy raz i pomyślałem, że zapytam o pewne kwestie.
1. W pliku "makefile" nie widzę reguły uninstall. Jak w takim razie będę mógł usunąć program?
2. Czytałem trochę o CFLAGS i CXXFLAGS. Czy optymalizacja kodu w tym przypadku daje jakieś odczuwalne efekty? Jeśli tak, to czy trzeba skompilować w taki sposób również zależności tt++?

[Ralandil]

1) Bardzo łatwo prześledzić można co się zainstaluje poleceniem

Kod: Zaznacz cały

make DESTDIR=/tmp/tt install

Polecam utworzyć sobie z powyższego katalogu paczkę, korzystając z narzędzi odpowiednich dla danej dystrybucji. Późniejsza jej instalacja/usunięcie pozwoli w wygodny sposób zachować porządek.

W ostateczności można usunąć ręcznie, w tym przypadku to tylko jeden plik.

2) Moim zdaniem tak, chociaż bardziej odczuwalne jest to na starszych procesorach. Zawsze lepiej uszyć garnitur na miarę niż kupić gotowy w sklepie. Kompilacja emulatora/konsoli w której ma działać TinTin wydaje się dobrym pomysłem.

Większą uwagę przykułbym jednak do posiadanych skryptów, jedna nierozsądna konstrukcja może wszystko zaprzepaścić. Poza tym warto pomyśleć o wpływie na muda, żeby jednak nie oceniać wszystkich osób na lokacji albo nie spamować kondycji, pomimo że zakodowano opcje jej wyświetlania.

[Torn]

Zatem spróbuję zrobić paczkę z kodu, chociażby polecanym checkinstallem.
Druga sprawa jest trudniejsza. Mam stary procek pentium4 640 prescott z rodziny 2m niby 64 bit ale system Lubuntu x86. W manualach nie jest jednoznacznie wyjaśnione czy w takim wypadku brać flage -march "prescott" czy "nocona". Następna sprawa to miejsce wpisania/nadpisania tych flag. Muszę jeszcze dużo o tym poczytać.
Dziękuję za szybką, inspirującą odpowiedź.

[Werbat]

Skoro masz system 32bit, to jak chcesz obsłużyć aplikacje 64? Bierz prescott.

[Torn]

Dzięki Werbacie za rozwianie moich wątpliwości. Udało mi się jakoś skompilować ten kod. Wszystko działa dość sprawnie a odczyty z #info cpu w tt++ są podobne do tych z wersji paczkowych. Zastanawiam się tylko czy nastąpiła jakakolwiek optymalizacja? Do ./configure dodałem:

Kod: Zaznacz cały

./configure CFLAGS='-march=prescott -O2 -pipe -fomit-frame-pointer' CXXFLAGS='-march=prescott -O2 -pipe -fomit-frame-pointer'

W utworzonym pliku config.log mam wpisy z powyższymi danymi takie jak:

Kod: Zaznacz cały

## Core tests. ##
wiele takich: configure:2555: gcc -march=prescott -O2 -pipe -fomit-frame-pointer   conftest.c  >&5
## Cache variables. ##
ac_cv_env_CFLAGS_value='-march=prescott -O2 -pipe -fomit-frame-pointer'
## Output variables. ##
CFLAGS='-march=prescott -O2 -pipe -fomit-frame-pointer'

Zastanawia mnie też opcja -march=native. Komenda:

Kod: Zaznacz cały

echo | gcc -### -E - -march=native 

pokazuje wiele flag, które obsługuje mój procek(spr. cat /proc/cpuinfo) i zastanawiam się czy nie jest to lepsza alternatywa dla -march=prescott... Czytam te manuale i naprawde ciekawych rzeczy można się dowiedzieć.
Edit:
Właśnie doczytałem, że -march=native chyba jednak wskazuje mój procek jako "nocona" ...

Kod: Zaznacz cały

COLLECT_GCC_OPTIONS='-E' '-march=native'
 /usr/lib/gcc/i686-linux-gnu/4.8/cc1 -E -quiet -imultiarch i386-linux-gnu - "-march=nocona" -mcx16 -mno-sahf -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt --param "l1-cache-size=16" --param "l1-cache-line-size=64" --param "l2-cache-size=2048" "-mtune=nocona" -fstack-protector -Wformat -Wformat-security

[Werbat]

Ja Ci powiem tak: przez pięć lat używałem na desktopie Gentoo, dystrybucji takiej, że wszystko na niej się kompilowało samemu. Też miałem hopla na punkcie optymalizacji, też na p4. Tyle, że to jest zysk wydajności rzędu, powiedzmy, trzeciego miejsca po przecinku. Tak naprawdę absolutnie niezauważalne, zwłaszcza przy małych programikach. Owszem, jak kompilowałem takie OpenOffice, kobyłę, to zamiat 15 sekund uruchamiała się 7, jakieś 2 sekundy szybciej uruchamiał mi się też samodzielnie skompilowany Firefox, ale wszystko inne - zupełnie nie widać różnicy.

Ale jak koniecznie chcesz, skompiluj sobie z prescott, odpal, poużywaj, zmierz (hint: komenda time Twoim przyjacielem), potem tak samo z noconą i porównaj wyniki.

[Torn]

Faktycznie, mam pewne skrzywienie na punkcie skrajnej optymalizacji. Lubię totalny minimalizm, brak wodotrysków itp. W tym wypadku chciałem zrobić swoją pierwszą kompilację w miarę dobrze. Myślę, że nie jest źle. Po załadowaniu tych samych skryptów, włączeniu mappera użycie procka wydaje się być jakieś 0.10-0.15% niższe, szybciej też spada w czasie bezczynności. Złapię trochę wprawy to zabiorę się za opt. Urxvt a jak będzie mnie męczyło to wsadzę w blaszaka jeszcze starszego prescotta i porównam.
Na poważnie, kiedyś czytałem jak komuś mocny pc nie wyrobił przy skrypcie, którego używam i od tej pory zachowuję się w tym temacie jak ofiara incepcji.

[Torn]

Może ktoś z użytkowników TT++ spotkał się z podobnym problemem. Chciałbym zrobić #action, gdzie sprawdzany jest tekst do pierwszej kropki. Coś w stylu "#action {^%*.$}", ale mielące tylko pierwsze zdanie w akapicie. Zakres znakow "A-Z, a-z" oraz ",". Myślałem nad konstrukcją znak{liczba występowania}, ale to zły trop.

[Dorien]

hej, nie mam teraz tintina przy sobie, ale wykorzystanie action do tego jest moim zdaniem mega zlym pomyslem. (taki action zamuli ci calego tt imho)
zamiast tego uzyj

Kod: Zaznacz cały

#EVENT {RECEIVED LINE} 

a potem przy uzyciu #rexexp wyciagnij text do kropki.
cos w stylu:

Kod: Zaznacz cały

#var text %0;
#rexexp {$text} {^{.*}.} {#var {pierwsze_zdanie} {&1}};

ale nie wiem poprobuj cos w tym kierunku bardziej moim zdaniem
D.