Příspěvky

691

Vývoj / Re:"Transplantace" kódu

« kdy: 07. 08. 2015, 07:39:27 »

Pokud použiju slovo z angličtiny, tak ho přece nemůžu skloňovat, ne? Nebo mi pořád něco uniká?

Takze nesklonujete ani slova internet, fotbal nebo svertr? Snad prvni faze, nez se to prijme nekde oficialne, musi byt, ze to pouzivaji lidi. A tam kde to pude, tam se uprednostni skolonovani. Zrovna ultimatni mi jako novotvar neprijde, ale veci jako: pušnu, repo, komit, komitnu, komandlajna, zakiluju, kilnu nebo odsnajprovat se mi ne vsechny libi ale sklonuji/casuji se.

692

O serveru Root.cz / Re:Problém s uživatelem Reklama

« kdy: 06. 08. 2015, 13:37:40 »

Zde je userscript, ktery to resi. Reklamy neblokuje, pouze skryva.

693

Vývoj / Re:Je C++ dobrá volba na větší projekt?

« kdy: 05. 08. 2015, 17:11:04 »

Myslím to tak, že na to jak Minecraft vypadá, je na HW poměrně náročný. Proč myslíte, že všechny nové verze jsou v C++?

Nevim, mozna protoze na cilove platforme neni Java (nevim, jen placam)? Take oznaceni "nove verze" je takove divne, jsou to porty, nejsou to novejsi = lepsi verze hry. Hlavni "verze" je na PC a ta je stale v Jave.

Zajimalo by me, s cim srovnavate. Ono totiz pracovat s voxelovym svetem neni zadna sranda. Par voxelovych veci v C++ jsem zkousel (myslim ze cubeworld a trove) a vetsinou jely jeste hur nez Minecraft (navic s mnohem horsi dohlednosti i grafikou). Dokud jsem si nezkusil napsat rendrovani voxeloveho sveta, tak jsem myslel, jak je Minecraft spatne napsany. Az po teto zkusenosti jsem zjistil, jak je Minecraft (relativne) dobre napsany, na vine je totiz nepodpora jak HW tak SW pro operace s voxely (kdyz jsem to zkousel, tak nebyl zadny engine/knihovna pro Javu podporujici voxely - svet, chunky, meshing, svetlo atd.).

No zrovna Minetest mi běžel na Mobilním dvoujádru znatelně líp... a nejsou náročné operace s voxely jenom dalším důvodem pro C++?

Nedalo mi to a srovnal jsem to na svem prehistorickem ctyrjadru v opengl (berte jen orientacne, muselo by se provest mnohem vice testu; oboje byla nova mapa a pockani ~minuty dokud se nestabilizuje fps, pri mereni jsem nechodil, pouze se rozhlizel):

Minetest 0.4.12 64b msvc: 30-60fps (bez mlhy, velmi mala dohlednost 5 [netusim jak se pocita])
Minecraft 1.8.8 (java 7 64b): 85-120fps (s mlhou, vbo, fancy grafika, dohlednost 10 chunku; s vecmi jako optifine to muze byt jeste lepsi [mod])

Mozna polamany build Minetestu? Zajimave, ze ne uplne optimalizovany MC z toho vychazi podstatne lepe nez MT v C++ . Po pravde jsem ocekaval spis tesnou prohru Minecraftu. Nebo ze by ten JIT delal tolik?

694

Vývoj / Re:Je C++ dobrá volba na větší projekt?

« kdy: 05. 08. 2015, 15:36:06 »

Myslím to tak, že na to jak Minecraft vypadá, je na HW poměrně náročný. Proč myslíte, že všechny nové verze jsou v C++?

Nevim, mozna protoze na cilove platforme neni Java (nevim, jen placam)? Take oznaceni "nove verze" je takove divne, jsou to porty, nejsou to novejsi = lepsi verze hry. Hlavni "verze" je na PC a ta je stale v Jave.

