Re: [Xotcl] Bug in filter processing?

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Sun, 29 Aug 2010 14:09:37 +0200

  ... forgot to mention:
You have to return the result of "next" as return of the filter (in the
case of your example $r).

all the best
-gustaf neumann

Am 29.08.10 13:54, schrieb Gustaf Neumann:
> Dear Kristoffer,
>
> many things went wrong. It is true, there is a bug in all XOTcl 1.*
> releases,
> which is there most likely since many years (8+).
>
> the bug:
>
> - when a filter chain comes to its end without finding the method
> (e.g. "ob foo"), xotcl records its fact, but this affected as well
> the method invocations from the filter after the "next".
>
> - The call "$targetclass info ..." was then letal especially
> with the standard unknown handler of the metaclass:
> xotcl belived incorrectly that "info" is unknown, and
> since an "unknown" call on a class (here $targetclass)
> creates an object, it was creating the object "info"
> as instance of that class, and the nightmare turned
> even worse.
>
> I have fixed the bug in 1.6.6, you can obtain it via
>
> git clone git://alice.wu-wien.ac.at/xotcl
>
> best regards
> -gustaf neumann
>
> Am 29.08.10 03:02, schrieb Kristoffer Lawson:
>> Take a look at this code:
>>
>> package require XOTcl 1.6
>> namespace import xotcl::*
>>
>> Class Foo
>>
>> Foo instproc hello {} {
>> puts hello
>> }
>>
>> Foo instproc myfilter {args} {
>> puts "\nme: [self]"
>> ::set targetclass [my info class]
>> puts "targetclass: $targetclass"
>> puts "calledproc: [self calledproc]"
>> ::set r [next]
>> puts "back from next"
>> puts "paramcmds: [$targetclass info instparametercmd]"
>> }
>>
>> Foo instfilter myfilter
>>
>> Foo ob
>> ob hello
>> ob foo
>>
>>
>> So first I have a filter installed which does nothing but print some
>> information, and checks something using the [info] method afterwards.
>> I call an instantiated object with [hello] (an existing method) and
>> again with [foo] (a non-existing method). The latter is when things
>> get interesting. Check the output:
>>
>>
>> me: ::ob
>> targetclass: ::Foo
>> calledproc: configure
>> back from next
>> paramcmds:
>>
>> me: ::ob
>> targetclass: ::Foo
>> calledproc: init
>> back from next
>> paramcmds:
>>
>> me: ::ob
>> targetclass: ::Foo
>> calledproc: hello
>> hello
>> back from next
>> paramcmds:
>>
>> me: ::ob
>> targetclass: ::Foo
>> calledproc: foo
>> back from next
>>
>> me: ::alloc
>> ::alloc: unable to dispatch method 'info'
>> while executing
>> "my info class"
>> (procedure "cleanup" line 4)
>> ::alloc ::Foo->myfilter
>> ::Foo ::xotcl::Class->recreate
>> ::Foo ::xotcl::Class->create
>> ::Foo ::xotcl::Class->unknown
>> ::Foo ::xotcl::Class->create
>> ::Foo ::xotcl::Class->unknown
>> ::Foo ::xotcl::Class->create
>> ::Foo ::xotcl::Class->unknown
>> invoked from within
>> "$targetclass info instparametercmd"
>> (procedure "foo" line 9)
>> ::ob ::Foo->myfilter
>> invoked from within
>> "ob foo"
>> (file "filtertest.tcl" line 24)
>>
>> me: ::alloc
>> targetclass: ::Foo
>> calledproc: destroy
>> back from next
>> paramcmds:
>>
>> me: ::info
>> targetclass: ::Foo
>> calledproc: destroy
>> back from next
>> paramcmds:
>>
>> me: ::ob
>> targetclass: ::Foo
>> calledproc: destroy
>> back from next
>> paramcmds:
>>
>> ...
>> So while the [hello] method works as expected, things get totally
>> weird for [foo]. The first thing we notice is that it doesn't jump
>> out at [next] (which should give an error as it does not exist). It
>> continue execution of the filter after [next]. This may or may not be
>> intended, I don't know. The documentation is not clear on this.
>>
>> More interesting still, we end up with a totally unexpected error.
>> The thing I believe is happening is that, for some reason or other
>> [$targetclass info instparametercmd] is not ending up calling [info]
>> for $targetClass, but creating an object called ::info (and thus
>> overriding the original Tcl command). How [alloc] gets involved in
>> the filter chain too, I am not sure. My guess is that the "unknown
>> method" that resulted from [foo] is being interpreted by the XOTcl
>> $targetclass C implementation as an error that occurred there, and
>> that a new instance called "info" or possibly "alloc" should be created.
>>
>> This causes major havoc as soon as an unknown method is called. Does
>> the filter code look correct?
>>
>> This happens with 1.6.2. I had a quick look at CHANGES for later
>> versions and while there was some mention of memory leaks in [info] I
>> wasn't sure if there was anything that would have fixed this.
>>
>> Any ideas?
>>
>
>

-- 
Univ.Prof. Dr. Gustaf Neumann
Institute of Information Systems and New Media
WU Vienna
Augasse 2-6, A-1090 Vienna, AUSTRIA