f



Why TCL?

Hi,

2 weeks ago I found out about TCL for the first time, and I've fallen
for it since. It turned out to be very easy to learn, and seems to do
what I want it to do so far.

I have to hold a speech on any arbitrary technical subject soon for a
room of techies and I've thought about introducing them to TCL, since
many have heard of Expect, but don't realize it's built on top of TCL.

Since 2 weeks has not been enough for me to know all ins and outs, I
wonder how I can convince them of the benefits of TCL. By testing the
waters, the first responses I got were:

"Why yet another language to learn? I can do everything I want with
Perl, and has a greater userbase".

So, help me here..

1. why use TCL and not Perl for example? (my answer was the legibility
but they just say it's a matter of taste and what you're used to)
2. what are its (dis)advantages?
3. what's on the outlook? Is it going to remain a tool used by a few,
while the rest of the world moves on with Perl, PHP, Bash and Java?

What else? I know these are same old typical questions, but they are
asked. I've been around a lot of experienced programmers, most on linux
platform, and nobody, including myself, had heard of TCL before, even
though some knew about Expect. How come? What does PHP or Perl have
that TCL does not? If TCL is a specialized tool for a particular
purpose, then what is it?
I know the idea of TCL, why re-invent the wheel for every tool that
supports some kind of scripting when you can use TCL libs, but why
Perl. PHP and all the other? What's TCL's flaw? It seems faster to me
than PHP, more legible than Perl, .. so what's lacking? Advertising? Or
is there another reason?

Lisa

0
reageer (10)
11/30/2005 1:43:08 PM
comp.lang.tcl 23429 articles. 2 followers. Post Follow

118 Replies
1878 Views

Similar Articles

[PageSpeed] 18

reageer@yahoo.com wrote:

> 1. why use TCL and not Perl for example? (my answer was the legibility
> but they just say it's a matter of taste and what you're used to)

I'm a firm believer in picking the right tool for the job so I go between
PERL and Tcl fairly often.  I pick Tcl for scripting functions in which I 
want GUI attached.  I also use Tcl for GUI programs that would take too
long to implement in C++/Qt; usually this occurs when I don't have to
interface to legacy C code.

I know you can use Tcl for those, I just choose not to.

> 2. what are its (dis)advantages?

To me, there are too many competing technologies which all have their 
pluses and minuses.  Lots of table widgets, notebooks, object oriented
facilities, etc...  

> 3. what's on the outlook? Is it going to remain a tool used by a few,
> while the rest of the world moves on with Perl, PHP, Bash and Java?

All tools have a place.  We use Tcl to get a job done and it just works!
I really like it for that.

Joey
0
joey3864 (42)
11/30/2005 2:41:23 PM
Tcl (notice the spelling:) is sort of a minority language, not much in
public fashion, although to those who know it it is extremely simple
and extremely powerful.

For a family tree, think of Tcl as having sprung from Lisp, C, and
(Unix) shells.

There is a mid-sized community which usually is very helpful and can be
reached at
news:comp.lang.tcl (here)
IRC #tcl
Also, there's a quite rich Wiki about Tcl/Tk at http://wiki.tcl.tk
One point of interest might be the "Advocacy" pages there at
http://wiki.tcl.tk/references/9855! (the exclamation mark is part of
the URL). One of my own testimonies says:
Tcl matters to some (to me very much), and doesn't to the vast majority
of the Earth's population... As a linguist, I've been interested in
programming languages for thirty years, from Assembler to Lisp to C++,
but haven't found another one that gives me more power to do almost
anything, including very unexpected things. We have FP, and we can have
most any flavor of OO with little effort, need it or not :)

We're not trying to proselytize friends of other languages, but we're
glad to help all who have questions about Tcl/Tk.

0
11/30/2005 2:42:36 PM
reageer@yahoo.com wrote:
> Hi,

> "Why yet another language to learn? I can do everything I want with
> Perl, and has a greater userbase".
Probably they have a greater userbase knowing that they use Perl, its
hard to hide the ugly..., Tcl is more of a chameleon, see your own
Expect example...

> 
> So, help me here..
> 
> 1. why use TCL and not Perl for example? (my answer was the legibility
> but they just say it's a matter of taste and what you're used to)
They are right. Its a matter of taste. Perl is better for some low level
Unix work, while Tcl makes cross platform stuff (unix,win,mac) much
easier than perl, as it hides the complexity.

> 2. what are its (dis)advantages?
Basically quote the advocacy pages from www.tcl.tk
http://www.tcl.tk/about/features.html
http://www.tcl.tk/about/highlights.html

> 3. what's on the outlook? Is it going to remain a tool used by a few,
> while the rest of the world moves on with Perl, PHP, Bash and Java?
Tcl surely isn't the hippest thing in the universe. So there will be
more hype around PHP, Java and others like Python or Ruby. But its a
solid, mature tool. If your following the hype, try Ruby, or some other
of the current marketing bubbles.

> 
> What else? I know these are same old typical questions, but they are
> asked. I've been around a lot of experienced programmers, most on linux
> platform, and nobody, including myself, had heard of TCL before, even
> though some knew about Expect. How come? What does PHP or Perl have
> that TCL does not? 
Lots of noisy advocats and better marketing.
PHP is a crap language, getting better slowly with each major version,
but its widely installed on web hosters and easy to get basic things
done. (but the trouble starts when you want more than the basics).
But PHP is visible as hell, you can't hide it as easily as Tcl. You have
to configure a zillion things, have a zillion dependencies because PHP
includes everything but the kitchen sink in its distribution (just
because it doesn't have something smart like Tcl Stubs it has to do it
that way, otherwise PHP deployment would be even worse than it is). Add
the fact that PHP is used as a web tool, so you have the huge and noisy
web designer crowd out there producing nice looking webpages with
documentation, examples and other things, even if there code is substandard.
Perl, no idea. Its a nice tool if your fluent with it, otherwise its
hell. Part of the toolkit for true hackers or so, the same people that
believe in self documenting code...

Part of the marketing problem may be Tcl's BSD license: You do not have
to admit that you use Tcl, you can simply embed Tcl into your product,
software, appliance and no one will notice it on a cursory look. Similar
embedding is a lot harder with Perl (and the license for EmbPerl is
somewhat more confusing legally) and at least as hard with PHP.

> If TCL is a specialized tool for a particular
> purpose, then what is it?
Its in a way specialized to handle strings and glue things together. It
is used as a specialized tool in lots of contexts, see Expect, most ECAD
applications, etc. etc.

> I know the idea of TCL, why re-invent the wheel for every tool that
> supports some kind of scripting when you can use TCL libs, but why
> Perl. PHP and all the other? What's TCL's flaw? It seems faster to me
> than PHP, more legible than Perl, .. so what's lacking? Advertising? Or
> is there another reason?
Main reason really is marketing.

Michael
0
schlenk (1615)
11/30/2005 2:48:07 PM
On Wed, 30 Nov 2005, reageer@yahoo.com wrote:

> What does PHP or Perl have that TCL does not?

> why Perl. PHP and all the other? What's TCL's flaw? It seems faster to 
> me than PHP, more legible than Perl, .. so what's lacking? Advertising?

Integration. When you install some UN*X variant you get hunders of Perl 
scripts, starting from hellbent initscripts and ending to system wide log 
examination and stuff. Even debconf requires perl-base.

When you install web server you get tens of Perl and PHP examples that let 
you do cool things in next to no time.

When you install Tcl you have nothing to play with. Nothing requires it, 
nothing even suggests it, you get nothing to start playing with, it is not 
necessary. Fortunately, same applies to Python that I never install. But I 
can't get rid of Perl, nothing works if I do, and PHP is just so cool toy.

So yes, you could say Tcl is lacking advertising, and pl2tcl system script 
converter.

> Or is there another reason?

There is one more reason: none is asking these questions about those other 
languages :)

-- 
-Kaitzschu
s="TCL ";while true;do echo -en "\r$s";s=${s:1:${#s}}${s:0:1};sleep .1;done
0
kaitzschu1 (358)
11/30/2005 2:52:22 PM
I wil add my own reasons for using Tcl to the other replies:
On the one hand, Tcl to me is a tool that fills a gap between a
language like C or Fortran where speed is important (big computational
programs, database systems, sophisticated graphical presentations) and
a shell scripting language to chain programs together (bash, ...).

On the other hand, Tcl is also a tool for me to explore new programming
ideas, to create lightweight programs (scripts if you like) to do a
small job perfectly well.
Mind you: I have used it and continue to use it for big jobs too.

If I am to name my favourite languages: Tcl for the lightweight stuff
and gluing things together, Fortran for the numerical stuff and (yes,
surprise, surprise) for doing that sort of programs in an elegant way!
I know, FORTRAN (note the capitals) has an ill reputation - but it has
evolved into something much more sophisticated than the first public
standard that everybody still has in mind. I love them both for being
as platform-independent as they are, even though they may by themselves
not be sufficient for everything.

And the best part perhaps: both communities are usually unusually
helpful :)

Regards,

Arjen

0
arjen.markus (2628)
11/30/2005 2:53:40 PM
reageer@yahoo.com wrote:
> Hi,
>
> 2 weeks ago I found out about TCL for the first time, and I've fallen
> for it since. It turned out to be very easy to learn, and seems to do
> what I want it to do so far.
>
> I have to hold a speech on any arbitrary technical subject soon for a
> room of techies and I've thought about introducing them to TCL, since
> many have heard of Expect, but don't realize it's built on top of TCL.
>
> Since 2 weeks has not been enough for me to know all ins and outs, I
> wonder how I can convince them of the benefits of TCL. By testing the
> waters, the first responses I got were:
>
> "Why yet another language to learn? I can do everything I want with
> Perl, and has a greater userbase".
>
> So, help me here..
>
> 1. why use TCL and not Perl for example? (my answer was the legibility
> but they just say it's a matter of taste and what you're used to)
> 2. what are its (dis)advantages?
> 3. what's on the outlook? Is it going to remain a tool used by a few,
> while the rest of the world moves on with Perl, PHP, Bash and Java?
>
> What else? I know these are same old typical questions, but they are
> asked. I've been around a lot of experienced programmers, most on linux
> platform, and nobody, including myself, had heard of TCL before, even
> though some knew about Expect. How come? What does PHP or Perl have
> that TCL does not? If TCL is a specialized tool for a particular
> purpose, then what is it?
> I know the idea of TCL, why re-invent the wheel for every tool that
> supports some kind of scripting when you can use TCL libs, but why
> Perl. PHP and all the other? What's TCL's flaw? It seems faster to me
> than PHP, more legible than Perl, .. so what's lacking? Advertising? Or
> is there another reason?
>
> Lisa

Standard answer for this is at: http://wiki.tcl.tk/590

As to why Tcl is not as popular, basically some people didn't like Tcl
and they turned out to be very influential *cough*RMS*cough*. And there
was a war waged against Tcl and detractor's polularity won against the
supporter's reason. The rest, as they say, is history.

BTW, Tcl tend to sneak its way into popular use. Expect is a good
example. After playing with expect most people can't think of an easier
way to achieve what expect can do. Or of a simpler language to script
expect. Another good example is AOLserver.

I'm guilty of staging such sneak attacks myself. I kind of forced my
former employer to let Tcl co-exist with VB not by being stubborn. But
by prototyping software very quikly in Tcl. The VB guys would take a
whole day to prototype something and I can whip up a prototype in my
spare time during lunch. The prototypes eventually grew and got shipped
to the end user. I was able to implement so many features so quickly
that the prospect of porting my "hack" to VB became very challanging.
It was easier to re-train the VB guys to write Tcl than to port the app
to VB.

0
slebetman (894)
11/30/2005 3:02:03 PM
According to  <reageer@yahoo.com>:
:1. why use TCL and not Perl for example? 

Why use Perl instead of Java or C or C++?
I mean, if you use C, you should be able write any code you want.
The reason people use scripting languages at all is that it improves the
speed of getting to the goal quicker.

So why use Tcl instead of some other scripting language? Most of the
major scripting languages have similar capabilities. Learning one is
generally enough. There's no technical reason for needing to learn
dozens of scripting languages if someone is writing original code.
Pick one that has a lot of support for easy to write code, good documentation,
lots of extensions/modules/ways to leverage code written by others so you
don't have to re-invent the wheel, and which has a great user community and
maintenance team. 

If someone feels that Perl has all of that, why fight them over it? Let
them stay there.  If someone doesn't currently know a scripting language,
or is unsatisfied with the scripting language they are using, then Tcl
becomes a tool to suggest.

One other reason to learn Tcl.  Probably the most important reason for
a programmer to learn Tcl is to be able to use things written to be used
with Tcl.  For instance, the Perl and Python Tk bindings depend on the
Tcl underneath. So learning Tcl makes using those tools easier.  Other
people know, or want to know, Expect, or Scotty, or some other useful
tool written in Tcl.  Learning Tcl allows them to enhance and extend
(and sometimes, the extendability is built into the tool).

:2. what are its (dis)advantages?

Few, if any, books sitting on the neighborhood bookstore shelves.

:3. what's on the outlook? Is it going to remain a tool used by a few,
:while the rest of the world moves on with Perl, PHP, Bash and Java?

Define "used by a few". For instance, users of AOL's web sites are using web
servers written in Tcl.  Do those people count?  I don't have a list of
the current popular web sites using Tcl - perhaps someone else here does.
Then there are other popular Linux tools written in Tcl and Tk. And
Tcl and Tk are shipped with MacOS X. Anyone know of any highly used Tcl/Tk
apps on Windows?

:What else? I know these are same old typical questions, but they are
:asked. I've been around a lot of experienced programmers, most on linux
:platform, and nobody, including myself, had heard of TCL before, even
:though some knew about Expect. How come?

Because most of the people writing articles, etc. these days are writing
about Java, and most of the schools don't teach scripting - if they
do, they generally teach Perl because it is used on many web sites.

:What does PHP or Perl have
:that TCL does not?

In general, neither have "something" that one cannot download or code
for Tcl.  However, at least Perl comes with more functions "out of the
box" as well as a pretty slick interface to a world wide, supported,
repository of add on functionality.  While at least one or
two people have written repositories for Tcl, none of them have set the
tcl community on fire to join in and support.

:If TCL is a specialized tool for a particular
:purpose, then what is it?

It isn't a specialized tool.

:I know the idea of TCL, why re-invent the wheel for every tool that
:supports some kind of scripting when you can use TCL libs, but why
:Perl. PHP and all the other?

It's the "not invented here" syndrome, in my opinion.  Different
people resonate with different languages.  Same reason there are hundreds,
if not thousands, of human languages.  Why doesn't everyone speak just
one human language?

:What's TCL's flaw? It seems faster to me
:than PHP, more legible than Perl, .. so what's lacking? Advertising? Or
:is there another reason?

Oh, there was a bit of advertising.  But it has always been drowned out
by the popular press for perl, then python, then java.  Shrug.  For me,
Tcl works just as well as it would if there were 10 times more users.
And I suspect I get quicker answers to my questions now ... because it
doesn't seem that the size of the community involvement increases 
geometrically, let alone exponentially, as the user base increases.

-- 
<URL: http://wiki.tcl.tk/ > Indescribable,uncontainable,all powerful,untameable
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvirden@gmail.com > <URL: http://www.purl.org/NET/lvirden/ >
0
lvirden (1938)
11/30/2005 3:08:01 PM
In article <1133358188.388126.121540@g14g2000cwa.googlegroups.com>,
 <reageer@yahoo.com> wrote:
			.
			.
			.
>I have to hold a speech on any arbitrary technical subject soon for a
>room of techies and I've thought about introducing them to TCL, since
>many have heard of Expect, but don't realize it's built on top of TCL.
			.
			.
			.
This is *very* common, and does indeed deserve mention.
0
claird (2363)
11/30/2005 3:08:02 PM
In article <1133358188.388126.121540@g14g2000cwa.googlegroups.com>,
 <reageer@yahoo.com> wrote:
 			.
			.
			.
>Since 2 weeks has not been enough for me to know all ins and outs, I
>wonder how I can convince them of the benefits of TCL. By testing the
>waters, the first responses I got were:
>
>"Why yet another language to learn? I can do everything I want with
>Perl, and has a greater userbase".
>
>So, help me here..
>
>1. why use TCL and not Perl for example? (my answer was the legibility
>but they just say it's a matter of taste and what you're used to)
>2. what are its (dis)advantages?
>3. what's on the outlook? Is it going to remain a tool used by a few,
>while the rest of the world moves on with Perl, PHP, Bash and Java?
>
>What else? I know these are same old typical questions, but they are
>asked. I've been around a lot of experienced programmers, most on linux
>platform, and nobody, including myself, had heard of TCL before, even
>though some knew about Expect. How come? What does PHP or Perl have
>that TCL does not? If TCL is a specialized tool for a particular
>purpose, then what is it?
>I know the idea of TCL, why re-invent the wheel for every tool that
>supports some kind of scripting when you can use TCL libs, but why
>Perl. PHP and all the other? What's TCL's flaw? It seems faster to me
>than PHP, more legible than Perl, .. so what's lacking? Advertising? Or
>is there another reason?
			.
			.
			.
You do NOT have to know everything about Tcl to make a good 
presentation--although it often helps.

Your colleagues are right:  to zeroth order, Perl and Tcl *are*
the same language, and much of the difference in practice is a
matter of taste.

How does Tcl compare to Perl?  <URL: http://wiki.tcl.tk/1330 >
has details.

In these terms, I don't particularly expect Tcl ever to be other
than "a tool used by the few".  On the other hand, I *do* expect
Tcl to be around for a long time into the future, arguably longer
than Perl or PHP.  In any case, <URL: http://wiki.tcl.tk/1887 >
might interest you.

Why have people, including you, heard of PHP and Perl, but not 
Tcl?    I suspect that the true answer is a subtle one,
involving a conjunction of marketing and technical realities
that few have the experience to synthesize.  I can assure you
that the ethos of Tcl practitioners is characteristically less 
.... aggressive than that which has prevailed in the Perl and 
PHP communities.  For a variety of historical reasons, pugna-
cious zealotry hasn't been Tcl's style.

Tcl is a specialized tool for tasks which are hard to character-
ize in Perl and PHP terms:  high reliability, convenient 
interfacing, technical flexibility, ...

Tcl *is* faster than PHP, and more readable than Perl.  Why
isn't it known, or even dominant?  I repeat:  there are a
variety of historical reasons, many of the most prominent 
having to do with vagaries of The Web's evolution.

I was an early adopter and advocate for both Perl and PHP, 
incidentally.

You have correctly identified that Tcl originated as a 
technology for implementation of extension languages.  As
of 2005, though (or even 1995, for that matter), it's most
appropriate to present it as a potent general-purpose 
language which happens to be particularly successful in
embedded situations.
0
claird (2363)
11/30/2005 4:08:02 PM
Cameron wrote:
"Why have people, including you, heard of PHP and Perl, but not
Tcl?    I suspect that the true answer is a subtle one,
involving a conjunction of marketing and technical realities ..."

Aside from Scriptics - perhaps even that can be ignored, was Tcl ever
marketed?

0
ray.mosley (58)
11/30/2005 5:15:15 PM
Define what you mean when you write "was Tcl ever marketed"?  Does Sun
touting articles about Tcl on the sun.com front page count?  Does
articles in various magazines, from Dr. Dobbs, to various Linux
magazines, to Computerworld count? Does major companies like Oracle and
Vignette using and advertising they use Tcl count?

0
lvirden (1938)
11/30/2005 5:36:09 PM
In article <1133372169.815267.318400@f14g2000cwb.googlegroups.com>,
Larry W. Virden <lvirden@gmail.com> wrote:
>Define what you mean when you write "was Tcl ever marketed"?  Does Sun
>touting articles about Tcl on the sun.com front page count?  Does
>articles in various magazines, from Dr. Dobbs, to various Linux
>magazines, to Computerworld count? Does major companies like Oracle and
>Vignette using and advertising they use Tcl count?
>

My congratulations, by the way, to the PHPers.  The project has
been on the verge of collapse at least a couple of times, and 
received serious non-help at crucial times from organizations 
that might have made a difference.  Despite these obstacles, it
has flourished.  Along with its intimacy with Apache, its early
collaborative documentation was essential, in my view.
0
claird (2363)
11/30/2005 7:08:02 PM
> 1. why use TCL and not Perl for example? (my answer was the legibility
> but they just say it's a matter of taste and what you're used to)

Because you often need to read and *understand* your code 6 or 12
months later - this is complicated with perl.

> 2. what are its (dis)advantages?

- It does not appear in manager magazines, and seldomly on the shelves
of book stores.
- The documentation is sometimes hard to grab, if you are used to the
per-class-or-method documentation that is employed in Java, python and
modern pure OO languages. This is indeed a problem: developers don't
want to read entire manpages just to find out how a command works -
they want a short description on exact this command with all arguments
(options) and want to find this within a few seconds when they need it.
- really the lack of momentum. No one knows Tcl, no one knows how
successful projects with Tcl can be. But everyone has heard something
about Java somewhere. So, just because of this fact, Java gains more
confidence in projects. It is really necessary to advertise successful
projects written in Tcl/Tk, and tell the world what is inside.

> 3. what's on the outlook? Is it going to remain a tool used by a few,
> while the rest of the world moves on with Perl, PHP, Bash and Java?

Tcl will always have its niche as embeddable scripting language and in
testing environments. Tk will always be included as Widget set in other
scripting languages. But I doubt that Tcl will ever be as widely spread
as Python or PHP.
A new environment could be these embedded handheld/PDA systems and the
like. When I see it right, Tcl is one of the first _scripting_
languages that runs on these systems - and that is great ;-).There
should be more of such efforts... how about bringing Tcl to the .Net
platform, for instance a Tcl-> .Net compiler?

