Forum64

Quoted from "TheRyk"

Tja, wie soll "er" sonst auch ohne Space wissen, ob er den Befehl POKER oder den string "POKER" vorgesetzt bekommt.
Das kann man wohl gar nicht ändern.

Strings stehen üblicherweise in Anführungszeichen?

Quoted from "Birger"

Es ist mehr das Problem, woher weiß der Syntaxhighlighter, wenn er POKER vorgesetzt bebekommt, ob dies nun eine Variable ist oder ob Befehl POKE + die Variable R gemeint ist. Wenn der Highlighter kein BASIC versteht... dann kann er es auch nicht wissen... Machbar währe das sicherlich auch irgendwie, aber mir fehlt da ein wenig die Phantasie. Die Ansätze die ich habe, würden wohl jeden Quartcore in die Knie zwingen, denn die Abfrage nach bekannten Strings erfolgt sinngemäß nach jedem Tastendruck...

Ich dachte es ginge um einen Syntaxhighlighter für C64-Basic, da ist POKER kein gültiger Variablenname weil der Tokenizer das POKE in ein Token wandelt und der Interpreter nur noch (POKE) R sieht.

Ansonsten könnte ich mir vorstellen dass das Problem mit einer sorgfältig formulierten Grammatik zumindest für manche Befehle lösbar ist und auch schnell genug abläuft um während der Eingabe durchgeführt zu werden (es muss nur die aktuelle Zeile geparst werden), allerdings wäre das ganze recht sinnfrei da es mit IIRC nur drei Ausnahmen nur Variablennamen mit mehr als zwei Zeichen betrifft und die Programme an C64 nicht bearbeitet werden dürfen.

Mir ging es zwar eigentlich wirklich nur um den Highlighter und gar nicht um Konflikte mit Strings/Schlüsselwörter. Aaber:

Quoted from "Unseen"

Quoted from "TheRyk"

Tja, wie soll "er" sonst auch ohne Space wissen, ob er den Befehl POKER oder den string "POKER" vorgesetzt bekommt.
Das kann man wohl gar nicht ändern.

Strings stehen üblicherweise in Anführungszeichen?

Jein. Was ist mit

Quoted from "Birger"

Wir und der CBM wissen ja das mit POKER nur POKE R gemeint sein kann, aber der dummer Highlighter nicht... Ich weis auch nicht ob man hier in etwas Zeit investiert, die eventuell keiner nutzen wird... außer TheRyk natürlich :-)

Ja, aber auch TheRyk hat ja schon gesagt "Klitzekleines Minus". Im Grunde genommen wird gerade jemand, der zur Minderheit der Leute gehört, die noch viel mit BASIC macht, nicht sooo zwingend auf ein vollfunktionsfähiges Highlighting angewiesen sein. Finde es auch so, wie es ist, ein tolles Tool. Nur solange Highlighting nicht 100% funktioniert, finde ich es gut, wenn man die Möglichkeit hat es abzuschalten. Denn sonst verwirrt es u.U., da man dann doch verblendet wird, wenn man die Zeilen überfliegt und eniige Schlüsselwörter mangels Highlighting nicht sieht, andere aber doch.

Quoted from "Birger"

Ups, sorry...

Da war noch was, wenn eine Datei ein Leerzeichen hatte, so gab es beim Übertragen von der Floppy zum PC eine Fehlermeldung, obwohl das PRG ordnungsgemäß kopiert wurde. das ist in der 0.3p nun auch weg...

Super! Hatte ich gar nicht gemerkt. Bin gerade in HH bei meiner Freundin. Versuche, das in Kiel mal zu saugen und zu checken.

Quoted from "TheRyk"

	Source code
1 2 3 4	Strings stehen üblicherweise in Anführungszeichen?[/quote] Jein. Was ist mit [code]DATA POKER / REM <-- geht durchaus ohne "" READ A$

Oh, stimmt - aber Ausnahmen bestätigen ja die Regel. ;-)

Ich glaube ich sollte mal selbst einen Highlighter schreiben nur um zu zeigen obs geht. ;-)

Quoted from "Birger"

@Unseen: sehr gute Idee! Ich habe jetzt schon ne ganze weile gegoogled und alles was ich finden konnte (Delphi) verfährt nach dem selben Prinzip. Also ohne ein Leerzeichen keine Erkennung der Schlüsselwörter...

