1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Take Command v11 RC1 (build 28) Uploaded

Discussion in 'Support' started by rconn, Oct 20, 2009.

  1. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    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.
     
  2. TimButterfield

    Joined:
    May 20, 2008
    Messages:
    402
    Likes Received:
    2
    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
    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.

    Tim
     
  3. fromano

    Joined:
    May 20, 2008
    Messages:
    110
    Likes Received:
    0
    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
     
  4. dim

    dim Dimitry Andric

    Joined:
    May 31, 2008
    Messages:
    203
    Likes Received:
    0
    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.
     
  5. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    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
     
  6. TimButterfield

    Joined:
    May 20, 2008
    Messages:
    402
    Likes Received:
    2
    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.

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

    Tim
     
  7. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    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
     
  8. TimButterfield

    Joined:
    May 20, 2008
    Messages:
    402
    Likes Received:
    2
    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:
    Code:
    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.
     
  9. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    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.
     
  10. TimButterfield

    Joined:
    May 20, 2008
    Messages:
    402
    Likes Received:
    2
    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
     
  11. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    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
     

Share This Page