> What else? I know these are same old typical questions, but they are
> asked.

Tell them about Tclkit (http://wiki.tcl.tk/2?Q=tclkit). IMHO, this is
one of the best technologies available.


Eckhard

0
ecky-l (428)
11/30/2005 9:24:44 PM
Michael Schlenker <schlenk@uni-oldenburg.de> wrote about perl:
> Probably they have a greater userbase knowing 
> that they use Perl, its hard to hide the ugly...

QOTW ?
0
avl1 (2748)
12/1/2005 8:54:37 AM
Kaitzschu schrieb:

> necessary. Fortunately, same applies to Python that I never install. But I

you don't get around Python when you install recent releases of
OpenOffice or GNOME. It seems to make it's way as scripting environment
in these platforms.
What brings up another question: Why did Sun choose to integrate clumsy
and slow Python as scripting language in OO and not slim and fast Tcl
(which, I think, was developed directly at Sun)? What is the reason
that Tcl was not prefolding into OO scripting at all? That would have
been a great chance to gain popularity...

> There is one more reason: none is asking these questions about those other
> languages :)

No one needs to ask them.
But for Tcl, I see its non-popularity as a real problem. I really think
that something should be done to attract new developers, otherwise the
language evolution will stagnate at some point in time...

Just my 2c


Eckhard

0
ecky-l (428)
12/1/2005 1:24:45 PM
Eckhard Lehmann wrote:
> What is the reason that Tcl was not prefolding into OO scripting at all?

I take it by "OO" you mean OpenOffice? The answer is probably a
combination of "Large Organization Politics" and "Someone Hacked Around
with Python and Made it Work with OOo, but Nobody Did That with Tcl".

Donal.
0
12/1/2005 2:02:09 PM
In article <1133443485.809281.211710@g47g2000cwa.googlegroups.com>,
Eckhard Lehmann <ecky-l@web.de> wrote:
			.
			.
			.
>What brings up another question: Why did Sun choose to integrate clumsy
>and slow Python as scripting language in OO and not slim and fast Tcl
>(which, I think, was developed directly at Sun)? What is the reason
>that Tcl was not prefolding into OO scripting at all? That would have
			.
			.
			.
Did Sun have any role?  I thought the company just picked up work
that had already been done by outsiders.
0
claird (2363)
12/1/2005 3:08:02 PM
Eckhard Lehmann wrote:

> What brings up another question: Why did Sun choose to integrate clumsy
> and slow Python as scripting language in OO and not slim and fast Tcl
> (which, I think, was developed directly at Sun)? 

Tcl was not "developed directly at Sun". Tcl only vacationed there for a 
few years. Tcl started in the fall of 1987 and didn't show up at Sun 
Microsystems until mid 1994, where it stayed through 1997. The influence 
of Sun Microsystems therefor lasted only three and a half years, give or 
take a month or two.

http://wiki.tcl.tk/1721
http://www.tcl.tk/about/history.html
0
oakley (2075)
12/1/2005 3:31:25 PM
> I take it by "OO" you mean OpenOffice? The answer is probably a

Yes, I do...

> combination of "Large Organization Politics" and "Someone Hacked Around
> with Python and Made it Work with OOo, but Nobody Did That with Tcl".

Someone should have done that with Tcl - probably it would have been
even easier ;-).
Now it is too late, PyUno is rolled out and gets accepted as "the
standard"...


Eckhard

0
ecky-l (428)
12/1/2005 3:51:41 PM
Eckhard Lehmann wrote:
>>I take it by "OO" you mean OpenOffice? The answer is probably a
> 
> 
> Yes, I do...
> 
> 
>>combination of "Large Organization Politics" and "Someone Hacked Around
>>with Python and Made it Work with OOo, but Nobody Did That with Tcl".
> 
> 
> Someone should have done that with Tcl - probably it would have been
> even easier ;-).

There is TclUno: http://wiki.tcl.tk/tcluno
0
nem3909 (1000)
12/1/2005 7:57:05 PM
What do you think should be done?

A great "full stack" web framework in the vein of Rails, TurboGears,
Django, Catalyst would be something to show. These frameworks have high
visibility right now. We have Rivet and several db abstraction layers.
Marry them, throw some weight behind Rivet to get it on more platforms
and build a framework around it.

A CPAN implementation "blessed" and used by the community would be
nice.

There was a recent comparison on the Tcl wiki about db abstraction
layers. It would be nice to "pick one" and work to extend it to be a
"defacto" abstraction layer ala the Perl DBI.

Magazine articles...

Web articles...all over...also O'Reilly might be willing to create a
Tcl space like the other have where we could post articles and then
anyone visiting the O'Reilly site would see the blurbs on the main page
and might just read the article and be curious enough to try Tcl.

I would be willing to talk with O'Reilly about a Tcl section if we
could get articles posted. Really some of the little apps that show up
on the wiki would be great little articles that could show how easy
things are in Tcl.

There might be other things as well.

The problem is usually the "someone" problem. "Someone needs to or
should do it but nobody does".

Robert

0
sigzero (1319)
12/1/2005 10:54:34 PM
In article <1133477674.592032.146850@g44g2000cwa.googlegroups.com>,
Robert Hicks <sigzero@gmail.com> wrote:
>What do you think should be done?
>
>A great "full stack" web framework in the vein of Rails, TurboGears,
>Django, Catalyst would be something to show. These frameworks have high
>visibility right now. We have Rivet and several db abstraction layers.
>Marry them, throw some weight behind Rivet to get it on more platforms
>and build a framework around it.
>
>A CPAN implementation "blessed" and used by the community would be
>nice.
>
>There was a recent comparison on the Tcl wiki about db abstraction
>layers. It would be nice to "pick one" and work to extend it to be a
>"defacto" abstraction layer ala the Perl DBI.

I don't know if I can find the time, but I'd be interested in something like
this..

Mattias
0
mghembru (122)
12/1/2005 11:28:29 PM
Which one? : )

Robert

0
sigzero (1319)
12/1/2005 11:42:17 PM
In article <1133480537.838545.251950@g44g2000cwa.googlegroups.com>,
Robert Hicks <sigzero@gmail.com> wrote:
>Which one? : )
>
>Robert

The DB part.

Mattias
0
mghembru (122)
12/2/2005 12:17:10 AM
Robert Hicks wrote:

> What do you think should be done?
> 
> A great "full stack" web framework in the vein of Rails, TurboGears,
> Django, Catalyst would be something to show. These frameworks have high
> visibility right now. We have Rivet and several db abstraction layers.
> Marry them, throw some weight behind Rivet to get it on more platforms
> and build a framework around it.
> 

Don't get me wrong, I think Tcl/Tk is the best thing since sliced bread, but
IMHO it is not going to make an serious impact until the appearance of the
widgets is improved.

Ian
0
ruffrecords2 (612)
12/2/2005 10:19:04 AM
MH wrote:
> In article <1133480537.838545.251950@g44g2000cwa.googlegroups.com>,
> Robert Hicks <sigzero@gmail.com> wrote:
>>Which one? : )
>>
>>Robert
> 
> The DB part.

