tcllib-devel — Discussion of development for tcllib

Re: [Tcllib-devel] More file utilities ?

[Mark G. S. <mar...@ya...>]

Andreas Kupries wrote:

>I have (over time) collected a set of convenient commands operating
>on/with whole files which seem to belong directly into either the
>fileutil namespace, or a related namespace, like 'fileutil::FOO'.
>
>
>	touch PATH
>
>		Creates empty file at PATH. Deletes any pre-existing
>		file in this location.
>  
>
I believe fileutil::touch (or whatever) should be compatible with unix 
'touch' comand and NOT delete an existing file - it should only "Update 
the access and modification times of each FILE to the current 
time.existing file"

Also, the touch command is the only one which does not change the 
contents of a file, and maybe should be in a different namespace/package ?

-- 
Mark G. Saye
markgsaye @ yahoo.com

Re: [Tcllib-devel] More file utilities ?

[Arjen M. <arj...@wl...>]

Andreas Kupries wrote:

> Subject: [Tcllib-devel] More file utilities ?
> Date: Mon, 30 Jan 2006 21:27:08 -0800
> From: Andreas Kupries <aku...@sh...>
> To: Tcllib Development <tcl...@li...>
> 
> I have (over time) collected a set of convenient commands operating
> on/with whole files which seem to belong directly into either the
> fileutil namespace, or a related namespace, like 'fileutil::FOO'.
> 

These commands all seem to deal with the _contents_ of the files
whereas the fileutil commands deal with meta-information about
the files. Perhaps: fileutil::contents as a namespace?
(I do not think a new module would be appropriate)

Regards,

Arjen

[Tcllib-devel] More file utilities ?

[Andreas K. <aku...@sh...>]

I have (over time) collected a set of convenient commands operating
on/with whole files which seem to belong directly into either the
fileutil namespace, or a related namespace, like 'fileutil::FOO'.

Unfortunately I also have trouble to find a proper name for FOO. Note
that we also might wish to change their names when they go into their
namespace, to remove redundancies ('file'), or have their final names
reflect their behavior more correctly (touch, hack_file).

Below are the commands collected so far. I would like to get opinions
on whether these commands should really be put into Tcllib, and if
yes, where.

	getfile PATH

		Returns contents of file. Assumes that file is text,
		and in system encoding.

		I.e. loads the file completely into memory

	putfile PATH TEXT

		Writes text as the new content of the file.
		Note: Does _not_ add a traling \n to the data.

	touch PATH

		Creates empty file at PATH. Deletes any pre-existing
		file in this location.

	appendto PATH DATA

		See putfile, but appends the data to existing
		content. Returns the location of the first character
		of the appended data in the file.

	insertat PATH AT DATA

		Inserts data at offset AT into the file.

	removeat PATH AT N

		Removes N characters from the file, starting at
		offset AT.

	hack_file PATH KEY VAL ...

		Takes the list of keys and values and applies them to
		the contents of the file, via [string map].

	hack_file_copy PATHin PATHout KEY VAL ...

		Like hack_file, but writes the result to a different
		file.


-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

[Tcllib-devel] Tcllib testsuite work in the recent past ...

[Andreas K. <aku...@sh...>]

Hi ya all.

People might have seen the series of large commits I did in the last
days and week. This mail is just a heads up of what I did, and why.

After a long time of procrastinating on this I finally managed to get
the motivation to dive into the Tcllib testsuite as a whole and give
it a nice scrubbing.

For example, while most of the testsuites for the various modules and
packages had the correct code to load the local sources for testing
instead of from (external) installation we did still had a number of
packages which did it wrong, or only half-right. And those which did
it completely right not only had heaps of ugliness coming before the
actual set of tests, but the code in question was in essence
replicated all over.

Half of the work I did was to draw the common parts out of this code
and put them into a separate file to be shared by all testsuites. This
additionally had the benefit of hiding all the ugly machinery behind
commands with (nearly) self-explanatory names.

The other half then was just drudgery, replacing all the existing
replicated boilerplate with much small prologues using all the shiny
new stuff.

