Sorting Skript für die reaper-kb.ini

mespotine commented 6 years ago

Da Reaper dazu neigt die reaper-kb.ini bei neuschreiben nach einem unklaren System neu zu sortieren, ist das Einpflegen der reaper-kb.ini in den Master-Branch unglaublich schwierig: GitHub kann einfach kein sinnvolles Diff daraus mehr generieren.

Wenn wir ein Skript haben, welches die reaper-kb.ini vor nem committen sortiert nach immer dem gleichen Sortieralgorithmus, könnte das Problem evtl sich erledigen bzw geringer werden.

Die Sortierung muss dabei die Einträge in einzelne Zeilen aufteilen, diese nach ACT, SCR und KEY sortieren und innerhalb nochmal sortieren(also ACT nochmal sortieren, SCR sortieren, KEY sortieren). Danach müssen die Zeilen wieder in die reaper-kb.ini geschrieben werden, in der Reihenfolge: Alle Zeilen, die mit ACT anfangen, dann alle Zeilen, die mit SCR anfangen, dann Alle Zeilen, die mit KEY anfangen.

Dafür sollten wir aber einen stabilen Sortieralgorithmus nutzen, der immer die identische Reihenfolge liefert. Luas "table.sort()" ist das leider nicht(könnte aber vielleicht für unseren Zweck schon ausreichen).

rstockm commented 6 years ago

Dafür. Ist aber REAPER selbst die Reihenfolge nicht vielleicht sogar total egal? Das könnte man nochmal Testen.

mespotine commented 6 years ago

Die KEY-Einträge müssen am Ende sein, der Rest ist Reaper wurscht.

Aber wenn, dann lass uns gleich richtig sortieren... ;)

lootsy commented 6 years ago

Unter Linux/Unix/Mac ist das ja recht einfach zu machen. Unter Win würde ich mit PowerShell starten.

Ich denke dabei an einen pre-commit-Hook. @heikopanjas Wär' das genehm?

Ach so, bei nem Hook, könnte man auch einarbeiten, dass man "unwichtige" Zeilen aus einer ini-Datei löscht (solche, die einen sinnvollen Diff verhindern und keinen (wesentlichen) Inhalt beitragen)

lootsy commented 6 years ago

Mehr oder weniger darf man ja bei allen Entwicklern eine lokale git Installation vorausssetzen. Das hieße, dass auch grep, sort und uniq installiert sein müssten. Korrekt?

Wie wäre es mit

#!/bin/sh
grep ^ACT reaper-kb.ini | uniq | sort  > reaper-kb.iniSorted
grep ^SCR reaper-kb.ini | uniq | sort >> reaper-kb.iniSorted
grep ^KEY reaper-kb.ini | uniq | sort >> reaper-kb.iniSorted
mv reaper-kb.iniSorted reaper-kb.ini

?

Solche Helferlein können wir ja irgendwo sammeln. Z. B. in einem Unterordner, den wir dann in die gitignore werfen.

rstockm commented 6 years ago

Das tut es soweit schon mal auf dem Mac... sortiert halt 255 vor 30, aber ja nun: solange es überall gleich passiert...

lootsy commented 6 years ago

Ja, das macht ne lexikalische Sortierung. Da ist 2 nun mal vor 3. und 25 vor 30 und "255" vor "30 ". Ich glaube das tut nicht weh.

Kann man ja alles noch pimpen. Je nach Bedarf und Komplizierheits-Wunsch, Akkuratesse...

mespotine commented 6 years ago

Es muss halt auf allen Systemen exakt sein. Dann ist mir der verwendete Ansatz eigentlich wurscht :)

fairsein commented 6 years ago

Das sollte mit einen git hook der Sorte pre-commit und pre-receive durchaus machbar sein. Wenn man unter Windows git installiert, kommt ja auch immer die Git Bash mit. Ich würde es unter Windows testen...

rstockm commented 6 years ago

Wie ist das Konzept dieser Git Hooks - sind das Skripte, die dezentral auf den Rechnern vor/nach commit/receive ausgeführt werden? Kann man die nicht auch zentral in GitHub hinterlegen/laufen lassen? Ansonsten: andere .ini sind glaube ich klarer/besser strukturiert. Wenn wir aber „von der Seite“ in Dateien rumfummeln können, wäre das auch für andere .ini interessant um einzelne lokale Einträge zu maskieren (Pfade, Versionsnummern etc..)

mespotine commented 6 years ago

