Lua + gemlib.

Jak się spodziewałem utworzenie własnej biblioteki w C dla Lua jest bardzo proste. Póki co moja „biblioteka” to ambitna funkcja v_pline() z gemlib rysująca polilinię, z dowolnej (ile się zmieści) ilości danych przekazywanych przez stos Lua. Nauczka nr 1: nie używać malloc() z libstd PureC (wywala się), tylko Malloc() z tos.h.

Cała filozofia, to utworzenie modułu np. gemlib.c, w którym będą zdefiniowane funkcje z biblioteki w C, w tym przykładzie jest aż jedna: vpline() o definicji jak niżej:

static int vpline(lua_State *L) {
/* narysuj polilinię */
}

potem:


static const luaL_Reg gemlib[] = {
{"v_pline", vpline},
{NULL, NULL}};

LUAMOD_API int luaopen_gemlib (lua_State *L) {
luaL_newlib(L, gemlib);
return 1;
}

i dodanie: LUAMOD_API int (luaopen_gemlib) (lua_State *L); np do lualib.h oraz
{„gem”, luaopen_gemlib} do loadedlibs[] w linit.c, żeby interpreter go zarejestrował, bo moduł jest statycznie linkowany więc nie trzeba go ładować.

Wybiorę co najciekawsze funkcje GEM/VDI/AES i zobaczymy co z tego wyjdzie. Proceduralne tworzenie grafiki ze skryptu Lua może być całkiem zabawne ;).

Mam sporo przemyśleń i wątpliwości czy obsługa GUI z Lua jest do zrobienia, ale w tym cała frajda ;).

Reklamy

Gemlib.

Szkoda, że tak niewiele dobrej dokumentacji się zachowało (albo ja nie wiem gdzie szukać). Znalazłem GEM’s Programmers Reference z Abacus Software i Professional GEM, i tu jest sporo fajnych artykułów. I jeszcze to na początek i ten wątek na Atari Forum jest bardzo ciekawy. Ok, znalazłem jeszcze to. Chyba wystarczy ;).gemlib
No i API Gemlib jest chyba dość spójne, bo dla prostych przykładów można bez problemów linkować z GEM.LIB (w wersji 0.43.6) zamiast PCGEMLIB.LIB z PURE C.

gemlib_st

Zaczynam powoli zmieniać zdanie na temat ST…

Lua-5.3.0 dla Atari ST (PureC).

No i wyszła wersja Lua-5.3.0. Binarka dla Atari ST tutaj. A gdyby ktoś chciał poeksperymentować wrzucam mój kompletny katalog PURE_C, wraz ze katalogiem lua530 i paroma koniecznymi nagłówkami. A w katalogu src znajduje się plik projektu lua.prj (i lamerski patch ze zmianami względem oryginalnych źródeł, już zaaplikowany). purec_lua530Jak widać powyżej, działa w Aranym. Aby skompilować, ładujemy plik lua.prj w menu Project -> Select, a potem Project -> Make all. W pliku lua.prj trzeba ustawić właściwy katalog w którym utworzona zostanie binarka (u mnie g:\build\lua\lua53.prg). lua530

Lua-5.3.0-rc4 dla Atari ST.

No i udało się skompilować w PureC 😉 Binarka, gdyby ktoś chciał się pobawić (148KB), tutaj.

lua530rc4

Lua530rc4 jest nawet trochę szybsze od 503 z 2006 roku.

iterator_closure_generator5Interpreter zdaje się działać na miarę możliwości platformy, powyżej ST spotyka iteratory, generatory i domknięcia 😉

f2c

Dla większych serii danych i dużych ilości obliczeń w Lua 5.3.0 różnica GCC vs PureC nie jest już tak duża: jeśli policzymy 30 elementów nieszczęsnego Fibonacciego, 30 razy w pętli, to czas wykonania dla binarki skompilowanej GCC wynosi: 1591x5ms=7,955s a dla PureC 1495x5ms=7,475s. Różnica 6.7%. W 5.2.3 2186x5ms=10,930s. 46% vs 6.7% robi różnicę ;). Dla małych skryptów różnica oczywiście da się we znaki, a 3x większy rozmiar binarki na wolniejszych dyskach da sporą różnicę czasu wykonania.

Niewiarygodne jest to, że da się taki projekt w 2015 skompilować w PureC, który ma 22 lata :]