I know from preparing the Tcl database abstraction layer comparision (
http://wiki.tcl.tk/14972 ) that at least the author of Tcldb is looking
for help (and it is my favorit currently, for nicest set of
functionalities, followed by Tclodbc, nstcl-database and DIO). I heard
Michael Cleverly talking about updating nstcl with 8.5 features once 8.5
comes out, and others seem to be interested too.

As most of the Tcl database abstraction layers are somehow OO style i
would propose to pick one of the available ones and port it to the new
Tcl core OO style once it is available, enhancing and including the
missing/nice features of the other into the system.

Michael
0
schlenk (1615)
12/2/2005 11:59:16 AM
Ian Bell wrote:
> 
> Don't get me wrong, I think Tcl/Tk is the best thing since sliced bread, but
> IMHO it is not going to make an serious impact until the appearance of the
> widgets is improved.

Are you aware of the tile project? You wanna talk sliced bread? Tile is 
the whole loaf, a jar of jelly and a jar of peanut butter! And a knife.

Coming soon to an 8.5 tcl/tk core near you.

http://tktable.sourceforge.net/tile
0
oakley (2075)
12/2/2005 1:12:09 PM
> Web articles...all over...also O'Reilly might be willing to create a
> Tcl space like the other have where we could post articles and then
> anyone visiting the O'Reilly site would see the blurbs on the main page
> and might just read the article and be curious enough to try Tcl.
>
> I would be willing to talk with O'Reilly about a Tcl section if we
> could get articles posted. Really some of the little apps that show up
> on the wiki would be great little articles that could show how easy
> things are in Tcl.

This would be *very* effective, IMHO. I would try to participate in
that as good as I can, by submitting articles or anything else..


Eckhard

0
ecky-l (428)
12/2/2005 2:33:42 PM
On 2005-11-30, Cameron Laird <claird@lairds.us> wrote:
> Why have people, including you, heard of PHP and Perl, but not 
> Tcl?    I suspect that the true answer is a subtle one,
> involving a conjunction of marketing and technical realities
> that few have the experience to synthesize.  I can assure you
> that the ethos of Tcl practitioners is characteristically less 
> ... aggressive than that which has prevailed in the Perl and 
> PHP communities.  For a variety of historical reasons, pugna-
> cious zealotry hasn't been Tcl's style.

You may be on to something there.  IMO, Tcl practitioners are often 
phlegmatic engineering-mindset types who "just want to get things done".
Consider the following pattern, which I seem to see quite often:

A problem needs to be solved.  A team gets assembled to discuss how
to solve it.  Much heated discussion about technologies to use, etc.
Meanwhile, Person A (often me 8-) sits quietly in the corner, hacking up a
Tcl script that solves the problem.  When everyone pauses from exhaustion
(or someone finally notices that A hasn't said a word and draws everyone's
attention to that fact), A says "well, how about this then?" and shows
everyone the finished script.  A long silence and several dirty looks
later, the script gets adopted, the problem is solved, the meeting is
adjourned.

(Personally, I've hardly ever had to defend my choice of Tcl as a primary
scripting language in my daily work, perhaps because, when challenged,
I simply show them the (usually short) Tcl programs that I write and
ask them, "How would *you* do this in Perl/PHP/whatever...and how long
would it take you?" 8-)

Another opinion: Works of Perl/Python/etc. art often evoke cries of
"Wow, that's amazing, how did you do that, you are a programming GOD!",
probably due to various obscure tricks that are hard for the average
eye and brain to follow.  Works of Tcl art, OTOH, often elicit an "Oh,
that's obvious."  To be a zealot, methinks one needs a better battle
cry than "Tcl's the BOMB coz it's so OBVIOUS!"  8-)

=====

From the technical marketing perspective, I'd argue that Tcl is *too*
simple and easy-to-use for the current crop of "technical marketers"
to make much money on.  As I'm writing this, I'm looking at my
bookshelf, which contains, among many other things:

* a dozen C++ books
* 3 dozen Java books
* 10 Tcl books (Welch, Libes, Flynt, etc.)

(The above list is in chronological order of my use of said languages
over the last 10 years.)

If you were standing beside me, you'd notice one odd thing about the
books: The C++ and Java books are well-thumbed, but the Tcl books are
still in pristine condition, because I've hardly had to refer to them.
In fact, I bought them long *after* I started using Tcl[*] (unlike the
other books that I needed just to get started), not because I needed to
look them up, but because their comparative rarity to the quintillions
of Java/C++/.NET/etc. books stirred some bizarre collector's urge in me.

[*] Again, but by that time, I'd pretty much forgotten everything about
Tcl.  It's a testament to Tcl's utter simplicity that I could hit the
ground running 12 years after, without resorting to a single "how-to" book.
0
Adrian
12/2/2005 2:41:11 PM
Michael Schlenker wrote:
> http://wiki.tcl.tk/14972 ) that at least the author of Tcldb is looking
> for help (and it is my favorit currently, for nicest set of
> functionalities, followed by Tclodbc, nstcl-database and DIO). I heard
> Michael Cleverly talking about updating nstcl with 8.5 features once 8.5
> comes out, and others seem to be interested too.

I strongly urge people interested in doing database APIs to take a look
at how SQLite does its higher-level APIs. Richard Hipp's got it right
(and whether or not you use cursors underneath is almost immaterial to
most programmers; do the "Right Thing" instead of overwhelming people
with options with subtle effects).

Donal (the parenthetical part is an attempt to stop the usual complaint
        that comes up when this sort of thing is discussed!)
0
12/2/2005 2:46:45 PM
Bryan Oakley wrote:
> Are you aware of the tile project? You wanna talk sliced bread? Tile is 
> the whole loaf, a jar of jelly and a jar of peanut butter! And a knife.

QOTW!

Donal.
0
12/2/2005 2:48:01 PM
You know, I have over 8 years of C/C++ experience, I love it, it's powerful, 
I can do everything with it, and doesn't seem all that hard or complex to 
me..  I moved to windows platform years ago for commercial reasons (feeling 
not so much as a collaborater, but rather a victim.. fortunately I've moved 
more than half of my efforts back to linux platform).

I never liked VB, never bothered to learn Perl, used but disliked ASP, and 
settled with PHP for web stuff.
But I've embraced TCL.. in just 2 weeks time.. why?

Well, I agree, if you want power, use C, you want glue, use the best glue 
there is..
When I got a new PC, I never bothered to upgrade to the next one out.. I 
made the jump from 486 to Pentium II en then to Pentium 4. In other words, 
the change should be significant enough for me to make the big leap. 
Everything in between is not significant enough.

I never liked, for wrong reasons (laziness to learn, choosing alternatives I 
was already familiar with) scripting languages, but TCL does it all.. can be 
used for DHTML (Rivet?), shell scripting, windows (Tk), VERY easy to use, 
very quick to learn, powerful, extendible, ..

But I know I can't be a good judge since I am too unfamiliar with the 
alternatives.. but TCL looks pretty on the inside and outside, .. the other 
ones not on the outside, perhaps they do on the inside.. dunno.

What I do feel lacking is indeed something like CPAN, or aptitude/apt-get to 
easily add/delete modules and upgrade them.
And installing the MD5 package for TCL was too painful for me. Still not 
sure what steps are exactely required to install/remove a package (but I 
know there is documentation available.. just have to read it).
Should be more plug and play to make setup just as convenient as the actual 
tcl coding itself.

And I don't understand Tk yet.. that looked like chinese to me at first 
sight.. haven't looked at it since.. and I don't understand the relationship 
between TCL en TK yet.. TK is not part of or dependent on TCL, but a thing 
of its own, that can be scripted with TCL, but Perl or any other language 
that supports TK, do I understand that correctely?

Lisa


<lvirden@gmail.com> wrote in message news:dmkf8h$mdo$1@mailhost.cas.org...
>
> According to  <reageer@yahoo.com>:
> :1. why use TCL and not Perl for example?
>
> Why use Perl instead of Java or C or C++?
> I mean, if you use C, you should be able write any code you want.
> The reason people use scripting languages at all is that it improves the
> speed of getting to the goal quicker.
>
> So why use Tcl instead of some other scripting language? Most of the
> major scripting languages have similar capabilities. Learning one is
> generally enough. There's no technical reason for needing to learn
> dozens of scripting languages if someone is writing original code.
> Pick one that has a lot of support for easy to write code, good 
> documentation,
> lots of extensions/modules/ways to leverage code written by others so you
> don't have to re-invent the wheel, and which has a great user community 
> and
> maintenance team.
>
> If someone feels that Perl has all of that, why fight them over it? Let
> them stay there.  If someone doesn't currently know a scripting language,
> or is unsatisfied with the scripting language they are using, then Tcl
> becomes a tool to suggest.
>
> One other reason to learn Tcl.  Probably the most important reason for
> a programmer to learn Tcl is to be able to use things written to be used
> with Tcl.  For instance, the Perl and Python Tk bindings depend on the
> Tcl underneath. So learning Tcl makes using those tools easier.  Other
> people know, or want to know, Expect, or Scotty, or some other useful
> tool written in Tcl.  Learning Tcl allows them to enhance and extend
> (and sometimes, the extendability is built into the tool).
>
> :2. what are its (dis)advantages?
>
> Few, if any, books sitting on the neighborhood bookstore shelves.
>
> :3. what's on the outlook? Is it going to remain a tool used by a few,
> :while the rest of the world moves on with Perl, PHP, Bash and Java?
>
> Define "used by a few". For instance, users of AOL's web sites are using 
> web
> servers written in Tcl.  Do those people count?  I don't have a list of
> the current popular web sites using Tcl - perhaps someone else here does.
> Then there are other popular Linux tools written in Tcl and Tk. And
> Tcl and Tk are shipped with MacOS X. Anyone know of any highly used Tcl/Tk
> apps on Windows?
>
> :What else? I know these are same old typical questions, but they are
> :asked. I've been around a lot of experienced programmers, most on linux
> :platform, and nobody, including myself, had heard of TCL before, even
> :though some knew about Expect. How come?
>
> Because most of the people writing articles, etc. these days are writing
> about Java, and most of the schools don't teach scripting - if they
> do, they generally teach Perl because it is used on many web sites.
>
> :What does PHP or Perl have
> :that TCL does not?
>
> In general, neither have "something" that one cannot download or code
> for Tcl.  However, at least Perl comes with more functions "out of the
> box" as well as a pretty slick interface to a world wide, supported,
> repository of add on functionality.  While at least one or
> two people have written repositories for Tcl, none of them have set the
> tcl community on fire to join in and support.
>
> :If TCL is a specialized tool for a particular
> :purpose, then what is it?
>
> It isn't a specialized tool.
>
> :I know the idea of TCL, why re-invent the wheel for every tool that
> :supports some kind of scripting when you can use TCL libs, but why
> :Perl. PHP and all the other?
>
> It's the "not invented here" syndrome, in my opinion.  Different
> people resonate with different languages.  Same reason there are hundreds,
> if not thousands, of human languages.  Why doesn't everyone speak just
> one human language?
>
> :What's TCL's flaw? It seems faster to me
> :than PHP, more legible than Perl, .. so what's lacking? Advertising? Or
> :is there another reason?
>
> Oh, there was a bit of advertising.  But it has always been drowned out
> by the popular press for perl, then python, then java.  Shrug.  For me,
> Tcl works just as well as it would if there were 10 times more users.
> And I suspect I get quicker answers to my questions now ... because it
> doesn't seem that the size of the community involvement increases
> geometrically, let alone exponentially, as the user base increases.
>
> -- 
> <URL: http://wiki.tcl.tk/ > Indescribable,uncontainable,all 
> powerful,untameable
> Even if explicitly stated to the contrary, nothing in this posting
> should be construed as representing my employer's opinions.
> <URL: mailto:lvirden@gmail.com > <URL: http://www.purl.org/NET/lvirden/ > 


0
no672 (255)
12/2/2005 3:22:28 PM
Hmmm.. interesting point..
Recently I upgraded to Apache2.. just a new Debian setup, I thought "why not 
get the latest and greatest version on this new install?". Only to have 
problems with PHP.. because it doesn't work with the DEFAULT apache2 setup, 
that uses mpm-worker thread... had to install apache2-mpm-prefork instead.

I read about it, and.. found the depate about Apache and PHP shoving off 
blame to eachother.. PHP is not thread safe, and is declared that PHP has no 
intention to ever support Apache2 in its multithreaded mode that actually 
boost Apache2 performance and memory requirements, but that it isn't their 
problem.. And Apache2 doesn't see it as their problem either.

This is just stuff I picked up on the news group.. now, I love PHP.. and use 
it plenty, however, can't TCL take adventage of this current issue to 'catch 
up' and perhaps even surpass PHP's popularity?

Is TCL thread safe? Does it support Apache2's new threading model?
I've used PHP for a few years and TCL only for 2 weeks and I'm already 
willing to make the switch.. no, of course you should not present PHP as the 
enemy, and with that, all of its addicts.. keep them a friend, get them to 
use it side by side first.. TCL doesn't have to rule the world, as long as 
it's known as well as the other alternatives.

Lisa


"Cameron Laird" <claird@lairds.us> wrote in message 
news:ss6163-dnk.ln1@lairds.us...
> In article <1133372169.815267.318400@f14g2000cwb.googlegroups.com>,
> Larry W. Virden <lvirden@gmail.com> wrote:
>>Define what you mean when you write "was Tcl ever marketed"?  Does Sun
>>touting articles about Tcl on the sun.com front page count?  Does
>>articles in various magazines, from Dr. Dobbs, to various Linux
>>magazines, to Computerworld count? Does major companies like Oracle and
>>Vignette using and advertising they use Tcl count?
>>
>
> My congratulations, by the way, to the PHPers.  The project has
> been on the verge of collapse at least a couple of times, and
> received serious non-help at crucial times from organizations
> that might have made a difference.  Despite these obstacles, it
> has flourished.  Along with its intimacy with Apache, its early
> collaborative documentation was essential, in my view. 


0
no672 (255)
12/2/2005 3:30:42 PM
Donal K. Fellows wrote:
> Michael Schlenker wrote:
>> http://wiki.tcl.tk/14972 ) that at least the author of Tcldb is looking
>> for help (and it is my favorit currently, for nicest set of
>> functionalities, followed by Tclodbc, nstcl-database and DIO). I heard
>> Michael Cleverly talking about updating nstcl with 8.5 features once 8.5
>> comes out, and others seem to be interested too.
> 
> I strongly urge people interested in doing database APIs to take a look
> at how SQLite does its higher-level APIs. Richard Hipp's got it right
> (and whether or not you use cursors underneath is almost immaterial to
> most programmers; do the "Right Thing" instead of overwhelming people
> with options with subtle effects).

I can just agree with Donal on this. SQLites API is really a nice fit
for Tcl, some of the abstraction layers move in similar directions, but
non of them really has this smooth set of interlocking features
introduced in SQLites Tcl API. The SQLite eval method with its variable
binding and autoquoting in querys, the flexible way to get the result
set with no fuzz (the only thing thats missing is returning nested
lists, but thats trivial to do.), the really good transaction support,
the callbacks for progress and transactions, all really nice.

The basic DB functionality is done really good in the SQLite API and
others could benefit from picking it up instead of basically porting the
C API exposed by their database to Tcl without adapting the API.

What some of the Tcl DB Abstraction Layers offer are things like support
functions for portable table constructions, table objects to use for
easy handling of the result sets and other nice extras. But those are
extra, on the basic database access API all DB abstraction layers are so
close to each other (see the above mentioned comparision) that they
could simply unify on something very similar to the SQLite API and just
put their cool extras into addon packages.

Michael



0
schlenk (1615)
12/2/2005 3:34:10 PM
I just posted another message in this thread.. about the issues between PHP 
and Apache2's new threading model.
Does TCL suffer the same issues, or could TCL take advantage of the fact 
that Apache and PHP have come to a point of weakness, to a point where they 
point fingers at eachother (from what I read in some news groups, in an 
effort to find out why PHP5 wasn't working with Apache2 with 
apache2-mpm-worker on Debian Sarge)

Lisa

"Robert Hicks" <sigzero@gmail.com> wrote in message 
news:1133477674.592032.146850@g44g2000cwa.googlegroups.com...
> What do you think should be done?
>
> A great "full stack" web framework in the vein of Rails, TurboGears,
> Django, Catalyst would be something to show. These frameworks have high
> visibility right now. We have Rivet and several db abstraction layers.
> Marry them, throw some weight behind Rivet to get it on more platforms
> and build a framework around it.
>
> A CPAN implementation "blessed" and used by the community would be
> nice.
>
> There was a recent comparison on the Tcl wiki about db abstraction
> layers. It would be nice to "pick one" and work to extend it to be a
> "defacto" abstraction layer ala the Perl DBI.
>
> Magazine articles...
>
> Web articles...all over...also O'Reilly might be willing to create a
> Tcl space like the other have where we could post articles and then
> anyone visiting the O'Reilly site would see the blurbs on the main page
> and might just read the article and be curious enough to try Tcl.
>
> I would be willing to talk with O'Reilly about a Tcl section if we
> could get articles posted. Really some of the little apps that show up
> on the wiki would be great little articles that could show how easy
> things are in Tcl.
>
> There might be other things as well.
>
> The problem is usually the "someone" problem. "Someone needs to or
> should do it but nobody does".
>
> Robert
> 


0
no672 (255)
12/2/2005 3:34:21 PM
Bryan Oakley wrote:

> Ian Bell wrote:
>> 
>> Don't get me wrong, I think Tcl/Tk is the best thing since sliced bread,
>> but IMHO it is not going to make an serious impact until the appearance
>> of the widgets is improved.
> 
> Are you aware of the tile project? You wanna talk sliced bread? Tile is
> the whole loaf, a jar of jelly and a jar of peanut butter! And a knife.
> 
> Coming soon to an 8.5 tcl/tk core near you.
> 
> http://tktable.sourceforge.net/tile

I had heard of the tile project but was *not* aware it was feted for
inclusion in 8.5. I am off to that URL RIGHT NOW!!

Ian
0
ruffrecords2 (612)
12/2/2005 3:36:55 PM
There already is a lot of PHP code. Many people are refusing to upgrade to 
Apache2 from Apache 1.3 because of the incompatibility issue. To make PHP 
work with Apache2 requires the use of the prefork model instead of the 
default, which is said to actually make Apache slower and more resource 
hungry and thus defeats much of the purpose to upgrade.

So this PHP/Apache2 issue is working against the two instead of helping each 
other it seems.

I read and understand too little about the threading issues of PHP and 
Apache2, but I wonder if TCL, if it doesn't suffer the same constraints as 
PHP, could initially used as some kind of stub/proxy to process PHP scripts 
on behalf of Apache2 so that it sits between PHP and Apache and perhaps this 
was resolves the threading issue? Perhaps I'm talking crap, but such thing 
would sneak TCL into the PHP world, and soon enough take it over.

Lisa

"Lisa Pearlson" <no@spam.plz> wrote in message 
news:43906955$0$13786$e4fe514c@dreader17.news.xs4all.nl...
>I just posted another message in this thread.. about the issues between PHP 
>and Apache2's new threading model.
> Does TCL suffer the same issues, or could TCL take advantage of the fact 
> that Apache and PHP have come to a point of weakness, to a point where 
> they point fingers at eachother (from what I read in some news groups, in 
> an effort to find out why PHP5 wasn't working with Apache2 with 
> apache2-mpm-worker on Debian Sarge)
>
> Lisa
>
> "Robert Hicks" <sigzero@gmail.com> wrote in message 
> news:1133477674.592032.146850@g44g2000cwa.googlegroups.com...
>> What do you think should be done?
>>
>> A great "full stack" web framework in the vein of Rails, TurboGears,
>> Django, Catalyst would be something to show. These frameworks have high
>> visibility right now. We have Rivet and several db abstraction layers.
>> Marry them, throw some weight behind Rivet to get it on more platforms
>> and build a framework around it.
>>
>> A CPAN implementation "blessed" and used by the community would be
>> nice.
>>
>> There was a recent comparison on the Tcl wiki about db abstraction
>> layers. It would be nice to "pick one" and work to extend it to be a
>> "defacto" abstraction layer ala the Perl DBI.
>>
>> Magazine articles...
>>
>> Web articles...all over...also O'Reilly might be willing to create a
>> Tcl space like the other have where we could post articles and then
>> anyone visiting the O'Reilly site would see the blurbs on the main page
>> and might just read the article and be curious enough to try Tcl.
>>
>> I would be willing to talk with O'Reilly about a Tcl section if we
>> could get articles posted. Really some of the little apps that show up
>> on the wiki would be great little articles that could show how easy
>> things are in Tcl.
>>
>> There might be other things as well.
>>
>> The problem is usually the "someone" problem. "Someone needs to or
>> should do it but nobody does".
>>
>> Robert
>>
>
> 


0
no672 (255)
12/2/2005 3:39:10 PM
Lisa Pearlson wrote:
> Hmmm.. interesting point..
> Recently I upgraded to Apache2.. just a new Debian setup, I thought "why not 
> get the latest and greatest version on this new install?". Only to have 
> problems with PHP.. because it doesn't work with the DEFAULT apache2 setup, 
> that uses mpm-worker thread... had to install apache2-mpm-prefork instead.
> 
> I read about it, and.. found the depate about Apache and PHP shoving off 
> blame to eachother.. PHP is not thread safe, and is declared that PHP has no 
> intention to ever support Apache2 in its multithreaded mode that actually 
> boost Apache2 performance and memory requirements, but that it isn't their 
> problem.. And Apache2 doesn't see it as their problem either.
> 
> This is just stuff I picked up on the news group.. now, I love PHP.. and use 
> it plenty, however, can't TCL take adventage of this current issue to 'catch 
> up' and perhaps even surpass PHP's popularity?
> 
> Is TCL thread safe? Does it support Apache2's new threading model?
> I've used PHP for a few years and TCL only for 2 weeks and I'm already 
> willing to make the switch.. no, of course you should not present PHP as the 
> enemy, and with that, all of its addicts.. keep them a friend, get them to 
> use it side by side first.. TCL doesn't have to rule the world, as long as 
> it's known as well as the other alternatives.

AFAIK Rivet also has problems with the Apache2 threading model. WebSH
supports Apache2, but i do not know if there are problems with threads.

Contact David N. Welton on the rivet mailing if your interested in all
the gory details of Threads + Rivet. AFAIK Rivet does not blame Apache
for their new thread model, it was just not yet ported to the new thread
model.

But to Tcl is thread safe, see for example the massive use of multi
threaded Tcl inside aolserver (which had a threaded instead of a fork()
based model from the start, unlike Apache). So yes, you can do high
performance web stuff with Tcl in threaded environments, there needs
just to be someone to do the work and port Rivet to multi threaded Apache.

Michael





0
schlenk (1615)
12/2/2005 3:45:06 PM
Ian Bell wrote:
> Robert Hicks wrote:
>
> > What do you think should be done?
> >
> > A great "full stack" web framework in the vein of Rails, TurboGears,
> > Django, Catalyst would be something to show. These frameworks have high
> > visibility right now. We have Rivet and several db abstraction layers.
> > Marry them, throw some weight behind Rivet to get it on more platforms
> > and build a framework around it.
> >
>
> Don't get me wrong, I think Tcl/Tk is the best thing since sliced bread, but
> IMHO it is not going to make an serious impact until the appearance of the
> widgets is improved.
>
> Ian

I don't agree with that. Just about every "dynamic" language has Tk
bindings and I have never seen anything about "I chose Python because
of Tkinter". We might as well shock the world and say we are going to
focus on a "Wx" implementation instead of "Tk". Wx is starting to show
up on all the major OS's (Widows, Linux, OSX, BSD's). I don't think
Tk+Tile is going to create an influx of users for Tcl because all the
other languages that tie into Tk will get that benefit as well.

All of the things I mentioned were outside of Tk. Python is in the news
because of TurboGears and Django. Ruby is in the news because of Rails.
Java goes without saying but most of the things I see about it are
about frameworks that make developing web applications easier. Even
Perl is starting to come on with its framework Catalyst.

Let's suppose that we do those 4 things I mentioned (a full stack
framework, a more visible blogspace like O'Reilly, a db abstraction
layer, and a CPAN like repository). Now let's suppose that we
implemented them and it didn't do anything to bring Tcl into the
limelight. The one thing it would do is give the current community some
really good tools to work with that people have posted over and over
about wanting. That can only be a good thing for the community.

Those are my thoughts...

Robert

0
sigzero (1319)
12/2/2005 3:54:40 PM
In article <4390668c$0$13804$e4fe514c@dreader17.news.xs4all.nl>,
Lisa Pearlson <no@spam.plz> wrote:
			.
			.
			.
>And I don't understand Tk yet.. that looked like chinese to me at first 
>sight.. haven't looked at it since.. and I don't understand the relationship 
>between TCL en TK yet.. TK is not part of or dependent on TCL, but a thing 
>of its own, that can be scripted with TCL, but Perl or any other language 
>that supports TK, do I understand that correctely?
			.
			.
			.
<URL: http://wiki.tcl.tk/487 >
0
claird (2363)
12/2/2005 7:08:03 PM
Lisa Pearlson (no@spam.plz) wrote:

: can't TCL take adventage of this current issue to 'catch 
: up' and perhaps even surpass PHP's popularity?

No.

0
yf110 (571)
12/2/2005 9:28:53 PM
Ian Bell wrote:

> Bryan Oakley wrote:
> 
>> Ian Bell wrote:
>>> 
>>> Don't get me wrong, I think Tcl/Tk is the best thing since sliced bread,
>>> but IMHO it is not going to make an serious impact until the appearance
>>> of the widgets is improved.
>> 
>> Are you aware of the tile project? You wanna talk sliced bread? Tile is
>> the whole loaf, a jar of jelly and a jar of peanut butter! And a knife.
>> 
>> Coming soon to an 8.5 tcl/tk core near you.
>> 
>> http://tktable.sourceforge.net/tile
> 

I have had a good look at tile. It is certainly an improvement over the
standard widget set. At least the default scroll bars look decent at last
but why oh why do we still swap the mouse pointer direction when a menu is
selected????? I notice the Keramik theme manages to avoid this behavior in
a menu button but all themes seem to retain it in the main menu bar. The
only other prog I know of that still does this is Xemacs.

Ian
0
ruffrecords2 (612)
12/2/2005 9:46:52 PM
Robert Hicks wrote:

> 
> Ian Bell wrote:
>> Robert Hicks wrote:
>>
>> > What do you think should be done?
>> >
>> > A great "full stack" web framework in the vein of Rails, TurboGears,
>> > Django, Catalyst would be something to show. These frameworks have high
>> > visibility right now. We have Rivet and several db abstraction layers.
>> > Marry them, throw some weight behind Rivet to get it on more platforms
>> > and build a framework around it.
>> >
>>
>> Don't get me wrong, I think Tcl/Tk is the best thing since sliced bread,
>> but IMHO it is not going to make an serious impact until the appearance
>> of the widgets is improved.
>>
>> Ian
> 
> I don't agree with that. Just about every "dynamic" language has Tk
> bindings and I have never seen anything about "I chose Python because
> of Tkinter". We might as well shock the world and say we are going to
> focus on a "Wx" implementation instead of "Tk". Wx is starting to show
> up on all the major OS's (Widows, Linux, OSX, BSD's). I don't think
> Tk+Tile is going to create an influx of users for Tcl because all the
> other languages that tie into Tk will get that benefit as well.
> 
> All of the things I mentioned were outside of Tk. Python is in the news
> because of TurboGears and Django. Ruby is in the news because of Rails.
> Java goes without saying but most of the things I see about it are
> about frameworks that make developing web applications easier. Even
> Perl is starting to come on with its framework Catalyst.
> 
> Let's suppose that we do those 4 things I mentioned (a full stack
> framework, a more visible blogspace like O'Reilly, a db abstraction
> layer, and a CPAN like repository). Now let's suppose that we
> implemented them and it didn't do anything to bring Tcl into the
> limelight. The one thing it would do is give the current community some
> really good tools to work with that people have posted over and over
> about wanting. That can only be a good thing for the community.
> 
> Those are my thoughts...
> 
> Robert

I don't disagree with anything you have said. However I want to create GUI
apps that look as good as any other and with the current Tk widget set they
don't. I am not interested in eye candy but I am interested in relaxing my
end users by presenting them with a familiar looking/acting interface ( or
rather not sensitising them to think this is somehow an odd app. simply
because the UI looks odd). Tk is a very visual interface and its appearance
is very important.

Ian
0
ruffrecords2 (612)
12/2/2005 9:53:04 PM
Ian Bell wrote:

> I have had a good look at tile. It is certainly an improvement over the
> standard widget set. At least the default scroll bars look decent at last
> but why oh why do we still swap the mouse pointer direction when a menu is
> selected????? 

You're probably just seeing the remnants of old standards at play. You 
don't see a different cursor on MacOSX or Windows. Though, tile will 
likely do nothing to solve this particular problem. I think the plan is 
that tk apps will still use the tk menu widget for menubars.

If you want this behavior changed, perhaps you can submit a feature 
request to sourceforge.
0
oakley (2075)
12/2/2005 10:50:40 PM
And a CPAN like feature is probably the thing I have on the top of my wish 
list!
Easy install, update and upgrade lowers the barier greatly for somebody to 
install and use it.. with the thought that it only takes a second to 
install, and uninstall if they don't like it.. but they will.. especially if 
there are some samples to play with.

TCL is nice, cool, and quality will sell itself, but not if it remains 
unseen en thus unknown.. CPAN lowers the barrier significantly. TCL allowes 
quick and easy development of code, but this ease should also be part of the 
entire TCL experience, including its install.

For example, I struggled to get MD5 installed.. I tried it manually from a 
sourceforge tar, and got all kinds of errors and crap.. fortunately I also 
found a debian package libtcl or something with some standard stuff 
including MD5, so I got that working.. but my next problem is getting MySQL 
support.. and I found no Debian package for it..
We shouldn't have to depend on Debian or RPM or whatever, to easily install 
TCL packages.

Lisa

"Robert Hicks" <sigzero@gmail.com> wrote in message 
news:1133538880.520758.246240@g47g2000cwa.googlegroups.com...
>
> Ian Bell wrote:
>> Robert Hicks wrote:
>>
>> > What do you think should be done?
>> >
>> > A great "full stack" web framework in the vein of Rails, TurboGears,
>> > Django, Catalyst would be something to show. These frameworks have high
>> > visibility right now. We have Rivet and several db abstraction layers.
>> > Marry them, throw some weight behind Rivet to get it on more platforms
>> > and build a framework around it.
>> >
>>
>> Don't get me wrong, I think Tcl/Tk is the best thing since sliced bread, 
>> but
>> IMHO it is not going to make an serious impact until the appearance of 
>> the
>> widgets is improved.
>>
>> Ian
>
> I don't agree with that. Just about every "dynamic" language has Tk
> bindings and I have never seen anything about "I chose Python because
> of Tkinter". We might as well shock the world and say we are going to
> focus on a "Wx" implementation instead of "Tk". Wx is starting to show
> up on all the major OS's (Widows, Linux, OSX, BSD's). I don't think
> Tk+Tile is going to create an influx of users for Tcl because all the
> other languages that tie into Tk will get that benefit as well.
>
> All of the things I mentioned were outside of Tk. Python is in the news
> because of TurboGears and Django. Ruby is in the news because of Rails.
> Java goes without saying but most of the things I see about it are
> about frameworks that make developing web applications easier. Even
> Perl is starting to come on with its framework Catalyst.
>
> Let's suppose that we do those 4 things I mentioned (a full stack
> framework, a more visible blogspace like O'Reilly, a db abstraction
> layer, and a CPAN like repository). Now let's suppose that we
> implemented them and it didn't do anything to bring Tcl into the
> limelight. The one thing it would do is give the current community some
> really good tools to work with that people have posted over and over
> about wanting. That can only be a good thing for the community.
>
> Those are my thoughts...
>
> Robert
> 


