nicklockwood / fastcoding Goto Github PK

I see the version in the repo here contains tvos, but not the version in the public trunk. https://github.com/CocoaPods/Specs/blob/master/Specs/FastCoding/3.2.1/FastCoding.podspec.json

Can you please push an update?

When writing a NSDate object to data, there is no alignment written before the NSTimeIntervall, although it is expected to be there when reading a NSDate

Sorry for creating this as an issue, but I wonder whether anyone measured archive size and encoding/decoding performance FastCoding against MsgPack, which seems to be pretty similar in goals and approach.

If not, I will come up with some reference payloads and put it under a test myself.

Hi nick,
I am trying to adopt fastcoding lib. I found if the class property deleted or renamed will get a entire uninitialized object.
The reason I found setValue to a non existed property will raise an exception:

    for (__unsafe_unretained NSString *key in definition->_propertyKeys)
    {
            [object setValue:FCReadObject(decoder) forKey:key];
    }

The quick fix is add a try-catch to prevent the exception.

    for (__unsafe_unretained NSString *key in definition->_propertyKeys)
    {
        @try {
            [object setValue:FCReadObject(decoder) forKey:key];
        }
        @catch (NSException *exception) {

        }
    }

However if there is another better solution?

I've submitted a unit test with pull request #29

I've stepped through the reading and writing functions, and FCReadNSCodedObject is pulling out the correct properties and keys into decoder->_properties but the FC_AUTORELEASE([[NSClassFromString(className) alloc] initWithCoder:decoder]) line still builds an invalid NSColorSpace for some reason. It's not clear to me why it's breaking.

Occasionally get an alignment error on 32 bit devices. This fix works for me:

static id FCReadFloat64(__unsafe_unretained FCNSDecoder* decoder) {
  FC_ALIGN_INPUT(double_t, *decoder->_offset);
  FC_READ_VALUE(uint64_t, *decoder->_offset, decoder->_input, decoder->_total);
  __autoreleasing NSNumber* number = @(*(double_t*)&value);
  return number;
}

I have a very hard to reproduce (but reproducible!) issue where data transmitted from a 64 bit device can't be interpreted by a 32 bit device, and vice versa. Because of how gargantuan the app is (over 250 KLOC) and a couple custom classes are involved, it's very hard to submit a test case. Does anyone have any feedback on the best way to go about debugging this/putting other people in a position to debug this?

The reproducible case involves an empty NSMutableArray inside an NSDictionary inside an NSMutableDictionary, inside an NSMutableDictionary, inside an NSMutableDictionary.

How can i remove an object i saved :

 NSString *path = [[[self class] documentsDirectory]      stringByAppendingPathComponent:@"Establishment.reservation"];
 NSData *data = [FastCoder dataWithRootObject:self];
 [data writeToFile:path atomically:YES];

It would be useful to serialize CCLocation using FastCoding protocol.

I'm running into crashes when using FastCoding to serialize MTLModel objects for storage in YapDatabase. To get you an overview of what's currently happening: We have our object graph ready and set and currently trying out different methods of persisting it to get the best performance / size setup. I dare to say everything works on our side as NSKeyedArchiver, NSJSONSerialization and NSPropertyListSerialization works just fine, but FastCoding fails on archiving one of our object types. I hope you can help us on integrating your library for this task.

