Hi Alan, > I. Possible technical solution > > Since you have a fairly up-to-date Windows platform, I guess this > means > snprintf is unequivocally not available on any "bare" Windows > platform. > I don't know the situation for Cygwin and MinGW. > > Hez, Andrew: is replacing snprintf with sprintf (just as in all other > examples) what should be done? Or would you like to do something more > general here like configuring plcdemos.h to take advantage of the > CMake > variables, PL_HAVE_SNPRINTF and _PL_HAVE_SNPRINTF to implement > essentially > the same solution as in plplotP.h?
snprintf is available for MinGW/Cygwin. But not for Visual C++. The correct name is _snprintf which has something to do with C99 standard and very likely that Microsoft always had problems with standards. Whatever, plplot "knows" about that and I was about to get these macros through to the examples, but Andrew whistled me back, since the examples should not see private plplot macros, which is correct. So the most easy solution is to add something like #ifdef MSVCVER #define snprintf _snprintf #endif to solve the locally. > > II. Platform testing implications > > I am afraid this result means at least the bare Windows platforms > did not > get tested with ctest since August 5th, the last time example 19 was > changed. That lack of testing during the last month before our > release of > 5.9.5 could have had pretty serious implications for that release, > but I > believe we got off fairly lightly this time (assuming that once we > straighten out the issue, the rest of the examples do work on bare > Windows). > > The problem with attempting to deal with this Windows testing issue in > future is there are many bare Windows platforms as well as Cygwin > and MinGW > (with and without MSYS) to test. So our three active developers > with access > to Windows are unlikely to have time, disk space, and Windows compiler > licenses to test all variations. > > To help deal with this issue for all future releases let's do some > specific > coordination of which developers will take firm responsibility for > running > at least ctest on the Windows platforms that are accessible to > them. That > coordination will probably reveal some Windows platforms that won't be > tested, but it would be good to identify those. > > In any case, I think we should formally ask for some testing help on > the > plplot-general list a week before each release from now on for all > platforms > but especially for the Windows platforms where we don't have good > testing > coverage. (A week should give us time to deal with most issues that > come > up). From our download statistics and number of questions asked on > plplot-general there appears to be more and more interest in PLplot so > encouraging the new users to help out with testing on all our > platforms > (especially for the many different Windows platforms where our > developer > coverage is thin) makes a lot of sense. If there is general > consensus this > is a good idea, and Hazen is willing to send such an e-mail the week > before > each release, I will put a reminder in > README.Release_Manager_Cookbook. Apart from asking users it would generally be good to have one responsible person for a certain combination of OS/compiler and maybe bindings. So we cover maybe not all combinations, but at least some and as you say, we also must cover at least all OS. Although I tested plplot with MinGW before the release and that worked. Regards, Werner > > 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 > __________________________ > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria DVR-Nr: 0005886 email: sme...@iap.tuwien.ac.at web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
