Debuggen von Konsolenprogramme

[mschnell]

Hi,

Ich meine, so etwas wäre hier schonmal diskutiert worden, ich finde die Lösung aber nicht in den alten Foren-Beiträgen.

Wie kann ich de "Writeln()" Output eines Konsolen-Programmes sehen, wenn ich den Lazarus-Debugger verwende (Ich erinnere mich, das bei einer uralten Lazarus-Version dieses Fenster immer geöffnet wurde, die neue tut das nicht mehr.)

Ich kann den Output im "Debugger"-Fenster sehen, aber nicht realtime, sondern erst erst, wenn das Programm angehalten hat und gemischt mit diversen Outputs des gdb. Das ist gar nicht praktisch .

-Michael

[theo]

Ja, Konsolenprogramme mit Lazarus debuggen ist anerkannter Käse.
Alles was mir dazu einfällt, ist ein Flush zu machen, wenn du das Debuggerausgaben Fenster updaten willst.

Writeln('test');
Flush(StdOut); //Aus dem Gedächtnis

[mse]

Das ist gar nicht praktisch

Nimm MSEide?
Meines Wissens gibt es da zwei Probleme. Unter Windows werden pipes beim writeln von FPC nicht geflushed, wie Theo schrieb braucht's dann ein flush(output) um die Resultate in einem mittels pipes verbundenen Fenster zu sehen oder beim filehandler muss eine procedure umgesetzt werden. Die Details sind mir im Moment nicht mehr präsent, für entsprechende Änderungsvorschläge meinerseits hatte das FPC-Team kein Gehör.
Unter Windows kann aber das System-Konsolen-Fenster verwendet werden, dort wird output bei jedem writeln geflushed. Unter Linux kann ein Pseudo-Terminal zur Trennung von gdb und target output und zum forcieren des flush verwendet werden (MSEide macht das mit dem 'Targetconsole'-Fenster). Für Lazarus wurde ein entsprechender Patch noch nicht appliziert AFAIK.

[theo]

Nimm MSEide?

Ich sag's ja wirklich nicht gerne, aber in diesem - und nur in diesem - Falle hat Herr Schreiber unter Umständen, eventuell, möglicherweise afaik, afair, imho, damit vielleicht sogar recht.

[mschnell]

Unter Linux kann ein Pseudo-Terminal zur Trennung von gdb und target output und zum forcieren des flush verwendet werden (MSEide macht das mit dem 'Targetconsole'-Fenster). Für Lazarus wurde ein entsprechender Patch noch nicht appliziert AFAIK.

Wenn Du mir aus Deiner mse-ide - Erfahrung sagen kannst, wie das gehen könnte, versuche ich mich vielleicht daran...

-Michael

[mschnell]

Ja, Konsolenprogramme mit Lazarus debuggen ist anerkannter Käse.

Offensichtlich !!!
Erinnere ich mich denn wirklich falsch, dass eine ganz alte Lazarus-Version bei jedem Debuggen ein Konsolen-Fenster aufgemacht hat und man mit writeln() darauf schreiben konnte ?

Gruß,
-Michael

[theo]

Erinnere ich mich denn wirklich falsch, dass eine ganz alte Lazarus-Version bei jedem Debuggen ein Konsolen-Fenster aufgemacht hat und man mit writeln() darauf schreiben konnte ?

Das weiss ich nicht. Ich kann mir aber nicht vorstellen, dass das jemals im Zusammenspiel mit GDB zufälligerweise funktioniert hat, und jetzt plötzlich nicht mehr und keiner weiss warum.
Früher war alles besser, jedenfalls in der Erinnerung.

[mse]

Wenn Du mir aus Deiner mse-ide - Erfahrung sagen kannst, wie das gehen könnte, versuche ich mich vielleicht daran...

Zuerst habe ich den Spott und danach auch noch die Arbeit?

[mschnell]

Zuerst habe ich den Spott

Aber nicht von mir !

und danach auch noch die Arbeit?

Das Los der Wissenden Die beste Lösung jedes einzelnen Teil-Aspekts sollte bei Bedarf verfügbar sein
-Michael

[theo]

Zuerst habe ich den Spott

Aber nicht von mir !

Von mir auch nicht. Ich habe mse ja sogar recht gegeben (Schwersten Herzens versteht sich)

[marcov]

Das ist gar nicht praktisch

Meines Wissens gibt es da zwei Probleme. Unter Windows werden pipes beim writeln von FPC nicht geflushed, wie Theo schrieb braucht's dann ein flush(output) um die Resultate in einem mittels pipes verbundenen Fenster zu sehen oder beim filehandler muss eine procedure umgesetzt werden.

Alle Text I/O mit writeln ist immer gepuffert. Unter TP, FPC und Delphi, mit mindestens 128 byte puffer. Aber ein settextbuffer(f,0); kontte auch helfen?

[shokwave]

Offensichtlich !!!
Erinnere ich mich denn wirklich falsch, dass eine ganz alte Lazarus-Version bei jedem Debuggen ein Konsolen-Fenster aufgemacht hat und man mit writeln() darauf schreiben konnte ?

Das einzige was mir dazu einfällt, wäre der Haken bei Win32-GUI-Anwendung in den Compilereinstellungen. Wenn Haken raus, dann Konsole an. Muß man nur genug Breakpoints setzten und von Breakpoint zu Breakpoint mit F9 hüpfen.

[mschnell]

Alle Text I/O mit writeln ist immer gepuffert. Unter TP, FPC und Delphi, mit mindestens 128 byte puffer. Aber ein settextbuffer(f,0); kontte auch helfen?

Das wäre zum Debuggen sicher vorteilhaft.

Darüber hinaus wäre es aber sehr wünschenswert, wenn man optional ein Fenster aktivieren könnte, in das der writeln() Output getrennt vom gdb Output geschrieben wird. MSEIDE macht das wunderschön (Ich würde das für Linux brauchen).

Wie könnte man das machen ?

-Michael

[shokwave]

Unter Start/Startparameter gibts noch "Startprogramm verwenden". Wenn Haken rein, dann Xterm an.
Hoffe das hilft dir weiter.

[mse]

Alle Text I/O mit writeln ist immer gepuffert. Unter TP, FPC und Delphi, mit mindestens 128 byte puffer. Aber ein settextbuffer(f,0); kontte auch helfen?

Liefert Do_Isdevice() true, wird bei writeln geflushed, sonst nicht. Unter Linux kann durch Verwendung eines Pseudoterminals geflushter Betrieb erreicht werden, unter Windows geht das nur mittels des System-Konsolen-Fensters, nicht hinter einer Pipe. Früher (FPC <= 1.8?) lieferte Do_Isdevice() for stdio immer true. Mein Vorschlag war, unter Windows auch bei Pipes true zu liefern. Nun kommt mir auch wieder in den Sinn, wie das flushen im Programm ein- und ausgeschaltet werden kann:

Code: Alles auswählen

textrec(output).flushfunc:= textrec(output).inoutfunc; //flush ein
 textrec(output).flushfunc:= nil;                       //flush aus