Dokumentin asetukset #499

Open dezhidki opened 9 years ago

In GitLab by @Smibu on Sep 28, 2015, 13:49

https://tim.jyu.fi/view/tim/TIMin%20kehitys/Dokumentin%20asetukset

Checklist

[x] Globaalit plugin-attribuutit
[x] Dokumentin css
[ ] KateX / MathJax -kytkimet
[x] Pluginkohtaiset globaalit attribuutit
[x] deadline / starttime
[x] makrot
[ ] Kommenttien mahdolliset tagit
[ ] asetusten ottaminen hakemiston settings.tim tiedostosta

In GitLab by @Smibu on Sep 28, 2015, 11:29

@vesal @juvalkee @tomijkarppinen Rupesin tätä tekemään; kokeilen ekaksi tuota uutta Dumboa joka tukee makroja; sitä ei ole vielä testattu eikä mergetty.

In GitLab by @Smibu on Oct 2, 2015, 17:25

@vesal @tomijkarppinen @juvalkee Laitoin tuotantoon tuen globaaleille plugin-attribuuteille ja dokun css:lle. Esimerkki:

``` {.collapsed settings=""}
global_plugin_attrs:
  stem: joku globaali
css: |!!
body {
  background-color: lightgray;
}
!!



Eli tuon täytyy olla dokun ensimmäinen kappale. Luokka `.collapsed` on sitä varten, ettei kappale turhaan näy, mutta siihen jää kumminkin pieni marginaali, josta sitä pääsee muokkaamaan. Mutta sen ei lukijaa pitäisi häiritä.

In GitLab by @Smibu on Oct 2, 2015, 22:03

@Smibu Tuossa

https://tim.jyu.fi/view/tim/koe/globaalit

on jotakin hämminkiä sillä jälkimmäisen pluginin attribuutit nousevat globaaleiksi. – Vesa Lappalainen

In GitLab by @Smibu on Oct 2, 2015, 22:38

@vesal En tainnut kokeilla kahdella pluginilla; on aavistus mistä johtuu. Kokeilen korjata.

In GitLab by @Smibu on Oct 2, 2015, 22:51

@vesal Korjattu; johtui siitä kun globaalit ja pluginin omat arvot yhdistettiin, niin tuo muutos jäi voimaan muillekin plugineille. Globaaleista arvoista pitää tehdä kopio ennen kuin kutsuu update.

In GitLab by @Smibu on Oct 3, 2015, 01:24

@Smibu Saisikos tuon mielluumin kuin display:none niin että siitä tehdään html joka on esim. vain

Tämä siksi, että nyt sisältö menee kokonaan HTML:ään ja nuo asetukset saattaisivat sisältää jotakin, jota html:än käyttäjän ei tarvitsisi nähdä. – Vesa Lappalainen

In GitLab by @Smibu on Oct 4, 2015, 19:23

@Smibu @juvalkee @tomijkarppinen Muutin tätä hieman niin, että tuon sisältö ei tulostu selaimeen.

Mutta tuosta plugien globaaleista tuli sen verran mieleen, että sillä voi näköjään myös sotkea jos samaa sanaa on hieman eri tarkoituksessa eri plugineista. Tämä jääköön käyttäjän päänsäryksi, mutta voisi olla lisäksi mahdollisuus jotenkin sanoa että tällä pluginijoukolle on globaalit muuttujat

global_plugin_attrs: csPlugin
  stem: joku globaali

onnistuisiko esim noin vaim ietn pitäisi tehdä? Samaa attribuutin nimeä ei taida saada toistaa. Voisiko sitä huijata sitten:

global_plugin_attrs_csPlugin:
  stem: joku globaali

eli kaappaisi tuosta attribuutin nimen loppuosasta sen pluginin nimen ja jos sitä ei ole, ne ovat totaalisen globaaleja. – Vesa Lappalainen

In GitLab by @Smibu on Oct 5, 2015, 12:26

@vesal @juvalkee @tomijkarppinen Ehkä voisi olla:

global_plugin_attrs:
  csPlugin:
    stem: asdasd
  mmcq:
    stem: qweqewqwe
  all:
    stem: kaikille

Eli stem olisi ensimmäinen näistä:

Pluginin oma attribuutti
Pluginkohtainen globaali (esimerkissä csPluginilla asdasd)
Globaali (esimerkissä kaikille)

Tämä ei ole oikein yhteensopiva nykyisen kanssa ellei sitten sovi, ettei tuota all-avainta tarvitse ollenkaan.

In GitLab by @Smibu on Oct 5, 2015, 20:33

@Smibu Tuo yhteensopivuus ei tällä hetkellä haittaa, koska kukaan ei ole käyttänyt tuota pluginin attribuutteja vielä. Kannattaisiko /voisiko tuole antaa jokin vakio-ID:n, jolloin olisi tarvittaessa helpompi listata kaikki globaalit asetukset jos noita haluaisi seurata? Silloinhan sille tulisi aina sama hakmeiston nimi kaikissa dokuissa?

@juvalkee @tomijkarppinen – Vesa Lappalainen

In GitLab by @Smibu on Oct 5, 2015, 21:40

@vesal @tomijkarppinen @juvalkee Tarviikohan noita kytkimiä nyt ollenkaan, kun tuo osaa nyt ladata MJ:n automaattisesti tarvittaessa, jos katex failaa?

In GitLab by @Smibu on Oct 5, 2015, 21:48

@vesal Annatko tuosta ID:stä jonkun esimerkin, en tiedä ymmärsinkö mitä hait.

In GitLab by @Smibu on Oct 5, 2015, 21:50

@Smibu Siinä mielessä kyllä, että voisi ainakin pakottaa MathJax päälle, koska se joissakin kaavoissa tekee kai parempaa jälkeä ja siinä on se zoomaus. Eli voisi itse haluta että kaikki kaavat ladotaan samalla tavalla. Pitää mitata haittaako tuo Katexin mukana ole minkä verran. – Vesa Lappalainen

In GitLab by @Smibu on Oct 5, 2015, 21:53

@Smibu ID:stä esim. Eli jos TIM toteaa että uusi kpl on settings, niin sillehän arvotaan nyt ID, mutta sille voisi tulla vaikka joku settings+CheckSum niminen id. Silloin kaikissa dokusisa tuo settings olisi saman niminen hakemiston ja tiedosto (sanotaan että CheckSum on X)

settiingsX/current

ja silloin voisi helpommin tarkkailla mitä dokukohtaisia asetuksia ihmisest tekevät ja pitäisikö nisitä jotakin nostaa TIM-tasolle. Tarvittaessa silloin settings voisi olla jopa missä kohti vaan (en tiedä onko järkeä), kun se voitaisiin hakea ID:llä. – Vesa Lappalainen

In GitLab by @Smibu on Oct 8, 2015, 15:24

@vesal Ok, muutan tuota siis niin, että plugineiden attribuutit on muodossa

global_plugin_attrs:
  csPlugin:
    stem: asdasd
  mmcq:
    stem: qweqewqwe
  all:
    stem: kaikille

En tuosta id-ideasta oikein tykkää, kun se monimutkaistaisi tuota rakennetta (=enemmän iffejä koodiin) ja muutenkin tuota statistiikkaa varten voi aika pienellä vaivalla tehdä jonkin reitin TIMiin, joka koostaa dokujen asetukset jossain muodossa.

In GitLab by @Smibu on Oct 8, 2015, 18:49

@vesal Tuotannossa tuo nyt. Samaten settings-kappaleen voi nyt lainata muualta.

In GitLab by @Smibu on Oct 30, 2015, 15:23

Nyt tuntuisi makrot toimivan vikkelään myös isommalla dokulla. Latausaika cachesta ohj1-monisteella vähän reilu sekunti lokaalisti. Kirjoitan vielä yhden testin.

In GitLab by @Smibu on Oct 30, 2015, 16:19

voiko tota kokeilla missään ja mikä on tämän hetkinen syntaksi?@mikkalle – Vesa Lappalainen

In GitLab by @Smibu on Oct 30, 2015, 16:39

@vesal Laitan kohta deville. Dokun alkuun pitää laittaa

``` {settings=""}
macro_delimiter: "%%"
macros:
 jokumakro: hello



