subject:"Re\: \[Geany\-devel\] Ideas on increasing quality of plugins"

On Sat, 12 Mar 2011 12:04:31 +1100
Lex Trotman ele...@gmail.com wrote:

 On 12 March 2011 11:35, Matthew Brush matthewbr...@gmail.com wrote:
  On 03/11/11 15:24, Frank Lanitz wrote:
 
  On Wed, 23 Feb 2011 15:28:05 +0300
  Alexander Petukhovalexander.petuk...@mail.ru  wrote:
 
  5. Other language bindings - don't really think it can increase
  plugins quality dramatically, there can be problems in any
  language that you have to solve in order to make your code work
  correctly.
 
  I agree. It will might also split up resources on core side to
  support maybe 5 API as even you do use some kind of automatically
  binding it will not working out of the box in every case.
 
  If the core API were more binding friendly, for example using
  standard GObject conventions, a HUGE portion of the work doing
  bindings would be completely automated for quite a number of
  languages, without any need to customize the core for them.  The
  things that don't work out of the box would be fixed in the binding
  itself as is common with other bindings of things.  This is the
  whole purpose of things like GObject introspection (to make GObject
  bindings automatic and natural to that language).
 
  As an example, the Vala bindings are being hacked to death to make
  them more like Vala-ish (make that GObject-ish), when this would be
  a basically fully automated process if the API was already
  GObject-ish.  Same with Genie, Python, and probably others with
  GObject support like Perl, Ruby, Scheme, C++, and so on.
 
  Even if it didn't lead to improved plugin quality, which it would
  at least for languages using VMs/interpreters, it would create a
  lot of new functionality for Geany by having much more
  participation from a wider range of programmers.  Just hanging
  around on the ML and IRC I've heard many times Geany users saying
  they would like to make a plugin but they don't know C, they are
  experts on some other language.  One of the big benefits of a
  plugin system is making it easy for users to extend the program,
  and IMO making the users learn and code properly in C does not
  (necessarily) accomplish that goal.
 
  The barrier to entry to writing Geany plugins currently is such
  that a very small portion of the users (programmers) are able to
  extend the software at all, and those that fake it in C will end up
  with nasty mess of buggy code (like me :).
 
  My 0.02$ CAD
 
  Matthew Brush (codebrainz)
 
 Hi Matthew,
 
 I wasn't party to the original design of the Geany plugin API/ABI so I
 don't have any investment in it.
 
 I can see why it was done the way it is, it has several potential
 advantages in terms of reducing plugin re-compilation requirements,
 although it loses some of that by being very conservative (but safe)
 in terms of its run time acceptance of older plugins.  But as you
 point out it isn't easy to bind to.
 
 As we have discussed before, replacing the interface isn't acceptable,
 but that doesn't mean that a second interface that is automatically
 GObjectable, SWIGable introspectable etc.can't be added.
 
 Over time existing plugins can then be migrated and the old interface
 removed.
 
 But someone has to do it (tm) and of course patches are welcome (c)...

Yes. I'm sure we can discuss to set up a branch on geany-svn where
Matthew and maybe some other can start to build up a GObject based
interface by keeping the old. That's being said: I guess the core team
itself will currently not have the capacities to do it. But this should
be another thread as its off topic here. 

Cheers, 
Frank 
-- 
http://frank.uvena.de/en/


pgp3qXJiz8VJG.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] Ideas on increasing quality of plugins

On Sat, 12 Mar 2011 12:37:14 +1100
Lex Trotman ele...@gmail.com wrote:

 Maaaybe, sort of see your point, but not really convinced that
 uprating warnings to errors is a good idea on the dev codebase, it
 stops people trying and testing things.

I agree. A failing build is more demotivating for some tester as a
plugin which is deactivated and maybe needs to be activate with an
--with-enable-foo-plugin 

Cheers, 
Frank
-- 
http://frank.uvena.de/en/


pgpPGzJklH33K.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] Ideas on increasing quality of plugins

On Sat, 12 Mar 2011 02:53:47 +0100
Colomban Wendling lists@herbesfolles.org wrote:

  Maaaybe, sort of see your point, but not really convinced that
  uprating warnings to errors is a good idea on the dev codebase, it
  stops people trying and testing things.
 Unfortunately, believe me that non-fatal warnings are use to be
 ignored by unexperienced programmers, believing that if their code
 compile it is then OK.
 And I don't see why a warning upgraded to an error on every build
 would be worst than a syntactical problem (as I described above
 previously)? In a typical situation, the developer who writes the
 plugin should get the warning (well, the error), see his plugin don't
 build, care (hopefully :D), and then fix it directly even before
 committing and then before anybody else could face the problem.
 Don't you think?

Just thinking about adding a flag which is activating a paranoid
check inside default build system and which lead into failing buildsin
such a case. This would give plugin devs the chance to fix their code
on one hand and unexperienced people which just want to test to have a
build they can do their stuff with. 

Cheers, 
Frank
-- 
http://frank.uvena.de/en/


pgpOxZcr6oK7W.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] Ideas on increasing quality of plugins

2011-03-12 Thread Lex Trotman

On 12 March 2011 20:21, Frank Lanitz fr...@frank.uvena.de wrote:
 On Sat, 12 Mar 2011 02:53:47 +0100
 Colomban Wendling lists@herbesfolles.org wrote:

  Maaaybe, sort of see your point, but not really convinced that
  uprating warnings to errors is a good idea on the dev codebase, it
  stops people trying and testing things.
 Unfortunately, believe me that non-fatal warnings are use to be
 ignored by unexperienced programmers, believing that if their code
 compile it is then OK.
 And I don't see why a warning upgraded to an error on every build
 would be worst than a syntactical problem (as I described above
 previously)? In a typical situation, the developer who writes the
 plugin should get the warning (well, the error), see his plugin don't
 build, care (hopefully :D), and then fix it directly even before
 committing and then before anybody else could face the problem.
 Don't you think?

 Just thinking about adding a flag which is activating a paranoid
 check inside default build system and which lead into failing buildsin
 such a case. This would give plugin devs the chance to fix their code
 on one hand and unexperienced people which just want to test to have a
 build they can do their stuff with.

Yeah, so long as it doesn't make the whole system too complicated and
is well documented, it has to be easily usable and maintainable :-)

Cheers
Lex


 Cheers,
 Frank
 --
 http://frank.uvena.de/en/

 ___
 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] Ideas on increasing quality of plugins

2011-03-12 Thread Lex Trotman

On 12 March 2011 20:54, Frank Lanitz fr...@frank.uvena.de wrote:
 On Sat, 12 Mar 2011 20:49:10 +1100
 Lex Trotman ele...@gmail.com wrote:

 On 12 March 2011 20:21, Frank Lanitz fr...@frank.uvena.de wrote:
  On Sat, 12 Mar 2011 02:53:47 +0100
  Colomban Wendling lists@herbesfolles.org wrote:
 
   Maaaybe, sort of see your point, but not really convinced that
   uprating warnings to errors is a good idea on the dev codebase,
   it stops people trying and testing things.
  Unfortunately, believe me that non-fatal warnings are use to be
  ignored by unexperienced programmers, believing that if their code
  compile it is then OK.
  And I don't see why a warning upgraded to an error on every build
  would be worst than a syntactical problem (as I described above
  previously)? In a typical situation, the developer who writes the
  plugin should get the warning (well, the error), see his plugin
  don't build, care (hopefully :D), and then fix it directly even
  before committing and then before anybody else could face the
  problem. Don't you think?
 
  Just thinking about adding a flag which is activating a paranoid
  check inside default build system and which lead into failing
  buildsin such a case. This would give plugin devs the chance to fix
  their code on one hand and unexperienced people which just want to
  test to have a build they can do their stuff with.

 Yeah, so long as it doesn't make the whole system too complicated and
 is well documented, it has to be easily usable and maintainable :-)

 Yes, didn't had something else in my mind.
 For autotools this could be a new target with cpp-flags as on waf it
 could be an option on command line.
 Something, and I bag you to don't take me to serious, similar to:
 make devbuild or ./waf build --developer

Does waf build --developer build developers? That would be great we
could use some more!!!  (well you said not to take it too seriously
:-)

Cheers
Lex

PS The question of course is does the nightly build use --developer,
I'd say yes for all the reasons I've listed previously.  But then by
who and when is --release (or whatever its called) used?


 Cheers,
 Frank



 --
 Frank Lanitz fr...@frank.uvena.de

 ___
 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] Ideas on increasing quality of plugins

Le 12/03/2011 09:31, Yura Siamashka a écrit :
 On Sat, 12 Mar 2011 02:53:47 +0100
 Colomban Wendling lists@herbesfolles.org wrote:
 
 Unfortunately, believe me that non-fatal warnings are use to be ignored
 by unexperienced programmers, believing that if their code compile it is
 then OK.
 And I don't see why a warning upgraded to an error on every build would
 be worst than a syntactical problem (as I described above previously)?
 In a typical situation, the developer who writes the plugin should get
 the warning (well, the error), see his plugin don't build, care
 (hopefully :D), and then fix it directly even before committing and then
 before anybody else could face the problem.
 Don't you think?
 
 Sorry I have not read all thread but here is my 2 cents. Warnings as
 errors are bad because different compiler version can generate different
 compile warnings. So It can be pain for developer to find and fix all
 warning forall compiler versions in the world.
I wasn't talking about promoting all warnings to errors, only a few,
carefully-chosen, ones. Actually, implicit-function-declaration and
pointer-arith. IMO both problem are grave (implicit function declaration
prevents the compiler to check whether a function is called with
appropriate parameters, and untyped pointer arithmetic is unportable),
and I doubt any compiler would have such options doing something else
than what you can expect from the name.

 This issue is the same
 for for all other validation tools (valgrind, etc). Actually such
 maintains bother can be enough reason to abandon geany-plugins and move
 plugins to somewhere else.
It would probably be sad, and it's not the goal, but we try to find a
way to improve plugin quality. And to achieve this, we need to have some
criteria.
Of course the goal is not to enforce a ton of coding standards,
validation process and stuff, and if a particular developer have a
complain about something we will discuss it without problem.

But OTOH, if a plugin developer finds annoying to try to enforce a
minimal quality on his plugin (the less crashers possible, not too many
memory leaks, etc.), maybe geany-plguins don't want him. But I'm quite
confident all developers want their code to be the better, so they would
care :)

Cheers,
Colomban
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

On Sat, 12 Mar 2011 15:55:52 +0100
Colomban Wendling lists@herbesfolles.org wrote:

 Le 12/03/2011 10:49, Lex Trotman a écrit :
  On 12 March 2011 20:21, Frank Lanitz fr...@frank.uvena.de wrote:
  On Sat, 12 Mar 2011 02:53:47 +0100
  Colomban Wendling lists@herbesfolles.org wrote:
 
  Maaaybe, sort of see your point, but not really convinced that
  uprating warnings to errors is a good idea on the dev codebase,
  it stops people trying and testing things.
  Unfortunately, believe me that non-fatal warnings are use to be
  ignored by unexperienced programmers, believing that if their code
  compile it is then OK.
  And I don't see why a warning upgraded to an error on every build
  would be worst than a syntactical problem (as I described above
  previously)? In a typical situation, the developer who writes the
  plugin should get the warning (well, the error), see his plugin
  don't build, care (hopefully :D), and then fix it directly even
  before committing and then before anybody else could face the
  problem. Don't you think?
 
  Just thinking about adding a flag which is activating a paranoid
  check inside default build system and which lead into failing
  buildsin such a case. This would give plugin devs the chance to
  fix their code on one hand and unexperienced people which just
  want to test to have a build they can do their stuff with.
  
  Yeah, so long as it doesn't make the whole system too complicated
  and is well documented, it has to be easily usable and
  maintainable :-)
 It would be easy to add a flag to enable/disable the warnings
 (actually I already had a flag to disable the warnings, thought they
 was enabled by default). However in Autotools side it's probably only
 really doable at configure-time, don't know for Waf.
 
 So you'd prefer what:
 1) enable warnings by default, and propose some to errors with a flag
 2) no warnings by default, can be enabled by a flag (with or wtithout
 error promotion?)
 
 IMHO 1) is better so the developers gets the warnings, and it would
 still please everyone since these wouldn't be fatal -- only ugly :D.
 
 If we finally agree with the flags I suggested minus the errors, I
 could set this up soon. Needs agreement (or not) then :)

I think we shall start with the compiling flags (I'm not this familiar
with them so I cannot say which of them are really useful) with just
warnings for the start. This should give a first impression to
everybody where we are and some period we can do the next steps. As a
new release for Geany-plugins is not scheduled yet it should also be
fine to add them in a first step directly.

Cheers, 
Frank
-- 
http://frank.uvena.de/en/


pgpEFumeEVwcX.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] Ideas on increasing quality of plugins

On Sat, 12 Mar 2011 16:09:29 +0100
Colomban Wendling lists@herbesfolles.org wrote:

  This issue is the same
  for for all other validation tools (valgrind, etc). Actually such
  maintains bother can be enough reason to abandon geany-plugins and
  move plugins to somewhere else.

 It would probably be sad, and it's not the goal, but we try to find a
 way to improve plugin quality. And to achieve this, we need to have
 some criteria.
 Of course the goal is not to enforce a ton of coding standards,
 validation process and stuff, and if a particular developer have a
 complain about something we will discuss it without problem.
 
 But OTOH, if a plugin developer finds annoying to try to enforce a
 minimal quality on his plugin (the less crashers possible, not too
 many memory leaks, etc.), maybe geany-plguins don't want him. But I'm
 quite confident all developers want their code to be the better, so
 they would care :)

I second this :)
Maybe the user also don't want to have his/her plugin either :)

Cheers, 
Frank
-- 
http://frank.uvena.de/en/


pgpgA2v9TBtfa.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] Ideas on increasing quality of plugins

Le 11/03/2011 19:37, Colomban Wendling a écrit :
 Le 08/03/2011 22:29, Colomban Wendling a écrit :
 I'd like to commit this to the Autotools build system:
 
 1) run cppcheck on `make check`;
 2) enable by default, if compiler understands them, the following
 warnings (discussed in other mails of this thread):
  * -Werror=implicit-function-declaration
  * -Werror=pointer-arith
  * -Wundef
  * -Wshadow
  * -Wwrite-strings