Zajimalo by me, s cim srovnavate. Ono totiz pracovat s voxelovym svetem neni zadna sranda. Par voxelovych veci v C++ jsem zkousel (myslim ze cubeworld a trove) a vetsinou jely jeste hur nez Minecraft (navic s mnohem horsi dohlednosti i grafikou). Dokud jsem si nezkusil napsat rendrovani voxeloveho sveta, tak jsem myslel, jak je Minecraft spatne napsany. Az po teto zkusenosti jsem zjistil, jak je Minecraft (relativne) dobre napsany, na vine je totiz nepodpora jak HW tak SW pro operace s voxely (kdyz jsem to zkousel, tak nebyl zadny engine/knihovna pro Javu podporujici voxely - svet, chunky, meshing, svetlo atd.).

695

Vývoj / Re:Je C++ dobrá volba na větší projekt?

« kdy: 05. 08. 2015, 14:25:56 »

Jo, Minecraft je napsaný v Javě a taky to podle toho vypadá.

Jestli narazite na vykonost, tak vanilla Minecraft je hratelny na beznem kancelarskem orezavatku. Nebo podle ceho "to vypada"? Pokud se vam nelibi estetika, tak to je ciste subjektivni a IMO bez toho unikatniho vzhledu by MC nikdy neprorazil.

A prodávanost opravdu není dobrým indikátorem výběru vhodného jazyka. To by jste rovnou mohl tvrdit že Windows je skvěle navržený operační systém...

A co je tedy "poradna" hra? Uspesna, dobre hodnocena, prodavana, ziskova, s hodne radky kodu, originalni v nejakem aspektu, s odehranymi miliardami hodin, nebo s vyhozenymi miliony v grafice jako vetstina nynejsich 3A? Jen jsem reagoval na to, ze na "poradnou" hru si nevyberu Javu. Pritom ale tu nepopiratelne je Minecraft... (A dokonce, jak tu nekdo poznamenal, jeho porty nejedou nad JVM.)

Mel jsem pocit, ze zrovna Winy jsou v C++, takze ani volba jazyka je nezachranila .

(Po dopsani textu dosla dalsi odpoved, rovnou tedy zareaguji.)

Nevsim jsem si, ze by se poradne hry delaly treba v Jave.

Prosim o definici "poradne hry". ....

Poradne hry myslim Ackove hry. To ze je jedna uspesna hra, minecraft, psana v Jave jeste neznamena, ze v tom muzes udelat 99% i vsech ostatnich Ackovych her.
Uznavam, ze u her, kde technicke zpracovani jde stranou mozna se Java pouzit da. Tam kde je treba ale z HW vymacknout maximum, tak tam fakt ne.

Jak jsem psal vyse, myslim ze ten trend uvidime vice a vice. Tezkou praci odedrou enginy napsane v C++, ale na herni logiku (tj. to, v cem jsou hry psane) bude "stacit" i Java/C#. Uz nyni jsou cim dal vetsi casti her psany v nejakem skriptovacim jazyce ala Lua nebo JS. Navic i s tim vykonem je to znacne diskutabilni, videl jsem hodne benchmarku, kde Java (po nekolika stovkach iteraci) porazela C++.

696

Vývoj / Re:Je C++ dobrá volba na větší projekt?

« kdy: 05. 08. 2015, 13:33:18 »

Nevsim jsem si, ze by se poradne hry delaly treba v Jave.

Prosim o definici "poradne hry". Minecraft je (alespon podle wiki) nejvice prodavanou PC hrou. Ma po dekompilaci ~180k loc (udaj je logicky pouze kod, bez komentaru), Quake 3 (vcetne enginu) s komentari mel ~300k loc. Jestli ani tohle neni poradna hra, tak uz nevim co je.

Co jsem tak sledoval, hodne indie her je nyni psanych v C# ci Jave (i 3d her, ne uplne jednoduchych). A enginy, ktere tvorily prave vetsinu kodu, se uz prestavaji psat na kolene a radeji se pouzivaji hotove vytunene.

PS: Je tady jeste problem srovnavani loc Javy a C++.

697

Odkladiště / Re:Pravidla zamykání vláken

« kdy: 20. 07. 2015, 08:58:12 »

Takováhle fóra patřící k webům jsou prostě více moderována... volnější diskusi bych asi hledal jinde, než na specificky zaměřených webech.

