PaxCompiler

[backdraft]

Hallo zusammen,

weiss schon jemand, was aus dem PaxCompiler geworden ist.
Wir sollen ein Projekt zukünftig pflegen, wo dieser im Einsatz ist, bzw. ob da noch was raus wird?

Leider haben wir keine Lizenz dafür, und müssten uns so eine sicherlich zulegen.
Ggf. verkauft auch jemand seine Lizenz (sofern das überhaupt erlaubt ist).

Grüße
Oliver

[himitsu]

Vor 2 Jahren wurden die Rechte am PaxCompiler an Apex Data Solutions verkauft.
Da kannst wohl nur mal bei deren Support anfragen, was damit los ist. (auf die Schnelle nichts auf der Webseite zu gefunden)


Alternativ: es gibt auch andere Pascal-Script-Compiler/Intepreter

[backdraft]

Ja, das habe ich auch schon rausgefunden.
Auch dass das Produkt als Apex Athena angepriesen wird.
https://apexdatasolutions.com/techno...2/apex-athena/
Aber von kaufen steht da nix.

[jaenicke]

Das wird es vermutlich mittlerweile geben. Ich hatte davon auch mal eine Beta, die aber leider nicht funktionierte. Eine Rückmeldung zu dem Bug habe ich nie bekommen.

Aber bei den aufgerufenen Preisen würde ich die auch nicht auf die Webseite stellen. Spoiler: Der PaxCompiler war dagegen ein Schnäppchen, zumindest als ich damals das letzte Mal Kontakt hatte.

Leider gibt es keine gleichwertige Skripting-Lösung. dwscript kommt noch am nächsten heran.

[himitsu]

Als "offene" Lösung wäre der Windows-Scripting-Host eine Idee.

Standardmäßig sind VBScript, JavaScript und PowerShell da drin,
aber auch Python und auch mehrere PascalSciptingEngines ließen sich dort registrieren.


Klar, Intepreter sind meistens bissl langsamer, als die kompilierte VersionVariante (Script nach ByteCode übersetz und das dann ausgeführt),
aber wenn es nur darum geht "irgendwelche" Scripte zur Laufzeit auszuführen, wäre es ja fast egal, was man nun nimmt.

Der WSH hätte den Vorteil, dass man im Programm nur eine Schnittstelle hat und unterschiedlichste Scripte ausführen kann.
Beispiel dieser Lösung siehe FinalBuilder, welcher das für sein Scrippting benutzt.



Wir nutzen aktuell Python4Delphi mit der EmbeddedVersion der Python-DLL (im Programmverzeichnis mitgegeben).
Aber jetzt komplett auf eine andere ScriptSprache umzustellen wäre wohl noch etwas mehr Aufwand, als nur diesen PascalCompiler durch einen anderen PascalCompiler oder -Interpreter zu ersetzen.

[jaenicke]

PaxCompiler hatte den Riesenvorteil, dass man einfach Interfaces in Units packen konnte, die dann sowohl in die Exe einkompiliert als auch mit der Skriptlösung mitgeliefert werden können. PaxCompiler konnte die Units dann einfach direkt kompilieren und die Referenzen auf die Interfaces konnten dann in beide Richtungen über eine mit Generics ausgestattete Schnittstelle weitergegeben werden. Die entsprechenden Objekte konnten also sowohl mit dem PaxCompiler kompiliert werden als auch aus der Exe stammen.

Eine so tolle Integration bietet leider keine andere Lösung soweit ich weiß.

[himitsu]

Bei Python als Embedded können auch Variablen, Funktionen und Objekte von Delphi im Script genutzt werden.

Im Programm kompiliert und registriert, im Script benutzt
und Variablen, sogar mit sowas wie einem Setter/Getter, vom Script aus abgerufen oder zugewiesen und im Programm live eine Reaktion,

Sowie Variablen vorher oder hinterher, also vor oder nach dem/den Script(en), im Programm setzen und auslesen, welche im Script gelesen/verändert werden können.




Über die Python.exe, also via Stdin und Stdout, geht natürlich nicht so viel, aber die DLL im Programm geladen, kannschon recht viel.
Aber ja, Pascal als Script wäre für Pascal-/Delphi-Entwickler natürlich viel cooler/schöner/geiler/intuitiver/.....

[backdraft]

Zitat:

Zitat von jaenicke (Beitrag 1491389)

Das wird es vermutlich mittlerweile geben. Ich hatte davon auch mal eine Beta, die aber leider nicht funktionierte. Eine Rückmeldung zu dem Bug habe ich nie bekommen.

Aber bei den aufgerufenen Preisen würde ich die auch nicht auf die Webseite stellen. Spoiler: Der PaxCompiler war dagegen ein Schnäppchen, zumindest als ich damals das letzte Mal Kontakt hatte.

Leider gibt es keine gleichwertige Skripting-Lösung. dwscript kommt noch am nächsten heran.

