From: mikeday on
Hi All,

I'm really liking Tcl and have decided to use it as the primary
language for my current project. However, I haven't found an
affordable (free or low cost!) cross-platform deployment solution that
includes all of the following packages:

Tcl 8.5
Tk
Itcl
Sqlite
Threads

It also needs to support at least the following platforms:

Windows (2000, XP, and on)
Unix/Linux
Mac OS X

Tclkit is awesome but doesn't support threads. eTcl looks very
promising but doesn't come with Itcl. dqkit is out of date and
doesn't seem to be actively supported.

Is there a ready-to-use option that satisfies the above that I haven't
found yet? If not, would someone more experienced here mind
recommending what they think is the best route to take to make my own
binaries for the above platforms that include all these packages?

BTW, I've noticed arguments here and there against threading. I'm
sympathetic to these arguments, since I've done a lot of multithreaded
coding myself and experienced the headaches. However, there are still
situations where threading seems the best solution. In my case, I
need to have multiple AI's considering a situation at the same time,
and it would be very difficult to give all of them a fair amount of
computation time while keeping the whole UI responsive without
threads.

Any help, tips, pointers, warnings, welcome.

Thank you!
- Mike Day
From: tom.rmadilo on
On Jan 29, 6:06 pm, mike...(a)webmail.us wrote:
> Hi All,
>
> I'm really liking Tcl and have decided to use it as the primary
> language for my current project.  However, I haven't found an
> affordable (free or low cost!) cross-platform deployment solution that
> includes all of the following packages:
>
> Tcl 8.5
> Tk
> Itcl
> Sqlite
> Threads
>
> It also needs to support at least the following platforms:
>
> Windows (2000, XP, and on)
> Unix/Linux
> Mac OS X
>
> Tclkit is awesome but doesn't support threads.  eTcl looks very
> promising but doesn't come with Itcl.  dqkit is out of date and
> doesn't seem to be actively supported.
>
> Is there a ready-to-use option that satisfies the above that I haven't
> found yet?  If not, would someone more experienced here mind
> recommending what they think is the best route to take to make my own
> binaries for the above platforms that include all these packages?
>
> BTW, I've noticed arguments here and there against threading.  I'm
> sympathetic to these arguments, since I've done a lot of multithreaded
> coding myself and experienced the headaches.  However, there are still
> situations where threading seems the best solution.  In my case, I
> need to have multiple AI's considering a situation at the same time,
> and it would be very difficult to give all of them a fair amount of
> computation time while keeping the whole UI responsive without
> threads.
>
> Any help, tips, pointers, warnings, welcome.

So the issue boils down to packaging? Seems like the immediate issue
should be program design. You could test the different component
packages on each platform to assure yourself that they work and work
together. You'll need that experience before moving on to a cross-
platform deployment solution, if one exists.
From: Tcl Bliss on
On Jan 29, 6:06 pm, mike...(a)webmail.us wrote:
> Hi All,
>
> I'm really liking Tcl and have decided to use it as the primary
> language for my current project.  However, I haven't found an
> affordable (free or low cost!) cross-platform deployment solution that
> includes all of the following packages:
>
> Tcl 8.5
> Tk
> Itcl
> Sqlite
> Threads
>
> It also needs to support at least the following platforms:
>
> Windows (2000, XP, and on)
> Unix/Linux
> Mac OS X
>
> Tclkit is awesome but doesn't support threads.  eTcl looks very
> promising but doesn't come with Itcl.  dqkit is out of date and
> doesn't seem to be actively supported.
>
> Is there a ready-to-use option that satisfies the above that I haven't
> found yet?  If not, would someone more experienced here mind
> recommending what they think is the best route to take to make my own
> binaries for the above platforms that include all these packages?
>
> BTW, I've noticed arguments here and there against threading.  I'm
> sympathetic to these arguments, since I've done a lot of multithreaded
> coding myself and experienced the headaches.  However, there are still
> situations where threading seems the best solution.  In my case, I
> need to have multiple AI's considering a situation at the same time,
> and it would be very difficult to give all of them a fair amount of
> computation time while keeping the whole UI responsive without
> threads.
>
> Any help, tips, pointers, warnings, welcome.
>
> Thank you!
> - Mike Day

