tcl-core

[TCLCORE] Question about components of Tcl/Tk8.6

[Воронов Р. <rv...@ya...>]

First, excuse me about my vary bad language.

This question for developers of Tcl/Tk (may be, for Tcl Core Team's developers)

Hello! Tell me please, why are you trying to add so many unnecessary components in the standard package of Tcl 8.6? For example, is in necessary the Itcl, if you already have TclOO? Why add TDBC in standard package, if it is possible to install it manually. There are several extensions of questionable need.

TCL's charm lies in its size. But I fear that soon Tcl's size will be equal to Java's size.

The Great extension - Tk is not installed by default with Tcl and it may be installed on the user's request. To my mind, user have to choose which extension to install and which are not.

Thus please don't add any extensions (except PNG in Tk) in standard Tcl package.

Re: [TCLCORE] Question about components of Tcl/Tk8.6

[Donal K. F. <don...@ma...>]

Воронов Роман wrote:
> Hello! Tell me please, why are you trying to add so many unnecessary
> components in the standard package of Tcl 8.6? For example, is in
> necessary the Itcl, if you already have TclOO? Why add TDBC in
> standard package, if it is possible to install it manually. There are
> several extensions of questionable need.

The actual size of those packages is pretty small, and the only one that
we're thinking of adding but where we haven't yet done so is Thread
(because that's important functionality that is very useful for taking
advantage of modern computer architectures).

> TCL's charm lies in its size. But I fear that soon Tcl's size will be
> equal to Java's size.

Don't worry about that. Java's got a massive head start...

> The Great extension - Tk is not installed by default with Tcl and it
> may be installed on the user's request. To my mind, user have to
> choose which extension to install and which are not.

Minimalism is all very well, but Tcl's not really all that minimal
anyway. (Compare with Lua here for real minimality.) The extensions that
have been gained are exactly these: TDBC (database access *core* lib;
drivers are external, and will remain so) and Itcl (it's been sought by
a large part of the community for many years). TclOO and zlib are
quasi-packages; they've got names and versions, but are really just part
of Tcl.

> Thus please don't add any extensions (except PNG in Tk) in standard
> Tcl package.

Tk now has PNG support; that'll be part of 8.6.0 (it only just slipped
8.6b1 due to shortage of developer effort).

Donal.

Re: [TCLCORE] Question about components of Tcl/Tk8.6

[Donald G P. <dg...@ni...>]

??????? ????? wrote:
> First, excuse me about my vary bad language.

I'll take that as a reason to ignore the inflammatory tone I read
in your questions.

Rather than respond point by point, let me ask you.  Would it
adequately address your concerns if we simply added another download
option for "tcl-only" ?  There could be three tarballs:

tcl-only8.6-src.tar.gz
tcl8.6-src.tar.gz
tk8.6-src.tar.gz

where currently there are only two.  "tcl-only" would contain Tcl
only.  This would acknowledge there is some subset of Tcl users
whose use patterns truly require only the language itself, and
this download option spares them the burden of stripping down the
standard release for themselves.

> Thus please don't add any extensions (except PNG in Tk) in standard Tcl package.

That comment made me laugh.  Every Tcl'er has the same prescription.
Tcl/Tk should come with the goodies I need, and none of that other crap.

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] Question about components of Tcl/Tk8.6

[Jeff H. <je...@ac...>]

On 28/04/2009 6:40 AM, Donald G Porter wrote:
> ??????? ????? wrote:
>> First, excuse me about my vary bad language.
> 
> I'll take that as a reason to ignore the inflammatory tone I read
> in your questions.
> 
> Rather than respond point by point, let me ask you.  Would it
> adequately address your concerns if we simply added another download
> option for "tcl-only" ?  There could be three tarballs:
> 
> tcl-only8.6-src.tar.gz
> tcl8.6-src.tar.gz
> tk8.6-src.tar.gz
> 
> where currently there are only two.  "tcl-only" would contain Tcl
> only.  This would acknowledge there is some subset of Tcl users
> whose use patterns truly require only the language itself, and
> this download option spares them the burden of stripping down the
> standard release for themselves.

I believe that is antiproductive to where Tcl needs to move.  The core 
download can be 50MB in size - very few people really care.  What may be 
important is that you can build the core runtime without all the 
components if you so choose, but that certainly shouldn't be the default.

>> Thus please don't add any extensions (except PNG in Tk) in standard Tcl package.
> 
> That comment made me laugh.  Every Tcl'er has the same prescription.
> Tcl/Tk should come with the goodies I need, and none of that other crap.

