Be able to print the contents of let things = realm.objects(Thing.self) from the code sample(I know now there should be nothing in there but this is not relevant to the issue IMO).
I get this warning:
warning: Swift error in module RealmSwift.
Debug info from this module will be unavailable in the debugger.## Steps to Reproduce
What are steps we can follow to reproduce this issue?
I just hit a breakpoint in an IBAction call. An then try po things in the console.
import UIKit
import RealmSwift
class Thing: Object {
dynamic var name = "Thing"
}
class SomeThing: Thing {
dynamic var number = 0
}
class NoThing: Thing {
dynamic var iAmEmpty = true
}
class ViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
let some = SomeThing()
let no = NoThing()
let realm = try! Realm()
try! realm.write {
realm.add(some)
realm.add(no)
}
}
@IBAction func tryStuff(_ sender: Any) {
let realm = try! Realm()
let things = realm.objects(Thing.self)
for thing in things {
print(thing.name)
}
}
}
In the CONTRIBUTING guidelines, you will find a script,
which will help determining these versions.
Realm version: 2.4.2
Xcode version: 8.2.1
iOS/OSX version: iOS 10.2 SImulator / iOS 10.2.1 Device
Dependency manager + version: Carthage 0.18.1
Sorry to hear you're having problems. I tried replicating the problem with the setup you described above and couldn't reproduce it.
Could you try cleaning and rebuilding your project (Xcode's Product menu while holding down Option --> Clean Build Folder), and seeing if you still run into the same problem?
The problem persists. Whatever I try to print if I break at let's say
for thing in things { in tryStuff prints this warning and then does the actual printing of the object.
Is there any chance you can provide us with a sample project that reproduces the issue? Otherwise, I'm inclined to close this as a low-priority ticket, since it's not really interfering with your ability to debug. We've seen similar issues before, but they've all been transient.
Sure. Should I send it to and email or upload it somewhere?
You can send it to [email protected]. Thanks!
You should have and email :)
Thanks for sending us a sample project. It seems to have something to do with Carthage. I'm going to repurpose this ticket to track this problem so we can investigate further. Thanks for reporting it!
Sure! I'd be glad to help make Realm better :)
@ivan-konov actually could you please file a Radar with Apple about this (https://bugreport.apple.com) or a Swift bug (https://bugs.swift.org) since this appears to be an LLDB issue.
Radar submitted.
Awesome, thank you @ivan-konov. Mind sharing the Radar #?
radar# 30646008
Let me know if you think i should add more info or post corrections of my initial wording of the radar.
I also played a bit more with the sample project I sent you. It seems this warning appears only when trying to print Realm objects.
Okay, thank you for sharing that.
@ivan-konov just so you know, radars aren't public, so we can't comment on the wording of your report, and also can't duplicate it or track its progress from Apple's side. There's a site called Open Radar where many developers cross-post their Apple radars to maintain a public repository of them, so you could cross-post yours there and then we could duplicate and keep track.
There you go - rdar://30646008
@jpsim I have another reply on the radar from Apple:
Engineering has provided the following feedback regarding this issue:
In current Swift releases, you鈥檒l have to rebuild all Carthage Swift frameworks locally for debugging to succeed.
In that case I guess you would want to change the Carthage preferences of the project to fetch the code from GitHub and then build locally.
Alright, thanks for following up. This all but confirms that Realm isn't the culprit here, but rather current Carthage and Swift behaviors. Closing.
Sure. Does that mean that there will be upcoming changes on how Realm is installed through Carthage or it will still be distributed as a pre built framework?
We'll continue to distribute Realm.framework and RealmSwift.framework as binaries via Carthage, as Carthage offers a way to force to build from source (--no-use-binaries) for those who want it, while also retaining the advantages of prebuilt frameworks.