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