W dniu środa, 22 listopada 2017 08:05:42 UTC+1 użytkownik M.M. napisał:
> On Tuesday, November 21, 2017 at 1:35:43 PM UTC+1, Maciej Sobczak wrote:
> > A to poziom trudności wpływa na stosunek rozmiaru binarki względem liczby linii
kodu?
> > Ja piszę o tym, że jeżeli weźmiemy Linuksa jako pewny znany punkt odniesienia, to
przykład wielogigabajtowych DLLek tak bardzo od tego punktu odniesienia odbiega, że
aż się prosi o wyjaśnienie. I tego wyjaśnienia nadal nie widać.
>
> Wyjaśniam ponownie, hello world w qt gui w wersji debug wraz z bibliotekami dll
> zajmuje ponad pół gigabajta. W wersji release ponad 50mb. I nie odpowiadajcie


patologia - choc ciezko w to uwierzyc

ja juz sam z trudem wierze i rozumiem co to za kram gdzie skompilowanie hello worlda
w c++ pod sfmlem twory 1.5 MB exe
(c++ nie dotykam od lat, pominawszy ze czesc swoich kodow kompiluje
w trybie c++, co i tak robi chyba jakies kilkudziesieco-kilobajtowe narzuty ale nie
az takie)
(zdrowy hello world jak ktos sie zastanawia powinien miec kilka kilobajtow (ze
wzgledu na te alignmenty w formacie pe) jak na razie nie widze powodu by mial miec
wiecej)

postsawowe pytanie co tam dokladnie
siedzi w tych bloatowanych syfach
i co to jest (trzeba sie wiec nauczyc troche lepiej reverse engeeneringu i znajomosci
bebechow
binarek - szkoda ze nikt poza mna tu specjalnie sie tym nie interesuje, a moja wiedza
jest nadal czesciowa)


> że debug nie ma znaczenia, bo zanim wypuści się wersje release to
> chociażby do testów rozprowadza się pewną ilość wersji debug. Hmmmm czy
> w przypadku linkowania statycznego w wersji debug linkier za każdym
> razem musiałby zapisywać na dysk około 500mb danych, podobną ilość
> danych wczytywać i analizować? Nie wiem dlaczego czas kompilacji u
> was nie jest problemem, stosujecie małe biblioteki? Gdy moja aplikacjia
> używała kiedyś tylko np. mfc to faktycznie liniowałem statycznie i
> nie miałem problemów. Ale linkować statycznie z QT... czy ktoś
> próbował w ogóle?
>
>
> Pozdrawiam

do góry

W dniu 22.11.2017 o 08:05, M.M. pisze:
> Wyjaśniam ponownie, hello world w qt gui w wersji debug wraz z bibliotekami dll
> zajmuje ponad pół gigabajta.

To kłamstwo! Wszystkie biblioteki Qt w wersji debug zajmują 313,26MB. A do "Hello
Word" wszystkich nie potrzebujesz! Potrzeba QtCored.dll 12MB + QtGuid.dll 13MB +
QtWidgetsd.dll 11MB. Czyli łącznie 36MB a nie 500!!!

> Hmmmm czy
> w przypadku linkowania statycznego w wersji debug linkier za każdym
> razem musiałby zapisywać na dysk około 500mb danych, podobną ilość
> danych wczytywać i analizować?

Tu znowu podajesz, że g* wiesz o linkowaniu. Linkowanie statyczne polega na pobraniu
jedynie tego co użyłeś do exe.

do góry

On Wednesday, November 22, 2017 at 6:45:02 PM UTC+1, s...@g...com wrote:
> > Ale linkować statycznie z QT... czy ktoś
> > próbował w ogóle?
>
> A czy ktoś kupił wersję komercyjną?!? W Polsze to chyba raczej odpada. Wiec nie
zadawaj głupich pytań! Jak masz problem z rozmiarem bibliotek to sypnij kasą 3,5KEUR
od stanowiska. A jak Cię nie stać, to się ciesz, że dają za darmo dynamicznie
linkowaną wersję za darmo! Dziś postęp w nośnikach danych jest tak wielki, że nie
jest to problem!

Ja przestałem się interesować szczegółowo licencjami, gdy zobaczyłem, że nawet
prawnicy się sprzeczają o to, jak poprawnie zinterpretować tak popularne
licencje jak apache, gpl, lgpl, mit, berkeley, itd.

