the purpose of tcllib
chedderslam
besides the package require command, is there anything else required
to make use of them?
Are there other packges you can include besides those in tcllib?
Thanks.
Neil Madden
Tcllib is one source of packages. There are plenty of other packages -
see the wiki http://wiki.tcl.tk/ which lists a rather large number of
them for various purposes (XML parsing, databases, Tk widgets, OO
frameworks, networking, etc, etc). There is also ActiveTcl's teapot
repository.
-- Neil
chedderslam
> Tcllib is one source of packages. There are plenty of other packages -
> see the wikihttp://wiki.tcl.tk/which lists a rather large number of
> them for various purposes (XML parsing, databases, Tk widgets, OO
> frameworks, networking, etc, etc). There is also ActiveTcl's teapot
> repository.
>
> -- Neil
How do you know what is installed in your environment? I guess I'm
trying to find out what's available to me locally, what's available
out there, and how to use it.
This is the latest activetcl install, btw.
Thanks.
Neil Madden
package names
That will give you a list of all the packages that could be found (it
can often be helpful to package require some dummy package first so that
a full search is done).
Larry W. Virden
> How do you know what is installed in your environment? I guess I'm
> trying to find out what's available to me locally, what's available
> out there, and how to use it.
>
> This is the latest activetcl install, btw.
Do you mean ActiveTcl 8.5.2 or 8.4.19?
ActiveTcl 8.4.19 is what sometimes is referred to as a "heavy" or
"batteries included" installation. There are numerous useful packages
installed in the initial install.
ActiveTcl 8.5.2 is what sometimes referred to as a "light"
installation (maybe it should be called a batteries available
install?)
In the latter case, the install environment is minimal.
In both cases, ActiveTcl has, within its bin directory, a command
called "teacup". This command can access an ActiveState software
repository, allowing you to install additional packages as you have
need/see fit/have space/etc.
Check out http://wiki.tcl.tk/teacup for some more information.
Certainly questions here are fine - however, the ActiveState
development group also maintains an ActiveTcl mailing list where one
can ask specific questions about the distribution.
Does that help?
Donald G Porter
>> How do you know what is installed in your environment?
> package names
> That will give you a list of all the packages that could be found
Sorry, no it won't.
[package names] tells you what package the current interp knows
about. There may be many more available for a successful
[package require] that the interp knows nothing about yet. It
gives at best a partial answer.
The issue is similar to the fact that [info commands] will not
tell you what commands you can successfully call, since it doesn't
account for the ability of [unknown] to create a missing command
'on demand'.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Donald G Porter
> [package names] tells you what package the current interp knows
> about. There may be many more available for a successful
> [package require] that the interp knows nothing about yet. It
> gives at best a partial answer.
A demonstration:
% info patch
8.5.2
% package require no-such-package
can't find package no-such-package
% lsearch [package names] platform::shell
-1
% package require platform::shell
1.1.3
chedderslam
Neil Madden
> Donald G Porter wrote:
>> [package names] tells you what package the current interp knows
>> about. There may be many more available for a successful
>> [package require] that the interp knows nothing about yet. It
>> gives at best a partial answer.
Sure, but that is much better than nothing. For instance, on my system:
% llength [package names]
567
I imagine the number of packages that don't show up is usually tiny in
comparison. (At least, as long as Tcl Modules don't catch on). Is there
a better alternative?
>
> A demonstration:
>
> % info patch
> 8.5.2
> % package require no-such-package
> can't find package no-such-package
> % lsearch [package names] platform::shell
> -1
> % package require platform::shell
> 1.1.3
I hadn't realised Tcl Modules exhibit this behaviour -- e.g.
platform::shell doesn't show up in tkcon's available packages list
either. That's disappointing.
-- Neil
Donald G Porter
> I imagine the number of packages that don't show up is usually tiny in
> comparison. (At least, as long as Tcl Modules don't catch on). Is there
> a better alternative?
No. The design flaw that [package] uses an extension hook,
[package unknown], to define the process of package finding,
while not putting in place a corresponding hook for control
over package installation means that strictly speaking the
set of packages installed and able to be [package require]d
cannot be introspected in a generally reliable way.
If you want to know whether a package is available, all you can
do is try to [package require] it and see if that succeeds.
Chris Krueger
system the tcl packages are located in /usr/lib/tcl8.4. You can look
around there to see what is installed. You can also download packages
from the web. The steps would be
tar xvzf package.tar.gz
cd package
./configure
make
make install
I usually use ./configure --prefix in order to install them to a
particular dir. Whatever you choose to do make sure that the dirs
containing the pacakges are in your auto_path variable
Chris
neuro...@gmail.com
As far as I can see - this is only an issue for Tcl Modules which are
installed in a namespaced fashion ie in subdirectories.
Most of my .tm files are directly in one of the paths returned by
[tcl::tm::list] and so show up in the [package names] list.
Julian
Helmut Giese
<chedd...@gmail.com> wrote:
>How do you know what is installed in your environment? I guess I'm
>trying to find out what's available to me locally, what's available
>out there, and how to use it.
Hi,
I find 'lspackages' invaluable You can find it on
http://wiki.tcl.tk/689
HTH
Helmut Giese
Donald G Porter
> As far as I can see - this is only an issue for Tcl Modules which are
> installed in a namespaced fashion ie in subdirectories.
> Most of my .tm files are directly in one of the paths returned by
> [tcl::tm::list] and so show up in the [package names] list.
That is currently true, but not part of the guarantees of the
[package] interface. The [package unknown] handler that finds
TMs could change its behavior on that point, or a completely
different [package unknown] handler with completely different
package discovery behavior could be dropped in place, by the app,
or by the site, or by the distribution.
neuro...@gmail.com
> neuronst...@gmail.com wrote:
> > As far as I can see - this is only an issue for Tcl Modules which are
> > installed in a namespaced fashion ie in subdirectories.
> > Most of my .tm files are directly in one of the paths returned by
> > [tcl::tm::list] and so show up in the [package names] list.
>
> That is currently true, but not part of the guarantees of the
> [package] interface. The [package unknown] handler that finds
> TMs could change its behavior on that point, or a completely
> different [package unknown] handler with completely different
> package discovery behavior could be dropped in place, by the app,
> or by the site, or by the distribution.
>
> --
> | Don Porter Mathematical and Computational Sciences Division |
> |http://math.nist.gov/~DPorter/ NIST |
> |______________________________________________________________________|
Yeah.. I've found the [package unknown] handling especially
unsatisfactory when I know I want to load a .tm or fail quickly.
Unfortunately the standard handler falls back to scanning the
filesystem looking for ordinary modules, which adds about 50ms for
each failed load. (there are often easily 10 or more failed loads in a
row under normal operation so it adds up to a noticeable delay)
At the moment I set ::auto_path to empty, and restore it after the
package require sequence.
I could also just redesign it to source the modules directly - but it
seems to me it would be nice to have a notion of package providers and
be able to query and manipulate them, or even specify providers in an
adhoc manner when doing a package require
e.g package require -providers {tm xxx} somemodule
[[package unknown]] behaviour seems very strange to me..
If I attempt to temporarily limit it to .tm modules using:
%package unknown ::tcl::tm::UnknownHandler
Then it actually seems to run the package-name as a command if it
doesn't find it!
e.g
%package require spud
invalid command name "spud"
%package require pwd
wrong # args: should be "pwd"
%package require puts
0-
Is it supposed to be legit to chop down the package unknown list to a
single entry like that, and if so - is the above a bug?
Julian
Donald G Porter
[::tcl::tm::UnknownHandler] takes the first argument to be an additional
package finding handler command, so that these commands can be chained
together. Try this instead:
proc no-op args {}
package unknown {::tcl::tm::UnknownHandler no-op}
Keep in mind you're intruding into Tcl internals when you do this, so
keep a close eye for any changes when you upgrade to a new release.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|