ja tosiaan tuo `%%` pitää olla lainausmerkeissä, koska muuten YAML ei tykkää.

Sitten toimii myös Jinja2:n `{%` ja `%}` [lohkosyntaksi](http://jinja.pocoo.org/docs/dev/templates/).

Tuotakin voi tarvittaessa vaihtaa, mutta sille ei ole vielä asetusta tehty. Voisi olla vaikka `macro_block_delimiter` tms.

In GitLab by @Smibu on Oct 30, 2015, 16:41

@tomijkarppinen Päivitin hieman DocParagraph-luokkaa; lähinnä se että siellä on nyt viite doku-olioon eikä pelkkä id. Se helpotti paria asiaa. Eli kannattaa varmaan nyt pullata master, niin ei tule konflikteja niin paljon (jos oot sattunut editoimaan samoja kohtia).

In GitLab by @Smibu on Oct 30, 2015, 16:51

@vesal @tomijkarppinen @juvalkee Tuolla voi kokeilla makroja: https://tim-dev.it.jyu.fi/view/tim/koe/makrot

In GitLab by @Smibu on Oct 30, 2015, 17:19

@Smibu https://tim-dev.it.jyu.fi/view/tim/koe/makrot

Ei purrut pluginin sisällä? Pistin tuonne pienen esim – Vesa Lappalainen

In GitLab by @Smibu on Oct 30, 2015, 17:31

@vesal Aijuu, unohdin että tuo plugin on hieman eri tapaus, hoidanpa sen.

In GitLab by @Smibu on Oct 30, 2015, 17:43

@vesal Korjattu tuo, eli nyt makrot laajennetaan ennen kuin YAML parsitaan pluginia varten.

In GitLab by @Smibu on Oct 30, 2015, 17:56

@Smibu Mites tuo silmukkataulukko, siinä sisällä olevat eivät laajene, pitäisikö? – Vesa Lappalainen

In GitLab by @Smibu on Oct 30, 2015, 18:01

@vesal Tuon rivin pitää olla:

{% for s in sarakkeet %}%%('{} {}, {} sarake').format(r,rivi,s).rjust(sarakeleveys)%% {% endfor %}

In GitLab by @Smibu on Oct 30, 2015, 18:09

@Smibu OK, ei mikään ihan ilmeisin syntaksi :-)

