Tcl - Is there a need for another distribution?

Author

Is there a need for another distribution?

George Peter Staplin

2007-12-23, 4:32 am

Given what some people have said about ActiveTcl recently I wonder --

Is there a need for another distribution, perhaps maintained by the
community?

Most of ActiveTcl is based on freely available software.

ActiveTcl developers know more than most Linux distributors about which
sources to use, for instance some of the Tcl-based projects on
sourceforge get some regular bug/build fixes in the cvs HEAD, but no
releases, except from ActiveState.

So, Ubuntu/Debian/Redhat and other distributors lag behind in some cases
because they either A) refuse to use the cvs HEAD B) don't know to use
the cvs HEAD rather than the releases of some packages.

Look at the Img home page for a good example of that. Another is Incr
Tcl... This gives the impression that Tcl is dying, but it's good for
ActiveTcl, because those in the know just say "use ActiveTcl."

You have no idea how frustrating that last comment is when you're using
an unsupported system like OpenBSD or NetBSD, or simply want to make
sure that the Cool Aid is safe by mixing it yourself.

We now also have a popular proprietary software distribution mechanism
in ActiveTcl that only supports TEA packages. That means the hard work
of people like myself isn't included, and many others that don't use
TEA. And I can't use it anyway on a non-ActiveTcl supported system.

Also, what happens if ActiveState pulls a Scriptics/Ajuba/Interwoven on
the community? Do you really want to be stuck telling your boss that
there are no alternatives, other than to dump Tcl and move to
Java/Python/Ruby/Perl?

George

Michael Schlenker

2007-12-23, 4:32 am

George Peter Staplin schrieb:

Hi George,
> Is there a need for another distribution, perhaps maintained by the
> community?
sorry to say that, i would think the answer is: NO

There is some benefit in diversity and having both Tclkit, evolanes
etcl, ActiveTcl, the various OS distros and some other more special
cased versions is nice, but not strictly needed.
>
> Most of ActiveTcl is based on freely available software.
>
> ActiveTcl developers know more than most Linux distributors about which
> sources to use, for instance some of the Tcl-based projects on
> sourceforge get some regular bug/build fixes in the cvs HEAD, but no
> releases, except from ActiveState.
Your wrong on that point. There is at least etcl and afaik some other
minor distributions around. IIRC from the chat even bitkeeper was
thinking about building their own distro. Not all have the same set of
extensions, and getting an agreement on whats essential puts you back
into the Batteries Included discussion.

What would be nice was a buildbot style system to get nightly builds and
test runs like many other projects do them.
>
> So, Ubuntu/Debian/Redhat and other distributors lag behind in some cases
> because they either A) refuse to use the cvs HEAD B) don't know to use
> the cvs HEAD rather than the releases of some packages.
Are unable to communicate with others in some cases...
Basically its a given that they don't use CVS head, which wouldn't be a
problem if they did for Tcl what some distributions do for many of their
other packages, port fixes from CVS into the distro.
>
> Look at the Img home page for a good example of that. Another is Incr
> Tcl... This gives the impression that Tcl is dying, but it's good for
> ActiveTcl, because those in the know just say "use ActiveTcl."
IncrTcl is an example of a totally messy web presence, no clear
communication on the state of affairs and a lot of outdated file releases.
So if i didn't knew better from the chat and the wiki i would assume its
dead and abandoned. (closer look at CVS activity shows thats not
entirely true, but cursory look tells you its dead).
Img is not much better in its communication.
So if you had the choice as a maintainer to hunt info about arcane Tcl
packages or fix your other more active sources (e.g. the OS X maintainer
at apple has to deal with Tcl/Tk and all of X11, so he didn't have
enough time to include the nearly complete patch for a more modern Tcl
in leopard that was sent to him.)

So to get up to date Tcl packages into your distribution of choice (be
it some kind of BSD, OpenSolaris, OS X, or whatever else) it takes work.
Work that someone has to do. The maintainers will probably not do it,
because they are busy and don't care for your particular OS because they
either have no benefit or just don't know anyone who uses it on that
platform. A new core binary distribution wouldn't fix much in this area.

There could be some benefit in setting up a better entry point for
getting the current sources for a variety of Tcl packages.

> We now also have a popular proprietary software distribution mechanism
> in ActiveTcl that only supports TEA packages. That means the hard work
> of people like myself isn't included, and many others that don't use
> TEA. And I can't use it anyway on a non-ActiveTcl supported system.
There are some options here:
- Create something better and make it popular enough
- Reverse engineer it like the samba people did with cifs and provide a
teapot server with stuff for the BSDs
- Make TEA better so it supports you usecase better (and if that means
throw autotools out of the window so be it...)

BTW. its not much better than what other languages do. Python for
example has disttools in its main distribution, which take care of some
of the build issues like TEA does, but as soon as you need extra tweaks
to your compiler settings (non-standard flags, extra include or lib
dirs) your often writing non-portable setup.py files again.

> Also, what happens if ActiveState pulls a Scriptics/Ajuba/Interwoven on
> the community? Do you really want to be stuck telling your boss that
> there are no alternatives, other than to dump Tcl and move to
> Java/Python/Ruby/Perl?
As you said before, most of this stuff is open source, so one could
always hire someone to do the job for you. Not much different from
corporations that use some popular stuff like VisualBasic where you are
at the whim of Microsoft and are really

about the VB.Net move...

Michael

George Peter Staplin

2007-12-23, 4:32 am

Michael Schlenker wrote:
> George Peter Staplin schrieb:
>
> Hi George,

Hi Michael,

> sorry to say that, i would think the answer is: NO

I respectfully disagree.

> There is some benefit in diversity and having both Tclkit, evolanes
> etcl, ActiveTcl, the various OS distros and some other more special
> cased versions is nice, but not strictly needed.
> Your wrong on that point. There is at least etcl and afaik some other
> minor distributions around. IIRC from the chat even bitkeeper was
> thinking about building their own distro. Not all have the same set of
> extensions, and getting an agreement on whats essential puts you back
> into the Batteries Included discussion.

