🚀 go-pugleaf

On 26/09/2019 02:06, antispam@math.uni.wroc.pl wrote:
> Pan Mareczek pewnie nie wiedzial co mowi.  Ale mam wrazenie ze
> ty tez nie wiesz co piszesz.  Jest pare sposobow zeby kod
> Turbo Pascala przekompilowac na ARM-a.

Niemożliwe! A Brainfucka też się da? To czemu nie jest równiez brany pod 
uwagę? Tak on śliczny, amerykański!

>  A Pascal bywal preferowany
> w stosunku do C systemach wbudowanych. 

Bywał? Co najmniej od lat 80 nie pamiętam grama Pascala na systemach 
wbudowanych choć oczywiscie nie widziałem *wszystkich* systemów 
wbudowanych i niewątpliwie z zachodnim Texasie na sterownikach automatów 
do Coli mógł taki faktycznie banglać. Obecnie, jesli jest, to ma pewnie 
udział w rynku na poziomie szumu kwantowego.

Bywał preferowany ... no cóż może i ktoś tam preferował, wiec 
twierdzenie akademicko rozgrzeszam.

> Dlaczego? 

No własnie, dlaczego?

> Dosc powszechne
> jest przekonanie ze Pascal jest mniej blednogenny niz C, czyli
> po prostu ze latwej jest napisac _poprawny_ program w Pascalu
> niz w C.

No tak, to przeciez ZUPEŁNIE inny język, jak się napisze := zamiast =. 
Natychmiast poprawia to wszelakie bugi, generuje kod magicznie 
działający i krowy dają więcej mleka.

Zawsze mnie zastanawiało skąd ten pogląd o lepszości składni pascala nad 
c. W sumie to identyczne języki, może więc wchodzi w rachubę jakaś magia 
albo inna religia.

>  A w przypadku sterownika kotla poprawnosc jest
> kluczowa...

Na szczęscie od dziesięcioleci potrafimy badać poprawnośc kodu innymi 
metodami niż intensywnie gapienie się Panów Mareczków w kod.

heby <heby@poczta.onet.pl> wrote:
> On 26/09/2019 02:06, antispam@math.uni.wroc.pl wrote:
> > Pan Mareczek pewnie nie wiedzial co mowi.  Ale mam wrazenie ze
> > ty tez nie wiesz co piszesz.  Jest pare sposobow zeby kod
> > Turbo Pascala przekompilowac na ARM-a.
> 
> Niemo?liwe! A Brainfucka te? si? da? To czemu nie jest r?wniez brany pod 
> uwag?? Tak on ?liczny, ameryka?ski!

OK, dziekuje za potwierdzenie: nie wiesz (albo cie nie obchodzi)
co piszesz.
 
> >  A Pascal bywal preferowany
> > w stosunku do C systemach wbudowanych. 
> 
> Bywa?? Co najmniej od lat 80 nie pami?tam grama Pascala na systemach 
> wbudowanych cho? oczywiscie nie widzia?em *wszystkich* system?w 
> wbudowanych i niew?tpliwie z zachodnim Texasie na sterownikach automat?w 
> do Coli m?g? taki faktycznie bangla?. Obecnie, jesli jest, to ma pewnie 
> udzia? w rynku na poziomie szumu kwantowego.

To ze czegos nie widziales nie znaczy ze tego nie ma.  Z tego
co mi wiadomo wiekszosc kodu wbudowango wytworcy traktuja jako
sekret.  Ja kodu w Pascalu nie widzialem, ale dotarlo do mnie
pare w miare wiarygodnych informacji ze takowy byl rozwijany
po roku 2000.  Udzial w rynku sam w sobie jest malo istotny.
Istotne jest czy rozwiazanie w konkretnym przypadu dziala
i co mozna dzieki niemu zyskac.

> 
> > Dlaczego? 
> 
> No w?asnie, dlaczego?
> 
> > Dosc powszechne
> > jest przekonanie ze Pascal jest mniej blednogenny niz C, czyli
> > po prostu ze latwej jest napisac _poprawny_ program w Pascalu
> > niz w C.
> 
> No tak, to przeciez ZUPE?NIE inny j?zyk, jak si? napisze := zamiast =. 
> Natychmiast poprawia to wszelakie bugi, generuje kod magicznie 
> dzia?aj?cy i krowy daj? wi?cej mleka.
> 
> Zawsze mnie zastanawia?o sk?d ten pogl?d o lepszo?ci sk?adni pascala nad 
> c. W sumie to identyczne j?zyki, mo?e wi?c wchodzi w rachub? jaka? magia 
> albo inna religia.


Dosc powazne studium bledow w programach w C stwierdzilo ze
ok 25% bledow wykrytych po oddaniu programu to bylo bledne uzycie
=, kiedy mialo byc == (przy tym studium dotyczylo starannie napisanych
programow, z w miare niska srednia iloscia bledow).  W Pascalu
bardzo trudno zrobic taki blad.  Ale skladnia to tylko kawalek,
semantyka C bazuje na operatorze adresu i arytmetyce wskaznikowej.
Prawie kazdy inny jezyk jawnie uzywa tablice.  Jest tez sprawa
sprawdzania typow, Pascal to traktuje powazniej.

-- 
                              Waldek Hebisch

On 27/09/2019 15:49, antispam@math.uni.wroc.pl wrote:
>>> Pan Mareczek pewnie nie wiedzial co mowi.  Ale mam wrazenie ze
>>> ty tez nie wiesz co piszesz.  Jest pare sposobow zeby kod
>>> Turbo Pascala przekompilowac na ARM-a.
>> Niemo?liwe! A Brainfucka te? si? da? To czemu nie jest r?wniez brany pod
>> uwag?? Tak on ?liczny, ameryka?ski!
> OK, dziekuje za potwierdzenie: nie wiesz (albo cie nie obchodzi)
> co piszesz.

Wręcz przeciwnie. Wiem doskonale. Z faktu że można skompilować pascala 
na ARMa NIE WYNIKA że to jest sensowne i użyteczne. Nic z tego nie 
wynika poza hobby.

>> Bywa?? Co najmniej od lat 80 nie pami?tam grama Pascala na systemach
>> wbudowanych cho? oczywiscie nie widzia?em *wszystkich* system?w
>> wbudowanych i niew?tpliwie z zachodnim Texasie na sterownikach automat?w
>> do Coli m?g? taki faktycznie bangla?. Obecnie, jesli jest, to ma pewnie
>> udzia? w rynku na poziomie szumu kwantowego.
> To ze czegos nie widziales nie znaczy ze tego nie ma. 

Ależ oczywiście, akademicko patrząc masz rację.

> Z tego
> co mi wiadomo wiekszosc kodu wbudowango wytworcy traktuja jako
> sekret.

No, sam kiedyś widziałem jak jeden kontroler miał kłódkę a nowu w innym 
komentarze były w bułgarskim. Fakt, traktują jak sekret. Nikt nie wie w 
czym się pisze w embedded. Nikt. Strasznie patrzeć na tych wszystkich 
programistów embedded których poznałem, albo lobotomia, albo 
elektrowstrząsy. Nikt nie wie w czym pisał, albo bezczelnie kłamie że w 
C/C++ albo czasem asm. Trafił sie nawet jeden fantasta że w Adzie, ale 
wiadomo że w Pascalu pisali. Ale pssst, to sekret.

>  Ja kodu w Pascalu nie widzialem, ale dotarlo do mnie
> pare w miare wiarygodnych informacji ze takowy byl rozwijany
> po roku 2000.

Z tego że nie widziałeś nie wynika że jest.

To że ktoś pisał miganie diodą po 2000 roku w Pascalu niewiele też 
wynika. Niektórzy pisali miganie diodą w Pythonie na uC. Też nic z tego 
nie wynika poza kilkoma religijnymi maniakami twierdzącymi że teraz to 
juz z górki.

>  Udzial w rynku sam w sobie jest malo istotny.
> Istotne jest czy rozwiazanie w konkretnym przypadu dziala
> i co mozna dzieki niemu zyskac.

No własnie. Skupmy się na tym. Co można zyskać z Pascala na uC czego nie 
można zyskać z C/C++ na uC?

A na marginesie udziału w rynku: ja też uważam że brainfuck powinien być 
brany pod uwagę, tym bardziej że ma 0 procent udziału w rynku embedded, 
więc musi być dobry.

> Dosc powazne studium bledow w programach w C stwierdzilo ze
> ok 25% bledow wykrytych po oddaniu programu to bylo bledne uzycie
> =, kiedy mialo byc == (przy tym studium dotyczylo starannie napisanych
> programow, z w miare niska srednia iloscia bledow). 

Serio? I to studium nie zauważyło metod zarządzania jakością w kodzie po 
latach 60tych? Skupili się na nieistotnym elemencie języka który od 
całej wieczności generuje ostrzeżenia w kompilatorach i który co 
najmniej od 20 lat nie stanowi żadnego argumentu? Sprawdziłeś czy ta 
książka jest po naszej erze? biory biblitek akademickich bywają czasem 
mocno przykurzone.

> W Pascalu
> bardzo trudno zrobic taki blad.

Wiadomo. Dlatego lepszy. I dlatego nikt go nie stosuje. Spisek, Panie.

>  Ale skladnia to tylko kawalek,
> semantyka C bazuje na operatorze adresu i arytmetyce wskaznikowej.

Zupełnie jak Pascal. Chyba że znasz w Pascalu jakieś magiczne sztuczki 
operowania na rejestrach peryferiów, manipulowania pamięcia w sterowniku 
LCD, wypełnianiu bufora dla DMA, czyli codzienność w uC.

> Prawie kazdy inny jezyk jawnie uzywa tablice.

Dawaj, zademonstruj jak wypełnić bufor w DMA pod konkretnym adresem w 
pamiecu uC BEZ używania semantyki adresowej, najlepiej bez adresu. Żeby 
magicznie było.

Ciekawe że mogę sobie napisać sementykę tablic w C++ działającą pod 
spodem na raw memory. Ale wiadomo, C++ jest niekoszerny. Pascal ino 
jest. Najlepiej Turbo.

>  Jest tez sprawa
> sprawdzania typow, Pascal to traktuje powazniej.

Zabawne bo C++ też. To gdzie ta zaleta nad C/C++ która powoduje że mam 
go traktować serio?

Podpowiem tylko na marginesie: jeśli chcesz język koszerny do embedded, 
który ma co najmniej jakąs zaletę nad C/C++ to obecnie uważa się za taki 
Adę. Nie żeby to była prawda bo już coś tam pierdykło spektakularnie z 
powodu debilizmu programistów, ale mimo to koszerne to jest, ludzie 
lubią jak porządne języki robią porządne fajerwerki. Plebs pisuje w C z 
Misra-C a jak wie co robi to bez Misra. Troche się miga diodami w C/C++. 
W Toyocie piszą zmiennymi globalnymi w języku ciężko rozpoznawalnym. Tyle.

