From: Donald G P. <dg...@ca...> - 2000-10-26 08:22:34
|
> Note that this is distinct from the "batteries included" (BI) > distribution, and is not intended to be a model for building > the BI distribution. On the contrary, it is precisely the problem addressed by the BI distribution -- how do we combine Tcl and a collection of useful packages in a single download. > It is a special case for inclusion in > the core tcl command set, since a "class" command is a > fundamental language construct. I don't agree with this assessment, but if I did, the natural implication is that [class] should be a built-in command in Tcl itself. That's a proposal I could understand, though disagree with. This proposal boils down to "Let's make a BI distribution that includes only one battery." That seems like a half-measure. It only makes sense, perhaps, as step 1 in the development of the full BI distribution. > ~ Alternatives > > Include [[incr Tcl]] in a "batteries included" (BI) distribution. > > Many people will not opt for the BI distribution ''(need a TIP > reference here when that's been tipped correctly)'' due to its larger > size. If that is the case, then the BI distribution will be a failure. The whole point of a BI distribution is to enable application writers to distribute their Tcl-based apps that rely on third-party packages already being installed, without having to include the third-party packages in their distribution, or having to send their users all over the Net to assemble a suitable environment of Tcl packages for their app. This will only be the case if when most people go to get "Tcl", or find "Tcl" pre-installed with their OS, what they know as "Tcl" is really the BI distribution. Since I have confidence the BI distribution will succeed, I believe this alternative is the correct one. Rather than propose this new TIP, let's help George make progress on TIP 4. If we want to make the first release of the BI distribution include only Tcl and Itcl, that's OK with me, but let's not stop there. DGP -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Donald G P. <dg...@ca...> - 2000-10-26 17:33:57
|
> Title: Include [Incr Tcl] in the Core Tcl distribution > [[incr Tcl]] shall be included in the core Tcl distribution. It shall > be included in the Tcl source tree, and built as part of the standard > Tcl distribution. It shall remain a dynamically loaded extension, > accessible via "package require" and "namespace import". Okay, I slept on it and I think I can offer a more cooperative spirit today. There's always been a place in my vision of Tcl's future for a Tcl+Itcl distribution. I just see it as a step toward the full BI distribution, and later as a subset of the full BI. (Imagine a web site where one assembles her own BI a la carte...) So, I'm not opposed to creating such a distribution, and I think efforts toward it will help support the BI project. Perhaps having two TIPs that describe the same basic effort from two perspectives will attract more hands to make that effort. That said, here's what I want and don't want: I want this Tcl+Itcl distribution project and the BI project to solve the problem of how we combine Itcl and Tcl in one distribution the same way. When both projects are complete, I want Tcl+Itcl to look like a subset of BI. I want Itcl to remain a separate package. That is, a [package require Itcl] will be necessary in any script using Itcl commands. I don't want TCT to take on responsibility for Itcl development. I don't want Tcl and Itcl to be forced into a "lockstep" release calendar. (Separate development teams imply separate release calendars) I still want to be able to download a distribution which contains only Tcl. Friends? DGP -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Karl L. <ka...@ne...> - 2000-10-26 18:08:06
|
Interesting. I was thinking yah yah it should be integrated and you should have to do a package require to get itcl. But now I'm wondering. As long as you have to do a package require, some number of people will continually holler that Tcl doesn't have an object system in the core, etc., etc. I think it could be really cool to have "class" show up automatically as a top level command in tclsh and wish. It wouldn't be hard to implement, like you could do a "package require Itcl" and namespace import in the startup script. You wouldn't have to merge the code trees or anything like that. And if you really didn't want it, I guess we could add a "--disable-itcl" or "--disable-automatic-itcl" or something. By the way, I use Itcl a lot. Karl -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: D. R. H. <dr...@hw...> - 2000-10-26 19:52:15
|
Karl Lehenbauer wrote: > > [P]eople will continually holler that Tcl doesn't have an object > system in the core, etc., etc. Good point. I do not use Itcl, but I can see the need to have it in the core, just so "object oriented" can appear on the list of core Tcl features. The political reality is that you really need this to sell Tcl in a lot of circumstances. > > I think it could be really cool to have "class" > show up automatically as a top level command in > tclsh and wish. Perhaps something like this: proc class {args} { rename class {} package require Itcl namespace import itcl::* return [uplevel 1 "class $args"] } Or better still, perhaps we can patch up the "unknown" proc to do the "package require" at the right moment. For that matter, why not have "unknown" do a "package require" for any unknown command in a namespace. So if I do this: blt::graph .g and BLT is not loaded, the "unknown" command tries a "package require Blt". -- D. Richard Hipp -- dr...@hw... -- http://www.hwaci.com/drh/ -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Mark H. <ma...@us...> - 2000-10-28 03:01:38
|
D. Richard Hipp <dr...@hw...> wrote: > Karl Lehenbauer wrote: > > > > [P]eople will continually holler that Tcl doesn't have an object > > system in the core, etc., etc. > > Good point. I do not use Itcl, but I can see the need to > have it in the core, just so "object oriented" can appear > on the list of core Tcl features. The political reality > is that you really need this to sell Tcl in a lot of > circumstances. That's right. I'm sick of having to do the defensive thing... "Well, Tcl really does have objects, John Ousterhout really doesn't hate objects as much as he seems to, blah blah." I want to take the offensive. I want to put proponents of other languages on the defensive regarding their second-rate object systems. Itcl has a better object model than both perl and python. A strong case can be make in clear terms to demonstrate this. Let's move the battleground over to their side of the fence for a while. Mark -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: George H. <ga...@bl...> - 2000-10-26 17:51:18
|
In message <02bc01c03f1f$5a3913c0$070...@sw...>, "Mark Harrison" wr ites: : Donald G Porter <dg...@ca...> wrote: : > I don't agree with this assessment, but if I did, the natural : > implication is that [class] should be a built-in command in Tcl : > itself. That's a proposal I could understand, though disagree : > with. : : Since [incr Tcl] is basically "class" with supporting functionality, : that's what this proposal is. Note this is not discussing [incr Tk] : or [incr Widgets]. : : I don't want to repeat the tedious clt discussions earler this year, : but do you have an alternative proposal to create Tcl-level data : structures? Or perhaps Tcl-level data structures are unnecessary? : : > This will only be the case if when most people go to get "Tcl", or : > find "Tcl" pre-installed with their OS, what they know as "Tcl" is : > really the BI distribution. : : I think there will always be a distinction between the "standard" : tcl distribution and the BI tcl distribution. Otherwise, the BI : distribution just means "put everything in the core". If the "Batteries Included" release is a good idea, then so is this one. It incorporates the same goals, just on a smaller scale. I see this proposal as complementary --not overlapping--, the "Batteries Included" distribution. The experience and lessons of implementing this proposal will be extremely valuable to the all-in-one distribution. This proposal has the benefit of being able to focus on a smaller problem, so their solutions may be very helpful in building larger distributions. I also see this team working with (not against) me on the myrriads of small and important details that crop up. I've have visited and worked for many companies that did not use Tcl, (but rather Python) just because of the perceived lack of object oriented programming in Tcl. If you ask yourself why Python has seemingly surpassed Tcl in popularity, this is point one. We may not see OO as a deal-breaker, but it is for many people. Point two is that Tcl lacks decent Tcl-based libraries. Python on the other hand, has lots of library code written in Python. That's simply because it's easier to write and package code as classes than a groups of related procedures and global variables. I firmly predict that adding [incr Tcl] will open the flood gates to user-contributed Tcl libraries. I myself have tons of plotting-related [incr Tcl] classes that I don't distribute because I can't rely on people having [incr Tcl]. This biggest point is that Mark's proposal doesn't adversely affect any Tcl users. [incr Tcl] is very small and will only be included as a package. This adds neither bulk nor changes how anyone using Tcl right now works. So how is any of this a loss? I don't know how can one be for a "Batteries Included" distribution but against this? --gah -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Mo D. <md...@cy...> - 2000-10-26 17:16:44
|
On Thu, 26 Oct 2000, George Howlett wrote: > If the "Batteries Included" release is a good idea, then so is this > one. It incorporates the same goals, just on a smaller scale. Well, one could argue that Tcl+Tk is the BI on a smaller scale. The smaller scale did not help in that case, it just lead to shortcuts like wish instead of tclsh + "package require Tk". > I've have visited and worked for many companies that did not use Tcl, > (but rather Python) just because of the perceived lack of object > oriented programming in Tcl. If you ask yourself why Python has > seemingly surpassed Tcl in popularity, this is point one. We may not > see OO as a deal-breaker, but it is for many people. Very true. I would love to see (or perhaps even write) a "Tcl 2000" article about all the cool stuff that is available "by default" in Tcl (the BI version). > Point two is that Tcl lacks decent Tcl-based libraries. Python on the > other hand, has lots of library code written in Python. That's simply > because it's easier to write and package code as classes than a groups > of related procedures and global variables. I firmly predict that > adding [incr Tcl] will open the flood gates to user-contributed Tcl > libraries. I myself have tons of plotting-related [incr Tcl] classes > that I don't distribute because I can't rely on people having [incr > Tcl]. We should not open the flood gates without the BI in place. Otherwise, we may be washed away. If we suddenly have all sorts of packages but no solution to the distrobution problem, we are just as screwed. > This biggest point is that Mark's proposal doesn't adversely affect > any Tcl users. [incr Tcl] is very small and will only be included as > a package. This adds neither bulk nor changes how anyone using Tcl > right now works. I frankly don't give a rats ass about these "I don't want no OO in my Tcl" folks. They can just download Tcl and build it off by itself if they want a version with no frills. Mo DeJong Red Hat Inc -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Dan K. <ku...@aj...> - 2000-10-26 16:19:33
|
> If the "Batteries Included" release is a good idea, then so is this > one. It incorporates the same goals, just on a smaller scale. We are in total disagreement here. One proposal is a different *distribution* mechanism (which also might require a build environment). Moving itcl into the core means that the source would live in the tcl source base and it would *always* be distributed as part of tcl. There would be no distribution of tcl with itcl (there is even a distribution of tcl without tk and I would argue that tk is *much* more widely used than itcl) > This biggest point is that Mark's proposal doesn't adversely affect > any Tcl users. [incr Tcl] is very small and will only be included as > a package. This adds neither bulk nor changes how anyone using Tcl > right now works. Would you be equally supportive if I offered to move tk and the thread package into the tcl core (as a package)? What about BLT, tclxml, or vu? Where is the line drawn? What packages get moved into tcl's source base and are managed as part of the tcl project, and what ones stand on their own and are distributed as part of the batteries included package? > This biggest point is that Mark's proposal doesn't adversely affect > any Tcl users. [incr Tcl] is very small and will only be included as > a package. This adds neither bulk nor changes how anyone using Tcl > right now works. find itcl -name \*.c -o -name \*.h | xargs wc -l 227 itcl/mac/tclMacAppInit.c 172 itcl/generic/itcl.h 263 itcl/generic/itclDecls.h 264 itcl/generic/itclInt.h 1048 itcl/generic/itclIntDecls.h 185 itcl/generic/itclStubInit.c 83 itcl/generic/itclStubLib.c 1699 itcl/generic/itcl_bicmds.c 1782 itcl/generic/itcl_class.c 1424 itcl/generic/itcl_cmds.c 2239 itcl/generic/itcl_ensemble.c 327 itcl/generic/itcl_linkage.c 2522 itcl/generic/itcl_methods.c 139 itcl/generic/itcl_migrate.c 1206 itcl/generic/itcl_objects.c 1953 itcl/generic/itcl_obsolete.c 1076 itcl/generic/itcl_parse.c 1383 itcl/generic/itcl_util.c 157 itcl/unix/tclAppInit.c 38 itcl/win/dllEntryPoint.c 280 itcl/win/tclAppInit.c 18467 total This is approximately 10-11% of the size of the current tcl C source code base (from my estimations, correct me if I am wrong). I wouldn't say that is a small change as this code will become part of the tcl source base under the proposal and will be maintained as part of the core. --Dan -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Mo D. <md...@cy...> - 2000-10-26 17:02:03
|
On Thu, 26 Oct 2000, Dan Kuchler wrote: > > > If the "Batteries Included" release is a good idea, then so is this > > one. It incorporates the same goals, just on a smaller scale. > > We are in total disagreement here. One proposal is a different > *distribution* mechanism (which also might require a build > environment). Moving itcl into the core means that the source > would live in the tcl source base and it would *always* be > distributed as part of tcl. There would be no distribution > of tcl with itcl (there is even a distribution of tcl without > tk and I would argue that tk is *much* more widely used than > itcl) Well, I don't think we are talking about putting Itcl code into the same src tree as Tcl. Just making it an avilable package. ... > Would you be equally supportive if I offered to move tk and the > thread package into the tcl core (as a package)? > > What about BLT, tclxml, or vu? > > Where is the line drawn? What packages get moved into tcl's > source base and are managed as part of the tcl project, and > what ones stand on their own and are distributed as part of > the batteries included package? This is a very good point. I for one don't see that we can draw the line at just Itcl. What about the Thread package? I would really like to be able to do a "package require Thread" in "the core". Of course, when I say "the core" I really mean the BI distro or whatever it is currently called. Perhaps what we need to do is draw a line and define some terms. What if we defined the "Tcl core" as something other than "just Tcl"? Tcl Core - Tcl - Itcl - Thread - Tk ??? - ?? Perhaps these are the "required batteries" in the BI distro. You can add more, but these would be the ones that always get included. Frankly, I don't think making a release with Tcl + Itcl is going to help with the BI release. In fact, I think it would just hurt it. Then there would be the same old, I can depend on package X because it is in the BI distro crap all over again. Also, it would help to define out audience here. We are talking about those developers that want to download the "latest and greatest" and see what can be done. We are also talking about distro providers. I know Red Hat is going to want to break up Tcl and Tk into two RPMS. On the other hand, I am not so sure they would want to break up a Tclcore.rpm into a bunch of little packages for each. There are also application providers to think about. We (Red Hat) have our own build for Tcl + Tk + Itcl + Tix + bunch of other stuff. We need a good "batteries included" policy so that we don't have to create our own. So my point is that I think we should forget about "putting Itcl in the core" and focus on getting a working BI process in place for the next release. I would rather have a "minimal BI", I think that would actually solve all of the problems we know about without introducing new ones. Heck if we are going to add Itcl to the core (with a global class command), we really should just call it Tcl 9.0 and be done with it. Mo DeJong Red Hat Inc -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Brent W. <we...@aj...> - 2000-10-26 19:29:43
|
>>>Mo DeJong said: > Perhaps what we need to do is draw a line and define some > terms. What if we defined the "Tcl core" as something > other than "just Tcl"? > > Tcl Core > - Tcl > - Itcl > - Thread > - Tk ??? > - ?? > > Perhaps these are the "required batteries" in the BI distro. > You can add more, but these would be the ones that always > get included. Frankly, I don't think making a release > with Tcl + Itcl is going to help with the BI release. > In fact, I think it would just hurt it. Then there > would be the same old, I can depend on package X because > it is in the BI distro crap all over again. Today we have the "Tcl Core" as src/tcl8.3.2 or whatever, not including anything else. I'd like to retain that definition. It excludes Tk. In includes a few things that perhps it shouldn't (http.tcl comes to mind). Today we have "The Standard Tcl Library" which this group hasn't focused on. I think we need to nourish this effort as well. There are two camps. One believes it should be "pure Tcl", and the other that thinks you can only do it well with an OO framework. I am of both minds at different times. Today I have a "TclHttpd bundled distribution" that includes: Tcl 8.3.2 Tcllib 0.7 Thread 2.1 TclHttpd 3.2 TclHttpd (the web server) can run without Thread, and it can run with a variety of Tcl versions, but with the 3.* release I made it dependent on Tcllib. When I release TclHttpd, I release both the "core" and the "bundle". I think this is what we should do for Tcl. I have a home-brew "make distribution" script, and a top-level Makefile that builds and installs everything. Please check out ftp://ftp.scriptics.com/put/tcl/httpd/tclhttpd3.2-dist.tar.gz I think we should create a new SF Project, tclsdk, sooner rather than later, and we should experiment with creating distributions. We can lift the build environment from TclPro to use as a starting point - it knows how to drive the compilation of Tea-compliant Tcl extensions. I'd like to see some action at this point, more than I'd like to hear the discussion about "including [incr Tcl] in the core". Actions speak louder than words. If we start making 8.4 releases that have both a straight core, plus a bundle (as I'm doing already with TclHttpd) that includes: Tk incr Tcl expect TclX TkCon Thread tktable Tcllib blt then the Tcl community will jump for joy. I'd really like to see this happen. Who would like to help out by being a member of the "tclsk" SF project? Or, should I just make it another module under the "tcl" project? -- Brent Welch <we...@aj...> http://www.ajubasolutions.com Scriptics changes to Ajuba Solutions scriptics.com => ajubasolutions.com -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: John O. <ou...@aj...> - 2000-10-27 04:41:23
|
At 12:29 PM 10/26/2000 -0700, Brent Welch wrote: >.... >Who would like to help out by being a member of the "tclsk" SF project? >Or, should I just make it another module under the "tcl" project? No!! The SDK or "Batteries Included" release is a great idea, but it shouldn't be a module under the "tcl" project. It should be a totally separate project. In fact, it should have its own team, distinct from the TCT (though I suspect several people will be on both teams). -John- ________________________________________________________________________ John Ousterhout 650-210-0102 tel Chairman and Chief Technology Officer 650-230-4070 fax Ajuba Solutions ou...@aj... http://www.ajubasolutions.com -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Brent W. <we...@aj...> - 2000-10-26 19:46:25
|
>>>Brent Welch said: > Please check out > ftp://ftp.scriptics.com/put/tcl/httpd/tclhttpd3.2-dist.tar.gz Gack - that is ftp://ftp.scriptics.com/pub/tcl/httpd/tclhttpd3.2-dist.tar.gz of course, as well as http://download.sourceforge.net/tclhttpd/tclhttpd3.2-dist.tar.gz -- Brent Welch <we...@aj...> http://www.ajubasolutions.com Scriptics changes to Ajuba Solutions scriptics.com => ajubasolutions.com -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Mark H. <ma...@us...> - 2000-10-28 03:07:59
|
Mo DeJong <md...@cy...> wrote: > Perhaps what we need to do is draw a line and define some > terms. What if we defined the "Tcl core" as something > other than "just Tcl"? Good point. If I were to break it down as you describe, I would make it something like: Tcl: tcl (core) tcl (commands) itcl tcllib Tk: (because I want to have a pure non-gui tcl thing) tk (core) tk (widgets) ??? > Heck if we are going to add Itcl to > the core (with a global class command), > we really should just call it Tcl 9.0 > and be done with it. By John's numbering scheme, it doesn't break backwards compatibility, so no need to bump the major number. But maybe we could skip version 9 and call it TclX. (that's a joke, btw) Mark. -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Jim I. <ji...@ap...> - 2000-10-26 18:48:21
|
Dan, I think that Itcl is fundamentally different from all the other packages you mentioned (and from most others with the exception of the other OO packages). The main argument of Mark's TIP, to me at least, is that Itcl or something like it is a necessary precondition for a really good set of Tcl code libraries. We really have to agree on some kind of object based system to write useful libraries. This is pretty clear from experience. Now, if everyone hacks up their own OO or simpler object based systems then we will not be able to generate a consistent set of Tcl libraries with common design principles, etc... And as the debate over the TclLib earlier on c.l.t showed pretty clearly, using Itcl produced faster and MUCH more readable code than hand crafted systems using upvar, arrays, and namespaces. So this TIP should really be viewed as a necessary enabler to producing a consistent, elegant and maintainable set of Tcl code libraries for Tcl. As such, the inclusion of Itcl is very different from the inclusion of BLT, tclxml, etc, etc... This is a separate issue from the Tcl BI distribution. If Itcl is going to be the bedrock for the Tcl code libraries, then it really should ALWAYS be available, and we should know immediately when we break it by modifications to Tcl. Jim On Thursday, October 26, 2000, at 09:19 AM, Dan Kuchler wrote: > Would you be equally supportive if I offered to move tk and the > thread package into the tcl core (as a package)? > > What about BLT, tclxml, or vu? > > Where is the line drawn? What packages get moved into tcl's > source base and are managed as part of the tcl project, and > what ones stand on their own and are distributed as part of > the batteries included package? -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Eric M. <er...@aj...> - 2000-10-26 18:57:59
|
On Thu, 26 Oct 2000, Jim Ingham wrote: > Tcl libraries with common design principles, etc... And as the debate > over the TclLib earlier on c.l.t showed pretty clearly, using Itcl > produced faster and MUCH more readable code than hand crafted systems > using upvar, arrays, and namespaces. No, that discussion did _not_ show that Itcl produced faster code. The metrics and benchmarks that Mark used were biased in favor of the Itcl implementations, as I stated and demonstrated repeatedly at the time of the discussion. I concede that the Itcl code was more readable than the alternative. Eric Melski The Other Tcl Guy ericm at ajubasolutions.com Ajuba Solutions -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Mo D. <md...@cy...> - 2000-10-26 19:01:14
|
> > Tcl libraries with common design principles, etc... And as the debate > > over the TclLib earlier on c.l.t showed pretty clearly, using Itcl > > produced faster and MUCH more readable code than hand crafted systems > > using upvar, arrays, and namespaces. > > No, that discussion did _not_ show that Itcl produced faster code. The > metrics and benchmarks that Mark used were biased in favor of the Itcl > implementations, as I stated and demonstrated repeatedly at the time of > the discussion. As long as the two implementations were close to each other in terms of speed, it really would not matter. > I concede that the Itcl code was more readable than the alternative. This is the key factor. Speed can always be improved. Mo DeJong Red Hat Inc -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Jim I. <ji...@ap...> - 2000-10-26 19:15:42
|
Eric, > > > Tcl libraries with common design principles, etc... And as the debate > > over the TclLib earlier on c.l.t showed pretty clearly, using Itcl > > produced faster and MUCH more readable code than hand crafted systems > > using upvar, arrays, and namespaces. > > No, that discussion did _not_ show that Itcl produced faster code. The > metrics and benchmarks that Mark used were biased in favor of the Itcl > implementations, as I stated and demonstrated repeatedly at the time of > the discussion. > Sorry, I guess I didn't follow this discussion to the bitter end. Bad net-boy! No DSL... But I agree with Mo, as long as they were comperable, then this is a wash. > I concede that the Itcl code was more readable than the alternative. And I agree with Mo, this is the main point. Jim -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Mark H. <ma...@us...> - 2000-10-27 16:52:22
|
Eric Melski <er...@aj...> wrote: > I concede that the Itcl code was more readable than the alternative. Thank you. This is the most important point of the discussion. > No, that discussion did _not_ show that Itcl produced faster code. It showed that the obvious itcl solution (class data) was about 20x faster than the tcllib solution (get/set functions) and did not exhibit the quadratic runtime behavior. The reasons for this should be obvious, since itcl data access is identical to "normal" tcl data access, which was greatly optimized with the compiler. Any implementation that uses arrays in namespaces is going to pay a performance penalty on name lookup. Any implementation that uses get/set procs and array storage loses the benefits of the compiler with regards to data access. > The > metrics and benchmarks that Mark used were biased in favor of the Itcl > implementations, as I stated and demonstrated repeatedly at the time of > the discussion. My observation was "appending elements to a list is slow", which you got around by claiming "your benchmark doesn't need to append to lists". Note that my origina response was regarding the quote "However, you're guaranteeing it will be slower if you base it on itcl...." >From my original message in April: > 3. Performance suffers > > Some ADTs, such as trees, need to have data associated > with them. The current method is to have "get" and > "set" methods for each of the data types: > > tree t > t set root -key name "Mark" > puts [t get root -key name] > > Unfortunately, this kills a lot of the speed improvement > introduced to Tcl over the past several revisions. Some > simple timing tests I've done, consisting of appending > elements to a list: > > N plain incr tcllib > 1000 15552 15645 835529 > 2000 28475 30526 1936207 > 3000 43242 45564 3013813 > 4000 54734 60202 5957176 > 5000 356977 85017 8348434 > 6000 89041 100088 10148768 > > plain: a simple for loop, "lappend mylist $i" (control) > incr: itcl class, "lappend mylist $i", mylist is a class var. > tcllib: tree, using "get, lappend, set", as above -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Eric M. <er...@aj...> - 2000-10-27 02:06:36
|
Mark -- I really don't care to rehash the tcllib versus itcllib debate. I think your tests were biased, you think they weren't. That's fine. Either way, I don't think that has any significant bearing on the discussion at hand: should itcl go in the core. Let's try to keep this discussion on track. Eric Melski The Other Tcl Guy ericm at ajubasolutions.com Ajuba Solutions -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Mark H. <ma...@us...> - 2000-10-27 17:39:06
|
Eric Melski <er...@aj...> wrote: > I don't think that has any significant bearing on the discussion at hand: > should itcl go in the core. Let's try to keep this discussion on track. For too many years, people have repeated the (incorrect) "itcl is slow" mantra until it has become common wisdom for many people, and a reason for opposing itcl. Note the verbatim quote which kicked off that entire thread: "However, you're guaranteeing it will be slower if you base it on itcl...." I want to make very clear that the itcl data abstraction mechanism (class variables) is faster than the equivalent "pure" tcl data abstraction mechanism (a combination of global arrays, upvar, and namespaces). -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Eric M. <er...@aj...> - 2000-10-27 05:36:36
|
On Fri, 27 Oct 2000, Mark Harrison wrote: > I want to make very clear that the itcl data abstraction mechanism > (class variables) is faster than the equivalent "pure" tcl data > abstraction mechanism (a combination of global arrays, upvar, and > namespaces). That's fine. I concur that itcl class variables are a bit faster than the equivalent pure Tcl constructs, due to the use of compiled local variables. However, that does not account for the orders of magnitude better speed you showed in your benchmarks using itcl. The fact is that your benchmarks were biased in favor of the itcl classes you created. Your itcl tree had a different interface, which allowed it to do a particular operation (lappend) faster than the tcllib tree. This had very little to do with itcl's use of compiled locals, and very much to do with the way that you set up a pathologically bad used of the tcllib tree. You compared an itcl tree with an lappend member operation to the tcllib tree with no such operation. Of course the tcllib tree came out significantly behind. But you failed to note that we could just as easily have made an lappend member operation for the tcllib tree too, and avoided the extraneous memory copying that your benchmark was incurring. If you like, I will write up the code to test this, or better, you could do it yourself and post the results here. I expect that the tcllib tree will still be a titch slower, but not the orders of magnitude that you showed in your benchmarks. Maybe you could post your benchmark code again here, so that the rest of the TCT can evaluate the benchmarks themselves, and need not listen to us bicker over their validity. Thanks, Eric Melski The Other Tcl Guy ericm at ajubasolutions.com Ajuba Solutions -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Mark H. <ma...@us...> - 2000-10-27 21:19:42
|
Eric Melski <er...@aj...> wrote: > On Fri, 27 Oct 2000, Mark Harrison wrote: > > > I want to make very clear that the itcl data abstraction mechanism > > (class variables) is faster than the equivalent "pure" tcl data > > abstraction mechanism (a combination of global arrays, upvar, and > > namespaces). > > That's fine. I concur that itcl class variables are a bit faster than > the equivalent pure Tcl constructs, due to the use of compiled local > variables. OK, then I think we're cool. > Your > itcl tree had a different interface, which allowed it to do a particular > operation (lappend) faster than the tcllib tree. Sure, that's true... but I noticed the problem when my original application was doing the same thing: traversing a tree and lappending data to the list. From a design standpoint, the "natural" itcl thing (member data) is a bit better than the "natural" pure thing (get/set procs) in terms of optimization. Additionally, the application was delegated responsibility for managing application-level data, rather than having to provide this a priori in the base library code. > But you failed to note that we could just as easily have made an > lappend member operation for the tcllib tree too, and avoided the > extraneous memory copying that your benchmark was incurring. True, but this was a standard library component. I didn't want to make a patched version just for my application. > If you like, I will write up the code to test this, or better, you could > do it yourself and post the results here. I expect that the tcllib tree > will still be a titch slower, but not the orders of magnitude that you > showed in your benchmarks. With the addition of an lappend method, I agree. > Maybe you could post your benchmark code again here, so that the rest of > the TCT can evaluate the benchmarks themselves, and need not listen to us > bicker over their validity. If I recall correctly, everything is still at http://www.markharrison.net/tcllib/ I added some graphviz generation functions to my own copy recently. Cheers, Mark. -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Eric M. <er...@aj...> - 2000-10-27 06:37:27
|
On Fri, 27 Oct 2000, Mark Harrison wrote: > data to the list. From a design standpoint, the "natural" itcl > thing (member data) is a bit better than the "natural" pure thing > (get/set procs) in terms of optimization. This statement compares apples to oranges. On the one hand, you are talking about how the data is stored; on the other, how it is accessed. You can't compare the two "things" that you describe here the way that you are trying to. It's like saying "Application A stores its data in arrays, but Application B has a command line interface; therefore application A is faster." It just doesn't make sense. You can say that the "natural" way to store member data in itcl (that is, class variables) provides, in general, better performance than the "natural" way to store member data in pure tcl (that is, upvar, et al.), but this has nothing to do with the fact that the tcllib tree used a get/set paradigm. I think that we are in agreement then on these points: 1. Itcl's class data is somewhat faster than the equivalent mechanisms in pure tcl 2. Your itcllib vs tcllib benchmarks were not a fair demonstration of point 1 because the things benchmarked did not implement the same interface, and the performance difference caused by the different interfaces far overwhelmed the performance difference caused by point 1. > True, but this was a standard library component. I didn't want > to make a patched version just for my application. A standard library component in a library that was and is under rapid development. If it's missing something that you need, fix it. We're all in this together. Eric Melski The Other Tcl Guy ericm at ajubasolutions.com Ajuba Solutions -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Mark H. <ma...@us...> - 2000-10-27 21:49:35
|
Eric Melski <er...@aj...> wrote: > I think that we are in agreement then on these points: > > 1. Itcl's class data is somewhat faster than the equivalent mechanisms > in pure tcl > > 2. Your itcllib vs tcllib benchmarks were not a fair demonstration of > point 1 because the things benchmarked did not implement the same > interface, and the performance difference caused by the different > interfaces far overwhelmed the performance difference caused by > point 1. OK, combine this with the most important point > I concede that the Itcl code was more readable than the alternative. And I think we can call it a wrap. > A standard library component in a library that was and is under rapid > development. If it's missing something that you need, fix it. We're all > in this together. My mistake... Sorry! Onward and Upward! Mark. -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
From: Eric M. <er...@aj...> - 2000-10-27 07:12:56
|
On Fri, 27 Oct 2000, Mark Harrison wrote: > And I think we can call it a wrap. Cool. Nevertheless, I agree with those who have spoken against incorporating itcl directly into the core, for all the reasons that they have enumerated. I think that the batteries included distribution will make this a non-issue, as long as we put in the effort to make BI successful. Giving extensions special status now will seriously undermine the effectiveness of the BI idea. It will just leave us where we are now: people won't rely on an extension unless it gets pulled into the core. We have to break out of the mentality that extensions cannot be relied upon. That will take time, patience, and a good BI distribution. Eric Melski The Other Tcl Guy ericm at ajubasolutions.com Ajuba Solutions -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |