Beiträge von Schlowski

    Neue Version 1.38 hochgeladen:

    Code
    - Basic Erweiterungen für den Label-Mode im Projekt

    Eine meiner langjährigen Ideen für BasEdit war die Möglichkeit, Basic-Erweiterungen einzubauen, die es trotzdem erlauben, das fertige programm auf einem Standard-Rechner laufen zu lassen.

    Als ersten Schritt in diese Richtung hab ich mal das folgende Feature implementiert:
    In einem Projekt-File kann man jetzt die Option "enable keyword extensions" anhaken. Diese Erweiterungen funktionieren ausschließlich im Label-Mode und nur, wenn man als Tokenfile Basic V2 geladen hat - ich möchte nicht mit anderen Basic-Erweiterungen wie ExBasic oder Basic V10 etc. kollidieren...

    Die neuen Keywords sind diese hier:

    Beispiele:

    Diese zeilen werden dann in Standard Basic V2 übersetzt beim Übergang vom Label zum LineBitte melde dich an, um diesen Link zu sehen.:

    Ok, ist nicht optimal, aber macht, was es soll :)
    Die Negation einiger Ausdrücke sieht etwas gewöhnungsbedürftig aus und ist etwas langsamer als eine "von Hand optimierte Negation".
    NOT(A=500) ist etwa 18,5% langsamer als das logisch äquivalente A<>500 oder, in diesem fall noch bessere, A<500.
    Aber wenn es auf geschwindigkeit ankommt sollte man für diese Art von Zählschleifen eh eine FOR-NEXT Schleife nehmen, die ist um den Faktor 10 schneller!
    Die zweite Unschönheit ist die zeile 90 REM, die wird als Sprungziel für das EXIT aus dem DO-LOOP benötigt. Würden noch Befehle nach dem LOOP kommen, würde BasEdit diese zeile natürlich nicht generieren.
    Und last but not least könnte ich die Zeile 70 noch optimieren, indem das überflüssige GOTO nach dem THEN eingespart wird. Das taucht momentan deswegen noch auf, weil EXIT ja auch einzeln stehen könnte, dann benötigt es natürlich ein GOTO.

    Das Ergebnis der Konvertierung des mehrzeiligen IF-THEN-ELSE-ENDIF sieht noch wursteliger aus... Da bekommt der Begriff Spaghetti-Code wieder eine ganz neue Bedeutung ;)

    Naja, zumindest ein bisschen Info gibbet mit F1, da steht auch F2 für's Character Window drin :smile:
    Ansonsten ist ReadMe eher Fehlanzeige, noch so eine Baustelle *seufz*

    Control ersetzt die Commodore-Taste, das Keyboard-Layout hält sich dann relativ eng an das Vice-Layout.

    Sollte ich mal zumindest in das F1-Fenster mit einbauen, damit das wenigstens irgendwo steht...

    Mmh, ich wollte eigentlich mal meinen ersten Post editieren, aber da gibt es keinen Edit-Button!? Genaugenommen finde ich gerade überhaupt keinen Edit-Button, um eine ältere Post von mir zu überarbeiten, komisch. Ich weiß aber, dass ich das schonmal gemacht habe...

    Egal, ich dachte mir, nach so vielen Änderungen an BasEdit könnte ich mal einen aktuellen Screenshot und eine FeatureListe hinterlegen, damit Neuankömmlinge wissen, was sie erwartet :smile:

    Könnte vielleicht ein Admin diese Post nach vorne setzen oder so?

    Bitte melde dich an, um dieses Bild zu sehen.

    Und hier die Features:

    Neue Version 1.36 hochgeladen:

    Code
    - Pfadbehandlung beim Laden/Speichern überarbeitet

    Die Dateien für Chargen, TokenFile und PetCat aus der BasEdit.Ini werden jetzt immer in fest definierten Unterverzeichnissen zum BasEdit-Verzeichnis (AppDir) gesucht:

    Code
    ' base dir for pathes is application directory!
    ' relativ pathes no longer supported!
    ' 
    ' Character ROM files will be searched in AppDir\Fonts\
    ' Basic Token Files will be searched in AppDir\Basic-Tokens\
    ' ASCII tokenizer files will be searched in AppDir\ASCII-Tokenizer\
    ' BasEdit.Ini will be searched in AppDir\

    Bitte passt Eure BasEdit.Ini's entsprechend an und enfernt aus den Einträgen für Chargen, TokenFile und PetCat alle relativen oder absoluten Pfadangaben. Nur die reinen dateinamen dürfen da noch stehen!

    Für Lade-/Speichervorgänge für PRG/PETSCII/ASCII-Dateien sowie DiskImages und Projekt-Dateien wird ein WorkingDir mitgeführt, das jeweils auf das zuletzt benutzte Verzeichnis verweist und für die Öffnen/Speichern-Dialoge als StartDirectory gilt. Nach Programmstart ist das gleich dem AppDir, es sei denn, man hat per Drag and Drop eine Datei übergeben, dann ist das Verzeichnis dieser Datei das aktuelle WorkingDir.

    Projekte erwarten jetzt immer ihre PRG und TXT-Dateien im gleichen Verzeichnis wie die Projektdatei, außerdem dürfen die Basic-Token- und ASCII-Tokenizer-Dateien nur entweder im Projektverzeichnis oder in ihren jeweiligen Unterverzeichnissen relativ zum AppDir liegen (in dieser Reihenfolge werden sie auch beim Laden gesucht). Damit kann man Projekte schön in Unterverzeichnissen anlegen und ohne Pfadprobleme zwischen verschiedenen Rechnern austauschen.

    Mal schauen, wo's jetzt noch hakt, ich hab bestimmt wieder irgendwas vergessen...

    Neue Version 1.35 hochgeladen

    Code
    - Der mittige waagerechte Strich wird jetzt korekterweise als CHR(96) und nicht mehr als CHR(192) eingefügt über das F2 Character Fenster
    - Zahlen in wissenschaftlicher Notation werden jetzt erkannt (1E+09)
    - Erweiterungen an der Erkennung von logischen Ausdrücken in Zusammenhang mit Zuweisungen an numerische Variablen

    Damit funktionieren jetzt auch Zuweisungen wie

    Code
    10 A=-(LEFT$(A$,1)="N")

    Vorher wurden nur numerische Vergleiche akzeptiert...

    Das erste was ich mache ist im Vice die Häkchen für P00 Dateien wegnehmen - dann speichert er die Dateien 1:1 ab, ohne Header usw. Dann sollte das bei Dir auch gehen - ich konnte so einwandfrei Charset-Dateien binär speichern und laden.

    D64 und Truedrive braucht man meiner Erfahrung nach nur, wenn man mit Fastloadern und/oder JiffyDOS etc. arbeitet. Die normalen Kernal-Routinen kommen wunderbar mit Verzeichnissen auf der Host-Platte klar. Und man hat den Vorteil ungebremster Datei-Transfer-Geschwindigkeit, kann die Dateien einfach kopieren oder auch mal mit einem Hex-Viewer reinschauen...

    Hehe, dazu müsste ich erstmal W(rite)TFM :rolleyes:
    Und meine kleine Webseite zu BasEdit, die noch nie schön war, ist jetzt auch noch völlig überaltert, da stimmt ja kaum noch was, noch so eine Neben-Baustelle...

    Egal, wer braucht schon Doku, wenn man ihn mit unbekannten Features erschlagen kann :)

    Zitat

    Das Projekt-Öffnen geht bei mir immer schief, wenn das Projekt nicht im gleichen Ordner wie BasEdit liegt.


    Ja, das ist mir gestern auch schon aufgefallen, da muss ich nochmal konzeptionell ran mit meinen Verzeichnissen...

    Zitat

    Wäre eigentlich denkbar, eine Art Zeilennummerstart für die generierten Zeilen einzusetzen?


    Gibt es schon, den ' Kommentar mit einem #<Start>,<Schrittweite>:

    Code
    '#100,10
    (irgendwelche Codezeilen)
    '#1000,5
    (irgendeine Unterroutine)
    '#2000,5
    (noch eine Unterroutine)

    Das war eine meiner ersten Erweiterungen zum Label -> Line# Umwandeln, weil ich es gerne ordentlich habe :)

    Neue Version 1.34 hochgeladen

    Code
    - ' als Kommentar im Label-Modus wird nicht in den Zeilennummern-Modus übernommen
    - neuer Switch in Tokenfiles: HasSimpleRem=0/1
    - Syntax Highlighting bleibt jetzt auch korrekt erhalten, wenn man nach rechts scrollt
    - Projektfile um neue Option erweitert: shorten variables

    Im Projektmodus kann der einfache ' als Kommentar im Label-Modus sozusagen als unsichtbarer Kommentar für das PRG-file benutzt werden. Bei der Umwandlung von Labels in Zeilennummern wird alles nach einem ' einfach ignoriert.
    Also auch sowas wie

    Code
    A=5  ' IRGENDEIN KOMMENTAR


    obwohl das syntaktisch fehlerhaft wäre.
    Ausnahme: Wenn der aktuell gewählte Basic-Befehlssatz ein ' als REM-Ersatz erlaubt, wie z.B. ExBasic Level II. Dafür kann man jetzt im Tokenfile das Setting HasSimpleRem einstellen.

    Auf vielfachen Wunsch Einzelner hab ich mich mal an die Umsetzung der automatischen Variablenkürzung gewagt.
    Da dieser Vorgang den Quelltext nicht unerheblich verändert hab ich das nur im Projekt-Modus erlaubt, außerdem wird das nur bei der Labelmode in Zeilennummern-Umwandlung durchgeführt.

    Gedacht ist es für folgendes Vorgehen:
    1. Neues Projekt anlegen und in den Label-Modus wechseln bzw. bestehendes Projekt öffnen
    2. Nach Herzenslaune Quelltext einhacken, dabei ohne mit der Wimper zu zucken lange Variablennamen benutzen
    3. Irgendwann mal ausprobieren, ob das eigentlich läuft, was man da so zusammenbraut -> F5 und im Emulator testen
    4. Wieder zurück im Editor
    4.a Fehler bereinigen oder Source erweitern - zurück zu 2
    4.b oder alles abspeichern und fertig

    Beim Schritt 3 wird der Quelltext automatisch im Hintergrund wieder in ein Programm mit Zeilennummern übersetzt und dabei werden dann auch die langen Variablennamen auf 2-buchstabige zurückgekürzt.
    Das Vorgehen beim Kürzen ist folgendes:
    1. Variablenliste erstellen (Crossreference ohne Dialog am Ende)
    2. Die Variablenliste alphabetisch absteigend abarbeiten
    3. Falls Variablename länger als 2 Buchstaben bzw. Buchstabe+Ziffer wird gekürzt (z.B. ABER)
    3.a Es wird nacheinander geprüft, ob der Erste + x.Buchstabe des Variablennamens schon als Variable vergeben ist (AB, AE, AR)
    3.b falls so kein geeigneter Variablenname gefunden wird, A0 -ZZ durchtesten
    3.c falls wir immer noch keinen gefunden haben ->PANIK,ERROR (dann sind aber auch schon alle 936 möglichen Variablennamen vergeben...)
    4. Langen Variablennamen im gesamten Quelltext gegen kurzen Variablennamen austauschen
    5. Kurzen Variablennamen in die Liste vergebener Namen aufnehmen
    6. zurück zu 2. bis die Liste abgearbeitet ist

    Meine Tests sahen soweit ok aus, durch es wird immer innerhalb einer Variablen"gruppe" getestet und ersetzt (A, A%, A$, A(), A%(), A$() )
    Durch die alphabetisch absteigende Reihenfolge werden zuerst längere, dann kürzere Variablen (ABER, ABERMALS) getestet, damit es da nicht zu Problemen kommt. Außerdem wird noch der "Kontext" um den Variablennamen herum abgeprüft, damit es beim Ersetzen nicht zu Problemen kommt (BERM, ABERMALS)

    Code
    ab=1
      ac=2
      aber=3
      achtung=4
      ab$="b"
      ae$="e"
      aber$="r"
      abermals$="m"
      print ab,ac,aber,achtung
      print ab$,ae$,aber$,abermals$
    Code
    10 ab=1:ac=2:ae=3:ah=4
    20 ab$="b":ae$="e":a0$="r":ar$="m"
    30 printab,ac,ae,ah
    40 printab$,ae$,a0$,ar$

    Insgesamt war das deutlich anspruchsvoller als ich zuerst dachte...

    Ach ja, und für Rückmeldungen, ob das wirklich funktioniert wäre ich dankbar :)

    Neue Version 1.33 hochgeladen:

    Code
    - kleine "Projektverwaltung" eingebaut

    Man kann jetzt im neuen Project-Menü ein Projekt anlegen, laden, speichern und schließen.
    Ein Projekt ist nichts weiter als eine kleine Ansammlung von Pfadangaben :)

    Bitte melde dich an, um dieses Bild zu sehen.

    Project name - Wird bei einem geöffneten Projekt im Menü angezeigt
    Project file - unter diesem Namen wird das Projektfile immer gespeichert
    PRG file - unter diesem Namen wird das PRG-file automatisch gespeichert
    TXT file - unter diesem Namen wird das PETSCII-file automatisch gespeichert
    Basic tokens - zugehörige Token-Datei, wird automatisch beim Projekt laden aktiviert
    ASCII tokenizer - zugehörige ASCII-tokenizer Datei, wird automatisch beim Projekt laden aktiviert

    Beim Speichern werden automatisch die PRG und die TXT-Datei gespeichert, es wird jeweils ausgehend vom aktuellen Editor-Zustand die jeweils andere Datei neu erzeugt.

    Achtung: Wenn ein Projekt geöffnet ist und man z.B. eine andere PRG-Datei über das File-Menü lädt, wird der Projekt-interne Name nicht nicht geändert, das führt beim Projekt-Speichern oder bei F5 zu einem Überschreiben der Projekt-PRG-Datei! Das ist gewollt, um Dateien sozusagen ins Projekt zu importieren.

    Zitat

    Meine rudimentären Mono/VB.Net Kenntnisse lassen mich auf ein Of-by-One Problem scliessen. Doch waurm passiert dies unter Windows nicht?

    Code
    For x = EditInfo.OffX To Zeile.Length() - 1

    Das wäre aber sehr merkwürdig, weil meine Schleife nur bis Zeile.Length()-1 geht - die kann da nicht drüberhinaus laufen
    Und der Startwert EditInfo.OffX (das ist der Offset am linken Rand, wenn man rechts über die Fensterbreite rausgelaufen ist und der ganze Quelltext nach rachts scrollt) ist 0 wenn man ein neues PRG lädt. Also so spontan sehe ich nicht, wie ich hier außerhalb der erlaubten Grenzen landen kann...Und wie Du schon sagts - warum passiert das dann unter Windows nicht?
    ich befürchte eher, dass da irgendeine Zeichenumwandlung mit 2-Byte UTF's arbeitet und deswegen das Ganze nicht mehr stimmt. Das war ja auch in einer Fehlermeldung zu ASC(...) zu sehen.

    Code
    ...
    Parameter name: bytes
      at System.Text.UTF8Encoding.InternalGetBytes (System.Char* chars, Int32 count, System.Byte* bytes, Int32 bcount, System.Char& leftOver, Boolean flush) [0x00000] 
      at System.Text.UTF8Encoding.InternalGetBytes (System.Char[] chars, Int32 charIndex, Int32 charCount, System.Byte[] bytes, Int32 byteIndex, System.Char& leftOver, Boolean flush) [0x00000] 
      at System.Text.UTF8Encoding.GetBytes (System.Char[] chars, Int32 charIndex, Int32 charCount, System.Byte[] bytes, Int32 byteIndex) [0x00000] 
      at Microsoft.VisualBasic.Strings.Asc (Char String) [0x00000] 
      at Microsoft.VisualBasic.Strings.Asc (System.String String) [0x00000] 
      at BasEdit.frmMain.ShowOneLine (System.Drawing.Graphics myGraphic, System.String Zeile, Int32 y, Boolean 
    ...

    Okay, was jetzt folgt ist das was Neudeutsch so schön "rant" heißt, also einfach nur mein Gegrummel. Ich weiß, das gibt bestimmt Mecker, aber ich muss das mal loswerden :)

    <rant>
    Das mit dem DirSeparator hab ich ja schon drin, das bezog sich mehr auf die Groß-/Kleinschreibung.
    An Dateisysteme mit case sensitive filenames kann ich mich nicht gewöhnen - ich fühle mich mit Schlowski genauso angesprochen wie mit schlowski und kann nicht einsehen, dass das zwei unterschiedliche entities sein sollen...

    Das geht dann weiter bei dem VAL("&h80") - warum zum Geier ist denn VAL("&H80") nicht gültig? Und ist dann VAL("&ha0") <> VAL("&hA0")? Oder erzeugt das sogar einen Fehler? Anmerkung: Hab das inzwischen "voll manuell" gelöst, d.h. ohne ein VAL mit irgendwelchen Hex-Werten sondern auf die klassische Art zeichenweiser Umwandlung und Umrechnung. Das funktionierte dann auch unter Mono...
    </rant>

    Das mit der Tastenauswertung ist interessant, da scheint dann nur der Mac-Mono-Port drunter zu leiden. Aber das lässt mich befürchten, dass es neben grundsätzlichen Mono-Inkompatibilitäten auch noch System-spezifische Probleme gibt, das macht das nicht einfacher *grusel*

    Zitat

    Das ist sehr schade. Aus meiner Erfahrung hat man nachher mehr Schmerz damit, etwas rückzuportieren.


    Da gebe ich Dir prinzipiell Recht, aber eigentlich hatte ich nie vor, das auf was anderem als Windows laufen zu haben. Das war ja alles nur, weil ich gefragt wurde, ob das auch woanders läuft. Aber ehrlich gesagt ist mir persönlich das völlig schnurz, auch wenn ich durchaus verstehe, das das für andere total ärgerlich ist. Aber ich muss auch sehen, wie ich meine Prioritäten setze, habe nur eine gewisse Menge an Zeit zur Verfügung, und die möchte ich dann für Features nutzen, die ich selbst für wichtig halte und/oder die mir einfach mehr Spaß machen. Ich möchte damit niemandem auf die Füße treten, aber nachdem ich jetzt einen Abend mit Mono rumprobiert habe und noch nicht einmal die Spitze des Problem-Eisberges erklommen habe, wollte ich lieber wieder was machen, woran ich Spaß habe. Das er bei ASC(...) mit nirgendwelchen UTF8-Umwandlungen abschnasselt hat mir den Rest gegeben...

    Das mit der Portabilität von .NET Programmen dank Mono läuft in etwas genauso gut wie die vielgepriesene Portabilität von C-Programmen. Prinzipiell schon, es sei denn, man versucht das mit einer echten Anwendung :) Dann kommen all die kleinen Tücken und Kinken zum Tragen und die Anpassungen daran dauern nochmal so lange wie die ursprüngliche Programmierzeit... Oder man muss vorher schon wissen, was geht und was nicht und kann das dann gleich berücksichtigen. Aber dazu fehlt mir die Zeit und die Lust, mich erstmal in Mono einzuarbeiten.

    Also: Vielen Dank an alle, die sich die Zeit genommen haben, das zu testen - zumindest wissen wir jetzt, das es nicht geht.

    Noch ein Nachsatz zu Mono: Hab das gerade mal auf meinem Mac probiert und bin dabei auf folgende Probleme gestoßen:

    1. Pfadprobleme - lassen sich durch Vermeiden von .\ und Beachtung von Groß-/Kleinschreibung lösen
    2. &H80 kann nicht ausgewertet werden - ließe sich durch eine andere Hex-Dez-Routine lösen
    3. Absturz mit Index out of Range nach dem Laden eines PRG - muss genauer untersucht werden
    4. Absturz nach Eingabe einiger Tastenkombinationen mit Shift/Ctrl/Alt
    5. Die Tastaturauswertung funktioniert nicht wirklich, nur ungeshiftete Zeichen werden erkannt, nicht einmal shift-2 für Anführungszeichen gehen

    Und das ist erst der Anfang. So leid es mir für alle Nicht-Windows-User tut, ich lege das erstmal beiseite, um mich weiter um die Funktionalität von BasEdit zu kümmern.