On 09/06/2020 22:43, Maciej Sobczak wrote:
>> Programowania defensywnego na inpucie.
> Rzucam tezą, że ktoś z dobrą intencją ulepił koncept a cała masa ludzi ten koncept
powiela, już bez zastanowienia o co autorowi chodziło.
> Weź sobie funkcję std::sort. Ma trzy argumenty, trzeci to właśnie callback
komparatora (zwany w kręgach zbliżonych do akademickich "predykatem"). Otwórz sobie
header "algorithm" ze swojego kompilatora i poszukaj tam co robi funkcja std::sort ze
swoim trzecim argumentem (czyli "inputem", jak to nazywasz).
> Sprawdza, czy programista nie podał pustego wskaźnika/funktora/itp.?

Teraz weź dowolny nagłówek z Qt i poszukaj sobie Q_ASSERT. Niezłe
głupki, nie? Kto by traciła na to czas, Paaaanie...

> Tak więc biblioteka HTTP jest właśnie w takim towarzystwie (przynajmniej w tej
konkretnej kwestii...).

No ale to kiepskie towarzystwo. Co by o std:: nie mówić, jakościowo to
jest takie sobie, że nie wspomnę już że ma co najmniej kilka implementacji.

>>> Od kiedy to biblioteki HTTP służą do weryfikacji programów?
>> W każdym inpucie powinna być weryfikacja,
> To nie jest input, tylko część programu. Inputem jest URL z przeglądarki albo dane
z formatki w POST. I *to* należy walidować.

Więc mamy różne pojęcie o inpucie. Jako klient bibliteki widzę to
inaczej, nic nie poradzę.

>> ponieważ *ułatwia* to
>> debugowanie klientowi.
> Debugowanie ułatwia fakt, że gdybyś faktycznie spróbował zrobić taki błąd w tej
bibliotece, zamiast trollować na rympał, to byś zobaczył, że std::function rzuca
wtedy wyjątek, który biblioteka uczciwie wypisuje na podanym strumieniu do logowania
błędów.

Exceptions to nie asercje. Nie służa do tego samego. Narzekanie jest na
asercje a raczej ich brak. Asercje to rodzaj dokumentacji dla klienta.
Przydają się w debugu. Nic nie kosztują w runtime. Gdzie są wady które
powodują że nie warto?

> To programowanie defensywne, podobnie jak paranoja wokół unit testów, to niestety
efekt braku refleksji nad własnym warsztatem.

Paranoja wokół unit testów oznacza po drugiej stronie luzacki kod bez
śladu testowania. Rozsądek nakazuje być gdzieś w środku, specyfikacja
nakazuje czasem mieć prawie 100% pokrycia. Trudno tu doszukiwac się
refleksji, choć często muszę stopować młodych gniewnych którym wszystko
zawsze wychodzi dobrze od razu, tylko troche nie działa. Jednak pisanie
unit testów czasem się przydaje. Jak coś zapraszam do mnie, sam zobaczysz.

>>> Targetem są świadomi inżynierowie, którzy nie oczekują od biblioteki HTTP, że im
zrobi weryfikację poprawności programu...
>> Chyba takich jest relatywnie mało. Sądzepo ilości assertów w poważnych
>> biblitekach.
> No to ile assertów znalazłeś w std::sort na trzecim argumencie?

Trudno nazwać std:: poważną bibliteką pod kątem jakości. Obserwowałem
kiedyś rozwój stlport i muszę przyznać że podejście z gatunku "chyba
dobrze, komituj na produkcję" dało mi dużo do myślenia i zmianę własnego
warsztatu ze zwrotem przeciwnym.

> Ja sprawdziłem w bibliotekach standardowych z trzech różnych kompilatorów.