Yes, and someone else will say "I don't need Tk, just give me OO 
finally!", or similar.  The final line contradicts the argument of the 
entire email.

Jeff

Re: [TCLCORE] Question about components of Tcl/Tk8.6

[Twylite <tw...@cr...>]

Jeff Hobbs wrote:
>> where currently there are only two.  "tcl-only" would contain Tcl
>> only.  This would acknowledge there is some subset of Tcl users
>> whose use patterns truly require only the language itself, and
>> this download option spares them the burden of stripping down the
>> standard release for themselves.
>>     
> I believe that is antiproductive to where Tcl needs to move.  The core 
> download can be 50MB in size - very few people really care.  What may be 
> important is that you can build the core runtime without all the 
> components if you so choose, but that certainly shouldn't be the default.
>   
I think Jeff is right on the mark here.  I would like the option of a 
minimal Tcl (e.g. for embedding) but I don't really care if I have to 
download a bunch of extra stuff, so long as I can use appropriate 
compile-time options to produce a minimal build.  I think the bigger 
question is whether such compile-time options exist, and how they are 
managed with respect to future additions to the core.

Regards,
Twylite

Re: [TCLCORE] Question about components of Tcl/Tk8.6

[Donal K. F. <don...@ma...>]

Larry McVoy wrote:
> Personally, I would love to see more stuff in the core.  Instead of putting
> the burden on end users to drag stuff in they need, put the burden on the
> people who want small to toss stuff out.

I largely agree with that (modulo engineering standards being high for
things that go in). The key point here is that most of the people who
want minimality also have the skills to read the documentation and pass
suitable arguments at the right places to get that minimality.

Donal.

Re: [TCLCORE] Question about components of Tcl/Tk8.6

[Robert S. <rhs...@gm...>]

On Wed, Apr 29, 2009 at 12:10 AM, Donal K. Fellows <
don...@ma...> wrote:

> Larry McVoy wrote:
> > Personally, I would love to see more stuff in the core.  Instead of
> putting
> > the burden on end users to drag stuff in they need, put the burden on the
> > people who want small to toss stuff out.
>
> I largely agree with that (modulo engineering standards being high for
> things that go in). The key point here is that most of the people who
> want minimality also have the skills to read the documentation and pass
> suitable arguments at the right places to get that minimality.
>
> Donal.
>

