🚀 go-pugleaf

Dnia 16.07.2009 d < 0 <2009czerwiec@inmail.sk> napisa�/a:
>     jakie  s�  inne rozwi�zania??w zasadzie? jakie s� w og�le rozwi�za-
> nia, poniewa�  ja nie znajduj� niczego poza pustym s�owem ?przeno�no��?,
> kt�rego skuteczno�� opiera si� jedynie na tym, �e nikt nie stosuje real-
> nie  niezgodnej maszyny, lecz odpowiednio niezgodnej, czyli konwertowal-
> nej.?dlaczego  mam mie� najnowsz� kart� graficzn�, by m�c zagra� w naj-
> nowsze ?wypasione? szachy, je�li na starym komputerze wystarczy mi nary-
> sowanie planszy w trybie tekstowym lub cho�by podawanie ruch�w tekstowo,
> poniewa� zyskiem gry w szachy na komputerze w tym wypadku jest gra z in-
> n�  osob�  na  kra�cu  �wiata  bez konieczno�ci oczekiwania na odpowied�
> o ruchu przez ?e?mail???ale je�li mam nowiute�ki sprz�t prosto z fabry-
> ki, to  chc�  go  u�y�  do zobaczenia pi�knej wizualizacji zwi�zanej te�
> z opcjami konfiguracyjnymi drugiego gracza o jego bierkach.
>     i jak ugry��?;-) przeno�no��?

Tzn widzisz napisa�e� to czym tak naprawd� r�ni� si� te 2 aplikacje
_GUI_, wi�c spokojnie piszesz engine programu, jak najbardziej przeno�ne,
a gui piszesz osobno w 2 wersjach (full_wypas_3D, vga, konsola ;).

Jak to pogodzi�? R�nie to jest robione, np zobacz engine poczty (pop3 czy
imap) a gui masz w wypasione w indedimail, zwyk�e w outlooku czy bat albo
tekstowe w pine.

--
*** rozanski.at.sergiusz.dot.com sq3bkn ***
***       http://www.4x4.kalisz.pl      ***
$ You have new spam in /home/serek/maildir/

‟Sergiusz Rozanski” popracował i:
> Tzn widzisz napisałeś to czym tak naprawdę różnią się te 2 aplikacje
> _GUI_, więc spokojnie piszesz engine programu, jak najbardziej
> przenośne, a gui piszesz osobno w 2 wersjach (full_wypas_3D, vga,
> konsola ;).
>
> Jak to pogodzić? Różnie to jest robione, np zobacz engine poczty (pop3
> czy imap) a gui masz w wypasione w indedimail, zwykłe w outlooku czy bat
> albo tekstowe w pine.
gdyby to był problem tylko różnego ‘gui’. algorytmy są pisane pod kątem
określonej architektury, np. mało pamięci, dużo, takiej, innej…
--
―oh yea, i got it!
―oh, stupid!
D. Icke

