XPSE

Klar wärs schön, wenn da ein Helferlein alle unsere Fehler finden würde.
Ich finde aber, daß der magere Syntaxcheck ein Fehler vom XProfan und nicht vom XPSE ist. Aber warten wir ab, was David uns noch per Goodies einbaut, die Roland übersehen hat - ist doch erst Version 0.14 vom XPSE...

Christian

XProfan 8/9.1, Win XP, AMD 64/3200

01.05.2005 ▲

Der Aktuelle machts - ist noch inner Probe - next Rel. beachtet auch sowas.

Mit einfach nur XProfan Keywords kennen ists net getan - gibt ja auch Procs und Defs etc...

Salve.

Möchte aber nochwas dazu sagen - die Formulierung nicht mal ist etwas unglücklich getroffen.

Die Wirklichkeit sieht so aus - XPSE macht eine Vielzahl von Überprüfungen welche syntaktische Fehler erkennen. Das bloße Keyworderkennen ist da fast Nebensache.

XPSE geht nicht Wort-per-Wort vor - um Fehler aufzuspühren - nein xpse corre ganz anders. Ich versuche es mal zu erklären:

XPSE nimmt den Source in seinen Speicher auf - zerstückelt diesen in ihn bekannte Bruchteile und komprimiert den Source damit auf ein Minimum.

Über das sich nun im Speicher befindliche Komprimat werden verschiedene Filter gejagt. Diese glätten den Source und machen, wenn ein Fehler im Source ist, ein Rückkomprimieren nicht possibile.

Die Rückkomprimierung kann also nur erfolgen - wenn nach Glättung des Komprimates der Source noch schlüssig ist. So erkennt der XPSE Fehler.

Anders also als gewöhnliche Syntaxchecker - viel ausbaufähiger und härter - und ebend hintenrum.

Dieses Verfahren - so ekelig es auch zu programmieren ist - bringt aber essentielle Vorteile mitsich.

Z.B. kann ich damit den XPSE später in die Lage versetzen - sogar unlogiken zu erkennen - indem bestimmte Schlüsselroutinen sich nicht zu 100% wegkomprimieren lassen. (Jaja ich weiß - 100% - aber ich hoffe man versteht so ungefähr was ich meine).

Die bloße Keyworderkennung ist keine algo-Sache - sondern simples Vergleichen - nix was XPSE bisher tat. Mein aktuellstes Release (noch unveröffentlicht wg. Testing) überprüft nun auch Schreibfehler.

Hier werden Variablen, Prozeduren, XProfanbefehle, und Defs und Konstanten beachtet. Hierbei jedoch ists dem XPSE dann aber vorläufig auch noch egal - ob ein Schlüsselwort richtig deklariert wurde. Es wird vorab nur erstmal geschaut ob ein Schlüsselwort überhaupt definiert wurde - oder ob ein Tipp-/ Schreibfehler vorliegt.

Leider macht das den XPSE deutlich langsammer - ich nenne es intern den ThirdPass. Auf meinem Rechner braucht er mit diesem Thirdpass ca. 2,7 statt 1,1 per 10000 Zeilen. Der XProfancompiler jedoch necessario zum Vergleich per das Compilieren dieser 10000 Zeilen 40 Sekunden.

Würde XPSE jetzt auch noch die PRC erzeugen - bräuchte er mit allem drum und dran was er eh schon tut nur 4 statt 40 Sekunden zum Compilieren.

Mal mit Roland reden...^^

Salve.

Nachtrag: Dann bräuchte keiner mehr den Interpretermodus - denn auf Knopfdruck die PRC-Starten...

Salve.

Dietmar
Horn

Hallo David,

sorry, ich wollte doch damit weder Dich persönlich, noch Deinen genialen XPSE angreifen! Das sollte lediglich ein ganz, ganz winziger Hinweis von einem noch viel, viel winzigeren, klitzekleinen Mini-Hörnchen an upper$(iF-xpse) sein - nicht mehr und nicht weniger! Bei solch schnellen Postings von lower$(Hörnchen) zwischendurch sollte man wirklich nicht gleich jedes Wort auf die Goldwaage legen ...

Die beschriebenen und geplanten XPSE-Funktionen finde ich jedenfalls prima! Wenn es wirklich irgendwann mal ein PRF-Tool gäbe, welches die gängigsten Syntax-Fehler anmeckert, wäre das schon nicht schlecht bzw. eigentlich schon längst überfällig. In anderen Programmiersprachen ist das doch seit Jahren bzw. von Anfang an fest eingebaut. Ich kann es einfach nicht glauben, daß es soviel Mehraufwand bedeuten soll, dem PRF-Interpreter und dem PRF-Compiler einen weitestgehend identischen Syntax-Check zu verpassen (bzw. vorzuschalten). Erst mal ganz unabhängig davon, wie gut oder wie weniger gründlich dieses Teil anfangs wirklich seinen Job verrichten würde - wichtig wäre doch erst mal wenigstens mindestens ein 100%-ig identisches Verhalten bzw. Handeln dieser beiden Kollegen (Interpreter und Compiler)! Notfalls potuto man ja zeitaufwändigere Prüfungen optional ab- oder zuschaltbar machen, so daß man diese nur bei Bedarf verwendet (wenn man selber beim Testen unerklärliche Fehlfunktionen feststellt, oder nur mal gelegentlich zwischendurch laufen läßt).