etcl is binary-only as far as I know, and includes several proprietary
extensions. It's not open source, and based on what others have said
probably never will be. It supports even fewer systems than ActiveTcl.

> What would be nice was a buildbot style system to get nightly builds and
> test runs like many other projects do them.
> Are unable to communicate with others in some cases...
> Basically its a given that they don't use CVS head, which wouldn't be a
> problem if they did for Tcl what some distributions do for many of their
> other packages, port fixes from CVS into the distro.

I don't blame them. Who knows what garbage will get commited, only to
be reverted?

> IncrTcl is an example of a totally messy web presence, no clear
> communication on the state of affairs and a lot of outdated file releases.
> So if i didn't knew better from the chat and the wiki i would assume its
> dead and abandoned. (closer look at CVS activity shows thats not
> entirely true, but cursory look tells you its dead).
> Img is not much better in its communication.
> So if you had the choice as a maintainer to hunt info about arcane Tcl
> packages or fix your other more active sources (e.g. the OS X maintainer
> at apple has to deal with Tcl/Tk and all of X11, so he didn't have
> enough time to include the nearly complete patch for a more modern Tcl
> in leopard that was sent to him.)

Sounds as though OS X should use ActiveTcl then, I guess. ;) Perhaps
Apple could pay ActiveState for that ability.

> So to get up to date Tcl packages into your distribution of choice (be
> it some kind of BSD, OpenSolaris, OS X, or whatever else) it takes work.
> Work that someone has to do. The maintainers will probably not do it,
> because they are busy and don't care for your particular OS because they
> either have no benefit or just don't know anyone who uses it on that
> platform. A new core binary distribution wouldn't fix much in this area.

A new distribution (with sources as well) would at least provide a
freely available distribution from which OS maintainers could pull their
sources from. Have you ever read the ActiveTcl user license agreement?
It's unusuable for Linux distributors, as well as BSD, but then that's
the point.

http://www.activestate.com/Products..._agreement.plex

> There could be some benefit in setting up a better entry point for
> getting the current sources for a variety of Tcl packages.
>
> There are some options here:
> - Create something better and make it popular enough
> - Reverse engineer it like the samba people did with cifs and provide a
> teapot server with stuff for the BSDs
> - Make TEA better so it supports you usecase better (and if that means
> throw autotools out of the window so be it...)

There have been others in the past. The problem is that the Tcl Core
Team is so used to saying "use ActiveTcl" they can't fathom any change,
and they can't include an alternative in the core now, because that
would step on the toes of Jeff Hobbs, and Andreas Kupries, and any other
ActiveState employees.

> BTW. its not much better than what other languages do. Python for
> example has disttools in its main distribution, which take care of some
> of the build issues like TEA does, but as soon as you need extra tweaks
> to your compiler settings (non-standard flags, extra include or lib
> dirs) your often writing non-portable setup.py files again.
>
> As you said before, most of this stuff is open source, so one could
> always hire someone to do the job for you. Not much different from
> corporations that use some popular stuff like VisualBasic where you are
> at the whim of Microsoft and are really

about the VB.Net move...

I want what's best for Tcl. :) Citing a dying company like Microsoft
doesn't do us much good.

George

Pascal

2007-12-23, 8:17 am

George Peter Staplin a écrit :

> etcl is binary-only as far as I know, and includes several proprietary
> extensions. It's not open source, and based on what others have said
> probably never will be. It supports even fewer systems than ActiveTcl.

I would not say "fewer systems" but "different systems". For example
eTcl supports Pocket PC, not ActiveState.

Pascal

Michael Schlenker

2007-12-23, 7:21 pm

George Peter Staplin schrieb:
> Michael Schlenker wrote:
>
> A new distribution (with sources as well) would at least provide a
> freely available distribution from which OS maintainers could pull their
> sources from.
I find the source part the interesting thing, yes. It might conflict
with absurd distributors policies about getting and patching sources
though..., but you don't get things to work if you do not have the
volunteers aka manpower to do the job. Tech is the smaller problem.

There is no real need for another binary distro, but a good managed
source repository would be a good thing. I actually like the cheeseshop
of python, it has some sane rules, but don't like their technology.

> Have you ever read the ActiveTcl user license agreement?
yes, i have acceptable for my uses

>
> There have been others in the past. The problem is that the Tcl Core
> Team is so used to saying "use ActiveTcl" they can't fathom any change,
> and they can't include an alternative in the core now, because that
> would step on the toes of Jeff Hobbs, and Andreas Kupries, and any other
> ActiveState employees.
And i don't think there isn't a current, portable alternative that
someone tried. I'm sure if someone got rid of the autotools mess and
replaced it with a better toolchain (but provided support for nearly all
the platforms that autotools does) it would have a chance.

Bras is nice but I'm not sure it has all the autoconf goo for checking
headers and other portability support. SCons is Python and sucks quite a
bit. CMake isn't too bad but needs a C++ compiler (if i read the docs
right), so not as portable as Tcl.

Michael

Michael

Gerald W. Lester

2007-12-23, 7:21 pm

George Peter Staplin wrote:
> ...
> There have been others in the past. The problem is that the Tcl Core
> Team is so used to saying "use ActiveTcl" they can't fathom any change,
> and they can't include an alternative in the core now, because that
> would step on the toes of Jeff Hobbs, and Andreas Kupries, and any other
> ActiveState employees.
>
>...

George,

I disagree. The TCT can look to change their recommendation. An I do not
think they worry about stepping on Jeff or anyone else toes.

May I suggest that you go ahead and create a *better* (not just alternative
distro) and see if people do not use it.

--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

slebetman@yahoo.com

2007-12-23, 7:21 pm

