Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

TCL(Tool Command Language) Scripting

tcl interp inside vim throws error w/ clock format


This command...
  puts "clock test : [clock format [clock seconds] -format {%H:%M:
%P}]."

Fails w/ this error...
  self-referential recurison in "unknown" for command
"::tcl::tm::UnknownHandler"

I am using...
tcl : 8.5.6a
vim : 7.1 - latest version, but this is a problem that I have seen
before w/ vim 7.0
mac osx 10.4.

I want to track down this error. It occurs when running tcl commands
with the interpreter inside of the application vim. The problem seems
to be limited to the [clock format] command. I have spot tested a
bunch of other commands and [clock format] appears to be the only one
affected. If this is not something that one of our resident experts
can debug with a glance, a nudge in the likely direction would be
greatly appreciated.

Mark.

Dug a little deeper. Rebuilt vim 7.1 with tcl 8.4.15. and tried again.
With 8.4.15, puts [clock format [clock seconds]] works.

I looked into the clock.tcl file that exports the clock commands into
the ::tcl namespace. I noticed that it has an arg check early, so I
called [clock format]. The first time I called it it hit the arg test
and failed with the error message from the arg test. If I call the
same commands again, it bounces to the message...
   self-referential recurison in "unknown" for command
  "::tcl::tm::UnknownHandler"

Looks like there is something weird with either the clock.tcl file or
the unknown command.

On May 24, 4:14 am, Mark Smithfield <m_smithfi@yahoo.com> wrote:

Mark Smithfield schrieb:

> Dug a little deeper. Rebuilt vim 7.1 with tcl 8.4.15. and tried again.
> With 8.4.15, puts [clock format [clock seconds]] works.

> I looked into the clock.tcl file that exports the clock commands into
> the ::tcl namespace. I noticed that it has an arg check early, so I
> called [clock format]. The first time I called it it hit the arg test
> and failed with the error message from the arg test. If I call the
> same commands again, it bounces to the message...
>    self-referential recurison in "unknown" for command
>   "::tcl::tm::UnknownHandler"

> Looks like there is something weird with either the clock.tcl file or
> the unknown command.

I don't know the vim embedding of Tcl, but it might be that vim is not
fully initializing the Tcl script library and so the new Tcl 8.5 clock
command, which is implemented in large parts in the script library
cannot find parts of its implementation.

Michael

On May 25, 11:22 am, schl@uni-oldenburg.de wrote:

That can't be completely correct, because the error message from the
clock.tcl file returns the first time that it is called (w/ no args).
[clock format] seems to create a worker function based on the format
args. This is failing and some how all further clock format commands
get picked up by unknown. If this is the result of an upstream
initialization error, vim will not be the only project affected.

Could someone tell me how/where the scripts/clock.tcl file is
initialized?

Mark Smithfield wrote:
> Could someone tell me how/where the scripts/clock.tcl file is
> initialized?

OK, it's a trifle complicated.

In any given (unsafe) interpreter, the first definition of [clock]
is a 'proc' in 'init.tcl'.  That procedure creates the [clock] ensemble
by [namespace ensemble], overriding its own definition.  It also
creates stub procedures in the '::tcl::clock' namespace for
[clock add], [clock format] and [clock scan] (the other subcommands
are all implemented in C).

Having done so, the [clock] procedure evaluates:
    [uplevel 1 [info level 0]]
essentially retrying the [clock] command.  Sunce here you were
doing [clock format], that second try will go to the stub procedure,
which will do
    source -encoding utf-8 [file join $TclLibDir clock.tcl]
to pull in the Tcl code for the rest of [clock] and then do
    [uplevel 1 [info level 0]]
a second time, this time getting into the '::tcl::clock::format'
procedure defined in 'clock.tcl'.

What I suspect happens then to cause your failure is that
something's going wrong in he [package require msgcat 1.4]
and [package require registry 1.1] at the head of 'clock.tcl'.
'tcl::tm::UnknownHandler' is invoked when 'package require'
fails to find a package.

In this case, I expect that 'package require msgcat' will get
into the 'package unknown' path, and first try calling
::tcl::tm::UnknownHandler.  That procedure will not yet be
defined, so now 'unknown' gets called for it, and loads the
'tclIndex' files for directories on the library path.  The
'tclIndex' file for Tcl itself should direct it to source
lib/tm.tcl to load it up.

Now 'unknown' re-evaluates ::tcl::tm::UnknownHandler, which
discovers that 'msgcat' is a Tcl Module, evaluates the [package
ifneeded] script for it and returns.  Now the package mechanism
has a [package ifneeded] script, loads up the msgcat library and
returns into 'clock.tcl'.

But we never seem to get that far.  Instead, something inside
this mechanism is causing [unknown] to be invoked recursively
for ::tcl::tm::UnknownHandler.

It's hard to tell, based on the information you've provided,
just which bit of the Tcl library might be damaged.  My
guess is that something prior to the first [clock] call is
overriding some Core command, or that the library is
misinstalled.

--
73 de ke9tv/2, Kevin