On Friday, September 27, 2019 at 1:36:36 PM UTC-4, heby wrote:
> On 27/09/2019 15:49, antispam@math.uni.wroc.pl wrote:
> >>> Pan Mareczek pewnie nie wiedzial co mowi.  Ale mam wrazenie ze
> >>> ty tez nie wiesz co piszesz.  Jest pare sposobow zeby kod
> >>> Turbo Pascala przekompilowac na ARM-a.
> >> Niemo?liwe! A Brainfucka te? si? da? To czemu nie jest r?wniez brany pod
> >> uwag?? Tak on ?liczny, ameryka?ski!
> > OK, dziekuje za potwierdzenie: nie wiesz (albo cie nie obchodzi)
> > co piszesz.
> 
> Wręcz przeciwnie. Wiem doskonale. Z faktu że można skompilować pascala 
> na ARMa NIE WYNIKA że to jest sensowne i użyteczne. Nic z tego nie 
> wynika poza hobby.
> 
> >> Bywa?? Co najmniej od lat 80 nie pami?tam grama Pascala na systemach
> >> wbudowanych cho? oczywiscie nie widzia?em *wszystkich* system?w
> >> wbudowanych i niew?tpliwie z zachodnim Texasie na sterownikach automat?w
> >> do Coli m?g? taki faktycznie bangla?. Obecnie, jesli jest, to ma pewnie
> >> udzia? w rynku na poziomie szumu kwantowego.
> > To ze czegos nie widziales nie znaczy ze tego nie ma. 
> 
> Ależ oczywiście, akademicko patrząc masz rację.
> 
> > Z tego
> > co mi wiadomo wiekszosc kodu wbudowango wytworcy traktuja jako
> > sekret.
> 
> No, sam kiedyś widziałem jak jeden kontroler miał kłódkę a nowu w innym 
> komentarze były w bułgarskim. Fakt, traktują jak sekret. Nikt nie wie w 
> czym się pisze w embedded. Nikt. Strasznie patrzeć na tych wszystkich 
> programistów embedded których poznałem, albo lobotomia, albo 
> elektrowstrząsy. Nikt nie wie w czym pisał, albo bezczelnie kłamie że w 
> C/C++ albo czasem asm. Trafił sie nawet jeden fantasta że w Adzie, ale 
> wiadomo że w Pascalu pisali. Ale pssst, to sekret.
> 
> >  Ja kodu w Pascalu nie widzialem, ale dotarlo do mnie
> > pare w miare wiarygodnych informacji ze takowy byl rozwijany
> > po roku 2000.
> 
> Z tego że nie widziałeś nie wynika że jest.
> 
> To że ktoś pisał miganie diodą po 2000 roku w Pascalu niewiele też 
> wynika. Niektórzy pisali miganie diodą w Pythonie na uC. Też nic z tego 
> nie wynika poza kilkoma religijnymi maniakami twierdzącymi że teraz to 
> juz z górki.
> 
> >  Udzial w rynku sam w sobie jest malo istotny.
> > Istotne jest czy rozwiazanie w konkretnym przypadu dziala
> > i co mozna dzieki niemu zyskac.
> 
> No własnie. Skupmy się na tym. Co można zyskać z Pascala na uC czego nie 
> można zyskać z C/C++ na uC?
> 
> A na marginesie udziału w rynku: ja też uważam że brainfuck powinien być 
> brany pod uwagę, tym bardziej że ma 0 procent udziału w rynku embedded, 
> więc musi być dobry.
> 
> > Dosc powazne studium bledow w programach w C stwierdzilo ze
> > ok 25% bledow wykrytych po oddaniu programu to bylo bledne uzycie
> > =, kiedy mialo byc == (przy tym studium dotyczylo starannie napisanych
> > programow, z w miare niska srednia iloscia bledow). 
> 
> Serio? I to studium nie zauważyło metod zarządzania jakością w kodzie po 
> latach 60tych? Skupili się na nieistotnym elemencie języka który od 
> całej wieczności generuje ostrzeżenia w kompilatorach i który co 
> najmniej od 20 lat nie stanowi żadnego argumentu? Sprawdziłeś czy ta 
> książka jest po naszej erze? biory biblitek akademickich bywają czasem 
> mocno przykurzone.
> 
> > W Pascalu
> > bardzo trudno zrobic taki blad.
> 
> Wiadomo. Dlatego lepszy. I dlatego nikt go nie stosuje. Spisek, Panie.
> 
> >  Ale skladnia to tylko kawalek,
> > semantyka C bazuje na operatorze adresu i arytmetyce wskaznikowej.
> 
> Zupełnie jak Pascal. Chyba że znasz w Pascalu jakieś magiczne sztuczki 
> operowania na rejestrach peryferiów, manipulowania pamięcia w sterowniku 
> LCD, wypełnianiu bufora dla DMA, czyli codzienność w uC.
> 
> > Prawie kazdy inny jezyk jawnie uzywa tablice.
> 
> Dawaj, zademonstruj jak wypełnić bufor w DMA pod konkretnym adresem w 
> pamiecu uC BEZ używania semantyki adresowej, najlepiej bez adresu. Żeby 
> magicznie było.
> 
> Ciekawe że mogę sobie napisać sementykę tablic w C++ działającą pod 
> spodem na raw memory. Ale wiadomo, C++ jest niekoszerny. Pascal ino 
> jest. Najlepiej Turbo.
> 
> >  Jest tez sprawa
> > sprawdzania typow, Pascal to traktuje powazniej.
> 
> Zabawne bo C++ też. To gdzie ta zaleta nad C/C++ która powoduje że mam 
> go traktować serio?
> 
> Podpowiem tylko na marginesie: jeśli chcesz język koszerny do embedded, 
> który ma co najmniej jakąs zaletę nad C/C++ to obecnie uważa się za taki 
> Adę. Nie żeby to była prawda bo już coś tam pierdykło spektakularnie z 
> powodu debilizmu programistów, ale mimo to koszerne to jest, ludzie 
> lubią jak porządne języki robią porządne fajerwerki. Plebs pisuje w C z 
> Misra-C a jak wie co robi to bez Misra. Troche się miga diodami w C/C++. 
> W Toyocie piszą zmiennymi globalnymi w języku ciężko rozpoznawalnym. Tyle.

Tak się przglądam tej dyskusji i cos mi sie wydaje, że anti..@math.uni.wroc.pl nie widział żadnego oprogramowania przemysłowego poza uczelnią. Paru piszących tu właczając w to szanownego kolegę stara mu się wytłumaczyc jak to robią "big boys and girls" ale to nie trafia. 
Njaśmieszniejsze jest to, że on ma trochę racji o nie pisaniu C/C++ tylko on o tym nie wie. W przemyśle zajmującymi sie rzeczami jeżdzącymi masa nowego oprogramowania krytycznego (nie mówie tu o systemach mutimedialnych ale a naprawdę krytycznym  oprogramowaniu np. kontroler ABS, ECU, DriveByWire) pisze sie w Mathlab/Simulink i to jest transpilowane do C. Tak latwiej mozna udowodnic i przetestowac poprawnosc logiki - jest masa oprogramowania automatatyzujaca to zadanie.
Natomiast jeśli kolegi dyskutant nadal chce używac Paskala do kontrolerow to polecam Siemens SCL na sterowniki S7 - wyglada prawie jak Paskal - ma begin end i nawet koszerny operator przypisania :=   ;-)

On 2019-09-27 19:36, heby wrote:
> No własnie. Skupmy się na tym. Co można zyskać z Pascala na uC czego nie 
> można zyskać z C/C++ na uC?

Na pewno mozna uzyskac o wiele lepsza kontrole typow (co za tym idzie
mniejsza bledogennosc) niz w C.
W sensie jakosci/optymalnosci kodu _nie ma praktycznie zadnych roznic_
w stosunku do C.

PS: Tylko prosze o powazne ew. kontrargumenty bo w Pascalu pisalem
jeszcze na Odrze (1305), ze PC-tach, czyli o TurboPascalu, MS Pascalu
czy NDP Pascalu nie wspomne.

AK

On 2019-09-27 20:57, Adam M wrote:
> Natomiast jeśli kolegi dyskutant nadal chce używac Paskala do kontrolerow to polecam
> Siemens SCL na sterowniki S7 - wyglada prawie jak Paskal - ma begin end i nawet
> koszerny operator przypisania :=   ;-)

Owszem. Siemens to ma (i baardzo dobrze), ale jednak wiekszosc
automatyki jest ciagle w sredniowieczu w sensie inzynierii programowania
i smierdzace assemblerem "ladery" uwaza za szczytowe osiagniece :)

AK

On 28/09/2019 20:01, AK wrote:
>> No własnie. Skupmy się na tym. Co można zyskać z Pascala na uC czego 
>> nie można zyskać z C/C++ na uC?
> Na pewno mozna uzyskac o wiele lepsza kontrole typow (co za tym idzie
> mniejsza bledogennosc) niz w C.

A w C++?

> W sensie jakosci/optymalnosci kodu _nie ma praktycznie zadnych roznic_
> w stosunku do C.

Czyli posiadając C++ który ową kontrolę typów załatwia - pisanie w 
Pascalu mija się z celem bo nie zostaje już nawet ślad killer ficzera.

> PS: Tylko prosze o powazne ew. kontrargumenty bo w Pascalu pisalem
> jeszcze na Odrze (1305), ze PC-tach, czyli o TurboPascalu, MS Pascalu
> czy NDP Pascalu nie wspomne.

Ja zaś pisałem w asm 6502, Z80 że o x86 nawet nie wspomnę. Czy taki 
argument jest okay żeby twierdzić o dominacji asm w dziedzinie embedded?

AK <nobody@nowhere.net> Wrote in message:
> Na pewno mozna uzyskac o wiele lepsza kontrole typow (co za tym idziemniejsza bledogennosc) niz w C.

Dyscyplina typów nie jest istotna. To tak, jakby twierdzić że
 język polski jest do niczego, bo przedimków nie ma. W Pythonie
 można łatwo zrobić błąd bo nie ma ani kontroli typów, ani
 deklaracji zmiennych. Ale za to programy są zwięzłe i czytelne. W
 C++ są deklaracje, kontrola typów... ale programy są mniej
 czytelne, dłuższe, łatwo o wyciek pamięci i niewątpliwie niższy
 poziom abstrakcji.

>W sensie jakosci/optymalnosci kodu _nie ma praktycznie zadnych roznic_w stosunku do C.PS: Tylko prosze o powazne ew. kontrargumenty bo w Pascalu pisalemjeszcze na Odrze (1305), ze PC-tach, czyli o TurboPascalu, MS Pascaluczy NDP Pascalu nie wspomne.

W sensie... C ma i miał wskaźniki z arytmetyką i dynamiczne
 tablice robione przez malloc itp. Pascal na Odrze 1305 nie miał
 tego. Pascal nie ma arytmetyki wskaźników. C++ ma dziedziczenie
 wielobazowe i szablony, Delphi tego brakuje. Był p2c, ale nie
 c2p.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

On Sun, 29 Sep 2019 08:12:49 +0200 (GMT+02:00), slawek wrote:

> W sensie... C ma i miał wskaźniki z arytmetyką i dynamiczne
>  tablice robione przez malloc itp. Pascal na Odrze 1305 nie miał
>  tego. Pascal nie ma arytmetyki wskaźników. C++ ma dziedziczenie
>  wielobazowe i szablony, Delphi tego brakuje. 

Delphi ma generyki i helpery, C++ nie ma. I ma rekordy z metodami.

> Był p2c, ale nie c2p.

https://wiki.freepascal.org/C_to_Pascal
https://github.com/WouterVanNifterick/C-To-Delphi

-- 
pozdrawiam
Roman Tyczka

> Podpowiem tylko na marginesie: jeśli chcesz język koszerny do embedded, 
> który ma co najmniej jakąs zaletę nad C/C++ to obecnie uważa się za taki 
> Adę. Nie żeby to była prawda bo już coś tam pierdykło spektakularnie z 
> powodu debilizmu programistów

A cóż takiego pierdykło w Adzie z powodu debilizmu programistów?

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

On 30/09/2019 09:21, Maciej Sobczak wrote:
>> Podpowiem tylko na marginesie: jeśli chcesz język koszerny do embedded,
>> który ma co najmniej jakąs zaletę nad C/C++ to obecnie uważa się za taki
>> Adę. Nie żeby to była prawda bo już coś tam pierdykło spektakularnie z
>> powodu debilizmu programistów
> A cóż takiego pierdykło w Adzie z powodu debilizmu programistów?

