The Simplest Steps to Converting TCL TK to a Stand Alone Application - tcl

After running into major compatitiblity problems with C#, ASP.NET, MS Access, Linux, and Mono, I've decided to program in a language that is cross-platform, open source, and compatible with embedded databases that are also compatible with many platforms. I narrowed my choice down to TCL.
Before I began a sample application with TCL, I wanted to see how easy it was to create a stand alone application. I purchased a book entitled "Practical Programming in TCL and TK", downloaded TCLkit, and FreeWrap, yet I am having troubles finding a methodological way to convert TCL in TK (Wish) into a standalone application.
Would anyone be able to provide simple steps towards converting a TCL TK script, such as a label with text on it, into an application, or a web resource that has a pretty straight forward explanation?

To build a starpack you need a) a tclkit runtime, b) sdx.kit. You also need a "basekit", the executable that will be wrapped with your tcl code. For this example I'll assume you're creating an application for the same platform you are running on. You can create a basekit by simply copying tclkit (or tclkit.exe on windows) to another name, such as "basekit"
% ls
sdx.kit tclkit
% cp tclkit basekit
% ls
basekit sdx.kit tclkit
Now, create the code that you want to have wrapped into an executable. The convention is to create a directory with the name of your app and the suffix ".vfs" (for 'virtual file system'), then create a file named 'main.tcl' in that directory:
% mkdir myapp.vfs
% cat > myapp.vfs/main.tcl
package require Tk
label .l -text "Hello, world"
pack .l
^D
% ls myapp.vfs
main.tcl
Now to do the wrapping: for this you'll need the sdx.kit file. Assuming it and tclkit (or tclkit.exe) are in your current working directory, you wrap your app like this:
% ./tclkit sdx.kit wrap myapp -runtime basekit
1 updates applied
% ls
basekit myapp myapp.vfs sdx.kit tclkit
The wrap command knows when you give it the argument "myapp" that it should wrap the contents of myapp.vfs, and that it should look for a file named "main.tcl" in that directory to be the program entry point. You can put whatever other files you want in that directory and they will all be wrapped, including platform-specific binary files, image files and anything else you want bundled up.
You now have an executable file, 'myapp', that is the wrapped application.
If you have the tclkits for different architectures you can use them (replacing 'basekit' on the command line with the kit for the target architecture) to cross-compile for other platforms.
For more information see How to create my first Starpack on the Tcl'ers Wiki

kitgen build system may also help you at the beginning.

Related

A problem with creating directories in tcl

I am writing a code in tcl using windows. When I try to create a folder using this command
set FileName "GVOutPut";
file mkdir $FileName;
i get this error:
can't create directory "GVOutPut": permission denied
while executing
"file mkdir $FileName"
how could i solve this problem?
You should check that the current directory (puts [pwd]) is the directory where you expect the new directory to be created in instead of being somewhere where normal users can't write by default. It is very easy for that to be different in a GUI program than for a text program; the defaults vary (due to the different ways that they're launched by the OS). It often pays to use full pathnames in your programs, or to make things all relative to a known location. You can use the cd command to set the current directory.
Alternatively, launch the program from an elevated shell. But you probably don't want that option as it has a lot of non-trivial consequences.

Compiling a program on a server

I'm new to servers and programming in general, and I have a question regarding remote acces to a server, and how much I can actually do on it.
The thin is I have a working program on a linux server, which I acces with my windows machine using mobaxterm. I can acces the server, I see folders and a cmd line, where I can compile a makefile. Everything runs well, however when I run the makefile it just compiles, and doesn't do anything. No error messages, but also no opening of a program. I don't understand anything. Is it a delimitation of the servers structure, that it can only store files on it?
When you compile under linux using a make, it produces an executable but does not run it. Make builds executable objects, but it does not run them. You should include your makefile in the question (reduced to a minimum if it is large). Inside it, you will see that it generates a executable file with a specific name. To run it, you need to invoke this from the command line.
To find out what it is building, a quick way is to type "make clean" (press enter of course) to clean up any built objects. Then type the "ls" command to see what is in your directory.
Next, build the program with the "make" command, then type "ls" to see what has been added. Ignore any new files that end in .o or .a or .so and look for any new files. These are the files built by make and at least one of them is the program you built.
Assuming you found a new file called "myprogram". To run it, type:
./myprogram

tcl spawn sftp not working

