[Xotcl] Bug in filter processing?

[Gustaf Neumann]

  ... 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