0
no672 (255)
12/3/2005 12:07:55 AM
Hey, while I DO believe that TCL could be as big as Perl or PHP, with some 
effort (technically it already can, but it's unknown.. and much easier to 
learn.. Organize a programming competition between tcl programmers and 
perl/php programmers, just for fun.. or send in a comparison chart to 
existing popular computer/linux/programming magazines en start a flame war.. 
after the dust settles, they will all be known and accepted side by side.. 
any fame is better than no fame in this case).

But the most interesting part here is, embedded systems.. indeed.. I used to 
be a PalmOS programmer.. I abandoned it because programming for it was too 
cumbersome.. the tools were primitive and a palm 'database' is just a flat 
file, and reading a 'record' meant reading from a certain offset in this 
file.. if you wanted a free compiler, you had a seperate resource compiler 
and primitive compiler, linker, etc.. took forever to write a decent 
application and it drew many of the old Amiga hardcore assembler 
programmers, due to its Motorola CPU.

PalmOS was small, fast, battery efficient, simple, plain, minimalistic, and 
application was just a few Ks, while WindowsCE on a pocket pc was like a 
typical microsoft SUV that guzzles all of the world's natural resources, it 
was very nice and easy to develop software for.. for commrecial reasons I 
made the switch en now I develop on SmartPhone (Windows Mobile) platform..

But still, lacking frameworks like MFC, it takes quite some effort to 
develop apps for it, that would be a breeze with TCL/Tk. And since 
smartphones are becoming common place, with a huge userbase (well, mobile 
phones with java anyay), it would be a great platform for tcl. It could be 
the easiest tool on that platform, with little competition (Except java).

I for one would love to be able to write internet applications on my I-Mate 
SP5 Windows Mobile smart phone, but TCL would make a far bigger difference 
on the PalmOS platform.. because it would make palm programming easy.. 
perhaps much has changed on that platform since I abandoned it (multimedia 
features), but tcl ports to palm, windows ce, symbian and linux based PDA's 
could change the world. Java is slow on these platforms..

Write 1 video game, that runs on all these platforms, requiring tcl, free 
download, and all the kids will be indoctrinated in no time.

Lisa


"Eckhard Lehmann" <ecky-l@web.de> wrote in message 
news:1133385884.104550.108920@z14g2000cwz.googlegroups.com...
>> 1. why use TCL and not Perl for example? (my answer was the legibility
>> but they just say it's a matter of taste and what you're used to)
>
> Because you often need to read and *understand* your code 6 or 12
> months later - this is complicated with perl.
>
>> 2. what are its (dis)advantages?
>
> - It does not appear in manager magazines, and seldomly on the shelves
> of book stores.
> - The documentation is sometimes hard to grab, if you are used to the
> per-class-or-method documentation that is employed in Java, python and
> modern pure OO languages. This is indeed a problem: developers don't
> want to read entire manpages just to find out how a command works -
> they want a short description on exact this command with all arguments
> (options) and want to find this within a few seconds when they need it.
> - really the lack of momentum. No one knows Tcl, no one knows how
> successful projects with Tcl can be. But everyone has heard something
> about Java somewhere. So, just because of this fact, Java gains more
> confidence in projects. It is really necessary to advertise successful
> projects written in Tcl/Tk, and tell the world what is inside.
>
>> 3. what's on the outlook? Is it going to remain a tool used by a few,
>> while the rest of the world moves on with Perl, PHP, Bash and Java?
>
> Tcl will always have its niche as embeddable scripting language and in
> testing environments. Tk will always be included as Widget set in other
> scripting languages. But I doubt that Tcl will ever be as widely spread
> as Python or PHP.
> A new environment could be these embedded handheld/PDA systems and the
> like. When I see it right, Tcl is one of the first _scripting_
> languages that runs on these systems - and that is great ;-).There
> should be more of such efforts... how about bringing Tcl to the .Net
> platform, for instance a Tcl-> .Net compiler?
>
>> What else? I know these are same old typical questions, but they are
>> asked.
>
> Tell them about Tclkit (http://wiki.tcl.tk/2?Q=tclkit). IMHO, this is
> one of the best technologies available.
>
>
> Eckhard
> 


0
no672 (255)
12/3/2005 12:29:11 AM
Ian Bell wrote:

>I don't disagree with anything you have said. However I want to create GUI
>apps that look as good as any other and with the current Tk widget set they
>don't.

It's possible to make Tk apps look better with little effort -- 
Jeff Hobbs has a great tutorial on how to do this, check the
Tcl'2005 conference proceedings -- and with a *lot* of effort
you can make a truly spectacular Tk GUI (see e.g., Coccinella).

As for making apps that look "as good as any other", I think
the main problem is simply one of age.  Tk's default look and feel
actually *was* a lot better than the industry standard on X11
(Motif), but that was 10 years ago, and fashions have changed 
since then.  (The Tile widget set attempts to address this issue).

It's true, Tk "out-of-the-box" doesn't look very modern; that's
largely due to the core maintainers' strong commitment to backwards-
compatibility (just *try* to provide a button widget that doesn't
have a '-bg' option and watch how many existing users complain :-)
But it's certainly *possible* to make a good-looking Tk app; 
and with the 8.5 release it will (we hope) even be *easy*.

--JE
0
jenglish (354)
12/3/2005 3:07:57 AM
Lisa Pearlson wrote:

>[...] if you want power, use C, you want glue, use the best glue 
>there is..

QOTW nomination!

[...]

>And I don't understand Tk yet.. that looked like chinese to me at first 
>sight..  haven't looked at it since..

You are due for a very pleasant surprise.  Take a second look
at Tk, it is (still!) the best/easiest UI toolkit around.
(IMO, of course).

> and I don't understand the relationship 
>between TCL en TK yet.. TK is not part of or dependent on TCL, but a thing 
>of its own, that can be scripted with TCL, but Perl or any other language 
>that supports TK, do I understand that correctely?

Tk *is* dependant, to a degree, on Tcl -- it's a UI toolkit
done "the Tcl way".  Which is what makes it the best (IMO, again).

Other languages (Perl, Python, probably Ruby, don't know) have
Tk modules, but those bindings tend to be second-class citizens;
(maybe Jeff will chime in with further details).  But to fully
appreciate how great Tk is, you really need to use it from Tcl.

--je
0
jenglish (354)
12/3/2005 3:37:28 AM
Tcl happens to be my favorite language.  When people ask me why, I tell
them the following:

Tcl IS significantly different from Perl (or Python, or Ruby, or PHP,
....) because I can turn it into anything that I like.  If I don't like
any of the existing OO extensions, then I make my own (I have make two
different ones, which each have their own advantages).  If a new
languagle construct will make problem solving in the current domain, I
simply add it (and I do mean simply).

Doing such dynamic things in other languages is MUCH more difficult
(simply not worth it, effortwise, in most cases).

You can look on the Tclers Wiki for countless examples (Try...Catch
that looks like Java, playing other languages page, multiple OO
extensions, ...)

Mike

Cameron Laird wrote:
> In article <1133358188.388126.121540@g14g2000cwa.googlegroups.com>,
>  <reageer@yahoo.com> wrote:
>  			.
> 			.
> 			.
> >Since 2 weeks has not been enough for me to know all ins and outs, I
> >wonder how I can convince them of the benefits of TCL. By testing the
> >waters, the first responses I got were:
> >
> >"Why yet another language to learn? I can do everything I want with
> >Perl, and has a greater userbase".
> >
> >So, help me here..
> >
> >1. why use TCL and not Perl for example? (my answer was the legibility
> >but they just say it's a matter of taste and what you're used to)
> >2. what are its (dis)advantages?
> >3. what's on the outlook? Is it going to remain a tool used by a few,
> >while the rest of the world moves on with Perl, PHP, Bash and Java?
> >
> >What else? I know these are same old typical questions, but they are
> >asked. I've been around a lot of experienced programmers, most on linux
> >platform, and nobody, including myself, had heard of TCL before, even
> >though some knew about Expect. How come? What does PHP or Perl have
> >that TCL does not? If TCL is a specialized tool for a particular
> >purpose, then what is it?
> >I know the idea of TCL, why re-invent the wheel for every tool that
> >supports some kind of scripting when you can use TCL libs, but why
> >Perl. PHP and all the other? What's TCL's flaw? It seems faster to me
> >than PHP, more legible than Perl, .. so what's lacking? Advertising? Or
> >is there another reason?
> 			.
> 			.
> 			.
> You do NOT have to know everything about Tcl to make a good
> presentation--although it often helps.
>
> Your colleagues are right:  to zeroth order, Perl and Tcl *are*
> the same language, and much of the difference in practice is a
> matter of taste.
>
> How does Tcl compare to Perl?  <URL: http://wiki.tcl.tk/1330 >
> has details.
>
> In these terms, I don't particularly expect Tcl ever to be other
> than "a tool used by the few".  On the other hand, I *do* expect
> Tcl to be around for a long time into the future, arguably longer
> than Perl or PHP.  In any case, <URL: http://wiki.tcl.tk/1887 >
> might interest you.
>
> Why have people, including you, heard of PHP and Perl, but not
> Tcl?    I suspect that the true answer is a subtle one,
> involving a conjunction of marketing and technical realities
> that few have the experience to synthesize.  I can assure you
> that the ethos of Tcl practitioners is characteristically less
> ... aggressive than that which has prevailed in the Perl and
> PHP communities.  For a variety of historical reasons, pugna-
> cious zealotry hasn't been Tcl's style.
>
> Tcl is a specialized tool for tasks which are hard to character-
> ize in Perl and PHP terms:  high reliability, convenient
> interfacing, technical flexibility, ...
>
> Tcl *is* faster than PHP, and more readable than Perl.  Why
> isn't it known, or even dominant?  I repeat:  there are a
> variety of historical reasons, many of the most prominent
> having to do with vagaries of The Web's evolution.
>
> I was an early adopter and advocate for both Perl and PHP,
> incidentally.
>
> You have correctly identified that Tcl originated as a
> technology for implementation of extension languages.  As
> of 2005, though (or even 1995, for that matter), it's most
> appropriate to present it as a potent general-purpose
> language which happens to be particularly successful in
> embedded situations.

0
12/3/2005 5:05:03 AM
> All of the things I mentioned were outside of Tk. Python is in the news
> because of TurboGears and Django. Ruby is in the news because of Rails.
> Java goes without saying but most of the things I see about it are
> about frameworks that make developing web applications easier. Even
> Perl is starting to come on with its framework Catalyst.

There is AOLserver with much Tcl functionality. If all the small
commands and libraries were aggregated into an abstract and powerful
web development framework, that would be an option, wouldn't it?
I would not start something completely new - it usually takes ages
until new projects are usable and customers are more confused, when too
many options/libraries/programs are available (what of the 34 web
development frameworks for Tcl should I use, which is the best one?)...
Let's rather extend and improve things that already exist here.

The problem is always the question "who should do it?". It is almost a
full time job for someone, and this person(s) has to draw a sallary...
I've seen at the page of RubyOnRails, that they provide hosting, and a
fraction of the hosting income goes into Rails development. Would this
be an option, maybe in addition to other things?


Eckhard

0
ecky-l (428)
12/3/2005 11:05:19 AM
A short addition: I've seen that the AOLserver Tcl API is indeed very
big and provides much functionality... but obviously, a HTML template
library is missing.

And I meant "salary", not "sallary" (non-native-speaker-error ;-)).


Eckhard

0
ecky-l (428)
12/3/2005 12:02:37 PM
Lisa Pearlson wrote:

> I for one would love to be able to write internet applications on my I-Mate 
> SP5 Windows Mobile smart phone, but TCL would make a far bigger difference 
> on the PalmOS platform.. because it would make palm programming easy.. 
> perhaps much has changed on that platform since I abandoned it (multimedia 
> features), but tcl ports to palm, windows ce, symbian and linux based PDA's 
> could change the world. Java is slow on these platforms..

They just aren't fast platforms, first of all.  Tcl isn't likely to beat
Java in the speed arena.

That said, have a look at Hecl (www.hecl.org) - it's still in the
initial stages, but you can write small programs for any J2ME system
with it!

-- 
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/
0
davidw (997)
12/3/2005 4:13:08 PM
Lisa Pearlson wrote:

> For example, I struggled to get MD5 installed.. I tried it manually from a 
> sourceforge tar, and got all kinds of errors and crap.. fortunately I also 
> found a debian package libtcl or something with some standard stuff 

tcllib, the standard Tcl library.  Although if it's standard, it's a
pity it doesn't ship with Tcl...

> including MD5, so I got that working.. but my next problem is getting MySQL 
> support.. and I found no Debian package for it..

There are several.  'mysqltcl' for instance.

> We shouldn't have to depend on Debian or RPM or whatever, to easily install 
> TCL packages.

The best that we're likely to attain anytime in the near future is to
have a 'batteries included' distribution that includes all kinds of
stuff like tcllib.

-- 
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/
0
davidw (997)
12/3/2005 4:15:49 PM
Yes I do agree totally with that, I didn't mean to marginalize
anything. I am very excited about Tile myself.

Robert

0
sigzero (1319)
12/3/2005 5:49:08 PM
I checked with O'Reilly, we can submit articles and they will go up but
a separate section goes to those who get high enough traffic.

So if you are a Tcl'er, I would start to submit articles to O'Reilly.
That is one easy way to get some Tcl exposure.

0
sigzero (1319)
12/3/2005 5:55:28 PM
Joe English wrote:
> 
> It's possible to make Tk apps look better with little effort --
> Jeff Hobbs has a great tutorial on how to do this, check the
> Tcl'2005 conference proceedings -- and with a *lot* of effort
> you can make a truly spectacular Tk GUI (see e.g., Coccinella).
> 

I have searched but I cannot find the proceedings anywhere. I have found a
reference to the topic in the tutorials section and I have even checked
Jeff Hobbs' web page but the article is not there either.

Ian
0
ruffrecords2 (612)
12/3/2005 7:40:56 PM
Bryan Oakley wrote:

> Ian Bell wrote:
> 
>> I have had a good look at tile. It is certainly an improvement over the
>> standard widget set. At least the default scroll bars look decent at last
>> but why oh why do we still swap the mouse pointer direction when a menu
>> is selected?????
> 
> You're probably just seeing the remnants of old standards at play. You
> don't see a different cursor on MacOSX or Windows. Though, tile will
> likely do nothing to solve this particular problem. I think the plan is
> that tk apps will still use the tk menu widget for menubars.
> 
> If you want this behavior changed, perhaps you can submit a feature
> request to sourceforge.

I would like it changed, more so because I had not realised it was limited
to Linux/Unix platforms. I'll do as you suggest.

Thanks

Ian
0
ruffrecords2 (612)
12/3/2005 7:47:00 PM
Ian Bell wrote:
> I have searched but I cannot find the proceedings anywhere. I have found a
> reference to the topic in the tutorials section and I have even checked
> Jeff Hobbs' web page but the article is not there either.

As they were content you had to pay extra for, the tutorials are not
available online anywhere (well, not unless the people giving them have
put the material up!)

Donal.
0
12/4/2005 1:03:47 AM
Mike Rogers wrote:
> Tcl IS significantly different from Perl (or Python, or Ruby, or PHP,
> ...) because I can turn it into anything that I like.  If I don't like
> any of the existing OO extensions, then I make my own (I have make two
> different ones, which each have their own advantages).  If a new
> languagle construct will make problem solving in the current domain, I
> simply add it (and I do mean simply).

Good point. This sort of thing puts Tcl much more in the same sort of
class of languages as Lisp, Forth and ML. It comes at that sort of thing
from quite a different direction to those languages, but that is
elevated company indeed.

The other highly distinguishing factor is the fact that the core
language constructs are on the same linguistic basis as code you write
yourself. I can remember (from years ago when I was learning) that it
was amazing to me that you could replace something fundamental like
[while] with your own version *and* that that new version could be
written in the language itself. That's a very rare combination indeed.

Donal.
0
12/4/2005 1:14:58 AM
Donal K. Fellows wrote:

> Ian Bell wrote:
>> I have searched but I cannot find the proceedings anywhere. I have found
>> a reference to the topic in the tutorials section and I have even checked
>> Jeff Hobbs' web page but the article is not there either.
> 
> As they were content you had to pay extra for, the tutorials are not
> available online anywhere (well, not unless the people giving them have
> put the material up!)
> 
> Donal.

I guessed as much. Proceedings of previous year's are there but I do not
really want to wait that long ;-) I'll email Jeff.

Ian
0
ruffrecords2 (612)
12/4/2005 8:23:09 AM
Robert Hicks wrote:
> I checked with O'Reilly, we can submit articles and they will go up but
> a separate section goes to those who get high enough traffic.
> 
> So if you are a Tcl'er, I would start to submit articles to O'Reilly.
> That is one easy way to get some Tcl exposure.

I kind of thought they didn't really like Tcl there.  Maybe it's not
"Web 2.0" enough;-)

-- 
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/
0
davidw (997)
12/4/2005 3:48:34 PM
> I kind of thought they didn't really like Tcl there.  Maybe it's not
> "Web 2.0" enough;-)

Where I really think it is time for "Web 2.0" from a technical and
users point of view. Probably that is the reason why Rails and those
frameworks are so successful... Tcl should catch up here, before it is
too late.


Eckhard

0
ecky-l (428)
12/4/2005 7:02:02 PM
Eckhard Lehmann wrote:
>>I kind of thought they didn't really like Tcl there.  Maybe it's not
>>"Web 2.0" enough;-)
> 
> 
> Where I really think it is time for "Web 2.0" from a technical and
> users point of view. Probably that is the reason why Rails and those
> frameworks are so successful... Tcl should catch up here, before it is
> too late.

It is already too late, unless someone descends from the heavens and
starts producing lots of code, and I don't see that happening.  As it
is, there aren't enough people working on projects like tclhttpd and Rivet.

The comment about "Web 2.0" is in reference to the fact that it is
basically a marketing term invented by O'Reilly and friends to sell
books about "Web 2.0".  I'd rather see book sellers spotting trends and
writing about them, rather than trying to create them.

I like Paul Graham's take on it: http://www.paulgraham.com/web20.html

-- 
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/
0
davidw (997)
12/5/2005 7:50:12 AM
> It is already too late, unless someone descends from the heavens and
> starts producing lots of code, and I don't see that happening.  As it
> is, there aren't enough people working on projects like tclhttpd and Rivet.

No, I don't think so. It is not too late to actually *start* producing
code. I don't know how long it took for Rails to become a usable
framework, but I estimate the _technical_ work involved for a similar
thing in Tcl to be around one year or one and a half - given at least
one person working on it full time.
We should not forget, that there are already very good and stable
building blocks available: Rivet, AOLserver, oratcl (mysqltcl...),
tDOM... and (hopefully) the built in object system in 8.5. It is not
about starting something completely new from scratch, it is about
bringing all these tools together into an usable and abstract framework
(see my other post above). The design patterns are given as well, so
there is not even this to redesign - except for consideration of some
Tcl specific aspects.
Another thought is, that this could give new momentum to projects like
rivet and tclhttp.

This would really rock and show the world that Tcl is alive. I am
certainly not the person who works fulltime on this project (although I
could imagine, if I was currently unemployed ;-)), but I would be happy
to contribute as much as I can.


Eckhard

0
ecky.l (13)
12/5/2005 8:24:31 AM
David N. Welton wrote:

> Eckhard Lehmann wrote:
> 
>>>I kind of thought they didn't really like Tcl there.  Maybe it's not
>>>"Web 2.0" enough;-)
>>
>>
>>Where I really think it is time for "Web 2.0" from a technical and
>>users point of view. Probably that is the reason why Rails and those
>>frameworks are so successful... Tcl should catch up here, before it is
>>too late.
Hello,