Vice moderovana? Je tu uplne bezne, ze po par prispevcich je vlakno nekym uneseno a vsechny nasledujici prisevky uz nesouvisi s originalnim tematem. Jako chapu, ze nechteji moc mazat, mohou tedy ale vzit ten off-topic, vytvorit nove vlakno a tam presunout vsechny souvisejici prispevky. Je zajimave, ze zamykat jim asi nevadi.

Mne sa zda, ze sa zamykaju temy, ktore obsahuju umyselny a cieleny off-topic, pripadne ak to vobec nesuvisi s tymto serverom. Takze keby sa v debate o uzitocnosti matematiky doslo k existencii veriacich s Linuxom, tak by sa to nezamklo.

Proc neni linux za penize => niekto podpisany ako lael, zrejme troll, kedze to nepisal pravy Lael. Zrejme pokus dostat ludi k tomu, nech napisu, ze je nanic a nasledny flame

Bude někdy Windows open source? => mierne off-topic, ale na tom sa velmi neda trollit

Su medzi linuxakmi aj veriaci ? => flamebait

Ehm, jak presne mate zadefinovany off-topic ze nepatri do sekce "Vše, co se nevešlo do kategorii. Tady není nic off topic."? Ani studium VS nesouvisi se zamerenim serveru - podle stejne logiky, proc s nim nesouvisi denni rezim programatora. A teda zrovna ty mega-thready o VS na me casto pusobily jako flamewar.

Zaver:

• Trollove nesmi zakladat topic (ktery muze byt dokonce zajimavy a originalni) ale unaset jina vlakna je v poradku.
• Pokud se flamewar strhne az po par prispevcich tak je vse spravne.

<>To abych sel do nejakeho zajeteho off-topic vlakna (jako jsou ty VS) vecpat viru linuxaku, kdyz jinak se to zamkne...</sarcasm>

PS: Omlouvam se za nepresny nazev. Pokud to cte nejaky mod, slo by to prejmenovat na "Pravidla zamykání vláken na fóru"?

698

Odkladiště / Pravidla zamykání vláken

« kdy: 19. 07. 2015, 09:03:38 »

Procházel jsem některá zamčená vlákna a moc v tom nevidím logiku. Podle čeho se určuje, co nepatří do kategorie "Vše, co se nevešlo do kategorii. Tady není nic off topic." a zaslouží zamčení a přesun do "/dev/null"?

Např. táma "Proc neni linux za penize" bylo zamčené ale hodně podobné (IMO) "Bude někdy Windows open source?" zůstalo odemčené.

Celkem mě zajímalo téma "Su medzi linuxakmi aj veriaci ?" (OP si dokonce dal práci s definováním pojmů), bohužel bylo zamčeno po pár příspěvcích. Rozhodně si nemyslím, že spadá do "témata o ničem". Moc nevím, co si o tom mám myslet. Nebo snad veškerá netechnická témata se zamykají (a ta nezamčená jsou pouze opomenutí)? Nebo žádná pravidla nejsou a mod náhodně kliká na ikonu zámku?

PS: Teď se dívám, že i další téma by mohlo být zajímavé "ponocovani u pocitace" (možná zlepšit jméno, něco jako "denní režim práce na pc"). Pokud je téma pracovního režimu "tématem o ničem", pak nevím, k čemu tohle fórum je.

699

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 04. 06. 2015, 10:38:34 »

tak je to naopak mnohem horsi, nez tam hodit jednoduchou konfiguraci v YAML nebo JSON.

Má to opodstatnění tam, kde využiješ větší expresivitu než prostou statickou datovou strukturu. Pokud je celá konfigurace jenom klíč-hodnota, tak to samozřejmě nemá smysl. Ale pokud tam máš nějaké části, které by bylo super generovat nějakou funkcí nebo třeba použít sem tam nějaký ten if, tak to význam má. Nevím, jestli znáš konfiguraci Nagiosu a jeho derivátů, ale to je typický příklad, kde by se to hodilo - je tam hromada spousta struktur, které se liší třeba jenom jednou položkou - typický adept na funkci/makro. V Nagiosu se to řeší šablonami a je to takový horor, že se to málo komu chce psát ručně a radši si to něčím vygeneruje. Pokud by konfigurace byla napsaná v nějakém expresivním jazyce, tak bys to generování nějakým třetím nástrojem nepotřeboval, protože by struktury generoval sám zdroják.

