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 ?
On 18 May 2010 20:37, Andrei Vishneuski vish@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:
- 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?
Cheers Lex
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 18 mei 2010, at 13:22, Lex Trotman wrote:
On 18 May 2010 20:37, Andrei Vishneuski vish@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:
- Install port and install geany through the port. This is the most simple way. Geany looks a little bit ugly but workable and fast.
- 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 !
- 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)
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@gravitysoft.org mailto:vish@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
- Mac OSx port GTK2 2.18.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 tried geany with two different approaches implementing GTK (native and ported).
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@gravitysoft.org mailto:vish@gravitysoft.org> wrote:
I am big fun of Geany and have used it in Windows and Linux asmy 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 workableand 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 inreading 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
- Mac OSx port GTK2 2.18.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 :(.
Regards, Enrico
2010/5/20 Enrico Tröger enrico.troeger@uvena.de
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@gravitysoft.org mailto:vish@gravitysoft.org> wrote:
I am big fun of Geany and have used it in Windows and Linux asmy 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 workableand 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 inreading 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
- Mac OSx port GTK2 2.18.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 :(.
Regards, Enrico
Couple of thoughts, do we know those exact versions of GTK/Glib work on Linux? That would reduce the risk of it being a GTK/Glib bug.
Can OSX use the dozewin method of synchronous builds instead, ie how much Win specific stuff is in that path? That removes the possibility of an unconstrained loop in the monitor code, the most likely place IMHO.
Cheers Lex
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Thu, 20 May 2010 07:44:13 +1000, Lex wrote:
Can OSX use the dozewin method of synchronous builds instead, ie how much Win specific stuff is in that path? That removes the possibility of an unconstrained loop in the monitor code, the most likely place IMHO.
Luckily, the question doesn't matter anymore since you solved the Mac OSX problem the better way :). The synchronous builds on Windows are only a workaround, not a solution.
Regards, Enrico
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@gravitysoft.org mailto:vish@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:
- 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
- Mac OSx port GTK2 2.18.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%.
I have tried geany night build and geany 0.17. They have the same 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.
On 20 May 2010 19:28, Andrei Vishneuski vish@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@gravitysoft.org mailto:vish@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:
- 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
- Mac OSx port GTK2 2.18.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.
Personally I havn't got windows build capability either, I just havn't had the chance to set it up.
Cheers Lex
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 20 mei 2010, at 11:42, Lex Trotman wrote:
On 20 May 2010 19:28, Andrei Vishneuski vish@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@gravitysoft.org mailto:vish@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:
- 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
- Mac OSx port GTK2 2.18.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.
On 20 May 2010 20:20, Andrei Vishneuski vish@gravitysoft.org wrote:
On 20 mei 2010, at 11:42, Lex Trotman wrote:
On 20 May 2010 19:28, Andrei Vishneuski vish@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@gravitysoft.org mailto:vish@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:
- 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
- Mac OSx port GTK2 2.18.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
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 20 mei 2010, at 12:48, Lex Trotman wrote:
On 20 May 2010 20:20, Andrei Vishneuski vish@gravitysoft.org wrote:
On 20 mei 2010, at 11:42, Lex Trotman wrote:
On 20 May 2010 19:28, Andrei Vishneuski vish@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@gravitysoft.org mailto:vish@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:
- 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
- Mac OSx port GTK2 2.18.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
Thank you for provided information. At least I will try to find the issue, nevertheless I have deal with C/C++ approx. 10 years ago :)
On 05/20/2010 03:48 AM, Lex Trotman wrote:
[snip]
AFAIK none of the Geany developers uses Macs so there is no reason for anyone to spend money do it.
I'm just a Geany hacker (not so much a developer :P) but I experimented with porting Geany to OS X some years ago. I use OS X as my comfort-zone at home, even. (Ubuntu at work, of course!) The good thing about buying OS X, if any developers/hackers wanted to try it out under VirtualBox, it only costs $30 USD from the Apple Store [1].
[1] http://store.apple.com/us/product/MC573Z/A?fnode=MTY1NDAzOA&mco=MTc1MTEz...
On 20 mei 2010, at 12:48, Lex Trotman wrote:
On 20 May 2010 20:20, Andrei Vishneuski vish@gravitysoft.org wrote:
On 20 mei 2010, at 11:42, Lex Trotman wrote:
On 20 May 2010 19:28, Andrei Vishneuski vish@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@gravitysoft.org mailto:vish@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:
- 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
- Mac OSx port GTK2 2.18.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 ...
On 21 May 2010 02:49, Andrei Vishneuski vish@gravitysoft.org wrote:
On 20 mei 2010, at 12:48, Lex Trotman wrote:
On 20 May 2010 20:20, Andrei Vishneuski vish@gravitysoft.org wrote:
On 20 mei 2010, at 11:42, Lex Trotman wrote:
On 20 May 2010 19:28, Andrei Vishneuski vish@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@gravitysoft.org > mailto:vish@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
- Mac OSx port GTK2 2.18.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.
Cheers Lex
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 05/21/2010 02:06 AM, Lex Trotman wrote:
On 21 May 2010 02:49, Andrei Vishneuski <vish@gravitysoft.org mailto:vish@gravitysoft.org> wrote:
On 20 mei 2010, at 12:48, Lex Trotman wrote:On 20 May 2010 20:20, Andrei Vishneuski <vish@gravitysoft.org <mailto:vish@gravitysoft.org>> wrote: On 20 mei 2010, at 11:42, Lex Trotman wrote:On 20 May 2010 19:28, Andrei Vishneuski <vish@gravitysoft.org <mailto:vish@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@gravitysoft.org <mailto:vish@gravitysoft.org> >>>> <mailto:vish@gravitysoft.org <mailto:vish@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 LexThe 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".
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:
On 20 mei 2010, at 12:48, Lex Trotman wrote:
On 20 May 2010 20:20, Andrei Vishneuski vish@gravitysoft.org wrote:
On 20 mei 2010, at 11:42, Lex Trotman wrote:
On 20 May 2010 19:28, Andrei Vishneuski vish@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@gravitysoft.org >> mailto:vish@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".
Hmmmmm....
Did you have a chance to test the patch that checks the return from g_io_channel_read_line?
Cheers Lex
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
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.
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
On 21 mei 2010, at 11:37, Lex Trotman wrote:
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!!
I have tried your solution. It works. "g_io_channel_read_line" method returns G_IO_STATUS_EOF as status what can be successfully used as condition to leave watcher function.
Thank you !
On Fri, 21 May 2010 16:59:10 +0200, Andrei wrote:
On 21 mei 2010, at 11:37, Lex Trotman wrote:
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!!
I have tried your solution. It works. "g_io_channel_read_line" method returns G_IO_STATUS_EOF as status what can be successfully used as condition to leave watcher function.
Great. Thanks Andrei and Lex for tracking this down. Lex, feel free to commit your patch otherwise tell me.
Regards, Enrico
2010/5/23 Enrico Tröger enrico.troeger@uvena.de:
On Fri, 21 May 2010 16:59:10 +0200, Andrei wrote:
On 21 mei 2010, at 11:37, Lex Trotman wrote:
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!!
I have tried your solution. It works. "g_io_channel_read_line" method returns G_IO_STATUS_EOF as status what can be successfully used as condition to leave watcher function.
Great. Thanks Andrei and Lex for tracking this down. Lex, feel free to commit your patch otherwise tell me.
Done.
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Thu, 20 May 2010 20:48:52 +1000, Lex wrote:
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
I felt addressed :). Just didn't have time to answer, sorry.
Regards, Enrico
Andrei Vishneuski wrote:
Snip ...
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.
I don't think this (OSx guest in Vbox) would be useful for testing Geany. According to the Vbox web site:
"New Mac OS X – On Apple hardware only, support for creating virtual machines running Mac OS X."
Unless I'm missing something.
Bob S.
Nope. You can do hackintosh stuff to get it to run on windows host, I've heard-guessed but so far as I know you need a MacOSX host. Also, the $30 disc is just a upgrade (unless they've changed it recently). Yes you can install from the disc, but you are cheating more or less.
On 5/20/2010 10:16 PM, Bob Snyder wrote:
Andrei Vishneuski wrote:
Snip ...
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.
I don't think this (OSx guest in Vbox) would be useful for testing Geany. According to the Vbox web site:
"New Mac OS X – On Apple hardware only, support for creating virtual machines running Mac OS X."
Unless I'm missing something.
Bob S.
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 05/21/2010 05:16 AM, Bob Snyder wrote:
Andrei Vishneuski wrote:
Snip ...
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.
I don't think this (OSx guest in Vbox) would be useful for testing Geany. According to the Vbox web site:
"New Mac OS X – On Apple hardware only, support for creating virtual machines running Mac OS X."
Unless I'm missing something.
Bob S.
Yes, agree, have not noticed the comment May next release of VB allows to do it everywhere.