Sorry, ich hatte heute meinen Tag der obskuren Programmiersprachen... ;-) Das Ding hat ein paar Bugs - Anführungszeichen werden immer paarweise in einer Zeile erwartet - und macht eigentlich kein Highlighting sondern setzt nur die gefundenen Schlüsselworte in [] damit das Win32-Binary klein genug bleibt um es anzuhängen. Ausserdem ist die gewählte Implementierung ziemlich langsam (719 Zeilen Sourcecode von Hypra-Comp werden in 2.5s bearbeitet), aber das liegt an der ineffizient konstruierten Funktion die Schlüsselworte vergleicht. Man kann das auch effizient über einen Automaten lösen, aber da hätte ich längere Zeit grübeln müssen wie man das am besten in Haskell umsetzt.

Lizenz: No rights reserved

Aufruf: "syntaxhighlighter eingabedatei ausgabedatei", wobei die Eingabedatei ein BASIC-Programm in ASCII enthalten sollte (zB die Ausgabe von petcat).

Quoted

Dieses Spalten in Worte bzw. Zeichenketten fällt bei uns schon mal flach, da in einer Kette mit unter mehrere Tokens rumsitzen können, also müssen die Ketten komplett zerlegt und durchforstet werden, was das ganze wohl träge machen wird...

Du kannst den Programmtext von vorne durchgehen und kommst mit einem endlichen Lookahead aus (alle Schlüsselworte haben endliche Länge) um festzustellen ob du gerade am Anfang eines zu highlightenden Schlüsselwortes bist oder das Zeichen ohne Highlight "ausgegeben" werden muss. Dazu noch ein paar Zustände um entscheiden zu können ob man gerade im Programmtext, in einem REM, einem String, einer DATA-Zeile oder einem String in einer DATA-Zeile ist und fertig ist der BASIC-taugliche Highlighter. Das angehängte Programm hat den "faulen" Weg gewählt und verlässt die String-bezogenen impliziten Zustände nur bei " statt auch auf Zeilenenden zu testen.

Da du dich bei BASIC auch noch darauf beschränken kannst nur die Zeile zu highlighten in der gerade editiert wird weil es keinen Einfluss auf vorhergehende oder folgende Zeilen gibt sollte der Rechenaufwand selbst bei einer ineffizienten Implementierung vernachlässigbar sein.

Quoted from "Birger"

nicht so aber in der neuen Version 0.3q

Es wird besser und besser!

Quoted from "Birger"

Hm, wenn man sich also mit so ner obskuren Programmiersprache (wie du selbst schreibst) rumschlägt, dann bekommt man das doch bestimmt auch in Baby Pascal hin oder?

Sortier Haskell nicht gleich in die selbe Schlublade wie INTERCAL, Brainfuck, Befunge usw. nur weil ich es als obskur bezeichnet habe - letztere sind eher "Spielzeugsprachen" die designt sind um möglichst umständlich programmierbar zu sein, Haskell ist dagegen genauso "ernst gemeint" wie zB C/C++, Pascal, Fortran usw.

Allerdings werde ich dir nicht den Gefallen tun das ganze in Pascal umzusetzen - ich habe zur Zeit keinen Pascal-Compiler installiert, es ist viele Jahre her das ich zuletzt was in Pascal geschrieben habe und ausserdem lernst du dann nichts. =)

Daher gibts hier jetzt Parserbau für Anfänger (Light-Version):

Wie schon geschrieben will man zum Erkennen der Schlüsselworte am besten einen Automaten konstruieren der in jedem Zustand sagt ob der bisher gelesene Teil einem Teil eines Schlüsselwortes entspricht, einem kompletten Schlüsselwort entspricht oder auf gar kein Schlüsselwort passt. So ein Automat lässt sich anschaulich als gerichteter Graph darstellen, bei dem jeder Knoten einen Zustand repräsentiert. Kanten in diesem Graphen sind Übergänge zwischen den Zuständen, die Zeichen die an die Kanten geschrieben sind geben an welcher Buchstabe den Übergang auslöst. Ich habe mal ein Beispiel für sowas nur für die Befehle "GO", "GOTO" und "GOSUB" als Grafik angehangen:


Dieser Automat fängt oben im Zustand "start" an und geht über zu Z1 wenn er als nächstes (ok, erstes) Zeichen ein "g" liest. Eigentlich müsste man noch für alle anderen Zeichen als "g" eine Kante von "start" aus hinzufügen die auf "NoMatch" zeigt, aber das wäre zu unübersichtlich geworden. Das "Part" in der zweiten Zeile im Z1-Kringel steht für "Partial match", d.h. die bisher gelesenen Zeichen sind der Anfang eines Schlüsselwortes. Auch in Z1 gilt wieder, das eigentlich noch diverse Kanten auf "NoMatch" fehlen. Wie in jedem Zustand wird der Automat nun versuchen ein weiteres Zeichen der Eingabe zu lesen, wenn es ein "o" ist geht er über in Zustand Z2. Das "Full" darin steht für "Full match", d.h. die bisher gelesenen Zeichen können ein komplettes Schlüsselwort sein (Z2 ist ein Rechteck um die Full/Part-Unterscheidung visuell deutlicher zu machen). Man könnte jetzt meinen, dass man ja an dieser Stelle aufhören könnte weil die Ausgabe "Full" lautet und somit ein komplettes Schlüsselwort erkannt wurde - aber der einzige Zustand der die Abarbeitung des Automaten wirklich beendet ist "NoMatch". Daher würde der Automat nun ein weiteres Zeichen lesen und bei einem "t" in Z3 oder bei einem "s" in Z5 übergehen usw. bis irgendwann "NoMatch" erreicht wird.

Nehmen wir nun einmal an, dass du schon so einen Automatengraphen für alle Schlüsselworte des C64-BASICs hättest und damit ein Syntaxhighlighting machen willst. Dann müsstest du die aktuelle Zeile zeichenweise an den Automaten verfüttern bis die Ausgabe irgendwann "NoMatch" lautet. Das kann natürlich schon beim ersten Zeichen passieren, dann muss das Zeichen nicht gehighlightet werden und der Automat kann mit dem nächsten Zeichen der Zeile neu gestartet werden.

Möglicherweise kommen auch erst einige "Part"-Ausgaben vor dem "NoMatch" - dann gibst du genau das erste Zeichen das du dem Automaten gegeben hast ohne Highlighting aus und startest ihn im Startzustand mit dem Zeichen danach wieder neu. Das geht im Prinzip auch effizienter, macht aber die Konstruktion des Automaten deutlich schwieriger und da die längsten Schlüsselworte im C64-BASIC gerade mal 7 Zeichen lang sind kostet das ganze nicht übermäßig viel Rechenzeit.

Interessant wird es wenn in der Ausgabe des Automaten irgendwo "Full" vorgekommen ist, dann wurde ein Schlüsselwort komplett erkannt. Da einige Schlüsselworte Prefixe von anderen sind ist an dieser Stelle nur die längste Eingabe interessant die als "Full" erkannt wurde (beim Aufruf des Automaten einfach bei jedem "Full" eine Variable auf die Anzahl der bisher reingesteckten Zeichen setzen, ihr Endwert ist die Länge des längsten gefundenen Schlüsselwortes). Genau so viele Zeichen sind gehighlighted auszugeben, der Automat wird dann mit dem Zeichen danach neu gestartet. Das ist die einzige Situation in der du mehr als ein Zeichen der zu highlightenden Eingabe fertig bearbeitet ausgibst.

Zusätzlich gibts noch ein paar "kleinere" Komplikationen: Wenn du ein Anführungszeichen in deiner Eingabe siehst muss in den Stringmodus umgeschaltet werden bis wieder ein Anführungszeichen kommt oder die Zeile zu Ende ist - idealerweise prüft man das an einem Punkt an dem der Automat in den Startzustand versetzt wurde und mit einem neuen Zeichen gefüttert werden soll da sonst einige Sonderbehandlungen anfallen damit Schlüsselworte vor dem Anführungszeichen korrekt behandelt werden.

Für DATA und REM gilt ähnliches, am bequemsten sind die zu finden indem man schaut was gerade als zu highlightender Text gefunden wurde. Bei DATA sollte man beachten, dass der "Data-Modus" zwar durch einen Doppelpunkt verlassen werden kann, aber nur wenn der Doppelpunkt nicht in Anführungszeichen steht (-> Data-Modus und String-in-Data-Modus).

Das einzige was noch fehlt ist eine Umsetzung des Automatengraphen in irgendwas das man vernünftig im Programm benutzen kann und eine Methode um den Graphen möglichst automatisch zu konstruieren.

Ersteres geht beispeilsweise indem man alle Knoten des Graphen beliebig nummeriert (zB 1 für den Startzustand, 2 für Z1 usw.) und ein 2D-Array anlegt in dem jede Zeile für einen Zustand steht. Die Zeile verwendet die Zeichen an den ausgehenden Kanten als Arrayindex (ineffizient: 256 für ASCII, besser: 26 Buchstaben plus ein paar Sonderzeichen, extra sparsam: Verkette Liste der nicht auf NoMatch führenden Einträge), der Inhalt der Arrayposition ist die Nummer des neuen Zustands in den übergegangen wird wenn das zugehörige Zeichen gelesen wurde. Ausserdem muss man noch speichern welche Ausgabe die Knoten geben sollen wenn sie erreicht werden, zB in einem zweiten Array oder mit einem ARRAY OF RECORD statt eines 2D-Arrays.