To sprawdź jeszcze resztę świata. Zacznij od Qt. Spodoba Ci się, tam
pracują sami nadprzyrodzeni hackerzy którzy mają reglamentowane asserty.
Ale i tak można ich tam troszkę znaleźć. Widocznie ktoś stwierdził że
czasem warto pilnować czy coś nie jest nullem, nawet jeśli klient tej
biblioteki jest nadprzyrodzonym superkoderem z kontraktem i +10 do
szczęścia.

do góry

On 09/06/2020 23:14, Maciej Sobczak wrote:
> Nie emulować, tylko sztucznie te zagadnienia rozdzielasz.
> Przecież biblioteka oparta w całości o callbacki jest eventowa niemal z założenia.
To Ty usiłujesz jej przypisać jakieś inne cechy.

Ale "eventowa z wątkami" to nie to samo co "coroutines/cooperative".
Więc jeśli będziesz się upierał o to że callback z wątku to "event" to
mamy rózne pojęcie co to jest event-based i oba do obrony.

>>> Muteks jest potrzebny, jeśli masz powody, żeby robić sekcje krytyczne. Tylko od
Ciebie zależy, czy będziesz miał te powody.
>> Nie. Jeśli mam event-based to nie mam powodów aby z powodu bibloteki
>> robić coś ekstra.
> Ciągle nie pokazałeś, dlaczego miałbyś robić coś ekstra.
> I dlaczego to akurat miałoby być z powodu tej biblioteki.

Bibliteka czyta/zapisuje zmienną globalną w implementacji callbacka.

Muszę ją obarierować i używać tej bariery w kodzie który nie ma NIC
wspólnego z serwerem HTTP. W ten sposób wątki z jakiejś bibliteki
agresywnie wymuszają na mnie zmiany kodu w miejscach odległych.

> Powtórzę: przykłady 1-5 *nie mają* muteksów. A jakie piękne GUI mają.

Helloworldy zazwyczaj nie mają żadnych problemów, chyba głównie dlatego
że połowa biblitek na necie nie ma innych zastosowań niż własne helloworldy.

Innymi słowy trudno o to aby kilka przykładów było dowodem w innym
zastosowaniu.

>>>> Mały muteksiak to duży kłopot w kilku przypadkach.
>>> Ale zapomniałeś je opisać.
>> Na przykład tam gdzie masz do czynienia z RT.
> No i? Jest cała szkoła modelowania systemów RT z obiektami chronionymi (patrz np.
Ada i związane z nią papiery akademickie), gdzie muteksy w niczym nie przeszkadzają.
Jaki masz problem z tymi muteksami?

Zajmują czas, wymagają grubego schedulera preemptive ze skomplikowaną
logią "Wait". Co prawda taki scheduler jest w zasięgu przeciętnego
programisty, ale to już nie jest za darmo.

>> Powiedzmy... piszesz soft do drukarki 3D sterujący wprost mechaniką.
> Łał. Myślałem, że drukarki 3D to był szpan dwa lata temu. :-p
> Teraz młodzież steruje dronami.

Nie, ten przykład to takie RT w domu, czyli w sam raz target Twojej
bibliteki. Hobbystyczny soft z hobbystycznymi biblitekami.

>> Wystawiasz w nim serwer www do sterowania.
> Masz na myśli, że serwer www lata na RaspberryPi

Obecnie sterowniki mają zaszyte jakeiś ARMy po 100MHz. Mimo że to RT to
w zasadzie procesor ma sporo wolnego w tzw "międzyczasie". Dlaczego nie
miałby generować jakiegoś www?

> Czy może masz na myśli to, że jakiś masochista uparł się, że serwer www z
niesterowalnym stosem TCP musi koniecznie być na jedynym mikrokontrolerze?

Trudno to nazwać masochizmem że ktoś stara się wykorzystać CPU bez
dodatkowego point-of-failure jakim jest extra Pi robiące za serwer www.

>> Mutexy są mało sensowne
> Ale dalej nie pokazałeś, po co te muteksy. Masz jakieś fiksacje. :-)

