Komentowana treść: Lua w nowym wcieleniu
14.12.2010 12:42
[#1]
Re: Lua w nowym wcieleniu
Brzmi naprawdę zachęcająco. Może "na fali" Lua powstanie jakiś sprytne, małe IDE, które w końcu będzie korzystało z MUI i zastąpi GoldEd-a.
Jeśli Lua to jest skryptowy język, to znaczy że w systemie musi być ciągle uruchomiony jakiś interpreter, tak jak Java VM albo coś w tym stylu?
Jeśli Lua to jest skryptowy język, to znaczy że w systemie musi być ciągle uruchomiony jakiś interpreter, tak jak Java VM albo coś w tym stylu?
14.12.2010 13:16
[#2]
Re: Lua w nowym wcieleniu
@R-Tea, post #1
No i niech ktoś jeszcze powie, że Krashan nie rządzi. :) Na razie nie bardzo potrzebuję tego języka ale gdzie bym się nie ruszył w świecie pozaamigowym to ciągle się na niego natykam, więc myślę, że prędzej czy później będzie mi potrzebny. Tak samo było z Pythonem. Normalnie bym na niego nie popatrzył ale jak zaczął być potrzebny (w Blenderze) to dziękowałem niebiosom, że mamy go pod MorphOS-em. Dzięki Krashan!
A tak swoją drogą to ciekawy jestem co skłoniło autora MOSowej wersji do zrobienia Lua dla MorphOS. Dlaczego akurat Lua?
R-Tea:
A może zamiast pisać IDE dla Lua po prostu zrobić plugin, czy przystosować GoldEd/CubicIDE do tego żeby wspierał Lua. A przynajmniej rozpoznawał jego składnię i trochę pomagał w pisaniu (na miarę możliwości GoldEd/CubicIDE).
A co do interpretera to pewnie jest to zrobione tak jak z ARexxem. Ale pewnie zaraz sprawę przybliży autor więc dowiemy się dokładnie.
Ostatnia edycja: 14.12.10 13:17:56
A tak swoją drogą to ciekawy jestem co skłoniło autora MOSowej wersji do zrobienia Lua dla MorphOS. Dlaczego akurat Lua?
R-Tea:
A może zamiast pisać IDE dla Lua po prostu zrobić plugin, czy przystosować GoldEd/CubicIDE do tego żeby wspierał Lua. A przynajmniej rozpoznawał jego składnię i trochę pomagał w pisaniu (na miarę możliwości GoldEd/CubicIDE).
A co do interpretera to pewnie jest to zrobione tak jak z ARexxem. Ale pewnie zaraz sprawę przybliży autor więc dowiemy się dokładnie.
Ostatnia edycja: 14.12.10 13:17:56
14.12.2010 13:17
[#3]
Re: Lua w nowym wcieleniu
@R-Tea, post #1
Nie musi być uruchomiony ciągle. W bibliotece lua.library jest funkcja LuaNewState(), która tworzy instancję interpretera - do tej instancji ładujemy skrypt (z pamięci lub z pliku) i wykonujemy. Każdy program może sobie otworzyć lua.library i stworzyć swoją instancję, oczywiście lua.library i moduły binarne są w pamięci komputera tylko raz, niezależnie od tego czy aktualnie pracujących skryptów jest 5, czy 500.
Rzecz jasna, żeby wykonać skrypt nie wewnątrz jakiejś aplikacji, tylko jako zewnętrzny, musi być jakaś komenda, która ten skrypt wykona, odpowiednik ARexxowej "rx". Taka komenda (nazwana "luax") wkrótce będzie gotowa, nie jest to nic skomplikowanego.
Jeżeli jakiś program pozwala na wykorzystanie skryptów ARexxa odpalając je przez "rx", będzie można go "oszukać" tworząc linka "rx"->"luax" i będzie tak samo dobrze wykonywał skrypty Lua.
Co do maszyny Javy - jest tu pewne podobieństwo. Lua najpierw tłumaczy sobie skrypt do bytecodu i potem wykonuje go. Bytecode można sobie nawet zgrać i potem załadować z pliku. Zasadnicza różnica jest taka, że Lua nie gwarantuje przenośności bytecodu między różnymi systemami operacyjnymi, nie gwarantuje też istnienia kompatybilnych między systemami bibliotek np. do GUI czy grafiki niskopoziomowej. A to dlatego, że przenośność "binarek" nie jest celem Lua, tak jak jest celem Javy.
Rzecz jasna, żeby wykonać skrypt nie wewnątrz jakiejś aplikacji, tylko jako zewnętrzny, musi być jakaś komenda, która ten skrypt wykona, odpowiednik ARexxowej "rx". Taka komenda (nazwana "luax") wkrótce będzie gotowa, nie jest to nic skomplikowanego.
Jeżeli jakiś program pozwala na wykorzystanie skryptów ARexxa odpalając je przez "rx", będzie można go "oszukać" tworząc linka "rx"->"luax" i będzie tak samo dobrze wykonywał skrypty Lua.
Co do maszyny Javy - jest tu pewne podobieństwo. Lua najpierw tłumaczy sobie skrypt do bytecodu i potem wykonuje go. Bytecode można sobie nawet zgrać i potem załadować z pliku. Zasadnicza różnica jest taka, że Lua nie gwarantuje przenośności bytecodu między różnymi systemami operacyjnymi, nie gwarantuje też istnienia kompatybilnych między systemami bibliotek np. do GUI czy grafiki niskopoziomowej. A to dlatego, że przenośność "binarek" nie jest celem Lua, tak jak jest celem Javy.
14.12.2010 13:19
[#5]
Re: Lua w nowym wcieleniu
@G. Kraszewski, post #3
Czyli tak jak się spodziewałem jest to zorganizowane podobnie do ARexxa. Fajnie. Rozwiązanie do którego przywykliśmy. Takie ludzkie, amigowe. :)
A jak się ma prędkość Lua do prędkości ARexxa? Skoro to jest tłumaczone na jakiś bytekod to domyślam się, że różnica prędkości jest znaczna (na korzyść Lua oczywiście).
Jak już poskromisz Lua w 100% to jaki będzie kolejny język? :) Dużo ludzi chciałoby żeby jakiś odważny mózg wziąłby się za Javę... Wiem, że to ogromne przedsięwzięcie. Ale sensowna przeglądarka, TinyGL, Blender, Python, Lua też nie wydawały się małymi przedsięwzięciami, a zostały zrobione. I to nie przez całe zespoły korporacyjnych programistów.
Ostatnia edycja: 14.12.10 13:24:16
A jak się ma prędkość Lua do prędkości ARexxa? Skoro to jest tłumaczone na jakiś bytekod to domyślam się, że różnica prędkości jest znaczna (na korzyść Lua oczywiście).
Jak już poskromisz Lua w 100% to jaki będzie kolejny język? :) Dużo ludzi chciałoby żeby jakiś odważny mózg wziąłby się za Javę... Wiem, że to ogromne przedsięwzięcie. Ale sensowna przeglądarka, TinyGL, Blender, Python, Lua też nie wydawały się małymi przedsięwzięciami, a zostały zrobione. I to nie przez całe zespoły korporacyjnych programistów.
Ostatnia edycja: 14.12.10 13:24:16
14.12.2010 13:27
[#6]
Re: Lua w nowym wcieleniu
@MDW, post #5
A po co kolejny język ?
Lepiej niech Krashan poskromi drugiego proca :)
Zaletą Amiga OS jest ich lekkość. Java lekka nie jest. Dlatego Lua idealnie się wpisuje w filozofię AOS. Jak pojawi się JIT dla Lua będzie też szybko.
Całą zaletą Javy jest bardzo szybka i dobra VM. Nie wiem czy są źródła tej VM, i czy jest JIT dla PPC. Bez tych rzeczy Java będzie działała tragicznie.
Ostatnia edycja: 14.12.10 13:34:48
Lepiej niech Krashan poskromi drugiego proca :)
Zaletą Amiga OS jest ich lekkość. Java lekka nie jest. Dlatego Lua idealnie się wpisuje w filozofię AOS. Jak pojawi się JIT dla Lua będzie też szybko.
Całą zaletą Javy jest bardzo szybka i dobra VM. Nie wiem czy są źródła tej VM, i czy jest JIT dla PPC. Bez tych rzeczy Java będzie działała tragicznie.
Ostatnia edycja: 14.12.10 13:34:48
14.12.2010 13:40
[#7]
Re: Lua w nowym wcieleniu
@Sventevith, post #6
Java przydałaby się do częściowego uzupełnienia braków w naszym skromnym oprogramowaniu. Chociaż częściowo się z Tobą zgodzę. Ta krowa pewnie zamuliłaby nieco nasze fajne maszyny i zrobiłoby się bardzo... nieamigowo.
Wobec tego powiem tak: Krashan, Javę zostaw sobie na emeryturę. ;)
Wobec tego powiem tak: Krashan, Javę zostaw sobie na emeryturę. ;)
14.12.2010 13:46
[#8]
Re: Lua w nowym wcieleniu
@MDW, post #2
A tak swoją drogą to ciekawy jestem co skłoniło autora MOSowej wersji do zrobienia Lua dla MorphOS. Dlaczego akurat Lua?
1. Mały i zgrabny, w dodatku interpreter jest szybki (niedługo pewnie jakieś testy).
2. Minimum zależności - nie muszę przy okazji portować pierdylionów linuksowych bibliotek. Wystarczy zlinkować z -lc i to naprawdę są zupełne trywializmy typu strlen(), czy strchr(). Nawet z printf()-a nie muszę korzystać.
2. Łatwo rozszerzalny.
3. Łatwo się miesza w środku (np. dodaje własny loader do modułów ładowanych dynamicznie...).
4. Podoba mi się składnia.
5. Uniwersalność stosowania, możesz go mieć zarówno wewnątrz aplikacji, jak i sterować nim aplikacjami z zewnątrz.
Co do IDE i tak dalej - Lua Explorador może się stać takowym. Po pierwsze klasa, która wyświetla kod i pokazuje, która linia jest wykonywana, jeszcze co prawda nie jest edytorem i nie ma kolorowania składni, ale kluczem jest słowo "jeszcze". Poza tym - cały debuger będzie wkrótce klasą MCC - więc jeżeli używasz skryptów do wewnętrznej logiki aplikacji i chcesz żeby użytkownik miał do tego dostęp, to wstawiasz w swoją aplikację obiekt klasy LuaDebugger i użytkownik ma od razu środowisko uruchomieniowe do tych swoich skryptów...
Ostatnia edycja: 14.12.10 13:48:49
1. Mały i zgrabny, w dodatku interpreter jest szybki (niedługo pewnie jakieś testy).
2. Minimum zależności - nie muszę przy okazji portować pierdylionów linuksowych bibliotek. Wystarczy zlinkować z -lc i to naprawdę są zupełne trywializmy typu strlen(), czy strchr(). Nawet z printf()-a nie muszę korzystać.
2. Łatwo rozszerzalny.
3. Łatwo się miesza w środku (np. dodaje własny loader do modułów ładowanych dynamicznie...).
4. Podoba mi się składnia.
5. Uniwersalność stosowania, możesz go mieć zarówno wewnątrz aplikacji, jak i sterować nim aplikacjami z zewnątrz.
Co do IDE i tak dalej - Lua Explorador może się stać takowym. Po pierwsze klasa, która wyświetla kod i pokazuje, która linia jest wykonywana, jeszcze co prawda nie jest edytorem i nie ma kolorowania składni, ale kluczem jest słowo "jeszcze". Poza tym - cały debuger będzie wkrótce klasą MCC - więc jeżeli używasz skryptów do wewnętrznej logiki aplikacji i chcesz żeby użytkownik miał do tego dostęp, to wstawiasz w swoją aplikację obiekt klasy LuaDebugger i użytkownik ma od razu środowisko uruchomieniowe do tych swoich skryptów...
Ostatnia edycja: 14.12.10 13:48:49
14.12.2010 13:57
[#9]
Re: Lua w nowym wcieleniu
@MDW, post #7
Co do małej ilości softu. To brakuje mi Flasha no i office jakiegoś.
Szkoda, że AmigaWriter nie ma portu Arexxa, tak aby napisać export/import innych formatów. Szkoda, też ze Papyrus został zarzucony na MOSa.
Głównym programem w obecnych czasach jest przeglądarka WWW. Moim zdaniem świat będzie zmierzał w kierunku cloud i przeglądarka będzie podstawowym softem. Istotny jest też JIT dla JS, z tego co wiem OWB takowego nie ma :( To jest istotniejsze niż następne języki programowania.
Czym szybciej przyjmie się HTML5 tym szybciej flash będzie tracił na popularności.
Szkoda, że AmigaWriter nie ma portu Arexxa, tak aby napisać export/import innych formatów. Szkoda, też ze Papyrus został zarzucony na MOSa.
Głównym programem w obecnych czasach jest przeglądarka WWW. Moim zdaniem świat będzie zmierzał w kierunku cloud i przeglądarka będzie podstawowym softem. Istotny jest też JIT dla JS, z tego co wiem OWB takowego nie ma :( To jest istotniejsze niż następne języki programowania.
Czym szybciej przyjmie się HTML5 tym szybciej flash będzie tracił na popularności.
14.12.2010 14:28
[#10]
Re: Lua w nowym wcieleniu
@G. Kraszewski, post #8
@ G. Kraszewski
kluczem jest słowo "jeszcze".
:D
@ MDW
A może zamiast pisać IDE dla Lua po prostu zrobić plugin, czy przystosować GoldEd/CubicIDE do tego żeby wspierał Lua.
GoldEd nie korzysta z MUI, a ja jestem fanem MUI :)
offtopic:
Zauważyłem że OWB pamięta treść wpisaną w textarea po cofnięciu się do poprzedniej stroni i powrocie :D. Zszarpałem sobie nerwy kiedyś jak traciłem swoje wypociny po użyciu "Cofnij" w FF, IE lub Operze.
kluczem jest słowo "jeszcze".
:D
@ MDW
A może zamiast pisać IDE dla Lua po prostu zrobić plugin, czy przystosować GoldEd/CubicIDE do tego żeby wspierał Lua.
GoldEd nie korzysta z MUI, a ja jestem fanem MUI :)
offtopic:
Zauważyłem że OWB pamięta treść wpisaną w textarea po cofnięciu się do poprzedniej stroni i powrocie :D. Zszarpałem sobie nerwy kiedyś jak traciłem swoje wypociny po użyciu "Cofnij" w FF, IE lub Operze.
14.12.2010 17:07
[#12]
Re: Lua w nowym wcieleniu
@R-Tea, post #10
GoldEd nie korzysta z MUI, a ja jestem fanem MUI
Z tego co mi wiadomo na mosa dostępne będzie inne rozwiązanie które pozwoli zapomnieć o cubic/morphed... więc jak najbardziej idziemy w kierunku mui.
Dodanie parsera lua do cubicide nie jest trudne.. gorzej może być w przypadku morpheda..
A.. no i brawa dla Krashana..
Z tego co mi wiadomo na mosa dostępne będzie inne rozwiązanie które pozwoli zapomnieć o cubic/morphed... więc jak najbardziej idziemy w kierunku mui.
Dodanie parsera lua do cubicide nie jest trudne.. gorzej może być w przypadku morpheda..
A.. no i brawa dla Krashana..
14.12.2010 17:27
[#14]
Re: Lua w nowym wcieleniu
@R-Tea, post #10
R-Tea:
GoldEd nie korzysta z MUI, a ja jestem fanem MUI
Kumam co masz na myśli i w pełni popieram. Ja też uwielbiam MUI. Dla mnie wszystko mogłoby być pod MUI. Cały świat mógłby być pod MUI. :) Dawno temu jak kupiłem kartę graficzną do klasycznej Amigi marzyłem, że byłbym w raju gdyby mój system przyjął MUI jako domyślny GUI i gdyby MUI się trochę rozwinął, oderwał się od tych 8 kolorów MagicWB i trochę uporządkował. Dosłownie wyobrażałem sobie to co dzisiaj jest pod MOSem (no, może trochę mniej sobie wyobrażałem). Nigdy nie przypuszczałem, że te marzenia się spełnią. :)
MaaG^dA:
Z tego co mi wiadomo na mosa dostępne będzie inne rozwiązanie które pozwoli zapomnieć o cubic/morphed... więc jak najbardziej idziemy w kierunku mui.
Powinienem się zmartwić, bo CubicIDE za którego zapłaciłem stanie się bezużyteczny. Ale nie! IDE napisane od początku pod MUI i specjalnie dla MorphOS to naprawdę świetna wiadomość. Już cieszę się jak dziecko. :)
A można więcej informacji? Maczasz w tym swoje zdolne palce?
Sventevith:
Głównym programem w obecnych czasach jest przeglądarka WWW. Moim zdaniem świat będzie zmierzał w kierunku cloud i przeglądarka będzie podstawowym softem. Istotny jest też JIT dla JS, z tego co wiem OWB takowego nie ma To jest istotniejsze niż następne języki programowania.
Masz rację. Przeglądarka to faktycznie podstawa. Był już moment w którym na ami-systemach po prostu nie dało się przeglądać sieci. IBrowse, Voyager, AWeb już zupełnie się nie nadawały do chodzenia po stronach. Potem smaku narobił Sputnik ale niestety wszyscy wiemy jak skończył. No ale na szczęście powstało OWB, które jak na warunki amigowe jest rewelacyjne (przynajmniej wersja dla MorphOS-a, innych nie używałem). Życzyłbym sobie żebyśmy w każdej dziedzinie mieli program na poziomie OWB. Byłoby absolutnie rewelacyjnie. Co oczywiście nie znaczy, że OWB nie powinno się nadal rozwijać. No ale o to nie ma się co na razie martiwć, bo się rozwija i to naprawdę sensownie.
Ostatnia edycja: 14.12.10 17:30:19
GoldEd nie korzysta z MUI, a ja jestem fanem MUI
Kumam co masz na myśli i w pełni popieram. Ja też uwielbiam MUI. Dla mnie wszystko mogłoby być pod MUI. Cały świat mógłby być pod MUI. :) Dawno temu jak kupiłem kartę graficzną do klasycznej Amigi marzyłem, że byłbym w raju gdyby mój system przyjął MUI jako domyślny GUI i gdyby MUI się trochę rozwinął, oderwał się od tych 8 kolorów MagicWB i trochę uporządkował. Dosłownie wyobrażałem sobie to co dzisiaj jest pod MOSem (no, może trochę mniej sobie wyobrażałem). Nigdy nie przypuszczałem, że te marzenia się spełnią. :)
MaaG^dA:
Z tego co mi wiadomo na mosa dostępne będzie inne rozwiązanie które pozwoli zapomnieć o cubic/morphed... więc jak najbardziej idziemy w kierunku mui.
Powinienem się zmartwić, bo CubicIDE za którego zapłaciłem stanie się bezużyteczny. Ale nie! IDE napisane od początku pod MUI i specjalnie dla MorphOS to naprawdę świetna wiadomość. Już cieszę się jak dziecko. :)
A można więcej informacji? Maczasz w tym swoje zdolne palce?
Sventevith:
Głównym programem w obecnych czasach jest przeglądarka WWW. Moim zdaniem świat będzie zmierzał w kierunku cloud i przeglądarka będzie podstawowym softem. Istotny jest też JIT dla JS, z tego co wiem OWB takowego nie ma To jest istotniejsze niż następne języki programowania.
Masz rację. Przeglądarka to faktycznie podstawa. Był już moment w którym na ami-systemach po prostu nie dało się przeglądać sieci. IBrowse, Voyager, AWeb już zupełnie się nie nadawały do chodzenia po stronach. Potem smaku narobił Sputnik ale niestety wszyscy wiemy jak skończył. No ale na szczęście powstało OWB, które jak na warunki amigowe jest rewelacyjne (przynajmniej wersja dla MorphOS-a, innych nie używałem). Życzyłbym sobie żebyśmy w każdej dziedzinie mieli program na poziomie OWB. Byłoby absolutnie rewelacyjnie. Co oczywiście nie znaczy, że OWB nie powinno się nadal rozwijać. No ale o to nie ma się co na razie martiwć, bo się rozwija i to naprawdę sensownie.
Ostatnia edycja: 14.12.10 17:30:19
15.12.2010 12:12
[#19]
Re: Lua w nowym wcieleniu
Brawo! O wersje OpenSource nie prosze :)
PS. Dlugo sie trzymalem z daleka od Lua, a tu nagle niespodzianka - to glowny sinlik spryptowy w mikrokernelu L4 :)
PS. Dlugo sie trzymalem z daleka od Lua, a tu nagle niespodzianka - to glowny sinlik spryptowy w mikrokernelu L4 :)
15.12.2010 14:15
[#22]
Re: Lua w nowym wcieleniu
@szuler, post #21
Hehehe. To prawda. Świetnie byłoby gdyby odpowiednik takiego ARexxa był na wszystkich urządzeniach. Tak żeby można było sobie programować dosłownie wszystko i żeby urządzenia mogły się ze sobą komunikować. Jak się zastanowić jak można połączyć np. samochód w garażu z zegarkiem, komputerem w pokoju, czajnikiem w kuchni, ogrzewaniem, mikrofalówką i oświetleniem to wychodzą tak niesamowite możliwości, że aż ciarki przechodzą po plecach. No ale pewnie nie dożyję takich czasów, bo nie ma szans żeby firmy z różnych branż dogadały się co do jednego standardu. W obrębie jednej dziedziny zawsze są wojny, a co dopiero między różnymi dziedzinami. No chyba żeby zrobić sobie taki inteligentny dom na własną rękę. To oczywiście jest do zrobienia ale nie bardzo jestem przekonany do tego czy jest sens. :) Strasznie dużo roboty byłoby z elementami wykonawczymi (co ma otworzyć lodówkę? siłownik? jaki?).
15.12.2010 15:19
[#24]
Re: Lua w nowym wcieleniu
@ede, post #23
A to inna historia. W fazie planów i marzeń to wszystko fajnie "działa". Ale jak dojdzie do tego praktyka, korporacje, pieniądze, czyjeś interesy. Jak zaczną to pisać firmy zatrudniające programistów, którzy robią to tylko dla pieniędzy to piękna wizja by się skończyła. Wszystko by się sypało, krzaczyło. Byłoby pewnie więcej problemów niż radochy. No więc ok... już sam sobie rano zaświecę światło w łazience i włączę czajnik w kuchni. Trudno... ;)
15.12.2010 21:11
[#25]
Re: Lua w nowym wcieleniu
@MDW, post #22
Strasznie dużo roboty byłoby z elementami wykonawczymi (co ma otworzyć lodówkę? siłownik? jaki?).
To już jest - dostępne są elementy automatyki "domowej" sterowanej np. z poziomu przeglądarki. Rozszczelnienie okien (sprzęt realizujący uchył w oknach), włączanie urządzeń, świateł, sterowanie prądem, etc. - często mają wbudowany serwer www z możliwością sterowania nawet za pomocą WAP.
To już jest - dostępne są elementy automatyki "domowej" sterowanej np. z poziomu przeglądarki. Rozszczelnienie okien (sprzęt realizujący uchył w oknach), włączanie urządzeń, świateł, sterowanie prądem, etc. - często mają wbudowany serwer www z możliwością sterowania nawet za pomocą WAP.