Ich hab jetzt mal ein Lua-Script gebastelt, welches ich mal in nen Branch packe. Das sortiert die Einträge mal durch. Es erstellt auch ne Backup-kopie(für den Fall eines Falles) und prüft, ob nach dem Sortieren noch alle Einträge da sind(wenn nicht: Fehlermeldung ohne Änderung an der kb.ini)

lootsy commented 6 years ago

Ich bevorzuge den Weg über ein Shell-Skript. Das sollte bei einer "vernünftigen" git Installation auf jedem Rechner gleich ablaufen. Lua gehört nicht zu einer Standard-Git-Installation.

@rstockm Genau. Die Hooks sind Skripte, die bei jedem Entwickler lokal laufen. Sie legt man in dem git-Verzeichnis ".git" im Ordner hooks ab. Dort sollten auch diverse Beispiele zu finden sein.

rstockm commented 6 years ago

Kann das denn mal jemand so bauen, dass es für EinsteigerInnen nachvollziehbar ist und robust läuft?

_{Sent with GitHawk}

rstockm commented 6 years ago

@mespotine wie stellst du dir deine Variante denn vor - dass man die händisch aus REAPER heraus aufruft?

lootsy commented 6 years ago

Auf der Arbeit fahren wir folgenden Ansatz:

Wir lassen die Originale da, wo sie sind und kopieren eine bereinigte Version unterhalb von "cleaned" / "niceDiff" / "sexyDiff"...

Für die reaper-kb.ini wäre die bereinigte Variante eben die sortierte: erst ACT, dann SCR, dann KEY. Für weitere "schlimme Dateien" könnte man andere Arten der Bereinigung überlegen / umsetzen und die dann ebenfalls unter "cleaned"... ablegen.

Wenn man dann einen sinnvollen Diff sehen will, ignoriert man halt das Original und guckt für diese Dateien nur im "cleaned"...-Ordner.

Verstanden? Meinungen?

Ich setz das mal im Branch "#30-sortiere-reaper-kb-ini-per-git-hook" um, dann können wir am lebenden Objekt über diesen Ansatz diskutueren. Ok?

rstockm commented 6 years ago

Ja danke, nur zu. Detail: die Sortierung der drei Bereiche bekommt REAPER schon durchaus hin, das ist immer sauber. Aber innerhalb der drei Bereiche kommt es eben zu wirklich sonderbaren Umsortierungen ohne für mich nachvollziehbaren Grund.

lootsy commented 6 years ago

ich habe in dem Branch #30-sortiere-reaper-kb-ini-per-git-hook eine erste Version abgelegt. Die Dateien unterhalb von UsTeamHelper müssen lokal in den Ordner .git/hooks/ kopiert werden.

Dann könnt ihr das mal testen. Die grundlegende Funktionalität ist schon da. Ob sich das Skript auch in "Ausnahmesituationen" gut verhält, muss ich noch testen.

Bei Fragen fragen... Merci.

mespotine commented 6 years ago

@rstockm Ja, die müsste man kurz mal händisch aufrufen. Die Sortierung bekommt Reaper intern auch kaum hin. Nur die Trennung zwischen Shortcuts (immer am Ende) und dem Rest(immer davor), aber schon ACT und SCR-Einträge werden schonmal munter durcheinander gehauen, neue KEY-Einträge können auch mal hier und mal dort eingefügt werden, obwohl es sinnvoller wäre, wenn die immer als letzter Shortcut-Eintrag hinzugefügt werden würden. Das System, wo was einsortiert wird, ist auch nicht nachvollziehbar. Ich vermute mal, dass es irgendwie auch damit zusammenhängt, wann welche Action in Reaper hinzugefügt wurde durch die Programmierer, zumindest bei Shortcuts (KEY-Einträge) scheint es so zu sein. Aber der Rest....dunno...

@lootsy Erhält Dein Sortierer auch die CR+LF am Ende jeder Zeile? Das ist wichtig, sonst funzt das nicht.

Achja: Lua gehört nicht zu ner Standard-Git-Installation, aber zu ner Standard Reaper-Installation ;)

mespotine commented 6 years ago

Egal welchen Sortierer wir jetzt nehmen, wichtig ist, dass wir im master eine damit sortierte reaper-kb.ini einpflegen, die bei neuen Branches immer verwendet wird als Grundlage.

@rstockm Es merged ja nicht jeder die Branches mit dem Master, oder? Ansonsten würd ich sagen: die Sortierung machen die Merge-Meister direkt vorm Mergen. Dann ists in den Händen von wenigen, was ich da erstmal sinnvoller und sicherer fände...

lootsy commented 6 years ago

