Hi Alan,


> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, August 29, 2017 6:00 AM
> To: Arjen Markus; PLplot development list
> Subject: Is it time to remove our old fortran and our old Tcl bindings and 
> examples?
>
> Hi Arjen:
>
> This e-mail concerns cruft removal for both the Fortran and Tcl cases.
>
> Fortran:
>
> We introduced the new Fortran binding and corresponding examples as of
> PLplot-5.12.0 (released on 2017-01-29), but as a safety measure supplied the 
> old
> Fortran binding and examples if the user specified the CMake option -
> DPL_DEPRECATED_fortran=ON (which gave access to bindings/old_fortran and
> examples/old_fortran).
>
> Since that release I think we have gotten not even one complaint about the new
> fortran binding which introduced many backwards incompatible changes.  (There
> was one complaint about lack of Fortran support in CMake for a non-mainstream
> Fortran compiler, but that is a different issue that affects both our old and 
> new
> fortran binding for that one user.) Furthermore, the next release is likely 
> coming out
> in early 2018 or roughly one year later than PLplot-5.12.0.
> Therefore, I believe this release cycle is the right time to get rid of the 
> cruft
> consisting of the -DPL_DEPRECATED_fortran=ON option and bindings/old_fortran
> and examples/old_fortran.
>
> If you agree with this timing, and assuming nobody on the plplot-general list 
> objects
> (i.e., there is nobody there who is still actually using the old fortran 
> binding), then I
> would plan to remove this cruft within a few days from now (just to make this
> change early in the release cycle so it gets maximum testing before the 
> release in
> early 2018).

I agree - keeping the old stuff around (especially with the extra logic 
required for its support) is an unnecessary complication.

>
> Tcl:
>
> There is a similar story with the redacted Tcl API introduced in 
> PLplot-5.12.0.
> There have been no complaints about that large backwards incompatible change,
> and the next release will be roughly a year away from the release where this
> change was introduced.
> Therefore, I believe this release cycle is the right time to get rid of the 
> cruft
> consisting of the -DUSE_NON_REDACTED_TCL_TK=ON option and the
> corresponding bindings/non_redacted_tcl, bindings/non_redacted_tk,
> bindings/non_redacted_tk-x-plat, examples/examples/non_redacted_tcl,
> and examples/non_redacted_tk.
>
> If you agree with this timing, and assuming nobody on the plplot-general list 
> objects
> (i.e., nobody there is using the -DUSE_NON_REDACTED_TCL_TK=ON option),
> then I would plan to remove this cruft within a few days from now just as in 
> the
> fortran cruft removal case and for similar reasons.
>
Here the same remark holds.

> General remarks about this cruft removal:
>
> I am pushing this cruft removal because keeping those old files around 
> implies we
> should sometimes test the -DPL_DEPRECATED_fortran=ON and -
> DUSE_NON_REDACTED_TCL_TK=ON options (which I don't want to do) and also
> do minimal maintenance to the old versions of the files (which I also don't 
> want to
> do).  For example, I am about to remove the long-deprecated plrgb, plrgb1, 
> plhls,
> and plwid.  But some of those are assumed to be available (when -
> DPL_DEPRECATED=ON) in the old versions of the Fortran and Tcl bindings.
> Which implies I need to either maintain those old versions consistent with the
> removal of plrgb, plrgb1, plhls, and plwid or do the much simpler task of 
> deleting
> those old versions.
>
I see that some of the source files for Tcl/Tk contain these macros. These can 
be simplified as well then.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to