below is the code used for testing:
MOX_ ... is the internal name from me for various tcl api-types
RL_ ... is a helper to build the objc/objv array to finally call the Tcl_EvalObjv api-command

int NS(_IncrIndex1) (OBJCMD_ARGS) {
MOX_SETUP_hdl_static;
if (objc < (1+__skip) || objc > (2+__skip)) {
Tcl_WrongNumArgs(interp,__skip,objv,"... expect: varName ?increment?");
return TCL_ERROR;
}
MOX_OBJ_T varNameO = objv[__skip++];
MOX_OBJ_T incrO = __skip < objc ? objv[__skip++] : NULL;
int incrI=1;
if (incrO) {
if (Tcl_GetIntFromObj(interp,incrO,&incrI) == TCL_ERROR) return TCL_ERROR;
}
MOX_OBJ_T varO = Tcl_ObjGetVar2(interp,varNameO,NULL,TCL_LEAVE_ERR_MSG);
if (varO == NULL) return TCL_ERROR;
int varI;
if (Tcl_GetIntFromObj(interp,varO,&varI) == TCL_ERROR) return TCL_ERROR;
MOX_OBJ_T newO = Tcl_ObjSetVar2(interp,varNameO,NULL, Tcl_NewIntObj(varI+incrI), TCL_LEAVE_ERR_MSG);
if (newO== NULL) return TCL_ERROR;
Tcl_SetObjResult(interp,newO);
return TCL_OK;
};
MoxObjDelete(_IncrIndex1);

int NS(_IncrIndex2) (OBJCMD_ARGS) {
MOX_SETUP_hdl_static;
if (objc < (1+__skip) || objc > (2+__skip)) {
Tcl_WrongNumArgs(interp,__skip,objv,"... expect: varName ?increment?");
return TCL_ERROR;
}
if (objc == 2) {
RL_init( 2, RL_NewS(0,"incr") ) ; RL_O(1,objv[1]) ;
return RL_EvalEx(TCL_LEAVE_ERR_MSG);
} else {
RL_init( 3, RL_NewS(0,"incr") ) ; RL_O(1,objv[1]) ; RL_O(2,objv[2]) ;
return RL_EvalEx(TCL_LEAVE_ERR_MSG);
}
};
MoxObjDelete(_IncrIndex2);

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

what happened to the tcl "C" api?

i remember that about 20 years ago, when i wrote the tcl-c compiler, the language "tcl" was the language with one of the best
"c" api support. back then, not only the "public" documented c api could be used but also the semi-public api where every tcl
command was accessible with "tcl_?Cmd?ObjCmd" (e.g. Tcl_IncrObjCmd for "incr").

today almost the entire tcl api is "private" and therefore unusable for the extension writer. This means that a simple command
like "incr" which already has a "C" API in Tcl can only be called via Tcl-EvalXX OR has to be laboriously reconstructed from the
Tcl source code using "copy-past". The reason for the (make everything private mode) seems to be the "stubs" subsystem where
every API function has to be exported using Tcl's internal "table")

Here are some numbers
1) is a version of "incr" that works using the "limited public tcl-c-api "Tcl_ObjGetVar/SetVar" etc
2) is a version that works using "Tcl_Eval"

even WITHOUT the direct use of "Tcl_IncrObjCmd" the "handwritten" solution is better than the Tcl_Eval solution. I rate the

NON-exported Tcl_IncrObjCmd solution as MUCH better than my "hand-written" solution.

and now the summary: Question: Why did the TCL community "throw away" TCL's massive technological lead just to become one of

the slowest languages ​​ever?


# modification via PUBLIC tcl-api
set start1 0

0

::myooX::_IncrIndex1 start1

1

::myooX::_IncrIndex1 start1 2

3

::myooX::_IncrIndex1 start1 -1

2

set start1

2

# modification via tcl-eval-api
set start2 0

0

::myooX::_IncrIndex2 start2

1

::myooX::_IncrIndex2 start2 2

3

::myooX::_IncrIndex2 start2 -1

2

set start2

2

time { ::myooX::_IncrIndex1 start1 } 1000

0.84 microseconds per iteration

time { ::myooX::_IncrIndex2 start2 } 1000

0.983 microseconds per iteration

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

aotto1968 <aotto1968@t-online.de> posted:

what happened to the tcl "C" api?

i remember that about 20 years ago, when i wrote the tcl-c compiler, the language "tcl" was the language with one of the best
"c" api support. back then, not only the "public" documented c api could be used but also the semi-public api where every tcl
command was accessible with "tcl_?Cmd?ObjCmd" (e.g. Tcl_IncrObjCmd for "incr").

today almost the entire tcl api is "private" and therefore unusable for the extension writer. This means that a simple command
like "incr" which already has a "C" API in Tcl can only be called via Tcl-EvalXX OR has to be laboriously reconstructed from the
Tcl source code using "copy-past". The reason for the (make everything private mode) seems to be the "stubs" subsystem where
every API function has to be exported using Tcl's internal "table")

Here are some numbers
1) is a version of "incr" that works using the "limited public tcl-c-api "Tcl_ObjGetVar/SetVar" etc
2) is a version that works using "Tcl_Eval"

even WITHOUT the direct use of "Tcl_IncrObjCmd" the "handwritten" solution is better than the Tcl_Eval solution. I rate the

NON-exported Tcl_IncrObjCmd solution as MUCH better than my "hand-written" solution.

and now the summary: Question: Why did the TCL community "throw away" TCL's massive technological lead just to become one of

the slowest languages ​​ever?

Hello Andreas,

could you go into detail about how you achieved access to Tcl_ObjGetVar, Tcl_ObjSetVar, and so on from you code via MOX_? I'm curious about this because I wouldn't know how to really do this myself.

At an abstract level, my first thought would be that if Tcl_IncrObjCmd is an exported function the implementation has to be in a different file. However, it doesn't seem obvious to me why you wouldn't be able to link to that other file with the compiler.


With best regards,

Martin (m0h)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)