DN456529200

Subject: TEA Summit Notes - DN [1]

jeff_hobbs@my-dejanews.com - 19 Mar 1999 - comp.lang.tcl

 Here are some notes on Tcl Extension Architecture (TEA) Summit that was held
 at Scriptics on March 15/16.  For background, and those in attendance, see:
     http://www.scriptics.com/tea-summit/

 The 2 days were broken down into several sections where members of the
 Scriptics engineering staff presented background info to the current status
 of the item (ie - Configuration and Makefiles) and then moderated the
 discussion surrounding the issues.  I'll go through them topic by topic,
 covering major points and preliminary outcomes.  Each session had a set
 of slides, which Scriptics might be nice enough to post, but I won't
 otherwise elaborate (read: retype) the whole set here.

 NOTE: I am guaranteed to miss certain things, but please keep responses
 on topic.  Use "RE: <Topic Point>" when replying to KEEP THREADS DISTINCT.
 Also note that when I say I guess|think|believe|<fuzzy logic here> then
 that really means me, Jeff Hobbs, not Scriptics per se.

 ** TOPIC 1: Ouster Chat -

 John gave use a shortened version of what he normally presents at the
 Tcl conferences.  On point of interest is that Scriptics currently has
 only 4 core development engineers, that means engineers on the Tcl core,
 compared to 10-12 that were available at Sun.  Keep this in mind next
 time you complain about slow integration of new features.  Of course,
 also keep in mind that Scriptics is still hiring (they've got expansive
 new digs in Mountain View).  Scriptics is definitely in a major growth
 cycle.

 Even with the limited resources, they've managed to continue with 8.0/1
 parallel development while also creating tools like TclPro.

  * Why is their a parallel 8.0/8.1 development thread?

 This question doesn't have the simplest answer.  The core Scriptics team
 left Sun with 8.1 in a very immature state.  John initially wanted to
 focus on 8.1 and get the first TclPro out for 8.1, but realization came
 that by the time 8.1 was stable enough, Scriptics could deep-six.  So,
 8.1 was continued because it had important key new features (ie Unicode),
 but 8.0 was (is) being carried along further than originally intended
 because it is the base for TclPro.

 My guess is that when TclPro makes the move to 8.1, 8.0 will finally drop
 by the wayside.  This dual-path certainly hasn't helped alleviate the
 crunch on Scriptics limited resources.  Also, it was noted that 8.1 has so
 many core changes from 8.0 that it would have been better to call it v9.
 This is one reason stubs will be in 8.1 and not back-ported to 8.0.

 Scriptics hopes to improve items like transparency into the bug fixing
 process and communication between Scriptics and the community as a whole
 (both paying customers and open source).

 The issue of a possible Tcl Advisory Board was raised, and quickly
 scuttled.  It's usefulness was in question, especially after the flames
 that arose around the Tcl Consortium.  I feel that Scriptics was hoping
 for a moderated view into the community pathos, but it looks like they
 will just wade into the consciousness hip deep.

  * Why are we here?

 The purpose of the TEA summit arose from problems that exist in the
 extension management today.  I even got an "I told you so" in on this.  The
 Scriptics guys, who have not been keen on breaking things into packages for
 the Tcl core (ref kernel/core discussion), have finally had to deal with
 this when integration bundles into TclPro (which now bundles with incrTcl,
 TclX and Expect).  On average, it required 2 engineer man months to
 integrate an extension into TclPro cleanly.  Basically, Tcl is easy to
 extend, but with so many variations on the packaging theme, actually
 merging this together wasn't dead simple.

 TEA hopes to make it so.

 ** TOPIC 2: Stubs

 Stubs.  First, what are they?  Well, the simplest answer is that they
 provide a platform-independent backlinking mechanism.  See Duffin's
 very long commentaries on his posts for more exact semantics.

 Important aspects of stubs are that is provides forwards compatability
 through its pointer table(s), meaning no (much much less?) worries about
 future changes in C APIs.  Scriptics plans to also provide function
 stubs for 8.0 of UTF and a few other items, so extensions should be
 able to compile and run against both 8.0 and 8.1 equally.  Stubs won't
 be for everyone, but should make extensions easier for most.  The
 actual Stubs mechanism is new in 8.1b2.

 ** TOPIC 3: Makefiles and Configure

 The use of cygwin as a cross-platform solution was raised.  The Scriptics
 guys will be surveying c.l.tcl in the near future to see who would be
 willing to use it.  Basically, it means the ability to use configure and
 make equally on Unix and Windows, when one has the free cygwin tools.

 It was recommend that Scriptics supply a VC++ project file for Windows
 instead of the makefile.vc (or in addition to).  I guess Windows guys
 like this a lot more than having to resort to nmake on the command line
 (what a sad state of affairs...).

 In general, the ability to use native tools (VC++ being considered the
 "native tool" for Windows) is important, with gcc as an option.

 The basic features of the makefiles and tclConfig.sh are to change in the
 coming versions for TEA.  No more --with-tk, and --tcl-path as a search
 path for various Tcl things were recommended.  The Makefile will have
 DYNAMIC and DEBUG defines, allowing for the removal of --enable-shared
 and --enable-symbols from the configure.  The recommendation was to have
 four sub-directories:
     dynamic, dynamic-debug, static, static-debug
 with makefiles that support the right options for each in them.

 Makefiles in general should all have the following targets:
     all, man, test, dist
     install, install-binaries, install-libraries, install-man
     clean, distclean, setup (build binary dist of extension)

 The makefile default will be to use dynamic libs by default where
 supported.  tclConfig.sh will have the info for all 4 variants.  I
 recommended that tclConfig.sh was built into the tclsh tcl_platform
 variable, but that didn't fly for some reason.  I still think that the
 ability to have binaries named tclsh8.1, tclsh8.0, tclsh8.0d, etc all know
 internally the tclConfig stuff (which is only the one file) makes sense to
 me.

 The Scriptics guys also want to be able to support static builds on
 Windows.  Also, getting rid of any dependency on environment variables
 that find the init files would be nice.  In general, the tcl_findLibrary
 call should be used by extensions.

 ** TOPIC 4: Test Suites

 Test suites should actually cover source code and be maintainable.  The
 tcltest namespace and extension will be packaged with Tcl in the future.
 The area of testing is important, and Tcl can make much better headway this
 way.  There is a new doc on writing test suites in the tests subdir
 (README, it'll probably get a better location soon).  Further hints on
 all this stuff will be in TEA.

 ** TOPIC 5: Installation

 Wouldn't it be nice to just say:

     package require Expect

 and when it doesn't exist, have a dialog come back asking if you want to
 install it?  This has been used in apps like Netscape, and may become a
 reality in Tcl in the future.  Until then, the issues for TEA are to
 standardize everything down to the minutiae, so that automatic builds
 can be guaranteed.

 Also, the focus should shift to more binary distributions, with perhaps
 even a method to upload to a special site that builds the binaries for you.
 A standardized Tcl archive will be formulated in the (near) future to get
 this all kick-started.  An installer of some sort will also find its way
 into the Tcl core to support this.  More to come as the individual points
 are finalized.

 Oh, one thing - it should be assumed for extension writers that Tcl
 will be installed (and Tk for Tk extensions) already.

 ** TOPIC 6: Miscellany & Closing stuff

 It looks like XML will be the future doc format for the Tcl core and its
 extensions.  In this case, the core will provide conversion utilities for
 XML->nroff/HTML/rtf, etc as appropriate.

 One important item that Scriptics was ambushed with was printing support.
 It was noted by most extension authors to be a key issue.  Scriptics got
 the message I believe, but their expertise on and resource for this is slim
 at the moment.  Any volunteers?  It was noted that just 100% proper canvas
 printing was essential, and the text widget after that.  More than that
 would just be having the ability for Tk extension writers to access the
 necessary primitives in a cross-platform manner.

 CONCLUSION

 This is the start of a process which will take a bit to reach finalization.
 Scriptics is aware of the importance, and will be devoting core engineer
 time to realizing the issues above.  Some are already done, others are
 well-formed or out in open source, and others are still pie in the sky
 ideas.

 With coordinated community effort, especially among extension authors, it
 looks like we should be able to reach concensus on outstanding items and
 develop the Tcl Extension Architecture to the benefit of every user.  We
 need to eliminate the idea that adding a C extension is anything more than
 a simple turnkey solution, and take Tcl to the next level.

     jeff.hobbs @SPAM acm.org
     jeffrey.hobbs @SPAM icn.siemens.de

 -----------== Posted via Deja News, The Discussion Network ==----------
 http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own