Le 12/03/2011 23:34, Colomban Wendling a écrit :
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
On Sun, 13 Mar 2011 21:32:48 +1100, Lex wrote:
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.
Do you want to integrate
On 11.03.2011 19:37, Colomban Wendling wrote:
Do you have objections, comment or whatever?
I largely agree with all of what Lex said.
* I routinely add temporary debug code without the proper headers
(because I know it works) so making this break the build would be
inconvinient for me
On Sun, 13 Mar 2011 14:52:24 +0100, Thomas wrote:
On 13.03.2011 14:50, Enrico Tröger wrote:
On Sun, 13 Mar 2011 14:39:29 +0100, Thomas wrote:
On 13.03.2011 14:35, Enrico Tröger wrote:
Something like ./configure --enable-extra-c-warnings (or shorter
if you prefer ^^)
...so this sounds good
Le 13/03/2011 15:08, Enrico Tröger a écrit :
On Sun, 13 Mar 2011 14:52:24 +0100, Thomas wrote:
On 13.03.2011 14:50, Enrico Tröger wrote:
On Sun, 13 Mar 2011 14:39:29 +0100, Thomas wrote:
On 13.03.2011 14:35, Enrico Tröger wrote:
Something like ./configure --enable-extra-c-warnings (or shorter
Hi,
On Sun, 13 Mar 2011 09:57:36 +0100
Enrico Tröger enrico.troe...@uvena.de wrote:
Do you want to integrate these flags into the build system? I don't
think this is a good idea. Such flags should be set outside of the
build system by the developer/user, not automatically.
This is why they
On Sun, 13 Mar 2011 15:18:09 +0100, Colomban wrote:
Le 13/03/2011 15:08, Enrico Tröger a écrit :
On Sun, 13 Mar 2011 14:52:24 +0100, Thomas wrote:
On 13.03.2011 14:50, Enrico Tröger wrote:
On Sun, 13 Mar 2011 14:39:29 +0100, Thomas wrote:
On 13.03.2011 14:35, Enrico Tröger wrote:
Something
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 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
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
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
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
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:
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
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:
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
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
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
--
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
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
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
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
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
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.
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
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
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,
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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 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
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
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
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,
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/
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
Am 23.02.2011 00:04, schrieb Colomban Wendling:
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.
Sure, not without asking first.
Best regards.
Hi all,
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)
Hi All,
To add my 2c to a number of posts above, taking advantage of my
timezone to be able to summarise :-):
When you provide code to open source, in a sense, you no longer own
the code, the purpose of open sourcing is to allow others to use and
abuse it.
However as Colomban says, maintainers
65 matches
Mail list logo
