Trilium Notes - relační mapy

21.11.2018 16:27 | Přečteno: 3201× | | poslední úprava: 21.11.2018 16:38

Skoro před rokem jsem tu představil svůj projekt Trilium Notes na správu "osobní znalostní báze" v blogpostu Trilium Notes - představení hobby projektu a pak nějaké nové featury v blogpostu Trilium Notes jako platforma pro mini-aplikace.
Dnes bych chtěl ukázat další featuru, kterou považuji za docela zajímavou - tou jsou "relační mapy".

S vysvětlováním ale musím začít od základů ...

Poznámka a její atributy

Poznámky jsou typicky o nějaké reálné věci (např. knize), která má nějaké atributy. V Triliu se tyto atributy dělí na:

• label je jednoduchá položka typu klíč-hodnota. Pro knihu může být label např. rokVydani=1984
• relace reprezentuje (orientovaný) vztah mezi dvěma poznámkami. U knih to může být v knižní sérii relace "následuje", tedy např. Návrat krále následuje Dvě věže následuje Společenstvo Prstenu.
  • relace je orientovaná, takže můžeme mluvit o "zdroji" (source) a "cíli" (target) relace

Pokud mluvím o atributech, tak tím myslím labely a relace dohromady.

Trilium používá atributy i pro některé pokročilejší "systémové" funkce - např. label sorted umístěný na poznámku znamená, že její pod-poznámky budou udržovány abecedně seřazené nebo že poznámka připojená jako cíl relace runOnNoteView se spustí při zobrazení zdrojové poznámky.

Dědičnost atributů

Poznámky jsou zařazeny do stromu a tak se nabízí myšlenka, že by atributy bylo možné v tomto stromě dědit - tzn. atribut uložený pro nějakou poznámku je automaticky "aktivní" i pro podpoznámky. Příkladem využití je label archived, který vyřadí poznámku z vyhledávání - typicky totiž chceme takto vyřadit celý podstrom, ne jen jednu poznámku.

Dědičnost je užitečná ale jen někdy - např. už zmíněný label rokVydani jaksi nemá smysl dědit do pod-poznámek knihy (které můžou obsahovat třeba výtažky, recenzi atp. u nichž tento label může být přímo zavádějící). Dědičnost je proto nutné explicitně zapnout pro daný atribut.

Trilium má pak ještě jeden typ dědičnosti, který dědí atributy přes relaci template , aniž by poznámky musely být ve vztahu předek - potomek. Později uvidíme na co to může být užitečné.

Potenciální idea do budoucna je možnost definovat určité aplikační nastavení jako atributy. Např. nastavení komprese a škálování uložených obrázků. Celý dokument může mít nastavenu JPEG kompresi na 70 (nastavením děděných atributů na kořen dokumentu) a některý podstrom toto může přenastavit na 90. Můžeme si tak ponastavovat aplikaci zvlášť pro různé podstromy.

Definice atributů

Atribut je ve své podstatě jen položka klíč-hodnota, kde jak klíč, tak hodnota jsou netypované řetězce. To je ale pro některé použití málo. Pokud si např. chci definovat label datumNarozeni, tak je docela blbé, aby do něj bylo možné zadávat jakýkoli řetězec v jakémkoli formátu - např. "22. 1. 2000", "první duben 89" atp. 

V Triliu je to řešeno trochu nestandardně tím, že existují dva další typu atributů - definice labelu a definice relace. Mezi atributy a jejich definicemi neexistuje přímé spojení. Funguje to tak, že definice určuje, jak pracovat s daným atributem, pokud se vyskytuje ve stejné poznámce. Přičemž "vyskytuje" bere v úvahu dědičnost. V praxi pak typicky vytváříme takové definice pro určitý podstrom - např. pokud máme některý podstrom vyhrazený pro lidi, tak takovou definici pro datumNarozeni podědíme v celém tomto podstromě.

A co můžeme v takové definici definovat?

