Thoughts on supporting Automatic Reference Counting (ARC) about nimbus HOT 73 CLOSED

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

from nimbus.

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!?

from nimbus.

@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.

from nimbus.

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).

from nimbus.

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.).

from nimbus.

@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.

from nimbus.

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.

from nimbus.

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.

from nimbus.

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.

from nimbus.

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.

from nimbus.

+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.

from nimbus.

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.

from nimbus.

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.

from nimbus.

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?

from nimbus.

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.

from nimbus.

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

from nimbus.

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

from nimbus.

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

from nimbus.

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.

from nimbus.

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

from nimbus.

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

from nimbus.

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.

from nimbus.

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.

from nimbus.

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 [email protected] 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)

from nimbus.

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

from nimbus.

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

from nimbus.

@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.

from nimbus.

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.

from nimbus.

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)

from nimbus.

@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!

from nimbus.

Thanks @NukemHill - any time is time well spent! :)

Yes... you can turn on/off ARC on a per file bases... but that is a pain for maintenance.

I think we need to embrace ARC also, as this will make things easier for Developers integrating Nimbus in the future, especial as ARC enabled is the default.

Has anyone started work on this?? If not I'll wade through Nimbus and get this done...the sooner the better in my opinion.

from nimbus.

I'm definitely on board with this as well. Have we fully answered the question of whether we'd be able to use an ARC Nimbus in a non-ARC project?

from nimbus.

If we change Nimbus to be ARC enabled there will be a few issues:

• Third party libraries would have to be ARC enabled also (or the user would have to set -fno-objc-arc for every .m file that is not ARC enabled)
• You would have to use XCode >4.2
• Your project would have to be ARC enabled

If you have a non-arc project you would have to ARC enable it and then set -fno-objc-arc on all your .m files that are non-arc.

The problem is trying to mix and match, as adding '-fno-objc-arc' to every file is a pain unless we could come up with a script for this?

from nimbus.

Another option would be to use Nimbus in a static library way and keep ARC disabled for the Nimbus library; static libraries can be used in ARC-enabled and ARC-disabled projects... but I prefer the way it is now :)

from nimbus.

I wonder if there might be a way to go at it from the other direction. For a non-ARC project, could we explicitly enable ARC for all of the Nimbus source using #pragma statements?

from nimbus.

Thinking on my feet here... but I think if we had a non-ARC project would be not have issues with the global NSReleasePool ??

from nimbus.

Hrmm, this is definitely reaching the edge of my knowledge for ARC quickly, haha. Let's try to answer these last few questions before we go full-tilt with ARC. I know that it's unlikely, for example, for the Google+ iPhone app to switch to ARC any time soon - if ever - simply due to the size of the project, so I'm hesitant to completely switch Nimbus over yet.

from nimbus.

ARC is an all or nothing kind of thing!

I think the solution would have to be to leave Nimbus the way it is and for ARC-projects you would have to set -fno-objc-arc for all Nimbus files.

Creating a pre-build script to automate this might be the way to go. Bit of a pain for developers, but you only have to do it once (per ARC enabled project).

This is what other libraries are doing: https://github.com/gowalla/AFNetworking/issues/36#issuecomment-2160306

from nimbus.

Take in account the future.

Nimbus is not widespread now. Have not a legacy to protect. When will be the
first usefull release? Because is is for the next year then whay bother for
the past?

Nimbus is in the best position possible to make the switch. Is enough new,
have not a big follow, implement new ideas. Is fresh & ready.

So, if somebody need it in pre-ARC, the compile it as static lib. That is
what I'm doing right now for a new ARC-ONLY project: I create a subproject
with all the old-stuff lib, add it to the ar-only as dependency, compiloe
both.

Pain? Null. Is simple, easy & work. I compile like 6 external libs + a lot
of my own custom code.

Three20 is among of them, and the biggest one.

NO PROBLEM AT ALL!

Mario A.Montoya
Gerente
http://www.elmalabarista.com

Haz pedidos & facturas con tu iPhone: http://www.bestsellerapp.com

from nimbus.

I think we should convert to ARC, and provide a detailed/easy guide for how someone in a non-ARC project can setup/use Nimbus (be it compiling as a static lib, setting some flags on the files, etc). We should also provide as much automation as possible to make it easier for the user to set it up this way.

Apple is pushing ARC as the future, it's better to change now than to try and convert everything later (Three20 anyone?)

from nimbus.

oh man, my project is allready using some Nimbus. Doe this mean that when you guys flip to ARC, and i update , I will have to flip my project that uses Nimbus to arc too?

BTW i thinking going all out ARC is a good thing and seems to make sense

from nimbus.

@yeahdixon: As @alias1 mentioned, we'll have to put a detailed guide for this together. In short, you'll need to enable ARC for your project and then set the -fno-objc-arc on all of your existing files. As you switch your existing files to ARC you'll be able to slowly remove the special-case ARC flag.

