Pan Sebastian Biały napisał:

>>> Można więc zrobic lepiej: poszukać procesu, zapamiętać pida, odpalić
>>> nowy, zamknąć stary.
>> I to ma być lepiej?!
>
> Zdefiniuj najpier kryterium "lepiej". IMHO w zastosowaniu o jakim tu
> rozmawiamy lepiej oznacza prościej. Prościej się chyba nie da.

"Lepiej" się nie definiuje, wystarczy definicja "gorzej" i wiadomość,
że są to rzeczy przeciwstawne. W tym przypadku prościej, to jest na
przykład wysłanie procesu SIGUSR1. W tej chwili wszystkie przeglądarki
PDF, PS albo DVI poszły jeszcze dalej -- same śledzą, czy oglądany plik
się zmienił, a jeśli tak, to go przeładowują. Owszem, kiedyś tak się
pracowało, że się "odpalało nowy viewer i zamykało stary". Ale skoro
teraz można jeszcze lepiej i prościej, to czemu nie?

>>> Jesli oprogramowanie pracuje na czymś lepszym niz kalkulator Bolek,
>>> nie zauważysz różnicy.
>> Argument z Bolkiem, to już w ogóle do niczego. Chcę *tylko* wyświetlać
>> obrazki, co nawet dla Bolka nie jest ambitnym zadaniem, a mam se kupić
>> maszynę z czterema rdzeniami i akceleratorem graficznym?
>
> Dlatego nie widze sensu pisania oprogramowania do czynności która jest
> osiągalna od ręki w dowolnym unixie. O to całe boje od początku.

Czemu od razu boje? Miły, sympatyczny człowiek potrzebuje coś zrobić,
a sam nie umie, albo ma głupie pomysły, więc prosi o pomoc. Jacyś mu
pomagają i coś z tego wychodzi. Nawet bez bólu. Gdzie te boje?

> W dodatku nie widze sensu robienia akademicko poprawnie, skoro problem
> nie ma żadnych zagadnień związanych z wydajnościa, zajętością pamięci
> czy czymkolwiek istotnym *akademicko*.

Przepraszam, może to ja sobie sam te założenia gdzieś w głowie dopisałem,
ale problem wydał mi się tak podobny do wcześniej rozwiązywanych przeze
mnie, że trudno mi się pozbyć skojarzeń. Więc jak coś ma chodzć z flasha
sterowane portem seregowym, to zakładam, że będzie na mało wydajnym
sprzęcie.

> Powiedzmy że problem ma być rozwiązany biznesowo: napisać jak najmniej,
> uzyskać jak najwięcej, nawet jesli to oznacza pogwałcenie wszelkich
> zasad w tym akademickich.

Rozwiązanie biznesowe, to takie, które się powiela w wielu egzemparzach.
Może ja i drogi jestem, ale nie aż tak, by moje myślenie było więcej
warte niż ileś egzemplarzy pomnożone przez ileś złotych, dolarów, czy
nawet orzechów zmarnowanych nie wiadomo po co. Akademicko, to ja se
mogę dla siebie, w jednym egzemlarzu, na swoim komputerze na biurku
-- wtedy mogę gwałcić, co tylko zechcę.

> To i tak lepiej niż Lazarus.

Przeważnie.

>>>> , nie jest najlepszym pomysłem (akademik Grigorij Syzyfow problem
>>>> ten omawia w swojej głosnej pracy).
>>> Rozwiązanie sprawdzi się bez względu na akademickie wywody. W tym
>>> przypadku okres wyświetlania obrazu będzie na tyle dlugi że zamortyzuje
>>> overheat odpalania procesu.
>> Akurat akademickie wywody się tu przydają. Nie można na przykład pominąć
>> tego, co w swoim słynnym podręczniku do fizjologii napisał prof. Widzeń.
>
> Dreptasz w absuradlnym kierunku.

Lubię takie spacery.

>> Telewizory, co teraz na lotniskach wyświetlają odloty i przyloty, na ogół
>> projektowane są przez ludzi, który żadnej tego typu książki nie czytali.
>> Coś się zmienia w rządku cyfr, a ekran nawet nie błyśnie.
>
> To *nie* ma żadnego związku z tematem bo nie mamy pojęcia jakie to
> obrazki mamy pokazywać.

Jak *nie* wiemy, to wszystko ma związek. Gdyby ktoś tu zażądał, by zrobić
za niego projekt dokładnie taki jak w opisie i to koniecznie na jutro, to
byśmy go słusznie olali. A tak, to sobie możemy o tym i owym pogadać.

>> Kolejne obrazy są niemal takie same,
>
> Nie wiesz tego.

A co to ja telewizora na lotnisku nie widziałem? Więc wiem.

>> z odpalaniem na nowo procesu na ogół się nie sprawdza (choć akurat przy
>> 'display' i root window będzie ok).
>
> Nic nie rozumiem, co ma odpalanie procesu z kiepskim designem gui?