• multiplicita - existuje pro jednu poznámku jen jeden takový atribut nebo jich může být několik?
• je atribut povýšený ( promoted )? - atributy jsou standardně ukryty v dialogu, tento příznak je povýší do hlavního UI poznámky (vidět možno níže)
• jen pro label: typ hodnoty - řetězec, číslo, datum, URL, boolean
• jen pro relaci: inverzní relace - např. relace isChildOf je inverzní k hasChild. Bude vidět níže.

Příklad jak takový výsledek definice může vypadat je toto:

Relační mapa

Relační mapa je nový typ poznámky (zatím dostupný jen v beta verzi 0.24), která vizualizuje poznámky a jejich relace. Níže můžete vidět proces tvorby takové relační mapy:

Tohle ale potřebuje vysvětlit:

1. Začínáme s existující (ale prázdnou) relační mapou.
2. Pod mapou jsou dvě existující poznámky, které mezi sebou již mají definovanou relaci isPartnerOf
   1. Tyto poznámky mají relaci template na poznámku "person", která obsahuje několik definicí atributů - např. ona relace isPartnerOf, label dateOfBirth atd.
      1. relace template je v tomto případě analogická konceptu jakéhosi typu nebo třídě poznámky
3. Ze stromu postupně přetáhneme obě existující poznámky a umístíme je na relační mapu. Hned vidíme již existující obousměrnou relaci (ve skutečnosti dvě orientované relace) isPartnerOf
4. Vytvoříme poznámku pro Charlese a "natáhneme" relace isChildOf k oběma rodičům.
   1. Poznámka je dle konvence vytvořena pod relační mapou (ale může být přesunuta kamkoli jinam)
   2. Tady si všimněme, že relace je vytvořena jako obousměrná, ale opačný směr se jmenuje hasChild. To je tím, že definice relace pro isChildOf specifikuje inverzní relaci hasChild (a naopak). Inverzní relace je pak automaticky dovytvořena.
5. Vytvoříme poznámku pro Dianu a natáhneme isPartnerOf relaci od Charlese. Opět je relace vytvořena jako oboustranná, protože definice relace isPartnerOf specifikuje inverzní relaci isPartnerOf. 

Závěr

Tento příklad s královskou rodinou je k dispozici v demo dokumentu Trilia - stačí tedy stáhnout a spustit poslední betu a můžete si s tím zkusit pracovat sami.

Demo v tomto blogpostu je tak trochu "kitchen sink" v tom, že jsem se do něj snažil nacpat několik konceptů dohromady, což může (oprávněně) vyvolat dojem, že je to celé hrozně složité. Ve skutečnosti je ale možné začít daleko jednodušeji - stačí pár poznámek, pár relací a relační mapa. Pokročilé koncepty jako inverzní relace, dědičnost, template relace atp. jsou k dispozici pro náročnější použití.

Aktuální stav relačních map je tak nějak MVP. Je možné si představit další možnosti vizualizace - např. nějaké seskupování do větších celků, obarvování, nějaké vysvětlující poznámky přímo v diagramu - věci známé např. z UML diagramů. Co bude možné přidat se uvidí ...

       

Komentáře

[Josef Kufner]

Uvažoval jsi o nějakých hrátkách s ontologiema, OWL, RDF a tak vůbec?

[Cal]

Prestoze k tomu oznaceni "znalostni baze" svadi, tak v tomto smeru plany nemam ...

Snazim se byt pragmaticky - vetsina veci, co si tak clovek potrebuje zaradit a "katalogizovat" je dost neformalnich. I tyhle relace a jejich mapy povazuju spis za doplnek, ktery se muze hodit pouze pro nektere specificke druhy poznamek. Hratky s ontologiemi atp. by bylo otevreni pandoriny skrinky a zaroven odklonu od pragmatismu nekam jinam ...

[OldFrog {Ondra Nemecek}]

Začíná to být docela zajímavý soft...

[Bystroushaak]

Velmi pěkné.

Já jsem se nedávno rozhodl taky pustit do psaní vlastní osobní wiki, s tím že u toho chci provést experimenty s interní strukturou v prototypovém jazyce a práci s objekty přímo z té wiki. Uvidíme, jestli z toho něco bude.

