mehr kompilierten Code nutzen

[jvoigtlaender]

Bzw. zumindest mal durchschauen, an welchen Stellen sich noch Dinge aus der Interpreter- in die Compile-Zeit verschieben lassen. Sowohl in aktuellen Aufgabenkonfigurationen als auch im Aufgabentyp-Code selbst.

Zum Beispiel sollten sich ja die Instanzen https://github.com/fmidue/flex-tasks/blob/6b5ceaa44aa1b250d63b20097b0a2a8520b2a864/tasks/proplogic.txt#L194-L195 bereits im logic-tasks Repo deriven lassen und lägen dann kompiliert vor.

Und etwa diese Funktion: https://github.com/fmidue/flex-tasks/blob/6b5ceaa44aa1b250d63b20097b0a2a8520b2a864/flex-task/src/FlexTask/Interpreter.hs#L212-L223 ließe sich, statt als String eingebettet zu sein, in eines der Utility-Module des flex-task Pakets packen und wäre dann bei Aufruf auch bereits kompiliert.

[patritzenfeld]

Und etwa diese Funktion:

https://github.com/fmidue/flex-tasks/blob/6b5ceaa44aa1b250d63b20097b0a2a8520b2a864/flex-task/src/FlexTask/Interpreter.hs#L212-L223

ließe sich, statt als String eingebettet zu sein, in eines der Utility-Module des flex-task Pakets packen und wäre dann bei Aufruf auch bereits kompiliert.

Das geht leider nicht direkt, da dieser Code dann im gleichen Paket liegt, wie die Aufrufe des Interpreters. Das wird direkt unterbunden, indem der Interpreter dann gar nicht läuft und mit Fehler stoppt. Ich habe deshalb schon überlegt, das Interpreter-Modul in ein weiteres Paket abzuspalten, dann gäbe es das Problem nicht. Allerdings kam mir das bisher nicht gerechtfertigt vor, da es nur sehr wenig Code gibt, der davon betroffen wäre.

[jvoigtlaender]

Vielleicht verstehe ich die Abhängigkeiten nicht ganz, aber es gibt doch in der gleichen Datei auch einen Interpreter-Aufruf zu TaskData, und das wiederum benutzt auch Utility-Module aus flex-task. Wieso darf man das da aber nicht hier?

[patritzenfeld]

Der Code In TaskData wird ja nur indirekt aufgerufen. Der Interpreter bekommt davon erstmal nichts mit. Er sieht nur das irgendein Modul geladen wird, das nicht im gleichen Paket liegt. Dieser Code hier wird aber direkt geladen und soll gar nicht in den Config-Modulen vorkommen. Wenn ich dort versuche Code aus dem gleichen Paket zu laden, wird es fehlschlagen.

Das ist wohl eine Sicherheitsvorkehrung, da es anscheinend segfaulten könnte, wenn man aus der eigenen Bibliothek liest. Das scheint aber dank anderer Package-DB in den Config-Modulen nicht zu passieren.

[jvoigtlaender]

Ließe sich dann nicht hier die "Auslagerung" und "Laden vorkompiliert" durch eine kleine Indirektion erreichen, die dennoch nicht gleich Erstellung eines neuen Pakets erfordert?

Und zwar indem die Funktion showWithFieldNumber in das flex-task Paket gepackt wird und dann in https://github.com/fmidue/flex-tasks/blob/6b5ceaa44aa1b250d63b20097b0a2a8520b2a864/flex-task/src/FlexTask/Interpreter.hs#L181-L208 erstmal eine Helper.hs Datei auf die Platte geschrieben wird, welche einfach nur aus dem flex-task Paket die Funktion showWithFieldNumber importiert und reexportiert. Und Helper wird dann wie Global, Parse, Check in den Interpreter geladen?