Pluginien refaktoroinnista johtuvat bugit ja muut asiat #1310

Closed dezhidki closed 2 years ago

In GitLab by @Smibu on Jan 3, 2019, 11:00

Kerätään tähän korttiin pluginien refaktoroinnista johtuvat bugit ja tehtävät.

Pusken jatkossa vain stack-haaraan.

Lista ajettavista replace-komennoista

Komennon alapuolella määrä "lohko/dokumentti" moneenko komento vaikuttaa devs5-koneessa.

./run_python.sh timApp/admin/replace_in_documents.py --folder '' --filter_attr plugin=imagex --term '(?= *)size: *\[\](?= *\n)' --to 'size:' --regex
65/35

./run_python.sh timApp/admin/replace_in_documents.py --folder '' --filter_attr plugin=imagex --term ' *align: *""\n' --to '' --regex
5/5

./run_python.sh timApp/admin/replace_in_documents.py --folder '' --filter_attr plugin=imagex --term '(?= *)type: *""(?= *\n)' --to 'type: rectangle' --regex
5/5

./run_python.sh timApp/admin/replace_in_documents.py --folder '' --filter_attr plugin --term ': \|!!\n// *\n(?=\S)' --to ': |!!\n' --regex
1423/350

./run_python.sh timApp/admin/replace_in_documents.py --folder '' --filter_attr plugin --term ': \|\n //\n' --to ': |1\n' --regex
3457/357

Näitä replaceja ei tarvitsekaan

./run_python.sh timApp/admin/replace_in_documents.py --folder '' --filter_attr plugin=imagex --term ' *(color|borderColor|borderWidth|length|font|textColor|dotRadius): *\n' --to '' --regex
16/11

./run_python.sh timApp/admin/replace_in_documents.py --folder '' --filter_attr plugin=csPlugin --term '(?= *)userargs: *(\d*)(?= *\n)' --to 'userargs: "\1"' --regex
26/23

Muita tehtäviä

[x] csplugin: placeholder: -> placeholder: "" tai sallittava null
[x] imagex: textboxproperties kopioituu seuraaviin, mikä on loogista, mutta ainakin tämä plugin näkyy väärin, koska se näyttää tekstin moneen kertaan.
[x] a pitää voida olla null, ks. tämä
[x] Kertabindauksia (::) optimoitava niin, ettei mikään niistä jää templatessa undefined
[x] Laiskat pluginit välähtävät rumasti
[x] tiedostonlatauspluginissa ei pitäisi näkyä tekstilaatikkoa
[x] text/tiny näkyy väärin
[x] byFile ei toimi
[x] csplugin: highlight, normal, resetText sallittava nulleiksi
[x] csplugin: header ja stem sallittava nulleiksi
[x] csplugin: userinput sallittava numberiksi
[x] markup-virheilmoitus siistimmäksi
[x] Tarkista, että ohj1 demot toimivat
[x] Tarkista, että ohj2 demot toimivat
[x] Tarkista, että valintakokeet toimivat

In GitLab by @vesal on Jan 3, 2019, 11:37

Onko noita korvauksia mahdollsiat välttää? Mielestäni vastaavia saoin käsiteltyä Stack-pluginissa sopivilla oletusarvoilla.

Sitten on testattava hidastuuko esim Ohj1 moniste näiden muutosten takia. Mua huolettaa tuo mitä kokeilin joissakin (esim video-plugin, en edes csPlugin) tapauksissa että kuinka paljon kutsutaan niitä get-metodeja.

In GitLab by @Smibu on Jan 3, 2019, 11:56

On mahdollista, muttei erityisen helposti. Korvaus on noissa ylivoimaisesti järkevin.

Lisäsin ruksin noihin optimointeihin liittyen.

In GitLab by @vesal on Jan 3, 2019, 12:11

On mahdollista, muttei erityisen helposti. Korvaus on noissa ylivoimaisesti järkevin.

Mutta pitää miettiä myös mikä on pluginia kirjoittavalla luonnollisin vaihtoehto. Ohjelma tekee väsymättömästi asioita.

Jos on luonnollista ajatella jossakin että

elain:

tarkoittaa lautsamatonta arvoa, niin siinä se tarkoittaa.

Jos jossakin on sitten luonnollista tulkita että alustamaton arvo tarkoittaa samaa kuin tyhjä, niin sen voi silloin koodissa laittaa niin, ellei siitä tule yksikäsitteisyysongelmia jonkin muun kanssa.

Mitä oli ne käytännön esimerkit missä tuo korvaus oli pakko tehdä ja mitä se olisi vaatinut koodissa? Käyttäjä on minusta se, jota pitää ensisijaisesti aina ajatella, ei koodin määrää :-)