After thinking a little further, I updated my flags list first to remove
error= stuff to fit the discussion result, and propose a few more,
extracted from -Wall:

 * -Warray-bounds: warns about some out-of-bound array subscripting
 * -Wformat: warns about wrong format/arguments in printf-like functions
 * -Wimplicit-int: warns if the return type of a function is not missing
 * -Wimplicit-function-declaration: warns if a function is not defined
 * -Wnonnull: warns when passing NULL as argument marked as non-nullable
 * -Wpointer-arith: warns about arithmetic usage of untyped pointers
 * -Wreturn-type: warns about missing return values in functions
 * -Wsequence-point: warns when the code might result to undefined
result (e.g. a[i++] = i)
 * -Wshadow: warns when shadowing symbols
 * -Wstrict-aliasing: warns when breaking strict aliasing rules [1]
 * -Wstrict-overflow=1: warns when breaking strict overflow rules [1]
 * -Wtrigraphs: warns about trigraphs that may be interpreted
 * -Wundef: warns when testing undefined constants with the preprocessor
 * -Wuninitialized: warns when detecting use of undefined varaibles
 * -Wunused-value: warns when computing an unused value
 * -Wunused-variable: warns about unused variables
 * -Wwrite-strings: makes string literals constant, used to find case
where string literals are used as a modifiable value, which should be
avoided.

All of these but -Wpointer-arith, -Wshadow, -Wundef and -Wwrite-strings
are part of GCC's -Wall.
Maybe we might directly use -Wall, but it warns about some things that
are not really needed, such as unused functions.

Actually, apart -Wwrite-strings, these flags don't show so much warnings :)

So (once again), do these flags seems reasonable to you?


Cheers,
Colomban


[1] see GCC's manual for details ;)
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

On Sat, 12 Mar 2011 23:34:56 +0100
Colomban Wendling lists@herbesfolles.org wrote:

 Maybe we might directly use -Wall, but it warns about some things that
 are not really needed, such as unused functions.

Well, I'd like to get informed about unused functions. 

Cheers, 
Frank
-- 
http://frank.uvena.de/en/


pgpFZqI36vs4T.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] Ideas on increasing quality of plugins

Le 12/03/2011 23:49, Frank Lanitz a écrit :
 On Sat, 12 Mar 2011 23:34:56 +0100
 Colomban Wendling lists@herbesfolles.org wrote:
 
 Maybe we might directly use -Wall, but it warns about some things that
 are not really needed, such as unused functions.
 
 Well, I'd like to get informed about unused functions. 
Oh, so we might want to simply use -Wall then -- though it also adds
-Wswitch that warns for unhandled enumeration values if the is no
default: (it is useful in some case but might produce tons of warnings
that aren't really important).

Anybody against it?

Cheers,
Colomban
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

Le 13/03/2011 02:38, Lex Trotman a écrit :
 On 13 March 2011 09:34, Colomban Wendling lists@herbesfolles.org wrote:
 [...]
  * -Warray-bounds: warns about some out-of-bound array subscripting
  * -Wformat: warns about wrong format/arguments in printf-like functions
  * -Wimplicit-int: warns if the return type of a function is not missing
 
 Actually warns when the function type IS missing, but know what you mean :-)

Woops! I must have reworded my sentence incorrectly :D

  [...]

 All of these but -Wpointer-arith, -Wshadow, -Wundef and -Wwrite-strings
 are part of GCC's -Wall.
 Maybe we might directly use -Wall, but it warns about some things that
 are not really needed, such as unused functions.

 Actually, apart -Wwrite-strings, these flags don't show so much warnings :)

 So (once again), do these flags seems reasonable to you?
 
 Well if they are warnings only, the more the merrier, I'd use -Wall
 and -Wextras but noting that there is a possibility that some plugin
 might need a customised list if there is a good reason why it is
 correct and can't reasonably avoid some warning.  Up to the plugin dev
 to tell us why, but hey we're reasonable aren't we? :-)

The problem of -Wextra is that it adds -Wunused-parameter, which is a
bit annoying when writing callbacks (you get tons of them, and you don't
have to fix them).
But it adds some cool stuff too (for example -Wmissing-parameter-type
and -Wold-style-declaration). Maybe we would like to use -Wall -Wextra
-Wno-unused-parameter, or only pick the warning we like from -Wextra.

I don't think we should add too much warnings with false-positive (like
-Wunused-parameter) by default, because they are likely to:
 * make the unexperienced programmer try to fix them, though actually
they shouldn't be [1];
 * hide some more interesting warnings between plenty of false ones;
 * annoy some developers without good reason.

 Note most developers compile Geany itself with -Wall at least (iaw the
 Hacking file) and Nick has some extras he likes.

Of course -- I personally use the following for all my builds: :D
-Wall -W -Wunused -Wunreachable-code -Wformat=2 -Wundef -Wshadow
-Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wconversion
-Waggregate-return -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute
-Wredundant-decls -Wnested-externs -pedantic
-Werror-implicit-function-declaration -fshow-column

But these are maybe a little too much, they usually generate a bunch of
warnings that should not be fixed since they are false-positive actually.

 Also note that some warnings need at least -O2 so the compiler does
 the dataflow tracing needed to detect the warning.

Right, but -O2 also have some drawbacks when debugging, so I'm not sure
we want to add it by default.

 PS we are only talking about gcc flags here but I think we only supprt
 gcc even on Windows, right Enrico?

Actually I check whether the compiler understand each flag, so it would
be easy to support any compiler. I only talk about GCC warnings because
I only know GCC's flags, but if somebody knows some other, we might add
them.


Cheers,
Colomban


[1] for example, hiding an unused parameter warning by faking a usage
(like (void)param) generally only bloats the code without any benefit
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

2011-03-12 Thread Lex Trotman

On 13 March 2011 13:57, Colomban Wendling lists@herbesfolles.org wrote:
 Le 13/03/2011 02:38, Lex Trotman a écrit :
 On 13 March 2011 09:34, Colomban Wendling lists@herbesfolles.org wrote:
 [...]
  * -Warray-bounds: warns about some out-of-bound array subscripting
  * -Wformat: warns about wrong format/arguments in printf-like functions
  * -Wimplicit-int: warns if the return type of a function is not missing

 Actually warns when the function type IS missing, but know what you mean :-)

 Woops! I must have reworded my sentence incorrectly :D

  [...]

 All of these but -Wpointer-arith, -Wshadow, -Wundef and -Wwrite-strings
 are part of GCC's -Wall.
 Maybe we might directly use -Wall, but it warns about some things that
 are not really needed, such as unused functions.

 Actually, apart -Wwrite-strings, these flags don't show so much warnings :)

 So (once again), do these flags seems reasonable to you?

 Well if they are warnings only, the more the merrier, I'd use -Wall
 and -Wextras but noting that there is a possibility that some plugin
 might need a customised list if there is a good reason why it is
 correct and can't reasonably avoid some warning.  Up to the plugin dev
 to tell us why, but hey we're reasonable aren't we? :-)

 The problem of -Wextra is that it adds -Wunused-parameter, which is a
 bit annoying when writing callbacks (you get tons of them, and you don't
 have to fix them).
 But it adds some cool stuff too (for example -Wmissing-parameter-type
 and -Wold-style-declaration). Maybe we would like to use -Wall -Wextra
 -Wno-unused-parameter, or only pick the warning we like from -Wextra.

You're right, I forgot about callbacks, -Wno-unused-parameter is
better than having to splash G_GNUC_UNUSED all through the code.


 I don't think we should add too much warnings with false-positive (like
 -Wunused-parameter) by default, because they are likely to:
  * make the unexperienced programmer try to fix them, though actually
 they shouldn't be [1];
  * hide some more interesting warnings between plenty of false ones;
  * annoy some developers without good reason.

Yes, thats why I say some plugins might have to have customised lists
of options if they generate too many false positives, but I should
think most will be ok.
I guess customised option lists is a pain in the build scripts though,
your call.


 Note most developers compile Geany itself with -Wall at least (iaw the
 Hacking file) and Nick has some extras he likes.

 Of course -- I personally use the following for all my builds: :D
 -Wall -W -Wunused -Wunreachable-code -Wformat=2 -Wundef -Wshadow
 -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wconversion
 -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes
 -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute
 -Wredundant-decls -Wnested-externs -pedantic
 -Werror-implicit-function-declaration -fshow-column

 But these are maybe a little too much, they usually generate a bunch of
 warnings that should not be fixed since they are false-positive actually.

Yes, might be a *little* too much :-) Whilst they are all useful some
won't help prevent plugin crashes eg -Wunreachable-code


 Also note that some warnings need at least -O2 so the compiler does
 the dataflow tracing needed to detect the warning.

 Right, but -O2 also have some drawbacks when debugging, so I'm not sure
 we want to add it by default.

Yes, maybe only the release version should do O2 by default just to
ensure that the checks are done.


 PS we are only talking about gcc flags here but I think we only supprt
 gcc even on Windows, right Enrico?

 Actually I check whether the compiler understand each flag, so it would
 be easy to support any compiler. I only talk about GCC warnings because
 I only know GCC's flags, but if somebody knows some other, we might add
 them.

Ok.

Cheers
Lex



 Cheers,
 Colomban


 [1] for example, hiding an unused parameter warning by faking a usage
 (like (void)param) generally only bloats the code without any benefit

___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

Le 08/03/2011 22:29, Colomban Wendling a écrit :
 Le 08/03/2011 19:58, Enrico Tröger a écrit :
 On Tue, 08 Mar 2011 11:06:16 +0100, Frank wrote:
 I like that idea. Can someone of you build up a howto on how to use it?
 I did try valgrind in past and wished for some advice ;)

 One this is done we can think of automatic tests with some of this
 tools.

 I, and obviously, Colomban as well, though indepdent from each other :D,
 recently played[1,2] with cppcheck. A small tool for static code
 analysis which actually found a few things in the geany-plugins
 repository.

 As I'm currently reworking the system to create the nightly builds, we
 could integrate such checks into the nightly builds, maybe run cppcheck
 on the sources after the builds and present the results somewhere on
 nightly.geany.org.
 I think it's a good idea.
 
 I did a few checks, and this is what I suggest:
 1) run cppcheck on `make check` and abort if it detects an error;
 2) enable by default (though in a portable manner) some compiler flags
 such as -Werror-implicit-function-declaration [1] [2]
 
 Maybe some other tests might be good, but I think this is a start.
I'd like to commit this to the Autotools build system:

1) run cppcheck on `make check`;
2) enable by default, if compiler understands them, the following
warnings (discussed in other mails of this thread):
 * -Werror=implicit-function-declaration
 * -Werror=pointer-arith
 * -Wundef
 * -Wshadow
 * -Wwrite-strings

There are currently 2 problems that would prevents the tests to pass:
1) The debugger plugin don't compile with
-Werror=implicit-function-declaration (this should be fixed --
Alexander, could you fix them please?);
2) cppcheck reports an error on geanylatex plugin; but I know Frank
already fixed this and so has probably only to import the fix in the
geany-plugins copy.

1 is really problematic since it require one to disable the debugger
plugin to be able to compiler the others, 2 is only problematic when
running `make check` so not so important in the meantime Frank fixes the
problem.

Do you have objections, comment or whatever?

Cheers,
Colomban
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

On Wed, 09 Mar 2011 07:27:06 -0800
Matthew Brush matthewbr...@gmail.com wrote:

 On 03/09/11 03:42, Frank Lanitz wrote:
  Hi,
 
 
  Am 23.02.2011 01:10, schrieb Matthew Brush:
  Another thing could be to make mandatory that documentation is
  existent and current, up to some standard.  I mean for README,
  manual, and also doc-comments in code (ex. each function/global
  must have a comment or something).  Some other items where
  documentation could be enforced; new keybindings, preferences,
  menu/toolbar items, tabs.
  I agree in a general view. According to code comments I'm not sure.
  But can you give me some more details what did you think about when
  you referred to the keybindings, preferences etc.?
 
 Sure!  The perfect example, although I haven't tried it in a little
 bit, is the Debugger plugin.  You load the plugin and see the tab in
 the Message Window, and it looks really cool and useful.  Obviously I
 wanted to try it out right away, so I start to hover over the GUI
 elements hoping for some tooltips to guide me to what to do, but
 nope.  There was nothing in the README (at least when I tried).  So
 then I tried to just figure it out.  Finally after about 10 minutes I
 figure out that Target means the binary executable you want to
 debug, which seems kinda obvious now, but at the time the wording
 alone of target didn't seem to cut it.
 
 So after that now I want to run it.  I spent another 10-15 minutes 
 looking through the Toolbar, Build menu, Tools menu, etc looking for 
 where I can invoke the Debugger.  There was nothing in the README.  
 Finally I looked under the Keybindings preferences and saw there was 
 keybindings to run it, and there was no default keybindings selected.
 
 Point of that story is that *all* I needed was a few hints about what 
 the plugin added to the GUI and what I needed to do to invoke it.  
 Things like the new keybindings, their defaults, etc.  Personally,
 after using some other IDEs, I would have expect a toolbar menu
 button with step into, step out of, etc.  So I guess what I mean
 is, if you add a keybinding, or a preference, or a menu item or
 toolbar item, it should be documented.
 
 I don't mean to pick on the Debugger plugin, I think it's *really*
 cool and I can appreciate that it's still under development, but this
 is specifically what I was thinking of when I wrote that in my
 previous message.

Ah I see. So basicly what you refer to is having a suitable
documentation at all with most important things as well as ensure there
is a basic 'ingame' docu. Did I understand it correct?

Cheers, 
Frank 
-- 
http://frank.uvena.de/en/


pgpBtE9gMHcwj.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] Ideas on increasing quality of plugins

On Fri, 11 Mar 2011 19:37:14 +0100
Colomban Wendling lists@herbesfolles.org wrote:

 2) cppcheck reports an error on geanylatex plugin; but I know Frank
 already fixed this and so has probably only to import the fix in the
 geany-plugins copy.

Yepp. Should be the issue we talked about before. 

Cheers, 
Frank
-- 
http://frank.uvena.de/en/


pgpno1knSGAMz.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] Ideas on increasing quality of plugins

On Wed, 23 Feb 2011 15:28:05 +0300
Alexander Petukhov alexander.petuk...@mail.ru wrote:

 And one more thing, as a debian user I see that there is still 0.19
 plugins version even in unstable, maybe it's a good idea to   move
 current developing version (0.21?) to unstable / testing to  make
 debian users to help us in bug reporting?

I did see Geany 0.20 has been migrated. I'm sure the plugins will
follow soon. 
-- 
http://frank.uvena.de/en/


pgpR5bnwwoQfk.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] Ideas on increasing quality of plugins

