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 ...