Co by mě zajímalo, tak jak hodnotíš použití Electronu? Nějakou dobu jsem přemýšlel co vlastně použít a Electron mi čím dál víc vychází jako nejracionálnější možnost, tak by mě zajímaly tvoje zkušenosti.

[Cal]

Je to siroke tema, zkusim napsat nejake dojmy:

• JavaScript jako jazyk usel dlouhou cestu a vlastne se mi v nem pise dobre. Da se v nem programovat castecne funkcionalne (arrow funkce, map/filter/reduce ...), async/await je obrovsky posun, ma to pekne ficury jako destructuring, stringova interpolace atp. Moderni JS preferuju oproti treba Pythonu.
• Stejne tak CSS je dost jiny beast nez to byvalo. S pomoci CSS Grid a Flexbox uz jdou konecne delat rozumne layouty.
• Single thread asynchronni model na node.js je pro desktopove aplikace dost zbytecny a komplikuje veci - jen async/await to dela trpitelnym. Komplikuje to ale veci jako transaction management (typicky delany pres ThreadLocal, tady se musi roubovat pres CLS). Vyjimky/stack tracy jsou stale dost na houby.
• S cim mam obcas problemy jsou nativni knihovny - napr. SQLite. Musi se zkompilovat a pak upravit pro kazdou platformu, pricemz to neni kompatibilni (ABI, nekdy i API) mezi major verzemi node.js. S tim SQLite mam pak problemy, ze na linuxu zavisi na konkretni verzi glibc.
• Na frontend i backend existuje velke mnozstvi kvalitnich (i nekvalitnich ofc) knihoven s milionem ruznych widgetu atp. Takovy vyber treba na QT nebude.
• Electron je dual process - jeden proces pro "chromium", jeden pro node.js, mezi nimi se komunikuje asynchronne pres IPC messagy, coz je trochu awkward, ale ve vysledku to docela funguje.
• Lidi stale narikaji na vykon, ale ja s tim problem nemam ani na starsim PC. V8 je dost rychle. Jedina slabina muze byt start aplikace, ale neni to zadna tragedie.
• Oproti kompilovanym jazykum si uzivam rychly feedback a iterace. Frontend reload/restart je s CTRL-R za sekundu, s backendem je to do 3 sekund.
• Nektere veci se delaji docela blbe - napr. "in page search" je z architekturnich duvodu dost slozite udelat a zrovna se mi to po upgrade na novy electron rozbilo. Pak jsou tam malickosti, treba ze neexistuji nativni (kontextove) menu a musis si to udelat od piky nebo pouzit existujici knihovnu ...
• Cele to na me pusobi jako takovy velky hack. Electron urcite neni vrchol designu, ale tak nejak to funguje a pokryva nekolik use casu zaroven.

[Bystroushaak]

Zkoušel jsi používat Electron bez JS? Co jsem tak koukal, tak jsou python bindingy (do JS backendu se pouštět nehodlám).

[Cal]

To jsem nezkousel (ani jsem vlastne o tom doted neslysel). Ale radeji bych se tomu vyhnul - cekal bych, ze to bude mit vic problemu vzhledem k tomu, ze to neni uplne mainstream, bude to mit mensi podporu v toolingu (napr. electron-packager) atp. Pokud k tomu neni silny duvod, tak se vyplati jit spis s mainstreamem ...

[Bystroushaak]

No, nezlob se že to tak řeknu, ale co se mě týče, tak se nebudu přeorientovávat na javascript, to by byl jeden krok vpřed, deset kroků zpět a tři kroky směrem do dimenze pátého kruhu pekla.

Co tak chápu Electron, tak by s tím neměl být moc problém, s tím že ti můžou chybět nějaké high-level featury. Ale díky za upozornění, prvně to experimentálně vyzkouším.

Pokud k tomu neni silny duvod, tak se vyplati jit spis s mainstreamem ...

S tímhle přístupem bys nemusel programovat vlastní aplikaci a rovnou mohl používat evernote ;)

[Cal]