On Dec 23, 10:33 pm, Michael Schlenker <schl...@uni-oldenburg.de>
wrote:
> George Peter Staplin schrieb:> Michael Schlenker wrote:
>
>
> I find the source part the interesting thing, yes. It might conflict
> with absurd distributors policies about getting and patching sources
> though..., but you don't get things to work if you do not have the
> volunteers aka manpower to do the job. Tech is the smaller problem.
>
> There is no real need for another binary distro, but a good managed
> source repository would be a good thing. I actually like the cheeseshop
> of python, it has some sane rules, but don't like their technology.
>
<unsnipped>[color=darkred]
</unsnipped>[color=darkred]
>
> yes, i have acceptable for my uses
>
>

Sorry "acceptable to your eyes" does not mean acceptable for a Linux
distro, which is what George was saying. Specifically:

2. ..You may not distribute copies of this Package, or copies of
packages derived from this Package, or cause by Your actions copies of
this Package to be distributed, to others outside your organization
without specific prior written permission from ActiveState..

and

4. ..this License does not allow You to (a) redistribute the Package
as a whole..

directly conflicts with GPL such that including ActiveTcl in a distro
would make the distro illegal (legally speaking). Even if ActiveState
PROMISE TO NEVER SUE Linux distros which redistribute ActiveTcl
(essentially creating a separate license for Linux similar to the
Novell-Microsoft agreement for said distros) some distros would prefer
a non conflicting license. But we don't have any such promise/
agreement from ActiveState so the clean/unclean point is moot. It is
simply illegal to include ActiveTcl in a Linux distro.

stevel

2007-12-23, 7:21 pm

On Dec 23, 4:27=A0pm, George Peter Staplin
<georgepsSPAMME...@xmission.com> wrote:
> Given what some people have said about ActiveTcl recently I wonder --
>
> Is there a need for another distribution, perhaps maintained by the
> community?

I don't know what people have said about ActiveTcl recently, but from
my perspective (as a person who produced the tclkit ports) I value
what ActiveState have done.

It takes a lot of work to maintain a distribution - ask Jeff Hobbs
some time about their automated build system, or the joys of producing
a Linux shared library that will work everywhere (despite g/libc
version hell), or accommodating a bag of extensions from multiple
authors.

stevel

2007-12-23, 7:21 pm

On Dec 24, 6:57=A0am, stevel <st...@digitalsmarties.com> wrote:

> I don't know what people have said about ActiveTcl recently, but from
> my perspective (as a person who produced the tclkit ports)

That should be "helped produce the Tclkit ports" ... mainly the
Solaris ones but also Tru64, AIX and HP-UX at various times.

The point being that doing a distro for a single Linux variant is one
thing, doing a distro that is consistent across diverse platforms and
architectures is a significant amount of work.

Jeff Hobbs

2007-12-23, 7:21 pm

On Dec 23, 2:00 am, George Peter Staplin
<georgepsSPAMME...@xmission.com> wrote:
> Michael Schlenker wrote:
>
> I respectfully disagree.

Of course you do, otherwise you wouldn't post the question. While
there is nothing stopping you from creating your own distro, it
doesn't mean you should spread FUD or inaccurate representation of
others. Let me address a few ...

>
> There have been others in the past.

Which ones, when? The Tcl community has never had a set of releases
as consistent, as rich or as cross-platform as ActiveTcl. That is
certain. It doesn't cover all platforms (notably, you want BSD), but
we can't do everything.

> The problem is that the Tcl Core
> Team is so used to saying "use ActiveTcl" they can't fathom any change,
> and they can't include an alternative in the core now, because that
> would step on the toes of Jeff Hobbs, and Andreas Kupries, and any other
> ActiveState employees.

Where such a statement of "use ActiveTcl" is made by a TCT _member_
(as ActiveTcl isn't endorsed by the core team in any way above another
distro), it is made because users are often struggling with compiling
when the ActiveTcl binaries would work for them. On some Linux
systems, the installed version may work, but many Linux distributors
don't keep up-to-date that fast.

If you choose to create an alternative distro that has better
qualities, I'm sure that people would recommend it. People vote with
their feet. Just fomenting discord is of no help to anyone.

As to the TCT worrying about stepping on ActiveState's toes ... I'm
not aware of any real issues here. Perhaps it is backroom concern
that I would not see, but I hope and believe the TCT members have the
integrity and honesty to let me know if they felt ActiveState were to
ever actually impeded Tcl's progress. I believe the opposite to be
the easily substantiated case.

>
> I want what's best for Tcl. :) Citing a dying company like Microsoft
> doesn't do us much good.

ActiveState wants what is best for Tcl as well. The last comment is
just perplexing ... I think we'd all be humored to think of finding
ourselves in Microsoft's dominant position. I guess from this thread
and others that you are one of the staunch anti-commercial types.
That is fine, but oftentimes commercial interests do improve things.
You can try and paint ActiveState with a negative brush, but it isn't
corroborated by the facts. ActiveState has, does and will support Tcl
in a way that benefits the community as a whole.

Jeff

Jeff Hobbs

2007-12-23, 7:21 pm

I addressed the philosophical side in my first post, but there are a
few points worth answering here ...

On Dec 22, 11:27 pm, George Peter Staplin
<georgepsSPAMME...@xmission.com> wrote:
> Most of ActiveTcl is based on freely available software.

Yes, 99% actually.

> ActiveTcl developers know more than most Linux distributors about which
> sources to use, for instance some of the Tcl-based projects on
> sourceforge get some regular bug/build fixes in the cvs HEAD, but no
> releases, except from ActiveState.
>
> So, Ubuntu/Debian/Redhat and other distributors lag behind in some cases
> because they either A) refuse to use the cvs HEAD B) don't know to use
> the cvs HEAD rather than the releases of some packages.