I am not really familiar w/ the "Web2.0" phrase, it kinda sounds like 
"scubbing bubbles..."
My interpretation of a Web2 might be along the Seaside/Rails 
implementations...very OO very pattern based.

WRT "being too late for cl..." and coding from scratch, IMHO, this does 
not have to be.
A few years ago, Dr. Neumann and co  created their "Actiweb" framework, 
which I believe ships with the XOTCL distro.

AFAIU from reading the papers, Actiweb uses a "modern", layered, 
patterns based OO approach to web development.

I feel that this framework is a sound foundation for further development...

The architecture consists of the following components,

xoAWO			Active Web Objects
xoComm			OO implementation of HTTP server
xoReg			Object Registry Service
xoRDF			RDF parser for matadata
xoXML			XML parser
xoStore			Persistence layer for active objects
xoMOS			Mobile object system

 From what I see, there's some similarity with the Rails framework....

RAILS				ACTIWEB
Webrick				HttpPlace/xoComm
Dispatcher			HttpWorker
ActiveRecord			xoAWO, xoStore
ActionWebService		xoXML xoRDF, xoMOS

Looking at the Rails cookbook tutorial

http://www.onlamp.com/pub/a/onlamp/2005/01/20/rails.html

1. I noticed that Rails adds the web application tree in one shot...

2. One command maps a class to a db table,
	class Recipe < ActiveRecord::Base
	end

The corresponding controller is also created..

Kinda cool, I thought, although there seem to be alternative ORM's than 
direct class to table mappings...
XOTcl from what I gather, has automatic persistence for objects, and not 
necessarily in an RDBMS. I dont know what kind of ORM is in there...

3. The "scaffold" method automatically creates "list, show, edit, and 
delete" actions and corresponding view templates...

If one were to also use the tcl plugin, one could also load XOTclide in 
the browser and inspect/change the running server
just as one does in Seaside...(or Tclhttpd for that matter...)

While I am not necessarily proposing to copy the Rails framework, I do 
think that the foundation of a new(er) web framework for tcl
is there in Actiweb. A templating system would need to be adopted (.tml, 
..rvt anyone...)

Might also fit in and showcase the recent OO/XOTcl TIP

Actiweb might need to be christened "Tcl-on-Track" or something catchy 
to gain some exposure...

Maybe Dr. N could fill in/comment on the feasilbility of this or some 
applications of Actiweb...

regards,

nikos
> 
> 
> It is already too late, unless someone descends from the heavens and
> starts producing lots of code, and I don't see that happening.  As it
> is, there aren't enough people working on projects like tclhttpd and Rivet.
> 
> The comment about "Web 2.0" is in reference to the fact that it is
> basically a marketing term invented by O'Reilly and friends to sell
> books about "Web 2.0".  I'd rather see book sellers spotting trends and
> writing about them, rather than trying to create them.
> 
> I like Paul Graham's take on it: http://www.paulgraham.com/web20.html
> 

0
12/5/2005 2:37:46 PM
It doesn't have to be from "scratch". A marrying of technologies would
be better. Rivert+db abstraction+whatever-is-cool would be the best
approach.

The problem isn't really "time", it's "people". I know Rivet itself
would be need some help (and lots would be better) to get it going on
Apache2 and on different operating systems. Who is going to step in to
do this when, in a real sense, there is apathy about it in the first
place?

Robert

0
sigzero (1319)
12/5/2005 3:01:42 PM
slebetman@yahoo.com wrote:
> ...
> It was easier to re-train the VB guys to write Tcl than to port the app
> to VB.

0
cnelson (363)
12/5/2005 3:30:14 PM
> My interpretation of a Web2 might be along the Seaside/Rails
> implementations...very OO very pattern based.

That's my interpretation, too ;-).

> [ActiWeb]

This sounds very well. I did not actually evaluate it yet, but it seems
like it is exactly what is needed. Thanks for pointing this out...


Eckhard

0
ecky.l (13)
12/5/2005 7:05:23 PM
Eckhard Lehmann wrote:
>>It is already too late, unless someone descends from the heavens and
>>starts producing lots of code, and I don't see that happening.  As it
>>is, there aren't enough people working on projects like tclhttpd and Rivet.
> 
> 
> No, I don't think so. It is not too late to actually *start* producing
> code. I don't know how long it took for Rails to become a usable
> framework, but I estimate the _technical_ work involved for a similar
> thing in Tcl to be around one year or one and a half - given at least
> one person working on it full time.

So - while Ruby on Rails, Django, and company mature, improve, and add
users and developers in this year and a half, some magic Tcl elf is
going to pop up and dedicate a bunch of time to doing something that
matches what those guys have already?  I think that's wishful thinking.

> This would really rock and show the world that Tcl is alive. I am
> certainly not the person who works fulltime on this project (although I
> could imagine, if I was currently unemployed ;-)), but I would be happy
> to contribute as much as I can.

It's a nice thought, but I guess I'm a bit burnt out and disappointed in
what I've seen already.  And it's not just Rivet - I follow most of the
other Tcl/web stuff, and none of it really gets the attention it deserves.

I would love to be proven wrong, of course:-)

-- 
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/
0
davidw (997)
12/5/2005 8:57:37 PM
Well, TurboGears isn't that old.  I want to say 6 months or so.
TurboGears just glues together other Pythonic things.

The problem is DEVELOPERS. Who is going to help with Rivet? Who is
going to help with the db abstraction? Those others frameworks are
using some kind of ORM, does Tcl even have an ORM?

I know David would love to have lots of help with Rivet but with none
coming...???

So to end this thread...it is another of those "Tcl should" but "Tcl
can't" because of lack of "developers" and "time".

Robert

P.S. I just want to make it a point. This isn't about David W. as I
think he is doing a good job with Rivet. Nobody is there to help is all
and being the lone man toting the rope gets tiring.

0
sigzero (1319)
12/5/2005 10:39:21 PM
Robert Hicks wrote:

> P.S. I just want to make it a point. This isn't about David W. as I
> think he is doing a good job with Rivet. Nobody is there to help is all
> and being the lone man toting the rope gets tiring.

There have been lots of people who have helped over the years, and of
course major portions of the code came from people like Damon Courtney
and Karl Lehenbauer.

Anyway, to put a positive spin back on things, here's a suggestion:

If we accept the fact that Tcl is not going to compete with Ruby on
Rails, maybe we can be creative and think of ways that we can still do
cool stuff that they can't.

Here's one idea off the top of my head:

Hack Rivet to use starkits, so that you can put an entire app on your
webserver as a starkit.  You could even put sqlite in it and have the
database and everything all wrapped up in one nice tidy package.

There are probably better ones lurking out there, but I guess the point
is that Tcl does some things pretty well... it's best to play off those
strengths rather than chase taillights.

-- 
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/
0
davidw (997)
12/5/2005 10:48:48 PM
David N. Welton schrieb:

> So - while Ruby on Rails, Django, and company mature, improve, and add
> users and developers in this year and a half, some magic Tcl elf is
> going to pop up and dedicate a bunch of time to doing something that
> matches what those guys have already?  I think that's wishful thinking.

What about the Actiweb thing or AOLserver? I didn't know about ActiWeb
before, now I would reconsider my time estimation and say it is less
than a year (full time) work on ActiWeb to make it usable. Well, I
didn't evaluate Actiweb yet, still...
It is a matter of having a stable core that is company mature, e.g.
Actiweb on AOLserver. More features and extensions would follow fast, I
think (e.g. Actiweb on Apache).

> It's a nice thought, but I guess I'm a bit burnt out and disappointed in
> what I've seen already.  And it's not just Rivet - I follow most of the
> other Tcl/web stuff, and none of it really gets the attention it deserves.

I think the main reason for that is, that there is too much to code
with Tcl. For instance, making a webshop in Tcl would involve coding
several hundret lines in Tcl - and who should do that, when you can
just pick and adopt a ready-to-run system in PHP?
The existing web building blocks are relatively low level and have not
much functionality, although the quality of existing functionality is
very high. Exactly that is the reason for this discussion. We need a
*high level* Web development framework, something where you can just
drag together the building blocks for problems that appear every day
and everywhere, over and over again in web development.
Once this is done and made popular, people will use it more frequently.
I see very big advantages of Tcl in web development. Consider just, how
easy it would be to have web applications as starkits that don't need
the installation horror of PHP scripts - just place them on your server
web space. You could have a simple persistence layer based on Metakit,
without the overhead of RDBMS if you don't need a complete RDBMS. You
could interface the application with Tclplugin, local standalone Tk
clients or Hecl-scripts on mobiles!
If it was just possible to built web application with Tcl as *easy* as
with PHP...


Eckhard

0
ecky.l (13)
12/6/2005 9:54:27 AM
Eckhard Lehmann wrote:
 > The existing web building blocks are relatively low level and have not
 > much functionality, although the quality of existing functionality is
 > very high. Exactly that is the reason for this discussion. We need a
 > *high level* Web development framework, something where you can just
 > drag together the building blocks for problems that appear every day
 > and everywhere, over and over again in web development.

The thing is that "Ruby on Rails", "Django" and the the rest happend 
because someone (usually, occasionally a couple of people) went away and 
did it. They didn't talk about it, or try and design the system up 
front, or try to rally a group of people to work on it, they just did it.

The same is true in the TCL space, "Rivet" happened because David went 
away and did it, etc. The only way that TCL is going to compete against 
the various web development frameworks is if someone goes away and 
develops such a framework, endlessly discussing why such a framework is 
valuable or how TCL will die without it is pointless. If someone is 
going to develop such a framework, they'll do it because they want to, 
and prompting is unnecessary, if no-one wants to do it, it aint going to 
get done, and no amount of prompting will change that.

It seems to me that even if "we" do "need a *high level* web development 
framework", none of us has yet needed it enough to develop it. We've 
been through several "TCL will die if it doesn't do X" crusades, very 
few (if any) of those X's have been done, and TCL doesn't appear even to 
be unwell.

So if you want a web development framework, make it happen, doesn't have 
to be perfect in it's first iteration, use the really nice sqllite 
bindings that DKF mentioned (because a good db abstraction will use 
something similar), build it on top of rivet (which will get ported to 
Apache 2.0 if someone needs it to be and the existence of your framework 
makes this more likely) or websh or tclhttpd. In short, build it and 
they will come, and all the bits that aren't perfect that you were 
convinced needed to be, will be perfected. If that is "we" really do 
need a high level web development platform.

It's all about scratching itches...

Dan "Something that people taking pain killers know all about" Smart
0
news551 (13)
12/6/2005 7:31:30 PM
On Fri, 2 Dec 2005, Donal K. Fellows wrote:

> Michael Schlenker wrote:
>> http://wiki.tcl.tk/14972 ) that at least the author of Tcldb is looking
>> for help (and it is my favorit currently, for nicest set of
>> functionalities, followed by Tclodbc, nstcl-database and DIO). I heard
>> Michael Cleverly talking about updating nstcl with 8.5 features once 8.5
>> comes out, and others seem to be interested too.
>
> I strongly urge people interested in doing database APIs to take a look
> at how SQLite does its higher-level APIs. Richard Hipp's got it right

As the author of one of the Tcl database abstraction layers, I've got to 
say I agree 100% with Donal.  I wrote nstcl to be compatible with 
AOLserver & ACS/OpenACS, and I do intend to update nstcl to take advantage 
of 8.5 once it's released.

However now that my day-to-day job doesn't have me working with 
AOLserver/OpenACS I find myself using SQLite almost exclusively in new 
projects, and it's Tcl API is just wonderful.  Absolutely wonderful.

I think I'll have a go at writing an SQLite-style wrapper for other 
databases at some point in the next month or two if someone doesn't beat 
me to it. (SQLMedium? ;-)

Michael
0
michael6504 (290)
12/7/2005 6:59:05 AM
Dan Smart schrieb:


> The thing is that "Ruby on Rails", "Django" and the the rest happend
> because someone (usually, occasionally a couple of people) went away and
> did it. They didn't talk about it, or try and design the system up
> front, or try to rally a group of people to work on it, they just did it.

They liked Ruby etc., and wanted to be it on the web - and they did it,
yes... These people work(ed) in the webdev area and have substantial
knowledge of what is needed and should be done.
If I was in the webdev area, I would immediately start to do it for Tcl
(remember, *Tcl*, not TCL). But I am unfortunately not in this
position. I am just a consumer who occasionally needs some HTML based
presentation of some data - usually not my data, not my web server and
not my decision about whatever technology is to be used. So it just is
not feasible for me to get into devlelopment of such a framework - at
least not at the moment.

> The same is true in the TCL space, "Rivet" happened because David went
> away and did it, etc. The only way that TCL is going to compete against
> the various web development frameworks is if someone goes away and
> develops such a framework, endlessly discussing why such a framework is
> valuable or how TCL will die without it is pointless.

You are right (except the TCL, rather than Tcl ;-). But what should
come out if I go for it in the few hours that I call my spare time? Do
you really think that such a relatively big project can be done with
approx 2-3hours work per week? Definitely not! It would take ages to
get something done, and Rails, Django etc. will be kicking it at
longitudes.
No, such a project needs full time work, I stressed that out several
times in previous posts. And full time work can either be invested by
someone who actively works in the field and want's Tcl to be on the web
or by a company specialized for things around (Tcl) scripting, when
this company decides to do it.

To come to the point: I would love to see a powerful webdev framework
for Tcl. I like the language and I do many things in it, so it would be
nice to do webdev with it too.
But I for myself don't need this webdev framework desperately. There is
PHP, and I don't care about using PHP for Web based things. I also
don't care about using Java for these things or whatever - the only
thing I care about is, that I can deliver my projects fast and with
high quality, regardless of the language and regardless of whether it
involves web development or anything else.
And since I do not work actively as web developer, I am not in the
position to start the webdev thingy for Tcl. And - I won't do that just
for fun in my spare time. When it is done 'just for fun', it will stay
'fun' forever.

Just my 2c.


Eckhard

0
ecky.l (13)
12/7/2005 8:11:25 AM
Eckhard Lehmann <ecky.l@gmx.de> wrote:
> When it is done 'just for fun', it will stay 'fun' forever.

I'm glad, that some famous project that started in the early 
nineties 'just for fun' did not stay just 'fun' forever.

Although, otoh., for me it's also a pleasure(fun) to work
with Linus T's "just for fun" project.  So, what's so bad
about "staying fun forever" ?

0
avl1 (2748)
12/7/2005 8:26:43 AM
David N. Welton wrote:
> They just aren't fast platforms, first of all.  Tcl isn't likely to beat
> Java in the speed arena.

Heh. For that, you need Tk. :-D

Donal (AWT, Swing and SWT are *all* sloooooow...)
0
12/7/2005 11:04:31 AM
Tcl/Tk run quite well on my mobile phone O2 Xda mini
(http://wiki.tcl.tk/14530), like before on my iPaq. Pity only is that
[socket] is not available either in Keuchel's port or JCW's Tclkit
Mobile, so I can only use it for stand-alone things like games or
little apps.

The PocketPC page http://wiki.tcl.tk/8688 has links to many of those
that have been "ported" (mostly, just tweaked in geometry) to Windows
CE. My "killer app" on CE is iFile http://wiki.tcl.tk/8540 which is
useful in many ways :)

0
12/7/2005 11:49:43 AM
Why isn't TCL listed at MySQL site, while Ruby is?

http://dev.mysql.com/downloads/

0
reageer (10)
12/7/2005 1:05:41 PM
Andreas Leitgeb schrieb:

> I'm glad, that some famous project that started in the early
> nineties 'just for fun' did not stay just 'fun' forever.
>
> Although, otoh., for me it's also a pleasure(fun) to work
> with Linus T's "just for fun" project.  So, what's so bad
> about "staying fun forever" ?

Linux isn't 'just fun' anymore. It came at the right time, when enough
people were upset about the win3.1/dos stuff and the expensivenes of
other platforms. It got momentum there and now it is in the commercial
area as well as other platforms. I use Linux for 6 years now, long
before Sun, IBM & co entered the field - and I really feel that the
development (especially kernel-development) is pushed by those and
other companies (Novell, RedHat..) much more than it was before.

The point is: Linux came at the right time, addressing the right
problems and attracting the right people. Tcl did this too, by the way
- with Expect and Tk a long time ago. And PHP did it for web
development. There is a long history of such events, usually it happens
when there is immediate need and currently no really good alternatives.
But it is a hard time to invent a new web development framework for fun
- there are heaps of high quality web frameworks available, and they
are used. That implies that, if I would start a new framework in Tcl
for fun, it would be hard to find people who help me with it, because
there are other - ready to use - platforms. And since I don't have a
really potential benefit from the framework by myself, I don't need to
do it at all.


Eckhard

0
ecky.l (13)
12/7/2005 1:21:50 PM
According to Lisa Pearlson <no@spam.plz>:
:What I do feel lacking is indeed something like CPAN, or aptitude/apt-get to 
:easily add/delete modules and upgrade them.

Yep - this has been discussed for years. These kinds of things, unfortunately,
require more time and resources than generally people have available.
The typical reason you see other languages have things like this is
that the alternates are so painful/frustrating for someone that they
go off and do something about it.

Note that people HAVE gone out and done things.  Jean Claude Wippler and
Steve Landers have done marvelous work on starkits. This provides a nice
method of distributing either scripts or binary within a single file.
Steve Cassidy created Cantcl < http://wiki.tcl.tk/Cantcl >, code that
provides the ability to upload package descriptions and files into a
repository. The code is available online, and provides the ability for
someone to upload starkits. Also, there's SDarchive, the starkit archive at
http://mini.net/sdarchive/ , where people can also access these starkits.
I suspect that Debian and other Linux distributions have a variety of
Tcl extension packages available as well.

However, it is going to take staff and resources to provide bandwidth,
disk maintenance, verification that submissions are virus free, probably
some sort of authentication so that Joe Hacker doesn't submit a Tk download
that is really code that steals your credit cards, etc. and so forth.
In other words, there's a LOT of work and liability that one must be
prepared to take on.  And people looking at such work would rather
write code or have a life with their family...


:And installing the MD5 package for TCL was too painful for me. Still not 
:sure what steps are exactely required to install/remove a package (but I 
:know there is documentation available.. just have to read it).

I'm uncertain what you mean here.  What MD5 package? The one in Tcllib,
or one of the many others?  There are not set steps to install or remove
a package. It depends on what kind of package you are working on, what
platform, etc.  And of course, that's part of the issue - differing
platforms, different authors mean different steps to take. And the
result is a mess.  However, note that there IS a standard (see
< http://wiki.tcl.tk/TEA > - doesn't mean that everyone uses it (some
people don't like it, or haven't learned how to use it, or can't
use it because of their environment), but many packages use it and it
should work on POSIX command line type systems (which exist even
on Windows).

:Should be more plug and play to make setup just as convenient as the actual 
:tcl coding itself.

Perhaps - but as I mentioned before, the hurdle is great, and there has
yet to be a champion whose work has taken hold as a community standard.

:And I don't understand Tk yet.. that looked like chinese to me at first 
:sight.. haven't looked at it since.. and I don't understand the relationship 
:between TCL en TK yet.. TK is not part of or dependent on TCL, but a thing 
:of its own, that can be scripted with TCL, but Perl or any other language 
:that supports TK, do I understand that correctely?

Nope. There's two issues here.  Number 1 - Tk is a C based library that
attempts to provide a Tcl interface to graphical user interfaces.  People
in other scripting language camps wanted something similar. So some languages
wrote a very thin layer that just talks to tcl and tk. Other languages, 
such as Perl, attempted to write a deeper interface, so they massage a copy
of the Tk code so that instead of being tcl and tk, the library becomes their
scripting language and tk. As I said, Perl/Tk is one of those types of efforts.
The supposed upside is that the script developer using the converted library
doesn't have to code in Tcl.
The downside is that updates to Tk take longer to make it back to the
community. And bugs that they discover may take longer to make their way
back into Tk.