No ja jen mam dojem ze JS ma ne uplne zaslouzene spatnou povest. Jinak obecne povazuju dulezitost jazyka za precenovanou (obzvlast tady v ramci jedne kategorie).

S tímhle přístupem bys nemusel programovat vlastní aplikaci a rovnou mohl používat evernote ;)

No tech nespocet spalenych hodin ukazuje na to, ze to bude asi pravda. Jinak samozrejme ta cena vyhybani se mainstreamu muze byt prijatelna, jen je potreba ji mit na pameti pri rozhodovani.

[Bystroushaak]

No ja jen mam dojem ze JS ma ne uplne zaslouzene spatnou povest.

Javascript jako takový je potrat, pro který neexistuje omluva. Ecmy to sice zlepšují, ES6 byl skoro fajn jazyk, ale stejně nemám důvod se do toho pouštět a zdaleka to nevyvažuje negativa (horší tooling, toxická komunita, nepraktičnost pro cokoliv jiného kromě webu).

No tech nespocet spalenych hodin ukazuje na to, ze to bude asi pravda. Jinak samozrejme ta cena vyhybani se mainstreamu muze byt prijatelna, jen je potreba ji mit na pameti pri rozhodovani.

To chápu a v principu s tím i souhlasím. Ostatně nejsem nadšený začátečník a do něčeho takového se pouštím s plným vědomím.

Jinak obecne povazuju dulezitost jazyka za precenovanou (obzvlast tady v ramci jedne kategorie).

K tomuhle mám dost komplikovaný přístup, kterým bych mohl popsat nejeden blog, ba možná i knihu.

Pro tohle chci použít python, protože s ním mám víc jak 14 let zkušeností a cca pět let z toho komerčně na každodenní bázi. Viděl jsem jeho výšiny i hlubiny, hackoval ho zleva i z prava, v cpythonu, v javascriptovém brythonu i v pythonním pypy. Je pro mě jako motor, na kterém patnáct let jezdím, a který jsem nespočetněkrát rozebral i složil. S ním si troufnu kolem světa nikoliv protože by byl tak skvělý, ale protože ho umím kdykoliv opravit a domlátit do něj kladivem co potřebuji, i kdyby mě zrovna někdo vzbudil ve tři ráno. JS by tohle jen hodně těžko vyvažoval (mohl by, ale trvalo by to 14 let), i kdyby měl co nabídnout, což kromě nativního běhu v prohlížeči imho nemá.

Druhá věc je paradigma a filosofie. Co do paradigma, tak v imperativním procedurálním jazyce už není moc co vymýšlet a vskutku je to prašť jako uhoď. Na poli objektových jazyků si ovšem myslím, že je pořád stále spousta prostoru, stejně jako u těch funkcionálních. Osobně momentálně dělám na klonu Selfu právě z důvodu, že mi přijde že potenciál prototypově objektově orientovaných programovacích jazyků byl javascriptem neprávem zabit a díky tomu stále ještě nebyl plně objeven a využit. Celé je to samozřejmě experiment, který může skončit špatně, ale i tak jsem na něj zvědavý a stojí mi za práci a čas.

[Bystroushaak]

*14/11, wtf?

[Emilek]

Nic si z toho nedělej, Bystroushaak se dokázal naučit jen Python a od toho se už nikdy nehne. Všechno ostatní je pro něj zlo, protože na to nemá. Nemá tedy cenu se snažit o objektivní diskuzi, choose your battles.

[Bystroushaak]

Python používám, protože má pro mě objektivně měřeno nejlepší poměr čas/výkon.

V javascriptu jsem dělal několik projektů, stejně tak v C (byl to můj první placený programátorský projekt, ale poměrně často v něm dělám v práci python moduly), C# a Javě (celá VŠ). Nedávno jsem placeně dělal menší projekt v Rustu, poslední tři roky jsem strávil s Rebolem, Lispem, Smalltalkem a Selfem. K tomu taky pár let D, o kterém jsem tu psal několik blogů a z kterého projekty http clienta a html parseru jsou pořád jedny z mých nejvíc starovaných projektů na githubu. Taky jsem napsal svůj díl v 8051 a x86 assembleru.

