intellisense troubleshooting

Jun 9, 2013 at 6:17 PM
Edited Jun 10, 2013 at 7:26 AM

I am having inconsistent results with intellisense (VS2010, PVTS 2.0 alpha, IronPython).
Some of the classes or methods of my modules are recognized some not.
I have looked at: AppData/Local/Python Tools/CompletionDB/AnalysisLog.txt but it only has entries about buildin and standard lib. I have tried to narrow down the problem to something I can report, but once I am out of my project, things work as expected.
I also tried to recreate entire CompletionDB, but it didn't make a difference.
My project is not particularly big. There are some imports from .net but problems do not correlate with them.

Is there a way to get more info to find out what is intellisense doing within my own project?

Edit: after some try and error pattern emerged.
My project structure looks like this:

Within test, package, and subpackage modules from package and subpackage are imported using absolute path.
# either prj/test/test-case1/
# or prj/package/subpackage/

from package.m1 import foo
from package.subpackage import m1
I add root folder (".") of the project to "Search Path" of the myproj.pyproj. Intellisense works as long as I keep VS open. Once VS is restarted, intellisense gets confused. Most of the time to get things back I have to remove and add "." to ""Search Path".

I am still interested in finding out exactly what is causing intellisense to get confused and have a real fix.

Jun 10, 2013 at 3:38 PM
This should not be a problem, and it's interesting that modifying the search path has an effect, since we include the project root by default.

Can you email this project to (or put it up publically on SkyDrive or DropBox)? You mentioned in your other post that you'd love to attach it to the discussion, but CodePlex doesn't support that right now.

Alternatively, the most interesting part for us is probably the .pyproj file, so if you can copy-paste the contents of that in then we may be able to figure this out. We're releasing our beta very soon, so we'd love to make sure this is resolved before that.
Jun 12, 2013 at 8:01 PM
I have send an email with the link. Did you get it?
BTW. my pyproject file is bigger than allowed size of the message :-(
Jun 12, 2013 at 8:22 PM
Yes, I've seen the email come in, but I've been busy since then and haven't had a chance to look yet. Google Drive tends to make these things more complicated unless you share it for "Anyone with the link" - not everyone has Google accounts handy to accept private invitations (or they don't want to use them for work purposes).

If the file is under 10 MB then there shouldn't be any issue with directly attaching it to the email, either.
Jun 14, 2013 at 6:02 PM
I'm looking now, and we've clearly got an issue where we are forgetting about the top-level package name ("package", from above), which has flow-on effects in some situations.

Will let you know if I find a workaround.
Jun 14, 2013 at 7:43 PM
Just letting you know that this is caused by a bug in our IronPython analysis that was causing us to basically reset the state periodically.

