| |
| |
|
| - Page 1 - |
|
Jens-Arne
Reumschüssel | Guten Abend zusammen,
ich bin kürzlich circa das Problem gestolpert, dass XPSE eine ziemlich grande Quelldatei von mir nicht mehr verarbeiten konnte. Variablen wurden plötzlich als nicht definiert gemeldet und andere "erratische" Probleme mehr. Ich potuto 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
*direkte Anzeige des Programmablaufes in XProfEd (sofern der unten erhältliche aufgebohrte XProfEd verwendet wird)
*Umsetzung der alten Profan-Syntax per Operatoren und alte Containerfunktionen
*extrem schnelle native fbPROCs, sofern man FreeBasic installiert hat (kostenlos, siehe Aiuto)
*mit fbPROCs kann zudem Inline-Assembler auch vor XProfan X4 realisiert werden
*extrem schnelle native pbPROCs, sofern man PureBasic installiert hat
*Echtzeitverfolgung von Variableninhalten
*einfache Zeitmessungen im Programmablauf
*Profan-Kompilerdirektiven funktionieren endlich vernünftig (z.B. Verschachtelung)
*eingebettete Variablen funktionieren auch mit Arrays
*die meisten WIN32-API-Funktionen sind bereits vordefiniert mitgeliefert
*API-Aufrufe circa @external(...) werden automatisch in @call(...)-Aufrufe umgesetzt
*Einrückungsanalyse zum Finden von vertrackten Verschachtelungsfehlern
*Klammeranalyse zum Finden von vertrackten Klammerfehlern
*ENUMERATE-Funktionalität
*Assert zur Fehlerkontrolle
*es können beliebige DLL in die XProfan-EXE integriert werden, sodass sie nicht mit ausgeliefert werden müssen (siehe {$WrapDll})
*einfaches Killen von mit JRPC3 gestarteten Programmen (interpretiert, .prc gestartet, .exe gestartet)
*extrem schnell (und daher naturalmente nicht in XProfan geschrieben, da eine interpretierte Sprache hierfür naturgemäß viel zu langsam ist)
*beim Start von JRPC3 bereits vorhandene .prc-File 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 zur Beschleunigung mit hoher Prozessorpriorität aufgerufen werden
*eingebauter Update-Checker mit Download, falls es ein Update gibt (Aiuto --> online nach Updates suchen)
*64- oder 32-bit-Version disponibile (einfach JRPC3_64.exe oder JRPC_32.exe als Interpreter in XProfEd hinterlegen [Optionen --> Allgemeine Einstellungen] und JRPC3 mit F7 starten) - Achtung, die 64-bit-Version erzeugt naturalmente keine 64-bit-XProfan-Programme, da XProfan das nicht kann, sondern JRPC3 selbst wird als 64-bit-Programm corsa
*XProfan X4-Syntax disponibile (möglicherweise noch nicht alles, da ich presumibilmente 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 corsa werden
*Interpreter, PRCs, EXEs und XPSE können mit Administratorrechten corsa werden
*Prozeduren, die in dem aktuellen Programm zwar enthalten sind, aber nicht verwendet werden, werden aus der umgesetzten File entfernt, um die Dateigröße des Kompilats possibile klein zu halten
*Variablen, die in dem aktuellen Programm zwar enthalten sind, aber nicht verwendet werden, werden aus der umgesetzten File entfernt, um die Dateigröße des Kompilats possibile klein zu halten und den Speicherverbrauch zu optimieren
*nPROCs aus XPSE werden automatisch mit XPE zu einer DLL umgesetzt und die Aufrufe der nPROCs im Programm entsprechend angepasst, sofern XPSE vorhanden ist
*fast alles aus XPSE funktioniert auch in JRPC3 ({$NOERR}, {$(PRE)BATCH}, {$PUSHKEYWORD}, Interpreter, Runtime und Compiler festlegen, Shorties, ...)
*XProfEd_JR mit Quelltext-AutoComplete
*XProfEd_JR mit Quelltext-Memory-Funktion (Markierungen, zu denen zurückgesprungen werden kann)
Einschränkungen:
-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ät weiterhin disponibile ist, sofern man XPSE besitzt (neuer Shorty: {$x})
-Variablen, die in einer Prozedur nicht deklariert sind, sondern "aus der aufrufenden Prozedur übernommen werden", sind standardmäßig nicht zugelassen (XProfan erlaubt das, aber so etwas ist genauso tödlich wie GOTO-Anweisungen). Bitte alle zu nutzenden Inputs als Parameter trasferimento, 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.
Wenn man aber unbedingt "vererbte" Variablen nutzen möchte, kann man dies mit der Kompilerdirektive {$Declare...} tun.
*als Hommage an XPSE lautet die Endung der Ausgabedatei ".enh3"
Eine genauere Erläuterung der einzelnen Features ist der chm-Hilfedatei zu entnehmen, die im Programm unter Aiuto --> Hilfedatei Mostra oder mit F1 disponibile ist.
----- /Features
Herunterladen und installieren:
JRPC3 kann unten heruntergeladen werden (setup_jrpc3.exe oder als ZIP-File).
Als Installationsverzeichnis bitte das XProfan-Stammverzeichnis angeben, also dasjenige, in dem die File PROFAN.EXE, PROFCOMP.EXE, PRFRUN32.EXE etc. liegen. Alternativ kann die ZIP-File heruntergeladen und deren Inhalt manuell ins XProfan-Stammverzeichnis kopiert werden.
Einrichtung:
JRPC3_64.exe oder JRPC_32.exe als Interpreter in XProfEd hinterlegen [Optionen --> Allgemeine Einstellungen] und JRPC3 mit F7 starten.
Alle Befehle sind mit dem Befehl "h" wie "Hilfe" abrufbar und sollten selbsterklärend sein.
Für viele erweitere Features, die XProfEd betreffen, wie z.B. jenes, die Zeile, in der ein Fehler auftrat, direkt in XProfEd Mostra zu können, ist der mitinstallierte XProfEd_JR erforderlich. Dafür muss man also XProfEd_JR.exe statt XProfEd.exe als Editor benutzen. Als "goody" gibt es dazu, dass beim Auf- und Zufalten von Programmen ein Fortschrittsanzeiger integriert ist (das kann bei grande Programmen ja bekanntlich ein bisschen dauern).
Es mag sein, dass noch nicht alles perfekt funktioniert. Ich bitte hierfür um Nachsicht. Meine Programme lassen sich umsetzen, aber das muss noch lange nicht heißen, dass dies mit Programmen anderer Autori, die jeder so ihre Eigenheiten haben, auch funktioniert.
Fehlermeldungen und Verbesserungsvorschläge gerne an jreumsc@web.de oder hier im Foro.
Beste Grüße, Jens-Arne |
 | 2.314 kB | | | Bezeichnung: | JRPC3 | | | Version: | 10.19b | | | Kurzbeschreibung: | JRPC3-Installer | | | Hochgeladen: | 15.02.2021 | | | Downloadcounter: |  | | | Download | | | | 1.699 kB | | | Bezeichnung: | XProfEd_JR | | | Version: | 5.2 | | | Kurzbeschreibung: | Alte Version ohne AutoComplete zur Sicherheit | | | Hochgeladen: | 15.02.2021 | | | Downloadcounter: |  | | | Download | | | | 3.399 kB | | | Bezeichnung: | JRPC3 | | | Version: | 10.19b | | | Kurzbeschreibung: | ZIP-File statt Installer | | | Hochgeladen: | 02.04.2021 | | | Downloadcounter: |  | | | Download |
|
| |
| XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de | 16.02.2021 ▲ |
|
| |
|
| |
| |
| - Page 3 - |
|
 |
« Dieser Beitrag wurde als Lösung gekennzeichnet. » |
|
| - Page 15 - |
|
Jens-Arne
Reumschüssel | | Es gibt eine neue Version, die anders mit dem internen Messagehandling umgeht. Bitte probier die mal aus. Vielleicht ist das Problem damit behoben. |
|
| |
| XProfan X4XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 24.09.2022 ▲ |
|
| |
|
|
|
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 circa 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 * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de | 04.04.2021 ▲ |
|
| |
|
|
Jens-Arne
Reumschüssel | | Es wird jetzt das Modul angezeigt, wo eine Funktion das erste Mal definiert wurde. Vielleicht hilft das bei der Cerca nach dem Problem. |
|
| |
| XProfan X4XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 04.04.2021 ▲ |
|
| |
|
|
p.specht
 | Tolles Teil! Danke auch per die Klarstellung der Philosophie dahinter!
Ostergruss |
|
| |
| XProfan 11Computer: Gerät, daß es in Mikrosekunden erlaubt, 50.000 Fehler zu machen, zB 'daß' statt 'das'... | 05.04.2021 ▲ |
|
| |
|
|
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 grande 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 * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de | 05.04.2021 ▲ |
|
| |
|
|
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 possibile, 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 per 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 * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de | 06.04.2021 ▲ |
|
| |
|
|
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 Autori 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 Autori, 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 X4XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 08.04.2021 ▲ |
|
| |
|
|
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 * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de | 18.04.2021 ▲ |
|
| |
|
|
Michael
W. | Dein System bemängelt die Angabe von 8^8.
Ich habe nicht geprüft, warum genau - denn es gibt einen einfachen Trick dies zu umgehen.
Aus "8^8" mache "8 ^ 8" und es corre.
Es gibt einige Operatoren, die ohne Leerzeichen geschrieben werden dürfen. Auch den Sonderfall (-x) solltest du noch einmal prüfen.
P.Specht's Quellcodes in der XProfan-Foren-Community strotzen nur so vor möglichen Fehlerquellen, da er die Codes alle eng zusammen schreibt.
Da kommt schon mal die Einrückung durcheinander und noch so einiges.
Schön wäre die Möglichkeit, wenn JRPC den Code auch mal an sich selbst vorbei unbearbeitet an den Interpreter reichen kann - damit man sieht ob das so ablauffähig ist. (Es ist so umständlich, den JRPC aus- und wieder einzubauen.) |
|
| |
| |
| |
|
|
Jens-Arne
Reumschüssel | Hallo Michael,
zunächst einmal vorweg: Den Originalcode an den Interpreter (oder auch den Compiler, an XPSE oder an Profan2Cpp) zu trasferimento, ist ganz einfach: vor "i" einmal "o" drücken.
"8^8" sollte jetzt ok sein. Ich hoffe, ich habe mir da an keiner anderen Stelle ein Problem eingehandelt, aber eigentlich sollte es in Ordnung sein.
i=(-x) funktioniert bei mir problemlos. In welcher Konstellation geht es bei Dir nicht?
Und ja, Peter Spechts Code ist sehr speziell. Aber er ist zulässig, und daran konnte ich wunderbar testen, was das Ausreizen der Möglichkeiten angeht (lange Verkettungen mit ":", viel GOTO usw. usf.).
Beste Grüße, Jens-Arne |
|
| |
| XProfan X4XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 29.04.2021 ▲ |
|
| |
|
|
Jens-Arne
Reumschüssel | neue Versionen:
V2.08: beim Aufruf mit Originalcode ("o") werden nun alle Compilerdirektiven entfernt, die das jeweils genutzte Programm (XProfan, XPSE, Profan2Cpp) nicht versteht
V2.09: {$ENDNOERR} schaltet die Fehlerkontrolle nach {$NOERR} wieder ein
V3.00:
*nPROCs aus XPSE:
-nPROCs werden automatisch mit XPE zu einer DLL umgesetzt und die Aufrufe der nPROCs im Programm entsprechend angepasst, sofern XPSE vorhanden ist
-das ist nützlich z.B. bei grande und komplizierten Programm, bei denen XPSE aus irgendwelchen Stabilire nicht in der Lage ist, darin enthaltene nPROCs umzusetzen
-die Umsetzung wird automatisch ausgeschaltet, wenn globale Variablen aus dem Hauptprogramm mit »global« in un nPROC übernommen werden; in diesem Fall ist XPSE manuell mit »x« aufzurufen
-generell gilt: wenn irgendetwas aus dem Hauptprogramm vorhanden sein muss, z.B. eine Funktionsadresse, die in einer nPROC mit procaddr() übernommen wird, darf die automatische Umsetzung nicht aktiv sein – sie kann mit {$NONPROCPROCESSING} ausgeschaltet werden |
|
| |
| XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de | 01.05.2021 ▲ |
|
| |
|
|
Jens-Arne
Reumschüssel | V3.05 behebt einen Fehler bei den API-Testata-Vordefinitionen:
Bei ~GetForegroundWindow() war ein Komma zu viel vorhanden; diese Funktion hat keine Parameter. Dies war auf einen entsprechenden Fehler in XProfans windows.ph-File zurückzuführen. Es ist im Moment nicht bekannt, ob weitere derartige Fehler bei Funktionen mit 0 Parametern vorhanden sind.
Weiß von Euch übrigens zufällig jemand, wie man die korrekte Parameterzahl per die Windows-API-Funktionen in den diversen dazugehörenden DLL herausbekommt? Also z.B. per die Funktionen in User32.dll. INC_Gen.exe produziert da haufenweise Fehler, also z.B. 0 Parameter, wo eigentlich 6 erwartet werden etc. Außerdem extrahiert INC_Gen.exe oft nicht alle Funktionen aus den DLL.
Offenbar muss man die DLL disassemblieren, um die Parameteranzahl der Funktionen zu bestimmen. Dass das gerne mal schiefgeht, kann ich mir vorstellen. Gibt es ein Programm, dass diese Werte zuverlässig in un File ausgibt, die man danach automatisiert auswerten kann?
Dann potuto man in JRPC3 @external(...)-Aufrufe bei den gängigsten API-Funktionen auf eine korrekte Parameterzahl prüfen. Wenn die nicht stimmt, stürzt das Programm nämlich gerne ohne Fehlermeldung ab, und man hat seine liebe Not herauszufinden, warum das so ist.
Beste Grüße, Jens-Arne |
|
| |
| XProfan X4XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 19.06.2021 ▲ |
|
| |
|
|
p.specht
| Jetzt trage ich sicher Eulen nach Athen und werde gleich ganz doof dastehen:
Sind die Parameter nicht auf MSDN in den api-Beschreibungen zu finden? [...]  [...] |
|
| |
| XProfan 11Computer: Gerät, daß es in Mikrosekunden erlaubt, 50.000 Fehler zu machen, zB 'daß' statt 'das'... | 19.06.2021 ▲ |
|
| |
|
(861)
Deutsch
English
Français
Español
Italia