Arine 5. "Steve, słuchaj, kończy nam się pamięć, to może olejemy te 
testy, co? Przecież wszystko zmieści się na bank w 16 bitach a Ada jest 
taka bezpieczna że sobe pewno da radę".

Pisanie w asm jest możliwe w każdym języku.

On 2019-09-30 18:33, heby wrote:
> On 30/09/2019 09:27, Maciej Sobczak wrote:
>> Spróbuj rozwiązać ten problem i wtedy zobaczysz, że nie trzeba 3 
>> kompilatorów. Dlatego tej metody się nie używa.
> 
> Zabawne, bo w kilku krytycznych miejscach i za duże pieniądze się używa. 
> Firmy kupują choelrnie drogi soft robiący to samo, ale od różnych 
> producentów tylko po to aby się upewnić że działanie ich kodu jest 
> zamierzone a nie tylko że to artefakt narzędzia.

Hehe. Gdy sie wybralo takie nieweryfikowalne barachlo jak C/C++
do rzeczy krytycznych, to sie trzeba pozniej takimi "technikami
weryfikacji" podpierac :)

AK

> > A cóż takiego pierdykło w Adzie z powodu debilizmu programistów?
> 
> Arine 5. "Steve, słuchaj, kończy nam się pamięć, to może olejemy te 
> testy, co? Przecież wszystko zmieści się na bank w 16 bitach a Ada jest 
> taka bezpieczna że sobe pewno da radę".

Czyli nie czytałeś raportu z analizy tej katastrofy.
Na pocieszenie: mało który internetowy "ekspert" czytał.

Skrót jest taki: w Ariane 5 wykorzystano moduł opracowany dla Ariane 4, czyli pod inne wymagania. Programiści, którzy ten moduł napisali, zrobili swoją robotę tak jak trzeba - w sensie, ten moduł był poprawny względem wymagań, dla których był pisany i nawet w nowych warunkach zachował się dokładnie tak, jak był zaprojektowany. Natomiast decyzję o wykorzystaniu tego modułu w innej rakiecie podjęli ludzie, których czasem się nazywa "inżynier systemowy" i którzy zwykle w ogóle sami siebie nie określiliby mianem "programista", bo na tym poziomie jest to określenie pogardliwe.

Wniosek: to nie pierdykło z powodu programistów, ani tym bardziej z powodu ich domniemanego przez Ciebie debilizmu. Więc trochę odpuść z tonu.

Hint: gdybyś był tam *programistą*, to też by pierdykło, bo miałbyś w tej sprawie dokładnie tyle samo do powiedzenia, co ci programiści, którzy to faktycznie wtedy robili.

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

Maciej Sobczak <see.my.homepage@gmail.com> Wrote in message:
> >Wyniki obliczeń tej funkcji nie będą zależeć od kompilatora i to niezależnie czy będzie tych kompilatorów 3 czy 33.W Twoim rozumowaniu jest błąd.

Teoretycznie masz rację. W praktyce niewiele umiesz.

Jeżeli masz trzy zupełnie różne kompilatory to niekoniecznie są
 one bezbłedne - te kompilatory - nie twój program. Podobnie z
 numeryką - wyniki obliczone na PIC mogą różnić się od tych
 obliczonych na Ryzenie... nawet jeżeli nie ma bugów w mikrokodzie
 to po prostu inna ilość bitów mantysy.

Dlatego monokultura - ein język, ein system, ein hardware - jest
 bardzo szkodliwa. 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

Roman Tyczka <noemail@because.no> Wrote in message:
> Delphi ma generyki i helpery, C++ nie ma. I ma rekordy z metodami.

Ajtam. Akurat C++ niezbyt mi się podoba - choć doceniam i używałem
 - zwłaszcza bez plusów (choć obiektowo, bo w czystym C też się
 tak da, tylko trzeba umieć).

C++ ma STL i templates, więc generyki Delphi trochę cienko
 wyglądają przy tym. Zwłaszcza że w C++ mamy i wielobazowość, i
 l-value references... a nawet preprocesor z #define którego
 próżno szukać w paszczalersach.

Rekordy z metodami...?!? Czy to nie przypadkiem nie nazywa się
 obiekty klas (nota bene zamiast class można pisać
 struct)...?

A może chciałeś napisać rekordy z wariantami? W C i C++ robi się
 to jako unię struktur, ew. strukturę zawierającą unię
 struktur.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

On Tue, 1 Oct 2019 20:40:17 +0200 (GMT+02:00), slawek wrote:

>> Delphi ma generyki i helpery, C++ nie ma. I ma rekordy z metodami.
> 
> Ajtam. Akurat C++ niezbyt mi się podoba - choć doceniam i używałem
>  - zwłaszcza bez plusów (choć obiektowo, bo w czystym C też się
>  tak da, tylko trzeba umieć).
> 
> C++ ma STL i templates, więc generyki Delphi trochę cienko
>  wyglądają przy tym. 

Razem ze Spring4D całkiem nieźle sobie te generyki radzą. Może nie urywają
dupy, ale żeby cienko to nie.

https://bitbucket.org/sglienke/spring4d/wiki/Home

> Zwłaszcza że w C++ mamy i wielobazowość, i
>  l-value references... a nawet preprocesor z #define którego
>  próżno szukać w paszczalersach.
> 
> Rekordy z metodami...?!? Czy to nie przypadkiem nie nazywa się
>  obiekty klas (nota bene zamiast class można pisać
>  struct)...?

TInteger = record
private
  fValue : Integer;
public
  function GetValue : Integer;
end;
 
> A może chciałeś napisać rekordy z wariantami? 

Raczej niekoniecznie.

-- 
pozdrawiam
Roman Tyczka

Roman Tyczka <noemail@because.no> Wrote in message:
> TInteger = recordprivate  fValue : Integer;public  function GetValue : Integer;end;

W starym C bez plusów:

#define Getter(s) (s->GetValue(s))
struct TInteger { int fValue; int (*GetValue)(TInteger); } s;
 s.GetValue = &GetValue;
...
y = Getter(s)

W C++ są oczywiście klasy, a w C# ponadto properties.

Jak tak dobrze znasz Pascala jak ci się wydaje - to napisz nam
 maluczkim - jak w Pascalu będzie takie coś z Pythona:

@controlled
def fun(*args):
    return filter(eggs, map(spam, args))


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

On 2019-10-01 20:40, slawek wrote:
> Roman Tyczka <noemail@because.no> Wrote in message:
>> Delphi ma generyki i helpery, C++ nie ma. I ma rekordy z metodami.
> 
> Ajtam. Akurat C++ niezbyt mi się podoba - choć doceniam i używałem
>   - zwłaszcza bez plusów (choć obiektowo, bo w czystym C też się
>   tak da, tylko trzeba umieć).
> 
> C++ ma STL i templates

C++ templates to poprostu _jeden wielki syf_ (taki rozbuchany
preprocessor). Np. w stosunku do Javowych czy C# generyk.
PS: W stosunku do Delphowych generyk tez..

> Rekordy z metodami...?!? Czy to nie przypadkiem nie nazywa się
>   obiekty klas (nota bene zamiast class można pisać
>   struct)...?

Nie. Nie mozna uzyc 'class' jako zamiennika rekordow z metodami.
(formalnie 'struct' tez nie.. Doucz sie C/C++ _praktycznie_,
a nie z uczelnianej ex catedra).

AK

On 2019-10-02 07:50, slawek wrote:
> Roman Tyczka <noemail@because.no> Wrote in message:
>> TInteger = recordprivate  fValue : Integer;public  function GetValue : Integer;end;
> 
> W starym C bez plusów:
> 
> #define Getter(s) (s->GetValue(s))
> struct TInteger { int fValue; int (*GetValue)(TInteger); } s;
>   s.GetValue = &GetValue;
> ....
> y = Getter(s)

Przestan nas rozsmieszac :)

> W C++ są oczywiście klasy, a w C# ponadto properties.

No wlasnie. Gdzie w tym wspanialym C++ sa (jakze uzyteczne)
properties?

> Jak tak dobrze znasz Pascala jak ci się wydaje - to napisz nam
>   maluczkim - jak w Pascalu będzie takie coś z Pythona:
> 
> @controlled
> def fun(*args):
>      return filter(eggs, map(spam, args))

Wez sie doucz Pythona.
filter i map juz dawno sa (delikatnie mowiac) niezalecane.

AK

On Wed, 2 Oct 2019 07:50:20 +0200 (GMT+02:00), slawek wrote:

>> TInteger = recordprivate  fValue : Integer;public  function GetValue : Integer;end;
> 
> W starym C bez plusów:
> 
> #define Getter(s) (s->GetValue(s))
> struct TInteger { int fValue; int (*GetValue)(TInteger); } s;
>  s.GetValue = &GetValue;
> ...
> y = Getter(s)

Mega czytelna rzecz, klękam
 
> W C++ są oczywiście klasy, a w C# ponadto properties.

C# properties ma podebrane z ...Delphi.
 
> Jak tak dobrze znasz Pascala jak ci się wydaje - to napisz nam
>  maluczkim - jak w Pascalu będzie takie coś z Pythona:
> 
> @controlled
> def fun(*args):
>     return filter(eggs, map(spam, args))
> 

function fun(args : IList<T>) : IEnumerable<T>;
begin
  result := args.ForEach(spam).Any(eggs);
end;

Zdziweczko?

-- 
pozdrawiam
Roman Tyczka

AK <nobody@nowhere.net> Wrote in message:
> Gdzie w tym wspanialym C++ sa (jakze uzyteczne)properties?

A wuj wie. Przecież nie jestem fanbojem C++. W C# są. A sam fakt
 że jaśniepan musi parę nawiasów napisać to dla kodera
 korporacyjnego żaden problem - choć faktycznie, klawiatura się
 nieco bardziej zużywa.

> Wez sie doucz Pythona.filter i map juz dawno sa (delikatnie mowiac) niezalecane.AK

Primo, podaj źródło tych swoich objawień. Może numer PEP, może
 jakiś artykuł z Bajtka lub Trans. ACM?

Secundo, wic był nie w filter i/lub map - ale w dekoratorze.
 Gratuluję spostrzegawczości i dogłębnej znajomości Pythona.
 

No to miśki - jak wydziergacie dekorator - skoro Pascal nie ma
 first class functions?



-- 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

On 01/10/2019 08:27, AK wrote:
>> Zabawne, bo w kilku krytycznych miejscach i za duże pieniądze się 
>> używa. Firmy kupują choelrnie drogi soft robiący to samo, ale od 
>> różnych producentów tylko po to aby się upewnić że działanie ich kodu 
>> jest zamierzone a nie tylko że to artefakt narzędzia.
> Hehe. Gdy sie wybralo takie nieweryfikowalne barachlo jak C/C++
> do rzeczy krytycznych, to sie trzeba pozniej takimi "technikami
> weryfikacji" podpierac :)

Trzeba się nimi podpierać ponieważ niezwykle mało rzeczy na tym świecie 
jest formalnie zweryfikowane a w dodatku nawet jaki jest to bywa że 
tylko teoretycznie. Przykładowo można sobie w d... wsadzić jądro L4 z 
całą ich weryfikacją jak się okaże że CPU ma buga sprzętowego.

On 01/10/2019 09:15, Maciej Sobczak wrote:
>> Arine 5. "Steve, słuchaj, kończy nam się pamięć, to może olejemy te
>> testy, co? Przecież wszystko zmieści się na bank w 16 bitach a Ada jest
>> taka bezpieczna że sobe pewno da radę".
> Czyli nie czytałeś raportu z analizy tej katastrofy.

Ależ czytałem. Nie inputuj.

