From: Donal K. F. <don...@ma...> - 2006-11-11 23:19:38
|
Robert Hicks wrote: > I am sorry, I didn't mean what I said to be taken that way. The way you > stated you had to do it in Tcl because of time constraints I was just > saying "no big deal" because if it needed to be fast at some point it > "could" be re-implemented in "C". I, by no means, meant that none of it > could be in Tcl. That would be silly for the reason you state. The position is this: Certain key parts of [clock] are in C (being the parts that manipulate the low-level OS API, or that have been determined to be serious bottlenecks) but everything else is in Tcl. This is good for several reasons, #1 of which is really that it is string processing and doing string processing in C is *really* tedious. :-) Given that most of [clock] is string processing and we've got some nice string handling utilities (called the Tcl language) to hand, seems silly to not use it. :-) We can always move more bits to C if necessary. No rush to do it without evidence of a real problem though. :-) Donal. |