critical issue patch downloads?

Mar 20, 2012 at 11:50 AM

I am having a couple critical errors with python tools, had to switch to Komodo which drives me nuts because python tools is far superior:

First is, spinning up a second third thread (or bringing up and down and up a second thread) in my python app locks the GUI in win 7 64bit

Second is, intellesense always and predictably fails very early on in the interactive window.  Get's an AppDomain error of some kind and thats it, interactive intellesnese gone until I restart all of Visual Studio.

I have seached and both these issues have been noted, addressed and mentioned as having fixes.    But am having difficulty leveraging these fixes because:

1) I don't know a ton about enterprise team dev and source code branches and such, and it isn't clear to me exactly what I am supposed to do.   I *think* I am supposed to download the latest source (which I hope is inclusive of all fixes up to that point) and recompile it in VS.NET?  And then rerun the newly compiled setup part of the project?

2) If I am right about #1 above, I have downloaded the latest source and tried to recompile...but I get a "TFS" error when I open the project and all the projects but "AppTest" or something are greyed out and empty.   Again, per #1 above, I don't know a lot about team development...so maybe I am supposed to configure some time TFS settings or something?   

A document somewhere explaining what exactly one is supposed to do to get an interim fix between formal releases would be awesomely helpful.

Thanks in advance for any help here..I very much want to begin using python tools again...I miss it!    

 

Coordinator
Mar 20, 2012 at 5:15 PM

We're going to put out a 1.1.1 in the next week or two probably (just need to wait for my PM to be back so I can train him on how to do releases) which should include the fixes for the crashes...  Do you have a link for the 1st issue?  Just want to make sure it's fixed.

As far as the building you can following the instructions at:

http://pytools.codeplex.com/wikipage?title=Build%20Instructions%20for%20PTVS

Which includes everything you need to have installed.  Likely the thing you're currently missing is the VS SDK which is the reason the projects aren't loading, but there's several more items after that you'll need.  Once you've done that there's instructions at the end of that page for Building the installer which will let you build the MSI.  Basically you shouldn't even need to open VS to do this after syncing to the latest sources.

Mar 21, 2012 at 1:59 PM

D,

Thank you so much for the reply.   Am very excited about the new release.  I *love* the toolset, I want all my developers to use it.   So it has been killing me to not quite be able to do some of the things I need to. 

So that you have them, I'll describe my outstanding issues.  I did you address issues kind of like what I am describing, but not precisely.  To be sure, they are:

1)  if I create a worker thread in python (such that my app has 2 threads) everything works fine.  But when I close the thread, if I try to spin off another thread, the UI locks up forever.  Seems I only get to run an extra thread only once.   After that I need to reset the interactive if I want to thread again.   In the case where I want to use a Winform, if I spin off a second thread like Iron Python recommends, it is actually the winform that locks up and gets the spinning cursor.   I have win7 64bit, and read your reply to someone who had something eimilar...something about debugging attachment that you could fix on 64bit?

2) intellesense fails immediately and forever in the interactive until I relaunch VS.NEt.   It is pretty predictable...I have a pretty complex class structure, and the moment I popup an intellesense selector on any of my objects, I get a 'appdomain' error and that's it.   I believe it works ok on the system objects, but when I try on mine, boom.   That said, there were periods earlier in my development where the intellesense did not fail immediately, I got quite awhile before it would happen.  But with the project where it now is, boom, pretty immediate.   I wonder if it has something to do with the inheritance chain of my objects.  Not sure.  And not sure how to troubleshoot.

If you want any system information, let me know.  Happy to provide and put time in to help you troubleshoot.

 

Thank you again, Dinov. 

Coordinator
Mar 21, 2012 at 5:06 PM

On #1 any chance I could get you to apply a small patch (the fix) to see if it fixes your issue?  I think it will, you just need to modify visualstudio_py_debugger.py and update the new_thread_wrapper function moving the THREADS_LOCK.release() call above the report_thread_exited and only call report_thread_exit if not DETACHED like this:

 

 
········THREADS_LOCK.release()
 
 
 
········if·not·DETACHED:
 
············report_thread_exit(cur_thread)
 
········THREADS_LOCK.release()

You can find visualstudio_py_debugger.py in $(VSINSTALLDIR)\Common7\IDE\Extensions\Microsoft\Python Tools for Visual Studio\1.1 (default install) or in %LOCALAPPDATA%\Microsoft\VisualStudio\10.0\Extensions\Microsoft\Python Tools for Visual Studio\1.1 (advanced install for per-user).

 

Mar 21, 2012 at 7:03 PM

Yup. Did it.  And thank you...that did seem to work.  I can now relaunch the thread without resetting the interactive.  Need to do a little more testing to be sure, but that thread used to lock the UI and now it isn't which is great.