In GitLab by @vesal on Jan 3, 2019, 12:13

Mitä oli ne käytännön esimerkit missä tuo korvaus oli pakko tehdä ja mitä se olisi vaatinut koodissa? Käyttäjä on minusta se, jota pitää ensisijaisesti aina ajatella, ei koodin määrää :-)

Tosin tuohon vielä se, että monesti olen toki huomannut että mitä monimutkaisemmaksi tekee koodilogiikan, niin se voi mennä monimutkaiseksi myös käyttäjän perspektiivistä, eli toki kompromissejä joutuu tekemään.

In GitLab by @Smibu on Jan 3, 2019, 14:10

Mutta pitää miettiä myös mikä on pluginia kirjoittavalla luonnollisin vaihtoehto.

Noista replaceista 2 kpl on sellaisia, jotka vaativat käyttäjältä enemmän kirjoittamista. Siis tuo userargs ja type.

Oikeastaan tuon typen voi sallia nulliksi, koska jo nyt jotkut sallitaan nulleiksi. Samaten sain sallittua myös nuo color|...-pätkässä mainitut eikä jopa koodiinkaan tarvinnut muutoksia vaan vain tyyppeihin.

userargsinkin voi sallia numeroksi; kyllä se passaa.

Miksi size: [] -> size: -korvaus: TypeScriptissä ei pysty ilmaisemaan "tyhjä tuple"-tyyppiä (yritin kikkailla t.array(t.never), mutta ei sallinut). Eli tuota sizeä ei pysty tyypittämään tarkasti, jos [] pitää sallia. Lähin on joku t.union([t.tuple([t.number]), t.tuple([t.number, t.number]), t.array(t.number)]), mutta en ruvennut tuolla edes kokeilemaan, koska tuo sallii sitten liikaa.

Tuo align: "" on sinänsä noista kaikkein epäloogisin ja se onkin vain muutamassa testipluginissa käytetty.

Eli kaiken kaikkiaan pelkästään size- ja align-korvaukset riittävät (ellei muita tule vastaan).

In GitLab by @vesal on Jan 3, 2019, 14:27

Miksi size: [] -> size: korvaus: TypeScriptissä ei pysty ilmaisemaan "tyhjä tuple"-tyyppiä (yritin kikkailla t.array(t.never), mutta ei sallinut). Eli tuota sizeä ei pysty tyypittämään tarkasti, jos [] pitää sallia. Lähin on joku t.union([t.tuple([t.number]), t.tuple([t.number, t.number]), t.array(t.number)]), mutta en ruvennut tuolla edes kokeilemaan, koska tuo sallii sitten liikaa.

Tuo align: "" on sinänsä noista kaikkein epäloogisin ja se onkin vain muutamassa testipluginissa käytetty.

Eli kaiken kaikkiaan pelkästään size- ja align-korvaukset riittävät (ellei muita tule vastaan).

Onko tuota size: [] käytty paljon. Mutta eikös sitten samaan liity mitään mm. sijaintiin (location tms) liittyvää, koska sekin esitetään taulukkona.

Mikähän tuon size: [] idea on ollutkaan? Sanoa että käytetään oletusta? Onkohan esim size: [10] sallittu ja tarkoittaisi että molemmat suunnat ovat 10?

Vesa

In GitLab by @Smibu on Jan 3, 2019, 14:41

Onko tuota size: [] käytty paljon. Mutta eikös sitten samaan liity mitään mm. sijaintiin (location tms) liittyvää, koska sekin esitetään taulukkona.

Niitä oli 65 kpl devs5:ssä silloin kun tuon skriptin ajoin siellä. Eli tuotannossa voi olla jonkin verran enemmän.

position on aina kaksiarvoinen; ei ainakaan muuta ole tähän asti tullut vastaan.

Mikähän tuon size: [] idea on ollutkaan? Sanoa että käytetään oletusta? Onkohan esim size: [10] sallittu ja tarkoittaisi että molemmat suunnat ovat 10?

Joo, [] sanoo että käytä oletusta ja [10] meinaa että leveys on 10 ja korkeus automaattinen (sitä on käytetty ainakin backgroundissa kun kuva on haluttu tietyn levyiseksi ja korkeus sitten muuttuu samassa suhteessa).

In GitLab by @vesal on Jan 3, 2019, 14:51

  Onko tuota size: [] käytty paljon. Mutta eikös sitten samaan liity mitään mm. sijaintiin (location tms) liittyvää, koska sekin esitetään taulukkona.