Olikos ideaa niistä automaattinumeroinneista?

Mites käykö se "turhaan" noita makroja laskemassa jos jossakin kpl ei ole niitä lainkaan? – Vesa Lappalainen

In GitLab by @Smibu on Oct 30, 2015, 20:22

@Smibu "siellä on nyt viite doku-olioon eikä pelkkä id"

Mites tuo vaikuttaa sen moniajon kanssa? Syntyykö jokaiselle prosessille omat cachet vai mitenkä tuossa käy? – Vesa Lappalainen

In GitLab by @Smibu on Oct 31, 2015, 10:29

@Smibu https://tim-dev.it.jyu.fi/view/1?timing=div mulla menee 12.8 sek ennenkuin tuo rupeaa tulemaan selaimelle.

Vastaavasti:

https://tim.jyu.fi/view/1?timing=div

on vajaa 1.4 sek. – Vesa Lappalainen

In GitLab by @Smibu on Nov 2, 2015, 11:14

Olikos ideaa niistä automaattinumeroinneista?

Joo ainakin alustavaa; teen tuosta oman kortin jossain vaiheessa.

Mites käykö se "turhaan" noita makroja laskemassa jos jossakin kpl ei ole niitä lainkaan?

Joo siis jokaiselle kappaleelle tehdään samat temput.

Mites tuo vaikuttaa sen moniajon kanssa? Syntyykö jokaiselle prosessille omat cachet vai mitenkä tuossa käy?

Jokaiselle prosessille syntyy oma.

mulla menee 12.8 sek ennenkuin tuo rupeaa tulemaan selaimelle.

Tuo johtuu juuri tuosta, että sillä prosessilla, joka tuon pyynnön palveli, ei ollut cachessa dokumenttia. Cachesta haettuna se pitäisi olla vikkelä (sekunnin luokkaa). @vesal

In GitLab by @Smibu on Nov 2, 2015, 18:21

@Smibu "Tuo johtuu juuri tuosta, että sillä prosessilla, joka tuon pyynnön palveli, ei ollut cachessa dokumenttia. Cachesta haettuna se pitäisi olla vikkelä (sekunnin luokkaa). "

Mutta nyt tuossa on sitten iin, että 8 ekaa joutuu kärsimään ja mään en kokeissa noita nopeita saanut juuri koskaan. Eli tyhjeneekö Cachessa missä ajassa? Miksi se kestää 13 sek käydä ne läpi. Erityisesti jos Ohj1 monisteessa ei edes ole yhtään makroa? Eikö kuitenkin Cachen kannattaisia olla monitasoisempi, eli levyltä löytyy viimeisin tilanne jos ei ole muistissa kunnossa? – Vesa Lappalainen

In GitLab by @Smibu on Nov 2, 2015, 18:22

@Smibu "Joo siis jokaiselle kappaleelle tehdään samat temput." Oliko nopeampi tunnistaa löytyy kplsta tuota %% ennenkuin mennään tekemään mitään? – Vesa Lappalainen

In GitLab by @Smibu on Nov 2, 2015, 19:12

8 ekaa joutuu kärsimään

Se logiikka on kai monimutkaisempi että miten se gunicorn jakaa pyyntöjä eri prossuille. Eli kahdeksan ekankin jälkeen voi olla prossu(ja), jotka ei vielä ole palvelleet. Mutta ennen pitkää kaikilla pitäisi olla cache käytössä.

Eli tyhjeneekö Cachessa missä ajassa?

Se on LRU eli se tyhjentää vanhimpia vain jos se tulee täyteen. Kooksi on määritetty tällä hetkellä 65536.

Miksi se kestää 13 sek käydä ne läpi.

Varmaankin HTML-konversio & makroprosessointi tuosta vie eniten aikaa.

Eikö kuitenkin Cachen kannattaisia olla monitasoisempi, eli levyltä löytyy viimeisin tilanne jos ei ole muistissa kunnossa?

Kyllähän se auttaisi. Se alkuperäinen HTML:n cachetustyyli (missä html menee jsonin sekaan muiden rinnalle) ei enää kelpaa, koska pitää tietää myös mitkä makrot olivat käytössä. Nyt kun katsoin niin pyfscache näyttäisi olevan sellainen, jota kannattaa kokeilla tuohon.

Oliko nopeampi tunnistaa löytyy kplsta tuota %% ennenkuin mennään tekemään mitään?

Voisin kokeilla, auttaako tuo tunnistus yhtään. @vesal

TIM-JYU / TIM

Dokumentin asetukset #499

Checklist