> Na pocieszenie: mało który internetowy "ekspert" czytał.
> Skrót jest taki: w Ariane 5 wykorzystano moduł opracowany dla Ariane 4, czyli pod inne wymagania.

I nikt go pod te wymagania nie testował. Wiadomo, prawdziwego 
programiste poznać na tym że raz napisze i już.

> Natomiast decyzję o wykorzystaniu tego modułu w innej rakiecie podjęli ludzie, których czasem się nazywa "inżynier systemowy"

Słusznie. "inzynier syatemowy" bowiem zakłada magiczność Ady i niajk nie 
potrafi sobie wyobrazić że ktoś może używać jej jako asemblera zaś 
ludzie z zespołu programistów nagle musieli lecieć do kibla i nikt nie 
protestował.

Jeśli się upierasz że winę nie ponosi ktoś kto napisał kiepską funkcję 
tylko jakiś pierdzący w stołek dyrektor to może spuśćmy zasłonę 
milczenia na to jak zakończą się następne projekty tego teamu skoro 
decyzje o użyciu kodu wykonuje się bez twórców i testów.

> Wniosek: to nie pierdykło z powodu programistów

Bzdura. Ktoś, powtórze to jeszcze raz, użył Ady jako assemblera. I można 
to zrobic w dowolnym języku. Czyli można pisać gównany kod w Adzie i 
znakomity w C. Wszystko zależy od progamistów i ich religijności a w 
zasadzie jej braku. Ale znacznie bardziej zależy od metod weryfikacji.

Kod który zakłada że "wynik obliczeń na pewno zmieści się w typie int16 
alnie nie testujemy bo nie chce nam się" jest do dupy z definicji. 
Choćby dlatego że w takim wypadku używa się arytmetyki z saturacją jesli 
ma wystapić niemożliwe. A tu najzwyczajniej w "bezpiecznym języku" 
odpierdolono byle jak.

> Hint: gdybyś był tam *programistą*, to też by pierdykło, bo miałbyś w tej sprawie dokładnie tyle samo do powiedzenia

Miałbym do powiedzenia znacznie więcej. Na przykład to że jezyk 
programowania jest DOKŁADNIE tak bezpieczny jak metody do jego 
weryfikacji których tutaj nie było.

Ada pokazuje że można z bezpiecznego języka zrobić takie same fajerwerki 
jak z pisania w C.

Całośc bredzenia o wyższości jakiejś składni nad inną składnią jest 
śmieszna. Zawsze podstawowe pytanie brzmi: czy kod jest zweryfikowany, 
poddany testom, ma pokrycie coverage które definiuje jakiś poziom ryzyka.

A tutaj sobie jakiś misio wrzuca kod z jednego systemu do drugiego. W 
BEZPIECZNYM języku, wiec na pewno nic się nie stanie. Bum. No cóż, życie.

On 2019-10-03 07:57, slawek wrote:
> AK <nobody@nowhere.net> Wrote in message:
>> Gdzie w tym wspanialym C++ sa (jakze uzyteczne)properties?
> 
> A wuj wie. Przecież nie jestem fanbojem C++. W C# są. A sam fakt
>   że jaśniepan musi parę nawiasów napisać to dla kodera
>   korporacyjnego żaden problem - choć faktycznie, klawiatura się
>   nieco bardziej zużywa.

Nie masz pojecia po co sa properties.

>> Wez sie doucz Pythona.filter i map juz dawno sa (delikatnie mowiac) niezalecane.AK
> 
> Primo, podaj źródło tych swoich objawień. Może numer PEP, może
>   jakiś artykuł z Bajtka lub Trans. ACM?

Sam ze znajdz.

> Secundo, wic był nie w filter i/lub map - ale w dekoratorze.
>   Gratuluję spostrzegawczości i dogłębnej znajomości Pythona.

Nie o dekoratory chodzi ale o comprehensions

>   
> No to miśki - jak wydziergacie dekorator - skoro Pascal nie ma
>   first class functions?

First class nie ma _zaden_ z "maistreamowych" jezykow.
Java i C# (ogolne .NET) maja bardzo porzadne reflection.
C++ nie ma nawet tego (klas jest kawalkiem tekstu).

AK

On 2019-10-03 20:25, heby wrote:
> Ada pokazuje że można z bezpiecznego języka zrobić takie same fajerwerki 
> jak z pisania w C.

Tak. Tyle tylko, ze _prawdopodobienstwo_ zrobienia buga w Adzie jest o
ile tak procent/rzedow mniejsze niz w slawetnym C/C++.

_I o to w tym wszytskim chodzi_ ! :)

AK

On 03/10/2019 22:01, AK wrote:
> Tak. Tyle tylko, ze _prawdopodobienstwo_ zrobienia buga w Adzie jest o
> ile tak procent/rzedow mniejsze niz w slawetnym C/C++.
> _I o to w tym wszytskim chodzi_ ! :)

I jak zapewne zauważyłeś nie dyskutuje z tą opinią bo jest ona prawdziwa.

Nieprawdziwa jest opinia że Ada jest bezpieczna bo język utrudnia 
robienie błedów.

Nie, soft jest tak bezpieczny jak dobrze jest przetestowany. Rodzaj 
wybranego języka co najwyżej determinuje narzędzia uzyte w procesie 
weryfikacji i komfort pisania. Czy Ada czy Asm na końcu i tak chodzi 
tylko o to jak zweryfikowaliśmy to co napisaliśmy.

On 2019-10-03 22:19, heby wrote:
> Nieprawdziwa jest opinia że Ada jest bezpieczna bo język utrudnia 
> robienie błedów.

Jak juz ustalilismy _nie ma_ (i nie bedzie) jezykow w pelni
bezpiecznych (wszytskim rzadzi prawdopodobienstwo).

Czy Ci sie to podoba czy nie, Ada jest jednak _najbezpieczniejszym_
jezykiem programowania. O (kilka?)rzad wielkosci bezpieczniejszym
od C/C++ czy nawet Pascala.

W dodatku ten jezyk (przez swoj "ekosystem" - weryfikowalnosc jezyka,
weryfikowalnosc kompilatorow - o dziwo jedna z przyczyn "upadku" Ady;)
jako jeden z nielicznych daje mozliwosc weryfikowalnosci programow
(czyli sprawdzalnosci kodu w stosnku do zalozen/projektu).

