From: <ke...@cr...> - 2004-03-30 23:44:20
|
xt...@de... said: > I don't have a vote on TIPs, but speaking as the official Tcl/Tk > maintainer for one of the most popular Linux distributions (Debian), > I'd be sorely tempted to rip out any tcl-specific code in this area > and replace it with simpler and more consistent (with the rest of the > system) C code. Uhm, right. Sort of. Everything you say is true. With some caveats upon which the whole idea may stand or fall. (1) The Olson codes, which include the 'gmtime' and 'localtime' variants that use /usr/share/zoneinfo, still have the Y2038 bug. It would be nice if Tcl could fix that before C does. We haven't very many more years before it really starts hitting the banking industry; there are a lot of 30-year bonds and 30-year mortgages out there. (2) Windows does NOT have any analogue to /usr/share/zoneinfo, and in fact cannot deal gracefully with changes to the rules for Daylight Saving Time. It gets DST wrong, for instance, for all US times prior to 1985. Its standard C library is also fraught with bugs, which is why Tcl doesn't even use the system's 'strftime' call on Windows. (3) If we depend on the C library functions 'localtime' and 'gmtime', then we have access to only two time zones: UTC plus some "local time zone" that's determined by tzset. One thing that started me down this road was that I have a server application that wants to format times in the client's time zone. Changing the time zone in the C library gets very tricky; you have to change the TZ environment variable, call tzset, call localtime, and then put TZ back. In a multithreaded process, you also have to arrange mutual exclusion around all of this - and often around all accesses to the environment. While possible, this gets very ugly very fast - and leads to some fragile code. I really don't want to go there if I can possibly avoid it. One of the beauties of Tcl is how seldom I have to worry about thread safety, even in a multithreaded process. (4) The maintenance of Tcl's time zone definition files is easier than you might imagine, owing to the fact that they're built from the same source distribution as /usr/lib/zoneinfo. It's really just a matter of downloading a fresh set of tzdata from elsie.nci.nih.gov and doing 'make tzdata'. Also, the plan would be to package the files in a zip filesystem, which packs them down to 370 kbytes or so. It's still fat, I know, but what can you do? (5) If even 370kb is unacceptable, I have already written code that reads the /usr/share/zoneinfo files directly, with the caveat that the [clock] command will get DST wrong after Y2038 (it'll still work otherwise). I'm willing to do a special case for Linux [Linux specifically] so that a distribution that omits the Tcl time zone data can still use the system data. The code needs to be Linux-specific, because even the majority of Unix systems that do use the Olson codes have all sorts of different places for keeping the data. The paths have differed even on different *releases* of Solaris, causing no end of fun for statically linked binaries. Can we compromise here? -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA |
From: Larry W. V. <lv...@ca...> - 2004-03-31 11:00:13
|
From: ke...@cr... (Kevin Kenny) > We > haven't very many more years before it really starts hitting > the banking industry; there are a lot of 30-year bonds and > 30-year mortgages out there. And anyone 21 or younger, who wants to do financial planning for retirement, is already hitting the problem. > The code needs > to be Linux-specific, because even the majority of Unix systems > that do use the Olson codes have all sorts of different places > for keeping the data. The paths have differed even on different > *releases* of Solaris, causing no end of fun for statically > linked binaries. Maybe I am missing someting obvious here - can't we also provide a configure flag for someone to specify , if they so desire, that tcl should use the files at /my/timezone/path rather than built in files? In theory, configure could even check the files for the common problems and let the person know that there are problems... -- Tcl - The glue of a new generation. <URL: http://wiki.tcl.tk/ > Larry W. Virden <mailto:lv...@ca...> <URL: http://www.purl.org/NET/lvirden/> Even if explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. -><- |
From: <ke...@cr...> - 2004-03-31 16:18:08
|
lv...@ca... said: > Maybe I am missing someting obvious here - can't we also provide a > configure flag for someone to specify , if they so desire, that tcl > should use the files at /my/timezone/path rather than built in files That's certainly viable if you're building from source. It's a bit more problematic for the keepers of binary distributions. If we go with a Linux configuration that uses the Olson files, it's trivial to add such a flag to the configurator, and I'd presume that's what we'd do. lv...@ca... said: > In theory, configure could even check the files for the common > problems and let the person know that there are problems... Of course, and even adapt the code around the problems. Nevertheless, there's a point where that approach becomes more complicated than simply providing our own implementation across the board. [clock] is awfully close to that point. I'm willing to use the Olson files if they're present, because they have a well-understood and stable format. The C library routines - particularly strptime - are more troublesome; as far as I can tell, they're *all* buggy in different ways. Let's at least have our *own* bugs - and our own test suite to scrub them out. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA |
From: Daniel A. S. <st...@ic...> - 2004-04-01 02:52:23
|
On Thursday, Apr 1, 2004, at 02:16 Australia/Sydney, Kevin Kenny wrote: > lv...@ca... said: >> Maybe I am missing someting obvious here - can't we also provide a >> configure flag for someone to specify , if they so desire, that tcl >> should use the files at /my/timezone/path rather than built in files > > That's certainly viable if you're building from source. It's > a bit more problematic for the keepers of binary distributions. > If we go with a Linux configuration that uses the Olson files, > it's trivial to add such a flag to the configurator, and I'd > presume that's what we'd do. FWIW, Mac OS X has /usr/share/zoneinfo, and I suspect other *BSDs do as well. There is nothing Linux specific here Cheers, Daniel -- ** Daniel A. Steffen ** "And now for something completely ** Dept. of Mathematics ** different" Monty Python ** Macquarie University ** <mailto:st...@ma...> ** NSW 2109 Australia ** <http://www.maths.mq.edu.au/~steffen/> |
From: <ke...@cr...> - 2005-07-22 14:31:23
|
lv...@ca... said: > In a language who's only data structure is a tcl list, it really seems > peculiar to have a function which requires one to convert the list > into a string to use it. I mean, no one's going to code the above > uses of min or max, instead they are more likely going to have to code > things like: > set a [join [split [read ans]] ","] > expr {min($a)} Larry, you've made the same mistake as Reinhard. TIP #232 is Final. With the changes that it made, Tcl math functions are now also commands. You can extract the minimum of a list with: namespace import ::tcl::math::min set min [min {expand}$list] (You don't have to import [min] into the current namespace, of course, but I think that's a bit nicer.) -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA |
From: <ke...@cr...> - 2005-08-03 15:24:02
|
lv...@ca... said: > I have found the tying of the release numbers to be a rather freeing > thing. Before it was done, I remember confusions among people about > what versions of Tk worked with what versions of Tcl. And in fact, I > see that same confusion when people are looking for the 'right' > version of TclX, because its version numbers are similar to Tcl's, but > don't keep in step. Ah, Larry, you are remembering the days before Stubs. The problem was not that the version numbers weren't synhronized; the problem was that Tk was far too intimate with Tcl, so that you couldn't mix and match versions and have them work. With the divorcing of the version numbers, we're also looking at confining Tk to public API's so that it will be cross-version compatible. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA |
From: <ke...@cr...> - 2005-09-13 13:27:09
|
lv...@ca... said: > I disagree that the _only benefit_ is printing. The studies I've read > (and I don't have any references handy right now; I apologive for > that) indicate that it grows increasingly difficult to keep the > functionality in mind after the code grows past 20-40 lines of actual > code, leading to more errors because the programmer begins to forget > all that was going on in the code elsewhere in the function as s/he > moves through the code. > I've seen that to be true, with the general programmer with whom I've > worked. I've seen a few exceptional people that are exceptions to > that case - but style guidelines should shoot for the average, rather > than the particularly talented. As always, the answer here is, "yes and no." Certainly there are functions in Tcl that would benefit from refactoring into smaller bits. But there are also places (big 'switch' statements come to mind) that simply are irreducible - where further breakdown introduces complexity, rather than alleviating it. Moreover, there are a few places in Tcl (TclExecuteByteCode is the infamous example) that are so difficult, either because of performance constraints or because of inherent difficulty of the task (regular expression recognition, anyone?) where we simply have to hope that we will always have a supply of talented maintainers. Trying to dumb these down to 'code monkey' level is ill-advised. Fortunately, this is Tcl, and in the fifteen years that Tcl has been in existence, it has consistently attracted enough talented programmers to keep those areas afloat. Perhaps I've seen too much bureaucracy together with coding style guidelines. If we remember that the style *guidelines* are just that, guidelines, we'll be fine. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA |
From: <ke...@cr...> - 2006-09-18 14:30:59
|
lv...@ca... said: > Currently there is a special compile time flag for the tcl core that > permits it to be build supporting UCS-4. > Is this considered a feature that is a standard part of tcl, or > something that is to be considered experimental? Definitely experimental. If I recall correctly, Red Hat tried turning it on (without adequate testing) and released a badly broken Tcl build. Right now, UCS-4 is not all that widely supported - although I concede that we do want to stay 'ahead of the power curve'. I don't think that it actually makes all that much sense as an internal rep for Unicode strings, because it's rather a memory hog, and characters outside the BMP today are rare even in situations where they are expected; for instance, in Han Zi, they are used only in ancient texts and to write some uncommon family names. With cloudy foresight, I think that as we explore the world outside the BMP, we'll switch to a "unicode" internal rep that consists of some sort of index enabling fast lookup of bytes in the UTF-8 stream by character index. An alternative would be to keep UTF-16 (with surrogate pairs) *and* an index if non-BMP chars are present. We most definitely need UTF-32 as an external representation; actually we need 'utf32be' and 'utf32le' because, like UTF-16, it comes in big-endian and little-endian versions. (And it wouldn't surprise me if some vendor hasn't come up with a byte-scrambled version like the old VAX 'nUxi' byte sequence, Recently, we had to deal with a handheld computer that did that with floating point.) Actually making a UCS-4-enabled build *work* might be a very good start toward this plan. I haven't tried, and won't have time to in at least the next few weeks. Maybe we can talk about this in Naperville? By the way, do you have a clear use case? Most demands (I won't call them 'requests'!) that I've heard regarding non-BMP Unicode so far have been from Unicode purists of the same stripe that protest that Tcl is "noncompliant" because of our use of C0 80 for the null byte internally. (Sorry, what we do with out own memory is no business of theirs!) I'd feel more comfortable with implementing all this if I understood prospective usage patterns. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B35A Schenectady, New York 12301-0008 USA |