Yes, this is correct, and it isn't intentionally done by AS to make it
harder for others. There is a difference between maintenance and
release engineering. There are many projects that need small fixes
that don't have real maintainers anymore. ActiveState has applied
innumerable patches to various projects over time, some user-
contributed, many developed from bug reports or fixed by us in the
first place. This all takes time, and we use these fixed modules in
our own work. In almost all cases, these are contributed right back
to the sources so that others can directly contribute from them (some
distros just post patches to projects and expect you to find them -
ick).

To do the release engineering on top of that would just take more time
than we have. So yes, ActiveState does know more about the broad
state of all things Tcl than any other group (aside from the TCT
collectively). It is part of our business to know that, but we do
share that knowledge as well.

> Look at the Img home page for a good example of that. Another is Incr
> Tcl... This gives the impression that Tcl is dying, but it's good for
> ActiveTcl, because those in the know just say "use ActiveTcl."

Yes, let's look at Img or [incr Tcl], or add TclX, Tix or several
other modules into the mix. If not for ActiveState's efforts over the
years, these would be unusable modules, and where would the Tcl
community then? The only personal enrichment I've received from such
efforts is quite a few drinks at various conferences. I will say that
I appreciate every one of them and thank the suppliers. Here's hoping
for another secret santa bottle under the tree. :)

If you would like to have somewhere to direct your energies, release
engineering would be greatly appreciated by many. In fact, it is a
prerequisite of what you want to do anyways.

> You have no idea how frustrating that last comment is when you're using
> an unsupported system like OpenBSD or NetBSD, or simply want to make
> sure that the Cool Aid is safe by mixing it yourself.

I'm not sure why using ActiveTcl should be drinking th Kool-Aid, but
yes, BSD is not an ActiveState platform. Is that the real issue here?

> We now also have a popular proprietary software distribution mechanism
> in ActiveTcl that only supports TEA packages. That means the hard work
> of people like myself isn't included, and many others that don't use
> TEA. And I can't use it anyway on a non-ActiveTcl supported system.

I addressed the TEA issue before, but I'll reiterate it ... there is a
very good reason to try and use TEA. If TEA doesn't work for you,
then improving that is 1000x better than going with something
completely different. There are a million ways to create makefiles.
ActiveState focuses on and encourages TEA because it is the one that
"just works" across platforms, and you just have to trust me when I
say that because I have the experience of time.

> Also, what happens if ActiveState pulls a Scriptics/Ajuba/Interwoven on
> the community? Do you really want to be stuck telling your boss that
> there are no alternatives, other than to dump Tcl and move to
> Java/Python/Ruby/Perl?

If that happens, then ActiveState has been acquired or died. Let's
hope for the former, as it will be better for Andreas and me. :) As
to what happens then, who knows. I get the impression that the
community is actually growing recently, and that 8.5 will only improve
things. Regarding the switch from Scriptics to ActiveState, I think
you should revisit the distros that Scriptics made and reevaluate how
much ActiveState has helped. We have no nefarious machinations to
ruin things.

Jeff

tom.rmadilo

2007-12-24, 4:26 am

Unfortunately the question "do we need another distribution" is
equivalent to the question "do I need a team to fold my underwear".

The answer is NO! Producing a distribution must be the least rewarding
task ever (behind folding my underwear). Creating a second one is
beyond pointless. Who goddamn cares, on this list, about a second
distribution? Personally I have never even downloaded one of these
things, where are they?

The whole point of a distribution is that the users don't need to
think about anything. A second 'distribution' means that users have to
think. Did I start with dist1 or dist2?

In general distributions are a distraction. They introduce at least as
many issues as they solve. This doesn't make them useless, just
something which is unimportant to application developers.

Michael Schlenker

2007-12-24, 8:18 am

slebetman@yahoo.com schrieb:
> On Dec 23, 10:33 pm, Michael Schlenker <schl...@uni-oldenburg.de>
> wrote:
> <unsnipped>
> </unsnipped>
> Sorry "acceptable to your eyes" does not mean acceptable for a Linux
> distro, which is what George was saying. Specifically:
Yes, sure. Never said that its acceptable for Linux distros. Not much
besides the one pure and true GPL (in the latest version of course) is
actually acceptable to some of the more strict Linux distros.

>
> 2. ..You may not distribute copies of this Package, or copies of
> packages derived from this Package, or cause by Your actions copies of
> this Package to be distributed, to others outside your organization
> without specific prior written permission from ActiveState..

Yes, basically: Don't distribute the free version without explicit
permission. Not entirely uncommon for a commercial entity.

> and
>
> 4. ..this License does not allow You to (a) redistribute the Package
> as a whole..
>
> directly conflicts with GPL such that including ActiveTcl in a distro
> would make the distro illegal (legally speaking).
Only if you force your distro to full GPL like Debian. There are lots of
non-free packages in distributions.

But yes, its unlikely that AS Tcl will be shipped with any linux
distros. Even if the License was okay, the distros would start bitching
about other stuff (static linked libraries vs. use distro libs that vary
for each distro, use rpath or don't ever use rpath and tons of other
insane stuff). So even if AS would allow it, it would simply not work as
a binary distro. What all this targets is: Make all of the ActiveState
buildprocess and setup including source code freely available. Which is
totally different to the current ActiveTcl distro..., so all the license
talk is misguided because it doesn't apply to a non-existing target.

But the license discussion is the wrong battlefield. The main problem is
that most distributions just don't really care about Tcl, that just
package it because some old program need it, thats a main reason you
have e.g. Tcl 8.3 still in some distros. To improve that you both need
manpower to do some work and get up to date packages for the distros
(one option would be someone to setup all the needed stuff at the
OpenSUSE buildfarm for example), then need someone with authority (there
is no such person really) to define whats the acceptable minimum of Tcl
packages everbody should include (which is an unsolved topic itself),
then need lots of work to collect all the info which package versions
work together and document and best automate it.

So basically if you want better Tcl/Tk support in your distro, sign up
as a maintainer somewhere and make it happen there. A centralized effort
is a waste of time.

Michael

Robert Hicks

2007-12-24, 7:16 pm

