[Plplot-devel] qt split code status
I have changed the subject line since the old one was barely relevant any more. On 2009-06-24 22:58-0700 Alan W. Irwin wrote: Let's proceed in steps. 1. Get everything to work with qt.cpp unsplit both for DYNDRIVERS ON and OFF and for the new and old build system for the installed examples. I would also like to see the pyqt4 extension module (which also depends on libplplotqtd) working for the first time as well. Unless you prefer something different, tomorrow (Thursday) I will work on this including checking in your current patch to the unsplit version of qt.cpp (assuming it works for me as well as it did above for you). 2. Split qt.cpp and confirm things still work for the four cases (DYNDRIVERS ON and OFF and for the new and old build system) and also for the pyqt4 extension module. I actually think splitting qt.cpp into device driver code and a library is generally a good idea. However, there are some build system issues to be aware of for the DYNDRIVERS OFF case, but it should be fairly straightforward to solve them once we have 1. working in all cases. 3. Document. Once, I actually looked at the patch Dmitri sent to the list I had to agree with him that those macros made the source code difficult to understand and essentially emulated splitting the source code. Therefore, I skipped 1. above and proceeded directly to 2 with the aid of a patch that Dmitri sent me off list to split drivers/qt.cpp into drivers/qt.cpp and bindings/qt_gui/plqt.cpp. I added some cmake infrastructure to support the split source code, and the result (revision 10073) gives clean valgrind results for all four kinds of qt devices as well as qt_example. Thanks, Dmitri for your split patch, and thank Alban for your earlier patch to fix uninitialized variables. Those two patches have made these completely clean valgrind results possible. The build-tree and install tree versions of qt.so, libplplotqtd, and plplot_pyqt4.so pass the ldd -r test for undefined symbols. Nevertheless, the split does not solve the black/blank gui problem for pyqt4_test.py. Hopefully, though, the split code is now much more readable and easier to debug for that issue. N.B. The above tests were done just for the default CMake configuration (ENABLE_DYNDRIVERS ON, ENABLE_qt ON) and with the new build system for the installed examples. Additional testing for other configurations is in progress, and in particular there are still a few obvious changes I have to make and test for the traditional build system for the installed examples to complete this work. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Qt driver: fix coding style
Geoff,
This sounds an eminently sensible set of coding guidelines and close to
what I would have suggested. I have only a couple of comments (see below).
In general I don't have really strong feelings about these things. I would
like consistency though. As long as we can easily configure emacs to do
the right thing I personally would be happy.
Andrew
On Thu, Jun 25, 2009 at 10:44:09PM -0500, Geoffrey Furnish wrote:
I would recommend that we publish a plplot-style that works with CC mode in
[X]Emacs.
Then the question is how that style is selected. There is some trick
involving file-local Emacs variables, which we could look up.
An alternative that I have used for some years, is something I call
infer-style, which figures out which style to use for a file based on where
it sits. This way it makes it easy for me to work on multiple projects which
use different styles, with no tweaking of my Emacs config, and no messy
file-local variables in the files in all the projects.
If we get as far as adopting a specific style for PLplot, I would be happy to
share my Elisp hooks and doohickies with others.
As for specific suggestions on the elements of style, just to get some
specifics out for consideration, I suggest:
1) No tabs. Tabs are evil. Spaces only.
2) 4 spaces per indent level
3) Liberal use of spaces:
This:
if ( a != 0 ( b == 2 || c == 2 - x ) ) ...
rather than:
if(a!=0(b==2||c==2-x)) ...
All agreed.
4) Braces:
if ( condition )
{
...
}
else
{
...
}
I have a slight personal preference for:
if ( condition ) {
...
}
else {
...
}
but I'm happy to live with the consensus.
5) Focus on language rules rather than code-nany style rules.
For example, to me, this is okay:
if ( condition )
single_line_action();
else
...
The part between the if and the else does not require enclosure in braces,
even though GCC 4.4 now whines about that in -Wall mode.
6) Somewhat controversial, but I actually do think warning free code is, to
an extent, a matter of style. If we would agree to seek the elimination
of all warnings from GCC 4.4 -Wall, for instance, then I would agree to style
rules that I might not otherwise be excited about (like the one mentinoed
above).
I don't see anything wrong with this code, but as a general rule I would
agree that it is better to be warning free if possible. This makes the
compile neater and reduces bug reports.
I would also be interested in standardizing function comment blocks. There
are a number of differntly styled function intro blocks evident in PLplot.
One thing I've been doing in my professional projects of late, is using
doxygen. I find the standard doxygen style that depends on all the '*'
characters to be really ugly, but since I mostly code in C++, there is the
alternative of ///, which annoys me, but not as badly as * , plus those
dorky header/trailer tokens.
I've not tried doxygen on a C code base before, so I'm not sure if there are
options that are more visibly appealilng than the standard/default. Without
looking into it a bit first, I'm not in a postion to propose a specific style
for function comment blocks. But I thought I throw out the doxygen option in
case anyone else is interested in that, and able to summarize some of the
options.
Fundamentally, I like the 79-char horizontal separators for functions. I
think that makes the code a lot easier to read. But I'm very annoyed by the
/* ... */ style of multi-line C comments. Did C99 pick up //-style comment
to end of line? If so, what would people think of using that in our C code
base?
I tend to think the
/***
* Function name
* Description
***/
style of comment is a little fiddly to write, but is very readable and clearly
marks out different functions. In recent years we have tended to stamp out the
use of // comments in non-C++ code since it is not standard. If your using
emacs with font lock mode then either is easy to read, so I suggest we stick
with the traditional C style for maximum compatibility.
Another element of style that Maurice and I have both used for nearly two
decades now, is that in-function comments are out-dented one level. We've
met some vi users who complain about this, but for [X]Emacs folk, it's
trivially easy to configure the cc-mode to do this, so that it requires no
extra keystrokes, and just happens automatically (plus end-of-line auto
wrapping support). Especially combined with font locking, it really helps to
make comments stand out in a way that lets you easily and visually separate
the control logic and the comments thereupon.
Again, this is not something I usually do, but I can see the sense in it.
[Plplot-devel] PLplot style guide for C/C++ now available as plplot-c-style.el
Thanks, Geoffrey, for your initial thoughts on a PLplot C/C++ coding style. I wanted to return to and emphasize my previous point which is a lot of us use emacs so that specifying an emacs settings file should be beneficial since it should help to focus the discussion and make it easy for us to bring the PLplot C/C++ code into conformance with our style guide as expressed by that emacs settings file. Dmitri previously mentioned the google C/C++ style guide so I looked that up (http://code.google.com/p/google-styleguide/), and there is actually an associated emacs settings file at http://google-styleguide.googlecode.com/svn/trunk/google-c-style.el. I figured the google types probably haven't made any huge blunders with their C/C++ style so I suggest we use that as a first approximation. Therefore, I downloaded and committed (revision 10075) that file (with essentially all instances of google changed to plplot) as plplot-c-style.el. I suggest we view this file as just a first approximation to where we want to go with a uniform C/C++ coding style for PLplot. So, for example, if a consensus develops that the indentation enforced by that file is not to our collective liking, then we can always change it and reprocess all our source files (ideally with a script) to bring them into conformance with the adopted change in style. I am currently trying plplot-c-style.el as follows: softw...@raven tail -6 ~/.emacs ; ; Support PLplot C/C++ style ; (load /home/software/plplot_cvs/HEAD/plplot_cmake_qt/plplot-c-style.el) (add-hook 'c-mode-common-hook 'plplot-make-newline-indent) (add-hook 'c-mode-common-hook 'plplot-set-c-style) Of course your own load command will be different depending on the location of the head of the PLplot source-code tree on your computer. I am an emacs newbie so the only method I know to enforce the PLplot style as given by plplot-c-style.el is to select all the text of the file and then hit ctrl-alt-backslash to change the indentation according to plplot-c-style.el. Resetting the indentation that way does work (i.e., plplot-c-style.el gives different indentation results than the emacs default c style, and both plplot-c-style.el and default C emacs indentation are different than revision 10073 of qt.cpp). I have committed the reindented (according to plplot-c-style.el) result as revision 10074 after confirming with svn diff -x -w qt.cpp that the changes are just whitespace ones. However, style is obviously more than just indentation. So I assume there are other emacs commands that I should be using to force qt.cpp to conform to the PLplot style as given by plplot-c-style.el. Can somebody advise what additional emacs commands I should use besides ctrl-alt-backslash to enforce that style? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
