Thoughts on supporting Automatic Reference Counting (ARC)

[rogchap]

iOS5's release is just around the corner and along with it will be XCode 4.2. Default projects in XCode 4.2 have ARC enabled, therefore all Nimbus code will cause errors.

We need to have a think on how we are going to support ARC for new projects, and still maintain compatibility with previous projects.

Disabling ARC is an option, however I'm sure many (especially new) developers will want ARC on.

Does anybody have any thoughts on this?

[bmeurer]

Nimbus could use macros for various operations related to reference counting. See the GTMARCMacros.h in the Google Toolbox for Mac for example.

[rogchap]

Looks good to me.

We should try to get ARC support in sooner rather than later; as the project grows there will be more to refactor. Maybe aim for the 0.7.0 release!?

[jverkoey]

@bmeurer looks like Apple recommends an all-or-nothing approach to ARC:

http://code.google.com/p/google-toolbox-for-mac/source/detail?r=458

I can see the rationale. It can easily be argued that those macros add more complexity than they remove.

[phillipuniverse]

Is there an equivalent of TT_RELEASE_SAFELY for Nimbus? I assume so, and if it's possible to check to see if ARC is enabled (maybe there's a macro somewhere?) then the equivalent TT_RELEASE_SAFELY could just be an empty call (similar to how the current TTDPRINT works).

[bmeurer]

That'll cause trouble for various projects, who cannot switch to Xcode 4.2 without getting into trouble (i.e. missing SDK 3.2 support, etc.).

[jverkoey]

@phillipuniverse NI_RELEASE_SAFELY.

The hardest part here is that I think we will have to make a committed decision one way or another. Supporting both does not look like an option.

On the one hand I'd love to support as many older SDKs as possible, but on the other we should try to use new technologies in Nimbus as much as possible.

I hear on the grapevine that ARC is weak-linked back to iOS 4.0? If this is true, then I could stand behind shifting the range of supported SDKs for Nimbus from 3.0=>5.0 to 4.0=>5.0, especially seeing as 5.0 is just around the corner.

[bmeurer]

Using ARC-only will nevertheless require some preprocessor tricks in the header files to make it work with non-ARC code that includes the headers, AFAIR. The good thing about Nimbus wrt. other libraries such as Three20 is that there are only a few projects using Nimbus yet, so a switch to ARC shortly after the iOS 5 would not cause too much trouble.

[jwang]

This is something that's been "plaguing" all of the third-party libraries. Everyone's been hit. ASIHTTPRequest, Three20 and pretty much everyone else who wrote a static library.

@jverkoey - Yes. ARC does work on iOS 4.0 but not on anything lower. AFAIK Apple is pretty much dumping iOS 3 when 5 comes out. You can see that by the move that XCode 4.2 also dumps arm6 support by default. A move that some are confused about.

For ARC, I really wish Apple would just give you a checkbox when you create a new project, asking you if you want to use ARC or not. It was quite the exercise to convert a new ARC project to a non-ARC project. If ease of use if your goal, I would highly suggest starting a branch that does ARC only for the near future. I'm trying to figure out how we can do that for Three20 right now.

[fcy]

There's one thing that ARC on iOS 4 isn't compatible. We can't use weak references on iOS 4, we've to use unsafe_unretained.

The only difference between them is that weak references nil themselves, unsafe_unretained don't.

If it counts on anything, I agree @jverkoey in this case. That's go ARC enabled removing 3.0 support.

[0xdevalias]

For my 2c, it looks like Apple are pushing the ARC route in the future, so it's an issue that's only going to get more complex/have a bigger impact to change as time goes on. While being able to support as many devices as possible is important, I think that it's better to design for the future rather than be unnecessarily weighed down by the past.

[mamcx]

+1 in fully support ARC - even for only support 5+!-. If something is new, is new. The adoption for new OS releases is high among iOS users. Also, for the old exist Three20. When this project get ready for prime time, a lot of time will pass, and provide backward compability will look (in the future) like a mistake.

[mhooge]

I personally like managing memory myself. I find it easy 95% or the time. However, 7 months in to my first real development job, I've found that no one that I work with likes memory management, so there are leaks, and many of our third party libraries leak. Tracking down these leaks takes a lot of time. Go for ARC and abstract that away as much as possible.