On Wed, 23 Feb 2011 15:28:05 +0300
Alexander Petukhov alexander.petuk...@mail.ru wrote:

 5. Other language bindings - don't really think it can increase
 plugins quality dramatically, there can be problems in any language
 that you have to solve in order to make your code work correctly.

I agree. It will might also split up resources on core side to support
maybe 5 API as even you do use some kind of automatically binding it
will not working out of the box in every case. 

Cheers, 
Frank
-- 
http://frank.uvena.de/en/


pgpbEIjInmpt8.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] Ideas on increasing quality of plugins

On Wed, 23 Feb 2011 12:41:54 -0800
Matthew Brush matthewbr...@gmail.com wrote:

  4. Removing unsupported plugins from releases
  what do you think about the following scheme: divide all pluging
  into:
  - supported (that are acting really well)
  - unsupported or bad (having problems) ?
  So, every geany-plugins release will contain several packages:
  geany-plugins, geany-plugins-bad or geany-plugins-unsupported,
  something like this

 This is like GStreamer plugins and I think it's a very good idea.
 They could be grouped in the configure.ac file to add an option like 
 --enable-bad and --enable--unsupported or something.

How this is going to be maintained? Somebody has to take over
responsibility to set the flag. 

Cheers, 
Frank 
-- 
http://frank.uvena.de/en/


pgpQM80R5qU8l.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] Ideas on increasing quality of plugins

On Fri, 11 Mar 2011 15:36:50 -0800
Matthew Brush matthewbr...@gmail.com wrote:

 On 03/11/11 14:43, Frank Lanitz wrote:
  On Wed, 09 Mar 2011 07:27:06 -0800
  Matthew Brushmatthewbr...@gmail.com  wrote:
 
  On 03/09/11 03:42, Frank Lanitz wrote:
  Hi,
 
 
  Am 23.02.2011 01:10, schrieb Matthew Brush:
  Another thing could be to make mandatory that documentation is
  existent and current, up to some standard.  I mean for README,
  manual, and also doc-comments in code (ex. each function/global
  must have a comment or something).  Some other items where
  documentation could be enforced; new keybindings, preferences,
  menu/toolbar items, tabs.
  I agree in a general view. According to code comments I'm not
  sure. But can you give me some more details what did you think
  about when you referred to the keybindings, preferences etc.?
  Sure!  The perfect example, although I haven't tried it in a little
  bit, is the Debugger plugin.  You load the plugin and see the tab
  in the Message Window, and it looks really cool and useful.
  Obviously I wanted to try it out right away, so I start to hover
  over the GUI elements hoping for some tooltips to guide me to what
  to do, but nope.  There was nothing in the README (at least when I
  tried).  So then I tried to just figure it out.  Finally after
  about 10 minutes I figure out that Target means the binary
  executable you want to debug, which seems kinda obvious now, but
  at the time the wording alone of target didn't seem to cut it.
 
  So after that now I want to run it.  I spent another 10-15 minutes
  looking through the Toolbar, Build menu, Tools menu, etc looking
  for where I can invoke the Debugger.  There was nothing in the
  README. Finally I looked under the Keybindings preferences and saw
  there was keybindings to run it, and there was no default
  keybindings selected.
 
  Point of that story is that *all* I needed was a few hints about
  what the plugin added to the GUI and what I needed to do to invoke
  it. Things like the new keybindings, their defaults, etc.
  Personally, after using some other IDEs, I would have expect a
  toolbar menu button with step into, step out of, etc.  So I
  guess what I mean is, if you add a keybinding, or a preference, or
  a menu item or toolbar item, it should be documented.
 
  I don't mean to pick on the Debugger plugin, I think it's *really*
  cool and I can appreciate that it's still under development, but
  this is specifically what I was thinking of when I wrote that in my
  previous message.
  Ah I see. So basicly what you refer to is having a suitable
  documentation at all with most important things as well as ensure
  there is a basic 'ingame' docu. Did I understand it correct?
 
 I'm not sure what 'ingame' docu means but what I mean is there
 should be a few minimal requirements, such as:
- Tooltips on widgets added to the UI (where it makes sense)
- A plugin_help() implementation, even if it just links to the
 README on plugins.geany.org
- A README file with text content including
- The purpose of the plugin, what it accomplishes, etc.
- A list of keybindings that will be available when the plugin
 is loaded
- A usage section explaining at least the basic way to use the
 plugin
- A description of the new menu items, tool items, and so on 
 introduced to the UI.
 
 This is just some ideas...

Yepp, that's what I understood under 'ingame' ;)


-- 
http://frank.uvena.de/en/


pgpaaFy3kuTFS.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] Ideas on increasing quality of plugins

Le 12/03/2011 01:18, Lex Trotman a écrit :
 Maybe some other tests might be good, but I think this is a start.
 I'd like to commit this to the Autotools build system:

 1) run cppcheck on `make check`;
 2) enable by default, if compiler understands them, the following
 warnings (discussed in other mails of this thread):
  * -Werror=implicit-function-declaration
  * -Werror=pointer-arith
  * -Wundef
  * -Wshadow
  * -Wwrite-strings
 
 Good start.
Feel free to suggest more :)

 There are currently 2 problems that would prevents the tests to pass:
 1) The debugger plugin don't compile with
 -Werror=implicit-function-declaration (this should be fixed --
 Alexander, could you fix them please?);
 2) cppcheck reports an error on geanylatex plugin; but I know Frank
 already fixed this and so has probably only to import the fix in the
 geany-plugins copy.

 1 is really problematic since it require one to disable the debugger
 plugin to be able to compiler the others,
 
 Why do we have to disable the dubugger, sure it gives warnings, but
 for nightly builds and SVN builds thats ok, the disabling only comes
 at release time.
Since I set -W*error=*implicit-function-declaration, the implicit
function declaration warnings are treated as errors and then aborts the
build (unless one uses make -k of course).

We could downgrade this to a warning, but I think this is a problem
important enough to trigger an error.

Cheers,
Colomban
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

On 12 March 2011 11:23, Colomban Wendling lists@herbesfolles.org wrote:
 Le 12/03/2011 01:18, Lex Trotman a écrit :
 Maybe some other tests might be good, but I think this is a start.
 I'd like to commit this to the Autotools build system:

 1) run cppcheck on `make check`;
 2) enable by default, if compiler understands them, the following
 warnings (discussed in other mails of this thread):
  * -Werror=implicit-function-declaration
  * -Werror=pointer-arith
  * -Wundef
  * -Wshadow
  * -Wwrite-strings

 Good start.
 Feel free to suggest more :)

 There are currently 2 problems that would prevents the tests to pass:
 1) The debugger plugin don't compile with
 -Werror=implicit-function-declaration (this should be fixed --
 Alexander, could you fix them please?);
 2) cppcheck reports an error on geanylatex plugin; but I know Frank
 already fixed this and so has probably only to import the fix in the
 geany-plugins copy.

 1 is really problematic since it require one to disable the debugger
 plugin to be able to compiler the others,

 Why do we have to disable the dubugger, sure it gives warnings, but
 for nightly builds and SVN builds thats ok, the disabling only comes
 at release time.
 Since I set -W*error=*implicit-function-declaration, the implicit
 function declaration warnings are treated as errors and then aborts the
 build (unless one uses make -k of course).

 We could downgrade this to a warning, but I think this is a problem
 important enough to trigger an error.

The general consensus seemed to be to not disable plugins from the
nightly builds or SVN just because they fail some tests, so these will
have to all be warnings.

There still seems to be some discussion on how to handle plugins that
don't compile cleanly, or have documentation at release time.

Cheers
Lex



 Cheers,
 Colomban

___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

2011-03-11 Thread Matthew Brush


On 03/11/11 15:24, Frank Lanitz wrote:

On Wed, 23 Feb 2011 15:28:05 +0300
Alexander Petukhovalexander.petuk...@mail.ru  wrote:


5. Other language bindings - don't really think it can increase
plugins quality dramatically, there can be problems in any language
that you have to solve in order to make your code work correctly.

I agree. It will might also split up resources on core side to support
maybe 5 API as even you do use some kind of automatically binding it
will not working out of the box in every case.

If the core API were more binding friendly, for example using standard 
GObject conventions, a HUGE portion of the work doing bindings would be 
completely automated for quite a number of languages, without any need 
to customize the core for them.  The things that don't work out of the 
box would be fixed in the binding itself as is common with other 
bindings of things.  This is the whole purpose of things like GObject 
introspection (to make GObject bindings automatic and natural to that 
language).


As an example, the Vala bindings are being hacked to death to make them 
more like Vala-ish (make that GObject-ish), when this would be a 
basically fully automated process if the API was already GObject-ish.  
Same with Genie, Python, and probably others with GObject support like 
Perl, Ruby, Scheme, C++, and so on.


Even if it didn't lead to improved plugin quality, which it would at 
least for languages using VMs/interpreters, it would create a lot of new 
functionality for Geany by having much more participation from a wider 
range of programmers.  Just hanging around on the ML and IRC I've heard 
many times Geany users saying they would like to make a plugin but they 
don't know C, they are experts on some other language.  One of the big 
benefits of a plugin system is making it easy for users to extend the 
program, and IMO making the users learn and code properly in C does not 
(necessarily) accomplish that goal.


The barrier to entry to writing Geany plugins currently is such that a 
very small portion of the users (programmers) are able to extend the 
software at all, and those that fake it in C will end up with nasty mess 
of buggy code (like me :).


My 0.02$ CAD

Matthew Brush (codebrainz)
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

Le 12/03/2011 01:32, Lex Trotman a écrit :
 On 12 March 2011 11:23, Colomban Wendling lists@herbesfolles.org wrote:
 Le 12/03/2011 01:18, Lex Trotman a écrit :
 Maybe some other tests might be good, but I think this is a start.
 I'd like to commit this to the Autotools build system:

 1) run cppcheck on `make check`;
 2) enable by default, if compiler understands them, the following
 warnings (discussed in other mails of this thread):
  * -Werror=implicit-function-declaration
  * -Werror=pointer-arith
  * -Wundef
  * -Wshadow
  * -Wwrite-strings

 Good start.
 Feel free to suggest more :)

 There are currently 2 problems that would prevents the tests to pass:
 1) The debugger plugin don't compile with
 -Werror=implicit-function-declaration (this should be fixed --
 Alexander, could you fix them please?);
 2) cppcheck reports an error on geanylatex plugin; but I know Frank
 already fixed this and so has probably only to import the fix in the
 geany-plugins copy.

 1 is really problematic since it require one to disable the debugger
 plugin to be able to compiler the others,

 Why do we have to disable the dubugger, sure it gives warnings, but
 for nightly builds and SVN builds thats ok, the disabling only comes
 at release time.
 Since I set -W*error=*implicit-function-declaration, the implicit
 function declaration warnings are treated as errors and then aborts the
 build (unless one uses make -k of course).

 We could downgrade this to a warning, but I think this is a problem
 important enough to trigger an error.
 
 The general consensus seemed to be to not disable plugins from the
 nightly builds or SVN just because they fail some tests, so these will
 have to all be warnings.
It's a bit more complicated IMO: if these warnings are on by default in
everyone's build, a code failing with them would just be as invalid as
an invalid C code (e.g. breaks everyone's build, and isn't acceptable at
all).
The problem here is that there is currently a plugin that can't be
compiled with them, so enabling them would mean disabling the plugin
that used to build.

Maybe the solution is to wait for Alexander to fix these problems, and
then enable the errors.

Cheers,
Colomban

 
 There still seems to be some discussion on how to handle plugins that
 don't compile cleanly, or have documentation at release time.
 
 Cheers
 Lex
 
 

 Cheers,
 Colomban


___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

On 12 March 2011 11:35, Matthew Brush matthewbr...@gmail.com wrote:
 On 03/11/11 15:24, Frank Lanitz wrote:

 On Wed, 23 Feb 2011 15:28:05 +0300
 Alexander Petukhovalexander.petuk...@mail.ru  wrote:

 5. Other language bindings - don't really think it can increase
 plugins quality dramatically, there can be problems in any language
 that you have to solve in order to make your code work correctly.

 I agree. It will might also split up resources on core side to support
 maybe 5 API as even you do use some kind of automatically binding it
 will not working out of the box in every case.

 If the core API were more binding friendly, for example using standard
 GObject conventions, a HUGE portion of the work doing bindings would be
 completely automated for quite a number of languages, without any need to
 customize the core for them.  The things that don't work out of the box
 would be fixed in the binding itself as is common with other bindings of
 things.  This is the whole purpose of things like GObject introspection (to
 make GObject bindings automatic and natural to that language).

 As an example, the Vala bindings are being hacked to death to make them more
 like Vala-ish (make that GObject-ish), when this would be a basically fully
 automated process if the API was already GObject-ish.  Same with Genie,
 Python, and probably others with GObject support like Perl, Ruby, Scheme,
 C++, and so on.

 Even if it didn't lead to improved plugin quality, which it would at least
 for languages using VMs/interpreters, it would create a lot of new
 functionality for Geany by having much more participation from a wider range
 of programmers.  Just hanging around on the ML and IRC I've heard many times
 Geany users saying they would like to make a plugin but they don't know C,
 they are experts on some other language.  One of the big benefits of a
 plugin system is making it easy for users to extend the program, and IMO
 making the users learn and code properly in C does not (necessarily)
 accomplish that goal.

 The barrier to entry to writing Geany plugins currently is such that a very
 small portion of the users (programmers) are able to extend the software at
 all, and those that fake it in C will end up with nasty mess of buggy code
 (like me :).

 My 0.02$ CAD

 Matthew Brush (codebrainz)

Hi Matthew,

I wasn't party to the original design of the Geany plugin API/ABI so I
don't have any investment in it.

I can see why it was done the way it is, it has several potential
advantages in terms of reducing plugin re-compilation requirements,
although it loses some of that by being very conservative (but safe)
in terms of its run time acceptance of older plugins.  But as you
point out it isn't easy to bind to.

As we have discussed before, replacing the interface isn't acceptable,
but that doesn't mean that a second interface that is automatically
GObjectable, SWIGable introspectable etc.can't be added.

Over time existing plugins can then be migrated and the old interface removed.

But someone has to do it (tm) and of course patches are welcome (c)...

Cheers
Lex

$0.02AUD worth about the same :-)

 ___
 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] Ideas on increasing quality of plugins

