Zdar!
Me uz dlouho pali obecna odpoved na otazku proc vlastne z C voalt luu... Ok.. kdyz volam z lua C tak mi asi chybela nekjak funkce potrebujici nativni reseni. Ale obracene?
Vim kdy se to obvykle pouziva, ale stejne. proc to? A otazka od
D.A.Tiger to uplne nadhodila - proc to? Co je tam v lue ze to nemohlo byt cley v C? A kdyz uz je tam kus v lue, proc ne cley v lue?
Nejsem nejkym ohnivym zastancem jendojazycnych projektuu, to ani omylem. Ale pouzivani luy me fakt celkem zarazi....
No predstav si treba herni engine (ja nevim, WoWko napriklad), kterej je v C nebo C++, proste v nejakem dost nizkourovnoven jazyce. A ted potrebujes bud urychlit vyvoj popr. dat uzivatelum k dispozici moznost tvorby pluginu. C nebo C++ je z mnoha ohledu blbost - nebezpecne (predavani pointeru, vubec sprava pameti), slozite, pomaly vyvoj, kazdou blbost musis opsat deseti radky kodu atd. Tady je vysokourovnovy skriptovaci jazyk idealni.
A co zvolit?
1 - Python? - hmm, battery included, obrovsky runtime, pomaly, navic GIL
2 - Perl? - ztracis jednoduchost
3 - TCL? - dtto
4 - JavaScript? - no proc ne, i kdyz ja osobne bych se z toho zblil :)
5 - Lua? - semanticky odpovida skoro Pythonu, VM ma snad jen 50 kB, dostatecne rychly, Lua<->C bezpecne, tak co resit...
jeste Re: "Co je tam v lue ze to nemohlo byt cely v C?"
no Luu muzes chapat i jako DSL pro veci, ktery bys v cecku psal sto roku, napriklad i operace nad retezci. On i celej BASH je vlastne z toho druheho pohledu zbytecnej, vsak namisto "cp" si to zkopirovani souboru muzes napsat v cecku, ale to tedy good luck :)
Trošku OT, ale když si tak čtu http://www.root.cz/zpravicky/zavazna-chyba-ve-firefoxu-umoznovala-odcizeni-dat/ tak si říkám, jak je dobré, že vlastně embedded Lua neumí "import" jakýchkoli modulů přímo ze skriptů. Tím si nemyslím, že by to tak původně bylo myšleno (sandboxing udělaný správně, tj. ne zakazováním, ale explicitním povolováním), ale nakonec to má svá pozitiva a sociální jistoty :-)
Mas pravdu, v drtive vetsine pripadu tomu tak je.
V projektu ve kterem jsem se toto chtel, jde o "jednoduchou konzoly" pro lua skripty ( http://www.imagehosting.cz/?v=lcons.png ). Vlastne jim poskytuje GUI okno, nekolik typu dialogu( zatim jen inputbox a messagebox; casem file/dirselector, progressbox, imageselector, atd...) a redefinje funkci print( ), tak, aby vystup byl formatovan a zobrazen do textboxu teto aplikace. A nejake dodatecne nastroje, uz ale jen v ramci aplikace a rizeni prubehu skryptu.
Aplikaci pouzivam v nekolika pripadech. Kdyz chci odladit skript, otestovat nejaky algoritmus a nakonec jako GUI ramec pro vlastni utilitky :) Vzhledem k tomu, ze skripty (pro zatim bezi vzdy jen jeden v jedne instanci aplikace), ktere maji byt spusteny si zadavam ja sam. Z drtive vetsiny je i pisu (a nebo je mam alespon zkontrolovane), takze je povazuji za velmi duveryhodne a jedine riziko je moje vlastni chyba... ;)
Bohuzel nemuzu v teto konzoly spoustet vsechny skripty, protoze lua me vykopne s externimi moduly. Vubec by mi nevadilo to resit (napr.) tim zpusobem, ze by se treba do adresare se skriptem vkladal nejaky (napr. xml) soubor se seznamem pouzitych ext. modulu. A jeste je muset povolit pri prvnim spusteni skriptu.
Ale proste nemohu prijit na zpusob jak (vubec) moduly zavadet....
Pod carou: HA! Zrada! Odkdy je upload v ImageShack plne placeny? Asi budu rusit dalsi ucet :-D
[...] Me uz dlouho pali obecna odpoved na otazku proc vlastne z C voalt luu [...]
my pouzivame kombinaci C + Perl (coz je ten samy princip) jenom s tim, ze knihovna perlu je bohuzel radove vetsi nez lua. Mame stovky malickych modulu v perlu, ktere bychom radi vyvolali z C, kdyz je to potreba (ucetnicke zaokrouhlovani, jiz zminene specialni stringove operace a zejmena specialni aplikacni funkce jako identifikacni barcode na zasilkach a jine).
Nevim jak je to u lua (a jinych interpretacnich jazyku), ale v perlu to ma ten hacek, ze ty moduly musi byt 100% 'lokalni', nesmi tam byt nic, co by si vlozeny interpreter mohl pro pristi volani zapamatovat (typicky globalni promenne v perlu). Jakmile to neni takhle osetrene, tak nasleduji tezka prekvapka. Zde vidim jakysi 'paradigma' rozpor v tom, ze v interpretru si neco 'narychlo' spichnu a je to urceno pro jedno 'volani', zatimco, jestli ze chci pouzivat moduly z C tak k psani tech scriptu musim pristoupit uplne jinak.
V Lua je to tak, ze si vytvoris strukturu reprezentujici stav virtualniho stroje Luy. V prikladech je to promenna L, ukazatel na tuto strukturu se predava do vsech funkci a tudiz si skript vsechno "pamatuje". Dokonce muzes mit vic stavu a tim padem i vic navzajem izolovanych virtualnich stroju.
Prave tato jednoduchost vazby C/Lua asi vede k jeji oblibenosti jako embedded jazyka (a FFI to jeste vysperkovava :)
Zdar Jirko,
to je problém hlavně komerčních projektů, například her, kde je jádro v céčku a Lua tam je pro uživatelské skripty, logiku AI atd. atd. Mě osobně vyhovuje přesně opačné řešení (které píšeš), tj. naprgat hlavní aplikaci přímo v Lua, použít LuaJIT a dosáhnout tak velmi uspokojivého výkonu a přes FFI volat nativní knihovny (OpenGL, SDL, glibc atd. atd.).
Ahoj.
Budu-li mluvit za sebe, tak k tomu mam nekolik duvodu
1. Jako uzivatel mam rad aplikace, ktere muzu v ramci urcitych moznosti libovolne rozsirit, aniz bych musel zasahovat do zdrojoveho kodu samotneho projektu. Modularizace, kdy mam nejake hlavni nezavisle jadro, a k tomu moznost dopsat dalsi funkce v modulech a tim si jej prizpusobit svym potrebam je to, co hodne sam ocenuji na jinych projektech. Nejlepsi je pokud je mozno takove pridavne moduly pomerne jednoduse sdilet. Napr. v pripade meho zpravce her, takto modulariziji treba spusoby jakym jsou jednotlive herni projekty spousteny, takze pro pripadneho uzivatele je vicemene jedno, zda-li je hra urcena pro DOS, Widle, popr je napsana v engine LOVE, nebo je vytvorena formou datoveho souboru WAD, Vzdy s ni pracuje vicemene stejne. A pokud to neumi, je pomerne jednoduche dalsi moznosti spousteni kdykoliv dodat.
Takovy vedlejsi efekt, je ze odpadne - pro mnohe uzivatele otravne - psani spoustecich skriptu, protoze zrovna tento modul je univerzalne supluje ( ve vetsine pripadu).
Dalsim efektem je, ze si danou funkcnost muze pridat vicemene kazdy kdo o to ma zajem, bez zdlouhaveho vyvoje, testovani a ladeni, jake je v C++ obvykle.
2. Jako programatorovy mi to hodne ulehcuje v nekterych smerech praci, protoze pomoci naskriptovane funkcionality muzu pomerne rychle a pruzne reagovat na zmeny v prostredi, ve kterem aplikace pusobi. A to zrovna v Linuxu je docela ozehava zalezitost. Jen si vemte napr. ty ciraty kolem blokovych zarizeni, ktere dneska (prozatim) konci udisks. A co zitra? Nemluve o rozdilnostech v ruznych prostredich a samotnych linuxovych distrech (treba rpm vs. deb based distra).
Jako programator muzu takto pozdovanou funkcionalitu velmi rychle priohnout, nebo vytvorit od zacatku. Tvorba a odladovani skryptu je dle meho nazoru (a zkusennosti) mnohem rychlejsi nez vytvareni doplnujicich binarnich modulu - toho jsem se dotkl jiz vyse.
Coz ale neznamena, ze chci si kompletne celou aplikaci naskryptovat. V skryptovacim jazyce tvorim prevazne moduly, ktere nejakym zpusobem doplnuji, ci upravuji kompletni funkcionalitu aplikace.
3. Proc prave Lua? Proste mi sedla a vyhovuje mi. Navic je trivialne jednoducha (pokud si dobre pamatuji, Pavel nekde ve svych clancich pise, ze byla zamyslena jako jednoduchy jazyk pro inzenyry, kteri maji minimalni programatorske znalosti, takze podle meho nazoru je dobre pouzitelna i pro hmmm... trochu vice premyslejici verejnost ). To ze vestaveny interpret je pomerne maly, rychly a snadno se integruje do aplikace je nesporna vyhoda asi neni moc potreba psat.
A ted se prosim zeptam zase ja: O co vlastne jde? Copak neni jedno, jestli aplikace preda data ke spracovani binarnimu modulu v C++, nebo skryptu? Neni preci jedno jestli zaklad aplikace skryptujes a pripojojues do nej binarni knihovny, nebo volis opacnou (jinou) strtegi tvorby takovych aplikaci? Neni to snad VZDY o osobnich preferencich daneho vyvojare, potrebach projektu, pripadne pozadavcich na projekt?
"Pavel nekde ve svych clancich pise, ze byla zamyslena jako jednoduchy jazyk pro inzenyry, kteri maji minimalni programatorske znalosti" - to jsem skutečně psal a navíc teď mám i příklad, jak v Lue dokážou prakticky bez problémů psát i lidé, kteří nikdy předtím neprogramovali (jen si hráli se Squeakem).
Například to, co někomu z IT na Lue vadí, třeba indexování prvků v polích od jedničky, člověk "zvenku" spíš oceňuje. Stejně tak lidské porovnávání řetězců (ehm String.equals ehm). Navíc celý jazyk i s knihovnami je popsán na cheatsheetu se sedmi (?) stranami, přičemž samotná syntaxe a sémantika je popsána na necelé jedné A4. Asi největší problémy způsobují "podivné" regexpy :-)
Jj, to je pravda - Lua je opravdu v nekterych smerech pro cloveka myslet v (treba) C/C++ trochu sranda :-D
Na indexovani od jednicky jsem si zvykl pomerne rychle, i kdyz jsem s tim ze zacatku trochu bojoval, ale dvoutvarnost lua poly me delala dlouuuuho celkem problem (seznamy vs asociativni pole) Tvori se stejne, tvari se stejne, ale v nekterych pripadech se s nimi pracuje jinym zpusobem. To me dost matlo.
Jiny takovy priklad, kdy hraly roly navyky z jineho jazyka u me mam zdokumentovany dokonce tady na foru, jednalo se o ekvivalent perlovske funkce split( ), ktera deli retezec na pole subretezcu podle vybraneho znaku. :-( Za normalnich okolnosti, bych pouzil nejeka vyhledavani (separacniho) znaku a pocitani pocatku a koncu subretezcu podle pozice techto znaku. V moji prvni implementaci s pouzitim string.find( ) to fungovalo... divne. Az me nektery z ctenaru upozornil na string.gsub( ). Uprime, do te doby by me nenapdlo, ze se cela funkce da napsat takto trivialne:
function split( s, sep ) local t = { } local lt_str = "[^" .. sep .. "]+" for str in string.gmatch( s, lt_str ) do table.insert( t, #t + 1, str ) end return t end
Funguje skvele! :-D
Ale proste vsechny zacatky jsou takove. Dodneska mi dela trochu problemy, kdyz neco delsi dobu pisi v Lue a potom prejdu do C++ tak syntaxni rozdily u stejnych prikazu, hlavne zavorky u prikazu jako je if, for a podobne. Opacne se mi to stava taky, navic, nedavno jsem mel tendenci nekde v Lue v cyklu pouzivat directivu continue :)
diky za vycerpavajici odpovedi vsem vise odpovidajicim.
Ten bash je dobry prikald. V lastne se to cele vratilo do jendoho z programatorskych oriskuu - definovat dobre api. pripadne mist akd eto bude chtit aplikaci dynamicky ohhybat. Chapni vlozeni skriptvoani do toh nuti. Hezke.