Hallo Besucher, der Thread wurde 6,8k mal aufgerufen und enthält 41 Antworten

letzter Beitrag von marco64 am

Syntaxchecker für Basic V2

    Nach langer Zeit des experimentieren's und schlafloser Nächte habe ich endlich eine stabile lauffähige Version meines Basic Syntaxcheckers Syntax64 . :roll2: Momentan wird nur das c64 original Basic unterstützt. Wer mit petcat oder Tok64 arbeitet, ich würde mich über Feedback freuen.


    Unter WinXP das Programm unter der Konsole mit "syntax64.exe basicprg.txt" starten, die gefundenen Fehler werden dann ausgegeben. Syntax64 ist in Python geschrieben. Der Soucecode liegt bei und sollte auch unter Linux laufen. Dann muss aber auch Python installiert sein, wenn's nicht schon dabei ist.


    Es ist jeder zum testen herzlich eingeladen. Fehler bitte posten. :)
    marco

    Zitat

    Klingt gut, ist da noch mehr geplant? (z.B. integration in 'nen edititor )


    Ich dachte erst mal in der freien Wildbahn auf Praxistauglichkeit testen, und später dann vielleicht Simon Support. Falls du mit integration so was wie ein Plug in für Eclipse meinst, sorry davon habe ich keine Ahnung.

    Ich habe jetzt eine Homepage für Syntax64 eingerichtet. Neben einer neuen Version (einen INPUT Bug und ein paar Kleinigkeiten gefixed) gibt es auch ein neues Pc-Tool. Mit Label64 können Basicprogramme auch ohne Zeilennummern geschrieben werden. Es Konvertiert die Label in normalen BasicV2 Text, der dann von Syntax64, petcat und Tok64 verarbeitet werden kann. Ein Beispiel liegt bei.


    Link: http://freenet-homepage.de/syntax64/index.html


    PS: Falls der Link nicht funktioniert, dann noch mal versuchen. Irgendwas muss bei Freenet schief laufen. Ein paar mal wurde angezeigt das die Seite nicht existiert und 2x bin ich schon auf einer komplett anderen gelandet :grr:

    Wollte heute Abend eine neue Version(0.1.2) ins netz stellen, nur freenet will mal wieder nicht. :encolere20: mal sehen vielleicht klappt's morgen


    Zitat

    Klingt gut, ist da noch mehr geplant? (z.B. integration in 'nen edititor )


    Neue Option( -e ) die die Fehlerausgabe für den ConTEXT editor lesbar macht ... soll bedeuten ein Doppelklick auf den SyntaxError und schon bist du in der passenden Zeile. Dazu gibt's dann noch einen Syntax Highlighter.


    Kennt jemand einen Webhoster mit dem er bessere Erfahrungen gemacht hat? (möglichst kostenlos, Filesize mind. 3MB)

    Wenn es dir nichts ausmacht als Untermieter zu fungieren kann ich dir auf nachtkatzen.de oder wahlweise stehrshardwarebude.de (schauen lohnt noch nicht, noch nicht wirklich was da ;) ) was geben.

    Die neue Version(v0.1.2) ist jetzt online und kann über die Homepage abgerufen werden. Syntax64 ist wie schon beschrieben an den ConText Editor angepasst worden.



    Zitat

    Wenn es dir nichts ausmacht als Untermieter zu fungieren ...


    BastetFurry:
    Danke für das Angebot, aber ich habe kurzfristig eine andere Lösung gefunden. :)



    marco
    http://www.freenet-homepage.de/syntax64/index.html

    Nachdem ich mit Label64 etwas gearbeitet habe, hatte ich die Idee lokale Label zu benutzen. Wenn man 10 unterschiedliche loop namen hat ist das besch***. Bevor ich an's realisieren gehe wollte ich eure Meinung, vielleicht kann man die Idee ja noch verbessern. :gruebel


    Ein Beispiel könnte so aussehen:

    Zumindest für Loops würd ich das so machen.

    Code
    1. DO
    2. GET A$
    3. IF A$ <> "" THEN EXIT DO
    4. LOOP


    wird zu:

    Code
    1. 10 GET A$
    2. 20 IF A$ <> "" THEN GOTO 40
    3. 30 GOTO 10

    Stimmt, für loops ist DO ... LOOP besser. Dann könnte ich ausser dem EXIT DO auch ein CONTINUE realisieren. Der Schritt in Richtung WHILE...DO...LOOP oder DO...LOOP WHILE wäre dann auch nicht mehr weit. Es läuft also alles auf strukturierte Programmierung hinaus.


    Dumme Frage, werden durch die ganzen GOTOs die Programme dann spürbar langsamer? Soweit ich mich erinnern kann fängt GOTO jedes mal von vorn an um eine bestimmte Zeile zu suchen. Kann man das mit irgendwelchen tricks umgehen? Weis jemand ob Petspeed oder der Austro-Speed-Compiler das Problem durch direkte Sprünge umgeht ohne erst suchen zu müssen?

    Ein GOTO ist nicht so tragisch wie ein IF.
    Ein IF braucht immer Ewigkeiten weil der Interpreter erstmal beide Teile des Vergleichs in Fließkomma umrechnen muss und dann noch in die FACCs schieben muss.
    Kannst ja selber durchtesten.

    Code
    1. 1 t=ti
    2. 2 fora=0to500
    3. 3 if1=2thenremnix
    4. 4 nexta
    5. 5 printti-t


    1=2 <- 140 ms
    1=a <- 129 ms
    a=2 <- 128 ms
    a=b <- 118 ms
    In allen varianten wird das IF einmal ausgeführt und tut nichts.
    Was auch interessant sein könnte für kleinere Reichweiten von SELECT CASE:

    Code
    1. select case a
    2. case 1
    3. rem ....
    4. case 2
    5. rem ....
    6. case 4
    7. rem ....
    8. case else
    9. rem ....
    10. end select


    wird zu:

    Code
    1. 10 on a goto 30,40,20,50 rem <-- Der Dritte Wert wird durch ELSE mit abgedeckt
    2. 20 print "else":goto 60
    3. 30 print "1":goto 60
    4. 40 print "2":goto 60
    5. 50 print "4"
    6. 60 rem end select


    ON GOTO ist definitiv schneller wie ein IF THEN Wald.


    Und um das ganze nachher schneller zu machen, einfach durch den BasicBoss nudeln :)

    Zitat

    Dumme Frage, werden durch die ganzen GOTOs die Programme dann spürbar langsamer? Soweit ich mich erinnern kann fängt GOTO jedes mal von vorn an um eine bestimmte Zeile zu suchen.


    stimmt


    Zitat

    Kann man das mit irgendwelchen tricks umgehen?


    ja kann man, in dem du an der stelle an die du springen willst eine FOR schleife beginnst deren abbruchbedingung niemals erreicht wird. hinspringen kannst du dann mit einem passenden NEXT. (das ist schneller weil in dem fall die rücksprungadresse auf einem stack gespeichert wird und nicht das ganze program von vorne durchsucht wird)


    mit strukturierter oder gar schöner programmierung hat das natürlich nichts mehr zu tun :=)