[Plplot-devel] pyqt4 bindings - cmake check not thorough enough
I notice that the pyqt4 bindings check for the presence of sip and disable the bindings if this is missing. On my Ubuntu systems with sip install this causes a compile error because I don't have the python-qt4-dev packages installed. It seems QtCore/QtCoremod.sip is missing. These binary packages come from different source packages. I don't know if other systems have this problem, but it might be worth a more thorough cmake check. Andrew -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] code cleanup: remove NEED_PLDEBUG
On Sat, Jul 04, 2009 at 08:14:27AM +0300, Dmitri Gribenko wrote: > On Fri, Jun 19, 2009 at 5:57 PM, Dmitri Gribenko wrote: > > There's actually no need in NEED_PLDEBUG (include/pldebug.h). > > pldebug() can be declared inline and that will silence warnings about > > pldebug() being unused. ?'inline' keyword is from C99. ?If it is a > > concern that some C compilers may not support 'inline' (but most > > modern compilers do), then an appropriate check can be added to the > > build system. > > > > The attached patch does what is described above. > > Hello, > > Anything wrong with that patch? > > Dmitri Dmitri, Your patch is fine for compilers which support C99 (or at least inline). We tend to be conservative about assuming such support in the core library since one of the great benefits of plplot is that it is very portable. A quick web search suggests that inline is not available for C code in Visual Studio 2003 for example. A cmake check for inline could get round this issue. Perhaps those with non-gcc compilers could comment on the availability of "inline". Thanks Andrew -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] cmap0.pal and cmap1.pal support
Alan W. Irwin wrote: > On 2009-07-06 12:26-0400 Hazen Babcock wrote: > >> Hezekiah M. Carty wrote: >>> On Sun, Jul 5, 2009 at 9:15 PM, Hazen Babcock wrote: As of v10119 you can now specify the color table to use for color table 0 or color table 1 as a command line argument to PLplot. For example: >>> As part of this effort the PLplot API has two new additions: plspal0(filename) - Set the color table 0 palette based on the cmap0.pal format file specified by filename. plspal1(filename) - Set the color table 1 palette based on the cmap1.pal format file specified by filename. Example .pal format files can be found in plplot-source/bindings/tk. Hopefully this addition will make it easier for people to use their preferred color scheme. >>> >>> Hazen, >>> >>> Thank you for putting these functions together. Are the names set and >>> ready to be propagated to other language bindings? >> >> I'd wait a week or two to see if anyone complains. >> >>> Where should new color palettes be placed in the PLplot source tree? >> >> I think that they are going to go into a new directory called cmaps in >> the root directory. > > Hi Hazen: > > Much thanks for this effort which is going to make colour management much > easier for PLplot. > > Currently plspal0 and plspal0 simply fopen the specified file with no > checks > on whether it exists. One obvious way to deal with that issue is to use > the > same function (plLibOpenPdfstrm) we use for opening map files and also our > traditional Hershey font files. > > plLibOpenPdfstrm currently tries a large number of standard locations > (including the current directory) to find the file specified. Any pointers for using this function? When I try: fp = (FILE *)plLibOpenPdfstrm(filename); instead of: fp = fopen(filename, "r"); I get a segmentation fault at my first attempt to read from the file: fscanf(fp, "%d\n", &number_colors); My guess was that this was due to the fact that it opens the file in "rb" mode instead of "r" mode, but when I modified it to use "r" mode I still got the same segfault. -Hazen -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] cmap0.pal and cmap1.pal support
On 2009-07-07 11:06-0400 Hazen Babcock wrote: > Alan W. Irwin wrote: >> plLibOpenPdfstrm currently tries a large number of standard locations >> (including the current directory) to find the file specified. > > Any pointers for using this function? When I try: > fp = (FILE *)plLibOpenPdfstrm(filename); > > instead of: > fp = fopen(filename, "r"); > > I get a segmentation fault at my first attempt to read from the file: > fscanf(fp, "%d\n", &number_colors); > > My guess was that this was due to the fact that it opens the file in "rb" > mode instead of "r" mode, but when I modified it to use "r" mode I still got > the same segfault. Both plsym.c and plmap.c use routines in pdfutils.c to actually read the file they open with plLibOpenPdfstrm. So you might want to do the same (using pdf_rd_header?) or else adapt the file access methods in the pdfutils.c code for the colour palette reading needs. An additional format issue I just thought of for these ascii colour palette files is line endings. Presumably some of our Windows users will want to edit these files directly (since they have no access to -dev tk or the associated colour palette GUI) so the resulting ascii files will have the Windows line endings (\cr followed by \nl as opposed to the Unix \nl). Also, assuming that we use the svn native line ending property for these files, our Windows users will checkout a version of our official palette files that have the windows line endings. I presume the Windows line endings means the null-terminated string returned by pdf_rd_header will have a \cr prepended to that null termination which will require a bit of care when parsing that string (or a special provision in pdf_rd_header to remove the \cr if it exists and the platform is windows). 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 __ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] style
Alan W. Irwin writes: > I have changed to the "style" subject line for this since it touches on > three separate recent threads with varying subject lines involving style. > > On 2009-06-30 15:20-0500 Geoffrey Furnish wrote: > > > Oh, one more really last thing. I haven't gotten around to trying out > > Alan's proposal for plplot-mode. > > It seems to me consensus on style has largely been reached, but I remain > deeply concerned that all the thought and time that has gone into this > discussion will be completely wasted unless somebody can come up with at > least one method to make it easy to conform to our agreed-upon style > consensus. > > Changing plplot-mode.el to reflect our style consensus is just one > possibility for that, but my newbie emacs questions on how to use emacs to > control more than just indentation (for example, to place whitespace > around parentheses, break or attach brackets, etc.) have gone unanswered. > It appears to me from describe-mode that parentheses and braces are > specially defined so the answer may be that with the appropriate > modifications to plplot-mode.el, that all new code will automatically > conform to our parentheses and bracket style. I just checked with a bit > of new C code, and it appears those modifications still need to be made. > But I hope this much at least is possible with emacs. I am overbooked with professional obligations for the next few work days. I expect I'll be able to address some of this in the time frame of end of next week. In very short, and probably inadequate response, my experience with using cc-mode for over a decade, is that I do my own spacing within a line, use C-j for newline, and the indentation happens correctly, and I am happy. The :-character also does some auto redenting. Electric braces just show me where the matching brace is, but I don't have any sort of auto-replacement of braces active in my own cc-mode style. The style you proposed is very very long compared to the one tht Maurice and I have used for years. I took a look through it, and didn't recognize many of the settings. The default cc-mode style, with adjusted c-basic-offset, is very close to how Maurice and I have used to author C and C++ for years. I plan to try to cull that out and exhibit it for consideration as well. But I have to get through an all-consuming activity at work in the next few days first. > However, because of the strong possibility that emacs may not be suitable > for changing the style of our old code, I started looking for other > coding-style tool alternatives, and the first one I found (called astyle) > looks interesting. Please take a look at > http://astyle.sourceforge.net/astyle.html for all the possibilities for > dealing with whitespace, parentheses, and brackets in programme source for > C, C++, and Java. It's a command-line tool with the possibility of using > a style file to control transforming our code base to our style consensus. > Thus, at first look it seems ideal for our needs, and I would appreciate > others here to look at it in more detail to make sure that really is the > case. My only real concern with this, is that no reformatting tool I've ever used has had the result of producing the same thing as what flows naturally from the use of cc-mode. If you use a reformatter (say as part of git commit ), and then find that the tab key (reindent line in [X]Emacs) moves stuff around, it sort of defeats the whole purpose of an editor-based style. So, I'm interested, but I'd like to see that we find a way to converge the in-editor-style with the reformatter-tool-style. I hope that's possible. And, I hope we can get the same or nearly the same assistive style programmed up for vim. I don't know vim myself, but I've been told it has programmable styles too, so I'm optimistic. But the more special casing we put into the style, the harder it will be to duplicate it on a range of tools (vim + [X]Emacs + reformatter(s)). So I think we should continue to do some experimenting and see how close we can come to something that works automatically and consistently. > > Does anyone know why "describe-mode" doesn't seem to have much to say > > about cmake-mode? Skimming the file, you'd think there would be a > > number of functions bound to keys, but apparently not. Seems strange. > > Am I missing something that anyone else has found? > > cmake-mode.el is a work in progress by the CMake team of developers. The > (almost) latest version can be found at cmake-2.6.4/Docs/cmake-mode.el. I > just checked, and that is very different from the equivalent file for > cmake-2.6.0. So if you are trying out an earlier version you should > probably switch to the 2.6.4 version. That said, I just switched from the > 2.6.0 version to 2.6.4, and the describe-mode results appear to be > unchanged. > > I say "almost" above, because my understanding from the CMake mailing list >
