On 2011-09-17 15:16, Jarosław Sokołowski wrote:
>> Nie. Mamy kilkadziesią lat doświadczeń w pisaniu aplikacji. Naprawdę,
>> potrafimy pisac programy niezawodne i przetestowane używając językow
>> innych niż perl czy bash *nawet* w jednym egzemplarzu. Kwestia warsztatu.
> Jeśli od kilkudziesięciu lat nie wyszliście

My. Programiści. My naprawde potrafimy pisać niezawodne programy. W
wielu językach. Zalicza się do nich C i C++. Bywa ze java. Bywa że Ada.
Bywa że lisp. Bash jest gdzieś na samym dnie jako utility language. Nic
dziwnego, to padlina.

> powyżej robienia automatyki
> do zaciągania rolet w oknie obok komputera i jeśli nie testujecie
> robionych rzeczy przed przekazaniem ich do użytkowania (mimo że potraficie),
> to nie ma się czym chwalić.

Jeśli, jesli, jesli. I wniosek. No pięknie.

> Nawet warsztatem w takiej sytuacji nie ma
> co się chwalić, bo kogo to obchodzi.

A kogo obchodzi pisanie kodu do sterowania czymkolwiek w bashu? To chory
język. Pod wieloma względami można w nim popełnić wiele błedow
nieznanych w innych, znacznie sensowniejszych językach. Chwalenie się,
że programy napisane w języku interpretowanym (a więc zapewne i
dynamicznym) będa mniej awaryjne niż pisane w czymkolwiek innym obnaża
twoją wiedzę dotycząca innych jezyków i metod utrzymywania jakości kodu.
I przyznaje - znam wielu ludzi robiących w embedded (programiści
pokolenia 8051) którzy o czymą takim jak abstrakcja, unit testy,
constraints, silne typowanie, generyczność, interfejsy, asercje w życiu
nie słyszeli. Nic dziwnego że robią szkole błedy i potem narzekają na C
produkując kod gówniany do granic możliwości, nieprzetestowany (no bo
jak, panie, to testować?) i działający na słowo honoru.

(Pewna niemiecka firma od 10 lat produkuje pewne urzedzenie które pomimo
bledow w firmware zagrażających życiu (nie przesadzam) nie naprawia go
bo człek co pisał odszedł a kod to kupa g... napisana w C na styl BCPLo
podobny).

>> - Panie Kaziu, niech pan mi tu da zapasowago peceta z LPT bo się zjarał
>> znowu zasilacz i upier... płytę.
>> - Ale nie ma, zapasy się skonczyły, w sklepach nie ma
>> - Cholera... dobra, to bankrutujemy
> Jeśli tam chadzają takie dialogi, to już dawno powinni zbankrutować.
> Ani trochę mi ich (was?) nie żal.

Co sugerujesz w zamian zamiast następnej nietrafionej oceny?

PS. Żeby była jasność. Nie jestem zwolennikiem stosowania *Atmela* jako
sterownika. Jestem natomiast wrogiem stosowania peceta tam, gdzie nie ma
miejsca na pomyłkę. A już na pewno nie peceta z gównianym bashem.

do góry

On 2011-09-17 18:44, Jarosław Sokołowski wrote:
>> Nie przeszkadza Ci fakt że unix to nie jest środowsko real-time,
> Przy opuszczaniu rolet i włączaniu grzejnika olejowego? Nie.

To bardzo skrajny przypadek sterowania. Zaryzykuje ze stosowanie w tym
celu peceta jest mało ekonomiczne.

>> że bash nie ma dostepu do potów I/O, że w normalnej sytuacji jako
>> user nie masz dostępu do przestrzeni I/O?
> Raczej pomaga.

Fajnie. Znaczy odpalasz swoj skrypt jako admin? No i proszę, problem
solved. A ja tu glupio rozmyślam jak zrobić coś lepiej. Brute force jest
zawsze lepsze.

> Kiedyś na końcówkach kabli USB były nalepki z ostrzeżeniem, by nie
> wtykać tego w komputer z systemem Windows, zanim się nie zainstaluje
> oprogramowania. No i faktycznie, gdy się to zignorowało, to jeśli ktoś
> nie był fachowcem, to po czymś takim nie udawało mu się już zmusić
> urządzenia do działania.

