"list [namespace code P] P]" error since tcl8.6

[Harald Oehlmann]

Just to ask the community if I am (again) dump or whatever.

Up to tcl8.5, I often used "errorneously" the following to construct a
callback with parameters and that worked:

proc P args {puts P<$args>}
set par1 "par 1"
after 500 [list [namespace code P] $par1]

Since tcl8.6, I get the error:
invalid command name "::namespace inscope :: P"

Is there any reason for this change ?

N.B.: the correct way is:
after 500 [concat [namespace code P] [list $par1]]
or
after 500 [namespace code [list P $par1]]

Thank you,
Harald

[Don Porter]

On 12/18/2012 06:05 AM, Harald Oehlmann wrote:
> Up to tcl8.5, I often used "errorneously" the following to construct a
> callback with parameters and that worked:
>
> proc P args {puts P<$args>}
> set par1 "par 1"
> after 500 [list [namespace code P] $par1]
>
> Since tcl8.6, I get the error:
> invalid command name "::namespace inscope :: P"
>
> Is there any reason for this change ?

Crazy Aunt Millie is dead.

In 8.5, your broken code works because ages ago, a workaround was
actually put into Tcl's default [unknown] command to forgive broken
code, and attempt to "Do What They Mean". It's been murky for a long
time just who we were helping with this. Legends claimed Itcl needed
it, but the evidence was pretty weak. Taking it out did not break Itcl.

In 8.6 we stopped doing that. We expect programmers to code what they
mean. That means putting {*} where they go. Or, if you just really
like what you had -- or have too much code to correct -- then put
the forgiving [unknown] back yourself, or even just in your namespace
with [namespace unknown].

--
| Don Porter Applied and Computational Mathematics Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|

[Harald Oehlmann]

On 18 Dez., 14:35, Don Porter <d...@nist.gov> wrote:
> On 12/18/2012 06:05 AM, Harald Oehlmann wrote:
>
> > Up to tcl8.5, I often used "errorneously" the following to construct a
> > callback with parameters and that worked:
>
> > proc P args {puts P<$args>}
> > set par1 "par 1"
> > after 500 [list [namespace code P] $par1]
>
> > Since tcl8.6, I get the error:
> > invalid command name "::namespace inscope :: P"
>
> > Is there any reason for this change ?
>
> Crazy Aunt Millie is dead.
>
> In 8.5, your broken code works because ages ago, a workaround was
> actually put into Tcl's default [unknown] command to forgive broken
> code, and attempt to "Do What They Mean".  It's been murky for a long
> time just who we were helping with this.  Legends claimed Itcl needed
> it, but the evidence was pretty weak.  Taking it out did not break Itcl.
>
> In 8.6 we stopped doing that.  We expect programmers to code what they
> mean.  That means putting {*} where they go.  Or, if you just really
> like what you had -- or have too much code to correct -- then put
> the forgiving [unknown] back yourself, or even just in your namespace
> with [namespace unknown].

Thank you, Don, fur the explanation.
As usual, I put this info on the wiki, as it might helpful for users
(like me).
I would not mind to have this in the tcl8.6 release notes...

http://wiki.tcl.tk/namespace code

Harald

[Ralf Fassel]

* Don Porter <d...@nist.gov>

| Crazy Aunt Millie is dead.

As a non-native speaker of english I'm always interested in those
references, as to where they come from and what they mean (pretty
obvious here but...).

In this case Aunt Googlie was not too talkative and just babbled about
bakeries and pizza deliveries, indicating that Aunt Millie either is not
dead or not crazy :-) Where does this one originate from?

TNX
R'

[Donal K. Fellows]

On 19/12/2012 09:05, Ralf Fassel wrote:
> As a non-native speaker of english I'm always interested in those
> references, as to where they come from and what they mean (pretty
> obvious here but...).
>
> In this case Aunt Googlie was not too talkative and just babbled about
> bakeries and pizza deliveries, indicating that Aunt Millie either is not
> dead or not crazy :-) Where does this one originate from?

The concept is one of locking crazy elderly relatives in the attic to
keep them out of the way of other people. (I don't think it's a nice
thing to do to someone, but it did happen.) The name "Millie" was just
picked at random and doesn't mean anything very much; that it matched
bakeries and pizza deliveries is just chance.

There are a few other features of Tcl that really qualify as "crazy
aunts" (in that deliberate use of them is probably a bug in the script
that uses them; they are *that* wrong) and that should be expected to go
away without much fanfare. For example:

* [case]
* The identity encoding
* [string bytelength]
* "Creative writing" of namespace variables
* Resolvers in general (or at least their bizarreness)

I'm sure there are others.

Donal.

[Gerald W. Lester]

