I am trying to use teapot under windows. What I observed, is that inside
the repository (<repository>\package\tcl\lib), there is a file named
pkgIndex.tcl, whose contents is a mess. This file contains invalid tcl
code, which remainds me of bad substitutions with regular expresions or
string map :-)
I can see in there pieces of tcl code interrupted by other tcl code, like:
ifif {![package vsatisfies [package provide Tcl] 8.0]} return
set _ $dir ; set dir [file join $_ Plotchart-1.3.1] ; source [file join
$dir pkgIndex.tcl] ; set dir $_ ; unset _
{![package vsatisfies [package provide Tcl] 8.4]} return
...
if {![package vsatset _ $dir ; set dir [file join $_ treeql-1.3.1] ;
source [file join $dir pkgIndex.tcl] ; set dir $_ ; unset _
set _ $dir ; set dir [file join $_ ctext-3.1] ; source [file join $dir
pkgIndex.tcl] ; set dir $_ ; unset _
set _ $dir ; set dir [file join $_ tablelist_common-4.8.1] ; source
[file join $dir pkgIndex.tcl] ; set dir $_ ; unset _
set _ $dir ; set dir [file join $_ tkpiechart-6.6] ; source [file join
$dir pkgIndex.tcl] ; set dir $_ ; unset _
isfies [package provide Tcl] 8.5]} return
How exactly is this file generated? Can I delete it and re-create it
somehow?
George
Here is an example of the pkgIndex.index file i have. This file is all 1
long line. List or dict can be used to parse this. The 8.1, 8.3, 8.4,
8.5 are Tcl versions, I do not know what the other numbers are for.
8.3 {416 {476 Plotchart-1.2}} 8.4 {588 {0 tablelist_common-4.8.1 760
tkpiechart-6.6 649 ctext-3.1}} 8.0 {69 {129 Iwidgets-4.0.2}} 8.5 {0 {61
snit-2.2.1}} 8.1 {242 {303 BWidget-1.8}}
It does not address the problem that I have had with teacup not
installing a lot of packages and saying that it did. Some examples are
"cursor", "datefield", "getstring", "history", "ico", "autoscroll",
"base64", and several more.
#fix.tcl
catch "console show"
proc main {argc argv} {
#check to see if pkgIndex.index exists
if {![file exists pkgIndex.index]} {
puts "\"pkgIndex.index\" not found"
return 1
}
#rename the original pkgIndex.tcl
if {[file exists pkgIndex.tcl]} {
puts "Renaming \"pkgIndex.tcl\" ..."
for {set i 0} {[file exists \
pkgIndex_$i.tcl]} {incr i} {}
file rename pkgIndex.tcl pkgIndex_$i.tcl
puts "\"pkgIndex.tcl\" renamed to \
\"pkgIndex_$i.tcl\" ..."
}
#open files
puts "Opening files ..."
set inFile [open pkgIndex.index r]
set outFile [open pkgIndex.tcl w+]
#read the packages
puts "Creating new \"pkgIndex.tcl\" from \
\"pkgIndex.index\" ..."
foreach {tclVersion pkgList1} [read $inFile] {
puts "Tcl/Tk $tclVersion\t..."
puts $outFile "if \{!\[package vsatisfies\
\[package provide Tcl\] 8.5\]\} \{"
foreach {u1 pkgList2} $pkgList1 {
foreach {u2 pkg} $pkgList2 {
puts "\t$pkg"
puts $outFile "\t# $pkg"
puts $outFile "\tset _ \$dir"
puts $outFile "\tset dir \[file \
join \$_ $pkg\]"
puts $outFile "\tsource \[file \
join \$dir pkgIndex.tcl\]"
puts $outFile "\tset dir \$_"
puts $outFile "\tunset _\n"
}
}
puts $outFile "\}\n"
}
puts "Done creating \"pkgIndex.tcl\" ..."
#close pkgIndex.tcl
puts "Closing files ..."
close $inFile
close $outFile
return 0
}
main $argc $argv
I think anytime you find yourself escaping code like that so much (which
I found myself in before at times), you should consider using [subst].
For example:
puts $outFile [subst -nocommands {
# $pkg
set dir [file join [set dir] $pkg]
source [file join [set dir] pkgIndex.tcl]
}]
In essence you can use -nocommands to make the evaluation occur later.
It's much easier to read as well.
George
--
I think beings writing/using proprietary open software should read this:
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/EWD1175.html
Gary
Ok. Back from my winter vacation, recovered from jet lag, still
recovering from the head cold and sore throat I caught Saturday ...
This, the messed up lib/pkgIndex.tcl file is a bug, a very major one,
and currently my main focus among all the teapot/teacup issues which
came up here in the last few weeks.
The file in question is modified by teacup, whenever a package is
installed/removed in the particular directory it, and its helper
pkgIndex.index, lives in. There is currently no way to delete and
regenerate it.
For reference, this is tracked in ActiveState's bug database at
http://bugs.activestate.com/show_bug.cgi?id=74010
I believe that I managed to fix the problem today, rewriting the
machinery dealing with these files fairly completely, however there is
still testing to be done. Part of the change will be a new teacup
command which will allow the regeneration of these files from scratch
in case of future trouble.
~~
Regarding the other problems, opinions, and ideas bandied around in
the various thread I am still collating what people are saying, and
working on distilling the various themes and arguments into a coherent
picture of the various issues. I will do my best to follow everything
here, however for better tracking and in case I miss something I also
ask anyone to go to ActiveState's bug tracker at
and add their stuff there. The project should be ActiveTcl, with
component 'teapot'.
--
So long,
Andreas Kupries <akup...@shaw.ca>
<http://www.purl.org/NET/akupries/>
Developer @ <http://www.activestate.com/>
-------------------------------------------------------------------------------
> I am having the same troubles that you are with teacup; and after
> reading your post I came up with a solution to the problem. It is
> not elegant, and I have not had a chance to do extensive testing,
> but it should create a semi-equivalent file to what teacup was
> intended to create. This script assumes that there is a
> pkgIndex.index file in the same directory as pkgIndex.tcl. To use
> this script just place it in the same directory as the pkgIndex.tcl
> and run it.
> When I was looking at the pkgIndex.index file, I did not understand
> the purpose of all the information in it; so I had to ignore some of
> it, mostly the numbers.
> Here is an example of the pkgIndex.index file i have. This file is all
> 1 long line. List or dict can be used to parse this.
The data is basically a nested dictionary. Top keys are Tcl version
numbers, entries are data for the packages which have version as their
minimal required version.
> The 8.1, 8.3, 8.4, 8.5 are Tcl versions.
Right.
> I do not know what the other numbers are for.
The other numbers are character offsets into the pkgIndex.tcl file,
and that is where the trouble starts, at some point during the
incremental modification of both files when inserting and removing
packages off-by-n errors crept in somewhere, causing new commands to
be inserted in the middle of others, and/or deleted commands to be
removed only partially, worsening over time.
The new code written today does away with this .index file and
operates only on the .tcl file, line-based. This certainly works for
the command to regenerate the pkgIndex.tcl from scratch based on my
tests today. The handling of series of insertions and removals still
needs testing.
> It does not address the problem that I have had with teacup not
> installing a lot of packages and saying that it did. Some examples
> are "cursor", "datefield", "getstring", "history", "ico",
> "autoscroll", "base64", and several more.
Please enter a bug report for things like this in ActiveState's
tracker at
I will likely need the output of the 'teacup install' command. Other
information which may have relevance would be
* Output of 'teacup default'
* What tclsh T tries to find the non-installed package (path)
* Its auto_path,
* Output of 'teacup link info T'
* Output of 'teacup link info R', for R the path to the
repository in question.
[snip script]
I did find one type in the script to rebuild pkgIndex.tcl, that's why
all tcl/tk versions in it are 8.5 instead of the proper version. There
is a line that looks something like this:
puts $outFile "if \{!\[package vsatisfies \[package provide Tcl\]
8.5\]\} \{"
and it needs to be changed to this:
puts $outFile "if \{!\[package vsatisfies \[package provide Tcl\]
$tclVersion\]\} \{"
Of course, this will make no difference if you are only using Tcl 8.5,
but if you decide to use earlier versions it may cause problems.
Gary
> > Please enter a bug report for things like this in ActiveState's
> > tracker at
>
> > http://bugs.activestate.com/
Please don't forget Andreas's advice about submitting a bug report.
Having a report of this bug there will result in a relatively quick
fix, in my experience.
Gary