I jeszcze jeden przykład, tym razem OOP w Lua:

OO_luaJasne, proste i przejrzyste, a możliwości implementacji OOP „po swojemu” ogromne (brak narzuconego modelu obiektowego).

Gulam, yet another shell for TOS.

Z jakiegoś powodu zakodowałem sobie, że binarki kompilowane pod Freemint/Aranym są linkowane z libmint i nie będzie się ich dało uruchomić pod TOS-em, a tak nie jest. Moje eksperymenta generowane przez GCC i PureC działają prawidłowo w „gołym” TOS-ie. Poniżej zdjęcie ekranu z Gulam shell w Mist (STEroids):

Zauważyłem też sporą różnicę czasu wykonania w zależności od „nośnika” na którym znajduje się uruchamiany program. Uruchomienie z dysku GEMDOS w Hatari jest znacznie szybsze od obrazu dysku z driverem AHDI:gulam1Po cichu liczę na to, że po przepisaniu DMA w Mist przez Till’a i przy bezpośrednim dostępie do FAT, będzie tak samo szybko.

Magic.

I jeszcze jedna ciekawostka od twórców PureC: MagiC.
magicNiestety nie działa w MIST i nie wiadomo czy zadziała, bo developer jest tylko jeden i ma jasno określone priorytety, co jest całkowicie zrozumiałe.

Aktualizacja: Już działa w MIST :).

Lua dla Freemint.

luaLua jest szybki, mały, dynamicznie typowany i wypasiony. Jest konsola interaktywna, można skompilować skrypt do bytecodu, są „list comprehensions” i sporo tego, co lubię z Pythona… Co ważniejsze: jak widać powyżej, jest szybko. Powiedziałbym nawet że bardzo szybko. Binarka Lua-5.2.3 dla Atari ST (skompilowana GCC-4.6.4) dla zainteresowanych tutaj. Tym razem niestety na Mist w trybie STEroids jest wolniej niż w Hatari (68020). A co dziwniejsze: w ST Mint uruchomienie bytecodu jest wolniejsze od interpretowanego pliku .lua (w Hatari też), a we Freemint w Aranym jest 2x szybsze (czego należałoby się spodziewać). Zwariować można. Nie zmienia to faktu, że Lua jest najszybszym językiem tego rodzaju, z jakim miałem do czynienia.

Update: Poniżej zrzut ekranu z Lua-5.0.2 (link do webarchives) skompilowanego PureC w 2006 przez Thorstena Butschke:
lua_purecJak widać Lua jest sporo szybszy. Może po prostu GCC kiepsko optymalizuje kod, chociaż nie chce mi się w to wierzyć. Z drugiej strony wersja 5.0.2 skompilowana GCC-4.6 działa tak samo szybko jak 5.2.3 i nie daje mi spokoju, że 16-bitowy retro-kompilator daje szybszy kod… Może to kwestia manipulacji 32-bitowymi typami danych w GCC, a może narzut starej wersji Mintlib/stdlib w ST Mint i/lub libgcc, ciężko stwierdzić. Binarka Lua-5.2.3 skompilowana GCC jest w każdym razie w pełni funkcjonalna, a kompilacja w PureC to taki mój eksperyment. Swoją drogą to bardzo fajny kompilator i IDE. Tutaj jest paczka z plikami projektu Lua-5.0.2 dla PureC, więc warto  powalczyć ;).

Update: Udało mi się w PureC 1.1 skompilować Lua-5.0.3:purec_lua503Binarka (wrzucam tutaj) działa w STMint znacznie szybciej niż kompilacje gcc.
lua503W Vbcc Lua-5.2.3 się kompiluje, ale działa nieprawidłowo (złe parsowanie plików i obsługa konsoli interaktywnej, pewnie dałoby się ogarnąć). AHCC odpada na starcie. Niby aktywnie rozwijany (ostatnia wersja z września 2014), ale nie radzi sobie już na etapie dołączania plików nagłówkowych, a komunikaty są mało pomocne w znalezieniu rozwiązania. Próbuje skompilować wersję 5.2.3 w PureC (2 moduły się jeszcze nie budują i niestety jeden z nich wymaga modyfikacji lub przepisania skomplikowanego makra). Fajnie byłoby też skompilować Tinypy. Ogólnie dobra okazja, żeby sobie odświeżyć ANSI C.