Jiste, ja nerikam ze to nema svoje misto. A i u pouheho klic-hodnota to muze byt k uzitku, kdyz by bylo v budoucnu potreba neceho pokrocilejsiho. Jen je dulezite, aby pro nastaveni zakladnich vlastnosti to bylo jednoduche a intuitivni a nevyzadovalo to ucit se dalsi jazyk (staci umet prirazeni). Take je nutne odlisit konfiguraci pokrocilych servrovych aplikaci a napr. GUI klikatka, ktere si bude nastavovat "bezny" uzivatel.

Např. v Elixiru vypadá konfigurační soubor projektu takhle: http://elixir-lang.org/getting-started/mix-otp/introduction-to-mix.html#project-compilation - a podívej se o kousek níž, jak je tam hezky použité to "deps_path(Mix.env)"

Pokud to chapu dobre, tak konfigurace samotna je v Elixiru. Vypada to jako prave ten dobry priklad pouziti - nenutim programatora se ucit dalsi jazyk jen proto, protoze se mi (jako tvurci nastroje) libil.

IMO spatne je, kdyz se konfigurace provadi v jinem jazyce, nez ve kterem je psan cely zbytek projektu. Prijde mi divne se ucit dalsi jazyk jen pro zapsani jednoducheho konfiguraku

V tomhle jsem se zjevně vyjádřil nesrozumitelně. Myslel jsem to tak, že je fajn, když je jazyk natolik dynamický, že konfiguraci můžeš zapsat v něm samém a nepotřebuješ další formát (a jeho parser) navíc. Nemyslel jsem to tak, že by bylo super, kdyby projekt v céčku měl embedded haskell kvůli konfiguráku

