MorphOS.pl – Polska strona użytkowników MorphOS-a
MorphOS.pl – Polska strona użytkowników MorphOS-a

BRexx 2.1.98 sierpnia 2011

Po porcie interpretera języka Rexx Regina, który rozwija się zwłaszcza pod AROS-em, mamy kolejny interpreter, mianowicie BRexx. Niestety podobnie jak w przypadku Reginy (a nawet bardziej), BRexx nie jest w stanie zastąpić oryginalnego ARexxa, przede wszystkim dlatego, że nie działa w nim komenda ADDRESS, automatycznie przekierowująca wszystkie nierozpoznane komendy do wybranego portu ARexxa w programie zewnętrznym, brakuje też serwera RexxMast. Wziąwszy to pod uwagę, mamy do czynienia z kolejnym ćwiczeniem z szybkiego portowania wykonanym przez Stefana Haubenthala. BRexxa można pobrać z MorphOS Files.

Zamieszczone przez: admin, 8 komentarzy

Komentarze:

  • Avatarkrashan

    Trochę to wygląda na kontrofensywę przeciw Lua . Ja jednak szykuję wersję 0.6 w której będzie kilka kolejnych fajnych rzeczy, np. monitorowanie wykorzystania pamięci przez skrypt w Lua Exploradorze, przeglądanie tablic w tymże, przekazywanie argumentów do skryptu z linii komend i parę innych drobiazgów.

  • AvatarEnder
    Trochę to wygląda na kontrofensywę przeciw Lua . Ja jednak szykuję wersję 0.6 w której będzie kilka kolejnych fajnych rzeczy, np. monitorowanie wykorzystania pamięci przez skrypt w Lua Exploradorze, przeglądanie tablic w tymże, przekazywanie argumentów do skryptu z linii komend i parę innych drobiazgów.

    Mimo że na razie nie używam żadnego to trzymam kciuki (szczególnie za nasz polski projekt). Może naiwne pytanie, ale czy tworząc Lua wybiegasz tak daleko w przyszłość i dopuszczasz możliwość (planujesz), by w przyszłości zastąpił ARexxa?

  • Avatarkrashan
    czy tworząc Lua wybiegasz tak daleko w przyszłość i dopuszczasz możliwość (planujesz), by w przyszłości zastąpił ARexxa?

    Najpierw w kwestii formalnej, co do słowa „tworząc”. Faktem jest, że MorphOS-owy port Lua to daleko posunięta modyfikacja oryginału, oddajmy jednak honor twórcom tego świetnego języka – to mimo wszystko tylko port. Przechodząc natomiast do ARexxa – w 90% przypadków Lua jest go w stanie zastąpić już w obecnej wersji 0.5, ponieważ ma możliwość wysyłania komend do portów ARexxa programów i odbierania wyników tych komend (coś, czego BRexx nie potrafi). W Lua można już teraz pisać np. skrypty rysujące cokolwiek w TVPaincie, czy używające portów ARexxa innych aplikacji. Piszę o tym dość obszerny artykuł do pisma PPA #6, później artykuł ten znajdzie się również na naszym portalu. W przyszłości widzę 3 zastosowania Lua: po pierwsze jako język skryptowy, zamiennik ARexxa. Po drugie jako język używany wewnątrz większych programów do różnych celów. Po trzecie wreszcie planuję wyposażyć Lua w bezpośredni dostęp do MUI, co pozwoli w Lua pisać kompletne aplikacje i da rozsądną alternatywę dla koszmarków tworzonych w Hollywood.

  • AvatarEnder
    Najpierw w kwestii formalnej, co do słowa „tworząc”. Faktem jest, że MorphOS-owy port Lua to daleko posunięta modyfikacja oryginału, oddajmy jednak honor twórcom tego świetnego języka – to mimo wszystko tylko port.

    Przyznam się bez bicia, że o tym nie wiedziałem i z automatu przyjąłem, że jest to projekt autorski. Przepraszam w takim razie autorów za moje gapiostwo.

    Co do reszty to zapowiada się ciekawie, powodzenia.

  • Avatarkrashan
    z automatu przyjąłem, że jest to projekt autorski.

    Tworzenie własnego języka, istniejącego tylko pod MorphOS-em, nie miałoby moim zdaniem sensu. Lua jest językiem wieloplatformowym, a przez to całkiem popularnym i można znaleźć w sieci dziesiątki tutoriali, fora dyskusyjne, przykłady, biblioteki i tak dalej. Co więcej, jest ciekawy projekt LuaJIT, czyli dynamiczny kompilator Lua, który również obsługuje procesory PowerPC (rdzeń e500v2, co oznacza, że praktycznie bez bólu powinien pójść na naszych e600 w Pegasosach czy Makach wszelakich). Mam na ten projekt oko, bo po jego zastosowaniu Lua zaczyna się zbliżać prędkością do języków kompilowanych i naprawdę może się z niej zrobić mocny język do pisania aplikacji. Na razie jednak skupiam się na rzeczach bardziej w Lua potrzebnych.

  • Avatarzbysiuk
    Co więcej, jest ciekawy projekt LuaJIT, czyli dynamiczny kompilator Lua, który również obsługuje procesory PowerPC (rdzeń e500v2, co oznacza, że praktycznie bez bólu powinien pójść na naszych e600 w Pegasosach czy Makach wszelakich). Mam na ten projekt oko, bo po jego zastosowaniu Lua zaczyna się zbliżać prędkością do języków kompilowanych i naprawdę może się z niej zrobić mocny język do pisania aplikacji. Na razie jednak skupiam się na rzeczach bardziej w Lua potrzebnych.

    Z tego co czytalem i przegladalem, jest to rozbudowany projekt. Nic natomiast nie wiedzialem o JITcie. Mam jednak pytanie, czym sie rozni obecna kompilacja skryptow od przyszlosciowej, opartej na LuaJIT? Kompilacja, przeciez odbywa sie "w locie", wiec jaka jest roznica? I jeszcze jedno czy kompilacja miedzyplatformowa bibliotek lua to duze wyzwanie?

  • Avatarkrashan
    Z tego co czytalem i przegladalem, jest to rozbudowany projekt. Nic natomiast nie wiedzialem o JITcie. Mam jednak pytanie, czym sie rozni obecna kompilacja skryptow od przyszlosciowej, opartej na LuaJIT?

    Obecnie nie zachodzi de facto kompilacja skryptów. Aktualnie przy ładowaniu skryptu kod źródłowy tłumaczony jest na rozkazy maszyny wirtualnej Lua i tak zapamiętywany. W czasie wykonywania skryptu, każda operacja maszyny wirtualnej powoduje wykonanie szeregu rozkazów procesora, powiedzmy kilkunastu, czy kilkudziesięciu. Teraz wyobraźmy sobie że mamy pętlę wykonującą się sto razy. Obecny interpreter przy każdym nawrocie będzie tłumaczył zawartość tej pętli z kodu maszyny wirtualnej, rozkaz po rozkazie na sekwencje rozkazów maszynowych procesora i te sekwencje wykonywał. LuaJIT może wnętrze pętli raz przetłumaczyć na blok kodu maszynowego procesora i zapamiętać. Wtedy przy każdym nawrocie nie będzie zachodziła interpretacja – procesor będzie dostawał gotowy blok instrukcji do wykonania i działał z taką samą prędkością, jakby program został napisany np. w C i skompilowany.

    Jest tu pełna analogia do UAE. Tam „maszyną wirtualną” jest emulowany procesor M68k. Zwykłe UAE bierze jeden rozkaz emulowanego M68k i wykonuje go, co sprowadza się do wykonania kilkunastu, czy kilkudziesięciu rozkazów PPC. Potem bierze następny rozkaz motorolki… i tak dalej. Natomiast WinUAE z JIT-em bloki, których wykonywanie się powtarza, tłumaczy w całości na kod maszynowy x86 raz, a potem go tylko wykonuje. Jaką to daje różnicę wydajności – wiadomo.

    I jeszcze jedno czy kompilacja miedzyplatformowa bibliotek lua to duze wyzwanie?

    To zależy czy są to biblioteki kompilowane (pisane w C/C++) czy pisane w Lua. Trudność portowania tych pierwszych zależy od przenośności kodu C. Jeżeli używają standardów uniksowych to o ile libnix wystarczy do ich skompilowania, można zawalczyć. Te drugie natomiast powinny działać po drobnych poprawkach uwzględniających np. fakt, że morphosowa Lua nie ładuje modułów standardowych automatycznie, albo faktu, że używa morphosowych ścieżek do plików.

  • Avatarzbysiuk
    Te drugie natomiast powinny działać po drobnych poprawkach uwzględniających np. fakt, że morphosowa Lua nie ładuje modułów standardowych automatycznie, albo faktu, że używa morphosowych ścieżek do plików.

    "Tych drugich" troche jest, to pocieszające, bo nawet takie dyletant jak ja moze sie temu przygladnać i coś tam przeportować z odrobiną szczęścia.
    W przypadku JITa wyjaśnileś mi przy okazji kilka zasadniczych rzeczy o budowie takich kompilatorów – dzięki. Coraz bardziej mi sie ta Lua podoba – przykladów jest mnogość, to mnie najbardziej cieszy.

  • Dodaj komentarz

    Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.