From: Daniel J S. <dan...@ie...> - 2005-07-13 23:15:53
|
Ethan Merritt wrote: > On Wednesday 13 July 2005 03:07 pm, Daniel J Sebald wrote: > >>>>After that, I'd propose making the BINARY_DATA_FILE permanent too. >>> >>>I am opposed to removing the EXPERIMENTAL warnings on that one. >>>The binary data file code is still very messy, and having it set off >>>by conditional flags is the only way anyone will ever be able to find >>>pieces for cleanup. >> >>I believe the new code is active by default in the CVS version and >>people have been using it for a year or more. > > > Do you really have a handle on how much use it has seen? There are some demo programs that utilize binary. They all work. I use binary data for images in Gnuplot (but that is only new code, not old). > > I think it is more fair to say that people have been using the > non-binary data path of the new code. Sure. Is there an alternative? I mean, the idea is do the best you can initially to find all bugs and anticipate any problems. Then, if people using the code find bugs you fix them (for free, mind you). > As to the actual binary > data path, I've been finding bugs in it even though I don't actually > use it for anything. I just trip over them while working on other > code parts, or when I hit compiler warnings. I missed something then, my bad. > >>Once people are comfortable with the idea of discarding the old bits, it is easy cleanup. >> >>#ifdef BINARY_DATA_FILE >> <keep this portion> >>#else >> <all this code gets tossed along with the ifdef's> >>#endif > > > But there is something strange about having that sort of code in the > first place. If the BINARY_DATA_FILE code were properly integrated, > that second code segment would be empty. The common functionality > should be factored out and removed from the conditional brackets > altogether. Ideally there would be no #else sections to remove. No. The thinking was "OK, this is a fairly big change that I'm sure people won't be comfortable with; so I had better keep the old behavior around so that people who thing something is wrong can switch over to the old code and verify if that is or isn't the case." It's experimental as indicated when configured. Find a problem? Turn back on the old code. Dan |
From: Petr M. <mi...@ph...> - 2005-07-14 07:07:08
|
>> I believe the new code is active by default in the CVS version and >> people have been using it for a year or more. > > Do you really have a handle on how much use it has seen? No number of users, but: - It is used in Octave image drawings and it works OK. - I use it for edf files. --- PM |
From: Robert H. <en...@no...> - 2005-07-14 10:50:29
|
On Wed, 2005-07-13 at 15:24 -0700, Ethan Merritt wrote: > > > I believe the new code is active by default in the CVS version and > > people have been using it for a year or more. > > Do you really have a handle on how much use it has seen? > In particular is anybody actively testing the CVS version on non-POSIX platforms? I had to compile the windows version the other week for a colleague who had a need for features not in 4.0 - it surprised me how much has changed since the last release. I could probably look at this in more depth if needed (I had to leave out png, gif, and pdf terms because I didn't have time to download pdflib and zlib) Do we have a release schedule in mind for the next version? Rob -- Robert Hart <en...@no...> University of Nottingham This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. |
From: Hans-Bernhard B. <br...@ph...> - 2005-07-14 14:13:09
|
Robert Hart wrote: > In particular is anybody actively testing the CVS version on non-POSIX > platforms? Yes. There may not be terribly many of them, but they exist. > Do we have a release schedule in mind for the next version? As long as I've been active in this project, there's never really been any kind of "schedule" other than the "Let's suit up for a release *now*" variety. |
From: Robert H. <en...@no...> - 2005-07-14 10:38:07
|
On Wed, 2005-07-13 at 14:34 -0700, Ethan Merritt wrote: > Which reminds me... I did some small amount of such cleanup recently. > You might have a look and see how much of the special-casing of the > BINARY code is not necessary. There was some investigation about Mircrowave OS9 support (which is special cases in some of the data reading code) - I posted a message on comp.os.os9 newsgroup. The replies I've got (and my impression from reading other posts on the groups is that) - if any new version of gnuplot were to be built it would be with gnu tools, and therefore special cases probably wouldn't be needed (and certainly not for the same functions) - nobody is still using gnuplot on that platform (in fact very few people are using the platform at all - and mostly for extreme legacy stuff - i.e. I can't see them upgrading anyway) - the last version of gnuplot to be built was early in the 3.x series (possibly 3.1) Therefore I think we can drop any #define OSK that are "in the way" - and maybe throughout the codebase if somebody feels there is something to be gained by that. Rob -- Robert Hart <en...@no...> University of Nottingham This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. |
From: Ethan M. <merritt@u.washington.edu> - 2005-07-15 23:53:28
|
On Thursday 14 July 2005 03:37 am, Robert Hart wrote: > > There was some investigation about Mircrowave OS9 support (which is > special cases in some of the data reading code) - I posted a message on > comp.os.os9 newsgroup. The replies I've got (and my impression from > reading other posts on the groups is that) > > - if any new version of gnuplot were to be built it would be with gnu > tools, and therefore special cases probably wouldn't be needed (and > certainly not for the same functions) > > - nobody is still using gnuplot on that platform (in fact very few > people are using the platform at all - and mostly for extreme legacy > stuff - i.e. I can't see them upgrading anyway) > > - the last version of gnuplot to be built was early in the 3.x series > (possibly 3.1) > > Therefore I think we can drop any #define OSK that are "in the way" - > and maybe throughout the codebase if somebody feels there is something > to be gained by that. OSK is heavily special-cased in gnuplot's built-in readline. This would clearly be irrelevant if the OSK community has moved to using gnu libreadline. The only other places are a malloc() customization in gplt_x11.c and the previously-discussed variant use of sscanf() in datafile.c. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
From: Daniel J S. <dan...@ie...> - 2005-07-13 21:40:18
|
Petr Mikulik wrote: >>> 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: >> >>> [...] >> 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. Do you mean strip out all the PM3D flags? I'm OK with that. It does add a little bit, but I think as time goes on it might be condensed slightly through clean up. Also, Gnuplot doesn't seem to be too bloated compared to other programs. Plotting a sufficiently large plot will use up more memory than the executable anyway. But please have a look at the patch for more versatile key placement before doing the mods because I'm guessing it would cause some hunks to fail. After that, I'd propose making the BINARY_DATA_FILE permanent too. It would unify the code flow for ASCII, binary, 2D, 3D. I can put together a patch for that down the road. Dan |
From: Petr M. <mi...@ph...> - 2005-07-14 07:27:51
|
> But please have a look at the patch for more versatile key placement before > doing the mods because I'm guessing it would cause some hunks to fail. The patch is fine with me. I think it can go to cvs right now. --- PM |
From: Ethan A M. <merritt@u.washington.edu> - 2005-07-15 06:57:38
|
On Thursday 14 July 2005 10:47 pm, Lucas Hart wrote: > > >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? > > Has there been a consensus on such a change in the direction of > gnuplot development? > > From the gnuplot home page "Gnuplot is a portable command-line driven > interactive data and function plotting utility for ...many platforms > ... has grown to support many non-interactive uses, including web > scripting and integration as a plotting engine for third-party > applications like Octave." I see no change away from that policy statement. > PM3D support adds image processing but that is an option in v4.0. But there the description goes off the rails. PM3D may have been originally motivated by image processing, but most/all of the #ifdef PM3D code segments in gnuplot have absolutely zero to do with image processing. > Users who have no need for the image processing features, who do > not have graphics hardware to support PM3D graphics, or to whose > OS PM3D is not ported can build a v4.0 executable without PM3D > support. This makes no sense to me (does it really say this on our home page?). There is no graphics hardware required for PM3D, nor is there an OS requirement. Zero. None. Nada. This statement is just utterly confused. > You seem to be taking the position that portability and local > configurability of gnuplot are no longer goals, rather that newer > versions of gnuplot are intended solely for systems capable of being > used for image processing Forget this business about image processing. That is a red herring. That phrase appears nowhere in the gnuplot documentation, and should not appear on the web site either. In fact the portability and generality of gnuplot scripting is very much improved by the PM3D code. I have never used gnuplot for image processing, but my web scripts use the PM3D code daily for generating plots with portable color assignments, filled curves, color-coded scatter plots, and so on. > While it is an additional burden on developers to code and test > w/ and w/o PM3D support, and building w/o PM3D support on Linux > platforms may have little impact on resources, I believe requiring > gnuplot users to include PM3D support is a major change that may > affect portability. I would be more impressed by that argument if someone could point to a single platform for which inclusion of PM3D support is problematic. Are you agreeing with HBB that a 10% size difference is a make-or-break issue? Is there reason to believe that the size difference on non-unix platforms will be greater that 10%? I encourage someone to run the same test builds I did on, say, MSWindows. If I recall correctly, PM3D per se is not a problem even for 16-bit DOS. It's the PostScript driver that is the killer, because its text section contains huge blocks of PostScript prolog string data. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
From: Petr M. <mi...@ph...> - 2005-07-15 11:37:12
|
>> PM3D support adds image processing but that is an option in v4.0. PM3D being a configure option dates to its beginning in 1999, when it was just an option to draw colour maps and surfaces (well, the "image processing" is not the best term for this). >> Users who have no need for the image processing features, who do >> not have graphics hardware to support PM3D graphics, or to whose >> OS PM3D is not ported can build a v4.0 executable without PM3D >> support. PM3D features can be used on any platform -- and if even not natively via a screen terminal, then via postscript or png. "Not having need for pm3d" is not a good excuse for not compiling it in. E.g. the fitting module is not used by many people and it's there as well, etc. >> You seem to be taking the position that portability and local >> configurability of gnuplot are no longer goals, Yes it is, but pm3d is a functionality of gnuplot, it does not depend on external tools, thus it does not need system-specific configure. > plots with portable color assignments, filled curves, color-coded > scatter plots, and so on. This shows that the PM3D has propagated into so many places that that's really just the time to remove its #idefs. >> I believe requiring gnuplot users to include PM3D support is a major >> change that may affect portability. Don't you rather mean that NOT including PM3D decreases portability? > I would be more impressed by that argument if someone could point > to a single platform for which inclusion of PM3D support is problematic. > Are you agreeing with HBB that a 10% size difference is a make-or-break > issue? Is there reason to believe that the size difference on non-unix > platforms will be greater that 10%? I encourage someone to run the > same test builds I did on, say, MSWindows. I don't think that's worth it -- mainly if GNU C compiler is used. --- PM |
From: Hans-Bernhard B. <br...@ph...> - 2005-07-15 14:20:50
|
Ethan A Merritt wrote: > issue? Is there reason to believe that the size difference on non-unix > platforms will be greater that 10%? On the platforms I'm concerned about, it will be larger than 10%, simply because the program itself will already have to be considerably smaller there. So the figure to keep in mind is the absolute size of the PM3D code, not the relative change. That appears to be 100 kB, for the Unix-based case. 16-bit code tends to be smaller, so it won't be quite as much on DOS or Win16. Current status is that enabling PM3D brings the DOS16 build (very small term.h) from 633264 bytes to 704960 bytes. The 633K version still doesn't quite work yet. But there's no way a 704960-byte program can run on DOS. If I turn off essentially *all* optional features (string vars, PM3d, image, histograms, ...), I get down to 592560 bytes. So yes, at the moment PM3D is currently contributing a major part to breaking the DOS build's back. > If I recall correctly, PM3D per se is not a problem even for 16-bit > DOS. It's the PostScript driver that is the killer, because its text > section contains huge blocks of PostScript prolog string data. For now, I have to remove the postscript driver to come close to a buildable DOS 16-bit version. Win16 should be a different story. |
From: Petr M. <mi...@ph...> - 2005-07-15 17:00:28
|
> The 633K version still doesn't quite work yet. But there's no way a > 704960-byte program can run on DOS. It can, compiled with a 32bit extender-friendly compiler like emx, djgpp, etc. > So yes, at the moment PM3D is currently contributing a major part to breaking > the DOS build's back. > >> If I recall correctly, PM3D per se is not a problem even for 16-bit >> DOS. It's the PostScript driver that is the killer, because its text >> section contains huge blocks of PostScript prolog string data. > > For now, I have to remove the postscript driver to come close to a buildable > DOS 16-bit version. Win16 should be a different story. Instead of disabling all new features available in gnuplot 4.0, users can use gnuplot 3.7, and all is working fine without any additional work. Why to bother with pure 16bit version? --- PM |
From: Ethan M. <merritt@u.washington.edu> - 2005-07-15 17:01:50
|
On Friday 15 July 2005 07:22 am, Hans-Bernhard Broeker wrote: > > So yes, at the moment PM3D is currently contributing a major part to > breaking the DOS build's back. For now, I have to remove the postscript > driver to come close to a buildable DOS 16-bit version. Sorry, but I just do not see this as being an important issue. I frankly don't think that support of 16-bit DOS should be a consideration in gnuplot development. I refer you again to the article that Robert Hart (no connection to Lucas Hart that I know of :-) pointed out the other day, which argues against spending any effort to support minority platforms. http://www.livejournal.com/users/udrepper/7326.html and subsequent discussion on Slashdot http://developers.slashdot.org/article.pl?sid=05/05/30/2233251&from=rss The guy takes it too far IMHO, since he is focused on minority platforms within the already restricted unix-derived world. But the point is even more apposite when applied to our case. We should let obsolete platforms (Amiga, DOS16) and terminals (ggi, NextStep, selanar) die a natural death and purge them from the development tree. Not so much because nobody uses them, but because nobody is implementing the new features in these code segments. What is the point of having a NextStep driver in 4.2 if it doesn't support any of the features added since 3.7? What is the point of having a ggi driver that requires libraries from SCO/Caldera which are no longer distributed even by the vendor? -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
From: Petr M. <mi...@ph...> - 2005-08-03 16:29:10
|
As indicated earlier, I tend to remove PM3D compile options (i.e. to have all PM3D code in) in order to clean up the source code. The only vote against was that 16bit DOS will not compile any longer due to "640 KB limit", but this argument was refused. I guess I do the change during the weekend, unless there are yet more agreed votes against. --- PM |