Pokud se ti to zdá málo, tak si naser.

[Bedňa]

Myslím si že vieš, že si ťa ako hackra vážim.

Mno Python nie je tiež bez chyby. Osobne som v ňom opravil len pár bugov v programoch, ale podľa mňa taký "for" bude mať v Pythone dosť race condition pretože vo väčšine jazykov je prepis podobný s asemblerom, čiže vloženie hodnoty a inkrementovanie. Je to jedna z vecí čo ma na Pythone sere a druhá je, že čo kurva majú proti závorkám.

Zrovna teraz za posledné dva dni som si púšťal videá o Pythone, tak ma neber, že som proti, skôr sa rozmýšľam, či to bude môj obľúbený jazyk, alebo si napíšem svoj sám, ktorý by sa ti určite aj páčil, keď som čítal tvoje blogy o "skutočnom objektovom progarmavani", alebo to boli len odpovede v diskusiách, je to asi jedno.

Javascript má chyby, ktoré serú všetkých, napr. nejednosť ako sa dostať k údajom, mno je tu jedna veľká výhoda, že to sere veľkú časť populácie a budú sa asi diať zmeny. Takže sa to nejak zjednotí, aby sme mali všetci radosť. Tak veľká komunita vývojárov sa proste ignorovať nedá.

Keď si sa pýtal na Electron, tak v tom som nenapísal ani riadok, je to viac lowlevel než napríklad NWjs v ktorom som už pár projektov napísal. Hlavne prečo som si zvolil NWjs je, že výzor si napíšem v klasickom HTML a ten JavaScript tam pridám len ako bonus, toto v Electrone neexistuje. Mno a NWjs projekty mávajú tak 50% veľkosti oproti Electron.

Do NWjs si môžeš pridať Python_console, neskúšal som to ale rýchlosť bude asi dosť slabá, hoci pre Pythonistov na jednoduché projekty to môže byť zaujímavé.

Čo sa chystám ešte naučiť, je Vuido, mno je to JavaScript, ale bez nutnosti si ťahať so sebou prehliadač aka Chromium a pomocou libui sa to natívne vykresľuje podľa platformy Linuz => GTK+, macOS => Cocoa a MS => Win. Výsledný kód je tiež malý, pretože si GUI nebalí so sebou sebou žiadny prehliadač, len binding na natívne GUI.

[Bystroushaak]

Mno Python nie je tiež bez chyby. Osobne som v ňom opravil len pár bugov v programoch, ale podľa mňa taký "for" bude mať v Pythone dosť race condition pretože vo väčšine jazykov je prepis podobný s asemblerom, čiže vloženie hodnoty a inkrementovanie. Je to jedna z vecí čo ma na Pythone sere a druhá je, že čo kurva majú proti závorkám.

Závorky jsou koncept imho vzniklý jen kvůli náročnosti parserů a neschopnosti tehdejších řádkových editorů. Python, ale i Smalltalky dokazují, že nejsou třeba a je to jen zbytečný fluff, který nic co by mělo nějakou hodnotu nepřidává. To s tím forem a race condition nechápu vůbec.

Python určitě není bez chyby, mohl bych vypsat spoustu věcí, které jsou na pythonu špatně, či nedobře řešené. Je to ovšem velmi pragmatický a praktický jazyk, jehož použitelnost je vysoká a málokdy se v něm střelíš do nohy. To o JS říct nejde.

Javascript má chyby, ktoré serú všetkých, napr. nejednosť ako sa dostať k údajom, mno je tu jedna veľká výhoda, že to sere veľkú časť populácie a budú sa asi diať zmeny. Takže sa to nejak zjednotí, aby sme mali všetci radosť. Tak veľká komunita vývojárov sa proste ignorovať nedá.

Javascript má hlavně problém absence jakékoliv vnitřní logiky a vize. Známé je napříkald wtf.js, nebo wtfjs, což oboje z větší části ukazuje totální shnilost typového systému. Python má taky svoje (viz wtfpython), ale přijde mi to podstatně konzistentnější a má to nějaký vnitřní model, co se dá pochopit.

