abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 01:55 | Bezpečnostní upozornění

Společnost Uber potvrdila bezpečnostní incident a únik dat v roce 2016. Unikly údaje o 57 milionech cestujících (jména, emailové adresy a čísla mobilních telefonů) a 600 tisících řidičích (navíc čísla řidičských průkazů).

Ladislav Hagara | Komentářů: 0
včera 23:44 | Humor

Co vypíše příkaz man půl hodiny po půlnoci? Text "gimme gimme gimme". Jedná se o virtuální velikonoční vajíčko připomínající skupinu ABBA a její hit Gimme! Gimme! Gimme! (A Man After Midnight). Problém nastane, pokud gimme gimme gimme nabourá automatizované testování softwaru. To se pak příkaz man musí opravit [Bug 1515352] [reddit].

Ladislav Hagara | Komentářů: 6
včera 18:11 | Zajímavý článek

Mozilla.cz informuje, že Firefox na Fedoře podporuje Client Side Decorations. Firefox na Linuxu se vykresluje včetně standardního záhlaví okna, které je v případě webového prohlížeče většinou nadbytečné a ubírá drahocenné vertikální místo na obrazovce. Verze distribuovaná uživatelům Fedory však nyní obsahuje experimentální podporu pro takzvané Client Side Decorations, které umožňují vykreslování „oušek“ panelů do záhlaví okna.

Ladislav Hagara | Komentářů: 9
včera 05:00 | Bezpečnostní upozornění

Maxim Goryachy a Mark Ermolov ze společnosti Positive Technologies budou mít v prosinci na konferenci Black Hat Europe 2017 přednášku s názvem "Jak se nabourat do vypnutého počítače, a nebo jak v Intel Management Engine spustit vlastní nepodepsaný kód". O nalezeném bezpečnostním problému informovali společnost Intel. Ta bezpečnostní problém INTEL-SA-00086 v Intel Management Engine (ME), Intel Server Platform Services (SPS) a Intel

… více »
Ladislav Hagara | Komentářů: 28
včera 01:33 | Zajímavý projekt

Na Humble Bundle byla spuštěna akce Humble Book Bundle: Java. Za 1 dolar a více lze koupit 5 elektronických knih, za 8 dolarů a více 10 elektronických knih a za 15 dolarů a více 15 elektronických knih věnovaných programovacímu jazyku Java od nakladatelství O'Reilly. Peníze lze libovolně rozdělit mezi nakladatelství O'Reilly, neziskovou organizaci Code for America a Humble Bundle.

Ladislav Hagara | Komentářů: 0
včera 00:11 | Zajímavý projekt

Článek na OMG! Ubuntu! představuje rodinu písma IBM Plex. Jedná se o open source písmo (GitHub) navržené a uvolněné společností IBM (YouTube, Carbon Design System). Ukázka na Font Squirrel.

Ladislav Hagara | Komentářů: 11
20.11. 23:22 | Komunita

Na Humble Bundle lze získat počítačovou hru Brütal Legend (Wikipedie, YouTube) běžící také v Linuxu zdarma. Speciální akce končí ve středu v 19:00.

Ladislav Hagara | Komentářů: 0
20.11. 06:00 | Zajímavý článek

USA Network vysílá již třetí sérii seriálu Mr. Robot (Wikipedie, ČSFD.cz). Ryan Kazanciyan, technický konzultant seriálu, se na Medium v sérii článků Mr. Robot Disassembled věnuje jednotlivým dílům a popisuje použité nástroje a postupy.

Ladislav Hagara | Komentářů: 2
19.11. 23:55 | IT novinky

Společnost StartCom oficiálně oznámila, že jako certifikační autorita končí. Od 1. ledna 2018 přestane vydávat nové certifikáty a následující 2 roky bude poskytovat OCSP a CRL. Počátkem roku 2020 budou všechny platné certifikáty zneplatněny.

Ladislav Hagara | Komentářů: 54
19.11. 22:00 | IT novinky

Hodnota Bitcoinu, decentralizované kryptoměny, překonala hranici 8 000 dolarů [reddit].

Ladislav Hagara | Komentářů: 5
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (9%)
 (1%)
 (1%)
 (1%)
 (74%)
 (14%)
