Regular expression code implementation review between Tcl vs Python

David Gravereaux davygrvy at pobox.com
Wed Nov 12 17:38:08 EST 2003


Google_Post at slink-software.com (K_Lee) wrote:

>David Gravereaux <davygrvy at pobox.com> wrote in message news:<tph3rvsru37i0b86jr1s4egr3bdvjqitrm at 4ax.com>...
>> Google_Post at slink-software.com (K_Lee) wrote:
>> 
>> >I guess the TCL original goal was also to support
>> >Win16, DOS, etc.
>> 
>> No it wasn't.  Given whatever core an extension is loaded into, the
>> extension grabs the function table from the core it is loaded into.
>> 
>> Say for example I build all of Tcl statically into my application (kinda
>> dumb, but let's just say).  If I try to load an extension into it, where is
>> it supposed to get the Tcl functions it needs?  Do you see the issue Stubs
>> solves?
>> 
>
>
>Ok, David,  I understand better now.  
>
>(Putting on my monday morning quarterback hat.) 
>
>If the original design specifies that 
>    * If you load extension with .so/dll, you are required 
>    load tcl from .so/dll.
>then we can get rid the stub interface, right?

Yes, I think so.  But still extensions would get locked to a named shared
library.  For example, loading a BLT extension which was linked against
tcl83.lib (implicit) into tclsh84 will breach and crash.  Either way with
or without Stubs, implicit linking is still available.  The EXTERN macro in
the prototypes exports them all.

>That doesn't sound like an unreasonable requirement for 
>people who use any tcl + extension.

It's real easy to use, though.
1) compile with -DUSE_TCL_STUBS and link with tclstub8X.(lib|a)
2) Use this in the extension's exported *_Init as the first call:

 #ifdef USE_TCL_STUBS
    if (Tcl_InitStubs(interp, TCL_VERSION, 0) == NULL) {
	return TCL_ERROR;
    }
 #endif

Beyond that, you don't need to think about it.  You can even extend the
Stubs concept for applications that embed Tcl.  Steps would be:

0) same as #1 above.
1) Knowing the path to a certain Tcl dll/so at or greater than the version
you require, dlopen/LoadLibrary it.
2) Get the address for Tcl_CreateInterp from the outside with
dlsym/GetProcAddress
3) make the first interp
4) call Tcl_InitStubs (code from tclstub8x.(lib|a) in us)
5) call Tcl_FindExecutable (very important!)
6) Done, function table loaded. Tcl_DeleteInterp or use it...  You have
avoided 880 (or more) GetProcAddress calls to fill your own tables.  Before
Stubs came around, I was guilty of doing that :)

Now you have an application that is upgradable from the outside, given that
the path to the Tcl dll/so is settable or auto-discovered in some manner.

>I still think Tcl'folks did a great jobs, just like to know the
>trade off vs. features better.

It gets even better with extensions that export a Stubs table.  You can
build extensions for extensions :)  Witness:

 #undef TCL_STORAGE_CLASS
 #define TCL_STORAGE_CLASS DLLEXPORT

 EXTERN int
 Gui_irc_Init (Tcl_Interp *interp)
 {
 #ifdef USE_TCL_STUBS
    if (Tcl_InitStubs(interp, "8.3", 0) == NULL) {
	return TCL_ERROR;
    }
 #endif
 #ifdef USE_ITCL_STUBS
    if (Itcl_InitStubs(interp, "3.1", 0) == NULL) {
	return TCL_ERROR;
    }
 #endif
    new IRCWindowsItclAdapter(interp);
    return TCL_OK;
 }

Using the services of [Incr Tcl] as well as Tcl, that extension declares
class methods for this script:

 itcl::class IRC::ui {
    constructor {args} {
	_initUI
    }
    destructor {
	_destroyUI
    }
    public {
	method destroy {} {itcl::delete object $this}
	method echo {} @irc-ui-echo
 	method window {} @irc-ui-window
	method menu {} @irc-ui-menu
	method hotkey {} @irc-ui-hotkey
	method alias {} @irc-ui-alias
	method channel {} @irc-ui-channel
	method query {} @irc-ui-query
	method chat {} @irc-ui-chat
	method queries {} @irc-ui-queries
	method chats {} @irc-ui-chats
	method say {} @irc-ui-say
	method input {} @irc-ui-input
    }
    private {
	method _initUI {} @irc-ui-construct
	method _destroyUI {} @irc-ui-destruct
    }
 }

The '@irc-ui-*' names refer to Tcl_CmdObjProcs set by the extension with
Itcl_RegisterObjC().  IMO, Stubs does not stop at the core.

>K Lee

-- 
David Gravereaux <davygrvy at pobox.com>
[species: human; planet: earth,milkyway(western spiral arm),alpha sector]




More information about the Python-list mailing list