Take Command v11 RC1 (build 28) Uploaded
- Thread starter rconn
- Start date
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
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
My simple Tcl/Tk script (posted before) executes as expected from the prompt. Here's a new one.
File: test.tcl
Code:
puts "abc"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
On 2009-10-21 05:58, rconn wrote:
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.
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.
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
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
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:
Tim
Edit: For some reason, this message was not emailed to 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:
Code:
C:\Tcl\demos\Tk8.5>echo %@tcl[expr 123 + 456]
expr 123 + 456
C:\Tcl\demos\Tk8.5>tclsh
% expr 123 + 456
579
% exitEdit: For some reason, this message was not emailed to me.
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.
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
Tim
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
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