OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Co v CLI napsat, aby byl program přeložen překladačem ze SolarisStudia či NetBeans?Zpravidla je to přesně naopak, IDE používá jako své komponenty další nástroje, třeba právě to
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
gcc. Rozhodně nikdo nebude vyvíjet nový kompilátor C++ jenom pro své IDE, kompilátor pro Javu takhle sice vznikl, ale i ten je pak oddělen jako samostatný CLI program.
11.1.2011 19:01
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
Taky pouzivam Eclipse, a to diky velke podpore ruznych jazyku (LaTeX, PHP, Python, C++). Ale na druhou stranu napriklad v nejnovejsich verzich blbne SVN (subclipse) a je to celkove obcas dost narocne. A 2GB RAM urcite nestaci, teda aspon ne na vetsi projekty. Pro zacatek bych doporucil neco lehciho, napriklad zminene Geany, ktere ma dost pluginu, takze IDE dokaze skoro plnohodnotne nahradit.
18.1.2011 22:47
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
Jo, tak ja na svem nb mam archa a prostredi po startu zere neco kolem 300mb, takze je fakt ze me osobne by asi stacili i 2GB. Ale v praci jsem mel OpenSUSE s KDE, a tam uz po startu jsem mel skoro cele 2GB zabrane :D
Spousta lidi o kterych mam vysoky mineni (pocinaje kolegy v praci a konce treba Linusem) pouziva "poradny editor" misto "IDE".
Však já to nepopírám, ale Vim-ko Vám třeba nezobrazí ve stromové struktuře, všechny třídy či fce
Prý to udělat jde (byť s nějakými omezeními). Ale osobně mi to nepřijde moc užitečné -- nepoužívám teď Vim, ale jenom Geany a funguje tam vyhledávání, code-folding a dokonce i doplňování s napovídáním hlaviček, takže pohoda, ač ve větším projektu by to mohlo drhnout.
...optimální kód je stále 80 znaků na řádek, tak na co jsou ty kraje monitoru, tam právě jsou ty další informace, které trknou - člověk si nemůže pamatovat všechno.
Tiling desktop. V jednom okně soubor, v dalším třeba debugger atd.
No právě z kvalitního IDE je spustíte jednou kombinací kláves a stále ve stejném prostředí
Stále jedno prostředí. Shell. ^.^
…Tím si skládáte vlastní (možná nekonzistentní) IDE :)…Ja bych řekl že je to naopak velmi konzistentní – se zbytkem desktopu. Prohlížeč a email je stejně důležitou součástí mého "integrovaného" prostředí jako debugger nebo verzovací systém. Stejně tak jabber klient, python konzole… ksakru i blbej přehrávač hudby je důležitej (pracuju v openspace). Nepotřebuju přesložitěný program který do sebe bude něco integrovat, ale jednoduchý nástroje který se budou integrovat do prostředí který už mám.
„příkazový řádek“ je nejmocnější nástroj…Jenže na wydlích odkojený fandové Zatmění/Síťfazolí tohle nepochopí protože jsou vychovaný považovat shell za odpornej opruz. A co si budem povídat, cmd.exe JE odpornej opruz
…jak potom děláš složitější věci jako generování kódu…refaktoring…Za prvé – strojové zpracování kódu používám zřídka. Možná mám štěstí, možná je to tím že nepoužívám jazyky které se ve stupidním a zbytečném opisování kódu vyžívají. Ano Javo, na tebe koukám
V tom malém zbytku většinou stačí dobře napsaný regex nebo jaký nástroj je zrovna po ruce – shell, awk, python…
Za druhé – a především – kde se bere tahle pevná víra, že takové nástroje nemůžou existovat bez IDE? To je nějaký zákon, že napsat generátor unit testů separátně je hrdelní zločin?
Možná mám štěstí, možná je to tím že nepoužívám jazyky které se ve stupidním a zbytečném opisování kódu vyžívají.Škoda že do téhle skupiny patří všechny běžně používané jazyky.
Regulární výrazy na rozdíl od transormací AST nezaručují, že se kód nerozbije.Regulární výrazy jsou úplný jazyk, lze v nich tedy (teoreticky) správně zpracovat libovolnou syntaxi. Prakticky, když člověk neprasí, nic tak složitého potřebovat nebude.
C++ tam nepatří, php, python ani ruby tam nepatří. perl má dokonce problém právě opačnýMožná mám štěstí, možná je to tím že nepoužívám jazyky které se ve stupidním a zbytečném opisování kódu vyžívají.Škoda že do téhle skupiny patří všechny běžně používané jazyky.
(jestě než to řekneš – ano, v C++ je potřeba opisovat hlavičky funkcí do hlavičkových souborů, ale tam to má důvod a kompiler tě nebuzeruje s něčím co nepotřebuje)
Nechci se moc zapojovat do hádky, ale tedy je faktická chyba: regulární výrazy popisují gramatiku typu 3, která na naprostou většinu používaných jazyků (a rozhodně na všechny o kterých jste tu mluvili) nestačí. Pravda, reálné implementace sice přidávají možnost backtrackingu, ale stále to IMHO nestačí. Rozhodně nelze mluvit o "úplném jazyku" nebo "libovolné syntaxi" (pod tím si představím gramatiku typu 0).Regulární výrazy na rozdíl od transormací AST nezaručují, že se kód nerozbije.Regulární výrazy jsou úplný jazyk, lze v nich tedy (teoreticky) správně zpracovat libovolnou syntaxi. Prakticky, když člověk neprasí, nic tak složitého potřebovat nebude.
C++ tam nepatříA co třeba psaní kopírovacích konstruktorů, destruktorů nebo přetížených operátorů =? Je to pořád dokola opisovaní toho samého. A takových věcí by se dalo vymyslet spousta.
Nejde o schopnosti jazyka, ale o to že refaktorovací nástroje znají sémantiku kódu.Opisování možná, ale ne zbytečné. To co jsi jmenoval jsou operace při kterých se kompiler nemůže rozhodnout, zda má kopírovat všechno položku po položce, nebo může předat referenci, nebo má alokovat novou paměť apod. a je potřeba to explicitně popsat. "Zbytečné" je pro mě vypisování něčeho co už kompiler ví a nutí mě to psát znovu čistě z buzerace. Například blbá konstrukce objektu:C++ tam nepatříA co třeba psaní kopírovacích konstruktorů, destruktorů nebo přetížených operátorů =? Je to pořád dokola opisovaní toho samého. A takových věcí by se dalo vymyslet spousta.
// C++ fooObject x(42); // java fooObject x = new fooObject(42);Ve druhém případě kompiler přesně ví s jakým typem má tu čest, popisovat ho znovu je čirá buzerace. Nejde o počet písmenek který musíš napsat (kdyby mi šlo o tohle, píšu v perlu
ale o přemíru syntaktického cukru. (BTW v Jave 7 snad má být tahle konkrétní zbytečnost odstraněna.)
fooObject x(6*9); fooObject *x = new fooObject(6*9);No jestli to je to jediné co označujete za zbytečné dokola opisování téhož, tak to asi mezi C++ a Java v tomto ohledu nebude moc velký rozdíl, nebo bude, ale obráceně :)… »Hlavou dolů«.
Jenže takhle to není celé. Posuďte// java fooObject x = new fooObject(42);
fooInterface x = new fooImpl(42);nebo
fooInterface x = createFoo(42);... a tady už je vidět proč se to tak píše.
... kompiler C++ predpokládá že programátor ví co dělá, ergo když typ vynechal chce použít implicitní.Naprostý nesmysl. V tomto případě je totiž objekt alokovaný na zásobníku a není možné tam uložit jiný typ, protože bys nejdřív musel zajistit, že se do alokované paměti vejde.
fooObject x(6*9); fooObject *x = new fooObject(6*9); fooObject *x = (fooObject *) new fooObjectExt(6*9);je docela zásadní rozdíl!
fooObject x(6*9); fooObject x = fooObject(6*9);jsou shodne protoze v prvnim pripade si kompiler umi domyslet ktery konstruktor mam na mysli. V Jave je prvni varianta nelegalni, prestoze kompiler muze konstruktor odvodit stejnym zpusobem. Ergo dopisovat ho rucne je tedy cira buzerace.
To je otázka uhla pohľadu. Predstav si, že si vývojár toho "buzerátora" javy. Čo je pre teba menej náchylné na chyby? Obmedzovať užívateľa alebo použiť vlastnú inteligenciu?
7.1.2011 12:35
10.1.2011 21:37
8.1.2011 02:04
17.1.2011 20:00
22.1.2011 18:33
7.1.2011 11:39
8.1.2011 17:13
7.1.2011 17:36
11.1.2011 11:06
new což dává další možnosti. Není přece možné říct, že je to jedno a že je to tam „navíc“, když by se tím omezily možnosti jazyka.To jsou ale už dvě operace – konstrukce a přetypovaní na předka. To se v C++ píše prakticky stejně, ale jen pokud je to potřeba. Je to kravina ale sere mě ten přístup – kompiler C++ predpokládá že programátor ví co dělá, ergo když typ vynechal chce použít implicitní. Java předpokládá že programátor je nesvéprávný debil, kteřeho je nutné hlídat jako dítě a v pravidelných intervalech buzerovat.Java nemá proměnné na stacku (kromě primitivních typů), takže tam je potřeba vždy 2 operace. V C++ taky nenapíšete
foo *x(5) i když by to bylo "pohodlnější". Každopádně to je vlastnost jazyka, do nesvéprávnosti a buzerace to má daleko.
Navíc chytří programátoři vědí, že čím víc věcí se děje v programu implicitně, tím méně je program přehledný a mozek odvádí svou pozornost k technickým nuancím programování místo aby se zabýval řešeným problémem.
Možná mám štěstí, možná je to tím že nepoužívám jazyky které se ve stupidním a zbytečném opisování kódu vyžívají. Ano Javo, na tebe koukámTahle debata tu už byla nedávno... není to o opisování / neschopnosti napsat kód bez jeho generování. Je to o hraní si s kódem. Chci přejmenovat funkci a všechna její volání. Nebo chci extrahovat kus kódu do samostatné funkce. Chci přesunout funkci do jiného souboru (třídy). Chci změnit pořadí parametrů. Atd. A sice na to existují ruční postupy nebo by se dalo trávit hodiny a napsat v sedu ale proč, když to můžu mít na jeden povel? Podívejte se např. na následující ukázku a dejte mi nějakou ne-IDE alternativu ke všem těm operacím: http://www.youtube.com/watch?v=ROSsjeeFmrU
Tvrzení, že programátor si vystačí s nástroji jako awk a sed mi připadá jak vyztřižené z tohohle XKCD. Při programování je potřeba se soustředit na program, ne se zdržovat bastlením nějakých pomocných skriptů, jenom proto, že "jsem přece programátor, dokážu si to napsat sám, nepotřebuju hotový nástroj jak tetička Tillie". Používat na refaktorování awk nebo sed mi teda nepřipadá moc reálné, protože tyhle nástroje neví nic o struktuře kódu, vidí ho jenom jako text. Samozřejmě, jde to (jsou to turingovsky úplné jazyky 
), ale udělat to pořádně (aby to kód spolehlivě nerozbilo) by znamenalo v podstatě napsat si ten nástroj "pro tetičku Tillie" sám v awk. Pokud bych si na program pustil nějaký nespolehlivý skript (co nevidí program jako program, ale jenom jako text), tak bych ho stejně pak po něm musel překontrolovat, jestli nic nerozbil.
IMHO prostě bez parseru to nemá cenu. Nedají se někde sehnat parsery pro různé jazyky (C, C++, Python, PHP, ...), abych si něco jako v tom videu mohl udělat ve vimu? Parser existuje pro každý jazyk, ale bohužel jsem ho pro běžné jazyky nikde nenašel jako samostatně použitelný nástroj. To si fakt výrobci IDE dělají vždycky vlastní parser? Připadá mi nesmyslné dělat stejnou věc (parser pro jazyk xyz) znovu, když už existuje.
To si fakt výrobci IDE dělají vždycky vlastní parser?Obvykle jo, parser z překladače je pro použití v IDE dost nevhodný. Jsou výjimky: libclang (z projektu Clang/LLVM) je pro použití mj. v IDE přímo navržená knihovna, a dokonce ji tak v Applu používají. API mi nepřišlo špatné, když jsem to trochu kuchal, ale už si nepamatuju, jak to bylo se zápisem. A tuším, že některá javovská IDE používají od Javy 6 pro parsování Java Compiler API, ale nezkoumal jsem to do podrobna.
Nedají se někde sehnat parsery pro různé jazyky (C, C++, Python, PHP, ...), abych si něco jako v tom videu mohl udělat ve vimu?A nebudete pak dělat tu věc pro tetičku? PHP a python má nástroje od JetBrains, případně pro PHP existuje krásné Zend studio. S C/C++ je trochu problém, protože existuje de fakto pouze Visual studio od MS. (Někdo si pochvaloval i codeblocks ale nebe/dudy.)
To si fakt výrobci IDE dělají vždycky vlastní parser?Většinou i překladač (nebo ho integrují stávající). Čím víc informací o editovaném programu to IDE ví, tím víc věcí Vám řekne/nabídne už při editaci a o tom to je. Jinak tím nezatracuju vim. Ten má svá pozitiva taky.
S C/C++ je trochu problém, protože existuje de fakto pouze Visual studio od MS. (Někdo si pochvaloval i codeblocks ale nebe/dudy.)Schopně vypadá GCCSense, který si tahá informace přímo z GCC. Co se týče C++ tak porovnávat Code::Blocks a Visual Studio je naprosto zcestné. Možná bych konečně měl napsat blog (nebo alespoň příspěvek do této diskuse) o mém výběru nejlepšího IDE pro C/C++ (zkusil jsem jich opravdu hodně – Code::Blocks, NetBeans, Eclipse, SunStudio, Monkey Studio, Code Lite, Intellij Idea, Qt Creator, krátce jsem později zkoušel i Visual Studio 2010 Ultimate (přes MSDNAA)) Ve zkratce, nejlepší podporu C/C++ mají KDevelop a Visual Studio 2010 (starší verze jsem nezkoušel, ale prý na rozdíl od KDevelopu a VS 2010 neumí zvýrazňovat chyby už během psaní kódu ale až po kompilaci). Na GCCSense se teprve chystám, ale vypadá to zabijácky (akorát se zdá, že ukazuje ukazuje i interní věci STL).
S refactoringem jsem problem taky nikdy nemel a v Intellij IDEA je refaktoring taky na velice slusne urovni.
(Edituju to v IDEi, ale ta mi poskytne jenom základní zvýrazňování a doplňování použitých slov, nic moc.)
IntelliJ IDEA je bezkonkurenčně nejlepší IDE – pro Javu. Mám dojem, že tady se mluví o C/C++, a i když pro IDEu existuje plugin (třetí strany, JetBrains plánujou v tomhle ohledu jenom IDE pro ObjC a pouze pro Mac OS X), není zdaleka na takové úrovni.Souhlasím. Používám ji na Javu a nic se jí nevyrovná. Na C++ je ale na houby.
Před časem jsem zkoušel KDevelop, který tu někdo zmiňoval, a i když má možná podporu jazyka skvělou, přišel mi oproti IDEi strašně "klikací" (mám pocit, že jsem nemohl najít klávesovou zkratku pro "find usages", takže jsem to znechuceně odinstaloval),Až na "Show uses" má klávesovou zkratku asi na vše (nebo se dá nastavit). Můžeš ale skákat na předchozí/další použití. Tedy ke show uses se klávesovou zkratkou dostat můžeš, ale je to trošku neintuitivní – použitím "Rename Declaration," protože to vypíše všechna použití.
takže když si teď hraju s adb, žádné IDE na to nemámadb? Co je to?
A nebudete pak dělat tu věc pro tetičku?Asi budu, ale
Jinak tím nezatracuju vim. Ten má svá pozitiva taky.No právě. Nejlepší by bylo mít ty pozitiva všechny
No právě. Nejlepší by bylo mít ty pozitiva všechnyVim je produktivní nástroj, ale na něco jiného. Pokud budete mít jiný produktivní nástroj (slušné IDE), tak Vám nebude z vimu nic chybět.
Ono všechny ty náhražky a vim-like módy jsou dost nedokonalé a povětšinou tomu chybí spousta funkcí.Opakuju se, ale znova - v dobrém IDE žádná spousta funkcí k editování textu nechybí. Naopak v pravém vimu chybí spousta funkcí k programování. Vim nemá zkratku na rename symbolu, na extract method, atp. To má právě jen to IDE a já říkám, že když už máte IDE tak už zrovna můžete akceptovat fakt že skok na konec řádku je end a nikoliv $. Vim je dobrá věc na spoustu jiných úkolů ale nesnažte se ho cpát všude.
IDE to v pohodě najde a přejmenuje.Zajímavá situace je, když metodu přejmenuji na jméno, které už mám v nějakém řetězci.
I když to jméno bude v nějakém řetězci vcelku, tak stejně nevíte, jestli se má změnit.Ve speciálním případě víme (např. když to bude přímo volání té reflexe). V obecném případě ne, ale dá se ukázat v editovacím okně v kontextu a dotázat se na požadovanou operaci.
Zajímavá situace je, když metodu přejmenuji na jméno, které už mám v nějakém řetězci.Jo, nebo když všechny proměnné a klíčová slova přejmenuju na "ahoj".
Zajímavá situace je, když metodu přejmenuji na jméno, které už mám v nějakém řetězci.Co se s tím řetězcem má stát, když to přejmenuji zpátky? A co když vím, že je volána metoda s názvem v tom řetězci?
To se jako máme automatického přejmenování zbavit, protože je nespolehlivé, a dělat ho vždycky ručně, protože to je ještě nespolehlivější?To jsem nechtěl ani naznačit, a jestli to tak vyznělo, tak se omlouvám.
Třeba efektivní editování textu tam bude chybět.Nevím, proč by mělo. Vim nemá patent na ovládnutí světa na dvě stisknutí kláves.
V okamžiku, kdy se s Vimem naučíš, tak s ním dokážeš upravovat text mnohem rychleji než s jakýmkoliv "běžným" editorem.Tvorba programu není úprava textu. Ve Vim je úprava textu fakt vymakaná a to může svádět k myšlence, že všechno je jen text a nic víc. Ale ve skutečnosti je programování mnohem více high level činnost a ta textová reprezentace je jen boční efekt. Potřebujete dělat operace typu "zadefinuj proměnnou", "obal příkaz cyklem", atd. a ne "přesuň blok textu odsud sem".
Jeho síla je poznat hlavně při složitějších úpravách, jako třeba "na konec každého řádku přidat uvozovku a čárku, na začátek tab a uvozovku" (při různé délce řádků; často potřeba při nakopírování seznamu názvů do kódu).Jo. Tahle operace se jmenuje "nakopíruj clipboard jako konstantu do kódu" a není důvod ji emulovat pomocí "dej na začátek uvozovky". Ta operace samozřejmě může pak jít trochu dál, např. escapovat nepovolené znaky apod., což už by pomocí editace textu bylo trochu přes ruku.
Jo. Tahle operace se jmenuje "nakopíruj clipboard jako konstantu do kódu" a není důvod ji emulovat pomocí "dej na začátek uvozovky". Ta operace samozřejmě může pak jít trochu dál, např. escapovat nepovolené znaky apod., což už by pomocí editace textu bylo trochu přes ruku.Není problém takovou věc udělat jako skript do vimu.
Není problém takovou věc udělat jako skript do vimu.Když zmáčknu paste tak aby vim pochopil jestli máte zrovna otevřený plain string nebo regexp coby string, případně SQL příkaz coby string, nebo jestli jste úplně jinde v XML souboru a potřebujete jen < a spol? Problém to není, jen je to docela na dlouho.
Tím nekonzistentní, krom toho, že jsem si rýpl, jsme myslel, že i když jsou všechno programy daného desktopu, každý má jiné ovládání a vzhled. :)Špatnej desktop
Nebo to tak uživatel prostě chce. Já mám dost konzistentní prostředí a proto se oběma hlavním IDE radši vyhýbám. Oni za to nemůžou ani tak autoři netbans/eclipse jako spíš java ale do mého pracovního prostředí se hodí asi jako střep do žaludku.
To by šlo otočit: „Fandové příkazového řádku nikdy nepochopí, že existují specializované komplexní nástroje, protože by se je museli naučit a to je opruz“ :)Šlo
Ale nedává to moc smysl – učení klikacích nástrojů není opruz. Opruz je že takové nástroje nejsou obvykle ani tak „specializované a komplexní“ jako spíše omezené až stupidní. Musí být – každá funkcionalita musí být reprezentována nějakým grafickým objektem, což je sice přehledné pokud jich je relativně málo, ale může jich být jen určité množství než vznikne nepřehledný chaos. Představ si třeba kolik klikací rozhraní ke gcc, buď to bude mít milion čudlíků a submenu nebo to bude nějak omezený.
Docela by mě zajímalo jakou feature třeba v případě zmiňovaných IDE si myslíte že by jste neměl k dispozici, či by se dělala nějak obskurně.V době kdy jsem dělal ve fazolích mi tam hodně chyběl SQL klient (dnes už snad použitelný je). A všechno co se týkalo deploymentu bylo dost tvrdě svázaný s nějakym javovským přesložitěným balíčkovacím pseudosystémem, kterej mě dost krkal. Ostatně samotný editor nebyl nic moc. Hlavní tahák obojího bylo pro mě inteligentní doplňování, a když jsem v další práci vyměnil javu za python, zjistil jsem že ho vlastně nepotřebuju. Ditto "refaktoring" – to je jen jiný slovo pro "obcházení stupidity kompileru javy". Nechci tady začínat flame o javě, takže bych si dovolil jen konstatovat, že v lépe vymyšlených jazycích tenhle nástroj není důležitý. Jestli chceš obecnější příklad kde je CLI silnější nástroj než GUI, tak bych řekl že prakticky všude. Vtip ja právě v té "omezené podmnožině". Třeba refaktorovací nástroje mají funkčnost omezenou na známou syntaxi a pevně daný rozhraní, sed a awk jsou úplné jazyky, ostatně i samotné regexpy jsou turingovsky úplné jazyky. Ditto debuggery, hledání, správa projektů… cokoliv. "Omezená podmnožina" je dobrá věc pro počítačově negramotnou tetičku Tillie, ne pro programátora.
regexpy jsou turingovsky úplné jazykyEhm? Regularni jazyky jsou ekvivalentni konecnym automatum, a ty teda rozhodne nejsou zadna velka sila. Pridej zasobnik (nebo nejlip dva) a muzeme se zacit bavit :)
18.1.2011 15:26
(?{ code }). To pak už asi bude turing-complete.
Tiskni
Sdílej:
