Deutsch
SDK-Helfer/ Tools

JRPC neuer Präkompiler für XProfan X4 - JRPC3

 
- Seite 1 -



Jens-Arne
Reumschüssel
Guten Abend zusammen,

ich bin kürzlich über das Problem gestolpert, dass XPSE eine ziemlich große Quelldatei von mir nicht mehr verarbeiten konnte. Variablen wurden plötzlich als nicht definiert gemeldet und andere "erratische" Probleme mehr. Ich könnte mir vorstellen, dass dies daran liegt, dass XPSE Schlüsselworte in Windows-Atoms verwaltet. Da ist irgendwann Schluss (bei irgendwas zwischen 60.000 und 70.000 Stück, wobei man bedenken muss, dass XPSE die Windows-API mit vorhält). Vielleicht ist es aber auch etwas ganz anderes, ich kann ja nicht in den "Maschinenraum" von XPSE schauen.

Jedenfalls blieb mir, da XPSE nicht mehr gepflegt wird, nichts anderes übrig, als das nachzubauen. Das Ergebnis ist JRPC3.

----- Features:

*vernünftige Meldung von Fehlern:
-die Datei, in der der Fehler auftrat, wird angezeigt (z.B. eine INC-Datei)
-es wird immer die Zeilennummer des Moduls ausgegeben, in dem der Fehler auftrat (also z.B. die Zeilennummer innerhalb einer INC-Datei), und nicht die reichlich nutzlose Zeilennummer der Ergebnisdatei
-bei allen Fehlern, insbesondere Sektionsfehlern (z.B. if, endif, endif), werden verständliche Meldungen ausgegeben, und zwar so nah wie möglich am Punkt im Quellcode, wo der Fehler zu verorten ist
-die Zeile, in der ein Fehler auftrat, kann direkt in XProfEd angezeigt werden, sofern der von mir aufgebohrte XProfEd verwendet wird (siehe unten)

*direkte Anzeige des Programmablaufes in XProfEd (sofern der unten erhältliche aufgebohrte XProfEd verwendet wird):
-{$XTRACE ON[,Verzögerung]} bewirkt, dass jede folgende Zeile direkt während des Programmablaufes in XProfEd angezeigt wird (der optionale Parameter <Verzögerung> stellt eine Pause zwischen den Zeilen in Millisekunden ein)
-{$XTRACE OFF} schaltet die Ablaufverfolgung wieder ab
-dies ist extrem nützlich, um herauszufinden, wo genau ein getestetes Programm abstürzt

*Neue Kompilerdirektive für alte Profan-Syntax für Operatoren (ab V1.64):
Für alte Codes, die z.B. @add(x%,y%) statt x%+y% verwenden, bitte nicht die Include-Datei „PROFALT.INC“ benutzen. Diese funktioniert mit JRPC3 nicht. Stattdessen ist die Com-pilerdirektive {$USEOLDPROF} zu verwenden. Diese schaltet die automatische Umwandlung der alten Operator-Funktionen in die aktuellen Operatoren ein.

*neue Kompilerdirektiven {$TRACEVAR ...} zur Echtzeitverfolgung von Variableninhalten, siehe Menü Hilfe --> Anleitung anzeigen (neuer XProfEd_JR unten für hervorgehobene Anzeige der Direktiven)

*neue Kompilerdirektiven für Zeitmessungen, siehe Menü Hilfe --> Anleitung anzeigen (neuer XProfEd_JR für hervorgehobene Anzeige der Direktiven)

*neue Kompilerdirektive {$NOCHECKDUPLICATEVARS}
es ist in XProfan möglich, Parameter- und Variablendeklarationen bedingt durch IF-Zeilen zu definieren – damit das funktioniert, muss die Prüfung auf doppelte Variablendeklarationen abgeschaltet werden, was diese Kompilerdirektive bewirkt; allerdings ist diese Prüfung dann für das gesamte Programm deaktiviert

*neue Compilerdirektive {$CONVERTFOR2WHILE}
bei Nutzung dieser Compilerdirektive werden alle FOR…ENDFOR-Schleifen zu WHILE…ENDWHILE-Schleifen konvertiert – beim Aufruf von Profan2Cpp aus JRPC3 heraus geschieht dies übrigens automatisch, da Profan2Cpp das XProfan-FOR nicht kennt (und auch das XPSE-FOR nicht)

