Steht auch mit in der Liste der fehlenden Funktionen.
Warte ich auch schon gefühlt ‚ewig‘ drauf
Gerade wenn ein Nutzer ein Problem hat, ist das sehr hilfreich.
Aktuell habe ich in meinen umgeschrieben Delphi-Module entsprechend 100 aus kommentierte Zeilen oder eine Dummy-Funktion.
Michael
Aktuell nur Windows, ja.
Erweiterung manuell rein kopieren.
Ob du die INI noch immer anpassen musst, glaube nicht.
IPS lädt wohl alles was es findet
Michael
Leider funktioniert xdebug (hier 2.4.0 für php5.6 VC11TS) auch unter Windows (akt. 4.0 Release) nicht. Wenn ich die xdebug Extension ins ext-Verzeichnis werfe, wird sie nur als normale extension, aber nicht als Zend Extension geladen. Dafür wird sie mit PHP-Info auch brav angezeigt. Ändere ich es manuell in der php.Ini auf zend_extension, startet IPS auch, aber dann steht es doppelt in der php.ini und beim Aufruf des Scriptes mit phpinfo stürzt IPS kommentarlos ab.
Gibt es noch was anderes zu konfigurieren ?
Eine Debugging-Möglichkeit für PHP-Scripte und Module wäre aber seeeehr hilfreich. Ich suche mir gerade bei einem Problem den Wolf.
Ich war so dreist und habe die dll einfach mal in das Symcon-root geworfen anstatt in den ext-Ordner.
Dann wird sie auch als zend-ext geladen (nach manuellen ändern der php.ini).
Dafür bekomme ich den remote-dbg nicht zum laufen
Habe aber gerade auch keine Zeit zu suchen. Aber geil wäre das schon
OK, das kannte ich in der Tat noch nicht.
Aber bist Du sicher, das phpdbg auch für das IPS PHP geht? Ich habe auch noch nichts gefunden, wie man eine IDE daran connected.
To install phpdbg, you must compile the source against your PHP installation sources, and enable the SAPI with the configure command.
Wir können ja nicht auf Deine PHP Sourcen zugreifen? Dann könnten wir ja auch die fehlenden Linux Extensions selber bauen.
Also xdebug läuft bei mir jetzt. Nur wenn sich xdebug jetzt mit Netbeans verbinden soll passiert nix.
Ich sehe auch keinen offenen Port 9000 auf den sich xdebug verbinden will.
Das andere Beispiel mit Notepad++ funktioniert auch nicht. Irgendwas ist da noch falsch bei mir.
Michael
Dazu noch die entsprechenden Mappings für das modules und das scripts-Verzeichnis in der Entwicklungsumgebung anlegen und dort den IDE-Key entsprechend setzen
Host und Port beziehen sich auf die IDE, denn das PHP connected sich zur IDE und nicht umgekehrt. Die Pfade müssen natürlich auch ggfls. angepasst werden.
Beim Aufruf eines Scriptes oder Modules sollte nun der Debugger anspringen, wenn er aktiviert ist und ein Break existiert.
Und genau das funktioniert bei mir nicht… muss ich aber noch mal suchen.
Ok, mein idekey steht noch auf default, aber das ist auch der einzige Unterschied
Tja, so richtig geht das mit Xdebug doch nicht. Unter Windows hat das mir den Rechner lahm gelegt, weil es über die Zeit alle Handles verbraucht hat. Das Erreichen das Breakpoints war auch nicht in allen Phasen eines Modulserfolgreich. Es hat zwar die IDE connected, aber keinen Break angezeigt. .
Schade.
Da ich aktuell auf VS Code gewechselt bin, habe ich das Thema eben auch noch mal aufgegriffen.
Grundsätzlich geht alles mit VS Code und der PHP xDebug Erweiterung + xdebug.dll.
Durch die DLL natürlich nur unter Windows.
Ich kann mich auch verbinden und der gesamte IPS-Start funktioniert perfekt inkl. aller Fehler / Breakpoints usw…
Aber im laufenden Betrieb schmiert mir zuverlässig IPS, die Konsole oder die xDebug-Erweiterung in VS-Code ab
Ich sehe aber auch in der Liste der Threads in VS-Code das mein Testsystem dort massiv Scripte durchjagt.
Eventuell auch einfach ein Performance Problem.
Am Wochende teste ich das mit einem leeren Symcon. Mal schauen ob es dann benutzbar ist.
Jetzt wäre es cool wenn alle Daten noch im Symcon Verzeichniss lägen, und man den Dienst auch in der Konsole starten könnte.
Dann könnte man pro Modul ein Testsystem haben
Michael
What we should have said is „no, use xdebug“: xdebug is mature software, full of features, with excellent remote capabilities.
Xdebug scheint also der richtige Pfad zu sein. Wäre IP-Symcon open source gäbe es sicherlich keine Probleme…
Nun gut, vielleicht gibt es trotzdem einen Weg? @paresy?
Ein irgendwie funktionierendes Debugging wäre absolut wünschenswert für das ganze Modul-Ökosystem auch mit eurer Hoffnung (aus den Youtube Videos) dass ihr Bug-Reports mit einem fehlschlagendem Test bekommt…