Invalid command name "font" 1

[gcooper]

I guess I would say I'm very much a Tcl/Tk novice.
My problem as far as I can see is that I've been messed around by one of our middleware suppliers.
Until recently, we've been running HP-UX 10.20. The supplier supplied a Tcl/Tk environment for us to develop some front ends, which my predecessor duely did. We have now upgraded to HP-UX 11.11 and our Tcl/Tk scripts have stopped working. There seems to be some confusion over Tcl/Tk versions.

What (I think) our supplier suggested was to replace wish 8.0 with wish 4.2(!) and libtcl7.6.sl.gz by libtcl4.2.sl.gz.
This was duely done and most of our scripts are now working, however, I'm having a problem with one which produces the following error:

invalid command name "font"
while executing
"font create timesfont -family Times -size 14 "
(file "/home/b110/sys_env/appl/dbfind.ocx.tcl" line 15)

Unless it's really essential, I don't want to start installing new versions of Tcl/Tk components, I'd just rather get the scripts working as the environment stands.

Any help would be most gratefully received.

Thanks,

Gary Cooper

 

[ulis]

Did you verified that Tk 4.2 knows about the font command?
Some info here:

http://www.tcl.tk/software/tcltk/7.6.html

HTH

ulis

 

[gcooper]

Ulis,

I had a look at the link you specified and did a bit of digging around and you are right in what you say, the font command didn't come in until tk 8.0.

I've removed the font command and the subsequent references to the font which should have been created and it seems OK now.

Thanks for the help.

Regards,

Gary

 

[AviaTraining]

And beat up your supplier for using a version of Tcl/Tk that is 8 years old! %-(

- Ken Jones, President, ken@avia-training.com
Avia Training and Consulting,

http://www.avia-training.com

866-TCL-HELP (866-825-4357) US Toll free
415-643-8692 Voice
415-643-8697 Fax

 

[gcooper]

It looks like the supplier's scripts are being re-written in perl, so I guess we'll be dropping the Tcl/Tk at sometime in the future. (I suppose we'll be using an old version of perl as well!).

 

[AviaTraining]

Yeah, they're probably switching to Perl because "Tcl is too slow" and "Tcl doesn't have the features we need." Use a modern version of Tcl/Tk and those aren't problems!

I know it's not your fault, so don't take my rant personally. It just irks me when I see situations like this. So instead of upgrading to a modern version of Tcl and preserving all the investment they've made in developing and debugging existing software, they're switching to a completely different language and having to make that investment again in developing software that does exactly what the old software did, fixing the new bugs that get introduced in the new software, and finally adding whatever new features they had in mind. Joel Spolsky sums it up pretty well in his article, "Things You Should Never Do, Part I,"

http://www.joelonsoftware.com/articles/fog0000000069.html.

- Ken Jones, President, ken@avia-training.com
Avia Training and Consulting,

http://www.avia-training.com

866-TCL-HELP (866-825-4357) US Toll free
415-643-8692 Voice
415-643-8697 Fax

 

[gcooper]

Interesting article. A lot of what it says is true - if it ain't broke, don't fix it... to a point. Like it says, some code that gets rewritten is because the new programmer can't understand it. I find this is usually because of poor names for variables or because of inadequate comments. What I tend to do in this instance is start adding comments first and then change the variables to more meaningful names if it's still needed.

However, we had an instance a few years ago, where one guy in the team (long since gone) wrote quite a large monolithic routine that was widely used and was completely (and I mean completely) illegible. After he had gone, if there were any problems suspected in the routine, it used to fill the entire project team (about 6 engineers) with dread at the prospect of trying to do fault finding on it. It was funny how everyone was busy doing something else. The routine looked an absolute mess - but do you know what? As far as I can recall although it was implicated in many problems, it was never convicted. Eventually, we did end up rewriting it as part of a validation project - our (then) newly developed coding standards specified that code should be easy to understand and support.

I've also done rewriting for efficiency reasons. I took a badly structured, inefficient program which was very mature and very robust and rewrote that into a streamlined and equally robust program with exactly the same functionality. The result was reducing processor load from 35% to around 3% (this was in the old PDP-11 days).

So there can be cases where a rewrite is acceptable, but you have to judge each case on it's own merits... and one person's merits ain't necessarily another person's.

One interesting thing about software, that it took me quite a while to appreciate and that is concerning the generally held belief that software doesn't wear out - it does! How? Well, for electrical and mechanical things, everyone knows about the bath tub curve for reliability, where (statistically) there are more problems at the beginning of a product's lifespan due to manufacturing and design faults (and that this is true for software); then after a few years electrical and mechanical components wear out and the number of problems increases once again. As software 'ages', gradually more and more bugs are fixed and so the reliability improves, but then a ‘bell’ is added here and a ‘whistle’ there and whilst this may not greatly affect the reliability, what usually happens is that the new functionality is shoe-horned into a program that was never intended to do that particular task. Some times the only way it can be achieved is by breaking the structure.

What we have now is code that is becoming poorly structured and increasingly more difficult to support. Changes to the code now frequently introduce new bugs and hey presto, we’re climbing up the bath tub and this is the sign that the code is nearing the end of it’s life. It doesn’t happen often, but I have seen it a few times.

But it does seem a shame to have to redevelop all of our Tcl/Tk scripts, when on the whole, they work OK.

Well, that’s my view on things, for what it’s worth.

Regards,

Gary Cooper

 

[ulis]

Thanks (to Gary & to Ken) for sharing your experiment.

ulis