flovilmart commented 9 years ago

The test [result isKindOfClass:[BFTask class]] is failing sometimes when using tasks created from Swift.

The result of the test is undefined (know bug by apple)

nlutsenko commented 9 years ago

isKindOfClass: should continue to work, since when converted to Swift - BFTask might become a subclass of BFTask aka SwiftBFTask. Which is valid for isKindOfClass:

Any chance you can create a repro PR that showcases the bug?

flovilmart commented 9 years ago

What’s odd now is that with a clean test framework I can’t reproduce the bug… But it repro 100% of times with the current project I’m working on.

I’ll get you screenshots of the current behaviour

On Fri, Jul 31, 2015 at 1:35 PM, Nikita Lutsenko notifications@github.com wrote:

isKindOfClass: should continue to work, since when converted to Swift - BFTask might become a subclass of BFTask aka SwiftBFTask. Which is valid for isKindOfClass:

Any chance you can create a repro PR that showcases the bug?

Reply to this email directly or view it on GitHub: https://github.com/BoltsFramework/Bolts-iOS/issues/111#issuecomment-126763544

flovilmart commented 9 years ago

As you can see the current stack: BOOL isKindOfClass = NO, however, with the NSStringFromClass.. introspection it yields "BFTask"

flovilmart commented 9 years ago

@nlutsenko what do you think? strange, odd and hardly reproductible with another project...

flovilmart commented 9 years ago

BTW, it's with the Bolts framework from the lastest FacebookSDK release

krusek commented 9 years ago

116 includes a repository with a task that doesn't chain properly. I know it's supposed to be an issue with swift, but this has the exact same symptoms, but without swift...maybe it's closer to the actual root issue?

Edit: and it can be fixed in the same way, using NSStringFromClass rather than isKindOfClass:

nlutsenko commented 9 years ago

Great. Many thanks guys for the repro. I'll take a look shortly and will update here.

krusek commented 9 years ago

Actually, I just tried @flovilmart 's fix and it doesn't fix my particular case. What I'd done is just compared the two NSStringFromClass, which fixes his issue, but adds problems with subclasses, but for some reason that branch doesn't fix my example.

flovilmart commented 9 years ago

That's getting even more interesting. Two related issues which don't fix the same way :popcorn:

On Sat, Aug 8, 2015 at 9:22 PM, Korben Rusek notifications@github.com wrote:

Actually, I just tried @flovilmart 's fix and it doesn't fix my particular case. What I'd done is just compared the two NSStringFromClass, which fixes his issue, but adds problems with subclasses, but for some reason that branch doesn't fix my example.

Reply to this email directly or view it on GitHub: https://github.com/BoltsFramework/Bolts-iOS/issues/111#issuecomment-129081059

nlutsenko commented 9 years ago

@krusek I've just ran the test on Xcode 6.4 with the project from https://github.com/krusek/Bolts-error It actually succeeds...

Was there anything specific about your configuration?

nlutsenko commented 9 years ago

I take it back, I can see the issue right now...

nlutsenko commented 9 years ago

Oh, crazy! I am yet once again amazed by how this is implicit, though extremely fragile.

I figured why this happens for you @krusek, which could also be the reason behind the problem with @flovilmart case (haven't seen the source there, so can't confirm).

It's extremely non-obvious, but since you have a dynamic framework that links Bolts.framework via static code, the code from it will be included there. Then you link Bolts.framework to your unit testing target. Since code for BFTask now is both statically linked to KRTaskUnzipper.framework (loaded dynamically) and to Unit Testing Bundle (also loaded dynamically), and the code is the same - there is no compiler error or warning, though these classes are actually different and referenced differently in runtime.

So one is created inside KRTaskUnzipper.framework, but actually used by code from Unit Testing Bundle - which tries to lookup that class in it's runtime (doesn't lookup in dynamic libraries, since it finds it locally), but can't find the same class, so the answer for isKindOfClass: is NO. :D

Does it make sense guys? It's tough to explain, but I can try some other way...

Fix: Remove linking with Bolts.framework from your unit testing bundle. Just tested it locally and it works as expected - it continues on a proper task and the result is NSString instead of BFTask with NSString. Step-by-step to fix the project by @krusek :

Remove KRTaskUnzipperTests from link_with in Podfile
Remove libPods.a from Link phase on KRTaskUnzipperTests
Remove $(inherited) and -l"Bolts" from Other Linker Flags on KRTaskUnzipperTests
Run the tests
???
Profit

I would recommend setting up the Framework via Cocoapods actually, so if you want to use it in a project or write tests against it - you link Bolts.framework only with a single target automatically and don't need to do the fix mentioned above. (we have this done in https://github.com/ParsePlatform/ParseUI-iOS)

Let me know if this helps, guys...

flovilmart commented 9 years ago

Awesome! Thanks for the fix!

I guess that will happen a lot with dynamic libs now that use libs.

If using Carthage and building/testing a framework (that will be distributed via Carthage), should I put my frameworks in framework search path in every case and let the automatic linking do it's magic?

On Sun, Aug 9, 2015 at 3:21 AM, Nikita Lutsenko notifications@github.com wrote:

I take it back, I can see the issue right now...

Reply to this email directly or view it on GitHub: https://github.com/BoltsFramework/Bolts-iOS/issues/111#issuecomment-129129814

krusek commented 9 years ago

it worked, thanks! my actual project has lots of BFTasks created and working properly (and some more pods), odd that only this snippet was borked (and could be pulled out into a separate/standalone project still being borked).

nlutsenko commented 9 years ago

@flovilmart - that works, yup. Another solution would be 'use_frameworks!' flag via Covoapods.

Thanks for raising this guys, and glad I could help.

flovilmart commented 9 years ago

Thanks @nlutsenko!

flovilmart commented 9 years ago

@nlutsenko

For me the resolution si not quite the same.

My project is a Swift framework.

I had Linking + Copy Files ( to Frameworks) for my dependencies (Bolts, Stripe and Realm)

When I removed Bolts from the linking and put it to auto linking the compiler could not build the framework as Bolts is no a dylib.

My solution was:

Remove the Deps. from Copy Bundle Resources
Remove dynamic libs from linking
Keep bolts linking in the framework AND the tests target
Keep the copy files to Frameworks to the tests bundles
Profit

So for my case, the resolution is also related to the build configuration, linking and embedding but solves differently! Cheers!

F.

BoltsFramework / Bolts-ObjC

Issue when chaining BFTasks created from Swift #111

Any chance you can create a repro PR that showcases the bug?

116 includes a repository with a task that doesn't chain properly. I know it's supposed to be an issue with swift, but this has the exact same symptoms, but without swift...maybe it's closer to the actual root issue?

Actually, I just tried @flovilmart 's fix and it doesn't fix my particular case. What I'd done is just compared the two NSStringFromClass, which fixes his issue, but adds problems with subclasses, but for some reason that branch doesn't fix my example.

I take it back, I can see the issue right now...