Konfiguracje środowiska i symulacji 

Na razie staram się poznawać Framsticks i jestem dopiero w trakcie czytania jego głównego podręcznika. Opiszę może parę pewnych moich wrażeń, wyobrażeń, pomysłów, propozycji dotyczących głównych programów tego systemu.

---

Obecnym interpreterom światów trzeba wskazywać osobno różne pliki (o typach gen, expdef itd.), będące różnymi fragmentami całego programu świata. Wg mnie bardziej naturalne byłoby chyba, gdyby każdy (zapisany w dysku) świat (do wykonywania) był określony tylko przez jeden program, tzn. zapisany jako jeden plik, a więc z tylko jednym swoim identyfikatorem (nazwą pliku). Ten plik powinien oczywiście być zestawem wielu plików (m.in. o powyższych typach: expdef, gen, neuro itd.).
Tym plikiem programu świata mogłoby być:
- miejsce, gdzie jest tamten zestaw zwykłych plików
albo
- plik końcowy (w sensie poziomu SO), zawierający (pod)pliki w takim sensie, w jakim plik typu ZIP zawiera w sobie inne pliki, czy plik typu MDB (z MSAccess) zawiera swoje 'wirtualne' (pod)pliki różnych typów.

Wg tego, co czytałem, to dotychczasowe interpretery światów nie potrafią zapisać nie tylko aktualnego stanu wykonywanego świata (co byłby przydatne dla okresowego tworzenia kopii bezpieczeństwa wykonywanego świata, a więc możliwości kontynuowana świata po np. awarii zasilania komputera lub po przeniesieniu świata do innego komputera), ale nie potrafią też zapisać aktualnego stanu żyjącego tam stworzenia (jego fenotypu) – w tym stanu jego mózgu (sieci neuronowej), o być może zmienionej strukturze (w porównaniu do swojego stanu za/noworodkowego), powstałej w trakcie rozwoju osobniczego, w tym uczenia się. Do zapisu takiego fenotypu prawdopodobnie najbardziej nadawałby się (spośród opisanych języków) język f0. Taka możliwość byłaby przydatna dla skopiowania dorosłego stworzenia do innego (zgodnego) świata do innego komputera (np. innego użytkownika).

Co pewien czas (automatycznie-okresowo lub na życzenie użytkownika) interpreter świata powinien zapisywać (po chwilowym zatrzymaniu czasu tego świata) aktualny stan świata (jego 'kopię bezpieczeństwa') jako plik, aby można było potem w razie potrzeby wczytać go z dysku i kontynuować wykonywanie (programu) tego świata od momentu jego zapisania - dotyczy to szczególnie światów wykonywanych bardzo długo (dni, tygodnie).
Najlepiej by było, aby każdy obiekt świata (środowisko, stworzenia i ich wytwory (np. budowle, książki)) był tam (w pliku) zapisywany jako osobny obiekt. W zapisie stworzeń (aktualnego dokładnego stanu ich ciał) powinno chyba być dla każdej ich części: miejsce (współrzędne), ukierunkowanie, prędkość, kręt, a być może też odkształcenia, naprężenia i inne cechy. Dlatego do zapisu wszystkich obiektów świata najlepiej nadawałby się jakiś język zgodny z językiem (metodą), w którym zapisywane są wszystkie obiekty w świecie będącym w (wirtualnej) pamięci operacyjnej interpretera.

W drugiej (alternatywnej) metodzie zapisu (np. gdyby z poprzednią metodą zapisu obiektów były trudności) oprócz skopiowania startowej wersji programu świata (tzn. plików typów expdef, gen itd.) wystarczyłoby jako jeden z (pod)plików zapisać aktualną zawartość wirtualnej pamięci (operacyjnej) interpretera świata - chodzi tu o tę pamięć wirtualną (czy tę jej część), w której jest zapisany cały wykonywany świat i stan jego wykonywania (czyli wszystkie informacje potrzebne do kontynuowania wykonywania świata po wczytaniu go z pliku przez interpreter świata). Zakładając (nie znam metody zapisu (organizacji) świata w pamięci operacyjnej), że na poziomie wirtualnym (zorganizowanym przez interpreter (lub wyżej)) metoda zapisania świata (a przynajmniej jego rozumienia przez interpreter) jest dokładnie taka sama dla każdego interpretera w każdym systemie operacyjnym i w każdym typie komputera (np. PC, Amiga itd.).

---

Czytałem też, że jest tworzona jakaś nowa wersja sieciowa tego systemu (ale nie zrozumiałem tego dokładnie). Natomiast wg tego, jak próbowałem wyobrazić sobie ulepszone działanie takiego przyszłego systemu Framsticks, to mogłoby to wyglądać tak:
Główny interpreter światów (odpowiednik CLI) na początku wczytywałby program świata (startowy lub zapisany wcześniej jako kopia bezpieczeństwa) i go wykonywał.
Drugi główny program dla użytkownika (odpowiednik GUI) służyłby do obserwacji (podglądu), co się dzieje w takim wykonywanym świecie (tryb obserwacji), a w drugim trybie swojego działania (tryb ingerencji) mógłby też modyfikować świat, program świata i jego wykonywanie.
Ten program (GUI) sam nie byłby bezpośrednio interpreterem, lecz podłączałby się do interpretera, a poprzez niego do świata (lub tylko do wirtualnej pamięci operacyjnej interpretera, gdzie byłby świat - ale raczej tylko w trybie obserwacji (chyba że sam też zawierałby w sobie własny interpreter, co byłoby jednak może trochę 'nadmiarowe')).