*Kompilerdirektiven funktionieren endlich vernünftig
-Verschachtelung wird berücksichtigt (in XPSE und auch XProfan ist Verschachtelung zwar möglich, aber innerhalb von $IFDEF DASHIER wird $DEFINE DIESHIER auch dann definiert, wenn DASHIER nicht definiert ist - das ist in JRPC3 anders)
-Prozeduren, die aktuell durch eine Kompilerdirektive, deren Bedingung nicht erfüllt ist, von der Kompilierung ausgeschlossen sind, werden erkannt und es wird eine entsprechende verständliche Fehlermeldung ausgegeben. So weiß man, dass die Prozedur grundsätzlich existiert (man sich also nicht verschrieben hat), dass aber eine Kompilerdirektivendefinition geändert werden muss, um diese Prozedur zu benutzen.

*Einrückungsanalyse
-Die Analyse von Verschachtelungsfehlern (z.B. fehlendes ENDIF) ist besonders schwierig, weil bei längeren Verschachtelungskaskaden prinzipiell nicht festgestellt werden kann, zu welchem bspw. IF das ENDIF fehlt. Erst am Ende einer Prozedur bzw. des Hauptprogramms steht fest, dass ein ENDIF zu wenig vorhanden ist. Wenn es sich um einen langen und komplizierten Codeblock handelt, ist es manchmal extrem mühsam, diese Verschachtelungsfehler zu finden, wenn man z.B. nach Copy/Paste-Aktionen solche Fehler produziert hat. Bei diesem Problem hilft die Einrückungsanalyse. Diese wird bei derartigen Fehlern als zusätzliche Option angeboten und kann dann mit „ü“ gestartet werden.
-Diese Analyse macht sich zu nutze, dass die allermeisten Autoren ihren Code innerhalb eines IF/ENDIF-, FOR/ENDFOR-, WHILE/ENDWHILE-, REPEAT/UNTIL-Blockes ein-rücken. Wenn ein Verschachtelungsfehler auftritt, ist damit daher in aller Regel ein Bruch der Einrückungen verbunden, der sich feststellen lässt. Auf diese Weise lässt sich sehr viel genauer eingrenzen, wo genau das Problem liegt.
-Die Standard-Einrücktiefe des Autors wird nur anhand des Moduls ermittelt, in dem der Verschachtelungsfehler auftritt, damit ggf. genutzte Fremdmodule anderer Autoren, die ggf. andere Einrücktiefen verwenden, keine Verfälschungen erzeugen.
-Es wird nur der Codeblock analysiert, in dem der Verschachtelungsfehler auftritt (also die entsprechende Prozedur oder das Hauptprogramm).
-gefundene Einrückungsbrüche können direkt in XProfEd angezeigt werden (aufgebohrter XProfEd nötig).

*ein mit JRPC3 gestartetes Programm (interpretiert, .prc gestartet, .exe gestartet) kann mit einem Tastendruck aus JRPC3 heraus gekillt werden - dies ist sehr hilfreich, wenn ein getestetes Programm mal wieder hängenbleibt und normalerweise nur mittels des Taskmanagers beendet werden kann

*extrem schnell (und daher natürlich nicht in XProfan geschrieben, da eine interpretierte Sprache hierfür naturgemäß viel zu langsam ist)

*beim Start von JRPC3 bereits vorhandene .prc-Dateien können zum Starten und Linken genutzt werden (es wird ein Hinweis angezeigt, dass es sich um ein altes Kompilat handelt)

*der Profan-Compiler kann mit hoher Prozessorpriorität aufgerufen werden („!“ statt „c“ als Befehl benutzen), hierdurch ist er etwa 1/3 schneller – allerdings erfolgt eine UAC-Abfrage des Administratorpassworts, weil Windows diese hohe Prozessorpriorität sonst nicht zulässt; dieses Feature lohnt sich also nur bei wirklich großem Quellcode

*eingebauter Update-Checker mit Download, falls es ein Update gibt (Hilfe --> online nach Updates suchen)

*64- oder 32-bit-Version verfügbar (einfach JRPC3_64.exe oder JRPC_32.exe als Interpreter in XProfEd hinterlegen [Optionen --> Allgemeine Einstellungen] und JRPC3 mit F7 starten)

*XProfan X4-Syntax verfügbar (möglicherweise noch nicht alles, da ich vermutlich nicht alles davon benutze, aber ich habe mich um Vollständigkeit bemüht - jedenfalls sind z.B. HASH-Arrays und QUADINTs dabei)

*Interpreter, PRCs und EXEs können mit Kommandozeilenparametern ausgeführt werden