I am trying to run a very simple tcl script
package require Expect
spawn sftp user#host
the error I get is
The system cannot find the file specified.
while executing
"spawn sftp user#host"
The only reason I see it's that sftp path should be specified somehow. I call this from a batch script and I've also tried changing the directory to sftp location before calling the script but the error is still the same.
By far the most likely cause of the issue here is that the sftp program is not in a directory that is on your PATH. The concept is almost the same across platforms, but with some minor niggles.
Working with the Unix PATH
Check to see if sftp is available in a PATH-known directory by typing:
which sftp
At your shell prompt. It should respond with the location of the sftp program, but if it isn't found then you get no response at all. If it isn't found, you'll need to find it yourself and add its location (strictly, the directory that contains the program) to the PATH. Find the program with something like:
locate sftp
Or (very slow!):
find / -name sftp -print
To append a directory to the PATH, do this in your shell:
PATH=$PATH:/the/dir/to/append
You can add a directory within the Expect script too (as long as it is before the spawn, of course!):
append env(PATH) : /the/dir/to/append
Working with the Windows PATH
On Windows, use Windows Search (Windows+F IIRC) and look for a file called sftp.exe (there's also a command line search tool, but I forget how to use it).
With the Windows PATH, a little more care is required:
append env(PATH) ";" {C:\the\dir\to\append}
# Or this...
append env(PATH) ";" [file nativename C:/the/dir/to/append]
Which is to say, the Windows PATH uses a different separator character (because : is used for separating drive names from directory parts) and the native name of the directory must be used, rather than the somewhat-more-convenient forward-slash variation (the backslashes interact with Tcl's syntax, hence the {braces}). Forward-slashes can be used provided you use file nativename to convert before appending, as in my second version.
Some Tcl Techniques that can Help
You can use the Tcl command auto_execok to find out whether a program is on your PATH or not. For example:
puts [auto_execok sftp]
However, for some commands (notably start on Windows) you get a more complex response; the command really exists as part of the code that supports interactive Tcl usage, describing how to run some external program which can sometimes be a lot more complex than it appears to be at first glance. Still, it approximates to a cross-platform version of which as listed in the beginning of this answer...
Tcl 8.6 provides $tcl_platform(pathSeparator) variable as a way to get the PATH element separator character (a : or ;, depending on platform). Probably doesn't help you though, as 8.6 hasn't yet been distributed as widely as previous versions.

configure file name for Tcl/Tk

When you build Tcl/Tk by default it creates the files
tclsh85
wish85
However many programs call tclsh and wish. This is one fix for that
cp tclsh85 tclsh
cp wish85 wish
However, can you simply build tclsh and wish directly, perhaps using a configure argument?
This behavior is The Right Thing as it allows several versions of the interpreter and its libraries to coexist in the system. The system, in turn, does provide a way to "bless" one of the version as "default" — for instance, Debian provides "alternatives". In essence, usually a symlink with the "canonical" name is created pointing to the real executable, like /usr/bin/tclsh → /usr/bin/tclsh85. And with the "blessed" version available via such a symlink for the applications that do not care about the precise version of the runtime, certain other applications still can pick some specific runtime version by referring to the interpreter's real executable name.
This also provides an easy way to test an existing program against an experimental runtime version: you just run /usr/bin/tclsh86 /path/to/the/script.tcl instead of just running /path/to/the/script.tcl as usually which relies on the shebang to pick the interpreter.
A long time ago, the builds of Tcl and Tk used to work in the way you describe. It was changed to the current system (putting the version number in the name) to allow multiple versions to coexist more smoothly; this was a very strong demand from the user community at the time.
Symlink the version-less filenames to the real ones (or use the mechanism of your distribution) if you want to give up control over which version to use. Alternatively, use this (fairly horrible) piece of mixed shell/Tcl code at the top of your files:
#!/bin/sh
# Try with a versionless name \
exec tclsh "$0" ${1+"$#"}
# Otherwise, try with tclsh8.6 \
exec tclsh8.6 "$0" ${1+"$#"}
# Otherwise, try with tclsh8.5 \
exec tclsh8.5 "$0" ${1+"$#"}
# Otherwise, try with tclsh8.4 \
exec tclsh8.4 "$0" ${1+"$#"}
# Otherwise... well... give up! \
echo "no suitable Tcl interpreter" >&1; exit 1
This relies on the fact that Tcl, unlike the Unix shell, treats a \ at the end of a comment line as meaning that the comment extends onto the next line.
(Myself? I don't usually put in #! lines these days; I don't consider it an imposition to write tclsh8.5 myscript.tcl.)

Execute TCL on windows XP

I installed tcl803.exe on my windows XP Operating System and my TCL path is C:\Tcl. Now I am unable to execute the TCL script on windows XP operating system. Please help me. Here I am very new. Please tell me each and every steps. Here is my TCL script. I write in a notepad and save it as a.tcl extension.
set x 50
set y 400
puts stdout "$x+$y=[expr {$x+$y}]"
puts stdout "-The addition of two variables $x and $y is [expr $x+$y]"
Do this at a DOS prompt:
assoc .tcl=TclScript
ftype TclScript=c:\Tcl\tclsh.exe %1 %*
However, it would be much easier for you to install ActiveTcl -- that install process will manage the file associations for you.
Tcl files aren't compiled, they're scripts that require they be handed to a Tcl interpreter to run. You have two primary options on Windows:
Run the tcl interpreter with the script as an argument:
tclsh.exe ddd.tcl
Associate .tcl files with the tclsh (or wish) interpreters. I don't recall how to do this offhand, but it's similar to associate .doc items with Word... When you double click on the .tcl file it calls the executable (Tcl) and gives it the name of the .tcl file you clicked on.
Note: You can "compile" tcl code into an executable (tclkit, starkit), but you probably aren't at a point where you'd be comfortable doing so.