Masz wątki to i masz mutexy. W zasadzie czasem tylko memory barrier z
tych mutextów, ale mimo to dalej masz *coś*. Gdyby było to tylko w
adapterze do tej bibliteki to spoko. Ale wątki złośliwie zarażają resztę
kodu pojęciem zasobu krytycznego.

>> Prawie kazdy widział wątek. Promil wie jak działa pod maską.
> [...]
>> Fakt, w http cięzko takie zagadnienia znaleźć ...
> O, to, to. Fajnie, że dostrzegasz bezcelowość swojego trollowania. :-)

Trudno powiedzieć czy to trolowanie. W zasadzie nie wiem. Może to
dlatego że niedawno trafiłem na równie bezuzyteczny kawałek kodu. Niby
mógłbym użyć, ale ... detale ... jak ten while (1){} w stackless TCLu.
Prawie dobrze tylko całkiem do dupy. Taka karma :/

do góry

W dniu 09-06-2020 o 22:47, heby pisze:
> On 09/06/2020 22:23, Maciej Sobczak wrote:
>> [*] OK, osobne połączenia klienckie to fizycznie różne wątki. Ale da
>> się o tym nie myśleć, mogę specjalnie dla Ciebie dodać serializację
>> callbacków.
>
> Zaczynasz emulować model event-based. Za chwile pojawi się lock-free
> kolejka i już będziemy w domu.
>
>> Muteks jest potrzebny, jeśli masz powody, żeby robić sekcje krytyczne.
>> Tylko od Ciebie zależy, czy będziesz miał te powody.
>
> Nie. Jeśli mam event-based to nie mam powodów aby z powodu bibloteki
> robić coś ekstra.
>
>>> Mały muteksiak to duży kłopot w kilku przypadkach.
>> Ale zapomniałeś je opisać.
>
> Na przykład tam gdzie masz do czynienia z RT.
>
> Powiedzmy... piszesz soft do drukarki 3D sterujący wprost mechaniką.
> Wystawiasz w nim serwer www do sterowania. Mutexy są mało sensowne bo
> pracujesz nie dośc że w środowisku RT to jeszcze z masą przerwań o
> priorytetach wyższych niż switch kontekstu.

zaraz, zaraz... chcesz napisać, że na platformach wielocorowych nie
korzystasz z wątków?

Przecież to marnowanie wydajności.

--
http://kaczus.ppa.pl

do góry

On 10/06/2020 07:50, Tomasz Kaczanowski wrote:
>> Powiedzmy... piszesz soft do drukarki 3D sterujący wprost mechaniką.
>> Wystawiasz w nim serwer www do sterowania. Mutexy są mało sensowne bo
>> pracujesz nie dośc że w środowisku RT to jeszcze z masą przerwań o
>> priorytetach wyższych niż switch kontekstu.
> zaraz, zaraz... chcesz napisać, że na platformach wielocorowych nie
> korzystasz z wątków?

Dlaczego wielocorowych? Przecięny ARM sterownika drukarki 3D, w wersji
mikrokontrolerowej, ma 1 rdzeń.

> Przecież to marnowanie wydajności.

Gdybym w systemie RT miał do wyboru czy drugi rdzeń poświęcę na
zagadnienia sterowania silnikami czy może na obsługę serwera www to
zgadnij co wybiorę ...

do góry

> > Ciągle nie pokazałeś, dlaczego miałbyś robić coś ekstra.
> > I dlaczego to akurat miałoby być z powodu tej biblioteki.
>
> Bibliteka czyta/zapisuje zmienną globalną w implementacji callbacka.
>
> Muszę ją obarierować

Dlaczego musisz? Jeśli callbacki są szeregowane[*], to nie musisz.

[*] Ale nie są.

> i używać tej bariery w kodzie który nie ma NIC
> wspólnego z serwerem HTTP.

Eee... To po co używasz biblioteki HTTP?

