GitHub pull requests and issues

[Travis Tilley]

There are currently two pull requests with no response and 4 issues (two of which are associated pull request issues). Since the pull requests don't seem to have been noticed, is there a better way to make contributions to the project? Is the google code issue tracker still in use and preferred, for example?

[Robbie Hanson]

GitHub is the preferred way, and the pull requests are preferred. It's my fault. I've been really busy with projects, deadlines, and looming shipping dates recently. Not to mention I just moved. Sorry about that.

-Robbie Hanson

On Jan 21, 2012, at 5:07 PM, Travis Tilley wrote:

There are currently two pull requests with no response and 4 issues (two of which are associated pull request issues). Since the pull requests don't seem to have been noticed, is there a better way to make contributions to the project? Is the google code issue tracker still in use and preferred, for example?

--
You received this message because you are subscribed to the Google Groups "CocoaLumberjack" group.
To view this discussion on the web visit https://groups.google.com/d/msg/cocoalumberjack/-/cqjanGHn_40J.
To post to this group, send email to cocoalu...@googlegroups.com.
To unsubscribe from this group, send email to cocoalumberja...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cocoalumberjack?hl=en.

[Travis Tilley]

Life happens. ::shrug:: 

Thanks for the response though! 

Now that you're around and potentially have time to review an idea... any chance you can take a cursory look at my update branch? The first commit is a squashed version of all the progress you've made on the ARC branch (at that time), only without using ARC or removing retain/release/autorelease/dealloc/etc. There are also a few other goodies (well -I- think they are):

• 32bit compatibility (i have a core duo imac. so sue me.)
• replace NSMakeCollectable+autorelease idiom with CFBridgingRelease, which works with ARC, GC, and manual reference counting
• (float)11.0 doesn't necessarily == (float)(10 * 1.1). Direct comparison using == and != have been replaced with C99 macros that are described as being safer.
• make implicit conversions explicit where I see them or the static analyzer finds them (I <3 clang)
• make implicitly atomic properties into explicitly nonatomic ones
• expose queueLogMessage:asynchronously: so that it's easier to extend DDLog (I have two local extensions that allow logging data and images via NSLogger for example)
• fix a comment re: logfile location
• cherry-pick a couple things from other forks, like that variable shadowing warning fix

My need to use the logger in a library that supports manual+GC+32bit makes the current shiny improved version of CocoaLumberjack unusable. I have implemented two separate strategies for using the latest CocoaLumberjack with my library. The first strategy involves a bit of juggling and jiggery pokery to get a binary that supports ARC in 64bit, but uses GC in 32bit. The second strategy involves the update branch I just mentioned, so you already know my goals there. Both work just fine, but it seems like it would be more productive to have a singular branch that can be used with or without ARC. I think this would be easier to achieve in the update branch via macros (as the original retain/release/dealloc still exists there).

If I were to make an additional pull request with macro based cross-compatibility for ARC, GC, and manual reference counting, would you consider it?