Darmowa wersja QT jest na licencji LGPL. Ktoś kiedyś mi tłumaczył, że to
oznacza, iż programu napisanego z wykorzystaniem kodu LGPL nie trzeba
udostępniać ze źródłami. Jeśli zmodyfikuje się sam kod objęty LGPL to
trzeba udostępnić zmodyfikowany kod - nic więcej.

Natomiast chyba do woli można kompilować kod objęty LGPL i po skompilowaniu
do woli wykorzystywać, w tym także jako biblioteki statycznie wkompilowane?
Więc skąd pytanie czy ktoś kupił komercyjną? Coś mylę z tą wolnością
kompilowania i statycznego linkowania?

Pozdrawiam

do góry

On Wednesday, November 22, 2017 at 9:09:02 PM UTC+1, Mateusz Bogusz wrote:
> > To ma rację bytu tylko wtedy, gdy przewidzisz rozwój aplikacji i zaprojektujesz
> > dobre interfejsy komunikacyjne. W praktyce jest to najczęściej wykonywanie
> > pracy która potem utrudni rozwój aplikacji o nieprzewidziane cechy.
>
> Chyba żartujesz.
Nie.


> Praca w zespole bez kontraktów, to jak taplanie się w
> błocie - wszyscy obrywają przy pracy jednego.
Dlaczego?


> Wraz z rozwojem aplikacji, pojawia się coraz więcej zalet
> trzymania się interfejsów.
Z tego wnioskuję, że Ty masz na myśli większe aplikacje, a ja
mniejsze i dlatego pomyślałeś że żartuję. Tak, w większych
aplikacjach na dłuższą metę opłaca się zaprojektowanie
interfejsów i trzymanie się ich.


> A jeżeli
> napotyka się "nieprzewidziane cechy", to z moich obserwacji tylko
> dlatego że ktoś w zespole nie do końca rozumie idee
Z moich wynika że nieprzewidziane cechy są po prostu nowymi
wytycznymi od klienta, albo tym, że na etapie projektowania
nie przewidziano iż wytyczne są niejednoznaczne albo nawet
sprzeczne.

> i albo napisał
> sztywny most albo ma się mini aplikację wewnątrz
> docelowej, a nie komponent.
Jakie są różnice pomiędzy mini aplikacją a komponentem?

Pozdrawiam

do góry

On Thursday, November 23, 2017 at 11:55:53 AM UTC+1, Maciej Sobczak wrote:
> > Masz mikroskop do badania jądra linuxa i za jego pomoca zamierzasz
> > oceniać budowę mostu. Proporcje Ci nie zniknęły tylko sa poza skalą i
> > nie sa proporcjonalne.
>
> Dlaczego nie są?
> Mamy:
> - wielomodułowy system
> - na kilkanaście milionów linii
> - pisany ponad 20 lat
> - przez setki ludzi
> - w zespole rozproszonym po całym świecie

Hmmm czy wie ktoś ile lat i przez ilu (średnio) programistów było
rozwijane QT? Bo tak jak mówiłem, hello world gui w qt (według
dedykowanego narzędzia) wymaga 500MB libów w debug i 50MB libów w
release. Też trochę się dziwię skąd się biorą te gigabajty kodu
wynikowego, z jakiejś super-optymalizacji na wydajność, rozwijanie
pętli, template do każdego duperela? Zarówno qt jaki i linux są
na różne platformy, więc przy konkretnej kompilacji dużo odrzuca
if-def.

Pozdrawiam

do góry

On 11/23/2017 11:55 AM, Maciej Sobczak wrote:
>> Masz mikroskop do badania jądra linuxa i za jego pomoca zamierzasz
>> oceniać budowę mostu. Proporcje Ci nie zniknęły tylko sa poza skalą i
>> nie sa proporcjonalne.
> Dlaczego nie są?
> Mamy:
> - wielomodułowy system
> - na kilkanaście milionów linii
> - pisany ponad 20 lat
> - przez setki ludzi
> - w zespole rozproszonym po całym świecie

