Menu
▾
▴
gnuplot-beta
|
From: Nigel N. <nN...@au...> - 2004-06-02 03:04:08
|
Another vote in favour of dropping K&R syntax. I have a wxWidgets demo that builds Gnuplot 4.x as a library, and drives it programmatically. But before adding another set of #defines to the code, it would be good if the config and pre-processor stuff could be cleaned up to simplify the next few years of Gnuplot evolution. Nigel PS: congrats to HBB on PhD! -----Original Message----- From: Allin Cottrell [mailto:cot...@wf...] Sent: Wednesday, 2 June 2004 12:35 PM To: gnuplot-beta Subject: Re: K&R C (was Re: Bugs in enhanced mode) On Tue, 1 Jun 2004, Daniel J Sebald wrote: > Would this be a tolerable hack? Define a special type in some header > for char's as function arguments > > /* Throwback to K&R */ > #ifdef __STDC__ > #define ACHAR char > #else > #define ACHAR int > #endif I strongly support the suggestion put forward by Hans-Berhard a few days ago, namely that support for 'K&R' should be dropped. I'm not aware of any other serious software package that insists on supporting pre-1989 C compilers. The effect is simply to complicate and obfuscate the gnuplot code. I'm aware that I don't have much standing in this debate because I have not contributed much to gnuplot. On the other hand, I'd be more inclined to contribute were it not for the weird archaisms in the gnuplot code base. How many people are there in the world who refuse to use an ISO/ANSI C compiler, but who want to be able to compile the latest and greatest gnuplot? Allin Cottrell ********************************************************************************** This message is intended for the addressee named and may contain confidential and privileged information. If you are not the intended recipient please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you receive this message in error, please delete it and notify the sender. Keep up to date with what's happening in Australian sport. Visit http://www.ausport.gov.au ********************************************************************************** |
|
From: Daniel J S. <dan...@ie...> - 2004-06-02 04:07:25
|
Nigel Nunn wrote: >Another vote in favour of dropping K&R syntax. I have a >wxWidgets demo that builds Gnuplot 4.x as a library, and >drives it programmatically. But before adding another set >of #defines to the code, it would be good if the config >and pre-processor stuff could be cleaned up to simplify >the next few years of Gnuplot evolution. > That I'd go along with. Speaking of evolution, the CVS source tree is a moving target right now. What are the near term, six month, one year plans? Dan -- Dan Sebald email: daniel DOT sebald AT ieee DOT org URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/ |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-06-02 11:34:39
|
On Tue, 1 Jun 2004, Daniel J Sebald wrote: > Would this be a tolerable hack? Define a special type in some header > for char's as function arguments > > /* Throwback to K&R */ > #ifdef __STDC__ > #define ACHAR char > #else > #define ACHAR int > #endif Ethan already suggested pretty much the same idea, and I rejected it as terminally ugly, and not particularly useful. If the K&R variant (making the parameter 'int') works at all, it'll work for ANSI C, too. > Anyway, is gnuplot.texi a generated file? (I see something called > doc2texi.el) If so, should it be in the cvsignore list so that it isn't > checked out when getting the latest CVS version? gnuplot.texi is a bit tricky to regenerate. Up until rather recently, I never managed to do it myself, because I usually do all builds outside the source tree, which breaks the generation of gnuplot.texi. Therefore, even though I'm not quite happy with the situation, I agree with Lars on this one: it'll have to remain inside CVS for now. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-06-02 11:47:08
|
On Wed, 2 Jun 2004, Lars Hecking wrote: > That said, we should move to ISO/ANSI C, and let ansi2knr sort it out. > As Lucas and myself recently found it, tis in turn will require a few > changes in the code. And one of those changes is elimination of 'char' type arguments, right? Because, as far as I'm aware, that's not handled by ansi2knr. So: do we have a consensus that we'll ANSI-fy the sources right now? And if so: do we do it on the 4.1 version after branching of a 4.0 for the "stable" version, or do we keep the version at 4.0 for the time being? At the minimum, I think we should tag a patchlevel 1 immediately before, and a patchlevel 2 after this change. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-06-02 11:55:18
|
On Tue, 1 Jun 2004, Daniel J Sebald wrote: > That's true. But I'm guessing one of the philosophies of Gnuplot is to > accommodate as wide an audience as reasonably possible Certainly. The debate we're having is about the exact meaning of "reasonably" in this context. It's becoming harder to guarantee K&R compatibility, with none of us using real K&R compilers on a daily basis any more. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-06-02 11:56:13
|
On Tue, 1 Jun 2004, Daniel J Sebald wrote:
> Speaking of evolution, the CVS source tree is a moving target right now.
> What are the near term, six month, one year plans?
We're not in the habit of making any plans...
But, if pressed, I'ld say:
near term: iron out remaining bugs in 4.0, split off a 'stable' 4.0
branch, tag the trunk as 4.1
medium term: discuss selection of patches, and integrate selected ones
into 4.1
--
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.
|
|
From: Daniel J S. <dan...@ie...> - 2004-06-02 17:05:16
|
Hans-Bernhard Broeker wrote: >We're not in the habit of making any plans... > >But, if pressed, I'ld say: > >near term: iron out remaining bugs in 4.0, split off a 'stable' 4.0 > branch, tag the trunk as 4.1 > I think there is a way in CVS to merge branches eventually, no? Anyway, simple bug fixes usually can be handled by "patch" with realignment, but something like ANSIfying the code would certainly cause problems for a large percentage of the patches in SourceForge. >medium term: discuss selection of patches, and integrate selected ones > into 4.1 > This would be nice. I'd opt for clearing the patch page over the course of a couple months. Then ANSIfy and restructer code. Dan |
|
From: Petr M. <mi...@ph...> - 2004-06-03 10:10:36
|
> >medium term: discuss selection of patches, and integrate selected ones > > into 4.1 Currently, I build my gnuplot with these patch: raise with image set mouse key $# I would see them in "regular development version of" gnuplot (soon?). -- PM |
|
From: BBands <bb...@ya...> - 2004-06-03 15:14:50
|
Dear gnuplotters,
Per an earlier discussion on EMFs and Windows.
Things have changed for EMFs in Windows. A Windows
security patch to fix an EMF buffer overflow
vulnerability, KB 835732, prevents many EMFs from
displaying. See MS Knowledge Base article KB 840997.
The hotfix did not work for me, I had to back out the
security patch to get gnuplot generated EMFs to
display.
Pass this along if you think it germane.
--jab
=====
John Bollinger, CFA, CMT
www.BollingerBands.com
If you advance far enough, you arrive at the beginning.
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2004-06-03 15:33:36
|
On Thursday 03 June 2004 03:10 am, Petr Mikulik wrote: > > Currently, I build my gnuplot with these patch: > raise > with image > set mouse key > $# > > I would see them in "regular development version of" gnuplot (soon?). I have five patchsets that I consider stable and ready to go into CVS whenever continued development is split off from 4.0 bugfixing. fillbounds adds "above" and "below" bound-clipping to filledcurves datastrings 'plot with labels', tic and plot labels from datafile, etc histograms plot with histograms fillcurves use fill style for filledcurves (cgm gd pdf post svg x11) XEvent reorganizes X event loop to speed up refresh The 'set mouse key' patch works, but I'm still cleaning it up and it sure would be nice to have string variables so that I could return the keypress as a character rather than as a key code. -- Ethan A Merritt Department of Biochemistry & Biomolecular Structure Center University of Washington, Seattle |
|
From: Petr M. <mi...@ph...> - 2004-06-03 16:23:06
|
> I have five patchsets that I consider stable and ready to go into
> CVS whenever continued development is split off from 4.0 bugfixing.
>
> fillbounds adds "above" and "below" bound-clipping to filledcurves
> datastrings 'plot with labels', tic and plot labels from datafile, etc
> histograms plot with histograms
> fillcurves use fill style for filledcurves (cgm gd pdf post svg x11)
> XEvent reorganizes X event loop to speed up refresh
OK with me
> The 'set mouse key' patch works, but I'm still cleaning it up and it
> sure would be nice to have string variables so that I could return
> the keypress as a character rather than as a key code.
If there are string variables, then both the keypress code (an integer
number) and string representation of the key will be returned.
Some other "cleaning" of interactive terminal APIs could be done by changing
"term->set_cursor(int,int,int)"
to
"term->set_interactive_terminal_function(int,int,int [,int?], string)"
to be reused for several purposes like "unset your default hotkeys", "change
menu", "do raise", etc.
Just I don't have time to do this change, right now.
---
PM
|
|
From: Daniel J S. <dan...@ie...> - 2004-06-03 17:03:40
|
Ethan A Merritt wrote: >I have five patchsets that I consider stable and ready to go into >CVS whenever continued development is split off from 4.0 bugfixing. > > fillbounds adds "above" and "below" bound-clipping to filledcurves > datastrings 'plot with labels', tic and plot labels from datafile, etc > histograms plot with histograms > fillcurves use fill style for filledcurves (cgm gd pdf post svg x11) > XEvent reorganizes X event loop to speed up refresh > >The 'set mouse key' patch works, but I'm still cleaning it up and it >sure would be nice to have string variables so that I could return >the keypress as a character rather than as a key code. > > In the same category of a few of the above patches, someone (don't remember who) had done some work to integrate gray scale filled curve-like plots into PostScript. That looked pretty nice, but I wonder if PostScript might be the only driver to easily support such a feature. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-06-03 17:14:23
|
On Thursday 03 June 2004 10:26 am, Daniel J Sebald wrote: > > fillcurves use fill style for filledcurves (cgm gd pdf post svg) > > In the same category of a few of the above patches, someone (don't > remember who) had done some work to integrate gray scale filled > curve-like plots into PostScript. That looked pretty nice, but I wonder > if PostScript might be the only driver to easily support such a feature. If I understand your description correctly, that is supported by the above patch: plot <whatever> using filledcurve linetype -1 fillstyle solid <greylevel> But maybe you are thinking of the request for shaded areas in the background? That should be possible to implement for any driver that supports filled rectangles, but I don't recall any suggestions at all as to what sort of syntax would be used to request such a plot. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2004-06-03 19:20:19
|
Ethan Merritt wrote: >On Thursday 03 June 2004 10:26 am, Daniel J Sebald wrote: > > >>> fillcurves use fill style for filledcurves (cgm gd pdf post svg) >>> >>> >>In the same category of a few of the above patches, someone (don't >>remember who) had done some work to integrate gray scale filled >>curve-like plots into PostScript. That looked pretty nice, but I wonder >>if PostScript might be the only driver to easily support such a feature. >> >> > >If I understand your description correctly, that is supported by the >above patch: > >plot <whatever> using filledcurve linetype -1 fillstyle solid <greylevel> > Ah, good. >But maybe you are thinking of the request for shaded >areas in the background? That should be possible to implement >for any driver that supports filled rectangles, but I don't recall >any suggestions at all as to what sort of syntax would be used >to request such a plot. > That's correct. Searching back email, Justace Clutter gave an example. I see there is no patch for this, only the example. Dan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X