Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
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 -- Get my GPG key from http://www.uvena.de/pub.asc pgpoBMBznOEVb.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
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/
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
2009/8/16 Thomas Martitz thomas.mart...@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
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
2009/8/17 Thomas Martitz thomas.mart...@student.htw-berlin.de:
Lex Trotman schrieb:
2009/8/16 Thomas Martitz thomas.mart...@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
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
2009/8/17 Thomas Martitz thomas.mart...@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
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
Lex Trotman schrieb: 2009/8/17 Thomas Martitz thomas.mart...@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
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
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.mart...@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 ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
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.mart...@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 ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
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. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
On Sat, 18 Jul 2009 16:54:16 +0200 Enrico Tröger enrico.troe...@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 -- Frank Lanitz fr...@frank.uvena.de pgpqUS5NOlNul.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
On Wed, 22 Jul 2009 13:12:41 +1000, Lex wrote: 2009/7/22 Enrico Tröger enrico.troe...@uvena.de: On Tue, 21 Jul 2009 13:45:16 +1000, Lex wrote: 2009/7/21 Lex Trotman ele...@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 -- Get my GPG key from http://www.uvena.de/pub.asc pgpxs4LEJEdPI.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
2009/7/25 Thomas Martitz thomas.mart...@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 ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
On Tue, 21 Jul 2009 13:45:16 +1000, Lex wrote: 2009/7/21 Lex Trotman ele...@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 -- Get my GPG key from http://www.uvena.de/pub.asc pgpZAHiyo1rYZ.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
2009/7/21 Lex Trotman ele...@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 ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
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 -- Get my GPG key from http://www.uvena.de/pub.asc pgprTneieDgR5.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
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 lookfeel 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 -- Get my GPG key from http://www.uvena.de/pub.asc pgpnoFHuG8S3g.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
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
--
Get my GPG key from http://www.uvena.de/pub.asc
Index: build-system/src/build.c
===
--- build-system/src/build.c (revision 3984)
+++ build-system/src/build.c (working copy)
@@ -1496,7 +1496,7 @@ void build_toolbutton_build_clicked(GtkA
{
if (last_toolbutton_action == GBO_TO_POINTER(GBO_BUILD))
{
- on_build_menu_item(NULL, user_data);
+ on_build_menu_item(NULL, GBO_TO_POINTER(GBO_BUILD));
}
else
{
pgpXUdh5przU4.pgp
Description: PGP signature
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
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 -- Get my GPG key from http://www.uvena.de/pub.asc pgpTMq532WQZQ.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
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. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
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
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
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 ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
