HIVE-Project

kuroneko hat geschrieben:

Zeus hat geschrieben:- Umlaute mag der OpenSpin nicht. Daher meckert er tief in der bel-keyb.spin:400. Da taucht im Assembler-Code ein 'ä' auf.

Funktioniert hier (wird als $E4 compiliert).

openspin: unter MingW32 mit der vor/letzten Revision vom git.

Windows scheint damit etwas anders umzugehen. Oder liegts am auschecken mit GIT? Oder...?

Ein: file lib/bel-keyb.spin
liefert: lib/bel-keyb.spin: UTF-8 Unicode text

was man dann auch schön sieht mit: cat lib/bel-keyb.spin | grep ä | hexdump -C
bekommt man:
00000000 20 20 20 20 20 20 20 20 69 66 5f 7a 20 20 20 20 | if_z |
00000010 20 20 20 20 20 20 20 20 6d 6f 76 20 20 20 20 20 | mov |
00000020 64 61 74 61 2c 23 22 c3 a4 22 0a |data,#"..".|

c3 a4 ist die UTF-8-Variante eines ä's.

Die verschiedenen Kodierungen sind hier übersichtlich dargestellt:
http://www.torsten-horn.de/techdocs/encoding.htm

Davon gibts noch einige weitere im Source. Pfeil nach links zum Beispiel und auch schon im Kommentar " This should be helpful for translatíons of this driver into".
Der Kommentar lässt sich leicht anpassen, ob man die anderen einfach mit iconv wegwerfen kann weis ich spontan nicht.

Zeus hat geschrieben:Ein: file lib/bel-keyb.spin
liefert: lib/bel-keyb.spin: UTF-8 Unicode text

Ich hab noch das SVN repo hier auf der Platte:
Little-endian UTF-16 Unicode English text, with CRLF line terminators

Und mit Marke Eigenbau (ISO-8859) geht's auch. Scheint am UTF-8 zu liegen.

Zeus hat geschrieben:Windows scheint damit etwas anders umzugehen. Oder liegts am auschecken mit GIT? Oder...?

Zeus hat geschrieben:Ich hab noch das SVN repo hier auf der Platte:
Little-endian UTF-16 Unicode English text, with CRLF line terminators
Und mit Marke Eigenbau (ISO-8859) geht's auch. Scheint am UTF-8 zu liegen.

Kann schon sein, daß es hier mit den aus dem Git ausgecheckten Versionen Probleme gibt. Git vereinheitlicht die Kodierungen, so daß es möglichst wenig Probleme mit den Vorlieben der verschiedenen Betriebssysteme gibt. Ich habe u.a. deswegen alle Spin-Files in UTF-8 gewandelt und die Zeilenenden auf LF statt CRLF geändert. Damit kann man die Sourcen z.B. auch besser mit Programmen anzeigen, die kein UTF-16 können. Mit BST sind dabei bisher keine Probleme aufgetreten (zumindest habe ich nichts bemerkt).

Wenn es doch Probleme mit der Codierung gibt: einfach in die entsprechende .gitattributes eine Zeile

dateiname -text

setzen, um die automatische EOL-Konvertierung von Git für dateiname zu deaktivieren. Dies ist die Lösung, wenn das Problem nur einzelne Dateien betrifft. Wenn das Problem sehr viele Dateien betrifft, gibt es auch eine Lösung - die erkläre ich aber erst, wenn das Problem wirklich konkret auftritt.

Die .gitattributes nutze ich schon. Problem ist eher, zu entscheiden, welche Datei welche Kodierung und welche Zeilenenden haben muß. Relativ einfach ist das noch bei den Spin-Files. Die sind ja teilweise reiner ASCII-Code, mal UTF-8 und oft UTF-16. Die Zeilenenden sind auch mal CR und mal CRLF. Die habe ich erstmal alle in UTF-8 und LF am Zeilenende gewandelt. Wenn ich richtig liege, werden die Zeilenenden je nach Betriebssystem unterschiedlich ausgecheckt, z.B. bei Windows mit CR und bei Linux ohne. Das dürfte bei Spin-Files auch egal sein. Ich könnte mir aber schon vorstellen, daß meine generelle Umwandlung nach UTF-8 nicht ganz problemlos ist, obwohl ich selbst noch keinen Fehler bemerkt habe. Deswegen wären viele Tests ganz gut.

Schwieriger ist es, wenn Projekte andere Textdateien enthalten, die dann z.B. vom Hive selbst angezeigt werden sollen (z.B. irgendwelche Hilfe-Seiten). Hier kommt es dann auf das Hive-Programm an, wie es Kodierung und Zeilenumbruch handhabt. Da ging es dann ohne .gitattributes nicht mehr.

Am Ende will ich damit aber niemanden verwirren, eigentlich sollte es schon so sein, daß man die einzelnen Projekte einfach auschecken und übersetzen kann.

Ich habe gerade die TriOS Version aus GIT installiert: Der erste Test war sehr erfolgversprechend. Zu den anderen Paketen kann ich noch nichts sagen. Die einzige kleine Sache, die mir aufgefallen ist: Im Verzeichnis vom Basic befindet sich die Datei m-glob-con.spin - das sind die Konstanten für mental. Aber ansonsten scheint erstmal alles zu funktionieren: die diversen Soundplayer, Plexus, Basic, mental. Games habe ich noch nicht getestet, aber da fehlt ja eh noch das Paket. Mit TriOS R58 wird es auch zeitgleich eine Toolbox 3 geben.