Niitä oli 65 kpl devs5:ssä silloin kun tuon skriptin ajoin siellä. Eli tuotannossa voi olla jonkin verran enemmän.

position on aina kaksiarvoinen; ei ainakaan muuta ole tähän asti tullut vastaan.
  Mikähän tuon size: [] idea on ollutkaan? Sanoa että käytetään oletusta? Onkohan esim size: [10] sallittu ja tarkoittaisi että molemmat suunnat ovat 10?
Joo, [] sanoo että käytä oletusta ja [10] meinaa että leveys on 10 ja korkeus automaattinen (sitä on käytetty ainakin backgroundissa kun kuva on haluttu tietyn levyiseksi ja korkeus sitten muuttuu samassa suhteessa).

OK, jos kaikki käytöt ovat olleet tuollaisia, niin antaa niidne vaihtua. Ongelmana tietysti on (niin kuin monessa muussakin paikassa), että saako tuosta sitten hyvän kirjoittajan virheilmoituksen jos käyttää väärää muotoa. (Mutta tuota virheilmoitusta ei nyt 1. prioriteetilla kannata lähteä kyhäämään, mutta joku tapa siihen joskus tarvittaisiin).

In GitLab by @Smibu on Jan 3, 2019, 15:54

marked the task csplugin: placeholder: -> placeholder: "" tai sallittava null as completed

In GitLab by @Smibu on Jan 3, 2019, 17:24

marked the task imagex: textboxproperties kopioituu seuraaviin, mikä on loogista, mutta ainakin tämä plugin näkyy väärin, koska se näyttää tekstin moneen kertaan. as completed

In GitLab by @Smibu on Jan 4, 2019, 09:55

marked the task a pitää voida olla null, ks. tämä as completed

In GitLab by @Smibu on Jan 4, 2019, 15:03

marked the task Kertabindauksia (::) optimoitava niin, ettei mikään niistä jää templatessa undefined as completed

In GitLab by @Smibu on Jan 4, 2019, 15:30

marked the task Laiskat pluginit välähtävät rumasti as completed

In GitLab by @Smibu on Jan 4, 2019, 15:31

Nyt laiskat pluginit eivät enää hypi eivätkä välähdä yhtä pahasti kuin ennen. Ei-laiska plugin vaihdetaan laiskan paikalle vasta kun Angular on kunnolla kääntänyt sen.

https://timdevs5.it.jyu.fi/view/1

In GitLab by @vesal on Jan 4, 2019, 15:55

Nyt laiskat pluginit eivät enää hypi eivätkä välähdä yhtä pahasti kuin ennen. Ei-laiska plugin vaihdetaan laiskan paikalle vasta kun Angular on kunnolla kääntänyt sen.

Mites plugin syttyy ennen AnswerBrowseria, niin siinä tulee pieni hyppäys kun ensin syttyy pluginin sisältö ja sitten sen yläpuolelle asnwerbrowser, joten plugin joutuu väistämään himpun alaspäin. Sen alla oleva teksti ei onneksi juurikaan siirry.

Mulla kestää edelleen sen n. 12 sek ennenkuin alkaa tavaraa tulemaan.

In GitLab by @Smibu on Jan 4, 2019, 15:59

Joo, se AB-hyppäys lienee aika helppo korjata.

Se sun tunnarin viive johtuu jostakin muusta kuin näistä pluginmuutoksista, mutta voisin sitä koittaa maanantaina vilkaista.

In GitLab by @vesal on Jan 4, 2019, 16:08

Mulla kestää edelleen sen n. 12 sek ennenkuin alkaa tavaraa tulemaan.

dev5: akankalla kestää 4 sek. DomContent 9.1 sek. tuotanto: 5.3 sek 9.5 sek beta: 3.2 sek 7.8 sek

Mikähän ero noilla koneilla on?

Eli tuo beta ei akankalla ihan mahdoton ole.

Vesa

In GitLab by @vesal on Jan 4, 2019, 16:28

Nyt laiskat pluginit eivät enää hypi eivätkä välähdä yhtä pahasti kuin ennen. Ei-laiska plugin vaihdetaan laiskan paikalle vasta kun Angular on kunnolla kääntänyt sen.

onkos tuo mun vai muun vika, että jos tehtävään ei ole yhtään vastausta, niin siihen pohjakoodiksi näytettävä ei ilmesty odottamaan ja sitten kun kosketaan, niin saattaa laajeta paljonkin.

Jos on oma vastaus (samasa pohjakoodista painettu run), niin on enemmän oikean kokoinen.

In GitLab by @Smibu on Jan 8, 2019, 09:56