@mespotine Wenn ich das richtig sehe (verstehe), ist Lua ja in Reaper "nur" einkompiliert. Kann ich Reaper ohne GUI starten und nur ein Lua-Skript ausführen lassen? Quasi Reaper als Lua-Interpreter auf der Kommandozeile "missbrauchen"?

Das scheint mir sehr unflexibel / zu stark an Reaper gebunden.

Generell vermute ich, dass "mein" Ansatz noch nicht verstanden ist:

Die "richtigen" Zeilenenden übernimmt git "automagisch", wenn man das in der Konfiguration richtig einstellt. (vgl. Slack) Die Einstellung heißt core.autocrlf.
Am Ende bleibt die reaper-kb.ini so wie sie von Reaper geschrieben wird! Unsortiert, durcheinander, falsch, inkonsistent.... was auch immer. Das Reaper-Ergebnis wird nicht angetastet! Stattdessen: Es wird eine zusätzliche Datei dem Repo hinzugefügt und zwar unter "niceDiff/reaper-kb.ini". Diese Datei wird so sortiert sein, wie wir uns das vorstellen.

Für künftige Commits sind dann die Vergleiche (Diffs) mit dieser zusätzlichen Datei zu beachten. Nur für diese Datei ist dann ein lesbarer Vergleich (Diff) sinnvoll. Bei jeder Änderung an der "original" reaper-kb.ini wird (per pre commit hook) diese zusätzliche Datei mit aktualisiert.

Ich schreib noch ein wenig dazu auf. Dann werde ich von diesem Branch einen weiteren Branch abzweigen, in dem ihr euch (zum Testen und "Einarbeiten") austoben könnt.

rstockm commented 6 years ago

@lootsy ja mr ist nur unklar, wie das hinterher in der Praxis läuft. Auf keinen Fall dürfen wir halt den derzeitigen Vorteil aufgeben "clone dir die mobile install lokal, lege reaper.exe/app rein und lege los" aufgeben. Dahinter sollte es kein zurück mehr geben im Sinne von "und dann kopiere noch XY um, und konfiguriere dein Git, und..." Sprich im Rootverzeichnis des Repos muss immer eine voll aktuelle und lauffähige reaper.kb.ini liegen - ob sortiert oder nicht ist hingegen zunächst egal. Ich denke das klärt sich, wenn man es mal in Code gegossen sieht.

343max commented 6 years ago

Man macht sich ja immer unbeliebt, wenn man direkt bei seinem ersten Post erst mal ohne auch nur die allergeringste Ahnung zu haben erst mal alles in Frage stellt und einen prinzipiell anderen Vorschlag macht.

Lasst es mich trotzdem tun.

Ich halte es für keine sonderlich schlaue Idee Reapers Einstellungsordner komplett einzuchecken, weil Reaper diesen Ordner für sein “Eigentum” hält und darin macht was es will. Das Problem das gerade auftaucht dürfte nur eines von sehr, sehr vielen sein:

was passiert, wenn Reaper Sachen einträgt die auf allen Systemen unterschiedlich sind, z.B. absolute Pfade?
was passiert, wenn Reaper auf unterschiedlichen Plattformen oder in unterschiedlichen Versionen leicht unterschiedliche inis schreibt?
wie soll eine Migration ablaufen? Wie soll ich als Laie ein Ultraschall Update durchführen ohne meine Einstellungen zu verlieren?
wie wird einfach ersichtlich Dokumentiert welche Änderungen an den Ini Dateien Reaper gemacht hat und welche Änderungen von Ultraschall stammen?
Man kommt so in die Merge Hölle. Wer jemals ein Xcode Storyboard oder Xcodeproj in git mergen wollte weiß wovon ich spreche. Und diese Probleme gibt es, obwohl Xcodes Dateiformate dafür optimiert sind leichter in VCS Systeme mergbar zu sein. Wie ist das wohl bei Dateien denen das total schnuppe ist?

Das wird garantiert ein ewiger Kampf werden und ich halte es für besser wenn dieses Repo nur Config Files enthält und die ganzen von Reaper erstellten Sachen gar nicht mit eingecheckt werden. Diese Config Dateien könnte man dann für human Readability/Editibility strukturieren und müsste sie nicht sortieren damit Reaper sie leichter Mergen kann.

Wie könnte das gehen?

Man bräuchte einen Installer, der alle benötigten Dateien an die richtige Stelle kopiert. inis müsste man mergen: die für Ultraschall benötigten Änderungen werden direkt in die Reaper Datei reingemerged. Wenn es eine neuen Ultraschall Version gibt wird der ganze Prozess wiederholt. Vorteil dieses Verfahrens: sauberes Repo ohne (copyright geschützte) externe Dateien die man händisch mergen muss, klare, saubere Update Methodik. Nachteil: es gäbe einen Installer.

