Názory k článku
Programovací jazyk Lua vestavěný do aplikací

1) ... můj problém to ještě neřeší. Já bych potřeboval vytvořit sadu funkcí ve skriptu, které bych volal v rámci C++ kódu. Umí to Lua (nebo to jen zase nogómu)?

2) Otázkou je taky, zda takové volání externího bitekódu / parsování skriptu neužírá výkon. Dejme tomu, že mám nějaké herní objekty (např. sprity), a všechny obsahují funkci update() v jejímž rámci je prováděna aktualizace hodnot struktůry daného objektu tak, aby se oběkt choval požadovaným způsobem. Abych nemusel při každém požadavku nějaké změny v chování daných oběktů zasahovat do zdrojáku aplikace, vyřeším to například tímto způsobem (popisovaným v článku). Je logické že např. u her bude takováto metoda u podobných oběktu volána dost často a velká režie na volání externího kódu by mohla být docela problém....

ad 1. Vzdyt presne k tomu je lua urcena :-)
ad 2. Vzhledem k tomu, ze lua se pouziva na skriptovani v mnoha komercnich hrach, napri i WoW, tak cena za prepina kontextu nebude dramaticky vysoka.

add 1) No, máte pravdu. nějak mi to nedocvaklo :)
add 2) Nějak ve mě hlodají pochybnosti, nebo se mi to spíš moc nechce věřit. Ale - pravda - nic mi nebrání si to sám vyzkoušet.


Dík. :)

jojo...

CLUAConsole:SetCurrentXP("89000")

1) pokud dokážeš získat ukazatel na tu funkci, tak není problém. Ten by nastal jen u nestatických metod, ty mají v hlavičce jeden parametr navíc, navíc mám dojem, že na tyto funkce nejde získat ukazatel. Asi Ti pomůže http://csl.sublevel3.org/lua/, ty příklady samozřejmě chodí i ve VC, BCC apod. Pokud by nevyhovoval "céčkový základ" Lua, lze použít různé C++ wrappery, například http://www.steve.org.uk/Software/lua-c++/. Ještě se o tom zmíním příště.

2) pokud se zdroják nejdříve přeloží do bajtkódu, odpadá část pro jeho parsing a překlad, nehledě na to, že bajtkód je menší a načítá se rychleji (i když u zdrojáků < 10 mega se to asi nepozná :-). Volání Lua2c nebo Lua2c++ něco stojí (nepoužívá se standardní stack frame), ale většinou to není nijak hrozné, záleží samozřejmě na způsobu použití.

1) Dík přesně něco takovýho potřebuji, hned to prozkoumám.
2) " ...záleží samozřejmě na způsobu použití." Hmm... no právě. :D O něčem podobném uvažuji už dlouho, ale právě obavy z vyšších režii a následné zpomalení aplikace mi v tom zatím brání. Zkusím - uvidím.

Díky moc.

I na nestatickou metodu lze ziskat ukazatel pomerne bez problemu, a pote jej i volat, jediny co, tak by mela byt pokud mozno nevirtualni :) (ale i to jde obejit, struktura vtable je znama)

Je lépe koncipovat skriptování tak, aby probíhalo na vyšší úrovni a výkonnostně náročné operace byly prováděny v nativním kódu, LUA může řešit občas něco - nějaké změny stavu, změny logiky chování, ale asi bych ji nenasadil každý frame na každý objekt

uz v nekolika po soube jdoucich pokracovanich se jednim dechem rika, ze implementace lua do jmenovanych jazyku je jednoducha.
S tim nemohu souhlasit, jednoduche se mi to zda jen v C.
Napr. projekt fxlua - bindigs lua pro fox-toolkit -> to nevypada tak jednoduse.

To bude spis problemem toho samotneho bindingu ne? ted se divam, ze je to ve verzi 0.9, ani to nema domaci stranku, takze z ceho lze predpokladat, ze ten binding delal nekdo alespon trosku pri smyslech? Napriklad takove wxLua je naopak docela jednoduche (v porovnani s pure C++ resenim), kdyz si clovek zvykne na wx-like veci, jako je propojovani udalosti s jejich cili (handlery).