As an end result the headers of all the .test files should now be much
more readable when it comes to declaring the needs of the contained
testsuite, be it dependencies on versions of Tcl and tcltest, or the
loading of the package under test and whatever other supporting files
and packages are needed.

It should make the creation of new testsuites for Tcllib easier as
well.


Now, while I consider the main cleanup of the testsuites to be done
there are still places in there which could be better. Namely:

- A lot of the testsuites under "struct" declare helper commands, some
  of them quite large. We should consider to put them into their own
  file and then declare that as a support.

- The testsuites under "math" have similar problems. They are a bit
  worse as well IMHO, as their helpers are also duplicated across the
  testsuites. And there seem to be several different implementations
  of some of them floating around.

  One helper for example compares two floating point numbers for
  equality within 4 digits after the decimal point. I know I have
  seen two different implementations of that, and I believe that there
  might actually be three.

- A number of packages have different implementations as well, pure
  Tcl vs. one or more accelerators. Only some of them have logic to
  allow the switching between implementations at runtime. And very few
  of the testsuites actually test all of the implementations they can
  can lay their hands on as well.

  There is opportunity for refactoring and generalization, for both
  package implementations, and accompanying testsuites.


So, even with this cleanup now behind us there are still lots of
things we can do to make Tcllib better and more polished. Lets go
forward.

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

[Tcllib-devel] Vacation

[Andreas K. <aku...@sh...>]

Hi all.

A quick note: I am going on vacation upcoming Saturday, Dec 10, and will be 
gone for a month. I will have no internet connection.

Have a nice X-mas, and a happy new year.

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

[Tcllib-devel] uri ftp path bug

[Aamer A. <aa...@gm...>]

Hello,

uri ftp is currently returning the path with ':'

% uri::split "ftp://aakhter@10.1.1.1:/var/tmp/:3"
port {} path :/var/tmp/:3 scheme ftp host 10.1.1.1 type {} user aakhter pwd=
 {}

Is there any reason for maintaining the ':' ?

--
Aamer Akhter / aa...@gm...

Re: [Tcllib-devel] Version numbers ! ...

[<ke...@cr...>]

Ca...@ph... said:
> My memory of version arithmetic was that "package require FOO 1.0"
> means that 1.0, 1.0.1, 1.0.8, ... are all accepted, but 0.9 is not.
> Have I had that wrong all along? 

The discrepancy is not between [package require] and [package provide],
but rather between [package ifneeded] and [package provide].  The package's
index script (which executes [package ifneeded]) is expected to be an
exact match in version number to the package itself.


--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
ke...@cr...           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA

Re: [Tcllib-devel] Version numbers ! ...

[Cameron L. <Ca...@Ph...>]

On Tue, Nov 15, 2005 at 10:24:14PM -0800, Andreas Kupries wrote:
			.
			.
			.
> Recently we had a change in the Tcl core, in the handling of errors
> thrown by the package management. A bug was fixed, a bug whose
			.
			.
			.
> 	pkgIndex.tcl:
> 		package ifneeded FOO 1.0 "source $dir/foo.tcl"
> 
> 	And foo.tcl:
> 		package provide FOO 1.0.1
> 
> 	This discrepance, 1.0 vs 1.0.1, was always an error, now such
> 	an error is actually reported.
			.
			.
			.
I'd welcome a few more words of explanation.

My memory of version arithmetic was that "package require FOO 1.0"
means that 1.0, 1.0.1, 1.0.8, ... are all accepted, but 0.9 is not.
Have I had that wrong all along?

[Tcllib-devel] Version numbers ! ...

[Andreas K. <aku...@sh...>]

No, this is _not_ about which version number to give to the next
release of Tcllib.

Recently we had a change in the Tcl core, in the handling of errors
thrown by the package management. A bug was fixed, a bug whose
presence swallowed errors and their messages.

The net effect of the fix from the user perspective is that the
package management now _strictly enforces_ that the 'package ifneeded'
and 'package provide' commands for a package have to use _identical_
version numbers.