On Dec 24, 12:29=A0am, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
> Unfortunately the question "do we need another distribution" is
> equivalent to the question "do I need a team to fold my underwear".
>
> The answer is NO! Producing a distribution must be the least rewarding
> task ever (behind folding my underwear). Creating a second one is
> beyond pointless. Who goddamn cares, on this list, about a second
> distribution? Personally I have never even downloaded one of these
> things, where are they?
>
> The whole point of a distribution is that the users don't need to
> think about anything. A second 'distribution' means that users have to
> think. Did I start with dist1 or dist2?
>
> In general distributions are a distraction. They introduce at least as
> many issues as they solve. This doesn't make them useless, just
> something which is unimportant to application developers.

Good points. I can't help but wonder though if a mechanism could be
put in place for "source" level repos. I am fine with the way Teapot/
Teacup work but I use ActiveTcl. Shouldn't there be a way for a
"standard" Tcl install to use a repo? Perl does this and it works
there with CPAN. I do not pretend to know how hard that would be but I
know it is possible.

Robert

billposer@alum.mit.edu

2007-12-24, 7:16 pm

One distribution that rather highlights Tcl is Puppy Linux:
http://www.puppylinux.org. Tcl/Tk is part of the distribution, and
they include quite a few programs written in Tcl/Tk. I haven't used
this distribution so I don't know the details, but it might be worth
looking into what they do, maybe even collaborating with them.

Robert Hicks

2007-12-24, 7:16 pm

On Dec 23, 5:58=A0pm, Jeff Hobbs <jeff.ho...@gmail.com> wrote:
<snip>
>
> ActiveState wants what is best for Tcl as well. =A0The last comment is
> just perplexing ... I think we'd all be humored to think of finding
> ourselves in Microsoft's dominant position. =A0I guess from this thread
> and others that you are one of the staunch anti-commercial types.
> That is fine, but oftentimes commercial interests do improve things.
> You can try and paint ActiveState with a negative brush, but it isn't
> corroborated by the facts. =A0ActiveState has, does and will support Tcl
> in a way that benefits the community as a whole.
>
> Jeff

I wholeheartedly agree with that. I haven't had any problems with
ActiveTcl and the questions I have asked through the support email
have always been kind, considerate and correct. But...

I don't think what ActiveState thinks is good for the community is
always 100% in sync. Teacup and Teapot would be in that category.
Those are binary repos (unless it is pure Tcl code) only when the
community could benefit more with something on the source level like
CPAN that actually comes with the standard Tcl install.

I am not saying that is "bad". It is a reality that sometimes the
"corporate" comes before the "community". That is understandable and
some people might not like that. They might not like the fact that
ActiveTcl is the face of Tcl no matter how community friendly they may
be.

I am a fan of ActiveTcl so don't count any of this as coming down on
ActiveState at all. I can see both sides of the reasoning and I am
fine with ActiveTcl.

GPS might fall into that category. If so, then maybe "something" needs
to be worked on. I don't think we need yet another distro of Tcl but
maybe something that comes with the standard source that allows the
use of source repos like Perl and CPAN do. Tcl is a different
community though and it might not work out like it did for the Perl
community. I don't know. I don't have enough history with the Tcl
community to make that kind of call.

Robert

Donal K. Fellows

2007-12-24, 7:16 pm

Robert Hicks wrote:
> Good points. I can't help but wonder though if a mechanism could be
> put in place for "source" level repos. I am fine with the way Teapot/
> Teacup work but I use ActiveTcl. Shouldn't there be a way for a
> "standard" Tcl install to use a repo? Perl does this and it works
> there with CPAN. I do not pretend to know how hard that would be but I
> know it is possible.

I think that teapot points the way and is a great solution for people
who just want pre-built packages. There's probably some tuning still to
do to get things perfect (especially for source-packages) but it's going
to take experience to work out all the use-cases.

Donal.

Robert Hicks

2007-12-24, 7:17 pm

On Dec 24, 1:58=A0pm, "Donal K. Fellows"
<donal.k.fell...@manchester.ac.uk> wrote:
> Robert Hicks wrote:
>
> I think that teapot points the way and is a great solution for people
> who just want pre-built packages. There's probably some tuning still to
> do to get things perfect (especially for source-packages) but it's going
> to take experience to work out all the use-cases.
>
> Donal.

I agree 100% and we are just starting to go down the road now.

Robert

Jeff Hobbs

2007-12-24, 7:17 pm

On Dec 24, 10:46 am, Robert Hicks <sigz...@gmail.com> wrote:
> On Dec 23, 5:58 pm, Jeff Hobbs <jeff.ho...@gmail.com> wrote:
>
> I wholeheartedly agree with that. I haven't had any problems with
> ActiveTcl and the questions I have asked through the support email
> have always been kind, considerate and correct. But...
>
> I don't think what ActiveState thinks is good for the community is
> always 100% in sync. Teacup and Teapot would be in that category.
> Those are binary repos (unless it is pure Tcl code) only when the
> community could benefit more with something on the source level like
> CPAN that actually comes with the standard Tcl install.

Sorry, but I strongly disagree. Let me see if you agree if we turn
the concept around. What if ActiveState had instead built tpan
instead of teapot, with only sources? Would that have truly been
better? That would work in part for the Linux crowd (even they have
compiler questions), but what about the others? Just as the value of
tclkits are in their ready-made nature, most people actually prefer
"it just works".

And BTW, for all those whining (sorry, yes, it seems that way mostly
from the way it is presented), does anybody realize or acknowledge
that the teapot does in fact contain sources for C-based extensions as
well? It isn't as perfect as real release engineering, but it is
there, yet another feature and service based on community requests.

Jeff

Robert Hicks

2007-12-24, 7:17 pm