Stawianie wiec Ady na rowniz z C/C++ czy assemblerem jest po prostu
horrendum... :(

AK

On 04/10/2019 08:16, AK wrote:
> Czy Ci sie to podoba czy nie, Ada jest jednak _najbezpieczniejszym_
> jezykiem programowania. O (kilka?)rzad wielkosci bezpieczniejszym
> od C/C++ czy nawet Pascala.

Nikt nie twierdzi inaczej.

> Stawianie wiec Ady na rowniz z C/C++ czy assemblerem jest po prostu
> horrendum... :(

I nikt jej tutaj nie stawia. Wskazuje jednak palcem że możesz sobie 
wybrać dowolny język weryfikowalny po zęby i dalej mieć bugi. Co usilnie 
religia Adowców próbuje wciskać do głów managerów to opinia jakoby 
magicznie rozwiązują się wszelakie problemy inżynierii programowania i 
weryfikacji kodu. Najwidoczniej wyjatkowo dobrze zadziałało to z 
Ariane5. Wolałbym też aby na tej religii nie był projektowany respirator 
którego może będę musiał kiedyś użyć.

AK <nobody@nowhere.net> Wrote in message:
> Nie o dekoratory chodzi ale o comprehensions

Ale wiesz że dotyczyło to Pythona 2? I że - pomimo paniki GvR że
 Python zamieni się w Lisp - w Pythonie są nadal filter i map, a
 jakby nawet nie było to wystarczą dwie linijki i tyle po
 wysiłkach purystów. I że [f(x) for x in L if f(x)] to akurat
 trochę nie zachęca?

Comprehensions to rozwiązanie rodem z write(2,100) (A(j),
 j=2,2,N). Poznajesz język? 

>   > No to miśki - jak wydziergacie dekorator - skoro Pascal nie ma
>   first class functions?First class nie ma _zaden_ z "maistreamowych" jezykow.Java i C# (ogolne .NET) maja bardzo porzadne reflection.C++ nie ma nawet tego (klas jest kawalkiem tekstu).AK

Przypadkiem są w Javascript (trudno o bardziej "mainstreamowy" -
 nie!mal każda strona WWW jest tym nadziana). Python też nie jest
 jakąś wściekłą egzotyką, no chyba że dla leśnych
 dziadków.


-- 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

heby <heby@poczta.onet.pl> Wrote in message:
> Wskazuje jednak palcem że

Zacytuję dyskusję jaka była około 40 lat temu:

X: Fortran jest do bani, bo wystarczy zmienić jeden znak -
 przecinek na kropkę - i pętla się nie wykona - Pascal jest
 beeezpieeeczny

        DO 10 K=1.50
  10  CALL BUZ

Y: A co - w Pascalu też się da - wystarczy np.

         for i:= 1 to 50 do;
               buz;


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

On 2019-10-04 21:10, slawek wrote:
> Tyle że są takie problemy że nie ma jak
>   robić unit testów. Nie wiadomo ile powinno wyjść.

Ano wlasnie :)

AK

On 2019-10-04 20:26, heby wrote:
> Ten problem (czyli pomyłka mnożenia z dodawaniem) rozwiazuje każda 
> kolejna warstwa inżynierii programowania od co najmniej 50 lat. Od unit 
> testów, przez code review po testy integracyjne, wszędzie zostanie 
> wyłapana z dokładnością do asymptoty. Na 99% bug taki zostanie wyłapany 
> już w unit testach, przynajmniej u mnie i zaryzykuje że w każdym 
> poważniejszym programowaniu. Jeśli Ci się wydaje że o takie błedy chodzi 
> wybierając kilka kompilatorów to naprawdę postaraj się zakładać że 
> rozmówcy nie są idiotami i od razu będzie lepiej.

Powinienies napisac: "wydaje mi sie".
Bo naprawde Ci sie tylko wydaje.
PS: No a co z tym 1% ?

AK

On 05/10/2019 07:04, AK wrote:
>> Ten problem (czyli pomyłka mnożenia z dodawaniem) rozwiazuje każda 
>> kolejna warstwa inżynierii programowania od co najmniej 50 lat. Od 
>> unit testów, przez code review po testy integracyjne, wszędzie 
>> zostanie wyłapana z dokładnością do asymptoty. Na 99% bug taki 
>> zostanie wyłapany już w unit testach, przynajmniej u mnie i zaryzykuje 
>> że w każdym poważniejszym programowaniu. Jeśli Ci się wydaje że o 
>> takie błedy chodzi wybierając kilka kompilatorów to naprawdę postaraj 
>> się zakładać że rozmówcy nie są idiotami i od razu będzie lepiej.
> Powinienies napisac: "wydaje mi sie".

Nie. To jest codzienność mojej pracy.

> Bo naprawde Ci sie tylko wydaje.

Nie.

> PS: No a co z tym 1% ?

Jest zarządzany ryzykiem. Jeśli migasz diodą i to jest clue projektu to 
może zostać. Jeśli sterujesz respiratorem to go wyeliminujesz tą bądź 
inną metodą testowania. Zarządzanie ryzykiem to obecnie spory fragment 
rynku weryfikacji. Bardzo bogatego rynku.

> Ten problem (czyli pomyłka mnożenia z dodawaniem) rozwiazuje każda 
> kolejna warstwa inżynierii programowania od co najmniej 50 lat. Od unit 
> testów, przez code review po testy integracyjne,

No wreszcie.

> Jeśli Ci się wydaje że o takie błedy chodzi 
> wybierając kilka kompilatorów to naprawdę postaraj się zakładać że 
> rozmówcy nie są idiotami i od razu będzie lepiej.

Niczego nie zakładam o rozmówcach przez pierwsze kilka postów. Potem oceniam na podstawie tego, co przeczytałem. Niektórzy dyskutują niechlujnie i wtedy wpadają do tego samego worka co ci, którzy są po prostu idiotami. Sorry, ale lepszego i bardziej otwartego na drugiego człowieka systemu nie znam.

No więc - skoro już poprawiliśmy tą naszą funkcję, to jaka jest wartość dodana z użycia kilku kolejnych kompilatorów?
Bo tego cały czas nie pokazałeś. Wiemy tylko, że "w dużych firmach", czy jakoś tam. Ale tak konkretnie, po co?

> Kiedy już te i masę innych etapów weryfikacji przejdziezsz po drodze 
> ktos zapyta czy dajesz wiarę w kompilator.

I tu jest cały trick. Kompilator nie jest celem ani centrum tego ćwiczenia. Celem (i ostatecznym produktem) jest kod wynikowy - a jego poprawność właśnie wykazaliśmy wszystkimi tymi metodami, o których wspomniałeś.

Czyli mamy poprawny kod wynikowy.

Więc po co kolejne kompilatory?

> Istnieją ryzyka gdzie nie można zaufa kompilatorowi. 

Ależ ja mu ani przez chwilę nie ufałem. Ani przez mikrosekundę.
Ale też nie on jest w centrum uwagi. Więc?

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

heby <heby@poczta.onet.pl> Wrote in message:
> On 05/10/2019 07:04, AK wrote:>> Ten problem (czyli pomyłka mnożenia z dodawaniem) rozwiazuje każda >> kolejna warstwa inżynierii programowania od co najmniej 50 lat. Od >> unit testów, przez code review po testy integracyjne, wszędzie >> zostanie wyłapana z dokładnością do asymptoty. Na 99% bug taki >> zostanie wyłapany już w unit testach, przynajmniej u mnie i zaryzykuje >> że w każdym poważniejszym programowaniu. Jeśli Ci się wydaje że o >> takie błedy chodzi wybierając kilka kompilatorów to naprawdę postaraj >> się zakładać że rozmówcy nie są idiotami i od razu będzie lepiej.> Powinienies napisac: "wydaje mi sie".Nie. To jest codzienność mojej pracy.> Bo naprawde Ci sie tylko wydaje.Nie.> PS: No a co z tym 1% ?Jest zarządzany ryzykiem. Jeśli migasz diodą i to jest clue projektu to może zostać. Jeśli sterujesz respiratorem to go wyeliminujesz tą bądź inną metodą testowania. Zarządzanie ryzykiem to obecnie spory fragment rynku weryfikacji. Bardzo bogatego rynku.

Ale wiesz kiedy i do czego zastosowano HAZARD po raz pierwszy?
-- 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

On 05/10/2019 22:13, slawek wrote:
> Ale wiesz kiedy i do czego zastosowano HAZARD po raz pierwszy?

To słowo ma kilka zastosowań w IT w tym ma również zastosowanie w 
weryfikacji dlatego określ o które z nich Ci chodzi.

On 05/10/2019 22:12, Maciej Sobczak wrote:
> No więc - skoro już poprawiliśmy tą naszą funkcję, to jaka jest wartość dodana z użycia kilku kolejnych kompilatorów?

Bardzo prosta. Twój kompilator w poprawnej funkcji dodawania przypadkiem 
zrobił mnożenie kiedy x=15 i y=90. Shit happens. Czasem to tylko mignie 
szybciej diodą a czasem wyśle samolot w kierunku gruntowym.

> Bo tego cały czas nie pokazałeś.

No więc wyobraź sobie sytuację w któej unit testy posiadają 
asymptotycznie pokrycie w 100% zgodne z testplanem.

A kod działa przypadkiem tylko dlatego że kompilator w jakimś miejscu 
zamiast referencji użył wartości. W kodzie produkcyjnym użyje referencji 
bo tak wyszło kompliatorowi. I wykryje buga na produkcji załączając 
odwracacz ciągu w powietrzu.

Dodając dodatkowe narzędzia weryfikacyjne (tak, w tym wypadku kompilator 
jest takim narzędziem) możesz zrealizować nastepne poziomy weryfikacji 
kodu które wynikają z wymogów bezpieczeństwa. I może, dzięki szczęściu, 
błąd wykryjesz. Bo w pewnym momencie niestety kończą się środki formalne 
a zaczynają statystyczne.

> Wiemy tylko, że "w dużych firmach", czy jakoś tam. Ale tak konkretnie, po co?

Aby zweryfikować narzędzia do weryfikacji. Ponieważ nie potrafimy tego 
robić formalnie ani pewnie, pozostaje weryfikacja statystyczna. 
Najprościej poprzez użycie podobnych bądź identycznych narzędzi kilku 
róznych firm w celu analizy różnicowej.

>> Kiedy już te i masę innych etapów weryfikacji przejdziezsz po drodze
>> ktos zapyta czy dajesz wiarę w kompilator.
> I tu jest cały trick. Kompilator nie jest celem ani centrum tego ćwiczenia.

Jest narzędziem które odpowiada na pytanie czy kod działa czy nie. Jesli 
odpowie źle to możesz sobie całe to unit testowanie wsadzić w dupę. 
Czasami odpowiada źle.

> Celem (i ostatecznym produktem) jest kod wynikowy - a jego poprawność właśnie wykazaliśmy wszystkimi tymi metodami, o których wspomniałeś.

Nie. Wykazałeś że w jakiś warunkach Twój kod działa. A czy to te same 
warunki kiedy będzie używany produkcyjnie?

Nie da się tego stwierdzić. Dlatego używa się croos-checków. To jest 
BARDZO powszechna praktyka w symulacjach HDL i spotykana praktyka w 
programowaniu tradycyjnym.

> Czyli mamy poprawny kod wynikowy.

Nie, testy tego nie wykazują. Testy wykazują że mamy poprawnie 
działający kod pod testami. To może być wystarczające jeśli wymogi 
bezpieczeństwa są przeciętne i może to być za mało jeśli są wysokie.

Może wyjaśnie na przykładzie. Znam człowieka pracujacego dla poważnej 
instytucji związanej z lotnictwem. Aby ich kod przeszedł certyfikat 
pozwalający na stosowanie w samolotach musieli, poza wykazaniem 
testowania we wszystkich odmianach, zarządzania jakością, weryfikacji 
formalnej również to czy zweryfikowali narzędzia. Ponieważ smutni 
panowie od certyfikowania nie są z kosmosu i znają realia to zapytali w 
ILU różnych symulatorach potwierdzono działanie kodu i czy ich 
producenci sami są certyfikowani do użycia w takiej branży.

Z punktu widzenia przeciętnego misaczka programującego pierdoły to jest 
bez sensu.

Z punktu widzenia dopuszczeń do zastosowań krytycznych jest kluczowe. 
Zarządzanie ryzykiem może prowadzić do czasem pozornie absuralnych akcji.

> Więc po co kolejne kompilatory?

Aby metodami statystycznymi podnieść pewność że to co testujesz nie jest 
związane z błędem kompilatora.

>> Istnieją ryzyka gdzie nie można zaufa kompilatorowi.
> Ależ ja mu ani przez chwilę nie ufałem. Ani przez mikrosekundę.
> Ale też nie on jest w centrum uwagi. Więc?

Ale to on napisał na koniec na ekranie "100% testów przeszło".

Możesz mu nie ufać. Cerytyfikator też nie będzie jesli ma się podpisać 
pod czymś montowanym jako rozrusznik serca.

PS. A zupałnie na marginesie wszelkiej certyfikacji. Odpalam mój kod pod 
trzema kompilatorami. clang, gcc i vc oraz dodatkowo okresowo pod 
valgrindem. Codziennie, głównie w celu łownienia różnic składniowych, na 
ciągłej integracji. Po kilka razy na co najmniej dwóch z nich. Zgadnij 
ile bugów znalazło się w kodzie na jednym z nich który to kod wykazywał 
brak błedów na innym? Nie, nie składniowych. 100% testów przeszło na 
unit i integracji. A pod innym GPF. Życie.

On 2019-10-05 10:06, heby wrote:
> Nie. To jest codzienność mojej pracy.

A w to to akurat wierze.
Nie nazywaj jednak tego pracą :)

AK

On 2019-10-05 22:12, Maciej Sobczak wrote:
> I tu jest cały trick. Kompilator nie jest celem ani centrum tego ćwiczenia.

No właśnie.

AK

heby <heby@poczta.onet.pl> Wrote in message:
> On 05/10/2019 22:13, slawek wrote:> Ale wiesz kiedy i do czego zastosowano HAZARD po raz pierwszy?To słowo ma kilka zastosowań w IT w tym ma również zastosowanie w weryfikacji dlatego określ o które z nich Ci chodzi.


Albo wiesz które, albo nie wiesz. A jeżeli nie wiesz...
-- 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

> > No więc - skoro już poprawiliśmy tą naszą funkcję, to jaka jest wartość dodana z użycia kilku kolejnych kompilatorów?
> 
> Bardzo prosta. Twój kompilator w poprawnej funkcji dodawania przypadkiem 
> zrobił mnożenie kiedy x=15 i y=90.

To wychodzi w pokryciu kodu obiektowego.

> Shit happens.

Nie, nie happens.
Tzn. może są firmy, gdzie happens i się nie bada pokrycia (tak, tak, teraz ja sobie dorabiam, dla równowagi do Twoich teorii, że w Ariane 5 nie było testów), ale tam gdzie widzę, bada się i nie happens.

> Czasem to tylko mignie 
> szybciej diodą a czasem wyśle samolot w kierunku gruntowym.

Nie było przypadku, żeby samolot poleciał w kierunku gruntowym przez to, że użyto jednego kompilatora a nie trzech. Dlatego ten pomysł byłby potraktowany jako koszt bez wartości dodanej.

> A kod działa przypadkiem tylko dlatego że kompilator w jakimś miejscu 
> zamiast referencji użył wartości. W kodzie produkcyjnym użyje referencji

Zaraz, zaraz... Testowałeś nieprodukcyjny kod a produkcyjny były jakiś inny?
Tyle mądrości na temat weryfikacji a tu taki klops. Skup się.
 
> Aby zweryfikować narzędzia do weryfikacji.

O, tu, widzisz, poruszyłeś ciekawe zagadnienie.
Ale kwalifikację narzędzia robi się przed projektem, bo projekt zaczyna się mając już zatwierdzone narzędzia. I jeśli do tej kwalifikacji chcesz sobie użyć materiału testowego pochodzącego z różnych kompilatorów, to właściwie może to mieć sens (ale nie musi). Tylko że nadal nie ma sensu używać więcej niż jednego kompilatora do robienia tego właściwego projektu.

> > I tu jest cały trick. Kompilator nie jest celem ani centrum tego ćwiczenia.
> 
> Jest narzędziem które odpowiada na pytanie czy kod działa czy nie.

Kompilator? Nie, nie odpowiada na takie pytanie. Właściwie to mogłoby nie być żadnego kompilatora, można posadzić człowieka z zapasem kawy i herbatników i niech "kompiluje". I to nawet nie jest fikcja.

> Czasami odpowiada źle.

Nie pokazałeś niczego takiego.

> Nie. Wykazałeś że w jakiś warunkach Twój kod działa. A czy to te same 
> warunki kiedy będzie używany produkcyjnie?

I w jaki sposób trzy kompilatory mają coś tu zmienić? Ilość kompilatorów wpływa na to, jak bardzo zmieniają się warunki w użyciu produkcyjnym?

