Re: [AOLSERVER] TclX keyed list changes in HEAD
On Tuesday 22 June 2004 18:24, you wrote: Zoran implemented some recent changes to TclX keyed lists in CVS HEAD which changed the C API, which broke at least some code at AOL which was still using the old C API. Ah, the C-API you're talking about! Well, this is right. This has changed. I see no problem in addint the compat layer on top of that. Zoran -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] TclX keyed list changes in HEAD
On Tuesday 22 June 2004 18:24, you wrote: Zoran implemented some recent changes to TclX keyed lists in CVS HEAD which changed the C API, which broke at least some code at AOL which was still using the old C API. ??? There are no Tcl-level changes to keyed list commands. Rather than a wholesale back-out of the changes, I'd like to discuss two things: 1) Should changes that break backwards compatibility be allowed between minor revisions (i.e., 4.0 - 4.1) or should they be limited to major releases only (i.e., 4.x - 5.x). Simple. They are not allowed. It has to be backward compatible. But, what are the changes between string and object-based keyed-list commands? Can you please be more descriptive? 2) Can we quickly implement some backwards compatibility for the TclX keyed list C API so that existing C code won't need to be modified/updated to use Zoran's new C API? What's the best way to do this? Can it be done through #define's? Or thin wrapper C procs that call the new C procs? Or, can we simply rename Zoran's new C procs to the old names to preserve compatibility? Again, I see no problems to make any backward-compat changes. I would like to see the problems first. The TclX keyed-list commands are those found in TclX package already. Zoran -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] TclX keyed list changes in HEAD
Zoran, I am just curious what you have done. Did you update the AS code to match what is at tclx.sf.net? Or is this just something you did? I believe you converted to the Tcl objects, but wasn't sure if you took it from SF or did it on your own. thanks, --brett --- Zoran Vasiljevic [EMAIL PROTECTED] wrote: On Tuesday 22 June 2004 18:24, you wrote: Zoran implemented some recent changes to TclX keyed lists in CVS HEAD which changed the C API, which broke at least some code at AOL which was still using the old C API. Ah, the C-API you're talking about! Well, this is right. This has changed. I see no problem in addint the compat layer on top of that. Zoran -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] TclX keyed list changes in HEAD
On Tuesday 22 June 2004 18:33, you wrote: On Tuesday 22 June 2004 18:24, you wrote: Zoran implemented some recent changes to TclX keyed lists in CVS HEAD which changed the C API, which broke at least some code at AOL which was still using the old C API. Ah, the C-API you're talking about! Well, this is right. This has changed. I see no problem in addint the compat layer on top of that. The new TclX commands expored are: TclX_KeylgetObjCmd TclX_KeylsetObjCmd TclX_KeyldelObjCmd TclX_KeylkeysObjCmd Equivalents of those are found in older string-based api. There is no problem in quick simple compat layer for those. The old string-based api allows additionaly for: Tcl_DeleteKeyedListField Tcl_SetKeyedListField Tcl_GetKeyedListField Tcl_GetKeyedListKeys Do you need those abstraced as well? Sorry for breaking the compat, I should have asked first if anybody uses the C-API before applying the change and should have written the compat layer as well at the same time. Zoran -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] TclX keyed list changes in HEAD
On Tuesday 22 June 2004 18:48, you wrote: Zoran, I am just curious what you have done. Did you update the AS code to match what is at tclx.sf.net? Or is this just something you did? I believe you converted to the Tcl objects, but wasn't sure if you took it from SF or did it on your own. It is the code from TclX package. I just made it work for AS. Zoran -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] TclX keyed list changes in HEAD
Hi - here are my thoughts on compatibility: Breaking compatibility at the TCL level is worse than breaking it at the C level. If someone wants to write a new, incompatible version of ns_return for example, it should be called something else and a compatibility wrapper written for ns_return that calls the new thing. In the best case, TCL compatibility should NEVER be broken. If we end up with a huge compatbility library, perhaps all written in TCL, that's much preferable to telling people to change their code. Breaking compatibility at the C level is more acceptable to me, because my guess is that very few people are using it. We have a small handful of C modules, so yeah, we may have to change them if the C API changes, but it would not be a big deal. Even if incompatible changes are allowed at major versions, what may very well happen is that it fractures the community and leaves some people running old versions longer than they want. We're in this situation now because of ns_shares: someone decided it was inconvenient to provide ns_share because of TCL core modifications, which I totally understand. But, we have a code base with over 800 ns_share statements, and probably 5x that many variable references. It will be a cold day in Hell before we rewrite all our code to use nsv arrays, just because someone decided that ns_shares are inconvenient to support. If ns_share ever goes away completely, we won't be upgrading, no matter how great a new version is. The other paradox with good, reliable software is that people don't have as much of a pressing need to upgrade it. So while a development group is releasing version after version of a product, and may have even released several production versions, there will be many customers that have not even tried the new version. Eventually, there will be a pressing need that forces the customer to consider upgrading. The Linux OS is an example of this, for us. We didn't upgrade to 2.4 until November of 2003, even though 2.4 had been released for a long time, because 2.2 was working fine for our needs. The 2 things that forced us to upgrade were that we needed to access more main memory, and our storage requirements increased to the point that we couldn't afford to do fsck's and needed a journaling file system. My point is, production customers may be running old versions much longer than developers think. If a customer has been happily running 3.4 AS for a few years and a compelling reason comes along for them to upgrade, and the current version of AS is 6.5, they don't want to run into a big incompatibility hurdle. If they run into too big of a hurdle, they will likely start considering all options, including moving to a different platform that they perceive is more stable from a compatibility point of view. Jim Zoran implemented some recent changes to TclX keyed lists in CVS HEAD which changed the C API, which broke at least some code at AOL which was still using the old C API. Rather than a wholesale back-out of the changes, I'd like to discuss two things: 1) Should changes that break backwards compatibility be allowed between minor revisions (i.e., 4.0 - 4.1) or should they be limited to major releases only (i.e., 4.x - 5.x). 2) Can we quickly implement some backwards compatibility for the TclX keyed list C API so that existing C code won't need to be modified/updated to use Zoran's new C API? What's the best way to do this? Can it be done through #define's? Or thin wrapper C procs that call the new C procs? Or, can we simply rename Zoran's new C procs to the old names to preserve compatibility? -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] TclX keyed list changes in HEAD
On Tuesday 22 June 2004 18:24, you wrote: Zoran implemented some recent changes to TclX keyed lists in CVS HEAD which changed the C API, which broke at least some code at AOL which was still using the old C API. Rather than a wholesale back-out of the changes, I'd like to discuss two A wholesale back-out of the changes seems like a very desperate step, hm? Since the CVS head is the development branch, changes to it should be allowed. Or not? Besides, head should not be used for any productive environment, AFAIK. If the checkin policy on head should be that rigorous, then we'll advance very, very slowly, which is bad, isn't it? As far as this particular issue is concerned, I did this purely for the benefit of other folks. Somebody has to take care, ok? Anyways, the compatibilty layer for following old calls has been done: Tcl_GetKeyedListKeys Tcl_GetKeyedListField Tcl_SetKeyedListField Tcl_DeleteKeyedListField I *did not* wrap the: Tcl_KeylgetCmd Tcl_KeyldelCmd Tcl_KeylkeysCmd Tcl_KeylsetCmd since those are only Tcl-API interfaces. I doubt that anybody would seriously use them. If I'm mistaken, please tell me and I will add those as well... Now, checkout the head and recompile. If there are *any* problems, please feel free to contact me directly ([EMAIL PROTECTED]) so we do not saturate the list. I do not think this is the right place to discuss such issues. For that, there is SF bug tracker. Zoran -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] TclX keyed list changes in HEAD
On Tue, Jun 22, 2004 at 10:04:14AM -0700, Jim Wilcoxson wrote: Even if incompatible changes are allowed at major versions, what may very well happen is that it fractures the community and leaves some people running old versions longer than they want. We're in this This has happened extensively with AOLserver in the past, but I think primarily NOT because of broken backwards compatibility, but because there was no attempt at all, sometimes for years at a time, to integrate fixes and patches into the master CVS sources in anything even resembling a timely and reliable fashion. Fortunately, that situation seems to have much improved already, and hopefully will continue to do so. If a customer has been happily running 3.4 AS for a few years and a compelling reason comes along for them to upgrade, and the current version of AS is 6.5, they don't want to run into a big incompatibility hurdle. If they run into too big of Frankly, there isn't much the AOLserver developers - or ANY external developers - can do about that. As a customer, part of the operatins and maintenance cost of ANY piece of software is upgrading every year or so to the latest and greatest version. If you ignore that maintenance for, say, 5 years running, when you finally do decide to upgrade, no surprise, you are going to have a LOT more work to do, all at once, then if you'd tracked development more closely upgrading a year at time. You'll also have completely abdicated any feedback or input into the software for those 5 years of development, which may further increase your upgrade effort. Make no mistake, CHOOSING to ignore newer versions of software because what we're using now is good enough (and I myself have sometimes done so) is a serious operations decision, with both rewards AND risks. And it is fundamentally the customer's responsibility to properly evaluate that decision - no external group of developers can do it for you, nor should they. What developers CAN do, is communicate as clearly, frequently, and consistently as possible where they're currently planning to take the code, when, and why, and be as receptive as possible to fixes and modifications that come from the larger user community. So e.g., ideally, if the AOLserver team finally drive stake through the heart of whatever deprecated legacy support still exists in the core for ns_share say for AOLsrever 5.0, or for 4.2, they'd let you know that well ahead of time, consider ways to provide an ns_share backwards compatibility module and help the (probably very small minority of) users who want that to maintain it, etc. -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.