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

>> 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?

Well, it's famously hard to check *everything* that could possibly go 
wrong at every possible moment in your program. The code is unreadable 
enough already... :-(

>> 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.

It's a backup script. It backed up so much data that there was no furter 
space available. Not really Tcl's fault, but it didn't handle it 
terribly gracefully.

>> 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.

...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?

Doesn't actually store the data anywhere. It's just trying to delete a 
folder recursively. (I discovered that if you don't manually walk the 
thing yourself, it gives up at the first file it hits that can't be 
deleted. I want it to delete EVERYTHING that can be deleted.)

>> 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.

IIRC, I tried to use a newer version of Freewrap and a few scripts 
broke. It's probably not hard to fix, but I haven't got round to it yet.

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

Well, I was under the impression that local variables get automatically 
freed when you exit a procedure - maybe I was wrong?

>> 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.

Define "extensible language".

>> 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.

I would question the sanity of that too. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v7 wrote:
> Well, it's famously hard to check *everything* that could possibly go 
> wrong at every possible moment in your program. The code is unreadable 
> enough already... :-(

If you're going to fill up the disk, you need to check you're not going 
to fill up the disk, or you need to catch all errors, or you need to 
accept you're going to bomb out. I don't see any way around that.

> It's a backup script. It backed up so much data that there was no furter 
> space available. Not really Tcl's fault, but it didn't handle it 
> terribly gracefully.

Tcl handles it fine. You didn't write code to account for filling up the 
disk, so you probably got stuck in a loop trying to write data and 
having it fail, is my guess.

> ....event...loop...?

Yeah, OK. You know, that thing you use with Tk, vwait, fileevent, that 
stuff?

Not knowing what the event loop is in Tcl is like using C and saying 
"Wait, function? Header file? What's that?"

> Doesn't actually store the data anywhere. It's just trying to delete a 
> folder recursively. (I discovered that if you don't manually walk the 
> thing yourself, it gives up at the first file it hits that can't be 
> deleted. I want it to delete EVERYTHING that can be deleted.)

Obviously, if you're recursing, you're at least storing the list of 
entries in each directory from where you are to where you started. 8M 
doesn't seem like a lot, depending on the directories.

> Well, I was under the impression that local variables get automatically 
> freed when you exit a procedure - maybe I was wrong?

Yes, they do. But the memory gets reused rather than being freed, so the 
process will grow to the biggest size you allocate at one time.

> Define "extensible language".

One where you can change the syntax of the language, basically. FORTH, 
LISP, Tcl, etc.

When you can redefine the meaning of "if" or "proc" at runtime, it's 
fairly difficult to have a code checker that will check you're passing 
the right types.

On the gripping hand, there *are* code checkers for Tcl, if that's your 
thing.

> I would question the sanity of that too. ;-)

Me too. I'd much rather have runtime checks than no runtime checks.

-- 
   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