I could have sworn that I’ve used xcode-kotlin to ...

# touchlab-tools

[Landry Norris]

I could have sworn that I’ve used xcode-kotlin to view UIImages from breakpoints in Kotlin code back in Kotlin 1.6.0, but I can’t seem to get it working now. It just sees the local variables as the runtime’s ObjHeader* now. Is there some step I’m supposed to do to get the konan_lldb.py to run so it can get more info on the types?

[kpgalligan]

Screenshot?

[Landry Norris]

I’ll try to get a screenshot of the ObjHeader* in a minute. I don’t have a screenshot of the UIImage being visible in XCode, but I’ve used it for debugging before, so I know it used to work.

[Landry Norris]

You can see here that it sees both objects as ObjHeader*. The UIImage is created to wrap the CIImage.

[kpgalligan]

Is that debugging a Kotlin file or a Swift file?

[Landry Norris]

This is when debugging a Kotlin file. We don’t have any Swift in this project, since we decided to go the UIKit route instead of SwiftUI for a few technical reasons.

[Landry Norris]

ObjHeader is the native runtime class for all Kotlin objects, to my understanding.

[kpgalligan]

Hmm. OK. ObjHeader isn’t a surprise. That is what the python script looks for and pokes into to get info. Why there’s nothing displayed is a different story. The Kotlin code for that would be good to have. Will need to do some kind of repro (that class, I don’t mean the whole set of code, unless it’s open)

[kpgalligan]

https://github.com/touchlab/xcode-kotlin/blob/main/data/Kotlin.ideplugin/Contents/Resources/konan_lldb.py#L549

[Landry Norris]

This is unfortunately closed source (it’s a work project). I can try to create a repro over the weekend if that would help.

[kpgalligan]

Yeah, that would certainly help.

[kpgalligan]

We check the python with new releases to see if the “official” one has any significant changes. Will need to see if we did that for 1.8 yet. What Kotlin version are you on?

[Landry Norris]

1.7.20

[Landry Norris]

xcode-kotlin is 1.2.1 on my system, and I’ve run sync

[kpgalligan]

I’m going from memory, but I’m 99.9% sure we did a diff check for the 1.7.x versions and nothing has changed. The lldb scripts haven’t changed much for a while, so it’s unlikely that.

[Landry Norris]

Makes sense that xcode-kotlin loads that script itself. I was wondering why it wasn’t letting me import the script from the konan directory.

[kpgalligan]

Well, you can. At different times, the xcode-kotlin script had very specific optimizations, but most of those have been folded into the konan one over the past few years, so I would expect them to function the same at this point, although I’d have to check and see if they’re currently identical. There were some optimizations that got removed over time. It used to be much faster, but I think less accurate in certain cases. We’ve settled into a “good enough” situation for now.

[Landry Norris]

Is there a good way for me to specify a Kotlin version for xcode-kotlin to load the lldb script from, just in case there ever are any major changes between versions? My project is structured as a library, and the main app team is suffering from some tech debt, so updates on my side sometimes break their project.

[kpgalligan]

For the plugin? Good question and no. Not now. It’s been discussed, but since we don’t really know what you’ll be running when starting up, it just defaults to the one file. If there were major changes with a Kotlin update, we could make a way to do it with, say, environment variables or similar.

[kpgalligan]

The lldb script hasn’t changed much in years, though, and the interface into the binary hasn’t changed at all for a long time, so it’s been a low-risk kind of problem.