ANNOUNCE: Tcl 8.4.0 Final Release
Jeff Hobbs
September 18, 2000
The Tcl Core Team are pleased to announce the 8.4.0 releases of the Tcl
scripting language and the Tk toolkit. This is the first stable release
of Tcl/Tk 8.4. More details can be found below. We'd like to thank all
those that submit bugs and patches as they are the primary source of
information for us to identify problems in the core.
Where to get the new releases:
------------------------------
Tcl/Tk 8.4.0 are freely available in open source from the
Tcl Developer Xchange web site at
http://www.tcl.tk/software/tcltk/8.4.html
This web page also contains additional information about the
releases, including new features and notes about installing and
compiling the releases.
For additional information:
---------------------------
Please visit the Tcl Developer Xchange web site:
This site contains a variety of information about Tcl/Tk in general,
the core Tcl and Tk distributions, the TclPro tool suite, and much more.
Thank you for your contributions:
---------------------------------
As usual, this release includes contributions from the Tcl community.
We have a page honoring these contributions at:
http://www.tcl.tk/software/tcltk/contributors.html
Summary of Changes since Tcl/Tk 8.3.4:
--------------------------------------
Development of Tcl/Tk 8.4 began in May 2000, shortly after the release
of Tcl/Tk 8.3.1. The number of new features, bug fixes, and changes
over those 28 months is quite large. This section attempts to summarize
the most evident user-visible changes, organized by package and type
of change. For more details see the "changes" and "ChangeLog*" files
included in the distribution.
The Tcl Core Team (TCT) began governing additions of new features in
Tcl/Tk in September 2000. The TCT documents their decisions in Tcl
Improvement Proposals available at:
http://www.tcl.tk/cgi-bin/tct/tip/
Where changes below are due to a TIP, the relevant TIP number is noted.
See the documentation for full details on new features.
> Changes in Tcl
* Key New Features
o extensible "virtual filesystem" interface allows extensions to
present data sources to Tcl as "virtual files". (TIP 17)
o 64-bit native filesystem support (where the OS supports it) enables
ability to operate on files larger than 2 GiB (TIP 72)
o [expr] handles "wide integers" (>= 64-bit) even on 32-bit OSes
(TIP 72)
o traces on command renames and deletes
o traces on command execution (TIP 62)
o direct list element access via [lset] and [lindex] (TIPs 22,33,45)
o serial port support as Tcl channel (TIP 35)
o CONST-ified C interface (TIP 27)
o support for [source]-ing starkits (formerly "scripted documents")
o greater consistency of error messages
* New Commands
o [array statistics] - hash table details for debugging & profiling
o [file link] - cross-platform creation of filesystem links (TIP 99)
o [file normalize] - unique name of file (TIP 17)
o [file separator] - file path separator for filesystem (TIP 17)
o [file system] - name of filesystem providing a file (TIP 17)
o [info functions] - list functions known by [expr] (TIP 15)
o [interp recursionlimit] - get and set (trusted interp) limit
(TIP 87)
o [lset] - Directly set element of list (to any nesting depth)
(TIP 33)
o [memory] - debugging command (--enable-memdebug configuration)
o [namespace exists] - test for existence
o [trace add] - create a trace (variable, command, execution)
o [trace remove] - remove a trace (variable, command, execution)
o [trace info] - get info about current traces (TIP 102)
* Expanded Syntax / New Options
o [array names] options -regexp, -exact, and -glob
o [expr] support for "eq" and "ne" string comparison operators
o [fconfigure] - serial port configuration options
o [fcopy] respects channel encodings
o [info script] allows setting the script.
o [lindex] accepts multiple indices into nested lists.
o [lsearch] - new options -all -ascii -decreasing -dictionary
-increasing -inline -integer -not -real -sorted -start (TIP 80)
o [regsub] can return substituted result (TIP 76)
o [unset -nocomplain] - silence non-existence errors
o 64-bit support in [binary], [expr]
o "Inf" and "Nan" recognized as numbers
o Safe Base no longer limits file name length or format in [source]
o new global variable: tcl_platform(wordSize)
* Changes in Public C Interface
o Many functions have new CONST modifiers on the pointer arguments by
default. See "Compatibility issues" below. (TIP 27)
o Tcl_VarTraceProc's can now return (Tcl_Obj *) or dynamic string
(TIP 52)
o 81 new functions, including
o Tcl_Attempt* - non-panic'ing mem allocation functions
o Tcl_CommandTraceInfo, Tcl_TraceCommand, Tcl_UntraceCommand
- command rename and delete traces
o Tcl_CreateObjTrace - C level access to command execution traces
(TIP 32)
o Tcl_FS* - interface to virtual file systems (TIP 17)
o Tcl_GetChannelThread - what thread manages a channel (TIP 10)
o Tcl_GetMathFuncInfo, Tcl_ListMathFuncs - [expr] introspection
(TIP 15)
o Tcl_GetTime - cross-platform time - higher res on Windows
o Tcl_GetUnicodeFromObj - pull UCS-16 strings from Tcl_Obj
o Tcl_InitCustomHashTable, Tcl_InitObjHashTable - support for new
hash table key types including (Tcl_Obj *)'s.
o Tcl_JoinThread - support for joinable threads.
o Tcl_OutputBuffered - bytes pending in an output queue (TIP 49)
o Tcl_SubstObj - C level access to [subst] functionality (TIP 36)
o Tcl_*WideInt* - operations on Tcl_Obj's holding wide integers
(TIP 72)
* Platform/Environment Support
o configure dropped support for --enable-gcc; define CC=gcc instead
o new configure options --enable-langinfo= and --enable-memdebug
o configure supports --include-dir= and --libdir= options
o unix/dltest/configure absorbed into /unix/configure
o new make targets: 'make gdb'; 'make shell'
o added tclPlatDecls.h to default install
o New or improved support for AIX-4 (64-bit xlc), AIX-5, Borland
compiler on Windows, Cray, DJGPP on DOS, FreeBSD
(--enable-threads), GNU HURD , IRIX (64-bit), Mac OS 9, Mac OS X /
Darwin, mingw 1.1 (gcc on Windows), OSF (--disable-shared), VC++
5.0
o new and updated encodings, including ISO-8859-15 and koi8-u
o corrected unsafe use of tmpnam() on Unix
o Unix file output now avoids zero-byte writes (STREAMs)
o [exec] argument quoting fixes on Windows
* Performance Enhancements
o optimization of bytecode execution engine
o thread-enabled memory allocator
o boolean Tcl_Obj values are now cached
o [proc foo args {}] compiles to 0 bytecodes -- efficient no-op
(TIP 53)
o string growth algorithm now allows use of more of available memory
o greater timer resolution on Windows (TIP 7)
o [binary scan] - caching scheme saves memory
o [glob] - excess stat calls on Windows suppressed
o [lsearch] - sorted or typed lists use faster algorithms
o [for],[if],[while] - byte-compiled optimization for constant
conditions
o variable lookup speed improved by Tcl_Obj use.
o new or improved byte compiling of [append], [lappend], [list],
[regexp], [regsub], [return], [string]
> Changes in Tk
* New Commands
o [clipboard get] means [selection get -selection CLIPBOARD]
o [image inuse]
o [labelframe] widget (TIP 18)
o [panedwindow] widget (TIP 41)
o [spinbox] widget
o [$photo transparency] - get/set transparency of pixel in photo
(TIP 14)
o [$text edit] - interface to undo/redo stack (TIP 26)
o [tk caret] - caret handling (accessibility;XIM) (TIP 96)
o [tk windowingsystem] - underlying library Tk built on (TIP 108)
o [wm attributes] - access to wm-specific interfaces (TIP 95)
o [wm stackorder] - query stacking order (TIP 74)
o private commands moved into ::tk namespace (TIP 44)
* Expanded Syntax / New Options
o [bell]: -nice option to not reset screen saver
o [button] support for -repeatdelay, -repeatinterval
o [*button],[label],[$menu add],[menubutton]: -compound option
adds both text and image (TIP 11)
o [*button]: -overrelief, -offrelief relief changes on mouseover
(TIP 82)
o [entry]: new -state readonly
o [grid],[pack]: -padx, -pady allow asymmetric padding (TIP 21)
o [grid (row|column)configure]: -uniform layout (TIP 37)
o [listbox]: -activestyle, -disabledforegroud, -state (TIP 94)
o [$photo copy]: -compositingrule transparency control (TIP 98)
o [raise] is now non-blocking (avoid 2-second delay) (TIP 107)
o [text]: -undo, -autoseparators configuration of undo stack (TIP 26)
o [$text delete],[$text get]: accept multiple index pairs (TIP 93)
o [tk_(get|save)OpenFile]: -multiple, -message
o [tk useinputmethods 1] is now default
o [wm transient] changed behavior; can't be parent of self
o better multi-display support
o new default bgerror dialog; easier stack trace access
o new event types: , , ,
,
o new virtual events: <>, <>
o new bind substitutions: %i, %P
* Changes in Public C Interface
o Many functions have new CONST modifiers on the pointer arguments by
default. See "Compatibility issues" below. (TIP 27)
o Reorganized Tk to allow usage in writing an X wm (TIP 47)
o New Tk_OptionType value, TK_OPTION_CUSTOM
o Tk registers its Tcl_ObjTypes
o 24 new functions, including
o Interface to a style engine (TIP 48)
o Tk_CollapseMotionEvents - make full motion events available
(TIP 84)
o Tk_CreateAnonymousWindow - create C-controlled anonymous window
o Tk_PhotoPut*Block - added compositing control (TIP 98)
o Tk_SetCaretPos - control over caret position (TIP 96)
o Tk_SetClassProcs - more control in widget creation (TIP 5)
* Platform/Environment Support
o menu indicator drawing corrected on Windows
o new button size default on Windows
o more Unicode use in native Windows widgets
o Windows mirrors B2 bindings to B3.
o native directory browser on Windows
o [button]: -width accepts negative value for minimum width on
Windows
o [wm iconbitmap $path -default $filename] icon on Windows (winico)
(TIP 8)
o new or improved support for AIX-4 (64-bit xlc), AIX-5, Borland
compiler on Windows, Mac OS X / Aqua, mingw 1.1 (gcc on Windows),
o improved --enable-threads support
o new make target: `make gdb`
o added tkPlatDecls.h to default install
o dialogs use msgcat package for localization
o message catalogs use "ampersand magic"
o test suite uses tcltest package
* Performance Enhancements
o Tcl-Obj-ified commands: [bindtags], [clipboard], [grid], [message],
[pack], [place], [selection], [tkwait], [wm]
o Internal use of "window" Tcl_ObjType
> Changes in bundled packages
* New major release
o tcltest 2.2 has replaced tcltest 1.0. tcltest 2.2 works
compatibly with test suites written for tcltest 1.0, but offers
many improvements. See the documentation for details
* New public commands
o [msgcat::mcload],[msgcat::mcmax],[msgcat::mcmset] (msgcat 1.2)
* Expanded Syntax / New Options
o [dde request]: -binary gets result as byte array (dde 1.2)
o XPG4 locales supported (msgcat 1.3)
* Platform/Environment Support
o More Windows registry locale codes recognized (msgcat 1.3)
o locale initialization from LC_ALL and LC_MESSAGES (msgcat 1.3)
Compatibility issues:
--------------------
The Tcl/Tk 8.4.0 releases are highly compatible with prior releases
of Tcl/Tk since 8.1. There are a handful of changes that may cause
programs and scripts written for prior releases to behave differently
with Tcl/TK 8.4.0. Here we summarize the known things to watch out for.
Script-visible incompatibilities in Tcl:
* The variables ::tcl_traceCompile and ::tcl_traceExec now govern the
printing of trace messages only in the TCL_COMPILE_DEBUG variant of
Tcl. In the default build of Tcl, they have no special effects.
* Literal integer values between 2147483648 and 4294967296 are now
treated as positive wide integers. They used to be negative 32-bit
integers.
* [glob] now respects platform conventions for hidden files. Hidden
files will not be returned by default. Supply the "-types hidden"
option to force their inclusion in the returned list.
* [info level $level] will now return a [namespace eval] in the call
stack.
* [fcopy] now respects the encodings of its channels.
* [subst] has changed the way it reacts to a [break] (TCL_BREAK) or
[continue] (TCL_CONTINUE) during substitution.
* The strings "Inf" and "Nan" are now recognized by the Tcl parser as
numbers.
* read traces during [array get] that modify the array are handled
differently
* [memory] command (in the --enable-memdebug variant) has changed;
[checkmem] has been removed.
* [auto_import] pattern matching is now namespace-aware.
* The search patch for init.tcl on Windows no longer includes the current
directory, and is no longer influenced by values in the registry.
* The string growth algorithm has changed, which may change memory use
patterns, especially for applications that use large strings.
* Several error messages have changed.
Script-visible incompatibilities in Tk:
* default button size has changed on Windows
* transient toplevels now mirror the state of their master
* a window cannot be a transient master of itself
* [tk_get(Save|Open)File] on unix ensures that the returned file has a
file extension if one was noted in the file types, to match Windows.
* The private commands and variables provided by Tk that match the glob
pattern tk[a-z]* have been moved into the ::tk namespace. Use the new
commands [::tk::unsupported::ExposePrivateCommand *] and
[::tk::unsupported::ExposePrivateVariable *] to restore their
availability as in previous releases. See TIP 44 and
http://wiki.tcl.tk/3670 for more details.
Incompatibilities in configuring/building/installing Tcl/Tk:
* cygwin support dropped; use mingw instead
* changed the binary extension format on Mac from MachO to .dylib
* support for the --include-dir= and --libdir= configuration options
implies that redefinition of exec_prefix during install no longer
fully controls installation.
C interface incompatibilities in Tcl/Tk:
* The public header files tcl.h now assumes at least minimal compiler
support for features of ANSI C that have been in the language for
years. If you have a truly ancient compiler, you may need special
configuration to successfully compile.
* The Tcl C library no longer defines a function matherr().
* The size of some of Tcl public structs, notably Tcl_HashTable, have
changed. If you define structs that include one of these changed
Tcl structs inline, the size and field offsets of your structs can be
changed, causing errors. See http://wiki.tcl.tk/3708 for more details.
* The C interface has been fully CONST-ified. That is, wherever a
function accepts an argument or returns a result that is intended to be
a read-only string, it now has type (const char *) even where prior
releases of Tcl/Tk had type (char *). This causes some source
incompatibilities. #define USE_NON_CONST will restore an interface
that is source-compatible with Tcl 8.3. See TIP 27 and
http://wiki.tcl.tk/3669 for more information.
* The functions Tk_PhotoPutBlock and Tk_PhotoPutZoomedBlock now take
an additional argument controlling the compositing rule. To use the
previous declaration, #define USE_COMPOSITELESS_PHOTO_PUT_BLOCK.
(TIP 98)
--
Tcl Core Maintainers
Jeff Hobbs, Tcl Core Release Manager
Sven Geggus
> The Tcl Core Team are pleased to announce the 8.4.0 releases of the Tcl
> scripting language and the Tk toolkit.
Downloaded, compiled, works so far...
Now for the real interesting Part.
I'm using the following extensions:
* TclX
* BLT
* BWidget
which one wiooll work with the 8.4.0 Release?
Sven
--
"Those who do not understand Unix are condemned to reinvent it, poorly"
(Henry Spencer)
/me is giggls@ircnet, http://geggus.net/sven/ on the Web
David Gravereaux
>* TclX
>* BLT
>* BWidget
>
>which one wiooll work with the 8.4.0 Release?
Do they all support Stubs? Your answer is from that question.
--
David Gravereaux <davy...@pobox.com>
Tomasoft Engineering, Hayward, CA
[species: human; planet: earth,milkyway,alpha sector]
Jacob Levy
distribution, which can be found here:
http://www.activestate.com/Products/Download/Register.plex?id=ActiveTcl
--JYL
David Gravereaux
>All of these extensions are included in the ActiveState 8.4.0 ActiveTcl
>distribution, which can be found here:
> http://www.activestate.com/Products/Download/Register.plex?id=ActiveTcl
>
>--JYL
But BLT isn't on the list.
http://www.activestate.com/Products/ActiveTcl/more_information.plex
David Gravereaux
>But BLT isn't on the list.
The reason BLT is not on the list might not have to do with the Stubs linking
technique for extensions, but might have to do with BLT's build system not using
the TEA architecture. Jeff would be the person to ask about why it's not in
ActiveTcl.
If BLT was using Stubs, and ignoring for the moment any internal structure
changes in 8.4 that BLT might be using that have shifted, BLT could be used with
8.4. But BLT uses implicit linking (on windows) to the tcl core by name and is
forever stuck to the core it was built for.
One could always just rebuild BLT for each core version needed. I think the
current HEAD in CVS (2.4z, i think) builds against 8.4.0 just fine.
Marty Backe
of TclX to get it to compile. And BLT2.4z (cvs only) now supports 8.4.
In article <ameml5$bmi$1...@benzin.geggus.net>, Sven Geggus wrote:
> Jeff Hobbs <je...@activestate.com> wrote:
>
>> The Tcl Core Team are pleased to announce the 8.4.0 releases of the Tcl
>> scripting language and the Tk toolkit.
>
> Downloaded, compiled, works so far...
>
> Now for the real interesting Part.
>
> I'm using the following extensions:
>
> * TclX
> * BLT
> * BWidget
>
> which one wiooll work with the 8.4.0 Release?
>
> Sven
>
--
Marty Backe
-------------------------------
http://www.lucidway.org
- Who is John Galt?
Jacob Levy
http://e4graph.sourceforge.net/) that doesn't conform to TEA yet nor
uses stubs, and it works fine with Tcl 8.4.
So, if I'm understanding you correctly, you're saying that in order to
work with Tcl 8.4, an extension has to use stubs, which seems incorrect,
because mine works.
On a relatd topic, how do you make an extension use stubs? If I want to
compile on Win32 using VC++ (using the IDE, i.e. using a '.dsw' file) as
well as on Linux/Unix/Solaris and on MacOS 9.x, etc. Can you point to a
starting point for docs to read -- a cookbook kind of thing, a how-to
for making an extension conform to TEA and use stubs?
Thanks! --JYL
David Gravereaux
>Not sure I'm understanding. I have an extension (I wrote it -- e4Graph
>http://e4graph.sourceforge.net/) that doesn't conform to TEA yet nor
>uses stubs, and it works fine with Tcl 8.4.
Because you compiled your dll for 8.4 and linked to tcl84.lib, that makes it
work in 8.4. Not having a TEA build just means Jeff won't consider adding it to
ActiveTcl.
>So, if I'm understanding you correctly, you're saying that in order to
>work with Tcl 8.4, an extension has to use stubs, which seems incorrect,
>because mine works.
Can't work in 8.3 and 8.4 from the same .dll/.so/.sl unless it uses Stubs.
Hence the need for Sven to recompile BLT with (probably) fresh 2.4z source. Try
it.. build an extension against 8.3's tcl83.lib and load that extension into
8.4, *BANG*. The implicit linking to 8.3 cause tcl83.dll to load into the
process, too, along with tcl84.dll and your extension will call into the wrong
core and GPF quite quickly.
>On a relatd topic, how do you make an extension use stubs? If I want to
>compile on Win32 using VC++ (using the IDE, i.e. using a '.dsw' file) as
>well as on Linux/Unix/Solaris and on MacOS 9.x, etc. Can you point to a
>starting point for docs to read -- a cookbook kind of thing, a how-to
>for making an extension conform to TEA and use stubs?
In it's simplest, just add -DUSE_TCL_STUBS to the compile flags and link to
tclstub84.lib and add
#ifdef USE_TCL_STUBS
if (Tcl_InitStubs(interp, "8.1", 0) == NULL) {
return TCL_ERROR;
}
#endif
to you Tcl_InitProc before any other function call. BLT with Stubs is more
complex because it provides an API as well, like Tk does and the code is missing
to allow this feature and handle some intriguing across the board version
differences with regards to internal Tk data used.
For TEA, look at the sampleextension in the tcl SF download section and the
numerous TEA found on http://www.tcl.tk in the whitepaper or docs section and
also on http://wiki.tcl.tk
MacOS 9 needs the compiler specific project files, whatever they are.. probably
metrowerks. There isn't (and can't be) a TEA abstraction for it. Unless
someone rewrites autoconf... not likely.. or TEA gets a redesign.
PS. Expect doesn't use Stubs either.
Jacob Levy
> In it's simplest, just add -DUSE_TCL_STUBS to the compile flags and link to
> tclstub84.lib and add
>
> #ifdef USE_TCL_STUBS
> if (Tcl_InitStubs(interp, "8.1", 0) == NULL) {
> return TCL_ERROR;
> }
> #endif
>
> to you Tcl_InitProc before any other function call. BLT with Stubs is more
> complex because it provides an API as well, like Tk does and the code is missing
> to allow this feature and handle some intriguing across the board version
> differences with regards to internal Tk data used.
What do you mean, provides an API? You mean its methods are callable
from C as well as from Tcl? If so would they need to provide a stubs
interface of their own?
Hopefully I do not have to worry about that because my extension does
not provide a C API.
Of course there's new questions:
Suppose I have an extension A and B. B requires A. Do both the init
functions have to have this #ifdef TCL_USE_STUBS construction?
My extension on Unix does not link against any Tcl library. This works
because it is loaded into Tcl and all the required symbols will already
be present. On Win32 it is linked with tcl84.lib, which I understand I
should replace with tclstub84.lib. My question: in order to be stub
compliant should I also link on Unix against libtclsub84.a? Why?
> For TEA, look at the sampleextension in the tcl SF download section and the
> numerous TEA found on http://www.tcl.tk in the whitepaper or docs section and
> also on http://wiki.tcl.tk
>
> MacOS 9 needs the compiler specific project files, whatever they are.. probably
> metrowerks. There isn't (and can't be) a TEA abstraction for it. Unless
> someone rewrites autoconf... not likely.. or TEA gets a redesign.
Thanks for all the help so far! e4graph 1.0a7 will use stubs and
potentially be TEA compliant because of your help.
Thanks! --JYL
David Gravereaux
>Dave
>
>
>> In it's simplest, just add -DUSE_TCL_STUBS to the compile flags and link to
>> tclstub84.lib and add
>>
>> #ifdef USE_TCL_STUBS
>> if (Tcl_InitStubs(interp, "8.1", 0) == NULL) {
>> return TCL_ERROR;
>> }
>> #endif
>>
>> to you Tcl_InitProc before any other function call. BLT with Stubs is more
>> complex because it provides an API as well, like Tk does and the code is missing
>> to allow this feature and handle some intriguing across the board version
>> differences with regards to internal Tk data used.
>
>
>What do you mean, provides an API? You mean its methods are callable
>from C as well as from Tcl?
Yes.
> If so would they need to provide a stubs
>interface of their own?
Yes. [Incr Tcl] does using the tools and techniques the core uses.
>Hopefully I do not have to worry about that because my extension does
>not provide a C API.
Not many do. And that's ok. One that I have will eventually, when I get that
far on it.
>Of course there's new questions:
>
>Suppose I have an extension A and B. B requires A. Do both the init
>functions have to have this #ifdef TCL_USE_STUBS construction?
If both call Tcl APIs, yes.
>My extension on Unix does not link against any Tcl library. This works
>because it is loaded into Tcl and all the required symbols will already
>be present. On Win32 it is linked with tcl84.lib, which I understand I
>should replace with tclstub84.lib. My question: in order to be stub
>compliant should I also link on Unix against libtclsub84.a? Why?
Yes, please. Version independence, mainly. For our new 8.4.0, the minor
version has been bumped up. And along with it, the shared library name. For a
working 8.3 Tcl extension to load into 8.4 requires that the reference to the
name of the shared library be abstracted away. That's what Stubs does. It
comes in handy for custom shells (or applications) with Tcl statically linked
into it that don't export any Tcl symbols and load external extensions.
Freewrap executables don't export any of the Tcl symbols. TclPro's bigwish.bin
(the executable base) doesn't either. But with Stubs, Tcl's API gets passed to
the extension. All that Stubs is is just a known/stable listing of function
pointers that are filled in @ Tcl_InitStubs(). So what once was "call by
symbol", is now "call by pointer" through some macro magic so it looks the same.
>> For TEA, look at the sampleextension in the tcl SF download section and the
>> numerous TEA found on http://www.tcl.tk in the whitepaper or docs section and
>> also on http://wiki.tcl.tk
>>
>> MacOS 9 needs the compiler specific project files, whatever they are.. probably
>> metrowerks. There isn't (and can't be) a TEA abstraction for it. Unless
>> someone rewrites autoconf... not likely.. or TEA gets a redesign.
>
>
>Thanks for all the help so far! e4graph 1.0a7 will use stubs and
>potentially be TEA compliant because of your help.
My pleasure. This stuff isn't documented enough.
Jacob Levy
>>My extension on Unix does not link against any Tcl library. This works
>>because it is loaded into Tcl and all the required symbols will already
>>be present. On Win32 it is linked with tcl84.lib, which I understand I
>>should replace with tclstub84.lib. My question: in order to be stub
>>compliant should I also link on Unix against libtclsub84.a? Why?
>>
>
> Yes, please. Version independence, mainly. For our new 8.4.0, the minor
> version has been bumped up. And along with it, the shared library name. For a
> working 8.3 Tcl extension to load into 8.4 requires that the reference to the
> name of the shared library be abstracted away. That's what Stubs does. It
> comes in handy for custom shells (or applications) with Tcl statically linked
> into it that don't export any Tcl symbols and load external extensions.
> Freewrap executables don't export any of the Tcl symbols. TclPro's bigwish.bin
> (the executable base) doesn't either. But with Stubs, Tcl's API gets passed to
> the extension. All that Stubs is is just a known/stable listing of function
> pointers that are filled in @ Tcl_InitStubs(). So what once was "call by
> symbol", is now "call by pointer" through some macro magic so it looks the same.
OK I understand that on Win32 I don't have a choice, I *must* link the
DLL against a specific version of tclXY.lib (or now, tclstubXY.lib).
That's the way the Win32 linker works.
However, on Unix I have a tradeoff:
* If I link my extension with libtclstub84.a, won't it then require 8.4
to be installed at the end user's site? It might, if libtclstub84.a
requires any '.so' from 8.4.
* If I don't link against libtclstubs84.a or anything else from Tcl, and
only use tcl.h, my extension does not (seem to) require a specific
version of Tcl to be installed at the end user's site. Any Tcl that has
the APIs I depend on will work.
Right?
Just playing devil's advocate, but I don't see what evil I'm protecting
against by linking with libtclstub84.a versus not linking against
anything. I do see however that it's costly since now all my Tcl APIs
are called via a pointer instead of directly. Kind of like a C++ vtbl
without the compiler having the option of converting virtual calls to
direct when possible :)
--JYL
Roy Terry
> anything. I do see however that it's costly since now all my Tcl APIs
> are called via a pointer instead of directly. Kind of like a C++ vtbl
> without the compiler having the option of converting virtual calls to
> direct when possible :)
Interesting viewpoint. I wonder if the speed difference (measured
against the time
spent running the Tcl program) would be noticable or even measurable? Do
you have
any data? Seems a modern computer going through a pointer is super quick
compared
to (say) running 1 pass through eval. Then of course there's the time
spent explaining
not using stubbs which would seem to swamp all other quantities! :^)
Don Porter
> In it's simplest, just add -DUSE_TCL_STUBS to the compile flags and link to
> tclstub84.lib and add
>
> #ifdef USE_TCL_STUBS
> if (Tcl_InitStubs(interp, "8.1", 0) == NULL) {
> return TCL_ERROR;
> }
> #endif
FWIW, the #ifdef is not necessary. When USE_TCL_STUBS is not defined,
the Tcl_InitStubs() call gets transformed to a Tcl_PkgRequire() call
for the "Tcl" package.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
David Gravereaux
>David Gravereaux wrote:
>> In it's simplest, just add -DUSE_TCL_STUBS to the compile flags and link to
>> tclstub84.lib and add
>>
>> #ifdef USE_TCL_STUBS
>> if (Tcl_InitStubs(interp, "8.1", 0) == NULL) {
>> return TCL_ERROR;
>> }
>> #endif
>
>FWIW, the #ifdef is not necessary. When USE_TCL_STUBS is not defined,
>the Tcl_InitStubs() call gets transformed to a Tcl_PkgRequire() call
>for the "Tcl" package.
I had an issue with 8.0.5 not defining it in it's tcl.h, and that seemed to me
like the simple way to took care of it. Yes, the #ifdef doesn't need to be
there for 8.1+. Maybe this could be used instead for the same 8.0 support?
#include "tcl.h"
#if (TCL_MAJOR_VERSION == 8 && TCL_MINOR_VERSION == 0)
# define Tcl_InitStubs(interp, version, exact) \
Tcl_PkgRequire(interp, "Tcl", "8.0", 1)
#endif
....
#undef TCL_STORAGE_CLASS
#define TCL_STORAGE_CLASS DLLEXPORT
EXTERN int
Blah_Init (Tcl_Interp *interp)
{
if (Tcl_InitStubs(interp, "8.1", 0) == NULL) {
return TCL_ERROR;
}
Tcl_CreateObjCommand(interp, "blah", BlahObjCmd, NULL, NULL);
Tcl_PkgProvide(interp, "blah", "0.0");
return TCL_OK;
David Gravereaux
libtclstub84.a is a static library. It doesn't require any .so
Here's the sliding part where it gets fun. The core is always loaded first
before extensions, and it's what the extension is loaded into that matters.
if (Tcl_InitStubs(interp, "8.1", 0) == NULL) {
return TCL_ERROR;
}
Tcl_InitStubs is getting the function table from the interp the extension is
loaded into only, with 8.1 being the minimum accepted version and not exact (the
zero). The trick is to know the Tcl API your using to select the right bottom
level version. In this one extension I have, I used to use
Tcl_UniCharNcasecmp(), but found later by accident it would crash in 8.3 upon
hitting that part of the code. I built it with 8.4, Tcl_InitStubs with 8.1, and
loaded it into 8.3. What did I do wrong? Tcl_UniCharNcasecmp() got introduced
in 8.4.. Ahh. So I switched to Tcl_UniCharCaseMatch() instead, which, I think,
got introduced in 8.3. I changed Tcl_InitStubs to require 8.3. Problem solved.
There was a time when I used to build against 8.1.0, and use its tclstub81.lib
and that way I would know for sure about staying to an 8.1 baseline. I don't do
it anymore.. Not a bad verification, though. If I had been building against
8.3, I would have known I couldn't have used that function and still want 8.3 as
my baseline. I must be getting sloppy...
if (Tcl_InitStubs(interp, TCL_VERSION, 0) == NULL) {
return TCL_ERROR;
}
That might be better when you are building against a baseline minimum. But
building against the newest core shouldn't place a minimum if you know it can
run in a lesser... That's the best way I can think of it. Plenty of room for
some game play.
>* If I don't link against libtclstubs84.a or anything else from Tcl, and
>only use tcl.h, my extension does not (seem to) require a specific
>version of Tcl to be installed at the end user's site. Any Tcl that has
>the APIs I depend on will work.
>
>Right?
Most of my work is on windows, so I can't contribute much in this..
No -L or -R for gcc? Is this common?
>Just playing devil's advocate, but I don't see what evil I'm protecting
>against by linking with libtclstub84.a versus not linking against
>anything. I do see however that it's costly since now all my Tcl APIs
>are called via a pointer instead of directly. Kind of like a C++ vtbl
>without the compiler having the option of converting virtual calls to
>direct when possible :)
Performance?
CALL - Procedure Call
Usage: CALL destination
Modifies flags: None
Pushes Instruction Pointer (and Code Segment for far calls) onto
stack and loads Instruction Pointer with the address of proc-name.
Code continues with execution at CS:IP.
Clocks
Operands 808x 286 386 486
rel32 (near, IP relative) - - 7+m 3
mem32 (near, memory indirect) - - 10+m 5
3 clock cycles vs. 5... I'd have to lookup what the machine code my compiler
is spitting-out to verify..
On windows, anyway, __imp__Tcl_CreateInterp does a call to the import table,
which then does a jump from a pointer anyways. A pointer that's filled by the
OS loader. It seems like a re-implimentation of the same.
David Gravereaux
>In it's simplest, just add -DUSE_TCL_STUBS to the compile flags and link to
>tclstub84.lib and add
>
>#ifdef USE_TCL_STUBS
> if (Tcl_InitStubs(interp, "8.1", 0) == NULL) {
> return TCL_ERROR;
> }
>#endif
>
>to you Tcl_InitProc before any other function call.
If it helps, I've found this useful on windows with VC++. It places the correct
linker requirements in the object file and there's no need for matching link
switches to the compiler ones in a makefile.
#ifdef _MSC_VER
/* Only do this when MSVC++ is compiling us. */
# ifdef USE_TCL_STUBS
/* Mark this .obj as needing tcl's Stubs library. */
# pragma comment(lib, "tclstub" \
STRINGIFY(JOIN(TCL_MAJOR_VERSION,TCL_MINOR_VERSION)) ".lib")
# if !defined(_MT) || !defined(_DLL) || defined(_DEBUG)
/* This fixes a bug with how the Stubs library was compiled.
* The requirement for msvcrt.lib from tclstubXX.lib should
* be removed. */
# pragma comment(linker, "-nodefaultlib:msvcrt.lib")
# endif
# else
/* Mark this .obj needing the import library */
# pragma comment(lib, "tcl" \
STRINGIFY(JOIN(TCL_MAJOR_VERSION,TCL_MINOR_VERSION)) ".lib")
# endif
#endif
David Gravereaux
>Don Porter <d...@email.nist.gov> wrote:
>
>>David Gravereaux wrote:
>>> In it's simplest, just add -DUSE_TCL_STUBS to the compile flags and link to
>>> tclstub84.lib and add
>>>
>>> #ifdef USE_TCL_STUBS
>>> if (Tcl_InitStubs(interp, "8.1", 0) == NULL) {
>>> return TCL_ERROR;
>>> }
>>> #endif
>>
>>FWIW, the #ifdef is not necessary. When USE_TCL_STUBS is not defined,
>>the Tcl_InitStubs() call gets transformed to a Tcl_PkgRequire() call
>>for the "Tcl" package.
>
>I had an issue with 8.0.5 not defining it in it's tcl.h, and that seemed to me
>like the simple way to took care of it. Yes, the #ifdef doesn't need to be
>there for 8.1+. Maybe this could be used instead for the same 8.0 support?
I think I like the following better... Does this seem valid?
>#include "tcl.h"
/* Check for Stubs compatibility when asked for it. */
#if (TCL_MAJOR_VERSION < 8 || \
(TCL_MAJOR_VERSION == 8 && \
(TCL_MINOR_VERSION == 0 || \
(TCL_MINOR_VERSION == 1 && TCL_RELEASE_LEVEL != TCL_FINAL_RELEASE) \
) \
) \
)
# define HAS_TCL_STUBS_SUPPORT 0
# ifdef USE_TCL_STUBS
# error Stubs doesn't work in alpha/beta 8.1 or less; only 8.1.0+
# else
/* Tcl_InitStubs doesn't exist, so fake it. */
# define Tcl_InitStubs(i,v,e) Tcl_PkgRequire(i, "Tcl", TCL_VERSION, 1)
# endif
#else
# define HAS_TCL_STUBS_SUPPORT 1
Don Porter
> I think I like the following better... Does this seem valid?
snipped good stuff.
> # else
> /* Tcl_InitStubs doesn't exist, so fake it. */
> # define Tcl_InitStubs(i,v,e) Tcl_PkgRequire(i, "Tcl", TCL_VERSION, 1)
That should be:
# define Tcl_InitStubs(i,v,e) Tcl_PkgRequire(i, "Tcl", v, e)
...but basically, you should just use Tcl 8.2 or later to get stubs
support.
David Gravereaux
Yes, 8.2 is minimum I'd go given all the progress that's happened in the last 3
years.
>> # define Tcl_InitStubs(i,v,e) Tcl_PkgRequire(i, "Tcl", TCL_VERSION, 1)
># define Tcl_InitStubs(i,v,e) Tcl_PkgRequire(i, "Tcl", v, e)
Say one compiled against 7.5, but tried to load into 7.6? That should be
restricted, right? Or am I thinking about this too much? The above would ask
for "8.1" if v got passed through and barf. I'm assuming the source would be
full of version checks for various things like Tcl_Obj, unicode, etc..
Some people have said that maintaining source compatibility down to 7.5 is a
"feature". Is this a realizable goal for today if the project was to not only
use Tcl_Objs, unicode and Stubs, but provide their own Stubs table, too? Is it
too hard to support everything old and everything new at the same time from the
same code base with extensions? Should the past be let go? I want to know...
`scuse me while I test some code to see :)
Pardon the strange questions that don't have yes/no answers. I'm intrigued by
Tcl's architecture lately.
George A. Howlett
> which one will work with the 8.4.0 Release?
The sources of BLT currently in the CVS repository on sourceforge.net
have been compiled and run with Tcl/Tk 8.4.0.
I hate to admit it, but I'm kind-of turned off by 8.4's new
look-and-feel for Tk buttons. When you pass the mouse pointer over a
Tk button, the button's relief changes to flat.
In previous versions, only the button's color changed when the mouse
passed over it. This provided a subtle, but very effective visual cue
that
1) the mouse was active meaning that you were currently over the
button and
2) the button could be pressed (distinguishing it from other 3-D
decorations such as a raised labeled).
In 8.4, when you pass over a button, it goes flat. I thought the
whole idea behind making 3-D buttons is that they look like they can
be pushed. And where outside of cyperspace does a button become
flattened without me pushing on it? Is there really another toolkit
does this?
When the button goes flat it confuses me (the user). It's three card
monty. When I finally move the mouse over a button, suddenly it's no
longer 3-D (and that was the thing that drew me to it). Did it become
suddenly disabled? It's also visually distracting. When the button
goes flat, you also lose the 3-D border. It looks like the button has
changed size since the entire rectangle is now the button's surface.
Now don't get me wrong. I'm not against adding features to Tk. It's
just when the default look-and-feel changes. I'm reluctant to upgrade
my company to Tk 8.4, because it means that every Tk program we have
has to be fixed to work the same as it did before. I guess there's
nobody left that remembers Tk 3.6.
--gah
Don Porter
>
>># define Tcl_InitStubs(i,v,e) Tcl_PkgRequire(i, "Tcl", v, e)
>
> Say one compiled against 7.5, but tried to load into 7.6? That should be
> restricted, right? Or am I thinking about this too much? The above would ask
> for "8.1" if v got passed through and barf.
I think I'm confused by the notion of using stubs where there is no
stubs support. Don't trust my answers.
I was assuming that the "v" and "e" arguments to Tcl_InitStubs were
meant to mean something, though. If we're going to ignore them, then
why not
# define Tcl_InitStubs(i,v,e) TCL_VERSION
> Some people have said that maintaining source compatibility down to 7.5 is a
> "feature".
I do that routinely, but I do it by (mostly) limiting my code to
7.5 features. When I rarely do use later features, I use "forward
compatibility" techniques (see the Wiki) to provide them to Tcl 7.
Jeffrey Hobbs
> I hate to admit it, but I'm kind-of turned off by 8.4's new
> look-and-feel for Tk buttons. When you pass the mouse pointer over a
> Tk button, the button's relief changes to flat.
>
> In previous versions, only the button's color changed when the mouse
> passed over it. This provided a subtle, but very effective visual cue
Woah ... this would be a bug. The active color change was meant to be the
only variation still in 8.4 - only when new options were used were you
supposed to get the toolbar style button behavior. Do you have a small script
to reproduce this behavior? I assume it is on unix, as I don't see it on my
Windows machine at home. Of course Win/Mac/Unix all have slightly different
bindings for the button on enter/leave/press.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
Marty Backe
this can be reproduced?
In article <uoqpsln...@corp.supernews.com>, George A. Howlett wrote:
<snip>
>
> I hate to admit it, but I'm kind-of turned off by 8.4's new
> look-and-feel for Tk buttons. When you pass the mouse pointer over a
> Tk button, the button's relief changes to flat.
>
<snip>
>
> --gah
Joe English
>
>Not sure I'm understanding. I have an extension (I wrote it -- e4Graph
>http://e4graph.sourceforge.net/) that doesn't conform to TEA yet nor
>uses stubs, and it works fine with Tcl 8.4.
(Aside: AFAICT, "conforms to TEA" simply means "works for Jeff Hobbs",
so you might be TEA-compliant without knowing it :-)
>So, if I'm understanding you correctly, you're saying that in order to
>work with Tcl 8.4, an extension has to use stubs
Not exactly. The implication goes the other way:
if a compiled extension works with Tcl 8.[321] and uses stubs [1],
then it will continue to work with Tcl 8.4 without recompiling
or relinking.
Of course, that's not the only way to get an extension
to work with 8.4 :-) If you don't use stubs, recompiling
against the 8.4 headers and relinking against the 8.4
libraries should also work [2].
But adding stubs support is easy and has many benefits:
just compile with -DUSE_TCL_STUBS and call Tcl_InitStubs()
as the first thing in the package initialization routine:
if (Tcl_InitStubs(interp, TCL_VERSION, 0) == NULL)
return TCL_ERROR;
--Joe English
[1] There are a few other restrictions -- if the extension
peeks at Tcl internals (#include tclInt.h), all bets
are off -- but for 8.3->8.4 even then you're probably
still OK.
[2] However beware -- there were more source-level incompatibilities
than usual in the 8.3->8.4 transition, mostly having to do with
CONST-correctness.
George A. Howlett
> Woah ... this would be a bug. The active color change was meant to
> be the only variation still in 8.4 - only when new options were used
> were you supposed to get the toolbar style button behavior. Do you
> have a small script to reproduce this behavior? I assume it is on
> unix, as I don't see it on my Windows machine at home. Of course
> Win/Mac/Unix all have slightly different bindings for the button on
> enter/leave/press.
It's obviously my bug. I restarted fresh, cleaned out everything and
rebuilt, and buttons behave like they should. Thanks, I'm very happy
that's not an 8.4.0 problem.
--gah
Jean-Claude Wippler
> Dave
>
> >>My extension on Unix does not link against any Tcl library. This works
> >>because it is loaded into Tcl and all the required symbols will already
> >>be present. On Win32 it is linked with tcl84.lib, which I understand I
> >>should replace with tclstub84.lib. My question: in order to be stub
> >>compliant should I also link on Unix against libtclsub84.a? Why?
> >
> > Yes, please. Version independence, mainly. For our new 8.4.0, the minor
> > version has been bumped up. And along with it, the shared library name.
[...]
> OK I understand that on Win32 I don't have a choice, I *must* link the
> DLL against a specific version of tclXY.lib (or now, tclstubXY.lib).
> That's the way the Win32 linker works.
Just to make sure there is no confusion: yes, you will *link* against
tclstubXY.lib, but that will let you *run* across versions anyway.
> However, on Unix I have a tradeoff:
>
> * If I link my extension with libtclstub84.a, won't it then require 8.4
> to be installed at the end user's site? It might, if libtclstub84.a
> requires any '.so' from 8.4.
Nope. It can on any Tcl >= 8.1, as long as you do not call functions
defined only in later releases. That is why the call to StubInit in
each extension mentions a version: the version of the *API* it needs.
> * If I don't link against libtclstubs84.a or anything else from Tcl, and
> only use tcl.h, my extension does not (seem to) require a specific
> version of Tcl to be installed at the end user's site. Any Tcl that has
> the APIs I depend on will work.
>
> Right?
Wrong, partly. Without linkage, you are relying on "back-linking", i.e.
the ability of the dynamic linker to resolve against what is already
loaded, i.e. the currently running Tcl/Tk code. That works on *some*
platforms, including Linux/Solaris.
It can break down on others, especially if the main app is statically
linked against Tcl/Tk (example: tclkit). Apart from deployment reasons,
there is on fact another major reason to link statically: performance.
On register-starved machine architectures, such as x86, dynamically
loadable code (i.e. PIC) is some 15..25% slower. With Tcl/Tk linked in
statically, you get this gain, even if the other extensions are dynamic.
> Just playing devil's advocate, but I don't see what evil I'm protecting
> against by linking with libtclstub84.a versus not linking against
> anything. I do see however that it's costly since now all my Tcl APIs
> are called via a pointer instead of directly. Kind of like a C++ vtbl
> without the compiler having the option of converting virtual calls to
> direct when possible :)
There may not be a cost at all. Resolving links in the dynamic linker
may well be implemented via an indirection, in which case it comes down
to exactly the same. In several OS'es, all system calls go through such
an indirection - I don't think the overhead is noticeable. I agree that
gratuitous vtable calls in C++ are one of the most common mistakes when
designing for maximum performance (and have spent a huge amount of time
myself to avoid all virtual calls I could in MetaKit, coded in C++).
As everything in life, it's a trade-off. From where I stand, stubs are
a no-brainer. Note that stubs are essentially identical to the "COM"
mechanism, and that all Win32 kernels are founded on that mechanism.
-jcw
Donal K. Fellows
> Not exactly. The implication goes the other way:
> if a compiled extension works with Tcl 8.[321] and uses stubs [1],
> then it will continue to work with Tcl 8.4 without recompiling
> or relinking.
Not exactly. ;^) If the extension accesses anything defined in tclInt.h (or is
the Img extension, which has a separate incompatability whose details I do not
recall) then all bets are off, even if it is stub enabled. This is because some
internal structure declarations have changed...
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ donal....@man.ac.uk
-- Short attention span since- ooh! Shiny thing on the floor!
-- Chad R. Orzel <orz...@earthlink.net>
Joe English
>Here's the sliding part where it gets fun. The core is always loaded first
>before extensions, and it's what the extension is loaded into that matters.
>
> if (Tcl_InitStubs(interp, "8.1", 0) == NULL) {
> return TCL_ERROR;
> }
It's usually better to say:
if (Tcl_InitStubs(interp, TCL_VERSION, 0) == NULL) { ... }
instead of specifying an explicit version number...
[ ... ]
> In this one extension I have, I used to use
>Tcl_UniCharNcasecmp(), but found later by accident it would crash in 8.3 upon
>hitting that part of the code. I built it with 8.4, Tcl_InitStubs with 8.1,
>and loaded it into 8.3. What did I do wrong? Tcl_UniCharNcasecmp() got
>introduced in 8.4..
... and that's one of the reasons why.
>There was a time when I used to build against 8.1.0, and use its tclstub81.lib
>and that way I would know for sure about staying to an 8.1 baseline.
That won't work -- the stub library only defines the function
Tcl_InitStubs() and pointer(s) to the stub table(s). So
you won't get any link-time errors if you use 8.4 routines
and link against tclstub81.lib -- in fact, the contents
of tclstub8[1234].lib are identical (I'm not sure why this
library even has a version number, it doesn't change between
releases).
The only reliable way to make sure your extension sticks
with the 8.1 baseline API is to compile against 8.1 headers.
--Joe English
Joe English
>Joe English wrote:
>> Not exactly. The implication goes the other way:
>> if a compiled extension works with Tcl 8.[321] and uses stubs [1],
>> then it will continue to work with Tcl 8.4 without recompiling
>> or relinking.
>
>Not exactly. ;^) If the extension accesses anything defined
>in tclInt.h (or is the Img extension, which has a separate
>incompatability whose details I do not recall) then all bets
>are off, even if it is stub enabled. This is because some
>internal structure declarations have changed...
Isn't that what I said in footnote [1]?
>Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ donal....@man.ac.uk
>-- Short attention span since- ooh! Shiny thing on the floor!
--Joe English
Jeff Hobbs
> Jacob Levy wrote:
>>Not sure I'm understanding. I have an extension (I wrote it -- e4Graph
>>http://e4graph.sourceforge.net/) that doesn't conform to TEA yet nor
>>uses stubs, and it works fine with Tcl 8.4.
>
> (Aside: AFAICT, "conforms to TEA" simply means "works for Jeff Hobbs",
> so you might be TEA-compliant without knowing it :-)
Hee hee ... may be right. Note that TEA and stubs are different issues,
just closely linked. TEA (Tcl Extension Architecture) is all about how
easy it is to build an extension. Stubs is solely about Tcl version
independence for binary extensions.
To be "TEA compliant" ideally means that you use the latest TEA spec,
which is part of the sample extension in cvs in the Tcl SF project.
However, it essentially means that your extension will compile with
'configure ; make' on any platform (including Windows), and that these
have a standard set of options and targets (like recognizing --with-tcl,
--enable-threads, --enable-symbols for configure and install-libraries
and install-binaries targets for make).
One of these days, hopefully soon, I'll update all the web-based TEA
refs and make real TEA packages tarballs to make it easier for users to
rely on the best extension base to build on.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
Join us in Sept. for Tcl'2002: http://www.tcl.tk/community/tcl2002/
Donal K. Fellows
> Isn't that what I said in footnote [1]?
So it was, pretty much. :^/ I blame my jet-lag...
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ donal....@man.ac.uk
-- Short attention span since- ooh! Shiny thing on the floor!
lvi...@yahoo.com
According to Jeff Hobbs <Je...@ActiveState.com>:
:To be "TEA compliant" ...
:... essentially means that your extension will compile with
:'configure ; make' on any platform (including Windows), and that these
:have a standard set of options and targets (like recognizing --with-tcl,
:--enable-threads, --enable-symbols for configure and install-libraries
:and install-binaries targets for make).
I think that it also means that if one of the TEA flags are present,
that the configure will use it in the same manner? That is to say,
that an extension would not be TEA compliant if a user found that
selecting, for example, --with-tcl , required them to point some place
unusual (either the installed lib directory, or the top of the source
code tree for tcl, or whatever).
--
Tcl - The glue of a new generation. <URL: http://wiki.tcl.tk/ >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >
lvi...@yahoo.com
According to Jeff Hobbs <je...@activestate.com>:
[[followed by lots of useful info]]
Jeff, is there a list of at least known working platforms with this release,
or perhaps, more useful, a list of platforms on which it is known 8.4.0
does not work? For instance, we know it doesn't work on a variety of less
used environments like DOS, CP/M, Apple ProDOS, whatever. But is it
safe to assume that it works on all current OS platforms? MVS? MacOS X?
SPARC Solaris? HP-UX? AIX? Linux? Windows 95/98/Me? Windows NT/2k/XP ?
David Gravereaux
>> Some people have said that maintaining source compatibility down to 7.5 is a
>> "feature".
>
>I do that routinely, but I do it by (mostly) limiting my code to
>7.5 features. When I rarely do use later features, I use "forward
>compatibility" techniques (see the Wiki) to provide them to Tcl 7.
This is good. A small "test" extension is showing me some good issues. The
declare proc for genStubs.tcl might need a restriction level. This way one can
place an export prototype and have it blocked off when the Tcl version is under
a minimum without any fuss on part of the developer to help with migration to
Stubs.
declare generic 22 -min 8.0 {
int SomeFunc (Tcl_Obj *in)
}
declare generic 23 -min 8.1 {
Tcl_Obj *SomeOtherFunc (Tcl_Encoding *list[], int count, Tcl_Obj *in)
}
It wouldn't be valid to require the use of Stubs under 8.0 and 7.6, but the
ability for an extension's source to be adaptive is good when using the tools
for providing a Stubs table are used.
More details to come while I play around with this idea.
Jeffrey Hobbs
> According to Jeff Hobbs <Je...@ActiveState.com>:
> :To be "TEA compliant" ...
> :... essentially means that your extension will compile with
> :'configure ; make' on any platform (including Windows), and that these
> :have a standard set of options and targets (like recognizing --with-tcl,
> :--enable-threads, --enable-symbols for configure and install-libraries
> :and install-binaries targets for make).
>
> I think that it also means that if one of the TEA flags are present,
> that the configure will use it in the same manner? That is to say,
Yes - it wouldn't be helpful to have the same flags meaning different
things in different extensions.
Bob Techentin
>
> To be "TEA compliant" ideally means that you use the latest TEA
spec,
> which is part of the sample extension in cvs in the Tcl SF project.
> However, it essentially means that your extension will compile with
> 'configure ; make' on any platform (including Windows), and that
these
> have a standard set of options and targets (like
recognizing --with-tcl,
> --enable-threads, --enable-symbols for configure and
install-libraries
> and install-binaries targets for make).
I haven't thought much about TEA for a year. At that time, I was
trying to copy and edit the sample extension, and I found the whole
thing somewhat vague and a little bit difficult. But then again,
anything having to do with makefiles is difficult (IMHO).
But this past week, I had my first crack at implementing
autoconf/automake as an alternative to a proprietary build system that
we have been using for several years. This is positively arcane. The
whole process depends upon a couple of configuration files. Although
there are "auto-generators" for these files, trolling the
documentation to figure out what options you -really- need is
difficult. But once you get those options figured out, it is actually
pretty cool.
Looking at it now, it appears that I could create Makefile.in and
configure.in from the files supplied in the sample extension. And it
doesn't even look too hard. But is there an automake source for
Makefile.in?
Bob
--
Bob Techentin techenti...@NOSPAMmayo.edu
Mayo Foundation (507) 538-5495
200 First St. SW FAX (507) 284-9171
Rochester MN, 55901 USA http://www.mayo.edu/sppdg/
Jeffrey Hobbs
> I haven't thought much about TEA for a year. At that time, I was
> trying to copy and edit the sample extension, and I found the whole
> thing somewhat vague and a little bit difficult. But then again,
> anything having to do with makefiles is difficult (IMHO).
TEA2 is simpler, perhaps a lot simpler, and all new in that last year.
> But this past week, I had my first crack at implementing
> autoconf/automake as an alternative to a proprietary build system that
> we have been using for several years. This is positively arcane. The
Yes, most people who whine about TEA are single-platform types, and do
not understand the need for the "complexity". TEA is positively simple
compared to other cross-platform build systems, although it doesn't
provide the ease-of-use of a single compiler-and-platform-and-path
specific makefile like makefile.vc.
> whole process depends upon a couple of configuration files. Although
> there are "auto-generators" for these files, trolling the
> documentation to figure out what options you -really- need is
> difficult. But once you get those options figured out, it is actually
> pretty cool.
It would be possible to make an auto-generator for TEA, although I find
that it is easy enough as is. However, having Tcl/Tk around does make
it even easier to make such a tool. We've been thinking about doing it
at least for the TDK, if not in general.
Donal K. Fellows
> Looking at it now, it appears that I could create Makefile.in and
> configure.in from the files supplied in the sample extension. And it
> doesn't even look too hard. But is there an automake source for
> Makefile.in?
(Hmm. That message took a long time to get here.)
We do not support automake at the moment because automake tends to do things
like making sure you've got the GPL license file handy (IIRC from earlier this
year when I was using it.) There's also the horrible morass that is libtool...
Bob Techentin
> Bob Techentin wrote:
> > Looking at it now, it appears that I could create
> > Makefile.in and configure.in from the files
> > supplied in the sample extension. And it doesn't
> > even look too hard. But is there an automake
> > source for Makefile.in?
>
> (Hmm. That message took a long time to get here.)
News server got stuck. It looked like it posted form this end, but
it never went out. (And I was starting to think you just didn't want
to reply to my post. :-)
> We do not support automake at the moment because
> automake tends to do things like making sure you've
> got the GPL license file handy (IIRC from earlier
> this year when I was using it.) There's also the
> horrible morass that is libtool...
Automake has a --foreign option for packages that don't include the
standard GNU files. And thanks for the libtool hint. Oddly, the
documentation doesn't mention the word "morass", but I will be
careful.
Thanks,
Michael Tiller
"Jeffrey Hobbs" <Je...@ActiveState.com> wrote in message
news:3D992921...@ActiveState.com...
> Bob Techentin wrote:
> > I haven't thought much about TEA for a year. At that time, I was
> > trying to copy and edit the sample extension, and I found the whole
> > thing somewhat vague and a little bit difficult. But then again,
> > anything having to do with makefiles is difficult (IMHO).
>
> TEA2 is simpler, perhaps a lot simpler, and all new in that last year.
>
> > But this past week, I had my first crack at implementing
> > autoconf/automake as an alternative to a proprietary build system that
> > we have been using for several years. This is positively arcane. The
>
> Yes, most people who whine about TEA are single-platform types, and do
> not understand the need for the "complexity". TEA is positively simple
> compared to other cross-platform build systems, although it doesn't
> provide the ease-of-use of a single compiler-and-platform-and-path
> specific makefile like makefile.vc.
I guess I fall into the category of "people who whine about TEA" (I've never
been able to get my head around it). When I look at Python's distutils, I
don't see any complexity introduced by cross-platform portability. Why
should TEA be any more complicated?
--
Mike
Michael Schlenker
stuff much more annoying).
TEA2 has ease of use (on windows if cygwin is installed, that is, but
who wants to live without it?), but has some dependencies.
Maybe a simple Tk GUI for the creation of a skeleton TEA config would
lower the barrier for those who hesitate to read all the docs and give
it a try. (Especially those ugly M4 type stuff in use for defining new
command line switches would really be get much nicer with a Tcl/Tk
wizard that just created the stuff from some reasonable language.)
Those files in the sampleextension with _EDIT_HERE_ and so on, just cry
for a GUI or something more sophisticated. Most of autoconfs uglyness
(but not power) is hidden quite well, but we can do better than that...
Better docs, what _exactly_ are the dependencies for TEA to work would
help. One or two simple scripts to install the needed stuff for the
major platforms if not present would be nice too.
Michael Schlenker
David N. Welton
The real answer is this:
http://www.tcl.tk/cgi-bin/tct/tip/59.html
Then we can make our own build tool, at least for extensions.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
Roland Roberts
Donal> We do not support automake at the moment because automake
Donal> tends to do things like making sure you've got the GPL
Donal> license file handy (IIRC from earlier this year when I was
Donal> using it.) There's also the horrible morass that is
Donal> libtool...
As Bob points out, automake has --foreign which can even put stuck at
the top of your Makefile.am as "AUTOMAKE_OPTIONS --foreign". And
although libtool might be a bit sticky, it is infinitely better than
the propriety library build system we have in-house. Of course,
that's a low bar to clear....
roland
--
PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD RL Enterprises
rol...@rlenter.com 76-15 113th Street, Apt 3B
rol...@astrofoto.org Forest Hills, NY 11375
Jeffrey Hobbs
>>Yes, most people who whine about TEA are single-platform types, and do
>>not understand the need for the "complexity". TEA is positively simple
>>compared to other cross-platform build systems, although it doesn't
>>provide the ease-of-use of a single compiler-and-platform-and-path
>>specific makefile like makefile.vc.
>
> I guess I fall into the category of "people who whine about TEA" (I've never
> been able to get my head around it). When I look at Python's distutils, I
> don't see any complexity introduced by cross-platform portability. Why
> should TEA be any more complicated?
distutils made the advantageous assumption that python can be used in full,
which for some reason TEA didn't with respect to Tcl (although it was always
for extensions ...)
I didn't write the first draft so I can't recall the reason why Tcl was not
used. Perhaps T3 will be just that. Of course, we don't want to just jump
right to that point, because then it would be *sooooo* easy to make
extensions for Tcl that people just would be flooding in like mad! ;)
Michael Schlenker
It's part of the answer, but not the complete answer.
This would be very usefull. I have been hit by incorrect tclConfig.sh
more than once... (one Active Tcl 8.3.4.x had a wrong tclConfig.sh
installed (aaargh.), makefile.vc does not build tclConfig.sh, and so on.
Not solving problems for extensions by itself, if they have dependecies
other than tcl.
> Then we can make our own build tool, at least for extensions.
>
We could yes. It could reduce dependencies for building extensions.
Michael Schlenker
Bob Techentin
>
> As Bob points out, automake has --foreign which can even put stuck
at
> the top of your Makefile.am as "AUTOMAKE_OPTIONS --foreign". And
> although libtool might be a bit sticky, it is infinitely better than
> the propriety library build system we have in-house. Of course,
> that's a low bar to clear....
Hmmm. I'm glad you know that, Roland. (Now I know it too.)
I know that part of this thread is discussing TEA distributions and
Tcl-based extension builders, which might help simplify uniform
extension building, but the underlying technology appears to be GNU's
build tools.
Since it seems that some of y'all have experience with these arcane
build tools, I wondered if you knew of any particularly good resources
for learning to use them. I've tried reading the online docs at
gnu.org, and I've seen the GNU Autoconf, Automake, and Libtool book by
Vaughn et. al. (http://sources.redhat.com/autobook/). Are there other
resources?
Thanks,
Andreas Kupries
> The real answer is this:
>
> http://www.tcl.tk/cgi-bin/tct/tip/59.html
>
> Then we can make our own build tool, at least for extensions.
There are some ideas floating around (1) regarding [package] which
partially invalidate TIP 59 ...
Namely a [package about] subcommand which can be used to set and query
an arbitrary number of meta-information about a package. This would be
a more general way of providing meta information for all packages
installed on a particular system.
The main change to TIP 59 (2) would be a move from the specified
method of embedding the information to a different method using a C
API to [package about]. Other packages could use the same method, ort
simply provide the relevant commands as part of the index scripts (in
pkgIndex.tcl).
~~
(1) Informal discussion between various people at the Tcl conference.
(2) AS TIP 59 is already accepted it cannot be changed. A new TIP
would have to be written which obsoletes #59. Given that #59 is
not yet final this is should be relatively easy to accomplish.
('final' means that the implementation is committed to CVS. There
is an implementation, but it currently lives in its own
experimental branch of the tcl core. So modifying this without
affecting other parts is no problem.)
--
Sincerely,
Andreas Kupries <akup...@shaw.ca>
Developer @ <http://www.activestate.com/>
Private <http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------
}
Mark G. Saye
> There are some ideas floating around (1) regarding [package] which
> partially invalidate TIP 59 ...
>
> Namely a [package about] subcommand which can be used to set and query
> an arbitrary number of meta-information about a package. This would be
> a more general way of providing meta information for all packages
> installed on a particular system.
>
> The main change to TIP 59 (2) would be a move from the specified
> method of embedding the information to a different method using a C
> API to [package about]. Other packages could use the same method, ort
> simply provide the relevant commands as part of the index scripts (in
> pkgIndex.tcl).
Are you suggesting an adoption of the format in TIP55? i.e. a
DESCRIPTION.txt file
Also, I might prefer the command [package info ...]. Just a personal
preference ...
When I have some time (!), I would like to help rework the [package]
command to include TIP55 recommendations for meta-data, CanTcl
compliance and package installation, etc. Anybody else interested?
Mark /
--
Mark G. Saye
mark...@yahoo.com
Donal K. Fellows
> It's part of the answer, but not the complete answer.
If we had a *complete* answer, would we be having this discussion? ;^)
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ donal....@man.ac.uk
-- Of course, she was referring not to the current but to a past chair, unless
Babbage is very, very old, *and* tied to a chair in Hawking's basement.
Which, admittedly, would be pretty cool. -- Chris Hammock
Donal K. Fellows
> Maybe a simple Tk GUI for the creation of a skeleton TEA config would
> lower the barrier for those who hesitate to read all the docs and give
> it a try. (Especially those ugly M4 type stuff in use for defining new
> command line switches would really be get much nicer with a Tcl/Tk
> wizard that just created the stuff from some reasonable language.)
>
> Those files in the sampleextension with _EDIT_HERE_ and so on, just cry
> for a GUI or something more sophisticated. Most of autoconfs uglyness
> (but not power) is hidden quite well, but we can do better than that...
Good idea. I'm working on something to do this as I write this...
Steve Cassidy
> Andreas Kupries wrote:
>> There are some ideas floating around (1) regarding [package] which
>> partially invalidate TIP 59 ...
>>
>> Namely a [package about] subcommand ...
>
> Are you suggesting an adoption of the format in TIP55? i.e. a
> DESCRIPTION.txt file
>
> Also, I might prefer the command [package info ...]. Just a personal
> preference ...
>
> When I have some time (!), I would like to help rework the [package]
> command to include TIP55 recommendations for meta-data, CanTcl
> compliance and package installation, etc. Anybody else interested?
Sounds like a great idea. Other things that folk might think about:
- write a DESCRIPTION.txt file for your favourite package (including the
core pacakges) and turn them into TIP55 packages
- add a 'package' target to TEA2 to build a TIP55 package
- work out how to sign packages so we can have a level of trust in
packages sourced from CANTCL
- work out how a network of CANTCL servers should talk with each other
The source of CANTCL is available as the installer package, I have a
sourceforge project established for it but haven't gotten around to
uploading anything yet. However I'm very keen to get others involved
with the development of this project.
Steve
Donal K. Fellows
> Michael Schlenker wrote:
>> Those files in the sampleextension with _EDIT_HERE_ and so on, just cry
>> for a GUI or something more sophisticated. Most of autoconfs uglyness
>> (but not power) is hidden quite well, but we can do better than that...
>
> Good idea. I'm working on something to do this as I write this...
Right, http://www.cs.man.ac.uk/~fellowsd/tcl/teapot.tcl is my current attempt at
doing this. Note that this is very much a work-in-progress, but it still might
be interesting to people...
Andreas Kupries
> Andreas Kupries wrote:
> > There are some ideas floating around (1) regarding [package] which
> > partially invalidate TIP 59 ...
> > Namely a [package about] subcommand which can be used to set and
> > query
> > an arbitrary number of meta-information about a package. This would be
> > a more general way of providing meta information for all packages
> > installed on a particular system.
> > The main change to TIP 59 (2) would be a move from the specified
> > method of embedding the information to a different method using a C
> > API to [package about]. Other packages could use the same method, ort
> > simply provide the relevant commands as part of the index scripts (in
> > pkgIndex.tcl).
>
> Are you suggesting an adoption of the format in TIP55? i.e. a
> DESCRIPTION.txt file
Not quite. So far as we have thought [package about] will allow usage
of any string as key, instead imposing a fixed/hardwired collection on
the user. Standards for useable keys/meta-information would evolve
outside/beside of this. TIP 59 based information for example would
help builders of other packages making use of the package. TIP 55
based information is more geared towards cataloguing and installation
management. There might be other information about packages we are
currently unable to see.
> Also, I might prefer the command [package info ...]. Just a personal
> preference ...
[info] is something I see more as an introspection thing, state of the
interpreter and such. [package about] is more something outside of the
interpreter itself.
> When I have some time (!), I would like to help rework the [package]
> command to include TIP55 recommendations for meta-data, CanTcl
> compliance and package installation, etc. Anybody else interested?
--
Dan Smart
news:3D9AB864...@man.ac.uk:
> Michael Schlenker wrote:
>> It's part of the answer, but not the complete answer.
>
> If we had a *complete* answer, would we be having this discussion? ;^)
>
> Donal.
Almost certainly, although it would likely be far more heated, as the
participants would be divided into two camps:
Those with the *complete answer*, who are ready and willing to defend it
against all-comers.
Those whose favourite thing is not obviously addressed by "the complete
answer", and who are very unhappy about it...
Oh, and me...
Dan "My favourite thing is never addressed..." Smart
--
Dan Smart. C++ Programming and Mentoring.
cpp...@dansmart.com
ADDvantaged
Donal K. Fellows
> Donal K. Fellows:
>> If we had a *complete* answer, would we be having this discussion? ;^)
> participants would be divided into two camps:
> against all-comers.
> * Those whose favourite thing is not obviously addressed by "the complete
> answer", and who are very unhappy about it...
But the existence of the latter group proves that the answer is not truly
complete, and hence that the premise of the conditional is not satisfied. ;^)
Build-and-Deploy is the second thorniest problem in software engineering. Mind
you, the nastiest problem is "People, whether programmers, users, admins or
management".
Michael Schlenker
> Dan Smart wrote:
>
>>Donal K. Fellows:
>>
>>>If we had a *complete* answer, would we be having this discussion? ;^)
>>
>>Almost certainly, although it would likely be far more heated, as the
>>participants would be divided into two camps:
>> * Those with the *complete answer*, who are ready and willing to defend it
>> against all-comers.
>> * Those whose favourite thing is not obviously addressed by "the complete
>> answer", and who are very unhappy about it...
>
>
> But the existence of the latter group proves that the answer is not truly
> complete, and hence that the premise of the conditional is not satisfied. ;^)
the true answer means have failed.
Perhaps answers that are more complex than "42" can not be comprehended
by the human mind :-))
Michael
Cameron Laird
Donal K. Fellows <donal.k...@man.ac.uk> wrote:
.
.
.
>Build-and-Deploy is the second thorniest problem in software engineering. Mind
>you, the nastiest problem is "People, whether programmers, users, admins or
>management".
.
.
Yet another reason to hang out in the Tcl neighborhood.
That is, the Tcl community is, from all I know, doing
more interesting work on deployment than any other.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
lvi...@yahoo.com
According to Andreas Kupries <akup...@shaw.ca>:
:Not quite. So far as we have thought [package about] will allow usage
:of any string as key, instead imposing a fixed/hardwired collection on
:the user. Standards for useable keys/meta-information would evolve
:outside/beside of this.
So the facility would be a general one, upon which one would build
the structure for specific uses of the facility. Installation for instance
would not care about licensing, but someone else might...
Andreas Kupries
> According to Andreas Kupries <akup...@shaw.ca>:
> :Not quite. So far as we have thought [package about] will allow usage
> :of any string as key, instead imposing a fixed/hardwired collection on
> :the user. Standards for useable keys/meta-information would evolve
> :outside/beside of this.
>
> So the facility would be a general one, upon which one would build
> the structure for specific uses of the facility. Installation for instance
> would not care about licensing, but someone else might...
Correct.