To wynik wielu czynników, ale jednym z nich są niedoróbki w kodzie
windowsa i sterownikow. Niby mamy to za sobą, ale czy na pewno pewnego
dnia następna prasa nie przywali kogoś w glowę bo sterownik się
wypierniczy na dereferencji nulowego pointera? Masz jakieś gwarancje że
kod składający się z milionów lini kodu do ktorego nawet nie masz wglądu
jest lepiej wytestowany niż sto lini w C na avr?

> A jeśli się dało, to sam powinien zapewnić niemożnaość rozłączenia.

Nierozłaczalne gniazdka USB. Czyli jak naprawić problem w innym miejscu
niż występuje. Musze ten pomysł gdzies zanotować. Oczywiście, żeby nigdy
na niego nie wpaść.

do góry

Pan Sebastian Biały napisał:

>>> Nie. Mamy kilkadziesią lat doświadczeń w pisaniu aplikacji. Naprawdę,
>>> potrafimy pisac programy niezawodne i przetestowane używając językow
>>> innych niż perl czy bash *nawet* w jednym egzemplarzu. Kwestia warsztatu.
>> Jeśli od kilkudziesięciu lat nie wyszliście
>
> My. Programiści. My naprawde potrafimy pisać niezawodne programy. W
> wielu językach. Zalicza się do nich C i C++. Bywa ze java. Bywa że Ada.
> Bywa że lisp. Bash jest gdzieś na samym dnie jako utility language. Nic
> dziwnego, to padlina.

Wiem, wiele potraficie. Ale też przecież potraficie popełniać błędy...

>> powyżej robienia automatyki do zaciągania rolet w oknie obok komputera
>> i jeśli nie testujecie robionych rzeczy przed przekazaniem ich do
>> użytkowania (mimo że potraficie), to nie ma się czym chwalić.
>
> Jeśli, jesli, jesli. I wniosek. No pięknie.

...na przykład nie dostrzegając kilku istotnych "jeśli" i iść dalej
jakby ich nie było. Nie zawsze wychodzi pięknie.

>> Nawet warsztatem w takiej sytuacji nie ma co się chwalić, bo kogo to
>> obchodzi.
>
> A kogo obchodzi pisanie kodu do sterowania czymkolwiek w bashu?

Tych co piszą.

> To chory język.

Chlorchinaldin powinien pomóc.

> Chwalenie się, że programy napisane w języku interpretowanym (a więc
> zapewne i dynamicznym) będa mniej awaryjne niż pisane w czymkolwiek
> innym obnaża twoją wiedzę dotycząca innych jezyków i metod utrzymywania
> jakości kodu.

Skoro rzeczywiście są mniej awaryjne, to co szkodzi się pochwalić?
Ale przecież nie chodzi o bezawaryjność i bezbłędność, tylko o możliwość
szybkiego dostrzeżenia i poprawienia pomyłek.

>>> - Panie Kaziu, niech pan mi tu da zapasowago peceta z LPT bo się zjarał
>>> znowu zasilacz i upier... płytę.
>>> - Ale nie ma, zapasy się skonczyły, w sklepach nie ma
>>> - Cholera... dobra, to bankrutujemy
>> Jeśli tam chadzają takie dialogi, to już dawno powinni zbankrutować.
>> Ani trochę mi ich (was?) nie żal.
>
> Co sugerujesz w zamian zamiast następnej nietrafionej oceny?

Ich (wasza?) ocena akurat jest trafna: powinni(ście) zbankrutować.

> PS. Żeby była jasność. Nie jestem zwolennikiem stosowania *Atmela* jako
> sterownika. Jestem natomiast wrogiem stosowania peceta tam, gdzie nie ma
> miejsca na pomyłkę. A już na pewno nie peceta z gównianym bashem.

Ja nie jestem wrogiem stosowania czegokolwiek jako cokolwiek, o ile ma
to uzasadnienie. Natomiast staram się unikać dawania możliwości decyzji
inż. inź. Mamoniom, którzy potrafią docenić tylko to, co sami znają.

--
Jarek

do góry

Pan Sebastian Biały napisał:

>>> Nie przeszkadza Ci fakt że unix to nie jest środowsko real-time,
>> Przy opuszczaniu rolet i włączaniu grzejnika olejowego? Nie.
>
> To bardzo skrajny przypadek sterowania.

