Sniffnet je multiplatformní aplikace pro sledování internetového provozu. Ke stažení pro Windows, macOS i Linux. Jedná se o open source software. Zdrojové kódy v programovacím jazyce Rust jsou k dispozici na GitHubu. Vývoj je finančně podporován NLnet Foundation.
Byl vydán Debian Installer Trixie RC 2, tj. druhá RC verze instalátoru Debianu 13 s kódovým názvem Trixie.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za červen (YouTube).
Libreboot (Wikipedie) – svobodný firmware nahrazující proprietární BIOSy, distribuce Corebootu s pravidly pro proprietární bloby – byl vydán ve verzi 25.06 "Luminous Lemon". Přidána byla podpora desek Acer Q45T-AM a Dell Precision T1700 SFF a MT. Současně byl ve verzi 25.06 "Onerous Olive" vydán také Canoeboot, tj. fork Librebootu s ještě přísnějšími pravidly.
Licence GNU GPLv3 o víkendu oslavila 18 let. Oficiálně vyšla 29. června 2007. Při té příležitosti Richard E. Fontana a Bradley M. Kuhn restartovali, oživili a znovu spustili projekt Copyleft-Next s cílem prodiskutovat a navrhnout novou licenci.
Svobodný nemocniční informační systém GNU Health Hospital Information System (HIS) (Wikipedie) byl vydán ve verzi 5.0 (Mastodon).
Open source mapová a navigační aplikace OsmAnd (OpenStreetMap Automated Navigation Directions, Wikipedie, GitHub) oslavila 15 let.
Vývojář Spytihněv, autor počítačové hry Hrot (Wikipedie, ProtonDB), pracuje na nové hře Brno Transit. Jedná se o příběhový psychologický horor o strojvedoucím v zácviku, uvězněném v nejzatuchlejším metru východně od všeho, na čem záleží. Vydání je plánováno na čtvrté čtvrtletí letošního roku.
V uplynulých dnech byla v depu Českých drah v Brně-Maloměřicích úspěšně dokončena zástavba speciální antény satelitního internetu Starlink od společnosti SpaceX do jednotky InterPanter 660 004 Českých drah. Zástavbu provedla Škoda Group. Cestující se s InterPanterem, vybaveným vysokorychlostním satelitním internetem, setkají například na linkách Svitava Brno – Česká Třebová – Praha nebo Moravan Brno – Břeclav – Přerov – Olomouc.
Byla vydána nová verze 8.7.0 správce sbírky fotografií digiKam (Wikipedie). Přehled novinek i s náhledy v oficiálním oznámení (NEWS). Nejnovější digiKam je ke stažení také jako balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo ke spuštění a spustit.
Brendan Eich, mj. autor JavaScriptu, spoluzakladatel Mozilly a její několikadenní CEO (zprávička), představuje v článku From asm.js to WebAssembly na svém blogu společný projekt Googlu, Microsoftu, Mozilly a dalších s názvem WebAssembly (GitHub, FAQ), jehož cílem je zvýšit výkon webových aplikací použitím univerzálního webového bajtkódu.
Tiskni
Sdílej:
podporovat i static typing (guards a trademarks)Koukal jsem na to a není mi jasné, jak budou fungovat parametrizované typy (například generika)?
Spise to vypada, ze oni ten jazyk opravi.Moc tomu nevěřím – nebude vůle udělat změny, které poruší zpětnou kompatibilitu. Spíš to dopadne tak, že k těm starým a špatným věcem přidají paralelně nové a lepší věci. V praxi se pak bude používat oboje a jazyk bude velice komplikovaný (na to, co umí, je komplikovaný už nyní). Například do ES 6 přidali generátory, což je IMO krok špatným směrem, uvažuje se o přidání async a await, což je IMO další krok špatným směrem. Pak třeba zjistí, že oboje vede na duplikaci kódu (viz příklad s
IEnumerable
z mého zápisku Algebraické efekty), a přidají vymezené kontinuace, které subsumují generátory i async a await.
Například do ES 6 přidali generátory, což je IMO krok špatným směrem, uvažuje se o přidání async a await, což je IMO další krok špatným směrem.Proč? Ten blog jsem více/méně četl, ale stejně mi to z toho není jasné.
Array.prototype.forEach
).
Druhý způsob generování prvků: Generátor – vrací objekt iterátor, jehož metodu next
můžeme volat, když chceme další prvek.
Výhodou prvního způsobu je, že takové funkci je snadné programovat. Jeho nevýhodou je, že cizí funcke řídí náš kód (inversion of control) – v některých případech může být těžké takovou funkci použít.
Naopak výhodou druhého způsobu je snadnost použití generátorů, jeho nevýhodou je, že se generátory těžko programují.
Aby ECMAScript odstranil nevýhodu druhého způsobu, přidal speciální podporu pro generátory. Tato podpora umožňuje psát generátory jako funkce z prvního způsobu – hlavní rozdíl je, že místo volání předané funkce voláme yield
a funkce je deklarována pomocí function*
.
Tato speciální podpora však neřeší nevýhodu prvního způsobu. Pokud máte například API, kde je pouze map
, tak vám podpora generátorů nepomůže – musíte počkat, až autor API přidá generátor.
Existuje však jiné řešení, které žádné generátory nepotřebuje a odstraní obě nevýhody. Tím řešením je převést první způsob na druhý. Je mj. snadné převést druhý způsob generování na první způsob. Převod naopak lze uskutečnit pomocí vymezených kontinuací nebo pomocí vlákna, mutexu a proměnné sdílené vlákny. Pokud ECMAScript bude podporovat green thready, nepotřebuje generátory.
To, co mi tedy vadí na generátorech je, že řeší problém jen napůl (neodstraňují nevýhodu prvního způsobu generování), komplikují jazyk a možná budou zbytečné, protože stejnou službu udělají green thready.
Kromě toho jsou tu otázky ohledně časové složitosti – jakou bude mít například ES analog následujích enumerátorů časovou složitost? Lineární nebo kvadratickou?
static IEnumerable<int> LeftAssocEnum(int i) { var acc = Enumerable.Empty<int>(); while (i > 0) { acc = Enumerable.Concat(acc, new int[] { i }); i--; } return acc; } static IEnumerable<int> RightAssocEnum(int i) { var acc = Enumerable.Empty<int>(); while (i > 0) { acc = Enumerable.Concat(new int[] { i }, acc); i--; } return acc; }Mj. v C# mají oba enumerátory kvadratickou složitost a oba z nich způsobí přetečení zásobníku pro dostatečně velké
i
. Nicméně v rozumné implementaci by RightAssocEnum
měl mít lineární časovou složitost a k žádnému přetečení zásobníku by u něj dojít nemělo.
function*
, navíc se takto označené funkce chovají jinak než klasické funkce označené function
. Green thready jsou tedy obecnější.
Když mám green thready, nemusím dopředu rozhodovat, zda nějaká funkce bude generátor – například map
mohu, jak jsem zmínil, použít jako generátor (bez toho abych něco přepisoval) – tj. vytvořím funkci, která vrací iterátor a tento iterátor uvnitř používá map
.
function*
.
Stejne tak preteceni zasobniku - implementace muze pouzivat segmented stack a tim se presune problem s alokaci do heapu.Oboje lze implementovat s konstantním zásobníkem a s lineární časovou složitostí. Je jen otázkou, jak chytrá je implementace. Příkladem takové implementace je knihovna scalaz-stream.
novy standard programovani vyrazne zjednodusujeMožná zjednodušuje programování, nicméně pochybuji, že zjednodušuje jazyk. Například verze 5 specifikuje jazyk na 100 stranách, verze 6 na 260 stranách.
Mozna koukate na jiny standard, ale verze 5.1 ma 258 stran, a verze 6.0 ma 566 stran.Bral jsem jazyk bez standardní knihovny – přijde mi to lepší pro odhad složitosti jazyka – a také jsem se spletl, v případě ES 6 to je více stran. Například oproti specifikaci Standard ML, která má pod 100 stran, je to celkem výrazný rozdíl.
v dalsich revizich muze byt vyjmuta.Jen dobře, pokud bude.
Například oproti specifikaci Standard ML, která má pod 100 stran, je to celkem výrazný rozdíl.To je nesmysl srovnavat podle stran, nebot se nejedna o dokumenty vytvorene pro jednu standardizacni instituci podle stejnych pozadavku. Lepsi priklad by byl treba Dart.
Koukal jsem na to a není mi jasné, jak budou fungovat parametrizované typy (například generika)?Pouzijete guards, ktere zajisti, ze v danem bloku kodu se pouziva pouze deklarovany trademark (typ). Kompilatoru pak zoptimalizuje genericky blok kodu pro dane typy. Stale je to otevrene, ale staticke typy v nejake forme budou.
a jazyk bude velice komplikovanýHorsi nez C++ ci rust to nebude.
Například do ES 6 přidali generátory, což je IMO krok špatným směrem, uvažuje se o přidání async a await, což je IMO další krok špatným směrem.Vsechno to ma byt postavene nad spawn, ktery ma bezet na green threads, takze blokovani neni az tak velky problem.
Pokud zarizeni nepodporuje WebAssembly - bude jich jeste dlouho plno, je Javascript fallback a nikdo to nebude psat dvakrat.Jako fallback muze byt interpretace WebAssembly pomoci JS. Nebo JIT preklad WebAssmebly do JS, ktery pak bude prolozeny JIT do nativniho kodu. ;-]
Spise to vypada, ze oni ten jazyk opravi.IMHO je JS FUBAR. Jak uz psal Radek Micek, ten jazyk obsahuje spoustu spatnych vlastnosti od zacatku a nikdo nebude mit odvahu rozbit zpetnou kompatibilitu... uz jenom kvuli tomu velkemu mnozstvi programatoru. Leda, ze by zavedli nejakou direktivitu (ala Perl), ktera by rikala, ze kod je napsany pro konkretni verzi JS.
"use more strict"
IMHO je JS FUBAR.To jsem si myslel take, a kdyby se mi zdalo o programovani v javascriptu, musel bych memit pyzamo, jak bych byl zpoceny hruzou. Rozdil oproti jinym jazykum je v tom, ze JavaScript se zatim pouziva v prostredi, kde zivotnost aplikaci beze zmen je v radu mesicu, zivotnost zarizeni v radu let, a prohlizec se updatuje kazdy mesic. To jim umoznuje delat i zpetne nekompatibilni zmeny, kde se kompatibilita docasne vyresi, jak bylo naznaceno vyse, pridanim dalsi direktivy.
Pokud zarizeni nepodporuje WebAssembly - bude jich jeste dlouho plno, je Javascript fallback a nikdo to nebude psat dvakrat.Dneska je v módě psát překladače do javascriptu.
Pokud používáte staticky typovaný jazyk, tak kód budete moci psát v něm, přeložit do WAsm a ono to poběží rychleji, než kdybyste to napsal přímo v ECMAScriptu. Kdo by pak používal ECMAScript?Určitě se počítá s tím, že JS se bude do WebAsm taky překládat. Jinak JS mi přijde jako celkem dobrý jazyk. Má svoje mouchy, ale určitě to není špatný jazyk ve smyslu skutečně špatných jazyků, jako třeba PHP...
V čom sú prototypy dobré? Neberte to ako hate príspevok, len ma to zaujíma. V js istý čas robím, čítal som mnoho blogov ako v tom napr. napísať dedičnosť a stále neviem ako na to.
Jinak doporučuji tento článek: Why Does JavaScript Suck?Mně právě tyhle quirks vůbec nepřijdou tak hrozné. Když píšu v JS, používám kontrolu typů, operátor
===
a podobně. Souhlasim s tim automatickým středníkem, to mě taky onehdá vytočilo. Ten scoping nevidim jako problém - stejně je to jazyk s GC. Ten odstavec o globálních proměnných mi přijde přehnaný, nevim o tom, že bych musel používat globální proměnný vyjma window
. Jako jo, v JS určitě jsou nepříjemnosti, ale ten jazyk alespoň celkově nějak dává smysl a má nějakou koncepci narozdíl od PHP.
Uz ted vznikaji ruzne prekladace pres LLVM do JSTo je hrozně pomalé a výsledná velikost je většinou taky dost špatná. O dost použitelnější jsou překladače přímo do JS, jako třeba brython.