> Może wyjaśnie na przykładzie. Znam człowieka pracujacego dla poważnej 
> instytucji związanej z lotnictwem. Aby ich kod przeszedł certyfikat 
> pozwalający na stosowanie w samolotach musieli, poza wykazaniem 
> testowania we wszystkich odmianach, zarządzania jakością, weryfikacji 
> formalnej również to czy zweryfikowali narzędzia. Ponieważ smutni 
> panowie od certyfikowania nie są z kosmosu i znają realia to zapytali w 
> ILU różnych symulatorach potwierdzono działanie kodu i czy ich 
> producenci sami są certyfikowani do użycia w takiej branży.

Wszystko się zgadza.
Ale nie ma tu ani słowa o użyciu wielu kompilatorów.

I jeśli jesteśmy w temacie samolotów i smutnych panów - standardy lotnicze są tak napisane, że użycie wielu kompilatorów do kompilowania tego samego kodu w projekcie nie jest podstawą do dodatkowego uznania (tzw. certification credit) w czasie audytu certyfikacyjnego a weryfikacji kodu wynikowego nie robi się garścią kompilatorów, bo kod ma być jeden. Ten sam w testach, co na produkcji.

Dlatego ten pomysł nie ma zastosowania w projektach krytycznych, w szczególności w lotniczych. Prawie byłeś blisko w temacie kwalifikacji narzędzi (np. narzędzie do badania pokrycia kodu testami można próbować kwalifikować przy użyciu materiału testowego z jakiegoś zestawu kompilatorów, ale to i tak niewiele wnosi w konteście danego projektu, gdzie jest jeden kompilator), ale generalnie mylisz pojęcia.

No i fajnie, że znasz "człowieka pracujacego dla poważnej instytucji związanej z lotnictwem".

> PS. A zupałnie na marginesie wszelkiej certyfikacji. Odpalam mój kod pod 
> trzema kompilatorami.

Ja też - wtedy, gdy piszę biblioteki.

Ale w projekcie krytycznym używa się jednego kompilatora. I testuje się kod produkcyjny.

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

On 06/10/2019 23:21, Maciej Sobczak wrote:
>> Bardzo prosta. Twój kompilator w poprawnej funkcji dodawania przypadkiem
>> zrobił mnożenie kiedy x=15 i y=90.
> To wychodzi w pokryciu kodu obiektowego.

Najpierw musisz znaleźć metodę testowania która zawiera dostatecznie 
dużo przypadków.

>> Shit happens.
> Nie, nie happens.

Ależ happens. Na ten przykład popularną metodą testowania kodu 
krytycznego, ale naprawdę krytycznego, jest psucie go w czasie 
rzeczywistym i patrzenie gdzie i co wybuchnie analizując czy jest czy 
nie podatny na uszkodzenia.

Nawet krzemowi się nie wierzy.

> Tzn. może są firmy, gdzie happens i się nie bada pokrycia (tak, tak, teraz ja sobie dorabiam, dla równowagi do Twoich teorii, że w Ariane 5 nie było testów), ale tam gdzie widzę, bada się i nie happens.

No ale jednak happens. Jesli nie to masz kompilator zewryfikowany 
funkcjonalnie. Nie język, kompilator. Gratuluje.

W HDL jest jeszcze ciekawiej: co prawda można testować kod ale podczas 
syntezy zamienia się on w graść tranzysotrów i tak ląduje w krzemie. Tam 
jest dopiero zabawnie bo metody testowania software nie chcą pasować.

>> Czasem to tylko mignie
>> szybciej diodą a czasem wyśle samolot w kierunku gruntowym.
> Nie było przypadku, żeby samolot poleciał w kierunku gruntowym przez to, że użyto jednego kompilatora a nie trzech.

Inaczej: akurat w tej branży testuje się kilkoma innymi metodami 
również. Albo inaczej: z faktu że internet działa nie wynika że admini 
są zbędni.

> Dlatego ten pomysł byłby potraktowany jako koszt bez wartości dodanej.

Nie "byłby" tylko jest stosowany. Może bardziej w HDLu ale w normalnym 
programowaniu też.

>> A kod działa przypadkiem tylko dlatego że kompilator w jakimś miejscu
>> zamiast referencji użył wartości. W kodzie produkcyjnym użyje referencji
> Zaraz, zaraz... Testowałeś nieprodukcyjny kod a produkcyjny były jakiś inny?

Kod źródłowy ten sam. Kod wynikowy już niekoniecznie. Kompilator to jest 
dość nietrywialny produkt.

> Tyle mądrości na temat weryfikacji a tu taki klops. Skup się.

No właśnie skup się, potwierdzenie kodu źródłowego, nawet metodami 
formalnymi, nie oznacza że wynikowy jest poprawny. Potwierdzenie kodu 
wynikowego unittestami czy innymi testami nie odpowiada na pytanie czy 
będzie poprawnie się zachowywał na produkcji, to tylko przybliżenie do 
ideału.

>> Aby zweryfikować narzędzia do weryfikacji.
> O, tu, widzisz, poruszyłeś ciekawe zagadnienie.
> Ale kwalifikację narzędzia robi się przed projektem, bo projekt zaczyna się mając już zatwierdzone narzędzia.

Różnie bywa. Taka ciekawostka: weryfikację narzędzia robi się czasem na 
słowo honoru: "działa od dziesięciu lat i nie ma problemu". Serio mówie. 
Zarządzanie ryzykiem z braku środków pewnych opiera się o statystykę i 
szczęście.

> I jeśli do tej kwalifikacji chcesz sobie użyć materiału testowego pochodzącego z różnych kompilatorów, to właściwie może to mieć sens (ale nie musi).

Musisz zagwarantować że twój pewny kompilator jest pewny dla kodu 
którego jeszcze nie ma. Dasz radę to udowodnić na etapie wyobu 
narzędzia? Niektórzy stosują dupchrony w postaci wybierania narzędzi 
certyfikowanych. Ale certyfikacja to nie jest brak bugów. To jest tylko 
takie zapewnienie że tamci się też starali.

> Tylko że nadal nie ma sensu używać więcej niż jednego kompilatora do robienia tego właściwego projektu.

Do robienia nie. Do weryfikacji musisz użyć środków adekwatnych do 
ryzyka zdefiniowanego w planie. To może oznaczać np. rozbieranie na 
pojedyncze bramki CPU na którym ten kod będzie działać aby wykluczyć 
wątpliwości czy hardware jest pewne. Nie, nie wyssałem tego z palca.

>> Jest narzędziem które odpowiada na pytanie czy kod działa czy nie.> 
> Kompilator? Nie, nie odpowiada na takie pytanie.

Oczywiśćie że odpowiada. Jesli masz tak w wyniku błedu kompialtora:

bool runUnitTesting()
{
	return true;
	....
}

To własnie wylądowałeś w dupie. Twój kompilator stwierdził że coś jest 
okay choć nie jest.

> Właściwie to mogłoby nie być żadnego kompilatora, można posadzić człowieka z zapasem kawy i herbatników i niech "kompiluje". I to nawet nie jest fikcja.

Tylko że to nie działa w praktyce ponieważ dodałeś dodatkową wartwę 
błedów. Ktoś o nią zapyta.

>> Czasami odpowiada źle.
> Nie pokazałeś niczego takiego.

Mam masę uni testów które przechodzą mimo błednego kodu. Tylko dlatego 
że urawło referencję ale obiekt dalej ma dobre dane, wyskoczyłem poza 
tablicę a tam akurat dobre 0 itd itp. Mówie o błedach *KOMPILATORA* a 
nie kodu. Fakt, to gówniany C++ ale nie zmienia to koncpecji ogólnej. 
Testy nie mówią czy kod jest poprawny. Co najwyżej mówią że kod pod 
testami daje spodziewane wyniki.

>> Nie. Wykazałeś że w jakiś warunkach Twój kod działa. A czy to te same
>> warunki kiedy będzie używany produkcyjnie?
> I w jaki sposób trzy kompilatory mają coś tu zmienić?

Zwiększają asymptotycznie pewność kodu. Kiedy w końcu coś spadnie z 
białkiem w środku zapytają: a czy użyliście wszystkich osiąglanych metod 
weryfikacji poprawniści kodu a jeśli nie to dlaczego? A ty im będziesz 
bredził że postawiłeś kogoś z herbatnikami i kompilował na kartce bo to 
żadna różnica skoro kod poprawny. BO TAK BYŁO W SPECYFIKACJI.

> Ilość kompilatorów wpływa na to, jak bardzo zmieniają się warunki w użyciu produkcyjnym?

Pozwalają zminimalizować nieszczęscie związane z błedami w kompilatorze 
lub z UB, z tym drugim nawet bardziej.

>> formalnej również to czy zweryfikowali narzędzia. Ponieważ smutni
>> panowie od certyfikowania nie są z kosmosu i znają realia to zapytali w
>> ILU różnych symulatorach potwierdzono działanie kodu i czy ich
>> producenci sami są certyfikowani do użycia w takiej branży.
> Wszystko się zgadza.
> Ale nie ma tu ani słowa o użyciu wielu kompilatorów.

Symulator. HDL. Niczym to się nie różni od kompilatora "normalnego", też 
kompilator i w dodatku Ady + pierdoły.

> I jeśli jesteśmy w temacie samolotów i smutnych panów - standardy lotnicze są tak napisane, że użycie wielu kompilatorów do kompilowania tego samego kodu w projekcie nie jest podstawą do dodatkowego uznania (tzw. certification credit) w czasie audytu certyfikacyjnego a weryfikacji kodu wynikowego nie robi się garścią kompilatorów, bo kod ma być jeden. Ten sam w testach, co na produkcji.

To jest to samo źródło, ale nie ten sam kod który będzie pracował na 
testach. Kompilatory nie są proste, a już na pewno nie są pewne. Dlatego 
robi się corss-checki na róznych. Wiesz, ja piszę głównie o EDA i 
głównie o HDL gdzie tego typu zabawy to codzienność.

Uzycie kilku narzędzi zwiększa pewność weryfikacji. Kila firm solidnie w 
ostatnich latach robiło w gacie i kupiło (bardzo) drogie narzędzia 
testując wszystko na wszystkim. "Dla pewności".

> Dlatego ten pomysł nie ma zastosowania w projektach krytycznych, w szczególności w lotniczych. Prawie byłeś blisko w temacie
> kwalifikacji narzędzi (np. narzędzie do badania pokrycia kodu testami można próbować kwalifikować przy użyciu materiału testowego z jakiegoś zestawu kompilatorów, ale to i tak niewiele wnosi w konteście danego projektu, gdzie jest jeden kompilator), ale generalnie mylisz pojęcia.

Albo z miejsca gdzie siedzę widać coś innego niż z Twojego. Siedzimy 
gdzie indziej.

> No i fajnie, że znasz "człowieka pracujacego dla poważnej instytucji związanej z lotnictwem".

Nie, to nie jest fajnie. Dowiadujesz się raczej jak ciężko pracuje się 
nad trudnymi projektami. Na ten przykład dokumentowanie kodu trwa 
znacząco dłużej niż jego pisanie. Trudno mieć pretensje ale nie każdy by 
potrafił.

>> PS. A zupałnie na marginesie wszelkiej certyfikacji. Odpalam mój kod pod
>> trzema kompilatorami.
> Ja też - wtedy, gdy piszę biblioteki.
> Ale w projekcie krytycznym używa się jednego kompilatora. I testuje się kod produkcyjny.

Super. Być może certyfikujesz używając róznych innych metod weryfikacji. 
Nikt nie naciska na kilka kompilatorów. Ale kilku wielkich graczy 
zdecydowało się na to. Widzisz, lista bugów w kompilatorach jest długa i 
raczej nie zamknięta. W tych certyfikowanych też.