Jo, teď jsem se na to taky díval. Ale podle mě se Fox na takovýhle věci zrovna dvakrát moc nehodí. Už jen třeba kvůli proměnlivému počtu a typu parametrů konstruktorů jednotlivých objektů, nutnosti udržovat specialní tabulku pro mapování událostí, a pod. Nehledě na to, že většina takových "transportů" Fox Toolkitu do jiných jazyků vůbec nebere v potaz fakt, že stěžejní vlastnosti na níž staví FoxToolkit je C++ polymorfizmuz, a vznikne z toho většinou nepouživatelný nebo těžkopádný zkamenělý paskvil... Podobně jak tomu je u portu Foxky do TCL. Jedním slovem děs :(

ja se priznam, ze nejsem informatik, takze se na podobne problemy dokazu divat jen prakticky z povzdali. Zatim jsem pochytil nasledujici:
- kombinace skriptovaci jazyk + C jde jednoduseji nez skriptovaci jazyk + C++. To jsem vycetl napr. u swigu - tam myslim rikaji v manualu, co jde jednoduse a co dokonce vubec nejde. Myslim, ze tam psali, ze to je prave tou C++

- v diskuzich ( a ze uz jich bylo na netu miliony) o tom, jestli ma byt nejaka GUI v C nebo C++ se najde vzdy argument, ze C implementace my vyhodu v jednodussim spojeni s nejakym skriptovacim jazykem (typicke srovnani gtk/Qt)

Dovedu si predstavit, ze kdyz mam nejaky hotovy toolkit, ktery ma nejake mechanismy (napr. to mapovani udalosti), tak ze se musim poprat i s toto problematikou - ale ve srovnani C/C++ vychazim z toho, ze i C implementace nejakeho toolkitu by nejak mapovala udalosti - te praci se tedy nevyhnu.

Ale jak napsal i vas predrecnik, ten nazor akceptuji, ze ta slozitost u te fxlua me zmatla tim smerem, ze jsem ji kompletne pricital jen te C++.

Rad bych, kdyby to mohl nekdo fundovane vysvetlit.

Někde jsem četl, že existují tři věci které mohou zrujnovat muže : ženy, hazard a bezmezná důvěra odborníkům :) Proto nevěřte žádným podobným "fundovaným" řečem - mě osobně ještě v žádné diskuzi (bez ohledu na to, která jazyky byly srovnávány) nikdo nepodal přesvědčivý důkaz o tom, že by upřednostňování apriory nějakého konkrétního jazyku přinášelo nějaké velké výhody. Kolik programátárů tolik pohledu na danou věc a žádné oběktivní hledisko v tomto směru neexistuje. Pokud Vám vyhovuje čisté C, tak v něm pracujte a vzdělávejte se v něm. "Fundovanější" radu neznám a velmi pochybuji o tom, že Vám ji někdo dá...

1) Nevěřím tomu, že by řešení C a script bylo výhodnější než C++ a script. Možná pouze z toho hlediska, že pokud se budete snažit přenést takové řešení do prostředí C++, pravděpodobně to nebude tak obtížné jako v opačném případě. Přicházíte však o možnosti a abstrakce, které vám nabýzí C++ díky třídám a šablonám (nebo je musíte složitě nahrazovat - je-li to vůbec možné). Jinak si myslým, že obě řešení by měla být relativně rovnocenná - záleží na konkrétním projektu a programátorovy (programátorech). v případě Swinngu nevím, ale tam možná omezení můžou být daná Javou.

2) Viz úvod a bod 1. Jinak porovnávání Qt s Gtk je hloupost (ale oblíbená, to je fakt). To už možná QT s Fox Toolkitem.

Mam dojem, ze ta prvni veta je ze skvele knizky "Programatorske poklesky" :-)

Nooo, už asi vím kde jsem to četl. :-). Ta knížka je opravdu úžasná. To by měla být povinná literatůra pro každého začínajícího programátora. Jen škoda, že vzhledem k jejímu stáří se už tak špatně zhání...

nj. uz ji myslim nepretiskli :-( Dnes leti spise tituly typu "Word za 3 dny" atd. :-)

Zrovna polymorfismus C++ bych jako problem nevidel. Napr. c++ wrapper vygenerovany swig-em zavola metodu a vtable se postara, aby byla zavolana spravna "verze".

Vetsi problem jsou treba sablony nebo pretizene metody, ktere nejdou rozlisit pri volani ze skriptovaciho jazyka (napr. se lisi typem argumentu, ktery je mapovan ve skriptovacim jazyku na tentyz typ).

Fox toolkit neznam, ale napr. pro Qt je navic potreba se vyporadat s kodem vygenerovanym pres meta-object compiler, ktery spolu s preprocesorem resi prepojovani signalu a slotu ("hack", ktery pridava reflexi, ale psat wrapper bych pro to nechtel ;-))

Nějak tak jsem to myslel - snažil jsem se to říci co nejobecněji (a na šablony jsem absolutně zapoměl - pravda), jsem prostě lenoch :D

Fox Toolkit používá trochu jiný systém pro zpětná volání - zprávy (QT používá systém slot-signal). Jinak je to podobné. Místo rozvíjení potřebných maker v oběktech (i mimo ně) externím programem, je u Foxky využit preprocesor.