onkos tuo mun vai muun vika, että jos tehtävään ei ole yhtään vastausta, niin siihen pohjakoodiksi näytettävä ei ilmesty odottamaan ja sitten kun kosketaan, niin saattaa laajeta paljonkin.

En osaa sanoa. Mutta tämän voinee korjata myöhemminkin, ts. se ei estä mergeä.

In GitLab by @Smibu on Jan 8, 2019, 11:54

marked the task tiedostonlatauspluginissa ei pitäisi näkyä tekstilaatikkoa as completed

In GitLab by @Smibu on Jan 8, 2019, 13:34

marked the task text/tiny näkyy väärin as completed

In GitLab by @Smibu on Jan 8, 2019, 13:34

marked the task Tarkista, että ohj1 demot toimivat as completed

In GitLab by @Smibu on Jan 9, 2019, 10:57

Tuli vastaan tuollainen kuin breakCount, joka on lisätty tammikuussa 2015 mutta jota käytetään tuotannossa vain kahdessa testipluginissa ja sitä ei ohjeissa mainita lainkaan. Aiotaanko sitä jollain tavalla käyttää tulevaisuudessa? Nimittäin vaikuttaisi, että aika paljon koodia saisi pois.

In GitLab by @Smibu on Jan 9, 2019, 11:29

Otin sen pois omassa commitissaan, niin saa helposti jälkeenpäin katsottua, mitä poistui.

In GitLab by @Smibu on Jan 9, 2019, 12:19

marked the task byFile ei toimi as completed

In GitLab by @Smibu on Jan 10, 2019, 19:12

marked the task csplugin: highlight, normal, resetText sallittava nulleiksi as completed

In GitLab by @Smibu on Jan 10, 2019, 19:20

marked the task Tarkista, että ohj2 demot toimivat as completed

In GitLab by @Smibu on Jan 11, 2019, 09:01

marked the task markup-virheilmoitus siistimmäksi as completed

In GitLab by @Smibu on Jan 11, 2019, 09:48

marked the task csplugin: header ja stem sallittava nulleiksi as completed

In GitLab by @Smibu on Jan 11, 2019, 10:01

marked the task Tarkista, että valintakokeet toimivat as completed

In GitLab by @Smibu on Jan 11, 2019, 10:41

marked the task csplugin: userinput sallittava numberiksi as completed

In GitLab by @Smibu on Jan 11, 2019, 10:51

Joo, nyt uskaltaisin sanoa, että stack-haaran voi pistää tuotantoon. Laitan ilmoituksen TIMiin, että tänään illalla klo 22 on päivitys n. 20 min.

Lisäsin vielä pari replace-komentoa, jotka poistavat noita turhia //. Ajoin jo devs5:ssä nuo.

Esimerkkejä korvauksista: diff 1, diff 2.

In GitLab by @Smibu on Jan 11, 2019, 15:35

Mergesin stack-haaran masteriin. stack-haara voi vielä olla GitLabissa, kunnes kukaan ei siihen enää viittaa.

In GitLab by @Smibu on Jan 11, 2019, 22:20

Tuotannossa nyt.

In GitLab by @Smibu on Jan 11, 2019, 22:20

closed

In GitLab by @vesal on Jan 11, 2019, 23:16

Tuotannossa nyt.

Nopeasti katsottuna näyttäisi tiomivan.

Stack toimii. Mun csPlugin tehtävän kopiointi toimii (sen mitä sitä on tehty).

Jostakin syystä TIM-kone on mulla hitain latamaan Ohj1-monisteen. Onko betalla ja timdevs5.ssa samat datat?

Sellaisen vian huomasin, että jos menee hakemistossa tiedoston manageen rattaan kuvasta ja sitten painaa "Subscribe to the entire folder" niin menee päähakemistoon.

Vesa

In GitLab by @vesal on Jan 11, 2019, 23:22

Tuo ei toiminut:

https://tim.jyu.fi/view/users/vesal/koe/stack/spline

eli ei osannut niitä kuvia joko laittaa siihen tiettyy hakemistoon tai näyttää sieltä.

Tuo taisi olla se, että ne pitäisi laittaa näkymään TIMin kautta eikö sen stackserverin kautta kun se saisi näkyvä vain Dockerin sisäverkossa.

Vesa

In GitLab by @vesal on Jan 11, 2019, 23:44

Tuo taisi olla se, että ne pitäisi laittaa näkymään TIMin kautta eikö sen stackserverin kautta kun se saisi näkyvä vain Dockerin sisäverkossa.

Joo, ei tuo betakaan enää tee kuvia tuonne: /var/www/api/plots Joku mounttiero siihen mitä oli mulla aikaisemmin.

TIM-JYU / TIM