Re: Anjuta2 -- problem importing Anjuta project files

[John Palmieri <johnp martianrock com>]

Hmm, I sort of fixed the problem but had some wierd debugging output
that did not match the GTK documentation. In the function read_output:

if (condition == G_IO_IN || condition == G_IO_PRI )

I added || TRUE to the statement to see what would happen if I executed
the code block without reading a condition of G_IO_IN or G_IO_PRI.  It
loaded my project flawlessly every time.  To see what condition it was
passing in I did a printf("CON: %i", condition); and also added a printf
for every enum in GIOCondition.  Here was the wierd output:

CON: 17
G_IO_IN 1, G_IO_OUT 4, G_IO_PRI 2, G_IO_ERR 8, G_IO_HUP 16, G_IO_NVAL 32

CON: 16
G_IO_IN 1, G_IO_OUT 4, G_IO_PRI 2, G_IO_ERR 8, G_IO_HUP 16, G_IO_NVAL 32


If you notice there is no condition 17 in GIOCondition.  This could be
an error in GLib.  

As for reading in projects the condition check seems unnesessary since
even if I choose a directory with no project the read will simply return
an EOF status and G_IO_HUP condition.  I don't know if this is correct
in the eyes of the GLib IO maintainer but it works.

--
J5

On Tue, 2002-10-08 at 19:52, Gustavo Giráldez wrote:
> Hey!
> 
> On Sun, 2002-10-06 at 13:08, Jeroen Zwartepoorte wrote:
> > On Sun, 2002-10-06 at 17:55, John Palmieri wrote:
> > > Hehe, well it is a major bug for me because it consistantly does not
> > > load my project though it does load Anjuta2 and gnome_build most of the
> > > time.  I've tracked down the problem to the "spawn_script" function in
> > > /gnome-build/src/backends/libgbf_am/gbf-am-project.c file.  It seems
> > > like it is not getting the output correctly from the script
> > > (data->output.length==0).  I can run gbf-am-parse -d --get
> > > /home/quinticent/Projects/project1 on the command line and it returns
> > > XML output that looks correct.  I'm going to keep hacking at it but I
> > > don't know how much futher I can get.  Perhaps this will help someone
> > > who is more familiar with the script spawning code and piped input.
> > 
> > Perhaps Gustavo can jump in and respond. He's the primary contributor of
> > the gbf-am-parse script and the spawn_script code.
> 
> Sorry for not replying before, but I've been busy with university work.
> 
> Could you both John and Jeroen try the attached patch to see if the
> problem is solved.  I have an idea of what could be causing the bug: if
> the machine is fast enough, maybe the script exits and the inner main
> loop which controls the pipes quits before data can be actually read.  I
> can't reproduce the problem here... probably because I'm on a k6-400 ;-)
> 
> Please let me know if this works or not.
> 
> Thanks,
> Gustavo
> 
> 
> _______________________________________________
> gnome-devtools mailing list
> gnome-devtools gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-devtools