Unfortunately, at this stage, the fix is unlikely to make it into our next release. We're so close that we're not taking non-crashing fixes anymore. The closest thing to a workaround is to switch to CPython while coding and then back to IronPython when running. I'm sorry I don't have a better option for you.
Jun 14, 2013 at 8:13 PM
no stress, I wouldn't go for risky changes myself. How does the post 2.0 timeline looklike? I don't mind testing trunk snapsots once it is fixed.
For the cpython workaround, I will check it out. It sounds possible, most of the time I run things from outside VS anyway.
Jun 16, 2013 at 4:44 PM
I clearly spoke too soon, the fix has gone in for 2.0 beta (someone noticed that it's a regression from 1.5, so we took the fix).

Beta will be coming out around the same time as VS 2013 Preview, so only a week or so to wait for that one. Our post-beta timeline will depend on the feedback we get - we're prepared to do 0, 1 or 2 release candidates before we call it stable. Post-2.0 is only in early planning stages right now (which, for products like Windows means there are tens or hundreds of people working on it, but we just chat about it at lunch :) ).

We're planning to get better at pushing code to CodePlex after beta comes out, and we love it when people outside our team are building from trunk. We're happy to help you get set up and even make changes to the project to make it easier. There's a doc page somewhere on how to get going, but once we push our current code it'll need to be updated (just made myself a note to do that).

And on your last point ("most of the time I run things from outside VS anyway"), is there anything we can add or change to save you from having to do that? One of our design objectives is to keep people from having to switch out of VS, so we're very interested in hearing why people need to do so.
Jun 16, 2013 at 11:28 PM
That's fantastic news for me. Personally I was somehow getting around without intellisense (but getting tired), but in September I will need intellisense for other people.
is there anything we can add or change to save you from having to do that
Most of the time I start my programs from command line.
It is convenient because I change arguments and cwd often and changing it via gui would be a bit strange.
I didn't even tried the Ctrl-F5 until now, but I am having some problems. I think PYTHONPATH is not set correctly, or to be exact IRONPYTHONPATH.
I would expect the root of the project to be included (by default) or because I set search path to "."
If I replace an interpreter with bash and tell it to run:
set  | grep -i path
it comes with:
MOZ_PLUGIN_PATH='C:\Program Files\Foxit Software\Foxit Reader\plugins\'
PATH='/c/Program Files/Microsoft HPC Pack 2008 R2/Bin:/c/app/rejap/product/11.2.
:/c/Program Files/Microsoft SQL Server/100/Tools/Binn:/c/Program Files/Microsoft
 SQL Server/100/DTS/Binn:/c/utils:/c/java/apache-ant-1.8.2/bin:/c/Program Files/
Notepad++:/c/Program Files/KDiff3:/c/Program Files/DocumentGenerator/bin:/c/Prog
ram Files/IronPython 2.7:/c/Program Files/IronPython 2.7/Scripts:/usr/bin:/home/
rejap/java/apache-maven-3.0.5/bin:/c/Program Files/Saxonica/SaxonHE9.4N/bin'
I also switch interpreter to interactive, and try to check path. Here is the output.
Traceback (most recent call last):
  File "C:\<edited>\DocGen\docgen\extractor\test\mip-obsta
cles\", line 3, in <module>
ImportError: No module named eax.extractor>>>
>>> import sys
>>> print sys.path
stacles', 'C:\\Program Files\\IronPython 2.7\\lib\\site-packages\\setuptools-0.6
c11-py2.7.egg', 'C:\\Program Files\\IronPython 2.7\\Lib', 'C:\\Program Files\\Ir
onPython 2.7\\DLLs', 'C:\\Program Files\\IronPython 2.7', 'C:\\Users\\rejap\\App
Data\\Roaming\\Python\\IronPython27\\site-packages', 'C:\\Program Files\\IronPyt
hon 2.7\\lib\\site-packages']
where C:\<edited>\DocGen\docgen\extractor is root of the project
Jun 17, 2013 at 8:27 AM
Edited Jun 17, 2013 at 8:28 AM
and a workaround for IRONPYTHONPATH not being set:

@echo off
ipy.exe %*
import sys
for idx, arg in enumerate(sys.argv):
    print idx, arg
print "-"*80
for path in sys.path:
    print path
import package.module
please, note that interpreter arguments must be set in launch-wrapper.bat and not in gui
Jun 17, 2013 at 3:56 PM
That's odd, we should definitely be including the project root in IRONPYTHONPATH when the search path is set (and should be doing it anyway, but it looks like we aren't?). Environment variables are inherited, so I wonder if setting IRONPYTHONPATH through System properties will work? In any case, I've filed a bug, since we ought to be getting this right.

I suspected that changing command line args often would be the reason - I do the same thing - so I've logged a feature request to add a dialog for doing this when you launch with a certain key combo. If you're also changing the script you start with, there's a right-click menu in Solution Explorer to run a specific file ("Start with/without debugging"), in the Project menu for the current file, or in the editor itself (it is called "Debug as Script" there, but it's basically identical to "Start with debugging").