Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2004-06-17 10:50:34
|
On Wed, 16 Jun 2004, Ethan Merritt wrote: > On the topic of compiler compatibility, > do we care about the following warnings from "gcc -pedantic"? We should care, but not too strongly. This is one of the pedantic ISO/ANSI C limits that pretty much every compiler on the planet seems to overcome easily. I.e. they seem to have been a bit more cautious in selecting that number than they strictly had to. In other words: there are *lots* of serious warnings we should tackle first before worrying about these. -pedantic mode is the least of our worries, as long as a simple gcc drowns us in hundreds of -Wsign-compare warnings. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-06-17 10:50:36
|
On Wed, 16 Jun 2004, Allin Cottrell wrote: > On Wed, 16 Jun 2004, Ethan Merritt wrote: > > > So I think Stephane's patch is usable, with maybe a footnote > > somewhere to warn of possible character problems. My > > one remaining reservation is that the revised version is no > > longer unicode compatible. > > Could we persuade Stephane to revert that aspect of the change? Or, maybe more to the point: is it feasible to break out that aspect and only keep the other modifications? Stephane originally submitted a complete modified emf.trm instead of a diff, IIRC, but that shouldn't stop us from merging that and the current emf.trm selectively. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-06-21 14:07:17
|
On Wed, 16 Jun 2004, Hans-Bernhard Broeker wrote: > *) If we move towards ANSI-C function definitions, I think that should be > done *before* we split off a 4.0 branch, to reduce "patch distance" > between the two branches. I'm in favour of doing that, with a tag 4.0.1 > before we start it, and another tag (4.0.2) right afterwards. 4.0.2 would > become the branch-off point for the 4.0-release branch. I've pretty much completed this monstrous editing job over the weekend. Nothing in CVS yet, but it can now be pulled off at a moment's notice. > *) K&R incompatibilities. Mainly the use of 'char' in some function's > parameter lists, most prominently in the terminal API. I went ahead and did that in the above-mentioned copy of the sources for the term->enhanced_writec() entry. Other instances of this will only be found by applying a genuine K&R compiler or lint. The yrange flip is next. The new bug with clipping of both pm3d and contours in a 'set dgrid3d ; set view map' situation is about equally bad, IMHO. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-06-21 21:58:34
|
On Monday 21 June 2004 07:07 am, Hans-Bernhard Broeker wrote: > > *) If we move towards ANSI-C function definitions, I think that should > > be done *before* we split off a 4.0 branch, to reduce "patch distance" > > between the two branches. I'm in favour of doing that, with a tag > > 4.0.1 before we start it, and another tag (4.0.2) right afterwards. > > 4.0.2 would become the branch-off point for the 4.0-release branch. > > I've pretty much completed this monstrous editing job over the weekend. > Nothing in CVS yet, but it can now be pulled off at a moment's notice. Did you do this manually, or were you able to automate the procedure somehow? I ask with some trepidation since it seems likely that applying this to the cvs tree will break every patchset on SourceForge including a couple of large ones that I have been maintaining. That's not an argument against doing it, but I wonder if there is a way to apply your ANSIfication to both a patched and unpatched CVS tree in parallel so that I can regenerate the patchset to apply against the ANSIfied version. -- 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-21 23:29:33
|
Ethan Merritt wrote: >On Monday 21 June 2004 07:07 am, Hans-Bernhard Broeker wrote: > > >>I've pretty much completed this monstrous editing job over the weekend. >>Nothing in CVS yet, but it can now be pulled off at a moment's notice. >> >> > >Did you do this manually, or were you able to automate the procedure >somehow? I ask with some trepidation since it seems likely that applying >this to the cvs tree will break every patchset on SourceForge including a >couple of large ones that I have been maintaining. > >That's not an argument against doing it, but I wonder if there is a way >to apply your ANSIfication to both a patched and unpatched CVS tree >in parallel so that I can regenerate the patchset to apply against the >ANSIfied version. > That would be nice. Dan |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-06-22 01:42:39
|
On Mon, 21 Jun 2004, Ethan Merritt wrote: > Did you do this manually, or were you able to automate the procedure > somehow? Some automation was possible. I essentially did an emacs 'tags-query-replace' operation to cover entire source directories, and a rather tricky egrep search to spot things still left to do (search for a function definition that has only one word before the first comma or closing parenthesis of the parameter list). I expect to have to use more tools to hunt the K&R definitions missed by egrep; like gcc in ultra-picky mode, or maybe splint. > I ask with some trepidation since it seems likely that applying > this to the cvs tree will break every patchset on SourceForge including a > couple of large ones that I have been maintaining. As long as they leave the function definitions alone, most patchsets should either be fine, or the conflict resolutions obvious. > That's not an argument against doing it, but I wonder if there is a way > to apply your ANSIfication to both a patched and unpatched CVS tree > in parallel so that I can regenerate the patchset to apply against the > ANSIfied version. Not really. The method is O(N) in the number of function definitions, which means using it on two source trees would take twice as long, and the majority of that would be wasted duplicate effort. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
×
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