taskoverview

[t-lenz]

This introduces a script that runs a web server displaying information about available tasks (using json-files) and providing the ability to compile and download task statements.

[fagu]

Soweit ich sehe, sind in cmstaskoverview/static ein paar Dateien (z.B. cws_style.css) Kopien aus cms/server/static. Würde es Sinn ergeben, direkt die Dateien aus cms/server/static (oder Links darauf) zu verwenden?

[fagu]

(Von mir aus könnten wir auch cms und cmstaskoverview komplett zusammenlegen und eine Konfigurationsdatei für beides zusammen verwenden. Dann könnten wir uns einen Großteil von cmstaskoverview/Config.py sparen.)

[t-lenz]

@fagu: Ich hatte ursprünglich Sym-Links versucht, aber die mochte das setup.py-Skript nicht. Prinzipiell könnte man es wohl von Hand dazu bringen, die entsprechenden Dateien zu kopieren. Wollen wir das (dazu müssen wir verfolgen, in welche Ordner das setup-Skript irgendwelche Sachen packt)?

[t-lenz]

@fagu: Eine eigene Konfigurationsdatei hatte ich ursprünglich gewählt, um (wie beim Ranking) zu betonen, dass der TaskOverviewWebServer unabhängig von der Datenbank ist. Ich klebe aber nicht an dieser Lösung.

[fagu]

Momentan lädt cmsTaskOverviewWebServer beide Konfigurationsdateien. Wirklich unabhängig ist es also anscheinend nicht. Das Zusammenlegen der Ordner cms und cmstaskoverview würde auch das Problem mit den doppelten Dateien beheben.

Vielleicht wäre es auch ganz nett, wenn man den cmsTaskOverviewWebServer in core_services in cms.conf eintragen könnte, damit man ihn nicht manuell starten muss.

[fagu]

Noch eine Kleinigkeit: Könnte man die Schriftgröße im Compilation Log etwas reduzieren (z.B. auf 10px) oder das Fenster etwas breiter machen? In Chromium entstehen sonst überall überflüssige Zeilenumbrüche.

[fagu]

Mir ist gerade aufgefallen, dass TaskInfo.queue nie geleert wird und daher unbegrenzt anwächst, solange niemand die Webseite aufruft. Können wir hier eigentlich einfachheitshalber auf das Multitasking verzichten und stattdessen Service.add_timeout verwenden, um nach Aufgabenänderungen zu suchen? Dann kann der Server nicht mehr parallel info.json-Dateien einlesen und auf HTTP-Anfragen antworten. Aber vermutlich ist doch beides sowieso hinreichend schnell, oder?

[t-lenz]

@fagu: Ich habe gerade gesehen, dass alles, was irgendwo etwas aus cms.<...> importiert, anscheinend die config-Datei liest (und das geschieht bei uns indirekt über unseren TaskLoader). Somit wäre ich dann auch dafür, die config-Datei mitzunutzen.

Allerdings bin ich (noch?) dagegen, den TaskOverviewWebServer zu core_services hinzuzufügen: wenn wir einen Wettbewerb am Laufen hätten, könnten wir dann den TaskOverviewWebServer doch nicht einfach neu starten (etwa weil irgendeine Kompilierung/irgendein Programmierfehler etc. das Programm aufhält) ohne den ResourceService abzuschießen (und damit die Contestteilnehmer hochgradig zu verwirren), oder?

[fagu]

Man kann auch core_services einzeln neu starten: entweder einfach mit dem "kill"-Befehl auf der Kommandozeile, oder über das Admin-Webinterface unter /resources/all.

[fagu]

Ist es so gedacht, dass beim Programmstart schon 3 Prozesse laufen?

Außerdem scheinen jetzt bei jeder Aufgabenkompilierung 2 neue Prozesse zu entstehen, von denen nur einer schließlich beendet wird. Bei der ersten Aufgabenkompilierung bleibt außerdem noch ein Zombie-Prozess übrig. :D

[fagu]

Wenn man den TaskOverviewWebServer neu startet, während er eine Aufgabe kompiliert, kommen danach unmengen Fehlermeldungen (KeyError), weil der Browser immer noch versucht, /compile?code=...&handle=... aufzurufen.

[fagu]

cms/server/static/css/cws_style.css = cms/server/static/cws_style.css, oder?

[t-lenz]

@fagu, bzgl. Fehlermeldungen: was schlägst du als Lösung vor? Sollte unser Programm in diesem Fall die Kompilierung einfach anstoßen (dann müsste man current_handle hoch genug ansetzen, was bei mehreren Clients, die auf dieselbe Aufgabe warten, problematisch wären) oder einen Fehler zurückgeben (mit Fehlermeldung à la "The web server has been restarted since you requested the statement. Please retry.")?

[fagu]

@t-lenz Ich hätte eine Fehlermeldung vorgeschlagen. Aber wenn das andere leichter zu implementieren wäre, ist das natürlich auch gut. :) (Von mir aus müsste die Fehlermeldung nicht mal unbedingt dem Benutzer angezeigt werden. Ich fand es nur ungünstig, dass man auf dem Server mit Exceptions bombardiert wird, nur weil man ihn neugestartet hat.)

[t-lenz]

@fagu: eher nicht ;-). Ich kümmere mich um die Fehlermeldung.