Go Back   Rhinocerus > Newsgroup > Newsgroup comp.lang.* 1 > Newsgroup comp.lang.tcl

Reply
 
Thread Tools Display Modes
  #1 (permalink)  
Old 08-16-2012, 12:08 AM
alex.rast.chocolate@gmail.com
Guest
 
Posts: n/a
Default uplevel causes "in TclCompileCatchCmd, currStackDepth = 6 should be 5

Some of you may recall a series of posts I made concerning interception of some TCL scripts and redirection to a handler to instantiate part of them on hardware.

I had the system working, or at least so it seemed, but now having changed machines (from a Fedora 14 to a Fedora 17 install) suddenly the program that was working now crashes with the error message you see in the subject.

I'm trying to do something *very* unusual, so please bear with me on this.

What happens in the code is, an outer-level program (Lens) runs a script containing an interception add-on to catch hardware-redirection commands. This interception add-on should:

1) use the unknown handler to redirect commands to itself prior to passing them on to Lens.

2) parse the command using an additional parser to pass it with arguments to the actual routines used to handle the redirection.

3) run the redirection command.

The message happens at the point where it tries to run the redirection command. The offending line (from the included script below) is:

uplevel 1 {namespace eval [namespace parent]::PACMAN_CMD} $command

As you'll see by going through the script below, the idea is that $command is a variable generated by the parser and passed into the unknown-handler'snamespace. Then, from the namespace of the command evaluator, the program should evaluate the parsed command (in another namespace, that of the interception-specific commands). The interception-specific commands themselves need to be in another namespace because it cannot be known a priori (i.e. atthe time the code is written) what the namespace of the command evaluator will be (it will be whatever namespace Lens is in at the time). Complicatedand convoluted, to say the least (if anyone has a simpler way of doing this that doesn't involve knowing in advance what the Lens command namespace will be please suggest!), so I'm not necessarily incredibly surprised that the upgrade has caused problems, but can anyone spot the actual cause of theerror here?

#-----------Interceptor script-below ------------------
#create the namespace for running PACMAN commands
namespace eval PACMAN {

#get the parent namespace so it can be used if necessary to invoke commandsfrom within the
#PACMAN script
set Lens [namespace parent]

#include the parser scripts
source LensScan.tcl
source LensParseTest.tcl
ScanLens LScan
ParseLens LParse -scanner [namespace current]::LScan

#set up the necessary unknown handler to invoke the parse routine

proc Lens_Unknown {args} {
global PACMAN::Lens
set PACMANCommands[list addNet setTime train test setObject addGroup copyUnitValues noiseType connectGroups connectGroupToUnits connectUnits loadWeights randWeights setLinkValues loadExamples useTrainingSet useTestingSet exampleSetMode]
if {[lsearch -regexp $PACMANCommands [lindex $args 0]] >= 0} {
#PACMAN command. Run the parser to do the complete decode.
uplevel 1 LScan start \"$args\"
#then directly execute the appropriate procedure
set command [uplevel 1 {eval LParse parse}]
uplevel 1 {namespace eval [namespace parent]::PACMAN_CMD} $command
#reset the parser in anticipation of the next line
uplevel 1 {LParse reset}
} else {
# Something else. Return to the default unknown handler for Lens and resolve the command there.
uplevel 1 {[namespace parent]::unknown} {*}$args
}
}

#register the unknown handler
namespace unknown Lens_Unknown

#This ends the PACMAN namespace
}

#create the namespace for defining PACMAN procedures
namespace eval PACMAN_CMD {

#<...command handlers for interception...>

}
Reply With Quote
Alt Today
Advertising
 
and become member of Rhinocerus
Standard Sponsored Links

  #2 (permalink)  
Old 08-16-2012, 07:57 AM
Donal K. Fellows
Guest
 
Posts: n/a
Default Re: uplevel causes "in TclCompileCatchCmd, currStackDepth = 6 shouldbe 5

On 16/08/2012 01:08, alex.rast.chocolate@gmail.com wrote:
> I had the system working, or at least so it seemed, but now having
> changed machines (from a Fedora 14 to a Fedora 17 install) suddenly
> the program that was working now crashes with the error message you
> see in the subject.


The crash in the subject is exceptionally serious, and indicates a bug
in the Tcl implementation itself. No matter how complex the script being
compiled, it should *never* *ever* hit that condition.

To track this further, I need to know the exact version of Tcl you are
using. What does [info patchlevel] report? (I'm also going to have to
figure out how to trigger the problem with a script that is small enough
to be comprehensible when I "pop the hood" on the bytecode compiler.)

Donal.
Reply With Quote
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off




All times are GMT. The time now is 02:54 AM.


Copyright ©2009

LinkBacks Enabled by vBSEO 3.3.0 RC2 © 2009, Crawlability, Inc.