Hello, Guest the thread was called5.4k times and contains 76 replays

last post from Lipti at the

Eigene WinVICE-Änderungen

  • Tja, Windows kann aber Symlinks... Auch wenn die GUI das nicht durchgängig kann. Allerdings: So lange er den Symlink nicht kaputt macht, ist das auch egal. Ist in diesem Fall ja nur eine Doku.

    Hab selber mal mit den Link-Geschichten bei NTFS was gemacht, aber gerade weil das so schlecht von den Programmen unterstützt wird hat man dadurch mehr Probleme als es nützt. Verwende die deshalb nur unter Linux.


    Ich gucke nochmal bzgl. Linefeeds und wenn das passt kann ich auf den Branch aufbauen und die anderen ableiten...

  • Und ich stecke gerne länger Zeit für ein solides Fundament fürs Arbeiten, um danach effizienter arbeiten zu können, als die ganzen Änderungen, Versuche etc. lokal in verschiedenen Sourcecode-Verzeichnissen durchzuwurschteln

    Das tönt vernünftig. :thumbsup: :thumbup:

    Und ist wohl genau das Gegenteil von dem, was ich selber gemacht hätte. ;( :/

  • markusC64


    Diff des Branches (welcher den offiziellen Code als Basis enthalten soll) meines Repos (via deines Repos über svn-mirror) gegen das offizielle Subversion passt trotz meiner Windows-Zwischenverarbeitung unter Linux:

    Code
    1. andre@debian:~/repotest$ diff -qr svn/trunk/ git/WinVICE-plus/
    2. Only in git/WinVICE-plus/: .git
    3. Only in git/WinVICE-plus/: .gitignore
    4. Only in svn/trunk/: .svn
    5. andre@debian:~/repotest$

    (Edit: in der ersten Version meiner Nachricht hatte ich diff nicht rekursiv angewandt)


    Gegentest, dass "diff -qr" die Zeilenumbruch-Steuerzeichen mitvergleicht:

    Code
    1. andre@debian:~/repotest$ diff -qr lf/ crlf/
    2. Files lf/test/test.txt and crlf/test/test.txt differ
    3. andre@debian:~/repotest$ diff -r lf/ crlf/ | cat -t
    4. diff -r lf/test/test.txt crlf/test/test.txt
    5. 1c1
    6. < Test
    7. ---
    8. > Test^M

    (Edit 2: auch den Gegentest auf rekursiv angepasst...)


    "^M" ist das abweichende CR im Zeilenumbruch im Gegentest.


    Somit sind unsere Branches des offiziellen VICE über dein svn-mirror in unseren Git-Repos identisch, perfekt! Nächster Schritt kann folgen... :)


    Das tönt vernünftig. :thumbsup::thumbup:

    Und ist wohl genau das Gegenteil von dem, was ich selber gemacht hätte. ;(:/

    Ich sehe die Dinge nie schwarz/weiß, habe ja selber bei diesem Problem eingangs die "schnelle" Vorgehensweise gewählt, um erstmal schnell anhand der Ergebnisse die Situation abschätzen zu können. Die Alternative wäre ja, dass man immer nur mit sauberem Aufbau beschäftigt ist, selbst bei den Dingen, die sich relativ schnell als Irrweg herauskristallisieren. Man muss halt dann nur den richtigen Zeitpunkt erwischen wann man auf "ordentlich" schwenkt. Ansonsten verwaltet man nur noch das Chaos, und das macht keinen Spaß. Das einzig Dumme an der Vorgehensweise ist, dass man für die Zeit nach außen erstmal keine Ergebnisse sieht. So hatte ich ja AW182 dadurch anfangs erst einmal schnell Testversionen geben können, jetzt sitzt er aber aufgrund meiner Reorganisation vorerst auf dem Trockenen; es wirkt dann halt nach außen so, als würde man derzeit nichts an dem Thema machen.

  • Etwas Merkwürdiges hat mich an anderer Stelle forschen lassen: Die bei Sourceforge gespeicherte WinVICE-3.2-x86.7z unter https://sourceforge.net/projec…eleases/binaries/windows/ scheint nicht genau dem Codestand vom Sourcecode-Tag "v3.2" zu entsprechen:


    Der "v3.2"-Tag, der unter Revision 34854 eingecheckt wurde, enthält Änderungen des "trunk"-Branches bis Revision 34852. Die Revision im entpackten Verzeichnisnamen lautet 34842, die des About-Dialogs im VICE die Revision "34843M". Schaut man sich im Hilfe-Menü in der deutschen Spracheinstellung die Kommandozeilen-Parameter an, bemerkt man die fehlende Übersetzung bei "-silent" ("Disable verbose log output."), die u.a. scheinbar zwischen den fehlenden Revisionen eingecheckt wurde.


    Nun frage ich mich, ob bei Sourceforge-Files eine veraltete 3.2er-Version abgelegt wurde, oder ob das wirklich die war, die auf der VICE-Website zum Download angeboten wurde. Ggf. gab es dort ja eine aktualisierte Version, die nur nicht bei Sourceforge abgelegt wurde.


    Und ich überlege, was logisch korrekter wäre, von welcher Revision ich den neuen Branch (auf Basis Version 3.2) ableiten soll; ich weiß, dass es im Endeffekt egal ist, aber ich denke trotzdem drüber nach. :) Logisch sinnvoller wäre ja die Version, die die User unter Windows wirklich hatten. Dann wäre selbst die fehlende Übersetzung eine Änderung ggü. der denen bekannte Version.

    Normalerweise würde ich bei Release-Tags aufsetzen, aber das setzt auch wirklich eine Synchronität zwischen Release-Tag und Release-Bindist voraus. ;)

  • Hm, ich habe ja meine Version auf die allerletzte VICE-Version aufgesetzt, die noch WIN32-Native-Support hat. Jedoch ist das ziemlich egal, beim Merge hätte man die Änderungen eh drin.


    Im Zweifel nimm die ältere, ein Rebase auf eine neuere Version ist leicht - umgekehrt um ist de Aufwand größer.

  • So hatte ich ja AW182 dadurch anfangs erst einmal schnell Testversionen geben können, jetzt sitzt er aber aufgrund meiner Reorganisation vorerst auf dem Trockenen; es wirkt dann halt nach außen so, als würde man derzeit nichts an dem Thema machen.

    Das ist verkraftbar, dafür weiß man dann ja, dass demnächst was kommen wird, was noch besser funktioniert als es die bisherige Testversion eh schon tut. :thumbup: Da warte ich dann gerne erstmal ab, ohne dass es was ausmacht. Man kann ja froh sein, dass sich überhaupt jemand der Thematik nun annahm.


    Und an alle kann ich schon mal sagen, LIPTI und ich, wir haben uns auch mal Gedanken gemacht, was noch sinnvoll und cool wäre zum einbauen, also auch noch über Sachen wie 2.4 SID-Filter und 8-SID Support hinaus. Ein paar Punkte wurden da besprochen, die man gut brauchen könnte im Emulator und Vorschläge wurden gemacht. Wenn das alles umgesetzt werden kann, dann wird eine tolle neue WinVICE Version kommen in naher Zukunft, mit ein paar neuen und vor allem sinnvollen, Zusatz-Funktionen.


    Ich halte das auch für eine sehr gute Idee mit dem Zusammenführen der Neuerungen zu den Versionen von "markusC64". Er und der Rest von "Tuneful Eight" sind ja sowas wie SID Spezialisten, würde ich mal sagen. Dann ist auch dieser Bereich gleich super mit abgedeckt. Tolle Sache, das Ganze.

  • Im Zweifel nimm die ältere, ein Rebase auf eine neuere Version ist leicht - umgekehrt um ist de Aufwand größer.

    Guter Tipp!


    Ich finde es außerdem schräg, dass die im .7z enthaltene Version im About-Dialog eine neuere Revision inkl. "modified working copy"-Marker hat als der Verzeichnisname des Builds, in dem alles enthalten ist.


    Die Revision im About-Dialog kommt aus der subversion.h, der Inhalt wird allerdings automatisch generiert und dafür das SVN-Programm "svnversion" herangezogen. Wie die Revision in den Verzeichnisnamen kommt, konnte ich bisher nicht nachvollziehen; bisher haben die von mir betrachteten Codepfade nur die reine Version (also z.B. "3.2" in das bindist-Verzeichnis) aufgenommen, aber ohne ergänzenden Bindestrich und folgender Revision. Ggf. gab es ein umgebendes Build-Skript des Erstellers, der den Verzeichnisnamen um die SVN-Revision ergänzt; allerdings würde ich dann noch weniger die Abweichung in diese Richtung verstehen. Umgekehrt könnte ich es eher nachvollziehen, wenn die SVN-Revision zum Zeitpunkt des Verpackens neuer ist als die des Builds selbst.


    Wenn du unter Linux einen Cross-Compile machst, hat das resultierende Verzeichnis nach bindist die SVN-Revisionsnummer im Verzeichnisnamen? Wobei du da selbstverständlich aus einem Verzeichnis heraus kompilieren müsstest, welches unter Subversion-Versionskontrolle steht.


    Scheinbar kommt das .7z von vice.pokefinder.org, zumindest sagt das die enthaltene buildnote. Auch die neusten Builds dort haben noch genau dieses Format der Bezeichnung.

  • Wenn du unter Linux einen Cross-Compile machst, hat das resultierende Verzeichnis nach bindist auch die SVN-Revisionsnummer im Verzeichnisnamen? Wobei du da selbstverständlich aus einem Verzeichnis heraus kompilieren müsstest, welches unter Subversion-Versionskontrolle steht.

    Müsste ich mal prüfen - weiß ich gerade gar nicht, weil ich i. d. R. eine Version ohne Versionsverwaltung als Grundlage nehme - in der Tat ein per "git archive" erzeugtes tar.

  • Könnte Sinn machen, wenn ich für die aus Git gebauten Versionen im About-Dialog statt der SVN-Revision folgendes Anzeige, was zum Zeitpunkt des Builds gültig war:

    • Git-Hash, der im lokalen Verzeichnis während des Builds die Basis war
    • Info, ob es Änderungen ggü. obigem Hash-Stand gab (analog modified-Marker von SVN)
    • ggf. Git-Branch (master wäre dann Releases während z.B. develop nightly o.ä. wären)
    • ggf. Anzahl Commits in jenem Branch, da es keine fortlaufenden Revisionen in solch verteilten Versionskontrollsystemen gibt; wäre allerdings zwischen unterschiedlichen Personen nicht kollisionsfrei, sofern Änderungen noch nicht gepusht wurden
  • Ich finde es außerdem schräg, dass die im .7z enthaltene Version im About-Dialog eine neuere Revision inkl. "modified working copy"-Marker hat als der Verzeichnisname des Builds, in dem alles enthalten ist.

    Könnte es denn sein, dass die alten Revisionsnummern abwichen, vom nativen WinVICE zum VICE allgemein? Vielleicht wurde im Build immer der allgemeine VICE Stand bezeichnet und bei den Versionen für die jeweiligen Betriebssysteme wich das dann ab? Könnte sowas in der Art vielleicht der Grund dafür sein?

  • Könnte es denn sein, dass die alten Revisionsnummern abwichen, vom nativen WinVICE zum VICE allgemein?

    Möglich, vielleicht wurde die Windows-Version vor anderen (und den dazwischen erfolgten Änderungen) gebaut... Aber das erklärt mir noch nicht, warum das Verzeichnis, in dem die Binärdistribution enthalten ist, eine niedrigere Revision als der kompilierte Inhalt hat.


    Stell dir vor, du schreibst einen Brief (analog zum Compiler, der aus dem Sourcecode im Falle von Windows die EXE baut) und nutzt dafür Briefpapier, auf das dir automatisch das aktuelle Datum gedruckt wird. Später verpackst du diesen Brief in einen Umschlag (analog zu "make bindist", der die kompilierten Dateien inkl. Hilfsdateien "zusammenschnürt"), der wird auch mit einem Datum versehen.


    Das Datum des Briefs kann eigentlich nicht neuer sein als das Datum des Umschlags.

  • Stell dir vor, du schreibst einen Brief (analog zum Compiler, der aus dem Sourcecode im Falle von Windows die EXE baut) und nutzt dafür Briefpapier, auf das dir automatisch das aktuelle Datum gedruckt wird. Später verpackst du diesen Brief in einen Umschlag (analog zu "make bindist", der die kompilierten Dateien inkl. Hilfsdateien "zusammenschnürt"), der wird auch mit einem Datum versehen.


    Das Datum des Briefs kann eigentlich nicht neuer sein als das Datum des Umschlags.

    Vielleicht hat es der Postbote geöffnet (solche Fälle gibts ja öfters mal) und selbst irgendwas abgeändert. *lol* :)


    Nein, im Ernst. Keine Ahnung wie das abweichen kann? Ist schon bisschen merkwürdig. Ich bin mir auch nicht sicher, ob es überhaupt zu jeder Revisions-Änderung dann immer kompilierte Versionen gab, aber das beantwortet die Frage ja auch nicht.

  • markusC64

    Nachdem ich mit dem ermittelten Aufsetzpunkt zufrieden bin, der wohl der Binärdistribution von WinVICE 3.2 am besten entspricht, folgende Frage:


    Wie wird deine .gitignore erzeugt? Hat es einen Grund, warum die .o-Objektdateien nicht enthalten sind? Würde sie dann lokal bei mir aufnehmen, um sie nach einem "make" nicht als untracked files angezeigt zu bekommen...

  • Die ".gitignore" ist eine maschinelle Umsetzung der svnignore-Eigenschaft - und der Algorithmus dazu ein Geheimnis des Herstelelrs der Umsetzungssoftware. Deswegen kann ich Dir nicht mehr dazu sagen.


    Auf der anderen Seite sind erwartbare Mergekonflikte in der .gitignore auf jeden Fall überschaubar, so dass man die durchaus anpassen kann.

  • Die ".gitignore" ist eine maschinelle Umsetzung der svnignore-Eigenschaft - und der Algorithmus dazu ein Geheimnis des Herstelelrs der Umsetzungssoftware. Deswegen kann ich Dir nicht mehr dazu sagen.

    Scheint/schien zumindest bei dem Mirrorstand von Revision 34842 nicht dasselbe Verhalten zu zeigen, auch wenn ich noch nicht genau geschaut habe, warum.


    Bei deiner git-Version mit Hash 3930b09da5f60d5d27909f4e455d5f84bd187bcf (entspricht obiger Revision), wird nach ./autogen.sh und ./configure angezeigt:

    Code
    1. Untracked files:
    2. (use "git add <file>..." to include in what will be committed)
    3. vice/libvicetest.a
    4. vice/vicetest.o

    Nach einem make noch viel mehr...


    Bei der offiziellen svn-Version der Revision 34842 erscheint nach ./autogen.sh und ./configure bei svn status keine Datei als nicht getracked.


    Ein erster flüchtiger Blick u.a. auf svn-ignores mittels...

    Code
    1. svn proplist -v -R

    ...konnte keine entsprechenden Eigenschaften zeigen, die von der .gitignore abwichen.


    Ich schaue da aus Interesse nochmal genauer nach...

    Auf der anderen Seite sind erwartbare Mergekonflikte in der .gitignore auf jeden Fall überschaubar, so dass man die durchaus anpassen kann.

    Sehe ich auch so. Ich schaue gerade nur, in welchem Branch ich das bei mir anpasse. Im "vanilla-vice" möchte ich eigentlich genau das Verhalten des offiziellen svn-Repos nachbilden. Sollte sich obiges Verhalten als schon dort unterschiedlich bewahrheiten, werde ich direkt dort die .gitignore anpassen. Ansonsten erst in einem abgeleiteten Branch. Möchte das möglichst sauber halten.

  • Zur Info: Die weitere Analyse deutet darauf hin, dass SVN-Mirror nicht die Default-Ignores von Subversion in die .gitignore übernimmt, sondern nur die Repo-spezifischen (wodurch sich praktisch aber das Verhalten unterscheidet). Standard-Ignores bei Subversion sind scheinbar:

    Code
    1. *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo __pycache__ *.rej *~ #*# .#* .*.swp .DS_Store [Tt]humbs.db

    Mal hier in die .gitignore klöppeln :) Bin mir nur unschlüssig, welche Position im File für anschließende automatische Merges besser ist: Anfang des Files, Ende des Files, irgendwo dazwischen...

  • . Im "vanilla-vice" möchte ich eigentlich genau das Verhalten des offiziellen svn-Repos nachbilden. Sollte sich obiges Verhalten als schon dort unterschiedlich bewahrheiten

    Das würde ich nicht machen - dann führen neue Commits der Entwickler von VICE nämlich direkt zu nicht mehr per FF in die "vanilla-.vice" übernehmbaren Commits... ich würde das nicht wollen.

  • Das würde ich nicht machen - dann führen neue Commits der Entwickler von VICE nämlich direkt zu nicht mehr per FF in die "vanilla-.vice" übernehmbaren Commits... ich würde das nicht wollen.

    Sehr guter Punkt, vor allem weil die .gitignore durch das automatische Mapping häufig angepasst wird. Danke für den Hinweis.


    Es gäbe noch die Möglichkeit, über den (ggf. nur global verfügbaren) Git-Config-Parameter "core.excludesfile" eine Art svnignore-File einzubinden, welches die default-Ignores von Subversion enthält. Wobei ich sowas nur nehmen würde, wenn sich das auf das Repo begrenzen lässt (also nicht nur global).


    Ich tendiere zur Ergänzung im von "vanilla-vice" abgeleiteten "win-still-in"-Branch, da ich dort zum einen eh massiv Änderungen direkt am Anfang habe (natives UI soll ja drin bleiben), und damit auch kein FF [auch künftig] möglich sein sollte, und zum anderen die Änderungen Committen muss (da würden die vielen fälschlicherweise als untracked [statt ignore] Files massiv die Übersicht stören.