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