Relaunch64 V3 - Finale Version erschienen!

Es gibt 133 Antworten in diesem Thema, welches 33.712 mal aufgerufen wurde. Der letzte Beitrag (19. Juni 2019 um 13:20) ist von WalkThatWay.

  • Seit Version 3.2 hat Relaunch64 neue Platzhalter (RSOURCEFILE und ROUTFILE)


    danke, jetzt sind die Pfadangaben weg. Ich hatte noch SOURCEFILE und OUTFILE aus einer Vorgängerversion im Script.

  • Da wird nichts zusammengeklebt, und da muss auch nichts zusammengeklebt werden. Solange ACME im richtigen Verzeichnis gestartet wird, ist der absolute Pfad dorthin für den Assembliervorgang völlig irrelevant.


    Sorry wegen OT!

    Da wird nichts zusammengeklebt, und da muss auch nichts zusammengeklebt werden. Solange ACME im richtigen Verzeichnis gestartet wird, ist der absolute Pfad dorthin für den Assembliervorgang völlig irrelevant.

    Ah, dann geht sowas nicht (grade getestet, mit 0.9), da der Unterordner sub1 nicht "mitgezogen" wird:

    main.asm
    sub1/sub1.asm
    sub1/sub2.asm


    main.asm

    sub1.asm

    Code
    !source "sub2.asm"
    
    
              sta VIC_BORDER

    sub2.asm

    Code
    VIC_BORDER = 53280

    C64Studio: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- C64Studio WIP: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Hi,

    ich habe geraden 0.94.3 getestet. auch er findet das include im Unterverzeichnis nicht.

    Und was spricht dagegen auch dort die gleiche Indirektion, wie im main.asm zu nehmen?

    Code
    source "sub1/sub2.asm"
    
    
              sta VIC_BORDER

    Im Prinzip kann man pro File einen relativen Pfadraum erzeugen.
    Einen Environment-Stack.
    Und das ganze steuerbar per Option.

    Sollte eigentlich schnell machbar sein Mac Bacon?

    Gruß Höp

    8 Bit sind genug, sonst komme ich morgens nicht aus dem Bett. %)

    „Nous sommes dans un pot de chambre et nous y serons emmerdés.“
    („Wir sitzen in einem Nachttopf und wir werden darin zugeschissen werden“)
    2.9.1870, Auguste-Alexandre Ducrot

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. The home of ACME win32 compile.

  • Ich hab einen neuen Snapshot hochgeladen:
    Bitte melde dich an, um diesen Link zu sehen.



    Neben der Beseitigung bisher genannter Fehler habe ich auch eine Toolbar implementiert. Kann in den Einstellungen ausgeschaltet werden.


    Gruß
    Daniel

  • Ah, dann geht sowas nicht [...]:
    main.asm:

    Code
    !source "sub1/sub1.asm"


    sub1/sub1.asm:

    Code
    !source "sub2.asm"

    Korrekt, an der Stelle geht es schief.

    Und was spricht dagegen auch dort die gleiche Indirektion, wie im main.asm zu nehmen?

    Das löst zwar das Problem, ist aber auch eher hässlich: denn dann funktioniert das File nur korrekt, wenn es vom übergeordneten Verzeichnis aus aufgerufen wird, und das widerspricht ja gerade der Empfehlung "starte den Assembler im gleichen Verzeichnis". Man könnte das Problem umgehen, indem man das Einbinden von "sub2.asm" ebenfalls in "main.asm" macht, aber prinzipiell ist Endurions Kritik berechtigt.

    Sollte eigentlich schnell machbar sein Mac Bacon?

    Machbar ist so ziemlich alles - aber wiegen die Vorteile die Nachteile auf? Wie gesagt, grundsätzlich trifft Endurions Beispiel genau den wunden Punkt. Aber es handelt sich um einen konstruierten Fall - ein realer Use Case wäre beeindruckender. ;)
    Weiterhin wäre eine Änderung nicht abwärtskompatibel (müsste also per Option freigeschaltet werden) und gäbe dem unbedarften Nutzer noch mehr Munition, um sich mit diffusen Pfadproblemen in den Fuß zu schießen.
    Hinzu kommt, dass das neue Verhalten dann natürlich auch genau spezifiziert bzw. dokumentiert werden muss, und da halte ich die derzeitige Lösung für weitaus pflegeleichter (man muss nur das Prinzip "Arbeitsverzeichnis" verstanden haben, was bei den meisten Nutzern, die schon mal eine Kommandozeile gesehen haben, eh der Fall ist).
    Und dann muss es noch implementiert werden, was tatsächlich gar nicht mal sooo viel Arbeit wäre (allerdings kommt noch die Plattformunabhängigkeit ins Spiel).
    Fazit: Ich schließe nicht aus, diese Sache mal anzugehen. Ich bin aber weder überzeugt, dass sie dringend ist, noch, dass sie die Bezeichnung "Problem" oder "Bug" verdient hat. Wer einen realen Use Case findet, möge mir Bescheid sagen.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Ob hier irgendjemand einen "realsen use-case" parat hat, weiß man nicht. Aber im Prinzip könnten alle mehr oder weniger komplexeren Projekte, die man "objektorientiert" anlegt, so ein Fall sein. Da hat man im "Arbeits"verzeichnis nachher nur ein eine kurze Datei, die fast aus include-Befehlen besteht und dann Unterverzeichnisse für verschiedene Bereiche ("Gegner", "Levelmap", usw.), und darin dann wieder aufgesplittete Dateien, die sich untereinander einbinden.

    In einem älteren Sourcecode von Sid-Wizard64 war das z.B. so, da gab es einen Unterordner include, der .asm-Dateien enthielt, die Dateien aus diesem Unterordner eingebunden haben. (also alle lagen im Unterverzeichnis von "include"). Das ganze wurde/wird mit 64tass programmiert, glaube ich. Aber weißt du, wie der Assembler das Pfadproblem löst?

    Code
    .include "include/initer.inc" ;set IRQ handlers, screen, and main VIC registers

    :wink:
    (also genauso wie ACME derzeit)

    Dennoch: Logischer fände ich auch, wenn es so funktioniert, wie von Höppie und Endurion vorgeschlagen. Denn der ganze Hickhack um "Keine absoluten Pfadangaben", "Arbeitsverzeichnis" usw. wird damit quasi ad absurdum geführt. Man braucht nur einmal die asm-Dateien aus dem Unterverzeichnis woanders hin verschieben, und muss wieder alle Pfadangaben anpassen.

  • alles andere als den assembler im root des sourcetrees zu starten und alle pfadangaben relativ zum aktuellen file zu machen ist mumpitz. echt jetzt. es hat schon seine gründe warum das bei ca jedem assembler so ist =P

  • alles andere als den assembler im root des sourcetrees zu starten und alle pfadangaben relativ zum aktuellen file zu machen ist mumpitz. echt jetzt. es hat schon seine gründe warum das bei ca jedem assembler so ist =P

    Direkte Worte, die ich gerne unterstreiche.
    Jeder Compiler muss sich da an Vorgaben halten, die gewachsen und verbereitet sind. Die meisten halten sich an die
    Art wie es in C gelöst ist. mit "Datei" und <Datei>. Wäre das eine Idee für den ACME?

    Gruß Höp

    8 Bit sind genug, sonst komme ich morgens nicht aus dem Bett. %)

    „Nous sommes dans un pot de chambre et nous y serons emmerdés.“
    („Wir sitzen in einem Nachttopf und wir werden darin zugeschissen werden“)
    2.9.1870, Auguste-Alexandre Ducrot

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. The home of ACME win32 compile.

  • zusätzliche include pfade angeben zu können ist davon ab natürlich in der tat sinnvoll (die unterscheidung zwischen <file> und "file" wiederum würde ich nicht einführen, das scheint mir zu verwirrend, und "system-header" gibts bei asm ja auch eher selten so das man das auch nicht wirklich braucht)

  • mit "Datei" und <Datei>. Wäre das eine Idee für den ACME?

    Damit wird zwischen Arbeitsverzeichnis und Library-Verzeichnis unterschieden, und das kann ACME schon seit der Antike (Version 0.05 beta)...

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Wenn man denn Projekte mit "Unterprogrammen" hat, will man ja idR auch, dass die Unterprogramme ebenfalls standalone lauffähig sind. D.h. ich würde dann eher den Weg gehen die Unterprogramme im Makefile als Abhängigkeit vom Hauptprogramm zu definieren, diese zuerst zu kompilieren und als Binaries + Symbol/Label-Liste in ein Hauptprogramm zu importieren.
    Man sollte da aber der Übersicht halber echt sparsam mit umgehen, acme als Linker zu gebrauchen.
    So ein vermeindliches "Feature" wie hier vorgeschlagen kann eher zu mehr Problemen führen.

    Zitat

    Art wie es in C gelöst ist. mit "Datei" und <Datei>. Wäre das eine Idee für den ACME?


    Genau so gibt es das doch schon in ACME.

  • alles andere als den assembler im root des sourcetrees zu starten und alle pfadangaben relativ zum aktuellen file zu machen ist mumpitz.

    Dann versteh ich deine Antwort nicht, weil wenn vom Hauptsourcecode ich im Unterverzeichnis "include" eine Datei "a.asm" einbinde, und in dieser Datei eine weitere aus dem selben Verzeichnis (also "include") eingebunden wird, dann ist doch "a.asm" das aktuelle File (aus Sicht des in a.asm einzubindenden Files), und "b.asm" wäre - relativ - als !bin "b.asm" einzubinden. Momentan muss man aber !bin "include/b.asm" schreiben.

    Ist jetzt aber auch nicht so ein großes Thema, wenn man weiß, wie es gehandhabt wird, kann man entsprechend damit umgehen.

  • Wenn man denn Projekte mit "Unterprogrammen" hat, will man ja idR auch, dass die Unterprogramme ebenfalls standalone lauffähig sind..

    Ich meinte nicht Unterprogramme, sondern ausgelagerte Programmteile, damit die Sourcecodes kleiner sind. Bei "standalone" lauffähigen (Unter-)Programmen ist das natürlich etwas anderes.

  • Hi,
    dann passt es doch mit den Includes. Darauf wollte ich
    heraus.
    Mit der Kombination von Makefiles und Projektsteuerung
    lässt sich doch alles erreichen.
    ACME hat doch noch die LIB-Variable um zentrale Sourcen
    zu verwalten.

    Gruß
    Höp

    8 Bit sind genug, sonst komme ich morgens nicht aus dem Bett. %)

    „Nous sommes dans un pot de chambre et nous y serons emmerdés.“
    („Wir sitzen in einem Nachttopf und wir werden darin zugeschissen werden“)
    2.9.1870, Auguste-Alexandre Ducrot

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. The home of ACME win32 compile.

  • Feedback: (Win7-64bit, Java7, Relaunch64 3.2.1 Build 20140623)

    * wenn man das Log-Fenster mit <shift>+<f12> aus- und wieder einschaltet, verändert sich die Position. (es sollte sich so wie die "Goto-sidebar" verhalten)
    * das Suchen-Fenster sollte über das Menü und/oder über ein kleines Icon geschlossen werden können. Es geht zwar mit der <Esc>, aber nur bei Fokus der Sucheingabezeile.
    * Tastenkürzel für den Menübefehl <Source><Collapse all folds> (für mich ein sehr häufig benutzter Befehl). Ein <F1> für die Hilfe kann auch nicht schaden.
    * die Tastenkombination <shift>+<tab> (Tab ausrücken) nimmt immer genau 8 Zeichen weg. (wenn möglich, sollte die Tabulator-Breite aus den Einstellungen verwendet werden)
    * (Wunsch) die beiden Funktionen "in Großbuchstaben umwandeln" und "in Kleinbuchstaben umwandeln" ins Edit-Menü einbauen. Sinnvoll bei Blockmarkierungen mittels <Strg>+<linke Maustaste>

  • Ok, vielen Dank! Ich schau mir die Sachen mal an. Eventuell klappt es noch vor meinem Urlaub, sonst im August.

  • Bug-Report V3.3 Windows:

    - "Enter" key keeps focus in find field -> Wenn find-by-typing an (sonst geht's): findet mit ENTER jedes Mal wieder das erste Vorkommen des Suchbegriffs von oben an, funzt also nicht fürs Weitersuchen mit Enter (aber wenigstens überschreibt es auch nichts mehr)
    - Don't wait when running scripts -> Enable, apply, Neustart -> disabled bzw. Disable, apply, Neustart, enabled. Saved also den Status genau vertauscht ab.

  • Hallo Jasmin,

    vielen Dank für das Feedback. Ja, das Problem mit der doppelten Verneinung, da hat sich der Fehler mit der vertauschtem Einstellung eingeschlichen... :wink:

    Damit verbunden schiebe ich hier noch mal die Ankündigung nach, dass Version 3.3 grade erschienen ist:
    Bitte melde dich an, um diesen Link zu sehen.


    bzw. Bitte melde dich an, um diesen Link zu sehen.

    Hier das change log:

    New features
    Code navigation

    • jump back and forth between label source and label definition (see menu navigation)
    • re-mapped menu-shortcut for "Jump to label" command, which was also renamed to "Jump to label-definition"

    Editor

    • added find-by-typing option for search textfield (can be en-/disabled via preferences)
    • added feature to convert selection to lower/upper case (see menu edit)

    GUI

    • added toolbar with common functions
    • added sorting-options for sidebar
    • "Select script" was removed from log-area and moved to the toolbar. if toolbar is hidden, a selection popup appears to select scripts
    • added close-button to find-/replace-textfield
    • added more shortcuts to menu-commands

    various

    • added preference that hitting enter-key in find-textfield keeps focus in find textfield, so multiple enter will find next searchterm
    • added preference to not wait for the last process (e.g. emulator run) when running a script (instead, editing is possible immediately after last process is being executed)

    Bug fixes

    • automatic update check did not work - fixed
    • changing "Other" preferences did not apply immediatley - fixed.
    • sidebar width changed when refreshing the sidebar-list or creating a new Goto-list - fixed




    Die oben genannten beiden Fehler werde ich in den nächsten Tagen mal angehen...


    Viele Grüße
    Daniel

  • So, hab die Fehler behoben. Ich kann die nächsten Tage ein Update bereitstellen...