Example:

	pkgIndex.tcl:
		package ifneeded FOO 1.0 "source $dir/foo.tcl"

	And foo.tcl:
		package provide FOO 1.0.1

	This discrepance, 1.0 vs 1.0.1, was always an error, now such
	an error is actually reported.

In the recent weeks I ran into lots of packages which had such
discrepances. Accumulated cruft, the fact that such problems were not
reported by the core caused people to quickly forget about keeping the
version number in sync.

Tcllib was quite lucky in this regard. Whenever we made a release the
release manager went through all packages and ensured that everything
was ship-shape.

So, if you commit a change to a package which touches version numbers
please take the extra minute and check that truly all of the relevant
locations have been updated and are in sync.

Before the laziness of not checking this was fine. Now it bites.

And yes, we do have tools which help us to do such checks. It is
called

    .../tcllib > ./sak.tcl validate <module>

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

Re: [Tcllib-devel] Tklib 0.4.1 is released

[Csaba N. <csa...@t-...>]

Andreas Kupries schrieb:
> Csaba Nemethi volunteered and has posted the announcement to
> c.l.t.
> 
> 	Thanks!
> 

Unfortunately, my e-mail client seems to tend to alter the formatting 
(although it is configured to send the messages in pure text format). 
For this reason, the columns are not aligned properly in that 
announcement. :-(

-- 
Csaba Nemethi   http://www.nemethi.de   mailto:csa...@t-...

Re: [Tcllib-devel] Tklib 0.4.1 is released

[Andreas K. <aku...@sh...>]

> It seems that my netnews installation has developed problems with
> posting news. Can someone post this announcement to comp.lang.tcl in
> my stead ? Note that I have sent a mail to the
> comp.lang.tcl.announce moderator, so this is not necessary [*].
 
> To avoid confusion over who is doing the posting, i.e. to avoid
> duplicate postings from several people anybody willing to do so
> please coordinate through me.

Csaba Nemethi volunteered and has posted the announcement to
c.l.t.

	Thanks!

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

Re: [Tcllib-devel] Re: file appender for logger

[Aamer A. <aa...@gm...>]

Actually, I was hoping that someone might find an error or an
alternate method. I'll commit and we'll see how it goes.

Thanks.


On 11/12/05, David N. Welton <da...@de...> wrote:
> Aamer Akhter wrote:
> > I haven't received a response to this, so I'm guessing it is ok to comm=
it it.
>
> If you find it useful, I suppose it is to other people, so go ahead.
>
> --
> David N. Welton
> - http://www.dedasys.com/davidw/
>
> Linux, Open Source Consulting
> - http://www.dedasys.com/
>


--
Aamer Akhter / aa...@gm...

Re: [Tcllib-devel] Re: file appender for logger

[David N. W. <da...@de...>]

Aamer Akhter wrote:
> I haven't received a response to this, so I'm guessing it is ok to commit it.

If you find it useful, I suppose it is to other people, so go ahead.

-- 
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

[Tcllib-devel] Re: file appender for logger

[Aamer A. <aa...@gm...>]

I haven't received a response to this, so I'm guessing it is ok to commit i=
t.

thanks.


On 11/9/05, Aamer Akhter <aa...@gm...> wrote:
> Folks,
>
> I've added a new appender type (fileAppend) to the logger appenders.
> The diff is avaliable at:
>
> https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1352763&gro=
up_id=3D12883&atid=3D312883
>
> request id# 1352763
>
> Summary of changes:
>
> * changes to man pages
> * new appender fileAppend
> * fixes to createLogProc to allow channel selection
> * tests
>
> example of usage:
>
> logger::utils::applyAppender \
>             -appender fileAppend -appenderArgs {-outputChannel stderr}
>
> In this example the output channel is stderr, but it could as easily
> be a file chanel.
>
> Comments and suggestions are welcome.
>
> --
> Aamer Akhter / aa...@gm...
>


--
Aamer Akhter / aa...@gm...

Re: [Tcllib-devel] Tklib 0.4.1 is released

[Andreas K. <aku...@sh...>]

> 
> [[ Note: The 0.4.1 release fixes a bug in the Tablelist package index
>    which made it unuseable after installation, but is otherwise
>    unchanged from 0.4.
>  ]]
> 
> New in Tklib 0.4
> =================

So, this announcemnt also means that the tklib CVS is now unfrozen
again, i.e. open to new commits. Hopefully this initial release also
spurs people to submit both ideas and implementations for them.


It seems that my netnews installation has developed problems with
posting news. Can someone post this announcement to comp.lang.tcl in
my stead ? Note that I have sent a mail to the comp.lang.tcl.announce
moderator, so this is not necessary [*].

To avoid confusion over who is doing the posting, i.e. to avoid
duplicate postings from several people anybody willing to do so please
coordinate through me.

[*] Although I fully expect the message to bounce, as it happened to
    the last one (the Tcllib 1.4 announcement). And even if not, the
    clta moderator seems to clean his queue only once every few months
    now.

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

[Tcllib-devel] Tklib 0.4.1 is released

[Andreas K. <aku...@sh...>]

[[ Note: The 0.4.1 release fixes a bug in the Tablelist package index
   which made it unuseable after installation, but is otherwise
   unchanged from 0.4.
 ]]

New in Tklib 0.4
=================
                                        Tcllib 1.8
Module          Package                 New Version     Comments
------          -------                 -----------     
-------------------------------
autoscroll	autoscroll              1.1		Automatic mapping of scrollbars
ctext		ctext                   3.1		A text widget with highlighting support
cursor		cursor                  0.1		Tk cursor routines
datefield	datefield               0.1		Tk datefield widget
getstring	getstring               0.1		A dialog which prompts for a string 
input
history		history                 0.1		Provides a history for Entry widgets
ico		ico                     0.3		Reading and writing windows icons
ipentry		ipentry                 0.1		An IP address entry widget
plotchart	Plotchart               1.1		Simple plotting and charting package
------          -------                 -----------     
-------------------------------
style		style                   0.3		Theming via tk options.
		style::as               1.3
		style::lobster          0.2
------          -------                 -----------     
-------------------------------
swaplist	swaplist                0.1		A dialog which allows a user to
							move options between two lists
------          -------                 -----------     
-------------------------------
tablelist	tablelist		4.2		Table widget.
tkpiechart	tkpiechart              6.6		2D or 3D pie chart object in a canvas
------          -------                 -----------     
-------------------------------
tooltip		tipstack                1.0		Tooltip management
		tooltip                 1.1
------          -------                 -----------     
-------------------------------
widget		widget                  3.0		Megawidget package (Snidgets).
		widget::dialog          1.2
		widget::panelframe      1.0
		widget::ruler           1.0
		widget::screenruler     1.1
		widget::scrolledwindow  1.0
		widget::superframe      1.0
------          -------                 -----------     
-------------------------------

Changes
=======

This is the first release of Tklib, rhus there cannot be any changes, only new 
code.

Unchanged Modules/Packages
==========================

Nothing can be unchanged.

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

RE: [Tcllib-devel] SNIT enhancement

[Jeff H. <je...@Ac...>]

Damon Courtney wrote:
>     Would anyone be opposed to me adding a -validtype argument to 
> options in SNIT?  The purpose is to add a feature that nearly every 
> megawidget system needs but most write their own for.  Goes like this:
	...
> validation of an option based on type.  The types I've defined are:
> 
> boolean
> color
> enum
> int
> nullboolean (can be boolean or null)
> padding (can be a single number or a pair of numbers)

This has already been covered on the snit mailing list in August
(I brought it up).  You can find the posts in the archives of
August 2005, but my proposal was essentially:

option -foo -type ...
1	{enum [list of values]}
2	{int    ?-list {minlen maxlen}? ?{min max}? ?...?}
3	{double ?-list {minlen maxlen}? ?{min max}? ?...?}
4	{pixels ?-list {minlen maxlen}? ?{min max}? ?...?}
5	{window ?$parent?} (uses [winfo exists])
6	{bool}
7	{method $snitmethod ?arg? ?arg?}
8	{command $proc ?arg? ?arg?}
9	{regexp ?-nocase? $RE}
10	{glob ?-nocase? $pattern}

Stuff from Tk_Config that might be checkable:
	color
	cursor
	font

The -list option handle multiple of the same type (like for -padx).
This covers just about everything, I think.

Jeff

Re: [Tcllib-devel] SNIT enhancement

[Damon C. <da...@tc...>]

> Why not just make [snit::validateOption] public and
> use [... -validatemethod [list snit::validateOption $type]]?

    Because that annoys me. 0-]  And, -validatemethod specifies the name
of a method internal to the class that will handle the validation
thereby forcing me to create a method in every class to validate. 
This is what most people are already doing, and it's what I don't want
to do.

>> The types I've defined are:
>>
>> boolean
>> color
>> enum
>> int
>> nullboolean (can be boolean or null)
>   ^^^^^^^^^^^
>
> This one is a warning sign -- I can envision needing
> 'nullint', 'nullcolor', and 'nullpadding' too (e.g.,
> Tile-based megawidgets would probably want to allow
> NULL values for many options); which would either lead
> to a proliferation of option types, or a new "-allownulls"
> option.

    Agreed.  This was a carryover from BWidget.  I think it should just be:

option -foo -validtype {boolean 1} ; ## The 1 says that nulls are allowed.
option -bar -validtype {int 0}     ; ## The 0 says nulls are not allowed.

    0 would be the default if not specified.

> I think making 'snit::validateOption' public (and adding
> any new validation-related options to *that* routine)
> would be a better factoring.

    Well, either way we need to add an argument to options.  It's either
gonna' be something like -validateproc (instead of -validatemethod) or
-validtype (which I think is cleaner).  Or, we can modify
-validatemethod to take a proc name, but then it's not really a
validate METHOD.  And, how would you distinguish between a method name
and a proc name?  Fully-qualified name?

D

Re: [Tcllib-devel] SNIT enhancement

[Joe E. <jen...@fl...>]

Damon Courtney wrote:
>     Would anyone be opposed to me adding a -validtype argument to
> options in SNIT?  [...]
>     All it really does is override the -validatemethod for the given
> option with a proc called snit::validateOption that does the very basic
> validation of an option based on type.

Why not just make [snit::validateOption] public and
use [... -validatemethod [list snit::validateOption $type]]?

> The types I've defined are:
>
> boolean
> color
> enum
> int
> nullboolean (can be boolean or null)
  ^^^^^^^^^^^

This one is a warning sign -- I can envision needing
'nullint', 'nullcolor', and 'nullpadding' too (e.g.,
Tile-based megawidgets would probably want to allow
NULL values for many options); which would either lead
to a proliferation of option types, or a new "-allownulls"
option.

I think making 'snit::validateOption' public (and adding
any new validation-related options to *that* routine)
would be a better factoring.


--Joe English

  jen...@fl...

[Tcllib-devel] file appender for logger

[Aamer A. <aa...@gm...>]

Folks,

I've added a new appender type (fileAppend) to the logger appenders.
The diff is avaliable at:

https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1352763&group=
_id=3D12883&atid=3D312883

request id# 1352763

Summary of changes:

* changes to man pages
* new appender fileAppend
* fixes to createLogProc to allow channel selection
* tests

example of usage:

logger::utils::applyAppender \
 =09    -appender fileAppend -appenderArgs {-outputChannel stderr}

In this example the output channel is stderr, but it could as easily
be a file chanel.

Comments and suggestions are welcome.

--
Aamer Akhter / aa...@gm...

[Tcllib-devel] SNIT enhancement

[Damon C. <da...@tc...>]

All,

    Would anyone be opposed to me adding a -validtype argument to 
options in SNIT?  The purpose is to add a feature that nearly every 
megawidget system needs but most write their own for.  Goes like this:

option add -state -default normal -validtype {enum {disabled normal}}
option add -background -default white -validtype color
option add -autoscroll -default 1 -validtype boolean
option add -index -default 0 -validtype int
etc..

    All it really does is override the -validatemethod for the given 
option with a proc called snit::validateOption that does the very basic 
validation of an option based on type.  The types I've defined are:

boolean
color
enum
int
nullboolean (can be boolean or null)
padding (can be a single number or a pair of numbers)

    There are more you can add, but that is all that BWidget uses, and 
it pretty much covers the basics.  I already have the code done if 
everyone can agree that it's a worthwhile change.  I'd really hate to 
see every single megawidget system built on top of SNIT have to define 
all this themselves.  It's a fundamental piece.  Even Tk has a standard 
routine for checking options (at the C level, mind you).

Damon

RE: [Tcllib-devel] BWidget and Tile

[Damon C. <da...@tc...>]

> IMO BWidgets won't "survive" the OO transition without a
> major rewrite.  I for one am duplicating BWidgets into my
> own tklib widget package, which is snidget based (and thus
> closer to what the OO would be).  These have different
> options, and perhaps different behaviors, and more
> importantly assume you already are using all that Tk 8.4
> and Ttk has to offer.

    I'd be more than happy to port BWidgets to SNIT if I had some kind of
assurance that SNIT would be the megawidget package of choice for the
core.  We have too many of these damn things.  SNIT is great, but it's
a lot of work to port BWidgets over only to find out that when OO gets
in the core, a whole new megawidget syntax will be built on top of
that.

    I assume SNIT will be rewritten in the core OO once 8.5 is released. 
Can you say, with any certainty, that SNIT's syntax will be the
megawidget syntax of choice?  If so, I'll gladly put in the work to
port BWidgets to SNIT with the idea that it will be REALLY fast in the
8.5 release.

D

RE: [Tcllib-devel] BWidget and Tile

[Jeff H. <je...@Ac...>]

Damon Courtney wrote:
>     Should BWidget do what Tile used to do and just ignore 
> the options passed that are not Ttk options?  Tile has now 
> removed all of these "dummy" options, but I'm wondering if 
> BWidget shouldn't do this to avoid upgrade problems?
> 
>     Any thoughts?  I'm looking forward to the future of 
> BWidgets being object-oriented with the new Tcl OO system, 
> but for now, I need to get it working with Tile and playing 
> nice.  I just need some direction from someone other than me. 
>  I don't like developing in a vacuum.

IMO BWidgets won't "survive" the OO transition without a
major rewrite.  I for one am duplicating BWidgets into my
own tklib widget package, which is snidget based (and thus
closer to what the OO would be).  These have different
options, and perhaps different behaviors, and more
importantly assume you already are using all that Tk 8.4
and Ttk has to offer.

Jeff

[Tcllib-devel] BWidget and Tile

[Damon C. <da...@tc...>]

    Should BWidget do what Tile used to do and just ignore the options
passed that are not Ttk options?  Tile has now removed all of these
"dummy" options, but I'm wondering if BWidget shouldn't do this to
avoid upgrade problems?

    Any thoughts?  I'm looking forward to the future of BWidgets being
object-oriented with the new Tcl OO system, but for now, I need to get
it working with Tile and playing nice.  I just need some direction
from someone other than me.  I don't like developing in a vacuum.

D

RE: [Tcllib-devel] Tklib state ?

[Andreas K. <and...@Ac...>]

Csaba of tablelist had some comments about the pre-release as well, sent
directly to myself. Incomplete list of contributors and bad stuff in the
.tap file ... I have committed fixes for these problems and generated new
pre-release archives.

  	http://www.purl.org/net/akupries//soft/clt-arch/tklib-0.4-1.kit
  	http://www.purl.org/net/akupries//soft/clt-arch/tklib-0.4-1.zip
  	http://www.purl.org/net/akupries//soft/clt-arch/tklib-0.4-1.tar.gz
  	http://www.purl.org/net/akupries//soft/clt-arch/tklib-0.4-1.tar.bz2

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com, a division of Sophos
	Tel: +1 604 484 6491