*Achtung: Variablen, die in einer Prozedur nicht deklariert sind, sondern "aus der aufrufenden Prozedur übernommen werden", sind nicht zugelassen (XProfan erlaubt das, aber so etwas ist genauso tödlich wie GOTO-Anweisungen). Bitte alle zu nutzenden Inputs als Parameter übergeben, und wenn etwas aus dem aufrufenden Programmteil verändert werden muss, beim Aufruf als Parameter z.B. @addr(x&) verwenden und in der Prozedur parameters x# und LONG x#,0=y& nutzen.

*Prozeduren, die in dem aktuellen Programm zwar enthalten sind, aber nicht verwendet werden, werden standardmäßig aus der umgesetzten Datei entfernt, um die Dateigröße des Kompilats möglichst klein zu halten (kann mit {$NOPROCEXCLUDE} abgeschaltet werden)

*fast alles aus XPSE funktioniert auch in JRPC3 ({$NOERR}, {$(PRE)BATCH}, {$PUSHKEYWORD}, Interpreter, Runtime und Compiler festlegen, Shorties, ...)

Einschränkungen:
-keine nPROCs
-kein XPSE-Inline-Assembler, wohl aber XProfan-Inline-Assembler (darin allerdings keine Prüfungen auf Korrektheit des Codes)
-ABER: man kann XPSE aus JRPC3 heraus aufrufen, sodass diese Funktionalitäten weiterhin verfügbar sind, sofern man XPSE besitzt (neuer Shorty: {$x})
-@external(...)-Aufrufe werden, anders als in XPSE, nicht in @call(...)-Aufrufe umgesetzt; diese sind zwar schneller, aber dann lassen sich Prozeduren nicht mehr als Prozesse aufrufen, wenn darin @external(...)-Aufrufe verwendet werden, weil die im Hauptprogramm definierten @call(...)-Adressen dann im Speichernirvana enden

*als Hommage an XPSE lautet die Endung der Ausgabedatei ".enh3"

----- /Features

JRPC3 kann unten heruntergeladen werden (setup_jrpc3.exe).
Als Installationsverzeichnis bitte das XProfan-Stammverzeichnis angeben, also dasjenige, in dem die Dateien PROFAN.EXE etc. liegen. Alternativ kann die ZIP-Datei heruntergeladen und deren Inhalt manuell ins XProfan-Stammverzeichnis kopiert werden.

Wenn man das Feature nutzen möchte, die Zeile, in der ein Fehler auftrat, direkt in XProfEd anzeigen zu können, ist der mitinstallierte XProfEd_JR erforderlich. Als "goody" gibt es dazu, dass beim Auf- und Zufalten von Programmen ein Fortschrittsanzeiger integriert ist (das kann bei großen Programmen ja bekanntlich ein bisschen dauern).

Alle Befehle sind mit dem Befehl "h" wie "Hilfe" abrufbar und sollten selbsterklärend sein.

Es ist bestimmt so, dass noch lange nicht alles perfekt funktioniert. Meine  Programme lassen sich umsetzen, aber das muss noch lange nicht heißen, dass dies mit Programmen anderer Autoren auch funktioniert, die jeder so ihre Eigenheiten haben. Ich weiß nicht einmal, ob es überhaupt (noch) Bedarf für diesen Präkompiler gibt. Falls jemand daran Interesse hat, wollte ich ihn hier trotzdem nicht vorenthalten.

Fehlermeldungen und Verbesserungsvorschläge gerne an jreumsc@web.de.

Beste Grüße, Jens-Arne

1.317 kB
Bezeichnung:JRPC3
Version:2.03b
Kurzbeschreibung: JRPC3-Installer
Hochgeladen:15.02.2021
Ladeanzahl34
Herunterladen
1.697 kB
Bezeichnung:XProfEd_JR
Version:5.2
Kurzbeschreibung: aufgebohrter XProfEd, um die Programmzeile von Fehlern, die JRPC3 findet, anzeigen zu können
Hochgeladen:15.02.2021
Ladeanzahl29
Herunterladen
2.112 kB
Bezeichnung:JRPC3
Version:2.03b
Kurzbeschreibung: ZIP-Datei statt Installer
Hochgeladen: vor 21 Tagen
Ladeanzahl10
Herunterladen
 
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
16.02.2021  
 



 
- Seite 2 -



