|
From: Andy G. <and...@gm...> - 2017-09-20 05:30:33
|
On the amg-string-insert branch I changed the way the [string] command is tested so that both the bytecoded and non-bytecoded implementations are exercised. I modeled my change after basic.test per dgp's suggestion: https://sourceforge.net/p/tcl/mailman/message/36043584/ Previously the bytecode testing was done by duplicating string.test to stringComp.test. Not only was this duplicate not kept up-to-date, but due to another change in bytecode compilation, the original string.test ceased testing the non-bytecoded implementation. This change flushed out one test failure: string-29.6 ==== string-29.6 string cat, efficiency FAILED ==== Contents of test case: tcl::unsupported::representation [run {string cat [list] [list x]}] ---- Result was: value is a list with a refcount of 2, object pointer at 0x241cc70, internal representation 0x24962b0:0x0, string representation "x" ---- Result should have been (glob matching): *no string representation ==== string-29.6 FAILED One shortcoming of the basic.test [run] method is it's not clear whether any test failure is with the bytecoded or non-bytecoded version. It turns out to be the bytecoded version, and the non-bytecoded version works fine. At this point you should be jumping up and down saying that doesn't make sense. Earlier I said bytecode compilation changed such that string.test wound up testing the bytecode implementations and nothing was testing the non-bytecode implementations. string.test was working before I touched it. Now I say the bytecode is failing. That's contradictory. Well, let's minimize confusion by bypassing Tcltest and running the commands directly: # Baseline % tcl::unsupported::representation [string cat [list] [list x]] value is a list with a refcount of 2, object pointer at 0x252f8d0, internal representation 0x2586800:0x0, no string representation # Bytecode % interp alias {} run {} try % tcl::unsupported::representation [run {string cat [list] [list x]}] value is a list with a refcount of 2, object pointer at 0x252f780, internal representation 0x25593c0:0x0, string representation "x" # Non-bytecode % interp alias {} run {} testevalex % tcl::unsupported::representation [run {string cat [list] [list x]}] value is a list with a refcount of 1, object pointer at 0x2534e20, internal representation 0x256e3d0:0x0, no string representation If you think that's strange, you haven't seen anything yet. Look here: % interp alias {} run {} try % tcl::unsupported::representation [if 1 {string cat [list] [list x]}] value is a list with a refcount of 2, object pointer at 0x2530110, internal representation 0x258d0a0:0x0, no string representation % tcl::unsupported::representation [try {string cat [list] [list x]}] value is a list with a refcount of 2, object pointer at 0x2530080, internal representation 0x258c620:0x0, no string representation % tcl::unsupported::representation [run {string cat [list] [list x]}] value is a list with a refcount of 2, object pointer at 0x252f780, internal representation 0x25593c0:0x0, string representation "x" Somehow the behavior is changing due to going through an interpreter alias. Though not in the general case, rather only when the target command simply executes its argument: % interp alias {} run {} string cat % tcl::unsupported::representation [run [list] [list x]] value is a list with a refcount of 2, object pointer at 0x2534ac0, internal representation 0x258c3a0:0x0, no string representation This is crazy. Any ideas? -- Andy Goth | <andrew.m.goth/at/gmail/dot/com> |