Invisible wrote:
> Right. And now how do I figure out how big the system tray is? (You 
> realise it's resizable, right?)

I realize. I don't know the answer. Give it a try. :-)

> I find the documentation for Tcl/Tk to be especially difficult to 
> follow. For example, I *still* can't figure out the correct way to 
> specify a font name. The page that's meant to tell you just rambles on 
> about a bunch of C functions... WTF?

Fonts are a mess in every language. And it depends on the underlying 
screen driver. On Windows, you just give the font name and size.

set font1 {courier 8}
set font2 {courier 10 bold}
set font3 {"Lechter Normal" 10 bold}

> Right. So when the server runs out of disk space, my Tcl script 
> unceremoniously halts, and rather than the interpretter shutting down, 
> it just *sits* there.

Is that because you're not checking the return result from writing?

> And since it's a background task, I have *no way* 
> of discovering what the hell went wrong, and no way of shutting it down 
> other than forcably killing the interpretter. Cool. Is that what the 
> spec says?

Why would you not have a way of shutting it down. You have to *code* a 
way of shutting it down, sure. Or use tclsvc to make it a real windows 
service and then use all the normal windows service management stuff 
(e.g., "net start" and "net stop") to turn it on and off.

What's the code that runs out of disk space and hangs the interpreter? 
If it's a bug, I'll report it for you.

> Frobbing bgerror is just painful. catch looks more useful...

Both do the same basic job. Granted, by the time you get to bgerror, 
it's not going to be very easy to correct the problem, but at least you 
can log it, start over, look at globals to figure out what happened, 
write a stack trace, etc.  You really kind of need both if you're using 
the event loop.

> No, not really. Just recursing over some directories. Memory usage 
> starts at about 2 MB, and grows linearly by about 50 KB every second. 
> Usually the script finishes before it actually reaches more than 8 MB, 
> but on occasion it doesn't.

If you're recursing over directories and saving the information 
somewhere, I wouldn't be at all surprised you're using 8MB. Did it ever 
actually run out of memory?

>> Granted, there is occasionally a leak in Tcl's memory handling 
>> described in the bug tracker. But it's rare, and they're all high 
>> priority to get fixed because people build real systems with Tcl.
> 
> How would I know about that? 

You look at the Tcl bug tracker?

> I downloaded Freewrap a few years back and 
> have been using it ever since. Still on the same version number.

Get the new one. It still works.

> So... you're saying that my particular Tcl interpretter just has a 
> memory bug in it?

If I recall correctly, there was one version of Tcl that had a memory 
leak in it, fixed shortly after it was reported. I don't think it was a 
general memory leak. I'm more suspecting that you *think* you have a 
memory leak that you really don't.

Tcl's actually amazingly solid. People reporting bugs of that nature in 
Tcl is like reporting bugs in your compiler - chances are *much* better 
that the code you've written is wrong than that your code is right and 
the compiler is wrong.

But show me the code, and I'll see if I can easily spot where you're not 
freeing something you should be.

> The whole "hey, let's not bother with datatypes and stuff, let's just 
> store everything as flat strings and reparse them every time we need to 
> touch something" concept simply *wreaks* of quick and dirty prototyping. 

A - That's pretty much how most extensible languages work, due to the 
nature of extensible languages.

B - Tcl doesn't store everything as flat strings and reparse. It just 
makes it possible to look at it that way. If you're still on a version 
that works that way, you need to upgrade, because it's been like 8 or 10 
years since Tcl did that.

C - Yes, it's annoying that there aren't syntax checks before you run 
the code. It comes with the extensible nature of the language. Don't 
write code that you put into production without ever having run it first.

> No sane person would design production-grade software this way, with no 
> safety checks or anything.

It has safety checks.  It just checks in different places.  It's no less 
sane than using a language that doesn't have array bounds checking.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message