|
From: Ethan A M. <merritt@u.washington.edu> - 2007-07-02 16:25:05
|
On Monday 02 July 2007 02:45, Daniel J Sebald wrote: > > Yes, a month ago I said I'll be making changes in my life so I was trying= =20 > to give developers an opportunity to integrate any patches I had remainin= g=20 > on sourceforge so I could address any concerns. Patches that fix current= bugs. =20 > Ones I'd been asked to "pick a bug and fix it". Etc. Over the course of= =20 > a month did any of them get consideration? No. =20 > When someone volunteers their time, should make good use of it. =20 Dan, I have myself put 4 of your patches into CVS over the past three weeks, according to the ChangeLog. Thimoth=E9e and Petr were going over your hidden3d and helpfile patches. Your effort and contributions are appreciated. But some of these are large patches, and touch pieces of the code that were already messy to begin with. It's not trivial to review and understand these. It is for example much easier to evaluate a self-contained body of new cleanly-written code than it is to=20 evaluate the effects of adding complex bandaids to old crufty code. That's why new drivers can be adopted fairly rapidly, while re-working the multiplexed terminal input code paths has been an recurring thorn in our side for years. > And why ask for a review of your patch if you aren't willing to hash out= =20 > any concerns, like the splines problem and the un-resampled FUNC data? I already thanked you for pointing out the function resampling issue. As to splines - I still have not spotted where in the code this would be a problem, and I haven't noticed any problems in practice using the demo files (e.g. mgr.dem). Could I ask you one more time to point to specific code lines or a demo script that shows a problem with splines or=20 smoothing? > You are rushing your patch toward CVS whereas with other patches=20 > you've been measured and cautious. =20 Heh. I'm not the one who is rushing it. I'd just as soon let it sit on SourceForge to accummulate feedback, as is my usual wont. It's the release of an incompatible Octave version that is fueling the urgency. > > the comment at the top says that it does away with the df_eof > > mechanism. But it doesn't. Have you really tested this? > Sure, df_eof is simply a global variable. That information is already=20 > passed back by df_readline(). Don't need the extraneous global. Sadly, this is not true. Getting rid of df_eof has been on my personal TODO list for quite a while. I've tried to remove it before and learned that it gets messy. The routines in datafile.c use it as an OOB channel for passing error conditions back to the calling routines. I'm sure a cleaner mechanism without the global variable is possible, but it's not as simple as just deleting it. > The thing is, I don't think strings will work with the method you are=20 > proposing without additional code. The x,y,z values of the labels are=20 > gotten in get_data() .... >=20 > But your patch is circumventing get_data(). So how is it that the=20 > values in the strings will have their x,y,z updated when the axis=20 > scale is modified? ??? I don't intend that their x,y,z values ever be updated. The point of "refresh" is to *not* update the values. I am suggesting that we implement axis scaling as an extra step in coordinate mapping. Input coordinates will always remain untouched. I thought we were in 100% agreement on that point. The transformation will be done later, at the time a plot coordinate is converted to a screen coordinate. No doubt this will turn up some wrinkles (e.g. layout of tic positions), but it will do away with the current complexities at the input stage. > > - It doesn't actually provide any advantage over the current > > "refresh" patch other than toggling the log scale. If I'm > > wrong about that, please provide a test script so that I can > > understand the difference. =20 >=20 > The splines smoothing/curve fitting. E(L(X)) may equal X, i.e.,=20 > reversible axis transform. But E(S(L(X)) !=3D S(E(L(X))) =3D S(X).=20 Give me an actual test script showing a problem, please. =2D-=20 Ethan A Merritt |