Noob-Fragen zur Übersetzung eigener Programm

    Hallo zusammen

    Da ich mich bis anhin noch nie mit der Übersetzung von Programmen beschäftigt habe, hier nun ein paar "Noob" Fragen...

    Soweit ich in der SDK-Doku gelesen habe, werden im Source-Code die Chunks und Tokens mit @Localize annotiert. Diese wiederum markieren die zu überstzenden Teile.

    - Ist es korrekt, dass ResEdit die übersetzte Geode selber erzeugt? Keine weiteren Tools, Kommandos oder Konfigurationen?

    - Wann wird die für ResEdit benötgte Resource-Datei (xxx.VM?) erzeugt? Muss ich hierzu etwas spezielles konfigurieren? Makefile-Eintrag? Pmake-Option?

    Besten Dank schon einmal für ein paar hingeworfene Hinweisschilder!

    Andreas

    @localize sind Bemerkungen zu dem Chunks.

    Resedit erstellt die Übersetzte Geode aus der englischen Geode und der zugehörigen VM-Datei die beim kompilieren loc -o geode.vm erstellt wird benötigt rsc Dateien.

    Resedit benötigt 2 Geosinstallationen Source und Target.

    Es gibt hier im GeosInfoBase eine Seite dazu:

    GEOS-InfoBase / ResEdit

    Gruss von Nico

    Hallo Nico

    Herzlichen Dank für den Beschreib zum Vorgehen. Mir hat der Befehl loc -o geode.vm gefehlt. Den kannte ich noch nicht.

    Beim Ausführen des Befehls erhalte ich folgende Meldung:

    Code
    $ loc -o geoladder.vm
loc: No .rsc files found.
* Build the NC version to create the .rsc files. *

    In der local.mk habe ich aber NO_EC = 1 gesetzt.

    Warum keine entsprechende .rsc Dateien erstellt / gefunden werden, ist mir schleierhaft.

    Code
    $ find . -type f -name "*.rsc"
./appui.rsc
./rsc.rsc

    Gehe ich richtig der Annahme, dass am Anfang die Target-Installationen eine Kopie vom von der Source-Installation ist?

    Gruss
    Andreas

    Edited once, last by bolle732 (June 23, 2024 at 9:50 PM).

    Ich kompiliere die geode :

    mkmf

    pmake -n

    loc -o geoladder.vm

    ? Gehe ich richtig der Annahme, dass am Anfang die Target-Installationen eine Kopie vom von der Source-Installation ist?

    TARGET ist eine Geosinstallation mit wo du dann die Geode + VM Datei hineinkopierst.

    Die richtige Methode ist irendwie mit "send" , habe ich nie gemacht.

    Gruss von Nico

    Update:

    Mit loc -o geoladder.vm wird die VM-Datei erzeugt. Die Fehlermeldung, dass keine .rsc Dateien vorhanden sei und man das NC-Target aktivieren soll kommt trotzdem. Werde diese Meldung fürs Erste ignorieren und weiter testen.

    nschu
    Danke nochmals für Deine Unterstützung!

    Wenn keine rsc-Dateien da sind, dann ist die vm-Datei auch wertlos, das sie nicht die richtigen Chunknahmen enthält.
    Versuch mal "pmake full" das sollte alles incl. .rsc und .vm machen. Die rsc werden nur für die NC-Geode gebaut. NO_EC=1 ist daher eigentlich gut. Ansonsten macht ein einfaches pmake immer die EC-Geode ohne rsc files! pmake -n mach nur die NC-Geode.

    @chunk char paul[] ="text hier"; ist automatisch immer** übersetztbar.
    @localize ist optional. Es ist "nur" ein Hinweis an die Übersetzer, was dieser Text soll. Allerdings kann man hier auch Mindest-in Maximallängen festlegen.

    Resedit zwingt dich beim ersten Starten eine "Target" Installation anzugeben. Die übersetzte Geode landet dann genau dort, wo im Originalverzeichnis die Originalgeode ist. Deswegen brauchst du auch zwei Installationen. Und ja, nix weiter Konfiguration, einfach nur den Menüpunkt anklicken und fertig.

    Wenn es immer noch nicht geht, poste mal den gesamten Compiler-Output.

    Rainer

    ** Der Text darf keine Steuerzeichen unter 20hex enthalten!

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

    Nachtrag: die Warnung habe ich damals, als wir das Thema mit den vm-Dateien schon mal hatten , bewusst zu loc hinzugefügt, Eigentlich sollte dort ganz fett ERROR stehen - das hat aber der Build-Prozess von Falk als "hier geht was nicht" aufgefasst. Den Hinweis musst du also ernst nehmen!

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

    Hallo Rainer

    Besten Dank für Deine Hinweise.

    Es sind ja schon .rsc Dateien da. Einaml appui.rsc und einmal rsc.rsc. Auch mit pmake full kommt am Schluss die Meldung. Ich habe die Geode und die VM-Datei im RedEdit öffnen können. Die Chunks sind da ersichtlich. Meine Annotation wird aber im ResEdit nicht aufgeführt.

    Code
    @chunk char Stim1[] = {
 "You eat quiche!"
};
@localize { "This is the first stimulation" 3-64 };

    Zu Testzwecken habe ich einen Chunk angepasst und dies ist in der generierten Geode dann auch so ersichtlich. Somit funktioniert es zwar, aber die Ursache für die Meldung ist mir unbekannt.

    Man kann ansonsten den "alten" Stand meines Codes von Github auschecken:

    GitHub - bolle732/pcgeos-3rdparty-games-ladder: This is a clone of the game Ladder originally written by Yahoo Software for various CP/M systems.
    This is a clone of the game Ladder originally written by Yahoo Software for various CP/M systems. - bolle732/pcgeos-3rdparty-games-ladder
    github.com

    Bei meinen Tests habe ich erst einzelne Annotation hinzugefügt und ein paar Chars zu String gemacht ('a', 'b', 'c' -> "abc").

    Sonderzeichen unter h20 sollten eigentlich auch keine enthalten sein.

    Gruss
    Andreas

    Bis anhin habe ich einfach Chunks vom Typ char[] getestet. das Übersetzen deren ist ja quasi automatisch.

    Wie sieht es mit dem Übersetzen bezüglich NULL terminierten Strings aus?

    Ich habe diverse Byte Arrays mit kodierten Informationen. Darin sind Strings enthalten, welche man übersetzen müsste.

    Ein Beispiel hier:

    Code
    TSPOS(8, 1),
