4 ms·
I happen to know of tens of thousands of running instances, and I'm sure many HNers will interact with one today. Can't say more ;-) Aolserver is reliable and
by dkarl 16y ago
I happen to know of tens of thousands of running instances, and I'm sure many HNers will interact with one today. Can't say more ;-)
Aolserver is reliable and efficient. Tcl is reasonably efficient for most purposes (which is to say, dog slow but who cares?) though we drop down to C++ in many cases where Tcl might not be fast enough.
Tcl is a powerful but strange language. The heavy dependence on strings in its implementation is problematic, to say the least. An object of a particular type may be converted to a string representation, deleted in its original form, and then resurrected from the string representation later. That's not exotic functionality; it's normal in ordinary usage of the language, and it would invalidate the use of Tcl's reference counting for resource management. Therefore, when you define a new type that manages a resource (a resource such as a "future" object returned from C++ land, when you're waiting for an asynchronous operation to complete) you have to be sure NOT to implement working object->string and string->object conversion methods on that type. You have to implement those methods to signal an error to ensure that the object is never stored as a string and then resurrected later.
That's all fine and dandy, but that means you can't store objects of that type in a list, because a Tcl list is a string built from the string representations of its members. In case you were wondering how an object might be converted to a string, deleted, and then resurrected later from its string form, that's exactly what happens when you add an object to a list, dereference the original instance, and then retrieve that item from the list. Truly weird.
- jrockway 16y agoSounds odd, but of course, strings are all computers store anyway; your address space is a big string (with holes, perhaps) from 0x00000000 to 0xffffffff, and that's where everything is. (And yes, if you have a 48-bit or 64-bit address space, the string is longer.) So what's strange is not the representation but how it's not hidden from the programmer.
- chwahoo 16y agoOne big string? My computer just stores one huge number :)
- msofer 16y agoSpeaking with some knowledge of the inner workings of Tcl, I can assert that your description is not correct in recent Tcl: you must be doing something more to that object, or misinterpreting what is happening. I suggest creating a bug ticket at Tcl's SF site with a description of the problem and sample code.
- dkarl 16y agoIt wasn't recent work so likely not recent Tcl, but are you saying that Tcl no longer represents lists as strings? I'm surprised such deep changes are still being made in an old language.
- msofer 16y ago:) If you are using Tcl7 (Tcl8 is 10+ years old) or the OLD string interfaces on Tcl8, things go through the string rep and will be dog slow - your fault. Tcl's lists, for instance, are maintained internally as C arrays of pointers to the element objects. The roundtrip through the string rep can happen, but only if YOU treat the list as a string (more generally, as a non-list). As to "deep changes to an old language": Tcl is actively maintained and still evolving. Tcl8.5 introduced anonymous functions among many other changes; Tcl8.6 (in beta) has a completely new engine (somewhat similar to py's stackless), coroutines and tailcalls, a builtin OO system, and many other enhancements.
- dkarl 16y agoThe roundtrip through the string rep can happen, but only if YOU treat the list as a string (more generally, as a non-list). That's a hell of a thing to have to document, so I think it was appropriate to have the string conversion functions raise an error. When I worked on it, the code was running in Tcl 8.3 or 8.4, and I was able to reproduce the round trip through the string reliably with exactly the operations I described. I may have printed the list to the console as part of the test, and if that qualifies as "treating the list as a non-list" it pretty well proves the need to assume the worst. (It's also possible I was using older interfaces, even 10+ year old interfaces, since I kept my code consistent with the existing style in our software, but it's pretty harsh to say "your fault" if the interfaces for the most basic type in the language changed between versions 7 and 8, just saying.)