Ich finde die Idee mit dem “Pack Reaper hier rein und doppelklick und alles ist schön” ziemlich cool und erhaltenswert. Wie könnten wir das also erreichen?

Es gibt zwei verschiedene Installationsarten die hier wichtig sind: wie installiert es der User und wie installiert es ein Contributor.

Was ich mir vorstellen könnte: Das Reaper Distributionsverzeichnis enthält eine Minimalkonfiguration:

leere .ini, damit Reaper weiß wo es sich hin installieren muss
ein Ultraschall Update Plugin
ein Ultraschall-Distro Ordner, in dem das ganze Zeug liegt, das kopiert/gemerged werden muss. Wenn der User sein Reaper da reingelegt hat und es das erste mal startet wird das Plugin geladen, kopiert seine Dateien und patcht die gerade erstellten inis. Wenn es damit fertig ist erscheint ein Dialog: “Ultraschall Installation abgeschlossen” [Reaper Neustarten]. Sobald der User das geklickt hat startet Reaper neu und hat sein fertiges Setup. Nicht perfekt aber ziemlich nah dran.

Ein Update würde genau so laufen: wenn das Update Plugin bemerkt, dass im Ultraschall Verzeichnis eine neue Version liegt könnte es den gleichen Prozess durchführen und währe auf dem aktuellen Stand. Wenn das Plugin die neue Version mit downloaden könnte wäre es sogar noch schicker: ich wähle im Menü “Update installieren” aus, das Updateplugin lädt, extracted und patcht und sagt am Ende: “Update fertig” [Reaper Neustarten].

Contributors könnten das genau so machen, es würde nur dazu führen, dass man ständig einen Reaper starten - update - neustarten - Tanz machen müsste. Nervig. Das könnte man fixen, indem man ein Kommandozeilentool baut, dass den Update Teil des Plugins außerhalb von Reaper ausführt. Das könnte entweder passieren, indem man das Update Plugin innerhalb von Reaper triggert sich jetzt zu aktualisieren. Oder man wrapt die Update Routine des Plugins noch mal in einem Shell script. Dieses Tool könnte man dann auch per filesystem Watchdog automatisch triggern oder den Editor seiner Wahl überreden bei jedem Save dieses Script auszuführen. Tools für recompile on FS change gibt es ja wie Sand am Meer.

Ich bin mir natürlich nicht sicher, ob das ganze so funktioniert, halte die Chancen aber für recht gut, solange man aus einem Plugin Dateien beliebig kopieren kann und beliebige INI Dateien lesen kann.

Meinungen?

fairsein commented 6 years ago

Genau das, was Du im letzten Absatz vorschlägst, machen wir doch mit dem git hook Ansatz von @lootsy schon. Warum @lootsy da allerdings eine eigene .ini in irgendeinem Ornder macht, weiß ich auch nicht. Kann man das nicht einfach direkt mit der reaper-kb.ini machen?

rstockm commented 6 years ago

Danke für den Input @343max , das ist so im Wesentlichen auch das Verfahren, das uns für die 4.0 vorschwebt. Das schon früher zu haben jetzt für die Entwicklung, ist auch breiter Konsens. Um ein ganz klein wenig das Drama raus zu nehmen: was uns gerade Schmerzen bereitet, ist eigentlich alleinig die reaper-kb.ini. Die reaper.ini mit den zentralen Settings wird allein von mir verwaltet/beschrieben, das wird auch so bleiben. Unsere ultraschall.ini ist klar aufgebaut und wird wenig Grund für merge-Konflikte geben. Aber egal: das meines (unseres) Erachtens zentrale Stelle ist die hier:

inis müsste man mergen: die für Ultraschall benötigten Änderungen werden direkt in die Reaper Datei reingemerged.