> W ten sposób wątki z jakiejś bibliteki
> agresywnie wymuszają na mnie zmiany kodu w miejscach odległych.

Używasz zmiennej globalnej z odległych miejsc? Kiepsko.
Dlaczego obwiniasz jakąś bibliotekę o problemy spowodowane złą architekturą Twojego
programu?

> >> Wystawiasz w nim serwer www do sterowania.
> > Masz na myśli, że serwer www lata na RaspberryPi
>
> Obecnie sterowniki mają zaszyte jakeiś ARMy po 100MHz. Mimo że to RT to
> w zasadzie procesor ma sporo wolnego w tzw "międzyczasie". Dlaczego nie
> miałby generować jakiegoś www?

No więc skoro ma sporo wolnego, to jaki masz problem?
I jakie proporcje w tym problemie? Na takich sprzętach ludzie wsadzają pełny RTOS,
pełny stos TCP, chcą jeszcze serwer www i w tym wszystkim jest jakiś wyimaginowany
problem z muteksem? Pomyliłeś proporcje. Zwłaszcza, że w takiej składance muteksów
jest już nadziabanych jakieś kilkadziesiąt.

> > Czy może masz na myśli to, że jakiś masochista uparł się, że serwer www z
niesterowalnym stosem TCP musi koniecznie być na jedynym mikrokontrolerze?
>
> Trudno to nazwać masochizmem że ktoś stara się wykorzystać CPU bez
> dodatkowego point-of-failure jakim jest extra Pi robiące za serwer www.

I dlatego wsadza serwer www do krytycznego kontrolera? Żeby nie mieć dodatkowego
point-of-failure?
Ja na taką logikę nic nie poradzę i nikomu nie obiecuję swojego udziału.

> Masz wątki to i masz mutexy.

Dalej nie pokazałeś, dlaczego.
Ani też dlaczego to miałby być problem.

> Trudno powiedzieć czy to trolowanie. W zasadzie nie wiem. Może to
> dlatego że niedawno trafiłem na równie bezuzyteczny kawałek kodu.

To straszne.
Najstraszniejsze jest jednak to, że się tak bardzo tym przejmujesz.

--
Maciej Sobczak * http://www.inspirel.com

do góry

> > Weź sobie funkcję std::sort.

> Teraz weź dowolny nagłówek z Qt

Nie używam.

> Niezłe
> głupki, nie?

Nie. To ich wybór. Ja wybrałem tak jak autorzy std::sort.

> No ale to kiepskie towarzystwo. Co by o std:: nie mówić, jakościowo to
> jest takie sobie,

Tak, teraz musisz się koniecznie wytrollować z tej retorycznej dziury, do której się
sam wtrollowałeś.

> że nie wspomnę już że ma co najmniej kilka implementacji.

Podobnie jak standard POSIX. Też ma kilka implementacji.

Skoro jest wiele implementacji biblioteki standardowej i wszystkie mają podobne
zdanie na ten sam temat (pomimo naturalnej konkurencji pomiędzy nimi), to można to
zdanie nazwać jakimś konsensusem w danym temacie.
W przypadku jednej biblioteki (np. Qt) można to nazwać opinią.

> Asercje to rodzaj dokumentacji dla klienta.

Nie. Dla klienta jest header. Jak się autor postara, to dokumentacja też tam jest.
Ale przede wszystkim dla klienta jest header.

Asercje jako kontrakt są do bani właśnie przez to, że nie ma ich w headerze.

> Przydają się w debugu. Nic nie kosztują w runtime. Gdzie są wady które
> powodują że nie warto?

Nie rozwiązują problemu, jakim jest niewłaściwa użyta funkcja i dają fałszywe
poczucie bezpieczeństwa. O, fajnie, asserty przeszły, jest OK. A tu klops.

Uwaga: asserty są fajne *na końcu* funkcji - jako sanity-check, czy funkcja zrobiła
to co miała zrobić.
Własnie dlatego, że są w implementacji, a nie w headerze.

