Refactor menu not active (running on mac via parallels)

[paulbaumgartner]

This is more of a support request than bug report. Sometimes I can use the refactor menu but most of the time it is disabled. I can't tell what the pattern is between working and not working. I'm using Parallels to run Windows and the only reason installed Parallels and Windows was to make us of Rubberduck so I'd really like to get it going. If anyone has successfully used Rubberduck on parallels please let me know.

The info below can be copy-paste-completed from the first lines of Rubberduck's Log or the About box:
Rubberduck version 2.4.0.4556 loading:
Operating System: Microsoft Windows NT 10.0.17763.0 x64 (Note running on OSX via Parallels)
Host Product: Microsoft Office x64
Host Version: 16.0.10730.20280
Host Executable: EXCEL.EXE;

Description
Most of the time the refactor menu is greyed out.

To Reproduce
Steps to reproduce the behavior:

1. Click refresh to ensure rubberduck ready
2. Right click on a variable name
3. Select Rubberduck, refactor

Expected behavior
Menu should be active

Screenshots
Screenshot attached

Logfile
Attached

Additional context
I have seen other support requests that were solved by clicking the refresh button in Rubberduck. I have tried that several times but it does not work.

Occasionally the menu does display, I don't know why

RubberduckLog.txt

[bclothier]

First, just to reassure you - Parallels has no bearing on the issue. I use VMWare, and it works.

Next, though you say you refreshed, and the screenshot show Ready, the status bar doesn't seem to agree with what is selected. For one, your selection is inside the procedure GroupIngredientsFromIngredients, but the statusbar shows that you are in AddIngredientsFromRecipesAndGroupBy procedure. Furthermore, the procedure is a Sub yet the status bar shows it as a function returning a variant.

Did you edit things while it was parsing or after it said Ready? It would make the tree stale and thus refactorings would be unavailable.

[retailcoder]

The toolbar mismatching the selection looks like the code was modified since the last time parser state was updated. Keep in mind that the VBE is not telling us when the code changes, so if a Function became a Sub and moved 10 lines underneath where it was last time Rubberduck parsed the code, then refactorings being disabled isn't a bug: running any refactoring or quickfix against a stale parse tree is pretty much guaranteed to wreck the code, so we disable it.

"Refreshing" essentially tells Rubberduck about exactly what changed in the code panes since the last parse, so that the position of every single token is exactly where it's expected to be. We do this processing "in the background" (leaving unchanged modules alone) so that the project can still be navigated, but any modification to the code will invalidate it.

The "status bar" (would be an actual status bar if the VBE had one) tells you how Rubberduck is seeing the code: if you select a variable and the status bar doesn't say you've selected that variable, then the code pane is out of sync with the parse trees and Rubberduck needs to reparse.

[comintern]

Stepping back a bit, based on my quick read of the Parallels Wikipedia page, it's possible that there might be at least a couple Parallels features that might be interfering with Rubberduck. The main one that pops to mind is the "Coherence" feature, although it appears that there might be? some issues in flushing the IO stream from the log file from multiple threads. The attached log is missing any indication that the parsing runs happened at all, but then it has a handful of inspections running at the bottom (which it can't do without a parse tree).

Can the OS integration features be disabled or configured separately for running Office? I'm also running in a virtual machine (VirtualBox on Linux Mint in my case), but the level of OS integration is much, much lower than Parallels based on what I'm seeing in the features list. In my case, communication with the host OS is limited to clipboard sharing and exposing the host file system as a network share (via Samba).

I also noticed a couple mentions of Windows 10 compatibility issues, although I have no idea how this might effect any given software running under Parallels in a Windows 10 guest.

[paulbaumgartner]

Thanks very much for your replies @bclothier and @retailcoder

As I recall, before taking the screenshot I clicked refresh and then semi-randomly used an open code window to demonstrate the issue. I'm pretty certain I didn't change the code, particularly to such a significant extent as changing from a function to a sub.

So if I understand correctly, after the initial refresh, Rubberduck needs to keep refreshing in response to changes in the code. Mostly it does this automatically in the background but until it completes you wouldn't be able to use the refactor menu. (Or are you saying a manual refresh is required after each change?)

So to try and reproduce, I did a refresh, then right clicked on a variable. Refactor menu worked
I added a line of code "a=1". Refactor menu did not work (testing on existing code not added line)
I waited 3 minutes, checking every 30s or so but the menu did not start working.

Noting the comments about the status bar module not matching the code window I had opened, I closed all code windows and opened 1 using the explorer. Then they matched but I still had the same issue with refactor menu.