The setup that fails: Trying to archive a MTLModel object with several custom subtypes (all subclasses of MTLModel). Doing so results in EXC_BAD_ACCESS deep in the write methods of FastCoding (we're not using -preferFastCoding). Most of the time something bad happens in FCCacheWrittenObject when the incremented count should be set on the _stringCache. If it helps here are all crash points we experienced so far:

object = @"keyNameOfOurClass", cache = coder->_stringCache
static inline NSUInteger FCIndexOfCachedObject(__unsafe_unretained id object, __unsafe_unretained NSMutableDictionary *cache)
{
==>    const void *index = CFDictionaryGetValue((__bridge CFMutableDictionaryRef)cache, (__bridge const void *)object);

object = @"someStringValueOfOneProperty", cache = coder->_stringCache, count = 32
static inline NSUInteger FCCacheWrittenObject(__unsafe_unretained id object, __unsafe_unretained NSMutableDictionary *cache)
{
    NSUInteger count = (NSUInteger)CFDictionaryGetCount((CFMutableDictionaryRef)cache);
==>    CFDictionarySetValue((CFMutableDictionaryRef)cache, (__bridge const void *)(object), (const void *)(count + 1));

Interestingly enough the NSMutableDictionary *cache won't print it's entries just the count of key/value pairs. I thought that CFDictionary are just toll free bridged so I don't know why they won't list their content with po or -description

Another object of ours serializes just fine, that's something that puzzles me. Skimming over the property types won't reveal any dangling pointer like an only assigned not strongly hold string for example. When we try to persist the JSON representation of our failing object with FastCoding the serialization works. But then we have this additional step of building the JSON and we could just use NSJSONSerialization. So I conclude it must have something to do with the non fast version of custom NSCoding objects and/or the combination of Mantle as our choice to implement NSCoding.

I would really love to successfully make use of this promising library, as the result with the serialized JSON by FastCoding was already interesting. I know this is just a broad overview in our problem so don't hesitate to ask away about internals. I'm afraid we only have to exchange code (such as header files) in private as our NDA enforces this.

for example, string, array? thanks.

why does fastcoding fast than nskeyedarchive and nskeyedunarchive

Hi. Didn't find in tests and readme information about support of nested classes.
Is it possible to encode/decode some property, that not is from list of supported items?

Like this:

@interface Model : NSObject <NSCopying>

@property (nonatomic, strong) NSString *text2;
@property (nonatomic, strong) NSString *textNew;
@property (nonatomic, strong) NSArray *array1;
@property (nonatomic, strong) NSArray *array2;
// ->
@property (nonatomic, strong) Model *model;

@end

I drag and drop FastCoding folder and the compiler show 2 errors. See screenshot:
http://take.ms/gUH9J

getting crashes on of FastCoder.m:512

[object setValue:FCReadObject(offset, input, total, cache) forKey:key];

Terminating app due to uncaught exception 'NSUnknownKeyException', reason:
'[<Message 0xa8b2010> setValue:forUndefinedKey:]: this class is not key value
coding-compliant for the key fontSize.'

I do in fact have class Message (that extends BaseModel) with an int property called fontSize.

Say we have been serializing an object with two properties:
@Property a1;
@Property a2;

In a new release: if we remove property a2, the decoding logic should bypass setValue:forKey: for a2 instead of throwing an exception and returning nil for the entire object.

Please pay attention on this demonstration project https://github.com/SiarheiFedartsou/FastCodingBug

So, I'm not sure how much this is a FastCoding issue vs a Swift 2.0 issue, but I figured you'd want to know about it either way:

I've been migrating a project to Swift 2.0, I skipped the first couple of betas but dived into Xcode 7 beta 3, and I've run into an issue where data is being corrupted when passed from Swift into FastCoding.

What appears to be happening is that the caching system is incorrectly identifying cache hits, and writing aliases to the previous entries, when in fact the data is different.

I'm not familiar enough with the internals of FastCoding or Swift to be sure, but I think this may be because Swift is wrapping some of its data structures in temporary objects when they get passed to Obj-C, and those might get recycled within one archiving operation?

This gist shows a minimal repro for the issue (tested with FastCoding version 3.2.1, Swift version 2.0 swiftlang-700.0.45 clang-700.0.57.2)

https://gist.github.com/Canis-UK/2409f367bbef978b43c3

If you create a new iOS Single View Application project in Xcode 7b3, and paste the gist code into its ViewController.swift, it'll attempt to encode and then decode a test dictionary (containing a couple of TestObject instances) when the app is launched, and compare what it decoded against the original.

If you flip the #define to use NSKeyed(Un)Archiver, it's fine -- but with FastCoder the two separate object instances end up with identical values.

The encoder for TestObject writes an array, which gets passed into FastCoder's encodeObject:forKey: as type "Swift._SwiftDeferredNSArray", which I'm guessing is a handle that points to the original Swift array and creates an NSArray on-demand with a reference to the same data; this deferred object then turns up in the cache -- a breakpoint in FCWriteObjectAlias shows it getting hit on the second instance.

(Irritatingly, certain debugging explorations cause the code to work correctly, making this tricky to discover. I'm guessing that poking at the objects in the debugger can cause the deferred objects to be instantiated or something like that, but I'm kinda shooting in the dark on that one. Just giving you a heads up that its a bit of a Heisenbug)

If it turns out to be strictly a Swift bug, I'll cheerfully file a radar :) but other folks using FastCoding should probably be warned!