Re: [Geany-devel] Adding .gitignore files to geany-plugins
Am 09.03.2011 03:44, schrieb Matthew Brush: On 03/08/11 17:55, Thomas Martitz wrote: git-svn supports svn:ignore property, perhaps use that instead. See git svn create-ignore/show-ignore. Good to know. But I ran git svn show-ignore and the list of excludes it printed doesn't seem nearly complete. Is it that the svn:ignore properties and/or global-ignore needs to be updated on the SVN repository? Yes, most likely the list isn't complete. Cheers, Frank ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Hello
Nicolas, Just to offer you an alternative, scintilla is an upstream project of Geany--what I mean is, scintilla is the--well, microsoft would call it the control, in Linux I guess you'd call it the editing widgit--it's the main GUI (I think) that Geany uses for editing. I'm trying to write a lexer / folder for scintilla for the family of markup languages including TWiki, Foswiki, and askRhk (my own variations on TWiki). A lexer/folder is the thing that highlights syntax and allows folding for a given language (like C, C++, HTML, ...). If such a lexer/folder is written for scintilla, it is a small effort (and the normal thing to happen) to add it to Geany. If you'd like to help with that effort, I could surely use the help. ;-) If you want me to give you some example tasks and tell you about my progress to date, let me know. (My problem is that I am not a C/C++ programmer, thus things are coming very slow.) Randy Kramer On Wednesday 09 March 2011 03:45:33 am Nicolas Floquet wrote: I am a french student in computer science, specialized in embedded systems and low level programming. However, since I'm kind of a linux lover, I've always wanted to be involved in an open-source project, and it turns out that geany is very interesting to me. I don't have a big professional experience, I am currently doing my final internship at the CNES (The french national space agency) My biggest project is a x86 operating system that I am currently developping with four of my friends (Quite useless project, but very didactic!). For every project I worked on, Geany has been my best friend (errr that sounds nerd), and now I would like to get involved on this project. I hope that I will find some task to work on with you, bug correction, making coffee, ventilating, anything! PS: I try to do my best to avoid english writting mistakes, but feel free to correct me if necessary ;) ___ 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 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
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] Hello
On Wed, 9 Mar 2011 09:45:33 +0100, Nicolas wrote: Hi, I am a french student in computer science, specialized in embedded systems and low level programming. However, since I'm kind of a linux lover, I've always wanted to be involved in an open-source project, and it turns out that geany is very interesting to me. I don't have a big professional experience, I am currently doing my final internship at the CNES (The french national space agency) My biggest project is a x86 operating system that I am currently developping with four of my friends (Quite useless project, but very didactic!). For every project I worked on, Geany has been my best friend (errr that sounds nerd), and now I would like to get involved on this project. I hope that I will find some task to work on with you, bug correction, making coffee, ventilating, anything! +1 for making coffee. There is never enough coffee available... Er, more seriously, welcome Nicolas! As Lex said, read HACKING, ask questions, pick some bugs or feature requests or whatever else you want and get in touch. Very much appreciated. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc pgpTo9s81clP9.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] Adding .gitignore files to geany-plugins
On Wed, 09 Mar 2011 11:21:21 +0100, Frank wrote: Am 09.03.2011 03:44, schrieb Matthew Brush: On 03/08/11 17:55, Thomas Martitz wrote: git-svn supports svn:ignore property, perhaps use that instead. See git svn create-ignore/show-ignore. Good to know. But I ran git svn show-ignore and the list of excludes it printed doesn't seem nearly complete. Is it that the svn:ignore properties and/or global-ignore needs to be updated on the SVN repository? Yes, most likely the list isn't complete. I use SVN, so I don't care much about a .gitignore (read: I'm neutral). I just would suggest, if we use a .gitignore as well (assuming replying svn:ignore won't work as expected with GIT), keep the .gitignore somewhat in sync with the svn:ignore content. Just my 2cents. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc pgpVLV7HA6N8H.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] Adding .gitignore files to geany-plugins
On 09.03.2011 20:05, Enrico Tröger wrote: I use SVN, so I don't care much about a .gitignore (read: I'm neutral). I just would suggest, if we use a .gitignore as well (assuming replying svn:ignore won't work as expected with GIT), keep the .gitignore somewhat in sync with the svn:ignore content. That's best accomplished by setting svn:ignore and generating .gitignore from it. IIRC, if you clone a svn repo with git-svn then it even automatically does this (and puts the ignores into .git/info/exclude). Best regards. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Adding .gitignore files to geany-plugins
On Wed, 9 Mar 2011 20:15:31 +0100, Frank wrote: On Wed, 09 Mar 2011 20:07:26 +0100 Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: On 09.03.2011 20:05, Enrico Tröger wrote: I use SVN, so I don't care much about a .gitignore (read: I'm neutral). I just would suggest, if we use a .gitignore as well (assuming replying svn:ignore won't work as expected with GIT), keep the .gitignore somewhat in sync with the svn:ignore content. That's best accomplished by setting svn:ignore and generating .gitignore from it. IIRC, if you clone a svn repo with git-svn then it even automatically does this (and puts the ignores into .git/info/exclude). But based on feedback earlier inside this thread, the svn:ignore list seems not to be complete. This seems like a good time to make it more complete...:D. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc pgpCUwcL8I4k3.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] Adding .gitignore files to geany-plugins
On Wed, 9 Mar 2011 20:21:27 +0100 Enrico Tröger enrico.troe...@uvena.de wrote: On Wed, 9 Mar 2011 20:15:31 +0100, Frank wrote: On Wed, 09 Mar 2011 20:07:26 +0100 Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: On 09.03.2011 20:05, Enrico Tröger wrote: I use SVN, so I don't care much about a .gitignore (read: I'm neutral). I just would suggest, if we use a .gitignore as well (assuming replying svn:ignore won't work as expected with GIT), keep the .gitignore somewhat in sync with the svn:ignore content. That's best accomplished by setting svn:ignore and generating .gitignore from it. IIRC, if you clone a svn repo with git-svn then it even automatically does this (and puts the ignores into .git/info/exclude). But based on feedback earlier inside this thread, the svn:ignore list seems not to be complete. This seems like a good time to make it more complete...:D. Dammit. I knew there was something -- http://frank.uvena.de/en/ pgpJ6ud7QOpkJ.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 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
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
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
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
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] Adding .gitignore files to geany-plugins
On 03/09/11 11:26, Frank Lanitz wrote: On Wed, 9 Mar 2011 20:21:27 +0100 Enrico Trögerenrico.troe...@uvena.de wrote: On Wed, 9 Mar 2011 20:15:31 +0100, Frank wrote: On Wed, 09 Mar 2011 20:07:26 +0100 Thomas Martitzthomas.mart...@student.htw-berlin.de wrote: On 09.03.2011 20:05, Enrico Tröger wrote: I use SVN, so I don't care much about a .gitignore (read: I'm neutral). I just would suggest, if we use a .gitignore as well (assuming replying svn:ignore won't work as expected with GIT), keep the .gitignore somewhat in sync with the svn:ignore content. That's best accomplished by setting svn:ignore and generating .gitignore from it. IIRC, if you clone a svn repo with git-svn then it even automatically does this (and puts the ignores into .git/info/exclude). But based on feedback earlier inside this thread, the svn:ignore list seems not to be complete. This seems like a good time to make it more complete...:D. Dammit. I knew there was something You can use the file/patch I sent on the original message to get a current list of what needs to be excluded/ignored, to update the svn:ignore property. The main problem I see with using the svn:ignore property is that I don't think it's settable for all the people using git-svn (might be able to now, but not from what I read online), so it's unlikely those plugins that generate files that should be ignored are going to have the svn:ignore property updated. The other thing is that anyone using the Git mirror isn't going to get those excludes/ignores, however, having used git-svn for a little bit now, I don't even understand why anyone would use the Git mirror over git-svn for development. The one thing I do like about .gitignore files is that you can have one global one for the whole project, and then one in each plugin dir that needs one, and then the plugin author just needs to tack on his generated files as required. I must say, being a newbie to community development and version control, I kinda freaked out bit when I almost commited 50 new files polluting the whole tree with noise on my first commit. Now that I've got my end setup properly, it's not as much of an issue, but hopefully at least it will result in the svn:ignore property being updated and maybe help with DRY for each developer (ie. maintaing their own ignores). Cheers, Matthew Brush (codebrainz) ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
