On Monday, November 20, 2017 at 5:31:27 PM UTC+1, fir wrote:
> W dniu niedziela, 19 listopada 2017 13:21:16 UTC+1 użytkownik fir napisał:
> > W dniu środa, 15 listopada 2017 06:10:23 UTC+1 użytkownik s...@g...com
napisał:
> > > Witam
> > > W wielu "dużych", "profesjonalnych" i "popularnych" programach obserwuję
zjawisko wyłączania z exe całego kodu aplikacji.
> > > Moje pytanie brzmi: Dlaczego wyłącza się dll z exe?
> > >
> > > Moje domniemania:
> > > 1. Żeby używać w innych aplikacjach. Tylko tu pojawia się takie pytanie: Czemu
cały exe jest przerzucany do dll?
> > > 2. Żeby używać w innych aplikacjach jako obiektu COM.
> > > 3. Żeby łatwiej testować (pisać programy exe testujące dll-kę zamiast mieszać
kod roboczy z testowym).
> > >
> > > A może są inne powody? Proszę potwierdzić moje domniemania lub je zweryfikować.
> > >
> > > z góry dzięki
> > > Szyk Cech
> >
> > 1)
> >
> > z dll mozna wyexportowac funkcje, (z exe albo nie mozna albo tez mozna ale
niktorzy i tak tego nie chcą robic (w tej chwili nie pamietam czy sie da))
> > - co prawda nie jestem pewien czy takie exportowanie z exe to dobry pomysl ale
byc moze niektprzy chcą
> > lub muszą to robic (?)
> > (ogolnie architektura wydaje sie prostsza i latwiejsza gdy miedzy dllakami
importy ida tylko w jedną strone ale nie ejestem w stanie powiedziec czy czasem nie
ejst zrobic w dwie, tj czy robienie w dwie strony jest zawsze bledem)
> >
> > 2)
> > dllki mozna dzilic miedzy programami, na przyklad jesli dane fonta wrzuci sie do
dllki a jest on uzywany przez 117 programow to w pamieci bedzie on obecny tylko raz,
> > gdyby zas kazdy z tych programow czytal go z jakiegos pliku .bin
> > klasyczna metodą to por obiloby sie 117 oddzielnych kopii (co prawda
> > to daloby sie obejsc chyba przez m-mapowanie plikow itd (mozna by sie zastanowic
ktory z tych sposobow
> > dll czy mmap bylby lepszy /ogolniejszy)
> >
> > (podbnie jak wyzej nie jestem jednak pewien czy exekow tez nie mozna dzilic
miedzy procesami (instancjami) oraz czy o to moze tu chodzic)
> >
> > jeslibym jednak mial cos podejrzewac o powod to te dwa punkty (ciut bardziej
pierwszy niz drugi ale drugi tez byc moze moze byc prawdopodobny jesli ktos pisze na
chacie nie jeden a kilka programow robiacych podobne rzeczy)
> >
> > 3) trzeci powod tez jest prawdopodobny, komus moze nie bardzo zalezec czy
kompilowac
> > jako exe czy dll i robi dll nawet wtedy gdy moglby robic exe
>
> inna opcja to ew byc moze
> 4) program ktory sam siebie chialby aktualizowac (moden w ostatnich czasach):
> sciagnac z netu na dysk dllke z glownym programem,

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.

Pozdrawiam

do góry

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

> > A to poziom trudności wpływa na stosunek rozmiaru binarki względem liczby linii
kodu?
>
> Na podstawie bredni o tym ile lat pisano jądro linuxa wymysliłes sobie
> że nie da się napisac aplikacji tak dużej aby kod zajmował GB.

Bardzo niestarannie omijasz kontekst tego o czym dyskutowaliśmy.
Chodziło mi o zachowanie proporcji w tych parametrach. Nie ma problemu w napisaniu
prostego programu, który dużo zajmuje. Pytanie było o to, czy proporcje są zachowane
- a skoro nie są, to czy ten brak proporcji jest uzasadniony.
Z Twoich wypowiedzi wynika, że nie ma takiej motywacji. To by sporo wyjaśniało, ale
wątpliwości nie rozwiewa.

> Czy jak bym wziął przecietne seminarium jako punkt odniesienia do badań
> nad religijnością obywateli

Ale ja nie wziąłem jądra Linuksa do badań nad tym, kto lubi jaki OS.
Jeśli chcesz się trzymać tej seminaryjnej analogii, to pytanie było raczej o indeks
BMI wśród studentów. I nie, nie miałbym nic przeciwko, żeby wziąć seminarium jako
jakiś znany punkt odniesienia i stwierdzić, że skoro gdzieś indziej ludzie mają
zupełnie odmienny indeks BMI, to warto zapytać, dlaczego.

> Wyjaśnienie: w rzeczywistym świecie sa projekty większe
> kilkanascie/dziesiąt razy od Linuxa pod względem kodu.

I właśnie o to pytam. O te proporcje, również w sensie czasu pracy. Bo skoro coś jest
dziesiąt razy większe a nie zajęło dziesiąt razy więcej pracy, to znowu gdzieś
zniknęły proporcje. Pytam gdzie, a słyszę wyzwiska.

> > Nie napisałem nigdzie, że plik nie może mieć takiego rozmiaru
>
> Znowu czas na cytat:
>
> "Co z kolei każe poddać pod wątpliwość, czy w ogóle taki program dało
> się na tej planecie napisać"

I znowu niestarannie omijasz kontekst. Chodziło o proporcjonalną ilość pracy, czyli
powiedzmy milion roboczo-lat. I tego nie dowiesz się z Total Commandera. Właśnie w
ten sposób nie odpowiadasz na pytania a wyzwiska tego nie uzupełnią.

> Czyli już odwrót. Już nie tyle nie da sie napisać co nie ma
> uzasadnienia. No no, szybko uciekasz.

Pytam, czy te zupełnie odmienne proporcje mają uzasadnienie. I nadal pytam, nigdzie
nie uciekłem, możesz śmiało odpowiadać.

> > I w ten sposób sam podrzuciłeś argument do dyskusji wskazując, że nie ma
motywacji, żeby te DLLki były mniejsze.
>
> Nie ma. Motywacja jest biznesowa.

I mamy piękną odpowiedź. Czyli gigabajtów jest tyle, bo tyle może być i nie ma
potrzeby, żeby było mniej. Nie można było tak od razu?

> Ludzie piszacy tak wielki kod mają
> *ZUPEŁNIE* inne problemy niż te z poziomu gimnazjum.

Ale ciągle nie napisałeś, jakie. Poza biznesowym. A ja bym chętnie o problemach
podyskutował, zwłaszcza o technicznych - tylko najchętniej z kimś, kto też chciałby o
technice.

> > Napisałem pustą funkcję w C i bez żadnych optymalizacji zrobiłem z niej:
> > - plik obiektowy: 687 bajtów
> > - archiwum do linkowania statycznego: 840 bajtów
> > - dynamiczną bibliotekę dzieloną: 56731 bajtów
>
> Brawo. Kupiłem garnek. Wlałem do niego kroplę wody. Zważyłem i wyszło 1kg.
> Wniosek: dwie krople wody w garnku to już 2kg.

Nie napisałem takiego wniosku. Wnioskiem jest to, że sama suma rozmiarów dużej liczby
plików nie przekonuje mnie, że tyle tych bajtów musi być.

> Zazwyczaj detale jak kod debugowy, symbole itp
> duperele

Brawo. Przy odrobinie wysiłku potrafisz między wyzwiskami zmieścić parę słów
technicznych.
Teza o kodzie debugowym jest dobrą wskazówką.

> A już przeciez chciałeś pisać do MS że mają poważnego
> buga w implementacji dll...

Po pierwsze nie chciałem pisać a po drugie to nawet nie był kompilator MS a po
trzecie nawet nie sugerowałem, że to jest bug. Czyli zrobiłeś trzy błedy w jednym
trollowym zdaniu.
Bardzo niestarannie trollujesz, masz słabą technikę. Nawet listę wyzwisk masz jakąś
taką ubogą.

> >> Więc zatrudnij się w jednej z większych firm programistycznych w okolicy
> > A mógłbyś coś polecić?
>
> Nie, miałbym ich na sumieniu.

Czyli jednak zakładasz, że przeszedłbym rekrutację? A jeżeli ja bym ją przeszedł, to
może jest tam już więcej takich ludzi? Ale wtedy - dlaczego mnie tam wysyłasz na
naukę?

Widzisz? Ciągle beznadziejnie trollujesz i zamiast mnie obrazić, to się tylko
kompromitujesz. Mógłbyś tego skilla poćwiczyć gdzie indziej?

> Nigdy jak widać nie pracowaleś nad projektem który ma
> ~20 lat kodu stukanego przez 4 pokolenia ludzi.

Nie ma potrzeby włączać mojej prywatnej historii do tej dyskusji (chyba że musisz
robić osobiste wycieczki z braku właściwych argumentów), ale jeśli możemy nawiązac do
tego znanego punktu odniesienia jakim jest wspomniane już jądro Linuksa, to jest to
projekt *jeszcze starszy*. I skoro nie zaistniały tam mechanizmy zwiększające jego
rozmiar do gigabajtów, to najwyraźniej znowu sięgnąłeś po niewłaściwy argument.