Thank you..

At least with this resolved, I can work which is great...intellisense (#2) would be great to resolve, but I can wait for the new patch.  At least now I am able to work.

For awhile I had to use, *shudder* Komodo.  Not bad, but I think they try to do too much with too many languages and are missing some real huge features: no intellisense on the interactive for Python (some other languages have it) , no right-click 'add to interactive'...

Working in some of these other environments makes one appreciate python Tools for VS all the more...

BTW: New code looks like this:

      THREADS_LOCK.acquire()
        if not cur_thread.detach:
            del THREADS[cur_thread.id]
            THREADS_LOCK.release()
            report_thread_exit(cur_thread)

Mar 21, 2012 at 7:31 PM

Ok, continuing to test...so I still do have a threading issue.  May or may not be related to this.  But when I try to do any simple winform work with Iron Python, I get a frozen winow (acts like the UI thread is frozen and the tutorial does, infact, utilize threads for the UI.

This simple code:

import winforms
from System.Windows.Forms import *
from System.Drawing import *
f = Form()
f.Show() 

Works fine from a command-line IPY or IPY64 (the winform window is responsive, moves, is happy on its thread).  But when done from Python Tools interactive, the winform window locks up and the cursor is a spinning circle.   The interactive console remains responsive.  

So not sure if this is another thread-related situation and related to this issue or not...

 


Coordinator
Mar 21, 2012 at 7:48 PM

This is actually due to a feature of winforms.py which interacts w/ the standard Python interpreter (via clr.SetCommandDispatcher).  It sets up IronPython so that all of the code you enter will run on the same thread as the UI thread and the UI thread never becomes unresponsive.  It also means that when running normally (not in the interactive window) your app will have a random extra thread hanging around after importing winforms. 

I'm not sure what the best solution is here...  We could potentially have our own winforms.py but that doesn't seem right because we shouldn't all have to re-create this (and do it again for WPF or someother UI framework). 

We can't just use IronPython's command dispatcher because it doesn't look like getting is is supported in IronPython currently (only setting it).  Although this seems like the best approach so maybe we just need to update IronPython and make this available, or see if there's a sneaky way to get ahold of it.

You could potentially import visualstudio_py_repl and then monkey patch BasicReplBackend.execute_code_work_item so that it would do the same thing as winforms.py.  But that's awfuly ugly.

For the time being it might be simplest to explicitly create a new thread and run the form on that new thread, but whenever you want to interact w/ it you'll need to post a message onto the UI thread like winforms.py does with dispatcher.Invoke(...).

Could you open a feature request, and we can try and work out the details of supporting Ipy's dispatcher mechanism?

Mar 21, 2012 at 8:50 PM

Yeah, for sure.  I will open a feature request..  We really want to be able to use winforms from the tool...

I wouldn't mind talking to the UI on a separate thread, however, not sure how I would be able to call a function like 'f.Show()' from the intepreter and ferry that over to the other thread.  Guess I could use 'eval()' or something, but that seems kind of ugly...and then I'd need to do things like >>>sendtothread('f.Show()').

Blah.   I need a lot of interaction between the interactive and the form...I actually use the form to dynamically create winform controls that map onto Python constructs...as a interactive aide to the code I am writing in the interactive console...so it isn't just a simple question of running a form.

So, yeah, I'll open a feature request.   Thanks for giving me a background here.  I understand the issue a little better now.

Coordinator
Mar 21, 2012 at 8:56 PM

For simple calls you could do:

sendtothread(lambda: f.Show())

But yeah, still pretty ugly and won't work if you need to use statements like assigning to a property :(

Coordinator
Mar 21, 2012 at 9:08 PM

Ok, just figured out how to get the command dispatcher, so it looks like this is another one that you could patch.  I'll check the fix in to the main branch, but the change you need is in visualstudio_py_repl.py (in the same folder as visualstudio_py_debugger.py) and you need to add this method:

 

    def python_executor(self, code):
        def func():
            code.Execute(self.exec_mod)
        return func
   
to BasicReplBackend and then replace the line "code.Execute(self.exec_mod)" in execute_code_work_item with:

            dispatcher = clr.GetCurrentRuntime().GetLanguage(PythonContext).GetCommandDispatcher()
            if dispatcher is not None:
                dispatcher(self.python_executor(code))
            else:
                code.Execute(self.exec_mod)

And we'll use the Winforms wrapper.  Given that this is new functionality rather than a simple fix it probably won't make it into 1.1.1 so you'll need to patch it again once that's released, but there's no problems putting it into the next major release.

 

Mar 22, 2012 at 12:31 AM

OMG, you are a magician...

Seriously, thank you.  This lets me get my work done.

I will try it now.