Eine Rückmeldung für meine Kaufanfrage hatte ich bisher auch nicht bekommen.
Keine Ahnung, ob da jemand am anderen Ende lauscht.

Es steht aber auch erstmal nicht zur Diskussion alles umzubauen, nur weil der Compiler teurer jetzt ist.
Der Mehraufwand alles umzustellen rechnet sich nicht wirklich, denke ich.

Vielleicht will ja auch jemand seine Lizenz loswerden.

[jaenicke]

Vielleicht bekommst du zu Alexander Baranovsky Kontakt. Der hatte damals immer relativ schnell geantwortet:
https://www.linkedin.com/in/alexanderbaranovsky/
Da im Profil immer noch drin steht, dass er dort arbeitet...

Ich habe damals auch immer nur von ihm Antwort bekommen, nicht von Apex.

Da die damalige Mailadresse öffentlich auf der Webseite stand und auch über das Webarchiv jederzeit gefunden werden kann, poste ich sie einfach mal:
paxscript @ gmail.com

[backdraft]

Zitat:

Zitat von jaenicke (Beitrag 1491410)

Vielleicht bekommst du zu Alexander Baranovsky Kontakt. Der hatte damals immer relativ schnell geantwortet:
https://www.linkedin.com/in/alexanderbaranovsky/
Da im Profil immer noch drin steht, dass er dort arbeitet...

Ich habe damals auch immer nur von ihm Antwort bekommen, nicht von Apex.

Da die damalige Mailadresse öffentlich auf der Webseite stand und auch über das Webarchiv jederzeit gefunden werden kann, poste ich sie einfach mal:
paxscript @ gmail.com

Ja top, hab ich direkt mal gemacht.
Vielen Dank ...

[dummzeuch]

Zitat:

Zitat von jaenicke (Beitrag 1491406)

PaxCompiler hatte den Riesenvorteil, dass man einfach Interfaces in Units packen konnte, die dann sowohl in die Exe einkompiliert als auch mit der Skriptlösung mitgeliefert werden können. PaxCompiler konnte die Units dann einfach direkt kompilieren und die Referenzen auf die Interfaces konnten dann in beide Richtungen über eine mit Generics ausgestattete Schnittstelle weitergegeben werden. Die entsprechenden Objekte konnten also sowohl mit dem PaxCompiler kompiliert werden als auch aus der Exe stammen.

Eine so tolle Integration bietet leider keine andere Lösung soweit ich weiß.

Ich kenne den Pax-Compiler zwar nicht, deshalb kann ich das nicht wirklich beurteilen, aber die Scripting-Engine von FastReport kann auch ziemlich eng mit einem Delphi-Executable verzahnt werden. Die erstellt allerdings nur Bytecode und keine eigentständigen Executables. Je nach Anwendungsfall könnte das aber ein guter Ersatz sein, insbesondere, wenn man FastReport bereits verwendet.

[jaenicke]

Zitat:

Zitat von dummzeuch (Beitrag 1491420)

Ich kenne den Pax-Compiler zwar nicht, deshalb kann ich das nicht wirklich beurteilen, aber die Scripting-Engine von FastReport kann auch ziemlich eng mit einem Delphi-Executable verzahnt werden.

Die hatten wir damals auch angeschaut, aber im Vergleich fühlt sich die wie ein Trabbi im Vergleich zu einem Ferrari an...
Die ist nicht schlecht, kann aber auch wenig.

Zitat:

Zitat von dummzeuch (Beitrag 1491420)

Die erstellt allerdings nur Bytecode und keine eigentständigen Executables.

Das wäre mir zumindest egal.

[Jens01]

Wie ich das verstanden habe, arbeitet Alexander Baranovsky für diese Firma. Der Mann muß wohl aus Donezk kommen. (Die Umstände sind bekannt.) Zu der Zeit hat sich das mit dem Paxcompiler geändert.

Den Paxcompiler fand ich anfangs sehr gut, weil er insbesondere bei Berechnungen viel schneller war als die einfachen Parser. Ich hatte dann aber ein Speicherproblem, welches ich nicht zuordnen konnte. Nachdem ich den Paxcompiler ausgebaut habe, war das weg.

[jaenicke]

Zitat:

Zitat von Jens01 (Beitrag 1491433)

Wie ich das verstanden habe, arbeitet Alexander Baranovsky für diese Firma.

Er hat den PaxCompiler entwickelt und dann wohl an Apex verkauft und ist selbst auch dort hin gegangen.

Zitat:

Zitat von Jens01 (Beitrag 1491433)

Den Paxcompiler fand ich anfangs sehr gut, weil er insbesondere bei Berechnungen viel schneller war als die einfachen Parser. Ich hatte dann aber ein Speicherproblem, welches ich nicht zuordnen konnte. Nachdem ich den Paxcompiler ausgebaut habe, war das weg.