Yes, dump support for 3.0. OTA updates are around the corner, and users will have the ability to update more quickly than they do now.

[jverkoey]

Haha, I'm the same as you @mhooge. I'm a control freak when it comes to my code (probably why I will forever like C-based languages over Java).

It looks like the overwhelming force is behind going with ARC full-steam ahead, so I think that is what we will do. Can I ask whether there is anyone in this thread (or elsewhere, for that matter) who knows ARC really well and would like to champion this task? I need someone who can own this and be accountable for any questions such as which SDKs are supported and any caveats.

[taknology]

Having dug into the core of three20 myself with several of my own customizations I think it will be a daunting task to convert for ARC and iOS 5 in general. I think, with Nimbus, the logical approach is to give in to ARC and move forward with support for that in the early stages before it becomes enormous like three20. I have forked Nimbus and will have a look at the task list and see what I can do to help. Any documented guidelines on contributing?

[rogchap]

Thanks @taknology Have a look at the Hacker notes: https://github.com/jverkoey/nimbus/blob/master/HACKERS.mdown

As this is quite a big job we need to try and make sure we time this well, otherwise we will all be in git merge hell! ;)

Before this officially makes it into the master branch xCode 4.2 needs to be out of beta.

I'm wondering if we can do a change freeze, while this work is done? Then maybe we also need to assign different modules to different people (with a deadline!) so this gets done in the most efficient way.

I'm going to do some research and maybe put together an action plan document for this.

[rogchap]

Anyone interested in learning more about ARC may find this doc helpful: http://clang.llvm.org/docs/AutomaticReferenceCounting.html

[rogchap]

ARC may be explicitly enabled with the compiler flag -fobjc-arc. It may also be explicitly disabled with the compiler flag -fno-objc-arc.

[hffmnn]

@rogchap: To be clear: you can enable/disable ARC on a per file basis, not just per project!

[jverkoey]

If we can enable/disable ARC in code that would be awesome as well - that way people don't have to manually configure the files in each project they add Nimbus to.

[hffmnn]

What about this:
davedelong/DDMathParser@c954d51
especially this in DDMathParser_Prefix.pch

#if __has_feature(objc_arc)

#define HAS_ARC 1
#define RETAIN(_o) (_o)
#define RELEASE(_o) 
#define AUTORELEASE(_o) (_o)

#else

#define HAS_ARC 0
#define RETAIN(_o) [(_o) retain]
#define RELEASE(_o) [(_o) release]
#define AUTORELEASE(_o) [(_o) autorelease]

#endif

[jverkoey]

I think the use of macros adds an extra level of complexity to the code. This goes against the intent of ARC which is to lower the complexity of the code. I noticed that TrahDivad appears to be taking a stab at making Nimbus ARC-compatible.

https://github.com/TrahDivad/nimbus/commits/master

[hffmnn]

Well, yes...but this extra complexity is for the nimbus developer who wants to support ARC and non-ARC. The user of nimbus will not have to use these macros. And nimbus would compile in ARC and non-ARC projects without any added complexity to the user.

[jverkoey]

Hm. That's a good point. If you'd like to take a stab at it and report the findings that would be awesome :)

I do wish that there was another way, rather than using macro methods, to do this because it requires of anyone hacking on Nimbus to be aware of this switch from obj-c method invocations to macro methods.

[rogchap]

Using macros will still not get round the use / non use of the dealoc method.

Sent from my iPhone

On 30 Sep 2011, at 20:25, Jeff Verkoeyenreply@reply.github.com wrote:

Hm. That's a good point. If you'd like to take a stab at it and report the findings that would be awesome :)

I do wish that there was another way, rather than using macro methods, to do this because it requires of anyone hacking on Nimbus to be aware of this switch from obj-c method invocations to macro methods.

Reply to this email directly or view it on GitHub:
#40 (comment)

[hffmnn]

I'm sorry but what do you mean with use / non use of dealloc?

[jverkoey]

From my understand you would have to conditionally compile the dealloc method out or you'd get compiler warnings.

[rogchap]

@jverkoey is basically right; in an ARC enabled project you shouldn't need to call the dealoc method. But, if you do override the dealoc method (like removing notification listeners, for example) you must not call super as this is handled by the compiler.

[dhennessy]

I think you have to decide whether to use (and therefore support) ARC in Nimbus or not. Using macros to delay the decision would be a nightmare - there would be a whole new set of bugs introduced because some people would only see one flavor. Also, it doesn't actually gain you anything because you'd have to manually code all the memory management, even if it was compiled out.

For a new library like Nimbus, my vote would be to embrace it. For older libraries, I bet we start seeing forks as older, stable, releases are non-arc and new features are arc-only. It's going to be messy for a while before things settle down.

[rogchap]

As much as I want to fully embrace ARC for Nimbus, we also need to take into account the use of other 3rd party libraries that Nimbus also utilises like JSONKit and ASIHTTPRequest.

On 6 Oct 2011, at 10:30, Denis Hennessy wrote:

I think you have to decide whether to use (and therefore support) ARC in Nimbus or not. Using macros to delay the decision would be a nightmare - there would be a whole new set of bugs introduced because some people would only see one flavor. Also, it doesn't actually gain you anything because you'd have to manually code all the memory management, even if it was compiled out.

For a new library like Nimbus, my vote would be to embrace it. For older libraries, I bet we start seeing forks as older, stable, releases are non-arc and new features are arc-only. It's going to be messy for a while before things settle down.

Reply to this email directly or view it on GitHub:
#40 (comment)

[NukemHill]

@rogchap - I thought you could use non-ARC code with ARC code. Is that not the case?

I will admit that I am not savvy with ARC to nearly the extent that I need to be. It has been on my mind, and my app has just been released to the AppStore. I'm using Three20, and just stumbled on Nimbus, so I have high hopes for your project. Three20 has been both a G-dsend and a royal PITA.

My personal vote (for what it's worth) is to embrace ARC from the outset. It has the potential to greatly simplify the development process, and if you roll Nimbus out in the manner you are committed to, then it becomes a state-of-the-art library for developing UIs.

I can't make any promises as far as time commitments, but I'm willing to take some spare time and dig into what you are doing. Maybe my tired eyes and cranky brain can contribute something to the conversation!

[rogchap]

I'm sure everyone has seen this but I thought it would be helpful to anyone looking into doing any ARC update:

http://developer.apple.com/library/ios/#releasenotes/ObjectiveC/RN-TransitioningToARC/_index.html#//apple_ref/doc/uid/TP40011226-CH1-DontLinkElementID_6

[rogchap]

Nimbus Core - Done #81

[jverkoey]

The ARC modifications for Nimbus core have been merged into the arc branch.

[rogchap]

Nimbus Web Controller - Done #84

[rogchap]

I'm going to do Nimbus Model at the same time as Attributed Label as I use it in my Attributed Label example app.

[rogchap]

Nimbus Models and Nimbus Attributed Label - Done - #85

[rogchap]

Nimbus Interapp - Done #86

[jverkoey]

Damn dude, you're on fire.

[rogchap]

Nimbus Network Image - Done #87

[NukemHill]

Okay, so I don't have to feel completely inadequate and intimidated by the amount of work he's doing? This really is an obnoxiously ridiculous volume? ;-)

I'm duly impressed. I was kicking out a lot of code today for one of my project prototypes. And I felt like a piker compared to Roger!

I think it's time for a Scotch. Been a long week. I'll see if I can dig into nimbus this weekend. Should be fun.

-greg

On Oct 21, 2011, at 10:55 PM, Jeff Verkoeyen wrote:

Damn dude, you're on fire.

Reply to this email directly or view it on GitHub:
#40 (comment)

[rogchap]

Sorry @NukemHill :)

Nimbus Launcher - Done #88

[jverkoey]

I'm beginning to think that the solution in f16b650 may not scale very well - perhaps we should define a preprocessor macro for backwards compatibility with iOS 4.* builds rather than have that three-line preprocessor macro patch.

[rogchap]

Nimbus Overview - Done #89

[jverkoey]

I can't wait for the final commit.

- #define NI_RELEASE_SAFELY(__POINTER) { [__POINTER release]; __POINTER = nil; }

:D

[rogchap]

Nimbus Photo & Nimbus Preprocessors - Done #90

[rogchap]

Right... That should be all of Nimbus updated for ARC, which is now in the arc branch. Enjoy!

[NukemHill]

"Sorry @NukemHill :)

Nimbus Launcher - Done #88"

Oh, please. No apology necessary! You're doing fabulous work. I only wish I could be so consistently productive.

I'm going to check the code out now and take a gander at it. I make no promises, but I'm hoping to have something positive to say.

I'm definitely looking forward to how you guys have documented your code. That, more than anything, is what kills me with open source projects. Poorly documented code (and I admit to being guilty of that with my own code; I've actually tried to get better about it recently) turns otherwise useful projects into nightmares. I think the premise of no code release without solid documentation is a fabulous foundation.

[NukemHill]

Mkay. Showing my rookie status here. I've not kept up with documentation standards, as most of the open source I've dealt with hasn't had enough to worry about it. But now I'm reading through the headers and extra docs and seeing lots of fun and interesting markup, and I have no idea what reader to use to be able to view it in what I feel is an informative manner.

For example, the NimbusModels.h file has a ton of detail on how the model architecture works, with embedded html that is supposed to display a side-by-side comparison of standard UI implementation vs NimbusModel implementation. Do I need to just cut-n-paste that part of the file into an html file and view it locally in Safari? Or, as I suspect, is there some sort of reader out there that handles the whole markup (markdown?) in a comprehensive manner so that all of the embedded links, html, and whatnot are displayed as I believe you intend it to be.

Sorry if I'm asking a really lame question here. But I'd like to be on the same logistical sheet of music as everyone else.

TIA.

[jverkoey]

Totally fair question.

We use Doxygen to generate our docs. In fact, we use our own version that we've modified to more closely match Apple's documentation style.

You can download the Doxygen binary here:
https://github.com/downloads/jverkoey/nimbus/Nimbus%20Doxygen.dmg.zip

If you're curious, you can also check out the source and modifications we've made to Doxygen here:
https://github.com/nimbusios/Doxygen/commits/master

Once you've installed Doxygen, run the Doxygen app and press Cmd+O to open a Doxyfile. You'll find Nimbus' doxyfile in the nimbus/docs/ folder. You'll also find that there are two doxyfiles, Doxyfile and Doxyfile-docset. The latter is used for our Xcode docsets which you can learn more about here:
https://github.com/jverkoey/nimbus/wiki/Subscribe-to-the-Nimbus-Docset-Feed-in-Xcode

Once you've opened the Doxyfile everything should be set up and ready to go. When you hit the "Run Doxygen" button under the "Run" tab you will generate the docs. Then just click the "Show HTML Output" button and Doxygen will open the docs in your default browser.

As for that giant block of HTML in the models feature, I've been questioning the value of it so I am likely going to remove that god-awfully-large chunk of HTML, haha.

[jverkoey]

Also, here is the Doxygen manual which goes over the various methods you can use to markup documentation:

http://www.stack.nl/~dimitri/doxygen/manual.html

[NukemHill]

Wow. Thanks for the links, Jeff. I've got Doxygen up and running. Fascinating tool. I'll have to dig in some more and see how to implement it on my projects.

Need to take some time and digest all of this. Lots to process. Not grokking the larger picture yet. I think this is one of the issues that I am grappling with--the big picture architectural philosophy, and being able to drill down to the individual pieces and seeing how they work in the real world. The example code is interesting, but maybe incomplete.... I dunno.

In looking at NICellFactory, for example, I think there needs to be a much more extensive example, with a step-by-step conversation discussing responsibilities, message generators and recipients, common errors and missed steps, etc. Maybe that's already in place, and I'm just not "getting it".

Now that I've got Doxygen running, I'll dig more deeply and see if what I'm looking for already exists.

Thanks again. I'll try to get more feedback to you shortly. Need to put some more time into my current projects, but I'm trying to take some breaks and dig into nimbus, too.

-greg

On Oct 22, 2011, at 1:29 PM, Jeff Verkoeyen wrote:

Totally fair question.

We use Doxygen to generate our docs. In fact, we use our own customized version that we've modified to more closely match Apple's documentation style.

You can download the compiler binary here:
https://github.com/downloads/jverkoey/nimbus/Nimbus%20Doxygen.dmg.zip

If you're curious, you can also check out the source and modifications we've made to Doxygen here:
https://github.com/nimbusios/Doxygen/commits/master