Celkem 737 hlasů
 Komentářů: 37, poslední včera 15:21
    Rozcestník
    Štítky: není přiřazen žádný štítek

    Vložit další komentář
    13.4.2015 23:03 my sme piestany
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    daju sa v tej scale robit aj normalne exace? abo len jarka?
    14.4.2015 09:57 aubi
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Exace se daji delat jenom z asm nebo c/c++. Vsechny novejsi jazyky pouzivaji runtime - Java, c#, nodejs. Uz VB bez runtime nebezel, dtto Lisp, Prolog... A jestli tomu dobre rozumim, tak runtime pri c je libc, jen je nastesti v systemu :-)

    Scala patri do rodiny jazyku postavenych nad Java virtual machine.
    14.4.2015 10:02 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Vsechny novejsi jazyky pouzivaji runtime
    Naštěstí to tak není.
    14.4.2015 10:18 aubi
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Na Tvem blogu jsem nasel Python a Haskel...

    Ktere jazyky se tedy kompiluji do exe bez potreby runtime?
    Bystroushaak avatar 14.4.2015 10:54 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Například D. Jinak i Lisp má verze, které se dají přímo kompilovat do strojáku, dokonce i subset pythonu rpython se dá kompilovat (viz taky micropython, The 3 different code emitters, The 3 different code emitters, part 2).

    Jinak to že má něco interpreter ještě neznamená, že se z toho nedá udělat spustitelná binárka.
    14.4.2015 12:22 pavel
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Z cehokoliv lze udelat exe: zabalis do toho interpretr a mezikod (.class|.pyc|.pyo apod..). Pri spusteni se to rozbali v pameti a spusti. Podobne jako fungovaly samorozbalovaci zip, ale vse se odehraje neviditelne v pameti.
    15.4.2015 10:09 aubi
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Diky, odkazy jeste proctu podrobneji.

    Myslis, ze by se z D mohl stat velky hrac velikosti Javy nebo aspon Pythonu? Mam na mysli komercni aplikace, web a serverside.

    Bystroushaak avatar 15.4.2015 10:57 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Myslis, ze by se z D mohl stat velky hrac velikosti Javy nebo aspon Pythonu? Mam na mysli komercni aplikace, web a serverside.
    Nevím jestli stejné velikosti (to záleží hlavně na tom, jestli se ho chytne nějaká velká firma), ale stejné užitečnosti určitě ano. Psát v D je velmi podobný pocit, jako psát v pythonu - je to dobře navržené a na podobné úrovni abstrakce. Přitom je to stále "lowlevel" systémový jazyk.

    Docela se mi líbí, že D si poslední dobou začínají všímat i lidi z /r/programming, viz třeba Excited About D, či The D Language: A sweet-spot between Python and C, nebo The State of D in 2015.
    15.4.2015 16:13 Květináč
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Systémový jazyk to není !! další lež tvůrců jazyka. Sem v tom chtěl napsat primitivní kernel a VIDA? Musel bych přepsat D runtime (běhovou platformu podle mojí terminologie) aby to běželo ... takže sorry, snažší je C/C++ na low level vývoj. A D trpí také tím, že plno vlastností jazyka závisí na GC, takže není možné jen tak GC vypnout. Celkově když sem se na D koukal před asi rokem, tak mne zklamal ...
    Bystroushaak avatar 15.4.2015 17:13 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Taková zhrzenost :D
    Musel bych přepsat D runtime (běhovou platformu podle mojí terminologie) aby to běželo ...
    Přepsat bys jí nemusel, jen momentálně moc nechce fungovat bez garbage collectoru. Garbage collector je jedna z věcí, o které psal Andrei, že jí v dohledné době přepíše a celkově co jsem tak četl, tak se pracuje na odproštění phobosu od něj co to jen půjde.
    A D trpí také tím, že plno vlastností jazyka závisí na GC, takže není možné jen tak GC vypnout.
    Vážně, vlastností? Vím o tom že systémová knihovna na tom záleží, ale vlastnosti, to je pro mě novinka. Můžeš nějaké jmenovat?
    19.4.2015 23:08 Květináč
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Super, takže přepsat bych runtime nemusel, ale bez GC nic neběží ... Kurva, ty si řek sračku. Víš to? Asi jo, ale prostě si jen chtěl nesouhlasit. To blbý runtime bych musel celí přepsat, od správy paměti až po definice primitivních operátorů. Proč? Protože OS je opravdu lepší psát bez GC. Ano, v historii byla Genera která běžela pod GC, jenomže procesorová architektura LISP machines ho podporovalo, takže to bylo rychlí.

    A co se týče těch vlastností. Je dost možné že jsem zvolil špatné slovo. Když se koukneš hlouběji do runtime na definice primitivních operátorů, zjistíš že mnoho z nich závisí na GC.

    A pozor, kdybych se přece jenom rozhodl ten OS s GC napsat, stejně bych musel to blbý runtime přepsat, protože GC z něčeho musí paměť čerpat. U OS je problém, že velká část samotného jádra (bez driverů) je tvořena managementem paměti (virtualizace, alokace). Takže by to vyžadovalo napsat v D bez GC dost kódu. A to by nešlo, kdyby bylo runtime závislí na GC. Takže se vracíme na začátek. MUSEL bych to celí přepsat. A to nemluvím o tom, že by se v případě GC muselo ještě dost srát s hledáním kořenů.

    Takže závěr? Jo sem zhrzenej z D, na první pohled to byl fakt zajímavej jazyk. Sice dost přeplácanej ale to je fuk. Ještě furt má D tak pomalej GC?

    A taková rada, klidně nesouhlas, ale aspoň o tom něco znej a nemel sračky. kdybys v tom něco lowlevel psal či se o to pokoušel, věděl bys že v aktuálním stavu je D absolutně napíču, pokud teda zrovna nemá člověk chuť se přepisovat s druntime.
    Bystroushaak avatar 19.4.2015 23:58 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    To blbý runtime bych musel celí přepsat, od správy paměti až po definice primitivních operátorů. Proč? Protože OS je opravdu lepší psát bez GC. Ano, v historii byla Genera která běžela pod GC, jenomže procesorová architektura LISP machines ho podporovalo, takže to bylo rychlí.
    Tady je místo, kde se hádám.

    A pozor, kdybych se přece jenom rozhodl ten OS s GC napsat, stejně bych musel to blbý runtime přepsat, protože GC z něčeho musí paměť čerpat. U OS je problém, že velká část samotného jádra (bez driverů) je tvořena managementem paměti (virtualizace, alokace). Takže by to vyžadovalo napsat v D bez GC dost kódu. A to by nešlo, kdyby bylo runtime závislí na GC. Takže se vracíme na začátek. MUSEL bych to celí přepsat. A to nemluvím o tom, že by se v případě GC muselo ještě dost srát s hledáním kořenů.

    Zde vedu nějaké argumenty, rozpaluji se, posílám odkazy a tak.
    .. runtime bych musel celí přepsat .. takže to bylo rychlí .. runtime závislí na GC .. MUSEL bych to celí přepsat
    Teď si do tebe kopnu za prasáckou češtinu, kop, kop. Použiju taky trochu CAPSLOCK, abych tomu dodal váhu a vykřičník! Vykřičník jak hrom!!
    A taková rada, klidně nesouhlas, ale aspoň o tom něco znej a nemel sračky. kdybys v tom něco lowlevel psal či se o to pokoušel, věděl bys že v aktuálním stavu je D absolutně napíču, pokud teda zrovna nemá člověk chuť se přepisovat s druntime.
    Místo tohohle si představ nějaký závěr a tak podobně.
    Super, takže přepsat bych runtime nemusel, ale bez GC nic neběží ... Kurva, ty si řek sračku. Víš to? Asi jo, ale prostě si jen chtěl nesouhlasit.
    S takhle hustým přístupem si diskutuj s někým, kdo ti na to skočí. Asi jsem dospěl, nebo co, ale nebudu ztrácet čas obhajobou něčeho, co je mi napůl ukradené, ale s čím mám náhodou osobní zkušenosti. Prostě mě za to nestojíš, pokud tě zajímá, jak to fakt je, tak si to vygoogli, pokud ne, hejtuj dál, nemám náladu klesat na tvojí úroveň diskuze. Koneckonců můj problém to není.
    pavlix avatar 20.4.2015 10:58 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    20.4.2015 10:58 květináč
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Lišáčku, fakt jsi mě zklamal. Myslel jsem že jsi inteligentní a vzdělaný. Teď cos napsal mne vyvedlo z omylu. Fakt, napsal si proud sraček bez jediný informační hodnoty. Jsi úplně mimo. Víš o tématu v kterém si ze mě chtěl udělat blbce úplný hovno. Sem myslel že si jinej, ale si jako ostatní sbírka postaviček tady. Arogantní, všechno víš a všude si byl dvakrát. A taky si ani pořádně nepochopil co sem napsal, jinak bys nepsal "je to tvůj problém" ale "byl to tvůj problém". A ta rada abych začal googlit perfektně sedí na tebe lišáčku.
    Bystroushaak avatar 20.4.2015 11:07 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Jo, je to spiknutí, kde je cílem udělat z tebe blbce. Ještě že jsi to odhalil *mrk*, *mrk*.
    pavlix avatar 20.4.2015 11:33 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Ahoj postavičko z Abclinuxu. :)
    Bystroushaak avatar 20.4.2015 12:18 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    To je tuším taky diagnóza, kdy vnímáš okolní lidi jako méněcenné postavy. Většinou to docela dost vypovídá o člověku, který to používá, určitě ve smyslu arogance a sebevědomí. Jílek by nám o určitě pověděl víc.

    Stejně tak je zajímavý způsob argumentace, který použil; že je zklamaný, protože si o mě myslel, že jsem vzdělaný a inteligentní. Argument jako kdyby mi snad mělo být líto, že si o mě vytvořil nějakou představu a teď jí neodpovídám. K tomu ještě nulová sebereflexe, vulgárnost a pocit, že mu ostatních chtějí uškodit. Fakt ideální kombinace do diskuzí, ten se jen tak neztratí.
    pavlix avatar 20.4.2015 12:28 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Je hezké, jak se každý zaměřujeme na něco úplně jiného. Tebe nejvíc zaujaly psychologické a sociální aspekty daného deprivovaného jedince a jejich projevy v diskuzi, zatímco mně ze všeho nejvíc baví ta nelogičnost počínání, kdy si člověk vybere místo nebo skupinu lidí, která ho nejvíce zajímá, a snaží se je urážet a vysvětlit jim, že jsou pro něj úplně nezajímaví. Nedávno jsem takhle viděl babu, co si vybrala pražskou lékárnu k tomu, aby nadávala na pražáky.
    Bystroushaak avatar 20.4.2015 12:39 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Na to už jsem si tak nějak zvykl.
    xkucf03 avatar 20.4.2015 21:38 xkucf03 | skóre: 46 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.

    Bezva, příště místo srazu uživatelů budeme pořádat sraz postaviček :-)

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
    little.owl avatar 20.4.2015 22:40 little.owl | skóre: 22 | Brighton
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Tak takovahle imlementace jazyka a runtime libraries je celkem slusny show stopper i pro pouziti v aplikacich, o systemovem programovanim nemluve.

    V posledni dobe zacinam mit pocit, ze psat cokoliv co ma byt dlouhodobe udrozovano v jazycich, ktere nemaji ISO/ANSI standard je uplne na pytel, i kdyz jsou to z vyjimkou C++ spise stojate vody.
    You're damned if you do, and you're damned if you don't.
    Bystroushaak avatar 20.4.2015 22:56 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Tak takovahle imlementace jazyka a runtime libraries je celkem slusny show stopper i pro pouziti v aplikacich, o systemovem programovanim nemluve.
    Já bych hlavně moc nedal na květináče, protože, jak už jsem naznačil, jeho informace nejsou úplně kvalitní a v posledním ~roce se to hodně mění.
    V posledni dobe zacinam mit pocit, ze psat cokoliv co ma byt dlouhodobe udrozovano v jazycich, ktere nemaji ISO/ANSI standard je uplne na pytel, i kdyz jsou to z vyjimkou C++ spise stojate vody.
    Pokud ti jde o stálost, tak nemá smysl si vybírat takového nováčka, jako je D. Sice může nabízet sexy featury, ale API systémové knihovny se stále mění. Nedokážu říct, jestli je to dobře, nebo špatně - sám za sebe jsem rád, protože to znamená, že stále probíhá vývoj, než si to „sedne“ a tedy že „dospělá“ verze bude o to lepší. Já ovšem obecně preferuji rychlost vývoje před ostatními vlastnostmi, tak chápu, že to může vadit.
    little.owl avatar 21.4.2015 00:03 little.owl | skóre: 22 | Brighton
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    a v posledním ~roce se to hodně mění.
    Z vlakna:
    Unfortunately, I doubt @nogc exception support will be ready for 2.068 (there isn't even any plans for it at the moment), and @nogc is still unusable until that's taken care of.
    Pokud ti jde o stálost, tak nemá smysl si vybírat takového nováčka, jako je D. Sice může nabízet sexy featury, ale API systémové knihovny se stále mění.
    Takze je to na ****** ;-).
    a tedy že „dospělá“ verze bude o to lepší.
    A Godot stale neprichazi ...
    Já ovšem obecně preferuji rychlost vývoje před ostatními vlastnostmi,
    Jako pouzitelnosti?

    Standardizovany jazyk ma vyhodu definovaneho chovani, zmeny standardu vetsinou nejsou tak radikalni a jsou [vetsinou] zpetne kompatibilni. To ma celou kupu praktickych dopadu, od stabilnich knihoven po udrzbu aplikaci ci zvladnuti jazyka na urovni, kdy si je clovek schopen poradit s jeho slabsimi strankami. To mi nejake nedopecene sexy featury novych jazyku, kterych je v posledni dobe v alejich nablito plno, nevykompenzuji, a to ani u throw away kodu.

    A jazyk D? Pokud se neprosadil dodnes, tak se uz asi neprosadi, uz jen kvuli C++17 ci i treba Rustu.
    You're damned if you do, and you're damned if you don't.
    21.4.2015 00:21 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    zvladnuti jazyka na urovni, kdy si je clovek schopen poradit s jeho slabsimi strankami
    Pokud je specifikace jednoznačná, dostatečně detailní a není příliš složitá.
    little.owl avatar 21.4.2015 01:17 little.owl | skóre: 22 | Brighton
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    To ma vice spolecneho se skutecnosti, ze jazyk je stabilni - ve smyslu kompatibility, nemeni se vam rychle pod rukama a nezahazujete pracne a nekdy bolestne ziskane zkusenosti.

    Pripomina mi to kolegu ktery v C/C++ programuje od roku 1983, po precteni tohoto cisla Byte venovaneho C jazyku (stoji za to projit, 580 stran, vcetne clanku od Kernighan, Unix tutorialu ci review/benchmark tehdejsich C kompilatoru na tehdejsim HW).
    You're damned if you do, and you're damned if you don't.
    Bystroushaak avatar 21.4.2015 00:24 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Takze je to na ****** ;-).
    Prostě to bude chvíli trvat. Neznamená to, že to nemůžeš používat ihned, jen že to ihned nemůžeš používat s plnou podporou phobosu (jsou i jiné knihovny).
    Já ovšem obecně preferuji rychlost vývoje před ostatními vlastnostmi,
    Jako pouzitelnosti?
    Stabilitou (ve smyslu změn v API, ne padání), rychlostí, do jisté míry i dokumentací.
    A jazyk D? Pokud se neprosadil dodnes, tak se uz asi neprosadi, uz jen kvuli C++17 ci i treba Rustu.
    Co se mě týče, tak je to jasná volba, pokud potřebuji sáhnout po něčem kompilovaném, protože mi garbage collector ve většině věcí nevadí.
    little.owl avatar 21.4.2015 01:16 little.owl | skóre: 22 | Brighton
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    protože mi garbage collector ve většině věcí nevadí.
    Hlavne treba psat kompilovane programy tak, abyste ho nepotreboval, C++11 vyse vam dava plno nastroju.
    You're damned if you do, and you're damned if you don't.
    Bystroushaak avatar 21.4.2015 10:18 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Já se nechci přít, protože se očividně pohybujeme v úplně jiných kruzích vývoje. Pro mě je prostě vhodnější D, i díky tomu, že neohrožuje mojí příčetnost.
    14.4.2015 13:11 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Ktere jazyky se tedy kompiluji do exe bez potreby runtime?
    Je otázkou, čemu přesně budeme říkat runtime.

    Třeba některé implementace nízkoúrovňových jazyků nepotřebují prakticky nic. Například C– nebo LLVM IR.

    Krom toho mnoho implementací (např. GHC Haskell, OCaml, MLton, Ur/Web, …) umí přibalit runtime přímo do spustitelného souboru – runtime je často realizován jako obyčejná knihovna, takže ho stačí staticky přilinkovat.
    pavlix avatar 14.4.2015 10:12 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Vsechny novejsi jazyky pouzivaji runtime
    To asi těžko, že. Nehledě na to, že ani C a C++ nejsou v pravém smyslu staré jazyky, stále se vyvíjejí.
    A jestli tomu dobre rozumim, tak runtime pri c je libc, jen je nastesti v systemu :-)
    Nikoli, je to jen knihovna.
    14.4.2015 10:50 aubi
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Aspon od Tebe bych cekal odpoved -- ktere jazyky delaji exace?

    Ad C++ - novym jazykem bych to asi nenazyval ani pres jisty vyvoj. Zacinal jsem na nem, bude to tak dvacet let. A treba na mainframech je na tom C++ stejne jako Java - bez runtime nebezi.
    pavlix avatar 14.4.2015 11:02 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Aspon od Tebe bych cekal odpoved -- ktere jazyky delaji exace?
    Jen si počkej na odpověď mistra programovacích jazyků výše, má mnohem větší přehled. Mimochodem, jazyk a toolchain jsou dvě zcela odlišné věci, nemá smysl jazyku přisuzovat vlastnosti, které má toolchain, jazyk nevytváří binárky ani nutně neurčuje všechny vlastnosti toolchainu.
    A treba na mainframech je na tom C++ stejne
    Přiznám se, že ani nevím, co se zde snažíš sdělit. Na mainframech běhá ledacos, takže bude většina kategorických tvrzení už z principu chybná.

    Fluttershy, yay! avatar 14.4.2015 12:18 Fluttershy, yay! | skóre: 81 | blog:
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Aspon od Tebe bych cekal odpoved -- ktere jazyky delaji exace?

    Jazyky? Exáče? Me gusta. Třeba Python: py2exe. ^_^

    15.4.2015 11:05 extremni lama | skóre: 14 | blog: e_lama
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Tady je nejakej seznam:

    http://en.wikipedia.org/wiki/Compiled_language

    asi nenu uplne kompletni...
    The enemy of my enemy is still my enemy.
    14.4.2015 12:42 květináč
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Neplést runtime, běhovou platformu a knihovnu ano? C nemá nic, jen std knihovnu. C++ to samé. Haskell má běhovou platformu ale nikoli runtime (pro větší přehlednost tomu ale runtime říkají ...). Java, C# a spol mají všechno. To znamená i runtime (interpretr, je jedno jestli AST a nebo bytecodu). No, a LISPi sou kompilovany, některý implementace ne, ale to je fuk. A s modernosti opatrně ano? Napiš mi v Jave třeba OS, rychlí interpretr, real time řídící systém, hru s low nároky, AI většího rozsahu, simulaci atp...
    15.4.2015 10:39 aubi
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Neni mi jasny, v cem je rozdil mezi runtime a behovou platformou (ktere taky rikaji runtime)?

    Java ma virtualni stroj, ktery malo frekventovany kod interpretuje a casto frek. kompiluje do strojaku na zaklade presne informace o procesoru a statistice treba podminenych skoku, takze potencialne lip nez C. Minus drobny cas na kompilaci, samozrejme. Moje testy stejneho programu ukazaly stejny vykon Javy a optimalizovaneho C.

    Moje oblibena hra IL2 je v Jave a soude podle stacku pri prvnich pokusech o beh pod wine ma na starosti i kresleni. On cpu stejne jenom natlaci data do gpu. Jo a to tam je pribalena java 1.3, ktera opravdu interpretovala.

    U operacniho systemu (teda Linuxu) na kazdy kousek kodu koukaji stovky kritiku, viz diskuze exceptions vs. return codes. Jinak se radsi spolehnu na vymozenosti, ktere prosadila Java.

    S interpretem taky muzu slouzit - kolega testoval rychlost parseru v Jave (Derby) proti jednomu v assembleru. Dvojnasobne rychlejsi Java. Assembleristi a ceckari se opaji blizkosti k hardware, ale unikaji jim jakekoliv struktury slozitejsi nez pole.

    Koukam, ze bych si tady mel zalozit blog. :-D

    pavlix avatar 15.4.2015 10:48 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Moje testy stejneho programu ukazaly stejny vykon Javy a optimalizovaneho C.

    O tomto fenoménu jsem zatím slyšel jen v testech, nikdy v hodnocené reálného software, možná škoda.
    S interpretem taky muzu slouzit - kolega testoval rychlost parseru v Jave (Derby) proti jednomu v assembleru. Dvojnasobne rychlejsi Java.
    Což má ovšem nulovou vypovídací hodnotu.
    Assembleristi a ceckari se opaji blizkosti k hardware, ale unikaji jim jakekoliv struktury slozitejsi nez pole.
    To jistě. Když dneska začneš psát v céčku tak se ti do pozítří z hlavy vykouří všechny znalosti datových struktur.
    Koukam, ze bych si tady mel zalozit blog. :-D
    Tipuju, že už tu alespoň jeden máš.
    15.4.2015 16:51 Květináč
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Runtime jazyka je v dnešní době blbě definovaný slovo. Může to být interpret, může to být i podpůrná platforma jazyka. A nebo obojí. Interpret je jasnej. A je jedno jestli interpretuje AST nebo bytecode. A JIT je jen optimalizace interpretru. Podpůrná platforma může být GC, zabudovaný háčky pro debuger, profiler, podpora pro Lazy evaluation či něco na tendle způsob (třeba podpora reaktivity, FRP). V dnešní době se prostě musíme kouknout na jazyk, popřípadě na jeho implementaci, a zistit, do jaký kolonky to "runtime" patří. Takže tak.

    No a teď rychlost Javy a C. To je hruuuuza. Java je fajn jazyk (na něco). Ale táhne ji ke dnu banda evangelistů, ochotna pro zdůraznění rychlosti Javy udělat cokoli. Stejný trend sleduju bohužel i u Haskellu. Sakra probuďte se doprdele. Abys mohl porovnat rychlost C a Javy, musíš mít oba jazyky stejně rád a být v obou jazycích stejně dobrý, pak napsat program a porovnávat. Bohužel, takový evangelista je hotovej z Javy a schválně program v Cčku zkurvý. Buď schválně a nebo proto že je debil. A tak vznikaj výsledky jako že Java je 3 krát rychlejší než C. Jako viděl sem i případ kdy evangelista v Haskellu ukázal že je Haskell rychlejší než C. Pomoh si zmenšením počtu iterací algoritmu v Haskellu. Stejně je to i v Javě. Takže klid.

    A ta rychlost JIT. Kompilace kódu dost času sežere, a samotné zjišťování který kód se hodí pro kompilaci taky. Takže bohužel je to dost nezanedbatelný zdržení. Jen pomysli co potřebuješ. Kód musíš rozdělit na bloky. Každý blok musí mít ňáký counter použití. Ten counter musí být zamykaný, protože máme paralelní programy žejo ... dále před každým blokem musíme mít kód, který se rozhodne jestli to zkompilovat a nebo interpretovat. A ta kompilace není žádnej med, plus ještě dynamický linkování. A jakýkoli snahy o větší optimalizaci za běhu obvykle víc sežerou než dají.

    Takže ve výsledku, ano, když aplikace poběží dlouho, JIT interpretr bude takřka tak rychlí jako nativní kód. Ale to je pouze teorie. Praxe je jinde co tak sleduju programi v Jave a C# (GC v imperativních jazycích dělá svý, to taky ...).

    A naposledy, to že je něco napsanýho ručně v ASM pomalí není žádný div. V ASM je kurva těžký něco rychlího udělat. Ona to není sranda. Nemám tady teď ani čas a ani chuť psát proč, ale zkušenější mi daj za pravdu, že napsat v ASM něco rychlího vyžaduje fakt dokonalou znalost daný architektury a všech jejích zákoutí.

    Jo a ten kec o poli na konci ukazuje na tvoji neznalost. Naše imperativní architektury neznaj nic efektivnějšího než pole. Maj dobrou cache locality a naše paměť je jedno velký pole. Třeba takový Hash tabulky sou mnohem rychlejší na dnešních architekturách než search trees (rekurzivní struktury -> funkcionální struktury ...). Pole má přístup O(1), stromy O(LOG N). Až bude nějaká funkcionální počítačová architektura, bude to jinak, ale není. Zatím.
    20.4.2015 11:36 koudy
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Výborně napsané!

    Tak jako nemůžu jít s bouracím kladivem okopávat macešky, nemá moc velkou logiku psát OS v něčem co má GC. Naopak nějaké jednoduchý filtr textu zas nebudu psát v ASM.

    (myšleno jednoduché echo "burak" | sed sabaca > to_neni_o_vas_pane_reditely.txt )

    Aneb jak říká lidové moudro: "Pokud znáš jen kladivo, ke všemu budeš přistupovat jako ke hřebíku."
    pavlix avatar 20.4.2015 11:59 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    burak
    Co to má prosím být?
    20.4.2015 12:09 koudy
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Burák = burský ořech (neboli podzemnice olejná, latinsky: opravdu netuším :) )

    Nebo taky: http://www.tapetynaplochu.org/tapety/tapetynaplochu-org-1024x768-02082008123028.jpg
    20.4.2015 13:20 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    nemá moc velkou logiku psát OS v něčem co má GC
    Zahraju si dablova advokata a zeptam se: "Proc?"

    Kdyz si vemu klasicky mikrokernelovou architekturu, tak je absolutne jedno, jak funguji jednotlive servery a jak pracuji s pameti.

    Mimochodem, hromada vyzkumu v oblasti OS jde smerem, ze se upousti od low-level prace s pameti ala struct+malloc a pracuje se s objekty na vyssi urovni abstrakce, aby sla dokazovat korektnost a dalsi vlastnosti OS.

    Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
    20.4.2015 15:32 koudy
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.

    Nebudu si tu hrát na experta v OS a ani v programování, rád svuj názor zmením, poté co se dozvím nové informace :)

     

    Dle mého není dobré mít GC v kernelu z techto duvodu:

    Garbage collector si musí nejak uchovávat ukazatele na všechna alokovaná pole, což pro celý systém bude mít urcitou pametovou nárocnost a to pole musí procházet a uvolnovat - vytežuje CPU.

    Pokud budete GC delat u neceho jako síte - pokud bude každý paket dynamický, mužete vyhradit 1 procesor jen na uvolnování sítového provozu.

    (to asi preháním a muselo by to být velmi špatne navržené, ale tušíte kam mírím? - malé pametové (de)alokace x set/tisíc/... krát za sekundu - jde to rešit lépe, ale když má clovek možnost udelat neco rychle, nebo správne, jsou tací, kterí to udelají správne, ale urcite to nejsou všichni)

     

    Pro více procesorový systém musíte rešit, zda má GC bežet na každém CPU samostatne, nebo zda má bežet jedno pro všechna CPU/kde a jak budou uloženy struktury pro GC. (je vubec možné udelat GC vícevláknové pro každý procesor zvlášt?)

    Na to samozrejme navazuje problém se synchronizací mezi CPU, lokováním sdílených struktur.

    Hlavne si ale myslím, že bez GC je to rychlejší a méne nárocné na pamet.
    To je jen pár drobností které mne ted napadají.

    Všechny problémy jdou samozrejme rešit, ale nevím zda není jednodušší si proste pamet (od)alokovat dle potreby.


    Microsoft napsal OS v C# (singularity), ale presto nízkoúrovnové veci jsou v ASM/C.
    Trošku na me Singularity pusobí jako Hurd - obojí to je spíš akademická debata než OS a obe OS vyjdou ve stejnou dobu - až zamrzne peklo :)

    Omlouvám se za diakritiku - nějaká chyba ctrl+insert shift+insert.

    20.4.2015 15:55 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    (je vubec možné udelat GC vícevláknové pro každý procesor zvlášt?)
    Pokud procesory nesdílí paměť, pak ano.
    Na to samozrejme navazuje problém se synchronizací mezi CPU, lokováním sdílených struktur.
    Pokud sdílíte paměť, tak tyto problémy nastávají i bez GC – např. malloc to také musí řešit.
    Hlavne si ale myslím, že bez GC je to rychlejší a méne nárocné na pamet.
    Záleží, jak je to implementované.
    Všechny problémy jdou samozrejme rešit, ale nevím zda není jednodušší si proste pamet (od)alokovat dle potreby.
    Jednodušší to není, nicméně v některých situacích to může být nutné.
    20.4.2015 16:52 koudy
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Pokud procesory nesdílí paměť, pak ano.
    To má logiku :)
    Pokud sdílíte paměť, tak tyto problémy nastávají i bez GC – např. malloc to také musí řešit.
    Měl jsem na mysli i to, že GC musí procházet paměťové bloky se kterými nyní pracuje jiná část systému, ten blok se může měnit, zatímco ho chce GC číst a podobné synchronizační vychytávky.

    Free většinou volá přímo ten kdo vytvářel data, většinou přímo ten samý proces, takže nedochází ani k přepnutí procesů.

    Pokud už uvolňuje paměť někdo jiný než ten kdo ji vytvářel, většinou ten jiný proces s alokovanými daty pracoval, takže je má v cache a nemusí je odnikud tahat.
    Záleží, jak je to implementované.
    S tím si dovolím nesouhlasit - můžete to udělat méně náročné na procesor, ale pak to bude stát více paměti a naopak, ale nikdy to neuděláte rychlejší a zároveň méně paměťově náročné než malloc/free způsob uvolňování, pokud ty implementace budou kvalitativně stejné.

    Já vím, nikdy neříkej že něco nejde, protože se najde nějaký *** který neví že to nejde a udělá to, ale tady jsem si celkem jistý... [Citation needed] (sorry Randall Munroe, ale musel jsem :) )
    Jednodušší to není, nicméně v některých situacích to může být nutné.
    Jj to je fakt, jako líný programátor bych občas dal za GC zlatý prase :)
    20.4.2015 17:25 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    S tím si dovolím nesouhlasit - můžete to udělat méně náročné na procesor, ale pak to bude stát více paměti a naopak, ale nikdy to neuděláte rychlejší a zároveň méně paměťově náročné než malloc/free způsob uvolňování
    S GC můžete snadno sdílet části datových struktur a tím ušetřit paměť (a někdy i čas).

    Například s GC můžete implementovat hash consing – sdílení (strukturálně) stejných hodnot. Často se to používá v dokazovačích (implementuje se vlastní GC) a například autor dokazovače E píše, že tím ušetří 80% až 99,99% uzlů pro termy. Navíc tím ušetří i čas, neboť statistiku pro stejné termy nepočítá vícekrát.
    21.4.2015 10:45 koudy
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Nešlo by něco takového implementovat i bez GC?
    21.4.2015 11:06 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Nevím, jak. Abyste sdílenou datovou strukturu mohl bezpečně uvolnit, musíte vědět, že ji už nikdo nepoužívá – např. si průběžně vést evidenci, kdo ji používá (počítání referencí), nebo se vždy podívat, zda ji někdo nepoužívá (mark & sweep).
    21.4.2015 12:05 koudy
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Díky, nechtělo se mi číst to pdf celé.(možná že se začtu, jen na to teď není klid a čas) :)

    Jak jsem psal už jinde - správné nástroje na správné věci. V tomhle případě je to určitě zjednodušení.
    21.4.2015 12:36 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    V tom PDF jsou relevantní slajdy 49, 64-74.
    21.4.2015 14:35 koudy
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Ještě jednou díky, přečtu si to ještě podrobněji, ale překvapilo mě:

    "Allocating and chopping up large blocks does not pay off!"
    21.4.2015 12:39 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Mj. E pro banku termů používá mark & sweep.
    20.4.2015 17:27 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Měl jsem na mysli i to, že GC musí procházet paměťové bloky se kterými nyní pracuje jiná část systému, ten blok se může měnit, zatímco ho chce GC číst a podobné synchronizační vychytávky.
    Nemusi. Protipriklad: mikrokernel. Jednotlive casti OS jsou v oddelenych pametovych prostorech, takze prochazet pametove bloky cizich casti systemu evidentne nemusis.
    ale nikdy to neuděláte rychlejší a zároveň méně paměťově náročné než malloc/free způsob uvolňování, pokud ty implementace budou kvalitativně stejné.
    Protipriklad: Vezmi si ve smycce milionkrat free(malloc(20)) a pak to zkus zamenit za milionkrat (nejake) gc_malloc(20) + jednou full gc.
    Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
    21.4.2015 10:23 koudy
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Dobré připomínky. Beru v potaz :)
    20.4.2015 16:24 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Garbage collector si musí nejak uchovávat ukazatele na všechna alokovaná pole, což pro celý systém bude mít urcitou pametovou nárocnost a to pole musí procházet a uvolnovat - vytežuje CPU
    Ty ukazatele neni potreba uchovavat. Ona i bezna alokace ma nejakou rezii, jen to neni tak na ocich. Pocitani odkazu, ktere se bezne pouziva, je technicky vzato jen chudy pribuzny GC.
    Pokud budete GC delat u neceho jako síte - pokud bude každý paket dynamický, mužete vyhradit 1 procesor jen na uvolnování sítového provozu.

    (to asi preháním a muselo by to být velmi špatne navržené, ale tušíte kam mírím?
    Ne, netusim.
    Pro více procesorový systém musíte rešit, zda má GC bežet na každém CPU samostatne, nebo zda má bežet jedno pro všechna CPU/kde a jak budou uloženy struktury pro GC. (je vubec možné udelat GC vícevláknové pro každý procesor zvlášt?)
    Ne, nemusis. Navic muzes jit i tak daleko, ze muzes mit GC pro jednotlive moduly -- sitovani, FS, atp.
    Na to samozrejme navazuje problém se synchronizací mezi CPU, lokováním sdílených struktur.
    To je obecny problem i bez GC.
    Hlavne si ale myslím, že bez GC je to rychlejší a méne nárocné na pamet.
    Byly doby, kdy si lide mysleli, ze operacni system se da psat jen v ASM.
    Microsoft napsal OS v C# (singularity), ale presto nízkoúrovnové veci jsou v ASM/C.
    Toho nizkourovnoveho kodu tam bylo pomalu.
    Trošku na me Singularity pusobí jako Hurd - obojí to je spíš akademická debata než OS
    Singularity byl vyzkumny projekt, takze se opravdu nediv, ze kolem toho byla akademicka debata... Srovnani s Hurdem notne pokulhava.

    Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
    21.4.2015 10:36 koudy
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Ty ukazatele neni potreba uchovavat.
    Nějak snad musíte vědět, kterou paměť máte volnou a kterou někdo používá + alespoň velikosti alokovaných polí? (něco takového má samozřejmě i malloc)
    Ne, nemusis. Navic muzes jit i tak daleko, ze muzes mit GC pro jednotlive moduly -- sitovani, FS, atp.
    Není to pak zas o něco pomalejší? Pokud se GC musí rozhodovat jaký typ GC pro každé uvolnění použít? Nebo běží takové GC v rámci stejného vlákna/objektu? (něco na způsob contructor x destructor - jako že si každý uklízí sám po sobě)
    Byly doby, kdy si lide mysleli, ze operacni system se da psat jen v ASM.
    Point taken :)

    Srovnání singularity X hurd bylo spíš myšleno jako b*bý vtip, měl jsem ještě kocovinu a přišlo mi to vtipné (očividně pouze mě) ;)
    xkucf03 avatar 20.4.2015 21:50 xkucf03 | skóre: 46 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.

    Pokud budete GC delat u neceho jako síte - pokud bude každý paket dynamický, mužete vyhradit 1 procesor jen na uvolnování sítového provozu.

    (to asi preháním a muselo by to být velmi špatne navržené, ale tušíte kam mírím? - malé pametové (de)alokace x set/tisíc/... krát za sekundu - jde to rešit lépe, ale když má clovek možnost udelat neco rychle, nebo správne, jsou tací, kterí to udelají správne, ale urcite to nejsou všichni)

    Tohle by mělo jít řešit tím, že na různých úrovních budu používat různé (vhodné) nástroje, ne? Síťový provoz, tahání dat z disku a spousta dalších věcí by se řešila klasicky. A jinde, kde tolik nezáleží na rychlosti a nejde o milionkrát opakované činnosti, ale naopak je tam složitější byznys logika, by se používaly objekty, GC, RAII, výjimky a různé další vymoženosti. Někdo asi řekne, že tohle má řešit až aplikační logika, ale podle mě by to bylo užitečné už v tom OS resp. na rozhraní mezi OS a aplikacemi.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
    21.4.2015 13:09 koudy
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Tady to bylo myšleno (teda já to myslel) napsat celý kernel s GC.

    Jinak samozřejmě nevidím problém to udělat, postup jaký navrhujete Vy, mi přijde rozumný.

    Na druhou stranu je otázka zda není lepší napsat drivery a podobné věci nízkoúrovňově a ovládání nechat systémovým knihovnám, kde může být GC, objekty atd.
    21.4.2015 10:48 koudy
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Ok, přesvědčily jste mě, že by to asi bylo proveditelné...

    Existuje nějaký takový projekt?

    Slovy Linuse: Show me the code :)
    20.4.2015 13:20 koudy
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Dobře, možná to mohlo být o trošku méně arogantně, ale jinak souhlas :)
    14.4.2015 12:11 R
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Ani z Javy nemusism mat JAR, da sa tiez skompilovat do binarky. Vid gcj.
    14.4.2015 18:48 ava
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Ja dělám triviálně z javy "exáče" pomoci proguard + launch4j. Samozřejmě to stále vyžaduje k běhu JRE...
    14.4.2015 19:16 ava
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Díky moc za parádní článek! Sám používám RxScala (binding RxJava do scaly), tak jsem nesmírně rád za možnost srovnání s scalaz-stream.

    Chtěl jsem se zeptat na tvrzení o časové složitosti(cituji: "Například časová složitost zřetězení proudů bude záležet na uzávorkování: zřetězení uzávorkované doleva (tj. (a ++ b) ++ c) bude mít kvadratickou časovou složitost a zřetězení uzávorkované doprava (tj. a ++ (b ++ c)) bude mít lineární časovou složitost."). Jak to myslíte? Podle mě časová složitost bude vždy stejná, (pokud se bavím o RxJava), tak se vždy budou emitovat prvky nejprve z Observable a, pak b, pak c. Časová složitost podle mě bude vždy prostý součet složitostí jednotlivých observables, v čem se podle vás časová složitost liší?

    Jinak co se týče správy zdrojů, v RxJava je na ni operátor using.

    Těším se na popis terminologie (tak nějak očekávám, že tam budou nějaké zdroje, operátory a sinky, ale těším se na ucelené vysvětlení).

    Také jsem zvědavý na vytváření vlastních observables (či jak se to v scalaz-stream jmenuje :). Byl bych vděčný za příklad, kdy by se vytvářel stream unit-ů reprezentujících např. kliky ve swingovém tlačítku. V RxJava si můžu vybrat, zda chci přidat actionlistenera pro každého, kdo se o kliky zajímá, nebo zda se má přidat actionlistener pouze pokud je více než 0 posluchač, a kliky se multicastují (operator share), jak se něco podobného dělá v scalaz-stream? I když možná moc předbíhám ve výkladu :)

    Zrovna jsem se chystal, že bych si měl konečně přečíst Genuinely Functional User Interfaces od Antony Courtneyho a Conala Elliotta, tak to snad do příště stihnu, ať se trochu orientuji :)

    Tak se velmi těším, díky!
    14.4.2015 21:35 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Chtěl jsem se zeptat na tvrzení o časové složitosti(cituji: "Například časová složitost zřetězení proudů bude záležet na uzávorkování: zřetězení uzávorkované doleva (tj. (a ++ b) ++ c) bude mít kvadratickou časovou složitost a zřetězení uzávorkované doprava (tj. a ++ (b ++ c)) bude mít lineární časovou složitost."). Jak to myslíte?
    Byly myšleny dlouhé sekvence ++. Každé ++ vytvoří nové Observable. Čtete-li z ((a ++1 b) ++2 c) ++3 d (++ jsem očísloval), tak prvky z a jdou do Observable, jenž vytvořilo ++1, pak do Observable, jenž vytvořilo ++2, a nakonec do Observable z ++3. Takže, když těch ++ tam bude třeba milión, tak každý prvek z a musí projít miliónem Observable, ne?

    V RxScala to simuluje následující kód:
    import rx.lang.scala.Observable
    
    object HelloWorld {
      def leftAssoc(i: Int, acc: Observable[Int] = Observable.empty): Observable[Int] =
        if (i > 0)
          leftAssoc(i - 1, acc ++ Observable.just(i))
        else
          acc
    
      def rightAssoc(i: Int, acc: Observable[Int] = Observable.empty): Observable[Int] =
        if (i > 0)
          rightAssoc(i - 1, Observable.just(i) ++ acc)
        else
          acc
    
      def f(i: Int): Unit = {
        val l = leftAssoc(i)
        val r = rightAssoc(i)
    
        println("i = " + i)
        println("startingl")
        val x = System.nanoTime()
        l.subscribe(i => (), e => (), () => ())
        val x2 = System.nanoTime()
        println("startingr")
        val y = System.nanoTime()
        r.subscribe(i => (), e => (), () => ())
        val y2 = System.nanoTime()
        val bil = 1000 * 1000 * 1000
        println((x2-x) / bil,(y2-y) / bil)
      }
    
      def main(args: Array[String]): Unit = {
        Seq.range(1, 5).map(_ * 10000).foreach(f)
      }
    }
    
    Podle výstupu to však vypadá, že složitost je bohužel kvadratická, ať to uzávorkujete zleva nebo zprava:
    i = 10000
    startingl
    startingr
    (1,1)
    i = 20000
    startingl
    startingr
    (9,9)
    i = 30000
    startingl
    startingr
    (24,30)
    i = 40000
    startingl
    startingr
    (68,60)
    
    Navíc jsem si musel s RxScala zvětšit velikost zásobníku, aby mi to nepadalo. Analogický kód pro scalaz-stream je:
    import scalaz.concurrent.Task
    import scalaz.stream._
    
    object HelloWorld {
      def leftAssoc(i: Int, acc: Process[Task, Int] = Process.empty): Process[Task, Int] =
        if (i > 0)
          leftAssoc(i - 1, acc ++ Process(i))
        else
          acc
    
      def rightAssoc(i: Int, acc: Process[Task, Int] = Process.empty): Process[Task, Int] =
        if (i > 0)
          rightAssoc(i - 1, Process(i).toSource ++ acc)
        else
          acc
    
      def f(i: Int): Unit = {
        val l = leftAssoc(i)
        val r = rightAssoc(i)
    
        println("i = " + i)
        println("startingl")
        val x = System.nanoTime()
        l.run.run
        val x2 = System.nanoTime()
        println("startingr")
        val y = System.nanoTime()
        r.run.run
        val y2 = System.nanoTime()
        val bil = 1000 * 1000 * 1000
        println((x2-x) / bil,(y2-y) / bil)
      }
    
      def main(args: Array[String]): Unit = {
        Seq.range(1, 5).map(_ * 10000).foreach(f)
      }
    }
    
    Dává to výstup
    i = 10000
    startingl
    startingr
    (0,0)
    i = 20000
    startingl
    startingr
    (0,0)
    i = 30000
    startingl
    startingr
    (0,0)
    i = 40000
    startingl
    startingr
    (0,0)
    
    15.4.2015 11:28 ava
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Hmm, máte pravdu, že kód se zpomaluje alespoň kvadraticky s ++. Celkově je to pomalý šíleně (i když to asi není zrovna typický use-case). Zajímalo by mě, co to brzdí..

    Je váš scalaz-stream kód opravdu ekvivalentní? V RxScala řetězíte Observable.just, ale v scalaz-stream Process.empty, to asi nedělá to samé? Jinak není to nikde vyřčeno, ale pochopil jsem správně, že se scalaz-stream vám zásobník nepřetéká? Jak je to možné?
    15.4.2015 12:16 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Jinak není to nikde vyřčeno, ale pochopil jsem správně, že se scalaz-stream vám zásobník nepřetéká? Jak je to možné?
    Ano, nepřetéká. Obecně lze použít trampolíny a vlastní kód transformovat tak, že nebude potřebovat více než jedno volání na zásobníku. Myšlenka je jednoduchá: Funkce, které budete psát, nebudou volat žádné jiné funkce – místo toho, když budete chtít zavolat funkci, tak vrátíte nějaký objekt, který říká, co chcete zavolat. Když máte výsledek, vrátíte jiný objekt, který říká, že už nechcete nic volat. Tj. vracíte
    trait ReturnVal[A]
    // Vracím, když jsem skončil a mám výsledek.
    case class Result[A](a: A) extends ReturnVal[A]
    // Vracím, když ještě nemám výsledek a chci zavolat další funkci, která ho možná spočte.
    case class Cont[A](f: () => ReturnVal[A]) extends ReturnVal[A]
    
    K tomu napíšete interpretr – např. while cyklus nebo tail rekurzivní funkci, která bude opakovaně volat funkce vracející ReturnVal, dokud nedostane Result. Jediný, kdo něco volá, je tedy interpretr, takže hloubka volání je 1.

    To je jeden z triků, co se tam používá – je to ve třídách Trampoline a Task ze scalaz. Je to také popsáno v článku Stackless Scala With Free Monads.

    Bohužel důsledkem trampolín je ztráta výkonu a zvýšená alokace (alokace ReturnVal). Navíc máte jinou konvenci volání – trampolínované funkce nejsou kompatibilní s ostatními funkcemi.
    15.4.2015 12:18 ava
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Díky za vysvětlení. A ta ekvivalence kódu RxScala a scalaz-stream? :)
    15.4.2015 12:21 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Je váš scalaz-stream kód opravdu ekvivalentní? V RxScala řetězíte Observable.just, ale v scalaz-stream Process.empty
    Pokud se nepletu, tak leftAssoc(3), vytváří
    ((Observable.empty ++ Observable.just(3)) ++ Observable.just(2)) ++ Observable.just(1)
    
    resp.
    ((Process.empty ++ Process(3)) ++ Process(2)) ++ Process(1)
    
    což je stejné.
    15.4.2015 12:26 ava
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Ajo, nějakou selektivní slepotou jsem nedokázal vidět to volání Process(i) v *assoc, nechápu jak je to možné. Souhlasím, vypadá to stejně, díky.
    xkucf03 avatar 14.4.2015 23:32 xkucf03 | skóre: 46 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Ekvivalentní kód v Javě vypadá následovně:

    Jaký má smysl srovnávat na jedné straně Scalu + externí knihovnu a na druhé straně čistou Javu (jen standardní knihovnu)? Pro Javu existují spousty knihoven a není důvod, proč by v ní ten kód měl vypadat složitěji.

    BTW: kdo je autorem článku? Bývalo zvykem tu uvádět jména nebo přezdívky.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
    Saljack avatar 15.4.2015 00:19 Saljack | skóre: 28 | blog: Saljack | Praha
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Nehlede na to ze Java 8 to jde zapsat naprosto stejne pomoci streamu.
    Sex, Drugs & Rock´n Roll.
    xkucf03 avatar 15.4.2015 08:13 xkucf03 | skóre: 46 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    O tom jsem nedávno psal :-)

    Java 8: Stream API
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
    15.4.2015 09:11 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Jaký má smysl srovnávat na jedné straně Scalu + externí knihovnu a na druhé straně čistou Javu (jen standardní knihovnu)?
    Cílem bylo ukázat klasický imperativní zápis – je na něm vidět, co všechno kód ve Scale dělá (například se postará o otevření a uzavření zdrojů nebo nemusí číst soubory až do konce). Pro tento kód jsem zvolil Javu, neboť Scala standardně nemá break a ani speciální syntax pro automatickou správu zdrojů.
    xxxs avatar 18.4.2015 11:47 xxxs | skóre: 18 | blog: vetvicky
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    tiez ma zaujima autor.
    18.4.2015 14:22 MR
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Redakci jsem pozdal o doplneni autora, kterym je Radek Miček
    15.4.2015 11:14 extremni lama | skóre: 14 | blog: e_lama
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Začneme programem, který vypíše řádky souboru na standardní výstup ...
    open(F, "countries.txt");
    print <F>;
    
    Pokud by to teda nekdo chtel pomoci cyklu, tak:
    open(F, "countries.txt");
    while (<F>) {
            print $_;
    }
    
    myslim ze zustanu u perlu...
    The enemy of my enemy is still my enemy.
    pavlix avatar 15.4.2015 11:16 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Funkcionální programování ve Scale 1.
    Perl se mi moc líbil, když jsem ho zkoušel, ale psát programy bych v tom nechtěl.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.