Le 12/03/2011 01:51, Lex Trotman a écrit :
 On 12 March 2011 11:44, Colomban Wendling lists@herbesfolles.org wrote:
 Le 12/03/2011 01:32, Lex Trotman a écrit :
 On 12 March 2011 11:23, Colomban Wendling lists@herbesfolles.org 
 wrote:
 Le 12/03/2011 01:18, Lex Trotman a écrit :
 Maybe some other tests might be good, but I think this is a start.
 I'd like to commit this to the Autotools build system:

 1) run cppcheck on `make check`;
 2) enable by default, if compiler understands them, the following
 warnings (discussed in other mails of this thread):
  * -Werror=implicit-function-declaration
  * -Werror=pointer-arith
  * -Wundef
  * -Wshadow
  * -Wwrite-strings

 Good start.
 Feel free to suggest more :)

 There are currently 2 problems that would prevents the tests to pass:
 1) The debugger plugin don't compile with
 -Werror=implicit-function-declaration (this should be fixed --
 Alexander, could you fix them please?);
 2) cppcheck reports an error on geanylatex plugin; but I know Frank
 already fixed this and so has probably only to import the fix in the
 geany-plugins copy.

 1 is really problematic since it require one to disable the debugger
 plugin to be able to compiler the others,

 Why do we have to disable the dubugger, sure it gives warnings, but
 for nightly builds and SVN builds thats ok, the disabling only comes
 at release time.
 Since I set -W*error=*implicit-function-declaration, the implicit
 function declaration warnings are treated as errors and then aborts the
 build (unless one uses make -k of course).

 We could downgrade this to a warning, but I think this is a problem
 important enough to trigger an error.

 The general consensus seemed to be to not disable plugins from the
 nightly builds or SVN just because they fail some tests, so these will
 have to all be warnings.
 It's a bit more complicated IMO: if these warnings are on by default in
 everyone's build, a code failing with them would just be as invalid as
 an invalid C code (e.g. breaks everyone's build, and isn't acceptable at
 all).
 
 Well on the development code base warnings should not break the build,
 if they do thats another problem :-)
...and invalid C code should neither, but it does :(
What I mean is that it is acceptable IMO to consider some mistakes as
invalid syntax.

  In fact even errors should also
 not break the whole build, just the specific plugin.
agreed. But that's a somewhat different point I guess... maybe just tell
people to use `make -k` ^^

 The problem here is that there is currently a plugin that can't be
 compiled with them, so enabling them would mean disabling the plugin
 that used to build.

 Maybe the solution is to wait for Alexander to fix these problems, and
 then enable the errors.

 
 But the next patch commit on any plugin could fail one of the checks,
 so then the whole dev build fails again, thats no good, its got to
 still build with warnings, its a development build after all.
but again, what if I add

  hello guys!

in the middle of the code?
Or even more realistic (someone might even understand... :D)

  if some test { foo_bar(); }

In this case, what would you do? Blame the programmer most probably. And
you'd be right IMO :)

Cheers,
Colomban
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

Le 12/03/2011 02:37, Lex Trotman a écrit :
 The general consensus seemed to be to not disable plugins from the
 nightly builds or SVN just because they fail some tests, so these will
 have to all be warnings.
 It's a bit more complicated IMO: if these warnings are on by default in
 everyone's build, a code failing with them would just be as invalid as
 an invalid C code (e.g. breaks everyone's build, and isn't acceptable at
 all).

 Well on the development code base warnings should not break the build,
 if they do thats another problem :-)
 ...and invalid C code should neither, but it does :(
 
 Hmmm, that IS a problem, do we know why? Is make -k sufficient to fix
 it?  (Sorry I can't try building things on this machine so I can only
 ask the question)
 
 What I mean is that it is acceptable IMO to consider some mistakes as
 invalid syntax.
 
 Maaaybe, sort of see your point, but not really convinced that
 uprating warnings to errors is a good idea on the dev codebase, it
 stops people trying and testing things.
Unfortunately, believe me that non-fatal warnings are use to be ignored
by unexperienced programmers, believing that if their code compile it is
then OK.
And I don't see why a warning upgraded to an error on every build would
be worst than a syntactical problem (as I described above previously)?
In a typical situation, the developer who writes the plugin should get
the warning (well, the error), see his plugin don't build, care
(hopefully :D), and then fix it directly even before committing and then
before anybody else could face the problem.
Don't you think?

  In fact even errors should also
 not break the whole build, just the specific plugin.
 agreed. But that's a somewhat different point I guess... maybe just tell
 people to use `make -k` ^^
 
 Yep.
 

 The problem here is that there is currently a plugin that can't be
 compiled with them, so enabling them would mean disabling the plugin
 that used to build.

 Maybe the solution is to wait for Alexander to fix these problems, and
 then enable the errors.


 But the next patch commit on any plugin could fail one of the checks,
 so then the whole dev build fails again, thats no good, its got to
 still build with warnings, its a development build after all.
 but again, what if I add

  hello guys!

 in the middle of the code?
 Or even more realistic (someone might even understand... :D)

  if some test { foo_bar(); }

 In this case, what would you do? Blame the programmer most probably. And
 you'd be right IMO :)
 
 Of course it should fail the plugin, but as above, not the whole build.
 
 And I hope we use blame in the non-emotive sense of identify the
 cause of the problem :-)
Maybe my English knowledge is not good enough, but I meant beat down to
death :D [1]

Cheers,
Colomban


[1] hopefully the reader will see the humor and understand I actually
meant something like gently ask the programmer to fix the problem...
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

On 12 March 2011 12:53, Colomban Wendling lists@herbesfolles.org wrote:
 Le 12/03/2011 02:37, Lex Trotman a écrit :
 The general consensus seemed to be to not disable plugins from the
 nightly builds or SVN just because they fail some tests, so these will
 have to all be warnings.
 It's a bit more complicated IMO: if these warnings are on by default in
 everyone's build, a code failing with them would just be as invalid as
 an invalid C code (e.g. breaks everyone's build, and isn't acceptable at
 all).

 Well on the development code base warnings should not break the build,
 if they do thats another problem :-)
 ...and invalid C code should neither, but it does :(

 Hmmm, that IS a problem, do we know why? Is make -k sufficient to fix
 it?  (Sorry I can't try building things on this machine so I can only
 ask the question)

 What I mean is that it is acceptable IMO to consider some mistakes as
 invalid syntax.

 Maaaybe, sort of see your point, but not really convinced that
 uprating warnings to errors is a good idea on the dev codebase, it
 stops people trying and testing things.
 Unfortunately, believe me that non-fatal warnings are use to be ignored
 by unexperienced programmers, believing that if their code compile it is
 then OK.
 And I don't see why a warning upgraded to an error on every build would
 be worst than a syntactical problem (as I described above previously)?
 In a typical situation, the developer who writes the plugin should get
 the warning (well, the error), see his plugin don't build, care
 (hopefully :D), and then fix it directly even before committing and then
 before anybody else could face the problem.
 Don't you think?

I agree that warnings should be fixed, but...

Not only the developer is going to be using the plugins, people who
are testing or even just using the latest will be, so you screw them
up as well as the original developer :-(

And also these users should not need the testing tools installed to
compile, we don't want to increase the dependencies.

And as for the original developer, they now have to build in the same
way  use the same testing tools.  That assumes they are using the
same environment as the nightly builds, and I am not sure I even know
exactly what that is.

Remember I'm only talking about development, I think the community has
a right to ask for a higher standard for releases that the community
is putting its name to.  But during development, preventing compiling
perfectly legal but frowned on code, is an imposition that I don't
think the community currently wants to make (based on other comments
in the thread).



  In fact even errors should also
 not break the whole build, just the specific plugin.
 agreed. But that's a somewhat different point I guess... maybe just tell
 people to use `make -k` ^^

 Yep.


 The problem here is that there is currently a plugin that can't be
 compiled with them, so enabling them would mean disabling the plugin
 that used to build.

 Maybe the solution is to wait for Alexander to fix these problems, and
 then enable the errors.


 But the next patch commit on any plugin could fail one of the checks,
 so then the whole dev build fails again, thats no good, its got to
 still build with warnings, its a development build after all.
 but again, what if I add

  hello guys!

 in the middle of the code?
 Or even more realistic (someone might even understand... :D)

  if some test { foo_bar(); }

 In this case, what would you do? Blame the programmer most probably. And
 you'd be right IMO :)

 Of course it should fail the plugin, but as above, not the whole build.

 And I hope we use blame in the non-emotive sense of identify the
 cause of the problem :-)
 Maybe my English knowledge is not good enough, but I meant beat down to
 death :D [1]

 Cheers,
 Colomban


 [1] hopefully the reader will see the humor and understand I actually
 meant something like gently ask the programmer to fix the problem...

Yes, on the grounds that our worldwide army of automatic beating down
robots has not been deployed yet, I guess we have to fall back to this
:-)

Cheers
Lex


___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

2011-03-11 Thread Matthew Brush


On 03/11/11 18:21, Lex Trotman wrote:


I agree that warnings should be fixed, but...

Not only the developer is going to be using the plugins, people who
are testing or even just using the latest will be, so you screw them
up as well as the original developer :-(
Considering the plugin in question crashed (locked up) my entire Xorg 
session and I lost data, I can't say it would be a dis-service.


Personally (not being the most experienced programmer) I would prefer my 
plugin not build if I had made some very bad programming error, so that 
potential testers don't get a bad taste in their mouth for my plugin.


In a general sense I agree with you though.

Cheers,
Matthew Brush (codebrainz)
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

2011-03-11 Thread Matthew Brush


On 03/11/11 18:33, Matthew Brush wrote:

On 03/11/11 18:21, Lex Trotman wrote:


I agree that warnings should be fixed, but...

Not only the developer is going to be using the plugins, people who
are testing or even just using the latest will be, so you screw them
up as well as the original developer :-(
Considering the plugin in question crashed (locked up) my entire Xorg 
session and I lost data, I can't say it would be a dis-service.



Replying to myself here...

I didn't mean to imply anything about that specific plugin, I actually 
think it's awesome.  I mean with lesser experienced C programmers like 
me in the mix, having some additional checks against obvious programming 
errors might not be a bad idea :)


Cheers,
Matthew Brush (codebrainz)
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

On 12 March 2011 13:33, Matthew Brush matthewbr...@gmail.com wrote:
 On 03/11/11 18:21, Lex Trotman wrote:

 I agree that warnings should be fixed, but...

 Not only the developer is going to be using the plugins, people who
 are testing or even just using the latest will be, so you screw them
 up as well as the original developer :-(

 Considering the plugin in question crashed (locked up) my entire Xorg
 session and I lost data, I can't say it would be a dis-service.

Nasty, but would the problem have been found by the quality tests?


 Personally (not being the most experienced programmer) I would prefer my
 plugin not build if I had made some very bad programming error, so that
 potential testers don't get a bad taste in their mouth for my plugin.

Yes, all developers should try to find all nasties before committing,
so the developer should run the tests that they have the time, tools
and abilities to run.

But there is a wide spectrum of developers and environments and time
and ability varies.  If you are concerned about your own abilities
(good on you for acknowledging it) then you should do all the testing
you can, run all the gotcha checkers etc. but that does have a cost in
terms of your environment and time.  For example I don't have a
windows development environment and my main development Linux is 64
bit, so I can't do exactly the same as the nightly builds do anyway.
Running all the tests in the world doesn't beat someone looking at
your commit though, but that means committing it :-)

To try to make it real lets give an example, lets say you have
developed the automatic mind reader code generator plugin.  I send a
message saying that if I think about coffee it crashes hopelessly and
I can't do anything else.  You have a vague idea where the bug is in
the Java synapse code but you only have time submit a quick fix so I
can go on testing/using the plugin.  Sadly the quick fix works but
happens to violate one of the quality warnings, so now the plugin
won't build and I can't continue to use it, whereas it should be
possible to continue to use the plugin and you fix the warning when
you have time.

There is no way that an automatic system can differentiate between
this sort of problem and your hang and lose data problem, so the
options are only to allow all warnings or allow no warnings, and for
all the reasons above I think no warnings is too harsh, especially if
the developer is relying on the automatic builds to check environments
that they don't have access to, it could take some time to fix and in
the meantime the plugin is unavailable.

But I stress again that we are talking about bleeding edge code here,
nightly builds or SVN builds.  It could pass all the tests and still
delete or sell all your private data.  And it might work fine on my
machine and crash on yours because mine is 64 bit and yours is 32 bit
or yours is Windows.

My approach is to use a release if I'm doing something important, and
bleeding edge if it matters less.  Thats why I was grumpy in the past
when I couldn't build plugins against anything but the system install.
I never sudo install anything from nightly builds or SVN (Geany or
other projects, including work ones) unless its on a disposable
machine.  I'm slowly getting a handle on using virtual machines for
this sort of thing, but I'm not there yet so very old PCs still get
used as disposable, but its a pain to rebuild them when they get
trashed and they are slow, noisy, have small screens etc so I don't do
it as often as I maybe should.

Cheers
Lex


 In a general sense I agree with you though.

 Cheers,
 Matthew Brush (codebrainz)
 ___
 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] Ideas on increasing quality of plugins

2011-03-09 Thread Colomban Wendling

Le 09/03/2011 05:31, Lex Trotman a écrit :
 Hi Colomban,
 
 Agree with most, comment on the rest below.
 
 On 9 March 2011 14:00, Colomban Wendling lists@herbesfolles.org wrote:
 Le 08/03/2011 22:29, Colomban Wendling a écrit :
 Le 08/03/2011 19:58, Enrico Tröger a écrit :
 On Tue, 08 Mar 2011 11:06:16 +0100, Frank wrote:

 Am 23.02.2011 01:10, schrieb Matthew Brush:
 For first thing, maybe we could enforce use/passing of those tools
 mentioned and these before adding to release, examples:
 http://www.splint.org/
 http://valgrind.org/info/tools.html
 (suppression for GTK -
 http://people.gnome.org/~johan/gtk.suppression)
 http://www.gnu.org/software/indent/ (just for making coding styles
 more consistent between plugins) http://check.sourceforge.net/ or
 http://cutest.sourceforge.net/ or http://cunit.sourceforge.net/
 Perhaps some or all of these could be automated.

 I don't suggest (yet) to use splint, because I haven't found it useful,
 it reported ways too much things (and some was false positive) to be
 really usable. However, I probably don't know how to configure it (and
 haven't the time to find out yet), so if somebody with experience with
 it can provide some hints, maybe we can add this too.

 For Valgrind however, I doubt we can do anything automatically, because
 it's a runtime checker, and its output must generally be read with some
 care. Writing some sort of guidelines and howto is probably the way to go.


 I like that idea. Can someone of you build up a howto on how to use it?
 I did try valgrind in past and wished for some advice ;)

 One this is done we can think of automatic tests with some of this
 tools.

 I, and obviously, Colomban as well, though indepdent from each other :D,
 recently played[1,2] with cppcheck. A small tool for static code
 analysis which actually found a few things in the geany-plugins
 repository.

 As I'm currently reworking the system to create the nightly builds, we
 could integrate such checks into the nightly builds, maybe run cppcheck
 on the sources after the builds and present the results somewhere on
 nightly.geany.org.
 I think it's a good idea.

 I did a few checks, and this is what I suggest:
 1) run cppcheck on `make check` and abort if it detects an error;
 2) enable by default (though in a portable manner) some compiler flags
 such as -Werror-implicit-function-declaration [1] [2]
 After a little more thinking and testing, I suggest:

 * -Werror=implicit-function-declaration (see above);
 * -Werror=pointer-arith, to avoid portability issues with untyped
 pointer arithmetic;
 * -Wundef because preprocessor tests should rely on defined variables or
 explicitly use ifdef;
 * -Wshadow because shadowing symbols is a Bad Practice (and maybe it is
 even non-standard, not quite sure however);
 
 Agree for shadow of locals and parameters, agree for globals but only
 because all globals should be prefixed by a module prefix like the
 Geany_ symbols are.  Is there any way to check this?