Navic pokud ke skoro neznamemu funkcionalnimu pristupu jeste pridam DSL s hromadou symbolickych neintuitivnich operatoru (v SBT kupr. %, ##, ---, +++, :=, <<=; to je v podstate novy jazyk) ...

Nadužívání DSLs je zlo, to je jasné. Bohužel to vzniká tak, že když člověk pracuje s jazykem, který DSLs umí dobře, tak je z toho tak nadšený, že to chce mermomoci použít. Znám z vlastní zkušenosti

V nekterych pripadech mohou vlastni symbolicke operatory dost pomoci, bohuzel vetsinou je to presne naopak. Jiz zminovane SBT je toho ukazkou - IMO by to melo byt pristupne v podstate vsem, co neco napsali ve Scale. V nekterych specializovanych knihovnach jako Scalaz to chapu - slouzi k zapisu predevsim matematickych operaci, presto mi teda prijdou unicode jmena divna, asi vec zvyku: ∑, ↦, ∅, ⊥. I tak to ale vytvari dojem slozitosti a znesnadnuje tak pochopeni veci novackum.

700

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 04. 06. 2015, 09:51:53 »

Navic je tam primo vazba aplikace v PHP <-> konfigurak v PHP.

Čili používá přesně ten mechanismus, o kterém mluvím? A ptáš se, kdo to používá a proč?

Ne. Zrovna pripad konfigurace WP se mi libi. Konfigurace je opravdu jen vyplneni sablony dodane s WP, ale zaroven pokud je treba neco extra, tak je to mozne dobastlit ve stejnem jazyce jako zbytek applikace.

Jen jsem napsal, ze to neni vselek a pokud se to pouzije spatne (IMO SBT a Gradle, ale mozna jsem zaujaty, protoze jsem byl "nucen" je pouzivat, nezvolil jsem si je), tak je to naopak mnohem horsi, nez tam hodit jednoduchou konfiguraci v YAML nebo JSON. IMO spatne je, kdyz se konfigurace provadi v jinem jazyce, nez ve kterem je psan cely zbytek projektu. Prijde mi divne se ucit dalsi jazyk jen pro zapsani jednoducheho konfiguraku - a uz je celkem jedno, jestli je to nejaky minoritni jazyk jako Haskell (ktery asi moc adminu a uzivatelu nezna), nebo jazyk vytvoreny jen pro konfiguraci jedne aplikace. Treba LUA je natolik jednoducha a dostatecne podobna nejpouzivanejsim jazykum, ze tam chapu tu volbu. Ale konfiguracni soubory v extremne malo pouzivanych jazycich jako Haskell, Scala nebo Lisp? Navic pokud ke skoro neznamemu funkcionalnimu pristupu jeste pridam DSL s hromadou symbolickych neintuitivnich operatoru (v SBT kupr. %, ##, ---, +++, :=, <<=; to je v podstate novy jazyk) ...

701

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 03. 06. 2015, 12:43:20 »

K tem konfigurakum v prog. jazyce jsem mirne skepticky. Pokud je bezne pouziti (tj. napr. 80% uzivatelu) pouze prirazeni hodnot do promennych (wordpress tusim to tak ma), tak s tim problem neni. Navic je tam primo vazba aplikace v PHP <-> konfigurak v PHP.

Mnohem horsi mi prijde, kdyz mam Gradle a musim se naucit Groovy a DSL pro konfiguraci, prestoze pisu Java aplikaci (na jednoduchy az stredne slozity buildeni by v pohode stacil nejaky konfigurak ve znamem a jednoduchem formatu). A takove SBT je jeste dal, prestoze je to Scala, tak jejich naduzivani custom operatoru z toho dela uplne novy jazyk  - co mam napr. cekat od operatoru <++=?

702

Studium a uplatnění / Re:Jak začít pracovat v IT oboru

« kdy: 28. 05. 2015, 11:54:10 »

Kdyz uz je tematem cistej a spravnej kod, tak nevim jak se k tomu pristupuje v Pythonu, ale jinde se bezne netoleruji magicke konstanty.

703

Studium a uplatnění / Re:Jak začít pracovat v IT oboru

« kdy: 28. 05. 2015, 11:04:45 »

...
Ano, příklad jen ilustruje jak fungují vyjímky, ale ne jak se má koncepčně programovat.
...

A v cem je tedy problem? Ukolem toho prikladu JE ukazat, jak funguji vyjimky. Ne predstavit, jak organizovat aplikaci na vrsty, dokonce ani nemusi resit vsechny chybove stavy, staci jen ty, ktere jsou dulezite pro demonstraci pouziti vyjimek. Pridavat testovani na dojiti pameti, zabiti programu, preruseni programu nebo cokoliv podobneho mi prijde pro ucely prikladu pouziti vyjimek naprosto spatne.

BTW opravdu bezne delite skript (at uz v Pythonu nebo treba bashi) o 50 radkach na vrstvy business/view/model? Ja totiz bezne pisu skripty o par stovkach radku pouze rozdelene na par trid nebo funkci, tak se ptam, jestli to mam povazovat za "praseni", pac mi to tak nikdy nepripadalo.

704

Studium a uplatnění / Re:Jak začít pracovat v IT oboru

« kdy: 27. 05. 2015, 19:29:59 »

Neco jsem nasel k Pythonu - http://paltman.com/try-except-performance-in-python-a-simple-test/. Neplati sice, ze vyjimky jsou obecne levnejsi, ale napr. pro ten linkovany priklad, kdyz by k nenalezeni prvku ve slovniku dochazelo dostatecne malo, tak z toho vychazi vyjimky lepe (doufam, ze jsem se neprehledl). V Jave myslim vetsinu zpomaleni zpusoboval call stack, s nejakymi parametry to hotspot dokazal optimalizovat srovnatelne (mozna i lepe, uz je to dlouho co jsem to cetl), zkusim to dohledat.

705

Studium a uplatnění / Re:Jak začít pracovat v IT oboru

« kdy: 27. 05. 2015, 18:12:02 »

<ot>

A bude chleba levnejsi?

Prehledl jsem se a precetl jmeno jako rohlik, hned ten prispevek mel vetsi grady . </ot>

K tematu (nebo je to jen jiny OT?) vyjimek: pred nejakym casem se to tu resilo ve specialnim vlaknu. V ruznych jazycich se s nimi pracuje ruzne. Nekde jsou drahe (C++?, Java?), jinde ale muzou stat stejne nebo byt dokonce levnejsi nez podminky. A IMO hlavne pujde o konzistenci uzivani pristupu (k vyjimkam a osetreni vstupu) v celem projektu.