Once you've installed Doxygen, run the Doxygen app and press Cmd+O to open a Doxyfile. You'll find Nimbus' doxyfile in the nimbus/docs/ folder. You'll also find that there are two doxyfiles, Doxyfile and Doxyfile-docset. The latter is used for our Xcode docsets which you can learn more about here:
https://github.com/jverkoey/nimbus/wiki/Subscribe-to-the-Nimbus-Docset-Feed-in-Xcode

Once you've opened the Doxyfile everything should be set up and ready to go. When you hit the "Run Doxygen" button under the "Run" tab you will generate the docs. Then just click the "Show HTML Output" button and Doxygen will open the docs in your default browser.

As for that giant block of HTML in the models feature, I've been questioning the value of it so I am likely going to remove that god-awfully-large chunk of HTML, haha.

Reply to this email directly or view it on GitHub:
#40 (comment)

[jverkoey]

In looking at NICellFactory, for example, I think there needs to be a much more extensive example, with a step-by-step conversation discussing responsibilities, message generators and recipients, common errors and missed steps, etc. Maybe that's already in place, and I'm just not "getting it".

That's an excellent point. I do think that we have a lot of room to improve with respect to step-by-step guides and articles. Our technical docs have fairly good coverage, but I think before we release a 1.0 of Nimbus we need to have a comprehensive set of in-depth technical articles covering various aspects of Nimbus as you mentioned.

[NukemHill]

Ah, good. Wasn't sure how that was going to land. Sometimes egos can be prickly around this stuff.

I'll start compiling some notes as I go through the code, and come up with ideas for guides. Should we perhaps open up a new issue and bring focus on technical articles there? It might actually be a good place to start asking questions, like the point I bring up above about NICellFactory. That would give noobs a chance to ask their own questions, and give the more senior people a sense of where the potential documentation weaknesses occur.

[rogchap]

Don't forget that the rendered documentation is also here:
http://jverkoey.github.com/nimbus/

You don't need Doxygen unless you are writing documentation!

And you ca also as the Docset to XCode: https://github.com/jverkoey/nimbus/wiki/Subscribe-to-the-Nimbus-Docset-Feed-in-Xcode

Thought I would point that out, as anyone reading this may think the only way to view the docs is in code or using Doxygen.

Sent from my iPhone

On 23 Oct 2011, at 04:29, Jeff Verkoeyenreply@reply.github.com wrote:

Totally fair question.

We use Doxygen to generate our docs. In fact, we use our own customized version that we've modified to more closely match Apple's documentation style.

You can download the compiler binary here:
https://github.com/downloads/jverkoey/nimbus/Nimbus%20Doxygen.dmg.zip

If you're curious, you can also check out the source and modifications we've made to Doxygen here:
https://github.com/nimbusios/Doxygen/commits/master

Once you've installed Doxygen, run the Doxygen app and press Cmd+O to open a Doxyfile. You'll find Nimbus' doxyfile in the nimbus/docs/ folder. You'll also find that there are two doxyfiles, Doxyfile and Doxyfile-docset. The latter is used for our Xcode docsets which you can learn more about here:
https://github.com/jverkoey/nimbus/wiki/Subscribe-to-the-Nimbus-Docset-Feed-in-Xcode

Once you've opened the Doxyfile everything should be set up and ready to go. When you hit the "Run Doxygen" button under the "Run" tab you will generate the docs. Then just click the "Show HTML Output" button and Doxygen will open the docs in your default browser.

As for that giant block of HTML in the models feature, I've been questioning the value of it so I am likely going to remove that god-awfully-large chunk of HTML, haha.

Reply to this email directly or view it on GitHub:
#40 (comment)

[NukemHill]

@rogchap - Yeah, I discovered that as I was browsing the docs generated by Doxygen. That's pretty much what I was looking for, so it's good to know what's where.

Thanks.

[jverkoey]

Nimbus fully supports ARC now :) W00t!

[taknology]

Awesome!

An iPhone entry so spelling errors (and intermittent words that make no sense) may occur

On Jun 19, 2012, at 7:07 PM, Jeff Verkoeyen reply@reply.github.com wrote:

Nimbus fully supports ARC now :) W00t!

---

Reply to this email directly or view it on GitHub:
#40 (comment)