Ale jednak linuxowcy to psychole. Facet zadeklarował, że do następnego dema chce użyć SVN i już święte oburzenie, no bo przecież jest tylko jeden jedyny słuszny GIT stworzony przez naszego Pana i Władcę. Ile w tym demie będzie branchów, żeby ułatwiać sobie merdżowanie? No bez jaj. Torvalds widać zabronił ludziom posiadania własnego zdania.
There you see, why most C64 demos run "fast". They simply do not calculate all stuff, just re use it, while Atari Demos mostly do all the stuff step by step.
emkay: I woudn't call it a rule. Just none has came up with such effect yet on atari. We do have some similar effects though, like infinite bobs to name one.
at0mic: Wyobraź sobie, że uczestniczysz w projekcie, nad którym pracuje kilka osób i każda z nich równolegle do pozostałych implementuje jakiś inny feature. Ty zmieniłeś procedurę A w liniach powiedzmy 100-200, a kolega naniósł poprawki na procedurę B w liniach 500-600. Jak synchronizować zmiany? Wysyłacie do siebie maile ze źródłami? Można! A jeśli jest ich dużo (kilka, kilkanaście, kilkadziesiąt tysięcy wierszy kodu) co wtedy? A jeśli programistów jest 10, 20, 30? Każdy coś robi. Pracujecie 8 godzin dziennie. Zmiany pojawiają się non stop. Jak to opanować? Tu wkraczają systemy kontroli wersji. Już w latach 50-tych mieli systemy polegające na lokowaniu wybranych plików (programista oznaczał plik jako zajęty i nikt inny nie mógł go zmodyfikować, dopóki nie został zwolniony. Taki semafor). Jeszcze kilka komercyjnych systemów działa w ten sposób po dziś dzień (nie wiem dlaczego ludzie tego używają). Nowocześniejsze system pozwalają na równoległą pracę z opcją zatwierdzania zmian do głównego repozytorium w dowolnym momencie (tak działa SVN). Wówczas pliki są porównywane i jeśli zmiana nie jest konfliktowa, jest ona zapisywana do serwera, tak aby inni mogli pobrać te zmiany i mieć je u siebie (konflikty są wtedy, gdy ktoś zmodyfikował ten sam fragment kodu. Nie można rozwiązać tego problemu automatycznie i człowiek musi podjąć decyzję jaka powinna być ostateczna wersja w repozytorium). Teraz trendy są systemy rozproszony bez jednego głównego repozytorium (tak działa git). Każdy ma całe repozytorium u siebie i każdy jest w stanie rozwijać swoją wersję projektu (bo nie ma wersji głównej). Powstałe wersje można ze sobą łączyć na życzenie. Jest to koncepcyjnie bardziej skomplikowane, ale dobrze sprawdza się w dużych projektach open-sourcowych (jak jądro linuxa, gdzie aplikowane są tylko wybrane zmiany). Dlatego śmieszy mnie, gdy ktoś do prostego projektu z małą liczbą developerów upiera się przy tak skomplikowanym systemie jak git. SVN jest o wiele prostszy, bardziej intuicyjny i w zupełności wystarczający.
@laoo uwież proszę że nawet taka produkcja jak demo na 8 bitowy sprzęt potrafi składać się z dużej ilości plików źródłowych. oczywiście nikt nie będzie robił brancha, ale warto mieć coś co ci pokazuje zmiany zrobione przez innych. pilnuje kolizji w kodzie, wersjonuje, itp... z kolegami z którymi teraz składam demko mamy środowisko składające się z narzędzi on-line m.in: GIT, Forum dyskusyjne z definiowaniem zadań dla ekipy i dropboxa do wymiany plików... jak ktoś w robocie przyzwyczai się że każdy nawet najkniejszy projekt programistyczny zaczyna się od takich rzeczy (nawet lokalnie a nie na serwerze) nie potrafi inaczej postępować. btw: polecam książkę "Pragmatyczny programista" - warto przeczytać nawet jak programuje siętylko w ASMie 6502.
z czego konkretnie korzystacie, crrn? przyznam że obecne projekty "hobby / 8 bit" prowadzimy wspierając się grupą dyskusyjną i mailami - moim zdaniem jest niewygodnie. Jeżeli jest coś darmowego, onlineowego to chętnie poczytam o doświadczeniach. Oczywiście kwestia svn, git, cvs czy czegoś tam jeszcze jest pomijalna i oczywista - ja preferuję svn i mnie on wspiera (z pluginami w rodzaju subclipse, czy tam subversive) we wszystkim co wymieniono i potrzebuję (merge, konflikty, branche itp). Chodzi mi bardziej o forum z "tasklistą" - wyważone i nie przesadzone (jednak dla takich projektów nie wiadomo jakie kombajny to przerost formy nad treścią, a proste narzędzia mogą pomóc)
@0xF Oburza mnie zealotyzm czcicieli Torvaldsa. Na wzmiankę o SVNie było głośne "what???!!" zupełnie jakby facet dopuścił się jakiegoś świętokradztwa, a on tylko wolał użyć prostszego, bardziej intuicyjnego systemu do prostych zastosowań. Jakby co, nie jestem fanboyem SVN, bo np nie mam oporów do zaznajamiania się z Mercurialem, a uważam tylko, że ten stabilny i dojrzały projekt jest świetny do prostych zastosowań.
@crrn Jestem adwokatem systemów kontroli wersji i wydajnej pragmatycznej metodologii tworzenia oprogramowania. Więc bez obaw, a Hunta Thomasa mam na półce :)
@xeen Swojego czasu do 8-bitowych zastosowań używałem ->link<- Nie jest to dokładnie to czego szukasz, a bardzo lekki bugtracker.
Trac: ->link<- - proste i pożyteczne. Wgląd do kodu źródłowego dzięki czemu można w ticketach linkować do konkretnego źródła, czy do wiki. Milestony, komponenty, historia zmian, powiadomienia mailem.
Edit: "Wgląd do kodu źródłowego" - miałem na myśli to, że trac może pokazywać zawartość projektu w repozytorium dowolnego VCS.
Trac jest fajny, używa(łe)m go w kilku projektach, w tym atarowskich.
laoo: Facet sam używa Gita, a SVNa wybrał dlatego, że jego kolega Oswald dopiero uczy się systemów kontroli wersji (oraz Makefile - w tym momencie sam bym krzyknął "what?!" ;).
Trzy, cztery lata temu wstecz byl pomysl, zeby taki tracker dolaczyc gdzies na podstronie AOL jako zalecany do prowadzenia projektow gier, dem, etc (bylyby artki zachecajace, etc). Zeby wlasnie od niego zaczynali nasi koderzy, zeby stal sie standardem, a znajomosc metodologii ulatwilaby powstawanie prac. Wowczas jednak nie bylo odpowiednio prostego, a dobrego i darmowego systemu.
Czy uwazacie ze a) ma to sens?, b) ktorys z tych wymienionych nadawal sie na taki standard?
Ja byłbym za Trac'iem: "It provides an interface to Subversion (or other version control systems), an integrated Wiki and convenient reporting facilities."
Co do nauki systemu kontroli wersji - to sie zawsze oplaci, bo im jest obojetne jaki kod wersjonuja (asm,c,php), gałazki sa wszedzie, etykietki rowniez. A git jest fajny dzięki github (no i OpenEmbedded).
Ale chyba dyskusja się toczy na temat który w prezentacji zajął 30-60 sekund.
A z glownego tematu - jak zrobic taka prezentacja o Atari? Tak, aby zostawić coś po sobie?
Mamy dema na ftp.pigwa.net, ale mniej i mniej osob potrafi je kompilowac, nie mowic o zrozumieniu, co tam sie dzieje. Ci, ktorzy je pisali, spedzili sporo czasu, aby osiagnac to co osiagneli. Wiele osob patrzy z niedowierzaniem na to, co osiagnieto to na 8 bitowym komputerze z konca lat 70 XX wieku. Obawiam sie, ze za pewien czas zostaną nam tylko owe filmiki.
Kaz: a) obawiam się pułapki "metodyki i standardowych narzędzi" - to nie jest najważniejsze przy programowaniu b) stawiam na Trac+SVN. Git daje więcej możliwości, niż SVN, ale przez to jest trudniejszy do opanowania.
blacktofu: Z takiej prezentacji to nauczysz się kodowania tyle co nic. :) Nie wiem nawet, czy zachęci ona kogokolwiek do kodowania na 8-bit.
Kilka godzin prezentacji wideo nie zastąpi lektury kilku książek i magazynów dyskowych. Wiele z nich jest już łatwo dostępnych w sieci.
0xF - jest mi znany efekt pulapki metodyki czy standardow, ale tutaj chodzi raczej o drogowskaz dla pewnych osob (niekoniecznie poczatkujacych koderow, raczej osob nie obeznanych z praca grupowa przy programach). To wyszlo przy pracach nad "Kolony 2106", w ktora bylo zaangazowanych kilkanascie osob (bo tlumacze, testerzy tez). Wiekszosc z tych osob nigdy nie uczestniczyla w projektach programistycznych. Zobacz jakie czesto bywa zamieszanie z kolejnymi wersjami gier tylko przez to, ze nie posiadaja one oficjalnej numeracji. Niby banalna sprawa, a standardowe numerowanie usprawniloby znacznie odbior, dodawanie do baz danych, analize, etc. A to jedna, prosta rzecz z zakresu metodologii, sa inne, znacznie wazniejsze.
Dlatego, jezeli koderzy wskaza efektywne, ale w miare proste narzedzia do zarzadzania projektem, poparte praktyka i doswiadczeniem polecajacego to zaloze sie, ze w pewnej perspektywie czasu podniesie to wydajnosc naszej spolecznosci. Bedzie moglo powstac wiecej gier czy dem, ktore wymagaja zaangazowania i ktore sa bardziej skomplikowane. Co wiecej, jezeli przyzwyczaimy sie do standardow pracy to latwo bedzie przechodzic z jednej tworczej grupy do drugiej i brac udzial w pracach z biegu. Obecnie zauwazylem, a pracowalem przy grach Atari w wielu roznych konfiguracjach osobowych, ze za kazdym razem trzeba wypracowywac "jezyk komunikacji", a sposoby postepowania sa inne. To uciazliwe.
