[Tcl-bugs] [ tcl-Bugs-3075155 ] oo depends on bytecoding?

[SourceForge.net <no...@so...>]

Bugs item #3075155, was opened at 2010-09-24 23:03
Message generated for change (Settings changed) made by dkf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3075155&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 07. Variables
Group: development: 8.6b1.1
Status: Open
Resolution: None
>Priority: 7
Private: No
Submitted By: miguel sofer (msofer)
Assigned to: miguel sofer (msofer)
Summary: oo depends on bytecoding?

Initial Comment:
When I disable the command compiler (juts add '0&&' at the start of the condition in tclCompile.c line 1639), there is a nasty-looking error:

==== oo-27.6 variables declaration - non-interference of levels FAILED
==== Contents of test case:

    oo::class create foo {
	superclass master
	variable x!
	constructor {} {set x! 1}
	method y {} {incr x!}
    }
    foo create bar
    oo::objdefine bar {
	variable y!
	method y {} {list [next] [incr y!] [info var] [info local]}
	export eval
    }
    bar y
    list [bar y] [lsort [info object vars bar]] [bar eval {info vars *!}]

---- Result was:
{3 2 {} {}} {x! y!} {x! y!}
---- Result should have been (exact matching):
{3 2 y! {}} {x! y!} {x! y!}
==== oo-27.6 FAILED

There is also a segfault in itcl's typeoption.test, which may well be related.

The build is configured as 
  CFLAGS=-DPURIFY ./configure --disable-shared --enable-symbols

----------------------------------------------------------------------

>Comment By: Donal K. Fellows (dkf)
Date: 2011-03-11 11:47

Message:
I'm not very excited about this after all. Turns out quite a bit of the
rest of Tcl also breaks if we disable command compilation.

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2010-10-20 00:36

Message:
Your analysis looks correct. I'll assign it to you (for now) since I'm not
going to do any hacking in the guts of resolvers if I can possibly help it.

----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2010-09-27 16:43

Message:
In order for this to work properly if we maintain the current behaviour
(ie, if #3075907 is declared a doc bug), we should extend Tcl_ResolverInfo
to contain a listProc to be used by [info vars]. This new function would
list all variable names that are able to be resolved in the current
context.

The alternative would probably be unnecessarily expensive: that all OO
methods be initialised to contain locals linked to every defined variable,
initially undefined.

----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2010-09-27 11:07

Message:
Just replacing [incr] by an equivalent [myIncr] or forcing a non-bc'ed
[incr] displays the difference: running the attached script outputs

{3 2 y! {}} {x! y!} {x! y!}
{3 2 {} {}} {x! y!} {x! y!}
{3 2 {} {}} {x! y!} {x! y!}


----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2010-09-27 10:24

Message:
The problem seems to be:

1. On a normal build, the presence of y! is detected at compile time by
the [incr] compiler. This causes y! to live in the LVT and the resolver to
be called at proc loading time. Due to #3075907 y! is reported by [info
vars]

2. With command compilers disabled (in this particular case, it is enough
to not compile incr), y! is not in the LVT: it will only exist when it is
given a value

This is all as should be, assuming [info vars] behaved as doc'ed in the
man page. Given #3075907 the behaviour depends on the set of commands that
are bytecompiled. 

----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2010-09-26 13:54

Message:
This led to discovery of (related, not the same) Bug #3075907. If that one
is resolved as an implementation bug, this test is wrong. If it is instead
a doc bug, this test is correct.

----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2010-09-26 13:04

Message:
After quick look at TclInfoVarsCmd(), it seems that [info vars] is not
resolver-aware at all

----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2010-09-26 13:03

Message:
>From the chat:
[14:56]	dkf	miguel: It looks like it's something to do with variable
resolvers. I don't pretend to understand those (and have probably got it
wrong, I accept) and write code for them by doing the equivalent of
throwing rocks at stuff until it seems to work.
[14:57]	dkf	I suspect that the highly restricted resolver used by TclOO is
too restricted, but since proc^Wmethod bodies are always compiled I don't
care 

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2010-09-25 18:53

Message:
Variable resolver involved! Argh!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3075155&group_id=10894