> Trudno nazwać std:: poważną bibliteką pod kątem jakości.

Rozumiem.

> > Ja sprawdziłem w bibliotekach standardowych z trzech różnych kompilatorów.
>
> To sprawdź jeszcze resztę świata.

A co będzie, jak znowu trafię na bibliotekę, która nie sprawdza?

> Zacznij od Qt.

Zacząłem od trzech różnych implementacji std.

--
Maciej Sobczak * http://www.inspirel.com

do góry

> > Ja sprawdziłem w bibliotekach standardowych z trzech różnych kompilatorów.
>
> To sprawdź jeszcze resztę świata. Zacznij od Qt.

A co mi tam. Sprawdziłem. Zacząłem od Qt.

https://github.com/qt/qtbase/blob/dev/src/corelib/to
ols/qalgorithms.h

Konkretnie, funkcja qSort z callbackiem komparatora jest tutaj:

https://github.com/qt/qtbase/blob/dev/src/corelib/to
ols/qalgorithms.h#L181

i bez walidowania swoich argumentów woła qSortHelper, który jest tutaj:

https://github.com/qt/qtbase/blob/dev/src/corelib/to
ols/qalgorithms.h#L340

i który bez walidowania swoich argumentów wywołuje callback tutaj:

https://github.com/qt/qtbase/blob/dev/src/corelib/to
ols/qalgorithms.h#L351

> Spodoba Ci się

Bez szału. Tzn. walidację callbacków robią poprawnie - w sensie że nie robią. O, to w
sumie podobnie jak w bibliotece standardowej. Konsensus w tej sprawie się przez to
poszerzył o kolejną zgodną opinię.

Natomiast ogólne wrażenie - jak na bibliotekę, która miała rzekomo inspirować
jakością, nie urywa.
Przykładowo, w jednym miejscu (w qSortHelper, 343) jest tak:

int span = int(end - start);

a w innym (w qStableSortHelper, 452) tak:

const int span = end - begin;

Dziwne, nie? I niekonsekwencja w nazwach iteratorów albo w użyciu const w dokładnie
takim samym idiomie, to akurat najmniejszy pikuś.
Ćwiczenie: czy wartość (end - start) zawsze mieści się w int?

Co się stanie, jeśli się nie zmieści? Jak to wpłynie na następne dwie linijki:

if (span < 2)
return;

?

Dalej: oszczędzanie na nawiasach klamrowych, niekonsekwentne ich stosowanie, albo raz
się namespace kończy komentarzem, innym razem bez komentarza. To tak na szybko.

Nie twierdze, że bardzo źle. W kategorii open-source na pewno powyżej średniej.

Ale nie o to chodzi. Chodzi o to, że strasznie jestem ciekaw, jaki argument teraz
wymyślisz.

--
Maciej Sobczak * http://www.inspirel.com

do góry

On 6/10/2020 8:57 PM, Maciej Sobczak wrote:
>> Bibliteka czyta/zapisuje zmienną globalną w implementacji callbacka.
>> Muszę ją obarierować
> Dlaczego musisz? Jeśli callbacki są szeregowane[*], to nie musisz.
> [*] Ale nie są.

Dlatego muszę.

>> i używać tej bariery w kodzie który nie ma NIC
>> wspólnego z serwerem HTTP.
> Eee... To po co używasz biblioteki HTTP?

Kod od manipulowania, powiedzmy, silnikami nic o jakims http nie wie.
Ale razem pracuja na jednym cpu i moga mieć dostęp do tych samych
zasobów jak np. zmienne okreslające położenie czy stan.

>> W ten sposób wątki z jakiejś bibliteki
>> agresywnie wymuszają na mnie zmiany kodu w miejscach odległych.
> Używasz zmiennej globalnej z odległych miejsc? Kiepsko.