Jens-Arne
Reumschüssel
Naja, das Ziel war es erst einmal, XProfan-Programme, die für XPSE zu groß geworden waren, wie mit XPSE umsetzbar zu machen. Dabei ist natürlich dann die neue Syntax von XProfan bis X4 dazugekommen, soweit ich diese bisher überblickt habe. D.h. "Entwicklung 64bit" bzw. "Erstellung compilierter EXEn 64bit" ist damit nicht gemeint, weil XProfan bislang nur 32bit kann.

Zur Benutzung ist an Abhängigkeiten nichts nötig außer XProfan, wobei die Version von XProfan dabei ziemlich egal sein sollte. Wenn man nPROCs und die XPSE-Assemblerfunktionen nutzen möchte, ist auch XPSE nötig (kann aus JRPC3 heraus aufgerufen werden). XProfan-Assembler läuft ja nun seit heute.

Eine Mindest-Windows-Version sollte es eigentlich auch nicht geben, da die 32bit-Version von JRPC3 vermutlich auch mit Windows XP läuft. Ich benutze aber Windows 10 mit 64bit und habe bislang keine andere Umgebung getestet. Die DLL für die Variablenverfolgung ist bewusst nur 32bittig, damit sie in jeder Windows-Umgebung läuft. Außerdem wird diese aus dem XProfan-Programm heraus beschickt, dessen Variablen man verfolgen möchte, sodass sie ohnehin nicht 64bittig sein kann.

Wie gesagt: Ich wollte so etwas wie XPSE in etwas moderner, nicht mehr. Ich habe seit Ewigkeiten alles in XPSE-Syntax geschrieben, und es ist fast unmöglich, das wieder auf reinen Profan-Code zurückzubauen, selbst wenn das eigentlich nur "Kleinigkeiten" sind. Aber davon eine unglaubliche Menge.

Wo ich nun schon einmal dabei war, war ein weiteres Ziel von mir, vernünftige Fehlermeldungen mit Angaben zu Quelldatei, Prozedur und Zeile zu erhalten. Die bekommt man weder von XProfan selbst, noch von XPSE. Das ist eine der großen Stärken von JRPC3, denke ich, und solche Winzigkeiten wie die, ein getestetes Programm zur Not mit einem Tastendruck abschießen zu können, wenn es nicht mehr reagiert, es mit Kommandozeilenparametern ausführen zu können, wenn man ein Programm testet, das diese nutzt, und nicht zuletzt sich Fehler direkt in XProfEd anzeigen lassen zu können, erleichtern das Leben ungemein.

Das sind die wesentlichen Ziele dieses Projekts. Niemand braucht es zum Überleben, aber es macht einiges sehr viel angenehmer. Jedenfalls, wenn es am Ende mal so funktioniert, dass es auch alle verwenden können. Ein erster großer Schritt dahin ist heute getan worden. Wenn es weitere Fehler gibt, die Euch sofort ins Auge springen, in die ich aber noch nie hineingelaufen bin, wäre ich für eine kurze Nachricht extrem dankbar. Michael Wodrich hat mir heute diverse Problemchen vorgesetzt, von deren Existenz ich nicht einmal etwas ahnte, aber das war trotzdem an einem Nachmittag in den Griff zu bekommen.

Beste Grüße und frohe Ostern, Jens-Arne
 
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
vor 20 Tagen  
 




RudiB.
Hallo Jens-Arne,

habs jetzt auch mal kurz getestet. Habe in vielen Quelltexten noch alte Profan-Syntax und nutze daher die Profalt.inc....und siehe da...



Konnte bisher nicht weiter testen, weil da stoppt ja die Fehlerabfrage. Hab ich da was überlesen oder warum durchläuft es nicht den ganzen Quellcode?

Will jetzt nicht alles umschreiben müssen, um weiter zu testen....

57 kB
Hochgeladen: vor 19 Tagen
Ladeanzahl1
Herunterladen
 
XProfan X4
Xprofan X4

Rudolf Beske / München
vor 19 Tagen  
 




Jens-Arne
Reumschüssel
...Ich bin dran. Dein Problem mit der alten Profan-Syntax ist bereits gelöst. Es gibt aber weitere, sodass ich das noch nicht hochladen kann.
 
XProfan X4
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
vor 19 Tagen  
 




Jens-Arne
Reumschüssel
...Ok, es ist vollbracht.

Die Include-Datei "PROFALT.INC" ist nicht mehr nötig und sollte nicht mehr verwendet werden. Stattdessen ist die neue Compilerdirektive {$USEOLDPROF} zu verwenden. Diese schaltet die automatische Umsetzung der alten Operator-Funktionen in die aktuellen Operatoren ein.

