-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SRKObjects not viewable / hackable in lldb debugger #111
Comments
Is this an XCode 10 thing? * just need to know where to focus energy. |
No I've had this in XCode 9 too. I remember not having this problem with the first cut of SharkORM I used a couple of years ago.. |
Okay, so here is a pure swift implementation and I can po the objects. Can you take a look at it and see if there is anything/ obviously different? or indeed if you yourself still cannot see the detail. |
Right, that is working as expected on my setup too. In my project all Shark objects are Obj-C implemented, although the project is mixed Swift / Obj-C.. I'll try to investigate this some more creating new projects. |
Ok so I played with a couple of different new projects, and in the end I can reproduce this error doing the following:
It wasn't necessary to create a mixed Swift / ObjC project in the end (although those also fail on me in the same way.) |
More investigation: I found out that actually, in those new projects I mentioned, I was getting this error because I'd neglected to open the database in AppDelegate. Opening the database cleared out the problems there. But that's odd, because I'm certainly opening the database in my original project. I went back to my original project, created an empty Swift Shark object for the heck of it, and found out that I could debug that object. I can also now debug those original Obj-C Shark objects, just by having a Swift Shark object in my project! Kind of weird.. It's not quite completely fixed my problem, i.e.:
returns
While
returns the correct value. And now I'm not sure how to reproduce this... |
That is so odd. I don't think Swift should have anything to do with it. But it could be a lifecycle thing. Swift objects potentially get initialised earlier than obj-c if they are defined and used prior to starting the ORM. When used as an |
Really odd, no? Quick question - are all the old swift issues ironed out these days? In other words, would you recommend I port across my Obj-C implementations to Swift ones and be done with it? |
Humm, it's not exactly perfect because you need to still use obj-c compatible properties, but we use it in all our apps and it works fine. The only bug which still exists is the setting of property values in the init() func, which then gets unset afterwards. It's still present in Swift 4.x, and the radar has just been marked as really complicated to fix! |
But we catered for that with the initWithProperties method instead. |
Small update, just an FYI really, I recoded one of my shark subclasses into swift to see what would happen, and it didn't change the behaviour - the debugger output is still not quite right. And in certain places, despite that weird hack I mentioned above, I've found I am still getting the |
Pausing on breakpoints in Xcode, I can't do anything useful with any SRKObject subclasses any longer.
e.g. using
p mPerson
,po mPerson
, or anything likep mPerson.name
(where mPerson is a Person SRKObject data class) gives:No lldb expressions work at all on any part of the SRKObject objects, they seem to get immediately hung up on this issue. And I've no idea where the "here" is that the second line refers to...
The text was updated successfully, but these errors were encountered: