Take Command v11 RC1 (build 28) Uploaded

[rconn]

I've uploaded v11.0.28 (RC1) to the ftp and web autoupdater sites. This should address all known bugs, and it now includes support for Tk scripts.

 

[TimButterfield]

I renew my b27 comment about modifying the @tcl documentation to be about supporting 'Tcl expressions' and not 'Tcl/tk expressions.'

My simple Tcl/Tk script (posted before) executes as expected from the prompt. Here's a new one.

File: test.tcl

puts "abc"

C:\Tcl\demos\Tk8.5>test.tcl
abc

Unfortunately, this simple command line Tcl script now blocks until the Tk window is closed by the user. I understand you have no way of knowing what kind of script will be executed, Tcl vs Tcl/Tk, without actually parsing the script file(s) first. And, with included files possible, finding a Tk command or 'package require Tk' may be tedious. But, unless both Tcl scripts can be run as under tclsh and Tcl/Tk scripts run as under wish, the behavior may be viewed as 'wrong' by a user.

Tim

 

[fromano]

I get the error System Error: The program can't start because tk85.dll is missing from your system in TCMD x64 11.0.28 on Win7 Ultimate

 

[dim]

On 2009-10-21 05:58, rconn wrote:

> I've uploaded v11.0.28 (RC1) to the ftp and web autoupdater sites. This should address all known bugs, and it now includes support for Tk scripts.

Unfortunately tcc.exe and tcmd.exe (the x64 versions) now die on startup
with "This application has failed to start because tk85.dll was not
found. Re-installing the application may fix this problem."

Note that I don't have any trace of TCL or TK on my system, TCmd.ini
contains "Tcl=No", and there is no tcl85.dll or tk85.dll anywhere in my
PATH.

This problem does not occur with the x86 version, however.

 

[rconn]

> My simple Tcl/Tk script (posted before) executes as expected from the
> prompt. Here's a new one.
>
> File: test.tcl
>
> Code:
> ---------
> puts "abc"
> ---------
> C:\Tcl\demos\Tk8.5>test.tcl
> abc
>
> Unfortunately, this simple command line Tcl script now blocks until the
> Tk window is closed by the user. I understand you have no way of
> knowing what kind of script will be executed, Tcl vs Tcl/Tk, without
> actually parsing the script file(s) first. And, with included files
> possible, finding a Tk command or 'package require Tk' may be tedious.
> But, unless both Tcl scripts can be run as under tclsh and Tcl/Tk
> scripts run as under wish, the behavior may be viewed as 'wrong' by a
> user.

If you don't want the script to block, then there's no reason to execute it
from TCC -- just use tclsh.

The internal Tcl/Tk support is intended 99% for Tk scripts, as you will see
in future builds.

Rex Conn
JP Software

 

[TimButterfield]

If you don't want the script to block, then there's no reason to execute it from TCC -- just use tclsh.

That's fine. I just wanted to provide you with my feedback so you will know what to include in the documentation to manage user expectations, command line for Tcl/Tk and @tcl for Tcl.

The internal Tcl/Tk support is intended 99% for Tk scripts, as you will see
in future builds.

This reminds me of a feature request I made long ago. Hmmm. :)

Tim

 

[rconn]

> Unfortunately, this simple command line Tcl script now blocks until the
> Tk window is closed by the user. I understand you have no way of
> knowing what kind of script will be executed, Tcl vs Tcl/Tk, without
> actually parsing the script file(s) first. And, with included files
> possible, finding a Tk command or 'package require Tk' may be tedious.

Replace "tedious" with "impossible", given the number of ways that Tk can be
indirectly invoked. And the Tcl/Tk developers apparently don't have any way
of doing it, or they wouldn't need to create multiple variations of the
shell (which require the user to already know how whether it's a Tk script).

The best I can do is *not* do a Tk_Init before the script is invoked, which
requires the user to have a "package require tk" somewhere, and after the
Tcl_EvalFile look for Tk windows. This is necessary because unless I shut
down & reinitialize the interpreter, the next Tk script will fail -- it also
means you cannot have a persistent interpreter executing Tk scripts from the
command line.

I've also added a @TK var function which will allow you to execute a script
without the "package require tk", and which will always create the Tk window
& enter an event loop.

Rex Conn
JP Software

 

[TimButterfield]

The best I can do is *not* do a Tk_Init before the script is invoked, which requires the user to have a "package require tk" somewhere, and after the Tcl_EvalFile look for Tk windows. This is necessary because unless I shut down & reinitialize the interpreter, the next Tk script will fail -- it also means you cannot have a persistent interpreter executing Tk scripts from the command line.

Would it work to have an option for the user to choose which shell to use, tclsh or wish? Requiring the 'package require Tk' with wish would be acceptable for that option (at least for me).

I've also added a @TK var function which will allow you to execute a script without the "package require tk", and which will always create the Tk window & enter an event loop.

Perhaps there could be an optional parameter for both @tcl and @tk, to return the exit code instead of expression result.

Also, @tcl doesn't appear to return the results of an expression. Here's an example:

C:\Tcl\demos\Tk8.5>echo %@tcl[expr 123 + 456]
expr 123 + 456

C:\Tcl\demos\Tk8.5>tclsh
% expr 123 + 456
579
% exit

Tim

Edit: For some reason, this message was not emailed to me.

 

[rconn]

Would it work to have an option for the user to choose which shell to use, tclsh or wish? Requiring the 'package require Tk' with wish would be acceptable for that option (at least for me).

Perhaps there could be an optional parameter for both @tcl and @tk, to return the exit code instead of expression result.

Also, @tcl doesn't appear to return the results of an expression. Here's an example:

C:\Tcl\demos\Tk8.5>echo %@tcl[expr 123 + 456]
expr 123 + 456
 
C:\Tcl\demos\Tk8.5>tclsh
% expr 123 + 456
579
% exit

Not sure what you're referring to here -- TCC doesn't use any shell (tclsh or wish) to execute the Tcl/Tk scripts; it runs them internally.

I don't know of a way to have an option to return the result code without interfering with (unknowable) the argument syntax.

The @TCL result string is fixed in build 29.

 

[TimButterfield]

Not sure what you're referring to here -- TCC doesn't use any shell (tclsh or wish) to execute the Tcl/Tk scripts; it runs them internally.

I don't know of a way to have an option to return the result code without interfering with (unknowable) the argument syntax.

The @TCL result string is fixed in build 29.

Without integrated supported, the user would have to explicitly call either tclsh or wish to execute their script. My suggestion is to include a similar choice to set a default for the internal support. The user could choose whether the internal support should include the Tk window and event handler (for Tcl/Tk scripts) or not (for Tcl scripts). Further, something like a setdos command/parameter variant could be used to programmatically switch between the Tcl vs Tcl/tk internal support variations.

Tim

 

[rconn]

> Without integrated supported, the user would have to explicitly call
> either tclsh or wish to execute their script. My suggestion is to
> include a similar choice to set a default for the internal support.
> The user could choose whether the internal support should include the
> Tk window and event handler (for Tcl/Tk scripts) or not (for Tcl
> scripts). Further, something like a setdos command/parameter variant
> could be used to programmatically switch between the Tcl vs Tcl/tk
> internal support variations.

I don't think there's any need for that. In 11.0.29, TCC will execute the
script (via Tcl_EvalFile), and then look to see if a Tk window was created
(which will happen automatically if the script does something like "package
require tk"). If so, TCC enters an event loop; if not, it's assumed to be a
Tcl script and TCC will return immediately. If you want to make a script
that's uninterpretable even by the Tcl/tk parser, you can force either Tcl
or Tk interpretation by using @TCL and @TK.

The only potential problem I can see with this approach is if you want to
create a Tk script *without* an event loop -- but I don't think there's any
way to do that with tclsh or wish either.

Rex Conn
JP Software