TSD_T_TEXT, 45,
   'O', 'r', 'i', 'g', 'i', 'n', 'a', 'l', ' ', 'i', 's', ' ',
   ...

    TSPOS() setzt den Cursor, TSD_T_TEXT und 45 zeigen an, dass ein Text von 45 Zeichen länge folgt.

    Beim Überstzen müsste man nun immer einfach genau 45 Zeichen verwenden, da ResEdit meine Kodierung nicht kennt. Wenn der Text kürzer ist, dann müsste man mit Leerzeichen auffüllen, ansonoten wird sehr wahrscheinlich dahinter Müll ausgegeben... Ich könnte das aber auf NULL terminierende Strings umwandeln. Nur weiss ich nicht, ob und wie ResEdit das handhabt.

    Ich konnte geoladder kompilieren und loc -o geoladder.vm ergab bei mir keine Fehlermeldung Ich musste allerdings den Ordner zu geoladder umdenennen.

    Ich compiliere unter Windows mit FreeSdk.

    geoladder.vm zeigt bei mir richtige Resourcennamen.

    Gruss von Nico

    Ok, dann liegt es wohl bei mir an meiner Installation. Bin unter Linux / Ubuntu. Das loc Utility ist glaube ich ein Perl-Skript. Das sollte man doch debuggen können.

    Im ResEdit wurden bei meinen Versuchen ja auch die Chunk-Namen angezeigt. Einzig die Anotationen kamen nicht...

    Versuch es mal ohne {} -oder nimmt ResEdit die Chunks mit { } ? (Da hätte ich wieder was gelernt)

    Code
    @chunk char Stim1[] =  "You eat quiche!";

    Soweit ich weiß, kann ResEdit nur Chunks übersetzen. Variablen oder Texte im Code

    Code
    strcpy(v,"paul ist doof");

    gehen nicht.

    Quote from bolle732

    Ich habe diverse Byte Arrays mit kodierten Informationen. Darin sind Strings enthalten, welche man übersetzen müsste.

    Das klingt nicht gut.

    ----

    loc nimmt die rsc.rsc plus alle *.rsc die es findet.

    Die localize-Infos erscheinen hier:

    Rainer

    P.S. habe gerade ein anderes Problem, deswegen bin ich noch nicht dazu gekommen, die Programm kam zu compilieren.

    Quote from bolle732

    TSPOS() setzt den Cursor, TSD_T_TEXT und 45 zeigen an, dass ein Text von 45 Zeichen länge folgt.

    Klingt nach Fortran 8o

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

    Also, der Befehl von loc -o geoladder.vm führt zu folgendem Kommando:

    Code
    loc  `perl /home/bolle/pcgeos/Tools/scripts/perl/product_flags loc ` -o geoladder.vm `ls *.rsc `

    Das Unterkommando

    Code
    perl /home/bolle/pcgeos/Tools/scripts/perl/product_flags loc

    liefert nichts zurück.

    Das heisst, es werden keine produktspezifischen Flags gefunden / gesetzt. Dann ist es so, dass ich wohl nicht ausserhalb des "pcgeos" Ordners kompilieren kann?

    Also, das generierte Kommando ist:

    Code
    loc -o geoladder.vm appui.rsc rsc.rsc

    Wenn ich das von Hand ausführe, dann kommt auch die Fehlermeldung bezüglich keine Ressourcen-Dateien gefunden...

    Das loc ist ein Binary. Müsste mal den Quelltext anschauen, was definitiv aufwendiger ist als ein Perl-Skript X/

    Ja, den Bereich im Footer habe ich auch gemeint. Werde mal Deine Beispiele bezüglich den Anotationen ausprobieren.

    Das mit dem Byte Array hat aber schon seine Richtigkeit. Sind ja Steuerkommandos enthalten. Die mit signed zu machen wäre sehr umständlich...

    Ich könnte aber die zu übersetzenden Strings in Chunks auslagern und dann einfach einen Steuercode mit angehängtem Object Pointer definieren? Dann den optr beim decodieren referenzieren?

    Quote from bolle732

    Dann ist es so, dass ich wohl nicht ausserhalb des "pcgeos" Ordners kompilieren kann?

    Allerdings. Entweder im ROOT_DIR (dort unter pcgeos/Installed/Appl/..) oder im LOCAL_ROOT (dort unter pcgeos/Appl/..), also direkt im Code-Ordner.

    Quote from bolle732

    Ich könnte aber die zu übersetzenden Strings in Chunks auslagern und dann einfach einen Steuercode mit angehängtem Object Pointer definieren? Dann den optr beim decodieren referenzieren?

    Prinzipiell könnte das so gehen. Allerdings käme es auf einen Versuch an, ob die optr in der Tabelle akzeptiert werden und dann im Code korrekt sind. Optr enthalten das Memhandle des Blocks, das erst beim Laden des Programms bekannt ist. Deswegen müssen sie (automatisch) angepasst werden. Ich persönlich würde hinter dem steuercode einen Index in eine Tabelle setzen, die dann die optr enthält.

    Quote from bolle732

    Das loc ist ein Binary. Müsste mal den Quelltext anschauen, was definitiv aufwendiger ist als ein Perl-Skript

    Als wir die Diskussion über die "Generischen" Namen in den VM-Dateien hatten, habe ich genau das gemacht. Und dafür gesorgt, dass es so funktioniert wie es jetzt ist, insbesondere die Warnung. Wenn loc meckert gibt es einen wichtigen Grund. Soweit ich mich erinnere zählt der Code einfach mit, ob und wie viele rsc-Dateien geöffnet wurden. Wenn die Warnung allerdings kommt, obwohl die vm-Datei korrekt erzeugt wird, dann müsste man noch mal schauen. Das kann ich mir aber nicht vorstellen.

    Rainer

    P.S. Welch rsc-Dateien hast du denn, nachdem pmake full? Bist du sicher, dass vor dem pmake keine da waren? Falls doch: vorsichtshalber löschen!

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

    Hallo Andreas,

    bei mir compiliert es ohne Probleme und loc meckert auch nicht.

    auch 'pmake full' geht. Mit oder ohne NO_EC in der local.mk
    Vielleicht besprechen wir die Details per PM.

    Rainer

    P.S. einmal hatte ich auch die Warnung "nur rsc.rsc gefunden" - nach dem Löschen aller build-Artefakte (*.nc, *.ec *.obj , *.geo usw) war es aber wieder ok.

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

    Hallo Rainer

    Mein LOCAL_ROOT leigt ausserhalb vom ROOT_DIR. Ich finde das extrem wichtig, meine Sachen entsprechend trennen zu können. Das habe ich immer schon so gemacht und das Kompilieren selbst funktioniert ohne Probleme. Nur beim loc happert es gerade...

    Erstellt werden appui.rsc und rsc.rsc. Werde nochmals überprüfen, wann die genau im Prozess erstellt werden. Ich habe aber auch immer wieder ein pmake clean mit anschliessendem Löschen der generierten Dateien durchgeführt (*.nc, *.obj, *.rsc, Makefile, dependencies.mk etc.)

    Zum Weitertesten komme ich erst wieder morgen Abend. Aber ich habe nun eine menge Anhaltspunkte zum Testen.

    Andreas

    Quote from bolle732

    Mein LOCAL_ROOT leigt ausserhalb vom ROOT_DIR.

    So muss das sein. Zum löschen der Artefakte habe ich ein eigenes Script (ok, ne Batch-Datei), das clean script gibt mir immer Dinge aus, die ich nicht verstehe/nachvollziehen kann.

    Rainer

    P.S. Die .rsc sind einfache Textdateien, die kannst du dir ansehen. Da stehen die Chunknamen und Ressourcen drin.

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.