d < 0 pisze:
>     wyobraźmy sobie, że wśród użytkowników komputerów osobistych popula-
> rność  zyskały  różne  architektury maszyn (w skrócie: różne komputery),
> ale  nie  znikomo różna —jak jest teraz, lecz absolutnie różne. załóżmy
> na  przykład, że  ludzie  mają i będą mieli w użytkowaniu stare typy ma-
> szyn, które  różnią  się  przynajmniej  tym, że mają mało pamięci ‘ram’,
> i ci  użytkownicy  chcą  być ‚nowocześni’— używać nowego oprogramowania.
> jakkolwiek— nowe  jest pisane jednostronnie— na nowe maszyny, na szybkie
> maszyny i mające sporo pamięci ‘ram’. stare komputery się… ;-) nie psu-
> ją… e… tak, nie  mają wbudowanego przez producentów, ukrytego wyłącznika
> wywołujacego  awarię, by  zmusić  tych  użytkowników do wymiany sprzętu.
> ;-) (patent, patent! to ja napisałem. ;-D )
>     a teraz— programy napisane nawet w tzw. ‛przenośnych’ technologiach,
> mimo  że  dałyby  się  skompilować  na  stare  maszyny, to  się  na nich
> ·nie· wykonają  z powodu niezgodności oczekiwań oprogramowania z dostęp-
> nymi  na  sprzęcie. i nie  pomoże  tu  symulacja  środowiska, w którym
> jest dużo pamięci, bo jedynym rozwiązaniem jest napisanie programu, któ-
> ry ·nie  ma· tych  wygórowanych wymagań i spełnia mniej wygórowane cele,
> lub  robi to —oczywiście (co się pomija, bo taniej)— optymalniej, ekono-
> miczniej dla użytkownika.
>     i jak to pogodzić? ‚spór’ chyba już trwa zbyt długo ;-) i chyba wa-
> rto  to pogodzić. wiadomo— jedną z metod jest pisanie wersji oprogramo-
> wania, które  są  na różne platformy sprzętowe, lecz czym to miałoby się
> różnić  od  pisania wielu programów. i zaznaczam: architektury docelowy
> są  drastycznie  różne, niezgodne  pod  względem  dostępnego  sprzętu,
> a nie  tylko  algorytmy  sprzętowe  są niezgodne (np. takie jak ‘big-en-
> dian’, ‘little-endian’). mówię  o niezgodności  maszyn, która  nie może
> być  uzgodniona przez odwzorowanie matematyczne (np. projektowe odwróce-
> nie kolejności bajtów w liczbie).
>     jakie  są  inne rozwiązania? w zasadzie— jakie są w ogóle rozwiąza-
> nia, ponieważ  ja nie znajduję niczego poza pustym słowem „przenośność”,
> którego skuteczność opiera się jedynie na tym, że nikt nie stosuje real-
> nie  niezgodnej maszyny, lecz odpowiednio niezgodnej, czyli konwertowal-
> nej. dlaczego  mam mieć najnowszą kartę graficzną, by móc zagrać w naj-
> nowsze ‚wypasione’ szachy, jeśli na starym komputerze wystarczy mi nary-
> sowanie planszy w trybie tekstowym lub choćby podawanie ruchów tekstowo,
> ponieważ zyskiem gry w szachy na komputerze w tym wypadku jest gra z in-
> ną  osobą  na  krańcu  świata  bez konieczności oczekiwania na odpowiedź
> o ruchu przez ‘e‐mail’? ale jeśli mam nowiuteńki sprzęt prosto z fabry-
> ki, to  chcę  go  użyć  do zobaczenia pięknej wizualizacji związanej też
> z opcjami konfiguracyjnymi drugiego gracza o jego bierkach.
>     i jak ugryźć ;-) przenośność?

 Można pisać programy mające wszystkie opcje, ale uruchamiające je na
żądanie lub w razie wykrycia odpowiedniej konfiguracji. Na przykład
program, któremu podasz wszystkie dane na linii poleceń nie musi
uruchamiać GUI składającego się z niewiadomo ilu okienek (zajmujących
oczywiście zasoby) i może skupić się na szybkim wykonaniu zadania.
Jeśli uda mu się zaalokować na przykład 1MB pamięci, może skorzystać z
jednego algorytmu, a jeśli nie, to może pracować według innego, mając
dane w kawałkach po 16kB. Jeśli program wykryje dobrą kartę graficzną,
może załadować bibliotekę z bajeranckim wyglądem, jeśli zostanie
uruchomiony w trybie tekstowym, ograniczy się do niego, tym samym
zużywając mniej pamięci i czasu procesora. Nie jest to równoznaczne z
pisaniem wielu programów, bo program jest jeden i tylko uruchamia
odpowiednie części (lub też nie).

 Maszyna nie musi być "konwertowalna". Skoro mówimy tu o "drastycznie
 różnych" architekturach docelowych, to zapominamy o asemblerze i
przenosimy się na przykład do C czy Javy. Sam napisałem kiedyś program
w Javie, który, jeśli otrzymał wszystko z linii poleceń, działał w
trybie całkowicie nieinteraktywnym i w ogóle nie uruchamiał GUI (które
miał wbudowane). To oznacza, że nie tylko uruchomiłby się na różnych
architekturach (co daje Java), ale uruchomiłby się nawet na maszynie
bez monitora (np. zdalnie na jakimś serwerze) czy w trybie tekstowym.
A program (nawet w sensie binarnym, jak to w Javie bywa) byłby ten sam.

 W programach "mających wszystko" można, według mnie, przyjąć dwa