A co ja poradzę, że przyszło nam taki analizować?

> Zaryzykuje ze stosowanie w tym celu peceta jest mało ekonomiczne.

Mam nadzieję, że nie grywa Pan na giełdzie. Ocena ryzyka (ekonomicznego)
słabo Panu wychodzi. Majstrowanie dodatkowego sterownika nigdy nie
będzie tańsze.

>>> że bash nie ma dostepu do potów I/O, że w normalnej sytuacji jako
>>> user nie masz dostępu do przestrzeni I/O?
>> Raczej pomaga.
>
> Fajnie. Znaczy odpalasz swoj skrypt jako admin?

Nie.

> No i proszę, problem solved.

?

> A ja tu glupio rozmyślam jak zrobić coś lepiej.

E tam lepiej. A poza tym, wszystko się zgadza.

> Brute force jest zawsze lepsze.

???

>> Kiedyś na końcówkach kabli USB były nalepki z ostrzeżeniem, by nie
>> wtykać tego w komputer z systemem Windows, zanim się nie zainstaluje
>> oprogramowania. No i faktycznie, gdy się to zignorowało, to jeśli ktoś
>> nie był fachowcem, to po czymś takim nie udawało mu się już zmusić
>> urządzenia do działania.
>
> To wynik wielu czynników, ale jednym z nich są niedoróbki w kodzie
> windowsa i sterownikow. Niby mamy to za sobą, ale czy na pewno pewnego
> dnia następna prasa nie przywali kogoś w glowę bo sterownik się
> wypierniczy na dereferencji nulowego pointera?

Bash nie wie co to jest defragmentacja nulowego pointera, więc gdyby
miał akurat takie obsesje, to bym mu poradził używanie basha.

> Masz jakieś gwarancje że kod składający się z milionów lini kodu do
> ktorego nawet nie masz wglądu jest lepiej wytestowany niż sto lini
> w C na avr?