On 2019-10-06 23:21, Maciej Sobczak wrote:
> Ale w projekcie krytycznym używa się jednego kompilatora. I testuje się kod produkcyjny.

Tak naprawde w projekcie (niekoniecznie tylko krytycznym - ot zwyklym)
powinien byc _nakaz_ (i z reguly jest/byl - przynajmniej w "moich
czasach") uzywania tylko jednego tego samego (co do scislej wersji)
kompilatora.
_Wlasnie ze wzgledu na wieksze bezpieczenstwo_.

PS: Inna sprawa to dobor "wlasciwego" kompilatora.
Powinien byc dokonany przez rozpoczeciem projektu
(zapisany w env. requirements), a potem non stop weryfikowany
- oczywiscie do pewnego etapu/momentu - zwlaszcza dla badziewi
typu C/C++ - Borlanda, VC++ czy szczegolnie gcc.

AK

> > To wychodzi w pokryciu kodu obiektowego.
> 
> Najpierw musisz znaleźć metodę testowania która zawiera dostatecznie 
> dużo przypadków.

Dalej nie kapujesz. Najpierw mam metodę mierzenia pokrycia. A potem, jeśli testy nie dają wystarczającego pokrycia, szukam dziury. To nie musi być dziura w testach. To może być dziura w kompilatorze. Czyli nie chodzi o to, żeby coś pokryć dużą liczbą testów, tylko żeby mieć świadomość, czemu coś nie jest pokryte. To znaczy, że nie muszę mieć jakiejś specjalnej metody testowania, żeby taką świadomość uzyskać a w omawianym przykładzie wcale nie trzeba mieć "dostatecznie dużo przypadków".

> Ależ happens. Na ten przykład popularną metodą testowania kodu 
> krytycznego, ale naprawdę krytycznego,

Łoł, ale tak naprawdę-naprawdę krytycznego, czy tylko naprawdę krytycznego?
Bo w tej dyskusji wspinasz się sięgając po coraż wyższe autorytety. Ostatnio było nawet o rozmowie z człowiekiem mającym kontakt z brażną lotniczą...

> jest psucie go w czasie 
> rzeczywistym i patrzenie gdzie i co wybuchnie analizując czy jest czy 
> nie podatny na uszkodzenia.

I nadal nie ma potrzeby używać wielu kompilatorów. Skup się.

> No ale jednak happens.

No ale jednak nie pokazałeś żadnego przekonywującego przykładu.

> Inaczej: akurat w tej branży testuje się kilkoma innymi metodami 
> również.

I właśnie dlatego nie potrzeba wielu kompilatorów. Do tego wniosku asymptotycznie zmierzamy.

> > Dlatego ten pomysł byłby potraktowany jako koszt bez wartości dodanej.
> 
> Nie "byłby" tylko jest stosowany. Może bardziej w HDLu ale w normalnym 
> programowaniu też.

Rozumiem. Czyli jeśli nie udało się wykazać sensowności użycia wielu kompilatorów, to trzeba napisać "bardziej w HDLu" a potem dodać "ale tu też". I jest szansa, że przypadkowy czytelnik dostrzeże w tym wartościową wypowiedź.

> Różnie bywa. Taka ciekawostka: weryfikację narzędzia robi się czasem na 
> słowo honoru: "działa od dziesięciu lat i nie ma problemu". Serio mówie.

To się nazywa Previously Developed Software. Tak. Ale to nie jest słowo honoru, bo historię użycia trzeba mieć udokumentowaną i trzeba wykazać w jakim stopniu nowe użycia pokrywają się ze starymi. Nie ma w tym nic nieracjonalnego.
 
> Musisz zagwarantować że twój pewny kompilator jest pewny dla kodu 
> którego jeszcze nie ma.

Jest dokładnie odwrotnie (czyli jak już pisałem, mylisz pojęcia).
Uważaj:

"Upon successful completion of verification of the software product, the compiler is considered acceptable for that product."

"Although the compiler is considered acceptable once all of the verification
objectives are satisfied, the compiler is only considered acceptable for that product and not necessarily for other products."

Czyli o tym, że kompilator *był* dobry wiadomo dopiero jak się nim zrobi produkt. Natomiast nie zakłada się, że *będzie* dobry, zanim się tego produktu nie zrobi. Bo proces jest tak ustawiony, że wcale na tym założeniu nie polega.

Zapytaj kolegę od samolotów, skąd są te cytaty.

> Albo z miejsca gdzie siedzę widać coś innego niż z Twojego.

Na to wygląda. Ale też dlatego nie mam zamiaru się w nieskończoność szarpać.

[...]

> Nikt nie naciska na kilka kompilatorów.

Hura!

> Ale kilku wielkich graczy 
> zdecydowało się na to.

"Pewni ludzie", "niektórzy", "chodzą głosy", "ktoś mi opowiadał", itp...

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

> Tak naprawde w projekcie (niekoniecznie tylko krytycznym - ot zwyklym)
> powinien byc _nakaz_ (i z reguly jest/byl - przynajmniej w "moich
> czasach") uzywania tylko jednego tego samego (co do scislej wersji)
> kompilatora.

Tak. Nie tylko co do wersji, ale również co do użytych opcji kompilacji.

Dlatego problematyczne jest poleganie na różnych ficzerach diagnostycznych przełączanych opcjami. Paradoksalnie, im wyższy rygor, tym mniejsza swoboda, również w tym zakresie.

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

On 2019-10-08 09:34, Maciej Sobczak wrote:
>> Tak naprawde w projekcie (niekoniecznie tylko krytycznym - ot zwyklym)
>> powinien byc _nakaz_ (i z reguly jest/byl - przynajmniej w "moich
>> czasach") uzywania tylko jednego tego samego (co do scislej wersji)
>> kompilatora.
> 
> Tak. Nie tylko co do wersji, ale również co do użytych opcji kompilacji.

Dokładnie!

AK

On 08/10/2019 09:28, Maciej Sobczak wrote:
>> Najpierw musisz znaleźć metodę testowania która zawiera dostatecznie
>> dużo przypadków.
> Dalej nie kapujesz. Najpierw mam metodę mierzenia pokrycia. A potem, jeśli testy nie dają wystarczającego pokrycia, szukam dziury.

Cały czas mówisz o tym jak znaleźć problem na testach. Niestety testy 
nie latają.

> To nie musi być dziura w testach. To może być dziura w kompilatorze. Czyli nie chodzi o to, żeby coś pokryć dużą liczbą testów, tylko żeby mieć świadomość, czemu coś nie jest pokryte. To znaczy, że nie muszę mieć jakiejś specjalnej metody testowania, żeby taką świadomość uzyskać a w omawianym przykładzie wcale nie trzeba mieć "dostatecznie dużo przypadków".

Trzeba znaleźć dziurę w kompilatorze. Dziura nie została znaleziona 
perfekcyjnymi testami *MOJEGO* kodu choć ujawniła się w MOIM kodzie na 
produkcji. Samolot spada.

>> Ależ happens. Na ten przykład popularną metodą testowania kodu
>> krytycznego, ale naprawdę krytycznego,
> Łoł, ale tak naprawdę-naprawdę krytycznego, czy tylko naprawdę krytycznego?

Naprawdę naprawdę.

> Bo w tej dyskusji wspinasz się sięgając po coraż wyższe autorytety. Ostatnio było nawet o rozmowie z człowiekiem mającym kontakt z brażną lotniczą...

No i? Myślisz że opowieści wyssałem z palca?

>> jest psucie go w czasie
>> rzeczywistym i patrzenie gdzie i co wybuchnie analizując czy jest czy
>> nie podatny na uszkodzenia.
> I nadal nie ma potrzeby używać wielu kompilatorów. Skup się.

Pokazuje to jak ważna jest statystyka kiedy wyczerpiesz metody ścisłe.

>> No ale jednak happens.
> No ale jednak nie pokazałeś żadnego przekonywującego przykładu.

Podobnie jak administrator sieci nie potrafi pokazać żadnego 
przekonywującego przykładu że jest potrzebny.

>> Inaczej: akurat w tej branży testuje się kilkoma innymi metodami
>> również.
> I właśnie dlatego nie potrzeba wielu kompilatorów. Do tego wniosku asymptotycznie zmierzamy.

Nie, kiedy już wyczerpiesz zasoby ścisłe pojawia się statystyka. Analiza 
randoiczna testów, upewnianie się co do kodu w różnych narzędziach itd itp.

>> Nie "byłby" tylko jest stosowany. Może bardziej w HDLu ale w normalnym
>> programowaniu też.
> Rozumiem. Czyli jeśli nie udało się wykazać sensowności użycia wielu kompilatorów

Ją się już dawno udało wykazać, tylko ciągle WYDAJE ci się że jak 
sprawdziłeś kod metodami testującymi takimi a siakimi to nagle wszelakie 
nieznane i znane bledy w kompilatorze masz pod kontrolą. Nie masz.

>, to trzeba napisać "bardziej w HDLu" a potem dodać "ale tu też". I jest szansa, że przypadkowy czytelnik dostrzeże w tym wartościową wypowiedź.

Podobnie jak w bredzeniu że ktoś bredzi. HDL akurat ma testowanie 
rozwięte do granic absurdu.

>> Różnie bywa. Taka ciekawostka: weryfikację narzędzia robi się czasem na
>> słowo honoru: "działa od dziesięciu lat i nie ma problemu". Serio mówie.
> To się nazywa Previously Developed Software. Tak. Ale to nie jest słowo honoru, bo historię użycia trzeba mieć udokumentowaną

Owszem. Udokumentowanie polega na obserwacji, statystycznej i 
subiektywanej, że działa.

> i trzeba wykazać w jakim stopniu nowe użycia pokrywają się ze starymi. Nie ma w tym nic nieracjonalnego.

Oczywisćie. W końcu pisali helloworlda i piszą teraz innego helloworlda. 
To TAKIE trywialne pokazać że mają ten sam kod, kompilwoany tak samo i 
to coś zapewnia. Utopia.

>> Musisz zagwarantować że twój pewny kompilator jest pewny dla kodu
>> którego jeszcze nie ma.
> Jest dokładnie odwrotnie (czyli jak już pisałem, mylisz pojęcia).
> Uważaj:
> "Upon successful completion of verification of the software product, the compiler is considered acceptable for that product."
> "Although the compiler is considered acceptable once all of the verification
> objectives are satisfied, the compiler is only considered acceptable for that product and not necessarily for other products."
> Czyli o tym, że kompilator *był* dobry wiadomo dopiero jak się nim zrobi produkt.

Niebywałe. Czyli innymi słowy gadanie o tym że się go wybiera PRZED nie 
miało sensu?

> Natomiast nie zakłada się, że *będzie* dobry, zanim się tego produktu nie zrobi. Bo proces jest tak ustawiony, że wcale na tym założeniu nie polega.

Super. Innymi słowy może być zły? Ojej, to będzie trzeab użyć innego? 
Ojejejej. Niemożliwe, przecież nie wolno:

"projekt zaczyna się mając już zatwierdzone narzędzia.".

No to lekka dupa, trzeba zauważyć.

Prosze, opisz jak wygląda koncepcja zrobnienia SWOJEGO projektu na 
nieznanym kompilatorze i udowodnienia formalnie w ten sposób że jest 
dobry. Z chęcią poczytam. Obawiam się jednak że wniosek  będzie że jest 
dobry do testów na których był testowany a i to będzie naciągane jak 
guma z majtek.

> Zapytaj kolegę od samolotów, skąd są te cytaty.

Ze śmiesznych norm ISO i DO? Dokumentów szkoleniowych Tuv? Z publikacji 
naukowych? Z poważnych książek z długimi tytułami?

>> Albo z miejsca gdzie siedzę widać coś innego niż z Twojego.
> Na to wygląda. Ale też dlatego nie mam zamiaru się w nieskończoność szarpać.

Ależ nie musisz. Ja najzwyczajniej w świecie doskonale sobie zdaje 
sprawę w jakiej utopii testowania siedzi pół świata. I jak absurdalnymi 
metodami staraja się z niej wydobyć.

>> Nikt nie naciska na kilka kompilatorów.
> Hura!
>> Ale kilku wielkich graczy
>> zdecydowało się na to.
> "Pewni ludzie", "niektórzy", "chodzą głosy", "ktoś mi opowiadał", itp...

Więc zapewne już rozumiesz że czasami o detalach nie można mówić. I nie 
dlatego że nie istnieją tylko dlatego że takie mamy reguły gry na tym 
rynku. To nie GitHub i nie każdy z woich rozmówców to dzieciak. Zrób 
założenie inne, może się rozjaśni dlaczego nie każdy ma prawo i 
możliwość mówienia o detalach, nazwach i nazwiskach.

On 08/10/2019 08:48, AK wrote:
>> A co to jest blech?
> buz()
> Pajacu

Czuć ten klimat lasu pełnego ojców AK przekazujacych tą kulturę na swoje 
dzieci. Jak już wspomniałem, jest pewna grupa ludzi mająca najwięcej do 
powiedzenia o kulturze.

>, moze bys tak wpierw przetestowal (unitestowo jak najbardziej)
> ten buz, zgdomadzil maksymalnie (bo wiadomo ze calej "dziedziny"
> nie pokryjesz, a wazne, zeby to byly miejsca "charakterystyczne" np.
> blisko koncow przedzialu, jakies inne punkty charakterystyczne)
> miarodajne dane (czyli wyniki buz() z przykladowego zakresu/zakresow).

No robie to z kodem dobre 20 lat jak nie więcej. I? No wiec zazyczaj 
wtedy mam buz(). A tu nie ma buz(). I dupa z unit testowaniem.

> Oblicz wiec dla przetestowanych unitestowo w buz() przedzialow

Nie da się.

Zacytuje klasyka:

"Bo gdy buz będzie
  definiowana przez użytkownika (np. przez podanie kilkunastu liczb
  określających współczynniki, wykładniki itp.) - to zwyczajnie nie
  wiesz co z czym masz assertEqual"

Nzjwyczajniej nie wiesz na jaki post i jaki kawałek kodu odpowiadasz, 
stąd rady które są tyle warte ile kosztowały.

> PS: Wiec zwyczajnie z tymi testami integracyjnymi pojechales.
> Jesli tak (hm... nie mamy _na patelni_ wartosci oczekiwanych to..
> olewamy unittesty.... a co !

Bzdura.

Unit testy z definicji testują *unity* kodu. A nie tajemnicze funkcjie 
podawane przez użytkownia jak u niejakiego sławka. Od tego są inne 
warstwy testowania.

> to moge stwierdzic tylko jedno. Przedszkole, a nie testowanie :(

Nic nie możesz stwierdzić bo nie masz danych. Pokaż buz() to będzie 
rozmowa o uni testach. Nie pokazesz buz() to nie ma unit testów tylko 
wróżenie z fusów, co czasami się oczywiscie praktykuje, ale raczej bez 
specjalnych nadziei że daje odpowiedź poprawną. Koniec dyskusji nad 
buz() i fun(). Nie ma kodu, nie ma unit testów.

On 2019-10-10 21:52, heby wrote:
> On 08/10/2019 08:48, AK wrote:
>>> A co to jest blech?
>> buz()
>> Pajacu
> 
> Czuć ten klimat lasu pełnego ojców AK przekazujacych tą kulturę na swoje 
> dzieci. Jak już wspomniałem, jest pewna grupa ludzi mająca najwięcej do 
> powiedzenia o kulturze.

Ktos kto mieni sie informatykiem i mowi o Windows, ze to jakas nisza,
jest pajacem i AK czy kultura nie ma tu nic do czynienia :)
Jest pajacem bezwzglednie i bezwarunkowo.
PS: Pajacem lub Ayatollahem (jeden BUC...).

>> , moze bys tak wpierw przetestowal (unitestowo jak najbardziej)
>> ten buz, zgdomadzil maksymalnie (bo wiadomo ze calej "dziedziny"
>> nie pokryjesz, a wazne, zeby to byly miejsca "charakterystyczne" np.
>> blisko koncow przedzialu, jakies inne punkty charakterystyczne)
>> miarodajne dane (czyli wyniki buz() z przykladowego zakresu/zakresow).
> 
> No robie to z kodem dobre 20 lat jak nie więcej. I? No wiec zazyczaj 
> wtedy mam buz(). A tu nie ma buz(). I dupa z unit testowaniem.
> 
>> Oblicz wiec dla przetestowanych unitestowo w buz() przedzialow
> 
> Nie da się.

Niby dlaczego. (Prawie) zawsze sie da.
Gdy naprawde ciezko, to mock buza() tez jest pewnym wyjsciem.
Mock chocby wylacznie po tp aby prze-unit-testowac funa()

> Zacytuje klasyka:
> 
> "Bo gdy buz będzie
>   definiowana przez użytkownika (np. przez podanie kilkunastu liczb
>   określających współczynniki, wykładniki itp.) - to zwyczajnie nie
>   wiesz co z czym masz assertEqual"

To sobie zgromadz te dane buz()-a dla tychze wspolczynnikow.

> Unit testy z definicji testują *unity* kodu. A nie tajemnicze funkcjie 
> podawane przez użytkownia jak u niejakiego sławka.

Te "tajemnicze" funkcje sa _takimi samymi_ jak kazde inne.
Identycznie jak te jawne (z source kodem itp) podlegaja unittestowaniu.

> Od tego są inne warstwy testowania.

Baju baju...
Inne warstwy sluza zupelnie czemu innemu, a nie testowaniu pojedynczych
funkcji.

Ze niby fun() nie jest normalna funkcja?
Chyba sobie kpisz.
Juz lepiej zmock-uj tego buz() /fakt, nie zawsze sie da/ gdy nie chce ci 
sie przygotowac _faktycznych_ danych.

>> to moge stwierdzic tylko jedno. Przedszkole, a nie testowanie :(
> 
> Nic nie możesz stwierdzić bo nie masz danych. Pokaż buz() to będzie 
> rozmowa o uni testach. Nie pokazesz buz() to nie ma unit testów tylko 
> wróżenie z fusów

To juz jest horrendum :)
Ze niby musi byc znany kod fukcji, aby ja prze-unittestowac?
Chopie, nie blamuj sie calkiem.

AK

On 10/10/2019 23:08, AK wrote:
> Ktos kto mieni sie informatykiem i mowi o Windows, ze to jakas nisza,

Możesz udowodnć tezę odwrotną. Zacznij np. od ilosci systemów 
operacyjnych w ogóle na świecie w użytku.

Zacznij tutaj:

https://en.wikipedia.org/wiki/Usage_share_of_operating_systems

>> No robie to z kodem dobre 20 lat jak nie więcej. I? No wiec zazyczaj 
>> wtedy mam buz(). A tu nie ma buz(). I dupa z unit testowaniem.
>>> Oblicz wiec dla przetestowanych unitestowo w buz() przedzialow

Ale nic o buz nie wiadomo. Tako rzecze szaman który to zadanie postawił.

>> Nie da się.
> Niby dlaczego. (Prawie) zawsze sie da.

Nie, możez sobie pisać *jakieś* unit testy. To zawsze można, choćby po 
to żeby zadowolić jakiegoś speca i komisje za zielonym suknem.

> Gdy naprawde ciezko, to mock buza() tez jest pewnym wyjsciem.

Żeby napisać mocka buza musiz wiedzieć jakie przyjmuje stany dozwolone. 
Inaczej możesz ten mock wydłubać na return 4; tylko że to co najwyżej 
przetesuje nerwy grupy na codereview.

> Mock chocby wylacznie po tp aby prze-unit-testowac funa()

Nie a się go przetestować, szaman Sławek wyjaśnił że wiedza o buz() jest 
niezbędna do testowania fun().

>> Zacytuje klasyka:
>> "Bo gdy buz będzie
>>   definiowana przez użytkownika (np. przez podanie kilkunastu liczb
>>   określających współczynniki, wykładniki itp.) - to zwyczajnie nie
>>   wiesz co z czym masz assertEqual"
> To sobie zgromadz te dane buz()-a dla tychze wspolczynnikow.

Nie ma buz(). Nie ma współczynników. Nic o niej nie wiadomo.

>> Unit testy z definicji testują *unity* kodu. A nie tajemnicze funkcjie 
>> podawane przez użytkownia jak u niejakiego sławka.
> Te "tajemnicze" funkcje sa _takimi samymi_ jak kazde inne.

Nie. Jesli to funkcja która liczy sin() to chwilowo nie znamy kątów dla 
których jest większa niż 1 wiec istnieje nikła szansa że nalezy testować 
fun() na inne wartości. Albo inaczej: można, tylko po h...

Nie, nie każda funkcja jest taka sama.

> Identycznie jak te jawne (z source kodem itp) podlegaja unittestowaniu.

I ich nie ma. Nie ma więc uni testowania, co nie przeszkadza testować 
inaczej, jak choćby uzywając jakiś wyssanych z palca constrains, które w 
tym przykładzie i tak nie zadziałają bo przykład zakłada jakiś buz() i dupa.

>> Od tego są inne warstwy testowania.
> Baju baju...
> Inne warstwy sluza zupelnie czemu innemu, a nie testowaniu pojedynczych
> funkcji.

To są dwie funkcjie, jedna znany drugą nie. Nie ma jak testować na 
poziomie programisty piszącego fun(). Być może jest możliwośc testowania 
na poziomie kogoś kto zna buz(), być może to będzie programista, ale to 
nie będzie unit test.

Zapewne kiedyś, w dalekkiej przyszłości linkowania kodu, buz() się 
ujawni albo może go ktoś załaduje w runtime. To wtedy bedzie testowanie 
po integracji.

> Ze niby fun() nie jest normalna funkcja?
> Chyba sobie kpisz.

Ależ normalna, ale niestety nie jest kompletna.

> Juz lepiej zmock-uj tego buz() /fakt, nie zawsze sie da/ gdy nie chce ci 
> sie przygotowac _faktycznych_ danych.

Żeby napisać mocka muszę coś wiedzieć. Tutaj nic nie wiemy. Sławek 
pewnie niecierpliwie przebiera nogami żeby dowiedzieć się w jakiej 
szklanej kuli mam wyczytać co to jest buz(). Chwilowo nawet a Algolu 
takiej nie wymyślili.

Więc tak, możesz sobie cośtam potestować unitestami ściemniając że niby 
działa bo dla 3,7 i 50000 działa. Ale to nie jest testowanie, to tylko 
taki wyścig na ilośc kkloc-ów.

>> Nic nie możesz stwierdzić bo nie masz danych. Pokaż buz() to będzie 
>> rozmowa o uni testach. Nie pokazesz buz() to nie ma unit testów tylko 
>> wróżenie z fusów
> To juz jest horrendum :)
> Ze niby musi byc znany kod fukcji, aby ja prze-unittestowac?

Musisz znać jej odpowiedzi na dane wejściowe, opisane w jakimś specu. 
Tutaj buz() jest nieznany. Czy to będzie kod czy specyfikacja, nie ma 
znaczenia. Pokaż buz() to go uzyje, albo pokaż speca to sobie mocka napiszę.

> Chopie, nie blamuj sie calkiem.

Patrzysz czasem w lustro jak dajesz innym rady?