Im Pseudocode könnte ein Automatendurchlauf dann ungefähr so aussehen:

Im Prinzip reicht das alles schon aus um einen Syntaxhighlighter nach Wunsch zu konstruieren der sich nicht auf so lästige Kleinigkeiten wie zB Leerzeichen zwischen den Schlüsselworten verlassen muss, aber den Automaten von Hand aufstellen ist schon für das kleine GO/GOTO/GOSUB-Beispiel lästig und fehleranfällig. Im Prinzip reicht es aber wenn man ein Programm bastelt welches eine Liste von Schlüsselworten einliest und die Automaten-Matrix in Form eines Quellcode-Schnippsels ausgibt, das man dann in den fertigen Syntaxhighlighter einbindet.

Zur Konstruktion der Tabelle fängt man mit einem hinreichend grossen Array (oder einem das man dynamisch in der Grösse ändern kann) an, bei dem alle Zeichen in allen Zustanden in den Zustand NoMatch führen (es würde sich jetzt irgendwie anbieten den als Zustand 0 zu verwenden und das Array mit Index 1 anzufangen...). Für jedes Schlüsselwort in der Liste hangelt sich das Programm dann so lange zeichenweise durch die Tabelle bis entweder das Ende des Schlüsselwortes erreicht wurde oder das erste Zeichen erreicht wurde das in den Zustand "NoMatch" führt. In erstem Fall markiert man einfach den letzten gefundenen Zustand als "Full", in letzterem Fall erzeugt man einen neuen Zustand der entweder als "Part" oder "Full" markiert wird (je nach dem ob es das letzte Zeichen des Schlüsselwortes war oder nicht) und lässt das bisher auf NoMatch zeigende Zeichen auf den neuen Zustand zeigen. Wenn alle Schlüsselworte abgearbeitet sind wird die konstruierte Tabelle in irgendeiner nützlichen Form ausgegeben.

Diese Art die Tabelle aufzubauen erzeugt keine minimale Tabelle, zB kann man einen Zustand einsparen indem für das P in STEP und STOP der gleiche Zustand verwendet wird. Es gibt auf jeden Fall eine ineffiziente Möglichkeit die Zustandsanzahl zu minimieren (so lange Zustände zusammenfassen bis keine zusammenfassbaren mehr gefunden werden; Zustände sind zusammenfassbar wenn sie das gleiche Ergebis ausgeben und für alle Zeichen in die gleichen Zustände übergehen), wie sowas effizient minimierbar ist müsste ich erstmal nachschlagen.

Ach ja: Die beschriebene Konstruktion eines Syntaxhighlighters ist nicht zu empfehlen wenn die zu erkennenden Schlüsselworte unbeschränkte Länge haben können (zB um Rechenausdrücke einzufärben), dann kann man Eingaben konstruieren bei denen für jedes ausgegebene Zeichen der Automat einen grossen Teil der Resteingabe einliest ohne einen Full-Match zu finden -> quadratische Laufzeit in der Eingabelänge.

Ach ja 2: Das ganze ist der erste Schritt auf dem Weg zu einem Compiler oder Interpreter.

so hab auch mal getestet

hab mit dir master ein d81 erstellt (ne demo eingefügt)

das d81 dann mittels prg-mover auf ne 3.5er disk geschrieben und nun rennt grade die demo aufm cevi...

DANKE

hatte vorher 1581copy versucht aber das geht ja unter xp wohl nit wirklich!

also d81 support unter xp scheint zu klappen.

Super ! Danke !

hallo, hab kurz eine frage wegen der nibtools bzw nibread.
ich höre immer das sich da eine diskseite in 8-10 sec auf den pc kopieren lässt.
ich hab jetzt ein xap kabel... aber ich komm immer auf 24sec.

angeschlossen sollte ja alles richtig sein, sonst würde ja nibread meckern oder? hat jemand noch einen tip dazu?

danke

swasti

danke. -i wird aber bereits verwendet.
wenn ich diverse andere schalter verwende (zb nibread -i -m -k -d testx.nib) komm ich auf ca 17sec.
also irgendwo ist da was faul.

nachdem es auf 2 pcs so ist - vermute ich entweder ein problem in der floppy (6522 defekt??) oder am aufbau des kabels. was ich aber nicht ganz glaube. wenn ich es ohne paralell kabel betreibe gehts ja garnicht...

strange.
noch wer einen tip? hab mich gestern gleich über ne neue 100er box hergemacht um die zu transferieren damit dieser diskhaufen todo endlich kleiner wird.

swasti