Könnte sein, dass ich die nächste Version auf GIT erstelle. Ich meine, allgemein muss man sagen, dass die ganzen Versionsverwaltungen ein ziemlicher Aufwand sind - egal ob nun GIT oder SVN. Mit der nächsten Version muss ich nun natürlich erstmal wieder schauen, wie das zusammenführen von Code mit GIT funktioniert. Aber wenn wir eine gemeinsame Struktur für TriOS, die Toolboxen, Games, Basic und Plexus finden, lohnt sich wahrscheinlich der Aufwand. Macht es irgendwann Sinn einen globalen Buildscript zu machen?

Hauptsache die jeweils aktuälteste Version von TriOS bleibt für nicht-Entwickler auf der Hive-Website weiterhin *einfach*, ohne irgendwelchen Klimbim herunterladbar, dann könnnt ihr Jungs mit GIT oder sonstnochwas gerne rumspielen soviel ihr Spass dran habt.

drohne235 hat geschrieben:Ich habe gerade die TriOS Version aus GIT installiert: Der erste Test war sehr erfolgversprechend.

Prima, danke für die Tests.

drohne235 hat geschrieben:Die einzige kleine Sache, die mir aufgefallen ist: Im Verzeichnis vom Basic befindet sich die Datei m-glob-con.spin - das sind die Konstanten für mental.

Ich hab gerade mal Basic ohne die m-glob-con.spin compiliert - funktioniert natürlich auch. Da müssen wir zille9 fragen, warum das in seinem Archiv drin ist, vielleich wollte er ein Mental-Basic bauen

drohne235 hat geschrieben:Games habe ich noch nicht getestet, aber da fehlt ja eh noch das Paket.

Damit (mit dem GamesPack) hatte ich auch schonmal angefangen. Hab es dann aber vorerst aufgegeben, weil die dazugehörigen Sourcen teilweise zu undurchsichtig waren.

drohne235 hat geschrieben:Ich meine, allgemein muss man sagen, dass die ganzen Versionsverwaltungen ein ziemlicher Aufwand sind - egal ob nun GIT oder SVN.

Eigentlich nur am Anfang, weil man sich natürlich etwas damit beschäftigen muß. Ansonsten braucht man im Wesentlichen nur 3 zusätzliche Dinge: Git auschecken, evtl. Branch erstellen und wieder einchecken. Zwischen Branch erstellen und einchecken wird dann ganz normal programmiert.

drohne235 hat geschrieben:Mit der nächsten Version muss ich nun natürlich erstmal wieder schauen, wie das zusammenführen von Code mit GIT funktioniert.

Für die nächste Version würde ich das noch nicht machen. Da müssen wir erstmal auf einen gemeinsamen Stand kommen. Entweder bastelst Du Deine Änderungen in die aktuelle Git-Version "von Hand" rein, alternativ kannst Du mir auch alles zukommen lassen, dann mach ich das (ich hab jetzt sowieso Erfahrung damit).

drohne235 hat geschrieben:Macht es irgendwann Sinn einen globalen Buildscript zu machen?

Hab ich auch schon überlegt, mir fehlt aber noch die Idee, wo wir den im Git ablegen
Abgesehen davon kann sich den bei Bedarf jeder auch selbst erstellen. Ist ja nur ein cd ins jeweilige Verzeichnis und ein Aufruf von make.bat/make.sh.

Micha hat geschrieben:Hauptsache die jeweils aktuälteste Version von TriOS bleibt für nicht-Entwickler auf der Hive-Website weiterhin *einfach*, ohne irgendwelchen Klimbim herunterladbar

Ich bastle gerade noch an den Release-Scripts der einzelnen Projekte. Auf Anregung von drohne235 wird es dann getrennte Archive für Binaries und Sourcen geben. Da ist dann auch keinerlei Klimbim drin

Aktueller Status: PlexBus funktioniert noch nicht mit dem GIT-Code, liegt aber eventuell am alten Stand - konnte es noch nicht eingrenzen.

Bin gerade dabei die R57 zu exportieren und habe es in ein BIN und ein Source-Paket getrennt. Einfache Nutzer nehmen das Paket mit den Binärdateien und können alles sehr einfach installieren. Ein paar Klicks und die Sache läuft - das funktioniert prima und gefällt mir so.

@Micha: Ich bin natürlich nach wie vor skeptisch, und werde darauf achten, dass es immer auch ein einfaches Paket im Downloadbereich geben wird, mit welchem man ohne GIT/SVN-Installationsorgie unkompliziert lokal experimentieren kann.

Letztlich macht das alles nur Sinn wenn es mehr Mitstreiter gibt, allein bin ich tausendmal schneller mit meiner lokalen Arbeitsweise. Nun ja, und die Mitarbeiterzahl ist jetzt trotz hippem GIT auch nicht gerade gewachsen... Aber vielleicht gibt es ja auch so schon positive Synergieeffekte - schauen wir mal. Allein wenn wir mit allen Paketen eine gemeinsame Struktur finden wäre das wohl eine tolle Sache. Momentan lockt mich da aber mehr der modulare Administra-Code.

Plexbus konnte ich mangels Hardware auch nicht testen. Ich hab einfach den Stand vom Plexus übernommen, keine Ahnung, wie aktuell der ist...