Version 21 of dqkit

Updated 2005-09-22 20:15:18

"Dqkit is like tclkit on steroids. It includes tcl, tk, metakit, vfs, zlib, tclx, itcl, itk, iwidgets, blt, tbcload, tclsqlite and openssl+tls", according to fan Bob Techentin. It also includes threading. Created by Wojciech Kocjan.

 What: dqkit
 Where: http://sf.net/projects/nstclhttpd
        http://www.sf.net/projects/dqsoftware
 Description: A single file executable which implements a
        tcl interpreter and various extensions.  Based on
        tclkit concept, but includes more extensions,
        at the cost of a larger runtime size.
        Currently at version 0.0 .
 Updated: 09/2004
 Contact: See web site

snichols I recently downloaded the dqkit and dqkitsh executibles for Windows from SourceForge. I am trying to use the Thread extension and another custom package that works with regular kit files. Where is dqkit looking for packages within a Thread pool? It can not find my packages when I do a package require. It works fine from my compiled Tcl Thread interp, but not dqkit. Is there something I need to do so it knows where to find my custom packages in my VFS kit file? Thanks in advance. S Nichols.

Wojciech Kocjan I think it doesn't set auto_path correctly. The easiest thing to do is simply send the right auto_path upon creation. This is actually tricky, because doing it at dqkit level would require many changes, but on the other hand doing it by the person using dqkit is just one line. So I chose the one line solution. And the following can also be used in any situation, I can't imagine why a thread would want a different auto_path by default...

 set tid [thread::create]
 thread::send $tid [list set ::auto_path $::auto_path]

Q: are the sources for dqkit available? A: I see them. Look for dqkit-sources-* in the file list PAK

        (on the sf.net web sites).

Q: was blt compiled with stubs for this kit? A: No. BLT is built in to the underlying wish PAK


JMN 2004-09-30 I tried building a minimal dqkit on Windows (with & without MinGW) and on FreeBSD but both failed with unenlightening error messages.

tclsh gen/buildkit build -tcl -tk -thread

e.g on windows NT:

 [ 3/11] tcl
     sh autoconf
 child process exited abnormally
     while executing
 "exec >@file124b340 2>@file124b340 sh autocon
 ...
     (file "gen/buildkit" line 1055)

On FreeBSD it got a little further... died at step 10/11 when trying to link.

Building software is always such a lottery... I don't hold much hope of the situation ever evolving much from the dogs-breakfast it it is today.

I guess Batteries Included tclkits are an acknowledgement of the sheer complexity of the task of ongoing provision of buildable sources across multiple platforms.. but for now, I usually have to build from source to use the packages I want on my chosen primary platforms of Windows & FreeBSD. The problem is that as in the case above, there are so many ways for things to go wrong and often very litle chance for a non-c programmer such as myself to diagnose & fix the errors.

Unfortunately binary packages for FreeBSD are rare; particularly if you're trying to create a multi-platform tclkit with package versions in sync. When you do find binaries, they may not have been built with the options you require - such as the unfortunate 2nd-class citizenship that threaded builds still seems to have in the Tcl world.

If anyone has some links to downloadable binaries of reasonably recent threaded tlkits for Windows & FreeBSD it'd be much appreciated. (even an un-threaded post tcl8.4.4 tclkit where Tk isn't broken on FreeBSD 5.x would be nice)


KPR - 2005.09.22 - I grabbed the Windows version of dqkit from SourceForge. I was excited about the inclusion of tclX, specifically (don't laugh) the keyed list commands. However, apon running Tkcon with dqkit (dqkit-Win32-i386-all-v0.4.exe) I get "invalid command name 'keylset'". Any idea why this is?


See also Batteries Included, functionality which dqkit provides.


Category Distribution