I'm pretty sure the list is:

Script-visible issues:

* A change was made to the standard unkown procedure to remove code that
had been inserted specifically to work arround issues in older versions of
Itcl/Itk. This may impact older versions of Itcl/Itk or people who have
custom ::unknown procedures.

* TIP 318 revised defaults for [string trim] by introducing other unicode
characters that are now considered whitespace. Thus scripts using the
default trim characters may now (correctly) trim additional characters off
that were not being trimmed before.

* The unload will now only unload extensions, thus removing their
commands, if the extension either has a special unload entry point or no
calls have been made to it. Thus commands that were delete due to unload in
prior versions of Tcl may not be deleted in 8.6.

* The system encoding at startup is now "iso8859-1", and no longer
"identity". This may impact scripts with strings with literal charactes (as
opposed to those using \u substition) whose characters are outside of the
printable ASCII range.

* The [exit] command may no longer invoke some C level "finalization"
routines that were previously (erronously) invoked.

* The read varaible traces that are invoked during an [lappend] command
are now consistant and no longer vary depending on if the code was byte
compiled or not. Anyone code using the previous (buggy) behavior to detect
if the code was byte compiled or not will not longer function.

* The Unicode tables have been update to correspond with Unicode 6.0.
Thus, some characters which were not previously recognized as [string is
alpha] are now correctly recognized as such.

* Allow function names like "influence()", "nanobot()", and "99bottles()"
that have been parsed as missing operator syntax errors before with the form
NUMBER + FUNCTION. I.e. the examples would have parsed as: Allow function
names like "inf luence()", "nano bot()", and "99 bottles()".

* On exit, Tcl will no longer flush non-blocking channels. Scripts relying
on non-blocking channels being flushed on exit will have to be modified to
explictly flush those channels.

* Corrected resulting indexes from -indexvar option to be usable with
[string range]; this was always the intention (and is consistent with
[regexp -indices] too). Uses of [switch -regexp -indexvar] that previously
compensated for the wrong offsets (by subtracting 1 from the end indices)
now do not need to do so as the value is correct.

(The above are my words).

--
+------------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+------------------------------------------------------------------------+

[Erik Leunissen]

On 19/12/12 12:02, Donal K. Fellows wrote:
> There are a few other features of Tcl that really qualify as "crazy
> aunts" (in that deliberate use of them is probably a bug in the script
> that uses them; they are *that* wrong) and that should be expected to go
> away without much fanfare. For example:
>
> * [case]
> * The identity encoding
> * [string bytelength]
> * "Creative writing" of namespace variables
> * Resolvers in general (or at least their bizarreness)
>

What's the craziness with [string bytelength] ?

Is it that it serves a use case that ought be handled by a package
rather then the core?


Erik.

> I'm sure there are others.
>
> Donal.

--
leunissen@ nl | Merge the left part of these two lines into one,
e. hccnet. | respecting a character's position in a line.

[Donal K. Fellows]

On 20/12/2012 18:59, Erik Leunissen wrote:
> What's the craziness with [string bytelength] ?
>
> Is it that it serves a use case that ought be handled by a package
> rather then the core?

No, it's that what it measures is exactly the space occupied by one type
of representation used internally by Tcl (which isn't properly UTF-8,
though it is close). The only thing for which this is actually useful is
feeding into the C API, but then you've got easy access to the
information anyway in a public field of the value structure. All other
cases are covered by [string length], possibly with [encoding convertto]
used first. If you're using [string bytelength], You're Doing It Wrong.

It's not as bad as the identity encoding though; that's plain crazy...

Donal.

[Donal K. Fellows]

On 19/12/2012 14:51, Gerald W. Lester wrote:
> I'm pretty sure the list is:

Those are the changes list, not the "crazy aunt" list. Some are just
changes that are unavoidably visible, despite not being horribly wrong
in the first place. The "crazy aunts" are the real misfeatures, not all
of which have been removed yet.

Even octal wasn't really a crazy aunt.

> * The unload will now only unload extensions, thus removing their
> commands, if the extension either has a special unload entry point or no
> calls have been made to it. Thus commands that were delete due to unload
> in prior versions of Tcl may not be deleted in 8.6.

I believe that was always the case. Note that it's not easy to write an
unloadable extension but it's not quite as useless as some seem to
think. That said, I've hardly ever had cause to write an unload hook.

Some features of Tcl's API are virtually impossible to retrace the use
of, notably anything that requires registration but where there is no
unregistration option. Others require that you keep very careful track
of what you've registered (e.g., when you create a command, you get a
Tcl_Command token that you need to track so you can delete it at the
appropriate time). Unloading is definitely an expert-only feature.

Donal.