Názory k článku
Programovací jazyk Lua

Hmm, pokial viem tak v komercnych projektoch sam moze pouzit LGPL, ale ak by som v projekte pouzil nieco s GPL licenciou, moze to sice byt komercne, ale automaticky musim spristupnit kody, takze komercnost ostava len na poli podpory, alebo je to inak s GPL v komercnych projektoch?

Pouze pokud vas o to pozada nekdo, komu jste projekt distribuoval v binarni podobe.

Co kdyby dodatkem licencni smlouvy byla klauzule, ze kupujici nikdy nepozada o zdrojove kody? Bylo by to v souladu s GPL?

GNU/GPL nepovoluje přidávání restrikcí nad rámec licence. Čili toto by bylo jasné porušení GNU/GPL.

Nie je to celkom presné, ale v tomto prípade je to aj tak irelevantné. Lua je distribuovaná pod MIT licenciou ktorá je podstatne menej reštriktívna ako GPL.

Projekt pro vlastní potřebu těžko označit za komerční...

Takze ak mam nejaky komercny soft, a predam ho ako sluzbu, teba bude bezat na mnou prenajatych serveroch, tak neporusujem GPL licenciu z nemusim zverejnit kody celeho softu?

Lua 5 nie je šírená pod GPL. To by rozhodne jej rozšíreniu nepomohlo. Naštastie je to MIT licencia.

Že bych poprvé za svůj život sledoval nějaký seriál na rootu? ;-)

Hmm, dalsi alternativa propojeni dynamickeho skriptovani se statickym kodem. Uzitecna vlastnost rozsahlejsich aplikaci, ktere maji vyvojarum poskytnou moznost rychle konfigurace nebo prepsani casto se menicich useku programu podle pozadavku zakaznika bez rekompilace. Pro C++ bych sice dal prednost variacim kolem Qt a jejich Script engine, ale proc ne.. Pekny uvodnik, nechtel byste v dalsich dilech vice popsat syntaxi, semantiku a uvest prakticke ukazky jazyka? Ocenil bych mene barevnych obrazku od tematu a globalnimu nahrazeni "intepretr" za "interpret" bych se taky nebranil. :)

Když už, tak "interpreter". Ale stejně je to zbytečné. V češtině je zavedený pojem interpret, tak nechápu, proč zavádět nějakou obskurní terminologii.

Syntaxi se mi teda Lua vubec nelibi, proc tak hnusny komentare, ach jo. V tom by se mi opravdu nechtelo psat neco rozsahlejsiho. Jak je to s podporou knihoven a bindingu typu binding na gtk, nejakou grafickou knihovnu, praci se zvukem, xml, soap, xml-rpc, webovymi frameworky, mod_lua a podobne? Tedy to, co tohle a mnohem vic poskytuje Python. Kdyz jsem cetl prvni dil, tak jsem si prakticky porad rikal, jo, tohle umi python, na tohle je prave taky stavenej python, napriklad ten embeding a podobne. Nejak jsem si nepovsimnul jedine veci, co by umel oproti Pythonu navic, co umi noveho, aby stalo se vubec zabyvat dalsimi dily. Zatim se mi zda, ze nic noveho neprinasi. A jeste jedna vec, jak je na tom lua se jmennymi prostory?

http://lua-users.org/wiki/LuaVersusPython

luaGnome, mod_lua, lua Orbit, luaXML (a hafo dalsich, tato je purge Lua, ne binding na C/C++ knihovny) je toho dost. Je to v clanku myslim popsane, v cem je Lua pro nektere projekty lepsi (pokud si clovek odlozi ideologicke bryle) - maly memory footprint, interpretr do cca 100 kB (ano, u Pythonu existuje jeho orezana lite verze, to vsak neni Python), rychlejsi beh programu, rychlejsi JIT (x Psycho) atd. Python je samozrejme pekny jazyk (patri do stejne skupiny), mnohdy je rozdil jen v syntaxi.