On May 25, 10:44 pm, Kevin Kenny <kenn@acm.org> wrote:

Thanks for the insight. Based on this prompting I dug around some
more.

An example, :tcl is the prefix for calling a tcl command in vim...

:tcl package require snack

first time...
wrong # args: should be "catch command ?varname?"

second time...
self-referential recursion in "unknown" for command
"::tcl::tm::UnknownHandler"

which is the same pathology as [clock format]

next,

:tcl info commands ::tcl::tm::*
returns nothing

I don't understand the particulars of how the new package system
works, but based on the Mr.K's description and a cursory examination I
believe that this is closer to the root of the problem. So..

Where is ::tcl::tm loaded?

Mark Smithfield wrote:
> :tcl package require snack

> first time...
> wrong # args: should be "catch command ?varname?"

That error message comes from Tcl 8.4.  In an 8.5 interp
you would see:

"catch script ?resultVarName? ?optionVarName?"

This suggests to me you're running a script meant for
the extended 8.5 [catch] syntax in an 8.4 interp that
can't handle it.

Looks like you're somehow combining bits and pieces
of an 8.4 install and an 8.5 install.

Do you have the TCL_LIBRARY environment variable set?
If so, stop that.

 From other clues, I think you intend to be using Tcl 8.5,
but the interp get used by vim is definitely 8.4 (or older?).
Get to the bottom of that.

DGP

On May 26, 11:13 am, Don Porter <dgpor@verizon.net> wrote:

Ok, I am using osx, and this is starting to look like a osx thing. Tcl
builds and installs as a Framework in osx which collects all the
assoc. files and lets you handle versions nicely, but the word on
using these is slow getting around.

I removed my Tcl.framework, rebuilt tcl8.5.6a, rebuilt vim, and tried
the above again. [info patch] says 8.5.6a, but the test fails w/ the
8.4 error message.

vim's config file allows you to specify the tclsh. I use tclsh8.5. My /
usr/local/bin tclsh points to tclsh8.5.

So.. now the trail is getting colder for me. I don't know what
question to ask, so how about... where do you go from here? I am quite
happy to do the legwork, but right now, I don't think I have a clear
enough bug report to cause action, if it even is a bug.

Oh, and I don't have a TCL_LIBRARY env var.

Thanks,
Mark.

On May 26, 7:55 pm, Mark Smithfield <m_smithfi@yahoo.com> wrote:

Note that this behaviour is not specific to clock. Any piece of code
using catch with 3 arguments gives this error.

The reason: The vim binding to Tcl redefines the catch command to a
version that is 'compatible' with the 8.4 and smaller versions.
Because 8.5 has added an additional optionsVarName argument some calls
to catch which are valid for 8.5 are invalid for the Vim catch
replacement.

The problem therefore is that Vim is doing something ugly (redefine
catch) which is not compatible with 8.5. Hence the only way to solve
this is to:

1) Only use 8.4 compatible packages
2) Use the trick described in http://wiki.tcl.tk/17765
   Using the following lines:
   :tcl interp create ok
   :tcl ok eval {puts "clock test : [clock format [clock seconds] -
format {%H:%M:%P}]."}
   works fine
3) update the Vim Tcl binding to remove the catch redefinition.

Hope this helps

Mark

On May 26, 8:29 pm, Mark Janssen <mpc.jans@gmail.com> wrote:

With respect to point 3, I have created a Win32 gvim.exe with the
catch redefinition removed. Preliminary testing indicates it is
working correctly with clock and this has no other adverse effects.
You can download it from http://marknet.tk/downloads/gvim.tcl85.zip

Mark

On May 26, 8:46 pm, Mark Janssen <mpc.jans@gmail.com> wrote:

And the patchfile in case you want to build it yourself at
http://marknet.tk/downloads/vim7-tcl85.patch

Mark

Mark Janssen wrote:
> 3) update the Vim Tcl binding to remove the catch redefinition.

This is, of course, the correct solution. :-)

Donal.

On May 26, 6:55 pm, "Donal K. Fellows"

<donal.k.fell@manchester.ac.uk> wrote:
> Mark Janssen wrote:
> > 3) update the Vim Tcl binding to remove the catch redefinition.

> This is, of course, the correct solution. :-)

> Donal.

Thank you all for your help. I have duplicated Mark's results on a
mac. I still have a slight wrinkle there, but I know that it is a mac
issue. I do have a few further questions.

First, vim overrides both [exit] and [catch].

In the case of [exit] I understand, from the vim point of view, if a
scripting language in an app doesn't like what it is asked, it should
return a val not kill the app. From the tcl point of view, [exit]
should deliver on it's name.

So, I'm gonna call that one a good play. tcl lets you override
everything, and [exit]'s default behavior is not appropriate when
using tcl in a subordinate role.

But [catch]? Why is catch in there? I suspect a history lesson would
help here. Once upon a time, did [catch] do something that would halt
or hang execution?

I want to know, because once I get this sorted out, I'll take it to
the vim-dev group.

Again, thanks all.

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc