Komentowana treść: Kod źródłowy Odyssey na GitHub
11.01.2016 15:22
[#61]
Re: Kod źródłowy Odyssey na GitHub
@pamp3rs, post #54
Albo nie chcesz przeczytać dokładnie to co napisałem wcześniej albo czytasz po łebkach. Ja pisałem o PRZESUNIĘCIU środków z bounty JIT na bounty naprawy endianów
dobrze, nalezy wiec zrozumiec ze powiadomiles krzystofa o tej mozliwosci i nie byl zainteresowany. dobrze. w takim razie uwazam ze wplacanie na takie bounty w tej danej chwili nie ma sensu. krzysztof prawdopodobnie bedzie sluzyl pomoca ale wolalby zeby ktos inny przejal to zadanie.
13.01.2016 11:27
[#70]
Re: Kod źródłowy Odyssey na GitHub
@recedent, post #65
To raczej demotywujące - odpowiedź w stylu "Mamy was w d***, będziemy robić te same endianowe błędy w silniku co do tej pory, a wy se łatajcie za każdym razem jak tam chcecie".
z ich punktu widzenia to nie sa bledy. po prostu big endian dla nich nie istnieje, no bo tak faktycznie jest na obecnym rynku. nie ma co inwestowac pracy w cos co przynosi moze 0,0001% wiecej uzytkownikow i to jeszcze na jakichs obskurnych platformach ktore trzebaby bylo ewentualnie supportowac, odpowiadajac na, jak nalezy sie spodziewac, steki glupich pytan, bo przeciez juz nagabywanie czy webkit moglby obslugiwac big endian samo w sobiejest naiwne.
trzeba sobie wyobrazic, wedlug bigfoota jest tych miejsc w kodzie chyba setki, trzebaby bylo tam powstawiac ifdefy, jakies sanity checki czy co no i sam kod do konwesji. z punktu widzenia autorow webkita cos takiego na pewno nie wyglada zachecajacao. niestety.
pytanie, czy jest wogole jakas mozliwosc pielegnacji kodu tak by nie trzebaby bylo portowac i reperowac calego silnika webkita przy kazdej nowej wersji. ja tego szczeze mowiac, nie widze. a jesli tak jest to cala sprawa nie ma sensu.
13.01.2016 11:48
[#71]
Re: Kod źródłowy Odyssey na GitHub
@wawrzon, post #70
Przecież oryginalnie WebKit działał bez problemu na big endianach. Te błędy zostały dodane z czasem, w wyniku prac developerskich, których po prostu już na big endianach nikt nie testował. Nie wynika to raczej ze złej woli developerów, czy stanowiska "od dziś chrzanić big endian".
Problem częściowo leży w Amigowym podejściu do open source. Czyli: bierzemy jakiś projekt FOO w wersji XYZ, i rzeźbimy sobie w nim na boku tak żeby było nam łatwiej, bez porozumienia z oryginalnymi twórcami, po czym dumni z siebie udostępniamy ten crap, przepraszam "port" Amispołeczności. Później wychodzi kolejna wersja projektu FOO, i całą robotę trzeba wykonać niemalże od nowa.
Gdyby chcieć do tego podejść na sposób zgodny z ideologią open source, to Ami-programista musiałby dołączyć do zespołu zajmującego się rozwojem danego projektu i na bierząco rozwijać/łatać/poprawiać rzeczy. Tylko to wymagałoby dodatkowego wysiłku, pisania w zespole, konfrontacji stylu czy jakości kodu z innymi, implementacji testów, pisania dokumentacji itd.
Na takie "poświęcenie" wielu już nie stać.
Problem częściowo leży w Amigowym podejściu do open source. Czyli: bierzemy jakiś projekt FOO w wersji XYZ, i rzeźbimy sobie w nim na boku tak żeby było nam łatwiej, bez porozumienia z oryginalnymi twórcami, po czym dumni z siebie udostępniamy ten crap, przepraszam "port" Amispołeczności. Później wychodzi kolejna wersja projektu FOO, i całą robotę trzeba wykonać niemalże od nowa.
Gdyby chcieć do tego podejść na sposób zgodny z ideologią open source, to Ami-programista musiałby dołączyć do zespołu zajmującego się rozwojem danego projektu i na bierząco rozwijać/łatać/poprawiać rzeczy. Tylko to wymagałoby dodatkowego wysiłku, pisania w zespole, konfrontacji stylu czy jakości kodu z innymi, implementacji testów, pisania dokumentacji itd.
Na takie "poświęcenie" wielu już nie stać.
13.01.2016 12:33
[#73]
Re: Kod źródłowy Odyssey na GitHub
@michal_zukowski, post #72
Być może tak było, przyznam, że dawno nie orientowałem się co tam w środku WebKita się dzieje.
Niezależnie od tego, wg. mnie udział Amiprogramistów w projektach open source, na których bazują Amigowe porty, wiele z takich problemów mógłby wyeliminować, bądź przynajmniej ograniczyć. Zwykle programiści należący do takiego zespołu wiedzą więcej na temat przyszłych planów, czy choćby są w stanie przygotować odpowiednią infrastrukturę testową. Dajmy na to, żeby testy jednostkowe wykonywały się też na big endianach.
Ostatnia aktualizacja: 13.01.2016 12:38:34 przez strim_
Niezależnie od tego, wg. mnie udział Amiprogramistów w projektach open source, na których bazują Amigowe porty, wiele z takich problemów mógłby wyeliminować, bądź przynajmniej ograniczyć. Zwykle programiści należący do takiego zespołu wiedzą więcej na temat przyszłych planów, czy choćby są w stanie przygotować odpowiednią infrastrukturę testową. Dajmy na to, żeby testy jednostkowe wykonywały się też na big endianach.
Ostatnia aktualizacja: 13.01.2016 12:38:34 przez strim_
13.01.2016 12:54
[#74]
Re: Kod źródłowy Odyssey na GitHub
@strim_, post #73
@strim
dobrze, ale ta amigowa filozofia sprzeczna z open source wynika z jednej strony prawdopodobnie z jakosci deweloperow ktorzy stoja po naszej stronie do dyspozycji i z regoly pewnie wola poprobowac na boku czy kod wogole da sie skompilowac na dany target, a wspolpracowania w aktywnym teamie fachowcow, juz nie mowiac o zwiazanych z tym ewentualnych permamentnych zobowiazaniach, anis sobie nie wyobrazaja.
jestes chyba jednym z niewielu kturzy pracuja upstream, i to moze byc fenomen net bsd. moze u was jest jakos wygodniej czy spokojhniej. ale zwroc uwage ze nawet ktos taki jak fab najwyrazniej nie pchnal swoich patchy wzwyz. to samo z dystrybucjami linuxa na maszyny dla os4, wlacznie z podobnymi endianowymi problemami z implementacja mesa/gallium, bo tam tez ten sam syndrom wystepuje. podobnie najwyrazniej nawet z kontrybucjami do arosa.
pracucjue obecnie (pod okiem deadwooda) miedzy innymi nad poprawieniem arosowego portu scalosa tak by dzialal na amidze (68k) i widze ze sa problemy ktore utrudniaja synchronizacje glownego repo (bo takie scalos ma) ze zmanami na danej platformie, miedzy innymi ze wzgledu na szczegolne wlasciwosci portu i build systemu.
reasumujac przyznaje ci racje, pewnie ze byloby lepiej gdyby bylo inaczej, ale sytuacje mamy jaka jest i sadze ze trudno oczekiwac by sie dala poprawic, mozna naj wyzej samemu dzialac w tym kierunku i miec nadzieje ze bedzie to wziete za przyklad.
Ostatnia aktualizacja: 13.01.2016 12:56:06 przez wawrzon
dobrze, ale ta amigowa filozofia sprzeczna z open source wynika z jednej strony prawdopodobnie z jakosci deweloperow ktorzy stoja po naszej stronie do dyspozycji i z regoly pewnie wola poprobowac na boku czy kod wogole da sie skompilowac na dany target, a wspolpracowania w aktywnym teamie fachowcow, juz nie mowiac o zwiazanych z tym ewentualnych permamentnych zobowiazaniach, anis sobie nie wyobrazaja.
jestes chyba jednym z niewielu kturzy pracuja upstream, i to moze byc fenomen net bsd. moze u was jest jakos wygodniej czy spokojhniej. ale zwroc uwage ze nawet ktos taki jak fab najwyrazniej nie pchnal swoich patchy wzwyz. to samo z dystrybucjami linuxa na maszyny dla os4, wlacznie z podobnymi endianowymi problemami z implementacja mesa/gallium, bo tam tez ten sam syndrom wystepuje. podobnie najwyrazniej nawet z kontrybucjami do arosa.
pracucjue obecnie (pod okiem deadwooda) miedzy innymi nad poprawieniem arosowego portu scalosa tak by dzialal na amidze (68k) i widze ze sa problemy ktore utrudniaja synchronizacje glownego repo (bo takie scalos ma) ze zmanami na danej platformie, miedzy innymi ze wzgledu na szczegolne wlasciwosci portu i build systemu.
reasumujac przyznaje ci racje, pewnie ze byloby lepiej gdyby bylo inaczej, ale sytuacje mamy jaka jest i sadze ze trudno oczekiwac by sie dala poprawic, mozna naj wyzej samemu dzialac w tym kierunku i miec nadzieje ze bedzie to wziete za przyklad.
Ostatnia aktualizacja: 13.01.2016 12:56:06 przez wawrzon
13.01.2016 21:39
[#80]
Re: Kod źródłowy Odyssey na GitHub
@recedent, post #65
Prawdę mówiąc to jest trochę żałosne, że kawał tak istotnego kodu jak WebKit nie radzi sobie z tak oczywistą sprawą jak obsługa endianów. Nieistotne czy porzucili czy nie porzucili PowerPC. To nie jest jedyna bigendianowa platforma. Skoro WebKit jest pomyślany jako coś multiplatformowego i obsługującego bigendian to taka odpowiedź jest po prostu żałosna. Jak można, robiąc coś tak profesjonalnego, tak nieprofesjonalnie się wypowiadać i traktować swój projekt? Tym bardziej, że problemy z endinanami to raczej dosyć prosta sprawa jeżeli się o tym myślało od początku, sensownie się zaprojektowało podstawy i postępowało konsekwentnie w czasie całego rozwoju. Teraz widać jak bardzo "profesjonalny" jest to kod skoro są w nim takie problemy.
W życiu pozaamigowym mam sporo styczności z takim właśnie "profesjonalnym" światem poważnego świata IT. I niemal codziennie przekonuję się, że ten wielki świat nie różni się niczym od amatorskiego świata IT. Te wielkie projekty prowadzone przez wielkie korporacje, przez firmy, które zna każde dziecko, wcale nie są bardziej profesjonalne niż małe, amatroskie projekty tworzone w domach. A może jest nawet gorzej. Śmietnik, bałagan, koszmarne historyczne zależności, rozwiązania których powinien się wstydzić programistyczny przedszkolak. Bardzo żałuję, że nie wolno mi pokazać kilku przykładów rozwiązań, których nie spodziewałbym się nawet po najbardziej lamerskich programikach pisanych przez dzieciaki w Basicu.
Ostatnia aktualizacja: 13.01.2016 21:48:05 przez MDW
W życiu pozaamigowym mam sporo styczności z takim właśnie "profesjonalnym" światem poważnego świata IT. I niemal codziennie przekonuję się, że ten wielki świat nie różni się niczym od amatorskiego świata IT. Te wielkie projekty prowadzone przez wielkie korporacje, przez firmy, które zna każde dziecko, wcale nie są bardziej profesjonalne niż małe, amatroskie projekty tworzone w domach. A może jest nawet gorzej. Śmietnik, bałagan, koszmarne historyczne zależności, rozwiązania których powinien się wstydzić programistyczny przedszkolak. Bardzo żałuję, że nie wolno mi pokazać kilku przykładów rozwiązań, których nie spodziewałbym się nawet po najbardziej lamerskich programikach pisanych przez dzieciaki w Basicu.
Ostatnia aktualizacja: 13.01.2016 21:48:05 przez MDW
13.01.2016 22:30
[#82]
Re: Kod źródłowy Odyssey na GitHub
@michal_zukowski, post #81
Dzięki. Spróbuje.
Widzisz staram się jak mogę. O dziwo żadne z naszych developerów nie potrafił się wprost dowiedzieć u źrodła, a taki sobie piszący się po prostu zapytał. Trochę to dziwne, że programiści takich akcji nie podejmują tylko czekają na zbawienie przez 3 lata.
@MDW
Cały świat tak wygląda. Ale z drugiej strony co się dziwić, PPC nie istniej, czemu maja siebie zawracać tym głowę?
Widzisz staram się jak mogę. O dziwo żadne z naszych developerów nie potrafił się wprost dowiedzieć u źrodła, a taki sobie piszący się po prostu zapytał. Trochę to dziwne, że programiści takich akcji nie podejmują tylko czekają na zbawienie przez 3 lata.
@MDW
Cały świat tak wygląda. Ale z drugiej strony co się dziwić, PPC nie istniej, czemu maja siebie zawracać tym głowę?
14.01.2016 08:42
[#83]
Re: Kod źródłowy Odyssey na GitHub
@MDW, post #80
Śmietnik, bałagan, koszmarne historyczne zależności, rozwiązania których powinien się wstydzić programistyczny przedszkolak. Bardzo żałuję, że nie wolno mi pokazać kilku przykładów rozwiązań, których nie spodziewałbym się nawet po najbardziej lamerskich programikach pisanych przez dzieciaki w Basicu.
A pamietasz ten kod?
....
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
.... 
14.01.2016 11:39
[#85]
Re: Kod źródłowy Odyssey na GitHub
@flops, post #84
goto? Ktoś chyba w Basicu programował wcześniej.
Akurat goto w C dosc czesto sie pojawia, chociazby w bebechach linuksa. Potrzebe "goto" mozna obejsc ale czasami programisci decyduja sie na takie rozwiazanie "awaryjne". W C++ wystarczy w przypadku klopotow rzucic wyjatkiem a C nie dawal dostepu do takiego mechanizmu.
A ten kod to akurat slynne "goto fail bug" z Apple.