podejścia:

1) domyślnie wszystko powyłączane (czyli minimalna implementacja),
poszczególne elementy (np. graficzne) uruchamiałyby się po wykryciu
odpowiadającej konfiguracji sprzętowej lub na żądanie użytkownika (w
tym, na przykład, na brak danych), z automatycznym powrotem do
ustawień "słabszych", gdyby w czasie uruchamiania "lepszych" wystąpił błąd

2) domyślnie wszystko włączone, z automatycznym uruchamianiem ustawień
"słabszych", gdy w czasie uruchamiania "lepszych" wystąpił błąd lub
gdy użytkownik zażądał np. tylko interfejsu tekstowego

 Binarka programu może być ciągle jedna i ta sama (i mała), a elementy
opcjonalne (np. interfejs graficzny) byłyby w osobnych modułach,
ładowanych w razie potrzeby. Tak było/jest np. z Wordem czy MSIE (nie
pamiętam dokładnie) - plik EXE programu to było tylko kilkadziesiąt kB
(a wiadomo, że cała funkcjonalność by się w tym nie zmieściła), a
razem z programem były DLLe po kilkaset kB. Podobnie można byłoby
zrobić z owym "przenośnym" programem.

 Jest też oczywiście opcja kompilacji warunkowej (np. w Asm/C/C++) -
program pisany jest ze wszystkimi możliwościami i tylko w czasie
kompilacji pod określoną maszynę podaje się kompilatorowi opcje, by
odpowiednie części kodu programu kompilował lub ich nie kompilował. To
nie jest, nie da się ukryć, pisanie wielu programów, bo kod ciągle
jest jeden (zawierający wszystko), zmienia się tylko wynik jego
kompilacji. W Javie co prawda nie ma bezpośrednio takiej możliwości,
ale można ją "zasymulować" poprzez ręczne sprawdzanie dostępności
elementów środowiska uruchomieniowego lub wychwytywanie błędów. To
podejście ogranicza jednak możliwości programu, gdyż w razie zmiany
konfiguracji sprzętowej maszyny docelowej (np. dołożenie nowej karty
graficznej) niezbędna jest ponowna kompilacja programu. Program
skompilowany w całości (ten z modułami) mógłby po prostu od tej pory
ładować sobie inny moduł interfejsu graficznego.

--
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.JabberPL.org www.TorProject.org Soft (EN): miniurl.pl/bogdro-soft

czyli  składania  z klocków programowych nie przeskoczę…? w takim razie
chyba  warto zastanowić się, jak je składać, by było ich mało, a wykona-
nie nie kosztowało dużo.
--
―oh yea, i got it!
―oh, stupid!
D. Icke

d < 0 pisze:
> czyli  składania  z klocków programowych nie przeskoczę…?

 Raczej bym nie pisał programu typu "ze wszystkim włączonym", bo
wystarczy brak na przykład jednej biblioteki współdzielonej i program
nawet nie będzie miał szans się uruchomić, by wyświetlić informację o
błędzie. Po prostu system go nawet nie uruchomi i tyle.

> w takim razie
> chyba  warto zastanowić się, jak je składać, by było ich mało, a wykona-
> nie nie kosztowało dużo.

 Z jednej strony masz minimalizację wysiłku/nakładów (czyli używanie
na przykład jak najmniejszej liczby bibliotek), a z drugiem -
maksymalizację kompatybilności (jak ktoś nie ma OpenGL/DirectX,
używasz SDL czy innej biblioteki; jak ktoś nie ma karty dźwiękowej
7.1, uruchamiasz na przykład dźwięk stereo, mono lub wcale).

--
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.JabberPL.org www.TorProject.org Soft (EN): miniurl.pl/bogdro-soft

