Hallo Besucher, der Thread wurde 2,7k mal aufgerufen und enthält 6 Antworten

letzter Beitrag von skoe am

Patch für Vice-Monitor

    Hier sind ein paar Änderungen für den Vice-Monitor, sie wurden z.T. hier im Forum vorgeschlagen (ernörgelt?).


    Es gibt eine patch-Datei über alle betroffenen Dateien (inkl. generierter .c- und .h-Dateien)


    Alternativ kann man die monitor.tar.bz2 entpacken und damit das Originalverzeichnis "src/monitor" ersetzen.


    Bei beiden Dateien muss man die Endung ".prg" entfernen. Die Änderungen passen zu 1.22. Bitte testet sie doch mal, auch unter anderen Umgebungen. Ich habe sie nur unter Linux angetestet.


    Und das sind die Änderungen:

    Mhhh, dass die generierte Datei solch böse Fallen hat, habe ich nicht erwartet... Muss mir wohl doch mal eine Compiler-Umgebung für die verschiedenen Systeme zum Testen zurechtbasteln. Auf Windows fehlt mir noch das DirectX-SDK, muss ich mir mal ziehen.


    Nach Code lesen würde ich vermuten, dass in mon_lex.l und mon_lex.c hinter
    #define YY_ALWAYS_INTERACTIVE 1
    folgende Zeile helfen sollte:
    #define YY_NO_UNISTD_H


    Warum ziehen die sich die Datei rein, wenn's auch ohne geht (auch unter Linux)?


    Mal sehen, ob sonst noch was fehlt.


    Kann jemand was zu BeOS, RiscOS, OS/2 etc. sagen?

    Hallo,


    jetzt kompiliert es.


    Zitat

    Original von skoe
    Warum ziehen die sich die Datei rein, wenn's auch ohne geht (auch unter Linux)?


    Tja... Das ist halt der GNU way... :(


    Zitat


    Kann jemand was zu BeOS, RiscOS, OS/2 etc. sagen?


    Ich denke, wenn wir die Bugs entfernt haben werden wir es bei VICE reinreichen - da wird es dann automatisch getestet. ;)


    Also, was mir aufgefallen ist:

    Code
    1. (C:$0410) m 8:0050 0070
    2. >8:0050 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 04 04 00 00 05 fa c8 22 eb 00 00 0a 05 ea ff 00 00 00 ....................."..........
    3. >8:0070 00 .
    4. (C:$0410)


    Geht also, wie vorher auch


    Nun die Kurzform:

    Code
    1. (C:$0410) m8:00500070
    2. ERROR -- Unexpected token:
    3. m8:00500070
    4. ^
    5. (C:$0410)


    Komischerweise kommt das nur, wenn ich das Prefix "8:" da stehen habe:

    Code
    1. (C:$0410) m00500070
    2. >C:0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
    3. >C:0070 00 .
    4. (C:$0071)


    Auch ein "dev 8:" vorher geht, um es von der Floppy anzuzeigen.


    Aus irgendeinem Grunde ist jetzt aber der HELP-Befehl *extrem* langsam. Benötigt hier über 15 Sekunden. Ich bin aber noch nicht ganz dahinter, ob es an deinem Patch liegt oder an dem, was vorher schon da war. (Ich habe deinen Patch auf 1.22.5 angewendet)



    Dann:

    Code
    1. (8:$ebff) m,0050,0070
    2. ERROR -- Unexpected token:
    3. m,0050,0070
    4. ^
    5. (8:$ebff)


    Aha, da darf also kein Komma stehen. Wieso eigentlich nicht?


    Über solche Mißdeutigkeiten wir "m0123" will ich mich jetzt nicht auslassen (GPZ: Ist das nun "m 0123", "m 0 123", "m 01 23", oder "m 012 3"? Gerade die letztere Interpetation hat einen "schönen" Effekt).


    Was sagen denn diejenigen dazu, die das unbedingt so haben wollten? Im großen und ganzen gefällt mir das, auch wenn ich darin immer noch keinen Nutzen sehe. ;)


    Gruß,
    Spiro

    Hallo,


    anbei eine neue Version, die das unistd- und das 8:-Problem löst.


    Zitat


    Komischerweise kommt das nur, wenn ich das Prefix "8:" da stehen habe:


    Habe nur vergessen, dass so ein Range auch ein memspace haben kann. Der Monitor ist mir nicht so gut vertraut, deshalb ist es auch wichtig, das andere ihn auch testen.


    Zitat


    Aus irgendeinem Grunde ist jetzt aber der HELP-Befehl *extrem* langsam. Benötigt hier über 15 Sekunden.


    :nixwiss: komisch. Kann ich hier nicht nachvollziehen (Linux). Kann ich mir auch nicht erklären, hab kaum was dran geändert. Verstreicht die Zeit, bis mon_command_print_help (aus mon_command.c) aufgerufen wird, oder dauert der Durchlauf der Schleife dort so lange? Kannst Du das mal mit dem Debugger prüfen?


    Zitat


    (Ich habe deinen Patch auf 1.22.5 angewendet)


    Wo gibt's denn die Version?


    Zitat


    Aha, da darf also kein Komma stehen. Wieso eigentlich nicht?


    Ich dachte mir, das innere Verlangen, zwischen den Parametern Kommas zu machen, kommt vielleicht von Befehlen wie "poke 53280,2" oder "memcpy(a, b, c)". Kaum jemand würde auf die Idee kommen, "poke,53280,2" oder "memcpy(,a,b,c)" zu schreiben. Deshalb habe ich weder Kosten noch Mühe gescheut, das Komma gerade an dieser Stelle *nicht* zuzulassen.


    Irgendwo habe ich auch mal gesehen (RiscOS Basic???), das ein zusätzliches Komma zum expliziten auslassen von Parametern benutzt wurde: "bla ,,c" hieß dort, dass a und b nicht angegeben werden. Diesen Mechanismus gibt es zwar im Vice-Monitor nicht, aber das war halt ein weiterer Grund, es nicht zu erlauben. Zwischen zwei Parametern darf deshalb bei mir auch nur EIN Komma, aber beliebig viele Spaces stehen.


    Ein bisschen Geschmacksfrage ist das aber auch zweifellos. Wie die Kommafrage überhaupt.


    Zitat


    Über solche Mißdeutigkeiten wir "m0123" will ich mich jetzt nicht auslassen (GPZ: Ist das nun "m 0123", "m 0 123", "m 01 23", oder "m 012 3"? Gerade die letztere Interpetation hat einen "schönen" Effekt).


    Eigentlich ist das recht eindeutig: Zahlen werden nie zerpflückt, außer bei einer Ausnahme: Bei Befehlen, die einen Adressbereich erwarten, wird eine Eingabe mit GENAU 8 Ziffern (wenn Hex Modus aktiv) zu zwei 16-Bit Adressen getrennt. Da 0123 nicht 8 Ziffern hat, wird es also immer als "m 0123" interpretiert. Z.B. 0123456 würde übrigens eine Fehlermeldung verursachen.


    Aber ich verstehe Deine Zweifel, ich wäre auch nicht auf diese Idee gekommen. Das mit dem Komma finde ich schon nachvollziehbar.


    Zitat


    Was sagen denn diejenigen dazu, die das unbedingt so haben wollten? Im großen und ganzen gefällt mir das, auch wenn ich darin immer noch keinen Nutzen sehe. ;)


    Der Kunde ist König :-) Wenn Du mit dem Ergebnis unter Windows zufrieden bist, könnten wir ja auch mal ein Binary zum Beta-Testen veröffentlichen, mich würde nämlich auch etwas Feedback interessieren. (Hab immer noch kein MSVC+DXSDK installiert)


    Gruß,
    Thomas

    Hallo,

    Zitat

    Original von skoe
    anbei eine neue Version, die das unistd- und das 8:-Problem löst.


    Ja, sieht schon besser aus.


    Zitat


    :nixwiss: komisch. Kann ich hier nicht nachvollziehen (Linux).


    Ich habe noch einmal gegengetestet, das Problem war auch schon vor deinem Patch da. Da muss ich wohl mal suchen, was da schief läuft. :(


    Zitat


    Wo gibt's denn die Version?


    Offiziell nur für Entwickler des VICE-Teams, man kann sie aber auch mal so zwischendurch erhalten, wenn es dafür Gründe gibt.


    Übrigens hat sich zwischen der offiziellen 1.22 und der 1.22.5 im Monitor noch gar nichts geändert.


    Zitat


    Irgendwo habe ich auch mal gesehen (RiscOS Basic???), das ein zusätzliches Komma zum expliziten auslassen von Parametern benutzt wurde: "bla ,,c" hieß dort, dass a und b nicht angegeben werden.


    Richtig, so kenne ich das auch, aus verschiedenen Kontexten.


    Zitat

    Eigentlich ist das recht eindeutig: Zahlen werden nie zerpflückt, außer bei einer Ausnahme: Bei Befehlen, die einen Adressbereich erwarten, wird eine Eingabe mit GENAU 8 Ziffern (wenn Hex Modus aktiv) zu zwei 16-Bit Adressen getrennt. Da 0123 nicht 8 Ziffern hat, wird es also immer als "m 0123" interpretiert. Z.B. 0123456 würde übrigens eine Fehlermeldung verursachen.


    Ich weiß, so ist das bei dir geregelt. IMHO ist das aber damit wieder so ein komischer "Sonderfall" mit genau 8 Zeichen; gefallen tut mir das nicht.


    Zitat

    Der Kunde ist König :-) Wenn Du mit dem Ergebnis unter Windows zufrieden bist, könnten wir ja auch mal ein Binary zum Beta-Testen veröffentlichen, mich würde nämlich auch etwas Feedback interessieren. (Hab immer noch kein MSVC+DXSDK installiert)


    Leider hat sich hier bislang noch keiner gemeldet... Vielleicht müssen wir nochmal den alten Thread suchen und die Leute auf diesen hier hinweisen?


    Wenn du mir deine Mail-Adresse sendest (für den ChangeLog) würde ich deinen jetzigen Patch (nach noch ein paar Tests) für die Aufnahme in die nächste VICE-Version einreichen. Es sei denn, das willst du selbst tun. ;)


    Aber ich würde ja gerne auf eine Stellungnahme von den "Wünschern" hoffen...


    Gruß,
    Spiro

    Zitat


    IMHO ist das aber damit wieder so ein komischer "Sonderfall" mit genau 8 Zeichen; gefallen tut mir das nicht.



    Ich hätte auch überhaupt kein Problem damit, diesen Spezialfall wieder rauszunehmen.


    Zitat


    Was sagen denn diejenigen dazu, die das unbedingt so haben wollten?


    Die sagen nichts.


    Zitat


    Wenn du mir deine Mail-Adresse sendest (für den ChangeLog) würde ich deinen jetzigen Patch (nach noch ein paar Tests) für die Aufnahme in die nächste VICE-Version einreichen. Es sei denn, das willst du selbst tun. ;)


    Die steht im Patch, ich habe mir mal die Frechheit rausgenommen, mich als Author der lex/yacc-Datei dazuzuschreiben :-) Schick den Patch doch ruhig weiter und schick mir eine Kopie der Mail.


    Gruß,


    Thomas