Bo teraz mamy dodatkowy parametr: 15 milionów linii kodu, >20 lat trwania projektu,
udział dużej liczby ludzi rozproszonych po całym świecie i... raptem kilkadziesiąt
megabajtów kodu wynikowego.
Czyli jeszcze bardziej mam wątpliwości, czy te gigabajty tam muszą być.

> Najlepiej idź i wyjasnij
> że trzeba wszystko przepisać w C#.

A dlaczego najlepiej?
Pytam, bo po pierwsze ani razu o tym nie wspomniałem (co wskazuje na Twoją ponowną
nieumiejętną próbę wciskania mi nie moich słów), a po drugie to też jest ciekawy
temat.

> Byłes już u tych imbecyli z Photoshopa

Znowu wyzwiska. Masz bardzo niskie umiejętności komunikacyjne.

> > Ale jeszcze nie wykazałeś, że te GB są uzasadnione.
>
> W tej chwili właśnie strzeliłeś w pysk programistów wszystkich dużych
> aplikacji.

Nie, niektóre duże aplikacje nie mają gigabajtów. Już o tym pisałem. Stąd pytanie,
czy te gigabajty muszą tam być. W dodatku, to pytanie nie musi być obraźliwe - tak
jak pytanie o to, czy samochód musi dymić i hałasować, nie musi być obraźliwe dla
*wszystkich* kierowców. Niektórym nie dymi i nie hałasuje.

> I serio, masz czelnośc twierdzić że to ja obrażam ludzi?

Tak. Statystykę użytych wyzwisk zrobisz samodzielnie, czy trzeba pomóc?

> Ten kod jest niezbędny.

Tego nie pokazałeś. Odniosłeś się do motywacji biznesowych oraz do kodu debugowego i
symboli. To jedyne ślady rzeczowych argumentów w tej dyskusji, ale żadnego z nich nie
określiłbym jako "niezbędny".

> Nie mam interesu w
> przekonywaniu kogokolwiek.

W tym jednym punkcie mnie przekonałeś.

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

do góry

On 11/22/2017 3:33 PM, Maciej Sobczak wrote:
> Bardzo niestarannie omijasz kontekst tego o czym dyskutowaliśmy.
> Chodziło mi o zachowanie proporcji w tych parametrach. Nie ma problemu w napisaniu
prostego programu, który dużo zajmuje. Pytanie było o to, czy proporcje są zachowane
- a skoro nie są, to czy ten brak proporcji jest uzasadniony.

Nie jest proste. Pozwól że zacytuje:

"W każdym razie, ja nie umiałbym naklepać tyle kodu (nawet z kolegami),
żeby mi się zrobiło z tego parę GB"

> Z Twoich wypowiedzi wynika, że nie ma takiej motywacji. To by sporo wyjaśniało, ale
wątpliwości nie rozwiewa.

Nie. To jest tylko odległy parametr w funkcji celu. Jesli dostarczysz
system embedded o rozmarze 10GB to nie osiągniesz celu bieznesowego.
Jesli dostarczysz apliakcję EDA o prędkości żółwia to tez nie osiągniesz.

>> Czy jak bym wziął przecietne seminarium jako punkt odniesienia do badań
>> nad religijnością obywateli
> Ale ja nie wziąłem jądra Linuksa do badań nad tym, kto lubi jaki OS.

Wziąłeś bardzo specyficzny projekt do oceny możliwości lub nie napisania
gigabajtów kodu.

>> Wyjaśnienie: w rzeczywistym świecie sa projekty większe
>> kilkanascie/dziesiąt razy od Linuxa pod względem kodu.
> I właśnie o to pytam. O te proporcje, również w sensie czasu pracy. Bo skoro coś
jest dziesiąt razy większe a nie zajęło dziesiąt razy więcej pracy, to znowu gdzieś
zniknęły proporcje.

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.

> Pytam gdzie, a słyszę wyzwiska.

Słyszysz bo bezustannie emitujesz je w kierunku ludzi którzy takimi
tematami zajmują się od lat (nie da się, niemożliwe, ktoś zlinkował
pornola do dllki itp). Jesteś jak ten jehowiec, co przychodzi i gada o
swoich urojeniach głuchy na fakty. W końcu się na takiego macha ręką, bo
nieuleczalny.

>>> Nie napisałem nigdzie, że plik nie może mieć takiego rozmiaru
>> Znowu czas na cytat:
>> "Co z kolei każe poddać pod wątpliwość, czy w ogóle taki program dało
>> się na tej planecie napisać"
> I znowu niestarannie omijasz kontekst. Chodziło o proporcjonalną ilość pracy, czyli
powiedzmy milion roboczo-lat. I tego nie dowiesz się z Total Commandera. Właśnie w
ten sposób nie odpowiadasz na pytania a wyzwiska tego nie uzupełnią.