One possible line of investigation is the performance on Parallels. The first refresh took 2:14 is that longer than normal? If I have the inspections window open the Rubberducks seem to spin for several minutes (I'm not sure if they ever stop, I usually close it)

@comintern thanks for looking into parallels, I don't know much about how it works. I'm not using the coherance option but not sure what else parallels is doing in the background. Overall I do find performance a bit slow but I've turned off Cortana and Windows defender and the system seems to be a bit more useable now.

I'm also attaching the log file from my testing today as it might be more comprehensive.
RubberduckLog.txt

[MDoerner]

To clarify, after adding the additional code, did you click the refresh button? RD does not parse on keypress. Although we only reparse the modules that have been modified, the process takes too long to do it on keypress. Moreover, RD does not reparse periodically.

There are a few times an automatic reparse happens, though. E.g. After adding, removing or renaming a module an automatic parse is triggered. The same it true after executing a refactoring.

[paulbaumgartner]

No I didn't click refresh after adding code. I've misunderstood how it works.

How long is a typical refresh, does 2mins seem long?

[bclothier]

The initial parse will usually take the longest because Rubberduck has to know everything about the entire project.

After that, we try to minimize the updates we require, but due to how VBE works, we can only refresh at a per-module level. One ramification of that is that if you edit a public procedure's signature in a module that is referenced by 10 different modules, then Rubberduck must refresh those 11 modules.

To confirm are you saying that even after the initial parse, it still takes you up to 2 minutes to re-parse?

[paulbaumgartner]

That refreshing scheme makes sense

Yes two minutes on subsequent refreshes. For example when I did the first refresh and then added the line "a=1" it took 1:55 to refresh again. And that is not referenced anywhere else. Might my system be doing a full refresh each time rather than incremental?

That's sort of why I thought you only needed to refresh once; because it seemed impractical to be refreshing frequently.

[Inarion]

In my "main" project, an Excel Add-In with about 10k lines of code and several references to additional libraries (like ADODB and Access), the initial parse takes 20s (according to RD's log) and subsequent parses typically 9-10s. That's on a Windows 7 machine, though. So in that light, the parsing times you're encountering seem rather high.

Edit: My source files corresponding to the above ~10k LoC weigh about 700KB combined.

[paulbaumgartner]

Thanks that's a helpful reference point. I think my project is about 30k lines (including whitespace though, not sure how code lines are normally counted), total source files is 1MB.

So some potential options could be

• virtual machine running slow
• something in my project causing RD to get stuck / run slower

Examining the parse time via the log is a good idea. As far as I can tell theres a few parse errors in mine. I'll try to narrow down the issue by removing some modules and see if it works any better. If anyone can assist with interpreting the log file that would be great

thanks every one for help so far

[paulbaumgartner]

In the logs I've noticed a couple of sections where the time jumps 10-20s at a time, whereas all the other entries only have milliseconds between them. Any thoughts if this is significant?

                  |
                  V
2019-02-28 06:28:49.5980;INFO-2.4.0.4556;Rubberduck.Parsing.VBA.RubberduckParserState;RubberduckParserState (20) is invoking StateChanged (Ready);
2019-02-28 06:28:50.9885;DEBUG-2.4.0.4556;Rubberduck.Parsing.VBA.ParseCoordinator;Parsing run finished after 105.8625537s. (thread 14).;
19s jump
2019-02-28 06:29:09.1135;DEBUG-2.4.0.4556;Rubberduck.UI.Command.MenuItems.CommandBars.AppCommandBarBase;(34166919) Executing click handler for commandbar item 'Ready', hash code 35011040;
2019-02-28 06:29:09.1135;DEBUG-2.4.0.4556;Rubberduck.Parsing.VBA.ParseCoordinator;Parsing run started. (thread 17).;
2019-02-28 06:29:09.1135;INFO-2.4.0.4556;Rubberduck.Parsing.VBA.RubberduckParserState;RubberduckParserState (21) is invoking StateChanged (Started);
5s
2019-02-28 06:29:14.9344;INFO-2.4.0.4556;Rubberduck.Parsing.VBA.RubberduckParserState;RubberduckParserState (22) is invoking StateChanged (LoadingReference);
2019-02-28 06:29:16.6854;DEBUG-2.4.0.4556;Rubberduck.Parsing.Common.ParsingStageTimer;Loaded and unloaded referenced libraries in 264ms.;

2019-02-28 06:29:17.0055;DEBUG-2.4.0.4556;Rubberduck.Parsing.VBA.RubberduckParserState;Module 'modTestDataCreators' state is changing to 'ResolvingReferences' (thread 19);
2019-02-28 06:29:17.0055;INFO-2.4.0.4556;Rubberduck.Parsing.VBA.RubberduckParserState;RubberduckParserState (23) is invoking StateChanged (ResolvingReferences);
4s
2019-02-28 06:29:21.8640;INFO-2.4.0.4556;Rubberduck.Parsing.VBA.RubberduckParserState;RubberduckParserState (24) is invoking StateChanged (ResolvedDeclarations);
13s
2019-02-28 06:30:34.1291;DEBUG-2.4.0.4556;Rubberduck.Parsing.VBA.RubberduckParserState;Module 'modGeneral' state is changing to 'ResolvingReferences' (thread 17);
2019-02-28 06:30:34.1308;DEBUG-2.4.0.4556;Rubberduck.Parsing.VBA.RubberduckParserState;Module 'WorkbookReporter' state is changing to 'ResolvingReferences' (thread 17);

[Vogel612]

The first jump you noticed seems rather innocuous. The parsing run itself finished and Rubberduck has nothing to do until you click refresh 19 seconds later.

The other jumps are somewhat long, but not something to be terribly worried about, IMO. They match pretty well with incidents of Rubberduck having a lot to do. If you set the Log-Level to TRACE, most of these jumps will turn into a high volume of TRACE entries

[paulbaumgartner]

@Vogel612 sorry for the delayed reply, I've checked and confirmed the log was set to trace. Note those individual jumps may not seem that long but the overall time of that run is at least 1m30s (from 29:09 to 30:34)

I did notice some processes on my mac using a lot of resource and have removed those. Same in the VM. Things are now working a little better, but refreshes with no change to code still take around 30s. It's useable but not great for regular refactoring.

I've pretty much concluded it's the VM that runs slow and probably not much to be done on the Rubberduck side.

[bclothier]

Since there has been no activity on this issue, I assume the issue is addressed for now and will close the issue. Of course, if there are any new feedback, feel free to open an issue. :)