I expect this to be an unusual question, but maybe someone can help me nonetheless: I have IntelliJ attached to the process that contains the Kotlin Kernel. Where would I need to set a breakpoint so all the locally available variables inside the Kotlin Jupyter Notebook with the IntelliJ debugger view? I find the latter vastly superior for inspecting objects, and traversing their referencing objects etc, but the Jupyter Notebook is much more pleasant to actually write code in to test out more complicated expressions

I think it won't be possible. Kotlin kernel generate the code on-flight and the compiled code does not exist before you start the program. Why don'y you start your code as a kts script or code with a regular

main

entry point?

My Kotlin Kernel is embedded into another application and I am using the Jupyter Notebook/Console to interact with that application. This application is the one I have the debugger attached to.

Personally I prefer Idea files with

main

methods to notebook. The only advantage of a notebook is the graphical output. I think it will be possible to do that directly in IDEA in futute. And if not, it is not hard to do detached data viewer.

This setup is basically a replacement for running the application under IntelliJ and using the integrated Jython shell of the application.

Sadly, I do not answer for you. You probably need to go into JVM debug server logic for that.

I didn't expect this to be something that is even guaranteed to work.

Perhaps @Ilya Muradyan can help?

@Maria Khalusova This have nothing to do with the NoteBook API, it is about general JVM debugging. Probably better to ask IDEA debugger specialists.

@altavir Sure, and Ilya might be able to find the right person within IDEA team to discuss this and perhaps offer some suggestions 🙂

It's not really important, I was just curious if there was some trick. The

KotlinContext

object was basically the start and putting a watch on it to give me list of variables solves most of my problem. I just need to manually navigate to the stack frame but that is easy as long as it is marked

Yes, as @altavir mentioned, every code snippet is an instance of new class, but the properties (KProperty objects) of these instances are collected into repl's KotlinContext, and you may track it to watch variables. As you've mentioned, there's only one instance of KotlinContext in production, so the first decision that comes into my head is that in your fork you may make it a singleton, so that you'll only need to watch globally available expression

KotlinContext.INSTANCE