On 2019-10-06 13:48, Mateusz Viste wrote:
> Ja takim
> geniuszem nie jestem, muszę walczyć z własnymi ograniczeniami.

To nie jest zaden "geniusz".
Po prostu polaczenie jakze osobniczej cechy (wybitne "wzrokowstwo")
+ przymus wynikajacy z rzadkiego dostepu do komputera.

PS: Piszac stdlib w assemblerze po jakims czasie zauwazylem ze znam
wiekszosc kodow mnemonikow assemblerowych na pamiec.
Dzis pamietam tylko kilka:
nop 90h
far ret CBh
near ret (chyba) C3h

AK

do góry

On 06/10/2019 13:27, AK wrote:
>> Powiedz nam proszę, jak obecnie być godnym rozmowy z AK.
> Trzeba _codziennie_ myslec o Polsce.

Myślę codziennie. Nie wyjechałem mimo nastu okazji. W sklepie kupuje
polskie nawet jeśli droższe. Chodż do małych sklepików i kupuje u nich a
nie w hipermerketach. Ustępuje staruszkom miejsca i tępie debili w
polityce. Pomogłem w życiu więcej ludziom niż jestem w stanie
optymistycznie oszacować. Płacę podatki. Pewnie by się tego dużo wiecej
znalazło. Ale nie mam ojca w AK. No i dupa zbita, lewacki pomiot jak
nic. Dlatego pytam jak mieć ojca w AK. Jak byś był w stanie zdradzić sekret.

> Myslec jak o swym jedynym ukochanym dziecku, dla ktorego jest sie
> w stanie zrobic wszytsko.

Nie, wszystko nie bo to silnie zależy od definicji. Przykładowo częśc
obecnych "patriotów" robiła wszystko wbrew Polsce w PRL. Czyli ukochane
dziecko zalezy od poglądów politycznych.

> Trzeba ja budowac (wlasciwie od 0) na wiedzy.

Tak. Przy czym zauważę, na aktualniej, Nie na Algolu.

> Na _prawdziwej_ wiedzy (czyli wlasnie np. IT), a nie takiej,
> ktora polega jedynie na wykonywaniu pracy niewolnika zachodnich
> korporacji

O a to ciekawe. Czyli to taki h..owy patriotyzm i za chwile będzie coś o
Żydach?

> Bo tylko taka Polska jest w stanie przetrwac.

Ależ jest w stanie przetrwać na wiele róznych sposobów. Twój jest tylko
jednym z wielu, w dodatku ten który kipesko działa. Najłatwiej wygrywa
się gospodarczo i militarnie. Na oba nas nie stać, nas stać obecnie co
najwyżej na machanie szabelką, podrdzewiałą z resztą.

> Oparta na wiedzy z tzw "lekką" infrastrukturą (warsztat w głowie)
> i oparta o militarny sojusz z USA/obecna wojskową.

No patrz, jakie to proste. Tymczasem kilka bombek jądrowych z Chin czy
innej Rosji załatwi całość tych bredni w 10 sekund. Jesteś pewnien że
przedwojenne mądrości mają obecnie zastosowanie?

> To nie wystarczy. Potrzeba jest jeszcze duża (min 25% populacji)
> silna i lojalna (wzorem Żydowskiej) w stosunku do Ojczyzny diaspora
> (tak: tez po to, aby było z czego ew. odtworzyć naród)

O cholera, a myślałem że już dzisiaj słuchałem Radia Maryja.

A mówiłem że o Żydach będzie!

> Aby to zrobic, trzeba byc niezaleznym/odwaznym/skrajnie
> pracowitym/otwartym na wiedze-nowosci i przede wszystkim
> _samodzielnie myslacym_/umiejacym sie sprzeciwic nawet _calemu swiatu_
> jesli idzie w zlym (dla Polski czy ogolnie pojetej wiedzy) kierunku.

A kto kierunki i jego złość określa? Bo chwilowo największa partia
bredzi o prawicowości będąc jednoczesnie na kilometr na lewo od SLD.
Dzisiaj prawica to lewica a lewica to prawica. I wszędzie tyle samo
idiotów, spoglądają na mnie codziennie z plakatów.

> Najwazniejsze: Trzeba robic wszystko w zyciu z mysla "pro publico
> bono" (a nie tylko o wlasnej d..pie). Tak robila moja Mama i Tata
> (nawet po powrocie z Syberii - tak robil do konca - nielatwego
> zycia).

Jak wielu w IT. Cieżko harują na wygnaniu w korporacjach żeby potem
wydawać resztki gorsza na kawę w starbuksie albo rurki w Lee. Ciezkie
życie mają. Doceń to. Najzywczajniej nie ma chwilowo wojny wiec takie
problemy mamy i takie rozwiązujemy.

> PS: Dobrze napisałes, ze "poki co" mamy pokoj.
> Nie zauwazyles tylko, ze to "poki co" staje sie wcale nie powoli
> nieaktualne (mimo, ze w TVN o tym nie mowia;)

Niestety obecnie wojny wygrywa się inaczej niż kilkoma amerykanami na
patyku, machając nimi przy granicy.

> Potrafisz to zrozumiec swym czerwono/zaglebiowskim umyslem?

Była ulica Czerwonego Zagłębia. W przedszkolu byłem, może troche w
podstawówce, potem zlikiwodowali. Moda też się zmienia, obecnie
potrzebni są kryptogeje na prawicy, kiedyś to były łajzy z lewicy. Ot,
co robić, takie życie, na modę nie poradzisz.

do góry

On 2019-10-06 13:58, g...@g...com wrote:
>> Tak. Moze to kogos otrzezwi/zmniejszy nieuzasadniona BUC-owatosc.
>> Poza tym nigdy nie robie tego jako pierwszy.
[...]
> czy to jest aby najlepsza strategia "zmieniania świata na lepsze", albo czy spośród
osób się tutaj wypowiadających jej zdaniem Ty należysz do tych o najwyższej kulturze
dyskusji.

Heh. Nie mam ambicji zmienia "swiata na lepsze" :).
Glupcow i BUCow nie da swe zmienic.
Szansa jest jedynie dla zupelnie nielicznych, ktorzy
"sie zapedzili"/poddali sie "owczemu pedowi" kolejnej
"political correctness" w IT:).

>> Zebys Ty slyszal jak moj Tata okreslal niekiedy kondycje
>> "moralna"/etyczna rodakow (ostatecznie wydali go w rece NKWD nalezy s
>> dawni "przyjaciele"), a jednoczesnie poswiecil im reszte zycia
>> i robil wszystko dla ich dobra.
>
> ?

No coz. Tak myslalem. Nie zrozumiesz.

>> Ja tez od Waszego pokolenia nie doswiadczylem w swym zyciu
>> zawodowym wlasciwie niczego dobrego, wiec nie czuje jakichs
>> specjalnych "zobowiazan".
>
> Całkiem niedawno na tej grupie ktoś napisał coś takiego:

Nie rozumiem co ma jedno z drugim wspolnego?

> ``Najwazniejsze: Trzeba robic wszystko w zyciu z mysla
> "pro publicobono" (a nie tylko o wlasnej d..pie).
> Tak robila moja Mama i Tata (nawet po powrocie z Syberii
> - tak robil do konca - nielatwego zycia).''
>
> Przeczytaj i przemyśl to sobie w zestawieniu z tym, co przed chwilą napisałeś.

Przeczytalem i przemyslalem. No i jakos nijak mi nie wyszlo,
ze glupocie i BUC-owatosc nie nalezy sie przeciwstawiac/obnazac ją?

AK

do góry

W dniu niedziela, 6 października 2019 14:15:42 UTC+2 użytkownik AK napisał:

> Heh. Nie mam ambicji zmienia "swiata na lepsze" :).

"Pro publico bono" znaczy dokładnie tyle, co "dla dobra ogółu".
[Albo: "żeby na świecie było lepiej".]

> Glupcow i BUCow nie da swe zmienic.

Na pewno nie da się zmienić ludzi, wychodząc z założenia,
że są głupcami.
I na pewno obelżywe traktowanie innych osób prędzej
zaszkodzi, niż pomoże.

> >> Ja tez od Waszego pokolenia nie doswiadczylem w swym zyciu
> >> zawodowym wlasciwie niczego dobrego, wiec nie czuje jakichs
> >> specjalnych "zobowiazan".
> >
> > Całkiem niedawno na tej grupie ktoś napisał coś takiego:
>
> Nie rozumiem co ma jedno z drugim wspolnego?