On Dec 24, 2:37=A0pm, Jeff Hobbs <jeff.ho...@gmail.com> wrote:
> On Dec 24, 10:46 am, Robert Hicks <sigz...@gmail.com> wrote:
>
>
>
[color=darkred]
d[color=darkred]
cl[color=darkred]
>
>
>
> Sorry, but I strongly disagree. =A0Let me see if you agree if we turn
> the concept around. =A0What if ActiveState had instead built tpan
> instead of teapot, with only sources? =A0Would that have truly been
> better? =A0That would work in part for the Linux crowd (even they have
> compiler questions), but what about the others? =A0Just as the value of
> tclkits are in their ready-made nature, most people actually prefer
> "it just works".

I do realize that and I am in the "it just works" crowd. I was only
trying to present the other side.

You could actually do just a "source" thing as the Perl have done (see
Strawberry Perl). Is it "easy" probably not but it can be done.

>
> And BTW, for all those whining (sorry, yes, it seems that way mostly
> from the way it is presented), does anybody realize or acknowledge
> that the teapot does in fact contain sources for C-based extensions as
> well? =A0It isn't as perfect as real release engineering, but it is
> there, yet another feature and service based on community requests.
>
> Jeff

I realize that and acknowledge it. I was only trying to present the
other side.

I hope you weren't inferring that I am in the group whining. I tried
to state that I was happy with ActiveTcl and Teacup/Teapot but I also
tried to convey the mentality on the other side of the street. Sorry
if it didn't come across that way to you.

Robert

Robert Hicks

2007-12-24, 7:17 pm

tom.rmadilo

2007-12-24, 7:17 pm

On Dec 24, 11:57 am, Robert Hicks <sigz...@gmail.com> wrote:

> BTW...how does someone contribute to the Teapot?

As someone who has never used teapot or teacup, what is it? From the
description it sounds like a client-server installation/configuration
tool of some sort.

One thing that there always seems to be a lack of is expert
installation advice and information for related packages, stuff that
needs to be combined in a particular way so things work as intended. I
guess this is the same motivation behind the starkits.

Several years ago I wanted to automate this process for a bunch of
packages I needed to download, configure, make and install (and then
setup config files). I didn't want to create a hard coded installation
path, in fact, I couldn't because it would be necessary to install
several copies on the same machine.

I came up with something called app-install, written in Tcl which read
a configuration file, usually from a foreign url. The first
configuration file was usually a list of other configuration files in
a similar form, for instance:

'include'
'variable'
'name'AllBaseUrl'
'default'http://rmadilo.com/app-install'
''
'url'$AllBaseUrl/tcl/tcl-8.4.5.rhf'
'url'$AllBaseUrl/daemontools/daemontools-0.76.rhf'
'url'$AllBaseUrl/postgresql/postgresql-7.3.4.rhf'
'url'$AllBaseUrl/pg-init.d/pg-init.rhf'
'url'$AllBaseUrl/aolserver/aolserver-4.0.7.rhf'
'url'$AllBaseUrl/cvs/cvs.rhf'
'url'$AllBaseUrl/openacs/openacs-5.0.0b1a.rhf'
'url'$AllBaseUrl/openacs-prep/openacs-prep-5.0.0b1a.rhf'
''

The script would fetch these and 'include' them into the scrip, for
instance, the config script for tcl:

'application'
'variable'
'name'TclVersion'
'default'8.4.5'
''
'variable'
'name'TclBaseUrl'
'default'http://rmadilo.com/app-install/tcl/'
'help'Directory URI for application file.'
''
'variable'
'name'TclFilename'
'default'tcl${TclVersion}-src.tar.gz'
''
'variable'
'name'TclPrefix'
'default'/usr/local/aolserver'
''
'variable'
'name'TclBuildDir'
'default'./'
''
'variable'
'name'TclUrl'
'default'$TclBaseUrl$TclFilename'
''
'md5sum'3fb354dba28166a1004f9103553a3974
'
'command'cd $TclBuildDir'
'command'wget $TclUrl'
'command'tar xzf $TclFilename'
'command'cd tcl${TclVersion}/unix'
'command'./configure --prefix=$TclPrefix \\
--enable-threads \\
--enable-shared'
'command'make'
'command'make install'

'comment'This is the end'
''

Certain things happened behind the scenes besides the obvious
execution of commands. For instance, the app-install application would
step the user through the set of variables allowing them to change any
as needed. All I/O was recorded into a single log file for all of the
commands, so all information would be available if something went
wrong and the user sought help. Certain commands like [cd] get special
attention to log what directory is the [pwd]. The variable values can
be reused in later scripts. This is not as risky as you might think,
since it is unlikely that the expert who wrote the includes would not
know about any conflicts.

The main feature however is that the problem of keeping up with an
ever-advancing set of tools is decomposed into a set of much smaller
tasks: a new install script for each released tool, probably with very
little change, and a new top-level 'include' script to reference the
new scripts.

Jeff Hobbs

2007-12-24, 7:17 pm

On Dec 24, 11:57 am, Robert Hicks <sigz...@gmail.com> wrote:
> BTW...how does someone contribute to the Teapot?

You make a request to ActiveState. Yes, it isn't direct community
maintained, but there is a reason for that, mostly trust and
reliability factors. Others are welcome to create and maintain their
own teapot repos (it is designed to support that) with their own set
of binaries. This is in the same style as PPM is to Perl.

For the most part, if it is a TEA extension with a reliable source
area (SF, Google code or other reliable web host), then it is
relatively easy to add.

Jeff

Robert Hicks

2007-12-24, 7:17 pm

On Dec 24, 4:28=A0pm, Jeff Hobbs <jeff.ho...@gmail.com> wrote:
> On Dec 24, 11:57 am, Robert Hicks <sigz...@gmail.com> wrote:
>
>
> You make a request to ActiveState. =A0Yes, it isn't direct community
> maintained, but there is a reason for that, mostly trust and
> reliability factors. =A0Others are welcome to create and maintain their
> own teapot repos (it is designed to support that) with their own set
> of binaries. =A0This is in the same style as PPM is to Perl.
>
> For the most part, if it is a TEA extension with a reliable source
> area (SF, Google code or other reliable web host), then it is
> relatively easy to add.
>
> Jeff

I am find with that. I realize the AS repo needs to have stable
verified binaries. Is there some documentation on how to setup a repo?

Robert

Jeff Hobbs

2007-12-24, 7:17 pm

On Dec 24, 1:31 pm, Robert Hicks <sigz...@gmail.com> wrote:
> I am find with that. I realize the AS repo needs to have stable
> verified binaries. Is there some documentation on how to setup a repo?

All the teapot administrative tools are part of TDK and documented at:

http://aspn.activestate.com/ASPN/do...0/TEA_Apps.html

Jeff

George Peter Staplin

2007-12-25, 4:27 am

Jeff Hobbs wrote:
> On Dec 23, 2:00 am, George Peter Staplin
><georgepsSPAMME...@xmission.com> wrote:
>
> Of course you do, otherwise you wouldn't post the question. While
> there is nothing stopping you from creating your own distro, it
> doesn't mean you should spread FUD or inaccurate representation of
> others. Let me address a few ...

Unfortunately you missed the point of why I was saying I respectfully
disagree. I am more open to change than some people I suppose. Michael
Schlenker is a bright person, and it's possible that his message would
have convinced me to change my mind.

>
> Which ones, when? The Tcl community has never had a set of releases
> as consistent, as rich or as cross-platform as ActiveTcl. That is
> certain. It doesn't cover all platforms (notably, you want BSD), but
> we can't do everything.

I was talking about the distribution mechanism. Joe English has gutter,
and some tools for generating it. There have been other *Teapot-like*
tools. That's all I was saying. The context was misplaced.

>
> Where such a statement of "use ActiveTcl" is made by a TCT _member_
> (as ActiveTcl isn't endorsed by the core team in any way above another
> distro), it is made because users are often struggling with compiling
> when the ActiveTcl binaries would work for them. On some Linux
> systems, the installed version may work, but many Linux distributors
> don't keep up-to-date that fast.

Does a TCT member exist that works on any other distro?

> If you choose to create an alternative distro that has better
> qualities, I'm sure that people would recommend it. People vote with
> their feet. Just fomenting discord is of no help to anyone.

I'm not choosing to. I just asked if there was a need. That is all.
Quit putting words in my mouth, and misunderstood intentions.

George

Robert Hicks

2007-12-25, 7:16 pm

On Dec 25, 1:30=A0am, George Peter Staplin
<georgepsSPAMME...@xmission.com> wrote:
<snip>
>
> I'm not choosing to. =A0I just asked if there was a need. =A0That is all. =
=A0
> Quit putting words in my mouth, and misunderstood intentions.
>

To be fair, I don't think it was just Jeff that misunderstood. I
thought along the same lines as him as well when reading your post. I
even posted to your wiki page asking about it (you can delete than
now).

Robert

Eckhard Lehmann

2007-12-26, 8:12 am

Jeff Hobbs schrieb:

> I'm not sure why using ActiveTcl should be drinking th Kool-Aid, but
> yes, BSD is not an ActiveState platform. Is that the real issue here?

Since OSX is based on BSD, would it be possible to use the OSX distro of
ActiveTcl on this platform? Just an idea...

> I addressed the TEA issue before, but I'll reiterate it ... there is a
> very good reason to try and use TEA. If TEA doesn't work for you,
> then improving that is 1000x better than going with something
> completely different. There are a million ways to create makefiles.
> ActiveState focuses on and encourages TEA because it is the one that
> "just works" across platforms, and you just have to trust me when I
> say that because I have the experience of time.

Full ACK. For release engineering TEA is definitely the best way to go!
Although I must say that for some extensions it takes longer to
configure the TEA scripts and ac macros than to write the C code... ;-).

TEA comes in handy, when one develops an extension that should be
compiled on different platforms. BUT: At least I create the extension on
one platform (likely Linux, Windows or Mac OSX), and have binaries for
this platform. When I provide the source to users of other platforms,
e.g. via sourceforge, the recipients should know enough about the
compile process there, so that they can build it without TEA as well
(afer reading some instructions maybe...). This is mostly easy, since
many Tcl extensions consist only of very few C files and you could
actually compile them on the command line.

The only bit that was missing before teapot is the deployment of
*binary* extensions via a central repository. This is addressed now and
it is great and so far sufficient, in my opinion. I think that there is
no need for another standard source code repository besides sourceforge,
google code - or whatever extension developers use to maintain their code.

Eckhard

George Peter Staplin

2007-12-26, 10:18 pm

Robert Hicks wrote:
> On Dec 25, 1:30_am, George Peter Staplin
><georgepsSPAMME...@xmission.com> wrote:
><snip>
>
> To be fair, I don't think it was just Jeff that misunderstood. I
> thought along the same lines as him as well when reading your post. I
> even posted to your wiki page asking about it (you can delete than
> now).

OK :) I'm not always as clear as I should be, and sometimes I let my
frustrations come out and confuse matters.

George

Robert Hicks

2007-12-26, 10:18 pm

On Dec 26, 9:02=A0pm, George Peter Staplin
<georgepsSPAMME...@xmission.com> wrote:
> Robert Hicks wrote:
th[color=darkred]
>
l. =A0[color=darkred]
>
>
> OK :) =A0I'm not always as clear as I should be, and sometimes I let my
> frustrations come out and confuse matters.
>
> George

Happens to us all. : )

davidnwelton@gmail.com

2007-12-27, 4:29 am

I think that AS Tcl is a "local maximum" in that it's pretty good for
a lot of people and has provided a lot of value, but could probably be
improved on by having something more community-oriented.

As I've said in the past, it makes sense to have:

* Minimal/core Tcl clearly labeled as "you don't really want this
unless you know you do".

* Batteries included distribution. Core + at least tcllib, maybe a
few other things. This makes Tcl more valuable out of the box for
people with systems like Linux or MacOS X. One thing it should have
is basic command line editing (even Hecl has this in svn HEAD!).