Not that I know, unfortunately. However maybe a dumb sed/grep might do
the trick.

 * -Waggregate-return because returning aggregate values is no good for
 performances and it's not a Good Practice in C;
 
 Why isn't it good?  Performance should be as good if not better than
 returning multiple parameters via pointers and then assembling the
 aggregate in the caller.  Why isn't it Good Practice?? (your caps :-)
 Its been standard ever since someone invented allocating the return
 variable on the stack prior to the call, so it can be referenced
 relative to the frame pointer.
Well... I must admit I'm not really pro on the subject, but AFAIK the
main problem is ABI, because since the return value will not necessarily
fit in registers the compiler is likely to generate a dummy parameter to
the function (as you might have done yourself), but this implicitly, so
changing the natural ABI of the function.

However it's true that since we don't speak about libraries, we don't
mind about that.

Another point seems to be that some ooold compilers used not to support
aggregate return, though once again we probably don't mind.

OTOH, I don't know of any good (or not BTW) code using aggregates as
return values; maybe there's other reasons?

However, I don't really mind about this one, since even if I used to
think it's a performance issue, it's not a really important point. We're
trying to make code stronger, not necessarily faster :D

 
 * -Wwrite-strings because using a string literal as a modifiable value
 may lead to crashes, and anyway good code should probably assume it's
 constant.

 I thing all is perfectly fine but maybe -Wwrite-strings. What
 -Wwrite-strings does is set all string literals (foobar) constant
 (const char*). It is a good practice to assume string literals are
 constant, but however it is not necessarily wrong to assign it to a
 non-constant variable (if one actually don't modify the value), so it
 may have false positive.
 And actually it probably has: it adds

Re: [Geany-devel] Ideas on increasing quality of plugins

2011-03-09 Thread Matthew Brush


On 03/09/11 03:42, Frank Lanitz wrote:

Hi,


Am 23.02.2011 01:10, schrieb Matthew Brush:

Another thing could be to make mandatory that documentation is existent
and current, up to some standard.  I mean for README, manual, and also
doc-comments in code (ex. each function/global must have a comment or
something).  Some other items where documentation could be enforced; new
keybindings, preferences, menu/toolbar items, tabs.

I agree in a general view. According to code comments I'm not sure. But
can you give me some more details what did you think about when you
referred to the keybindings, preferences etc.?


Sure!  The perfect example, although I haven't tried it in a little bit, 
is the Debugger plugin.  You load the plugin and see the tab in the 
Message Window, and it looks really cool and useful.  Obviously I wanted 
to try it out right away, so I start to hover over the GUI elements 
hoping for some tooltips to guide me to what to do, but nope.  There was 
nothing in the README (at least when I tried).  So then I tried to just 
figure it out.  Finally after about 10 minutes I figure out that 
Target means the binary executable you want to debug, which seems 
kinda obvious now, but at the time the wording alone of target didn't 
seem to cut it.


So after that now I want to run it.  I spent another 10-15 minutes 
looking through the Toolbar, Build menu, Tools menu, etc looking for 
where I can invoke the Debugger.  There was nothing in the README.  
Finally I looked under the Keybindings preferences and saw there was 
keybindings to run it, and there was no default keybindings selected.


Point of that story is that *all* I needed was a few hints about what 
the plugin added to the GUI and what I needed to do to invoke it.  
Things like the new keybindings, their defaults, etc.  Personally, after 
using some other IDEs, I would have expect a toolbar menu button with 
step into, step out of, etc.  So I guess what I mean is, if you add 
a keybinding, or a preference, or a menu item or toolbar item, it should 
be documented.


I don't mean to pick on the Debugger plugin, I think it's *really* cool 
and I can appreciate that it's still under development, but this is 
specifically what I was thinking of when I wrote that in my previous 
message.



I know its not possible for everybody and useful in every case, but I
did try to make on geanyLaTeX docu [1] what I'd like to have for every
plugin.


Cheers,
Frank

[1] http://frank.uvena.de/files/geany/manuals/geanylatex/geanylatex.html
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Cheers,
Matthew Brush (codebrainz)
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

2011-03-09 Thread Lex Trotman

On 10 March 2011 00:45, Colomban Wendling lists@herbesfolles.org wrote:
 Le 09/03/2011 05:31, Lex Trotman a écrit :
 Hi Colomban,

 Agree with most, comment on the rest below.

 On 9 March 2011 14:00, Colomban Wendling lists@herbesfolles.org wrote:
 Le 08/03/2011 22:29, Colomban Wendling a écrit :
 Le 08/03/2011 19:58, Enrico Tröger a écrit :
 On Tue, 08 Mar 2011 11:06:16 +0100, Frank wrote:

 Am 23.02.2011 01:10, schrieb Matthew Brush:
 For first thing, maybe we could enforce use/passing of those tools
 mentioned and these before adding to release, examples:
 http://www.splint.org/
 http://valgrind.org/info/tools.html
 (suppression for GTK -
 http://people.gnome.org/~johan/gtk.suppression)
 http://www.gnu.org/software/indent/ (just for making coding styles
 more consistent between plugins) http://check.sourceforge.net/ or
 http://cutest.sourceforge.net/ or http://cunit.sourceforge.net/
 Perhaps some or all of these could be automated.

 I don't suggest (yet) to use splint, because I haven't found it useful,
 it reported ways too much things (and some was false positive) to be
 really usable. However, I probably don't know how to configure it (and
 haven't the time to find out yet), so if somebody with experience with
 it can provide some hints, maybe we can add this too.

 For Valgrind however, I doubt we can do anything automatically, because
 it's a runtime checker, and its output must generally be read with some
 care. Writing some sort of guidelines and howto is probably the way to go.


 I like that idea. Can someone of you build up a howto on how to use it?
 I did try valgrind in past and wished for some advice ;)

 One this is done we can think of automatic tests with some of this
 tools.

 I, and obviously, Colomban as well, though indepdent from each other :D,
 recently played[1,2] with cppcheck. A small tool for static code
 analysis which actually found a few things in the geany-plugins
 repository.

 As I'm currently reworking the system to create the nightly builds, we
 could integrate such checks into the nightly builds, maybe run cppcheck
 on the sources after the builds and present the results somewhere on
 nightly.geany.org.
 I think it's a good idea.

 I did a few checks, and this is what I suggest:
 1) run cppcheck on `make check` and abort if it detects an error;
 2) enable by default (though in a portable manner) some compiler flags
 such as -Werror-implicit-function-declaration [1] [2]
 After a little more thinking and testing, I suggest:

 * -Werror=implicit-function-declaration (see above);
 * -Werror=pointer-arith, to avoid portability issues with untyped
 pointer arithmetic;
 * -Wundef because preprocessor tests should rely on defined variables or
 explicitly use ifdef;
 * -Wshadow because shadowing symbols is a Bad Practice (and maybe it is
 even non-standard, not quite sure however);

 Agree for shadow of locals and parameters, agree for globals but only
 because all globals should be prefixed by a module prefix like the
 Geany_ symbols are.  Is there any way to check this?
 Not that I know, unfortunately. However maybe a dumb sed/grep might do
 the trick.

 * -Waggregate-return because returning aggregate values is no good for
 performances and it's not a Good Practice in C;

 Why isn't it good?  Performance should be as good if not better than
 returning multiple parameters via pointers and then assembling the
 aggregate in the caller.  Why isn't it Good Practice?? (your caps :-)
 Its been standard ever since someone invented allocating the return
 variable on the stack prior to the call, so it can be referenced
 relative to the frame pointer.
 Well... I must admit I'm not really pro on the subject, but AFAIK the
 main problem is ABI, because since the return value will not necessarily
 fit in registers the compiler is likely to generate a dummy parameter to
 the function (as you might have done yourself), but this implicitly, so
 changing the natural ABI of the function.

Functions that return too much to fit in the registers should use the
stdcall ABI which defines an extra reference parameter for the
aggregate. (Or rather the compiler should use it).  There is no such
thing as a natural ABI that is corrupted by aggregate returns, there
are ABIs defined by Intel and other CPU makers for all the required
call/return patterns.  Yes its slower than returning something in a
register, but if you have got to return an aggregate value thats too
big you have to return it.  Might as well let the compiler do the
heavy lifting rather than having to declare a temporary and pass a
pointer to it as an explicit parameter or otherwise return the
components and assemble the aggregate in the caller.

Back in the dim distant past (1970s) when function prototypes were as
rare as hens teeth such returns were a drama since they required a
prototype.  I don't see why we should continue this restriction as a
hangover from the dinosaurs and the voracious EGCS compiler raptor
:-).

Not that

Re: [Geany-devel] Ideas on increasing quality of plugins

2011-03-09 Thread Thomas Martitz


On 10.03.2011 01:23, Lex Trotman wrote:

On 10 March 2011 00:45, Colomban Wendlinglists@herbesfolles.org  wrote:

Le 09/03/2011 05:31, Lex Trotman a écrit :

Hi Colomban,

Agree with most, comment on the rest below.

On 9 March 2011 14:00, Colomban Wendlinglists@herbesfolles.org  wrote:

Le 08/03/2011 22:29, Colomban Wendling a écrit :

Le 08/03/2011 19:58, Enrico Tröger a écrit :

On Tue, 08 Mar 2011 11:06:16 +0100, Frank wrote:


Am 23.02.2011 01:10, schrieb Matthew Brush:

For first thing, maybe we could enforce use/passing of those tools
mentioned and these before adding to release, examples:
http://www.splint.org/
http://valgrind.org/info/tools.html
(suppression for GTK -
http://people.gnome.org/~johan/gtk.suppression)
http://www.gnu.org/software/indent/ (just for making coding styles
more consistent between plugins) http://check.sourceforge.net/ or
http://cutest.sourceforge.net/ or http://cunit.sourceforge.net/
Perhaps some or all of these could be automated.

I don't suggest (yet) to use splint, because I haven't found it useful,
it reported ways too much things (and some was false positive) to be
really usable. However, I probably don't know how to configure it (and
haven't the time to find out yet), so if somebody with experience with
it can provide some hints, maybe we can add this too.

For Valgrind however, I doubt we can do anything automatically, because
it's a runtime checker, and its output must generally be read with some
care. Writing some sort of guidelines and howto is probably the way to go.


I like that idea. Can someone of you build up a howto on how to use it?
I did try valgrind in past and wished for some advice ;)

One this is done we can think of automatic tests with some of this
tools.

I, and obviously, Colomban as well, though indepdent from each other :D,
recently played[1,2] with cppcheck. A small tool for static code
analysis which actually found a few things in the geany-plugins
repository.

As I'm currently reworking the system to create the nightly builds, we
could integrate such checks into the nightly builds, maybe run cppcheck
on the sources after the builds and present the results somewhere on
nightly.geany.org.

I think it's a good idea.

I did a few checks, and this is what I suggest:
1) run cppcheck on `make check` and abort if it detects an error;
2) enable by default (though in a portable manner) some compiler flags
such as -Werror-implicit-function-declaration [1] [2]

After a little more thinking and testing, I suggest:

* -Werror=implicit-function-declaration (see above);
* -Werror=pointer-arith, to avoid portability issues with untyped
pointer arithmetic;
* -Wundef because preprocessor tests should rely on defined variables or
explicitly use ifdef;
* -Wshadow because shadowing symbols is a Bad Practice (and maybe it is
even non-standard, not quite sure however);

Agree for shadow of locals and parameters, agree for globals but only
because all globals should be prefixed by a module prefix like the
Geany_ symbols are.  Is there any way to check this?

Not that I know, unfortunately. However maybe a dumb sed/grep might do
the trick.


* -Waggregate-return because returning aggregate values is no good for
performances and it's not a Good Practice in C;

Why isn't it good?  Performance should be as good if not better than
returning multiple parameters via pointers and then assembling the
aggregate in the caller.  Why isn't it Good Practice?? (your caps :-)
Its been standard ever since someone invented allocating the return
variable on the stack prior to the call, so it can be referenced
relative to the frame pointer.

Well... I must admit I'm not really pro on the subject, but AFAIK the
main problem is ABI, because since the return value will not necessarily
fit in registers the compiler is likely to generate a dummy parameter to
the function (as you might have done yourself), but this implicitly, so
changing the natural ABI of the function.

Functions that return too much to fit in the registers should use the
stdcall ABI which defines an extra reference parameter for the
aggregate. (Or rather the compiler should use it).  There is no such
thing as a natural ABI that is corrupted by aggregate returns, there
are ABIs defined by Intel and other CPU makers for all the required
call/return patterns.  Yes its slower than returning something in a
register, but if you have got to return an aggregate value thats too
big you have to return it.  Might as well let the compiler do the
heavy lifting rather than having to declare a temporary and pass a
pointer to it as an explicit parameter or otherwise return the
components and assemble the aggregate in the caller.



Returning an aggregate is exactly the same as manually allocating the 
aggregate and passing a pointer to the function (in order to let it fill 
the aggregate) on most if not all ABIs. Without any difference in 
performance.


Of course the latter has the advantage that you can additionally return

Re: [Geany-devel] Ideas on increasing quality of plugins

2011-03-09 Thread Colomban Wendling

