Switch branches/tags
Nothing to show
Commits on Apr 28, 2011
  1. Update README

    mdippery committed Apr 28, 2011
Commits on Feb 1, 2011
Commits on Jan 31, 2011
  1. Fix a bug in `inject:into`.

    mdippery committed Jan 31, 2011
  2. Remove debug driver code

    mdippery committed Jan 31, 2011
    I figured out how to debug unit tests, so I don't need this anymore.
    Unfortunately, it seems like the custom executable I set up for the
    unit test debugging doesn't get added to the Xcode project...
  3. Rename `immutableCopy` to `freeze`

    mdippery committed Jan 31, 2011
    The method name implied that it returned an object with a +1 retain count,
    but really the copy was autoreleased.
  4. Replace common macros with methods

    mdippery committed Jan 31, 2011
    This might be a bit "uglier" than before in some ways, but most of the
    ugliness won't be exposed to the user. The only problem I have is with
    the method `setObject:forValue`, which seems likely to run into
    conflicts (and sounds a lot like an existing method in the Foundation
    framework). I may change the name of this method eventually.
  5. Handle NSMutableDictionary accumulators

    mdippery committed Jan 18, 2011
    This will be necessary when functionality for NSDictionary is
    implemented. It makes the code a bit ugly and convoluted, but I think
    this is okay since the code in Common.{h,m} is not for public
    consumption anyway.
Commits on Jan 25, 2011
  1. Expose the IMMUTABLE_COPY macro

    mdippery committed Jan 25, 2011
  2. Use a goto statement to simplify a code path

    mdippery committed Jan 25, 2011
    I know, I know, gotos are evil...but this is easier to read, damn it.
Commits on Jan 24, 2011
  1. Remove parentheses from project filename

    mdippery committed Jan 24, 2011
    I hate parentheses.
Commits on Jan 18, 2011
  1. Build static library for iOS 4.2

    mdippery committed Jan 18, 2011
    The library is built for both iPhone and iPad.
    As expected, no changes were required to compile for iOS. However, I had
    to make a separate project file; it is my understanding that the same
    project file cannot contain targets for both Mac OS X and iOS.
    Disappointing, because each project file will now have to be kept in sync
    as files are added and deleted, but that's how it is.
    I haven't actually tested this in any iOS apps, but again, the library
    is pretty simple so it should work fine.
Commits on Jan 17, 2011
  1. Use build number for compatibility information

    mdippery committed Jan 17, 2011
    According to the Apple docs, "the current version number tracks
    individual builds of your framework and is mostly for internal use
    by your team. [...] When you make certain kinds of changes to public
    interfaces, you should set the compatibility version to match the
    current version of your framework." So I'm going to use the
    $CURRENT_PROJECT_VERSION to record compatibility information for the
    library; I'll increment this number whenever I create a build for
    internal or external testing or external consumption. This will be
    maintained separately from the "marketing" version of the library,
    which will be the more familiar "1.0", "1.0.1", etc.
  2. Use the framework version in the library filename

    mdippery committed Jan 17, 2011
    This will output a library named, e.g., "libCollections.A.dylib"
    instead of "libCollections.0.1.0.dylib". I thought putting the
    entire current library version in the filename made it a bit cumbersome.
    Also, why put the entire version name in the filename, when only the
    compatibility version really matters?
    The downside is that there are now basically two compatibility versions:
    $DYLIB_COMPATIBILITY_VERSION, which is actually used by the linker to
    provide versioning information; and $FRAMEWORK_VERSION, which is used
    in the output file name. No big deal, though; I'll just have to
    increment both whenever I change the public interface of the library.
  3. Include the dylib's version number in the filename

    mdippery committed Jan 17, 2011
    The current library version number is included, so a library named
    "libCollections.0.1.0.dylib" is created. There doesn't seem to be a
    standard way to put version numbers in the libraries. Some use this
    style; others use something like "libAwesome.1.dylib",
    "libAwesome.2.dylib"; and others use "libAwesome.A.dylib",
    "libAwesome.B.dylib", etc. I might change the style before release,
    but it's not something I'm going to worry about right now.
  4. Don't implement methods that rely on ordering in NSSet

    mdippery committed Jan 17, 2011
    NSSet is an unordered collection, but detect:, dropWhile:, and
    takeWhile: require (or at least imply) that the underlying collection
    is ordered. They don't really make sense for NSSet, so I am removing
  5. Create a simple debug program

    mdippery committed Jan 17, 2011
    The problem with the Objective-C unit test framework is that it doesn't
    offer a way to enter gdb in order to root out failures. This simple
    program will allow that.
  6. Set library's installation directory as '@rpath'

    mdippery committed Jan 17, 2011
    @rpath is more flexible, although it will require the consuming
    application to set the runpath search directories appropriately.
  7. Refactor implementation into standalone functions

    mdippery committed Jan 16, 2011
    This will make it easier to add the same functionality for NSSet and
    Some of the unit tests are broken; I'll have to fix those before I
    merge this back into master.
Commits on Jan 16, 2011
  1. Support Mac OS X 10.5

    mdippery committed Jan 16, 2011
    I was only using one 10.6-only method (that I could find, at least).
    Supporting 10.5 also required a change from clang to llvm-gcc (clang
    isn't supported on Leopard).
Commits on Jan 15, 2011
  1. Remove plus sign from filenames

    mdippery committed Jan 15, 2011
    The name without the plus sign is a bit more aesthetically pleasing.
Commits on Jan 14, 2011
  1. Update the README

    mdippery committed Jan 14, 2011
    I want to stress that this is an early in-development version and
    (probably) not suitable for production use. That said, it works pretty
    well as far as I can tell.
    I also wanted to head off complaints that there's no iOS version (yet).
  2. Change install name of dynamic library

    mdippery committed Jan 14, 2011
    I am assuming that the library will normally be shipped with an
    application, in the bundle's "Frameworks" directory.