Keď si sa pýtal na Electron, tak v tom som nenapísal ani riadok, je to viac lowlevel než napríklad NWjs v ktorom som už pár projektov napísal. Hlavne prečo som si zvolil NWjs je, že výzor si napíšem v klasickom HTML a ten JavaScript tam pridám len ako bonus, toto v Electrone neexistuje. Mno a NWjs projekty mávajú tak 50% veľkosti oproti Electron.

NWjs neznám, mrknu na to. Osobně jsem zatím ve fázi hledání, skutečně jsem se odhodlal pustit se do toho projektu po pár letech psaní poznámek a přemýšlení až minulý týden.

[Bedňa]

Občasne musím zachrániť svet, tak zas som v tejto fáze.

OK, Pythonistov rešpektujem a sledujem minimálne od tejto konferencie PyCon 2011 Qtile Lightning Talk Friday Afternoon, kde som si skoro cvrkol.

Jako fakt berem to, JavaScript sa proste zlepšuje a keď nechceš písať v ňom, tak si vyberieš niečo nad ním, napríklad Python. V tom je momentálne sila, že JavaScript sa momentálne stáva len taký objekt kód pre písanie webGL aplíkacií v hocijakom jazyku atď. nad ním.

[Bedňa]

To s tím forem a race condition nechápu vůbec

Proste sa ten cyklus musí nejak spracovať, namiesto naplnenia premenných a inkrementácií +-

[Bystroushaak]

for v pythonu pracuje nad iterátory. Je to úplně něco jiného, než for cyklus v C. Jak vypadá iterace přes iterable object je možné vidět například v builtin funkci all():

static PyObject *
builtin_all(PyObject *module, PyObject *iterable)
/*[clinic end generated code: output=ca2a7127276f79b3 input=1a7c5d1bc3438a21]*/
{
    PyObject *it, *item;
    PyObject *(*iternext)(PyObject *);
    int cmp;

    it = PyObject_GetIter(iterable);
    if (it == NULL)
        return NULL;
    iternext = *Py_TYPE(it)->tp_iternext;

    for (;;) {
        item = iternext(it);
        if (item == NULL)
            break;
        cmp = PyObject_IsTrue(item);
        Py_DECREF(item);
        if (cmp < 0) {
            Py_DECREF(it);
            return NULL;
        }
        if (cmp == 0) {
            Py_DECREF(it);
            Py_RETURN_FALSE;
        }
    }
    Py_DECREF(it);
    if (PyErr_Occurred()) {
        if (PyErr_ExceptionMatches(PyExc_StopIteration))
            PyErr_Clear();
        else
            return NULL;
    }
    Py_RETURN_TRUE;
}

Tedy nad objektem voláš iternext(), dokud tam něco je. For samotný se překládá na konkrétní instrukce v podobném smyslu:

$ python3
Python 3.6.6 (default, Sep 12 2018, 18:26:19) 
[GCC 8.0.1 20180414 (experimental) [trunk revision 259383]] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def xe():
...  for i in range(5):
...   print(i)
... 
>>> import dis
>>> dis.dis(xe)
  2           0 SETUP_LOOP              24 (to 26)
              2 LOAD_GLOBAL              0 (range)
              4 LOAD_CONST               1 (5)
              6 CALL_FUNCTION            1
              8 GET_ITER
        >>   10 FOR_ITER                12 (to 24)
             12 STORE_FAST               0 (i)

  3          14 LOAD_GLOBAL              1 (print)
             16 LOAD_FAST                0 (i)
             18 CALL_FUNCTION            1
             20 POP_TOP
             22 JUMP_ABSOLUTE           10
        >>   24 POP_BLOCK
        >>   26 LOAD_CONST               0 (None)
             28 RETURN_VALUE