Ale dowiem się z doświadczeń swoich i okolicznych. Np. przez fakt że
programy sa napisane pod architekture x86/Sparc wynika ze sa pisane nie
dlużej niż jakieś 30 lat, no i zatrudnienia w firmach. Ale nie przejmuj
się, to tylko głupie fakty. Miliony roboczolat brzmia zdecydowanie
bardziej ekscytująco.

> I mamy piękną odpowiedź. Czyli gigabajtów jest tyle, bo tyle może być i nie ma
potrzeby, żeby było mniej. Nie można było tak od razu?

Nie można bo dyskutuje z misiaczkiem co twierdził że na tej planecie nie
sposób takiego kodu napisać.

>> Ludzie piszacy tak wielki kod mają
>> *ZUPEŁNIE* inne problemy niż te z poziomu gimnazjum.
> Ale ciągle nie napisałeś, jakie.

Wiele z nich jest oczywistych. Zacznij od zastanowienia się:
a) ile czasu trwa linkowanie gigabajtowych execów
b) ile na to potrzeba pamięci
c) jak rozwiązać problem testowania regresyjnego
d) jak uzywać dowolnych narzedzi debugowych

To tak na początek. Wyboraź sobie że mnożysz te czasy i pamięci razy
ilośc programistów (setki) i liczysz dolary na prąd i papier toaletowy.

To tylko zerkniecie przez dziurkę od klucza do przeciętnej firmy
pokazujące margines oczywistosci. Świadomie pomijam problemy u klienta i
setki innych związanych z architekturą.

> Poza biznesowym. A ja bym chętnie o problemach podyskutował, zwłaszcza o
technicznych - tylko najchętniej z kimś, kto też chciałby o technice.

No to dyskutuj. To jest cos odmiennego niż pokazywanie faktów palcem i
mówienie że to niemożliwe.

>> Brawo. Kupiłem garnek. Wlałem do niego kroplę wody. Zważyłem i wyszło 1kg.
>> Wniosek: dwie krople wody w garnku to już 2kg.
> Nie napisałem takiego wniosku. Wnioskiem jest to, że sama suma rozmiarów dużej
liczby plików nie przekonuje mnie, że tyle tych bajtów musi być.

Trudno. Jehowca tez nie posób przekonać do czegokolwiek.

>> Zazwyczaj detale jak kod debugowy, symbole itp
>> duperele
> Brawo. Przy odrobinie wysiłku potrafisz między wyzwiskami zmieścić parę słów
technicznych.
> Teza o kodzie debugowym jest dobrą wskazówką.

Tak i jest ona wyświetlona prawie na środku ekranu Visuala. Nie
spodziewaj sie że ktokolwiek powaznie będzie dyskutowal z kimś kto nie
wie jakie efekty daje domyślna kompilacja w Visualu choć wyciąga wnioski
zmieniające przyszłość świata.

>> A już przeciez chciałeś pisać do MS że mają poważnego
>> buga w implementacji dll...
> Po pierwsze nie chciałem pisać a po drugie to nawet nie był kompilator MS a po
trzecie nawet nie sugerowałem, że to jest bug. Czyli zrobiłeś trzy błedy w jednym
trollowym zdaniu.

To była ironia. Ciezko w niej robić błędy.

> Bardzo niestarannie trollujesz

Bardzo dziękuje, dokładnie tak własnie jest.

>, masz słabą technikę. Nawet listę wyzwisk masz jakąś taką ubogą.

Ja ich nie używam jako ja. Zazwyczaj krystalizuje tylko wypowiedzi
innych w formie ironii.

>>>> Więc zatrudnij się w jednej z większych firm programistycznych w okolicy
>>> A mógłbyś coś polecić?
>> Nie, miałbym ich na sumieniu.
> Czyli jednak zakładasz, że przeszedłbym rekrutację?

Obecnie biora każdego kto ma choć kawalek palca do stukania w klawisze.
No dobra, nie, nie wszystkie. Niektóre nie biorą nawet ludzi po
mad-fib-bzdziu. Zalezy do firmy. Zazwyczaj duże korporacje robiące durze
rzeczy mają kilka poziomów dla programisty i znajdzie się coś dla
poziomu -1 a potem sie pniesz. Mam nadzieje że nie zakładasz że trafisz
od razu na stanowisko głównego architekta.

> A jeżeli ja bym ją przeszedł, to może jest tam już więcej takich ludzi?

Cała masa, jak mówie zalezy co chcesz robić. Możesz pisać router do fpga
ale raczej nie stanie się to godzine po rekrutacji. Coś bardziej po 10
latach.

> Ale wtedy - dlaczego mnie tam wysyłasz na naukę?

