Developping debugger Protocol for IPython/Jupyter and notebook.

[Matthias Bussonnier]

Hi all 

There seem to be an effort from Microsoft to contribute a Debug Protocol to Jupyter:

https://github.com/Microsoft/PTVS/issues/774  and [1]

If anyone from the Julia Community that have interest in Debugger would like to pitch in, 

or at least someone who know which member of your community might be interested, and

make them aware of this fact.

I think your input would be really valuable to create something that once more is language agnostic. 

Thanks !

-- 

Matthias for the IPython/Jupyter team, who definitively need 48h/day to do more Julia.

NDLR: Despite that it's Microsoft, we have good experience from this specific team.

[1]: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/jupyter/McQUeg1klro/j8VCuDM9DgAJ

[Matthias Bussonnier]

Sorry for N-tuple post, chome hang and crashed, and relaunched to at least a quadruple post, which make me unconfortable. 

-- 

M

[Tony Kelman]

You can probably delete the duplicates.

This is interesting, but I'm not sure why we would go through PTVS and Jupyter for this? For integration specifically with Visual Studio's debugger we'd probably use the LLDB-VS interface directly. We can't make Jupyter a required dependency to debug Julia code, but it could potentially be valuable as an alternative front-end UI.

[Elliot Saba]

I think the actionable item here is to have input into the process of codifying a general debugging protocol for Jupyter, so that we can have something that works for IJulia as well as Visual Studio.

-E

[Matthias Bussonnier]

Hum, as I am not admin, I did not even try to delete. I'll have a check.

And yes, the goal is not to enable integration with PTVS directly, but
the PTVS team interesting in developing a protocol,
contributing back to Jupyter, which would hopefully magically make
things work in IJulia at some point, or any
pairs of frontend/backend that implement this protocol.

[Matthias Bussonnier]

Well trying to delete was a bad idea,

I tried to delete one of the messages without answers to it, and now
the all thread is gone.
--
M

[Tony Kelman]

What do you mean? I see one or two of the duplicate copies is gone now, but this main copy where the actual conversation is happening is still present.

Is there any past precedent for a language-independent debugging protocol? Maybe the GDB machine interface would be the closest thing? Keno Fischer is the person to ask about what form Julia's debugging capabilities will take, I'm not sure if there's a public place where the design plan is entirely written down yet. We should work on fixing the bus factor of that.

There's also https://github.com/toivoh/Debug.jl which may be worth looking at as a proof of concept, though since that requires code modification to use I suspect the long-term plan will be to deprecate that package once robustly-working replacement functionality is available through LLDB.

[Matthias Bussonnier]

On Sat, Aug 22, 2015 at 11:45 AM, Tony Kelman <to...@kelman.net> wrote:
> What do you mean? I see one or two of the duplicate copies is gone now, but
> this main copy where the actual conversation is happening is still present.

For me in the thread view I only see the first 3 duplicate messages
sent, the rest
of the thread and the message you replied to is gone.Happy if you see
the all thread.
I think I have messed up Google in a way I didn't think imaginable,
but whatever,
it works from mail clients.

> Is there any past precedent for a language-independent debugging protocol?
> Maybe the GDB machine interface would be the closest thing? Keno Fischer is
> the person to ask about what form Julia's debugging capabilities will take,
> I'm not sure if there's a public place where the design plan is entirely
> written down yet. We should work on fixing the bus factor of that.

Ok, thanks I'll try to ping Keno if he does not see this thread.
I also though at chrome debugger tools that can be a separate process
for V8.

> There's also https://github.com/toivoh/Debug.jl which may be worth looking
> at as a proof of concept, though since that requires code modification to
> use I suspect the long-term plan will be to deprecate that package once
> robustly-working replacement functionality is available through LLDB.
>

Thanks for the pointer.
I'll try to add that to the discussion.

Thanks for being that responsive.
--
M