Hi,
I know Frank has asked a few times for people to clean up the build warnings for their plugins. There's still *way* too many warnings.
I quickly went through all the warnings and "fixed" them. I just did the quick/obvious fixes and didn't test anything. I can almost guarantee that at least a few of the "fixes" aren't correct and will cause problems with the plugins.
Attached are all the patches that fix the warnings. If the plugins developer(s) could each look at their respective patches and review them and either apply and thoroughly test their plugins or ignore them and otherwise fix the warnings, that would be great.
The only plugin with non-trivial (by way of quantity) warnings to fix was GeanyGDB. I don't know if this is maintained any more or if it's needed with having the Debugger plugin, but if it is, the author(s) should go through and fix all their `const` usage themselves. The attached patch for GeanyGDB only fixes a few usages but exposes much more warnings, so it might be of little use.
In the Treebrowser I did a little more than fix the warnings since there were some weird logic and memory issues. Again, I can't guarantee I've fixed them, but it should give some ideas.
For the Gendoc plugin, I'm not sure if the warnings are false positives or not, if so, ignore the patch for that.
Just to reiterate *none of the fixes were tested*, so don't just blindly apply the patches but rather use them as motivation to fix your plugin properly.
Cheers, Matthew Brush
Am Freitag, den 28.10.2011, 16:02 -0700 schrieb Matthew Brush:
The only plugin with non-trivial (by way of quantity) warnings to fix was GeanyGDB. I don't know if this is maintained any more or if it's needed with having the Debugger plugin, but if it is, the author(s) should go through and fix all their `const` usage themselves. The attached patch for GeanyGDB only fixes a few usages but exposes much more warnings, so it might be of little use.
The original author of this plugin was Jeff Pohlmeyer, I'm afraid he will not read this, though. I took over the "maintainership" long time ago, approx. at the beginning of 2010 (or maybe earlier) to not have an unmaintained plugin within the Geany-Plugins project.
Seems I was out of my estimation regarding what it means to maintain such an amount of C code written by someone else - having in mind that I'm not that skilled in C (I'd call myself rather a beginner in writing C). I actually didn't wrote C since a few month now and also do not use GeanyGDB at present.
I appreciate any efforts and patches which may improve GeanyGDB and would apply any contributed stuff for that plugin, but I'd like to discuss some questions (IIRC some may also were earlier discussed before):
1)
There are guys out there who write C code and may use debugging plugins from within Geany. There are at least two alternative plugins which would do the job. I'd love to know your honest opinion which one you actually prefer.
2)
Wasn't it discussed before that we maybe remove GeanyGDB after the 0.21 release? - I'm not sure about this and to lazy to investigate for the mails. :)
3)
Is there anyone out there who alternatively would like to maintain and improve GeanyGDB (and is more skilled in C than me :) ).
4)
I of course appreciate Matthews patch and like to apply it, but that most likely should wait at least until we moved to GitHub with Geany-Plugins, should it?
Regards, Dominic
On 10/28/2011 04:27 PM, Dominic Hopf wrote:
Am Freitag, den 28.10.2011, 16:02 -0700 schrieb Matthew Brush:
The only plugin with non-trivial (by way of quantity) warnings to fix was GeanyGDB. I don't know if this is maintained any more or if it's needed with having the Debugger plugin, but if it is, the author(s) should go through and fix all their `const` usage themselves. The attached patch for GeanyGDB only fixes a few usages but exposes much more warnings, so it might be of little use.
The original author of this plugin was Jeff Pohlmeyer, I'm afraid he will not read this, though. I took over the "maintainership" long time ago, approx. at the beginning of 2010 (or maybe earlier) to not have an unmaintained plugin within the Geany-Plugins project.
Seems I was out of my estimation regarding what it means to maintain such an amount of C code written by someone else - having in mind that I'm not that skilled in C (I'd call myself rather a beginner in writing C). I actually didn't wrote C since a few month now and also do not use GeanyGDB at present.
It's almost all just that the const-incorrectness everywhere in the existing code is causing a zillion warnings. It doesn't necessarily mean the code is bad or broken, just that it's going to cause a ton of warnings and could possibly have some weird memory issues IIUC. Maybe if no one can fix the warnings, there's a way to disable the specific warnings for that plugin alone in the build systems?
I appreciate any efforts and patches which may improve GeanyGDB and would apply any contributed stuff for that plugin, but I'd like to discuss some questions (IIRC some may also were earlier discussed before):
There are guys out there who write C code and may use debugging plugins from within Geany. There are at least two alternative plugins which would do the job. I'd love to know your honest opinion which one you actually prefer.
I think there's only the Debugger plugin as an alternative, no?
I had only tried the Debugger plugin when it first landed in G-P, so it was quite buggy still, but the general concept/UI was quite nice and I know it's being worked on quite frequently, so it's probably improved quite a bit since then.
Wasn't it discussed before that we maybe remove GeanyGDB after the 0.21 release? - I'm not sure about this and to lazy to investigate for the mails. :)
I'd say if the Debugger plugin is in good enough shape, it would be ok to remove GeanyGDB. I guess we should see how many people use it though and ask them if they'd like to maintain it (ex. on the general geany list).
Is there anyone out there who alternatively would like to maintain and improve GeanyGDB (and is more skilled in C than me :) ).
No thanks :)
I of course appreciate Matthews patch and like to apply it, but that most likely should wait at least until we moved to GitHub with Geany-Plugins, should it?
I wouldn't apply the patch for that at all. It's the only one of those patches that's totally incomplete and it will probably cause all kinds of strange bugs and even more warnings.
Cheers, Matthew Brush
Am Freitag, den 28.10.2011, 16:46 -0700 schrieb Matthew Brush:
There are guys out there who write C code and may use debugging plugins from within Geany. There are at least two alternative plugins which would do the job. I'd love to know your honest opinion which one you actually prefer.
I think there's only the Debugger plugin as an alternative, no?
I think I remember some other stuff as well, but this was quite long ago and I couldn't find those ad-hoc.
The Debugger plugin looks quite better than GeanyGDB at a first quick view (I didn't had a chance to look deeper into it before).
Wasn't it discussed before that we maybe remove GeanyGDB after the 0.21 release? - I'm not sure about this and to lazy to investigate for the mails. :)
I'd say if the Debugger plugin is in good enough shape, it would be ok to remove GeanyGDB. I guess we should see how many people use it though and ask them if they'd like to maintain it (ex. on the general geany list).
Let's start a poll somewhere.. :)
Regards, Dominic
On Sun, 30 Oct 2011 16:01:22 +0100 Dominic Hopf dmaphy@googlemail.com wrote:
Am Freitag, den 28.10.2011, 16:46 -0700 schrieb Matthew Brush:
There are guys out there who write C code and may use debugging plugins from within Geany. There are at least two alternative plugins which would do the job. I'd love to know your honest opinion which one you actually prefer.
I think there's only the Debugger plugin as an alternative, no?
I think I remember some other stuff as well, but this was quite long ago and I couldn't find those ad-hoc.
The Debugger plugin looks quite better than GeanyGDB at a first quick view (I didn't had a chance to look deeper into it before).
Wasn't it discussed before that we maybe remove GeanyGDB after the 0.21 release? - I'm not sure about this and to lazy to investigate for the mails. :)
I'd say if the Debugger plugin is in good enough shape, it would be ok to remove GeanyGDB. I guess we should see how many people use it though and ask them if they'd like to maintain it (ex. on the general geany list).
Let's start a poll somewhere.. :)
I think just doing here on list is fine. I'd say deprecate geanyGDB and check whether some features might are missing from inside Debugger. Once the list is empty, we can remove it from source tree.
Cheers, Frank
Hi Matthew,
On 29 October 2011 10:02, Matthew Brush mbrush@codebrainz.ca wrote:
Hi,
I know Frank has asked a few times for people to clean up the build warnings for their plugins. There's still *way* too many warnings.
I quickly went through all the warnings and "fixed" them. I just did the quick/obvious fixes and didn't test anything. I can almost guarantee that at least a few of the "fixes" aren't correct and will cause problems with the plugins.
Attached are all the patches that fix the warnings. If the plugins developer(s) could each look at their respective patches and review them and either apply and thoroughly test their plugins or ignore them and otherwise fix the warnings, that would be great.
Well done, I tested all but GeanyGDB and found some extra warnings, see [1] probably as my checking is stricter than yours. "-Wall -Wextra -O2 -no-unused-parameter"
Plugin maintainers should look at these since they may indicate real errors, eg "warning: comparison of unsigned expression >= 0 is always true" and various uninitialised things.
Note that Geany itself has only one "well known" warning with these settings, so they can't be said to be too strict.
All plugins loaded and ran the most basic things except:
- geanymacro which wouldn't accept any input in the keycode field and without a keycode wouldn't do anything.
YMMV
Starting from a clean machine, I found many dependencies are undocumented. Many plugins required the dev package as well as the specified package, ok its sort of obvious, but it would be nice to mention as well.
Other than the dev packages, unexpected and undocumented dependencies I found were:
debugger - vte-dev geanypg - gpgme not just gpg update checker - webkitdev
As I went through the website I noticed several plugins had errors in the markup of their READMEs giving messy error messages in the web page.
geanymacro geanynumberedbookmarks
and geanylua, redirects to an external page, but the link is broken
Cheers Lex
[1] https://github.com/elextr/geany_stuff/raw/master/geany-plugins-warnings
Am 29.10.2011 05:38, schrieb Lex Trotman:
Well done, I tested all but GeanyGDB and found some extra warnings, see [1] probably as my checking is stricter than yours. "-Wall -Wextra -O2 -no-unused-parameter"
Plugin maintainers should look at these since they may indicate real errors, eg "warning: comparison of unsigned expression >= 0 is always true" and various uninitialised things.
My understanding was that these flags are already set on make check.
Cheers, Frank
Am 29.10.2011 05:38, schrieb Lex Trotman:
Starting from a clean machine, I found many dependencies are undocumented. Many plugins required the dev package as well as the specified package, ok its sort of obvious, but it would be nice to mention as well.
Other than the dev packages, unexpected and undocumented dependencies I found were:
debugger - vte-dev geanypg - gpgme not just gpg update checker - webkitdev
Are you just referring to documentation or to build system as well?
Cheers, Frank
On 30 October 2011 02:07, Frank Lanitz frank@frank.uvena.de wrote:
Am 29.10.2011 05:38, schrieb Lex Trotman:
Starting from a clean machine, I found many dependencies are undocumented. Many plugins required the dev package as well as the specified package, ok its sort of obvious, but it would be nice to mention as well.
Other than the dev packages, unexpected and undocumented dependencies I found were:
debugger - vte-dev geanypg - gpgme not just gpg update checker - webkitdev
Are you just referring to documentation or to build system as well?
They should be documented, IIUC the build script checks, thats why they fail to build.
Having to search the build script to find dependencies is not good.
Cheers Lex
Cheers, Frank _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 11-10-29 05:36 PM, Lex Trotman wrote:
On 30 October 2011 02:07, Frank Lanitzfrank@frank.uvena.de wrote:
Am 29.10.2011 05:38, schrieb Lex Trotman:
Starting from a clean machine, I found many dependencies are undocumented. Many plugins required the dev package as well as the specified package, ok its sort of obvious, but it would be nice to mention as well.
Other than the dev packages, unexpected and undocumented dependencies I found were:
debugger - vte-dev geanypg - gpgme not just gpg update checker - webkitdev
Are you just referring to documentation or to build system as well?
They should be documented, IIUC the build script checks, thats why they fail to build.
Having to search the build script to find dependencies is not good.
The best situation would be to have the ./configure summary print something like this:
Plugins: Addons: yes [automatic] CodeNav: no [disabled by user] Debugger: no [missing `vte' package] [...]
I'm not sure how much a PITA this would be to write though.
Cheers, Matthew Brush
[..]
They should be documented, IIUC the build script checks, thats why they fail to build.
Having to search the build script to find dependencies is not good.
The best situation would be to have the ./configure summary print something like this:
Plugins: Addons: yes [automatic] CodeNav: no [disabled by user] Debugger: no [missing `vte' package] [...]
I'm not sure how much a PITA this would be to write though.
That of course is a better solution, but I assumed it was too hard with autofools, WAF would of course just be print "I can't find ..." in appropriate places.
Cheers Lex
Am 30.10.2011 02:52, schrieb Lex Trotman:
That of course is a better solution, but I assumed it was too hard with autofools, WAF would of course just be print "I can't find ..." in appropriate places.
Its doing this. just as example from the machine I'm currently working on:
$ ./waf configure Setting top to : /home/frlan/quellen/git/geany-plugins_svn/geany-plugins Setting out to : /home/frlan/quellen/git/geany-plugins_svn/geany-plugins/_build_ Checking for waf version in 1.6.1-1.7.0 : ok Checking for 'gcc' (c compiler) : ok Checking for program pkg-config : /usr/bin/pkg-config Checking for 'gtk+-2.0' >= 2.12.0 : yes Checking for 'geany' >= 0.21 : yes Checking for 'geany' : yes Checking for 'geany' version : yes Checking for 'gtk+-2.0' version : yes Checking for program msgfmt : /usr/bin/msgfmt Checking for program perl : /usr/bin/perl Checking for 'intltool-merge' : /usr/bin/intltool-merge Checking for header locale.h : yes Checking for 'vte' : not found Checking for 'gtk+-2.0' >= 2.16 : yes Checking for 'glib-2.0' >= 2.16 : yes Checking for 'gthread-2.0' >= : yes Checking for 'webkit-1.0' >= 1.1.18 : not found Checking for header elf.h : yes Checking for 'ctpl' >= 0.3 : not found Checking for 'lua' >= 5.1 : not found Checking for 'lua5.1' >= 5.1 : not found Checking for 'lua51' >= 5.1 : not found Checking for 'lua-5.1' >= 5.1 : not found Checking for 'gpgme-config' : not found Checking for 'gtkspell-2.0' >= 2.0 : not found Checking for 'libxml-2.0' >= 2.6.27 : not found Checking for 'enchant' >= 1.3 : not found Checking for 'gio-2.0' >= 2.16 : yes Checking for header sys/types.h : yes Checking for header sys/stat.h : yes Checking for header fcntl.h : yes Checking for 'libsoup-2.4' >= 2.4.0 : not found Checking for program glib-genmarshal : /usr/bin/glib-genmarshal Checking for program perl : /usr/bin/perl Checking for 'glib-mkenums' : /usr/bin/glib-mkenums Checking for program glib-compile-schemas : /usr/bin/glib-compile-schemas Checking for 'gio-2.0' >= 2.18 : yes Checking for 'gdk-pixbuf-2.0' >= 2.0 : yes Checking for 'webkit-1.0' >= 1.1.18 : not found Summary: Install Geany Plugins 0.21 in : /usr/local Using GTK version : 2.24.6 Using Geany version : 1.22 Compiling Subversion revision : 2314 Plugins to compile : addons codenav geanydoc geanyextrasel geanygdb geanyinsertnum geanylatex geanylipsum geanymacro geanynumberedbookmarks geanyprj geanysendmail geanyvc gproject shiftcolumn tableconvert treebrowser xmlsnippets 'configure' finished successfully (4.906s)
Of course, this is not showing which plugin is effected, but a nicer view to missing dependencies.
Cheers, Frank
Hi Frank,
On 30 October 2011 19:05, Frank Lanitz frank@frank.uvena.de wrote:
Am 30.10.2011 02:52, schrieb Lex Trotman:
That of course is a better solution, but I assumed it was too hard with autofools, WAF would of course just be print "I can't find ..." in appropriate places.
Its doing this. just as example from the machine I'm currently working on:
[...]
Yeah, autotools does this as well (but not so clear I must admit) but as you say below, it doesn't identify which plugin requires which dependency.
Plugins to compile : addons codenav geanydoc geanyextrasel geanygdb geanyinsertnum geanylatex geanylipsum geanymacro geanynumberedbookmarks geanyprj geanysendmail geanyvc gproject shiftcolumn tableconvert treebrowser xmlsnippets 'configure' finished successfully (4.906s)
Would be nice to list the ones it is rejecting as well.
Of course, this is not showing which plugin is effected, but a nicer view to missing dependencies.
I've never got my head round Waf, but if looks like it checks some dependencies several times so I'm assuming that it is per plugin, so all that is needed is to print "Checking dependencies for xxx" before doing it, that would associate each plugin with the needed dependencies. IIUC Waf is just python so adding a print shouldn't be too hard (or have I totally misunderstood?).
Cheers Lex
Cheers, Frank _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 29 Oct 2011 14:38:11 +1100 Lex Trotman elextr@gmail.com wrote:
update checker - webkitdev
I've updated the RADME for this, but the only dependency should be libsoup. Not sure where webkit is coming from.
Cheers, Frank
On 31 October 2011 21:30, Frank Lanitz frank@frank.uvena.de wrote:
On Sat, 29 Oct 2011 14:38:11 +1100 Lex Trotman elextr@gmail.com wrote:
update checker - webkitdev
I've updated the RADME for this, but the only dependency should be libsoup. Not sure where webkit is coming from.
Hi Frank,
Thats my mistake, the update checker configured ok when I installed webkit for webhelper since that pulls in libsoup and I assumed the dep was webkit.
Cheers Lex
Cheers, Frank -- http://frank.uvena.de/en/
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 31 Oct 2011 21:37:30 +1100 Lex Trotman elextr@gmail.com wrote:
On 31 October 2011 21:30, Frank Lanitz frank@frank.uvena.de wrote:
On Sat, 29 Oct 2011 14:38:11 +1100 Lex Trotman elextr@gmail.com wrote:
update checker - webkitdev
I've updated the RADME for this, but the only dependency should be libsoup. Not sure where webkit is coming from.
Thats my mistake, the update checker configured ok when I installed webkit for webhelper since that pulls in libsoup and I assumed the dep was webkit.
OK. That solves my confusion :) Documentation should fit now.
Cheers, Frank