fungujici korutiny a schopne prostredky pro paralelni programovani.. tady Python tezce pohori, yield totiz nestaci..

A videl jsi uz nekdy Stackless Python? A modul multiprocessing v "normalnim" Pythonu?

Paralelni jako stovky a tisice "procesu" s minimalni rezii. Kouknete se treba na erlang a kolik "procesu" obsluhuje na jabber.cz (co uzivatel to lightweight proces). A lua je na tom s rezii jeste lepe.

Stackless python je hezky, ale tezka vlakna nikdy nebudou tak rychla a levna. Vite co vykonu vas stoji klasicky context switch?

Tu posledni vetu jsem mel asi rozdelit.

Stackless python je hezky. (zel experimentalni a nevsiml jsem si, ze by ho moc firem pouzivalo, vyzaduje upraveny interpret)
Multiprocessing je to same, novinka v 2.6, tudiz experimentalni a neoverene.

a pak nam zbyva threading.. a tam plati moje vytka o vlaknech.

Lua tu uz par let je a v porovnani s ostatnimi jazyky byla nejvice prostredkove nenarocna co se korutin tykalo. Vysledky stackless pythonu a multiprocessing modulu neznam, ale klasicky pythoni yield mel extremne vysokou spotrebu pameti (desitky KB).

Krom toho jak se divam, multiprocessing jen obchazi problem se zamykanim interpretu tim, ze pouziva vice procesu, misto vice vlaken. Tudiz take prilis drahy context switch.

Klasicky python proste neni delany na vysoce paralelni ulohy.

Stackless mnoho firem jistě nepoužívá, zejména proto, že nemají potřebu. Erlang má můj respekt (funkcionálním jazykům fandím) a Lua má stoprocentně taky mnohé výhody. Chtěl jsem jenom poukázat na to, že Python v podobných situacích nemusí být úplně špatný nápad.

Já můžu uvést taky pěkný příklad: Hra Eve Online používá na serveru právě Stackless. Chtělo by to asi nějaký benchmark pro srovnání výkonu Lua, Erlangu, Stackless Pythonu apod...

Je toho docela dost, ne sice tolik, jako napriklad v CPAN, ale dostupne knihovny toho pokryvaji docela dost:

http://lua-users.org/wiki/LibrariesAndBindings

Ahoj, tento skriptovací jazyk jsem používal ve svém 3D enginu před několika lety (když jsem měl ještě čas na hraní v OpenGL) a dost mi vyhovovalo jeho jednoduché embedování do C++

napodobne :) teraz o Lua pisem diplomovku

kupte si Fallout 3

jedinou nevyhodu vidim jako v pripadech ostatnich podobnych jazyku v tom, ze chybi CPAN.

Docela dost zajimavych a uzitecnych veci se da najit na http://lua-users.org/wiki/LibrariesAndBindings, otazkou je, zda je to dostatecne "comprehensive" ve smyslu CPANu ;-)

Taky si kolikrát říkám, když přijdu do pekárny:
Kolik druhů pečiva budeme nakonec v tom pekárenském babylonu mít? Vždyť já vlastně potřebuju jen chleba a rohlíky! Že někdo občas potřebuje i veku? Na co? Však když se ty rohlíky nakrájí podélně, je výsledek skoro stejný!

pouzivani prikladu vede vzdy k tomu, ze je treba vynalozit mnozstvi energie na to zjistit, je-li priklad vhodny. Tento styl komunikace ponechme prosim parlamentu, zive, abclinuxu a jinym.

Proc se nepoperete skutecne s nadhozenym problemem predrecnika v obecne rovine. Jake vyhody a nevyhody prinasi ruznotvarnost. Kolik te ruznorodosti je potreba pro efektivni vyvoj. V diskuzi jiz lecos zaznelo. Je moznost paralelniho programovani dostatecnym dovodem, aby nejaka firma tento nastroj zaradila do sveho nastrojoveho repertoaru. Jake vykonove ztraty je treba zakalkulovat, jestlize nasazuji v ramci jedne firmy, projektu vice nastroju nebo se koncentruji na malou podmnozinu.