W niektórych sytuacjah, jak opisywany sterwanik druku 3D, takim stanem
jest bardzo duzo róznych małych detali. Gdzie jest glowica, jaka jest
prędkośc itd itp.

> Dlaczego obwiniasz jakąś bibliotekę o problemy spowodowane złą architekturą Twojego
programu?

Ona w tym zastosowaniu NIE jest zła. Jest wręcz jedyna sensowna przy
200kB flasha.

>> Obecnie sterowniki mają zaszyte jakeiś ARMy po 100MHz. Mimo że to RT to
>> w zasadzie procesor ma sporo wolnego w tzw "międzyczasie". Dlaczego nie
>> miałby generować jakiegoś www?
> No więc skoro ma sporo wolnego, to jaki masz problem?

Poniewaz nie rozumiesz dlaczego można się wiekszośc czasu nudzić i
jednoczesnie mieć problem z wyrobieniem się w zastosowaniach RT. Otórz
twój preemptive multitasking powoduje że *akurat* w tym złosliwym
przykładzie może to powodować konkretne skutki w postacji utraty jakości
wydruku. Tylko dlatego że trzeba przełaczyc konteks kiedy glowica
właśnie wjechala w materiał.

> I jakie proporcje w tym problemie?

Jakie sobie tylko wymyslisz.

> Na takich sprzętach ludzie wsadzają pełny RTOS

Na ARM7, powiedzmy, ma to już resztkę sensu.

>, pełny stos TCP

Nie jest potrzebny. Wystarczy kawalek.

>, chcą jeszcze serwer www i w tym wszystkim jest jakiś wyimaginowany problem z
muteksem? Pomyliłeś proporcje.

Raczej "mam to na codzień".

> Zwłaszcza, że w takiej składance muteksów jest już nadziabanych jakieś
kilkadziesiąt.

Zero.

>> Trudno to nazwać masochizmem że ktoś stara się wykorzystać CPU bez
>> dodatkowego point-of-failure jakim jest extra Pi robiące za serwer www.
> I dlatego wsadza serwer www do krytycznego kontrolera? Żeby nie mieć dodatkowego
point-of-failure?

Tak. Albo dla wygody. Albo bo to modne. Rózne można miec powody.

> Ja na taką logikę nic nie poradzę i nikomu nie obiecuję swojego udziału.

I nikt nie obiecuje że uzyje w tym zastosowaniu. Dzień jak co dzień w
OpenSource.

>> Masz wątki to i masz mutexy.
> Dalej nie pokazałeś, dlaczego.

Niezupełnie. Po prostu odrzucasz częśc rzewczywostości nie pasującej do
zastosowania aktualnego. Wolno Ci.

> Ani też dlaczego to miałby być problem.

To też już zostało wyjasnione.

> To straszne.
> Najstraszniejsze jest jednak to, że się tak bardzo tym przejmujesz.

Czyli miałem rację. Nie chciałeś zapytać o porady co do kodu. Po prostu
musisz sobie podsykutować z rosnącym poziomem adrenaliny.

Ale nuda. EOT.

do góry

On 6/10/2020 9:13 PM, Maciej Sobczak wrote:
>> To sprawdź jeszcze resztę świata.
> A co będzie, jak znowu trafię na bibliotekę, która nie sprawdza?

To będziesz miał powód watpić czy Twoje rozwiązanie, i kolegow z std::,
jest prawidłowe. Skoro reszta świata w jakimś procencie uzywa.
Oczywiście to wszystko moga byc idioci, wiadomo.

do góry

On 6/10/2020 10:35 PM, Maciej Sobczak wrote:
> Ale nie o to chodzi. Chodzi o to, że strasznie jestem ciekaw, jaki argument teraz
wymyślisz.

Żaden. Z płaskoziemcami tez mi się cieżko rozmawia i w sumie to mało
konstruktywne. Ponadto EOT to EOT. Ziew.

do góry