což je trošku komplikovanější, protože se to interpretuje v bytecode cruncher looopu v ceval.c:

        case TARGET(FOR_ITER): {
            PREDICTED(FOR_ITER);
            /* before: [iter]; after: [iter, iter()] *or* [] */
            PyObject *iter = TOP();
            PyObject *next = (*iter->ob_type->tp_iternext)(iter);
            if (next != NULL) {
                PUSH(next);
                PREDICT(STORE_FAST);
                PREDICT(UNPACK_SEQUENCE);
                DISPATCH();
            }
            if (PyErr_Occurred()) {
                if (!PyErr_ExceptionMatches(PyExc_StopIteration))
                    goto error;
                else if (tstate->c_tracefunc != NULL)
                    call_exc_trace(tstate->c_tracefunc, tstate->c_traceobj, tstate, f);
                PyErr_Clear();
            }
            /* iterator ended normally */
            STACK_SHRINK(1);
            Py_DECREF(iter);
            JUMPBY(oparg);
            PREDICT(POP_BLOCK);
            DISPATCH();
}

Samozřejmě, pro čísla je to kapku míň efektivnější, než C, ale zase to umí iterovat na libovolným objektem implementujícím protokol iterátorů. V pypy interpretru se to pak afaik ještě jituje a leze z toho relativně efektivní kód.

[Bystroushaak]

Ad pypy, viz FOR_ITER v pyopcode.py:

    def FOR_ITER(self, jumpby, next_instr):
        w_iterator = self.peekvalue()
        try:
            w_nextitem = self.space.next(w_iterator)
        except OperationError as e:
            if not e.match(self.space, self.space.w_StopIteration):
                raise
            # iterator exhausted
            self.popvalue()
            next_instr += jumpby
        else:
            self.pushvalue(w_nextitem)
        return next_instr

Nutno myslet na to, že celý kód je pak na úrovni AST analyzován a je z něj vygenerováno ekvivalentní C, které je potom na základě statistik jitováno do asm podle analýzy typů rpythonem.

[Bedňa]

Dík za vyčerpávajúcu odpoveď, tak na čísla to bude určite menej efektívne, ale je to OK.

[Josef Kufner]

Nadávání na výkon jsou hlavně kvůli paměťové rozežranosti Chromia/Chrome.

[kralyk z abclinuxu]

Už může člověk v JS v praxi používat nové ES6 moduly? (A nemyslim tim jen podporu ze strany browseru/Node.js, která vim, že je, ale spíš mi jde o to, jestli to podporuje i ekosystém.)

[Cal]

Myslim, ze jo (vidam obcas v README projektu), ale v praxi to vyzkousene nemam. ES6 moduly pouzivam pro vlastni kod, ale externi zavilosti bud taham tradicne pres skript tag nebo pres line/lazy az pri pouziti.

Trochu OT, ale jsem z nich trochu rozpacity, protoze a) nejdou tahat line/lazy (treba jako CommonJS require) a b) mohou byt pomalejsi nez standardni script tagy, protoze musi byt "objeveny" az v potencialne serii zavislosti, napr. A zavisi na B zavisi na C zavisi na D - A, B, C, D se musi loadovat jeden po druhem a nejde to paralelne (ale rozdily asi nebudou velke).

[Josef Kufner]

To objevování závislostí probíhá při "kompilaci" (minifikaci) kódu do jednoho balíčku, který se pak posílá do prohlížeče. Takže ve výsledku to je vlastně úplně jedno.

[kralyk z abclinuxu]

On mluví o on-demand loading z prohlížeče, není to jedno...

[Cal]

Ja mam prave rad ten 0-step build a proto zadnou minifikaci/bundling nepouzivam. Ono je to cele spis takova obezlicka kvuli omezenim HTTP1 (resp. limitu prohlizecu), v HTTP2 by stahovani vetsiho mnozstvi malych souboru problem byt nemel. Ale je fakt, ze konkretne tohle postupne stahovani zavislosti bundling resi bez ohledu na verzi HTTP.

Jinak abych dovysvetlil ten lazy loading - nektere knihovny (text editor, code editor, markdown ...) jsou pomerne velke a jsou potreba jen nekdy a proto je chci tahat line, ale to ES6 moduly ani bundling neresi (workaround ale neni slozity). Prislo mi to docela zvlastni vzhledem k tomu, ze je to docela casty pozadavek a starsi CommonJS to umi, tak je to trochu krok zpet.