Nachtrag: PROFALT.INC kann im Code stehenbleiben. Sie wird ignoriert und automatisch die entsprechende Compilerdirektive aktiviert. So bleibt der Code kompatibel zum nativen Profan.

XProfEd_JR ist nun im Installer und in der ZIP-Datei enthalten.

Ich wünsche einen schönen Ostersonntag,
Jens-Arne
 
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
vor 19 Tagen  
 




RudiB.
Hallo,

...und der nächste Fehler ???



gruß Rudi

55 kB
Hochgeladen: vor 19 Tagen
Ladeanzahl1
Herunterladen
 
XProfan X4
Xprofan X4

Rudolf Beske / München
vor 19 Tagen  
 



 
- Seite 3 -



Jens-Arne
Reumschüssel
Naja, Du hast Windows.ph eingebunden. Da ist die Funktion bereits definiert. Das soll also so sein. Man findet eine ganze Menge Fehler mit JRPC3, die einem vorher entgangen sind, jedenfalls war das bei mir so.

EDIT: Obwohl, wenn ich jetzt so darüber nachdenke... Das ist da ja nur als Headeraustauschtext definiert. Also müsste Dein Code ok sein. Ich werde das mal checken.

EDIT 2: Versuch's jetzt bitte nochmal.

EDIT 3: Du kannst mir die Fehlermeldungen auch per pm schicken (jreumsc@web.de), dann füllt das diesen Thread nicht so. Ein Beispielprogramm zum Testen wäre auch einfacher, als bei jedem Fehler sukzessive über neue Uploads hier das Troubleshooting durchzuführen.

EDIT 4: Der Fehler tritt bei Dir in STBAR.INC auf. Möglicherweise ist die Funktion wirklich doppelt definiert? Ich kann den Fehler nämlich nicht nachvollziehen.
 
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
vor 19 Tagen  
 




Jens-Arne
Reumschüssel
Es wird jetzt das Modul angezeigt, wo eine Funktion das erste Mal definiert wurde. Vielleicht hilft das bei der Suche nach dem Problem.
 
XProfan X4
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
vor 19 Tagen  
 




p.specht
Tolles Teil! Danke auch für die Klarstellung der Philosophie dahinter!
Ostergruss
 
XProfan 11
Computer: Gerät, daß es in Mikrosekunden erlaubt, 50.000 Fehler zu machen...
vor 18 Tagen  
 




Jens-Arne
Reumschüssel
Der Profan-Compiler kann jetzt mit hoher Prozessorpriorität aufgerufen werden (V1.68). Dazu ist "!" statt "c" zum Starten des Compilers zu verwenden. Es gibt aber einen großen Wermutstropfen: Damit Windows diese Prozessorpriorität zulässt, erfolgt eine UAC-Abfrage des Windows-Administratorpasswortes. Das lohnt sich also nur bei entsprechend großem Code. Der Compiler wird dadurch etwa 1/3 schneller als normalerweise, jedenfalls bei mir.

Mit "p" kann jetzt Profan2Cpp aufgerufen werden, sofern installiert (V1.69).

Beste Grüße, Jens-Arne
 
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
vor 18 Tagen  
 




Jens-Arne
Reumschüssel
neue Version:

V1.73:
- Bug bei XPSE-FOR...DO BEGIN-Umsetzung behoben
- jedes Programm, das Profan-FOR benutzt (also z.B. For i%,1,10), kann jetzt direkt ohne Nutzung von XFOR in XPSE gestartet werden, sofern JRPC V1 im Profan-Stammverzeichnis vorhanden ist (XFOR darf aber weiter benutzt werden)
- alte Move-Befehle zu {$USEOLDPROF} hinzugefügt

V1.74:
- neue Kompilerdirektive {$NOCHECKDUPLICATEVARS}
es ist in XProfan möglich, Parameter- und Variablendeklarationen bedingt durch IF-Zeilen zu definieren – damit das funktioniert, muss die Prüfung auf doppelte Variablendeklarationen abgeschaltet werden, was diese Kompilerdirektive bewirkt; allerdings ist diese Prüfung dann für das gesamte Programm deaktiviert
- keine Doppelpunkt-Zeilentrennung mehr bei CASE/NOCASE (XProfan kann das zwar, aber XPSE nicht)
- XPSE-FOR wird jetzt als XProfan-FOR umgesetzt, nicht mehr als WHILE...ENDWHILE (XPSE funktioniert trotzdem noch, wenn JRPC V1 vorhanden ist)
 
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
vor 17 Tagen  
 




