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 ;).

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).

Lua, ewolucja.

Lubię zbiegi okoliczności (święta). Szukałem małego, szybkiego języka skryptowego,
a o tym języku słyszałem już wcześniej. Niestety jestem dość sceptyczny do tego typu projektów (ile powstało nowych, wartych uwagi języków w ciągu ostatnich 10-lat?)
i czasem mi trochę schodzi żeby się zbliżyć do tematu, więc w tym przypadku musiało minąć prawie 10 lat…

Ale do sedna: twórcy Lua stworzyli najlepsze wprowadzenie do języka programowania, jakie kiedykolwiek czytałem: „The evolution of LUA”. Szczerze polecam każdemu. Jest to historia rozwoju i opis pojawiających się kolejno możliwości, ale napisana w sposób bardzo pragmatyczny i co najważniejsze, bardzo jasny. Przykład: zawsze się zastanawiałem, kiedy w Pythonie pojawiały się pewne kluczowe elementy, albo np. w której wersji dany „feature”, który np. lubię nadużywać, już był. W „The evolution…” jest to podane wprost:evolution_of_luaPowiem wprost: szacunek dla Brazylijczyków. Inni powinni się od nich uczyć.

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 :).