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.
Es gibt 133 Antworten in diesem Thema, welches 33.712 mal aufgerufen wurde. Der letzte Beitrag (
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
sub2.asm
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?
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
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
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.
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?
![]()
(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
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)...
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.
ZitatArt 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.
im Makefile
makefile vs leute die mit pfaden probleme haben....
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
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... ![]()
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
Editor
GUI
various
Bug fixes
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...