In my specific case, I'm typically trying to write software to make use of a pacakge, but I'm either uncertain what specific name to use for the package, or I'm using the right package, but something is wrong with the package or with the installation.
As I previously wrote, all I get is a "can't find" type message. Sometimes, because of reading comp.lang.tcl, etc. for years, I know to start by looking through the directories in $auto_path , to see if the software is installed in any of them. If not, then I have to figure out why it was installed in the wrong place. If it is, then I know to look in pkgIndex.tcl and to try and figure out what is wrong there.
However, there's no references to that error (or most of the others) in any of the man pages, and the error message that is generated is accurate, but less than helpful to developers without the background to know where to start.
I'm not trying to say "Bad Tcl!!!" here. I'm just pointing out that while many of Tcl's error messages are quite helpful in solving problems, there are others (such as this one, which I hit pretty frequently) which are less helpful.
On Nov 15, 7:15 am, "Larry W. Virden" <lvir...@gmail.com> wrote:
> I'm not trying to say "Bad Tcl!!!" here. I'm just pointing out that > while many of Tcl's error messages are quite helpful in solving > problems, there are others (such as this one, which I hit pretty > frequently) which are less helpful.
You probably wrote this as I was writing my response. Usually [package require] is called from a page level script, inside a [namespace eval]. In that case, you get the best information possible, assuming you look at the full error message, you get a full file path and line number. But only if you get the full error message. Not getting the full error message is a programming mistake, not a language mistake. If you use other peoples' code, you always run the risk that they don't know what they are doing.
I seldom use [package require], I use a configuration/load script which sources files and initializes code in a known order. It is faster to source everything explicitly than it is to search for one missing package. Failure should be fast, not slow. Programming should be explicit, not guess-and-go. But, everyone appears to be happy to make installation easy and debugging hard, go figure.
Larry W. Virden wrote: > I'm not trying to say "Bad Tcl!!!" here. I'm just pointing out that > while many of Tcl's error messages are quite helpful in solving > problems, there are others (such as this one, which I hit pretty > frequently) which are less helpful.
The problem with this complaint is that it (largely) depends on something being "not there", and so that generating an informative error message would require knowing about code that hasn't been executed. That would be pretty close to the pinnacle of TIP#131's powers, let alone those of a normal script. :-)
Working out what didn't happen (or rather what didn't happen that should have happened) remains difficult. But that's not special to any language.
On Nov 15, 8:00 am, "Donal K. Fellows" <donal.k.fell...@man.ac.uk> wrote:
> The problem with this complaint is that it (largely) depends on > something being "not there", and so that generating an informative > error message would require knowing about code that hasn't been > executed.
Finding errors depends 100% on logging the errorInfo when an error occurs. If you don't do that, you can't complain that Tcl has unhelpful error messages, you just threw away the information you needed. Maybe you should ask "What stupid application would continue to operate if it can't find a required package?" The program should be complaining very loudly, but it appears to be suppressing the information provided by Tcl.
Here is an example of a startup. I put in a bogus [package require]:
[15/Nov/2007:08:32:29.257970][27192.1696194768][-main-] Notice: TWS:About to package require abXdcE [15/Nov/2007:08:32:29.275229][27192.1696194768][-main-] Error: TWS:can't find package abXdcE while executing "package require abXdcE" (file "/web/nsd45/servers/tutos/modules/tcl/twsdl/packages/tdom/ tcl/tdom-procs.tcl" line 14) invoked from within "::source /web/nsd45/servers/tutos/modules/tcl/twsdl/packages/tdom/tcl/ tdom-procs.tcl" ("uplevel" body line 1) invoked from within "uplevel ::source "$file"" (procedure "::tws::sourceFile" line 4) invoked from within "::tws::sourceFile [::tws::util::package::directory [file join $packageName tcl ${packageName}-procs.tcl]]" (procedure "procs" line 4) invoked from within "procs $package" PACKAGE tdom [15/Nov/2007:08:32:29.275389][27192.1696194768][-main-] Notice: TWS:Package wsdb: Procs loading...
> On Nov 15, 8:00 am, "Donal K. Fellows" <donal.k.fell...@man.ac.uk> > wrote: > > The problem with this complaint is that it (largely) depends on > > something being "not there", and so that generating an informative > > error message would require knowing about code that hasn't been > > executed. [...] > TWS:can't find package abXdcE > while executing > "package require abXdcE"
[... full trace ...]
> So the last [log Notice] was skipped because the error aborts sourcing > the file, you get a full trace of the error. No mystery here.
I think the mystery from Larry's perspective is "why can't package abXdcE be found? I know it's there but I don't know precisely what it's name is." The fact that Tcl's catchable errors are very informative sheds no light there.
-- Glenn Jackman "You can only be young once. But you can always be immature." -- Dave Barry
On Nov 15, 10:33 am, suchenwi <richard.suchenwirth-
bauersa...@siemens.com> wrote: > But isn't that problem comparable to > $ tclsh > % set foo 1 > 1 > % puts $Foo > can't read "Foo": no such variable
> "Case matters" is an old rule in Unix, C, and many other worlds... > Should the error message say "Make sure your capitalization is right"?
I don't think we have to go to that level. But should the documentation somewhere indicate that variables are case sensitive, and the tutorial or doc or something mention that "no such variable" could mean that the casing was wrong, or that the variable had not yet been set, or that the variable had been unset by this time, or that it existed in a different namespace? That would at least give the programmer some ideas of the kinds of things that might cause the problem, right?
I'm not saying that all of this belongs in the man page. But surely somewhere a new programmer could hope to find some sort of guide. Certainly there's a great guide for Perl that provides the reader with at least some ideas on what to do next when encountering certain error messages...
On Nov 15, 9:00 am, Glenn Jackman <gle...@ncf.ca> wrote:
> I think the mystery from Larry's perspective is "why can't package > abXdcE be found? I know it's there but I don't know precisely what it's > name is." The fact that Tcl's catchable errors are very informative > sheds no light there.
Gee, I hope that isn't true, but maybe it is. The first thing a developer should figure out is the exact name of the package they want to require. This goes along with my complaint about optimistic programming. If proc and/or package names ever become case insensitive, that would be a real disaster. Duct tape programming models work well up until they don't.
Next thing you know, there will be a TIP asking for hard coded paths to be auto converted based upon platform, to avoid the necessity of abstracting paths with [file] commands.
So to tie this back into the 'Tcl is easy' meme, I'll just add that robust programming isn't easy. Guess-and-go programming is not robust. Tcl makes it easier to write robust programs, not guess-and-go programs.
> At 2007-11-15 11:39AM, "tom.rmadilo" wrote:> On Nov 15, 8:00 am, "Donal K. Fellows" <donal.k.fell...@man.ac.uk> > > wrote: > > > The problem with this complaint is that it (largely) depends on > > > something being "not there", and so that generating an informative > > > error message would require knowing about code that hasn't been > > > executed. > [...] > > TWS:can't find package abXdcE > > while executing > > "package require abXdcE"
> [... full trace ...]
> > So the last [log Notice] was skipped because the error aborts sourcing > > the file, you get a full trace of the error. No mystery here.
> I think the mystery from Larry's perspective is "why can't package > abXdcE be found? I know it's there but I don't know precisely what it's > name is." The fact that Tcl's catchable errors are very informative > sheds no light there.
And, in other cases, I know not only that it is there, but I know precisely what its name is. But Tcl doesn't find it anyways. Generally, after much head scratching, what I find is a mangled pkgIndex.tcl or some other weird case. But, as Glenn accurately points out, Tcl's error message tells me plenty about my code - where I typed the command - but very little about the steps it took to decide that the file that I "know" is there isn't being seen...
On Nov 15, 11:00 am, "Donal K. Fellows" <donal.k.fell...@man.ac.uk> wrote:
> The problem with this complaint is that it (largely) depends on > something being "not there"
If, however, there were some extra command, or option, or variable, or flag that could be set that said "show me the places you are looking and why you are rejecting what you are rejecting, then I might be able to say "oh look, it read the right file, but decided that the item there wasn't relevant because ..." or "oh look, it didn't look in the directory where the package is installed because ..." or whatever.
Right now, trying to figure out what is going on inside the process is a black box - which is the right thing when everything works. It just is a nuisance when something is going wrong and you need to figure out what.
On Nov 15, 12:20 pm, suchenwi <richard.suchenwirth-
bauersa...@siemens.com> wrote: > Just to add, a quick way of checking "correct" package names is, in an > interactive tclsh: > % packa re "" > % join [lsort [package names]] /n
On 15 Nov., 18:28, "Larry W. Virden" <lvir...@gmail.com> wrote:
> On Nov 15, 12:20 pm, suchenwi <richard.suchenwirth-
> bauersa...@siemens.com> wrote: > > Just to add, a quick way of checking "correct" package names is, in an > > interactive tclsh: > > % packa re "" > > % join [lsort [package names]] /n
> probably want to use
> join [lsort [package names]] \n
> to make it a wee bit easier to read...
Of course - sorry, was multitasking too much to check what I actually posted... :^)
On Nov 15, 9:23 am, "Larry W. Virden" <lvir...@gmail.com> wrote:
> And, in other cases, I know not only that it is there, but I know > precisely what its name is. But Tcl doesn't find it anyways. > Generally, after much head scratching, what I find is a mangled > pkgIndex.tcl or some other weird case. But, as Glenn accurately points > out, Tcl's error message tells me plenty about my code - where I typed > the command - but very little about the steps it took to decide that > the file that I "know" is there isn't being seen...
As Alexandre Ferrieux pointed out in another thread, strace is your friend:
$ strace -o /tmp/log-file-access.txt tclsh
You will get a list of every directory searched. If you want the full path, just try to find a package which doesn't exist. One problem with [package require] is that you can mangle up the auto_path, so one package might screw up something which used to work. This is a perfect example of why using fuzzy programming is objectively annoying, and strikes at the least helpful time. All of this plagues any language which uses shared libraries, the problem is that with Tcl, using shared libraries only saves disk space, in C, you save memory.
ewilsonm...@gmail.com wrote: > However, I would've thought that Brian Kernighan's comment would have > given some indication that Tcl is not simple.
I'd note that Tcl is simple enough that, unlike C and C++, one doesn't find programs out there to translate type declarations into English for you so you can figure out what the compiler thinks you wrote.
-- Darren New / San Diego, CA, USA (PST) Remember the good old days, when we used to complain about cryptography being export-restricted?
> On Nov 15, 11:00 am, "Donal K. Fellows" <donal.k.fell...@man.ac.uk> > wrote:
>> The problem with this complaint is that it (largely) depends on >> something being "not there"
> If, however, there were some extra command, or option, or variable, or > flag that could be set that said "show me the places you are looking > and why you are rejecting what you are rejecting, then I might be able > to say "oh look, it read the right file, but decided that the item > there wasn't relevant because ..." or "oh look, it didn't look in the > directory where the package is installed because ..." or whatever.
It is there inside the tcl libraries package.tcl file. Just register your own version of the proc there before things go bad.