Jak je to s pracovnimi silami. Jsou personalni pracovnici sto rozlisovat takove spektrum ruznych dovednosti s tim, aby firme zajistili odpovidajici pracovniky?

Otazky pres otazky ...

Takove energie jsi vynalozil a stacilo napsat jen: "Na hloupou otazku, hloupa odpoved." :-)

Omlouvám se, ale nešlo to. Předřečník totiž nenadhodil problém, jak říkáte, pouze se chvástal tím, že umí napsat za jeden semestr překladač. Myslím, že téměř každý, kdo má za sebou předmět typu "výstavba překladačů" to zvládne taky a nevšiml jsem si, že by se tím tady někdo chlubil (pokud ano, opravte mě).

Samozřejmě mohu teď ke všem zdejším článkům o POV-rayi napsat komentáře typu "napsat vlastní raytracer je náplní semestrálního projektu předmětu počítačová grafika", ale bude to zhruba stejně relevantní tlach.

A ja bych je doplnil, ze predrecnik si zrejme neuvedomil, ze je rozdil napsat prekladac a prekladac pro kompletni a pouzitelny jazyk.

Ve firme kde pracuju udelali kdysi tu chybu, ze do produktu vlozili vlastni skriptovaci jazyk. No a ted padame na hubu, rozsirujeme vlastnosti jazyka misto dalsich vylepsovani celeho systemu a zakaznici se furt ptaji: "kdy bude podporovat tuhle vlastnost jazyka? a tamhletu? proc to ve vasem skriptu nejde zapsat stejene jako v jazyce x?".

A mimochodem, obcas se taky ptaji proc jsme nepouzili Python nebo Lua :-).

Beru ;) prosil bych zapouzdritelny jazyk se syntaxi ruby a pametovou narocnosti lua (par stovek bajtu na korutinu).

To ze v prvnim dilu serialu potkate pouze jednoduche vyrazove konstrukce totiz nic nerika o samotnem jazyce. V lua se pisi simulace o desetitisicich samostatne bezicich "procesu".

Nijak nezpochybnuji uzitecnost predmetu typu vystavba prekladacu, ale jazyk je casto vic nez jen syntaxe. Efektivne implementovat vlastnosti jako uzavery nebo podporu pro paralelni programovani s minimalni spotrebou pameti uz je trosku umeni.

Uvidíme.... Uznávám, že Lua mi co se implementace do C přijde lepší než třeba Python. Sám již delší dobu pátrám po jednoduchém skriptovacím jazyce a zatím jsem vždycky skončil tím, že dotyčnému uživateli (cílový zákazník) připravím framework v C++ plus hromádka maker, a nepozná, že to je C++. Má se ten člověk učit syntaxi Céčka (bez extrabuřtů), pascalu, Visual basicu, pythonu, Luy, rubyho, javascriptu, nebo kýho čerta (nehledě na to, že ten člověk doteď píše v OFP scriptu (scriptovací jazyk Operation Flashpoint a Army od Bohemia Interactive Studia... doporučuju nastudovat, možná jako odstrašující příklad)

boze tydle teoreticky zvasty miluju :)

Ano, ve školních podmínkách není vpodstatě žádný problém udělat si vlastní překladač i interpret zkompilovaného bajtkódu. Ale bude to trpět všemi vlastnostmi školských projektů - sice to bude nějak fungovat, ale bez pořádných harness testů, pomalu, paměťově neefektivně, prostě typický bastl (stačí se podívat na kód, co vyleze z lexu a yaccu). Dost úspěšných jazyků (poslední implementace JS, Lua, Iron Python) si dávají právě důraz na efektivitu, což je poznat - spousta JS aplikací by si například na starých interpretrech ani neškrtla.

Moc pěkný projekt je LÖVE.

