| |
|
|
- Seite 1 - |
|
![Jens-Arne Reumschüssel: 16.02.2021](.././../../i/a/171494484748f1e66bd153d.jpg) 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 *direkte Anzeige des Programmablaufes in XProfEd (sofern der unten erhältliche aufgebohrte XProfEd verwendet wird) *Umsetzung der alten Profan-Syntax für Operatoren und alte Containerfunktionen *extrem schnelle native fbPROCs, sofern man FreeBasic installiert hat (kostenlos, siehe Hilfe) *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 über @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 DLLs 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 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 zur Beschleunigung mit hoher Prozessorpriorität aufgerufen werden *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) - Achtung, die 64-bit-Version erzeugt natürlich keine 64-bit-XProfan-Programme, da XProfan das nicht kann, sondern JRPC3 selbst wird als 64-bit-Programm ausgeführt *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 *Interpreter, PRCs, EXEs und XPSE können mit Administratorrechten ausgeführt werden *Prozeduren, die in dem aktuellen Programm zwar enthalten sind, aber nicht verwendet werden, werden aus der umgesetzten Datei entfernt, um die Dateigröße des Kompilats möglichst klein zu halten *Variablen, die in dem aktuellen Programm zwar enthalten sind, aber nicht verwendet werden, werden aus der umgesetzten Datei entfernt, um die Dateigröße des Kompilats möglichst 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 verfügbar 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 ü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. 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 Hilfe --> Hilfedatei anzeigen oder mit F1 verfügbar ist.
----- /Features
Herunterladen und installieren: JRPC3 kann unten heruntergeladen werden (setup_jrpc3.exe oder als ZIP-Datei). Als Installationsverzeichnis bitte das XProfan-Stammverzeichnis angeben, also dasjenige, in dem die Dateien PROFAN.EXE, PROFCOMP.EXE, PRFRUN32.EXE etc. liegen. Alternativ kann die ZIP-Datei 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 anzeigen 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 großen 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 Autoren, die jeder so ihre Eigenheiten haben, auch funktioniert.
Fehlermeldungen und Verbesserungsvorschläge gerne an jreumsc@web.de oder hier im Forum.
Beste Grüße, Jens-Arne |
![](/intl/i/dw.gif) | 2.583 kB | | Bezeichnung: | JRPC3 | | Version: | 10.27 | | Kurzbeschreibung: | JRPC3-Installer | | Hochgeladen: | 15.02.2021 | | Ladeanzahl: | ![Abruf-Service Ladezählerbild 346](https://xprofan.net/i/coeco.gif) | | | Herunterladen | | | | 1.699 kB | | Bezeichnung: | XProfEd_JR | | Version: | 5.2 | | Kurzbeschreibung: | Alte Version ohne AutoComplete zur Sicherheit | | Hochgeladen: | 15.02.2021 | | Ladeanzahl: | ![Abruf-Service Ladezählerbild 216](https://xprofan.net/i/uoeco.gif) | | | Herunterladen | | | | 3.765 kB | | Bezeichnung: | JRPC3 | | Version: | 10.27 | | Kurzbeschreibung: | ZIP-Datei statt Installer | | Hochgeladen: | 02.04.2021 | | Ladeanzahl: | ![Abruf-Service Ladezählerbild 285](https://xprofan.net/i/canvo.gif) | | | Herunterladen |
|
|
| XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 16.02.2021 ▲ |
|
|
|
| |
|
- Seite 17 - |
|
![](.././../../i/hr.gif) |
« Dieser Beitrag wurde als Lösung gekennzeichnet. » |
|
- Seite 15 - |
|
![Jens-Arne Reumschüssel: 24.09.2022](.././../../i/a/171494484748f1e66bd153d.jpg) 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 ▲ |
|
|
![](.././../../i/hr.gif) |
|
|
![RudiB.: 29.09.2022](.././../../i/a/2208.gif) RudiB. | Übrigens, Freebasic ist selbst beim verarbeiten von String-Funktion ca. 35x schneller als XProfan. Das hätte ich nicht gedacht, dafür ist aber Freebasic lange nicht so komfortabel bei der Programmierung.
Gruß aus München |
|
|
| |
|
|
|
![RudiB.: 29.09.2022](.././../../i/a/2208.gif) RudiB. | Ja, Dein Beispiel funktioniert.... |
|
|
| |
|
|
|
![Jens-Arne Reumschüssel: 30.09.2022](.././../../i/a/171494484748f1e66bd153d.jpg) Jens-Arne Reumschüssel | Ich kann nicht bestätigen, dass FreeBasic-Stringfunktionen schneller wären als XProfan-Stringfunktionen, jedenfalls nicht für @upper$:
declare i%,tc&,s$
fbPROC fbupper(ByRef s As ZString) As Integer Export s=ucase(s) return 0 ENDPROC
cls
tc&=&GetTickCount for i%,1,10000 s$="asdjhaskdjhaskjdhkajshdkjhaksjdhkjahö+12" s$=@upper$(s$) endfor print "@upper$: "+@str$(&GetTickCount-tc&)
tc&=&GetTickCount for i%,1,10000 s$="asdjhaskdjhaskjdhkajshdkjhaksjdhkjahö+12" @fbupper(@addr(s$)) endfor print "@fbupper: "+@str$(&GetTickCount-tc&)
waitinput end
FreeBasic ist deutlich langsamer, und zwar obwohl der Funktionsaufruf von JRPC3 über call realisiert wird und nicht über external, und obwohl für die FreeBasic-Routine nicht einmal neuer Speicherplatz reserviert werden muss, wie es für @upper$ der Fall ist (weil dort s$ neu zugewiesen wird). |
|
|
| XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 30.09.2022 ▲ |
|
|
|
|
![RudiB.: 01.10.2022](.././../../i/a/2208.gif) RudiB. | dann teste mal so.....
sogar schneller mit Upper-Case und Lower-Case.... |
|
|
| |
|
|
|
![RudiB.: 01.10.2022](.././../../i/a/2208.gif) RudiB. | oder so, mit gleichen Voraussetzungen (jeweils eine Procedure aufrufen)
hier ist der Vorteil zwar nicht mehr ganz so groß, aber trotzdem schneller |
|
|
| Xprofan X4 Rudolf Beske / München
Hardware: NB Intel I9 - 16GByte RAM | 01.10.2022 ▲ |
|
|
|
|
![Jens-Arne Reumschüssel: 01.10.2022](.././../../i/a/171494484748f1e66bd153d.jpg) Jens-Arne Reumschüssel | Hallo Rudi,
darüber hatte ich auch schon nachgedacht. Offenbar ist der Aufruf einer Prozedur mit so viel Registergeschiebe u.ä. verbunden, dass das ganz schön lange dauert. In der Praxis lohnt es daher nicht, eine FB-Funktion für die Stringfunktionen zu schreiben, die man dann im Profan-Programm nutzen würde. Aber innerhalb einer fbProc kann man den Geschwindigkeitsvorteil, der offenbar doch existiert, natürlich ausspielen.
Gruß, Jens-Arne |
|
|
| XProfan X4XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 01.10.2022 ▲ |
|
|
|
|
![RudiB.: 01.10.2022](.././../../i/a/2208.gif) RudiB. | Du sprichst gerade die FB-Funktionen an. Warum wird die eigentlich nicht von JRPC3 erkannt, hast Du das nicht implementiert ? |
|
|
| |
|
|
|
![Jens-Arne Reumschüssel: 01.10.2022](.././../../i/a/171494484748f1e66bd153d.jpg) Jens-Arne Reumschüssel | Ich meinte damit FreeBasic-Procs (fbProcs). Die werden doch hoffentlich von JRPC3 erkannt. Ich habe darauf angespielt, dass offenbar jedweder Funktionsaufruf mit sehr viel Overhead geschieht, der Zeit kostet. Ansonsten verstehe ich die Frage nicht ganz, erläutere mir sie bitte noch einmal (hast Du mit "FB-Funktion" etwas anderes gemeint als ich?).
Und unser kleines Beispiel habe ich noch einmal etwas verfeinert. Denn um wirklich Gerechtigkeit herzustellen, muss auch die Profan-Funktion mit call aufgerufen werden und außerdem einen Parameter haben (auch wenn der vorliegend nichts tut):
declare i%,tc&,s$,funcaddr%
fbPROC fbupper(ByRef s As ZString) As Integer Export s=ucase(s) return 0 ENDPROC
PROC upper parameters dummy% s$=@upper$(s$) ENDPROC
cls funcaddr%=@procaddr("upper",1)
tc&:=&GetTickCount for i%,1,10000 s$:="asdjhaskdjhaskjdhkajshdkjhaksjdhkjahö+12" call(funcaddr%,@addr(s$)) endfor print "@upper$: "+@str$(&GetTickCount-tc&)
tc&:=&GetTickCount for i%,1,10000 s$:="asdjhaskdjhaskjdhkajshdkjhaksjdhkjahö+12" @fbupper(@addr(s$)) endfor print "@fbupper: "+@str$(&GetTickCount-tc&)
waitinput end
Jetzt sind beide Varianten fast gleich schnell (kompiliert) mit immer noch einem kleinen Vorteil bei FreeBasic. |
|
|
| XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 01.10.2022 ▲ |
|
|
|
|
![RudiB.: 01.10.2022](.././../../i/a/2208.gif) RudiB. | Hallo Jens-Arne,
....alles gut. Die fbProcs werden natürlich sauber erkannt und verarbeitet. Ich meinte Freebasic-Funktionen. Habe doch dazu die Datei "datei_fb_test.prf" hochgeladen. Diese hast Du dann auch umgeschrieben zu einer fbProc. Wie gesagt unter Freebasic gibst ja Sub´s und Funktionen.... |
|
|
| |
|
|
|
![Jens-Arne Reumschüssel: 01.10.2022](.././../../i/a/171494484748f1e66bd153d.jpg) Jens-Arne Reumschüssel | Man kann schlicht nicht direkt in FreeBasic programmieren, also auch nicht direkt Funktionen von dort aufrufen, weil der Profan-Compiler diese Funktionen nicht direkt in sein Programm einbauen kann. Um sie zu nutzen, muss immer eine DLL erzeugt werden, in der naturgemäß Funktionen (Procs) stehen, die man dann von außen aufrufen kann, um den darin enthaltenen nativen FreeBasic-Code zu nutzen. Das geht nicht ohne den Umweg über eine DLL-Funktion. Das macht auch der XProfan-Inline-Assembler so, der XPSE-Inline-Assembler und XPSE-nPROCs ebenfalls.
EDIT: Vielleicht noch einmal anders herum erklärt: Um FreeBasic-Code zu erzeugen, muss der FreeBasic-Compiler verwendet werden. Das geht natürlich nicht "plötzlich" innerhalb eines Profan-Programms. Durch die Nutzung von DLL-Funktionen ist der FreeBasic-Code hingegen derart abgegrenzt, dass der FreeBasic-Compiler das vorgesetzt bekommt, was für ihn gedacht ist, und der Profan-Compiler seinen Anteil. |
|
|
| XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 01.10.2022 ▲ |
|
|
|
|
![RudiB.: 01.10.2022](.././../../i/a/2208.gif) RudiB. | Hallo Jens-Arne,
Danke für Deine Antwort......verstehe....man kann das ganze ja auch mit Sub´s lösen. Aber gut zu wissen. Ich möchte mein Programm jetzt mit fbProcs optimieren, da es mir einfach zu langsam ist.....
Gruß Rudi |
|
|
| |
|
|
|
![Jens-Arne Reumschüssel: 01.10.2022](.././../../i/a/171494484748f1e66bd153d.jpg) Jens-Arne Reumschüssel | Genau dafür sind fbProcs da. Das lohnt sich aber nur bei Programmpassagen, die viel rechnen oder ganz oft aufgerufen werden, etwa in einer großen Schleife. Z.B. ist es eine extrem gute Idee, die Subclassproc nach FreeBasic zu verlagern, wenn die länger als ein paar Zeilen ist. Wenn man darin bspw. OwnerDraw-Elemente versorgt, dann ist das in Profan oft zu langsam. Ein Beispiel dafür wären farbige Elemente in Gridboxen. |
|
|
| XProfan X4XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 01.10.2022 ▲ |
|
|
|