Interpreterów światów (odpowiedników CLI) mogłoby być włączonych w komputerze dowolnie wiele - te interpretery (każdy ze swoim wykonywanym światem) mogłyby być też w innych komputerach - a drugi program (GUI) miałby do nich dostęp przez sieć lokalną i przez Internet.
Potrzebna byłaby więc trzecia metoda ("zewnętrzna") dostępu do tych interpreterów i światów. Ten program razem dodatkowym oprogramowaniem w sieci (we wszystkich komputerach z interpretatorami światów) służyłby do zarządzania wykonywaniem światów. Byłby to więc taki wirtualny (pod)system operacyjny do zarządzania wykonywaniem światów. Użytkownik mógłby te światy kopiować i przenosić przez sieć do innych komputerów, kolejkować, wznawiać i wstrzymywać ich wykonywanie (zachowując je w pamięci operacyjnej lub zapisując w dysku, aby ją zwolnić), tworzyć kopie bezpieczeństwa ('ręcznie' lub określając okres automatycznego jej tworzenia) itd...

Maciej Komosinski's picture

> Obecnym interpreterom światów trzeba wskazywać osobno różne pliki (o typach gen, expdef itd.), będące różnymi fragmentami całego programu świata. Wg mnie bardziej naturalne byłoby chyba, gdyby każdy (zapisany w dysku) świat (do wykonywania) był określony tylko przez jeden program, tzn. zapisany jako jeden plik, a więc z tylko jednym swoim identyfikatorem (nazwą pliku).

    Może byłoby to bardziej naturalne, ale mniej elastyczne. Jeśli te same pliki brałyby udział w wielu eksperymentach, trzeba by je wielokrotnie kopiować w różne miejsca. Nie wydaje się, by takie rozwiązanie wnosiło jakąś nową funkcjonalność.

> Wg tego, co czytałem, to dotychczasowe interpretery światów nie potrafią zapisać nie tylko aktualnego stanu wykonywanego świata (co byłby przydatne dla okresowego tworzenia kopii bezpieczeństwa wykonywanego świata, a więc możliwości kontynuowana świata po np. awarii zasilania komputera lub po przeniesieniu świata do innego komputera), ale nie potrafią też zapisać aktualnego stanu żyjącego tam stworzenia (jego fenotypu) – w tym stanu jego mózgu (sieci neuronowej)

    Tak, to prawda. Założyliśmy, że główna "wiedza" środowiska zawarta jest w puli genów, i nawet, jeśli tracimy trochę informacji nie zapisując chwilowego stanu żywych organizmów, to nie jest to duża strata. Oczywiście wszystko zależy od eksperymentu - czasem może być faktycznie tak, że organizm żyje kilkanaście godzin i to co nagromadził w swojej sieci neuronowej, jeśli zniknie, będzie wymagało powtórnej kilkunastogodzinnej symulacji. Inny przypadek to specyficzne ułożenie organizmów w środowisku, które również nie może zostać zapisywane. Jednak w znakomitej większości przypadków nie zapisywanie stanu żyjących organizmów nie prowadzi do wielkich strat. Zakładamy, że o ile odtworzymy idealnie pulę genów, to nie będzie specjalnie niekorzystne, jeśli stan środowiska po odtworzeniu ze stanu zapisanego będzie się nieco różnił - bo i tak przecież symulacja jest niedeterministyczna i mogła by pójść dowolną drogą. Więc to, że organizmy po wznowieniu symulacji urodzą się w innych miejscach, albo że od nowa będą musiały się trochę nauczyć, nie stanowi wielkiego zaburzenia całego procesu. Podstawowa informacja czyli pula genów zostaje zachowana.

    Ilustruje to poniższy schemat - biegnie symulacja oznaczona "1", robimy zapis "z", i faktycznie tracimy pewien fragment symulacji (stan środowiska czyli dwie ostatnie "1"). Jednak wznawiając symulację "2" mamy świadomość, że te dwie utracone końcowe jedynki były i tak tylko jedną z możliwych dróg, jakimi mógł pójść rozwój wydarzeń od momentu "z". Zatem droga z "2" jest równie uprawiona, jak te dwie jedynki - one są jedynie małym kawałkiem zmarnowanego czasu symulacji.

...1111111111111111111z11
                       22222222222222...

Oczywiście wszystko to przy założeniu, że podstawę informacji o procesie stanowi pula genów. Jeśli tak nie jest (np. wcale nie ma puli genów i wszystko co istnieje, żyje), to najwygodniej zorganizować zapis przenosząc podstawowe informacje o świecie do puli genów (która ma wtedy pełnić rolę "wyciągu" ze stanu świata). A jeśli to rozwiązanie nie jest wystarczające, to można też zrealizować zapis i odczyt niektórych elementów stanu świata za pomocą napisanego samodzielnie skryptu, dostosowanego do konkretnego eksperymentu.

> Czytałem też, że jest tworzona jakaś nowa wersja sieciowa tego systemu (ale nie zrozumiałem tego dokładnie).

    Framsticks może działać w trybie serwera (czyli to samo co CLI, ale można się komunikować z nim zdalnie, przez Internet). Stąd możliwość rozpraszania obliczeń na najróżniejsze sposoby, ale to wymaga obecnie pewnej wiedzy z zakresu programowania - żeby skonfigurować/stworzyć taki rozproszony eksperyment.