Ad druhy odstavec - toto problem zde opravdu je, na druhou stranu vsak pretizena metoda, ktera pro kazdy typ funguje jinak, je obecne cesta do velmi nepeknych mist :-) Napriklad slusne API by sice mohlo obsahovat metody (popripade konstruktory) metoda(char a), metoda(int a), metoda(long a), ale je dobrym zvykem, ze se ty metody chovaji v ramci moznosti stejne, tj. pri automatickem wrappingu Lua to C++ by melo byt jedno, ktera se zavola (pokud se metody chovaji ruzne, tak by napriklad chudak uzivatel tohoto API musel rozlisovat mezi metoda(42) a metoda(42L), coz je IMHO dosti error-prone).

Ja mel spis na mysli neco jako logMessage(const char*) a logMessage(const std::string&). Obe metody delaji to same, je jedno ktera konverze se pouzije. Zrovna v tomhle jednoduchem pripade vybere swig 'const char*' verzi.

Ve slozitejsich pripadech to nekdy neuhodne (misto toho zahlasi neco jako "don't know which overloaded method to use"), je potreba "dovysvetlit rucne".

lua_open() lze normalne zavolat, nebot je v hlavickovem souboru zadefinovana jako makro, ktere vola luaL_newstate. Volani lua_newstate() skutecne ma smysl pouze tehdy, kdyz potrebujeme pamet alokovat jinym zpusobem, nez to delaji klasicke libc funkce.

luaopen_* lze samozrejme nahradit luaL_openlibs(). To varovani je napsane proto, ze funkce s parametry se skutecne museji volat pres lua_call(), protoze zpusob ulozeni parametru na zasobniku je v tomto pripade odlisny od std. cecka - opacne poradi + je pridany pocet parametru.

V kazdem pripade ale mate pravdu v tom, ze propriste budu presne specifikovat verzi Lua (mezi 5.0.x a 5.1 jsou zmeny v API) a taktez budu pouzivat nejnovejsi API, tj. to z 5.1, aby zbytecne nedochazelo k rozporum napriklad pri cteni aktualni dokumentace. Diky za upozorneni!

Ano, to je pravda. U mě výpis "ar t /usr/lib/liblua50.a" vypadá pouze takto :
lapi.o
lcode.o
ldebug.o
ldo.o
ldump.o
lfunc.o
lgc.o
llex.o
lmem.o
lobject.o
lopcodes.o
lparser.o
lstate.o
lstring.o
ltable.o
ltests.o
ltm.o
lundump.o
lvm.o
lzio.o

Prohledl jsem zbezne jednotlive dily a i diskuze a skutecne jsem nenasel nic k debugu. Po konzultaci s google mam dojem, ze je tak trochu problem?

Vidim to spravne? Budete problematiku debugu probirat?

ze si ten debug musi event. napsat uzivatel sam nebo sahnout k non-free ldb. Doufam, ze se k tomu pan Tisnovsky vyjadri.

Stačí použít některý jiný Lua debugger, ne?

Zdravím,

těch debugerů je více, některé používají standardní debuging interface interpertru, jiné vyžadují úpravu zdrojáků před překladem.

z non-free je pěkný http://www.unknownworlds.com/decoda (debuger s GUI, vlastně celé IDE, ale jak říkám, not-free, non-cost free)

potom je zde cmd. line debugger http://luaforge.net/projects/clidebugger/

nad kterym je postaven http://lua-users.org/wiki/SciteDebug

taktez lze pouzit http://www.keplerproject.org/remdebug/, ktery je mimochodem i soucasti LuaEclipse (ale pro mnoho programatoru to muze byt kanon na vrabce :-)

Osobne si ale myslim (ale je to dano tim, ze me aplikace v Lua maji max. par tisic radku, zadne slozitosti), ze nejjednodussi je primo vyuzit debug interface a pres nej si vytahat vsechny relevantni informace a ty logovat (pokud tedy neni zapotrebi interaktivni debuging, potom je lepsi sahnout po hotovem nastroji nebo si nad debug interfacem udelat nejake callbacky).

V podstate problem muze nastat v pripade, ze se ma soubezne ladit jak ceckovy kod, tak i Lua kod, aby prechod mezi obema castmi byl co nejjednodussi - teoreticky SciteDebug by to resit mohl, ale nemam ho vyzkouseny. Jinak

Zkus prejit na Lua 5.1. Sice mam dojem, ze ty funkce jsou i ve verzi 5.0, ale pro jistotu. Jinak by taky pomohl vypis archivu liblua50.a, tj. ktere objektove soubory obsahuje a co ony obsahuji za funkce. To se dela pomoci utility "ar".

Zaregistrované funkce se nedají volat z coroutin.

Pokud getsomething() je zaregistrovaná funkce vracející třeba 15, pak výše uvedený kód vydá něco jako

Nevíte někdo, jak získat z coroutiny hodnotu vrácenou zaregistrovanou C funkcí?