Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
FujiNET firmware v1.3.0 Nowa wersja oprogramowania do interfejsu sieciowego FujiNET. Tym razem z obsługą TCP!
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Wyniki FujiCup 2023 Wyniki konkursu FujiCup na najlepszą grę dla 8-bit Atari w 2023 roku zostały ogłoszone!
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
http://www.poloniainfo.dk/images/atari/ … gress1.png
Zbliżają się długie jesienne wieczory :) Widzę że wcześnie zacząłeś sezon :D
A nie prościej było sobie zacząć od nowa i napisać coś "command-line" niż przegryzać się przez kod AspeQT? ;)
Coool!
Jak ma być szeroko używane to musi być GUI. To może tak prościej.
Nie wymaga specjalnej karty PCI z RS-232 jak AtariSIO? Wystarczy FTDI 232RL?
I jest szansa na, przepraszam, mniej chimeryczny rozwój AspeQT.
Tylko jaki byłby sens pisania dzisiaj narzędzia command line tego typu. Interfejst typu command line ma sens tam gdzie zdarza się że program się używa w trybie wsadowym, a to raczej nie ten przypadek :) Pod współczesnymi systemami command line robi się trudniej niż GUI :)
Zawsze można odpalić programik w screenie bez xów. gui to zło i niedobro.
@wieczor: Oj bredzisz stary bredzisz. 95% dobrego softu na Linuxie chodzi w trybie command line. Uwierz mi, zamiast klikac 50 razy myszka i tracic czas na szukanie jakiegos tam ustawienia, wszystko zalatwia sie podajac parametr w lini komend lub edytujac konfiguracyjny plik tekstowy.
Ostatnio edytowany przez Monsoft (2013-08-29 11:57:40)
Tylko po pierwsze - po co program tego typu odpalać w tle, przecież trzeba z nim rozmawiać, zmieniać dyskietki, a i widzieć co robi by się przydało. Po drugie - jedno nie wyklucza drugiego - jest trochę programów z gui, działających też w command line z parametrami. Po trzecie - o ile się orientuję to główną platformą Aspecta jest Windows :) A po czwarte - jasne zamiast tracić czas na szukanie łatwo dostępnych ustawień w interfejsie, lepiej go stracić na czytanie manuala - parametrów które musisz podać nie zgadniesz.
Ot wszystko ma swoje zastosowania - ważne jest aby dobrać odpowiednie podejście do danego zadania :)
Z programem rozmawia się telnetem i killem.
Edit:
o ile się orientuję to główną platformą Aspecta jest Windows
Dopiero od niedawna. Dlaczego qt? Nie prościej byłoby używać jakiegoś winapi?
zamiast tracić czas na szukanie łatwo dostępnych ustawień w interfejsie, lepiej go stracić na czytanie manuala
Dzięki temu wiesz dokładnie co program może :P
Ostatnio edytowany przez mono (2013-08-29 12:09:58)
Z programem rozmawia się telnetem i killem.
Edit:
wieczor napisał/a:o ile się orientuję to główną platformą Aspecta jest Windows
Dopiero od niedawna. Dlaczego qt? Nie prościej byłoby używać jakiegoś winapi?
winapi prostsze od QT? Obśmiałem sie jak norka.
Rozne podejsice do sprawy, dlatego ludzie korzystaja w roznych systemow.
QT jest nieco wygodniejsze od winapi - no i łatwiej skompilować pod inną platformę, tym nie mniej, jest to program pomyślany jako okienkowy :) Fani command line'a mają swoje narzędzia :)
Zawsze w opisie pola ustawiającego coś można podać jak mają wyglądać opcje do wstawienia w command line, bez RTFM.
Wiem, jesteśmy wygodni, ale co z tego. Renesans był z te 500 lat temu.
winapi prostsze od QT? Obśmiałem sie jak norka.
Chodziło mi o to, że skoro to dedykowane windowsowi, to może użycie jakiegoś api windowsowego pozwoli wykorzystać w pełni (i prościej) mechanizmy osa, bo mam wrażenie (może mylne, nie pisałem nigdy nic pod windowsa), że pisanie multiplatformowe stawia więcej ograniczeń.
Pewnie i tak, chociaż z reguły dotyczy to bardziej zaawansowanych funkcji - te API różnych okienek są zaskakująco komplementarne, dlatego chociażby WINE jest możliwy.
Sprawa komplementarności nie ma nic do rzeczy WinAPI jest API na o wiele niższym poziomie niż QT. Pisanie praktycznie dowolnej aplikacji w wykorzysatniem WinAPI będzie trudniejsze i bardziej pracochłonne niż przy wykorzystaniu QT.
Zgadza się - chodziło mi tylko o to, że trzymanie się WinAPI nie oferuje nic specjalnego, czego nie można osiągnąć bez.
Wszyscy macie rację.
Dlaczego zabrałem się za to w ten sposób ? A bo tak. I już.
Gdyby nie to nigdy bym się ani za Qt ani C++ nie zabrał, a teraz to już za późno żeby się wycofać. Przeryłem cały kod AspeQT, nauczyłem się c++ (na tyle ile można tego dokonać w tydzień wieczorami), Nauczyłem się korzystać z Qt (patrz uwaga poprzednia) ... i więcej raczej nic nie napiszę korzystając z tego duetu :D
Ogólnie jak popatrzyłem w zdeasemblowany kod prostej funkcji ... bardziej niż kompilator c++ to już chyba tego zagmatwać się nie da.
Cała komunikacja oparta jest o winapi i ft232(b). Na razie działa w standardowej prędkości, ale celem napisania tego było umożliwienie zgrywania dyskietek w prędkości warp 10 :D - co jeszcze nie zostało osiągnięte.
Hej!
Ogólnie jak popatrzyłem w zdeasemblowany kod prostej funkcji ... bardziej niż kompilator c++ to już chyba tego zagmatwać się nie da.
A ja myślałem że jestem osamotniony w mojej interpretacji "rzeczywistości kompilator-owej" ;) Miło iż ktoś ma podobne zdanie na temat tego całego śmietnika :D
Tak naprawdę to nie wiem dokąd to zmierza, ale nic dobrego z tego nie będzie i tłumaczenie że inaczej się nie da, bo to wymyślone po to aby dało się pracować w dużych zespołach, i że potem takie podejście owocuje tym iż duże programy piszą piszą setki ludzi i to jakoś działa, etc. jakoś do mnie nie przemawia :D
Właśnie to "jakoś" mnie przeraża ;/ z wydajnym kodem to już od dawna nie ma nic wspólnego :) Wystarczy popatrzeć w "task manager" na dowolny program który nie robi jakichś skomplikowanych rzeczy i zajmuje zasobów w stosunku do tego co robi :P
Heh, dlatego kernel Linuxa caly czas jest pisany w C a nie C++.
Ja pamietam ze na studiach mielismy Turbo Pascala i pozniej Ansi C. Oba jezyki bardzo lubialem. W nastepnym roku akademickim dostalismy C++ i Assemblera na PC. C++ mnie zabilo i gdyby nie to ze oba jezyki wykladal ten sam koles to bym chyba ledwo przeszedl semestr. Jako ze czlowiek obyty byl z assemblerem na mala atarke to i kumalem niezle assemblera na pc i to mnie uratowalo.
Ostatnio edytowany przez Monsoft (2013-08-29 21:19:42)
Cała komunikacja oparta jest o winapi i ft232(b). Na razie działa w standardowej prędkości, ale celem napisania tego było umożliwienie zgrywania dyskietek w prędkości warp 10 :D - co jeszcze nie zostało osiągnięte.
Mam nadzieję, że jak pójdzie warp, to zrobisz też tryb Turbo 1050 (i ew. (super)Synchromesh), bo nie wszyscy mają stacje z UltraSpeed.
monsoft, nie wiem czym sie zajmujesz, ale ja niestety musze czasami tego kernela poprawiac/dodawac cos od siebie dla platform embeded - wiekszego syfu, niz ten ktory jest w tamtym kodzie to ja naprawde nie widzialem :/
wyglada to wszystko tak, jakby pisali to ludzie z przypadku, bo np umie sprawnie pisac na klawiaturze i to bylo glownym kryterium przy "zatrudnianiu"
nie podoba mnie sie open source - prowadzi wlasnie do takiego przerostu formy nad trescia - mowcie co chcecie, ale jakos nie widze projektow assemblerowych typu "open source"
Ja, obecnie sie obijam.
Ostatnio edytowany przez Monsoft (2013-08-30 17:41:49)
Jest Open Source i Open Source ...
Porównaj Linuxa i FreeBsd, oba są Open Source ... ale jednak jak wielce się różnią (chodzi mi o zarządzanie projektem nie o funkcjonalność)
A co do AspeQT-1050-2-pc żeby nie było OT - koniec projektu.
Za dużo pracy w dostosowaniu do potrzeb, startuje od zera jako osobny projekt.
Stałego cytatu nie było, ale zawsze jest tak, że własny kod od zera będzie lepszy niż poprawiany w dużej ilości cudzy.
monsoft, nie wiem czym sie zajmujesz, ale ja niestety musze czasami tego kernela poprawiac/dodawac cos od siebie dla platform embeded - wiekszego syfu, niz ten ktory jest w tamtym kodzie to ja naprawde nie widzialem :/
Jeśli to co w tym wątku http://lkml.indiana.edu/hypermail/linux … 00905.html przypadkiem poczytałem jest prawdą, to się nie dziwię.
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.089 sekund, wykonano 10 zapytań ]