Ponieważ tak głupio skonstruowany jest swiat że warto celować wyżej niz
swoja obecna wiedza.

>> Nigdy jak widać nie pracowaleś nad projektem który ma
>> ~20 lat kodu stukanego przez 4 pokolenia ludzi.
> Nie ma potrzeby włączać mojej prywatnej historii do tej dyskusji (chyba że musisz
robić osobiste wycieczki z braku właściwych argumentów), ale jeśli możemy nawiązac do
tego znanego punktu odniesienia jakim jest wspomniane już jądro Linuksa, to jest to
projekt *jeszcze starszy*. I skoro nie zaistniały tam mechanizmy zwiększające jego
rozmiar do gigabajtów, to najwyraźniej znowu sięgnąłeś po niewłaściwy argument.

Jeszcze starszy od jądra linuxa jest kod w zegarku na korytarzu w
technikum gdzie uczęszczałem, na 8051. Jakie wnioski moglibysmy z tego
wyciągnąc w dyskusji nad aplikacjami o rozmiarze x GB?

> Bo teraz mamy dodatkowy parametr: 15 milionów linii kodu, >20 lat trwania projektu,
udział dużej liczby ludzi rozproszonych po całym świecie i... raptem kilkadziesiąt
megabajtów kodu wynikowego.
> Czyli jeszcze bardziej mam wątpliwości, czy te gigabajty tam muszą być.

Jak już mówiłem, możesz zmieniać świat. Idziesz do firmy, zatrudniają
Cię i od razu walisz do szefa że masz watpliwości. I dostajesz wolna
reke, odlinkowujesz pornola z ddlki, produkt zarabia miliard dolarów i
się budzisz.

Znowu nazywasz ludzi pracujących z tym kodem głupimi. No bo niby jak to
nie potrafią zredukować rozmiaru? Czyli że głupi no bo jak inaczej.

>> Najlepiej idź i wyjasnij
>> że trzeba wszystko przepisać w C#.
> A dlaczego najlepiej?

No to może w Go. Im bardziej ciekawy język wybierzesz tym klepanie w
ramie bedzie miało bardziej charakter kierunkowy do najbliższych drzwi.

> Pytam, bo po pierwsze ani razu o tym nie wspomniałem (co wskazuje na Twoją ponowną
nieumiejętną próbę wciskania mi nie moich słów), a po drugie to też jest ciekawy
temat.

Tak bardzo. Przetestuj sam jakie wzbudzi zaciekawienie u kierownika
projektu. Jakas prosta rewolucyjna myśl. Coś w rodzaju "zlinkujmy
wszystko statycznie" albo "piszmy na ifona a nie na komputery". Tak zeby
zakrztusił sie śmiertelnie herbatą z donutem.

>> Byłes już u tych imbecyli z Photoshopa
> Znowu wyzwiska. Masz bardzo niskie umiejętności komunikacyjne.

Tak, on sa wręcz śladowe. Ledwo litery stawiam na ekranie.

Ale umysl bystry i zauważylem że (tu przecieram oczy ze zdumienia)
zrobiłeś sobie wycieczkę osobistą na ktorą to przed chwilą się sam
oburzyłeś. No no :) Robisz postępy, już za chwile możesz pisac na advocacy.

Pamiętaj ze udawanie braku hipokryzji jest mocno nieludzkie i krzywdzące.

>>> Ale jeszcze nie wykazałeś, że te GB są uzasadnione.
>> W tej chwili właśnie strzeliłeś w pysk programistów wszystkich dużych
>> aplikacji.
> Nie, niektóre duże aplikacje nie mają gigabajtów. Już o tym pisałem. Stąd pytanie,
czy te gigabajty muszą tam być.

Po raz drugi strzeliłeś programistów w pysk.

Masz grupę ludzi którzy klepią kod od 20 lat, niektórzy wybitni.
Przychodzi przecietny misiaczek z zadupia internetu i mówi "ale czy wy
jesteście pewni że dobrze robicie? Bo ja tu mam taka makietkę dllki...".
No i co na to masz powiedzieć?

> W dodatku, to pytanie nie musi być obraźliwe - tak jak pytanie o to, czy samochód
musi dymić i hałasować, nie musi być obraźliwe dla *wszystkich* kierowców. Niektórym
nie dymi i nie hałasuje.

Nie, ty pytasz inżynierów w nasa czy na pewno silniki do rakiet musza
być takie duże bo sąsiad ma taką kosiarkę i w niej ...

>> I serio, masz czelnośc twierdzić że to ja obrażam ludzi?
> Tak. Statystykę użytych wyzwisk zrobisz samodzielnie, czy trzeba pomóc?

