can't find package __teapot__ ???
in [TCL]
|
Prev: TCL exec
Next: couldn't load library "mpexpr10.dll" ...
From: Helmut Giese on 31 Oct 2007 07:06 Hello out there, I sent a Tcl script to a client together with instructions how to install Tcl and how to launch the script. The client now reports that he receives the error message can't find package __teapot__ I have never seen this message before (of course all my machines are Tcl aware) so my question is: In what context does this message appear or what could have gone wrong at the client's site to produce this message? Any help will be greatly appreciated - client is very unhappy and on the border of getting angry. Best regards Helmut Giese
From: Helmut Giese on 31 Oct 2007 07:18 I should add that this is ActiveTcl 8.4.14 on Windows (2000 or XP - don't know right now). The script in question is a small Tcl-only (no GUI) script which only depends on one extension present in the same directory and which gets loaded like lappend auto_path . package require Hrt with a proper pkgindex.tcl present .- no other 'package require' in sight. Helmut Giese
From: Larry W. Virden on 31 Oct 2007 09:09 On Oct 31, 7:06 am, Helmut Giese <hgi...(a)ratiosoft.com> wrote: > can't find package __teapot__ > > I have never seen this message before (of course all my machines are > Tcl aware) so my question is: In what context does this message appear > or what could have gone wrong at the client's site to produce this > message? > well, teapot is the name of ActiveState's ActiveTcl software repository, designed to provide packages to a software administrator. However, using teacup (the activetcl client side of the setup), I don't see a package named teapot listed. The steps _I_ would take if this were my problem would be: 1. Recommend the client uninstall the previous activetcl, download the latest Tcl 8.4 Windows ActiveTcl, and install it 2. Make certain the user has installed my script into a directory containing nothing else 3. Report the situation to activestate with a high priority assigned.
From: Helmut Giese on 31 Oct 2007 11:17 Hi Larry, >well, teapot is the name of ActiveState's ActiveTcl software >repository, designed to provide packages to a software administrator. yeah, I have heard about it - don't know whether I would need it or not though. >The steps _I_ would take if this were my problem would be: > >1. Recommend the client uninstall the previous activetcl, download the >latest Tcl 8.4 Windows ActiveTcl, and install it It was a fresh install of Tcl 8.4.14. >2. Make certain the user has installed my script into a directory >containing nothing else This is probably / almost certainly the case. >3. Report the situation to activestate with a high priority assigned. Hm, not sure what to report. Anyway, this is one of those rare days, where a problem disappeared all by itself (usually they appear from nowhere and insist on hanging around). Doing some hand-holding via telephone the program now runs like it should. Differences: - It is possible (though a bit unlikely) that the machine was rebooted in the meantime. - When it failed the user was in Tcl's bin directory and called tclsh c:\somedir\somescript.tcl c:\destDir (note the '\') - When called from the script's directory like tclsh somescript.tcl . everything was ok (note the '.' for the directory and that no paths are involved). Looks like the culprits are the '\' in the invocation? Well, trying version 1 on my machine worked as well as version 2, so it appears far from obvious. But the problem is gone so I won't trouble myself guessing for reasons. Thanks for your thoughts and best regards Helmut Giese
From: Larry W. Virden on 31 Oct 2007 12:59
On Oct 31, 11:17 am, Helmut Giese <hgi...(a)ratiosoft.com> wrote: > Differences: > - When it failed the user was in Tcl's bin directory and called > tclsh c:\somedir\somescript.tcl c:\destDir > (note the '\') I wonder if the problem was being in Tcl's bin directory - you indicated in your original (well followup) message: > The script in question is a small Tcl-only (no GUI) script which only > depends on one extension present in the same directory and which gets > loaded like lappend auto_path . package require Hrt Notice that you add . rather than a directory name, to auto_path, then do a package require. Perhaps something in the tcl bin directory interfered. Or, if the user didn't have Hrt installed in the bin directory, then perhaps the package require was having problems. Alas, I don't have access to a Windows machine where I can test out these theories. |