-- 
<URL: http://wiki.tcl.tk/ > Indescribable,uncontainable,all powerful,untameable
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvirden@gmail.com > <URL: http://www.purl.org/NET/lvirden/ >
0
lvirden (1938)
12/7/2005 2:03:34 PM
In article <Pine.OSX.4.60.0512062355350.7818@powerbook.cleverly.com>,
Michael A. Cleverly <michael@cleverly.com> wrote:
>On Fri, 2 Dec 2005, Donal K. Fellows wrote:
>> I strongly urge people interested in doing database APIs to take a look
>> at how SQLite does its higher-level APIs. Richard Hipp's got it right
>
>As the author of one of the Tcl database abstraction layers, I've got to 
>say I agree 100% with Donal.  I wrote nstcl to be compatible with 
>AOLserver & ACS/OpenACS, and I do intend to update nstcl to take advantage 


Me three - SQLite's API is nice (I've used it often as of late.)  I 
originally wrote Sybtcl's & Oratcl's API to be closer to the C API of
each database, which certainly served my purposes at the time.  

-- 
Tom Poindexter
tpoindex@nyx.net
http://www.nyx.net/~tpoindex/
0
tpoindex1 (87)
12/7/2005 3:26:42 PM
Eckhard Lehmann wrote:
> 
> They liked Ruby etc., and wanted to be it on the web - and they did it,
> yes... These people work(ed) in the webdev area and have substantial
> knowledge of what is needed and should be done.
> If I was in the webdev area, I would immediately start to do it for Tcl
> (remember, *Tcl*, not TCL). But I am unfortunately not in this
> position. I am just a consumer who occasionally needs some HTML based
> presentation of some data - usually not my data, not my web server and
> not my decision about whatever technology is to be used. So it just is
> not feasible for me to get into devlelopment of such a framework - at
> least not at the moment.
Turns out it isn't feasible for anyone else to work on it either, which 
means it won't get done, which means discussing it ad-infinitum is 
spectactularly pointless.

As for the capitalisation nit-pick, (1) it's an acronym, everyone else 
(and I mean everyone JO) is spelling it wrong :-) (2) as I repeatedly 
point out (adittedly not in this post) my spelling is fried due to the 
not insignificant number of pain-killers I'm ingesting.

> 
> You are right (except the TCL, rather than Tcl ;-). But what should
> come out if I go for it in the few hours that I call my spare time? Do
> you really think that such a relatively big project can be done with
> approx 2-3hours work per week? Definitely not! It would take ages to
> get something done, and Rails, Django etc. will be kicking it at
> longitudes.

I think that unless someone starts it, nothing will ever happen. I also 
think that if you started it you might be surprised by how quickly you 
had something that might attract other people to work on it. The saying 
is "A journey of a thousand miles begins with but a single step", not "A 
journey of a thousand miles begins with a long discussion about how 
desireable it would be to be a thousand miles away". (p.s. you did the 
Tcl/TCL thing already, it wasn't that funny the first time).

> No, such a project needs full time work, I stressed that out several
> times in previous posts. And full time work can either be invested by
> someone who actively works in the field and want's Tcl to be on the web
> or by a company specialized for things around (Tcl) scripting, when
> this company decides to do it.

As I pointed out, there demonstrably isn't anyone who fits that bill, 
and if there was, they wouldn't need your encouragement, they would 
already be working on it.
> 
> To come to the point: I would love to see a powerful webdev framework
> for Tcl. I like the language and I do many things in it, so it would be
> nice to do webdev with it too.

I would love to see world peace, and a billion dollars in my bank 
account (and if I had a billion dollars, I'd pay someone to develop this 
cursed framework if only to kill this thread).

> But I for myself don't need this webdev framework desperately. There is
> PHP, and I don't care about using PHP for Web based things. I also
> don't care about using Java for these things or whatever - the only
> thing I care about is, that I can deliver my projects fast and with
> high quality, regardless of the language and regardless of whether it
> involves web development or anything else.

If you don't need it, and obviously noone else needs it (at least not 
enough to actually develop it), then what is the point in going on about it?

> And since I do not work actively as web developer, I am not in the
> position to start the webdev thingy for Tcl. And - I won't do that just
> for fun in my spare time. When it is done 'just for fun', it will stay
> 'fun' forever.
> 
Hmm, I seem to remember this chap called Linus was working on something 
just for fun, what ever happened to that, I'll have to go look when I've 
finished this post...
And earlier, there were these chaps called Dennis and Brian and the 
other one (my apologies "other one", memory like a wossname) wanted to 
play spacewar on a PDP, I can't remember what happened to that project 
either...
You know I do believe you might be entirely wrong on that point...

> Just my 2c.
> 
> 
> Eckhard
> 

Go on, surprise yourself...

Dan "You have no idea how long it takes to produce this drivel[1]" Smart

[1] peobably long enough to develop a web development framework if I 
could concentrate long enough to remember why I had started the editor 
once it had actually started :-).
0
news551 (13)
12/7/2005 8:03:57 PM
Eckhard Lehmann wrote:
> And since I do not work actively as web developer, I am not in the
> position to start the webdev thingy for Tcl.

Only if you insist on not doing anything about it. If you want it to
happen, code something *simple* up that is a bit useful to you (and yes,
standing on the shoulders of a few giants can help here) and put a
decent license on it. Then tell the rest of us about it and we'll see
where we go from there. But sitting there moaning about the fact that
nobody's doing anything about it, well, that's just unproductive (and
that applies to _everyone_, OK?)

> And - I won't do that just
> for fun in my spare time. When it is done 'just for fun', it will stay
> 'fun' forever.

Not necessarily. My Tcling started out as "just for fun" but didn't stay
that way. My first serious Tcl app was a small tool I put together to
help me make pictures for some documentation I was writing, and when
other people saw it in operation (over my shoulder) it snowballed.
(Other people have pointed out Linux as a more commonly known example,
but I usually prefer to use examples from personal experience.)

Donal.
0
12/8/2005 9:30:58 AM
In article <dn6q3m$lrm$1@mailhost.cas.org>,  <lvirden@gmail.com> wrote:
			.
			.
			.
>Note that people HAVE gone out and done things.  Jean Claude Wippler and
>Steve Landers have done marvelous work on starkits. This provides a nice
>method of distributing either scripts or binary within a single file.
>Steve Cassidy created Cantcl < http://wiki.tcl.tk/Cantcl >, code that
>provides the ability to upload package descriptions and files into a
>repository. The code is available online, and provides the ability for
>someone to upload starkits. Also, there's SDarchive, the starkit archive at
>http://mini.net/sdarchive/ , where people can also access these starkits.
>I suspect that Debian and other Linux distributions have a variety of
>Tcl extension packages available as well.
>
>However, it is going to take staff and resources to provide bandwidth,
>disk maintenance, verification that submissions are virus free, probably
>some sort of authentication so that Joe Hacker doesn't submit a Tk download
>that is really code that steals your credit cards, etc. and so forth.
>In other words, there's a LOT of work and liability that one must be
>prepared to take on.  And people looking at such work would rather
>write code or have a life with their family...
			.
			.
			.
.... and that's not all.  Already fossilized are several earlier efforts
to build public repositories, extending back, I think, even before CPAN
was prominent:  ones hosted by NeoSoft, Alcatel (?), ...
0
claird (2363)
12/8/2005 4:08:02 PM
In article <dn6q3m$lrm$1@mailhost.cas.org>,  <lvirden@gmail.com> wrote:
			.
			.
			.
>Nope. There's two issues here.  Number 1 - Tk is a C based library that
>attempts to provide a Tcl interface to graphical user interfaces.  People
>in other scripting language camps wanted something similar. So some languages
>wrote a very thin layer that just talks to tcl and tk. Other languages, 
>such as Perl, attempted to write a deeper interface, so they massage a copy
>of the Tk code so that instead of being tcl and tk, the library becomes their
>scripting language and tk. As I said, Perl/Tk is one of those types of efforts.
>The supposed upside is that the script developer using the converted library
>doesn't have to code in Tcl.
>The downside is that updates to Tk take longer to make it back to the
>community. And bugs that they discover may take longer to make their way
>back into Tk.
			.
			.
			.
There are even other technical possibilities now, as Jeff's work has
demonstrated the Perl/Tk people can, if they choose, enjoy both lower
maintenance costs *and* higher performance while retaining a Perlish
programming interface.
0
claird (2363)
12/8/2005 4:08:04 PM
There is a short talk on the Perl/Tk list about this relating to Perl6.
Whether to continue with Tk or put their energies into another toolkit
where time and talent could be shared/split.

Robert

0
sigzero (1319)
12/8/2005 5:48:58 PM
> Go on, surprise yourself...

OK,there you are - I will see what can be done!
I think, I'll start to look at rivet + apache2 integration first... no
idea what's going on there at the moment and how they play together -
no clue about the apache nor the rivet sources, and no guarantee that
something get's done... But lets stop this discussion now and start to
do something.

You will hear from me, if I have something to announce - eventually at
some time in the future.


Eckhard

0
ecky.l (13)
12/8/2005 6:47:31 PM
Apache2 work needs doing! If you need a tester for Windows I am
available. Talk with David Welton about who currently does the current
Windows Rivet binary and that may help as well.

Robert

0
sigzero (1319)
12/8/2005 7:12:26 PM
Oh, actually I can test on OSX as well.  : )

0
sigzero (1319)
12/8/2005 8:35:03 PM
Eckhard Lehmann wrote:
>>Go on, surprise yourself...
> 
> 
> OK,there you are - I will see what can be done!
> I think, I'll start to look at rivet + apache2 integration first... no
> idea what's going on there at the moment and how they play together -
> no clue about the apache nor the rivet sources, and no guarantee that
> something get's done... But lets stop this discussion now and start to
> do something.
> 
> You will hear from me, if I have something to announce - eventually at
> some time in the future.

I would love it if someone did a Rivet module for Apache 2.  I'm
available for questions, of course, so you don't have to do it
completely on your own:-)

It's probably not all that hard if you want to ignore the threaded MPM's
in Apache 2.  If you want to tackle those, though, you need to figure
out a way of making sure that one Tcl interpreter is created and used
per-thread.  Perhaps one way of doing this would be to delay creation of
the Tcl interpreter until a request has come in and you are in a thread.
 It means the first request would be slow, but probably not even all
that bad.  There may be better ways... I haven't looked at Apache 2 for
a while - maybe 2.2 has some better stuff?

-- 
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/
0
davidw (997)
12/8/2005 9:54:42 PM
According to Robert Hicks <sigzero@gmail.com>:
:Let's suppose that we do those 4 things I mentioned (a full stack
:framework, a more visible blogspace like O'Reilly, a db abstraction
:layer, and a CPAN like repository). Now let's suppose that we
:implemented them and it didn't do anything to bring Tcl into the
:limelight. The one thing it would do is give the current community some
:really good tools to work with that people have posted over and over
:about wanting. That can only be a good thing for the community.

You are right that if these things were done, it would be good for the
existing developer community.

I won't, however, make the claim that these are the highest priority for
the majority of the community. I have no idea what the majority want -
I've not taken a survey on the topic.

And, then there is one more thing. Who is going to work on these things.

It looks like, to my novice eye, that at least 3 of the 4 items above would
each require several years of concentrated effort by 3 or more people .

How many readers of this posting are interested in devoting the majority of
your time over the next year or so to at least one of the four projects
proposed by Robert?

The steps would be, at a minimum, to come up with:

o a detailed vision of what you want for the project
o detailed requirements
o design documents
o coding of a prototype 
o verification that user interface and functionality really meets user needs
o a move from prototype to production quality code, in cycles of deliverables,
	so that people can use the tool over time and refine requirements
	as necessary
o user documentation
o one or more host machines that will commit to long term support of the
	system
o support and improvements to the system


 
-- 
<URL: http://wiki.tcl.tk/ > Indescribable,uncontainable,all powerful,untameable
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvirden@gmail.com > <URL: http://www.purl.org/NET/lvirden/ >
0
lvirden (1938)
12/9/2005 2:27:36 PM
:> We shouldn't have to depend on Debian or RPM or whatever, to easily install 
:> TCL packages.
:
:The best that we're likely to attain anytime in the near future is to
:have a 'batteries included' distribution that includes all kinds of
:stuff like tcllib.

Well, activetcl is a distribution that includes all kinds of stuff. And
there is a tcllib starkit, I think, at the SDarchive.

-- 
<URL: http://wiki.tcl.tk/ > Indescribable,uncontainable,all powerful,untameable
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvirden@gmail.com > <URL: http://www.purl.org/NET/lvirden/ >
0
lvirden (1938)
12/9/2005 2:29:11 PM
According to David N. Welton <davidw@dedasys.com>:
:I kind of thought they didn't really like Tcl there.  Maybe it's not
:"Web 2.0" enough;-)

I don't know why you would think that. They are one of the few
publishers still printing a book relating to Tcl, and they publish
articles about Tcl in the Linux and MacOS sections occasionally.

More articles submitted might even result in a Tcl section.

-- 
<URL: http://wiki.tcl.tk/ > Indescribable,uncontainable,all powerful,untameable
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvirden@gmail.com > <URL: http://www.purl.org/NET/lvirden/ >
0
lvirden (1938)
12/9/2005 2:32:30 PM
According to David N. Welton <davidw@dedasys.com>:
: I follow most of the
:other Tcl/web stuff, and none of it really gets the attention it deserves.

Which Tcl stuff of any sort gets the attention that it deserves?
Other than, of course, the core and Tk? The one package I know of
is ActiveTcl - those wonderkins at ActiveState just keep coming out
with updates on a regular basis.

But nearly all of the other mailing lists for extensions are comatose,
and many of the extensions have minimal releases.  
-- 
<URL: http://wiki.tcl.tk/ > Indescribable,uncontainable,all powerful,untameable
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvirden@gmail.com > <URL: http://www.purl.org/NET/lvirden/ >
0
lvirden (1938)
12/9/2005 2:35:13 PM
According to David N. Welton <davidw@dedasys.com>:
:Hack Rivet to use starkits, so that you can put an entire app on your
:webserver as a starkit.  You could even put sqlite in it and have the
:database and everything all wrapped up in one nice tidy package.

You'd even have 2 choices of databases, since metakit comes in tclkit
already...



-- 
<URL: http://wiki.tcl.tk/ > Indescribable,uncontainable,all powerful,untameable
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvirden@gmail.com > <URL: http://www.purl.org/NET/lvirden/ >
0
lvirden (1938)
12/9/2005 2:36:19 PM
You are correct. I have no idea what people would want as well. 

Robert

0
sigzero (1319)
12/9/2005 3:04:54 PM
In article <4391c530$0$27601$4fafbaef@reader1.news.tin.it>,
David N. Welton <davidw@dedasys.com> wrote:
			.
			.
			.
>> We shouldn't have to depend on Debian or RPM or whatever, to easily install 
>> TCL packages.
>
>The best that we're likely to attain anytime in the near future is to
>have a 'batteries included' distribution that includes all kinds of
>stuff like tcllib.
			.
			.
			.
Better than ActiveTcl <URL: http://wiki.tcl.tk/activetcl >?

I'll be more explicit:  when people ask me about a "batteries-
included Tcl", I urge them to install ActiveTcl (let's leave
MacOS aside for the moment).  With rare exceptions, my inter-
locutors express satisfaction.  I conclude that ActiveTcl is
a correct answer to this question.  It happens to be a fact
that ActiveTcl includes, among several other highlights, 
tcllib.

How do you see it, David?
0
claird (2363)
12/9/2005 3:08:04 PM
Cameron Laird wrote:
> I'll be more explicit:  when people ask me about a "batteries-
> included Tcl", I urge them to install ActiveTcl (let's leave
> MacOS aside for the moment).  

Huh?

Either you mean Mac OSX, in which case there's no reason to leave
it aside; the ActiveTcl releases for Mac OSX work great.

Or you really mean the "classic" Mac OS 9, in which case I have
to ask "who cares?"

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| donald.porter@nist.gov             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|
0
dgp1 (946)
12/9/2005 3:40:58 PM
lvirden@gmail.com wrote:
> According to David N. Welton <davidw@dedasys.com>:
> : I follow most of the
> :other Tcl/web stuff, and none of it really gets the attention it deserves.
> 
> Which Tcl stuff of any sort gets the attention that it deserves?
> Other than, of course, the core and Tk? The one package I know of
> is ActiveTcl - those wonderkins at ActiveState just keep coming out
> with updates on a regular basis.

Thanks!

> But nearly all of the other mailing lists for extensions are comatose,
> and many of the extensions have minimal releases.  

FWIW, I don't like all the other mailing lists for extensions,
although I'm on many of them.  I love this newsgroup - it
collects together lots of Tcl related topics and still remains
over-viewable (insert better word for that here).  I can be sure
not to lose track of important happenings, as well as assisting
those where I can, when I can find the time.

-- 
   Jeff Hobbs, The Tcl Guy
   http://www.ActiveState.com/, a division of Sophos
0
jeffh (1291)
12/9/2005 4:44:23 PM
Are you talking MacOS <= 9? Why wouldn't you urge them to do so on OSX?
I use AT on OSX and am very happy with it.

Just curious...

Robert

0
sigzero (1319)
12/9/2005 5:33:02 PM
Cameron Laird wrote:

>>>We shouldn't have to depend on Debian or RPM or whatever, to easily install 
>>>TCL packages.
>>
>>The best that we're likely to attain anytime in the near future is to
>>have a 'batteries included' distribution that includes all kinds of
>>stuff like tcllib.

> Better than ActiveTcl <URL: http://wiki.tcl.tk/activetcl >?

I like how Python has done it.  You get Python, you get a bunch of stuff
that you are more or less guaranteed to have on any system.  It's part
of pretty much any Linux system out there these days.  As is Tcl, but
Tcl does not ship with its standard library by default.

> I'll be more explicit:  when people ask me about a "batteries-
> included Tcl", I urge them to install ActiveTcl (let's leave
> MacOS aside for the moment).  With rare exceptions, my inter-
> locutors express satisfaction.  I conclude that ActiveTcl is
> a correct answer to this question.  It happens to be a fact
> that ActiveTcl includes, among several other highlights, 
> tcllib.
> 
> How do you see it, David?

The Linux people won't ship ActiveTcl as 'The' Tcl, and neither will the
MacOS X folks.  That leaves a lot of people with a very plain system
when they perhaps get curious and try out this 'tclsh' thing.

Another can of worms is the fact that people who really get into a
system like Debian like to keep everything nice and tidy with Debian
packages.  This can lead to conflicts with other packaging systems like
Ruby gems and CPAN, let alone something that isn't, as a whole, "open
source" like ActiveTcl (*).

-- 
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

(*) ActiveTcl is free for commercial, and non commercial uses, but you
can't redistribute without permission from ActiveState.  While this is
entirely reasonable, it does preclude it from being included in open
source environments like Fedora and Debian.
0
davidw (997)
12/10/2005 2:31:21 PM
Does Apple just have a policy of not relying on a 3rd party? I can
understand the Linux folks. 

Robert

0
sigzero (1319)
12/10/2005 3:58:43 PM
> As is Tcl, but Tcl does not ship with its standard library by default.

Maybe that should change? Seems a shame not to.

Robert

0
sigzero (1319)
12/10/2005 4:03:51 PM
David N. Welton wrote:
> Cameron Laird wrote:
>
> >>>We shouldn't have to depend on Debian or RPM or whatever, to easily install
> >>>TCL packages.
> >>
> >>The best that we're likely to attain anytime in the near future is to
> >>have a 'batteries included' distribution that includes all kinds of
> >>stuff like tcllib.
>
> > Better than ActiveTcl <URL: http://wiki.tcl.tk/activetcl >?
>
> I like how Python has done it.  You get Python, you get a bunch of stuff
> that you are more or less guaranteed to have on any system.  It's part
> of pretty much any Linux system out there these days.  As is Tcl, but
> Tcl does not ship with its standard library by default.
>
> > I'll be more explicit:  when people ask me about a "batteries-
> > included Tcl", I urge them to install ActiveTcl (let's leave
> > MacOS aside for the moment).  With rare exceptions, my inter-
> > locutors express satisfaction.  I conclude that ActiveTcl is
> > a correct answer to this question.  It happens to be a fact
> > that ActiveTcl includes, among several other highlights,
> > tcllib.
> >
> > How do you see it, David?
>
> The Linux people won't ship ActiveTcl as 'The' Tcl, and neither will the
> MacOS X folks.  That leaves a lot of people with a very plain system
> when they perhaps get curious and try out this 'tclsh' thing.
>
> Another can of worms is the fact that people who really get into a
> system like Debian like to keep everything nice and tidy with Debian
> packages.  This can lead to conflicts with other packaging systems like
> Ruby gems and CPAN, let alone something that isn't, as a whole, "open
> source" like ActiveTcl (*).
>
> --
> David N. Welton
> - http://www.dedasys.com/davidw/
>
> Linux, Open Source Consulting
> - http://www.dedasys.com/
>
> (*) ActiveTcl is free for commercial, and non commercial uses, but you
> can't redistribute without permission from ActiveState.  While this is
> entirely reasonable, it does preclude it from being included in open
> source environments like Fedora and Debian.

