From: SourceForge.net <no...@so...> - 2012-08-29 11:38:11
|
Bugs item #3562640, was opened at 2012-08-28 23:28 Message generated for change (Comment added) made by nijtmans You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3562640&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 80. Thread Package Group: development: 8.6b2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Nijtmans (nijtmans) Assigned to: Jan Nijtmans (nijtmans) Summary: problem loading Thread in 8.5, when compiled for 8.6 Initial Comment: (Reported on Tcl because Thread is not the only package suffering from this) In Tcl 8.6, (interp)->errorLine became deprecated. In order to prevent the deprecation warning, extensions should do something like: #if (TCL_MAJOR_VERSION == 8) && (TCL_MINOR_VERSION < 6) #define ERRORLINE(interp) ((interp)->errorLine) #else #define ERRORLINE(interp) (Tcl_GetErrorLine(interp)) #endif The problem with this is that when Thread is compiled using Tcl 8.6 but run on Tcl 8.5, the Tcl_GetErrorLine call will crash because Tcl 8.5 does not have it. ---------------------------------------------------------------------- >Comment By: Jan Nijtmans (nijtmans) Date: 2012-08-29 04:38 Message: > it really needs to do the correct [package requires] as well. That's why it has a: if {[package vsatisfies [package provide Tcl] 8.5] && [::tcl::pkgconfig get threaded]} { because that's the miminum supported version, even if compiled against 8.6 headers. > Hacking the API function into 8.5's private space isn't a good solution > because it still won't be in the existing releases of 8.5 Agreed, but its better than doing nothing. > However, it generates a warning when building against 8.6 to > remind the developer that the field will go away in the future Well, if the developer used: #if (TCL_MAJOR_VERSION == 8) && (TCL_MINOR_VERSION < 6) #define ERRORLINE(interp) ((interp)->errorLine) #else #define ERRORLINE(interp) (Tcl_GetErrorLine(interp)) #endif Then why does it still need to being reminded? He already did what he should do. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2012-08-29 03:58 Message: BTW, if the thread code is doing something like the construction in the initial message, it really needs to do the correct [package requires] as well. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2012-08-29 03:55 Message: If an 8.6-specific API is used (such as Tcl_GetErrorLine) then it requires that you have done a [package require Tcl 8.6] (or C equivalent) beforehand. If only the API functions used are 8.5 ones, there's a sporting chance that build with 8.6 and load into 8.5 could work, but it is a Formally Unsupported configuration. Hacking the API function into 8.5's private space isn't a good solution because it still won't be in the existing releases of 8.5. (You can't control what exact versions people use, you just can't. I wish we could get people off 8.0 for example...) For the errorline code (and equivalently the interpreter result) there's a migration strategy: define the correct symbol when building. However, it generates a warning when building against 8.6 to remind the developer that the field will go away in the future. ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2012-08-29 03:34 Message: > And building against version 8.X and loading into 8.Y (where Y<X) has never > ever been a supported scenario. So, you are trying to say that Thread made a mistake, supporting to be compiled using 8.6 and runnung under 8.5? I don't think so! Tcl/Tk not supporting that is another story than Thread supporting that. There's code in Thread, related TIP #285 support (thread cancel). The only way to compile Thread with TIP #285 support is compiling it against 8.6 headers. If Thread is running on Tcl 8.5, a runtime-check makes sure that the TIP #285 support is disabled, so a single extension can handle both Tcl 8.5 and 8.6. I think that's well done, even though Tcl doesn't support that officially. Tk 8.6 should never be loadable in Tcl 8.5, I agree with that. But tcldde.dll and tclreg.dll work fine in Tcl 8.5, even when they are compiled against the 8.6 headers. So, we should provide something for Thread (and other extensions) one way or another. Your solution results in deprecation warnings when compiled against 8.6, which cannot be switched off. What I want is provide a way for extensions to upgrade their use of interp->errorLine, without being haunted with deprecation warnings and without causing crashes in difficult-to-debug situation. I gave two alternatives doing that. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2012-08-29 03:06 Message: Doesn't change a thing. The migration path is to first define USE_INTERP_ERRORLINE, which lets the code compile and work (but with a compile-time warning when building against 8.6). Once they tire of the warning, they can switch to the 8.6-specific API, but that *requires* that they also update what version of the API they depend on. And building against version 8.X and loading into 8.Y (where Y<X) has never ever been a supported scenario. ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2012-08-29 01:56 Message: Alternative fix (for Tcl 8.5) committed to branch "bug-3562640-alt". Either "bug-3562640" should be committed to 8.6, or "bug-3562640-alt" to 8.5, or Thread should be compiled with -DUSE_INTERP_ERRORLINE. Otherwise people who did nothing wrong will be confronted with unexplainable crashes, when they have Tcl 8.5 and 8.6 (with thread) together in the same environment. But I would hate to punish Thread for making the conversion to Tcl_GetErrorLine(). Other extensions doing that should be rewarded, not punished, and people using those extensions (who didn't do anything wrong) should not be confronted with unexplainable crashes. ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2012-08-29 01:31 Message: Or -- in other words: I don't want to punish people which convert their extension in using Tcl_GetErrorLine(), as thread did. People should be stimulated to do that! So if there is a way to prevent a crash, when someone installs Tcl 8.6 (including a thread compiled against 8.6) in an enviroment where Tcl 8.5 is installed already. And then someone does a "package require thread" from a 8.5-related Tcl application. Thats the tricky situation we are talking about, and I would like to make that work, without extension writers holding back to make the Tcl_GetErrorLine() conversion. One alternative solution (If I cannot convince you) is fill the Tcl 8.5 stub table with an internal Tcl_GetErrorLine. Then - at least starting with Tcl 8.5.13 - the described scenario will start to work. ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2012-08-29 01:21 Message: > I think that's totally and wholly wrong Somehow, I expected that reaction ;-) ... However, it's just what we want to support. > has *never* been supported, and is not expected to work at all Yes, it works, and everything in Thread is in place to support it except the use of Tcl_GetErrorLine(). A declaration warning on the use of "unused5" is not necessary: Anyone using it is playing dangerous anyway. The alternative is to let thread use -DUSE_INTERP_ERRORLINE, and just continue to use (interp)->errorline. But then the conversion must wait until Tcl 8.5 died. This way we can use my hack as a transition in Tcl 8.6, and remove it in Tcl 8.7: Tcl 8.5 will be dead (hopefully) when 8.7 comes out. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2012-08-29 01:09 Message: I think that's totally and wholly wrong. It's based on a wrong way of working and is wrongheaded in what it does. Wrong, wrong, wrong, wrong, wrong. Compiling against 8.6 and loading into 8.5 is wholly unsupported, has *never* been supported, and is not expected to work at all. That it crashes makes me happy because it prevents people from doing something wrong. Avoiding the deprecation warning by doing weird hacks is wrong; it's there precisely to warn people that their code is doing something that will cease to work. Code should either target 8.5 (defining USE_INTERP_ERRORLINE in case they're actually building against 8.6) or should use Tcl_GetErrorLine and explicitly declare a dependency on the 8.6 API in its [package require]. ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2012-08-28 23:31 Message: Proposed solution committed in branch bug-3562640. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3562640&group_id=10894 |