Le 10/03/2011 01:23, Lex Trotman a écrit :
 On 10 March 2011 00:45, Colomban Wendling lists@herbesfolles.org wrote:
 Le 09/03/2011 05:31, Lex Trotman a écrit :
 Hi Colomban,

 Agree with most, comment on the rest below.

 On 9 March 2011 14:00, Colomban Wendling lists@herbesfolles.org wrote:
 Le 08/03/2011 22:29, Colomban Wendling a écrit :
 Le 08/03/2011 19:58, Enrico Tröger a écrit :
 On Tue, 08 Mar 2011 11:06:16 +0100, Frank wrote:

 Am 23.02.2011 01:10, schrieb Matthew Brush:
 For first thing, maybe we could enforce use/passing of those tools
 mentioned and these before adding to release, examples:
 http://www.splint.org/
 http://valgrind.org/info/tools.html
 (suppression for GTK -
 http://people.gnome.org/~johan/gtk.suppression)
 http://www.gnu.org/software/indent/ (just for making coding styles
 more consistent between plugins) http://check.sourceforge.net/ or
 http://cutest.sourceforge.net/ or http://cunit.sourceforge.net/
 Perhaps some or all of these could be automated.

 I don't suggest (yet) to use splint, because I haven't found it useful,
 it reported ways too much things (and some was false positive) to be
 really usable. However, I probably don't know how to configure it (and
 haven't the time to find out yet), so if somebody with experience with
 it can provide some hints, maybe we can add this too.

 For Valgrind however, I doubt we can do anything automatically, because
 it's a runtime checker, and its output must generally be read with some
 care. Writing some sort of guidelines and howto is probably the way to go.


 I like that idea. Can someone of you build up a howto on how to use it?
 I did try valgrind in past and wished for some advice ;)

 One this is done we can think of automatic tests with some of this
 tools.

 I, and obviously, Colomban as well, though indepdent from each other :D,
 recently played[1,2] with cppcheck. A small tool for static code
 analysis which actually found a few things in the geany-plugins
 repository.

 As I'm currently reworking the system to create the nightly builds, we
 could integrate such checks into the nightly builds, maybe run cppcheck
 on the sources after the builds and present the results somewhere on
 nightly.geany.org.
 I think it's a good idea.

 I did a few checks, and this is what I suggest:
 1) run cppcheck on `make check` and abort if it detects an error;
 2) enable by default (though in a portable manner) some compiler flags
 such as -Werror-implicit-function-declaration [1] [2]
 After a little more thinking and testing, I suggest:

 * -Werror=implicit-function-declaration (see above);
 * -Werror=pointer-arith, to avoid portability issues with untyped
 pointer arithmetic;
 * -Wundef because preprocessor tests should rely on defined variables or
 explicitly use ifdef;
 * -Wshadow because shadowing symbols is a Bad Practice (and maybe it is
 even non-standard, not quite sure however);

 Agree for shadow of locals and parameters, agree for globals but only
 because all globals should be prefixed by a module prefix like the
 Geany_ symbols are.  Is there any way to check this?
 Not that I know, unfortunately. However maybe a dumb sed/grep might do
 the trick.

 * -Waggregate-return because returning aggregate values is no good for
 performances and it's not a Good Practice in C;

 Why isn't it good?  Performance should be as good if not better than
 returning multiple parameters via pointers and then assembling the
 aggregate in the caller.  Why isn't it Good Practice?? (your caps :-)
 Its been standard ever since someone invented allocating the return
 variable on the stack prior to the call, so it can be referenced
 relative to the frame pointer.
 Well... I must admit I'm not really pro on the subject, but AFAIK the
 main problem is ABI, because since the return value will not necessarily
 fit in registers the compiler is likely to generate a dummy parameter to
 the function (as you might have done yourself), but this implicitly, so
 changing the natural ABI of the function.
 
 Functions that return too much to fit in the registers should use the
 stdcall ABI which defines an extra reference parameter for the
 aggregate. (Or rather the compiler should use it).  There is no such
 thing as a natural ABI that is corrupted by aggregate returns, there
 are ABIs defined by Intel and other CPU makers for all the required
 call/return patterns.  Yes its slower than returning something in a
 register, but if you have got to return an aggregate value thats too
 big you have to return it.  Might as well let the compiler do the
 heavy lifting rather than having to declare a temporary and pass a
 pointer to it as an explicit parameter or otherwise return the
 components and assemble the aggregate in the caller.
 
 Back in the dim distant past (1970s) when function prototypes were as
 rare as hens teeth such returns were a drama since they required a
 prototype.  I don't see why we should continue this restriction as a
 hangover from the

Re: [Geany-devel] Ideas on increasing quality of plugins

2011-03-09 Thread Lex Trotman

On 10 March 2011 11:57, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
 On 10.03.2011 01:23, Lex Trotman wrote:

 On 10 March 2011 00:45, Colomban Wendlinglists@herbesfolles.org
  wrote:

 Le 09/03/2011 05:31, Lex Trotman a écrit :

 Hi Colomban,

 Agree with most, comment on the rest below.

 On 9 March 2011 14:00, Colomban Wendlinglists@herbesfolles.org
  wrote:

 Le 08/03/2011 22:29, Colomban Wendling a écrit :

 Le 08/03/2011 19:58, Enrico Tröger a écrit :

 On Tue, 08 Mar 2011 11:06:16 +0100, Frank wrote:

 Am 23.02.2011 01:10, schrieb Matthew Brush:

 For first thing, maybe we could enforce use/passing of those tools
 mentioned and these before adding to release, examples:
 http://www.splint.org/
 http://valgrind.org/info/tools.html
 (suppression for GTK -
 http://people.gnome.org/~johan/gtk.suppression)
 http://www.gnu.org/software/indent/ (just for making coding styles
 more consistent between plugins) http://check.sourceforge.net/ or
 http://cutest.sourceforge.net/ or http://cunit.sourceforge.net/
 Perhaps some or all of these could be automated.

 I don't suggest (yet) to use splint, because I haven't found it
 useful,
 it reported ways too much things (and some was false positive) to be
 really usable. However, I probably don't know how to configure it (and
 haven't the time to find out yet), so if somebody with experience with
 it can provide some hints, maybe we can add this too.

 For Valgrind however, I doubt we can do anything automatically,
 because
 it's a runtime checker, and its output must generally be read with
 some
 care. Writing some sort of guidelines and howto is probably the way to
 go.

 I like that idea. Can someone of you build up a howto on how to use
 it?
 I did try valgrind in past and wished for some advice ;)

 One this is done we can think of automatic tests with some of this
 tools.

 I, and obviously, Colomban as well, though indepdent from each other
 :D,
 recently played[1,2] with cppcheck. A small tool for static code
 analysis which actually found a few things in the geany-plugins
 repository.

 As I'm currently reworking the system to create the nightly builds,
 we
 could integrate such checks into the nightly builds, maybe run
 cppcheck
 on the sources after the builds and present the results somewhere on
 nightly.geany.org.

 I think it's a good idea.

 I did a few checks, and this is what I suggest:
 1) run cppcheck on `make check` and abort if it detects an error;
 2) enable by default (though in a portable manner) some compiler flags
 such as -Werror-implicit-function-declaration [1] [2]

 After a little more thinking and testing, I suggest:

 * -Werror=implicit-function-declaration (see above);
 * -Werror=pointer-arith, to avoid portability issues with untyped
 pointer arithmetic;
 * -Wundef because preprocessor tests should rely on defined variables
 or
 explicitly use ifdef;
 * -Wshadow because shadowing symbols is a Bad Practice (and maybe it is
 even non-standard, not quite sure however);

 Agree for shadow of locals and parameters, agree for globals but only
 because all globals should be prefixed by a module prefix like the
 Geany_ symbols are.  Is there any way to check this?

 Not that I know, unfortunately. However maybe a dumb sed/grep might do
 the trick.

 * -Waggregate-return because returning aggregate values is no good for
 performances and it's not a Good Practice in C;

 Why isn't it good?  Performance should be as good if not better than
 returning multiple parameters via pointers and then assembling the
 aggregate in the caller.  Why isn't it Good Practice?? (your caps :-)
 Its been standard ever since someone invented allocating the return
 variable on the stack prior to the call, so it can be referenced
 relative to the frame pointer.

 Well... I must admit I'm not really pro on the subject, but AFAIK the
 main problem is ABI, because since the return value will not necessarily
 fit in registers the compiler is likely to generate a dummy parameter to
 the function (as you might have done yourself), but this implicitly, so
 changing the natural ABI of the function.

 Functions that return too much to fit in the registers should use the
 stdcall ABI which defines an extra reference parameter for the
 aggregate. (Or rather the compiler should use it).  There is no such
 thing as a natural ABI that is corrupted by aggregate returns, there
 are ABIs defined by Intel and other CPU makers for all the required
 call/return patterns.  Yes its slower than returning something in a
 register, but if you have got to return an aggregate value thats too
 big you have to return it.  Might as well let the compiler do the
 heavy lifting rather than having to declare a temporary and pass a
 pointer to it as an explicit parameter or otherwise return the
 components and assemble the aggregate in the caller.


 Returning an aggregate is exactly the same as manually allocating the
 aggregate and passing a pointer to the function (in order

Re: [Geany-devel] Ideas on increasing quality of plugins

2011-03-09 Thread Lex Trotman

 So maybe I was just plain wrong and should update my bias :) I actually
 don't know much about this -- and I should blame myself to speak about
 it then.

Don't ever not talk about something because you might not know much
about it, because then we'd never get to discuss much at all :-)  (Or
at least I wouldn't)

Cheers
Lex


 Cheers,
 Colomban

___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

2011-03-08 Thread Frank Lanitz

On Tue, 8 Mar 2011 19:58:16 +0100
Enrico Tröger enrico.troe...@uvena.de wrote:

 On Tue, 08 Mar 2011 11:06:16 +0100, Frank wrote:
 
 Am 23.02.2011 01:10, schrieb Matthew Brush:
  For first thing, maybe we could enforce use/passing of those tools
  mentioned and these before adding to release, examples:
  http://www.splint.org/
  http://valgrind.org/info/tools.html
  (suppression for GTK -
  http://people.gnome.org/~johan/gtk.suppression)
  http://www.gnu.org/software/indent/ (just for making coding styles
  more consistent between plugins) http://check.sourceforge.net/ or
  http://cutest.sourceforge.net/ or http://cunit.sourceforge.net/
  Perhaps some or all of these could be automated.
 
 I like that idea. Can someone of you build up a howto on how to use
 it? I did try valgrind in past and wished for some advice ;)
 
 One this is done we can think of automatic tests with some of this
 tools.
 
 I, and obviously, Colomban as well, though indepdent from each
 other :D, recently played[1,2] with cppcheck. A small tool for static
 code analysis which actually found a few things in the geany-plugins
 repository.
 
 As I'm currently reworking the system to create the nightly builds, we
 could integrate such checks into the nightly builds, maybe run
 cppcheck on the sources after the builds and present the results
 somewhere on nightly.geany.org.
 
 Just an idea.

If this is working I'd give a huge pro for it ;) 

Cheers, 
Frank 
-- 
http://frank.uvena.de/en/


pgpIX9FuqtB63.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] Ideas on increasing quality of plugins

2011-03-08 Thread Colomban Wendling

Le 08/03/2011 19:58, Enrico Tröger a écrit :
 On Tue, 08 Mar 2011 11:06:16 +0100, Frank wrote:
 
 Am 23.02.2011 01:10, schrieb Matthew Brush:
 For first thing, maybe we could enforce use/passing of those tools
 mentioned and these before adding to release, examples:
 http://www.splint.org/
 http://valgrind.org/info/tools.html
 (suppression for GTK -
 http://people.gnome.org/~johan/gtk.suppression)
 http://www.gnu.org/software/indent/ (just for making coding styles
 more consistent between plugins) http://check.sourceforge.net/ or
 http://cutest.sourceforge.net/ or http://cunit.sourceforge.net/
 Perhaps some or all of these could be automated.

I don't suggest (yet) to use splint, because I haven't found it useful,
it reported ways too much things (and some was false positive) to be
really usable. However, I probably don't know how to configure it (and
haven't the time to find out yet), so if somebody with experience with
it can provide some hints, maybe we can add this too.

For Valgrind however, I doubt we can do anything automatically, because
it's a runtime checker, and its output must generally be read with some
care. Writing some sort of guidelines and howto is probably the way to go.


 I like that idea. Can someone of you build up a howto on how to use it?
 I did try valgrind in past and wished for some advice ;)

 One this is done we can think of automatic tests with some of this
 tools.
 
 I, and obviously, Colomban as well, though indepdent from each other :D,
 recently played[1,2] with cppcheck. A small tool for static code
 analysis which actually found a few things in the geany-plugins
 repository.
 
 As I'm currently reworking the system to create the nightly builds, we
 could integrate such checks into the nightly builds, maybe run cppcheck
 on the sources after the builds and present the results somewhere on
 nightly.geany.org.
I think it's a good idea.

I did a few checks, and this is what I suggest:
1) run cppcheck on `make check` and abort if it detects an error;
2) enable by default (though in a portable manner) some compiler flags
such as -Werror-implicit-function-declaration [1] [2]

Maybe some other tests might be good, but I think this is a start.

I'm working on implementing this for Autotools, maybe I can take a look
at Waf too (but Enrico would love to do this :D).

Thoughts?

Cheers,
Colomban


[1] and maybe some other flags, but implicit function declaration is a
very crash-prone bug, and I can't think of (and never saw) a case where
this would break legitimate code.

[2] for example, debugger plugin currently have some implicit function
declarations -- Alexander, could you fix this?
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

2011-02-23 Thread Thomas Martitz


Am 23.02.2011 04:01, schrieb Lex Trotman:

Of course on the other hand because the maintainers are volunteers
with limited time this process slows changes, but IMHO this is
necessary.  Having more maintainers for a piece of code is of course
the solution, but as we are finding, its hard to actually do for a
small project.  Even for core there was a deafening silence when I
recently suggested that more people volunteer to be maintainers.



I don't think that silence meant anything other than the people that can 
decide haven't read it yet. But yea, I would welcome a discussion about 
this in the core. There's great potential contributors on this list, but 
they're all sitting on their patches and nothing moves forward.




Of course the Geany community also has a responsibility to Geany users
(not least ourselves :-) to make sure that the whole Geany ecosystem
offered as an official release meets reliability and usability
standards.  On this basis, Frank's concern that some plugins don't
meet those standards is important, but I don't think that it is
reasonable for the community to impose work on maintainers without
discussion (thats this thread) and a reasonable period for improving
things, otherwise the community is undermining the maintainers
responsibility, and I certainly would get upset if I were a
maintainer.


