 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Any suggestions as to how to pull this off? Personally I don't know of a
> programming language that makes it easy to do this kind of thing.
Tcl.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Any suggestions as to how to pull this off? Personally I don't know of a
> programming language that makes it easy to do this kind of thing.
Tcl. More specifically....
http://tktable.sourceforge.net/winico/winico.html
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Tcl. More specifically....
>
> http://tktable.sourceforge.net/winico/winico.html
I had a feeling you'd say that.
It looks like I can use this to put an icon with a tooltip in the
taskbar. I was kind of hoping to be able to pop up small messages as
well, but I guess that isn't critical.
Apparently the latest version of Freewrap includes this extension, and
it does seem to work. I'm not very confortable with using an unreliable
language like Tcl, but there doesn't appear to be a lot of option...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Darren New wrote:
>
>> Tcl. More specifically....
>>
>> http://tktable.sourceforge.net/winico/winico.html
>
> I had a feeling you'd say that.
Hey, Tcl does just about everything. That's why I like it.
> It looks like I can use this to put an icon with a tooltip in the
> taskbar. I was kind of hoping to be able to pop up small messages as
> well, but I guess that isn't critical.
You can do that. You don't need this extension for it. Use "wm
OVERRIDE_REDIRECT" or some such on your window, and you won't get a
border or close buttons, so you just position it in the corner and draw
into it.
> Apparently the latest version of Freewrap includes this extension, and
> it does seem to work. I'm not very confortable with using an unreliable
> language like Tcl, but there doesn't appear to be a lot of option...
What's unreliable about it? I've very rarely had a problem with anything
not working as specified. Indeed, I've been using it for 13 years and
only found two rather obscure bugs.
If you mean "it doesn't work as I expect" (e.g., things complaining
about malformed lists), post your code and I'm happy to show you how to
do it reliably.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I had a feeling you'd say that.
>
> Hey, Tcl does just about everything. That's why I like it.
Well, it does a few things that are useful. (E.g., it's one of the few
portable languages that lets you access Windoze-specific file attributes.)
>> It looks like I can use this to put an icon with a tooltip in the
>> taskbar. I was kind of hoping to be able to pop up small messages as
>> well, but I guess that isn't critical.
>
> You can do that. You don't need this extension for it. Use "wm
> OVERRIDE_REDIRECT" or some such on your window, and you won't get a
> border or close buttons, so you just position it in the corner and draw
> into it.
And how the heck do I figure out *where* the corner of the screen is?
(And, for that matter, avoid stealing the input focus when the window
opens?)
> What's unreliable about it? I've very rarely had a problem with anything
> not working as specified. Indeed, I've been using it for 13 years and
> only found two rather obscure bugs.
>
> If you mean "it doesn't work as I expect" (e.g., things complaining
> about malformed lists), post your code and I'm happy to show you how to
> do it reliably.
It's a scripting language. It doesn't really "do" error-handling. If
something goes wrong, the script tends to just choke in an unpredictable
way.
Many of the Tcl scripts I run seem to leak memory pretty badly. I did
have a Tcl script that did something every 5 minutes - but I discovered
that the longer it runs, the more RAM it eats. I now rerun the script
every 5 minutes using an external tool.
There are many, *many* things that work unexpectedly in Tcl. But then,
the language isn't really set up for making production-grade
applications, it's designed for quickly throwing things together that
work on the day you test them.
The list goes on...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> And how the heck do I figure out *where* the corner of the screen is?
I would ask for the coords of the window in the system tray and go from
there? I haven't done it, but it can't be all that hard. I'm almost
certain you can get the screen size in pixels from Tcl.
Now, that's assuming you only have one screen.
To answer your question precisely, "winfo screenheight" and "winfo
screenwidth" are what you're looking for, I think. "winfo" and "wm"
control all that sort of stuff. (WM referring to the window manager, so
it controls borders and focus and such. The documentation doesn't
clarify for me how to avoid taking focus when you create a window.)
> (And, for that matter, avoid stealing the input focus when the window
> opens?)
I think Windows prevents this from happening in the first place in
general, but that's a good question.
> It's a scripting language. It doesn't really "do" error-handling. If
> something goes wrong, the script tends to just choke in an unpredictable
> way.
No. You're thinking of C. Tcl chokes in very predictable ways. Indeed,
at work, I use a Tcl monitoring process to restart all the craptastic
C++ stuff that dumps core about once a week. (Not that C++ is
necessarily craptastic, but this stuff is.)
Between [catch] and [bgerror], Tcl should never do something
unpredictable. Maybe you don't know how Tcl behaves, but it really is
well-defined.
> Many of the Tcl scripts I run seem to leak memory pretty badly. I did
> have a Tcl script that did something every 5 minutes - but I discovered
> that the longer it runs, the more RAM it eats. I now rerun the script
> every 5 minutes using an external tool.
I have Tcl programs that run literally months without being touched. If
you're leaking memory, it's because you're storing stuff in globals and
not cleaning up after yourself.
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.
Tcl doesn't always dispose of the maximum amount of memory it can, but
if you free something up after allocating it, that memory does get reused.
> There are many, *many* things that work unexpectedly in Tcl. But then,
> the language isn't really set up for making production-grade
> applications, it's designed for quickly throwing things together that
> work on the day you test them.
I disagree. I've written all kinds of server stuff in Tcl that runs for
months without being touched, that automatically recovers from my
mistakes, and so on. If you can't get it to work for you, it's because
you don't know how, methinks.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> And how the heck do I figure out *where* the corner of the screen is?
>
> I would ask for the coords of the window in the system tray and go from
> there? I haven't done it, but it can't be all that hard. I'm almost
> certain you can get the screen size in pixels from Tcl.
Right. And now how do I figure out how big the system tray is? (You
realise it's resizable, right?)
> Now, that's assuming you only have one screen.
That's a safe assumption for the purposes of this project. ;-)
> To answer your question precisely, "winfo screenheight" and "winfo
> screenwidth" are what you're looking for, I think. "winfo" and "wm"
> control all that sort of stuff. (WM referring to the window manager, so
> it controls borders and focus and such. The documentation doesn't
> clarify for me how to avoid taking focus when you create a window.)
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?
>> (And, for that matter, avoid stealing the input focus when the window
>> opens?)
>
> I think Windows prevents this from happening in the first place in
> general, but that's a good question.
I'll check later...
>> It's a scripting language. It doesn't really "do" error-handling. If
>> something goes wrong, the script tends to just choke in an
>> unpredictable way.
>
> No. You're thinking of C. Tcl chokes in very predictable ways. Indeed,
> at work, I use a Tcl monitoring process to restart all the craptastic
> C++ stuff that dumps core about once a week. (Not that C++ is
> necessarily craptastic, but this stuff is.)
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. 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?
> Between [catch] and [bgerror], Tcl should never do something
> unpredictable. Maybe you don't know how Tcl behaves, but it really is
> well-defined.
Frobbing bgerror is just painful. catch looks more useful...
>> Many of the Tcl scripts I run seem to leak memory pretty badly. I did
>> have a Tcl script that did something every 5 minutes - but I
>> discovered that the longer it runs, the more RAM it eats. I now rerun
>> the script every 5 minutes using an external tool.
>
> I have Tcl programs that run literally months without being touched. If
> you're leaking memory, it's because you're storing stuff in globals and
> not cleaning up after yourself.
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.
> 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? I downloaded Freewrap a few years back and
have been using it ever since. Still on the same version number.
So... you're saying that my particular Tcl interpretter just has a
memory bug in it?
>> There are many, *many* things that work unexpectedly in Tcl. But then,
>> the language isn't really set up for making production-grade
>> applications, it's designed for quickly throwing things together that
>> work on the day you test them.
>
> I disagree. I've written all kinds of server stuff in Tcl that runs for
> months without being touched, that automatically recovers from my
> mistakes, and so on. If you can't get it to work for you, it's because
> you don't know how, methinks.
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.
No sane person would design production-grade software this way, with no
safety checks or anything.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