tclkit located here: http://code.google.com/p/tclkit/ supports
threads, at least for Linux. I haven't tested the Windows or Mac
versions. Download and try.
From: tomk on
On Jan 29, 7:06 pm, mike...(a)webmail.us wrote:
> Hi All,
>
> I'm really liking Tcl and have decided to use it as the primary
> language for my current project.  However, I haven't found an
> affordable (free or low cost!) cross-platform deployment solution that
> includes all of the following packages:
>
> Tcl 8.5
> Tk
> Itcl
> Sqlite
> Threads
>
> It also needs to support at least the following platforms:
>
> Windows (2000, XP, and on)
> Unix/Linux
> Mac OS X
>
> Tclkit is awesome but doesn't support threads.  eTcl looks very
> promising but doesn't come with Itcl.  dqkit is out of date and
> doesn't seem to be actively supported.
>
> Is there a ready-to-use option that satisfies the above that I haven't
> found yet?  If not, would someone more experienced here mind
> recommending what they think is the best route to take to make my own
> binaries for the above platforms that include all these packages?
>
> BTW, I've noticed arguments here and there against threading.  I'm
> sympathetic to these arguments, since I've done a lot of multithreaded
> coding myself and experienced the headaches.  However, there are still
> situations where threading seems the best solution.  In my case, I
> need to have multiple AI's considering a situation at the same time,
> and it would be very difficult to give all of them a fair amount of
> computation time while keeping the whole UI responsive without
> threads.
>
> Any help, tips, pointers, warnings, welcome.
>
> Thank you!
> - Mike Day

I would recommend that you use the Active State distribution, here is
the man page for their packages http://docs.activestate.com/activetcl/8.5/at.pkg_index.html.
I would also point out that is extreamly unlikely that you need to use
threads, as you do with other languages, because tcl unlike other
languages, has a built in event model that does all the work for you.
Please discuss your need for using threads with the tcl experts be for
going down that path.
tomk
From: tom.rmadilo on
On Jan 30, 9:42 am, tomk <krehbiel....(a)gmail.com> wrote:

> I would recommend that you use the Active State distribution, here is
> the man page for their packageshttp://docs.activestate.com/activetcl/8.5/at.pkg_index.html.

This seems like good advice if you are not used to one or more
alternative platforms.

> I would also point out that is extreamly unlikely that you need to use
> threads, as you do with other languages, because tcl unlike other
> languages, has a built in event model that does all the work for you.

Follow the next piece of advice before the one above:

> Please discuss your need for using threads with the tcl experts be for
> going down that path.

Tcl can use the event loop and threads, in fact, the Threads package
relies on the event loop to queue events. What threads gives you is
easier isolation of data in the global namespace and easier
programming with channel code, without creating a cross-thread
communication problem.

To do worker-thread-like programming with a single interp, you have to
change the data model to handle multiple sets of data for each
parallel chunk of work.* This is not free and it isn't at all easy to
adapt code to move from serial to parallel workflow. So one thing you
get with threads is the ability to use code without too much worry
that a script will screw up your global environment. BTW, this is one
reason that web servers usually rely on threads or separate processes:
code review would quickly cost more time than any other activity.
(Note that most other types of servers don't rely at all on externally
contributed code).

* One method is to migrate a scalar variable to an array where the key
is added to the API signature,
* Another method is to use some type of object system (TclOO uses a
unique namespace to protect data),
* Instead of an array you can directly use a namespace, which allows
more than one variable to be easily referenced with a particular key
(I'm guessing this is why TclOO uses namespaces).