Ja nie wyzywam ludzi. Ja stosuje tą sztuczkę aby pokazać jak Ty (mam
nadzieje nieświadomie) traktujesz wszystkich na około za idiotów bo
przeciez można zrobić taki eksperyment z dllką że od razu wiadomo że źle
robią ...

>> Ten kod jest niezbędny.
> Tego nie pokazałeś.

Jakiego dowodu oczekujesz? Machania rekami? Przysięgi na jakąś ksiązke?
Certyfikatu z pieczątką? Jak można to udowodnić bez znajomosci
architektury aplikacji co jest a co nie niezbedne? Myslisz że wiedza o
tym jak coś działa, jakie ma założenia, algorytmy, budowę, problemy i
rozwiązania daje się zmieścić w małym trolingu internetowym? Jak juz
mówiłem: celuj wyżej niz Nabino to zrozumiesz jaki popełniasz bład w
płytkiej ocenie problemu.

> Odniosłeś się do motywacji biznesowych oraz do kodu debugowego i symboli. To jedyne
ślady rzeczowych argumentów w tej dyskusji, ale żadnego z nich nie określiłbym jako
"niezbędny".

Bo przeoczyłeś wszystkie ważne.

do góry

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

do góry

On 11/22/2017 6:20 PM, Sebastian Biały wrote:
> durze

Hehehehe. Jeśli się ktoś zadławił to przepraszam.

do góry

> 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. Praca w zespole bez kontraktów, to jak taplanie się w
błocie - wszyscy obrywają przy pracy jednego. Wraz z rozwojem aplikacji,
pojawia się coraz więcej zalet trzymania się interfejsów. A jeżeli
napotyka się "nieprzewidziane cechy", to z moich obserwacji tylko
dlatego że ktoś w zespole nie do końca rozumie idee i albo napisał
sztywny most albo ma się mini aplikację wewnątrz docelowej, a nie komponent.

--
Pozdrawiam,
Mateusz Bogusz

do góry

W dniu niedziela, 19 listopada 2017 13:21:16 UTC+1 użytkownik fir napisał:
>
> 1)
>
> z dll mozna wyexportowac funkcje, (z exe albo nie mozna albo tez mozna ale niktorzy
i tak tego nie chcą robic (w tej chwili nie pamietam czy sie da))


przy okazji tak naprawde jest to dosyc wazna kwestia.. poszukalem i znalazlem wg tego
linka sie (NA SZCZESCIE) da

https://stackoverflow.com/questions/24024227/can-a-s
tandard-executable-have-an-export-table

czemu jest to wazne? otoz moge podac przyklad mojego eksperymentalnego projektu do
programowania agentowego, mam tam program exe ktory jest jakby srodowisiem dla
agentow (i ktory dalej bede chyba nazywal 'hostem') i dwie dllki dla dwu grup agentow
roznych typow

przykladowy kod takiego agenta btw
to

#include <stdlib.h>
#include <stdio.h>

extern "C"
{
__declspec(dllexport) int RunAgentBlack();
__declspec(dllimport) int Move(int dx, int dy);

}

int RunAgentBlack()
{
int dx = rand()%3 - 1;
int dy = rand()%3 - 1;

Move(dx, dy);

return 0;
}


gdyby nie mozna bylo exportowac funkcji z ekse znaczy to ze musialbym pisac jakis
starter.exe
i host.dll po czym ciagac te wszystkie niebedne referencje miedzy dllkami (i tak
nieststy w tym projakcie swoja droga robilem
bo niedoczytalem ze sie ponoc jednak da) teraz chyab to przerobie na pojedynczy
host.exe (bo mam lekka chec sie za to wziac) ktory bedzie exportowal ta metode move,
and thatz all

swoja droga ten projekt bedzie przykladem na to jak programowanie agentowe da sie
robic praktycznie w
c przy pomocy c i dll-ek (byc moze
w przyszlosci sie przerzuce bardziej na taki agentowy design)

do góry

> 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

O jakim systemie teraz napisałem?
...
Wiesz, że nie zgadłeś?

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.

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

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

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

> Jesteś jak ten jehowiec

O, nowe.

> Ale dowiem się z doświadczeń swoich i okolicznych. Np. przez fakt że
> programy sa napisane pod architekture x86/Sparc wynika ze sa pisane nie
> dlużej niż jakieś 30 lat, no i zatrudnienia w firmach. Ale nie przejmuj
> się, to tylko głupie fakty. Miliony roboczolat brzmia zdecydowanie
> bardziej ekscytująco.

Tak niestarannie trollujesz, że nawet swoich sąsiednich zdań nie kojarzysz.
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.
Właśnie to wskazuje na zaburzenie proporcji (czyli: ktoś przy mniejszym wysiłki
zrobił większą binarkę).

> dyskutuje z misiaczkiem co twierdził że na tej planecie nie
> sposób takiego kodu napisać.

