Meeting 2017 01 17
Anwesend:
- Jürgen Richter-Gebert
- Aaron Montag
- Michael Strobel
- Martin von Gagern
Martin hat einen Branch angefangen und am 4.11. eine Mail dazu geschrieben. Sollten wir noch mal ansprechen.
Jürgen erinnert sich, dass er irgendwann eine Konstuktion hatte, bei der ein sich analytisch bewegender Punkt auf dem Kegelschnitt unmöglich verhindern kann, ins komplexe abzudriften. Daher ist der ANsatz von Cinderella, mit Geraden durch den Mittelpunkt, nicht wesentlich schlimmer als viele Alternativen.
Welche internen Interfaces geben gewrappte Objekte zurück, und welche native? Welche Argumente sind gewrappt und welche nativ? Welche Typ-Checks (ggf. rekursiv) muss der Aufrufer machen, und welche die aufgerufene Funktion? All das ist etwas uneinheitlich im Moment. In einer Sprache mit statischer Typisierung (oder mit hinreichend vielen Annotationen für den Closure Compiler) würde das Typsystem auf sowas aufpassen, aber so müssen wir selber da drauf achten, dass wir das konsistent hinbekommen. Bei der Gelegenheit sollten wir vermutlich auch auf die _helper-Namensräume für List und CSNumber reden.
Anlass: Habe zwei kaputte Aufrufe von List.isNumberMatrix(…) gefunden, wo ein anschließendes .value vergessen wurde. Siehe #546. Und habe mich sehr gewundert, dass das Argument zu List.zeromatrix zwei komplexe Zahlen sind, statt einfach nur zwei Integer.
Es besteht Konsens, dass die internen Interfaces (List, CSNumber) möglichst wenig gewrappte Typen, Typüberprüfungen bei der Eingabe oder Typunsericherheit bei der Ausgabe haben sollten. All das ist Aufgabe der entsprechenden CindyScript-Operator-Implementierungen oder sonstiger Stellen, an denen der Code mit Objekten von unbekanntem Typ in Berührung kommt.
Passend zu dem Punkt eben: wollen wir statische Typ-Überprüfung haben? Closure Compiler kann das ja, nutzen wir aber im Moment nicht (außer für Plugins). Und manche Konzepte die wir nutzen bildet der nicht so richtig gut ab, insbesondere die Datentypen mit dem ctype. Bin kürzlich (durch Kontakt mit KaTeX) auf Flow aufmerksam geworden. Das kann solche tagged unions abbilden, und zwar so, dass er nach einer Fallunterscheidung anhand des ctype auch weiß, mit welchem Untertyp man es zu tun hat, und ohne weitere Konvertierungen damit arbeiten lässt. Man könnte versuchen, das auf CindyJS anzuwenden, erst mal nur im weak mode. Sollen wir das weiterverfolgen und mal einen Test starten?
Es bestehen Bedenken, noch ein Tool mehr in den Build-Prozess einzubeziehen. Typisierung in JavaScript wirkt mitunter recht aufgesetzt. Es muss davon ausgegangen werden, dass Typannotationen auf absehbare Zeit nicht gewartet werden würden, und damit der Nutzen einer erstmaligen Umstellung bald verflogen sein könnte. Daher ist im Moment keine Einführung von statischer Typisierung geplant. Statt dessen sollen informelle Konventionen strenger eingehalten werden.
In dem Zusammenhang können wir auch noch mal überlegen, ob wir bei der Gelegenheit unsere Codebase auf ES6 umstellen wollen. Einige stellen würden damit deutlich eleganter zu formulieren sein. Wir können immernoch ES5 zum Ausführen verwenden, dank Cross Compilation.
Mehrere Team-Mitglieder würden gerne auch Code in ES6-Notation schreiben. Solange der CLosure Compiler daraus ES5-Code erzeugt, sollte das eigentlich kein Problem sein. Wenn ausgefallenere Konstrukte zum Einsatz kommen, sollte man im Rahmen des Reviews vermutlich mal schauen, wie viel Aufwand diese mit sich bringen, in Codegröße und Laufzeit-Performance.
Auch das Thema Modularisierung ist zu überdenken, nachdem einige Checks mit sauberer Modularisierung leichter realisierbar sind als mit unserem “concat all sources”-Ansatz. Beim Blick auf Alternativen zu js-beautify hat sich auch gezeigt, dass wir mit unserem concat-Ansatz recht unkanonisch und damit von den Tools her recht inflexibel sind.
Das wäre eine größere Baustelle, und solche sollten derzeit nicht aufgemacht werden.
Bisher haben Conics bei uns eine Matrix. Wollen wir eine zweite mit dazu legen, um primale und duale Beschreibung gleichzeitig parat zu haben? Vorteil wäre, dass wir damit in einigen degenerierten Situationen noch genug Infos hätten, um z.B. den Mittelpunkt zu beschreiben. Außerdem würden wir es vermeiden, für jede Operation die das braucht erneut zu dualisieren. Nachteil wäre erhöhter Aufwand falls die Duale gar nicht gebraucht wird.
Kegelschnitte als Primal-Dual-Paare zu führen macht Sinn, sollte so eingeführt werden.
Martin berichtet zum Stand der Dinge.
Jürgen wird die aktuellen Branches zu conicDrawing3 und conicDrawing4 mal anschauen, um mit zu entscheiden, welche Ansätze langfritig besser zu waren sien dürften.
Meshes und Texturen
Es ist derzeit eine Bachelor-Arbeit am Laufen, außerdem ein Vortrag am 25./26.1. geplant, bei denen Dreiecksmeshes mit benutzerspezifizierten Normalen und Texturen nützlich wären. Es kann davon ausgegangen werden, dass neben dem einen Objekt mit der einen Textur in diesen Inhalten keine weiteren Meshes verwendet werden, so dass eine vorläufige Implementierung die Textur auf alle gerenderten Dreiecke anwenden kann.
Die diversen Pages- und Taskpaper-Dateien im Admin-Verzeichnis sind hoffnungslos veraltet. Soll irgendwas daraus in das GitHub Ticket-System oder sonstwohin übernommen werden, bevor die gelöscht werden?
Die Dateien können gelöscht werden. Für den Notfall sind sie immernoch in der git-Historie.
Martin schreibt an einem.
Die Ausrichtung erscheint auf den ersten Blick sinnvoll.
Wir (Aaron, Jürgen und Michael) hatten gestern eine kurze Diskussion wie man CindyJS auf den Desktop bringen kann. Stichworte waren u.a.: Speichern/Laden, Parsing von cdy Dateien, Look and Feel, Eingabemethoden und Deployment. Michael hat Frameworks wie Electron vorgeschlagen.
Eine Standalone-Anwendung macht Sinn, aber die Möglichkeit einer Konstruktionsumgebung im Browser sollte darüber nicht vergessen werden. Ersteres kann besser aufs lokale Dateisystem zugreifen, letzteres hingegen braucht nicht installiert werden und senkt somit die Hürde.
Als Speicherformat bietet sich JSON an. Es ist möglich, auch die Skripte direkt in der JSON-Datei zu speichern, ohne HTML-Tags dafür zu brauchen.
CDY-Dateien parsen zu können dürfe an einzelnen Stellen etwas problematisch sein, insbesondere dann wenn die Information zur Auswahl des Elements bei einer mehrstelligen Funktion nicht direkt die Position ist, wie sie in CindyJS verwendet wird. Aber prinzipiell sollte es möglich sein, die meisten CDY-Dateien auch ohne Mitwirkung von Cinderella zu parsen und zu konvertieren. Als Alternative dazu stellt https://cdyconvert.cinderella.de/ eine Möglichkeit dar, CDY-Dateien serverseitig unter Verwendung von Cinderella-Code zu konvertieren.
Martin, Aaron und Michael sind vermutlich nur noch auf absehbare Zeit unmittelbar an den Projekten beteiligt. Wir sollten für die Zeit danach planen.
Aktuelle Pläne wurden besprochen, und auch Möglichkeiten der Informationsweitergabe angesprochen.
Die nächste Videokonferenz ist für Donnerstag den 9. Februar um 14 Uhr geplant.