I think that's the key point to keep in mind:

   - A large number of people that want all the bells and whistles ("it just
   works") don't have the knowledge or experience to go get all the individual
   pieces.
   - A large number of people that want the stripped down version are
   perfectly comfortable stripping out the parts they don't need, as long as
   how to do it is relatively well documented and "built into the system" (ie,
   make/configure options).


Robert Seeger

Re: [TCLCORE] Question about components of Tcl/Tk8.6

[Jeff H. <je...@ac...>]

On 28/04/2009 8:19 AM, Larry McVoy wrote:
>>>> Thus please don't add any extensions (except PNG in Tk) in standard Tcl package.
>>> That comment made me laugh.  Every Tcl'er has the same prescription.
>>> Tcl/Tk should come with the goodies I need, and none of that other crap.
>> Yes, and someone else will say "I don't need Tk, just give me OO 
>> finally!", or similar.  The final line contradicts the argument of the 
>> entire email.
> 
> Personally, I would love to see more stuff in the core.  Instead of putting
> the burden on end users to drag stuff in they need, put the burden on the
> people who want small to toss stuff out.
> 
> The hard part is getting agreement on what should go in.  zlib and png
> are great examples of stuff that finally made it but should have made
> it long ago.  Bwidgets is a great example of something that should not
> be in the core, it's essentially dead from what I can tell, which is a
> bummer but putting dead code into the core seems bad.  Perhaps one of 
> the tests for inclusion is "are you willing, or do you have someone who
> is willing, to maintain this for at least the next 3 years?"  If the
> answer is no, well, I guess you don't care enough.

Note that BWidgets is not a core candidate for exactly the question you 
stated above.  Instead we are looking at alternative megawidget 
solutions that contain much better frameworks and will be much easier to 
maintain for years to come.

> I'd be willing to dedicate some of our resources on trying to shepherd 
> stuff into tk if that helps.

That's always welcome.  My laundry list for Tk isn't getting shorter, 
and it's all good stuff.

Jeff

Re: [TCLCORE] Question about components of Tcl/Tk8.6

[<lm...@bi...>]

> >> Thus please don't add any extensions (except PNG in Tk) in standard Tcl package.
> > 
> > That comment made me laugh.  Every Tcl'er has the same prescription.
> > Tcl/Tk should come with the goodies I need, and none of that other crap.
> 
> Yes, and someone else will say "I don't need Tk, just give me OO 
> finally!", or similar.  The final line contradicts the argument of the 
> entire email.

Personally, I would love to see more stuff in the core.  Instead of putting
the burden on end users to drag stuff in they need, put the burden on the
people who want small to toss stuff out.

The hard part is getting agreement on what should go in.  zlib and png
are great examples of stuff that finally made it but should have made
it long ago.  Bwidgets is a great example of something that should not
be in the core, it's essentially dead from what I can tell, which is a
bummer but putting dead code into the core seems bad.  Perhaps one of 
the tests for inclusion is "are you willing, or do you have someone who
is willing, to maintain this for at least the next 3 years?"  If the
answer is no, well, I guess you don't care enough.

I'd be willing to dedicate some of our resources on trying to shepard 
stuff into tk if that helps.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [TCLCORE] Question about components of Tcl/Tk8.6

[Paul A. <pau...@gm...>]

You could get the best of both worlds if the bells and whistles were
packaged with the core distribution but only loaded on demand (transparently
would be best). The rare case where are truly small system on disk is needed
would be easy to create by deleting the loadable parts.

On Wed, Apr 29, 2009 at 9:34 AM, Robert Seeger <rhs...@gm...> wrote:

>
> I think that's the key point to keep in mind:
>
>    - A large number of people that want all the bells and whistles ("it
>    just works") don't have the knowledge or experience to go get all the
>    individual pieces.
>    - A large number of people that want the stripped down version are
>    perfectly comfortable stripping out the parts they don't need, as long as
>    how to do it is relatively well documented and "built into the system" (ie,
>    make/configure options).
>
>

Re: [TCLCORE] Question about components of Tcl/Tk8.6

[Jordan H. <jor...@ya...>]

On Wednesday 29 April 2009, Paul Alfille wrote:
> You could get the best of both worlds if the bells and whistles were
> packaged with the core distribution but only loaded on demand
> (transparently would be best). The rare case where are truly small system
> on disk is needed would be easy to create by deleting the loadable parts.
My 2 cents, as a long time user of TCL/TK, would be to include everything in the standard as it is 
done today.  Most people will want, unknowingly, the distribution to be like this.  However, people 
who work on embedded systems, can download the source, albeit large, and configure it to something 
smaller.

I work, on a regular basis, on embedded systems where I need only the minimal core, as well as 
server and end-user applications where the full suite is needed.  I like the idea, like Active 
State's configuration, of just installing the full suite on the servers and end-users 
configuration.

For the embedded systems configuration, I have to compile and configure many other parts, only one 
of which is TCL/TK.  For me, this is not a problem and rather expected. Many of the tools I use on 
the embedded platforms need configuration.

Thanks,
Jordan Henderson


>
> On Wed, Apr 29, 2009 at 9:34 AM, Robert Seeger <rhs...@gm...> wrote:
> > I think that's the key point to keep in mind:
> >
> >    - A large number of people that want all the bells and whistles ("it
> >    just works") don't have the knowledge or experience to go get all the
> >    individual pieces.
> >    - A large number of people that want the stripped down version are
> >    perfectly comfortable stripping out the parts they don't need, as long
> > as how to do it is relatively well documented and "built into the system"
> > (ie, make/configure options).

Re: [TCLCORE] Question about components of Tcl/Tk8.6

[Kevin W. <kw...@co...>]

> 
> Note that BWidgets is not a core candidate for exactly the question you 
> stated above.  Instead we are looking at alternative megawidget 
> solutions that contain much better frameworks and will be much easier to 
> maintain for years to come.

Out of curiosity, what frameworks are these?

BWidgets is a real mixed bag. How a package that is so comprehensively 
documented can nonetheless be so hard to learn is a bit of a mystery to 
me. And parts of it are definitely long in tooth and have been 
superseded by other, more recent widgets (panedwindow, combobox in ttk, 
etc.).

Still, I find parts of BWidgets indispensible, in terms of their 
flexibility and relative. I make heavy use of the Tree widget in my 
apps, and the ListBox widget is also slated for inclusion in an app or 
two I'm developing. Once I "got" how these widgets worked, I found them 
to be very powerful and perfect for my needs. Last I looked, the new 
tree/table widget in ttk wasn't as flexible. Also, BWidgets' 
drag-and-drop support remains the best script-level package for this 
kind of functionality (hard to grok, but more powerful than the basic 
drag-and-drop package I developed).

Of couse, if there is a better, more comprehensive megawidget framework 
than BWidgets out there, I'd be glad to see it.

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [TCLCORE] Question about components of Tcl/Tk8.6

[Jeff H. <je...@ac...>]

On 29/04/2009 3:34 PM, Kevin Walzer wrote:
>> Note that BWidgets is not a core candidate for exactly the question 
>> you stated above.  Instead we are looking at alternative megawidget 
>> solutions that contain much better frameworks and will be much easier 
>> to maintain for years to come.
> 
> Out of curiosity, what frameworks are these?

*secret* frameworks.

> BWidgets is a real mixed bag. How a package that is so comprehensively 
> documented can nonetheless be so hard to learn is a bit of a mystery to 
> me. And parts of it are definitely long in tooth and have been 
> superseded by other, more recent widgets (panedwindow, combobox in ttk, 
> etc.).
> 
> Still, I find parts of BWidgets indispensible, in terms of their 
> flexibility and relative. I make heavy use of the Tree widget in my 
> apps, and the ListBox widget is also slated for inclusion in an app or 
> two I'm developing. Once I "got" how these widgets worked, I found them 
> to be very powerful and perfect for my needs. Last I looked, the new 
> tree/table widget in ttk wasn't as flexible. Also, BWidgets' 
> drag-and-drop support remains the best script-level package for this 
> kind of functionality (hard to grok, but more powerful than the basic 
> drag-and-drop package I developed).

Does that mean you are stepping up to maintain it for the next 3 years? 
  Because nobody else is doing so, and I'd be happy to reassign all the 
open bugs.

> Of couse, if there is a better, more comprehensive megawidget framework 
> than BWidgets out there, I'd be glad to see it.

better != more comprehensive IMO.  Iwidgets is more comprehensive than 
BWidgets, but while some still use it, more would be advised to stay far 
away.  I want a framework that espouses the current nature of Tcl, using 
the latest features, and that is _very_ easy to develop for and maintain.

Jeff

Re: [TCLCORE] Question about components of Tcl/Tk8.6

[Damon C. <da...@tc...>]

>
> BWidgets is a real mixed bag. How a package that is so comprehensively
> documented can nonetheless be so hard to learn is a bit of a mystery  
> to
> me. And parts of it are definitely long in tooth and have been
> superseded by other, more recent widgets (panedwindow, combobox in  
> ttk,
> etc.).
>
> Still, I find parts of BWidgets indispensible, in terms of their
> flexibility and relative. I make heavy use of the Tree widget in my
> apps, and the ListBox widget is also slated for inclusion in an app or
> two I'm developing. Once I "got" how these widgets worked, I found  
> them
> to be very powerful and perfect for my needs. Last I looked, the new
> tree/table widget in ttk wasn't as flexible. Also, BWidgets'
> drag-and-drop support remains the best script-level package for this
> kind of functionality (hard to grok, but more powerful than the basic
> drag-and-drop package I developed).
>
> Of couse, if there is a better, more comprehensive megawidget  
> framework
> than BWidgets out there, I'd be glad to see it.

You and Jeff are referring to two different things, and I agree with  
both of you. 0-]

You are referring to the BWdiget API, which I believe is quite good.   
It's very easy to learn, it's consistent, and I use it throughout all  
of my projects and plan to continue to do so.

Jeff is referring to the underlying framework on which BWidgets is  
built.  This is a total freaking mess, and it's horrible to code in.   
It does some of the bare basic things for you in creating new widgets,  
but (as the developer) you're still expected to do a lot of things by- 
hand.  This is what Jeff means when he says that it is unmaintainable.

The documentation of the widgets is pretty complete, and I like the  
API quite a lot, but what you don't have to see is the spaghetti mess  
underneath the widgets that is very hard to program in.  This is not  
something we want to continue to put time and effort into.  Especially  
when there seems to be so little of it going around these days.

The plan we have going forward is to have a new framework in place  
that megawidgets can be built off of, and then my plan is to port the  
usable BWidgets over to the new framework.  In all likelihood, these  
won't be EXACTLY like their counterparts in terms of how they look,  
but they will most likely be totally API compatible.  The reason they  
won't look exactly the same is because I hope to build the Tree and  
ListBox widgets on top of tktreectrl and not on top of the canvas  
widget.

I like BWidgets.  I plan to use the API going forward.  But, I don't  
plan to spend a lot of time fixing bugs in it and supporting it.  It's  
throwing my precious little time down a black hole.

D