On 21 May 2010 19:30, Andrei Vishneuski vish@gravitysoft.org wrote:
On 21 mei 2010, at 11:07, Lex Trotman wrote:
On 21 May 2010 16:55, Andrei Vishneuski vish@gravitysoft.org wrote:
On 05/21/2010 02:06 AM, Lex Trotman wrote:
On 21 May 2010 02:49, Andrei Vishneuski vish@gravitysoft.org wrote: Ok, thats where I thought it would be, I'm not sure why, maybe its GTK2.18 or OSX pipes but whatever, can you try the attached patch that tries to pick up more conditions to stop.
Debugging indicated that the section below starts getting condition = G_IO_IN forever, but "g_io_channel_read_line" can read nothing. I have tried to use additional reading method like read_char, read_to_the_end. I have tried to flush pipe. None of it helped. The result workaround I have used shown below:
if (cond & (G_IO_IN | G_IO_PRI)) { gchar *msg;
int count = 0;while (g_io_channel_read_line(ioc, &msg, NULL, NULL, NULL) && msg) { gint color = (GPOINTER_TO_INT(data)) ? COLOR_DARK_RED : COLOR_BLACK;
process_build_output_line(msg, color); g_free(msg);count++}
if (count == 0) return FALSE;}
It works, but doesn't give an answer why pipe says "there is still something to read in the pipe".
Hmmmmm....
Did you have a chance to test the patch that checks the return from g_io_channel_read_line?
Cheers Lex
No I have not tried it yet (read it this morning). I will try it today to see may be G_IO_STATUS_ xXX can be used as an indicator to compete pipe input handling.
Ok, good luck!!
Cheers Lex
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany