forcing a re-index

Recently (version 3.0.4), app 'cant resolve' references and trips all over the <includes> after a syntax error is introduced in a macros.h that is in the precompiled headers. The only way to get rid of this is to reindex (now by closing and reopening the project)...  shortcut to do this please ?

10 comments
Comment actions Permalink

Hi Yves,

Do you mean that your project has red code after the problem was resolved in headers?
Do you have a project that we can use to reproduce the problem?
Please, send us an example! There are too many potential reasons for the issue.

You can add information to the issue.

Regards,
-uta

0
Comment actions Permalink

yes, red code all over. Offers me to <include> already included headers :)   yet it compiles fine.  I dont have a project to share, but i will try to find a minimum example, or at least take screen shots next time i mess-up my headers.

but, coming back to origninal question : can I somehow force a re-index ?

0
Comment actions Permalink

Does "FIle | Invalidate Caches / Restart" help?

0
Comment actions Permalink

kill -9 works, but i was hoping to avoid.

Did not happen since last week. However, now I'm curious. What's the purpose of caches?  what is being cached? Anything i could read on this 'feature' ?

0
Comment actions Permalink

OK. Could you send us the Java Stack Trace for frozen AppCode process?
You need to use the jstack util to do this. Seems we got the exponential algorithm or deadlock on UI thread.
To localize the problem we need to have that dump.

0
Comment actions Permalink

as soon as it happens i will trace with jstack. Dont hold your breath, i was on the last miles of refactoring nasty 'include' loops ... could be a while still.

0
Comment actions Permalink

Alexey, here is a classic case of what i am going through.

Use case : refactoring my game engine to be ARC and 64bits friendly.  I created a dummy game, where i am adding GE (game engine) classes one by one, and cleaning the mess. When i imported the class on pic, AppCode whined (legitimately)  that it could not resolve GEPersistableP (a protocol). So i added my protocols 'en masse'. After about 15secs of mulling it over, the #import got resolved ... good. However, the use of the protocol in one of the method signature is broken !!!!  First sign of trouble. The index is broken. My only way out of this is to close the project, and re-open it to force a re-index. Sure enough , it works.  Here is the clincher : even if i was willing to share that library's project, the moment you open it the problem is gone.

for now i am at 14/424 classes, so the time loss is not too extravagant. But as i advance into this, the close-reopen will start not working, and i will have to shutdown AppCode, restart.  bummer.



Attachment(s):
Screen Shot 2014-08-16 at 12.20.05 PM.png
0
Comment actions Permalink

Thank you for use case description. Seems that your problem need deeper investigation.

I created a bug OC-10636 and subscribed you as watcher.

0
Comment actions Permalink

another very localized use case (i put it here because YouTrack complains that my browser does not have java 1.5.0 enabled, which it does).

while refactoring this protocol, i could not locate why i had imported GEEngineSpecs.h (ss 8.33.49)

So i commented the import out  The editor then highlighted an undefined (the original reason why i had imported the definitions), and offered to import it. (ss 8.34.12)

Silly me, i proceeded to 'un comment' the import, and bang ! corrupt index (ss 8.35.50).

arghhh .... close/reopen.

So i tried again (after closing/reopening), and if instead of un-commenting, i had accepted the offer to import, the index was ok !!!.

this is repeatable.



Attachment(s):
Screen Shot 2014-08-19 at 8.35.30 AM.png
Screen Shot 2014-08-19 at 8.34.12 AM.png
Screen Shot 2014-08-19 at 8.33.49 AM.png
0
Comment actions Permalink

Just ran into this same issue, not sure what's caused it.

The project was fine, but then a week later I got back into it and I had ton's of problems with symbols and include files that were already there.

0

Please sign in to leave a comment.