Nie mam z góry zaufania ani do jednego, ani do drugiego. Ale na ogół
ma się większe zaufanie do miliona linii sprawdzanych w praktyce od
dwadziestu lat, niż do stu linni napisanych wczoraj przez jakichś
debeściaków ("bo my to panie wszystko testujemy, a poza tym mamy
kilkadziesiąt lat doświadczenia").

>> A jeśli się dało, to sam powinien zapewnić niemożnaość rozłączenia.
>
> Nierozłaczalne gniazdka USB.

Albo brak gniazdka.

> Czyli jak naprawić problem w innym miejscu niż występuje.

Przecież dymić się zaczęło po wyciągnięciu wtyczki.

> Musze ten pomysł gdzies zanotować. Oczywiście, żeby nigdy na niego nie
> wpaść.

Jest niepatentowalny, więc nie ma obaw.

--
Jarek

do góry

On 2011-09-17 19:28, Jarosław Sokołowski wrote:
> Mam nadzieję, że nie grywa Pan

Stosujesz żałosne metody A.L. do oceny dyskutantów?

>> Fajnie. Znaczy odpalasz swoj skrypt jako admin?
> Nie.

Więc jak uzyskujesz prawa do przestrzeni I/O LPT? Sterownikiem kernela?
Hackowaniem jądra?

>> To wynik wielu czynników, ale jednym z nich są niedoróbki w kodzie
>> windowsa i sterownikow. Niby mamy to za sobą, ale czy na pewno pewnego
>> dnia następna prasa nie przywali kogoś w glowę bo sterownik się
>> wypierniczy na dereferencji nulowego pointera?

> Bash nie wie co to jest defragmentacja

Ciąg dalszy żalosnych metod A.L. czy zwykłe przejęzyczenie?

> nulowego pointera

Albowiem bash działa w przestrzeni równoległej gdzie pojęcie nulowego
pointera nie istnieje i już! W szczegolności w sterowniku do LPT! I
wtedy się budzisz. Ja też kiedyś sniłem do czasu aż kernel z lini 2.4
zrobił oopsa przy obsłudzie - wydawało by się - trywialnego COMa.
Powtarzalnego 100%, żeby nie było że to krasnoludki.

> Nie mam z góry zaufania ani do jednego, ani do drugiego. Ale na ogół
> ma się większe zaufanie do miliona linii sprawdzanych w praktyce od
> dwadziestu lat, niż do stu linni napisanych wczoraj przez jakichś
> debeściaków ("bo my to panie wszystko testujemy, a poza tym mamy
> kilkadziesiąt lat doświadczenia").

Debesciaki są w ogólności bardziej bezpieczni niż windows zaopatrzony w
sterowniki produkowane na kolanie w chinach chodzace w trybie jądra.
Chwilowo nie ma na rynku popularnych mikrokernelów, więc *zawsze* jesteś
w czarnej dupie watpliwości co do tego czy sterownik myszki nie zrobi
BSOD po 3 tygodniach i 14 sekundach pracy. Chińczyk nie ma czasu na
testowanie takich dupereli.

do góry

On 2011-09-17 19:11, Jarosław Sokołowski wrote:
>> My. Programiści. My naprawde potrafimy pisać niezawodne programy. W
>> wielu językach. Zalicza się do nich C i C++. Bywa ze java. Bywa że Ada.
>> Bywa że lisp. Bash jest gdzieś na samym dnie jako utility language. Nic
>> dziwnego, to padlina.
> Wiem, wiele potraficie. Ale też przecież potraficie popełniać błędy...

I dzięki temu że to wiemy nauczyliśmy się również im przeciwdziałać. W
sposób, ktory pozwala pisać programy o rzedy bardziej niezawodne niż w
jezykach dynamicznych/interpretowanych a w szczegolności niż języki
padlinowate jaki bash, perl czy inny cli-php.

>> Chwalenie się, że programy napisane w języku interpretowanym (a więc
>> zapewne i dynamicznym) będa mniej awaryjne niż pisane w czymkolwiek
>> innym obnaża twoją wiedzę dotycząca innych jezyków i metod utrzymywania
>> jakości kodu.

> Skoro rzeczywiście są mniej awaryjne, to co szkodzi się pochwalić?
> Ale przecież nie chodzi o bezawaryjność i bezbłędność, tylko o możliwość
> szybkiego dostrzeżenia i poprawienia pomyłek.

NIE. Chodzi o to by nie dopuścić do pomyłek w momecie pisania. Nie
dopuscić. Żadnego dostrzegania i poprawiania. W bashu nie ma o tym mowy.
W C++ można ogromną ilość pomylek wyeliminować w compile-time bez
jednego straconego cyklu w run-time. To dwa końce problemu jakości kodu
w związku z językiem. Można dyskutować czy poprawienie buga w C jest
łatwiejsze niż w bash, ale z doświadczenia powiem: jest łatwiejsze w C.
Przynajmniej sa narzędzia.

Żeby była jasność: mowimy o sofcie który jest nieco bardziej rozbudowany
niż klepanie przekaźnikiem. Klepanie przekaźnikiem pewno dało by się
napisać w command.com w miarę bez błedow.

> Natomiast staram się unikać dawania możliwości decyzji
> inż. inź. Mamoniom, którzy potrafią docenić tylko to, co sami znają.

O dziwo czesto słyszę to od zwolenników wstawiania 8051 do
*wszystkiego*. Taki typowy embedded-banał.

do góry

Pan Sebastian Biały napisał:

>> Mam nadzieję, że nie grywa Pan
>
> Stosujesz żałosne metody A.L. do oceny dyskutantów?

Nie wiem kto to taki ten A.L., więc nawet nie wiem czy jego metody
są żałosne. Sądzę, że może być Pan znakomitym fachowcem w swojej
dziedzinie (jakieś programowanie czegoś bardzo konkretnego?),
ale uważam, że za tworzenie założeń i ocenę ekonomiki działań nie
powinien się Pan brać.

>>> Fajnie. Znaczy odpalasz swoj skrypt jako admin?
>> Nie.
>
> Więc jak uzyskujesz prawa do przestrzeni I/O LPT?

Nie potrzebuję.

> Sterownikiem kernela? Hackowaniem jądra?

W tym momencie (pisania w bash) nie muszę sobie tym głowy zaprzątać.

>>> To wynik wielu czynników, ale jednym z nich są niedoróbki w kodzie
>>> windowsa i sterownikow. Niby mamy to za sobą, ale czy na pewno pewnego
>>> dnia następna prasa nie przywali kogoś w glowę bo sterownik się
>>> wypierniczy na dereferencji nulowego pointera?
>
>> Bash nie wie co to jest defragmentacja
>
> Ciąg dalszy żalosnych metod A.L. czy zwykłe przejęzyczenie?

Przejęzyczenie. A właściwie dyfuzja sąsiedniego z okienka.

>> nulowego pointera
>
> Albowiem bash działa w przestrzeni równoległej gdzie pojęcie nulowego
> pointera nie istnieje i już! W szczegolności w sterowniku do LPT! I
> wtedy się budzisz. Ja też kiedyś sniłem do czasu aż kernel z lini 2.4
> zrobił oopsa przy obsłudzie - wydawało by się - trywialnego COMa.

Ten kernel był pisany w bashu?

> Powtarzalnego 100%, żeby nie było że to krasnoludki.

No to całe szczęście. W takim razie nie ma tragedii.

>> Nie mam z góry zaufania ani do jednego, ani do drugiego. Ale na ogół
>> ma się większe zaufanie do miliona linii sprawdzanych w praktyce od
>> dwadziestu lat, niż do stu linni napisanych wczoraj przez jakichś
>> debeściaków ("bo my to panie wszystko testujemy, a poza tym mamy
>> kilkadziesiąt lat doświadczenia").
>
> Debesciaki są w ogólności bardziej bezpieczni niż windows zaopatrzony
> w sterowniki produkowane na kolanie w chinach chodzace w trybie jądra.

Z Windows nigdy nie miałem na poważnie do czynienia. Z debeściakami
czasem tak. Trudno mi porównywać, ale niebezpieczni są. Ponad tolerowane
przeze mnie granice.

> Chwilowo nie ma na rynku popularnych mikrokernelów, więc *zawsze* jesteś
> w czarnej dupie watpliwości co do tego czy sterownik myszki nie zrobi
> BSOD po 3 tygodniach i 14 sekundach pracy. Chińczyk nie ma czasu na
> testowanie takich dupereli.

Nic mi jeszcze nie zrobiło BSOD, a co do Chińczyków, to nie mam uprzedzeń
narodowościowych -- traktuję ich jak innych debeściaków. Z tego powodu,
gdy chodzi o nowe rzeczy, staram się jak najwięcej robić we własnym
zakresie (to znaczy przynajmniej mieć nad tym kontrolę).

--
Jarek

do góry

Pan Sebastian Biały napisał:

>> Wiem, wiele potraficie. Ale też przecież potraficie popełniać błędy...
>
> I dzięki temu że to wiemy nauczyliśmy się również im przeciwdziałać.

Niestety nie ma prostego wynikania.

> W sposób, ktory pozwala pisać programy o rzedy bardziej niezawodne niż
> w jezykach dynamicznych/interpretowanych a w szczegolności niż języki
> padlinowate jaki bash, perl czy inny cli-php.

Co z tego, że macie sposoby na pisanie programów niezawodnych, skoro
nie umiecie przeanalizować założeń? Owszem, może uda wam się w ten
sposób zrobić działający program, ale to na nic, gdy robi on nie to,
co powinien.

>> Ale przecież nie chodzi o bezawaryjność i bezbłędność, tylko o możliwość
>> szybkiego dostrzeżenia i poprawienia pomyłek.
>
> NIE. Chodzi o to by nie dopuścić do pomyłek w momecie pisania.

Z takim podejściem w ogóle nie ma co się zabierać za pisanie programu.
Ani do żadnej roboty, bo człowiek jest omylny z definicji.

> Żeby była jasność: mowimy o sofcie który jest nieco bardziej rozbudowany
> niż klepanie przekaźnikiem. Klepanie przekaźnikiem pewno dało by się
> napisać w command.com w miarę bez błedow.

Ale przecież wy wszystko robicie tak samo, niezależnie czy chodzi
o klepanie przekaźnikiem czy czymś innym. Bo pisanie w innym języku
jest "gówniane".

>> Natomiast staram się unikać dawania możliwości decyzji inż. inź.
>> Mamoniom, którzy potrafią docenić tylko to, co sami znają.
>
> O dziwo czesto słyszę to od zwolenników wstawiania 8051 do
> *wszystkiego*. Taki typowy embedded-banał.

Albo do *wszystkiego* używają jednego języka programowania.

--
Jarek

do góry

On 2011-09-17 20:38, Jarosław Sokołowski wrote:
>> Albowiem bash działa w przestrzeni równoległej gdzie pojęcie nulowego
>> pointera nie istnieje i już! W szczegolności w sterowniku do LPT! I
>> wtedy się budzisz. Ja też kiedyś sniłem do czasu aż kernel z lini 2.4
>> zrobił oopsa przy obsłudzie - wydawało by się - trywialnego COMa.
> Ten kernel był pisany w bashu?

Ten bash pracowal w środowisku stworzonym przez kernel. Sam z siebie
pracować nie potrafi. Problem kernela jest problemem basha.

>> Powtarzalnego 100%, żeby nie było że to krasnoludki.
> No to całe szczęście. W takim razie nie ma tragedii.

Jasne, skonczyło się na poprawianiu kodu w kernelu. Jeszcze jedna do
miliona niewiadomych o stabilności całości systemu. Przy takiej ilości
nie ma już żadnego znaczenia, kontrole straciłeś wiele milionów lini
kodu wczesniej.

>> Chwilowo nie ma na rynku popularnych mikrokernelów, więc *zawsze* jesteś
>> w czarnej dupie watpliwości co do tego czy sterownik myszki nie zrobi
>> BSOD po 3 tygodniach i 14 sekundach pracy. Chińczyk nie ma czasu na
>> testowanie takich dupereli.

> Nic mi jeszcze nie zrobiło BSOD

Jesteś w mniejszości.

> gdy chodzi o nowe rzeczy, staram się jak najwięcej robić we własnym
> zakresie (to znaczy przynajmniej mieć nad tym kontrolę).

Czyli kernel też piszesz samodzielnie?

do góry

On 2011-09-17 20:45, Jarosław Sokołowski wrote:
>> W sposób, ktory pozwala pisać programy o rzedy bardziej niezawodne niż
>> w jezykach dynamicznych/interpretowanych a w szczegolności niż języki
>> padlinowate jaki bash, perl czy inny cli-php.

> Co z tego, że macie sposoby na pisanie programów niezawodnych, skoro
> nie umiecie przeanalizować założeń? Owszem, może uda wam się w ten
> sposób zrobić działający program, ale to na nic, gdy robi on nie to,
> co powinien.

Czekaj, skąd wytrzasnałeś brak umiejętności analizy założeń? Masz jakąs
szklaną kulę? I skąd to poprzednioustrojowe używanie "Wy" ?

>>> Ale przecież nie chodzi o bezawaryjność i bezbłędność, tylko o możliwość
>>> szybkiego dostrzeżenia i poprawienia pomyłek.
>> NIE. Chodzi o to by nie dopuścić do pomyłek w momecie pisania.
> Z takim podejściem w ogóle nie ma co się zabierać za pisanie programu.

Prezentujesz poziom zblizony do poglądow programistów z lat 80. Tak,
doskonale sobie zdaje sprawę że wiekszośc z nich przetrwala w
przechowalni o nazwie embedded. Widuje ich na codzień. Ta dyskusja wraca
bardzo czesto i zazwyczaj kończy się na inwektywach.

> Ani do żadnej roboty, bo człowiek jest omylny z definicji.

Błedy lepiej blokować niż dopuszczać i debugować. Języki interpretowane
i dynamicznie typowane nie potrafią blokować błedów poza trywialnymi w
składni. Na tej planecie są całe stada programistów którzy sobie tego
nigdy nie uświadomią. Trudno. Takie języki też sa potrzebne, ale u
diabła dlaczego ma od nich zależeć czyjeś życie?

> Ale przecież wy wszystko robicie tak samo, niezależnie czy chodzi
> o klepanie przekaźnikiem czy czymś innym. Bo pisanie w innym języku
> jest "gówniane".

Sam pisze oprogramowanie sterujące pewnym cusiem w JavaScript. Bo
doskonale wiedzialem, po analizie, czego i jak potrzebuje użyć. Pomimo
tego nie potrafie nawet naszkicować zbioru warunków na które odpowiedzią
byłby bash. Zawsze jest lepsza alternatywa.

>> O dziwo czesto słyszę to od zwolenników wstawiania 8051 do
>> *wszystkiego*. Taki typowy embedded-banał.
> Albo do *wszystkiego* używają jednego języka programowania.

Tak, to ci sami. Stosują jakąś lokalną gwarę C.

do góry