Why is teapot repositories so difficult to use?
Georgios Petasis
It seems that repository management is not so rubust, which makes really
difficult to use ActiveTcl 8.5. I will 8.5 came with all the packages
8.4 did...
I tried to make an executable using tclapp, and I get a failure in 80%
of the packages in my 8.5 installation. For example:
error copying "c:/program files
(x86)/tcl/lib/teapot/package/tcl/teapot/tcl8/8.2/base64-2.3.2.tm": no
such file or directory
while executing
"# Compiled -- no source code available
error "called a copy of a compiled script""
(procedure "Retrieve/teapot" line 1)
invoked from within
"# Compiled -- no source code available
error "called a copy of a compiled script""
(procedure "Retrieve" line 1)
invoked from within
"# Compiled -- no source code available
error "called a copy of a compiled script""
(procedure "::repository::localma::Snit_methodGet" line 1)
invoked from within
"::repository::api::localma1 Get {command {::snit::RT.CallInstance
::repository::union::Snit_inst2 _serialres ::repository::api::localma1
{} {{Bad requ..."
("after" script)
If I look into C:\Program Files
(x86)\Tcl\lib\teapot\package\tcl\teapot\tcl8\8.2, I can see a file named
base64-2.4.tm, but not base64-2.3.2.tm.
How is my repository so confused?
And hot to fix this? How to delete it and build it from scratch?
George
Larry W. Virden
wrote:
> Hi all,
>
> It seems that repository management is not so rubust, which makes really
> difficult to use ActiveTcl 8.5. I will 8.5 came with all the packages
> 8.4 did...
>
> I tried to make an executable using tclapp, and I get a failure in 80%
> of the packages in my 8.5 installation. For example:
I recommend submitting bug reports to activestate regarding your
problems. Be certain to specify the appropriate steps you took to
reach the error message, anything unique about your platform, etc.
For instance, what command were you running when you got the error
relating to base64?
On my sparc solaris machine, while I occasionally see errors, I've not
seen the one you mention.
If you want that particular version of base64 installed for some
reason, then you would type something like
teacup install --force base64 -exact 2.3.2
> How is my repository so confused?
>
> And hot to fix this? How to delete it and build it from scratch?
>
I would think that by uninstalling the activetcl and then installing a
fresh copy, you should have things well on the way to working again.
Georgios Petasis
Dear Larry,
Thank you for the info. I know about the activestate bug reports, but I
usually avoid it, as it is not so easy to use and feedback can take
days, which is more than the time required to fix the issue myself.
Regarding the commands that cause the problem, who knows? I never modify
the repositories. I only update the 8.5 by uninstalling/installing newer
versions, and sometimes I do "teacup update" in the Tcl/bin directory.
All other modifications are done "automatically", but are not so
successful. It seems that the whole infrastructure management is not so
stable...
Regarding the error, it is generated by tclapp. It is an app that needs
*a lot* of development to become a decent app. Each time I need to build
an exe, I usually consume many *hours* to get my job done...
I think that there is a problem with the 8.5 series of ActiveTcl. Its so
different from earlier series, that people do not want to use it.
The "product" I support is an open source app, and none of my users uses
8.5... And no-one plans to upgrade. And I cannot blame them...
Of course I uninstalled everything, deleted the repository and
re-installed everything (what a nice 1 hour waste :-) ). But try to
instruct a "client" to do so...
George
Georgios Petasis
Of course re-installing Tcl/repositories did not fix tclapp. It still
searches fro the outdated packages :-(
George
Larry W. Virden
wrote:
>
> Of course re-installing Tcl/repositories did not fix tclapp. It still
> searches fro the outdated packages :-(
What version of tclapp is the one with the problems?
Georgios Petasis
TDK 4.1.0 (TclDevKit4.1.0.284998-win32-ix86-threaded.exe).
What is strange is the following:
I have removed Tck 8.5.4. It was the only tcl installed on the system.
I removed TDK 4.1.
I erased everything from the Tcl/lib directory.
I erased an ActiveTcl folder I found in local settings.
I re-installed Tcl 8.5.4.
I re-installed TDK 4.1.0.
This means that the repository in Tcl/lib/teapot is simply an empty
repository.
I opened the preferences of tclapp. I added the path Tcl/lib/teapot in
the option that searches for repositories. And now I have many-many
packages to add to the wrap, even if the repository does not have them
at all!!! (including the old version of the base64 package :D )
It seems that the package list used by tclapp is kept somewhere (in the
registry?). But where?
(Well, it shouldn't be so difficult to use a wrapper application :-) )
George
AndreasK
wrote:
> O/H Larry W. Virden έγραψε:
> > I recommend submitting bug reports to activestate regarding your
> > problems. Be certain to specify the appropriate steps you took to
> > reach the error message, anything unique about your platform, etc.
>
> > For instance, what command were you running when you got the error
> > relating to base64?
> Dear Larry,
>
> Thank you for the info. I know about the activestate bug reports, but I
> usually avoid it, as it is not so easy to use and feedback can take
> days, which is more than the time required to fix the issue myself.
To address your comments about our bug tracker.
It is our official channel for getting information about problems with
our products. That, and the sup...@activestate.com email address. We
cannot guarantee to receive reports about problems sent anywhere else.
If you have trouble with our bug tracker please report _that_ as well.
While the tracker is not something I specifically have control over
our System and Webops people would be glad to know if someone has
trouble, and where and/or how.
We strive to make give our users a good experience. We cannot get
better if nobody tells us where we fail.
> George
AndreasK
wrote:
> O/H Larry W. Virden έγραψε:
>
> > On Sep 29, 9:12 am, Georgios Petasis <peta...@iit.demokritos.gr>
> > wrote:
> >> Of course re-installing Tcl/repositories did not fix tclapp. It still
> >> searches fro the outdated packages :-(
>
> > What version of tclapp is the one with the problems?
>
> TDK 4.1.0 (TclDevKit4.1.0.284998-win32-ix86-threaded.exe).
>
> What is strange is the following:
>
> I have removed Tck 8.5.4. It was the only tcl installed on the system.
> I removed TDK 4.1.
> I erased everything from the Tcl/lib directory.
> I erased an ActiveTcl folder I found in local settings.
> I re-installed Tcl 8.5.4.
> I re-installed TDK 4.1.0.
>
> This means that the repository in Tcl/lib/teapot is simply an empty
> repository.
>
> I opened the preferences of tclapp. I added the path Tcl/lib/teapot in
> the option that searches for repositories. And now I have many-many
> packages to add to the wrap, even if the repository does not have them
> at all!!! (including the old version of the base64 package :D )
>
> It seems that the package list used by tclapp is kept somewhere (in the
> registry?). But where?
No. The registry contains configuration/preference information, under
the key HKCU/Software/ActiveState, nothing else.
Note: In TDK 3 TclApp exclusively used the so-called 'TclApp
Packages', with definitions stored in files with extension '.tap', and
it managed list of paths to search for these in its configuration.
These typically comes from ActiveTcl installation.
In TDK 4 we _added_ the ability to search TEApot repositories for
packages as well, and for that added a second list of paths/urls to
search, which specify the repositories to look into.
When TclApp runs the list of packages available to wrap is dynamically
computed, by searching both these lists, then loading the .tap files
found and getting the lists of packages in the specified repositories.
Only the search lists are held in the configuration in the registry,
not the list of available packages derived from them.
AndreasK
Yes, that all sounds innocently enough ... I will you contact off-
group, directly by mail, and start asking more detailed questions
about the state of the repository and your system, so that you don't
have to post any internal info to the world.
> Regarding the error, it is generated by tclapp. It is an app that needs
> *a lot* of development to become a decent app. Each time I need to build
> an exe, I usually consume many *hours* to get my job done...
This sounds as if the problems you report now, with teapot
repositories, is not the only piece you have trouble with. Is it
possible for you to send us a more complete list of the areas where
you ran into trouble and how ? (GUI, Documentation, ...).
Georgios Petasis
Yes I know about all these. Perhaps the next step is to also support the
way Tcl looks for packages. Just add the entire directory that contains
the pkgIndex.tcl. For example, I am using a package named "pgintcl",
located in "C:\Program Files (x86)\Tcl\lib\pgintcl-3.0.1". My unwrapped
application can use the package. The wrapped one cannot, as the package
does not have a .tap file, and obviously is not in a teapot repository.
I think it would be very easy to also support this. It is unrelated to
my problem though. Just an enhancement wish...
>
> When TclApp runs the list of packages available to wrap is dynamically
> computed, by searching both these lists, then loading the .tap files
> found and getting the lists of packages in the specified repositories.
> Only the search lists are held in the configuration in the registry,
> not the list of available packages derived from them.
So, when I just installed ActiveTcl 8.5.4, and without touching the
repository, the fact that I saw many available packages suggests that
the repository created by the installer was already populated (as also
pointed by Larry)? I thought that these repositories were empty (at
least this was the case with earlier ActiveTcl 8.5.x releases). So,
perhaps I got the wrong impression (that a list of available packages
was "cached" somewhere). But all this is true only if 8.5.4 installs a
non empty teapot repository. Is it?
AndreasK
> > packages as well, and for that added a second list of paths/urls to
> > search, which specify the repositories to look into.
>
> Yes I know about all these. Perhaps the next step is to also support the
> way Tcl
... TclApp is meant here, I guess.
> looks for packages. Just add the entire directory that contains
> the pkgIndex.tcl. For example, I am using a package named "pgintcl",
> located in "C:\Program Files (x86)\Tcl\lib\pgintcl-3.0.1". My unwrapped
> application can use the package. The wrapped one cannot, as the package
> does not have a .tap file, and obviously is not in a teapot repository.
> I think it would be very easy to also support this. It is unrelated to
> my problem though. Just an enhancement wish...
> > When TclApp runs the list of packages available to wrap is dynamically
> > computed, by searching both these lists, then loading the .tap files
> > found and getting the lists of packages in the specified repositories.
> > Only the search lists are held in the configuration in the registry,
> > not the list of available packages derived from them.
> So, when I just installed ActiveTcl 8.5.4, and without touching the
> repository, the fact that I saw many available packages suggests that
> the repository created by the installer was already populated (as also
> pointed by Larry)?
Yes.
> I thought that these repositories were empty (at
> least this was the case with earlier ActiveTcl 8.5.x releases).
With 8.5.4 we started to fatten AT 8.5 up again, and we use a
preloaded teapot repository in the distribution to deliver the
packages upon installation.
> So,
> perhaps I got the wrong impression (that a list of available packages
> was "cached" somewhere). But all this is true only if 8.5.4 installs a
> non empty teapot repository. Is it?
See above.
AndreasK
> Yes, that all sounds innocently enough ... I will you contact off-
> group, directly by mail, and start asking more detailed questions
> about the state of the repository and your system, so that you don't
> have to post any internal info to the world.
Georgios and I have talked to each other over the last few days on
this and what is emerging is that this is likely not a problem in the
teapot/teacup specifically, but more general trouble with 'Shadow
Copies', a feature introduced by Vista. In essence a type of versioned
filesystem.
The problem seems to be, if an application uses the wrong runtime
(msvcrtd), it may get a shadow copy of a file, i.e. an old version,
instead of the current content, when reading a file. Any file.
In our specific case the repository INDEX had a shadow copy.
For teacup this is semi-fatal, a 'verify' will fail, and it may list
the wrong packages.
Tclsh is on the ohter hand ok, as it doesn't need the repository index
to load packages.
For TclApp it is more fatal as it may try to use a package for
wrapping which doesn't exist.
Like the base64 2.3.2 vs. 2.4 mismatch we saw in the message which
started this thread.
The higher layers have no defense against the lower parts lying to
them in part, and being truthful in other parts, painting an
inconsistent picture of the system.
We (ActiveState, all of us) will now have to figure out how to build
the Tcl core to prevent this type of thing from happening. This may
take a while.
Erik Leunissen
>
> The problem seems to be, if an application uses the wrong runtime
> (msvcrtd), it may get a shadow copy of a file, i.e. an old version,
> instead of the current content, when reading a file. Any file.
>
Well, that's a nice complement to behaviour commonly known as "dll hell"
(http://en.wikipedia.org/wiki/DLL_hell).
Are we perhaps witnessing consistency with respect to Microsofts
versioning policy?
Erik.
--
leunissen@ nl | Merge the left part of these two lines into one,
e. hccnet. | respecting a character's position in a line.