Gentoo provides an ebuild dev-tcltk/tcllib
Debian seems to have a package tcllib (1.7-1)
http://packages.debian.org/testing/interpreters/tcllib

Educate - keep telling people what bundle of stuff they should grab as
an ordinary tcl install.

0
igouy (1009)
12/10/2005 4:04:38 PM
Maybe there should be a debian metapackage 'tcl-BI' that depends on
tcllib and all other extensions? I see this approach taken in ubuntu
(maybe directly from debian?) with respect to eg gstreamer, where there
is a metapackage 'gstreamer-plugins' that contains no code, but depends
on every gstreamer plugin in the repository.

I imagine that something similar is also available for RPM-based
distros.

0
12/10/2005 4:35:55 PM
David N. Welton wrote:

>Another can of worms is the fact that people who really get into a
>system like Debian like to keep everything nice and tidy with Debian
>packages.  This can lead to conflicts with other packaging systems like
>Ruby gems and CPAN, let alone something that isn't, as a whole, "open
>source" like ActiveTcl (*).

David -- how are things like CPAN handled on Debian?

I know Debian repackages a lot of stuff from CPAN as
native packages, so in a lot of cases foo.pm is available
with 'apt-get install libfoo-perl'; but what if you want
to use a CPAN package that's not availale in the apt repository?

Or in general, how do the free Unices manage a distro-supplied
core perl/python/tcl/ruby with a mix of distro-supplied and 
locally-installed extensions?


--Joe English
0
jenglish (354)
12/10/2005 4:59:30 PM
A few notes concerning Actiweb: the persistence layer of actiweb is
based on the idea of persistent objects; there are different storage
strategies such as lazy (write-back on destroys) or eager (write back
on every modification of a persistent instance variable) and there are
different storage backends (such as e.g. gdbm). I have not done
anything with ROR, but as it looks to me, ROR is a thin object layer on
top of relational structures. This is a different approach, and could
as well be done with xotcl.

actiweb can be quite fast, as long all objects can be placed in memory
and single-threading is sufficient, and no transaction concept is
required. Furthermore, actiweb follows the agent approach, where
distributed systems are seen as multi-agent systems, and where objects
can move to and from such places.

For enterprise applications, a strong relational integration has many
advantages (transaction, joins, partial instantiations). If somebody is
interested in such applications with xotcl, i would suggest to check
out the newest developents in openacs (tcl based framework for
enterprise collaboration  systems based on the aolserver). openacs is
based on an object model implemented on top of relational databases and
contains a large array of components like for authentication,
templating, messaging, filestore, blogging, payment, etc. Since there
is a big interest in the community a recent TIP requires for the next
release 5.3 xotcl in its installation. During the last weeks, i have
implemented e.g. an object layer on top of the oacs content repository
which is similar (but not yet as full-featured) to ROR (see e.g.
http://openacs.org/forums/message-view?message_id=346699). People
interested are certainly invited to participate.

0
neumann8225 (127)
12/10/2005 5:51:11 PM
Joe English wrote:
> David N. Welton wrote:
> 
> 
>>Another can of worms is the fact that people who really get into a
>>system like Debian like to keep everything nice and tidy with Debian
>>packages.  This can lead to conflicts with other packaging systems like
>>Ruby gems and CPAN, let alone something that isn't, as a whole, "open
>>source" like ActiveTcl (*).

> David -- how are things like CPAN handled on Debian?

Imperfectly:-)  Either you forget about the Debian packaging system and
just use CPAN, or you try and automate package building, transforming
Perl packages into something recognized by Debian:

http://lists.debian.org/debian-perl/2005/10/msg00030.html

> I know Debian repackages a lot of stuff from CPAN as
> native packages, so in a lot of cases foo.pm is available
> with 'apt-get install libfoo-perl'; but what if you want
> to use a CPAN package that's not availale in the apt repository?

> Or in general, how do the free Unices manage a distro-supplied
> core perl/python/tcl/ruby with a mix of distro-supplied and 
> locally-installed extensions?

It's an open issue, as far as I can tell.  Whie poking around for
informationon Ruby, I stumbled across quite a flame-war between Ruby
people arguing that their gems system was to be preferred, and some
Debian folks trying to explain that that's not how things work on Debian.

In any case, I think the Python system of just giving you a big standard
distribution is pretty good.  What it lacks in elegance, it more than
makes up for in simplicity and benefits for the end user who just wants
to take what's there and write code.

-- 
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/
0
davidw (997)
12/10/2005 10:59:08 PM
On 2005-12-08, Cameron Laird <claird@lairds.us> wrote:
> ... and that's not all.  Already fossilized are several earlier efforts
> to build public repositories, extending back, I think, even before CPAN
> was prominent:  ones hosted by NeoSoft, Alcatel (?), ...

<TRIPPING_DOWN_MEMORY_LANE>

I can confirm that the very first Tcl/Tk Contrib Archive predated CPAN by
at least four years (the official Perl Timeline[1] puts CPAN's inception
in late 1995).  I set up myself in mid-1991, using some spare HD space
on a Sun Sparcserver 4/90 that I was sysadmining on behalf of the ME
department at UC Berkeley (ironically, I never met Prof Ousterhout during
my four years there).

I ran it for over a year, soliciting contributions from folks and putting
them up for FTP in a organized hierarchy complete with short READMEs that
I wrote up to briefly describe each extension.  All in all, I didn't
spend more than about an hour a week doing this, but there weren't as
many extensions then as now.

Then I graduated in Spring 1992 and *fumbled* the handoff of the Archive
to my sysadmin successor (he apparently didn't have the same commitment
to Tcl that I did 8-).  When I resurfaced on the Net almost two years
later, someone at Neosoft (I forget who) had rescued the Archive, and
the rest is, well, history.

</TRIPPING_DOWN_MEMORY_LANE>

[1] http://history.perl.org/PerlTimeline.html
0
Adrian
12/11/2005 5:31:27 PM
David N. Welton wrote:
> Cameron Laird wrote:
>> I'll be more explicit:  when people ask me about a "batteries-
>> included Tcl", I urge them to install ActiveTcl (let's leave
>> MacOS aside for the moment).  With rare exceptions, my inter-
>> locutors express satisfaction.  I conclude that ActiveTcl is
>> a correct answer to this question.  It happens to be a fact
>> that ActiveTcl includes, among several other highlights, 
>> tcllib.

> The Linux people won't ship ActiveTcl as 'The' Tcl, and neither will the
> MacOS X folks.  That leaves a lot of people with a very plain system
> when they perhaps get curious and try out this 'tclsh' thing.

OS X ships with a ton more Tcl extensions by default than even the
best supported Linux distro for Tcl packages (SuSE).  What does
that say about the communities around each?  ActiveTcl's best
advantage on OS X is being up-to-date, as you want the latest
version (OS X is a platform where Tk is constantly improving).

-- 
   Jeff Hobbs, The Tcl Guy
   http://www.ActiveState.com/, a division of Sophos
0
jeffh (1291)
12/11/2005 6:08:35 PM
miguel sofer wrote:
> Maybe there should be a debian metapackage 'tcl-BI' that depends on
> tcllib and all other extensions? I see this approach taken in ubuntu
> (maybe directly from debian?) with respect to eg gstreamer, where there
> is a metapackage 'gstreamer-plugins' that contains no code, but depends
> on every gstreamer plugin in the repository.

That's a good idea, and we could lean on the metapackage maintainer to
include what we think is a good idea for BI as a minimum.

Donal.
0
12/12/2005 4:16:54 PM
Jeff Hobbs wrote:

> OS X ships with a ton more Tcl extensions by default than even the
> best supported Linux distro for Tcl packages (SuSE).  What does
> that say about the communities around each?  ActiveTcl's best
> advantage on OS X is being up-to-date, as you want the latest
> version (OS X is a platform where Tk is constantly improving).

Now I'm curious:-) Which ones do MacOS X and Suse have?

In any case, the important thing is to provide Tcl's users (both current
and potential!) with a stable, widely available platform.  It would be
better not to leave its composition to the vagaries of fate.

-- 
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/
0
davidw (997)
12/12/2005 10:14:28 PM
David N. Welton wrote:
> Jeff Hobbs wrote:
> 
> 
>>OS X ships with a ton more Tcl extensions by default than even the
>>best supported Linux distro for Tcl packages (SuSE).  What does
>>that say about the communities around each?  ActiveTcl's best
>>advantage on OS X is being up-to-date, as you want the latest
>>version (OS X is a platform where Tk is constantly improving).
> 
> 
> Now I'm curious:-) Which ones do MacOS X and Suse have?
well i don't know about MacOS but
SUSE(9.2):
some gtk stuff deleted.
~ # rpm -q -a | egrep 'tcl|deja|expect|blt|tk'
tkimg-1.3-27
tkdiff-4.02-3
tcl-devel-8.4.9-7
dejagnu-1.4.4-4
blt-2.4z-205
tcl-8.4.9-7
expect-5.41-3
vtcl-1.6.0-43
itcl-3.3-421
tclx-8.4-331
tcllib-1.7-3
tk-8.4.9-9
spectcl-1.1-804
tclplug-3.0-242
tktable-2.8-165
tk-devel-8.4.9-9
tkcon-2.4-
snack-2.2.9-4

and some more stuff i did not think of at the moment.

and the rpm's that depend on tcl:
       1 cecilia-2.0.5-126
       1 dejagnu-1.4.4-4
       1 ding-1.3-42
       1 dirdiff-1.6-312
       1 scotty-2.1.11-617
       1 snack-2.2.9-4
       1 tcl-devel-8.4.9-7
       1 tclplug-3.0-242
       1 tk-8.4.9-9
       1 tk-devel-8.4.9-9
       1 tkeca-4.0.2-47
       1 vtcl-1.6.0-43

( got with
for pack in $( rpm -q -a ) ; do
	if rpm -q -R $pack | grep ^tcl >/dev/null 2>&1 ; then
		echo $pack
	fi
done | sort | uniq -c
not shure if there are any false positives or negatives)

uwe

> 
> In any case, the important thing is to provide Tcl's users (both current
> and potential!) with a stable, widely available platform.  It would be
> better not to leave its composition to the vagaries of fate.
> 
extension management that bypasses the native package manager
are IMHO problematic.

0
12/12/2005 11:07:04 PM
This is what comes with Tiger: http://tcltkaqua.sourceforge.net/tiger

I personally put ActiveTcl on there.

Robert

0
sigzero (1319)
12/12/2005 11:37:37 PM
Of that list, everything down to and including XOTcl (the ones below
are not relevant outside the Mac platform) is probably a reasonable
thing to include in anyone's BI configuration, together with Tile and
TkHtml if at all possible.

It's probably a good idea at this stage to include TclUDP or CepTcl for
UDP support.

Donal.

0
12/13/2005 11:22:49 AM

Adrian, I want to thank you for your contributions back in the dino age when
you started that first archive. Your time and efforts were appreciated!

-- 
<URL: http://wiki.tcl.tk/ > Indescribable,uncontainable,all powerful,untameable
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvirden@gmail.com > <URL: http://www.purl.org/NET/lvirden/ >
0
lvirden (1938)
12/13/2005 1:18:14 PM
Uwe Klein wrote:

> well i don't know about MacOS but
> SUSE(9.2):
> some gtk stuff deleted.
> ~ # rpm -q -a | egrep 'tcl|deja|expect|blt|tk'
> tkimg-1.3-27
> tkdiff-4.02-3
> tcl-devel-8.4.9-7
> dejagnu-1.4.4-4
> blt-2.4z-205
> tcl-8.4.9-7
> expect-5.41-3
> vtcl-1.6.0-43
> itcl-3.3-421
> tclx-8.4-331
> tcllib-1.7-3
> tk-8.4.9-9
> spectcl-1.1-804
> tclplug-3.0-242
> tktable-2.8-165
> tk-devel-8.4.9-9
> tkcon-2.4-
> snack-2.2.9-4

Debian/Ubuntu has, in no particular order:

Package: gdtclft
Package: itcl3.1

Package: libdb4.3-tcl
Package: libmetakit-tcl
Package: libpgtcl1.5

Package: libsqlite3-tcl
Package: mysqltcl
Package: newt-tcl
Package: plplot-tcl
Package: postgresql-pltcl-8.0
Package: ppxp-tcltk
Package: rrdtool-tcl
Package: tcl8.3
Package: tcl8.3-dev
Package: tcl8.3-doc
Package: tcl8.4
Package: tcl8.4-dev
Package: tcl8.4-doc
Package: tclcurlPackage: tktable

Package: libtk-img

Package: blt
Package: blt-demo
Package: blt-dev


Package: tcldom
Package: tclex
Package: tclexpat
Package: tcllib
Package: tclmagick
Package: tclparser
Package: tclreadline
Package: tclsoap
Package: tclthread
Package: tcltls
Package: tclvfs
Package: tclx8.4
Package: tclx8.4-dev
Package: tclx8.4-doc
Package: tclxml
Package: vim-tcl
Package: visual-tcl
Package: vtk-tcl
Package: wzdftpd-mod-tcl

Package: tk8.3
Package: tk8.3-dev
Package: tk8.3-doc
Package: tk8.4
Package: tk8.4-dev
Package: tk8.4-doc
Package: tkcon

a slew of tk* applications

Package: tktable
Package: tkx8.3
Package: tkx8.3-dev
Package: tkx8.3-doc
Package: itk3.1
Package: itk3.1-dev
Package: itk3.1-doc

Package: libsnack2
Package: libsnack2-dev
Package: libsnack2-doc
Package: tix8.1
Package: tix8.1-dev

and of course expect and dejagnu.  I'm probably missing a few, too.

Not bad!
-- 
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/
0
davidw (997)
12/14/2005 10:27:11 PM
Reply:

Similar Artilces:

tcl-pam: PAM authentication for Tcl (Tcl package)
This is an announcement for a relatively new Tcl project: tcl-pam Tcl-pam is a Tcl interface to the PAM* service of Linux. It provides a Tcl package that allows Tcl scripts to use PAM to authenticate users and programs. It relies on linux-pam library: http://www.kernel.org/pub/linux/libs/pam/ * PAM (Pluggable Authentication Modules): A mechanism to integrate multiple low−level authentication schemes into a high−level application programming interface (API). This enables programs that rely on authentication to be written independently of the underlying authentication scheme. Platform: Linux Home page: http://sourceforge.net/projects/tcl-pam/ Man page: http://tcl-pam.sourceforge.net/ Author: Alexandros Stergiakis alsterg ...

tcl-gaul: Genetic Algorithms for Tcl. (Tcl package)
This is an announcement for a relatively new Tcl project: tcl-gaul Tcl-gaul is a Tcl extension for genetic/evolutionary algorithm processing.It relies on the GAUL library: http://gaul.sourceforge.net/ * A genetic algorithm (GA) is a search technique used in computing to find exact or approximate solutions to optimization and search problems. Genetic algorithms are categorized as global search heuristics. They are a particular class of evolutionary algorithms that use techniques inspired by evolutionary biology such as inheritance, mutation, selection, and crossover. For an introduction to genetic algorithms visit: http://gaul.sourceforge.net/intro.html Platform: Linux (GAUL library dependency) Home page: http://sourceforge.net/projects/tcl-gaul/ Man page: http://tcl-gaul.sourceforge.net/ Author: Alexandros Stergiakis alsterg ...

tcl-mq: POSIX Message Queues for Tcl. (Tcl package)
This is an announcement for a relatively new Tcl project: tcl-mp Tcl-mp is a Tcl interface to POSIX Message Queues*. It provides a Tcl package that allows scripts to create/open/close/unlink multiple parallel message queues, and to send/receive messages synchronously and asynchronously to/from them. * A POSIX message queue is an Inter-Process Communication mechanism available on Linux and some other POSIX-compliant operating systems. It allows to or more processes (or threads) to communicate under the same OS. The messages are buffered by the kernel, which gives them kernel persistency. A message queue can be thought of as a linked list of messages. Threads with adequate permission can put messages onto the queue, and threads with adequuate permission can remove messages from the queue. Each message is assigned a priority by the sender, and the oldest message of highest priority is always retrieved first. Unlike PIPES and FIFOS, no requirement exists that someone be waiting for a message to arrive on a queue, before some process writes a message to that queue. It's not even a requirement for both processes to exist at the same time. Read mq_overview(7) for more details Platform: Linux Home page: http://sourceforge.net/projects/tcl-mp/ Man page: http://tcl-mp.sourceforge.net/ Author: Alexandros Stergiakis alsterg On Sep 3, 11:37=A0am, Alexandros Stergiakis <alst...@gmail.com> wrote: > This is an announcement for a relatively new Tcl pro...

tcl-syslog: Unix system logging for Tcl (Tcl package)
This is an announcement for a relatively new Tcl project: tcl-syslog Tcl-syslog is a Tcl interface to the *nix syslog service. It provides a Tcl package that allows Tcl scripts to log messages to syslog. Platform: Linux/Unix Home page: http://sourceforge.net/projects/tcl-syslog/ Man page: http://tcl-syslog.sourceforge.net/ Author: Alexandros Stergiakis alsterg ...

tcl-mmap: A POSIX mmap interface for Tcl. (Tcl package)
This is an announcement for a relatively new Tcl project: tcl-mmap Tcl-mmap is a Tcl interface to the POSIX mmap* system call. It provides a Tcl package that allows Tcl scripts to: 1) Memory map files for improved access efficiency; 2) Share memory between related processes; 3) Easily implement cyclic persistent log files. * See the mmap(2) man page. Platform: Linux/Unix Home page: http://sourceforge.net/projects/tcl-mmap/ Man page: http://tcl-mmap.sourceforge.net/ Author: Alexandros Stergiakis On Sep 3, 11:48=A0am, Alexandros Stergiakis <alst...@gmail.com> wrote: > This is an announcement for a relatively new Tcl project: tcl-mmap > > Tcl-mmap is a Tcl interface to the POSIX mmap* system call. It provides > a Tcl package that allows Tcl scripts to: 1) Memory map files for > improved access efficiency; 2) Share memory between related processes; > 3) Easily implement cyclic persistent log files. > > * See the mmap(2) man page. > Great to see this and the other packages you made. Looking at the manpage it looks a bit misformatted before the usage example. Any specific reason to use GPL for this instead the usual Tcl/MIT/BSD style license used? Michael schlenk wrote: > On Sep 3, 11:48 am, Alexandros Stergiakis <alst...@gmail.com> wrote: >> This is an announcement for a relatively new Tcl project: tcl-mmap >> >> Tcl-mmap is a Tcl interface to the POSIX mmap* system call. It provides >> a Tcl package that...

tcl-snmptools: SNMP v1/v2/v3 operations for Tcl. (Tcl package)
This is an announcement for a relatively new Tcl project: tcl-snmptools Tcl-snmptools is a Tcl interface to the Net-SNMP library which provides operations for the management of remote SNMP agents. It supports all the standard SNMP v1/v2/v3 operations: connect, close, get, set, getnext, walk, bulkget, bulkwalk, trap, translate and others. It is currently in a functional state, but more work and testing needs to be done. Home page: http://sourceforge.net/projects/tcl-snmptols/ Man page: http://tcl-snmptols.sourceforge.net/ Author: Alexandros Stergiakis alsterg ...