Ja też nie rozumiem. Z czym w ogóle ma mież związek "kiepski design gui"?

>>> Nie rózni się to niczym od prawidlowego zamykania i odpalania procesów,
>>> jesli nie masz na mysli 50 obrazków na sekunde.
>> A jesli mam?
>
> To sa inne rozwiązania. Nijak nie pasujące do rozwiązania problemu w tej
> dyskusji.

Dlaczego muszą być inne? Ja częściej niż 'display' używam 'kuickshow'.
To są bardzo podobne programy, napisane w tym samym celu. I ja tego
używam również do oglądania ruchomych obrazów z kamery, kilkadziesiąt
klatek na sekundę, ad hoc tworzących film z poszczególnych plików JPG
w katalogu. Wystarczy wcisnąć i przytrzymać klawisz Pg-Up albo Pg-Down.
Gdymym trzymał się założeń, że ma być "lepiej i prościej", a do każdego
zdjęcia trzeba odpalić nowy proces przeglądarki, to bym guzik zobaczył,
a nie film.

> Do odtwarzania filmów weźmiesz mplayera. Do obrazkow display.

A gwoździk w ścianę mogę wbić tylko młotkiem? Bo mosiężna figurka stojąca
ma kominku się do tego nie nadaje. Psycholodzy mówią na to "fiksacja
funkcjonalna". I pokazuja palcem na mnie jako na najlepszy przykład
gościa, który tego nie ma. No więc ja oglądam filmy programem do obrazków
i twierdzę, że (w konkretnym przypadku) mplayer się do tego zupełnie nie
nadaje.

> Do muzyki mpeg123. Oprogramowanie na miarę, a nie uniwersalne.

Perl jest uniwersalny. Da się nim muzyki słuchać. I to nie jak w bash
(który też uniwersalny), czyli przez wywołanie programu z zewnątrz,
na przykład mpg123.

> Uniwersalne zazwyczaj nie pasuje nigdzie.

Program 'convert' pasuje do wszystkich obrazków o formatach znanych
innym programom dostępnym w systemi. I można nim konwertować nie
posiadając wiedzy tajemnej (do Perla posiadać potrzeba).

>> Albo jeśli program, to wielka kobyła? Na przykład chciałbym
>> uruchomić firefoksa w root window. I szturchać go sygnałem, żeby robił
>> 'reload' strony. Niestety nie da się, ktoś zapomniał albo olał problem,
>> bo sam uważał, że to bez sensu (albo ja nie potrafię znaleźć rozwiązania).
>
> Ale co to ma wspólnego z czymkolwiek ?

Z czymkolwiek, to wszystko ma coś wspólnego (ja też potrafię pisać
niekonkretnie, a zwłaszcza lubię dawać niekonkretne odpowiedzi na
niekonkretne pytania).

>>> Szyj oprogramowanie na miarę.
>> Ta zasada sprawdza się u krawców mężczyźnianych. W uniksie lepszą zasadą
>> jest "szyj oprogramowanie na wyrost". Nie chodzi o przerost formy nad
>> treścią, tylko o udostępnianie nic nie kosztujących opcji. Nawet jak
>> ktoś sobie myśli, że "w tym wypadku do niczego to nie jest potrzebne".
>
> Nie pamiętam aby ktokolwiek dorabiał switcha gdziekolwiek na zaś.

No bo nikt nie *dorabia*, tylko robi się to od razu wszystko, co tylko
uda się przewidzieć. Choćby taki program jak "ls", służący do zadawłoby
się tak banalnej rzeczy, jak pokazanie plików w katalogu, ma tyle opcji,
że ledwie alfabetu starcza. Ja ich oczywiście w większości nie pamiętam.

> Zazwyczaj wiele absuralnych switchy miało uzasadnienie w postaci
> zarośniętego admina w serwerowni w singapurze który chciał zwiększyć
> czas na pożeranie pizzy.

Mam sentyment do zarośniętych adminów w serwerowniach w Singapurze.
Pizzy takiemu nie mam jak kupić, ale jeśli nieużywane przeze mnie opcje
programów mogą mu w jego doli ulżyć, to nie mam nic przeciwko nim.

> Być może dlatego do tej pory nie ma jak sensownie skonwertowąc bajta
> do liczby w bashu. Nikt tego na zapas nie zrobił choć np. programiście
> wydaje się oczywiste.

To nie tak. Bash już jest wystarczającą rewolucją w stosunku do
wcześniejszego sh. Ale zrobioną jednorazowo. Tak jak nienajlepszym
pomysłem jest obcinanie psu ogona po kawałku, żeby się przyzwycził,
tak nie jest dobrze dorzucać do programu po jednej możliwości co
jakiś czas. To może dobre, jak się chce ludzimom co roku sprzedawać
nowego iPhona. Ale porządne programy robi sie inaczej -- najpierw
się dłuuugo myśli, a dopiero potem pisze.

--
Jarek