Ja, wir hatten damit auch Fehler, haben diese aber untersucht, gemeldet und Bugfixes bekommen. Die aktuellste Version lief soweit recht stabil. Was dann noch an Bugs auftrat, konnte ich selbst beheben. Ja, das waren auch Speicherprobleme, die sich in Schutzverletzungen äußerten. Eine Analyse des Arbeitsspeichers konnte diese Bugs aber eingrenzen. Nur einer blieb am Ende übrig, bei dem ich nicht weiter gekommen war.
Angesichts der Funktionalität, die es eben sonst nirgends gab, konnten wir damals erst einmal damit leben.

Dass sich das dann so entwickelt und nun gar nichts mehr kommt, war ja nicht abzusehen.

[Jens01]

Zitat:

... nun gar nichts mehr kommt, war ja nicht abzusehen.

Irgendwie hatte ich das geahnt. Weil der PaxCompiler bei mir ein wichtiger Bestandteil geworden wäre und das ganze damals schon undurchsichtig war, hatte ich mal geguckt (wie man das im Internet so legal macht), wer er herkommt.
Ich glaube, ihm ist dort die Lebensstabilität abhanden gekommen. Deswegen wird das so gelaufen sein.

[backdraft]

Leider bin ich bei meinem Problem mit der fehlenden PaxCompiler Lizenz immer noch nicht weiter gekommen.
Es antwortet keiner auf meine E-Mails.
Vom Nachfolgeprodukt hört man auch nichts mehr.

Seit längerem kommt auf der Webseite auch nur noch ein Fehler, dass die Seite nicht mehr existiert.
https://www.apexdatasolutions.net/
Habe gerade nochmal probiert. Passiert nix.

Hat vielleicht mittlerweile jemand eine Lizenz, die er nicht mehr weiterhin verwenden möchte, und uns verkaufen kann?

[jaenicke]

Die Reviews sind bezeichnend:
https://www.indeed.com/cmp/Apex-Data...f05d1f6a7a94cd

Alle Hinweise auf die Projekte Athena usw. sind auch von der Webseite verschwunden. Ich glaube nicht, dass da noch etwas kommt.

Leider wirft die Firma offenbar mehr mit Marketing-Worten als mit echten Informationen zum Stand usw. und Taten um sich, auch jetzt noch, nur in Bezug auf andere Themen...

Angesichts dessen, dass das Projekt damals nicht fehlerfrei war, es keine Updates mehr geben wird, und der Quelltext nicht so einfach ist, kann ich nicht dazu raten neue Projekte damit anzufangen, selbst wenn man eine Lizenz bekommt. Leider.

[backdraft]

Zitat:

Zitat von jaenicke (Beitrag 1501648)

Die Reviews sind bezeichnend:
Angesichts dessen, dass das Projekt damals nicht fehlerfrei war, es keine Updates mehr geben wird, und der Quelltext nicht so einfach ist, kann ich nicht dazu raten neue Projekte damit anzufangen, selbst wenn man eine Lizenz bekommt. Leider.

Na es geht ja darum, ein vorhandes Projekt auf eine neuere Delphi Version zu portieren.
Da ist es sicherlich einfacher, einfach das vorhandene so zu belassen.
Ich habe ja eine relativ aktuelle Version im Quellcode, aber die gehört halt nicht uns.

Ich hatte mich mal mit ein paar anderen Engines rumgetestet, die wir auch als gekaufte Komponenten haben.
Dabei waren TMS, FastReports, LMD und Greatis.

Problematisch war immer, dass man kein "array of const" als Parameter an eine Funktion übergeben kann, zumindest habe ich es nicht hinbekommen.

Welche Alternativen habe ich denn?

[himitsu]

Konnten die Anderen denn ein

Delphi-Quellcode:

array of Variant

?

Das ließe sich dann ja zum Großteil recht leicht konvertieren. (bzw. eine Funktion schreiben, welche

Delphi-Quellcode:

array of const

annimmt und TArray<Variant> rausgibt)

[Jens01]

Also ich hab ne Lizenz von 2013 bei shareit. Kann man die übertragen?
"paxCompiler sources. Single developer license"

...hab gerade geguckt, ein Weinterverkauf müßte möglich sein.

[backdraft]

Zitat:

Zitat von Jens01 (Beitrag 1501661)

Also ich hab ne Lizenz von 2013 bei shareit. Kann man die übertragen?
"paxCompiler sources. Single developer license"

...hab gerade geguckt, ein Weinterverkauf müßte möglich sein.

Hab die eine Nachricht geschickt.

[backdraft]

Hat vielleicht auch noch jemand die PaxCompilerImporter Sources?
Der Link von damals ist in Wayback Maschine nicht gespeichert.
http://web.archive.org/web/201712170...mpiler.com:80/

[jaenicke]

Die Quelltexte waren da soweit ich mich erinnere nicht dabei. Es wurde nur der Importer als Exe mit ein paar Demos usw. geliefert.

[Jens01]

Hier gibts den noch aber ohne Sources:
https://torry.net/pages.php?id=59&sort=title

@backdraft
Hab auf Mail geantwortet