ActiveState Community

Also, does the module list need to have the entire path or just the name of the file?

What if I have foo.tcl in both the project I'm debugging and the second application?

I've asked the Tcl experts here to have a look at this.

In the meantime, would there be a way for you to separate
the parent and child applications, like writing a dummy
child with a few built-in behaviors that make sense given
what the parent is doing?

- Eric

It sounds like your parent app is also written in Tcl -- could
you confirm this? What's the code that "calls out" to the second
app?

The module instrumentation pref was written with a few specific
modules in mind -- itcl and expect, to name two -- since
instrumenting them can be quite expensive. Currently, it's
not a generally available option.

- Eric

I think you are suggesting that I use a stub for the child application, right? I can't do that easily since there is a lot of interaction with the child and it's dependencies (UART port for example).

The parent app is Tcl and the child is also Tcl. I start up the parent, it kicks off the child, I wait a while and don't see things happening as fast as they should so I break-now. And when it breaks I'm in the middle of the child code. I want it to fly through the child code (don't instrument). Does this answer the question?

I will try to remove the .tcl from my file list in the preferences to see if that helps. (I think what you're saying is that if I put foo.tcl in the list it will try NOT to instrument foo.tcl.tcl)

Thanks,
-Brad

The Tcl debugger should debug the child process
only if you're using spawnpoints. If you aren't
using spawnpoints, and the child is being debugged,
this is a bug. Could you file a bug on it at
http://bugs.activestate.com/enter_bug.cgi?product=Komodo

Regards,
Eric

Nope, no spawnpoints. I'll submit a bug.

Would you suggest I go get "Komodo 5.2.0 beta1"?

Since the last post...
I added all of the files of the child to the preferences for no instrumentation. (I added them to the prefs.xml in my Application Data area. Much quicker than through the gui.) I have tried with and without the .tcl extension and get the same results. They are still instrumented. I see dbgp_tcldebug.exe burning 100% of one of my of CPUs.

I would think that you would want to keep a separate list of "do not instrument" files per project. And also have a global set. Where can I submit this as a suggested enhancement?

Bug submitted:

http://bugs.activestate.com/show_bug.cgi?id=84551

I see from the bug report that you're using 'source', not 'exec'.

The problem here is that the source command does not spawn a new
process -- it simply reads and executes the Tcl code in the current
process. You could say you've run into a limitation in the Tcl
debugger, that you can't tell it to shut down debugging mode,
and then resume it later on.

If you could rewrite the code using a true parent/child
architecture with exec, then you'd get the performance
speedup you're looking for.

Regards,
Eric

I will give it a shot. Not sure of how much tear up there is to do it yet...

-Brad

(BTW, This is legacy code that was handed to me.)

The parent and child are too tightly coupled. It would take a huge effort to decouple them. Would it be possible to cache the instrumented file? And only re-instrument if it had changed? It would make startup times much faster. I saw posts of other people having the same instrumentation lag issues.

I don't think it would be possible to NOT instrument the files the way they are used in my case since the parent is making function calls into the child and then grabbing its internal data. (Yuck!)

-Brad

From talking to the actual Tcl debugger developer, instrumentation
is a special operation done on a small number of predetermined
modules:

itcl, expect, tclx, autoload, dynproc

The debugger can't be configured to leave other arbitrary modules
uninstrumented.

Are there other approaches you can take?

- Eric

Right! I agree. They all need to be instrumented.

I was looking at IPC methods but am very new to Tcl.

What I'll need to do is replace:

source child.tcl
::child::method
set local_var $::child::child_data

with a mechanism that uses exec or open to execute the method and get the child_data.

Correct? Is there a good resource for this?

And I wanted to thank you for your quick replies.

What did you think about caching the instrumented file? Is it possible?

-Brad

There's no code in the debugger right now to support that. We
could consider it depending on demand, but yours is the first
request I'm aware of.

Given you're new to Tcl, here are some recommended resources:

http://www.tcl.tk/man/tcl8.5/tutorial/tcltutorial.html
http://wiki.tcl.tk/
news:comp.lang.tcl

Regards,
Eric

Thanks! I'm looking around and am finding some good info. the tcl.tk stuff has great links.

I hope that I can easily find a way to uncouple the child app. I'm evaluating Komodo for us to purchase and I will have to disclose this limitation. If/when I find a solution, I will post it here.

I think that the "files to instrument" list should be changed to make it more clear that it is geared towards: itcl, expect, tclx, autoload, dynproc.

---
I do see some need for caching based on some posts I found. And I didn't do an exhaustive search.

http://community.activestate.com/forum/tcl-debug-komodo-windows-dead-slo...
http://community.activestate.com/forum-topic/how-to-limit-intrumented
http://community.activestate.com/forum-topic/37-minutes-to-start-a-scr

---

My evaluation copy of Komodo IDE is about to expire so I decided to try the TDK. I see that the TDK CAN selectively exclude files for instrumentation based on their path. This is what I was looking for.

This is not possible in the IDE?
Why would the TDK have such a different feature set than the IDE?
Is there a product that merges both sets of functionality? From what I see on the web site, the ActiveTcl Pro Studio is just both products bundled.

Am I missing something?

Thanks,
-Brad

Sorry about the delay - the Tcl people I needed to talk to
were out of the office with spotty email.

One thing to keep in mind is that most of the Komodo code is
actually language-independent. We design protocols for
activities like debugging, and then write components to
implement each protocol for each specific language. We
managed to shoehorn some hardwired instrumenting for Tcl,
but that was a special case, and the effort that was made
for the TDK would have to be duplicated for Komodo, to
little benefit for the overall customer base (there is no
language that dominates Komodo's usage).

We recognize that some people are looking for features in
both Komodo and the TDK, hence we offer the ActiveTcl Pro Studio,
which does contain more than just Komodo and TDK.

Hope this helps.

- Eric