Da liegt bei deinem (unseren) Ansatz das Problem. Die reaper.ini hat ein paar hundert Einträge. Von denen beschreiben wir "zwingend" ca. 40 (Beispiel: Zeit statt Takte als zentrale Entität). Weitere 30 sind "Geschmacksache", die die User selber umstellen könnten (was passiert bei einen Doppelklick im Ruler...). Weitere 30 sollten unbedingt vom User umgestellt werden können (Pfade...). Wie will man so etwas "von der Seite" mergen? Wir bräuchten hier mindestens drei Klassen von .ini Einträgen-Objekten und eine Menge Logik oben drüber. Und das ist nur die reaper.ini - die reaper-kb.ini ist dann noch der eigentliche Endgegner: natürlich sollten die Leute sich Shortcuts umstellen können. Aber dann vielleicht auch wieder nicht alle, siehe Supporthölle ("ich dachte damals, cmd+x brauche ich bestimmt nicht so oft). Und in der Datei herrscht das blanke Chaos, siehe Doku. Klar haben wir dafür jetzt keine Lösung, aber Dein Ansatz ist nur dann realistisch, wenn wir für dieses "semantische mergen" eine Lösungsidee finden. Derzeit haben wir die noch nicht.

343max commented 6 years ago

@fairsein Der hook wird nur ausgeführt, wenn man commited (oder pusht). Der watchdog würde immer triggern wenn man was ändert (auch ohne commit).

343max commented 6 years ago

@rstockm Das sollte sich eigentlich problemlos lösen lassen, man muss sich nur auf eine Syntax einigen. Man müsste unterschiedliche Syntaxen machen für: wird bei jedem Install gesetzt/überschrieben, wird nur beim ersten mal gesetzt/überschrieben, wird nur gesetzt aber nicht überschrieben...

Das könnte man machen, indem man den value ändert, z.B. sowas wie: shortcut-cut: cmd-X würde shortcut-cut: US_ONLY_ONCE cmd-X. Oder man legt die in unterschiedliche Kategorien (statt e.g. [Shortcuts] dann [Shortcuts_US_ONLY_ONCE] oder sogar in unterschiedliche Dateien/Ordner.

Man könnte die Custom Settings sogar in irgendwas anderes Packen als eine ini Datei. Es muss ja nur ein Format sein, dass das Plugin lesen kann.

mespotine commented 6 years ago

Lass uns mal hier im Issue bitte nur auf die reaper-kb.ini konzentrieren. Für das Management aller ini-Files(von denen es vier oder fünf verschiedene Systematiken gibt, die nicht alle wie ne Standard-Windows-Ini funzen) bitte nen eigenes Issue machen, wobei ich denke, es wäre sogar besser im Repo für die 4.0er aufgehoben. Sonst verfransen wir uns hier etwas.

Was mich grad etwas stört ist, dass wir uns grad allgemein etwas verzetteln. Sicher, mit git kann man das Ganze bestimmt irgendwie(tm) lösen, aber:

Funzt die Sortierung mit den Hooks wirklich auf allen Systemen gleich, also Mac, Win und Linux? Und zwar immer? Hat das jemand mal getestet, ob dann auch die identische kb.ini rauskommt? Immer? Edgecases ausgeschlossen bzw mal durchgetestet? Ansonsten haben wir das Grundproblem erneut, nur diesmal in grün. Und bitte nicht "das sollte in git eigentlich so funzen" denn es "sollte" nicht sondern "muss immer" identisch funzen. Ganz wichtig.
Der Ansatz mit den Hooks ist mir etwas zu pfriemelig bislang. Wir müssen da auch im Hinterkopf behalten, dass das Sortieren auch für Git-Unerfahrene noch möglich sein sollte. Wenn es zu kompliziert ist und daher zu Anwendungsfehlern kommt, wirds schnell sehr kompliziert und lästig. Es muss einfach gehen, was auch immer dieses Einfach heißt. Egal ob mit Hooks oder mit meinem Lua-Skript oder irgend nem anderen Ansatz.
Mir fehlt auch noch, welchen Sortierungsalgorithmus wir definitiv verwenden wollen. Es gibt da ja verschiedene Algorithmen, von denen einige "stable" sortieren, also immer vorhersehbar und Andere nicht. Dieser muss auf allen Systemen irgendwie verfügbar sein, in welchem Tool auch immer.
Eine Idee ist ja immer noch, ob wir nicht das Sortieren den Leuten überlassen, die die Merges machen. Dann nehmen wir für weniger Git-Erfahrene(also mir) die potenziellen Komplexitäten aus der Sortierung raus und übergeben die an diejenigen, die git besser verstehen. Diejenigen, die dann die Sortierung machen, müssen aber dann sowohl die Sortierung verstehen, als auch wie die kb.ini funzt, um überprüfen zu können, ob alles noch so klappt wie vorgesehen. Wenn die kb.ini bricht, bricht Ultraschall, da müssen wir mit aller Vorsicht walten.

@lootsy Du brauchst mit meinem Ansatz nur das Actions-Fenster öffnen, dort das Sortierskript suchen, es anklicken, auf den Run-Button klicken. Fertig. Das kricht jedeR in Lua/Reaper-Bastelnde hin da ein Skript auszuführen, bzw sollte Voraussetzung sein, weil vieles in Reaper sich auch um dieses Fenster dreht, sowohl Actions als auch Scripte als auch Shortcuts, ja sogar die Menüs können von dort aus belegt werden. Dazu brauchste Reaper nicht als Lua-Interpreter zweckentfremden, weil Du zum Entwickeln und Testen eh in Reaper bist, das also als letzten Schritt mal schnell machen kannst. Und da Ultraschall Reaper dringend voraussetzt, können wir auch davon ausgehen, dass Reaper da ist.

@343max Der Ansatz mit dem portable-Repo ist einer, der doch sehr gut abgehangen ist. In der Tat gibt es kaum Unterschiede in den Versionen von Reaper zwischen Max,Win und Linux. Du kannst also soweit problemlos das obige Repo in ne Reaper-Installation reinpacken und es läuft, egal ob Windows, Mac oder Linux. Allenfalls kanns unter Linux einige Probleme geben, weil die Linux-Version noch alpha ist, aber das wird auch mit der Zeit. Die größten Systemabhängigkeiten haste eher in den C++-Teilen wie das ultraschall-Plugin, aber ansonsten gibts da wenige systemspezifische Abhängigkeiten, die für uns relevant sind. Das einzige was ich bislang gesehen habe als potenziell schwierig ist der Pfad zu eigenen-eingestellten Aufnahmepfaden, wenn Du also nicht die Default-Pfade nutzt, was wir für die 4.0er durchdenken müssen, um es auch problemlos möglich zu machen, dass Ultraschall auf nen USB-Stick installierst und dort die Aufnahmen drauf machst, aber das ist, wie gesagt, ein 4.0er-Problem, da die 3er Versionen von US portable Installationen offiziell ohnehin nicht supporten. Solltest Du aber über noch weitere Sachen stolpern, die potenziell problematisch werden können, egal in welcher ini, dann sammel die Infos, wie gesagt, in nem eigenen Issue. Damit wir das irgendwo gesammelt haben. Hier gehts doch eher verloren, wenn der Issue geclosed ist irgendwann.

heikopanjas commented 6 years ago

Hier gehts doch eher verloren, wenn der Issue geclosed ist irgendwann. Truer words were never spoken.

rstockm commented 6 years ago

@mespotine habe das Skript mal in zwei Varianten ausprobiert: zuerst innerhalb des Feature-Branches das es mitbringt, danach einmal manuell rüberkopiert in einen frischen master. Beide Male wird abgebrochen mit einer Fehlermeldung (immerhin), hier die aus dem master:

mespotine commented 6 years ago

Okay, schau ich mir mal an. Ich wusste es war ne gute Idee noch nen Check mit einzubauen :D

lootsy commented 6 years ago

Ich bastel mal meinen Vorschlag zu Ende. (check :-)

Now it's your turn....

@fairsein Ich mache einen Extra-Ordner, weil ich ein "Schisser" bin (destruktiv programmieren möchte). Auf der Arbeit setzen wir das bei (z. T. binären M$-)Datei-Formaten ein, die NACH einer solchen Manipulation nicht mehr lauffähig sind. Deswegen gibt es eine "Kopie", die nur dazu da ist, ein lesbares Diff zu ermöglichen.

@343max immer her mit den Ideen (und dem dazu gehörigen Code / Build-System... ;-)

@rstockm Ich glaube, dass git eine gewisse Komplexität mit sich bringt, die "man" nicht einfach "wegdiskutieren" / "wegdeligieren" kann. Ich vergleiche das mal mit der Routingmatrix. ;-) Von daher: etwas Mitarbeit auf Entwicklerseite (Installieren / Pflegen der eigenen Hooks) halte ich für sinnvoll.

over and out

mespotine commented 6 years ago

@lootsy Hmm....was brauch ich denn alles, um den Hooks-Ansatz von Dir zu verwenden? Also system-requirements. Muss ich da irgendwas für installieren? Oder kann git die bash-Skripte auch so ausführen. Wie führe ich die aus? Kann man das irgendwo automatisieren? Kann ich das einfach in der Kommandozeile machen? Wie sortierts die kb.ini? Sind die Zeilenenden CR-LF oder LF oder wie genau? Hast Du mal bruteforce getestet, ob eine sortierte kb.ini nochmal sortieren auch das exakte Ergebnis liefert? Kann Reaper die sortierte kb.ini auch einlesen, auch wenn Du es erstmal nur auf Windows testen kannst... Ich finds etwas unglücklich, dass ich die sortierte kb.ini erst wieder zurückkopieren müsste, bevor ich sie dorthin comitten kann, wo sie im branch sein sollte(falls ich das beim Durchlesen der Doku richtig verstanden habe), da fänd ichs besser, wenn in niceDiff die originale kb.ini läge.

Gibts nen Check dafür, ob auch alle Zeilen drin sind, die in der ursprünglichen vorhanden waren? So als kleiner Validierungscheck, falls Reaper da mal was ändern sollte... Also auch Zeilen, die weder mit KEY ACT oder SCR anfangen...

Ansonsten nice work. Speziell die Doku da drin ist dafür sehr wichtig, sonst würd ich scheitern daran es zu nutzen....

lootsy commented 6 years ago

Hmm....was brauch ich denn alles, um den Hooks-Ansatz von Dir zu verwenden?

git. Da du irgendwie zu diesem Repository commitest / pushed, hast du (irgendeine) Art von Git installiert. Wenn du im Zweifel bist und git selber (nochmal) installieren willst: https://git-scm.com/downloads

Oder kann git die bash-Skripte auch so ausführen.

Die kannst du in der Shell ausführen, die mit (der) git (Installation) mitgeliefert wird (GNU bash).

Wie führe ich die aus?

direkt selber will "man" die nicht ausführen. Dafür existiert ja genau das Hook-Konzept. Die Skripte "haken" (hook) sich in den git Prozess ein. Ein Pre Commit Hook hakt sich eben vor einem Commit ein.

Die Skripte werden automatisch mit ausgeführt, wenn du commitest. Das kannst du selber testen, wenn du meinem Vorschlag zum Testen folgst.

Wie sortierts die kb.ini? Sind die Zeilenenden CR-LF oder LF oder wie genau?

siehe Git Konfiguration - nach autocrlf suchen

Kann Reaper die sortierte kb.ini auch einlesen, auch wenn Du es erstmal nur auf Windows testen kannst...

Ich arbeite nur mit Windows. Mein Sortier-Ansatz ändert nicht die originale Datei. Ich will die sortierte Datei gar nicht an Reaper übergeben.

Ich finds etwas unglücklich, dass ich die sortierte kb.ini erst wieder zurückkopieren müsste, bevor ich sie dorthin comitten kann, wo sie im branch sein sollte(falls ich das beim Durchlesen der Doku richtig verstanden habe), da fänd ichs besser, wenn in niceDiff die originale kb.ini läge.

Da sind wir (vermutlich?) unterschiedlicher Meinung.

Gibts nen Check dafür, ob auch alle Zeilen drin sind, die in der ursprünglichen vorhanden waren? So als kleiner Validierungscheck, falls Reaper da mal was ändern sollte... Also auch Zeilen, die weder mit KEY ACT oder SCR anfangen...

Nein. Kann man (leicht) einbauen.

Speziell die Doku da drin ist dafür sehr wichtig, sonst würd ich scheitern daran es zu nutzen....

Ich habe noch nicht verstanden, was dich hindert, es auszuprobieren / zu testen. Welche Infos / Werkzeuge / Hilfsmittel brauchst du noch? Was ist (noch) unklar?

rstockm commented 6 years ago

Ich glaube was @mespotine (und auch mir) fehlt, ist jetzt einmal der komplette Workflow, wie man denn nun in einem Feature-branch konkret damit umgeht. Deine sehr schöne Doku zum Testen hört ja irgendwie an der spannenden Stelle auf: wie/was kommite und merge ich wie letztlich in den Master, und wie bringe ich den dann wieder direkt lauffähig auf den Rechner? Es ist jetzt (zumindest mir) nicht ersichtlich, was uns die nicediff Datei in ihrem Unterordner bringt, dort wird sie ja von REAPER irgnoriert. Muss man die dann irgendwo umkopieren/umbenennen?

mespotine commented 6 years ago

Ich arbeite nur mit Windows. Mein Sortier-Ansatz ändert nicht die originale Datei. Ich will die sortierte Datei gar nicht an Reaper übergeben.

Hmm...die sortierte kb.ini muss aber hinterher von Reaper verwendbar sein und daher an Reaper übergeben werden. Schließlich soll die auch im Master-Branch landen, von dort nutzbar sein und für weitere neue Branches Verwendung finden können sowie das Mergen erleichtern. Sonst brauchen wir keine sortierte kb.ini. Da müssen wir konkreter nochmal klären, wie das Mergen ablaufen soll. Bin da zu wenig in git drin um zu wissen, wieviel git automatisch mergen kann, ob überhaupt....

Ich habe noch nicht verstanden, was dich hindert, es auszuprobieren / zu testen. Welche Infos / Werkzeuge / Hilfsmittel brauchst du noch? Was ist (noch) unklar?

Zeit. Ich nutz Git nur von GithubDesktop aus und weiß nicht mal, ob es ein git installiert oder alles in der App selbst mitbringt. Ich will auch gar nicht viel mehr von Git sehen ehrlich gesagt, nur genug um hier für Ultraschall basteln zu können im Sinne des WorkflowKonzepts das Ralf sich ausgedacht hat, das ist schon von der Komplexität her mehr als genug für mich. Auch weil mir die Zeit fehlt mich in Reaper UND in Git vollständig reinzufummeln. Und das Selbe gilt ja auch für Casual-Programmierende, die in ihrer Freizeit mal was beisteuern wollen aber auch nicht git in ihrer Tiefe verstehen können oder wollen. Da muss es Rock-Solid und leicht nutzbar sein. Das verhindert ja auch Nutzerfehler, die durch Wissenslücken entstehen, sei es durch Lücken in git, der kb.ini oder irgendein anderer Teil von Reaper, der mit der Sortierung in Berührung kommt. Wenn immer klar ist "so gehts" und "jetzt gabs nen Fehler, wende Dich mal an Leute im Projekt mit mehr Ahnung", dann wär das schon super, so auf niedrigschwelligem Niveau. Wie oben mein Skript sagt "hier ist die Sortierung schiefgelaufen bei dieser Zeile XYZ". Das kann man einfach als Screenshot posten oder in nem Issue schreiben und denen überlassen, die sich darin auskennen (sollten) zum Fixen. Das "hier lief was schief"-erkennen ist mir derzeit beim hook-Ansatz nicht so richtig klar...

Wie sortierts die kb.ini?

Da wär mir noch wichtig, nach welchem konkretem Algorithmus es sortiert. Für den Fall, dass wir da mal was andernorts umsetzen müssen wäre es gut, wenn wir den selben Sortier-Algorithmus verwenden, der mit dem GitHook übereinstimmt. Sprich: BubbleSort? QuickSort? ShellSort? Was nutzt der Hook konkret und wie sehen die Regeln für die lexikalische Sortierung aus, die verwendet werden.

343max commented 6 years ago

Wofür sollte interessant sein, ob ein BubbleSort oder ein QuickSort verwendet wird? Das ist ein Implementierungsdetail, das absolut egal ist: egal welcher verwendet wird, er ist schnell genug. Selbst der ineffizienteste Sortieralgorithmus ist problemlos schnell genug um auf halbwegs aktueller Hardware eure paar hundert Zeilen in deutlich unter einer Zehntelsekunde zu sortieren. Aber das kann man sicher im Lua Quellcode (oder welche Sprache auch immer zum Sortieren verwendet werden soll) nachschauen.

lootsy commented 6 years ago

Nach den Kommentaren war ich etwas verwirrt und mir nicht mehr sicher, ob ich die Aufgabe richtig verstanden habe. Ich habe mir den Anfang des Issues nochmal durchgelesen und bin der Meinung, dass der von mir verfolgte Ansatz genau das leistet, was gewünscht ist: Es geht darum, sinnvolle Diffs für die reaper-kb.ini zu bekommen.

Das ist für die "Kopie" unterhalb von "niceDiff" gegeben. Wie die Originaldatei im Hauptverzeichnis aussieht ist dafür irrelevant. Reaper nutzt das Original, die "schönen Diffs" entstehen dazu parallel "automagisch" in dem Unterordner "niceDiff".

Da die "Kopie" (die vom Hook sortierte ini-Datei unterhalb von niceDiff) ja immer neu (nach einer Änderung und einem Commit) aus der Originaldatei erzeugt wird, ist die "Kopie" - so glaube ich -immer "ausreichend nah" am Original.

Der von mir verfolgte Ansatz ist nur ein Vorschlag. Ich habe mit ihm in meinem Arbeitsumfeld gute Erfahrungen gemacht. Wenn es was besseres gibt, her damit.

mespotine commented 5 years ago

Ich schließe das mal derweil es händisch noch leichter zu machen ist.

mespotine commented 5 years ago

Neuer Versuch, im #137 Pullrequest Ihres Vertrauens

Ultraschall / ultraschall-portable

Sorting Skript für die reaper-kb.ini #30