Nadal twierdzę, że nie da się upchnąć miliona roboczo-lat w 30, które były dostępne.
Stąd obserwacja, że mamy do czynienia z innymi proporcjami w czasach i rozmiarach. A
stąd pytanie, dlaczego.

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

> Wiele z nich jest oczywistych. Zacznij od zastanowienia się:
> a) ile czasu trwa linkowanie gigabajtowych execów
[...]

Moje pierwsze pytanie w tej dyskusji było: czy statycznie zlinkowane byłoby mniejsze.
Nie wiemy tego (sam napisałeś, że nie możesz sprawdzić), więc teraz Twoje pytanie o
to ile czasu trwa linkowanie gigabajtowych execów jest bezpodmiotowe. Najpierw
ustalmy, czy te gigabajty byłyby w statycznie zlinkowanym programie. Tego nadal nie
wiemy, bo z braku możliwości przeprowadzenia testu pozostają tylko domysły,
ewentualnie wyzwiska.

> To tak na początek. Wyboraź sobie że mnożysz te czasy i pamięci razy
> ilośc programistów (setki)

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

> Nie
> spodziewaj sie że ktokolwiek powaznie będzie dyskutowal z kimś kto nie
> wie jakie efekty daje domyślna kompilacja w Visualu

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

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

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

> > Czyli jednak zakładasz, że przeszedłbym rekrutację?
>
> Obecnie biora każdego kto ma choć kawalek palca do stukania w klawisze.

Pewnie dlatego kompilują z domyślnymi opcjami...

> 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ł.
Ale jak już napisałeś - ta branża jest specyficzna. :-)

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

> Jakie wnioski moglibysmy z tego
> wyciągnąc

Bardzo starannie nie wyciągasz żadnych.

> Znowu nazywasz ludzi pracujących z tym kodem głupimi.

Nic podobnego. Pytam tylko. I do tej pory mamy takie odpowiedzi, po odfiltrowaniu
wyzwisk:

- nie ma potrzeby biznesowej, żeby był mniejszy rozmiar,
- kod debugowy,
- stosowanie domyślnych opcje kompilacji

> Masz grupę ludzi którzy klepią kod od 20 lat, niektórzy wybitni.

Masz na myśli jądro Linuksa?
Bo już się pogubiłem w Twoich argumentach i o jakim systemie rozmawiamy.

> Nie, ty pytasz inżynierów w nasa

O NASA jeszcze w tej dyskusji nie pytałem. Nieumiejętnie trollujesz.

> Ja nie wyzywam ludzi. Ja stosuje tą sztuczkę

Gdybyś był politykiem, miałbyś już mema za to stwierdzenie.

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

Pozostaję więc przy tym, co udało nam się do tej pory zebrać:

- brak motywacji biznesowej,
- kod debugowy,
- domyślne opcje kompilacji.

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

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

do góry