A tu mamy:
- konkretny cel pisany za konkretne pieniadze opierający się o
specyfikacje i dokumentacje
- kilkadziesiąt milionów lini kodu zbieranych przez lata przez
wchlanianie róznych firm i produkcję własną
- pisany przez tak dlugo że mało kto pamięta kiedy zaczeli
- pisany przez niekreslone ilości ludzi, ale raczej idace w grube tysiące
- w zespołach rozproszonych, ale w srodku grupy *zwartych*
- i ktoś za to płaci co jest nie najgorszym motywatorem
- i ktos pilnuje co robią

> O jakim systemie teraz napisałem?

O jakims innym.

> Do tej pory użyłeś każdego z powyższych punktów jako argumentu uzasadniającego, że
system ma wiele gigabajtów.
> Tymczasem jest system, który spełniając te warunki tych gigabajtów nie ma.

Dalej nie pojmujesz że porównujesz dwa światy i próbujesz wszykim wmówić
ze duże aplikacje pisza imbecyle bo na pewno zlinkowali pornola do dllki
albo zapomnieli wyłączyc debug. To jest obelga w stosunku do dużej
liczby ludzi majacych pojecie o programowaniu grubo większe.

> Stąd wątpliwości i szukanie dalszych argumentów.

Twoje wątpliwości nikogo nie interesują podobnie jak urojenia jehowcow.
Przedstaw dowody że jesteś w stanie prawdziwą aplikajce rzędu 1GB
zredukować tylko przez samo linkowanie.

> Odpowiedzi merytoryczne do tej pory:
> - nie ma motywacji, żeby było mniej
> - kod debugowy i symbole

I Ty twierdzisz że mam kiepskie zdolności komunikacyjne a sam nie
pojmujesz ze kod debugowy i symbole sam zrobiłeś i wyssales z tego
idiotyczne wnioski?

W powaznej firmie, nawet niewielkiej, istnieje wiele poziomów
*zapewniania* że w dll nie ma kodu debugowego i syboli. Niektóre
automatyczne a inne białkowe. Serio, po raz kolejny dajesz w pysk
programistom twierdząc że ich kłopoty to zapomniany debug? I mówisz to
na podstawie własnych urojeń...

> To sa dobre odpowiedzi (ale potrafię sobie wyobrazić ich więcej).

To są złe odpowiedzi. Poza Nabino nie pamiętam ostatnio o wpadce aby
ktokolwiek dostarczył na produkcje kod debugowy.

> Właśnie o to mi chodziło, że nie da się zmiescić tego (proporcjonalnego) miliona
roboczo-lat w 30 lat realnie dostępnych na rozwój takiego produktu.

Oczywiście, fakty jak zwykle perfidnie kłamia. Nie da się i już. Chyba
że ten milion roboczolat to tylko urojenie, ale przecież to obliczenie
opiera sie o soline pociągnięcie z palca wiec nie może być błędne.

> Właśnie to wskazuje na zaburzenie proporcji (czyli: ktoś przy mniejszym wysiłki
zrobił większą binarkę).

A może zrobił większa binarkę przy większym wysiłku uzyskując prędkośc,
ficzery i tym podobne zbędne na helloworldowców rzeczy?

> Nadal twierdzę, że nie da się upchnąć miliona roboczo-lat w 30, które były
dostępne.

Znowu te głupie fakty. Myślaleś żeby się zapisać do jakiejś
populistycznej partii? Oni też z zapałem walczą z faktami.

> Stąd obserwacja, że mamy do czynienia z innymi proporcjami w czasach i rozmiarach.
A stąd pytanie, dlaczego.

Dostajesz odpowiedzi i ciągle pytasz dlaczego. Jesteś może botem?

> BTW - misiaczek też jest nowy w tej dyskusji. Gorzej, że wypalasz się na
niewłaściwym odcinku i brakuje Ci energii na realną dyskusję.

Uważasz że pieprzenie "to nie może być prawda że 2+2=4" jest realnym
pomysłem na dyskusję?

> Moje pierwsze pytanie w tej dyskusji było: czy statycznie zlinkowane byłoby
mniejsze.

Tak. Nie. Nie wiadomo. Raczej niewiele.

> Nie wiemy tego (sam napisałeś, że nie możesz sprawdzić)

Nikt tego nie może sprawdzić. Choćby dlatego że architektura aplikacji
nie umozliwia statycznego linkowania aby zachowac funkcjonalność a samo
doświadczenie bywa że jest niemożliwe do uzyskania bez kolosalnych zmian
za które nikt nie zapłaci bo skutek jest i tak wiadomy.