Má funkce skoro na všechno včetně zabudovaného box2d fyzikálního enginu. Podporuje celou řadu obrázkových a zvukových formátů. Celou složku s daty a skripty pak snadno zazipujete. Po přejmenování z _.zip na _.love pak můžete přibalit k interpretru a šířit jako spustitelný soubor nebo spustit v interpretu jako takovém. Funguje na Windows, Linux a Mac.

Více informací: LÖVE Wiki(hlavně videa) a dokumentace.

O Luu se zajímám už delší dobu (no, v letech to zas není ^~) a tento seriál rozhodně vítám, protože přeci jen mě dělá problémy najít nějaký pěkný tutorial. Už jenom ten kód přiložený v rámci obrazců mě naučil jednu dvě pěkné věci.
Mno, ale chtěl bych se zeptat na věc, kterou jsem nikde nějak nenašel; umí Lua (pokud možno bez nějakých dalších přídavků) programovat tak, že někde ve scriptu přeruším vykonávání funkce, program přejde do C++ a v něm zas někdy spustím pokračování? Jde mě o simulaci paralrní práce, ale více vláken nechci použít, ty si šetřím na něco jiného. Konkrétně mám na mysli do herního enginu scripty na ovládání postav, hlavně v nějakých událostech: spustí se událost (Lua script), zpracují se data pro daný snímek (posun postav, zobrazení textu, ...), pak se přejde do C++, zde se vykreslí prostředí, texty apod., a v dalším snímku se bude pokračovat ve scriptu.
Jen se ptám, zda to jde, pokud ano, předpokládám, že se to objeví v seriálu, ale spíš by mě to zajímalo, protože je to poměrně důležité a podle toho se rozhodnu, zda ji budu chtít použít (ostatní info už mám)...

možná to půjde udělat přes koprogramy (coroutiny) a yield (to by bylo ono přerušení).

S jakyma knihovnama se to ma zkompilovat? Nebezi mi to.

překladač Lua nebo ten demonstrační příklad? Ten příklad vyžaduje pouze libc a lua (nejlépe staticky slinkovanou).

Pokud máte jazyk Lua již v systému (nainstalovaný pomocí balíčku), tak je zapotřebí při prekladu linkovat s knihovnou liblua50.so.5 (nebo 51 podle verze). Nebo je možné si stáhnout z http://www.lua.org/ftp/ zdrojáky Lua a přeložit je prakticky libovolným překladačem ANSI C (gcc vyhovuje, po mírných úpravách i bcc či Visual C) pomocí makefile. V každém případě (ať je již knihovna vytvořena staticky či dynamicky) musí být k dispozici hlavičkové soubory, k těm popř. uvést cestu pomocí přepínače -I při překladu.

Příklad ručního buildu:

1) stažení lua-5.1.4.tar.gz z http://www.lua.org/ftp/
2) rozbalení archivu
3) make linux (ve Windows make mingw, pokud máte MinGW nainstalovaný, jinak make ansi)
4) v podadresáři src se vytvoří (mj.) tři důležité soubory - interpret "lua", překladač "luac" a knihovna "liblua.a" - právě ta je určena pro linkování

Ještě me napadlo, že na některých systémech nemusí být defaultně knihovna readline (s hlavičkovým souborem), ta je potřebná pro interpret, samotná knihovna ji nevyžaduje. Pro jistotu si ji pls taky doinstalujte z baličkovacího systému.

Diky za odpoved, mel jsem problem s tim, ze mi prekladac hlasil unresolved errors. Reseni bylo jednoduche pouzivam totiz C++ prekladac- pridal jsem kolem hlavickovych souboru extern "C" { ... } a vsechno jiz bezi.

Na Ubuntu je postup takovýto:

1. nainstalovat lua5.1 liblua5.1–0-dev
2. změnit importy v C souboru na

#include <stdlib.h> #include <stdio.h> #include <memory.h> #include <math.h> #include <lua5.1/lauxlib.h> /* && / #include <lua5.1/lualib.h> / && */ 

3. zkompilovat jako

gcc lua-logo.c -Wall -pedantic -o lua-logo -lreadline -llua5.1