You seem to have misunderstood that letting other people help fix bugs 
is voluntary is has nothing to do with undermining. And I didn't suggest 
to share maintainership completely, but just accept help to fix the most 
immediate bugs (such as crashes) in a timely manner. Nobody wants to 
take plugins away from developers.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

2011-02-23 Thread Alexander Petukhov

If nobody mind, let me state my opinions:

1. Maintaining
I believe there has to be only one maintainer who is commiting code.
As for me, the amount of code in a ordinary geany plugin is not that huge,
one can easily support it. Others who has patches/improvements have to send them
to the maintainer and it's he, who decides what to do with them and is somehow 
responcible for the result.
Giving commiting rights to several people can cause mess in code.
If the plugin is unmaintained for a long time, lets contact a developer to 
learn his plans
and if he hasn't time for now (or at all) and there is someone else who wants 
to do his job - let this man to become a new maintainer,
I think little developers will reject this suggestion if they really have no 
time to deal with the code for now.
Current active maintainer have to mentioned on the plugins web-site in order to 
contact him to solve problems / send patches etc 

2. Documentation
Support Mathew, there has to be common documentation system,
maybe we can start from standartization README etc standart files

3. Different repos
Here I strongly disagree, I think this will also cause kind of a mess,
why not to solve problems in te common repository?

4. Removing unsupported plugins from releases
what do you think about the following scheme: divide all pluging into:
- supported (that are acting really well) 
- unsupported or bad (having problems) ?
So, every geany-plugins release will contain several packages: geany-plugins, 
geany-plugins-bad or geany-plugins-unsupported, something like this

5. Other language bindings - don't really think it can increase plugins quality 
dramatically,
there can be problems in any language that you have to solve in order to make 
your code work correctly.

And one more thing, as a debian user I see that there is still 0.19 plugins 
version even in unstable,
maybe it's a good idea to   move current developing version (0.21?) to unstable 
/ testing
to  make debian users to help us in bug reporting?

Cheers,
Alex 


 
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

2011-02-23 Thread Matthew Brush

On 02/23/11 04:28, Alexander Petukhov wrote:

If nobody mind, let me state my opinions:

1. Maintaining
I believe there has to be only one maintainer who is commiting code.
As for me, the amount of code in a ordinary geany plugin is not that huge,
one can easily support it. Others who has patches/improvements have to send them
to the maintainer and it's he, who decides what to do with them and is somehow
responcible for the result.
Giving commiting rights to several people can cause mess in code.
Isn't this how the current setup is? I thought it was just a courtesy
to not mess with the other plugins?

If the plugin is unmaintained for a long time, lets contact a developer to
learn his plans
and if he hasn't time for now (or at all) and there is someone else who wants
to do his job - let this man to become a new maintainer,
I think little developers will reject this suggestion if they really have no
time to deal with the code for now.
Current active maintainer have to mentioned on the plugins web-site in order to
contact him to solve problems / send patches etc

2. Documentation
Support Mathew, there has to be common documentation system,
maybe we can start from standartization README etc standart files
Maybe even to have a plugin template (GStreamer has this[1]), where
you clone from a repo/extract from a tarball all the standard files and
then add your source code and customize the templates (README, autotools
stuff, etc).

3. Different repos
Here I strongly disagree, I think this will also cause kind of a mess,
why not to solve problems in te common repository?
I guess I don't know enough about to Subversion to understand its
workflow. But this sounds better to me:

The Fork + Pull Model lets anyone fork an existing repository and push
changes to their personal fork without requiring access be granted to
the source repository. The changes must then be pulled into the source
repository by the project maintainer. This model reduces the amount of
friction for new contributors and is popular with open source projects
because it allows people to work independently without upfront
coordination. [2]

But like someone said, this is a whole different thread, and I really
don't know enough about VCS to have a strong opinion.

4. Removing unsupported plugins from releases
what do you think about the following scheme: divide all pluging into:
- supported (that are acting really well)
- unsupported or bad (having problems) ?
So, every geany-plugins release will contain several packages: geany-plugins,
geany-plugins-bad or geany-plugins-unsupported, something like this
This is like GStreamer plugins and I think it's a very good idea. They
could be grouped in the configure.ac file to add an option like
--enable-bad and --enable--unsupported or something.

5. Other language bindings - don't really think it can increase plugins quality
dramatically,
there can be problems in any language that you have to solve in order to make
your code work correctly.

I have to disagree with this for a few reasons:
- Many more people would write plugins if they could do it in their
native language (Just look at how many plugins Gedit has).
- I'd rather use a plugin written in Perl by a Perl guru, running on
it's interpreter, than Perl code written in C (ie. lets people use their
existing skills instead of translating them into bad C code).

- No memory leaks (ie automatic ref-counting, garbage collection)
- Isolation from Geany since most languages would be running under
their own VM/interpreter. Same reason you don't often (or ever?) see
Segmentation Fault when running a PHP or Python program for example.
- Rapid development. There's been many plugin ideas I've had myself
that I would've written if I could've done it in a couple evenings
instead of a month of evenings.

- People can still use the C API.

The only downside I can think of is the extra memory overhead of the
embedded interpreter.

My 0.02$

[1]
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/chapter-building-boiler.html

[2] http://help.github.com/pull-requests/

Cheers,
Matthew Brush (codebrainz)
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

Hi,

Le 22/02/2011 17:28, Frank Lanitz a écrit :
 Hi folks,
 
 And again it happen to me that Geany did crash due some issue with a
 plugin which might not have been tested very well before checking in
 /committing.
 However, I don't want to point with my finger to any developer so I'm
 asking how we could improve overall quality of plugins inside release as
 well as on trunk.
 
 Failures I was recognizing in past did start with simple case/data type
 warnings on compile time up to segfaults caused by not correct
 initialized pointers as well a number of memory leaks. I know its not
 possible to write 100% clean code as well as I'm aware of my code isn't
 very well too. But I really like to change something here.
 
 So my 1st suggestion is to remove all plugins which do have known issues
 and don't compile with some -W-flags (needs to be defined) from common
 build until these are fixed. Also remove plugins which don't bring
 propper documentation as well are unmaintained for some time.
Well... I'm puzzled. Disabling unperfect plugins is a good idea in
theory for the stability of Geany, but... how would be plugins tested then?

However, I agree with making official builds with strong error checking
enabled (at least -Werror-implicit-function-declaration comes directly
to my mind). This is static checking that will show most obvious
problems, and hopefully it'll encourage their maintainer to fix them.
However, finding the right flags will not be easy... for example not
allowing any implicit cast may have a false-positive effect where
unexperimented developers might hide a part of those with a cast where a
proper fix would be better.
And even I (yes, I think I'm pretty experimented and knowledgeable about
C) sometimes don't correct a hard-to-fix integer cast warning because I
know this particular implicit cast isn't really important but I also
know it should better be fixed than simply hiding it with an explicit
cast. So I leave the warning, kinda as a rememberer.

 
 As a first shoot this could be from my point of view
 
 - Updatechecker (crash on Windows build)
It then might be disabled only for Windows if it's safe on Unices?

 - GeanyLUA (lot of warnings on compiling time)
 - Pretty Printer (lot of warnings on compiling time)
Why not. Hopefully their author will fix them :)

 - GeanyGDB (nearly unmaintained)
For this one, it also has a candidate for replacement, hasn't it?

 - GeanyVC (de facto unmaintained)
...but AFAICT it's stable. Unmaintained software isn't good, but I doubt
dropping such a feature would please all users.

 - WebHelper (Crash mentioned on SF)
This is a good (I think :D) example of what I talked about above: user
testing. I use this plugin, and at least load it often (heh, I wrote
it...) and never found a crash I didn't fixed. So without testing, I
would probably never have been informed of such a crash, so I'd never
had a chance to fix it.

 Unfortunately this is not a complete list. So maybe we could just remove
 every plugin and just start to create a white list.
Again, a false-positive of a white-list is that blacked plugins won't
get real testing.

 Ideally (from my point of view) we could set up some kind of review
 process but I'm afraid it will not possible due lag of resources -
 somebody needs to read and understand the code.
Well... I might do basic review on demand. Not necessarily understanding
all the code, but reading it as a C developer and reporting what I find
wrong. Such a basic review probably needs about 1 or 2 hours, but I
personally feel this kind of code review more as rest time than hard
work ;)

 Also we might could work
 with tests for typical things - somebody only have to code them. I just
 don't see any big alternatives at the moment.
Like what? I doubt a specific tool would have most benefit over more
generic (and already written :p) tools -- I think of a static code
checker, maybe cppcheck or clang --check; and the Runtime Error Checking
King, I named Valgrind.

Finally, I don't point my finger to anybody neither, but I know some of
the developers aren't experienced C developers. They then probably
cannot really review their own code for C problems. And anyway, an
external review is IMHO always a good thing, even for the most
experienced of us: at least it's an opportunity to justify (to
ourselves) how the code is written.

 
 What do you think about?
To summarize: a white list is a kinda bad idea IMHO since it'll avoid
user testing. However, I think it's a good idea to enforce code quality
checking.


Regards,
Colomban
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins


Am 22.02.2011 19:36, schrieb Colomban Wendling:


So my 1st suggestion is to remove all plugins which do have known issues
and don't compile with some -W-flags (needs to be defined) from common
build until these are fixed. Also remove plugins which don't bring
propper documentation as well are unmaintained for some time.

Well... I'm puzzled. Disabling unperfect plugins is a good idea in
theory for the stability of Geany, but... how would be plugins tested then?

However, I agree with making official builds with strong error checking
enabled (at least -Werror-implicit-function-declaration comes directly
to my mind). This is static checking that will show most obvious
problems, and hopefully it'll encourage their maintainer to fix them.
However, finding the right flags will not be easy... for example not
allowing any implicit cast may have a false-positive effect where
unexperimented developers might hide a part of those with a cast where a
proper fix would be better.


I agree. While we may know they have known problems, how would we know 
in the future if they're disabled and receive no testing?


I think all plugin developers should get more easy about others touching 
there code. I could probably fix a number of problems in other people's 
plugins, but I'm afraid of the surrounded discussion (post or pre commit).


What I also wonder; is there a way to prevent plugins from crashing 
geany entirely? I'd rather have a notice Oops, Plugin Foo crashed.


Best regards.

___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins


Hit enter too early :)

Am 22.02.2011 19:36, schrieb Colomban Wendling:


Finally, I don't point my finger to anybody neither, but I know some of
the developers aren't experienced C developers. They then probably
cannot really review their own code for C problems.



I also observed this, and I think that's a major part of the problem. 
Hopefully we can code plugins in friendlier languages, such as Vala or 
python soon (work on both is ongoing).


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

Le 22/02/2011 20:04, Thomas Martitz a écrit :
 Am 22.02.2011 19:36, schrieb Colomban Wendling:
 
 So my 1st suggestion is to remove all plugins which do have known issues
 and don't compile with some -W-flags (needs to be defined) from common
 build until these are fixed. Also remove plugins which don't bring
 propper documentation as well are unmaintained for some time.
 Well... I'm puzzled. Disabling unperfect plugins is a good idea in
 theory for the stability of Geany, but... how would be plugins tested
 then?

 However, I agree with making official builds with strong error checking
 enabled (at least -Werror-implicit-function-declaration comes directly
 to my mind). This is static checking that will show most obvious
 problems, and hopefully it'll encourage their maintainer to fix them.
 However, finding the right flags will not be easy... for example not
 allowing any implicit cast may have a false-positive effect where
 unexperimented developers might hide a part of those with a cast where a
 proper fix would be better.
 
 I agree. While we may know they have known problems, how would we know
 in the future if they're disabled and receive no testing?
 
 I think all plugin developers should get more easy about others touching
 there code. I could probably fix a number of problems in other people's
 plugins, but I'm afraid of the surrounded discussion (post or pre commit).