>, więc teraz Twoje pytanie o to ile czasu trwa linkowanie gigabajtowych execów jest
bezpodmiotowe.

Przedmiotowe bo tak się akuratnie składa że w sąsiedniej firmie jakiś
pustak wpadł na ten pomysł i od 2010 roku niektóre osoby nic nie robią
tylko tna aplikację na kawałki żeby się ratować. Jesli debuger odzyskuje
callstack przez 2 minuty a drogie narzedzia do profilingu wieszają się
za każdym razem to oznacza ze właśnie jesteś w dupie. Niby mało ważny
argument, ten komfort pisania, a zatrzymal firme w rozwoju na kilka lat.

> Najpierw ustalmy, czy te gigabajty byłyby w statycznie zlinkowanym programie.

Tak, byłyby. To oczywiste - kod w dll jest unikatowy i wykorzystywany.
Chyba że uwazasz że statyczne linkowanie kompresuje asembler zipem.
Przyznam ze nie słyszałem o takim ale ja się słabo znam na programowaniu.

> Tego nadal nie wiemy, bo z braku możliwości przeprowadzenia testu pozostają tylko
domysły, ewentualnie wyzwiska.

Nie, to co Ty nazywasz domysłami jest najnormalnie w świecie *wiedza*. I
nie pochodzi ona z pustych funkcji w dllkach tylko z pracy nad dużą
aplikacją.

> Słyszałem o buildach integracyjnych off-line.
> Nie ma potrzeby, żeby każdy programista linkował u siebie kompletny system.
> Podobnie jest z testami.

Oczywiście. Na ten przykald możesz sobie zlinkować tylko prawą częśc
execa, lewą olać i puścić na testy regresyjne. Tak, jest w tym jakiś
pomysł na to żeby napierw spieprzyć a potem ratować dupę workaroundami.
Zupełnie jak w socjaliźmie, dzielnie walczy z problemami które sam generuje.

> Ja nawet przez chwilę nie zakładałem, że w takiej specyficznej branży ktoś używa
domyślnych opcji kompilacji. Naprawdę.

Najbardziej zaś nie zakładałeś robiąc "eksperyment" który miał udowodnic
że programiści to imbecyle.

> Ale jeśli używa się domyślnych, to jest to kolejny trop.

Tak, oczywiscie używa sie domyślnych a programisci to imbecyle. Idzie Ci
coraz lepiej.

> Nadal jednak nie wpada mi to do kategorii "niezbędne".

A może zaproponowałbyś jakaś apliakcję do wycinania przypadkowych
funkcji z dllek? Branża była by wdzięczna, manager wpisuje "wytnij mi
30% kodu na release" i po chwili ma co chciał. Można by na tym zrobić
dużą kasę, jak na homeopatii.

>> Możesz pisać router do fpga
>> ale raczej nie stanie się to godzine po rekrutacji. Coś bardziej po 10
>> latach.
> Dziwna strategia. Jak my zatrudniamy specjalistę od FPGA, to nie po to, żeby przez
10 lat tego nie robił.

Specjalista od FPGA może nie mieć pojęcia o programowaniu. To częsty
przypadek. Ponadto mowa była o misiaczkach którzy wpadają do firmy z
rewolucja. Sadza się ich w kącie i daje trywialne bugi aż zmiekną i z
generowania nastrojow rewolucyjnych przejda do czajenia bazy. Czasem to
trwa z 10 lat.

>> Jeszcze starszy od jądra linuxa jest kod w zegarku na korytarzu w
>> technikum gdzie uczęszczałem, na 8051.
> Ale nie ma 15 milionów linii kodu i nie był pisany przez >20 lat przez setki ludzi
w rozproszonym zespole.

Oczywicie że nie, to tylko drugi idiotyczny przykład po Twoim w tej
dyskusji. Postawienie dwoch absurdów obok siebie pozwala w końcu je
dostrzec.

>> Znowu nazywasz ludzi pracujących z tym kodem głupimi.
> Nic podobnego. Pytam tylko.

"Panie kierowniku, bo tu jakiś imbecyl zlinkował do dllek, a czemu nie
statycznie? Bo ja tu mam taką makietkę dllki... Tak tylko pytam."

Wbrew temu co mówią tumaniści istnieja głupie pytania.