from nimbus.

OK. I think I'm convinced that we should go full-tilt with ARC.

Here are some things we need to do in order to make this transition as seamless as possible.

1 - Update the existing code

• I will create a branch on the main repo called arc. [done]
• Anyone who can help migrate existing Nimbus code to ARC should issue a pull request to the arc branch.
• I will merge master into arc periodically so that it stays up-to-date.

2 - Write a guide for non-ARC projects that wish to use Nimbus

• This will be the reference doc we point people to when they want to use Nimbus in a non-ARC project.
• The guide should cover how to enable ARC for a project and how to disable ARC for specific files.
• If there are any gotchas for mixing ARC with non-ARC code, this should be clearly noted.
• Supported iOS SDKs should be clearly noted.
• This document should be added to the Nimbus Wiki.

3 - (optional) Write a script that can migrate a non-ARC project to an ARC-enabled project with all files set with the -fno-objc-arc flag.

• It's possible that this already exists or there is an easier way to do so in Xcode.
• If not, this script should be invocable as follows: arc-migrate <path to xcode project>
• You can likely use the pbxproj.py file if the script is written in Python.

I think we should aim to make Nimbus fully support ARC for the 1.0 release. For 0.9 I'm currently documenting the CSS and Chameleon features in preparation for release. I've also pulled the paging scroll view component from the photos feature into its own separate feature (pagingscrollview). This will allow us to reuse the paging scroll view data source and delegate model throughout Nimbus more effectively (overview and launcher both use a paging scroll view, for example).

Thoughts?

from nimbus.

All sounds good to me :)

Sent from my iPhone

On 20/10/2011, at 2:59 AM, Jeff Verkoeyen [email protected] wrote:

OK. I think I'm convinced that we should go full-tilt with ARC.

Here are some things we need to do in order to make this transition as seamless as possible.

1 - Update the existing code

• I will create a branch on the main repo called arc.
• Anyone who can help migrate existing Nimbus code to ARC should issue a pull request to the arc branch.

2 - Write a guide for non-ARC projects that wish to use Nimbus

• This will be the reference doc we point people to when they want to use Nimbus in a non-ARC project.
• The guide should cover how to enable ARC for a project and how to disable ARC for specific files.
• If there are any gotchas for mixing ARC with non-ARC code, this should be clearly noted.
• Supported iOS SDKs should be clearly noted.

3 - (optional) Write a script that can migrate a non-ARC project to an ARC-enabled project with all files set with the -fno-objc-arc flag.

• It's possible that this already exists or there is an easier way to do so in Xcode.
• If not, this script should be invocable as follows: arc-migrate <path to xcode project>
• You can likely use the pbxproj.py file if the script is written in Python.

I think we should aim to make Nimbus fully support ARC for the 1.0 release. For 0.9 I'm currently documenting the CSS and Chameleon features in preparation for release. I've also pulled the paging scroll view component from the photos feature into its own separate feature (pagingscrollview). This will allow us to reuse the paging scroll view data source and delegate model throughout Nimbus more effectively (overview and launcher both use a paging scroll view, for example).

Thoughts?

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

from nimbus.

@jverkoey Great!

from nimbus.

Sweet... I think this is the right move! Better now than later.

Currently working on a HTML Parser for the AttributedLabel, but I'll put than on hold to get ARC enabled.

It might be helpful to split arc pull-requests by Nimbus module, so we minimize conflicts?

Unless someone else has started I'm going to start with:

• Core
• WebController
• AttributedLabel

from nimbus.

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

from nimbus.

Nimbus Core - Done #81

from nimbus.

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

from nimbus.

Nimbus Web Controller - Done #84

from nimbus.

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

from nimbus.

Nimbus Models and Nimbus Attributed Label - Done - #85

from nimbus.

Nimbus Interapp - Done #86

from nimbus.

Damn dude, you're on fire.

from nimbus.

Nimbus Network Image - Done #87

from nimbus.

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)

from nimbus.

Sorry @NukemHill :)

Nimbus Launcher - Done #88

from nimbus.

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.

from nimbus.

Nimbus Overview - Done #89

from nimbus.

I can't wait for the final commit.

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

:D

from nimbus.

Nimbus Photo & Nimbus Preprocessors - Done #90

from nimbus.

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

from nimbus.

"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.

from nimbus.

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.

from nimbus.

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.

from nimbus.

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

from nimbus.

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)

from nimbus.

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.

from nimbus.

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.

from nimbus.

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 [email protected] 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)

from nimbus.

@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.

from nimbus.

Nimbus fully supports ARC now :) W00t!

from nimbus.

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 [email protected] wrote:

Nimbus fully supports ARC now :) W00t!

---

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

from nimbus.