Jens-Arne
Reumschüssel
Einrückungsanalyse eingebaut (V2.00b):

-Die Analyse von Verschachtelungsfehlern (z.B. fehlendes ENDIF) ist besonders schwierig, weil bei längeren Verschachtelungskaskaden prinzipiell nicht festgestellt werden kann, zu welchem bspw. IF das ENDIF fehlt. Erst am Ende einer Prozedur bzw. des Hauptprogramms steht fest, dass ein ENDIF zu wenig vorhanden ist. Wenn es sich um einen langen und komplizierten Codeblock handelt, ist es manchmal extrem mühsam, diese Verschachtelungsfehler zu finden, wenn man z.B. nach Copy/Paste-Aktionen solche Fehler produziert hat. Bei diesem Problem hilft die Einrückungsanalyse. Diese wird bei derartigen Fehlern als zusätzliche Option angeboten und kann dann mit „ü“ gestartet werden.
-Diese Analyse macht sich zu nutze, dass die allermeisten Autoren ihren Code innerhalb eines IF/ENDIF-, FOR/ENDFOR-, WHILE/ENDWHILE-, REPEAT/UNTIL-Blockes ein-rücken. Wenn ein Verschachtelungsfehler auftritt, ist damit daher in aller Regel ein Bruch der Einrückungen verbunden, der sich feststellen lässt. Auf diese Weise lässt sich sehr viel genauer eingrenzen, wo genau das Problem liegt.
-Die Standard-Einrücktiefe des Autors wird nur anhand des Moduls ermittelt, in dem der Verschachtelungsfehler auftritt, damit ggf. genutzte Fremdmodule anderer Autoren, die ggf. andere Einrücktiefen verwenden, keine Verfälschungen erzeugen.
-Es wird nur der Codeblock analysiert, in dem der Verschachtelungsfehler auftritt (also die entsprechende Prozedur oder das Hauptprogramm).
-gefundene Einrückungsbrüche können direkt in XProfEd angezeigt werden (aufgebohrter XProfEd nötig).
 
XProfan X4
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
vor 15 Tagen  
 




Jens-Arne
Reumschüssel
V2.02: wenn Profan2Cpp aufgerufen werden soll und FOR/ENDFOR im Code vorkommt, wird dies nun automatisch zu WHILE/ENDWHILE konvertiert, da Profan2Cpp die XProfan-FOR-Syntax nicht kennt.

Damit ist meine Agenda nun erst einmal abgearbeitet.

Beste Grüße, Jens-Arne

EDIT: Kleiner Bug bei verschachtelten FORs gefixt (V2.02a)

EDIT2: die Umwandlung kann nun auch per Compilerdirektive eingeschaltet werden: {$CONVERTFOR2WHILE} (V2.03)
 
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
vor 5 Tagen  
 




Antworten


Thementitel, max. 100 Zeichen.
 

Systemprofile:

Kein Systemprofil angelegt. [anlegen]

XProfan:

 Beitrag  Schrift  Smilies  ▼ 

Bitte anmelden um einen Beitrag zu verfassen.
 

Themenoptionen

981 Betrachtungen

Unbenanntvor 0 min.
Thomas ZielinskiGestern (16:18)
RGHGestern (11:09)
HofKVorgestern (20:52)
Manfred BareiVorgestern (19:51)
Mehr...

Themeninformationen



Admins  |  AGB  |  Anwendungen  |  Autoren  |  Chat  |  Datenschutz  |  Download  |  Eingangshalle  |  Hilfe  |  Händlerportal  |  Impressum  |  Mart  |  Schnittstellen  |  SDK  |  Services  |  Spiele  |  Suche  |  Support

Ein Projekt aller XProfaner, die es gibt!


Mein XProfan
Private Nachrichten
Eigenes Ablageforum
Themen-Merkliste
Eigene Beiträge
Eigene Themen
Zwischenablage
Abmelden
 Deutsch English Français Español Italia
Übersetzungen

Datenschutz


Wir verwenden Cookies nur als Session-Cookies wegen der technischen Notwendigkeit und bei uns gibt es keine Cookies von Drittanbietern.

Wenn du hier auf unsere Webseite klickst oder navigierst, stimmst du unserer Erfassung von Informationen in unseren Cookies auf XProfan.Net zu.

Weitere Informationen zu unseren Cookies und dazu, wie du die Kontrolle darüber behältst, findest du in unserer nachfolgenden Datenschutzerklärung.


einverstandenDatenschutzerklärung
Ich möchte keinen Cookie