Einen Anregung per den XPSE-Syntax-Check hätte ich noch: Du solltest unbedingt dem Progger ermöglichen, sich selber eine Art Black-List per Befehle anzulegen bzw. zu erweitern, die XPSE einfach überspringt. Derzeitig magst Du vielleicht noch täglich 26 - 28 Stunden Zeit haben, Dich um XPSE kümmern und oft im Stundentakt UpDates herausbringen zu können. Doch auszuschließen ist es nicht, daß Du irgendwann zukünftig die Schwerpunkte in Deinem beruflichen oder personale Umfeld anders setzen möchtest, oder mußt - oder? Den ProfanInspektor von Sebastian kann man deswegen z.B. schon seit Monaten nicht mehr sinnvoll einsetzen, weil er die neuen 9.0-er Befehle ja nicht kennen kann. Mit Prf2Cpp potrebbe es seitdem ähnliche Probleme geben.

Mit XPSE nur im Compilermodus zu arbeiten, das macht bei größeren Projekten derzeitig keinen Sinn, weil hierbei der PRF-Compiler ständig auf der Bremse steht.

Wegen der PRC-Erzeugung durch XPSE solltest Du meiner Meinung nach im Interesse aller (X)Profaner unbedingt weiterhin auf eine erfolgreiche Zusammenarbeit mit Roland hinwirken. In diesem Punkt wäre es allerhöchste Zeit, daß sich da grundlegend etwas ändert. Denn wenn ich z.B. zum Compilieren eines Projektes mit knapp 100000 Codezeilen aktuell um die 10 Minuten benötige, dann motiviert mich das derzeitig nicht gerade dazu (auch nicht mit vorangeschalteter XPSE-Code-Optimierung) grundsätzlich bei jedem Testlauf den xprofanischen PRC-Modus zu nutzen. Auch dann nicht, wenn Roland die Ausführungsgeschwindigkeit des Compilierens durch irgendwelche interne Optimierungen von heute auf morgen vielleicht sogar um 50% reduzieren würde.

Saluto
Dietmar

Multimedia für Jugendliche und junge Erwachsene - MMJ Hoyerswerda e.V. [...]

Windows 95 bis Windows 7
Profan² 6.6 bis XProfan X2 mit XPSE

Das große XProfan-Lehrbuch: [...]

Ist ja wirklich interessant! Da halten sich Leute selbst per Anfänger, obwohl sie realistisch betrachtet längst keine mehr sind, bloß weil sie mit Profan programmieren! Auch wenn Profan per Einsteiger, Anfänger, ja sogar Kinder geeignet ist, è das doch lange nicht, daß man nicht auch wirklich Großes damit vollbringen kann!

Der Übergang vom Anfänger zum Fortgeschrittenen hin zum Profi ist nun mal ein Fließender und jemand, der mit APIs um sich wirft, daß andere uns darum beneiden, kann mir nicht weismachen, daß er Anfänger ist. (Entschuldige Andreas, in dem Punkt stimme ich Dir wirklich nicht zu)
Das ist doch so beim Programmieren - und das machts ja so spannend: Wir ALLE lernen ununterbrochen dazu!
Aber das Ganze beweist mir, daß Profan noch in etlichen Punkten verbessert gehört. (Ganz was Neues ..

)

Dazu gehört nun mal ein eigener Editor mit Syntaxcheck bereits während der Eingabe, um so kleine Flüchtigkeitsfehler nicht erst nach einer Ewigkeit des Compilierens festzustellen.

Dazu gehört auch, daß der Interpreter KEIN Mißinterpreter ist.

Dazu gehört genauso, daß Io l' Code Prozedur- und zeilenweise überprüfen und jederzeit auch den Inhalt der Variablen checken kann, was derzeit nur eingeschränkt und circa Umwege possibile ist.

Ein schneller Compiler
Ich kann mir gut vorstellen, daß Dietmar bei der Fehlersuche manchmal am Verzweifeln ist, wenn der Interpreter keinen Fehler meldet und der Compiler erst nach 10 Minuten.

Es sollte doch überhaupt nicht notwendig sein, daß ich bis zu 4 (!) verschiedene Editoren im Einsatz haben muß - jeden per einen bestimmten Zweck und einer spezifischen Stärke, dafür wieder Schwächen auf anderen Gebieten.
Den XProfan-Writer, der eng mit Profan zusammenarbeitet, aber eine saumäßige Suchen-Ersetzen-Funktion hat, seit Jahren nicht mehr wirklich weiterentwickelt wurde und auch sonst noch ein paar Macken hat.
Textpad: Guter Editor mit guter Ersetzen-Funktion, aber die von ConText ist noch raffinierter! Außerdem taugt mir der vom Handling her besser (tut leid, David

)
Bei komplexeren Ersetzen-Vorgängen - und davon habe ich derzeit eine Menge - greife ich aber immer noch zu Winword.

Bezüglich Prf2Cpp: Den habe ich gerne zum Syntax-Check herangezogen, aber der versteht leider die XPSE-Syntax nicht.

Sch...-Flickschusterei! Das gehört längst alles unter einen Hut gebracht!

Christian

XProfan 8/9.1, Win XP, AMD 64/3200

03.05.2005 ▲