I am trying to convert previously objective C code which is without ARC into ARC. I am fallowing the procedure like in Xcode: File > Edit > Refactor > Convert to ARC.
But I am not able to convert it, because it's generating lots of errors. I searched about this; I am trying to change the build settings in Xcode Target.
The Convert to ARC tool is not a magic bullet that makes your project suddenly ARC ready. What the tool is does is remove all of your calls to things like release & retain, it can also take care of switching some autorelease pools to the new #auto release {} style.
Before it does any of this it runs a pre-flight script to look for stuff that is too complicated for it to figure out and flags them as errors so you can go through each one and make the correct fix.
You need to step through each one of those 84 issues and figure out the solution to each one. Most likely there are half a dozen or so kinds of errors that are in multiple places but each occurrence may have a slightly different solution. Xcode may suggest a few possible fixes for some of the errors (any of the errors that show a stop sign with a white square in it have possible fixes, Xcode just doesn't know which one to use so you need to pick). Some of the issues will be easily solvable with a little help from Google. There will also likely be more errors than that in the end (I converted one project over that each time I fixed errors and tried to convert it reported more).
For the errors that you can't figure out after doing some research you should post questions about here, make sure to be specific as there are many possible things that could cause issues when converting to ARC.
Related
I have some code comments like this:
/**
How to use this method.
#discussion To use it, do something like the following
id hook = [[STDeallocHook alloc] initWithBlock:^{
// Do something when 'hook' is dealloced
}];
*/
So the code example is indented with 4 spaces. When I compile the docset with appledoc, it compiles correctly and shows the code as code in the API reference I generate. However back in XCode (Where I have appledoc creating warnings for issues in the doco) I get the warning:
Invalid [[STDeallocHook alloc] reference found hear STDeallocHook.h#16, unknown object: [STDeallocHook !
I think what's happening is that appledoc is looking for markdown links inside the code block.
How can I stop this warning from appearing?
I've been unable to stop it as well. It looks like it's been a known bug since 2011, but it's still broken.
Interestingly enough, I don't get it for everything. In a large code example, I'll only get a few of them... still haven't figured out how it determines to cause me grief or not...
Workarounds
This works around the warning, and looks fine in the generated documentation, but looks like crap in plain text: substitute the leading [ with the HTML escape code [
Future Fix
Supposedly, the mythical version 3 has addressed it, but I can't find any mention of an ETA for it. There is a "3.0exp1" branch from March 2012, and a "3.0dev" branch from October 2014.
If you have both the time and inclination, maybe you can see how it was fixed and patch it yourself (though the codebase has apparently changed a ton since then).
My Attempt
I felt unsatisfied with that answer, so, I went back and looked at the source code. First time in that code. It's not exactly easy to navigate... and none of the classes are documented, which I find quite strange, especially for a documentation tool.
Anyway, I think I know why I only get the warning sometimes. The parser treats all underscores as formatting markers. Thus, if it finds two of them in the same "block" of text, it splits them up. Since the code I tested on had category documentation, only the last one encountered in each "block" caused a warning... because all the others were treated as italics... and then ignored.
Also, it seems that I may be able to coerce it into skipping source-code blocks if they are marked as either...
#code
[self wjh_doSomething];
#endcode
or
```
[self wjh_doSomething];
```
or
~~~
[self wjh_doSomething];
~~~
The first is common in documentation blocks, the latter two in markdown.
It's a hack, but it seems to work. I sent a PR, which can be found here. Who knows if it will get accepted, but feel free to try it out yourself if you are so inclined.
I think I'll at least use it locally, as it cleans up a ton of warnings for me... and I may just go try to regenerate all my documented stuff to boot.
Edit
Well, I guess I should have gone and looked at the open PRs first. There seems to be a PR already sitting there that deals with the same issue, that has been there since May. It would have saved me time... but it was a little fun experimenting with it a bit ;-)
You may want to use that one... it seems to be simpler. Simpler is better, but I have not used that one and I'm not sure it completely ignores the blocks, but he seems to have quieted the warnings with his patch.
That one does not support #code/#endcode, which I'm glad to have.
I have two targets in my project with overlapping classes.
I converted one target to arc and now I can't convert second target, beacues files common with first target are already converted. Unchecking these files during conversion not working.
Please help!
I've run into similar problems in the past. The solutions that I came up with weren't particularly elegant, but they did work.
If the second target has a small amount of changes over the first, you can go in to Xcode and change the Objective-C Automatic Reference Counting setting to YES for the second project and then manually fix the problems. This works OK for a small number of files, but isn't as comprehensive.
For significant changes, I ended up using my source control system (Perforce in my case, but git, hg, whatever should work fine) to temporarily roll back my changes for the first target and re-apply them to the second target so that I could use the automated tools, then I did a diff between the files that were changed in both runs to make sure that the changes were the same (I don't recall any differences).
So. The most painless method I figured out was to add second target as build dependency to the first one. Select both in conversion dialogue, and then remove this dependency after conversion. It 100% works.
So it's my first time to try and use jsonkit. I've been looking for the past hour and couldn't find any installation instructions so I just tried copying and pasting the files and then adding them into the xcode project and then import them. But when I compile it would throw a dozen errors, which would usually have ARC restrictions on it. One of these errors has this :
JSONKit does not support Objective-C Automatic Reference Counting
With that said, are there any specific instructions I need to follow for this to compile properly? Or maybe point me to the right direction?
Thanks!
This is Happening because here you are mixing the non-arc Code in ARC Code,that's why this error is coming.You can use below idea of mine and it works fine , have used the same in past
.
Hey You can Disable ARC for JSON classes by just set a flag in under the Build Phases of App setting.
and the flag is
-fno-objc-arc
As Below Image depicts the Way how to do this.
It would work with charm..!!!!
I've recently converted my iOS project to ARC. I have two targets in my project. One is the application itself, and the other is a set of GHUnit tests. I have approximately 200 tests that do quite a lot of work in terms of creating and modifying Core Data objects. The Core Data store used by the tests is an in memory store, and is thrown away once the tests are finished (i.e. it is not persisted anywhere).
When my tests have been running a while (they never reach the exact same point before the error is thrown, but it is always around the same tests) the application crashes with an EXC_BAD_ACCESS (Code=2, address=...)
The output in the console is as follows:
I've followed the instructions here in this answer, and set my main.m file of the GHUnit target to use the -fno-objc-arc compiler flag, but that doesn't seem to have helped.
I don't really understand what these errors mean, and searching for them doesn't seem to have helped. My only guess is that I am running out of memory, but I'm not sure why or how, considering ARC should be releasing objects for me.
I'd really appreciate any help anyone can give me to fix this! If you have any questions just leave me a comment and I will get back to you asap!
Thanks!
Chris,
First, As you have a memory exhaustion problem, you should look at your tests running under the Instruments allocation tool. Remember to turn on VM automatic snapshots. Then you should mark the heap multiple times as the tests execute.
Second, while this may be related to ARC, it quite possibly isn't. In general, ARC apps, because they can automatically release objects sooner, have a smaller footprint than MRR apps. The move to a new compiler with different options may just be uncovering a pre-existing problem.
Third, because you are using an in-memory database, my first test would be to just change it to a SQLite DB. It can have a much smaller footprint. (While you may choose to return to in-memory DBs later, we're trying to find the cause of your memory exhaustion. An in-memory DB can use a lot of RAM. Hence, lets take is out of the equation.
Once you've done the 1st and 3rd tasks above, please report back your results.
Andrew
In my Cocoa development, every so often I include a header into a source file so I can use a particular class in it. But then later I delete that code from the source file, and forget (or don't really want to worry about) deleting the corresponding #import.
With time, a lot of redundant #import lines pile up in my source files, throughout the codebase.
Now, I know that these lines cause no harm, but is there any easy way to get rid of them automatically? At least it would make the top of every file cleaner ;)
There's a tool that does this for C and C++, but as far as I could tell, it doesn't yet support Objective-C. I've filed a ticket to ask for that.
nothing comprehensive off the shelf comes to mind.
1) JetBrains' AppCode may help. It's quite young at this time (e.g. not even 'beta', but it is publicly distributed), and doesn't fully understand structures of includes and nontrivial xcode projects and build settings, but it is likely smart enough to handle simpler cases.
2) you could create some scripts to accomplish what you're after. it wouldn't be terrible if you already have a project which builds out everything using common build settings. doing this manually is a pain, and is usually not a good use of time in larger projects if you are not using a high level of automation.