[Geany] Mac OSx Snow Leopard experience, 100% CPU load whenever build has been started !
Andrei Vishneuski
vish at xxxxx
Fri May 21 06:55:21 UTC 2010
On 05/21/2010 02:06 AM, Lex Trotman wrote:
>
>
> On 21 May 2010 02:49, Andrei Vishneuski <vish at gravitysoft.org
> <mailto:vish at gravitysoft.org>> wrote:
>
>
> On 20 mei 2010, at 12:48, Lex Trotman wrote:
>
>>
>>
>> On 20 May 2010 20:20, Andrei Vishneuski <vish at gravitysoft.org
>> <mailto:vish at gravitysoft.org>> wrote:
>>
>>
>> On 20 mei 2010, at 11:42, Lex Trotman wrote:
>>
>>>
>>>
>>> On 20 May 2010 19:28, Andrei Vishneuski
>>> <vish at gravitysoft.org <mailto:vish at gravitysoft.org>> wrote:
>>>
>>>
>>> On 19 mei 2010, at 22:34, Enrico Tröger wrote:
>>>
>>> > On Tue, 18 May 2010 21:40:03 +0200, Andrei wrote:
>>> >
>>> >> On 05/18/2010 01:31 PM, Andrei Vishneuski wrote:
>>> >>>
>>> >>>
>>> >>> On 18 mei 2010, at 13:22, Lex Trotman wrote:
>>> >>>
>>> >>>>
>>> >>>>
>>> >>>> On 18 May 2010 20:37, Andrei Vishneuski
>>> <vish at gravitysoft.org <mailto:vish at gravitysoft.org>
>>> >>>> <mailto:vish at gravitysoft.org
>>> <mailto:vish at gravitysoft.org>>> wrote:
>>> >>>>
>>> >>>> I am big fun of Geany and have used it in
>>> Windows and Linux as
>>> >>>> my primary development editor.
>>> >>>> The problem is usage of Geany under Mac OSx.
>>> >>>> Basically under Mac osx you have three options:
>>> >>>>
>>> >>>> 1) Install port and install geany through the
>>> port. This is the
>>> >>>> most simple way. Geany looks a little bit ugly
>>> but workable
>>> >>>> and fast. 2) Deploy native Mac OSx GTK (see
>>> gtk-osx). More
>>> >>>> complicated way to use Geany. Geany looks more
>>> integrated with Mac
>>> >>>> OSx, but it is SLOW !
>>> >>>> 3) Use virtual (Linux) machine. Not a graceful
>>> way but better
>>> >>>> than nothing.
>>> >>>>
>>> >>>> I have tried all three options. And
>>> unfortunately only third
>>> >>>> option is applicable.
>>> >>>>
>>> >>>> Options 1) and 2) has critical bug. If you try
>>> to build
>>> >>>> something geany starts consuming 100% CPU time !
>>> >>>> It seems there is something wrong with process
>>> output reading,
>>> >>>> geany cannot correctly finalize it and stuck
>>> somewhere in
>>> >>>> reading loop.
>>> >>>>
>>> >>>> Does anybody have the same experience and may be
>>> just by chance
>>> >>>> has found a workaround ?
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> Which versions of Geany and Glib and GTK?
>>> >>>>
>>> >>> Geany 0.18.1
>>> >>> 1) Mac OSx port GTK2 2.18.2
>>> >>> 2) native gtk-osx GTK2 don't know exact version they
>>> are supporting
>>> >>> (have to see my home PC to give you more information)
>>> >>
>>> >> I little bit more about gtk-osx version: geany 0.18.1
>>> (built on May
>>> >> 18 2010 with GTK 2.18.2, GLib 2.22.2)
>>> >> Geany and gtk-osx has been compiled as i386
>>> applications since 64bits
>>> >> version of gtk-osx is no stable yet.
>>> >>
>>> >> PS: frankly speaking I think it is not GTK related
>>> bug, since I have
>>> >
>>> > It doesn't need to be a GTK/GLib bug but maybe we just
>>> use it wrong or
>>> > it behaves differently on MacOSX or MacOSX behaves
>>> differently than
>>> > Linux/Unix. I can't say what's wrong and I don't have
>>> access to a
>>> > MacOSX system :(.
>>>
>>>
>>> Could you give me a brief use case how the build feature
>>> works (several general steps) and point the file
>>> where I can find code responsible for it. May be I will
>>> try to take a look at the
>>> problem closer (cannot guarantee since I have not used
>>> C/C++ for ages :)). As far as I can see practically
>>> everything works:
>>> it executes appropriate tool for compilation, gets
>>> output from the tool, parses output and makes parsed
>>> results visible in compile
>>> window. But after that geany CPU load is 100%.
>>>
>>>
>>> Oh, the load remains 100% forever after??? Do you get a
>>> success message in the status bar?
>>>
>>> Can you try the nightly build version but configure the
>>> "build" to run a shell script that just does a delay so you
>>> can check if the load starts before the end of the build or
>>> after completion.
>>>
>>>
>>>
>>> I have tried geany night build and geany 0.17. They have
>>> the same problem.
>>>
>>>
>>> Ok, thanks, 0.17 lets out new build bits I added :-) but
>>> we've still got to fix the problem :-(
>>>
>>>
>>> PS: Buy the way, several days ago VirtualBox 3.2 has
>>> been released. One of the very interested
>>> feature is support for Mac OSx. That means it is
>>> possible to install original Mac OSx from
>>> original oficial DVD. It could be a good way to test
>>> geany for this platform.
>>>
>>>
>>> If one has a DVD, doesn't a Mac come from a place with
>>> golden arches?? Thats how much I know about them I'm afraid.
>>
>> The problem with Mac OSx is mac hardware uses more modern PC
>> (EFI instead of BIOS) architecture and of course it is impossible
>> just to take official Mac OSx DVD and install it on any PC
>> even if the hardware has identical CPU/GPU/etc. And reverse:
>> it is
>> impossible to install Linux/Windows on mac hardware as is,
>> without special boot loaders that emulates BIOS existence.
>>
>> There are several unofficial projects that modify (hack)
>> original DVD (most of them add special boot loader which
>> makes Mac OSx feels like
>> it starts on PC with EFI). What Virtual Box does it has
>> started supporting the modern PC architecture and as result
>> you can take original Mac OSx
>> (as far as I know it possible to buy Snow Leopard legally in
>> apple store) and install it as virtual machine. Of course,
>> there are still several
>> problems, your hardware (CPU/GPU/etc) should be compatible
>> with what Mac OSx can support.
>>
>>
>> AFAIK none of the Geany developers uses Macs so there is no
>> reason for anyone to spend money do it.
>>
>> But if you can help we are happy to provide all the guidance we
>> can if you can contribute by looking at the problem.
>>
>> If you get a chance to look at when the 100% starts would be good.
>>
>> As I said in a post a couple back to Enrico (I see I didn't
>> clearly indicate I was talking to him, oops sorry) if the problem
>> can't be definitely found, another option is to try the way
>> builds are run on Windows, where they are synchronous and
>> different methods are used to interface to the subprocess. So
>> all is not lost yet.
>>
>> To answer your question about where to look, all is in build.c,
>> you will see that there are #ifdefs that separate the windows and
>> unix code, look at the section headed "execute commands and
>> handle results" and the whole process starts at
>> build_spawn_command(). If you can use a debugger to find what
>> loop its stuck in maybe we can narrow it down. I would assume
>> its in the GTK event/monitor loop, otherwise the application
>> wouldn't continue to work, possibly the monitor of the subprocess
>> pipe isn't terminating right and GTK keeps calling it with no
>> characters??
>>
>> Cheers
>> Lex
>
>
> The only thing I can say right now is "build_iofunc()" executed
> infinitely, the function always returns TRUE (that is the reason
> why it is never terminated, I think).
> Will see why ii is always true ...
>
>
> 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".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/users/attachments/20100521/f2aadbc1/attachment.html>
More information about the Users
mailing list