Co ma stwierdzenie, że "trzeba robić wszystko dla dobra ogółu,
nawet jeśli samemu nie ma się lekko" do stwierdzenia
"nie będę robił nic dobrego dla kogoś, od kogo samemu
niczego dobrego nie doświadczyłem"?

Powiedziałbym, że są to dwie skrajnie przeciwstawne postawy.

do góry

On 06/10/2019 15:02, slawek wrote:
> No cóż - z takim znawcą jak ty - znawcą cyt. "zwykłego
> pieprzenia" - trudno polemizować.
> Więc taka mała prośba: funkcja muldiv(a, b, c) ma obliczać a*b/c
> tak aby unikać underflow i overflow, liczby są 64 bitowe, wynik
> też. Napisz wszystkie konieczne testy dla tego przypadku - tak
> abyś mógł zgodzić się że muldiv zostanie, cyt. "unittestowana".
> Chyba potrafisz, miszczu?!?

Jasne, miszczu. Przy czym nie ja, tylko przemysł.

Oczywiśćie w pewnych warunkach szacuje się ryzyko więc odpowiedź nie
będzie ścisła, tu masz przykłąd jednej z technologii w tym celu:

https://www.chipverify.com/systemverilog/systemveril
og-randomization

Albo może ogólniej:

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

A więc, miszczu, twój problem jest częsciowo rozwiązywany w granicach
zdrowego rozsądku mimo braku rozwiązania wprost.

Ale naprawde, podoba mi się Twoje podeście że jak ktoś wytnie Ci palcem
że masz zbyt trywialny przykład to go podkręcasz i znowu machasz rękami.

Czy już wpsomnałem że w pewnych warunkacj twój problem da się rozwiązać
formalnie? Tak, to też się robi tylko że tego nie można nazwać unit
testowaniem.

No dawaj, podkręcaj tą dziecinadę.

do góry

W dniu 06.10.2019 o 10:50, AK pisze:
> On 2019-10-05 16:05, J-23 wrote:
>> A nie zauważasz tego że biblioteka LCL choć mocno niedopracowana raz
>> użyta odpalisz ją wszędzie? bez dokładania i szukania bibliotek. LCL
>> to tylko przykład.
>
> LCL ? Czy VCL ? Super biblioteka to byla.
>

LCL jest odpowiednikem VCL tylko dla Lazarusa

Pozdrawiam
J-23

do góry

> > 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

do góry

W dniu 06.10.2019 o 11:28, heby pisze:
> On 06/10/2019 11:01, AK wrote:
>>> Do klikania widgetów i pisania kodu? A choćby NetBeans.
>>>> Na rynku gdzie jednym narzędziem będę pisał na dowolną platformę?
>>> Netbeans.
>>>> Bez dodatkowych bibliotek?
>>> Netbeans.
>> Bhuuuheheh :)
>
> Możesz zachować się jak profesjonalista i pokazać błąd w rozumowaniu,
> albo jak typowy dziadek trzasnąć dzwiami mając pretensję do upływającego
> czasu.

Jak byś przeczytał ze zrozumieniem to co napisałem w postach o Lazarusie
byś nie prosił o to by Ci ktoś wskazywał błąd w rozumowaniu. Dlaczego?
Dlatego że znał byś odpowiedz na to pytanie.

Pozdrawiam
J-23

do góry

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ż.

do góry

On 07/10/2019 00:50, J-23 wrote:
> Jak byś przeczytał ze zrozumieniem to co napisałem w postach o Lazarusie
> byś nie prosił o to by Ci ktoś wskazywał błąd w rozumowaniu. Dlaczego?
> Dlatego że znał byś odpowiedz na to pytanie.

Czas kończyć J-23. Dyskucja sprowadza się do bredzenia co ktoś kiedyś
tam powiedział i jak bardzo tego ktoś inny nie zrozumiał bo miał coś
innego na myśli niż tamten chciał żeby miał na myśli. Trudno, trolling
depleted, dalej już tylko pozostał argument sketch a to już lepiej w
oryginale obejrzeć.

do góry