On 21 May 2010 19:30, Andrei Vishneuski <[email protected]> wrote:
> > On 21 mei 2010, at 11:07, Lex Trotman wrote: > > > > On 21 May 2010 16:55, Andrei Vishneuski <[email protected]> wrote: > >> On 05/21/2010 02:06 AM, Lex Trotman wrote: >> >> >> >> On 21 May 2010 02:49, Andrei Vishneuski <[email protected]> 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 > [email protected] > http://lists.uvena.de/cgi-bin/mailman/listinfo/geany > >
_______________________________________________ Geany mailing list [email protected] http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
