What: dqkit Where: https://sourceforge.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.10. Updated: 04/2006 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 set 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]snichols 01-16-2006. I tried setting the auto_path variable in the worker thread. The worker thread can not find the Tcl package in the starkit VFS. Any ideas? Thanks in advance.
- 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).
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 -threade.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 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 tclkits 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)JMN 2007-10-23 - still hoping for a threaded tclkit for windows & freebsd.I've revisited this on FreeBSD 6.2 (tclsh gen/buildkit build -tcl -tk -thread) - build still fails when linking:
[11/12] link
gcc -c -I. -I/usr/local/buildtcl/dqkit-20060505/src/tcl-8...
child process exited abnormally
while executing
"exec >@file5 2>@file5 gcc -c -I. -I/usr/local/buildtcl/dqkit-20060505/src/tcl-8.5.0/generic -I/usr/local/buildtcl/dqkit-20060505/src/tcl-8.5.0/unix -I..."
("eval" body line 1)
invoked from within
"eval [concat [list exec >@$fh 2>@$fh] $cmd]"
(procedure "out::oexec" line 5)
invoked from within
"out::oexec [concat [list [conf::x gcc]] [conf::c_if debug [list -g] [list]] [list -c] $I $D [list -DBUILD_tcl=1 -DSTATIC_BUILD=1 $DAR] [file join $di..."
(procedure "_link" line 81)
invoked from within
"_link $buildorder"
(procedure "main::build" line 25)
invoked from within
"main::[lindex $argv 0] [lrange $argv 1 end]"
invoked from within
"if {[llength $argv]>0} {
main::[lindex $argv 0] [lrange $argv 1 end]
exit 0
} else {
main::build {}
exit 0
}"
(file "gen/buildkit" line 1433)RZ I build kbskit Tclkit Kitgen Build System for windows with threads enabled (tcl/tk8.5b2). May be you can try to build on FreeBSD with./kbs.tcl -v -r install kbskit-8.5
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?TP Perhaps you need to
package require Tclxbefore using Tclx commands.
PAK - 2005.10.14 - BLT uses treeview.cur for treeview and hiertable but Windows can't find it in the virtual filesystem. To avoid errors, force a builtin resize cursor when running on windows:
package require Tk package require BLT option add *Hiertable.ResizeCursor size_we 100 option add *TreeView.ResizeCursor size_we 100 pack [blt::hiertable .t]Without the second option add I get the following error message:
bad cursor spec "@C:/.../dqkit.exe/lib/blt2.4/treeview.cur"
2004/11/02 snicholsI want to add my own Tcl extension within a Tcl thread using dqkit. I have tested my extension and its appears to be thread safe. Anyway, how do I make it so the package require within a Tcl thread can find my extension using dqkit? Do I need to compile DQKit with my custom tcl extension included, and if so how? I could not find any documentation on the dqkit project at sourceforge.netWK It's true; there is no documentation at this time. The basic idea is to create parts/yourextension.tcl and add -yourextensions as parameters, like:
tclsh gen/buildkit build -tcl -tk -thread -yourextensionAs for parts/yourextension.tcl, you can have a look at things like tdom.tcl or other ones. Some parts/*.tcl files have special handling for Windows, not sure why, but I assumed it's faster to work around them. This can be some old tcl.m4 file or any other issue.
See also Batteries Included, functionality which dqkit provides.
