From: Pete B. <pe...@ak...> - 2011-07-15 10:31:06
|
On 2011.07.15 04:26, Michael Plante wrote: > I don't recall ever agreeing with the python guys. It's still "heresy" > (your word). Poor choice of example. It's not because you don't agree with how people analyse a problem that the problem doesn't exist, or that their analysis is wrong. The fact is, if we hadn't forced a CC on cygwin, which we didn't need to do since cygwin DLLs are only meant to be used by cywgin applications (they are labelled cyg####.dll to differentiate them from standard Windows DLLs, and cygwin is about as close as Linux as can be in that respect, in that, while it is of course possible, virtually nobody is expected to force a CC unless they really have to), and therefore use the default CC set by the cygwin compiler, we would have avoided that issue. So, *if* we had followed my advice on cygwin, the Python guys would *not* have had that issue. And, if you want to argue that we can't say we wouldn't have run into a different issue, had we left the CC unforced, please be aware that I have actually removed the forced cygwin's CC on my branch for months now (ever since the Python guys contacted us), and I'm still waiting for anybody to report a problem. So that's as good as evidence goes to prove my point as far as I'm concerned, regardless of whether you agree with that point or not. It isn't speculation. If "heresy" is what helps our users out there, I'm definitely gonna go with the heretics, because trying to help as many users as possible, rather than following dogma, is the religion I subscribe to. >>> My preference was for an #ifdef as well as an API change, to make sure >>> we bring it home. Another opinion was voiced to not go with the #ifdef, >>> and everybody else at the time said "either #ifdef or API change is >>> fine", > > Uh, no. Not true. Kustaa's proposal, as I understood it was "if()", not > "API change". But yes, the alternative was #ifdef. I don't recall anyone > besides you proposing API change. Maybe I missed someone? OK, then please follow me here. We were discussing a proposal to make the non portability of the detach_kernel() call more explicit. At this stage, nobody has come and said "I disagree" or "this is silly", so the implication is that there is some likelihood that people want this change in one way or another. So I propose a set of modifications, using *both* an ifdef and an API name change, with, after elaborating on the #ifdef part, and I quote: "And to further bring it home, I would suggest to add a _windows_ or _linux_ in the call prefix (or maybe an _np suffix as Graeme highlighted, as was done with 0.1)." So, there's the possibility that you read that part as "optionally, we could also do that", but I can tell you that, either/or wasn't the intended meaning. The intended meaning is: "I'd like to have both of these" Now, one person comes and says he doesn't like the #ifdef. At this stage, I still don't recall anybody saying that they see the API name change part, from my proposal, as a bad idea. Instead, people like yourself, who have apparently been following the discussion, chime in to write, and I quote again: "I can live with either Pete's or Kustaa's approach" Well, sorry, but since my approach (or at least how I expected people to interpret it) was for BOTH ifdef and API name change, I have to assume that you didn't see anything wrong with modifying the API name, and that neither did Xiaofan or anyone else did at this stage. You are of course free to change your mind later on, or clarify your actual intended meaning. But I hope that you will also understand that, when you write that you are OK with an approach, which, I stated, would also include an API name change, I have some ground to conclude that you are OK with both parts, even if this isn't what you meant to convey. At this stage then, since the #ifdef part of my proposed approach is in balance (50/50), and nobody is suggesting alternatives (such as adding comments around the call), I will of course conclude that API change is on the table as a viable option. > Invalid reasoning because of the above. The choice is if() vs #ifdef. Not > API change. See above. It seems we both read different meanings to some of the statements appearing on this thread, but I do hope you can agree there is some validity to my reasoning. > Or at least it wasn't originally; this seems to be a third > option, not necessarily mutually exclusive, but, IMO, a bad option anyway. That's fine. As I said, I don't have a problem with clarification being required or even changing your mind. But please don't indicate that I voluntarily misinterpreted a statement that, by all means, if the "approach" you were OK with didn't encompass the API change, was very much subject to confusion. > No, I meant you don't have to defend your choice to discuss it. I admit > that's probably so obvious (out of context, anyway) that you may not have > realized that's what I was saying. OK. Regards, /Pete |