I don't think that touching other one's code without her agreement is a
good idea. There are several reasons for this that comes to mind:
* some people will find this offensive (e.g. you can't even code right
and you won't even understand if I tell you);
* some people will find it cool, but won't necessarily try to understand
any further (heh, it's already fixed), so would likely reproduce
mistakes later;
* and unfortunately, some people might change things with not enough
care or understanding and break other things -- this is easier than we
might think...
* and some people would not feel confident of somebody else commit --
and this would probably be my case if it's somebody I hardly know.

And AFAICT, people who would need help are generally likely to accept it
when proposed (probably more than if it was imposed).

 What I also wonder; is there a way to prevent plugins from crashing
 geany entirely? I'd rather have a notice Oops, Plugin Foo crashed.
I doubt. This would need to run plugins in a separate process, and then
doing some IPC to communicate. Probably doable (well, AFAIK recent web
browsers tend to do so with their plugins -- chromium, FF4) but probably
really not easy.


Regards,
Colomban
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins


Am 22.02.2011 21:40, schrieb Colomban Wendling:

Le 22/02/2011 20:04, Thomas Martitz a écrit :

Am 22.02.2011 19:36, schrieb Colomban Wendling:


So my 1st suggestion is to remove all plugins which do have known issues
and don't compile with some -W-flags (needs to be defined) from common
build until these are fixed. Also remove plugins which don't bring
propper documentation as well are unmaintained for some time.

Well... I'm puzzled. Disabling unperfect plugins is a good idea in
theory for the stability of Geany, but... how would be plugins tested
then?

However, I agree with making official builds with strong error checking
enabled (at least -Werror-implicit-function-declaration comes directly
to my mind). This is static checking that will show most obvious
problems, and hopefully it'll encourage their maintainer to fix them.
However, finding the right flags will not be easy... for example not
allowing any implicit cast may have a false-positive effect where
unexperimented developers might hide a part of those with a cast where a
proper fix would be better.

I agree. While we may know they have known problems, how would we know
in the future if they're disabled and receive no testing?

I think all plugin developers should get more easy about others touching
there code. I could probably fix a number of problems in other people's
plugins, but I'm afraid of the surrounded discussion (post or pre commit).

I don't think that touching other one's code without her agreement is a
good idea. There are several reasons for this that comes to mind:
* some people will find this offensive (e.g. you can't even code right
and you won't even understand if I tell you);
* some people will find it cool, but won't necessarily try to understand
any further (heh, it's already fixed), so would likely reproduce
mistakes later;
* and unfortunately, some people might change things with not enough
care or understanding and break other things -- this is easier than we
might think...
* and some people would not feel confident of somebody else commit --
and this would probably be my case if it's somebody I hardly know.

And AFAICT, people who would need help are generally likely to accept it
when proposed (probably more than if it was imposed).



It's all open source after all, and part of it is working together with 
others on the same code. All of your points contradict with that spirit.


I didn't mean to say I would like to do work on someone else's plugin 
(as in new features). Just fix the most immediate problems. If the fix 
not a few-liner or no brainer I wouldn't bother with it any further 
anyway (but instead just disable the plugin for the time being).


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

2011-02-22 Thread Frank Lanitz

Hi, 

On Tue, 22 Feb 2011 19:36:51 +0100
Colomban Wendling lists@herbesfolles.org wrote:

 Hi,
 
 Le 22/02/2011 17:28, Frank Lanitz a écrit :
  Hi folks,
  
  And again it happen to me that Geany did crash due some issue with a
  plugin which might not have been tested very well before checking in
  /committing.
  However, I don't want to point with my finger to any developer so
  I'm asking how we could improve overall quality of plugins inside
  release as well as on trunk.
  
  Failures I was recognizing in past did start with simple case/data
  type warnings on compile time up to segfaults caused by not correct
  initialized pointers as well a number of memory leaks. I know its
  not possible to write 100% clean code as well as I'm aware of my
  code isn't very well too. But I really like to change something
  here.
  
  So my 1st suggestion is to remove all plugins which do have known
  issues and don't compile with some -W-flags (needs to be defined)
  from common build until these are fixed. Also remove plugins which
  don't bring propper documentation as well are unmaintained for some
  time.
 Well... I'm puzzled. Disabling unperfect plugins is a good idea in
 theory for the stability of Geany, but... how would be plugins tested
 then?

This is something I like to get clarified with my question ;)

 However, I agree with making official builds with strong error
 checking enabled (at least -Werror-implicit-function-declaration
 comes directly to my mind). This is static checking that will show
 most obvious problems, and hopefully it'll encourage their maintainer
 to fix them. However, finding the right flags will not be easy... for
 example not allowing any implicit cast may have a false-positive
 effect where unexperimented developers might hide a part of those
 with a cast where a proper fix would be better.

I agree. 

 And even I (yes, I think I'm pretty experimented and knowledgeable
 about C) sometimes don't correct a hard-to-fix integer cast warning
 because I know this particular implicit cast isn't really important
 but I also know it should better be fixed than simply hiding it with
 an explicit cast. So I leave the warning, kinda as a rememberer.

So... you know your task ;)

  As a first shoot this could be from my point of view
  
  - Updatechecker (crash on Windows build)
 It then might be disabled only for Windows if it's safe on Unices?

Yes. Valid point. 
 
  - GeanyLUA (lot of warnings on compiling time)
  - Pretty Printer (lot of warnings on compiling time)
 Why not. Hopefully their author will fix them :)

Nick did take it over as the original developer didn't maintain it
anymore. There have been only the most important things done IIRC due
of this point.

  - GeanyGDB (nearly unmaintained)
 For this one, it also has a candidate for replacement, hasn't it?

Yepp. But this would also include a 100% review uf the new plugin and
check whether it really does its job. At least for me I cannot decide. 

  - GeanyVC (de facto unmaintained)
 ...but AFAICT it's stable. Unmaintained software isn't good, but I
 doubt dropping such a feature would please all users.

There are some issue with the plugin. Of course a huge number of poeple
would miss it. 

  - WebHelper (Crash mentioned on SF)
 This is a good (I think :D) example of what I talked about above: user
 testing. I use this plugin, and at least load it often (heh, I wrote
 it...) and never found a crash I didn't fixed. So without testing, I
 would probably never have been informed of such a crash, so I'd never
 had a chance to fix it.

Yes, thats true. Without good testing you cannot find all bugs. 

  Unfortunately this is not a complete list. So maybe we could just
  remove every plugin and just start to create a white list.
 Again, a false-positive of a white-list is that blacked plugins
 won't get real testing.

This is not necessary true. It would be inside mainstream and would be
missing this testing, thats correct. But maybe there is some other
process in place? 

  Ideally (from my point of view) we could set up some kind of review
  process but I'm afraid it will not possible due lag of resources -
  somebody needs to read and understand the code.
 Well... I might do basic review on demand. Not necessarily
 understanding all the code, but reading it as a C developer and
 reporting what I find wrong. Such a basic review probably needs about
 1 or 2 hours, but I personally feel this kind of code review more as
 rest time than hard work ;)

I always like writing code more than try to understand others. Just a
thought ... Maybe you can do some review on some of the other plugins
if you have some need for a rest? ;) Would be really cool I guess. 

  Also we might could work
  with tests for typical things - somebody only have to code them. I
  just don't see any big alternatives at the moment.
 Like what? I doubt a specific tool would have most benefit over more
 generic (and already written :p) tools -- I think of a static

Re: [Geany-devel] Ideas on increasing quality of plugins

2011-02-22 Thread Frank Lanitz

On Tue, 22 Feb 2011 20:07:44 +0100
Thomas Martitz thomas.mart...@student.htw-berlin.de wrote:

 Hit enter too early :)
 
 Am 22.02.2011 19:36, schrieb Colomban Wendling:
 
  Finally, I don't point my finger to anybody neither, but I know
  some of the developers aren't experienced C developers. They then
  probably cannot really review their own code for C problems.
 
 
 I also observed this, and I think that's a major part of the problem. 
 Hopefully we can code plugins in friendlier languages, such as Vala
 or python soon (work on both is ongoing).

Even in Vala or Python you can write bad code... I'm very experienced in
doing it on Python...

Cheers, 
Frank 
-- 
http://frank.uvena.de/en/


pgpLQSgRc2vPV.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] Ideas on increasing quality of plugins

2011-02-22 Thread Frank Lanitz

On Tue, 22 Feb 2011 20:04:17 +0100
Thomas Martitz thomas.mart...@student.htw-berlin.de wrote:

 Am 22.02.2011 19:36, schrieb Colomban Wendling:
 
  So my 1st suggestion is to remove all plugins which do have known
  issues and don't compile with some -W-flags (needs to be defined)
  from common build until these are fixed. Also remove plugins which
  don't bring propper documentation as well are unmaintained for
  some time.
  Well... I'm puzzled. Disabling unperfect plugins is a good idea in
  theory for the stability of Geany, but... how would be plugins
  tested then?
 
  However, I agree with making official builds with strong error
  checking enabled (at least -Werror-implicit-function-declaration
  comes directly to my mind). This is static checking that will show
  most obvious problems, and hopefully it'll encourage their
  maintainer to fix them. However, finding the right flags will not
  be easy... for example not allowing any implicit cast may have a
  false-positive effect where unexperimented developers might hide a
  part of those with a cast where a proper fix would be better.
 
 I agree. While we may know they have known problems, how would we
 know in the future if they're disabled and receive no testing?

Yes, this is a problem we would need to solve. But it seems to me it
might not be a good idea to play some fundamentalistic disabling of
plugins. 

 I think all plugin developers should get more easy about others
 touching there code. 

Puh. This is a hard point as it might end up in some bad discussion
about direction of development. But well... I think there will be a
solution if some issue like this is popping up. 

 I could probably fix a number of problems in
 other people's plugins, but I'm afraid of the surrounded discussion
 (post or pre commit).

We. I guess there was only one case I dissmissed a patch (and I'm
sorry for this) in past. At least I'm always happy if somebody is
finding and fixing some issues. 

 What I also wonder; is there a way to prevent plugins from crashing 
 geany entirely? I'd rather have a notice Oops, Plugin Foo crashed.

freeing a document pointer will always crash Geany unless you put
plugins into some kind of virtual machine ... and I don't think its
what we want to do. 

Cheers, 
Frank 
-- 
http://frank.uvena.de/en/


pgpufNCAfKB0T.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] Ideas on increasing quality of plugins


Am 22.02.2011 23:00, schrieb Frank Lanitz:

I also observed this, and I think that's a major part of the problem.
Hopefully we can code plugins in friendlier languages, such as Vala
or python soon (work on both is ongoing).

Even in Vala or Python you can write bad code... I'm very experienced in
doing it on Python...

Cheers,
Frank


It's sure possible. But it's not as easy. Can you free(do not free 
string literals) in python? :)


I don't think we need to argue whether or not C is a hard language for 
beginners.


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

Le 22/02/2011 22:59, Frank Lanitz a écrit :
 Le 22/02/2011 17:28, Frank Lanitz a écrit :
 Hi folks,

 And again it happen to me that Geany did crash due some issue with a
 plugin which might not have been tested very well before checking in
 /committing.
 However, I don't want to point with my finger to any developer so
 I'm asking how we could improve overall quality of plugins inside
 release as well as on trunk.

 Failures I was recognizing in past did start with simple case/data
 type warnings on compile time up to segfaults caused by not correct
 initialized pointers as well a number of memory leaks. I know its
 not possible to write 100% clean code as well as I'm aware of my
 code isn't very well too. But I really like to change something
 here.

 So my 1st suggestion is to remove all plugins which do have known
 issues and don't compile with some -W-flags (needs to be defined)
 from common build until these are fixed. Also remove plugins which
 don't bring propper documentation as well are unmaintained for some
 time.
 Well... I'm puzzled. Disabling unperfect plugins is a good idea in
 theory for the stability of Geany, but... how would be plugins tested
 then?
 
 This is something I like to get clarified with my question ;)
A tester team? I doubt we have enough testers for that, but... ^^

 Unfortunately this is not a complete list. So maybe we could just
 remove every plugin and just start to create a white list.
 Again, a false-positive of a white-list is that blacked plugins
 won't get real testing.
 
 This is not necessary true. It would be inside mainstream and would be
 missing this testing, thats correct. But maybe there is some other
 process in place? 
Maybe... which ones? :-'

 Ideally (from my point of view) we could set up some kind of review
 process but I'm afraid it will not possible due lag of resources -
 somebody needs to read and understand the code.
 Well... I might do basic review on demand. Not necessarily
 understanding all the code, but reading it as a C developer and
 reporting what I find wrong. Such a basic review probably needs about
 1 or 2 hours, but I personally feel this kind of code review more as
 rest time than hard work ;)
 
 I always like writing code more than try to understand others. Just a
 thought ... Maybe you can do some review on some of the other plugins
 if you have some need for a rest? ;) Would be really cool I guess.
I'd better do this after the plugin's author told she was interested.
Not to loose my spare time perhaps, and not to end up with bad feeling
of somebody feeling offended. As you said: communication!

So, let's directly ask:
Dear plugins authors, are you interested by me reviewing your code and
discussing with you what may be improved/should be fixed/whatever? I'd
be happy to do so if you're interested :)
And if you prefer, I might simply send you a patch with mys suggested
changes/fixes.

 Also we might could work
 with tests for typical things - somebody only have to code them. I
 just don't see any big alternatives at the moment.
 Like what? I doubt a specific tool would have most benefit over more
 generic (and already written :p) tools -- I think of a static code
 checker, maybe cppcheck or clang --check; and the Runtime Error
 Checking King, I named Valgrind.
 
 I did have a look onto Valgrind... well I started to have a look
 but I wasn't able to figure out how its working in a useful way. Some
 more playing around is needed there I guess. 
Yep, Valgrind is not necessarily an easy-to-use tool, but it's powerful.
In practice, I mostly think about memcheck (a Valgrind's tool -- let's
say it's mode of Valgrind), which helps finding and fixing:
*) invalid memory usage (read or writes outside of bounds)
*) memory leaks

The problem with Valgrind is that it's too precise sometimes: it will
report each and every problem it finds in the program, not only your
code. So, bugs or leaks in other libraries you're not responsible of
will also be shown. To avoid being spammed with such reports, Valgrind
supports suppression files that tells him what's not worth reporting.
But someone need to write such a file...

 What do you think about?
 To summarize: a white list is a kinda bad idea IMHO since it'll avoid
 user testing. However, I think it's a good idea to enforce code
 quality checking.
 
 I agree on lot of user testing might will be missing but due some of
 the bugs experienced with geany-plugins 0.20 I assume its not too much
 missing :( Beside of this I totally second your opinion. 
Sad to hear that user faced so much problems. But then, you're probably
right that we should do something about it -- and that we have to find
out what :D

Cheers,
Colomban
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins

Le 22/02/2011 23:39, Thomas Martitz a écrit :
 I didn't mean to say I would like to do work on someone else's plugin
 (as in new features). Just fix the most immediate problems. If the fix
 not a few-liner or no brainer I wouldn't bother with it any further
 anyway (but instead just disable the plugin for the time being).
 I understand your purpose, but I doubt that such a policy would please
 anyone.
 Yes, I agree that IF the people that commit those fixes you talk about
 are only the ones that are competent to do so, it'd be acceptable IMHO.
 But with such policy it's likely that at some point somebody will feel
 too confident and fix somebody else's code wrongly. And there will be
 the drama, the hard feelings and the collapsing of the whole project --
 I know, it's a pessimistic POV :D

 
 Yes, very pessimistic. I'm a bit more optimistic and have trust that
 people can at least consider their competence before touching and
 committing to foreign code.
One might say it's only an optimistic POV ;)

 And even then, code changes can always be undone.
That's true. Thanks to VCS :)

 Perhaps I'm just biased by how slow things are currently going in the
 Geany core, where more collaboration (by more people) would help a lot
 (I even think it reached a dangerous level of standstill).
I can't disagree with this... but if maintainers have less time to work,
I can't really blame them. As I said in a previous mail, IMHO the
maintainers are quite responsible of how the project works; so I easily
understand that they don't want to give commit access to somebody they
don't trust.
Though, perhaps they might think a little about it and see if there is
some people that would be acceptable (I think of Lex in the first place,
though I can't tell he's interested).
But this is another discussion.

 But I always think the more people the merrier.
That's generally true, assuming these people are smart enough to know
their own capabilities.

 Currently every plugin author does
 his own thing with their plugins and communicate very little about it.
 
 I'd like it better if each plugin had a main maintainer and everyone
 else would be a co-maintainer. Now we have one and only one person
 working on each.
Don't get me wrong: I'm not against it. Why not. Actually, as far as
everything goes right, I'm happy with your proposal. But I also fear
what can happen if we don't explicitly ask the author.

A idea might simply be to ask every plugin author (and keep a list of
their answer not to have to ask again and again) if they are OK with
other people maintaining/developing/fixing/whatevering it. Perhaps even
stricter, who they allow to work on their plugin.
I guess this would be a good compromise, and would avoid hard feelings
since its the author that chooses.

Regards,
Colomban
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Ideas on increasing quality of plugins