Dear XOTcl community,
the results of the poll can be summarized as follows: - most people favored "names" instead of "symbols" for "selfDispatch" - the hottest favorite is "my". One can write now
... my instvar a b c my log ...
instead of ... [self] instvar a b c [self] log ...
the variant with [self] will continue to work forever.. If someone is not happy with "my", please react soon.
From the "volatile" front: we have now more-or-less Zoran suggestion implemented in C. Actually there is no need in general for using tcl-variables to implement volatile objects (we could handle this on a pop of stack frames), but at least for pure tcl-procs, var traces are the simplest implementation. The current implementation (purely in C) works as part of the "new" method:
a) Object new ... b) Object new -childof ... c) Object new -volatile ... d) Object new -volatile -childof ...
(a) creates "global" objects, not in the global namespace anymore, but in xotcl. (b) can be used to create objects as child of other objects (e.g. [self], the objects are deleted, when the specified object is deleted), (c) are "global" objects as in (a), but they are deleted, when the current tcl-proc/object-proc/instproc is left, and (d) is a combination of b and c.
Needless to say, a-d works for classes as well as e.g.
Class new -volatile
in order to create "anonymoes" classes. The implementation of new is slightly faster than before, since i changed the nameing schema to be the same for all kind new ("__#122", ...), such that e.g. [Class new -volatile] new -volatile works as well. the disadvantage is that the neat classname derived names as in earlier versions have to be done by hand now...
that was it for now
best regrads -gustaf
On Monday 04 March 2002 14:08, Gustaf Neumann wrote:
From the "volatile" front: we have now more-or-less Zoran
Smile !
suggestion implemented in C. Actually there is no need in general for using tcl-variables to implement volatile objects (we could handle this on a pop of stack frames), but at least for pure tcl-procs, var traces are the simplest implementation. The current implementation (purely in C)
It is not clear: does the C implementation use internal stack for garbage collection or the Tcl-trace variable mechansim? It is important to know when doing (or not doing!) such constructs:
Class foo foo instproc test args {}
[foo new -volatile] test ; # object leak ?
In case of volatile implementation with var traces, one should do:
set bar [foo new -volatile] $bar test
to be sure that when "bar" is unset, the object goes away.
So, which way is it?
Cheer's Zoran
On Monday 04 March 2002 18:21, Zoran Vasiljevic wrote:
suggestion implemented in C. Actually there is no need in general for using tcl-variables to implement volatile objects (we could handle this on a pop of stack frames), but at least for pure tcl-procs, var traces are the simplest implementation. The current implementation (purely in C)
It is not clear: does the C implementation use internal stack for garbage collection or the Tcl-trace variable mechansim?
the var-trace mechanism
It is important to know when doing (or not doing!) such constructs:
Class foo foo instproc test args {}
[foo new -volatile] test ; # object leak ?
this sets as a side effect a tcl variable in the current scope. if the scope is e.g. a tcl proc, it will be automatially unset, when the scope is left.
In case of volatile implementation with var traces, one should do:
set bar [foo new -volatile] $bar test
Note, that this is essentially the same as above. the call of [foo new] cannot set a vartrace on the "bar" variable. The result of the "new" is a tcl_obj, and not a variable. the tcl_obj is bound to the variable bar... so, the magic of the object deletion happens via another variable, that is set as a side effect. these magic variables are named similarly to the object name: in the example
set bar [foo new -volatile]
the objname will be ::xotcl::__#1 (or ...__#2, etc), the magic variable is __#1. therefore, one can refer from the object name to the variable name via
set vn [namespace tail $bar] unset $vn
will trigger the deletion of the object created with new. There is a potential danger of name conflics, but if one follows the rule: don't start user-variable names with "__", everyting will be safe.
I have used this example with the manual unset for explanatory purposes. Under most conditions you will not need to unset the magic variable by hand....
hope that this explains the details.
best regrads -gustaf
Hello! :)
How it must works, when in pre/post part of filter object calls his procs that calls next? Situation like here:
Class A A instproc msg msg { puts "puts: $msg" }
Class B -superclass A B instproc msg msg { next }
B instproc my_filter args { my msg "before next in filter" next }
B b
b filter my_filter b msg bb puts: before next in filter
that's all!: there is no "puts: bb".
if filter like this:
B instproc my_filter args { my msg "before next in filter" next my msg "after next in filter" }
then: "too many nested calls to Tcl_EvalObj"
Thank you.
Hi Andriy,
this was a little bug. We have closed down the filter chain upon the "msg" method but the filter was not done with its own next. I'll attach an xotcl.c file that should fix the problem (the fix will also be in the next xotcl release ... but as this is a quite unusual case we don't produce a full patch release for this fix). Simply replace the xotcl.c file in the distribution and re-compile ...
--uwe
On Wednesday 17 April 2002 05:46 pm, Andriy Tkachuk wrote:
Hello! :)
How it must works, when in pre/post part of filter object calls his procs that calls next? Situation like here:
Class A A instproc msg msg { puts "puts: $msg" }
Class B -superclass A B instproc msg msg { next }
B instproc my_filter args { my msg "before next in filter" next }
B b
b filter my_filter b msg bb puts: before next in filter
that's all!: there is no "puts: bb".
if filter like this:
B instproc my_filter args { my msg "before next in filter" next my msg "after next in filter" }
then: "too many nested calls to Tcl_EvalObj"
Thank you.
Xotcl mailing list - Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
thank you very mutch!
andriy.
On Fri, 19 Apr 2002, Uwe Zdun wrote:
Hi Andriy,
this was a little bug. We have closed down the filter chain upon the "msg" method but the filter was not done with its own next. I'll attach an xotcl.c file that should fix the problem (the fix will also be in the next xotcl release ... but as this is a quite unusual case we don't produce a full patch release for this fix). Simply replace the xotcl.c file in the distribution and re-compile ...
--uwe
On Wednesday 17 April 2002 05:46 pm, Andriy Tkachuk wrote:
Hello! :)
How it must works, when in pre/post part of filter object calls his procs that calls next? Situation like here:
Class A A instproc msg msg { puts "puts: $msg" }
Class B -superclass A B instproc msg msg { next }
B instproc my_filter args { my msg "before next in filter" next }
B b
b filter my_filter b msg bb puts: before next in filter
that's all!: there is no "puts: bb".
if filter like this:
B instproc my_filter args { my msg "before next in filter" next my msg "after next in filter" }
then: "too many nested calls to Tcl_EvalObj"
Thank you.
Xotcl mailing list - Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
-- Because strait is the gate, and narrow is the way, which leadeth unto <b>life</b>, and few there be that find it. (MAT 7:7) <b>Ask</b>, and it shall be given you; <b>seek</b>, and ye shall find; <b>knock</b>, and it shall be opened unto you... (MAT 7:14)
hello!
it seems yet another bug with this theme: if there are several filters:
Class A A instproc msg args { puts [concat A: $args] next }
Class B -superclass A B instproc msg args { my instvar a b puts [concat B: $args] next }
B instproc my_filter args { set ff [my info filter] puts "filter: calledproc: [self calledproc]; args: $args" my msg "in filter before next; calledproc: [self calledproc]" set res [next] #my msg "in filter after next; calledproc: [self calledproc]" return $res }
B instproc my_filter2 args { return [next] }
B b
b filter {my_filter my_filter2}
xotclsh [/usr~]b msg bb filter: calledproc: msg; args: bb B: {in filter before next; calledproc: msg} B: {in filter before next; calledproc: msg} A: {in filter before next; calledproc: msg} xotclsh [/usr~]
if uncomment in my_filter msg in post-next part, then: "too many nested calls to Tcl_EvalObj"
thanks, Andriy.
On Fri, 19 Apr 2002, Uwe Zdun wrote:
Hi Andriy,
this was a little bug. We have closed down the filter chain upon the "msg" method but the filter was not done with its own next. I'll attach an xotcl.c file that should fix the problem (the fix will also be in the next xotcl release ... but as this is a quite unusual case we don't produce a full patch release for this fix). Simply replace the xotcl.c file in the distribution and re-compile ...
--uwe
On Wednesday 17 April 2002 05:46 pm, Andriy Tkachuk wrote:
Hello! :)
How it must works, when in pre/post part of filter object calls his procs that calls next? Situation like here:
Class A A instproc msg msg { puts "puts: $msg" }
Class B -superclass A B instproc msg msg { next }
B instproc my_filter args { my msg "before next in filter" next }
B b
b filter my_filter b msg bb puts: before next in filter
that's all!: there is no "puts: bb".
if filter like this:
B instproc my_filter args { my msg "before next in filter" next my msg "after next in filter" }
then: "too many nested calls to Tcl_EvalObj"
Thank you.
Xotcl mailing list - Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
-- Because strait is the gate, and narrow is the way, which leadeth unto <b>life</b>, and few there be that find it. (MAT 7:7) <b>Ask</b>, and it shall be given you; <b>seek</b>, and ye shall find; <b>knock</b>, and it shall be opened unto you... (MAT 7:14)
Bugs in 0.9.3 and 0.9.4 for threaded (including AOLserver) builds. The problem is that in Tcl, a strong marriage between the Tcl interpreter and its accompaniyg thread exists.
Each time a new Tcl thread is starting, it may (AOLserver will!) load the XOTcl_Init routine. This will patch couple of the standard Tcl commands using the TclCommands function. This function had an internal static counter, tracking number of calls. On thread exit, this procedure was called again and it did a reverse, replacing patched pointers with original ones.
TclCommands(Tcl_Interp* in, int load) { int rc = TCL_OK; if (load) { #ifdef USE_TCL_STUBS rc|= XOTclReplaceCommand(in, EXPR, 0, 0); rc|= XOTclReplaceCommand(in, INCR, 0, 0); #endif rc|= XOTclReplaceCommand(in, SUBST, 0, SUBST_CMD); rc|= XOTclReplaceCommand(in, INFO, XOTcl_InfoObjCmd, 0); rc|= XOTclReplaceCommand(in, RENAME, XOTcl_RenameObjCmd, 0); rc|= XOTclReplaceCommand(in, UPLEVEL, XOTcl_UplevelObjCmd, 0); rc|= XOTclReplaceCommand(in, UPVAR, XOTcl_UpvarObjCmd, 0); } else { rc|= XOTclReplaceCommandCleanup(in, INFO); rc|= XOTclReplaceCommandCleanup(in, RENAME); rc|= XOTclReplaceCommandCleanup(in, UPLEVEL); rc|= XOTclReplaceCommandCleanup(in, UPVAR); } return rc; }
the results of the poll can be summarized as follows:
most people favored "names" instead of "symbols" for "selfDispatch"
the hottest favorite is "my". One can write now
... my instvar a b c my log ...
instead of ... [self] instvar a b c [self] log ...
the variant with [self] will continue to work forever.. If someone is not happy with "my", please react soon.
From the "volatile" front: we have now more-or-less Zoran suggestion implemented in C. Actually there is no need in general for using tcl-variables to implement volatile objects (we could handle this on a pop of stack frames), but at least for pure tcl-procs, var traces are the simplest implementation. The current implementation (purely in C) works as part of the "new" method:
a) Object new ... b) Object new -childof ... c) Object new -volatile ... d) Object new -volatile -childof ...(a) creates "global" objects, not in the global namespace anymore, but in xotcl. (b) can be used to create objects as child of other objects (e.g. [self], the objects are deleted, when the specified object is deleted), (c) are "global" objects as in (a), but they are deleted, when the current tcl-proc/object-proc/instproc is left, and (d) is a combination of b and c.
Needless to say, a-d works for classes as well as e.g.
Class new -volatile
in order to create "anonymoes" classes. The implementation of new is slightly faster than before, since i changed the nameing schema to be the same for all kind new ("__#122", ...), such that e.g. [Class new -volatile] new -volatile works as well. the disadvantage is that the neat classname derived names as in earlier versions have to be done by hand now...
that was it for now
best regrads -gustaf _______________________________________________ Xotcl mailing list - Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
On Sunday 10 March 2002 13:18, Zoran Vasiljevic wrote:
Bugs in 0.9.3 and 0.9.4 for threaded (including AOLserver) builds.
Sorry for the confusion. This has somehow left my mailboxox before being written to end. There is however a big problem in XOTcl 0.9.3 and 0.9.4 in respect to thread-support which I'm going to describe and report shortly. This will, of course, be under different subject.
Again, sorry for this little glitch. Zoran
-
Andriy Tkachuk -
Gustaf Neumann -
Uwe Zdun -
Zoran Vasiljevic