|
From: Petr M. <mi...@ph...> - 2005-07-13 16:14:11
|
>> Candidates for being always in gnuplot are: > >> #define EAM_DATASTRINGS 1 >> #define EAM_HISTOGRAMS 1 >> #define GP_MACROS 1 >> #define GP_STRING_VARS 2 >> #define GP_FIT_ERRVARS 1 >> #define PM3D 1 > > On Wednesday 13 July 2005 08:17 am, Hans-Bernhard Broeker wrote: >> >> I still haven't fully given up revitalizing the 16-bit >> builds yet (I've got DOS16 to link with OW, a third-party linker and >> some serious modifications...). These 10 percent of extra load could >> easily kill those. > > I think that effort would be a total and utter waste of your time. > Anyone runinng 16-bit DOS can just live with version 3.7 I think so too. Those old PC's are not used for image processing anyway, so they have no reason to switch to gnuplot >= 4.0. > I have not looked at GP_FIT_ERRVARS in detail, and don't have an > opinion on it. The rest of them should go in IMHO. We should avoid having too many gnuplot versions depending on ./configure options. It's better to on/off these features by some "set ..." switches. Was there any report of a broken script? > In particular PM3D is now so integral to many new features that I > think it would make no sense for anyone to upgrade past version 4.0 > and *not* include PM3D. Why go out of our way to support a > combination of options that doesn't make any sense? > > So yes, I think the PM3D code should be made unconditional. I will do this change within one week if there is no really strong objection. > If you like, I can resurrect the earlier patch pulling the PostScript > prolog and character-encoding text blocks out of the driver and make > them separately loadable files. That should gain about half of the > PM3D size back right there, and it has other benefits unrelated to > 16-bit support. The problem with loadable files is there to install them. Gnuplot supports too many OSes. Gnuplot load path is a candidate, but ... e.g. usual MSW users do not have any idea about setting environmental variables. --- PM |