Re: Debugging Tcl 8.6 in Komodo 5.2

    We do have our own in-house developed packages but they are not in the 'normal' packages path. We [lappend ::auto_path <our path>] so that we can see them. In the previous example/output I didn't do this, so Tcl wouldn't have looked there.



    Just now I also looked for "package present Tcl 8.5.0-8.6" throughout my default ::auto_path

C:/Tcl/lib/tcl8.6

C:/Tcl/lib

c:/tcl/lib/teapot/package/win32-ix86/lib

c:/tcl/lib/teapot/package/tcl/lib

and the only thing that I saw (1 occurrence in 4342 files), with that range, was C:\Tcl\lib\tk8.5\pkgIndex.tcl:

if {[catch {package present Tcl 8.5.0-8.6}]} { return }



    This same file for tk8.6 has:

if {[catch {package present Tcl     8.6b1.1}]} { return }





Is this just an issue from laying Tcl8.6b1.1 on top of Tcl 8.5.7?



--Aaron





-----Original Message-----
From: Andreas Kupries [mailto:[email protected]]
Sent: Tuesday, December 01, 2009 11:13 AM
To: Perez, Aaron P.
Cc: Jeff Hobbs; [email protected]
Subject: Re: [Komodo-discuss] Debugging Tcl 8.6 in Komodo 5.2



Perez, Aaron P. wrote:

> I ran two tests one in a command prompt (tclsh86 only) and another in

> Komodo using this new debugger.

>

>

> C:\>tclsh86

>

> % set ::errorInfo

>

> % set ::errorCode

>

> TCL LOOKUP VARNAME



First note that successful commands do not touch the ::errorXXX variables,

which means that they can have old information floating around.





>

> %

>

> % package require TclOO

>

> 0.6.1

>

> % set ::errorInfo

>

> % set ::errorCode

>

> TCL LOOKUP VARNAME



Command was successful, ::errorXXX was left unchanged.



> % package require Expect

>

> 5.43

>

> % set ::errorInfo

>

> version conflict for package "Tcl": have 8.6b1.1, need 8.5.0-8.6

>

>     while executing

>

> "package present Tcl 8.5.0-8.6"

>

> % set ::errorCode

>

> NONE



My guess is that there is a pkgIndex.tcl file in your setup which ran this

command, caught the error and decided on some actions based on the information.

There is not enough information present to say if it is one of the packages we

provide, or one of yours ...



Grepping through the Expect 4 Windows sources I do no see a 'package present'

command there, so Expect itself is not it.



And anything after left the :::errorXXX untouched.



NOTE: You did not see this for 'package require TclOO' because TclOO is

integrated in Tcl 8.6, so the command had no need to go out and read the

package indices.



As the 'package require Expect' returned a proper version number this command

ran ok.



> %

>

>

>

> *_Debugger Output:_*

>

> Tcl 8.6b1.1 interactive shell

>

> To use Tk, type 'package require Tk'

>

>

>

> set ::errorInfo

>

> can't rename "spawn": command doesn't exist

>

>     while executing

>

> "rename $cmd $nocmd"

>

> set ::errorCode

>

> NONE



That comes out of the debugger setup in the shell you started. The debugger

tries to intercept a number of commands it has to handle specially. One of them

is Expect's 'spawn' command. The debugger catches the fact that this command

doesn't exist (yet), however it is not cleaning up ::errorXXX.



> package require TclOO

>

> 0.6.1



Ditto, the data is simply still present.



> package require Expect

>

> 5.43

>

> set ::errorInfo

>

> can't rename "thread::create": command doesn't exist



The same as above, except that the debugger found that after loading of

'Expect' (loading is intercepted) the 'spawn'-command is now present and so has

intercepted it, and now you see the next last command it was looking for and

did not find for interception.



>

> Are these normal and/or expected?



Normal.



--

Sincerely,

     Andreas Kupries <[email protected]>

     Developer @    <http://www.activestate.com/>

CONFIDENTIALITY STATEMENT. This email and any attachment is for the sole use of the intended recipient and may contain private, confidential and/or privileged information that may be subject to Hospira internal policies. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you have received this transmission in error, please notify Hospira immediately by return email or by email to [email protected] and delete the message and all copies and attachments from your system.

_______________________________________________
Komodo-discuss mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Other options: http://listserv.ActiveState.com/mailman/listinfo/Komodo-discuss