Hi All,
The first alpha release of a version of Geany with flexible configuration of the Build Menu is available in the build-system branch of svn, https://geany.svn.sourceforge.net/svnroot/geany/branches/build-system/
This release is still under active development (see Known Bugs, Limits and Incomplete below) and is released to allow consideration of the functionality and how it might impact/assist other Geany activity.
Some of the highlights are: (see the Build Menu section in the manual for the gory details)
- Both build menu labels and commands are configurable - Configuration sourced from project if open, preferences, filetypes, defaults (in that order) - The maximum number of items in each section of the build menu is configurable - Unused items are hidden - New configuration dialog in the build menu (for preferences configuration source) and the project dialog (for project configuration source) - By default the build menu should operate the same as the old Geany. - New build configuration is in a new section in each config file and won't interact with settings used by older Geany versions, but will use the old settings if no new ones are available.
Examples of potential capabilities that need to be considered for Geany overall are: - Now that labels are configurable, should interpreted languages have the compile and build labels configured to something more appropriate - If so, labels read from the system filetypes.xxx files are locale sensitive iaw the GKeyFile specification, but how do the translations get made? - Can any languages benefit from extra or differing menu items?
Known Bugs, Limits and Incomplete (in no particular order) - Latex doesn't work yet, all the hard coded functionality has been removed but the filetype hasn't been updated to configure it back. - Only one execute command is currently supported/working - Dialog entries in preferences and project, for settings that are replaced by the new dialogs, have not been removed yet, but they probably do nothing - Error regex setting field in the new dialog does nothing yet - Not compiled at all on windows - Very limited testing so far (C/C++ filetypes only) - Sections of the manual other than build menu have not been changed, eg file formats, hidden settings any sections that reference build menu etc
Enjoy Lex
An extra Known Bug so Nick and Enciro don't beat me up
Source formatting and especially very long lines not yet fixed. (well they fit on my widescreen monitor)
Cheers Lex
Hi all,
A new version of the build-system branch is in svn.
Fixes many of the problems with loading, storing and selecting menu items by priority when changing filetypes.
I have added a routine to print the current menu items table each time a menu item is requested, first the current filetype is printed then the table. The table is printed by increasing priority across the line, each column has two lines for each menu item, the first is the label, the second is the command. There is a blank line between groups. The routine is enabled by setting PRINTBUILDCMDS to TRUE at compile time or setting printbuildcmds to 1 using a debugger. Be warned it makes lots of output but could be useful for debugging complex configurations.
Cheers Lex
PS A question for Enrico/Nick, I was using geany.html as a test file and I noticed that it is interpreted as XML and so doesn't have the ability to show it in a browser, I thought I had *another* bug :( until I noticed the filetype was wrong. Is this intentional or is there something subtle in the determination of the filetype?
On Sat, 11 Jul 2009 23:08:37 +1000, Lex wrote:
PS A question for Enrico/Nick, I was using geany.html as a test file and I noticed that it is interpreted as XML and so doesn't have the ability to show it in a browser, I thought I had *another* bug : ( until I noticed the filetype was wrong. Is this intentional or is there something subtle in the determination of the filetype?
It's a bug. Will fix that later.
Regards, Enrico
On Thu, 16 Jul 2009 18:05:04 +0200, Enrico wrote:
On Sat, 11 Jul 2009 23:08:37 +1000, Lex wrote:
PS A question for Enrico/Nick, I was using geany.html as a test file and I noticed that it is interpreted as XML and so doesn't have the ability to show it in a browser, I thought I had *another* bug : ( until I noticed the filetype was wrong. Is this intentional or is there something subtle in the determination of the filetype?
It's a bug. Will fix that later.
Fixed in SVN r3981. Good catch!
Regards, Enrico
On Thu, 9 Jul 2009 17:38:57 +1000, Lex wrote:
An extra Known Bug so Nick and Enciro don't beat me up
Source formatting and especially very long lines not yet fixed. (well they fit on my widescreen monitor)
A very few general notes:
- I think it'd better if you would format your code properly while writing. This is probably harder for you since you are not used to use our coding style but it would be easier for us to read and review the code and I think it would be easier than reformatting all at once when you are finished with your branch. But it's just a suggestion.
- you really should fix the compiler warnings, I get a whole bunch when compiling the code (see attachment). Most of them are harmless like unused variables but the more warnings you usually have, the bigger the danger is to overlook a real warning which you want to see
- the build settings dialog needs love. First, it needs some spacing between the GUI elements to match the other Geany dialogs look&feel and also to be more compliant with the Gnome HIG. But this is low priority and can be improved later as this is GUI stuff only.
- the build settings dialog looks already very big and a bit cluttered. Not yet sure whether we can improve this, will think about this a bit. But at least, please don't make it even bigger. Imagine you are a new user and just want to change the Run command, in the current dialog you first need to figure out which field does what and where the field is you actually want to edit. Don't get me wrong, it's pretty cool so far but maybe we can make it even cooler. And I'm not one of those Gnome guys who somtimes like hide/remove any option from the user. But there is also the other way to overload the GUI with useless stuff. And so, I'm just about to find a best way in between :).
Regards, Enrico
2009/7/17 Enrico Tröger enrico.troeger@uvena.de
On Thu, 9 Jul 2009 17:38:57 +1000, Lex wrote:
An extra Known Bug so Nick and Enciro don't beat me up
Source formatting and especially very long lines not yet fixed. (well they fit on my widescreen monitor)
A very few general notes:
- I think it'd better if you would format your code properly while
writing. This is probably harder for you since you are not used to use our coding style but it would be easier for us to read and review the code and I think it would be easier than reformatting all at once when you are finished with your branch. But it's just a suggestion.
Hopefully getting better :-) build.c should now be mostly matching the standard in Hacking I think. If not let me know.
- you really should fix the compiler warnings, I get a whole bunch when
compiling the code (see attachment). Most of them are harmless like unused variables but the more warnings you usually have, the bigger the danger is to overlook a real warning which you want to see
I don't get any of these, is there an option I need to give make or configure to make it picky???
Should be all fixed, but I can't actually check since I don't get them. BTW the filetypes one was useful, but most build ones were just annoying thankfully.
- the build settings dialog needs love. First, it needs some spacing
between the GUI elements to match the other Geany dialogs look&feel and also to be more compliant with the Gnome HIG. But this is low priority and can be improved later as this is GUI stuff only.
No problem, whats your standard spacing etc?
- the build settings dialog looks already very big and a bit cluttered.
Agree
Not yet sure whether we can improve this, will think about this a bit. But at least, please don't make it even bigger. Imagine you are a new user and just want to change the Run command, in the current dialog you first need to figure out which field does what and where the field is you actually want to edit. Don't get me wrong, it's pretty cool so far but maybe we can make it even cooler. And I'm not one of those Gnome guys who somtimes like hide/remove any option from the user. But there is also the other way to overload the GUI with useless stuff. And so, I'm just about to find a best way in between :).
I agree, its now the biggest dialog in Geany, its just that there is a certain amount of functionality to configure, any suggestions welcome, but I can't see a sensible way of dividing it up to make it smaller. At the moment it reflects the way the menu is laid out. I think its important to keep that relationship for easy use. Dividing it vertically doesn't really make sense either, label and command need to be together, and putting working dir on another tab or something is really messy because then I would be skipping back and forward to see which directories related to which commands. Maybe we *have* to be Gnomic and have the working dir column hidden unless the user selects to make it visible. As you say needs some thought.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 17 Jul 2009 10:03:15 +1000, Lex wrote:
- you really should fix the compiler warnings, I get a whole bunch
when compiling the code (see attachment). Most of them are harmless like unused variables but the more warnings you usually have, the bigger the danger is to overlook a real warning which you want to see
I don't get any of these, is there an option I need to give make or configure to make it picky???
Should be all fixed, but I can't actually check since I don't get them. BTW the filetypes one was useful, but most build ones were just annoying thankfully.
The most important flag is -Wall, this should be used generally I think. I personally use some more flags like (set before running ./configure resp. ./waf configure): export CFLAGS="-Wall -O0 -g -pipe -march=athlon64 \ -DGEANY_DEBUG \ -D_FORTIFY_SOURCE=2 \ -Waggregate-return \ -Wdeclaration-after-statement \ -Wdisabled-optimization \ -Wfloat-equal \ -Wformat-nonliteral \ -Wformat-security \ -Wformat=2 \ -Winit-self \ -Winline \ -Wmissing-field-initializers \ -Wmissing-include-dirs \ -Wmissing-noreturn \ -Wpointer-arith \ -Wshadow \ -Wsign-compare \ -fno-common \ -funit-at-a-time \ "
But this is enables rather much stuff. Anyway, the latest SVN builds pretty fine with these fine, good job.
- the build settings dialog needs love. First, it needs some spacing
between the GUI elements to match the other Geany dialogs look&feel and also to be more compliant with the Gnome HIG. But this is low priority and can be improved later as this is GUI stuff only.
No problem, whats your standard spacing etc?
See the Gnome HIG :). Using ui_dialog_vbox_new() gives you the correct border spacing for the dialog. Then there is some padding missing between the single GtkEntrys maybe add two or three pixels. And maybe it looks better when you set the icon size of the clear buttons to GTK_ICON_SIZE_MENU but that's not really a big thing.
Not yet sure whether we can improve this, will think about this a bit. But at least, please don't make it even bigger. Imagine you are a new user and just want to change the Run command, in the current dialog you first need to figure out which field does what and where the field is you actually want to edit. Don't get me wrong, it's pretty cool so far but maybe we can make it even cooler. And I'm not one of those Gnome guys who somtimes like hide/remove any option from the user. But there is also the other way to overload the GUI with useless stuff. And so, I'm just about to find a best way in between :).
I agree, its now the biggest dialog in Geany, its just that there is a certain amount of functionality to configure, any suggestions welcome, but I can't see a sensible way of dividing it up to make it smaller. At the moment it reflects the way the menu is laid out. I think its important to keep that relationship for easy use.
Yes, as I said I don't have a better idea so far and so I'm not in the position to criticise the dialog too much :). Maybe we find a solution, if needed at all, later. And since the dialog UI exists for now, it's more important to get everything behind working. Changing the GUI can be done easily afterwards.
forward to see which directories related to which commands. Maybe we *have* to be Gnomic and have the working dir column hidden unless the user selects to make it visible.
The question is whether this makes it better or not regarding usability.
Regards, Enrico
2009/7/18 Enrico Tröger enrico.troeger@uvena.de:
On Fri, 17 Jul 2009 10:03:15 +1000, Lex wrote:
- you really should fix the compiler warnings, I get a whole bunch
when compiling the code (see attachment). Most of them are harmless like unused variables but the more warnings you usually have, the bigger the danger is to overlook a real warning which you want to see
I don't get any of these, is there an option I need to give make or configure to make it picky???
Should be all fixed, but I can't actually check since I don't get them. BTW the filetypes one was useful, but most build ones were just annoying thankfully.
The most important flag is -Wall, this should be used generally I think. I personally use some more flags like (set before running ./configure resp. ./waf configure): export CFLAGS="-Wall -O0 -g -pipe -march=athlon64 \ -DGEANY_DEBUG \ -D_FORTIFY_SOURCE=2 \ -Waggregate-return \ -Wdeclaration-after-statement \ -Wdisabled-optimization \ -Wfloat-equal \ -Wformat-nonliteral \ -Wformat-security \ -Wformat=2 \ -Winit-self \ -Winline \ -Wmissing-field-initializers \ -Wmissing-include-dirs \ -Wmissing-noreturn \ -Wpointer-arith \ -Wshadow \ -Wsign-compare \ -fno-common \ -funit-at-a-time \ "
But this is enables rather much stuff. Anyway, the latest SVN builds pretty fine with these fine, good job.
Oh, OK environment variable!!
couple of (maybe helpful, maybe not) comments
I think Wformat=2 includes Wformat-security and Wformat-nonliteral I don't think Winit-self will work without -Wuninitialized and -O1 Winline seems wasted since no Geany currently inlines and anyway its not really useful even if you use inlines, if the compiler won't inline something, it won't, so whats the point of a warning? (C++ user speaking) funit-at-a-time isn't much use at low optimisation levels & is automatically on at high levels anyway.
probably worth Wstrict-prototypes
- the build settings dialog needs love. First, it needs some spacing
between the GUI elements to match the other Geany dialogs look&feel and also to be more compliant with the Gnome HIG. But this is low priority and can be improved later as this is GUI stuff only.
No problem, whats your standard spacing etc?
See the Gnome HIG :). Using ui_dialog_vbox_new() gives you the correct border spacing for the dialog. Then there is some padding missing between the single GtkEntrys maybe add two or three pixels. And maybe it looks better when you set the icon size of the clear buttons to GTK_ICON_SIZE_MENU but that's not really a big thing.
Ok I'll try those tomorrow, today was toolbars (almost).
Not yet sure whether we can improve this, will think about this a bit. But at least, please don't make it even bigger. Imagine you are a new user and just want to change the Run command, in the current dialog you first need to figure out which field does what and where the field is you actually want to edit. Don't get me wrong, it's pretty cool so far but maybe we can make it even cooler. And I'm not one of those Gnome guys who somtimes like hide/remove any option from the user. But there is also the other way to overload the GUI with useless stuff. And so, I'm just about to find a best way in between :).
I agree, its now the biggest dialog in Geany, its just that there is a certain amount of functionality to configure, any suggestions welcome, but I can't see a sensible way of dividing it up to make it smaller. At the moment it reflects the way the menu is laid out. I think its important to keep that relationship for easy use.
Yes, as I said I don't have a better idea so far and so I'm not in the position to criticise the dialog too much :). Maybe we find a solution, if needed at all, later. And since the dialog UI exists for now, it's more important to get everything behind working. Changing the GUI can be done easily afterwards.
Yes, I am about to say that this branch is feature complete and any problems that come up now are bugs or put in the TODO list
forward to see which directories related to which commands. Maybe we *have* to be Gnomic and have the working dir column hidden unless the user selects to make it visible.
The question is whether this makes it better or not regarding usability.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 18 Jul 2009 22:17:06 +1000, Lex wrote:
2009/7/18 Enrico Tröger enrico.troeger@uvena.de:
On Fri, 17 Jul 2009 10:03:15 +1000, Lex wrote:
- you really should fix the compiler warnings, I get a whole bunch
when compiling the code (see attachment). Most of them are harmless like unused variables but the more warnings you usually have, the bigger the danger is to overlook a real warning which you want to see
I don't get any of these, is there an option I need to give make or configure to make it picky???
Should be all fixed, but I can't actually check since I don't get them. BTW the filetypes one was useful, but most build ones were just annoying thankfully.
The most important flag is -Wall, this should be used generally I think. I personally use some more flags like (set before running ./configure resp. ./waf configure): export CFLAGS="-Wall -O0 -g -pipe -march=athlon64 \ -DGEANY_DEBUG \ -D_FORTIFY_SOURCE=2 \ -Waggregate-return \ -Wdeclaration-after-statement \ -Wdisabled-optimization \ -Wfloat-equal \ -Wformat-nonliteral \ -Wformat-security \ -Wformat=2 \ -Winit-self \ -Winline \ -Wmissing-field-initializers \ -Wmissing-include-dirs \ -Wmissing-noreturn \ -Wpointer-arith \ -Wshadow \ -Wsign-compare \ -fno-common \ -funit-at-a-time \ "
But this is enables rather much stuff. Anyway, the latest SVN builds pretty fine with these fine, good job.
Oh, OK environment variable!!
couple of (maybe helpful, maybe not) comments
I think Wformat=2 includes Wformat-security and Wformat-nonliteral I don't think Winit-self will work without -Wuninitialized and -O1 Winline seems wasted since no Geany currently inlines and anyway its not really useful even if you use inlines, if the compiler won't inline something, it won't, so whats the point of a warning? (C++ user speaking) funit-at-a-time isn't much use at low optimisation levels & is automatically on at high levels anyway.
Probably all true but on the other hand, it just don't hurt :). I didn't say you should use them, just that I use them.
probably worth Wstrict-prototypes
This causes lots of warnings in the GTK headers, kinda unfortunate.
Yes, as I said I don't have a better idea so far and so I'm not in the position to criticise the dialog too much :). Maybe we find a solution, if needed at all, later. And since the dialog UI exists for now, it's more important to get everything behind working. Changing the GUI can be done easily afterwards.
Yes, I am about to say that this branch is feature complete and any problems that come up now are bugs or put in the TODO list
Cool, so we can slowly start talking about merging the branch back to trunk (slowly). I think it's best to test this code and to find and fix obvious bugs and problems. And then get it into trunk for a wider audience.
I'm wondering if it is worth to make another release before merging the branch or to do it before. Doing a releasing before merging would make the release more stable probably and gives us more time to test the new code. OTOH merging the branch soon and delaying a possible new release a bit is maybe better for the users because they don't need to wait for another release cycle to see the new and fancy build system code :).
Any opinions? I tend to merge it and then make a release.
Regards, Enrico
Probably all true but on the other hand, it just don't hurt :). I didn't say you should use them, just that I use them.
Wasn't any criticism, but as I had to *read the documentation* to see what they did I thought I'd mention.
probably worth Wstrict-prototypes
This causes lots of warnings in the GTK headers, kinda unfortunate.
Yeah, thats a pity!!!
Yes, as I said I don't have a better idea so far and so I'm not in the position to criticise the dialog too much :). Maybe we find a solution, if needed at all, later. And since the dialog UI exists for now, it's more important to get everything behind working. Changing the GUI can be done easily afterwards.
Yes, I am about to say that this branch is feature complete and any problems that come up now are bugs or put in the TODO list
Cool, so we can slowly start talking about merging the branch back to trunk (slowly). I think it's best to test this code and to find and fix obvious bugs and problems.
Agreed, there is a fair bit of new code there
And then get it into trunk for a wider audience.
I'm wondering if it is worth to make another release before merging the branch or to do it before. Doing a releasing before merging would make the release more stable probably and gives us more time to test the new code. OTOH merging the branch soon and delaying a possible new release a bit is maybe better for the users because they don't need to wait for another release cycle to see the new and fancy build system code :).
Any opinions? I tend to merge it and then make a release.
I guess it depends when you are planning the next release. What else is already in trunk or planned? Is that enough for a release? If so I'd tend to small release quickly then we have time otherwise it might be a while until the release.
Need time for test + time for test in the trunk, plus any impact on translation since I havn't really tracked how many strings have been changed,
TODO List (Major items only)
I don't know what the impact on plugins is yet, I tried to build the plugins but no luck, you have seen my discussions with Chow. I might get a chance on the weekend to try it on an old machine where I can install Geany to the system directories so I can build plugins.
Has anyone tried to build it on Windows? I don't have windows build capability.
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 18 Jul 2009 23:19:41 +1000, Lex wrote:
And then get it into trunk for a wider audience.
I'm wondering if it is worth to make another release before merging the branch or to do it before. Doing a releasing before merging would make the release more stable probably and gives us more time to test the new code. OTOH merging the branch soon and delaying a possible new release a bit is maybe better for the users because they don't need to wait for another release cycle to see the new and fancy build system code :).
Any opinions? I tend to merge it and then make a release.
I guess it depends when you are planning the next release. What else is already in trunk or planned? Is that enough for a release? If so I'd tend to small release quickly then we have time otherwise it might be a while until the release.
Not sure. We already have a good bunch of new features and fixes in trunk making worth a release, I think. But no plans so far, still needs to be discussed. Hold on, I'll post with news soon.
Need time for test + time for test in the trunk, plus any impact on translation since I havn't really tracked how many strings have been changed,
Don't worry about translations. Usually we do a string freeze one or two weeks before doing a release so translators have time to update.
TODO List (Major items only)
I don't know what the impact on plugins is yet, I tried to build the
Any problems will quickly show up once the code is in trunk.
Has anyone tried to build it on Windows? I don't have windows build capability.
I will try building it on Windows next week. I don't expect much problems, at least not more than usual with build stuff on Windows...:)
Regards, Enrico
TODO List (Major items only)
I don't know what the impact on plugins is yet, I tried to build the
Any problems will quickly show up once the code is in trunk.
Plugins won't build, filetype.h now uses build.h which isn't installed to /usr/local/include/geany/
I'm AC_illiterate, where do I put build.h to get it installed, is it geany_include_HEADERS in src/Makefile.am ?
Or alternatively I could make the requirement go away since now the GeanyFiletype structure only has pointers to GeanyBuildCommand, so it doesn't actually need the definition.
Which is preferable from your point of view??
Cheers Lex
Has anyone tried to build it on Windows? I don't have windows build capability.
I will try building it on Windows next week. I don't expect much problems, at least not more than usual with build stuff on Windows...:)
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
2009/7/21 Lex Trotman elextr@gmail.com:
TODO List (Major items only)
I don't know what the impact on plugins is yet, I tried to build the
Any problems will quickly show up once the code is in trunk.
Plugins won't build, filetype.h now uses build.h which isn't installed to /usr/local/include/geany/
I'm AC_illiterate, where do I put build.h to get it installed, is it geany_include_HEADERS in src/Makefile.am ?
Or alternatively I could make the requirement go away since now the GeanyFiletype structure only has pointers to GeanyBuildCommand, so it doesn't actually need the definition.
Which is preferable from your point of view??
Cheers Lex
Update, making the requirement go away allows geany-plugins combined release to build & seems to workl!!!
So now the question is should plugins be able to access the build menu. I would think that there could be uses for it and would be happy to add two functions to build.h
gchar *get_build_cmd_field( GeanyBuildGroup group, gint cmdindex, GeanyBuildCmdEntries field); void set_build_cmd_field( GeanyBuildGroup group, gint cmdindex, GeanyBuildCmdEntries field, const gchar *value );
that are documented for use by plugins. and allow build_menu_update to be used by plugins unless there is another way of triggering it.
Then we need to install build.h
Cheers Lex
Has anyone tried to build it on Windows? I don't have windows build capability.
I will try building it on Windows next week. I don't expect much problems, at least not more than usual with build stuff on Windows...:)
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 21 Jul 2009 13:45:16 +1000, Lex wrote:
2009/7/21 Lex Trotman elextr@gmail.com:
TODO List (Major items only)
I don't know what the impact on plugins is yet, I tried to build the
Any problems will quickly show up once the code is in trunk.
Plugins won't build, filetype.h now uses build.h which isn't installed to /usr/local/include/geany/
I'm AC_illiterate, where do I put build.h to get it installed, is it geany_include_HEADERS in src/Makefile.am ?
Exactly. And for Waf, it's in wscript around line 451.
Or alternatively I could make the requirement go away since now the GeanyFiletype structure only has pointers to GeanyBuildCommand, so it doesn't actually need the definition.
Which is preferable from your point of view??
Update, making the requirement go away allows geany-plugins combined release to build & seems to workl!!!
So now the question is should plugins be able to access the build menu. I would think that there could be uses for it and would be happy to add two functions to build.h
gchar *get_build_cmd_field( GeanyBuildGroup group, gint cmdindex, GeanyBuildCmdEntries field); void set_build_cmd_field( GeanyBuildGroup group, gint cmdindex, GeanyBuildCmdEntries field, const gchar *value );
that are documented for use by plugins. and allow build_menu_update to be used by plugins unless there is another way of triggering it.
Then we need to install build.h
Yo. I guess we would add it at some point anyway and so we can also add it now. I think someone might want to write a plugin which uses/extends/whatever the new build system code in some way.
Regards, Enrico
2009/7/22 Enrico Tröger enrico.troeger@uvena.de:
On Tue, 21 Jul 2009 13:45:16 +1000, Lex wrote:
2009/7/21 Lex Trotman elextr@gmail.com:
TODO List (Major items only)
I don't know what the impact on plugins is yet, I tried to build the
Any problems will quickly show up once the code is in trunk.
Plugins won't build, filetype.h now uses build.h which isn't installed to /usr/local/include/geany/
I'm AC_illiterate, where do I put build.h to get it installed, is it geany_include_HEADERS in src/Makefile.am ?
Exactly. And for Waf, it's in wscript around line 451.
Done, waf not tested since I don't have it installed.
Or alternatively I could make the requirement go away since now the GeanyFiletype structure only has pointers to GeanyBuildCommand, so it doesn't actually need the definition.
Which is preferable from your point of view??
Update, making the requirement go away allows geany-plugins combined release to build & seems to workl!!!
So now the question is should plugins be able to access the build menu. I would think that there could be uses for it and would be happy to add two functions to build.h
gchar *get_build_cmd_field( GeanyBuildGroup group, gint cmdindex, GeanyBuildCmdEntries field); void set_build_cmd_field( GeanyBuildGroup group, gint cmdindex, GeanyBuildCmdEntries field, const gchar *value );
that are documented for use by plugins. and allow build_menu_update to be used by plugins unless there is another way of triggering it.
Then we need to install build.h
Yo. I guess we would add it at some point anyway and so we can also add it now. I think someone might want to write a plugin which uses/extends/whatever the new build system code in some way.
Ok, done except build_get_menu_item returns the whole *GeanyBuildCommand structure instead of one field at a time. Made the interface simpler since no set function is needed.
Included remove_menu_item function in the interface.
Without a plugin that uses it, testing was very rudimentary, I guess that bugs will show up when someone uses it. :-)
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 22 Jul 2009 13:12:41 +1000, Lex wrote:
2009/7/22 Enrico Tröger enrico.troeger@uvena.de:
On Tue, 21 Jul 2009 13:45:16 +1000, Lex wrote:
2009/7/21 Lex Trotman elextr@gmail.com:
TODO List (Major items only)
I don't know what the impact on plugins is yet, I tried to build the
Any problems will quickly show up once the code is in trunk.
Plugins won't build, filetype.h now uses build.h which isn't installed to /usr/local/include/geany/
I'm AC_illiterate, where do I put build.h to get it installed, is it geany_include_HEADERS in src/Makefile.am ?
Exactly. And for Waf, it's in wscript around line 451.
Done, waf not tested since I don't have it installed.
Works fine.
Or alternatively I could make the requirement go away since now the GeanyFiletype structure only has pointers to GeanyBuildCommand, so it doesn't actually need the definition.
Which is preferable from your point of view??
Update, making the requirement go away allows geany-plugins combined release to build & seems to workl!!!
So now the question is should plugins be able to access the build menu. I would think that there could be uses for it and would be happy to add two functions to build.h
gchar *get_build_cmd_field( GeanyBuildGroup group, gint cmdindex, GeanyBuildCmdEntries field); void set_build_cmd_field( GeanyBuildGroup group, gint cmdindex, GeanyBuildCmdEntries field, const gchar *value );
that are documented for use by plugins. and allow build_menu_update to be used by plugins unless there is another way of triggering it.
Then we need to install build.h
Yo. I guess we would add it at some point anyway and so we can also add it now. I think someone might want to write a plugin which uses/extends/whatever the new build system code in some way.
Ok, done except build_get_menu_item returns the whole *GeanyBuildCommand structure instead of one field at a time. Made the interface simpler since no set function is needed.
Included remove_menu_item function in the interface.
Without a plugin that uses it, testing was very rudimentary, I guess that bugs will show up when someone uses it. :-)
Great.
Btw, the code builds on Windows however I didn't run it yet. Will do once it is merged into trunk.
Regards, Enrico
On Sat, 18 Jul 2009 16:54:16 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Sat, 18 Jul 2009 23:19:41 +1000, Lex wrote:
And then get it into trunk for a wider audience.
I'm wondering if it is worth to make another release before merging the branch or to do it before. Doing a releasing before merging would make the release more stable probably and gives us more time to test the new code. OTOH merging the branch soon and delaying a possible new release a bit is maybe better for the users because they don't need to wait for another release cycle to see the new and fancy build system code :).
Any opinions? I tend to merge it and then make a release.
I guess it depends when you are planning the next release. What else is already in trunk or planned? Is that enough for a release? If so I'd tend to small release quickly then we have time otherwise it might be a while until the release.
Not sure. We already have a good bunch of new features and fixes in trunk making worth a release, I think. But no plans so far, still needs to be discussed. Hold on, I'll post with news soon.
Are there any points on this I might missed? ;) As it appears the branch is already working well (beside the mentioned points) I think we should do a release just in front of. In case of there are major issues after merging to trunk, a maintenance release without feature can be build up using a commit before submitting the changes inside a new branch. Just in case of.
Cheers, Frank
2009/7/26 Frank Lanitz frank@frank.uvena.de:
On Sat, 18 Jul 2009 16:54:16 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Sat, 18 Jul 2009 23:19:41 +1000, Lex wrote:
And then get it into trunk for a wider audience.
I'm wondering if it is worth to make another release before merging the branch or to do it before. Doing a releasing before merging would make the release more stable probably and gives us more time to test the new code. OTOH merging the branch soon and delaying a possible new release a bit is maybe better for the users because they don't need to wait for another release cycle to see the new and fancy build system code :).
Any opinions? I tend to merge it and then make a release.
I guess it depends when you are planning the next release. What else is already in trunk or planned? Is that enough for a release? If so I'd tend to small release quickly then we have time otherwise it might be a while until the release.
Not sure. We already have a good bunch of new features and fixes in trunk making worth a release, I think. But no plans so far, still needs to be discussed. Hold on, I'll post with news soon.
Are there any points on this I might missed? ;) As it appears the branch is already working well (beside the mentioned points) I think we should do a release just in front of. In case of there are major issues after merging to trunk, a maintenance release without feature can be build up using a commit before submitting the changes inside a new branch. Just in case of.
Hi Frank,
The actual merge shouldn't be much trouble, I'm now merging trunk into the branch each week. That still requires some manual intervention, which I have so far demonstrated twice is a source of error. What sort of worries me is the list of merges that svn thinks are ok and does automatically. Just because they merge doesn't say they are right.
So a good debugging time in trunk is important. As you said releasing trunk before the merge will allow that time without the current release getting too stale.
Cheers Lex
Cheers, Frank -- Frank Lanitz frank@frank.uvena.de
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 27 Jul 2009 10:52:08 +1000, Lex wrote:
2009/7/26 Frank Lanitz frank@frank.uvena.de:
On Sat, 18 Jul 2009 16:54:16 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Sat, 18 Jul 2009 23:19:41 +1000, Lex wrote:
And then get it into trunk for a wider audience.
I'm wondering if it is worth to make another release before merging the branch or to do it before. Doing a releasing before merging would make the release more stable probably and gives us more time to test the new code. OTOH merging the branch soon and delaying a possible new release a bit is maybe better for the users because they don't need to wait for another release cycle to see the new and fancy build system code :).
Any opinions? I tend to merge it and then make a release.
I guess it depends when you are planning the next release. What else is already in trunk or planned? Is that enough for a release? If so I'd tend to small release quickly then we have time otherwise it might be a while until the release.
Not sure. We already have a good bunch of new features and fixes in trunk making worth a release, I think. But no plans so far, still needs to be discussed. Hold on, I'll post with news soon.
Are there any points on this I might missed? ;) As it appears the branch is already working well (beside the mentioned points) I think we should do a release just in front of. In case of there are major issues after merging to trunk, a maintenance release without feature can be build up using a commit before submitting the changes inside a new branch. Just in case of.
Hi Frank,
The actual merge shouldn't be much trouble, I'm now merging trunk into the branch each week. That still requires some manual intervention, which I have so far demonstrated twice is a source of error. What
Haha. I'm also very experienced with such things :).
So a good debugging time in trunk is important. As you said releasing trunk before the merge will allow that time without the current release getting too stale.
Yes. We will do a release in the middle or end of August. After that release, we can merge the build-system branch into trunk to get it tested and integrated cleanly without being in a hurry for a release. OK?
Regards, Enrico
2009/7/28 Enrico Tröger enrico.troeger@uvena.de:
On Mon, 27 Jul 2009 10:52:08 +1000, Lex wrote:
2009/7/26 Frank Lanitz frank@frank.uvena.de:
On Sat, 18 Jul 2009 16:54:16 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Sat, 18 Jul 2009 23:19:41 +1000, Lex wrote:
And then get it into trunk for a wider audience.
I'm wondering if it is worth to make another release before merging the branch or to do it before. Doing a releasing before merging would make the release more stable probably and gives us more time to test the new code. OTOH merging the branch soon and delaying a possible new release a bit is maybe better for the users because they don't need to wait for another release cycle to see the new and fancy build system code :).
Any opinions? I tend to merge it and then make a release.
I guess it depends when you are planning the next release. What else is already in trunk or planned? Is that enough for a release? If so I'd tend to small release quickly then we have time otherwise it might be a while until the release.
Not sure. We already have a good bunch of new features and fixes in trunk making worth a release, I think. But no plans so far, still needs to be discussed. Hold on, I'll post with news soon.
Are there any points on this I might missed? ;) As it appears the branch is already working well (beside the mentioned points) I think we should do a release just in front of. In case of there are major issues after merging to trunk, a maintenance release without feature can be build up using a commit before submitting the changes inside a new branch. Just in case of.
Hi Frank,
The actual merge shouldn't be much trouble, I'm now merging trunk into the branch each week. That still requires some manual intervention, which I have so far demonstrated twice is a source of error. What
Haha. I'm also very experienced with such things :).
So a good debugging time in trunk is important. As you said releasing trunk before the merge will allow that time without the current release getting too stale.
Yes. We will do a release in the middle or end of August. After that release, we can merge the build-system branch into trunk to get it tested and integrated cleanly without being in a hurry for a release. OK?
Works for me.
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Enrico Tröger schrieb:
So a good debugging time in trunk is important. As you said releasing trunk before the merge will allow that time without the current release getting too stale.
Yes. We will do a release in the middle or end of August. After that release, we can merge the build-system branch into trunk to get it tested and integrated cleanly without being in a hurry for a release. OK?
Regards, Enrico
3-4 weeks seems plenty to iron out possible problems.
Anyway, I never use releases of Geany anyway; I just don't want to miss new features or bug fixes in trunk while running the cool branch :P
Best regards.
Lex Trotman schrieb:
Hi All,
The first alpha release of a version of Geany with flexible configuration of the Build Menu is available in the build-system branch of svn, https://geany.svn.sourceforge.net/svnroot/geany/branches/build-system/
Great work! That's a thing I'm really missing for Geany.
I'm digging in a bit. The dialog looks good already, but I think it lacks a important field: Working directory for the command.
It should be obvious, that for many projects, the source files are structured, so that having the working dir default to the dir where the source file is located doesn't work. And the base directory of a project also doesn't always work.
I'm looking at the code in the hope I can add it. It's a bit hard for me to read the code, it lacks comments and structure here and there, but I hope I'll find my way.
Thomas Martitz schrieb:
I'm looking at the code in the hope I can add it. It's a bit hard for me to read the code, it lacks comments and structure here and there, but I hope I'll find my way.
Alright, I've got to the point where I can add it.
BUT I needed to rewrite much parts (such as doing separate (even if it's the same) handling of GeanyBuildCommand.label and .command in a loop instead). The code duplication and hardcodedness was so irritating that I couldn't get it to work without.
I attached the patch. In case it's accepted, I can continue to work in really integrating the working dir field (I didn't add it yet). Adding the working dir entry field is mostly adding a item to the enum GeanyBuildCmdEntries now.
Best regards.
Hi Thomas,
Thanks for looking at it and working on improvements already.
(below copied from your previous email so I can reply to both at once)
Great work! That's a thing I'm really missing for Geany.
I'm digging in a bit. The dialog looks good already, but I think it lacks
a important field:
Working directory for the command.
To run a command in a specific directory just make the command field "cd <the directory>; <the rest of the command>"
That seems to be what your code is trying to do through a field for the directory, if I have misunderstood please explain.
If that is the case then I don't feel there is a need for another field in the dialog or any express support in the code, anyway for now my concern is getting the basic functionality working reliably and getting it used.
It should be obvious, that for many projects, the source files are
structured,
so that having the working dir default to the dir where the source file is
located doesn't work.
And the base directory of a project also doesn't always work.
True, this is just replicating the current way Geany performs so that it can load old config files.
I'm looking at the code in the hope I can add it. It's a bit hard for me
to read the code,
it lacks comments and structure here and there, but I hope I'll find my
way.
Yeah, thats the way of code thats evolved from an experiment through several iterations (15 according to my local version control) I intend to improve things when its all working. _
2009/7/12 Thomas Martitz thomas.martitz@student.htw-berlin.de
Thomas Martitz schrieb:
I'm looking at the code in the hope I can add it. It's a bit hard for me to read the code, it lacks comments and structure here and there, but I hope I'll find my way.
Alright, I've got to the point where I can add it.
BUT I needed to rewrite much parts (such as doing separate (even if it's the same) handling of GeanyBuildCommand.label and .command in a loop instead). The code duplication and hardcodedness was so irritating that I couldn't get it to work without.
I don't understand why it needs to be a loop like that, just add another field to GeanyBuildCommand and use it where you need to. Much easier to understand for simple folk like me ;-) Then all other places addressing label and command don't need to change.
I attached the patch. In case it's accepted, I can continue to work in really integrating the working dir field (I didn't add it yet). Adding the working dir entry field is mostly adding a item to the enum GeanyBuildCmdEntries now.
I tried to apply your patch to my working copy but 25 out of 27 chunks were rejected, thats the problem with patches on a rapidly changing source. So the patch can't be used directly, and for now I can't spare the time to work out the problems since there are still important bits of functionality to fix/add, but if the method of setting directory suggested above isn't sufficient let me know.
Cheers Lex
Best regards.
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Lex Trotman schrieb:
Hi Thomas,
Thanks for looking at it and working on improvements already.
(below copied from your previous email so I can reply to both at once)
Great work! That's a thing I'm really missing for Geany.
I'm digging in a bit. The dialog looks good already, but I think it
lacks a important field:
Working directory for the command.
To run a command in a specific directory just make the command field "cd <the directory>; <the rest of the command>"
I figured that it works. But that's overly nasty, especially with regards to multi-plattform support. Working dir of a process/command is a very basic and essential thing.
That seems to be what your code is trying to do through a field for the directory, if I have misunderstood please explain.
Yes, that's correct.
If that is the case then I don't feel there is a need for another field in the dialog or any express support in the code, anyway for now my concern is getting the basic functionality working reliably and getting it used.
What doesn't work "in a basic way"? I'm using it right now and works mostly?
It should be obvious, that for many projects, the source files are
structured,
so that having the working dir default to the dir where the source
file is located doesn't work.
And the base directory of a project also doesn't always work.
True, this is just replicating the current way Geany performs so that it can load old config files.
I'm looking at the code in the hope I can add it. It's a bit hard
for me to read the code,
it lacks comments and structure here and there, but I hope I'll find
my way.
Yeah, thats the way of code thats evolved from an experiment through several iterations (15 according to my local version control) I intend to improve things when its all working.
No problem. Documentation and readable code is essential at some point, though.
I don't understand why it needs to be a loop like that, just add another field to GeanyBuildCommand and use it where you need to. Much easier to understand for simple folk like me ;-) Then all other places addressing label and command don't need to change.
Because code duplication is bad, ugly and very error prone. And in most places, the code applies to all GtkEntry fields from the settings. The code isn't readable worse due to usage of the enum (.entries[BC_COMMAND] is as obvious as .command). It's needed almost everywhere were label and command are already needed (such as for config loading or dialog ui handling)
I tried to apply your patch to my working copy but 25 out of 27 chunks were rejected, thats the problem with patches on a rapidly changing source.
The patch is made off the branch, I'm fairly sure (going by the IRC bot) that there hasn't been much commits in the meantime.
So the patch can't be used directly, and for now I can't spare the time to work out the problems since there are still important bits of functionality to fix/add, but if the method of setting directory suggested above isn't sufficient let me know.
Cheers Lex
2009/7/13 Thomas Martitz thomas.martitz@student.htw-berlin.de
Lex Trotman schrieb:
Hi Thomas,
Thanks for looking at it and working on improvements already.
(below copied from your previous email so I can reply to both at once)
Great work! That's a thing I'm really missing for Geany.
I'm digging in a bit. The dialog looks good already, but I think it
lacks a important field:
Working directory for the command.
To run a command in a specific directory just make the command field "cd <the directory>; <the rest of the command>"
I figured that it works. But that's overly nasty, especially with regards to multi-plattform support. Working dir of a process/command is a very basic and essential thing.
Nasty is a bit harsh, but I agree its only a workaround. BTW I'm not disagreeing about the need for some improvement in the area of directory management, see below (sorry Enrico, another 'short' email)
That seems to be what your code is trying to do through a field for the directory, if I have misunderstood please explain.
Yes, that's correct.
If that is the case then I don't feel there is a need for another field in the dialog or any express support in the code, anyway for now my concern is getting the basic functionality working reliably and getting it used.
What doesn't work "in a basic way"? I'm using it right now and works mostly?
I'm glad, the announcement has a list of what I know I still need to do, some of which changes build.c quite a bit.
It should be obvious, that for many projects, the source files are
structured,
so that having the working dir default to the dir where the source file
is located doesn't work.
And the base directory of a project also doesn't always work.
Agree see below.
True, this is just replicating the current way Geany performs so that it can load old config files.
I'm looking at the code in the hope I can add it. It's a bit hard for me
to read the code,
it lacks comments and structure here and there, but I hope I'll find my
way.
Yeah, thats the way of code thats evolved from an experiment through several iterations (15 according to my local version control) I intend to improve things when its all working.
No problem. Documentation and readable code is essential at some point, though.
I don't understand why it needs to be a loop like that, just add another field to GeanyBuildCommand and use it where you need to. Much easier to understand for simple folk like me ;-) Then all other places addressing label and command don't need to change.
Because code duplication is bad, ugly and very error prone. And in most places, the code applies to all GtkEntry fields from the settings. The code isn't readable worse due to usage of the enum (.entries[BC_COMMAND] is as obvious as .command). It's needed almost everywhere were label and command are already needed (such as for config loading or dialog ui handling)
I tried to apply your patch to my working copy but 25 out of 27 chunks were rejected, thats the problem with patches on a rapidly changing source.
The patch is made off the branch, I'm fairly sure (going by the IRC bot) that there hasn't been much commits in the meantime.
Oh yes, It must have been made out of the branch, the trunk build.c is VERY different, this build.c is a significant re-write. The problem most likely is that there are still significant things being done to build.c to reduce the list of known bugs, limits and incompletes.
So the patch can't be used directly, and for now I can't spare the time to
work out the problems since there are still important bits of functionality to fix/add, but if the method of setting directory suggested above isn't sufficient let me know.
Cheers Lex
At the moment the directory handling is the same as Geany 0.17. This was as agreed when the scope of the changes were discussed in this ML.
But lets think some more about the problem of where commands run and how best to provide flexibility and ease of use. There are three groups of commands and several sources that need to be considered.
Filetype commands are intended to be run on the currently open file, so they always run in the source file directory. This allows them to be used for simple single file work without configuration, and allows movement around more complex source trees, again without configuration. Whilst there may be a use case for configuration to a fixed directory that I can't think of, I am sure that it is likely to cause confusion when a file in another directory is accidently used. Therefore I believe that the current behavior is correct.
Non-filetype commands are a bit more complicated. Since this group is intended to run commands independent of the source file, in theory it could be any directory, But there are a couple of likely candidates: - for make type builders to build the entire package the top of the tree is the right place, that is a fixed directory (at least for each package it is) - for make type bulders that build lower levels than the whole package, then somewhere below the top of the tree is right, that isn't a fixed directory (an example of where you use this is make doc in geany's doc subdirectory)
The current behaviour of Geany is to provide an approximation of both, at least if you are using a project. A fixed directory for all commands for this package is provided by the base_dir of the project, otherwise the directory of the current file is used as the most likely place to run commands within the tree. (Note although it is called the project base directory, I am not aware of any reason why it can't be set to any arbitary directory no matter where you keep the project file. So you can set it to a subtree if you intend to work there for a while) The make in base dir checkbox allows each command to be directed to one of these options.
Allowing each command to be run in a specific directory would add flexibility, but I for one wouldn't want to have to configure each command for each project, so the run in base should still be provided as a common setting and I can't think of a better analogue of the subtree than the directory of the current file, unless a select directory dialog is used (not suggesting it for now, but it could be a future). Therefore when a project is open each command needs to select between three possible directories, base, current or set in the dialog. Set in dialog could be selected if the setting is non-blank but we still need the base_dir checkbox as well. Or maybe a dropdown list to allow for the inevitable expansion ;-).
At the last minute I have also thought of another option that I would find useful, that is to have an option for the base_dir to be relative to the project file so that the whole tree can be copied around without having to re-configure the project file. So a project file with appropriate command settings could be included in version control and checked out with the tree.
When running without a project there is no base_dir available, so Geany runs commands in the directory of the current file or not at all. This could be improved by having a preference for a common directory (a base_dir for non-project use) and by having per-command directories.
I'm not entirely satisfied by this approach since I usually have multiple things on the go at once, and having to change the configured directory each time I change what I'm working on is not nice (but at least with the common one I would only have to change it in one spot). So maybe a popup to ask for the directory, that remembers the current value (so running a make the same as the last is just shift+f9 return) and has past values in a dropdown, might be needed sooner than I implied above.
Anyway thats my thoughts for now, lets see what the Geany community thinks, feedback encouraged.
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Lex Trotman schrieb:
I'm not entirely satisfied by this approach since I usually have multiple things on the go at once, and having to change the configured directory each time I change what I'm working on is not nice (but at least with the common one I would only have to change it in one spot). So maybe a popup to ask for the directory, that remembers the current value (so running a make the same as the last is just shift+f9 return) and has past values in a dropdown, might be needed sooner than I implied above.
Well, I haven't evens started to integrate that field, so it's a bit early to assume how it would behave.
I pretty much planned that it would fill the appropriate defaults if they're empty. And very few special characters which for example expand to the file's path (i.e. more than just %e and %f). That would make it pretty easy.
2009/7/13 Thomas Martitz thomas.martitz@student.htw-berlin.de
Lex Trotman schrieb:
I'm not entirely satisfied by this approach since I usually have multiple things on the go at once, and having to change the configured directory each time I change what I'm working on is not nice (but at least with the common one I would only have to change it in one spot). So maybe a popup to ask for the directory, that remembers the current value (so running a make the same as the last is just shift+f9 return) and has past values in a dropdown, might be needed sooner than I implied above.
Well, I haven't evens started to integrate that field, so it's a bit early to assume how it would behave.
I pretty much planned that it would fill the appropriate defaults if they're empty. And very few special characters which for example expand to the file's path (i.e. more than just %e and %f). That would make it pretty easy.
Sorry Frank, you've sort of lost me here? :-S
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Lex Trotman schrieb:
Well, I haven't evens started to integrate that field, so it's a
bit early to assume how it would behave.
I pretty much planned that it would fill the appropriate defaults
if they're empty. And very few special characters which for example expand to the file's path (i.e. more than just %e and %f). That would make it pretty easy.
Sorry Frank, you've sort of lost me here? :-S
Cheers Lex
What didn't you understand?
I basically just argued against your arguments, that it will be more work to put the paths in, by filling the entry boxes with nice default values (such as the project's or file's path), plus by adding a few variables to expand to suitable paths (like %e already does for the current file, %p could expand to the path of the current file).
That's all to free the user of tight limitations of Geany (w.r.t to building) and to support even unconventional build system, which I know a few of.
Best regards.
2009/7/14 Thomas Martitz thomas.martitz@student.htw-berlin.de
Lex Trotman schrieb:
Well, I haven't evens started to integrate that field, so it's a bitearly to assume how it would behave.
I pretty much planned that it would fill the appropriate defaults ifthey're empty. And very few special characters which for example expand to the file's path (i.e. more than just %e and %f). That would make it pretty easy.
Sorry Frank, you've sort of lost me here? :-S
Cheers Lex
What didn't you understand?
I basically just argued against your arguments, that it will be more work to put the paths in, by filling the entry boxes with nice default values (such as the project's or file's path), plus by adding a few variables to expand to suitable paths (like %e already does for the current file, %p could expand to the path of the current file).
That's all to free the user of tight limitations of Geany (w.r.t to building) and to support even unconventional build system, which I know a few of.
Which is why I am doing this whole damn thing.;-)
Best regards.
Ok, now I get you, good idea. I have top posted a cleaned up version of my description so lets see what feedback there is. New version is in SVN, if you can update your patch I won't make any changes tonight and try your patch tomorrow.
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Lex Trotman schrieb:
I tried to apply your patch to my working copy but 25 out of 27 chunks were rejected, thats the problem with patches on a rapidly changing source. The patch is made off the branch, I'm fairly sure (going by the IRC bot) that there hasn't been much commits in the meantime.Oh yes, It must have been made out of the branch, the trunk build.c is VERY different, this build.c is a significant re-write. The problem most likely is that there are still significant things being done to build.c to reduce the list of known bugs, limits and incompletes.
Alright, I did a svn up in the branch, at it's still at r3952. And my patch is against that revision. Could it be local changes on your side?
Best regards.
2009/7/13 Thomas Martitz thomas.martitz@student.htw-berlin.de
Lex Trotman schrieb:
I tried to apply your patch to my working copy but 25 out of 27 chunks were rejected, thats the problem with patches on a rapidly changing source.The patch is made off the branch, I'm fairly sure (going by the IRC bot) that there hasn't been much commits in the meantime.
Oh yes, It must have been made out of the branch, the trunk build.c is VERY different, this build.c is a significant re-write. The problem most likely is that there are still significant things being done to build.c to reduce the list of known bugs, limits and incompletes.
Alright, I did a svn up in the branch, at it's still at r3952. And my patch is against that revision. Could it be local changes on your side?
Most probably, as I said its still under active development, but at the moment I have a persistent crash so I don't want to commit a more broken program than is already there :-(
Cheers lex
Best regards.
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Am Montag, den 13.07.2009, 22:34 +1000 schrieb Lex Trotman:
Alright, I did a svn up in the branch, at it's still at r3952. And my patch is against that revision. Could it be local changes on your side?Most probably, as I said its still under active development, but at the moment I have a persistent crash so I don't want to commit a more broken program than is already there :-(
Don't be afraid to do some more commits. Also I had good experience developing using a local git branch so I keep track on my changes as well as I can patch/merge patches coming in.
Cheers, Frank
2009/7/13 Frank Lanitz frank@frank.uvena.de
Am Montag, den 13.07.2009, 22:34 +1000 schrieb Lex Trotman:
Alright, I did a svn up in the branch, at it's still at r3952. And my patch is against that revision. Could it be local changes on your side?Most probably, as I said its still under active development, but at the moment I have a persistent crash so I don't want to commit a more broken program than is already there :-(
Don't be afraid to do some more commits. Also I had good experience developing using a local git branch so I keep track on my changes as well as I can patch/merge patches coming in.
I just *hate* it when I grab a new version of something from SVN build it and find it crashes immediately :-( , so I don't want to do it to others.
Cheers lex
PS That damn warning is still there, its just a wrong cast, the data is ok, but I just can't seem to get the cast right to shut GCC up.
Cheers, Frank
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 13 Jul 2009 14:55:20 +0200, Frank wrote:
Am Montag, den 13.07.2009, 22:34 +1000 schrieb Lex Trotman:
Alright, I did a svn up in the branch, at it's still atr3952. And my patch is against that revision. Could it be local changes on your side?
Most probably, as I said its still under active development, but at the moment I have a persistent crash so I don't want to commit a more broken program than is already there :-(
Don't be afraid to do some more commits. Also I had good experience developing using a local git branch so I keep track on my changes as well as I can patch/merge patches coming in.
In case of the build-system branch, using a local git repository doesn't make sense. The idea of the branch is to constantly work on this code with all the advantages of a source code management system like SVN (even though some of you don't like it) and especially having the history. When using a local git repo and then commit one big chunk of changes, the whole idea of the branch is destroyed.
Just my 2cents.
Regards, Enrico
On Thu, 16 Jul 2009 18:17:10 +0200, Enrico wrote:
On Mon, 13 Jul 2009 14:55:20 +0200, Frank wrote:
Am Montag, den 13.07.2009, 22:34 +1000 schrieb Lex Trotman:
Alright, I did a svn up in the branch, at it's still atr3952. And my patch is against that revision. Could it be local changes on your side?
Most probably, as I said its still under active development, but at the moment I have a persistent crash so I don't want to commit a more broken program than is already there :-(
Don't be afraid to do some more commits. Also I had good experience developing using a local git branch so I keep track on my changes as well as I can patch/merge patches coming in.
In case of the build-system branch, using a local git repository doesn't make sense. The idea of the branch is to constantly work on this code with all the advantages of a source code management system like SVN (even though some of you don't like it) and especially having the history. When using a local git repo and then commit one big chunk of changes, the whole idea of the branch is destroyed.
I forgot to mention, committing such big chunks makes it also way more complicate to review the changes which we need to do at some point. And reviewing a super big maybe 100K or more patch is awful. So, small and logical structured commits would help us all most, I think.
Regards, Enrico
Enrico Tröger schrieb:
On Thu, 16 Jul 2009 18:17:10 +0200, Enrico wrote:
On Mon, 13 Jul 2009 14:55:20 +0200, Frank wrote:
Am Montag, den 13.07.2009, 22:34 +1000 schrieb Lex Trotman:
Alright, I did a svn up in the branch, at it's still atr3952. And my patch is against that revision. Could it be local changes on your side?
Most probably, as I said its still under active development, but at the moment I have a persistent crash so I don't want to commit a more broken program than is already there :-(
Don't be afraid to do some more commits. Also I had good experience developing using a local git branch so I keep track on my changes as well as I can patch/merge patches coming in.
In case of the build-system branch, using a local git repository doesn't make sense. The idea of the branch is to constantly work on this code with all the advantages of a source code management system like SVN (even though some of you don't like it) and especially having the history. When using a local git repo and then commit one big chunk of changes, the whole idea of the branch is destroyed.
I forgot to mention, committing such big chunks makes it also way more complicate to review the changes which we need to do at some point. And reviewing a super big maybe 100K or more patch is awful. So, small and logical structured commits would help us all most, I think.
Regards, Enrico
You can also commit each git commit seperately. Actually, that's being done by default (with git svn).
Best regards.
On Thu, 16 Jul 2009 18:24:14 +0200, Thomas wrote:
Enrico Tröger schrieb:
On Thu, 16 Jul 2009 18:17:10 +0200, Enrico wrote:
On Mon, 13 Jul 2009 14:55:20 +0200, Frank wrote:
Am Montag, den 13.07.2009, 22:34 +1000 schrieb Lex Trotman:
Alright, I did a svn up in the branch, at it's still atr3952. And my patch is against that revision. Could it be local changes on your side?
Most probably, as I said its still under active development, but at the moment I have a persistent crash so I don't want to commit a more broken program than is already there :-(
Don't be afraid to do some more commits. Also I had good experience developing using a local git branch so I keep track on my changes as well as I can patch/merge patches coming in.
In case of the build-system branch, using a local git repository doesn't make sense. The idea of the branch is to constantly work on this code with all the advantages of a source code management system like SVN (even though some of you don't like it) and especially having the history. When using a local git repo and then commit one big chunk of changes, the whole idea of the branch is destroyed.
I forgot to mention, committing such big chunks makes it also way more complicate to review the changes which we need to do at some point. And reviewing a super big maybe 100K or more patch is awful. So, small and logical structured commits would help us all most, I think.
You can also commit each git commit seperately. Actually, that's being done by default (with git svn).
Sure but it didn't happen really so far. But I must admit, I didn't have the time to read each commit carefully enough.
Just take the message of my both previous posts as a general advice for the future :).
Regards, Enrico
Sorry for the late reply.
On Thu, 16 Jul 2009 18:20:09 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
In case of the build-system branch, using a local git repository doesn't make sense. The idea of the branch is to constantly work on this code with all the advantages of a source code management system like SVN (even though some of you don't like it) and especially having the history. When using a local git repo and then commit one big chunk of changes, the whole idea of the branch is destroyed.
I forgot to mention, committing such big chunks makes it also way more complicate to review the changes which we need to do at some point. And reviewing a super big maybe 100K or more patch is awful. So, small and logical structured commits would help us all most, I think.
I fully agree on this. A local [Git] repository is sometimes fine for a series of commits which are all partial work in progress, but it's best to commit to the main SVN repo as soon as there's enough for a commit that others might want to see. (This may mean changing your workflow to allow regular commits).
Reviewing more than one functional change at once is much more difficult.
Regards, Nick
Lex Trotman schrieb:
2009/7/13 Thomas Martitz <thomas.martitz@student.htw-berlin.de mailto:thomas.martitz@student.htw-berlin.de>
Lex Trotman schrieb: I tried to apply your patch to my working copy but 25 out of 27 chunks were rejected, thats the problem with patches on a rapidly changing source. The patch is made off the branch, I'm fairly sure (going by the IRC bot) that there hasn't been much commits in the meantime. Oh yes, It must have been made out of the branch, the trunk build.c is VERY different, this build.c is a significant re-write. The problem most likely is that there are still significant things being done to build.c to reduce the list of known bugs, limits and incompletes. Alright, I did a svn up in the branch, at it's still at r3952. And my patch is against that revision. Could it be local changes on your side?Most probably, as I said its still under active development, but at the moment I have a persistent crash so I don't want to commit a more broken program than is already there :-(
No problem (active developement is a good thing!), but don't accuse me of posting broken patches please :)
Best regards.
2009/7/14 Thomas Martitz thomas.martitz@student.htw-berlin.de
Lex Trotman schrieb:
2009/7/13 Thomas Martitz <thomas.martitz@student.htw-berlin.de mailto: thomas.martitz@student.htw-berlin.de>
Lex Trotman schrieb:
I tried to apply your patch to my working copy but 25 out of 27 chunks were rejected, thats the problem with patches on a rapidly changing source. The patch is made off the branch, I'm fairly sure (going by the IRC bot) that there hasn't been much commits in the meantime. Oh yes, It must have been made out of the branch, the trunk build.c is VERY different, this build.c is a significant re-write. The problem most likely is that there are still significant things being done to build.c to reduce the list of known bugs, limits and incompletes.Alright, I did a svn up in the branch, at it's still at r3952. And my patch is against that revision. Could it be local changes on your side?
Most probably, as I said its still under active development, but at the moment I have a persistent crash so I don't want to commit a more broken program than is already there :-(
No problem (active developement is a good thing!), but don't accuse me of posting broken patches please :)
Goodness, sorry you interpreted it that way, I always meant that it was due to changes in my working directory, it hadn't occurred to me that you might think I was blaming the problem on your patch.
Cheers Lex
Best regards. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 13 Jul 2009 01:37:51 +0200, Thomas wrote:
The patch is made off the branch, I'm fairly sure (going by the IRC bot) that there hasn't been much commits in the meantime.
Never ever trust this bot, really :). For two reasons: first, the bot relies on the Sourceforge commit mails, which seem to work reliable lately but this wasn't always the case. And then, the bot sometimes get off the network, or it dies because of a reboot of the host or because of network problems.
svn up && svn info
is more reliable even though slower.
Regards, Enrico
Hi.
This is a great addition, thanks. A couple of quick remarks before I'll test it further:
On Thu, 9 Jul 2009 17:25:33 +1000 Lex Trotman elextr@gmail.com wrote:
- Configuration sourced from project if open, preferences, filetypes,
defaults (in that order)
Can it be that you don't take the user-defined filedefs under ~/.config/geany/filedefs into account? I have an own filedef for haxe e.g. but the configuration dialog shows the compile and execute entries of the general filedef.
- The maximum number of items in each section of the build menu is
configurable
Where can that be configured?
- New configuration dialog in the build menu
There's a typo: "Non Filetype Commands" and "Execute Commands" instead of "Comamnds", but I guess the dialog is preliminary for testing anyway.
-- Mockey
2009/7/13 Andreas Mokros am@medienpensionat.com
Hi.
This is a great addition, thanks. A couple of quick remarks before I'll test it further:
On Thu, 9 Jul 2009 17:25:33 +1000 Lex Trotman elextr@gmail.com wrote:
- Configuration sourced from project if open, preferences, filetypes,
defaults (in that order)
Can it be that you don't take the user-defined filedefs under ~/.config/geany/filedefs into account? I have an own filedef for haxe e.g. but the configuration dialog shows the compile and execute entries of the general filedef.
Sorry that the short summary in the announcement email isn't clear, as the table in the manual states, preferences is the ~/.config/geany filetypes files. It is worth a quick look at this table (near the end of the build menu section) because the sources used for load and save vary depending on which group the menu item is in (filetype, non-filetype and execute).
- The maximum number of items in each section of the build menu is
configurable
Where can that be configured?
There are three hidden settings, in the config file in the [build-menu] section called number_ft_menu_items, number_non_ft_menu_items and number_exec_menu_items which set the number in each group of items. They will be added to the config section of the manual when it gets updated. If you test them, remember that for the moment only one execute is working.
- New configuration dialog in the build menu
There's a typo: "Non Filetype Commands" and "Execute Commands" instead of "Comamnds", but I guess the dialog is preliminary for testing anyway.
Thanks, wil be in next svn commit, I've looked at that dialog maybe 100 times in the last weeks and not spotted it.
-- Mockey _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi.
On Mon, 13 Jul 2009 11:18:08 +1000 Lex Trotman elextr@gmail.com wrote:
Sorry that the short summary in the announcement email isn't clear, as the table in the manual states, preferences is the ~/.config/geany filetypes files. It is worth a quick look at this table (near the end of the build menu section) because the sources used for load and save vary depending on which group the menu item is in (filetype, non-filetype and execute).
I had a look at that table. I think the problem was that I had no [build-menu]-entries in my own filedef, just the old [build-settings] and *then* the menu showed the [build-settings] of the general filedef. Now with some [build-menu]-entries in my filedef it works correctly. Just a minor issue and a bit irritating.
There are three hidden settings, in the config file in the [build-menu] section called number_ft_menu_items,
Ok. Will try that.
-- Mockey
2009/7/13 Andreas Mokros am@medienpensionat.com
Hi.
On Mon, 13 Jul 2009 11:18:08 +1000 Lex Trotman elextr@gmail.com wrote:
Sorry that the short summary in the announcement email isn't clear, as the table in the manual states, preferences is the ~/.config/geany filetypes files. It is worth a quick look at this table (near the end of the build menu section) because the sources used for load and save vary depending on which group the menu item is in (filetype, non-filetype and execute).
I had a look at that table. I think the problem was that I had no [build-menu]-entries in my own filedef, just the old [build-settings] and *then* the menu showed the [build-settings] of the general filedef. Now with some [build-menu]-entries in my filedef it works correctly. Just a minor issue and a bit irritating.
In an attempt to get backward compatability I try to load old format files but don't write the new [build-menu] section until something is changed, then the system works as it used to until it is configured. Once something is changed the old settings are ignored. This allows old versions of Geany to co-exist with the new one (at least it does for me).
But I can't get a good mapping from the old filedefs to the new settings so I did the best I could, but there are some side effects.
Any better suggestions are welcome.
The only alternative is to ignore the old settings and re-write ALL the filedefs to the new format prior to release and I don't want to do that. Also then user changes couldn't be imported so thats probably not a good idea anyway.
There are also a significant number of fixes in my working directory , but at the moment I have a regular crash so I don't want to commit it just yet. Maybe tomorrow.
Cheers Lex
There are three hidden settings, in the config file in the [build-menu] section called number_ft_menu_items,
Ok. Will try that.
-- Mockey _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi.
On Thu, 9 Jul 2009 17:25:33 +1000 Lex Trotman elextr@gmail.com wrote:
- Very limited testing so far (C/C++ filetypes only)
OK. Did some testing with haxe files now.
The "build"-button in the toolbar doesn't seem to work correctly. By default it is disabled for haxe files. Adding a "_Build" command under "Haxe source file commands" enables the button, but clicking on it runs the command for "_Compile". Also the "Compile"-entry is missing in the dropdown menu called from the button.
The Build main menu works correctly, though. [build-menu]-entries are correctly added to the project file and the haxe-filedef.
-- Mockey
On Mon, 13 Jul 2009 01:41:03 +0200 Andreas Mokros am@medienpensionat.com wrote:
OK. Did some testing with haxe files now.
Another thing: Closing a project apparently crashes Geany (switching to another project seems to work).
-- Mockey
Andreas,
I can't repeat it here, if you can get it to occur repeatedly please run Geany in the debugger and attach the backtrace (bt command) and the project settings/file. Actually my 0.17 did crash on closing yesterday, but it had been running all day and I figured it was just tired;-) but maybe there is an intermittent problem in the underlying code, anyway lets see if you can get the backtrace.
Cheers Lex
2009/7/13 Andreas Mokros am@medienpensionat.com
On Mon, 13 Jul 2009 01:41:03 +0200 Andreas Mokros am@medienpensionat.com wrote:
OK. Did some testing with haxe files now.
Another thing: Closing a project apparently crashes Geany (switching to another project seems to work).
-- Mockey _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 13 Jul 2009 12:24:53 +1000 Lex Trotman elextr@gmail.com wrote:
I can't repeat it here, if you can get it to occur repeatedly please run Geany in the debugger and attach the backtrace (bt command) and the project settings/file.
I'm a bit in hurry now, so here's just the output of geany -v after closing a project file: (geany:5536): GLib-CRITICAL **: g_ptr_array_foreach: assertion `array' failed (geany:5536): GLib-CRITICAL **: g_key_file_set_string_list: assertion `list != NULL' failed (geany:5536): GLib-CRITICAL **: g_ptr_array_foreach: assertion `array' failed (geany:5536): GLib-CRITICAL **: g_ptr_array_free: assertion `array' failed Segmentation fault
Same messages show when switching a project, just without the segfault. So there seems to be something wrong with project handling in your branch. Doesn't happen with the latest trunk.
-- Mockey
Thanks, I don't get these messages or the crash so hopefully its already fixed in next commit.
Cheers Lex
2009/7/13 Andreas Mokros am@medienpensionat.com
On Mon, 13 Jul 2009 12:24:53 +1000 Lex Trotman elextr@gmail.com wrote:
I can't repeat it here, if you can get it to occur repeatedly please run Geany in the debugger and attach the backtrace (bt command) and the project settings/file.
I'm a bit in hurry now, so here's just the output of geany -v after closing a project file: (geany:5536): GLib-CRITICAL **: g_ptr_array_foreach: assertion `array' failed (geany:5536): GLib-CRITICAL **: g_key_file_set_string_list: assertion `list != NULL' failed (geany:5536): GLib-CRITICAL **: g_ptr_array_foreach: assertion `array' failed (geany:5536): GLib-CRITICAL **: g_ptr_array_free: assertion `array' failed Segmentation fault
Same messages show when switching a project, just without the segfault. So there seems to be something wrong with project handling in your branch. Doesn't happen with the latest trunk.
-- Mockey _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
2009/7/13 Andreas Mokros am@medienpensionat.com
Hi.
On Thu, 9 Jul 2009 17:25:33 +1000 Lex Trotman elextr@gmail.com wrote:
- Very limited testing so far (C/C++ filetypes only)
OK. Did some testing with haxe files now.
The "build"-button in the toolbar doesn't seem to work correctly. By default it is disabled for haxe files. Adding a "_Build" command under "Haxe source file commands" enables the button,
See comment below, looks like special handling is needed for build toolbutton.
but clicking on it runs the command for "_Compile". Also the "Compile"-entry is missing in the dropdown menu called from the button.
I havn't actually done anything with the toolbar code except point the activate at the new menu items (tool buttons mostly work by activating the respective menu item). I wasn't aware of the dropdown since I don't use the build toolbar item (I use the F9 key). Its not surprising then that it doesn't work right and I'm surprised it works at all.
I had a look at the code and I can't find where that submenu is created, can someone please provide guidance??
The Build main menu works correctly, though. [build-menu]-entries are correctly added to the project file and the haxe-filedef.
-- Mockey _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Cheers, thanks for the testing Lex
On Mon, 13 Jul 2009 12:50:09 +1000 Lex Trotman elextr@gmail.com wrote:
I wasn't aware of the dropdown since I don't use the build toolbar item (I use the F9 key). Its not surprising then that it doesn't work right and I'm surprised it works at all.
I see. It's quite new and I think it's more convenient than the normal menu. Shouldn't be too difficult to fix, though.
-- Mockey
On Mon, 13 Jul 2009 12:50:09 +1000, Lex wrote:
2009/7/13 Andreas Mokros am@medienpensionat.com
Hi.
On Thu, 9 Jul 2009 17:25:33 +1000 Lex Trotman elextr@gmail.com wrote:
- Very limited testing so far (C/C++ filetypes only)
OK. Did some testing with haxe files now.
The "build"-button in the toolbar doesn't seem to work correctly. By default it is disabled for haxe files. Adding a "_Build" command under "Haxe source file commands" enables the button,
See comment below, looks like special handling is needed for build toolbutton.
but clicking on it runs the command for "_Compile". Also the "Compile"-entry is missing in the dropdown menu called from the button.
I havn't actually done anything with the toolbar code except point the activate at the new menu items (tool buttons mostly work by activating the respective menu item). I wasn't aware of the dropdown since I don't use the build toolbar item (I use the F9 key). Its not surprising then that it doesn't work right and I'm surprised it works at all.
I had a look at the code and I can't find where that submenu is created, can someone please provide guidance??
The submenu is created in src/toolbar.c, it's an instance of geanymenubuttonaction.c. It depends when you re-created the branch, there were some changes/fixes to this recently (maybe two or three weeks ago, when I added the toolbar editor) to that code. So, maybe a sync with trunk is helpful. Otherwise, tell me exactly what's the problem, then I'll have a look.
Btw, current SVN crashes in src/build.c:1549. The free() on labeltxt is wrong because labeltxt isn't allocated nor initialised before, i guess just a typo :).
Regards, Enrico
Btw, current SVN crashes in src/build.c:1549. The free() on labeltxt is wrong because labeltxt isn't allocated nor initialised before, i guess just a typo :).
fixed thanks incompletely removed unused code at the last minute, pity it didn't crash for me, labeltxt must have happened to be NULL so g_free was happy.
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
2009/7/17 Enrico Tröger enrico.troeger@uvena.de:
On Mon, 13 Jul 2009 12:50:09 +1000, Lex wrote:
2009/7/13 Andreas Mokros am@medienpensionat.com
Hi.
On Thu, 9 Jul 2009 17:25:33 +1000 Lex Trotman elextr@gmail.com wrote:
- Very limited testing so far (C/C++ filetypes only)
OK. Did some testing with haxe files now.
The "build"-button in the toolbar doesn't seem to work correctly. By default it is disabled for haxe files. Adding a "_Build" command under "Haxe source file commands" enables the button,
See comment below, looks like special handling is needed for build toolbutton.
but clicking on it runs the command for "_Compile". Also the "Compile"-entry is missing in the dropdown menu called from the button.
I havn't actually done anything with the toolbar code except point the activate at the new menu items (tool buttons mostly work by activating the respective menu item). I wasn't aware of the dropdown since I don't use the build toolbar item (I use the F9 key). Its not surprising then that it doesn't work right and I'm surprised it works at all.
I had a look at the code and I can't find where that submenu is created, can someone please provide guidance??
The submenu is created in src/toolbar.c, it's an instance of geanymenubuttonaction.c. It depends when you re-created the branch, there were some changes/fixes to this recently (maybe two or three weeks ago, when I added the toolbar editor) to that code. So, maybe a sync with trunk is helpful.
Done, compiles and runs!!! I promise not to complain about the time daily commits take after that svn marathon ;-(
Otherwise, tell me exactly what's the problem, then I'll have a look.
Now I know where I'll have a look first, it probably just needs to point to the right menu items again.
Btw, current SVN crashes in src/build.c:1549. The free() on labeltxt is wrong because labeltxt isn't allocated nor initialised before, i guess just a typo :).
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Enrico,
Otherwise, tell me exactly what's the problem, then I'll have a look.
Now I know where I'll have a look first, it probably just needs to point to the right menu items again.
Ok, I'm lost again, for me the build toolbar menu is never enabled, the toolbutton is there ok and works but wrong. I can't find where the menu is enabled?
The build toolbar button runs the compile command. This is because the build_toolbutton_build_clicked user_data is always 0. It used to be GBO_BUILD. Where is it set now?
Cheers Lex
Btw, current SVN crashes in src/build.c:1549. The free() on labeltxt is wrong because labeltxt isn't allocated nor initialised before, i guess just a typo :).
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 17 Jul 2009 18:13:18 +1000, Lex wrote:
Enrico,
Otherwise, tell me exactly what's the problem, then I'll have a look.
Now I know where I'll have a look first, it probably just needs to point to the right menu items again.
Ok, I'm lost again, for me the build toolbar menu is never enabled, the toolbutton is there ok and works but wrong. I can't find where the menu is enabled?
Well, the menu itself is created in build_init(). And it seems while merging with trunk there went something wrong. The build_init() code in your branch has still the old menu handling code. The main thing is that in your branch the final call /* set the submenu to the toolbar item */ geany_menu_button_action_set_menu(GEANY_MENU_BUTTON_ACTION (widgets.build_action), toolmenu);
is missing in build_init(). And also the other code handling the button menu seems to be old. You should update it or tell me to do so if you don't want to.
The build toolbar button runs the compile command. This is because the build_toolbutton_build_clicked user_data is always 0. It used to be GBO_BUILD. Where is it set now?
Er, the build button callback user_data was always NULL. The NULL is set in src/toolbar.c:345. The build button should run the GBO_BUILD command unless any other build action from the menu was chosen. Then the build button runs the last chosen action. This is done in build_toolbutton_build_clicked() and there the user_data isn't taken into account. Maybe you changed the semantics in on_build_menu_item() but this can be easily changed with the attached patch (build_button_fix.diff) which explicitly call the GBO_BUILD action on on_build_menu_item().
Regards, Enrico
2009/7/18 Enrico Tröger enrico.troeger@uvena.de:
On Fri, 17 Jul 2009 18:13:18 +1000, Lex wrote:
Enrico,
Otherwise, tell me exactly what's the problem, then I'll have a look.
Now I know where I'll have a look first, it probably just needs to point to the right menu items again.
Ok, I'm lost again, for me the build toolbar menu is never enabled, the toolbutton is there ok and works but wrong. I can't find where the menu is enabled?
Well, the menu itself is created in build_init(). And it seems while merging with trunk there went something wrong.
Ah yes well, what went wrong was me, build.c not surprisingly needed to be merged manually, and I assumed most differences were changes on my side.
After a three way diff with an original build.c, trunk and build-system versions I think I have now incorporated the changes somewhat better. It would be good if you could check it though.
I have commented out execute/stop button code because now that multiple executes are possible the question is, which one does the button execute/stop??
The build_init() code in
your branch has still the old menu handling code. The main thing is that in your branch the final call /* set the submenu to the toolbar item */ geany_menu_button_action_set_menu(GEANY_MENU_BUTTON_ACTION (widgets.build_action), toolmenu);
is missing in build_init().
Well THAAAAATS why I couldn't find it!!! :-)
And also the other code handling the button
menu seems to be old. You should update it or tell me to do so if you don't want to.
Done as best I can. Please check.
The build toolbar button runs the compile command. This is because the build_toolbutton_build_clicked user_data is always 0. It used to be GBO_BUILD. Where is it set now?
Er, the build button callback user_data was always NULL. The NULL is set in src/toolbar.c:345. The build button should run the GBO_BUILD command unless any other build action from the menu was chosen. Then the build button runs the last chosen action. This is done in build_toolbutton_build_clicked() and there the user_data isn't taken into account. Maybe you changed the semantics in on_build_menu_item() but this can be easily changed with the attached patch (build_button_fix.diff) which explicitly call the GBO_BUILD action on on_build_menu_item().
Ok, I had just copied the way the old build_toolbutton_build_clicked worked? But I am not sure how it actually worked then?? But it works now so who cares!!!! Thanks.
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 18 Jul 2009 21:12:26 +1000, Lex wrote:
I have commented out execute/stop button code because now that multiple executes are possible the question is, which one does the button execute/stop??
Not sure. New features, new problems, haha. Maybe it's enough to let the Run/Stop button stick to the first Run command and maybe add the second Run command to the Build button's menu.
And also the other code handling the button
menu seems to be old. You should update it or tell me to do so if you don't want to.
Done as best I can. Please check.
I found only a little thing which was missing, see attached patch.
The build toolbar button runs the compile command. This is because the build_toolbutton_build_clicked user_data is always 0. It used to be GBO_BUILD. Where is it set now?
Er, the build button callback user_data was always NULL. The NULL is set in src/toolbar.c:345. The build button should run the GBO_BUILD command unless any other build action from the menu was chosen. Then the build button runs the last chosen action. This is done in build_toolbutton_build_clicked() and there the user_data isn't taken into account. Maybe you changed the semantics in on_build_menu_item() but this can be easily changed with the attached patch (build_button_fix.diff) which explicitly call the GBO_BUILD action on on_build_menu_item().
Ok, I had just copied the way the old build_toolbutton_build_clicked worked? But I am not sure how it actually worked then?? But it works now so who cares!!!! Thanks.
Hehe. Tested the Build button + menu and it seems to work as in trunk, so it's all fine for now.
Regards, Enrico
Am Donnerstag, den 09.07.2009, 17:25 +1000 schrieb Lex Trotman:
Hi All,
The first alpha release of a version of Geany with flexible configuration of the Build Menu is available in the build-system branch of svn, https://geany.svn.sourceforge.net/svnroot/geany/branches/build-system/
This release is still under active development (see Known Bugs, Limits and Incomplete below) and is released to allow consideration of the functionality and how it might impact/assist other Geany activity.
I've tested it with Ubuntu 9.04 x86 inside virtual box and had an compiling warning with current r3952
[137/192] cc: src/build.c -> _build_/default/src/build_3.o ../src/build.c: In function 'save_build_menu': ../src/build.c:1959: warning: passing argument 4 of 'g_key_file_set_string_list' from incompatible pointer type
I didn't take any look onto code so far, but maybe you can have one.
cheers, Frank
Thanks Frank, fixed. Will be in my next SVN commit. Lex
2009/7/13 Frank Lanitz frank@frank.uvena.de
Am Donnerstag, den 09.07.2009, 17:25 +1000 schrieb Lex Trotman:
Hi All,
The first alpha release of a version of Geany with flexible configuration of the Build Menu is available in the build-system branch of svn, https://geany.svn.sourceforge.net/svnroot/geany/branches/build-system/
This release is still under active development (see Known Bugs, Limits and Incomplete below) and is released to allow consideration of the functionality and how it might impact/assist other Geany activity.
I've tested it with Ubuntu 9.04 x86 inside virtual box and had an compiling warning with current r3952
[137/192] cc: src/build.c -> _build_/default/src/build_3.o ../src/build.c: In function 'save_build_menu': ../src/build.c:1959: warning: passing argument 4 of 'g_key_file_set_string_list' from incompatible pointer type
I didn't take any look onto code so far, but maybe you can have one.
cheers, Frank
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Lex Trotman schrieb:
Known Bugs, Limits and Incomplete (in no particular order)
- Latex doesn't work yet, all the hard coded functionality has been
removed but the filetype hasn't been updated to configure it back.
- Only one execute command is currently supported/working
- Dialog entries in preferences and project, for settings that are
replaced by the new dialogs, have not been removed yet, but they probably do nothing
- Error regex setting field in the new dialog does nothing yet
- Not compiled at all on windows
- Very limited testing so far (C/C++ filetypes only)
- Sections of the manual other than build menu have not been changed,
eg file formats, hidden settings any sections that reference build menu etc
I might add crashes when changing projects (close one and open another) which doesn't happen with trunk. Enrico also reported crashes on plain opening. Here's his backtrace: http://nopaste.geany.org/p/m4f327d9c
Best regards.
2009/7/25 Thomas Martitz thomas.martitz@student.htw-berlin.de:
Lex Trotman schrieb:
Known Bugs, Limits and Incomplete (in no particular order)
- Latex doesn't work yet, all the hard coded functionality has been
removed but the filetype hasn't been updated to configure it back.
- Only one execute command is currently supported/working
- Dialog entries in preferences and project, for settings that are
replaced by the new dialogs, have not been removed yet, but they probably do nothing
- Error regex setting field in the new dialog does nothing yet
- Not compiled at all on windows
- Very limited testing so far (C/C++ filetypes only)
- Sections of the manual other than build menu have not been changed, eg
file formats, hidden settings any sections that reference build menu etc
I might add crashes when changing projects
I wouldn't, I would add if you find a bug report it with usefull info like Enrico did.
(close one and open another)
which doesn't happen with trunk. Enrico also reported crashes on plain opening. Here's his backtrace: http://nopaste.geany.org/p/m4f327d9c
Can't replicate crash on project open, crash on change S/B fixed and should also fix likely cause of crash on open. Crash on open may depend on content of project file, if it still occurs with r4026 or greater please report with content of [build-settings] and [build-menu] sections of file.
Also fixed the GLib warnings. IMHO this is a GLib problem, NULL pointers are ignored, so why try to assert that they are arrays???
Regards Lex
Best regards. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 25 Jul 2009 15:37:47 +1000, Lex wrote:
which doesn't happen with trunk. Enrico also reported crashes on plain opening. Here's his backtrace: http://nopaste.geany.org/p/m4f327d9c
Can't replicate crash on project open, crash on change S/B fixed and should also fix likely cause of crash on open. Crash on open may depend on content of project file, if it still occurs with r4026 or greater please report with content of [build-settings] and [build-menu] sections of file.
It seems to work fine now. I can't reproduce the crashes anymore neither by opening a project nor by switching between projects (which is basically the same as simply close&open a project).
Also fixed the GLib warnings. IMHO this is a GLib problem, NULL pointers are ignored, so why try to assert that they are arrays???
If I read the diff correctly, you passed a NULL pointer to g_ptr_array_foreach() and g_ptr_array_freee() as first argument. This is simply wrong and so IMO the warning is correct. Who said NULL pointers are ignored? Most functions expect non-NULL arguments for any pointers usually unless stated otherwise. The good thing in most GLib/GTK/Geany is that you get a warning if you do it anyway. Other functions like glibc's string functions (e.g. strlen() or strcmp()) simply segfault when a NULL pointer is passed.
Regards, Enrico
Lex Trotman schrieb:
Hi All,
The first alpha release of a version of Geany with flexible configuration of the Build Menu is available in the build-system branch of svn, https://geany.svn.sourceforge.net/svnroot/geany/branches/build-system/
I'm loving this branch already, and use it on a daily basis (no major problems so far).
However, it IMO lacks something important: A away to cancel the processes. I'm right now forced to switch to the VTE to type "killall -9 make" which isn't nice you know. The classic way, that the compile button turns into a stop button while compiling doesn't seem to work.
Best regards.
Hi Thomas,
Good to hear that there are no major problems.
I can see that you may want to kill a long build that you started by accident or when you realise you forgot to do something first. I've done that more than once ;-)
In Geany execute changes to stop while running, but build doesn't.
The difference is because they are run in different ways, execute runs in a terminal (either external or VTE) but build commands are run directly so that no terminal window pops up and so that the output can be captured for parsing for errors. Due to problems on windows, builds have to be run synchronously on windows, ie the whole of Geany freezes while the build runs (why? I don't understand exactly, maybe Enrico can explain it). That means that cancelling a windows build can't be done from Geany anyway.
Whilst Linux builds are still asynchronous only one is allowed at a time so that output isn't mixed up in the error parser. So all build commands are set insensitive until completion. To have one menu item still enabled and to have it change to stop is going to be quite a bit of fiddling unless it is always a fixed menu item or a toolbar button.
But as a general action I would be worried about killing a build anyway.
Geany only knows about the parent process, the top level make, not any children that make forked to process subdirectories, or because -j was used, and they won't get killed (they migrate to be children of init). The overall impact is not well defined, but killing a top level make may leave most of the build still running. Now setting the build menu items sensitive and so enabling another build is risky.
And the results of builders other than make is even less well defined.
I think we need to consider this a bit more first to find a safe general solution.
In the interim why don't you configure an extra execute command to run the "killall -9 make". It can then run asynchronously whilst the build is running.
Cheers Lex
2009/8/16 Thomas Martitz thomas.martitz@student.htw-berlin.de:
Lex Trotman schrieb:
Hi All,
The first alpha release of a version of Geany with flexible configuration of the Build Menu is available in the build-system branch of svn, https://geany.svn.sourceforge.net/svnroot/geany/branches/build-system/
I'm loving this branch already, and use it on a daily basis (no major problems so far).
However, it IMO lacks something important: A away to cancel the processes. I'm right now forced to switch to the VTE to type "killall -9 make" which isn't nice you know. The classic way, that the compile button turns into a stop button while compiling doesn't seem to work.
Best regards. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Lex Trotman schrieb:
Hi Thomas,
Good to hear that there are no major problems.
I can see that you may want to kill a long build that you started by accident or when you realise you forgot to do something first. I've done that more than once ;-)
In Geany execute changes to stop while running, but build doesn't.
The difference is because they are run in different ways, execute runs in a terminal (either external or VTE) but build commands are run directly so that no terminal window pops up and so that the output can be captured for parsing for errors. Due to problems on windows, builds have to be run synchronously on windows, ie the whole of Geany freezes while the build runs (why? I don't understand exactly, maybe Enrico can explain it). That means that cancelling a windows build can't be done from Geany anyway.
Whilst Linux builds are still asynchronous only one is allowed at a time so that output isn't mixed up in the error parser. So all build commands are set insensitive until completion. To have one menu item still enabled and to have it change to stop is going to be quite a bit of fiddling unless it is always a fixed menu item or a toolbar button.
Seeing that the Run commands don't gray out too, I think adding a cancel button which doesn't gray out is going to be doable without a lot of fiddling.
But as a general action I would be worried about killing a build anyway.
Geany only knows about the parent process, the top level make, not any children that make forked to process subdirectories, or because -j was used, and they won't get killed (they migrate to be children of init). The overall impact is not well defined, but killing a top level make may leave most of the build still running. Now setting the build menu items sensitive and so enabling another build is risky.
And the results of builders other than make is even less well defined.
The Rockbox build system (see [1]) has a way to kill builds (even those which are started with -jX) using this snippet of perl code. Note that kill here is a perl function, which does IIUC killing the childs for us (it kills the process groups if the signal parameter is negative). I don't know if it helps us though. Could one try call the perl function from within geany with a crude hack/magic?
sub killchild { my ($id) = @_;
return if (not defined $builds{$id});
my $pipe = $builds{$id}{pipe}; $read_set->remove($pipe);
$busy -= $builds{$id}{cores};
my $pid = $builds{$id}{pid}; kill -9, $pid; tprint "Killed build $id\n"; waitpid $pid, 0;
my $dir = "$cwd/build-$pid"; if (-d $dir) { tprint "Removing $dir\n"; rmtree $dir; }
delete $builds{$id}; }
I think we need to consider this a bit more first to find a safe general solution.
In the interim why don't you configure an extra execute command to run the "killall -9 make". It can then run asynchronously whilst the build is running.
Because my run (and build) command list is full ;)
Best regards.
[1] http://daniel.haxx.se/blog/2009/07/05/concepts-of-a-new-distributed-build/
2009/8/16 Thomas Martitz thomas.martitz@student.htw-berlin.de:
Lex Trotman schrieb:
Hi Thomas,
Good to hear that there are no major problems.
I can see that you may want to kill a long build that you started by accident or when you realise you forgot to do something first. I've done that more than once ;-)
In Geany execute changes to stop while running, but build doesn't.
The difference is because they are run in different ways, execute runs in a terminal (either external or VTE) but build commands are run directly so that no terminal window pops up and so that the output can be captured for parsing for errors. Due to problems on windows, builds have to be run synchronously on windows, ie the whole of Geany freezes while the build runs (why? I don't understand exactly, maybe Enrico can explain it). That means that cancelling a windows build can't be done from Geany anyway.
Whilst Linux builds are still asynchronous only one is allowed at a time so that output isn't mixed up in the error parser. So all build commands are set insensitive until completion. To have one menu item still enabled and to have it change to stop is going to be quite a bit of fiddling unless it is always a fixed menu item or a toolbar button.
Seeing that the Run commands don't gray out too, I think adding a cancel button which doesn't gray out is going to be doable without a lot of fiddling.
But as a general action I would be worried about killing a build anyway.
Geany only knows about the parent process, the top level make, not any children that make forked to process subdirectories, or because -j was used, and they won't get killed (they migrate to be children of init). The overall impact is not well defined, but killing a top level make may leave most of the build still running. Now setting the build menu items sensitive and so enabling another build is risky.
And the results of builders other than make is even less well defined.
The Rockbox build system (see [1]) has a way to kill builds (even those which are started with -jX) using this snippet of perl code. Note that kill here is a perl function, which does IIUC killing the childs for us (it kills the process groups if the signal parameter is negative). I don't know if it helps us though. Could one try call the perl function from within geany with a crude hack/magic?
Um no, that would require Geany to have a dependency on Perl, and I doubt that such a requirement would be acceptable to the general Geany community.
I havn't written perl for a while but this seems to depend on the global builds variable, whats that got in it and where was it set??
sub killchild { my ($id) = @_;
return if (not defined $builds{$id});
my $pipe = $builds{$id}{pipe}; $read_set->remove($pipe);
$busy -= $builds{$id}{cores};
my $pid = $builds{$id}{pid}; kill -9, $pid; tprint "Killed build $id\n"; waitpid $pid, 0;
my $dir = "$cwd/build-$pid"; if (-d $dir) { tprint "Removing $dir\n"; rmtree $dir; }
delete $builds{$id}; }
I actually got interested in adding the configurability to Geany build system when an organisation I was consulting to was using Geany but running builds on a server farm with several versions of Linux, AIX, HP-UX, Solaris and several windows versions. And different pieces of software from many different sources used many different build systems, hence the need for configurability.
Of course such remote jobs won't be touched by any signals.
According to the reference you provided on Rockbox it does remote builds by copying data from SVN and then copying the results back. So a remote build can be cancelled by its special server on the remote system (I guess thats where the perl snippet came from) and thrown away and no corruption is possible, but our system used shared sources for all machines and locks to control multiple build interactions. Killing things could leave locks about and block builds until someone removed them manually. Worse some pieces of software could corrupt the build tree if cancelled (sure they were lousy build scripts, but we used software from lots of places and didn't want to touch such things unless absolutely required)
While such a system is unusual, it made me very aware that the area of child processes in Unix (ignoring windows) is very flexible and not always fully standardised ( eg Linux pre 2.6 is not exactly POSIX). Remember even if it doesn't run something remote, a build could easily spawn background processes that can't be killed from the parent because they are not part of the same process group, so if the perl function only kills the group it still won't get them.
And your killall only works because you know that you are the only make running on your machine, it would be considered impolite if you were to kill someone else's make by accident :-)
Its an area where caution is required to avoid real problems. If you have a solution that works for you, great!! Configure it for yourself, but it can't be offered as a general solution unless safe (oh, and useful ;-)
I think we need to consider this a bit more first to find a safe general solution.
In the interim why don't you configure an extra execute command to run the "killall -9 make". It can then run asynchronously whilst the build is running.
Because my run (and build) command list is full ;)
I keep running out too :-D
With the build-system branch the hidden preference number_exec_menu_items can be set to increase the number of execute commands, see the build-system version of geany.html preferences file format section.
Filetype and non-filetype numbers can also be increased so you can add make commands too (you can't decrease them). Close and re-open Geany before they take effect.
Cheers Lex
Best regards.
[1] http://daniel.haxx.se/blog/2009/07/05/concepts-of-a-new-distributed-build/ _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Lex Trotman schrieb:
2009/8/16 Thomas Martitz thomas.martitz@student.htw-berlin.de:
Lex Trotman schrieb:
Hi Thomas,
Good to hear that there are no major problems.
I can see that you may want to kill a long build that you started by accident or when you realise you forgot to do something first. I've done that more than once ;-)
In Geany execute changes to stop while running, but build doesn't.
The difference is because they are run in different ways, execute runs in a terminal (either external or VTE) but build commands are run directly so that no terminal window pops up and so that the output can be captured for parsing for errors. Due to problems on windows, builds have to be run synchronously on windows, ie the whole of Geany freezes while the build runs (why? I don't understand exactly, maybe Enrico can explain it). That means that cancelling a windows build can't be done from Geany anyway.
Whilst Linux builds are still asynchronous only one is allowed at a time so that output isn't mixed up in the error parser. So all build commands are set insensitive until completion. To have one menu item still enabled and to have it change to stop is going to be quite a bit of fiddling unless it is always a fixed menu item or a toolbar button.
Seeing that the Run commands don't gray out too, I think adding a cancel button which doesn't gray out is going to be doable without a lot of fiddling.
But as a general action I would be worried about killing a build anyway.
Geany only knows about the parent process, the top level make, not any children that make forked to process subdirectories, or because -j was used, and they won't get killed (they migrate to be children of init). The overall impact is not well defined, but killing a top level make may leave most of the build still running. Now setting the build menu items sensitive and so enabling another build is risky.
And the results of builders other than make is even less well defined.
The Rockbox build system (see [1]) has a way to kill builds (even those which are started with -jX) using this snippet of perl code. Note that kill here is a perl function, which does IIUC killing the childs for us (it kills the process groups if the signal parameter is negative). I don't know if it helps us though. Could one try call the perl function from within geany with a crude hack/magic?
Um no, that would require Geany to have a dependency on Perl, and I doubt that such a requirement would be acceptable to the general Geany community.
I havn't written perl for a while but this seems to depend on the global builds variable, whats that got in it and where was it set??
sub killchild { my ($id) = @_;
return if (not defined $builds{$id});
my $pipe = $builds{$id}{pipe}; $read_set->remove($pipe);
$busy -= $builds{$id}{cores};
my $pid = $builds{$id}{pid}; kill -9, $pid; tprint "Killed build $id\n"; waitpid $pid, 0;
my $dir = "$cwd/build-$pid"; if (-d $dir) { tprint "Removing $dir\n"; rmtree $dir; }
delete $builds{$id}; }
I actually got interested in adding the configurability to Geany build system when an organisation I was consulting to was using Geany but running builds on a server farm with several versions of Linux, AIX, HP-UX, Solaris and several windows versions. And different pieces of software from many different sources used many different build systems, hence the need for configurability.
Of course such remote jobs won't be touched by any signals.
According to the reference you provided on Rockbox it does remote builds by copying data from SVN and then copying the results back. So a remote build can be cancelled by its special server on the remote system (I guess thats where the perl snippet came from) and thrown away and no corruption is possible, but our system used shared sources for all machines and locks to control multiple build interactions. Killing things could leave locks about and block builds until someone removed them manually. Worse some pieces of software could corrupt the build tree if cancelled (sure they were lousy build scripts, but we used software from lots of places and didn't want to touch such things unless absolutely required)
Killing is done in the client (the snippet came from rbclient.rb). The server just sends a message CANCEL, the client in turn calls killchild.
Requiring perl is indeed suboptimal, but on the other hands it's really part of the default installation in 99% of all distros, and just about the same percentage of projects require perl already. But I understand that this is unwanted :)
While such a system is unusual, it made me very aware that the area of child processes in Unix (ignoring windows) is very flexible and not always fully standardised ( eg Linux pre 2.6 is not exactly POSIX). Remember even if it doesn't run something remote, a build could easily spawn background processes that can't be killed from the parent because they are not part of the same process group, so if the perl function only kills the group it still won't get them.
And your killall only works because you know that you are the only make running on your machine, it would be considered impolite if you were to kill someone else's make by accident :-)
I know, hence I'm searching for something better. See, I'm running a rockbox build client. Natually, I will kill those makes too if it was running at this very moment.
Its an area where caution is required to avoid real problems. If you have a solution that works for you, great!! Configure it for yourself, but it can't be offered as a general solution unless safe (oh, and useful ;-)
I actually played around a bit, and got a bit farther.
In my quick hack, I use kill(0, SIGTERM) to kill everything that has geanys pid as parent. To not kill geany itself too, I changed the signal handler to something which does nothing (and reverting to SIG_DFL afterwards). That works well, although I don't know which other process geany creates. Also, I think this is really a bad hack :( (isn't it?
What I'm wondering is why doing "kill(build_info.pid, SIGINT)" doesn't work. Isn't that the same as doing CTRL+C when doing make in a terminal manually?
I think we need to consider this a bit more first to find a safe general solution.
In the interim why don't you configure an extra execute command to run the "killall -9 make". It can then run asynchronously whilst the build is running.
Because my run (and build) command list is full ;)
I keep running out too :-D
With the build-system branch the hidden preference number_exec_menu_items can be set to increase the number of execute commands, see the build-system version of geany.html preferences file format section.
The geany.html is currently broken here due to svn merge (which took surprisingly long, some 30min) :D But I did not know that, thanks!
Filetype and non-filetype numbers can also be increased so you can add make commands too (you can't decrease them). Close and re-open Geany before they take effect.
Cheers Lex
2009/8/17 Thomas Martitz thomas.martitz@student.htw-berlin.de:
Lex Trotman schrieb:
2009/8/16 Thomas Martitz thomas.martitz@student.htw-berlin.de:
Lex Trotman schrieb:
Hi Thomas,
Good to hear that there are no major problems.
I can see that you may want to kill a long build that you started by accident or when you realise you forgot to do something first. I've done that more than once ;-)
In Geany execute changes to stop while running, but build doesn't.
The difference is because they are run in different ways, execute runs in a terminal (either external or VTE) but build commands are run directly so that no terminal window pops up and so that the output can be captured for parsing for errors. Due to problems on windows, builds have to be run synchronously on windows, ie the whole of Geany freezes while the build runs (why? I don't understand exactly, maybe Enrico can explain it). That means that cancelling a windows build can't be done from Geany anyway.
Whilst Linux builds are still asynchronous only one is allowed at a time so that output isn't mixed up in the error parser. So all build commands are set insensitive until completion. To have one menu item still enabled and to have it change to stop is going to be quite a bit of fiddling unless it is always a fixed menu item or a toolbar button.
Seeing that the Run commands don't gray out too, I think adding a cancel button which doesn't gray out is going to be doable without a lot of fiddling.
But as a general action I would be worried about killing a build anyway.
Geany only knows about the parent process, the top level make, not any children that make forked to process subdirectories, or because -j was used, and they won't get killed (they migrate to be children of init). The overall impact is not well defined, but killing a top level make may leave most of the build still running. Now setting the build menu items sensitive and so enabling another build is risky.
And the results of builders other than make is even less well defined.
The Rockbox build system (see [1]) has a way to kill builds (even those which are started with -jX) using this snippet of perl code. Note that kill here is a perl function, which does IIUC killing the childs for us (it kills the process groups if the signal parameter is negative). I don't know if it helps us though. Could one try call the perl function from within geany with a crude hack/magic?
Um no, that would require Geany to have a dependency on Perl, and I doubt that such a requirement would be acceptable to the general Geany community.
I havn't written perl for a while but this seems to depend on the global builds variable, whats that got in it and where was it set??
sub killchild { my ($id) = @_;
return if (not defined $builds{$id});
my $pipe = $builds{$id}{pipe}; $read_set->remove($pipe);
$busy -= $builds{$id}{cores};
my $pid = $builds{$id}{pid}; kill -9, $pid; tprint "Killed build $id\n"; waitpid $pid, 0;
my $dir = "$cwd/build-$pid"; if (-d $dir) { tprint "Removing $dir\n"; rmtree $dir; }
delete $builds{$id}; }
I actually got interested in adding the configurability to Geany build system when an organisation I was consulting to was using Geany but running builds on a server farm with several versions of Linux, AIX, HP-UX, Solaris and several windows versions. And different pieces of software from many different sources used many different build systems, hence the need for configurability.
Of course such remote jobs won't be touched by any signals.
According to the reference you provided on Rockbox it does remote builds by copying data from SVN and then copying the results back. So a remote build can be cancelled by its special server on the remote system (I guess thats where the perl snippet came from) and thrown away and no corruption is possible, but our system used shared sources for all machines and locks to control multiple build interactions. Killing things could leave locks about and block builds until someone removed them manually. Worse some pieces of software could corrupt the build tree if cancelled (sure they were lousy build scripts, but we used software from lots of places and didn't want to touch such things unless absolutely required)
Killing is done in the client (the snippet came from rbclient.rb). The server just sends a message CANCEL, the client in turn calls killchild.
Ok, which is client and which is server is not well defined :-)
Requiring perl is indeed suboptimal, but on the other hands it's really part of the default installation in 99% of all distros, and just about the same percentage of projects require perl already. But I understand that this is unwanted :)
While such a system is unusual, it made me very aware that the area of child processes in Unix (ignoring windows) is very flexible and not always fully standardised ( eg Linux pre 2.6 is not exactly POSIX). Remember even if it doesn't run something remote, a build could easily spawn background processes that can't be killed from the parent because they are not part of the same process group, so if the perl function only kills the group it still won't get them.
And your killall only works because you know that you are the only make running on your machine, it would be considered impolite if you were to kill someone else's make by accident :-)
I know, hence I'm searching for something better. See, I'm running a rockbox build client. Natually, I will kill those makes too if it was running at this very moment.
Its an area where caution is required to avoid real problems. If you have a solution that works for you, great!! Configure it for yourself, but it can't be offered as a general solution unless safe (oh, and useful ;-)
I actually played around a bit, and got a bit farther.
In my quick hack, I use kill(0, SIGTERM) to kill everything that has geanys pid as parent. To not kill geany itself too, I changed the signal handler to something which does nothing (and reverting to SIG_DFL afterwards). That works well, although I don't know which other process geany creates. Also, I think this is really a bad hack :( (isn't it?
Well, yes it is, thats too drastic, you don't know what else is running. If you use something like this elsewhere you just set the handler to SIG_IGN, thats what its for.
As an aside don't try blocking the signal, Geany (actually GTK+) uses multiple threads and you will only be blocking the main thread. So I guess thats advice for all GTK programs.
What I'm wondering is why doing "kill(build_info.pid, SIGINT)" doesn't work. Isn't that the same as doing CTRL+C when doing make in a terminal manually?
But it only kills the parent build process, unfortunately all the issues about children still apply.
Remember your ctrl-c from the terminal doesn't kill background processes because they are in another process group.
Your make script might not run other processes, but there is nothing preventing a script from running background processes or anything. We do *not* know what the users build executes and what a mess it might leave if terminated.
Thats why I say it should not be programmed into Geany, it makes too many assumptions.
As I said before, if it works for you in a particular situation configure it as a command, but just because it works for you does *not* mean it is safe in general. Having a command which is a script (even a perl one ;-) examine the process tree and find the "make" children of the instance of Geany that is a parent of the script itself (you may have to read that slowly, I did to ensure I got it right) would be the best way to go to avoid clobbering any other makes that are running and anything running from any other instances of Geany.
But programming one way of killing a build into Geany that may not work or may do damage is a bad idea.
I think we need to consider this a bit more first to find a safe general solution.
In the interim why don't you configure an extra execute command to run the "killall -9 make". It can then run asynchronously whilst the build is running.
Because my run (and build) command list is full ;)
I keep running out too :-D
With the build-system branch the hidden preference number_exec_menu_items can be set to increase the number of execute commands, see the build-system version of geany.html preferences file format section.
The geany.html is currently broken here due to svn merge (which took surprisingly long, some 30min) :D But I did not know that, thanks!
Was that merging trunk with your working copy? I will be merging trunk into build-system soon as 0.18 is released so let me know of any big problems. geany.html doesn't matter because it can be re-generated but if there are other problems its would be good to be warned. Build.c always has to be manually merged though.
Cheers Lex
Filetype and non-filetype numbers can also be increased so you can add make commands too (you can't decrease them). Close and re-open Geany before they take effect.
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Lex Trotman schrieb:
Killing is done in the client (the snippet came from rbclient.rb). The server just sends a message CANCEL, the client in turn calls killchild.
Ok, which is client and which is server is not well defined :-)
It is, it just wasn't obvious in the snippet.
I actually played around a bit, and got a bit farther.
In my quick hack, I use kill(0, SIGTERM) to kill everything that has geanys pid as parent. To not kill geany itself too, I changed the signal handler to something which does nothing (and reverting to SIG_DFL afterwards). That works well, although I don't know which other process geany creates. Also, I think this is really a bad hack :( (isn't it?
Well, yes it is, thats too drastic, you don't know what else is running. If you use something like this elsewhere you just set the handler to SIG_IGN, thats what its for.
:D I set it to SIG_IGN for the main program. And set it back to what main.c sets it to afterwards.
As an aside don't try blocking the signal, Geany (actually GTK+) uses multiple threads and you will only be blocking the main thread. So I guess thats advice for all GTK programs.
I don't think I'm blocking the main or any thread or signal.
What I'm wondering is why doing "kill(build_info.pid, SIGINT)" doesn't work. Isn't that the same as doing CTRL+C when doing make in a terminal manually?
But it only kills the parent build process, unfortunately all the issues about children still apply.
It doesn't do *anything* here. I also tried SIGQUIT (since a comment in main.c says "/* SIGQUIT is used to kill spawned children and we get also this signal, so ignore */") with the same effect.
Remember your ctrl-c from the terminal doesn't kill background processes because they are in another process group.
When I cancel make -j5 with CTRL+C, all of make's forks are terminated too. What do you mean with background processes, does that apply here? If you mean those process started with a '&' at the end, those are also in the same process group as the shell (they die if you terminate the shell)...*IIUC*.
Your make script might not run other processes, but there is nothing preventing a script from running background processes or anything. We do *not* know what the users build executes and what a mess it might leave if terminated.
Thats why I say it should not be programmed into Geany, it makes too many assumptions.
I don't see what's wrong with "kill child and its childs [and so on]" upon canceling. IMO, the user is in the duty to not create damaged build commands that break the system if they're cancelled (which is a manual action after all, i.e. the user doesn't need to hit it if he knows his script is going insane).
Killing/terminating *all* processes that are started due to the initial build command is a very valid action IMO.
As I said before, if it works for you in a particular situation configure it as a command, but just because it works for you does *not* mean it is safe in general. Having a command which is a script (even a perl one ;-) examine the process tree and find the "make" children of the instance of Geany that is a parent of the script itself (you may have to read that slowly, I did to ensure I got it right) would be the best way to go to avoid clobbering any other makes that are running and anything running from any other instances of Geany.
I might just do that, now that I know of the hidden additional run commands.
But programming one way of killing a build into Geany that may not work or may do damage is a bad idea.
As I said, the user is on fault if his commands cause damage. There are a lot of possibilities that the command dies without geany doing anything, and that's the users problem too then.
The geany.html is currently broken here due to svn merge (which took surprisingly long, some 30min) :D But I did not know that, thanks!
Was that merging trunk with your working copy? I will be merging trunk into build-system soon as 0.18 is released so let me know of any big problems. geany.html doesn't matter because it can be re-generated but if there are other problems its would be good to be warned. Build.c always has to be manually merged though.
Yea, it worked fine, just two uninteresting files conflicted. But of course I'm looking forward for this thing being in the trunk.
Best regards.
2009/8/17 Thomas Martitz thomas.martitz@student.htw-berlin.de:
Lex Trotman schrieb:
Killing is done in the client (the snippet came from rbclient.rb). The server just sends a message CANCEL, the client in turn calls killchild.
Ok, which is client and which is server is not well defined :-)
It is, it just wasn't obvious in the snippet.
Same thing ;-)
I actually played around a bit, and got a bit farther.
In my quick hack, I use kill(0, SIGTERM) to kill everything that has geanys pid as parent. To not kill geany itself too, I changed the signal handler to something which does nothing (and reverting to SIG_DFL afterwards). That works well, although I don't know which other process geany creates. Also, I think this is really a bad hack :( (isn't it?
Well, yes it is, thats too drastic, you don't know what else is running. If you use something like this elsewhere you just set the handler to SIG_IGN, thats what its for.
:D I set it to SIG_IGN for the main program. And set it back to what main.c sets it to afterwards.
As an aside don't try blocking the signal, Geany (actually GTK+) uses multiple threads and you will only be blocking the main thread. So I guess thats advice for all GTK programs.
I don't think I'm blocking the main or any thread or signal.
What I'm wondering is why doing "kill(build_info.pid, SIGINT)" doesn't work. Isn't that the same as doing CTRL+C when doing make in a terminal manually?
But it only kills the parent build process, unfortunately all the issues about children still apply.
It doesn't do *anything* here. I also tried SIGQUIT (since a comment in main.c says "/* SIGQUIT is used to kill spawned children and we get also this signal, so ignore */") with the same effect.
Oh, interesting, I don't know why it doesn't work, unless the signals are blocked somewhere?? Does your execute kill things correctly??
SIGQUIT is used by execute when it changes to stop, although it isn't the friendliest signal, see comment in build.c.
It probably should be SIGTERM which is the canonical "die now" signal, but then Geany's SIGTERM callback would have to decide where the signal came from and thats a-priori impossible.
Although, I am not sure why Geany should get the signal sent to its child?? The comments in build.c say it does but I don't know why. It doesn't happen in normal circumstances when a signal is sent to a child.
Can anyone else throw any light on why???
Something to examine further, the process creation and killing code in build-system is basically unchanged from 0.17 Geany.
Remember your ctrl-c from the terminal doesn't kill background processes because they are in another process group.
When I cancel make -j5 with CTRL+C, all of make's forks are terminated too. What do you mean with background processes, does that apply here? If you mean those process started with a '&' at the end, those are also in the same process group as the shell (they die if you terminate the shell)...*IIUC*.
No they are not in the same process group as the shell, do ps -o pid,ppid,pgid,command Or rather if bash has job control enabled they aren't, but I assumed it would be available for any recent Linux.
Things terminate when you terminate a shell because it sends SIGHUP to all its process groups at exit or they get tty control signals when their controlling terminal is disconnected. Shell also behaves differently if its interactive and if its a script.
Oh, and much of this behaviour is configurable too :-S
Your make script might not run other processes, but there is nothing preventing a script from running background processes or anything. We do *not* know what the users build executes and what a mess it might leave if terminated.
Thats why I say it should not be programmed into Geany, it makes too many assumptions.
I don't see what's wrong with "kill child and its childs [and so on]" upon canceling. IMO, the user is in the duty to not create damaged build commands that break the system if they're cancelled (which is a manual action after all, i.e. the user doesn't need to hit it if he knows his script is going insane).
Killing/terminating *all* processes that are started due to the initial build command is a very valid action IMO.
Well *thats* a very much bigger job than just one call to kill :-) and the comment below is still valid.
As I said before, if it works for you in a particular situation configure it as a command, but just because it works for you does *not* mean it is safe in general. Having a command which is a script (even a perl one ;-) examine the process tree and find the "make" children of the instance of Geany that is a parent of the script itself (you may have to read that slowly, I did to ensure I got it right) would be the best way to go to avoid clobbering any other makes that are running and anything running from any other instances of Geany.
I might just do that, now that I know of the hidden additional run commands.
And getting the process list is easier in a script, just run ps (or ptree if your system has it) and grab the output
But for C there isn't a system call to do it. AFAIK ps and top use an undocumented libproc, all others read the /proc directory tree, which is a pain. Or you could run ps in a subprocess & get its output. As I said a lot more work than just calling kill.
But programming one way of killing a build into Geany that may not work or may do damage is a bad idea.
As I said, the user is on fault if his commands cause damage. There are a lot of possibilities that the command dies without geany doing anything, and that's the users problem too then.
It may not be the users build script, for example, have you checked fully what Geany's make does??? I havn't even looked at it :-)
So we can't just blame the user :-( we have to ensure that things programmed into Geany can rarely cause damage.
The geany.html is currently broken here due to svn merge (which took surprisingly long, some 30min) :D But I did not know that, thanks!
Was that merging trunk with your working copy? I will be merging trunk into build-system soon as 0.18 is released so let me know of any big problems. geany.html doesn't matter because it can be re-generated but if there are other problems its would be good to be warned. Build.c always has to be manually merged though.
Yea, it worked fine, just two uninteresting files conflicted. But of course I'm looking forward for this thing being in the trunk.
Ditto
Cheers Lex
Best regards. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Lex Trotman schrieb:
2009/8/17 Thomas Martitz thomas.martitz@student.htw-berlin.de:
Lex Trotman schrieb:
Killing is done in the client (the snippet came from rbclient.rb). The server just sends a message CANCEL, the client in turn calls killchild.
Ok, which is client and which is server is not well defined :-)
It is, it just wasn't obvious in the snippet.
Same thing ;-)
I actually played around a bit, and got a bit farther.
In my quick hack, I use kill(0, SIGTERM) to kill everything that has geanys pid as parent. To not kill geany itself too, I changed the signal handler to something which does nothing (and reverting to SIG_DFL afterwards). That works well, although I don't know which other process geany creates. Also, I think this is really a bad hack :( (isn't it?
Well, yes it is, thats too drastic, you don't know what else is running. If you use something like this elsewhere you just set the handler to SIG_IGN, thats what its for.
:D I set it to SIG_IGN for the main program. And set it back to what main.c sets it to afterwards.
As an aside don't try blocking the signal, Geany (actually GTK+) uses multiple threads and you will only be blocking the main thread. So I guess thats advice for all GTK programs.
I don't think I'm blocking the main or any thread or signal.
What I'm wondering is why doing "kill(build_info.pid, SIGINT)" doesn't work. Isn't that the same as doing CTRL+C when doing make in a terminal manually?
But it only kills the parent build process, unfortunately all the issues about children still apply.
It doesn't do *anything* here. I also tried SIGQUIT (since a comment in main.c says "/* SIGQUIT is used to kill spawned children and we get also this signal, so ignore */") with the same effect.
Oh, interesting, I don't know why it doesn't work, unless the signals are blocked somewhere?? Does your execute kill things correctly??
SIGQUIT is used by execute when it changes to stop, although it isn't the friendliest signal, see comment in build.c.
It probably should be SIGTERM which is the canonical "die now" signal, but then Geany's SIGTERM callback would have to decide where the signal came from and thats a-priori impossible.
Although, I am not sure why Geany should get the signal sent to its child?? The comments in build.c say it does but I don't know why. It doesn't happen in normal circumstances when a signal is sent to a child.
Can anyone else throw any light on why???
Something to examine further, the process creation and killing code in build-system is basically unchanged from 0.17 Geany.
Remember your ctrl-c from the terminal doesn't kill background processes because they are in another process group.
When I cancel make -j5 with CTRL+C, all of make's forks are terminated too. What do you mean with background processes, does that apply here? If you mean those process started with a '&' at the end, those are also in the same process group as the shell (they die if you terminate the shell)...*IIUC*.
No they are not in the same process group as the shell, do ps -o pid,ppid,pgid,command Or rather if bash has job control enabled they aren't, but I assumed it would be available for any recent Linux.
Things terminate when you terminate a shell because it sends SIGHUP to all its process groups at exit or they get tty control signals when their controlling terminal is disconnected. Shell also behaves differently if its interactive and if its a script.
Oh, and much of this behaviour is configurable too :-S
Your make script might not run other processes, but there is nothing preventing a script from running background processes or anything. We do *not* know what the users build executes and what a mess it might leave if terminated.
Thats why I say it should not be programmed into Geany, it makes too many assumptions.
I don't see what's wrong with "kill child and its childs [and so on]" upon canceling. IMO, the user is in the duty to not create damaged build commands that break the system if they're cancelled (which is a manual action after all, i.e. the user doesn't need to hit it if he knows his script is going insane).
Killing/terminating *all* processes that are started due to the initial build command is a very valid action IMO.
Well *thats* a very much bigger job than just one call to kill :-) and the comment below is still valid.
As I said before, if it works for you in a particular situation configure it as a command, but just because it works for you does *not* mean it is safe in general. Having a command which is a script (even a perl one ;-) examine the process tree and find the "make" children of the instance of Geany that is a parent of the script itself (you may have to read that slowly, I did to ensure I got it right) would be the best way to go to avoid clobbering any other makes that are running and anything running from any other instances of Geany.
I might just do that, now that I know of the hidden additional run commands.
And getting the process list is easier in a script, just run ps (or ptree if your system has it) and grab the output
But for C there isn't a system call to do it. AFAIK ps and top use an undocumented libproc, all others read the /proc directory tree, which is a pain. Or you could run ps in a subprocess & get its output. As I said a lot more work than just calling kill.
But programming one way of killing a build into Geany that may not work or may do damage is a bad idea.
As I said, the user is on fault if his commands cause damage. There are a lot of possibilities that the command dies without geany doing anything, and that's the users problem too then.
It may not be the users build script, for example, have you checked fully what Geany's make does??? I havn't even looked at it :-)
For those we can make sure it doesn't harm to kill those. Otherwise I consider this as an actual bug in Geany.
So we can't just blame the user :-( we have to ensure that things programmed into Geany can rarely cause damage.
We can. Running an external script has nothing to do with "programmed into Geany", it just starts it (it even lets a shell start it).
That's like not implementing system calls in a operating system. Just because one can write harmful software using system calls?
Best regards.
It may not be the users build script, for example, have you checked fully what Geany's make does??? I havn't even looked at it :-)
For those we can make sure it doesn't harm to kill those. Otherwise I consider this as an actual bug in Geany.
Sorry, I'm not quite sure I understand your comment, I'm sure you are not saying its a bug in Geany if a users build script behaves badly??
So we can't just blame the user :-( we have to ensure that things programmed into Geany can rarely cause damage.
We can. Running an external script has nothing to do with "programmed into Geany", it just starts it (it even lets a shell start it).
Agreed thats why I suggest you put the kill build function in an external script that Geany runs, then you can use it but it isn't available by default to cause trouble for other users. Subject to comment by Enrico et al there is no reason that such a script couldn't be distributed with Geany with instructions how to configure it, but IMO it should not be part of the default build.
That's like not implementing system calls in a operating system. Just because one can write harmful software using system calls?
Yeah but system calls arn't available at user level.
Best regards.
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Lex Trotman schrieb:
It may not be the users build script, for example, have you checked fully what Geany's make does??? I havn't even looked at it :-)
For those we can make sure it doesn't harm to kill those. Otherwise I consider this as an actual bug in Geany.
Sorry, I'm not quite sure I understand your comment, I'm sure you are not saying its a bug in Geany if a users build script behaves badly??
You were the one referring to Geany's built-in default commands, so was I.
Btw, you just said it yourself. Of course Geany isn't on fault if a user script is damaged, the author of the script is. That's what I'm saying the whole time. That's why we can blame the user for it's scripts.
That's like not implementing system calls in a operating system. Just because one can write harmful software using system calls?
Yeah but system calls arn't available at user level.
Anyone can call system calls in every program no matter of the level.
I think we agree but are saying it differently. Let me re-state it from scratch.
1. Killing all the child build processes is significant but not impossible work and implementing it in C isn't very portable. 2. Even if we were willing to do the work involved in 1, killing a build is risky because Geany does not know what the build might be doing and what problems killing it may cause. 3. As we agree, this is the problem of the build script creator and you are right to blame them 4. But the user of Geany is not always the creator of the build script. They just grabbed a useful looking program from an SVN repository and edited and built it All goes well until they try to kill a build and they may get problems that they are not expecting or to blame for. This is not nice :-( Many will blame Geany for providing the kill command. 5. But killing a build is useful if you know what you are doing, so having an external script available for such users to configure into their Geany is useful. I encourage you to write the safest possible and most portable one. And if its invoked by the execute menu items it is configurable by filetype, project, user config etc. so the user can even limit when it is available to the smallest safe subset.
Cheers Lex
2009/8/17 Thomas Martitz thomas.martitz@student.htw-berlin.de:
Lex Trotman schrieb:
It may not be the users build script, for example, have you checked fully what Geany's make does??? I havn't even looked at it :-)
For those we can make sure it doesn't harm to kill those. Otherwise I consider this as an actual bug in Geany.
Sorry, I'm not quite sure I understand your comment, I'm sure you are not saying its a bug in Geany if a users build script behaves badly??
You were the one referring to Geany's built-in default commands, so was I.
Btw, you just said it yourself. Of course Geany isn't on fault if a user script is damaged, the author of the script is. That's what I'm saying the whole time. That's why we can blame the user for it's scripts.
That's like not implementing system calls in a operating system. Just because one can write harmful software using system calls?
Yeah but system calls arn't available at user level.
Anyone can call system calls in every program no matter of the level. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sun, 16 Aug 2009 15:00:18 +1000, Lex wrote:
Hey guys,
I won't respond on all details of this part of the thread due to lack of time and more importantly because of lack of knowledge at some parts.
One comment though: a Perl dependency is not an option even not if it were installed on 100% of all users' systems :).
I can see that you may want to kill a long build that you started by accident or when you realise you forgot to do something first. I've done that more than once ;-)
I guess we all had this issue already. At the time we added the Stop button for the Run command we also tried implementing this for the Make commands. But as you both noticed in this thread, it's not that easy. I don't say it's not possible but it's just not as easy as it may sound.
Due to problems on windows, builds have to be run synchronously on windows, ie the whole of Geany freezes while the build runs (why? I don't understand exactly, maybe Enrico can explain it).
I think I did explain it in http://lists.uvena.de/pipermail/geany-devel/2009-April/000584.html. If not, just ask again what exactly is not clear, then I'd be happy to explain it in more detail.
That means that cancelling a windows build can't be done from Geany anyway.
Yes, sort of. In theory it should be even easier to kill a synchronous build but the problem is the user can't do this because the GUI is frozen and doesn't react to any input until the build is finished. So yes, you are right, the process can't be killed at all. Anyway, I don't see this as a major issue as the whole synchronous build thing on Windows is not meant to be the final way. It's more or less only a temporary hack until someone shows up with time and/or knowledge (ideally both) on how to do it right on Windows :).
Whilst Linux builds are still asynchronous only one is allowed at a time so that output isn't mixed up in the error parser. So all build commands are set insensitive until completion. To have one menu item still enabled and to have it change to stop is going to be quite a bit of fiddling unless it is always a fixed menu item or a toolbar button.
Yes, as you say it, I'm thinking about. We actually could add a separate Stop button for the toolbar and the Build menu, That would obsolete a lot of not so nice code in build.c which deals with the double action of the button. And since the toolbar is pretty easy to configure these days, that probably would not be a big deal UI-wise. Though I don't have a strong opinion on that. Just share your thoughts about this, maybe in a separate new thread.
Regards, Enrico