Fragen zu Debug in PHP-Modulen

Welche Befehle muss man nutzen, damit im Debug-Tab des Moduls Ausgaben erscheinen?
Ich kenne zwar IPS_LogMessages, aber das schreibt nur ins Log.

Welche Möglichkeiten habe ich in IPS V4, von einer externen IDE (Eclipse, Idea, ZendStudio etc.) zu Debuggen? Kann man z.B Xdebug aktivieren

Tomnmi

Zur Zeit gibt es leider keinen Befehl um ins das eigentlich „Debug“ Fenster zu schreiben.

Ich habe xdebug noch nicht getestet… aber da eine PHP Extension ist, könnte es gut klappen.

paresy

Steht auch mit in der Liste der fehlenden Funktionen.
Warte ich auch schon gefühlt ‚ewig‘ drauf :wink:
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

OK, hört sich ja gut an. Wie kann ich xdebug einbinden? In welche PHP.INI.

Ich habe auch im Hinterkopf das z.B. auf dem Raspberry oder normalen Ubuntu normale Extensions dort nicht gehen sollen.

Tommi

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

Tommi

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 :frowning:
Habe aber gerade auch keine Zeit zu suchen. Aber geil wäre das schon :smiley:

Michael

Seit PHP 5.6 gibt es einen offiziellen Debugger… habt ihr den mal ausprobiert? phpdbg | php debugger

paresy

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.

Tommi

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

Ich habe es jetzt auch mit xdebug hinbekommen.
In der php.ini von IPS folgende Sektion hinzufügen:

[Xdebug]
zend_extension="C:\IP-Symcon\php_xdebug-2.4.0-5.6-vc11.dll"
xdebug.remote_enable=1
xdebug.remote_autostart=1
xdebug.remote_port=9000
xdebug.remote_host=127.0.0.1
xdebug.profiler_enable=1
xdebug.profiler_output_dir="C:\IP-Symcon	mp"
xdebug.idekey=IPS

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.

HTH
Tommi

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 :wink:

Wird wohl irgendwo an meiner IDE liegen.

Michael

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.

Tommi

Hallo zusammen.

Gibt es hierzu inzwischen eine Lösung? Es ist ja 2020 und ich hätte schon gerne beim Modul entwickeln breakpoints :slight_smile:

Auch wenn ich keine Erfahrung mit PHP habe … gäbe es in einem breakpoint eine REPL with z.B. in Python?

Grüße und danke,
elmcrest

Ist es nicht das, was man mit SendDebug macht? Oder hab ich die Frage falsch verstanden?


$this->SendDebug("Device", "variable STATE object id : ". $objectid, 0);

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 :frowning:

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 :slight_smile:
Michael

Hierzu ein Hinweis. Da die Originale Website nicht mehr existiert; hier ein Kommentar eines Entwicklers.
Is phpdbg dead? : PHP

Also für uns ‚normalos‘ ungeeignet.
Michael

Ok, aus dem Link

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…

Gesendet von iPhone mit Tapatalk

Ich habe gestern noch etwas gespielt.
Aber so ganz rund ist das noch nicht.

Dadurch daß er bei jeder Kleinigkeit stoppt, macht es nur Sinn mit einem blanko Symcon zu starten.
Michael

Sehr cool!

Ja, ok, aber zur modulentwicklung macht das ja sowieso sinn… also eine testbare umgebung ist ja eh möglichst frei von externen einflüssen.

Hast du zufällig den einen blogpost genutzt oder kannst du ne art anleitung zur verfügung stellen?

Gesendet von iPhone mit Tapatalk