> I do tej pory mamy takie odpowiedzi, po odfiltrowaniu wyzwisk:
> - nie ma potrzeby biznesowej, żeby był mniejszy rozmiar,

Jedna z setek.

> - kod debugowy,
> - stosowanie domyślnych opcje kompilacji

To brednie. Nikt, potarzam, nikt nie wypuscił by kodu w debug, symboli,
barku optymalizacji poza firmami garażowymi.

>> Masz grupę ludzi którzy klepią kod od 20 lat, niektórzy wybitni.
> Masz na myśli jądro Linuksa?

Mam na myśli setki aplikacji.

> Bo już się pogubiłem w Twoich argumentach i o jakim systemie rozmawiamy.

Rozmawiamy o bardzo wielu rzeczach, ale ja mam najwyraźniej kiepskie
zdolności komunikacyjne.

>> Nie, ty pytasz inżynierów w nasa
> O NASA jeszcze w tej dyskusji nie pytałem. Nieumiejętnie trollujesz.

To taka alegoria, choć przypuszczalnie zaraz za użycie tego słowa
zdzieli mnie w łeb była polonistka.

>>>> Ten kod jest niezbędny.
>>> Tego nie pokazałeś.
>> Jak można to udowodnić bez znajomosci
>> architektury aplikacji co jest a co nie niezbedne?
> I gdybyś od początku wyłożył karty na stół, że nie znasz tej architektury, to bym
wiedział, że nie trzeba tak mocno tej dyskusji toczyć.

Nie, ty nie znasz. Wypowiadasz się że "na pewno można coś zmniejszyć"
nie mają sladowego pojęcia o architekturze. Ja mam pojęcie ale wymagało
by kilku lat wyjasniania z kodem (bo kiepski jestem w komunikacji).
Możesz oczywiście podpisać NDA jesli bardzo chbcesz.

> Pozostaję więc przy tym, co udało nam się do tej pory zebrać:
> - brak motywacji biznesowej,
> - kod debugowy,
> - domyślne opcje kompilacji.

Czyli nic nie pojmujesz.

> Jeśli chciałbyś dołożyć coś do tej listy (oprócz wyzwisk), to ja bardzo chętnie.

Nie widze sensu. Nie probujesz się czegokolwiek dowiedzieć. Ot,
wyrzuciłeś z siebie idiotyzm że linkowanie statyczne jest zarąbiste i
teraz nie ma drogi odwrotu, wstyd porzucić, do przodu i huraaa! Prosto w
opary absurdu, debilnych argumentów, idiotycznych eksperymentów, chorych
urojeń.

A świat obok toczy się ze swoimi milionami roboczolat mając Twoje
urojenia głeboko na marginesie.

do góry

On Thursday, November 23, 2017 at 1:26:58 PM UTC+1, fir wrote:
> W dniu środa, 22 listopada 2017 08:05:42 UTC+1 użytkownik M.M. napisał:
> > On Tuesday, November 21, 2017 at 1:35:43 PM UTC+1, Maciej Sobczak wrote:
> > > A to poziom trudności wpływa na stosunek rozmiaru binarki względem liczby linii
kodu?
> > > Ja piszę o tym, że jeżeli weźmiemy Linuksa jako pewny znany punkt odniesienia,
to przykład wielogigabajtowych DLLek tak bardzo od tego punktu odniesienia odbiega,
że aż się prosi o wyjaśnienie. I tego wyjaśnienia nadal nie widać.
> >
> > Wyjaśniam ponownie, hello world w qt gui w wersji debug wraz z bibliotekami dll
> > zajmuje ponad pół gigabajta. W wersji release ponad 50mb. I nie odpowiadajcie
>
>
> patologia - choc ciezko w to uwierzyc

Tyle plików dołącza dedykowane narzędzie - czy ono minimalizuje
czy nie wiem. Faktem jest, że po użyciu tego narzędzia jeszcze
kilka dllek dodaję ręcznie, bo bez nich nie działa ;-)



> ja juz sam z trudem wierze i rozumiem co to za kram gdzie skompilowanie hello
worlda w c++ pod sfmlem twory 1.5 MB exe

Nie rozumiem.