Jeff Hobbs

2007-12-27, 7:16 pm

On Dec 27, 1:40 am, "davidnwel...@gmail.com" <davidnwel...@gmail.com>
wrote:
> I think that AS Tcl is a "local maximum" in that it's pretty good for
> a lot of people and has provided a lot of value, but could probably be
> improved on by having something more community-oriented.
>
> As I've said in the past, it makes sense to have:
>
> * Minimal/core Tcl clearly labeled as "you don't really want this
> unless you know you do".
>
> * Batteries included distribution. Core + at least tcllib, maybe a
> few other things. This makes Tcl more valuable out of the box for
> people with systems like Linux or MacOS X. One thing it should have
> is basic command line editing (even Hecl has this in svn HEAD!).

Does hecl use non-(L)GPL code to get command line editing?

People have proposed the partial-BI source distro before. I think it
is a good idea as well. You would rearrange the bits on SF to have
tcl-core-8.5.0.tar.gz and tcl-8.5.0.tar.gz that included the various
bits assembled properly.

The real trick is in the release engineering, which so few seem
inclined to work on. It is one thing to get the core out, it is
entirely another to do the release engineering for a set of modules
and merge them without significantly effecting the stability or your
sanity.

Jeff

davidnwelton@gmail.com

2007-12-27, 7:16 pm

On Dec 27, 5:45 pm, Jeff Hobbs <jeff.ho...@gmail.com> wrote:
> On Dec 27, 1:40 am, "davidnwel...@gmail.com" <davidnwel...@gmail.com>
> wrote:
>
>
>
>
>
> Does hecl use non-(L)GPL code to get command line editing?

It uses jline, which is under a BSD license. You'd want to look at
editline, I think, for something BSD licensed. Looking at how Ruby
and Python handle things might be a good idea too. The Ruby folks
seem to be more casual about licensing issues, but I don't get that
impression about Python.

> People have proposed the partial-BI source distro before. I think it
> is a good idea as well. You would rearrange the bits on SF to have
> tcl-core-8.5.0.tar.gz and tcl-8.5.0.tar.gz that included the various
> bits assembled properly.

> The real trick is in the release engineering, which so few seem
> inclined to work on. It is one thing to get the core out, it is
> entirely another to do the release engineering for a set of modules
> and merge them without significantly effecting the stability or your
> sanity.

Fair enough - this might be a good project for someone wanting to help
out who doesn't feel quite up to hacking on C code. Debian is a good
demonstration (IMO) of people doing very useful work without
necessarily being hardened C experts like the guys who work on the Tcl
core. I don't have the time at this point in my life unfortunately.

Ciao,
Dave

David Gravereaux

2007-12-27, 7:16 pm

Jeff Hobbs wrote:
> George Peter Staplin <georgepsSPAMME...@xmission.com> wrote:
>
> ....
>
>
> If that happens, then ActiveState has been acquired or died. Let's
> hope for the former, as it will be better for Andreas and me. :) As
> to what happens then, who knows. I get the impression that the
> community is actually growing recently, and that 8.5 will only improve
> things. Regarding the switch from Scriptics to ActiveState, I think
> you should revisit the distros that Scriptics made and reevaluate how
> much ActiveState has helped. We have no nefarious machinations to
> ruin things.
>
> Jeff

George,
Having lived through the Scriptics/Ajuba/Interwoven change from the
inside, the connection you are trying to imply does not exist and is
blinding you from the obvious...

Jeff is getting paid by someone to improve Tcl in the open. Be
appreciative of the now.

If you don't like it, fork all the work that Jeff and everyone else in
the community has done over the years and make (pun) your own tarballs.

BTW, John Ousterhout allowed the community in, not the other way at the
close of Ajuba. So in fact, your point is upside-down.

Unless your point is really a Neil Young, "This note's for you" vs.
Budweiser thing. Which, I hope it isn't as that's just childish.

rwk

2007-12-30, 8:37 pm

quote:
Originally posted by George Peter Staplin
Given what some people have said about ActiveTcl recently I wonder --

Is there a need for another distribution, perhaps maintained by the
community?

I realize this doesn't exactly address your question -- but all of this discussion leads me to ponder why there is all this tempest in a teapot. I have a rather different take on the problem:

The discussion keeps coming back to build engineering, which is very hard, and nobody wants to do -- and nobody really can afford to do!

Why?

Because the real problem here is NOT what is the right number of TCL distros, or perl distros, or SciLab distros, or octave, or emacs, or....

No -- the problem is that there are too @#$% many LINUX distros!!! OK, let's make that UNIX distros, but the linux ones have the rest outnumbered.

That's why the build problem is combinatorially horrible. Build engineering is tricky enough without multiplying it by large numbers.

I seriously try to avoid spending my time in makefile hell. 35 years of experience with Unix has taught me the best way is to avoid Unix entirely, especially if there's an 'imake' in the room.

But I know, and highly appreciate, that I can just grab an ActiveState distro of TCL or perl, for any platform I'm personally likely to encounter, and be off and running.

That would be extremely difficult to replace. Unimaginably difficult.

It's been a long, long time since I've built a TCL or perl myself. With the time I've saved, I've been able to have a family, raise kids, and send one off to college!

OK, I can't attribute all that to the efforts of ActiveState. But whenever I'm trying to get something done, and the bleeping platform doesn't have a functional TCL or perl, it sure reduces stress.

It's hard to see how any reasonable investment of effort could improve on that.

Better off spending your efforts killing off extraneous Linux distros. Not only would TCL benefit, but just about every other Linux-hosted piece of two-bit software would benefit, as would Linux itself.

Pooling all that saved effort -- and thus also simplifying the problem, and you might have enough resources to possibly have a non-ActiveState TCL distro.

That would mean working together, but you'd think that would be easier in the open source world than in fragmented commercial environments.

Sponsored Links