W dniu czwartek, 23 listopada 2017 11:55:53 UTC+1 użytkownik Maciej Sobczak napisał:
> > 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
>
> O jakim systemie teraz napisałem?
> ...
> Wiesz, że nie zgadłeś?
>
> 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.
>
> Stąd wątpliwości i szukanie dalszych argumentów.
>
> Odpowiedzi merytoryczne do tej pory:
> - nie ma motywacji, żeby było mniej
> - kod debugowy i symbole
>
> To sa dobre odpowiedzi (ale potrafię sobie wyobrazić ich więcej).
>
> > Jesteś jak ten jehowiec
>
> O, nowe.
>
> > Ale dowiem się z doświadczeń swoich i okolicznych. Np. przez fakt że
> > programy sa napisane pod architekture x86/Sparc wynika ze sa pisane nie
> > dlużej niż jakieś 30 lat, no i zatrudnienia w firmach. Ale nie przejmuj
> > się, to tylko głupie fakty. Miliony roboczolat brzmia zdecydowanie
> > bardziej ekscytująco.
>
> Tak niestarannie trollujesz, że nawet swoich sąsiednich zdań nie kojarzysz.
> 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.
> Właśnie to wskazuje na zaburzenie proporcji (czyli: ktoś przy mniejszym wysiłki
zrobił większą binarkę).
>
> > dyskutuje z misiaczkiem co twierdził że na tej planecie nie
> > sposób takiego kodu napisać.
>
> Nadal twierdzę, że nie da się upchnąć miliona roboczo-lat w 30, które były
dostępne. Stąd obserwacja, że mamy do czynienia z innymi proporcjami w czasach i
rozmiarach. A stąd pytanie, dlaczego.
>
> BTW - misiaczek też jest nowy w tej dyskusji. Gorzej, że wypalasz się na
niewłaściwym odcinku i brakuje Ci energii na realną dyskusję.
>
> > Wiele z nich jest oczywistych. Zacznij od zastanowienia się:
> > a) ile czasu trwa linkowanie gigabajtowych execów
> [...]
>
> Moje pierwsze pytanie w tej dyskusji było: czy statycznie zlinkowane byłoby
mniejsze. Nie wiemy tego (sam napisałeś, że nie możesz sprawdzić), więc teraz Twoje
pytanie o to ile czasu trwa linkowanie gigabajtowych execów jest bezpodmiotowe.
Najpierw ustalmy, czy te gigabajty byłyby w statycznie zlinkowanym programie. Tego
nadal nie wiemy, bo z braku możliwości przeprowadzenia testu pozostają tylko domysły,
ewentualnie wyzwiska.
>
> > To tak na początek. Wyboraź sobie że mnożysz te czasy i pamięci razy
> > ilośc programistów (setki)
>
> Słyszałem o buildach integracyjnych off-line.
> Nie ma potrzeby, żeby każdy programista linkował u siebie kompletny system.
> Podobnie jest z testami.
>
> > Nie
> > spodziewaj sie że ktokolwiek powaznie będzie dyskutowal z kimś kto nie
> > wie jakie efekty daje domyślna kompilacja w Visualu
>
> Ja nawet przez chwilę nie zakładałem, że w takiej specyficznej branży ktoś używa
domyślnych opcji kompilacji. Naprawdę.
>
> Ale jeśli używa się domyślnych, to jest to kolejny trop.
>
> Nadal jednak nie wpada mi to do kategorii "niezbędne".
>
> > > Czyli jednak zakładasz, że przeszedłbym rekrutację?
> >
> > Obecnie biora każdego kto ma choć kawalek palca do stukania w klawisze.
>
> Pewnie dlatego kompilują z domyślnymi opcjami...
>
> > 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ł.
> Ale jak już napisałeś - ta branża jest specyficzna. :-)
>
> > 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.
>
> > Jakie wnioski moglibysmy z tego
> > wyciągnąc
>
> Bardzo starannie nie wyciągasz żadnych.
>
> > Znowu nazywasz ludzi pracujących z tym kodem głupimi.
>
> Nic podobnego. Pytam tylko. I do tej pory mamy takie odpowiedzi, po odfiltrowaniu
wyzwisk:
>
> - nie ma potrzeby biznesowej, żeby był mniejszy rozmiar,
> - kod debugowlat, niektórzy wybitni.
>
> Masz na myśli jądro Linuksa?
> Bo już się pogubiłem w Twoich argumentach i o jakim systemie rozmawiamy.
>
> > Nie, ty pytasz inżynierów w nasa
>y,
> - stosowanie domyślnych opcje kompilacji
>
> > Masz grupę ludzi którzy klepią kod od 20
> O NASA jeszcze w tej dyskusji nie pytałem. Nieumiejętnie trollujesz.
>
> > Ja nie wyzywam ludzi. Ja stosuje tą sztuczkę
>
> Gdybyś był politykiem, miałbyś już mema za to stwierdzenie.
>
> > >> 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ć.
>
> Pozostaję więc przy tym, co udało nam się do tej pory zebrać:
>
> - brak motywacji biznesowej,
> - kod debugowy,
> - domyślne opcje kompilacji.
>
> Jeśli chciałbyś dołożyć coś do tej listy (oprócz wyzwisk), to ja bardzo chętnie.
>

1) teoretycznie mozliwe sa takie
wielkie procesy na kilka GB ale
ja powiatpiewam w to glownie dlatego ze wydaje mi sie ze takie wielkie programy
raczej beda jakimis raczej zestawami procesow a nie pojedynczym procesem
(jak ktos chce blysnac ze zna takie wielkie procesy to prosze o konkretne dane bo
inacczej to zachowywanie sie jak prz4edszkolak)

2) jak podalem wyliczenia takie wielkie binarki to nie miliony
roboczo lat tylko kilka tysiecy
(przy zalozeniu dosyc przezwoitej
produktywnosci w firmach moze z tym byc gorzej niz zalozona ale nie wiem dokladnie )

3) kod w postaci dllek i libek statycznych zamuje dokladnie tyle samo
(w przypadku libek mnozna czasem linkowac wybiórczo ale to nie ma wiekszego znaczenia
imo pominawszy
patologiczne przypadki gdy ktos linkuje dziesiatki dllek ktorych prawie wcale nie
uzywa ot by zlinkowac -
w przypadku dllek za to mozna wspoldzielic dllki miedzy procesami
co w zaleznosci od systemu moze spowodowac zmniejszenie zuzycia pamieci)
(osobiscie jestem raczej fanem linkowanie dynamicznego - jesli robi sie je dobrze)

do góry