onegdaj ‟d < 0” rzecze:
> wyobraźmy sobie, że wśród użytkowników komputerów osobistych popula-
> rność  zyskały  różne  architektury maszyn (w skrócie: różne komputery),
> ale  nie  znikomo różna —jak jest teraz, lecz absolutnie różne. załóżmy
> na  przykład, że  ludzie  mają i będą mieli w użytkowaniu stare typy ma-
> szyn, które  różnią  się  przynajmniej  tym, że mają mało pamięci ‘ram’,
> i ci  użytkownicy  chcą  być ‚nowocześni’— używać nowego oprogramowania.
> jakkolwiek— nowe  jest pisane jednostronnie— na nowe maszyny, na szybkie
> maszyny i mające sporo pamięci ‘ram’. stare komputery się… ;-) nie psu-
> ją… e… tak, nie  mają wbudowanego przez producentów, ukrytego wyłącznika
> wywołujacego  awarię, by  zmusić  tych  użytkowników do wymiany sprzętu.
> ;-) (patent, patent! to ja napisałem. ;-D )
>     a teraz— programy napisane nawet w tzw. ‛przenośnych’ technologiach,
> mimo  że  dałyby  się  skompilować  na  stare  maszyny, to  się  na nich
> ·nie· wykonają  z powodu niezgodności oczekiwań oprogramowania z dostęp-
> nymi  na  sprzęcie. i nie  pomoże  tu  symulacja  środowiska, w którym
> jest dużo pamięci, bo jedynym rozwiązaniem jest napisanie programu, któ-
> ry ·nie  ma· tych  wygórowanych wymagań i spełnia mniej wygórowane cele,
> lub  robi to —oczywiście (co się pomija, bo taniej)— optymalniej, ekono-
> miczniej dla użytkownika.
>     i jak to pogodzić? ‚spór’ chyba już trwa zbyt długo ;-) i chyba wa-
> rto  to pogodzić. wiadomo— jedną z metod jest pisanie wersji oprogramo-
> wania, które  są  na różne platformy sprzętowe, lecz czym to miałoby się
> różnić  od  pisania wielu programów. i zaznaczam: architektury docelowy
> są  drastycznie  różne, niezgodne  pod  względem  dostępnego  sprzętu, a
> nie  tylko  algorytmy  sprzętowe  są niezgodne (np. takie jak ‘big-en-
> dian’, ‘little-endian’). mówię  o niezgodności  maszyn, która  nie może
> być  uzgodniona przez odwzorowanie matematyczne (np. projektowe odwróce-
> nie kolejności bajtów w liczbie).
>     jakie  są  inne rozwiązania? w zasadzie— jakie są w ogóle rozwiąza-
> nia, ponieważ  ja nie znajduję niczego poza pustym słowem „przenośność”,
> którego skuteczność opiera się jedynie na tym, że nikt nie stosuje real-
> nie  niezgodnej maszyny, lecz odpowiednio niezgodnej, czyli konwertowal-
> nej. dlaczego  mam mieć najnowszą kartę graficzną, by móc zagrać w naj-
> nowsze ‚wypasione’ szachy, jeśli na starym komputerze wystarczy mi nary-
> sowanie planszy w trybie tekstowym lub choćby podawanie ruchów tekstowo,
> ponieważ zyskiem gry w szachy na komputerze w tym wypadku jest gra z in-
> ną  osobą  na  krańcu  świata  bez konieczności oczekiwania na odpowiedź
> o ruchu przez ‘e‐mail’? ale jeśli mam nowiuteńki sprzęt prosto z fabry-
> ki, to  chcę  go  użyć  do zobaczenia pięknej wizualizacji związanej też
> z opcjami konfiguracyjnymi drugiego gracza o jego bierkach.
>     i jak ugryźć ;-) przenośność?
przez deklaracje abstraktów.
--
 qo   |)      CPL: cs[0..1] (ss[0..1]) p lvl of curr code!
    _x/ ,     RPL: seg_sel[0..1] privilege lvl of seg_sel!
    |    ng  __ -- __ -- __ -- __ -- __ -- __ -- __ -x86-,
,__ -- __ -- DPL: 2._word_of_seg_desc[13..14]:`f seg_desc ,