Coder Social home page Coder Social logo

enumeratorkit's People

Contributors

aydegee avatar sebastiangrail avatar sharplet avatar taybenlor avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

enumeratorkit's Issues

EXC_BAD_ACCESS when using function style API calls on a nil receiver

This kind of code works just as expected:

@[@1, @2, @3].each(^(id num){
    NSLog(@"%@", num);
});

However, there is a hidden bug in this method:

- (void)doStuffWithArray:(NSArray *)array
{
    array.each(^(id obj){
        NSLog(@"%@", obj);
    });
}

The problems is that sending -each to a nil array returns nil, and then the method tries to invoke the result as a block, causing the EXC_BAD_ACCESS. This, however, works as expected:

- (void)doStuffWithArray:(NSArray *)array
{
    [array each:^(id obj){ // if array is nil, this block will never be called -- yay!
        NSLog(@"%@", obj);
    }];
}

By convention, most Objective-C developers would probably expect this method to fail gracefully if array was nil, but without an explicit guard it's not possible:

- (void)doStuffWithArray:(NSArray *)array
{
    if (array) { // yuck!
        array.each(^(id obj){
            NSLog(@"%@", obj);
        });
    }
}

According to Objective-C conventions, this kind of violates the principle of least surprise, putting the responsibility onto users to add guards such as this in their code. Requiring additional boilerplate like this kind of negates any syntactic sugar benefits you get from the API at this point.

It would be really nice if there was a more object-oriented / dynamic way of invoking blocks, like Ruby's yield or block.call. (Alas, -[block invoke] is private API. Not that it would help in this case.)

Any ideas? I feel like I may need to deprecate the function-style API calls... :(

/cc @alaroldai

.find seems to hang randomly

I don't know what triggers this, but if I call .find repeatedly enough times with good data, it hangs the whole application. I replaced the part in my app with a simple for loop to do the same check, and no crash.

map breaks with NSOrderedSetArrayProxy in EK 1.0.0

Problem with map:

The property is declared as a NSArray, debugging shows that the property is actually backed by a __NSOrderedSetArrayProxy.

Calling map: on this property crashes with following stack trace:

2015-03-17 13:51:13.225 XXXX[38091:696426] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSArray initWithObjects:count:]: method only defined for abstract class.  Define -[__NSOrderedSetArrayProxy initWithObjects:count:]!'
*** First throw call stack:
(
    0   CoreFoundation                      0x000000010f443a75 __exceptionPreprocess + 165
    1   libobjc.A.dylib                     0x000000010f0dcbb7 objc_exception_throw + 45
    2   CoreFoundation                      0x000000010f44b75f __CFRequireConcreteImplementation + 271
    3   CoreFoundation                      0x000000010f436157 -[NSArray initWithObjects:count:] + 39
    4   CoreFoundation                      0x000000010f33af92 -[NSArray initWithArray:range:copyItems:] + 450
    5   XXXX                                0x000000010c5d92e5 -[NSArray(EKEnumerable) initWithEnumerable:] + 261
    6   XXXX                                0x000000010c5d2d46 -[EKEnumerable map:] + 294
    7   XXXX                                0x000000010c4c78f0 -[XXX xxx:] + 384
    8   XXXX                                0x000000010c4d739f -[XXX xxx] + 303
    9   XXXX                                0x000000010c4d7bfd -[XXX xxx:] + 525
    10  UIKit                               0x000000010d8c5a22 -[UIApplication sendAction:to:from:forEvent:] + 75
    11  UIKit                               0x000000010d9cce50 -[UIControl _sendActionsForEvents:withEvent:] + 467
    12  UIKit                               0x000000010d9cc21f -[UIControl touchesEnded:withEvent:] + 522
    13  UIKit                               0x000000010dc73e80 _UIGestureRecognizerUpdate + 9487
    14  UIKit                               0x000000010d90b856 -[UIWindow _sendGesturesForEvent:] + 1041
    15  UIKit                               0x000000010d90c483 -[UIWindow sendEvent:] + 667
    16  UIKit                               0x000000010d8d8fb1 -[UIApplication sendEvent:] + 246
    17  UIKit                               0x000000010d8e6227 _UIApplicationHandleEventFromQueueEvent + 17700
    18  UIKit                               0x000000010d8c123c _UIApplicationHandleEventQueue + 2066
    19  CoreFoundation                      0x000000010f378c91 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
    20  CoreFoundation                      0x000000010f36eb5d __CFRunLoopDoSources0 + 269
    21  CoreFoundation                      0x000000010f36e194 __CFRunLoopRun + 868
    22  CoreFoundation                      0x000000010f36dbc6 CFRunLoopRunSpecific + 470
    23  GraphicsServices                    0x0000000112441a58 GSEventRunModal + 161
    24  UIKit                               0x000000010d8c4580 UIApplicationMain + 1282
    25  FIAT                                0x000000010c49da29 main + 169
    26  libdyld.dylib                       0x000000010f9cd145 start + 1
    27  ???                                 0x0000000000000001 0x0 + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException

Deadlock when repeatedly calling operators implemented in terms of EKEnumerator in a tight loop

EKFiber is implemented in a fairly heavyweight fashion in terms of NSOperationQueue and GCD semaphores. When a lot of fibers are created and completed within a tight loop, eventually a limit is reached where the system deadlocks. There are usually ~65 blocked operations when the deadlock occurs.

I've done a bunch of refactoring of EKFiber and its callers in this branch. Even moving from the current design (one NSOperationQueue per EKFiber) to a much simplified one (a single global NSOperationQueue for all EKFiber instances) doesn't resolve the problem. So the deadlock seems to be caused by the way semaphores are used to suspend execution.

The real solution is likely going to be switching to a lighter-weight concurrency model based on coroutines. Here are some possibilities I've found after some quick research:

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.