08.09.2015 23:41
[#1]
System kontroli wersji
Pytanie trochę o przeszłość, a trochę o teraźniejszość.
Jak obecnie tworzone jest oprogramowanie na Amigę ? W sensie jaki jest trend wśród programistów ? Czy aplikacje pisane są na klasycznych Amigach czy raczej na teraźniejszym sprzęcie (Linux, Mac, Windows) i kompilowane przy pomocy cross-kompilatorów ?
Jeżeli to pierwsze rozwiązanie to jakie systemy kontroli wersji są dostępne dla klasycznych Amig ? CVS, SVN, GIT ?
A w latach 90-tych jakiego systemu używali programiści ? Zakładam, że jakiegoś musieli używać, bo jakoś zespoły programistów musiały koordynować swoją pracę.
Jak obecnie tworzone jest oprogramowanie na Amigę ? W sensie jaki jest trend wśród programistów ? Czy aplikacje pisane są na klasycznych Amigach czy raczej na teraźniejszym sprzęcie (Linux, Mac, Windows) i kompilowane przy pomocy cross-kompilatorów ?
Jeżeli to pierwsze rozwiązanie to jakie systemy kontroli wersji są dostępne dla klasycznych Amig ? CVS, SVN, GIT ?
A w latach 90-tych jakiego systemu używali programiści ? Zakładam, że jakiegoś musieli używać, bo jakoś zespoły programistów musiały koordynować swoją pracę.
09.09.2015 00:15
[#2]
Re: System kontroli wersji
@g0trek, post #1
Jak obecnie tworzone jest oprogramowanie na Amigę ? W sensie jaki jest trend wśród programistów ?
Nie mogę się wypowiadać za innych, ale ja obecnie robię tak, że piszę i kompiluje na PC (Mac lub Linux) z użyciem vbcc. Użycie vbcc ma tą dodatkową zaletę, że w razie czego mam to samo środowisko natywnie działające na Amidze. Z vbcc jest to dość proste do osiągnięcia, bo ten sam kompilator działa zarówno na klasyku, Linuxie, Macu, MorphOSie, AmigaOS4, etc. (podobno też na Windows).
Zaraz ktoś może powiedzieć, że GCC jest lepsze (na pewno pod pewnym względami jest), ale z vbcc największą zaletą jest proste i ustandaryzowane środowisko na każdym hoście z którego kompiluje. Jeśli ktoś wykorzysta nowe GCC jako cross-kompilator, to niestety, w zasadzie uniemożliwia sobie natywną kompilację na Amidze (choćby z uwagi na brak nowych natywnych wersji na klasyka).
Testuje zawsze na prawdziwej Amidze, którą mam na tym samym biurku. Wynik kompilacji wrzucam na zasób NFS, który ma podmontowana Amiga (binaria wrzucają się skryptem automatycznie uruchamianym w wyniku kompilacji), ewentualnie używam rlaunch. Chyba, że jestem poza domem, wtedy testuje na UAE na laptopie.
Jeżeli to pierwsze rozwiązanie to jakie systemy kontroli wersji są dostępne dla klasycznych Amig ? CVS, SVN, GIT ?
Jedynym sensownie działającym na klasyku jest CVS. Dlatego te projekty, które muszę z jakiś powodów wersjonować na klasyku, trzymam w CVS. Dla własnej wygody mam zrobiony zautomatyzowany gateway CVS-do-git (np. dla SonnetAmiga). Pozostałe, których nie kompiluje na Ami, trzymam bezpośrednio w git.
A w latach 90-tych jakiego systemu używali programiści ? Zakładam, że jakiegoś musieli używać, bo jakoś zespoły programistów musiały koordynować swoją pracę.
Nie wiem nic o dawnych Amigowych projektach, ale np. NetBSD prawie od samego początku używa CVS (~1994).
Ostatnia aktualizacja: 09.09.2015 00:26:46 przez strim_
09.09.2015 00:28
[#3]
Re: System kontroli wersji
@g0trek, post #1
Ktoś już się ze mnie śmiał, że bez sensu mam to zorganizowane ale co tam... nie poświęcałem większej ilości czasu na konstruowanie środowiska, bo mam ważniejsze rzeczy do roboty, np. faktyczne pisanie kodu ;)
UAE z postawionym osem i vbcc, katalog ze źródłami jako folderodysk. Na żywym sprzęcie testuję ważniejsze rzeczy.
Jako że obecnie piszę solo to nie wersjonuję kodu. Jak pisałem w dwójkę to folderodysk był symbolicznym linkiem do podfolderu dropboksa i tym się synchronizowało. Wszystko szlag trafił gdy winuae przestał poprawnie rozpoznawać windowsowe linki symboliczne. Chociaż jak teraz o tym myślę, to po prostu UAE mogło bezpośrednio wskazywać na ten podfolder, hyhy.
Ostatnia aktualizacja: 09.09.2015 00:30:39 przez teh_KaiN
UAE z postawionym osem i vbcc, katalog ze źródłami jako folderodysk. Na żywym sprzęcie testuję ważniejsze rzeczy.
Jako że obecnie piszę solo to nie wersjonuję kodu. Jak pisałem w dwójkę to folderodysk był symbolicznym linkiem do podfolderu dropboksa i tym się synchronizowało. Wszystko szlag trafił gdy winuae przestał poprawnie rozpoznawać windowsowe linki symboliczne. Chociaż jak teraz o tym myślę, to po prostu UAE mogło bezpośrednio wskazywać na ten podfolder, hyhy.
Ostatnia aktualizacja: 09.09.2015 00:30:39 przez teh_KaiN
09.09.2015 00:31
[#4]
Re: System kontroli wersji
@teh_KaiN, post #3
nie poświęcałem większej ilości czasu na konstruowanie środowiska
Raz poświęcisz trochę więcej czasu i masz problem z głowy, np takie kwiatki...
Jak pisałem w dwójkę to folderodysk miał link symboliczny w folderze dropboksa i tym się synchronizowało. Wszystko szlag trafił gdy winuae przestał poprawnie rozpoznawać windowsowe linki symboliczne.
09.09.2015 05:37
[#5]
Re: System kontroli wersji
@g0trek, post #1
O systemach kontroli wersji grxmrx przeprowadził sondę na okoliczność artykułu o Mercurialu.
09.09.2015 16:37
[#6]
Re: System kontroli wersji
@g0trek, post #1
Jak obecnie tworzone jest oprogramowanie na Amigę ? W sensie jaki jest trend wśród programistów ? Czy aplikacje pisane są na klasycznych Amigach czy raczej na teraźniejszym sprzęcie (Linux, Mac, Windows) i kompilowane przy pomocy cross-kompilatorów ?
Kompilator skrośny + WinUAE + git, do ostatecznego testowania prawdziwa Amiga.
Osobiście korzystam z gcc, które można podpiąć pod NetBeans lub inne środowisko dewerloperskie (Vim/Emacs). Wygoda pisania w C lub C++ na nowoczesnym sprzęcie jest nieporównanie większa. Błędnie napisany program to nie reset maszyny - edytor nadal włączony, muzyka nadal gra, przeglądarka WWW dalej działa. Poza tym jeśli mój program się wywali to pod emulatorem mam możliwość poszperania przy pomocy wbudowanego debuggera WinUAE (shift+F12).
Kiedyś pokusiłem się o zrobienie prezentacji na temat: Jak (bezboleśnie) wrócić do kodowania na Amigę?. Uważam, że nadal jest aktualna i warta przejrzenia.
Jak napisał _strim, vbcc ma swoje zalety, ale jeśli zależy Ci na wydajności generowanego kodu lub chcesz pisać w C++ to zostaje gcc, które można sobie zbudować przy pomocy moich skryptów.
Ostatnia aktualizacja: 09.09.2015 16:38:10 przez cahir
09.09.2015 19:55
[#7]
Re: System kontroli wersji
@g0trek, post #1
Jak obecnie tworzone jest oprogramowanie na Amigę ? W sensie jaki jest trend wśród programistów ? Czy aplikacje pisane są na klasycznych Amigach czy raczej na teraźniejszym sprzęcie (Linux, Mac, Windows) i kompilowane przy pomocy cross-kompilatorów ?
Przeważnie używam kombinacji:
1) Jak robie coś w asm:
a) WinUAE + AsmOne/Barfly + notepad++.
b) WinUAE + notepad++ cygwin + skrośnie vasm + git
2) Jak C to:
a) WinUAE + kompilator skrośny vbcc + visual studio 2008 express.
b) WinUAE + vs2008 express + sas (jak mnie najdzie na sprawdzanie czy będzie lepsiejszy kod)
Kusi mnie coby wytestować jeszcze kombinację z gcc najlepiej skrośne na Windowsie ale to może w późniejszym czasie
A na realnym sprzęcie korzystam z AsmOne, Barfly i RCS do wersjonowania.
A w latach 90 to używałem Asm-One na dyskietce a wersjonowanie było w stylu plik1.s, plik2.s i plik3.s i to była katorga a to co tam klepałem to nie można nazwać programowaniem a raczej takim tam wystukiwaniem przypadkowych klawiszy i sprawdzanie czy wyszło dzieło na miarę Szekspira.
Zapomniałem dodać jeszcze o Amos i Blitz2. Do nich używam kombinacji WinUAE + notepad++ + amos/blitz2.
Ostatnia aktualizacja: 09.09.2015 19:57:16 przez asman
09.09.2015 21:27
[#8]
Re: System kontroli wersji
@strim_, post #2
Zaraz ktoś może powiedzieć, że GCC jest lepsze (na pewno pod pewnym względami jest)[...]
Postanowiłem, że nie będę gołosłowny w kwestii przewagi wydajności gcc nad vbcc. Zamieszczam link do testu kompilacji na nietrywialnej funkcji (procedura dekompresji LZO). Dezasemblację przeprowadziłem przy pomocy IRA. Kompilator vbcc wygenerował procedurę dłuższą o około 30% instrukcji w stosunku do gcc.
10.09.2015 09:13
[#11]
Re: System kontroli wersji
@cahir, post #6
To i ja dodam coś od siebie, ponieważ ostatnio przerobiłem tutoriale Photona/Scoopex i zacząłem bawić się w "kodowanie".
Ponieważ zaczynałem od AsmOne więc chciałem mieć coś podobnego w składni do cross kompilacji.
pracuję na OS X i tak:
1. edytor - SublimeText z podświetlaniem składni asm M68k
2. assembler - vasm - uruchamiany kombinacją klawiszy CMD+B w edytorze więc kompiluję bez makefile'a a wszystko "linkuję" (na razie) includami i incbin w kodzie
3. fs-uae w konfiguracji A500 512Chip+512 Slow. w podmontowanym katalogiem ze źródłami i skompilowanym plikiem - jako dysk.
4. dodaję sobie w katalogu roboczym ze źródłami katalog c: gdzie mam AsmOne + iffconverter + titanic, a wszystko na potrzeby testowania, debugowania itp. zwłaszcza asm one fajnie się sprawdza do debugowania, bo kod rozkładam sobie w różnych plikacj źródłowych i jak chcę coś skompilować i zdebugować to do AsmOne wczytuję tylko jeden plik z procedurami, które mnie interesują.
5. dodał bym jeszcze że używam też Processing (takie środowisko do prototypowania w javie) gdzie generuje sobie sinusy i itp. fajna sprawa polecam bo szybko można przetestować pomysły na efekty graficzne. Moi koledzy z C64 (niektórzy) używali tego do pisania efektów które potem po prostu implementowali w asmie.
co do kontroli wersji to nie używam w tej chwili. tzn jestem sam i kodu mam naprawdę mało więc nie potrzebuję pracować z różnymi wersjami kodu. co do archiwizacji i współdzielenia to po prostu trzymam kod w katalogu dropboxa, więc jak się przesiadam z laptopa na stacjonarny komputer w domu to mam wszystko w tym samym miejscu zsynchronizowane.
fajna zabawa muszę przyznać. no i polecam wspomniane wyżej tutoriale na YT.
Ostatnia aktualizacja: 10.09.2015 09:14:27 przez retronav
Ostatnia aktualizacja: 10.09.2015 09:16:09 przez retronav
Ponieważ zaczynałem od AsmOne więc chciałem mieć coś podobnego w składni do cross kompilacji.
pracuję na OS X i tak:
1. edytor - SublimeText z podświetlaniem składni asm M68k
2. assembler - vasm - uruchamiany kombinacją klawiszy CMD+B w edytorze więc kompiluję bez makefile'a a wszystko "linkuję" (na razie) includami i incbin w kodzie
3. fs-uae w konfiguracji A500 512Chip+512 Slow. w podmontowanym katalogiem ze źródłami i skompilowanym plikiem - jako dysk.
4. dodaję sobie w katalogu roboczym ze źródłami katalog c: gdzie mam AsmOne + iffconverter + titanic, a wszystko na potrzeby testowania, debugowania itp. zwłaszcza asm one fajnie się sprawdza do debugowania, bo kod rozkładam sobie w różnych plikacj źródłowych i jak chcę coś skompilować i zdebugować to do AsmOne wczytuję tylko jeden plik z procedurami, które mnie interesują.
5. dodał bym jeszcze że używam też Processing (takie środowisko do prototypowania w javie) gdzie generuje sobie sinusy i itp. fajna sprawa polecam bo szybko można przetestować pomysły na efekty graficzne. Moi koledzy z C64 (niektórzy) używali tego do pisania efektów które potem po prostu implementowali w asmie.
co do kontroli wersji to nie używam w tej chwili. tzn jestem sam i kodu mam naprawdę mało więc nie potrzebuję pracować z różnymi wersjami kodu. co do archiwizacji i współdzielenia to po prostu trzymam kod w katalogu dropboxa, więc jak się przesiadam z laptopa na stacjonarny komputer w domu to mam wszystko w tym samym miejscu zsynchronizowane.
fajna zabawa muszę przyznać. no i polecam wspomniane wyżej tutoriale na YT.
Ostatnia aktualizacja: 10.09.2015 09:14:27 przez retronav
Ostatnia aktualizacja: 10.09.2015 09:16:09 przez retronav
10.09.2015 11:14
[#12]
Re: System kontroli wersji
@g0trek, post #1
Dzięki za tak duży odzew. Z tego wynika, że nikt nie tworzy softu na oryginalnych komputerach :). W sumie jest to zrozumiałe, bo wygoda współczesnych rozwiązań jest ważniejsza przy produkcji oprogramowania niż trzymanie się klimatu i prymitywnych rozwiązań z tamtych lat. Najbardziej mi się spodobała koncepcja współdzielenia zasobu NFS, tworzenia kodu we współczesnych środowisku (co pozwoli na wersjonowanie przy pomocy GIT-a) i uruchamiania na oryginalnej maszynie. Muszę tylko rozpoznać temat współdzielenia zasobu pomiędzy Mac OS X i Amigą :).
14.09.2015 20:28
[#13]
Re: System kontroli wersji
@g0trek, post #12
To ja jeszcze dodam kolejne oryginalne rozwiązanie: programy 68k crosskompiluję na MorphOS-ie. Zaletą jest to, że programy "systemowe" mogę od razu uruchomić i wstępnie przetestować. Następnie testuję jeszcze pod WinUAE.
Do kompilacji używam crossa GCC 2.95.3 skompilowanego na PowerPC (jest bardzo szybki) oraz oryginalnych binutils 2.9.1 z Amigi (te nowsze z Aminetu są nic nie warte).
Do kompilacji używam crossa GCC 2.95.3 skompilowanego na PowerPC (jest bardzo szybki) oraz oryginalnych binutils 2.9.1 z Amigi (te nowsze z Aminetu są nic nie warte).
14.09.2015 21:18
[#14]
Re: System kontroli wersji
@g0trek, post #12
Ja koduję/programuję na oryginalnych komputerach. Mój sprzęt to Amiga 1200 desktop + HDD + CD-ROM w konsoli TOMS. Do tego karta turbo z pamięcią FAST.
C: Mój ulubiony to DICE C.
Asembler: Asm-One i Phx-Ass.
Obecnie piszę w CygnusEDzie choć rozglądam się ostatnio za innym edytorem (ten ma kilka usterek, a autor nie odpisuje).
Emulatorów nie używam.
@Grzegorz Kraszewski
Czy mógłbyś podać która wersja GCC jest najlepsza dla M68k i skąd ją pobrać? Dziękuję za odpowiedź.
C: Mój ulubiony to DICE C.
Asembler: Asm-One i Phx-Ass.
Obecnie piszę w CygnusEDzie choć rozglądam się ostatnio za innym edytorem (ten ma kilka usterek, a autor nie odpisuje).
Emulatorów nie używam.
@Grzegorz Kraszewski
Czy mógłbyś podać która wersja GCC jest najlepsza dla M68k i skąd ją pobrać? Dziękuję za odpowiedź.
14.09.2015 21:59
[#15]
Re: System kontroli wersji
@Hexmage960, post #14
Czy mógłbyś podać która wersja GCC jest najlepsza dla M68k i skąd ją pobrać? Dziękuję za odpowiedź.
Nie wiem która jest najlepsza. Używam sprawdzonej 2.95.3, chociaż na tym forum czytałem o eksperymentach z GCC 4.x. Niemniej GCC 4.x to raczej pod WinUAE. Wersja 2.95.3 zapewnia przyzwoitą pracę na Amidze z 68030 i 16 MB RAM, oczywiście dysk twardy. Na takim zestawie kilka lat pracowałem. Wersję 2.95.3 można ściągnąć z mirrora GeekGadgets na serwerze ExoticA, trzeba szukać w katalogu "alpha":
ftp://ftp.exotica.org.uk/mirrors/geekgadgets/amiga/m68k/alpha/gcc/gcc-2.95.3-4-bin.tgz
Do tego z katalogu snapshots archiwum binutils
ftp://ftp.exotica.org.uk/mirrors/geekgadgets/amiga/m68k/snapshots/990529/bin/binutils-2.9.1-bin.tgz
Nie polecam GCC 3.x z "alpha". Natomiast 2.95.3, mimo, że "alpha" służy mi od wielu lat i jest niezawodny. Jak z tym zestawem sobie poradzić na Amidze, opisałem szczegółowo w papierowym eXecu swego czasu.
Pod MorphOS-em zmieniam tylko sam kompilator na wersję skompilowaną dla PowerPC. Wersja M68k też działa, ale PPC jest szybsza. Reszta środowiska pozostaje bez zmian.
Instalując na Amidze trzeba też zwrócić uwagę na wersję biblioteki ixemul.library. Najlepiej zainstalować oryginalną v48. Wszelakie wersje wydane przez Bernda Roescha to całkowite porażki.
Ostatnia aktualizacja: 14.09.2015 22:06:55 przez Krashan
Nie wiem która jest najlepsza. Używam sprawdzonej 2.95.3, chociaż na tym forum czytałem o eksperymentach z GCC 4.x. Niemniej GCC 4.x to raczej pod WinUAE. Wersja 2.95.3 zapewnia przyzwoitą pracę na Amidze z 68030 i 16 MB RAM, oczywiście dysk twardy. Na takim zestawie kilka lat pracowałem. Wersję 2.95.3 można ściągnąć z mirrora GeekGadgets na serwerze ExoticA, trzeba szukać w katalogu "alpha":
ftp://ftp.exotica.org.uk/mirrors/geekgadgets/amiga/m68k/alpha/gcc/gcc-2.95.3-4-bin.tgz
Do tego z katalogu snapshots archiwum binutils
ftp://ftp.exotica.org.uk/mirrors/geekgadgets/amiga/m68k/snapshots/990529/bin/binutils-2.9.1-bin.tgz
Nie polecam GCC 3.x z "alpha". Natomiast 2.95.3, mimo, że "alpha" służy mi od wielu lat i jest niezawodny. Jak z tym zestawem sobie poradzić na Amidze, opisałem szczegółowo w papierowym eXecu swego czasu.
Pod MorphOS-em zmieniam tylko sam kompilator na wersję skompilowaną dla PowerPC. Wersja M68k też działa, ale PPC jest szybsza. Reszta środowiska pozostaje bez zmian.
Instalując na Amidze trzeba też zwrócić uwagę na wersję biblioteki ixemul.library. Najlepiej zainstalować oryginalną v48. Wszelakie wersje wydane przez Bernda Roescha to całkowite porażki.
Ostatnia aktualizacja: 14.09.2015 22:06:55 przez Krashan