Opening a TCL program from within another TCL program in ANSYS Tcl-Tk
Hi everyone, I have been pulling my hair with this one for a couple of days and still have not found a fix. I'm working within ANSYS Tcl-Tk implementation. I created a Tcl-Tk script that generates a simple window with three buttons. Each button opens another window which is created in a separate Tcl file. The second window have a lot of text entries, variables, procedures, etc. I can open the second Tcl file by itself and everything works as supposed, but when I open it using the button in the first window, it opens but any procedure called by the widgets on the second window are not found... Here's the deal... Since I'm working within the ANSYS implementation of Tcl-Tk, I'm actually using an ANSYS command to open the second window. The command I use is: ### ans_sendcommand ~eui,'source O:/mad_projects_2/ANSYS/Macros/ IBR_CAS.tcl' ### It actually sends a command back to ANSYS telling it to execute a Tcl command... I know this is not pretty but its the only way i was able to make it at least show the window. ############################## #Main Tcl (excerpt): ############################## namespace eval Tools { proc IBRCambpell {} { #source O:/mad_projects_2/ANSYS/Macros/IBR_CAS.tcl ans_sendcommand ~eui,'source O:/mad_projects_2/ANSYS/Macros/ IBR_CAS.tcl' } proc viewManager {} { ans_sendcommand ~eui,'source O:/mad_projects_2/ANSYS/Macros/ ViewManager.tcl' } proc powerAnnotation {} { ans_sendcommand ~eui,'source ...

tcl application with tcl application
Here is another question, I have one tcl-based application A, my co- worker has a tcl-based application B. Now I want to integrate my application A into the application B. After integration, I want to be able to run A's tcl command in B. Assume I can only change A's code, is there any way to do this? On 17 Dez., 07:03, teacupfull business <teacupfull.busin...@gmail.com> wrote: > Here is another question, I have one tcl-based application A, my co- > worker has a tcl-based application B. Now I want to integrate my > application A into the application B. >...

How to compile tcl or encrypt tcl
I use TclPro1.5 to compile my tcl script with tixwish in the Solaris before. But I cannot use the same method in Linux. Why? Is there any utility for me to compile or encrypt the code by using tixwish? The following is the simple code if I use the tixwish: #!/home/albertl/local/bin/tixwish puts "haha" And after using procomp by the TclPro1.5 Error in startup script: The TclPro ByteCode Loader is not available or does not support the correct version while executing "error "The TclPro ByteCode Loader is not available or does not support the correct version"" invoked from within "if {[catch {package require tbcload 1.3} err] == 1} { error "The TclPro ByteCode Loader is not available or does not support the correct version" ...." (file "a.tbc" line 4) The problem seems that tbcload1.3 cannot be found? But tbcload is already there "/home/albertl/local/lib/tbcload1.3" Why? Can anyone tell me? stratus schrieb: > I use TclPro1.5 to compile my tcl script with tixwish in the Solaris before. > But I cannot use the same method in Linux. Why? > > Is there any utility for me to compile or encrypt the code by using tixwish? > Tixwish is just a wish shell with the Tix package baked in. If TclPro does not have a specific bigwish with Tix included your out of luck on that road (but could build your own if you liked). You might have success with freewrap or TDK, don't know for su...

How Tcl speaks for itself and how Tcl is not spoken for...
Hello It's Friday and... well... Two things about Tcl going through my mind this week, a nice anecdote and a eyebrow-rising thing on Wikipedia: Anecdote: Until three months ago I worked in a scientific institue where I wrote much software in Tcl, especially a big Build and Report System, some tools for automatic checking of coding style and other things. Tcl had a bad reputation there (not because of me... they dropped Tcl before I started there in favour of Joy, then JavaScript and now Python) and besides me, there was only one co-worker who appearantly writes some small Tcl-Scripts to support other researchers in their work. To get completely rid of Tcl, they even started to reimplement all things, I wrote in Tcl in Python just to have it in a language, that most of them know (which is a good decision on the one hand, but on the other hand, I think, it would be better to simply learn Tcl ;-), which made me a little bit sad. Now there is a new collegue who has to maintain some of the things I wrote. Comming from Perl he wasn't exactly enthusiastic when he heard, that he must maintain my old code in such an obscure language.. Two weeks ago, I got mail from him. He's just studying a complex system of scripts that are used for a sandboxed build system for source code which comes from external untrusted source and must be compiled and tested. Of course it's written in Tcl (and some bash-Scripting). He told me, that although he has never looked at Tcl before,...

Extending TCL in C with tcl.h - Disabliing [<tcl-cmd>] feature
Hi, TCL has a command execution syntax like this: [<tcl cmd>] Anything inside the 3rd bracket will be executed as a Tcl command by the Tcl interprater. Is there any way I can disable/delete this Tcl construct [ <tcl-cmd>]? In other words, my Tcl interprator should print "[32]" for tcl command puts "[32]" It should not try to treat [] as a special character. Is this any way possible while extending Tcl in C with tcl.h? Thank you, Arijit * arijit79@gmail.com | puts "[32]" | | It should not try to treat [] as a special character. Check out the TCL quoting rules. http://www.tcl.tk/man/tcl8.4/TclCmd/Tcl.htm http://www.tcl.tk/man/tcl8.4/TclCmd/Tcl.htm#M10 http://www.tcl.tk/man/tcl8.4/TclCmd/Tcl.htm#M15 Any of puts {[32]} puts "\[32\]" will do the trick. R' On May 8, 3:14 am, ariji...@gmail.com wrote: > Is there any way I can disable/delete this Tcl construct [ <tcl-cmd>]? By doing this, you would disable the primary functionality of Tcl. I'm certain you could go into the tcl source and stop it - but why not talk about what you are really trying to do. Perhaps someone can give you a better way of doing what you are wanting to do. ...

Tcl
Hello, where can I see for tcl syntacs and how-to run a tcl test? Thank You Vittore ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request@ptolemy.eecs.berkeley.edu ...

Tcl
Hello all. I found on hobbes the afaik latest Tcl for Os/2 v8.35 Is there any newer port, cause i try to update the eggdrop and that says: Your Tcl version is much too old for Eggdrop to use. You should download and compile a more recent version. The most reliable current version is 8.5.X and can be downloaded from ftp://tcl.activestate.com/pub/tcl/tcl8_5/. -- With the best regards from the Netherlands, Tu, "Tellerbop" <Tellerbop@wint.nl>, hai scritto questo in data Wed, 14 Jan 2009 19:11:18 UTC: > Hello all. > > I found on hobbes the afaik latest Tcl for Os/2...

TCL
Hello, i would like to build TCL/TK as a separate DLL-Library. Can anyone tell me how this can be done with VC 6.0? Best regards, Reinhold "Reinhold.kwauka" <bernd-reinhold.kwauka@t-online.de> wrote: >Hello, > >i would like to build TCL/TK as a separate DLL-Library. Can anyone tell me >how this can be done >with VC 6.0? > >Best regards, >Reinhold > 1) get the source from http://tcl.sourceforge.net/ 2) open a command prompt 3) cd to the win/ subdirectory 4) call vcvars32.bat located in ??\vc98\bin\ of vc6 for wherever you installed it. 5) type @ the prompt: nmake -f makefile.vc -- David Gravereaux <davygrvy@pobox.com> [species: human; planet: earth,milkyway(western spiral arm),alpha sector] Reinhold.kwauka wrote: > Hello, > > i would like to build TCL/TK as a separate DLL-Library. Can anyone tell me > how this can be done > with VC 6.0? > > Best regards, > Reinhold > > Its already done. Just download a binary release for windows and check \Program Files\Tcl\lib for the DLLs and static libraries. ...

Tcl extension: check Tcl version?
Is there a recommended way to check if a (binary) Tcl extension is loaded to the same Tcl version that was used for linking the extension? Currently I'm encountering a problem with an extension that I have built (and linked) with libtk8.3.so and that can be loaded under wish8.5 as well (without re-bulding, using package require). A number of newly provided commands work well in spite of the version mixture, but others don't, and wish8.5 crashes when these commands are used. Is this behavior normal, i.e. should I check that compile-time version and run-time version are identical? Or does this indicate some subtle coding problem? Thanks for any suggestions Olaf Olaf Dietrich wrote: > Is there a recommended way to check if a (binary) Tcl extension > is loaded to the same Tcl version that was used for linking > the extension? > > Currently I'm encountering a problem with an extension that > I have built (and linked) with libtk8.3.so and that can be > loaded under wish8.5 as well (without re-bulding, using > package require). A number of newly provided commands work > well in spite of the version mixture, but others don't, and > wish8.5 crashes when these commands are used. > > Is this behavior normal, i.e. should I check that compile-time > version and run-time version are identical? Or does this > indicate some subtle coding problem? Not subtle. Major problem. DO NOT DO THAT. If you want to be loadable across mult...

MS Dictation and TCL
I'm trying to use the MS dictation tool while in TCL 8.5 program. The text starts to appear, but then the program crashes. It would be great to find a way to make this work. Thanks! Barney Tcl 8.5 (wish 8.5) makeindex (12/14/2007) MSWinXP sp3 plenty of ram and storage ...

Tcl command to evaluate a tcl script?
Hi all, I need to evaluate a separate tcl file within a tcl file. Is there any tcl command to evaluate a tcl file ? Regards, Prabu.K prabu wrote: > Hi all, > > I need to evaluate a separate tcl file within a tcl file. Is there any > tcl command to evaluate a tcl file ? > > Regards, > Prabu.K > hi, try: source your_other_tcl_file.tcl cheers, Tobi ...

[TCL] diff type operations in TCL
I didn't see anything in tcllib and thus far haven't turned up anything that looks like it will work. I would like to know if there is a TCL package, or already written procedure, that will do a simple diff of two files and tell me if they're the same or if they have differences. Is there anything like this? --------------------------------------------- Andrew R. Falanga (a non-HP employee) Hewlett-Packard Company 11311 Chinden Blvd. Boise, Idaho --------------------------------------------- Please note: The e-mail address is purposely mangled. I do not wish my account at HP to become a spam haven. Andrew Falanga wrote: > I didn't see anything in tcllib and thus far haven't turned up anything > that looks like it will work. I would like to know if there is a TCL > package, or already written procedure, that will do a simple diff of two > files and tell me if they're the same or if they have differences. > > Is there anything like this? If all you want to know is if they are different, then: set fd [open $file1 r] set f1 [read $fd] close $fd set fd [open $file2 r] set f2 [read $fd] close $fd if {[string equal $f1 $f2]} then { puts "'$file1' and '$file2' are the same." } else { puts "'$file1' and '$file2' are different." } -- +--------------------------------+---------------------------------------+ | Gerald W. Lester ...

Inline::Tcl vs. Inline::Tcl
The readme for CPAN's Inline::Tcl says this: > This module is not related to the Inline::Tcl module, but it might be > valuable to have some compatibility between the two. > This sentence seems to suggest that there is another module named Inline::Tcl somewhere. Is this true, and if so, where can I find it? Mumia W. wrote: > The readme for CPAN's Inline::Tcl says this: > > > This module is not related to the Inline::Tcl module, but it might be > > valuable to have some compatibility between the two. > > > > This sentence seems to suggest ...

[TCL] multi-threaded tcl apps
Hi, Where can one find complete documentation on the ttrace package to the Thread package? I'd like to know what commands are available in ttrace and how to use them. --------------------------------------------- Andrew R. Falanga (a non-HP employee) Hewlett-Packard Company 11311 Chinden Blvd. Boise, Idaho --------------------------------------------- Please note: The e-mail address is purposely mangled. I do not wish my account at HP to become a spam haven. If you wish to e-mail me, the address consists of a dot between my first and last names (excluding my middle initial). The rest is accurate. Also, note, responses must be within the given context of messages I've posted to usenet. If it's not, I WILL NOT RESPOND! ...

Debugger for Tcl/Tk and [incr Tcl]
hi, where can i get Coverage for debugging tcl/tk, [incr Tcl] source? this tool is advised to use in 'Practical Programming in Tcl and Tk' or any other good debugger, which i could use? best, s. On Jan 23, 5:56=A0am, Sitaca <sit...@gmail.com> wrote: > hi, > > where can i get Coverage for debugging tcl/tk, [incr Tcl] source? > this tool is advised to use in 'Practical Programming in Tcl and Tk' > > or any other good debugger, which i could use? I see, at http://wiki.tcl.tk/8638 , a brief reference to the topic of coverage for tcl. I don't know whether or not any of the tools mentioned include coverage of itcl. On 23 jan, 12:52, "Larry W. Virden" <lvir...@gmail.com> wrote: > On Jan 23, 5:56=A0am, Sitaca <sit...@gmail.com> wrote: > > > hi, > > > where can i get Coverage for debugging tcl/tk, [incr Tcl] source? > > this tool is advised to use in 'Practical Programming in Tcl and Tk' > > > or any other good debugger, which i could use? > > I see, athttp://wiki.tcl.tk/8638, a brief reference to the topic of > coverage for tcl. I don't know whether or not any of the tools > mentioned include coverage of itcl. I have a more complete version of the coverage tool mentioned on that page. I just never got around to publishing it more widely. As for debuggers: the Wiki has a lot of pointers on that subject as well. Regards, Arjen Larry W. Virden wrote:...

dynamic call of tcl proc from tcl
Hello, I would like to invoce a tcl proc from a line of tcl where I have a proc name and a list variable of arguments. eg. % callproc $procName $argList where: ..callproc - TCL Procedure for dynamically calling procedures ..procName - Name of procedure to be called in a string ..argList - List of Arguments My goal is to avoid creating a procedure call as a string and evaluating it as there are many potential pitfalls with using evals in such a way. Thanks, JsD Java script Dude wrote: > I would like to invoce a tcl proc from a line of tcl where I have a > proc name and a list variable of arguments. > > eg. % callproc $procName $argList > > where: > .callproc - TCL Procedure for dynamically calling procedures > .procName - Name of procedure to be called in a string > .argList - List of Arguments Except for error/exception handling, the answer is: proc callproc {cmd argList} { uplevel 1 [linsert $argList 0 $cmd] } -- | Don Porter Mathematical and Computational Sciences Division | | donald.porter@nist.gov Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| [; Thanks Don ;] ...

How Tcl source finds init.tcl???
Hi, I have one question about how Tcl finds init.tcl. What environment variable does Tcl source use to get the search path for init.tcl? Is there any way to specifically use init.tcl from a certain path? Thanks a lot in advance! Lihong lihong pei wrote: > I have one question about how Tcl finds init.tcl. > What environment variable does Tcl source use to get the search path for > init.tcl? If the environment variable TCL_LIBRARY exists, it's value is assumed to be a single directory which is added to the search path for init.tcl. Note that this is offered mostly as a way for the end-user to work around broken installations. In any sane installation, you should not need to use this environment variable, and its use should be avoided. > Is there any way to specifically use init.tcl from a certain path? There are a few ways. The most suitable to choose depends on how you are using Tcl. Are you writing a C program that links to the Tcl library? -- | Don Porter Mathematical and Computational Sciences Division | | donald.porter@nist.gov Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| lihong pei <lihong.pei@xilinx.com> wrote: >Hi, >I have one question about how Tcl finds init.tcl. >What environment variable does Tcl source use to get the search path for >init.tcl? >Is there any ...

Tcl only
I am curious about how many people just use Tcl for a systems language (instead of say, BASH) but don't use Tk. On Thursday, July 12, 2012 6:22:45 AM UTC-7, Robert wrote: > I am curious about how many people just use Tcl for a systems language (i= nstead of say, BASH) but don&#39;t use Tk. For me, if the script is mainly concerned with invoking other programs and = little else, then I'll grit my teeth and do it in bash because it handles s= uch things well even if the syntax is vintage Algol. Otherwise, it is hard = to get me to program in anything other than Tcl when the target is a conven= tional computing environment. Andrew Mangogna On Thursday, July 12, 2012 9:22:45 AM UTC-4, Robert wrote: > I am curious about how many people just use Tcl for a systems language (instead of say, BASH) but don&#39;t use Tk. I use tcl, bash, perl, awk. I hardly ever have GUI frontends. Στις 12/7/2012 16:22, ο/η Robert έγραψε: > I am curious about how many people just use Tcl for a systems language (instead of say, BASH) but don't use Tk. > I use tcl in almost all my scripts. I rarely use bash, and only for basic stuff (i.e. run a few tcl scripts in order). George On 7/12/12 8:22 AM, Robert wrote: > I am curious about how many people just use Tcl for a systems language (instead of say, BASH) but don't use Tk. While not exactly what you asked, I use Tcl to create Web Services -- that does not involve any GUIs (a...

Possible bug in Tcl or Windows or Tcl on Windows
Hi, There seems to be a bug in the way numbers are compared in Tcl. Consider the below script for calculating Pythagorean triplets. For hypotenuse upto a value of 100, there should have been 63 unique triplets. On Windows XP the script detects only 62. The script doesn't detect the case where c=99, b=20 ==> a=101. However running the same script under Tcl 8.4.1 in Cygwin detects 63 triplets. I don't have a Linux machine at hand to test it there. Following is the script and relevant output. Could anyone shed some light on the cause of this. Maybe it has something to do with how the numbers are represented internally? Running the script for N>100 shows up many more such missed values. An equivalent program in C runs correctly on the same machine. C code was compiled using both gcc and VC++6.0. ######################################################################### # a^2 = b^2 + c^2 proc pythag {MAX} { set i 0 for {set c 2} {$c <= $MAX} {incr c} { for {set b 1} {$b < $c} {incr b} { set a [expr hypot($c, $b)] ;# Calc. Hypot if { ($c == 99) && ($b == 20)} { ;# <<<<<<<< puts ">> [expr round($a)] == $a" } if {[expr round($a)] == $a} { puts "$a : $b : $c" incr i } } } return $i } if {$argc == 1} { set MAX [lindex $argv 0] } else { puts stderr "Usage: tclsh $argv0 N" exit } puts [pythag $MAX] ############# OUTPUT ################ Tcl 8.4.1 (Cygwi...

Web resources about - Why TCL? - comp.lang.tcl

Tcl - Wikipedia, the free encyclopedia
This article is missing information about Tcl procedures, procedure calls, and conditional statements . Please expand the article to include ...

Kyocera TCL Solar Inaugurates Floating Mega Solar Power Plants in Hyogo Prefecture, Japan - YouTube
Kyocera Corporation and Century Tokyo Leasing Corporation announced today that Kyocera TCL Solar LLC, a joint venture established by the two ...

Hands on: Ultra HD TCL 65-inch television
Is it worth paying for extra pixels when you can't put them to good use?

Hands on: Ultra HD TCL 65-inch television
Is it worth paying for extra pixels when you can't put them to good use?

Iron Man Joins TCL To Challenge Apple iPhone: China, Chinese Market
To take on Apple and Samsung in the global smartphone market, China's TCL is enlisting a strong ally: Iron Man.

正反之间心随由你 TCL idol3真机图赏
... 注册 首页 - 资讯中心 评测 导购 行情 - 手机大全 品牌 排行 - 应用之家 主题 壁纸 铃声 - 美人心机 唯丽是图 专题汇总 - 论坛 求助 活动 图赏频道 搜索 图赏首页 手机图赏 平板图赏 美人心机 手机之家 > 资讯中心 > 图赏频道 > 正反之间心随由你 TCL ...

Rumors State That TCL Could Be Looking To Buy Or Invest In HTC
You might not have heard of TCL. They’re the twenty fifth largest electronics manufacturer in the world, the third largest television manufacturer, ...

TCL Communications, SunPartner Testing Technology That Could Draw Solar Power Via A Smartphone's Screen ...
Smartphones are awesome, but with a few notable exceptions, it seems their awesomeness is inversely correlated with their battery life. The more ...

1070:Hong Kong Stock Quote - TCL Multimedia Technology Holdings Ltd - Bloomberg
Stock analysis for TCL Multimedia Technology Holdings Ltd (1070:Hong Kong) including stock price, stock chart, company news, key statistics, ...

Cisco, TCL joint venture to focus on cloud in China
Cisco, TCL joint venture to focus on cloud in China Business Cloud News Networking incumbent Cisco is to set up a joint venture company with ...

Resources last updated: 3/13/2016 4:50:40 PM