Re: [Geany-devel] Ideas on increasing quality of plugins
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
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
[Geany-devel] A few fixes for codenav, geanygdb, geanyinsertnum and geanylatex
Hi plugin maintainers,
In context of the ideas on increasing quality of plugins thread, I
tested a few code checker on geany-plugins trunk, and cppcheck found a
few little problems:
[./codenav/src/switch_head_impl.c:144]: (error) Memory leak: lang
[./geanygdb/src/gdb-io-frame.c:186]: (error) Possible null pointer
dereference: lv
[./geanyinsertnum/src/insertnum.c:156]: (error) Memory leak: line_pos
[./geanylatex/src/templates.c:47]: (error) Memory leak: template
I also attach here the fixes I propose for them, if you're interested.
Regards,
Colomban
diff --git a/geany-plugins/codenav/src/switch_head_impl.c b/geany-plugins/codenav/src/switch_head_impl.c
index fc062ec..a407043 100644
--- a/geany-plugins/codenav/src/switch_head_impl.c
+++ b/geany-plugins/codenav/src/switch_head_impl.c
@@ -131,7 +131,7 @@ switch_head_impl_cleanup()
static void
fill_default_languages_list()
{
- Language* lang = g_malloc0(sizeof(Language));
+ Language* lang = NULL;
languages = NULL;
diff --git a/geany-plugins/geanygdb/src/gdb-io-frame.c b/geany-plugins/geanygdb/src/gdb-io-frame.c
index aa4bd90..6ac7a70 100644
--- a/geany-plugins/geanygdb/src/gdb-io-frame.c
+++ b/geany-plugins/geanygdb/src/gdb-io-frame.c
@@ -182,8 +182,8 @@ var_created(gint seq, gchar ** list, gchar * resp)
lv-type = g_strdup(type ? type : int);
lv-value = fmt_val(value);
lv-numchild = g_strdup(numchild ? numchild : 0);
+ delete_var(lv-name);
}
- delete_var(lv-name);
}
if (h)
g_hash_table_destroy(h);
diff --git a/geany-plugins/geanyinsertnum/src/insertnum.c b/geany-plugins/geanyinsertnum/src/insertnum.c
index ae66ccd..67a833e 100644
--- a/geany-plugins/geanyinsertnum/src/insertnum.c
+++ b/geany-plugins/geanyinsertnum/src/insertnum.c
@@ -153,6 +153,7 @@ static void insert_numbers(gboolean *cancel)
if (*cancel)
{
ui_progress_bar_stop();
+g_free (line_pos);
return;
}
}
diff --git a/geany-plugins/geanylatex/src/templates.c b/geany-plugins/geanylatex/src/templates.c
index ea3d1f6..fcc44ba 100644
--- a/geany-plugins/geanylatex/src/templates.c
+++ b/geany-plugins/geanylatex/src/templates.c
@@ -39,13 +39,14 @@ GString *glatex_get_template_from_file(gchar *filepath)
static void glatex_init_cutom_template_item(gchar *file, GPtrArray *array)
{
- TemplateEntry *template = g_new0(TemplateEntry, 1);
+ TemplateEntry *template = NULL;
gchar *tmp = NULL;
/* Return if its not a searched file */
if (g_str_has_suffix(file,.gtl) == FALSE)
return;
+ template = g_new0(TemplateEntry, 1);
template-filepath = g_strdup(file);
tmp = g_path_get_basename(file);
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] A few fixes for codenav, geanygdb, geanyinsertnum and geanylatex
Am Mittwoch, den 23.02.2011, 19:32 +0100 schrieb Colomban Wendling: [./geanygdb/src/gdb-io-frame.c:186]: (error) Possible null pointer dereference: lv Applied. Thanks. :) -- Dominic Hopf dma...@googlemail.com http://dominichopf.de/ Key Fingerprint: A7DF C4FC 07AE 4DDC 5CA0 BD93 AAB0 6019 CA7D 868D signature.asc Description: This is a digitally signed message part ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] A few fixes for codenav, geanygdb, geanyinsertnum and geanylatex
On Wed, 23 Feb 2011 19:32:07 +0100 Colomban Wendling lists@herbesfolles.org wrote: [./geanyinsertnum/src/insertnum.c:156]: (error) Memory leak: line_pos Thanks. It was never freed actually... -- E-gards: Jimmy ___ 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 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