> (c++ nie dotykam od lat, pominawszy ze czesc swoich kodow kompiluje
> w trybie c++, co i tak robi chyba jakies kilkudziesieco-kilobajtowe narzuty ale nie
az takie)
> (zdrowy hello world jak ktos sie zastanawia powinien miec kilka kilobajtow (ze
wzgledu na te alignmenty w formacie pe) jak na razie nie widze powodu by mial miec
wiecej)

Ale nie odbiegajmy za bardzo od linkowania statycznego vs dynamicznego.

>
> postsawowe pytanie co tam dokladnie
> siedzi w tych bloatowanych syfach
> i co to jest (trzeba sie wiec nauczyc troche lepiej reverse engeeneringu i
znajomosci bebechow
> binarek - szkoda ze nikt poza mna tu specjalnie sie tym nie interesuje, a moja
wiedza jest nadal czesciowa)

Za darmo ja tylko szukam nowych algorytmów do AI, na pewno nie będę analizował
budowy exe czy elf dla rozrywki :)

Pozdrawiam

do góry

On Thursday, November 23, 2017 at 6:10:10 PM UTC+1, s...@g...com wrote:
> W dniu 22.11.2017 o 08:05, M.M. pisze:
> > Wyjaśniam ponownie, hello world w qt gui w wersji debug wraz z bibliotekami dll
> > zajmuje ponad pół gigabajta.
>
> To kłamstwo! Wszystkie biblioteki Qt w wersji debug zajmują 313,26MB. A do "Hello
Word" wszystkich nie potrzebujesz! Potrzeba QtCored.dll 12MB + QtGuid.dll 13MB +
QtWidgetsd.dll 11MB. Czyli łącznie 36MB a nie 500!!!

Dedykowanie narzędzie, program o nazwie windeploy.exe, u mnie dodawał
ponad 500MB plików, głównie dlli. Gdy robiłem Twoją metodą, to działało...
cztery lata temu gdy oprogramowanie działało zazwyczaj na jednym
komputerze z jednym osem. Gdy miało działać na wielu wersjach windowsa z
różnymi update, to wywalało się. Dopiero po użyciu windeploy nie mam
niespodzianek.

>
> > Hmmmm czy
> > w przypadku linkowania statycznego w wersji debug linkier za każdym
> > razem musiałby zapisywać na dysk około 500mb danych, podobną ilość
> > danych wczytywać i analizować?
>
> Tu znowu podajesz, że g* wiesz o linkowaniu. Linkowanie statyczne
> polega na pobraniu jedynie tego co użyłeś do exe.
Ty gówno wiesz, bo kompilator musi wstawić zarówno to co użyłeś, jak i to
co do czego nie potrafi obliczyć czy zostanie użyte. A takie obliczenie
nie jest trywialne. Kiedyś było normą, że wstawia wszystko z całego pliku
cpp, jeśli z tego pliku był użyty dowolny element.

do góry

Użytkownik <s...@g...com> napisał:
>> Hmmmm czy
>> w przypadku linkowania statycznego w wersji debug linkier za każdym
>> razem musiałby zapisywać na dysk około 500mb danych, podobną ilość
>> danych wczytywać i analizować?

> Tu znowu podajesz, że g* wiesz o linkowaniu. Linkowanie statyczne polega na
pobraniu
> jedynie tego co użyłeś do exe.

Wszystko "zalezy". Widzalem statyczne linkowane exe-ki, ktore mialy w sobie np.
z pol biblioteki, mimo, ze w kodzie uzyta byla jedna funkcja (wolna od zaleznosci).

AK

do góry

On Monday, November 27, 2017 at 9:57:57 AM UTC+1, AK wrote:
> Użytkownik <s...@g...com> napisał:
> >> Hmmmm czy
> >> w przypadku linkowania statycznego w wersji debug linkier za każdym
> >> razem musiałby zapisywać na dysk około 500mb danych, podobną ilość
> >> danych wczytywać i analizować?
>
> > Tu znowu podajesz, że g* wiesz o linkowaniu. Linkowanie statyczne polega na
pobraniu
> > jedynie tego co użyłeś do exe.
>
> Wszystko "zalezy". Widzalem statyczne linkowane exe-ki, ktore mialy w sobie np.
> z pol biblioteki, mimo, ze w kodzie uzyta byla jedna funkcja (wolna od zaleznosci).
>
> AK

Jaka to była biblioteka i kompilator?

Pozdrawiam

do góry