Adăugarea unui nou procesor de limbă

Ghidul pentru adăugarea suportului pentru limbajul de programare, prezentat aici, se referă la versiunea 2.3.1.

Un procesor de limbă (SP) este fie un compilator, fie un interpret al unui anumit limbaj de programare.

Deoarece sistemul ejudge suportă mai multe versiuni ale aceluiași limbaj de programare (de exemplu, Free Pascal, Borland Kylix, și așa mai departe. D.), nu este corect să vorbim despre sprijinul limbaje de programare, precum și suport pentru procesoare de limbi străine.

Adăugarea de suport pentru un nou JB la sistemul ejudge se face în mai mulți pași.

1. Determinarea parametrilor LN adăugat
2. Scrierea unui script de personalizare (lang-version.in)
3. Scrierea unui script de compilare (lang.in)
4. Reconfigurarea JA acceptată utilizând programul ejudge-configure-compilers
5. Repornirea sistemului ejudge

Determinarea parametrilor

Parametrii SP necesari pentru a-l susține în sistemul ejudge sunt enumerați mai jos:

modul de siguranță

numele scurt al AP (de obicei determinat automat)

numele complet al AP

sufixul standard al fișierului sursă pentru SP dat

fișier executabil standard pentru acest API

Argumentul specificat când se configurează JD cu programele ejudge-setup sau ejudge-configure-compilers

Parametrul principal al JA este arhitectura (arc). În cadrul arhitecturii se înțelege mediul de sistem, în care este lansat programul testat. Sistemul ejudge acceptă următoarele arhitecturi:

• linux este un program executabil legat static
• linux-shared - program executabil legat dinamic (inclusiv scripturi)
• java - codul de octet java
• msil - .NET bytecode
• dos - aplicații DOS

Arhitectura linux este arhitectura implicită. Dacă LSP are o arhitectură linux, parametrul arc pentru acest LO trebuie să fie absent sau gol.

Al doilea parametru este steagul pe care programul testat funcționează corect pentru acest SP când acesta este pornit în modul sigur. În cazul în care PL are o arhitectură Linux, Java sau DOS, programul de testare pentru PL, sprijinind în același timp toate restricțiile de securitate de obicei funcționează corect în modul de siguranță. Dacă LSP are arhitectura msil, atunci modul sigur nu este acceptat pentru aceasta. Programe astfel de PLS pot fi testate, dar fără restricții de securitate impuse programul nu va fi. În cazul în care PL are o arhitectură partajată-linux, modul de siguranță pentru PL este susținut, cu toate acestea, programul testat în Safe Mode poate să nu funcționeze corect sau nu funcționează deloc.

În orice caz, dacă există îndoieli cu privire la starea de sănătate a programului în condiții de siguranță, trebuie să verificați programele simple, care lucrează atât cu fire standard, cât și cu fișierele.

Dacă kernelul adăugat nu acceptă modul sigur, atunci parametrul JI nesigur trebuie să fie 1. Dacă este acceptat modul sigur, parametrul trebuie să fie absent sau gol.

