IPP parse.php Ja a Samuel Obuch sme spravili testovací skript pre parse.php. Zozbierali sme vstupy a výstupy z tejto skupiny a pridali nejaké vlastné. Zložku s testami som nahral do Gdrive priečinku od Vojta Chadima. Test očakáva lexikálnu analýzu literálov typu int!
https://drive.google.com/drive/folders/1R3qrmLmdqI-jUezRufFSWvbkn8gBkYgJ
Proč jste použili ".in" a ".out" soubory pro parse.php? Tyto soubory by se měly týkat až interpretru... - parse.php pracuje pouze se ".src" a ".rc" https://wis.fit.vutbr.cz/FIT/st/phorum-msg-show.php?id=50242
Zobrazit všechny odpovědi (11)
Ve finále je to jedno, stejně se používají stdin a stdout.
Jakub Samek Je to jedno pro někoho, kdo to ví, kdo by to nevěděl, tak může přepsat .out soubor výstupem z parse.php. Jenom mě zajímalo, jaká byla motivace pro tohle pojmenování, tot vše :)
Tento skript nie je navrhnutý podla testovacieho rámca zo zadania projektu :) A kedze parse.php pracuje so stdin a stdout tak su subory in a out
Tomáš Nereča Ok, díky :)
Tomáš Nereča A proč jste si přidělali práci tím, že jste vytvořili skript který dělá přesně to co má dělat test.php, akorát funguje jinak než je v zadání popsané?
Martin Foltýn Tento skript rozhodně nedělá, to co má dělat test.php :D
Petr Šopf Ne? Spustí testy, porovná s referenčními výstupy a vypíše výsledky testů. Proč ti to příjde o tolik jiný? :D
Martin Foltýn tento volá jen parse.php a potom porovnává xml za pomocí JExamXML
Martin Foltýn Příště píšeš testy ty :)
Martin Kobelka a to se jako nemůžu zeptat proč to někdo něco udělal jak to udělal? Chill ne?
Tomáš Nereča to ti vážně příjde ta moje otázka tak útočná že ti za to nestojí na ní odpovědět?
Martin Foltýn Myslím, že kolegovia to za mňa vystihli presne a nebolo treba sa vyjadrovať, bol som celý deň v práci a nemal som čas sa rozpisovať :) Ale keď inak nedáš: je to test čisto pre parse.php za pomoci referenčného nástroja jexamxml s referenčným konfiguračným súborom options, ktorý ti vypíše aj prípadný diff. Zahrnuli sme aj benchmark, či tvoj skript zvládne aj väčší vstupný súbor, pretože inému kolegovi sa stalo, že pri väčšom súbore mu došla pamäť. Takisto mi prístup zo zadania kde všetky vstupné a výstupné súbory sú v jednej zložke príde neprehladný. Dúfam, že budeš s mojou odpoveďou spokojný.
Zobrazit všechny odpovědi (1)
Jasně, díky moc i za ty testy samozřejmě, vážím si každé takovéhle pomocí ostatním
Obdrželi jste někdo po pokusném někdo nějaký log k otestovanému skriptu?
Zobrazit všechny odpovědi (1)
Jaký log? V termínu bylo napsáno, že dostaneme pouze rozmezí naší aktuální implementace.
Test04: Nemají být ty statistiky v opačném pořadí? Nejdřív LOC, pak COMMENTS? Nebo podle čeho se to určuje? Test09, Test11 - v případě nepovedených akcí se soubory (tedy i nezapisovatelný soubor - složka - by měly mít chybové kódy 12, ne?) viz https://wis.fit.vutbr.cz/FIT/st/phorum-msg-show.php?id=50251&mode=mthr
Zobrazit všechny odpovědi (1)
Test04 - poradie výpisu loc a comments má byť podľa poradia v akom boli tieto argumenty zadané - viď. zadanie projektu. Test 09 - duplicitne zadaný parameter - chyba 10, Test11 - zadaný neznámy parameter - chyba 10
dotaz: kolik máte na extreme performance testu na merlinu a evě?
Zobrazit všechny odpovědi (1)
10-15s merlin
Dotaz ohledně testu 33: nějak mi tam uniká důvod, proč se jedná o syntaktickou chybu?
Zobrazit všechny odpovědi (10)
Název návěští nesmí obsahovat @
Petr Šopf To sice ano, ale v rámci skriptu parse.php se nemá kontrolovat sémantická správnost, takže za instrukci LABEL můžeš dát jakýkoliv lexikálně korektní operand
Ondřej Pavela To ale ještě spadá do syntaktické analýzy
Ondřej Pavela viz https://wis.fit.vutbr.cz/FIT/st/phorum-msg-show.php?id=50237
Petr Šopf No tak to jsme to asi rozdílně pochopili, protože: "Co vás u syntaktické analýzy "nezajímá" je to, zda proměnná skutečně existuje nebo zda je její typ kompatibilní apod."
Ondřej Pavela Moc teď nechápu, na co tou citací odkazuješ. Důležité je toto: "bude třeba kontrolovat, že jsou splněny i náležitosti pro identifikátor" tedy i pro název návěští
Petr Šopf Narážím tím na to, že podle toho, jak jsem to pochopil z celého toho příspěvku to má fungovat opravdu tak jak jsem psal předtím, tzn. je ti jedno jestli tam je typově kompatibilní operand a jediné co tě zajímá je, jestli se vůbec jedná o NĚJAKÝ lexikálně korektní operand, takže tam klidně za LABEL můžeš dát v tomto případě proměnnou, pokud bude zápis lexikálně korektní.
Viz https://wis.fit.vutbr.cz/FIT/st/phorum-msg-show.php?id=50552 příklad od Křivky
Ondřej Pavela Ano všechny ty příklady parse.php projdou, protože: CONCAT <var> <symb> <symb> tzn. kontroluješ jen, jestli jde opravdu o symboly a proměnnou. V tom testu to je stejné. Máš Label <label> a jediné co v parse.php kontroluješ je to, jestli <label> splňuje podmínky pro název návěští (tedy první znak není číslo a může obsahovat alfanumerické znaky + nějaké speciání). Znak @ mezi nimi ale není => chyba
Petr Šopf Ok díky už tomu rozumím, jen mě tahle varianta opravdu nenapadla a nedával jsem pořádný pozor u těch dalších příkladů.
IPP parse.php Tady je sdílená složka se vstupy v IPPcode18 a odpovídajícími (doufám, že správnými :D) XML výstupy skriptu parse.php. Kdo má zájem může si to porovnat s výstupy svého analyzátoru a dát vědět (třeba do komentářů), zda se shoduje či nikoliv, a případně také rozšířit složku o vlastní vstupy a výstupy pro další testování :)
https://drive.google.com/drive/folders/1BJP3o6PThTPFHFIkfv6FSr_Gb3Xo7Nhe?usp=sharing
Nazdar, nemas v input8 chybu? NOT ma iba 2 operandy
Zobrazit všechny odpovědi (1)
Máš pravdu, opraveno. Díky!
Díky za testy :). V input8 máš preklep - inštrukcia STR2INT má správny opcode STRI2INT.
Zobrazit všechny odpovědi (1)
Díky za zpětnou vazbu, opravím to :)
Nema byt ve 4. testu <instruction order="10" opcode="CALL"> namisto <instruction order="10" opcode="CAlL">?
Zobrazit všechny odpovědi (2)
Nemajú byť opcodes vo výstupnom XML vždy uppercase?
Ano, na vstupu to může zůstat i s jedním malým písmenem, ale na výstupu to má být uppercase, output4 opraveno. Díky za upozornění.
V output4.xml je chyba v <instruction order="10" opcode="CAlL"> , ma tam byt CALL dle zadani "povinný atribut opcode (hodnota operačního kódu je vždy velkými písmeny)"
Vojta Chadima Nechtěl by jsi udělat Git repo? Lépe by se stahovaly updaty :-) Jinak supr práce!
Zobrazit všechny odpovědi (1)
Díky! :) Git repozitář byla původní myšlenka, měl jsem ho i vytvořený, pak jsem si ale řekl, že pro ostatní bude pohodlnější a rychlejší nahrávat své vlastní vstupy a výstupy do obyčejné sdílené složky :)
Output3 <arg2 type="string">string@retezec\032s\032lomitkem\032\092\032a\010novym\035radkem</arg2> string@ tam být nemá, ne?
Zobrazit všechny odpovědi (4)
celý ten string je napsaný takto string@string@retezec\032s\032lomitkem\032\092\032a\010novym\035radkem To slovo string@ je tam napsane dvakrat hned po sobe. Takze je to dobre :)
Tak tady je ten háček :D Děkuju, nevšiml jsem si :)
Ale keď je tam znovu @ tak už je to zakázaný znak a nemalo by to prejsť nie?
Klaudia Dia Fajtova „Literál pro typ string je v případě konstanty zapsán jako sekvence tisknutelných znaků v kódování UTF-8 (vyjma bílých znaků, mřížky (#) a zpětného lomítka (\))a escape sekvencí...“, @ je pro string validní :)
Musi byt ten vystupni xml u prazdnych stringu ve tvaru <arg1 type="string"></arg1> ? Nemohlo by byt jen <arg1 type="string"/> ?
Zobrazit všechny odpovědi (3)
Podla mna aj jeden, aj druhy zapis je korektny. O niecom podobnom sa bavili na fore..
Super diky
Je to jedno, viz: https://wis.fit.vutbr.cz/FIT/st/phorum-msg-show.php?id=50386&mode=mthr
input6, nemáš chybu v na řádku 7, READ TF@ahoj int ? Nemělo by to být když už tak: READ TF@ahoj int@ ?
Díky moc, pomohl jsi mi odhalit dvě chyby. Ta jedna mezera na jinak prázdném řádku byla fakt zákeřná. :D
input8: AND GF@side int@123 int@456 input8: OR TF@moje string@ahoj string@necum nemel by AND/OR/NOT pracovat pouze s bool operandy?
Zobrazit všechny odpovědi (5)
to už je sémantika => to řeší interpret
Tomáš Kazík ale keď niektoré veci viem odchytať už v parsri ako konštanty -> viz. príklad vyššie, tak to nemôžem riešiť už v parsri? nemyslím hodnotu premenných, ktoré vie až interpret, ale veci ako delenie int@0 atď. (myslím že v IFJ sme takéto veci odchytávali už v tomto štádiu)
na foréch ve vlákně "Kontrola typů" dnes ráno Křivka odpovědel: "Kontrolu typů bych již ponechal sémantické analýze v interpret.py, ale pokud tam tu chybu 21 zahlásíte, tak to nevadí."
Hlavne nekde na foru je taky Krivkou zmineno, ze se neda pocitat s tim, ze by nam do interpretu poustel jen xml prohnane tim nasim parserem, zrejme tam bude treba kontrolovat vice veci...
Samozrejme, v interprete s tým nebudem počítať, tak ale pre plnú funkčnosť parsra by sa mi to kontrolovanie typov už v parsri hodilo, forum som dnes ešte nepozerala, ďakujem :)
Rozšířil jsem testy od Vojta Chadima z ` google.drive` o zatím pár *nevalidních* testů, kdo chce, může najít zde: https://gitlab.com/Vondracek/IPP_tests
Zobrazit všechny odpovědi (3)
Lexikální správnost hodnot int kontrolovat nemusíme
Petr Šopf Nemusíme? Čtu sice forum, ale nemam to cele v hlavě, postni prosimtě link, jestli můžeš:)
https://wis.fit.vutbr.cz/FIT/st/phorum-msg-show.php?id=50297
Název jazyka musí být vždy IPPcode18, nebo je možné tam ten název vkládat podle zadaného textu z inputu? Např. v inputu došlo: .IPPCODE18 Tak do xml zadám IPPcode18 nebo IPPCODE18?
Zobrazit všechny odpovědi (4)
Vsadil bych se ze je to jedno, ja to tam vkladam vzdy stejne, o jednu promennou min. :D
Podla mna to jedno nie je. V zadani je napisane, ze kod zacina uvodnym riadkom, kde na velkosti pismen nezalezi. No potom pri popise XML ta velkost uz nie je spomenuta, takze zjavne to uz tam neplati.
Mě z toho jasně vyplývá akorát to, že pokud člověk vždy vloží do XML IPPcode18, neudělá chybu.
V zadání je fixně napsáno "IPPcode18", takže podle mě není co řešit :D