[Josef Kufner]

To se řeší tak, že každá ta větší věc má svůj entry point, od kterého se odpíchne řešení závislostí. Pak takový editor, který je jen někde, stahuje dva bundly: společný, který je všude, a pak ten pouze s editorem. Některé frameworky na to pak mají všelijaká udělátka, aby si tu extra závislost vyžádaly. V případě serverových frameworků to pak umí i poslat napřed v rámci HTTP/2 Server Push.

[Cal]

Jj, tak ono to samozrejme vyresit jde (urovni nad ES6 moduly), za cenu vyssi slozitosti reseni (konfigurace webpacku je nechvalne proslula).

Ja bundling povazuju za "stop gap" reseni, neco co by melo fungovat automaticky a transparentne, pravdepodobne na urovni webserveru (s nejakym JS pluginem). Server dostane request na entrypoint, server naparsuje cely staticky importovany bundle a HTTP2 server pushem je posle klientovi (klient je stale vidi jako ruzne soubory, jen jsou poslane najednou). Bundly si webserver muze cachovat, aby je nemusel buildovat pokazde od piky.

Jinak jak se tak divam, tak proposal na dynamicky import existuje a uz byl dokonce akceptovan do HTML standardu.

[Josef Kufner]

Jo, to by bylo ideální řešení. Ale ve výsledku je to jen o tom ve správnou chvíli zavolat Webpack.

[Josef Kufner]

Btw, neuvažoval jsi o použití Flow či Typescriptu? Docela to pomáhá jako dobrá prevence proti chybám.

[Cal]

V profesionalnim zivote jsem "strong typing fanboi", tak tenhle projekt jsem spis bral jako test, jake je to na te druhe strane barikady.

A celkem se mi to pro tento druh malych "one man show" projektu libi. Libi se mi rychlost feedbacku bez rekompilace, in browser REPL a debugger. Libi se mi ze tam nejsou zadne build stepy atp. Deployment u JS je ulozeni souboru.

Pred casem jsem pracoval na projektu v TypeScriptu (coz je jinak velmi pekny jazyk) a tam se tyto vyhody ztratily. Kompilace do JS nam trvala tak 20 sekund (behem niz clovek ztrati focus). Kouzlo se vytratilo.

Obcas nad tim premyslim a zda se mi, ze jen malo chyb v tomto projektu by se dalo kategorizovat jako "typove chyby". Rekl bych, ze je to tim, ze tak nejak mam stale vetsinu projektu ramcove v hlave (vicemene na nem kontinualne pracuju).

Dulezitost typu se v plne sile zacne projevovat u projektu s vice lidmi (nebo s jednim clovekem se spatnou pameti). Krome fakt jednoduchych projektu bych profesionalne dal urcite prednost TypeScriptu.

[kralyk z abclinuxu]

Já si vzpomínám naposledy, když jsem něco dělal v JS, TS byla celkem novinka. Spustil jsem tehdy TS "kompilátor" nad svým JS kódem víceméně jen tak ze zvědavosti, a našlo mi to chyby jen na základě type inference...

[Josef Kufner]

Jo, to je zhruba ten okamžik, kdy si člověk uvědomí, že pořádný typový systém, který není jen implementačním detailem (jako je tomu např. v C), je vlastně docela fajn věc.

[Bystroushaak]

Tak mě tak ještě napadlo - mohl bys popsat strukturu svojí osobní wiki? K čemu jí používáš, co tam trackuješ a tak? Sám jsem tu na tohle téma měl takový lehce filosofický blog, zajímalo by mě to ale praktičtěji, jestli od tebe nepochytím třeba nějaké zajímavé patterny.

[Cal]

To je dobry napad, ale je to tak siroke tema, ze si to zaslouzi zvlast blogpost.

[Ehm]

Napiš, spousta lidí o tom jenom dlouhá léta mluví a nic nedělá....