TCL on Win/xp/sp3 Newbie
SeaSideSam
operating systems, and i have concluded after a brief research period
that tcl could very well allow me to accomplish something i've long
wanted to accomplish... get away from micro$uck$ and it's crappie
operating system(s). so; i have spent the last two (2) weeks attempting
to make tcl work on my win/xp with my one (1) success being 'puts "Hello
World"' i will go public with my situation fully expecting to be...
my requirements are simple... display info on a screen, get info from a
screen, store data in a database, get data from a database, and do some
printing. i've been programming since 1969 (machine code, assembler,
cobol, pick, vsam, sql, on mainframes and minis), but for whatever
reason unix/linux talk gives me a headache.
what i would like to find is documentation and/or instructions written
from a windows perspective explaining how to install, configure, and
execute tcl.
tia.
sss
Gerald W. Lester
Install ActiveState's Tcl/Tk (www.activestate.com).
Create your programs using a text/program editor (not word -- try Komodo
from ActiveState).
Give the files a .tcl extension.
Double click on them to launch them.
Database access requires you to get the appropriate extension downloaded on
to your machine for the DB you want to use -- we are in the middle of having
a unified DB interface for extensions to conform to.
Printing support is not really there -- although there are some stop gap
answers that you may find usable. This is an area that was actively worked
on in the GSoC.
Your list of computer experience has a low intersection with Tcl/Tk's
ancestry so Tcl/Tk might seem rather "strange" -- particularly Tk's event
programming vs Cobal's procedural programming (you said pick for a DB but
did not say if you used Pick/Basic or ENGLISH when working with it). As for
VSAM, Tcl's view of files is much more Unix like -- just a stream of bytes
with no structure on top. For structured storage use a DB (MetaKit and
Sqlite work very nicely with Tcl).
If you post detail questions, people will be glad to help you here or on the
Tcler's chat (http://wiki.tcl.tk/2619).
--
+------------------------------------------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
oak...@bardo.clearlight.com
ActiveState's distribution is arguably the least painful way to go on
a windows platform. And since you're there you might as well download
Komodo Edit, their free editor [1]. There are other choices of
distributions and editors, but that's as good a first start as you're
likely to find.
The only thing I'll add is to comment on your statement "Tcl is
advertised as the end-all of all end-alls for any and all
operating systems". I'm curious what caused you to form that opinion.
Are there websites you've found that make that claim?
The reason I ask is that the Tcl community, unlike most programming
communities, generally tries to be a bit more pragmatic than that. Tcl/
Tk is a remarkable programming platform but it's not necessarily
better than other dynamic language, just different. Though,
considering its best-of-class bindings to Tk (for GUIs) and sqlite
(for databases), virtually transparent unicode support, virtual
filesystem and channel abstractions, and a best-of-class deployment
mechanism (tclkit, starkit, starpack) to name a few, one could argue
it's a step or three ahead of most other dynamic languages from a
purely technological standpoint.
Ok, so maybe it _is_ the end-all be-all of dynamic languages... :-)
SeaSideSam
the pick i was referring to was pick/basic; in my experience the finest
o/s ever marketed (no slams please; point made from my experiences).
too bad those that took control of p/b refused to allow enhancements.
i am not a stranger to event programming as i do some vb and numerical
controller work on the side. from what i've seen of tcl thus far i feel
it would be good for my use. if i can just get it to run.
d/l'd the tcl you recommended (along with the license). followed the
install instructions on the activestate web site. the tcl would NOT
install. the error reported was a missing db. there was no 'step' for
installing tcl (as there was for the license) so i installed tcl after i
completed the install instructions.
another normal day in the micro$uck$ world.
thanks again.
sss
SeaSideSam
Cameron Laird
SeaSideSam <S...@Sea.Side> wrote:
.
.
.
>d/l'd the tcl you recommended (along with the license). followed the
>install instructions on the activestate web site. the tcl would NOT
>install. the error reported was a missing db. there was no 'step' for
>installing tcl (as there was for the license) so i installed tcl after i
>completed the install instructions.
.
.
! ?! !!?!? I don't recognize this description. I've
installed ActiveTcl in a lot of circumstances, and can't
recall ever having symptoms that match this. I'm sure
we can help you get through this, once you provide the
salient details. If I understand correctly, you were
attempting to install ActiveTcl (which release?), you
followed all the directions, then you saw ... well, what
exactly did you see?
SeaSideSam
i downloaded the 'tcl dev kit 4.1.0'
(TclDevKit4.1.0.284998-win32-ix86-threaded.exe). i also downloaded the
21-day license (Tcl_Dev_Kit_Windows_T4E2D8456B.exe). the instructions
said to install the license then, as i discovered upon receiving an
email from activestate, to install the msi. i don't have an msi.
anyway. the error message made reference to a missing database. i'll
recreate the error message...
ok. earlier this afternoon i had uninstalled a program, but had not
booted. a few minutes ago i booted. i just now clicked on the
TclDevKit.... exe and it did it's thing. i did a 'single' user install
to the 'd:\' drive and the install had at least three (3) errors (yellow
highlights). stay tuned for further developments as i will now attempt
to construct a program.
thanks for your replies (and help).
sss
Jeff Godfrey
> i am prone to abbreviated postings...
>
> i downloaded the 'tcl dev kit 4.1.0'
> (TclDevKit4.1.0.284998-win32-ix86-threaded.exe).
Ahhh - that's the problem. You want ActiveTCL. TclDevKit is a
collection of commercial development tools. It's great to have, but you
don't need it for a basic Tcl install.
Try this link:
http://www.activestate.com/Products/activetcl/index.mhtml
Jeff
SeaSideSam
"hello..."' program, got a box and nothing else... no hello world. so.
looks i'm in need of some reference material. any one knowing a source
for online ref material please speak up. i've been through at least two
tutorials but i need more.
thanks again.
sss
Jeff Godfrey
> thanks jeff. downloaded. installed. double-clicked my 'puts
> "hello..."' program, got a box and nothing else... no hello world. so.
> looks i'm in need of some reference material. any one knowing a source
> for online ref material please speak up. i've been through at least two
> tutorials but i need more.
By default, ActiveTcl installs in c:/Tcl. I assume that's where your
install is? If you look there, you'll see a c:/Tcl/bin folder. In that
folder, among other things, you should see a tclsh85.exe and a wish85.exe.
Those are the 2 standard Tcl shells (the "85" represents the Tcl 8.5
release and differs based on the installed version). Anyway...
Tclsh85.exe is a shell that's typically used for CLI-type (Command Line
Interface) applications. That is, applications that don't require a
GUI. Though, with modern Tcl builds, it's simple to use tclsh in a
GUI environment, but I won't go into that now.
Wish85.exe, on the other hand, has the Tk graphical toolkit built into
it. So, it's designed to be used for programs requiring a GUI environment.
OK, back to the problem at hand. I think ActiveTcl will automatically
associate ".tcl" files with the graphical shell (wish85.exe above).
Under windows, there's no default location for stdout to be displayed in
the GUI shell, so while your program is probably working as expected,
you didn't see your "hello..." message, as there's no default place to
display it.
For quick results, there are 2 ways to remedy this...
1. As the very first line of your program, add the command "console
show". That'll create a 2nd window that acts as a interactive shell,
but will also display text destined for the stdio channels (so, your
[puts] output will end up there). With that additional line, you should
see output from your program.
2. Run your program against tclsh85.exe instead of wish85.exe. The
simplest way to do that may be just from a Windows command terminal.
Simply type "tclsh.exe yourfile.tcl". That should run your program and
print the results right in the command terminal.
Does that help?
Jeff
SeaSideSam
listen. and i'm working on finding the sql package that suits me. not
a small task.
thanks for the help. keep monitoring though cause i suspect i'll be in
more trouble before i get it figured out.
sss
suchenwi
> does it help??? you bet. i've got it talkn... now i gotta get it to
> listen.
The wish console emulates stdout and stderr, but not stdin. For stdin/
out conversation, best use tclsh from a cmd.exe. Here's an example:
puts "Ask me a question"
gets stdin line
puts "The answer to $line is 42"
SeaSideSam
sss
suchenwi wrote:
The wish console emulates stdout and stderr, but not stdin. For stdin/ out conversation, best use tclsh from a cmd.exe. Here's an example: puts "Ask me a question" gets stdin line puts "The answer to $line is 42" --- avast! Antivirus: Inbound message clean. Virus Database (VPS): 081008-1, 10/08/2008 Tested on: 10/9/2008 3:24:00 AM avast! - copyright (c) 1988-2008 ALWIL Software. http://www.avast.com
Ron Fox
It integerates quite nicely with tcl... and is very free...and is
bundled in with ActiveTcl
(you can load the extension via:
package require sqlite3
)
Documentation is in the ActiveTcl help pages as well.
RF
--
Ron Fox
NSCL
Michigan State University
East Lansing, MI 48824-1321
Christian Gollwitzer
"tkcon" also emulates stdin and is much much less painful than tclsh on
a windows box. In the Start menu, you should find the entry "ActiveState
ActiveTcl"->tkcon. Run this, and you get an interactive console.
Richards program can be run interactively:
loading history file ... 26 events added
buffer line limit: 512 max line length: unlimited
Main console display active (Tcl8.4.16 / Tk8.4.16)
(bin) 27 % puts "Whats your age?"
Whats your age?
(bin) 28 % gets stdin line
29
2
(bin) 29 % puts "You are $line years old."
You are 29 years old.
(bin) 30 %
or you put it into a file and then issue "source myprog.tcl" to run it.
Tkcon is one of the best testing/debugging facilities I've ever seen.
Christian
PS: The Tk equivalent of Hello world is
package require Tk
pack [button .b -text "Hello world" -command exit]
Gerald W. Lester
> thanks richard. i'm not ready for it yet, but you seem to know
> something about 'console', so maybe you can tell me what to use to
> format a screen and get data from it. no hurry. it will be a while
> before i'm ready to do this.
Do you really want to do a console based program?
Tk does really nice GUIs real easy.
Cameron Laird
Gerald W. Lester <Gerald...@cox.net> wrote:
>SeaSideSam wrote:
>> thanks richard. i'm not ready for it yet, but you seem to know
>> something about 'console', so maybe you can tell me what to use to
>> format a screen and get data from it. no hurry. it will be a while
>> before i'm ready to do this.
>
>Do you really want to do a console based program?
>
>Tk does really nice GUIs real easy.
.
.
I suspect that part of the consultation we should first offer
SeaSideSam is ... a modern perspective on "format a screen and
get data from it". As is ever true, first we start with
high-level requirements, then we get to the fun part of Tcl
implementation.
So, SeaSideSam, is there a problem if we answer you in terms of
a simple GUIfied data-entry form?
SeaSideSam
particular product. i do love 'simple' since i consider myself the last
's' in 'kiss'. and then there is the oldtymers...
> So, SeaSideSam, is there a problem if we answer you in terms of
> a simple GUIfied data-entry form?
>
the short answer to the question above is 'NO!!!!'. i take my help
where ever i can find it. i like reference manuals and i love
examples. i use what works for me.
i'm replacing an inventory program that i wrote for my brother's
business. it's written in visual basic, runs on windows. i've gotten
to the point where i hate micro$uck$. yes. i'm using the 'h' word.
and i wasn't kidding whe i said that 'c' gives me a headache. there are
a lot of different 'languages' out there; tcl appeals to me.
again, i thank all that are assisting me here on c.l.tcl. a tremendous
amount was achieved yesterday with your help. without your help i feel
i would be back coding vb or even cobol.
sss
SeaSideSam
work. only took me about three hours. don't laugh. it takes me weeks
to do what i used to do in hours... if i can get it done at all.
getting sqlite to work allowed me to learn about libraries and other
things... a good learning experience.
thanks ron.
sss
Cameron Laird
SeaSideSam <S...@Sea.Side> wrote:
>part of what i got done yesterday was to downlod sqlite AND to get it to
>work. only took me about three hours. don't laugh. it takes me weeks
>to do what i used to do in hours... if i can get it done at all.
>getting sqlite to work allowed me to learn about libraries and other
>things... a good learning experience.
.
.
<URL: http://www.unixreview.com/documents/s=10089/ur0606g/ >
might interest you; certainly <URL: http://wiki.tcl.tk/sqlite >
should.
Cameron Laird
It's even possible to code in Tcl *and* Cobol
<URL: http://wiki.tcl.tk/cobol >. Let's con-
centrate on the task at hand, though: there
certainly are existing Tcl programs that manage
inventory; you should have no doubt that your
target is achievable.
One of us will probably follow up before long
with examples of simple data-entry applications.
Barry Farinet
It's really a good option for someone with your background to go to
Tcl/Tk; SQLite is a very nice, reliable and fast engine (targeted to
single user usage). I use it a lot and am very happy (after I tried
PostgreSql and MySQL); my biggest data base has now 28MB and I've
absolutely no performance problems. There is a lot of tools to help
you define/digg/test SQLite data bases. SQLite Expert is a very good
one for Windows environment; it saves me a lot of time when testing/
reorganizing data bases: Try it!
Komodo is of course a good option. You can also used editors with
smaller requirements/environments; any one will do the job (Notepad++,
PSPad, and so on...).
For printing there are no specific tools inside Tcl; it can be done
with Tk and namelly "canvas". From there you can create a PDF file and
the job is done (you have not only a printable document but also a PDF
document you can keep or send through Internet).
Finally, in this group we can find a lot of fine and knowledgeable
guys always ready to help!
After a few programs in TCL and specially using Tk you'll never more
go back to Cobol!
See you later!
SeaSideSam
the problems i am having are the problems i always have when i try
something new... that first step. how to turn the dang thing on. i had
sqlite working the other night, but last night it wouldn't work at all.
tcl can't find the file. yesterday was a bad day (health) and today is
even worse. as soon as i get to feeling better i'll find out why tcl
can't find sqlite then progress some more.
all who have commented on printing don't seem to have much good to say
about tcl and printing. the output of this application will go straight
to the printer... or to a file that i can then have the os print. very
little in the way of graphics, no graphics are requiered. an assumption
would be that 'printing' is a 'need' just waiting for the right
'developer' to fill. i mastered hp's pcl or pml or whatever it was
called, and i mastered visual basic's printer object. maybe i can
assist one of you gurus in developing 'TCLPrint.tcl'. just a thought.
let's let this thread go away. when i get to feeling better i'll start
a new one. thanks to all who responded... and to those who paid
attention and chose not too. this is the most 'professional' news group
i've ever monitored or participated in.
thanks again.
sss
> ---
> avast! Antivirus: Inbound message clean.
> Virus Database (VPS): 081010-0, 10/10/2008
> Tested on: 10/10/2008 2:04:17 PM
Alexandre Ferrieux
>
> an assumption would be that 'printing' is a 'need' just waiting
> for the right 'developer' to fill.
That's a pretty good assumption for a newcomer !
Looking at the state of the "art" on the Tcl wiki at
http://wiki.tcl.tk/_search?_charset_=&S=printing
it looks like the problem is the lack of _hope_ of a generic solution.
There's a unix/OSX solution (where PostScript is ubiquitous and the
command-line utilities lp/lpr are always there), and there are dozens
of independent Windows solutions (generate a document for application
X and then ask it to print it). So it's not easy to wake up one
morning and say "today I'll add universal printing to Tcl". Instead,
each of us digs out the one specific solution fitting today's specific
need, and then forget about printing to save trees :-}
> i mastered hp's pcl or pml or whatever it was
> called, and i mastered visual basic's printer object. maybe i can
> assist one of you gurus in developing 'TCLPrint.tcl'. just a thought.
_That_ is interesting. Random thought: is by any chance VB's printing
support based on COM/DCOM/OLE/Whatever they call it these days ? If
yes, then based on your experience it could be straightforward to
"translate" the sequence of COM calls from VB to Tcl's 'tcom' package.
This way your problem could be solved with a minimum change of
paradigm, and the rest of us could learn about yet another (pretty
generic) way of printing under Windows (I have not found anything
about COM-based printing on the wiki, but I cannot swear it is not
there)...
First recover from your illness, then please post here the VB code
you're using for printing. If it's COM, we'll happily translate.
-Alex