De la PL sistem ejudge sprijinit ca standard în versiunea 2.3.8, sunt nesigure PL gcj (GNU Java), gfortran (GNU Fortran), mcs (Mono C #), mzscheme (MzScheme), PHP (PHP), vbnc (Mono Visual Basic ), yabasic (YaBasic).

Parametrul short_name este un nume scurt pentru AP. Un nume scurt este folosit în tabelul mesajelor utilizatorilor și al unui număr de alte locuri. Numele scurt al YAP este, de fapt, identificatorul YAP-ului. Ar trebui să fie un singur cuvânt, nu mai mult de 32 de caractere, format din litere latine litere mari și mici, numere și semne +, -, _. De obicei, numele scurt al SP este determinat automat din numele scriptului de compilare și din setări. De exemplu, dacă scriptul de compilare (mai exact, șablonul de script de compilare) are numele foo.in. atunci în mod implicit numele multiplu al LC va fi pentru foo. Rețineți că în sistemele unix, numele fișierelor sunt sensibile la minuscule. Valoarea parametrului short_name este de asemenea sensibilă la litere mari și mici.

Parametrul long_name este numele extins (complet) al AP. De exemplu, numele scurt al AP poate fi folosit pentru foo. iar cea integrală este "GNU Foo Interpreter". Rețineți că numele complet al SP nu include numărul versiunii.

Parametrul src_sfx este sufixul standard al fișierelor sursă pentru acest SP. De exemplu, dacă pentru GNU GNU Foo fișierele sursă sunt numite file.foo. atunci sufixul fișierelor sursă este șirul .foo (rețineți că "punctul" este inclus în sufix).

Parametrul exe_sfx specifică sufixul standard pentru fișierele executabile pentru un SP dat. Ca regulă, sufixul fișierelor executabile depinde de arhitectura AP. Deci, pentru arhitecturile linux și linux-shared, sufixul executabil standard nu este necesar, astfel încât parametrul exe_sfx poate fi omis sau poate avea o valoare goală. Pentru arhitecturile dos și msil, sufixul executabil standard este .exe. și pentru arhitectura java - .jar.

Parametrii arh. nesigur. SHORT_NAME. long_name. src_sfx. exe_sfx descriu proprietățile NL-ului propriu-zis, deci pentru un LN dat, acestea nu se schimbă de la instalare la instalarea sistemului ejudge.

Versiunile de opțiuni și arg descriu proprietățile de instalare ale acestui JD într-un anumit sistem, astfel încât valorile lor pot varia de la instalare la instalare.

Parametrul versiunii specifică versiunea SP. Dacă valoarea acestui parametru este goală, atunci se consideră că SP nu a fost detectat în sistem. Prin urmare, valoarea acestui parametru nu trebuie să fie goală. Versiunea JAR este determinată de scriptul de instalare, de obicei cu ajutorul pornirii JAV-ului cu opțiuni speciale și procesarea rezultatelor.

Parametrul arg conține argumentul de configurare PL a trecut la ejudge-setup script de configurare sau ejudge-configure-compilatoare. De exemplu, dacă un program începe ejudge-configure-compilatoare cu opțiunea --with-foo = / usr / local / bin / foo, / usr / bin / foo script parametru local / configurație va fi trecut PL foo-versiune. Mai mult decât atât, acest parametru poate fi setat și interactiv în programele ejudge-configurare și ejudge-configure-compilatoare. De obicei, acest parametru specifică calea către PL în sistemul de fișiere, și este util în cazurile în care PL este situat în locații non-standard.

Structura fișierelor pentru suport

Să presupunem că sistemul ejudge este instalat în directorul / opt / ejudge, iar directorul pentru date este instalat în / home / ejudge. Apoi, directorul / home / ejudge / compile conține fișierele de configurare și scripturile pentru serverul de compilare a aplicațiilor.

compile.cfg

Fișierul /home/ejudge/compile/conf/compile.cfg este fișierul principal de configurare a serverului de compilare. Fișierul conține informațiile necesare pentru a fi compilate pentru toate SP-urile acceptate în această instalare. De exemplu, pentru foo foo, secțiunea de descriere a SP poate arăta astfel:

Aici ID-ul este identificatorul numeric al SP, unic pentru toate SP-urile din această instalare. Restul informațiilor despre LR sunt preluate din parametrii LF descriși în secțiunea anterioară.

Fișierul /home/ejudge/compile/conf/compile.cfg este scris automat de fiecare dată când se numește programul ejudge-configure-compilers. Toate modificările făcute manual sunt pierdute de fiecare dată când executați ejudge-configure-compilers.

Versiunea YAP și pavilionul pe care îl detectează YAP-ul corespunzător din sistem nu sunt conținute în acest fișier de configurare, ci sunt citite direct din fișierul de configurare al YAP de fiecare dată când programul de compilare este pornit.

lang_ids.cfg

Catalog lang.d

Directorul /home/ejudge/compile/conf/lang.d conține fișiere de configurare a configurației pentru toate JD-urile activate cu eJudge. Pentru kernelul foo, fișierul de configurare se numește foo.cfg. Conținutul său poate fi ceva de genul:

Fișierul este scris în sintaxa / bin / sh. Acest fișier este folosit ca programe de sistem ejudge, cum ar fi compilarea, super-servirea și direct prin foo și foo-versiunea script-uri. Acesta este generat de foo-versiunea script-ului, care este lansat într-un mod special.

Pe lângă parametrii SP descriși mai sus, fișierul poate conține definiții ale variabilelor arbitrare necesare pentru a rula scripturile foo sau foo-version. În exemplul de mai sus, aceasta este variabila FOOPATH.

În director

În directorul din director există spații libere pentru scripturi de configurare și de compilare. În directorul / opt / ejudge / libexec / ejudge / lang / în preformă sunt script-uri pentru PLS acceptate în ejudge sistem de livrare standard de. Caseta / home / ejudge / compile / scripts / în director conține script-urile utilizatorului. Ultimul director o prioritate, script-ul este, în cazul în care activitatea este detectată în directorul / home / ejudge / compila / script / in, directorul de sistem nu va fi verificat. Prin urmare, dacă aveți nevoie să modificați script-ul furnizat, acesta trebuie mai întâi să fie copiat în acest director, și apoi modificați. Modificare fișiere direct în directorul / opt / ejudge / libexec / ejudge / lang / în ea nu este recomandată deoarece aceste fișiere sunt suprascrise atunci când actualizați ejudge.

Scripturi de catalog

În directorul / home / ejudge / compile / script-urile sunt procesate scripturi, gata pentru utilizare de către toate programele sistemului ejudge. scripturi piesa de lucru prelucrate și copiate din directorul / opt / ejudge / libexec / ejudge / lang / și / home / ejudge / compilare / script-uri / în acest program director ejudge-configure-compilatoare.

scripturi țagle

Pentru foo foo, scrobele foo.in și foo-version.in ar trebui să fie scrise. Scripturile ar trebui plasate în directorul / home / ejudge / compile / scripts / în directorul. Semnele scripturilor în funcție de semnificație corespund pregătirii fișierelor Makefile.in, config.h.in în sistemul GNU autotools. Asta este, în achiziționarea de scripturi, variabilele formulei @ var @ sunt înlocuite cu valorile lor.

Substituțiile acceptate sunt listate în tabel

respectiv. configurați opțiunea

Stabilirea scriptului

Scriptul de configurare ar trebui să suporte mai multe moduri de lansare. Modurile sunt specificate utilizând opțiunile din linia de comandă. Toate modurile de funcționare sunt luate în considerare folosind exemplul scriptului foo-version

-r - modul de configurare

În modul de configurare, suportul AP din această instalare trebuie verificat. Pentru ieșire standard, conținutul noului fișier de configurare PL foo.cfg să fie imprimate. În plus, dacă opțiunea -v este specificată, informațiile suplimentare despre procesul de configurare ar trebui să fie imprimate pe fluxul de eroare standard. După finalizarea cu succes a codului de configurare trebuie să fie egal cu 0, iar la eșec - 1. Parametrul ARG trece un traseu pe care utilizatorul au un --with-foo = ARG opțiuni configurate în modul de lot sau cale ca acesta a intrat la configurarea interactiv .

Deci, dacă suportul RL este acceptat în această instalare, scriptul de pornire poate fi:

Ultima linie (verificare.) Este ieșită la fluxul de eroare standard.

Dacă nucleul foo nu este acceptat în această instalare, scriptul de pornire poate fi:

Ultima linie (verificare.) Este ieșită la fluxul de eroare standard.

-l - modul de recuperare a listei

În modul de regăsire a listei, linia de informații LN trebuie tipărită pe fluxul de ieșire standard. Linia de informare este imprimată indiferent dacă AP-ul dat este suportat în această instalare. Codul de iesire trebuie sa fie intotdeauna 0.

Deci, pentru kernelul foo, scriptul de pornire poate fi:

Lista listei JD este folosită de programul ejudge-configure-compilers atunci când este rulat cu opțiunea -list.

-p - tipărirea căii către JAP

În modul de tipărire, calea către JAR din fluxul de ieșire standard trebuie imprimată cu calea către JA. Codul de finalizare trebuie să fie 0. Dacă SP nu este acceptat în această instalare, ieșirea trebuie să fie goală și codul de ieșire este 1. În acest caz, un mesaj de diagnosticare poate fi afișat pe fluxul de eroare standard.

Deci, dacă suportul RL este acceptat în această instalare, scriptul de pornire poate fi:

Modul de imprimare este utilizat de programul de super-servire în anumite cazuri speciale.

-f - imprimați numele complet și versiunea

În modul de imprimare, numele complet al PL la ieșirea standard trebuie să fie tipărite numele complet și versiune a numărului YAP YAP. În cazul în care PL nu este acceptat în acest sistem (în instalație), fluxul de ieșire standard, va fi gol, iar codul de retur este egal cu 1. La eroare standard, în acest caz, poate fi de ieșire de diagnosticare.

Deci, dacă suportul RL este acceptat în această instalare, scriptul de pornire poate fi:

În cazul în care nu este acceptată footerul LC, următoarele:

caz în care mesajul este trimis la fluxul de eroare standard.

Modul de imprimare versiune este utilizat de programul de super-servire în timpul configurării JV la editarea turneului.

versiune tipărită

În versiunea modul de imprimare, care este dat prin rularea script-ul fără parametri pentru ieșire standard trebuie să fie imprimate numărul versiunii PL. În cazul în care PL nu este acceptat în acest sistem (în instalație), fluxul de ieșire standard, va fi gol, iar codul de retur este egal cu 1. La eroare standard, în acest caz, poate fi de ieșire de diagnosticare.

Deci, dacă suportul RL este acceptat în această instalare, scriptul de pornire poate fi:

În cazul în care nu este acceptată footerul LC, următoarele:

caz în care mesajul este trimis la fluxul de eroare standard.

Modul de imprimare versiune este utilizat de programul de super-servire în timpul configurării JV la editarea turneului.

punerea în aplicare

Să luăm în considerare implementarea scriptului de configurare pentru FP foo foo-version.in. Pentru un exemplu pentru acest script (ipotetic), un script este folosit pentru a configura Ruby JS.

Scenariul de compilare

Scriptul de compilare ia ca parametri numele fișierului cu codul sursă al programului pentru JS și numele fișierului rezultat. Sarcina scriptului de compilare este de a obține fișierul de ieșire gata să fie lansat în mediul specificat de arhitectura lingvistică.

Pentru limbile compilate, rezultatul scriptului de compilare este un executabil binar. Pentru limbile interpretate, rezultatul scriptului de compilare este un script care este gata de a fi rulat. De regulă, pentru limbile interpretate, este suficient să notați construcția

și setați bitul x al permisiunii de executare a fișierului. Aici INTERP-PATH este calea completă spre interpretul limbii respective.

Apoi, scriptul de compilare este examinat folosind limba ipotetică interpretată foo.

Interfața scriptului de compilare este foarte simplă

Aici SRC-FILE este numele fișierului de intrare, DST-FILE este numele fișierului de ieșire. Sistemul ejudge generează numele fișierelor de intrare și ieșire folosind sufixele fișierului sursă și fișierul rezultat, așa cum este specificat în fișierul de configurare al JD. Prin urmare, nu este necesară procesarea suplimentară a numelor de fișiere de intrare și de ieșire.

În plus, steagurile pentru SP pot fi specificate în variabila de mediu EJUDGE_FLAGS. Administratorul turneului are capacitatea de a seta steaguri la editarea unui turneu. Prin urmare, scriptul de compilare ar trebui să susțină specificarea opțiunilor suplimentare utilizând mediul EJUDGE_FLAGS.

punerea în aplicare

O exemplu de implementare a scriptului de compilare foo.in. Pentru un exemplu pentru acest script (ipotetic), un script este folosit pentru a compila Ruby JS.

Reconfigurarea SAN-urilor acceptate

După ce script-urile foo-version.in și foo.in sunt plasate în directorul / home / ejudge / compile / scripts / în director, pur și simplu rulați programul ejudge-configure-compilers. Dacă scripturile sunt scrise corect, versiunea JAR trebuie să fie definită corect, după care limba este gata de utilizare.

În turneu, limba poate fi adăugată la editarea setărilor turneului utilizând programul de control CGI-serve.

Reporniți ejudge

După ce ați finalizat toți pașii, nu uitați să reporniți ejudge astfel încât serverul de compilare compilație să citească noul fișier de configurare.