Logtalk (Prolog)/Java debugger

[Anton Danilov]

Hello Jan and Paul,

Your opinion is needed to establish that the problem is really existing and if so, what the ways (directions) to solve this?

AFAIK, the Java standard debugger (tracer) is usually implemented via JDI interface.
The Prolog debugger is usually implemented via meta-interpreter.
The Logtalk debugger is based on Prolog.

What could we do to make the composite debugger to work?


Regards,

Anton

[Jan Wielemaker]

On 02/02/17 10:45, Anton Danilov wrote:
> Hello Jan and Paul,
>
> Your opinion is needed to establish that the problem is really existing
> and if so, what the ways (directions) to solve this?

I have very little opinion on that ...

> AFAIK, the Java standard debugger (tracer) is usually implemented via
> JDI interface.
> The Prolog debugger is usually implemented via meta-interpreter.

True, but SWI-Prolog's debugger is based on call-backs from the VM. The
advantage of that is that you can switch from debug to nodebug mode or
the other way around anywhere in the execution. The other advantage is
that the slowdown of using debug mode is not so big.

The price is that it complicates the VM :(

> The Logtalk debugger is based on Prolog.

I leave that to Paulo

Cheers --- Jan

>
> What could we do to make the composite debugger to work?
>
>
> Regards,
>
> Anton
>

> --
> You received this message because you are subscribed to the Google
> Groups "SWI-Prolog" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swi-prolog+...@googlegroups.com
> <mailto:swi-prolog+...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/swi-prolog.
> For more options, visit https://groups.google.com/d/optout.

[Paulo Moura]

Hi Anton,

I assume that the main issue you're interested in is in being able to debug applications that use both Logtalk/Prolog and Java code? Do you want to as seamlessly possible transitioning from one debugger to the other when there's an inter-language call? Can you confirm/clarify?

Cheers,
Paulo

> To unsubscribe from this group and stop receiving emails from it, send an email to swi-prolog+...@googlegroups.com.

> Visit this group at https://groups.google.com/group/swi-prolog.
> For more options, visit https://groups.google.com/d/optout.

-----------------------------------------------------------------
Paulo Moura
Logtalk developer

Email: <mailto:pmo...@logtalk.org>
Web: <http://logtalk.org/>
-----------------------------------------------------------------

[Sergio Castro]

Hi Paulo,

On Thu, Feb 2, 2017 at 5:27 PM, Paulo Moura <pjlm...@gmail.com> wrote:

Hi Anton,

I assume that the main issue you're interested in is in being able to debug applications that use both Logtalk/Prolog and Java code? Do you want to as seamlessly possible transitioning from one debugger to the other when there's an inter-language call?

Yes.

 

Can you confirm/clarify?

with Anton we are brainstorming a bit about the best way to implement a debugger for Java-Prolog applications for the IntelliJ plugin we are developing. I think that to simplify the problem we should start from the assumption that Prolog is started from the JVM and not the other way around.

Maybe the first step could be to extend the plugin with a visual debugger for Logtalk ? And only afterwards focusing on the more complex problem of extending it as a debugger capable of a seamless transition from one language to the other ? Do you see a way to do this ? Is there a debugging library in Logtalk that we could base on, at least for the first part of the problem ?

I do not know if Anton has something else to add.

cheers,

Sergio

 

Cheers,
Paulo

>> an email to swi-prolog+unsubscribe@googlegroups.com
>> <mailto:swi-prolog+unsub...@googlegroups.com>.

>> Visit this group at https://groups.google.com/group/swi-prolog.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "SWI-Prolog" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to swi-prolog+unsubscribe@googlegroups.com.

> Visit this group at https://groups.google.com/group/swi-prolog.
> For more options, visit https://groups.google.com/d/optout.

-----------------------------------------------------------------
Paulo Moura
Logtalk developer

Email: <mailto:pmo...@logtalk.org>
Web:   <http://logtalk.org/>
-----------------------------------------------------------------

--
You received this message because you are subscribed to the Google Groups "SWI-Prolog" group.

To unsubscribe from this group and stop receiving emails from it, send an email to swi-prolog+unsubscribe@googlegroups.com.

[Paulo Moura]

Hi Sergio,

> On 2 Feb 2017, at 20:19, Sergio Castro <serg...@gmail.com> wrote:
>
> Hi Paulo,
>
>
> On Thu, Feb 2, 2017 at 5:27 PM, Paulo Moura <pjlm...@gmail.com> wrote:
> Hi Anton,
>
> I assume that the main issue you're interested in is in being able to debug applications that use both Logtalk/Prolog and Java code? Do you want to as seamlessly possible transitioning from one debugger to the other when there's an inter-language call?
>
> Yes.
>
> Can you confirm/clarify?
>
>
> with Anton we are brainstorming a bit about the best way to implement a debugger for Java-Prolog applications for the IntelliJ plugin we are developing. I think that to simplify the problem we should start from the assumption that Prolog is started from the JVM and not the other way around.
> Maybe the first step could be to extend the plugin with a visual debugger for Logtalk ? And only afterwards focusing on the more complex problem of extending it as a debugger capable of a seamless transition from one language to the other ? Do you see a way to do this ? Is there a debugging library in Logtalk that we could base on, at least for the first part of the problem ?

In Logtalk, by compiling source files in debug mode, all clause heads and goals are wrapped such that trace and debug events are generated during execution and can be handled by e.g. debuggers and profilers, which are regular Logtalk applications. See the documentation of the trace_event/2, debug_handler_provider/1, and debug_handler/2 starting at:

http://logtalk.org/library/logtalk_0.html#trace_event/2

See also the "ports" tool for an example of use of this API for profiling instead of debugging:

http://logtalk.org/library/ports_0.html

> I do not know if Anton has something else to add.

Noted.

> >> an email to swi-prolog+...@googlegroups.com
> >> <mailto:swi-prolog+...@googlegroups.com>.

> >> Visit this group at https://groups.google.com/group/swi-prolog.
> >> For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > You received this message because you are subscribed to the Google Groups "SWI-Prolog" group.

> > To unsubscribe from this group and stop receiving emails from it, send an email to swi-prolog+...@googlegroups.com.

> > Visit this group at https://groups.google.com/group/swi-prolog.
> > For more options, visit https://groups.google.com/d/optout.
>
> -----------------------------------------------------------------
> Paulo Moura
> Logtalk developer
>
> Email: <mailto:pmo...@logtalk.org>
> Web: <http://logtalk.org/>
> -----------------------------------------------------------------
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "SWI-Prolog" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to swi-prolog+...@googlegroups.com.

[Anton Danilov]

Hi,

I'm sorry for delayed post.

I'm trying to write the sketched description of inter-language debugger.
I'd like to clarify some aspects to make sure that we're talking about
the same things.

1. Java application is debugged using JDI i.e. 2 processes for 2 JVMs.
1st JVM debugger (process#1) controls debugging (using GUI)),
2nd (remote) JVM - debuggee(process#2) (that executes the application).

2. Logtalk is compiled to backed Prolog in debug mode.
So we deal with Prolog interpreter executing code with the
clauses wrapped by Logtalk;
Debugger should map this clauses to Logtalk (GUI)
Further, as in Prolog.

3. Prolog uses its own debugger.

4. Inter-language calls.
Correct me if I'm wrong - in debug mode we, in principle, could
switch Logtalk from current backed Prolog to the one
implemented in Java (JIProlog, GNU Prolog for Java, tuProlog).

So, we will have two similar debug units from item 1:
First for java debugging ( process#1,2 )
Second for Java-Prolog ( process#3,4 )

Also, maybe there's the reason to have a look at PDT or something like this,
for an example.



WBR,


Anton

> You received this message because you are subscribed to a topic in the Google Groups "SWI-Prolog" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/swi-prolog/_7CZlBngwIo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to swi-prolog+...@googlegroups.com.

[Paulo Moura]

Hi Anton,

> On 3 Feb 2017, at 16:09, Anton Danilov <anton....@gmail.com> wrote:
>
> Hi,
>
> I'm sorry for delayed post.
>
> I'm trying to write the sketched description of inter-language debugger.
> I'd like to clarify some aspects to make sure that we're talking about
> the same things.
>
> 1. Java application is debugged using JDI i.e. 2 processes for 2 JVMs.
> 1st JVM debugger (process#1) controls debugging (using GUI)),
> 2nd (remote) JVM - debuggee(process#2) (that executes the application).

Ok.

> 2. Logtalk is compiled to backed Prolog in debug mode.
> So we deal with Prolog interpreter executing code with the
> clauses wrapped by Logtalk;

As long as the Logtalk runtime is loaded.

> Debugger should map this clauses to Logtalk (GUI)
> Further, as in Prolog.

Do you mean something like SWI-Prolog graphical debugger where the user can follow where in the sources is the goal currently being executed? That also works to some extent for Logtalk (i.e. you can the SWI-Prolog graphical debugger with Logtalk code).

> 3. Prolog uses its own debugger.
>
> 4. Inter-language calls.
> Correct me if I'm wrong - in debug mode we, in principle, could
> switch Logtalk from current backed Prolog to the one
> implemented in Java (JIProlog, GNU Prolog for Java, tuProlog).

Only for trivial applications if at all. Logtalk does use Prolog as an intermediate language when compiling source files but there are often portability issues if we try to use the generated intermediate Prolog code with a different Prolog backend compiler. Besides, in non-trivial Logtalk applications, proprietary Prolog resources are sometimes used, which will also prevent running the generated code with a different backend.

> So, we will have two similar debug units from item 1:
> First for java debugging ( process#1,2 )
> Second for Java-Prolog ( process#3,4 )

Not for Logtalk/Prolog for the reasons described above. Prolog is far different from Java in that there are multiple implementations with

> Also, maybe there's the reason to have a look at PDT or something like this,
> for an example.

PDT definitely is worth a closer look. It supports both SWI-Prolog and Logtalk.

[Paulo Moura]

* Sorry, accidentally sent a draft of this mail *

Hi Anton,

> On 3 Feb 2017, at 16:09, Anton Danilov <anton....@gmail.com> wrote:
>

> Hi,
>
> I'm sorry for delayed post.
>
> I'm trying to write the sketched description of inter-language debugger.
> I'd like to clarify some aspects to make sure that we're talking about
> the same things.
>
> 1. Java application is debugged using JDI i.e. 2 processes for 2 JVMs.
> 1st JVM debugger (process#1) controls debugging (using GUI)),
> 2nd (remote) JVM - debuggee(process#2) (that executes the application).

Ok.

> 2. Logtalk is compiled to backed Prolog in debug mode.
> So we deal with Prolog interpreter executing code with the
> clauses wrapped by Logtalk;

As long as the Logtalk runtime is loaded.

> Debugger should map this clauses to Logtalk (GUI)
> Further, as in Prolog.

Do you mean something like SWI-Prolog graphical debugger where the user can follow where in the sources is the goal currently being executed? That also works to some extent for Logtalk (i.e. you can the SWI-Prolog graphical debugger with Logtalk code).

> 3. Prolog uses its own debugger.
>
> 4. Inter-language calls.
> Correct me if I'm wrong - in debug mode we, in principle, could
> switch Logtalk from current backed Prolog to the one
> implemented in Java (JIProlog, GNU Prolog for Java, tuProlog).

Only for trivial applications if at all. Logtalk does use Prolog as an intermediate language when compiling source files but there are often portability issues if we try to use the generated intermediate Prolog code with a different Prolog backend compiler. Besides, in non-trivial Logtalk applications, proprietary Prolog resources are sometimes used, which will also prevent running the generated code with a different backend.

> So, we will have two similar debug units from item 1:
> First for java debugging ( process#1,2 )
> Second for Java-Prolog ( process#3,4 )

Not for Logtalk/Prolog for the reasons described above. Prolog is far different from Java in that there are multiple implementations with all sorts of portability issues due in part to limited standardization.

> Also, maybe there's the reason to have a look at PDT or something like this,
> for an example.

PDT definitely is worth a closer look. It supports both SWI-Prolog and Logtalk.

Cheers,
Paulo

[Anton Danilov]

>> Debugger should map this clauses to Logtalk (GUI)
>> Further, as in Prolog.

>Do you mean something like SWI-Prolog graphical debugger where the user can >follow where in the sources is the goal currently being executed? That >also works >to some extent for Logtalk (i.e. you can the SWI-Prolog graphical debugger with >Logtalk code).

I just meant that wrapped clauses or something should be viewed in
debugger in their initial form, as Logtalk user wrote them.

[Sergio Castro]

On Fri, Feb 3, 2017 at 5:09 PM, Anton Danilov <anton....@gmail.com> wrote:

Hi,

I'm sorry for delayed post.

I'm trying to write the sketched description of inter-language debugger.
I'd like to clarify some aspects to make sure that we're talking about
the same things.

1. Java application is debugged using JDI i.e. 2 processes for 2 JVMs.
    1st JVM debugger (process#1) controls debugging  (using GUI)),
    2nd (remote) JVM - debuggee(process#2) (that executes the application).

IntelliJ should provide a convenient abstraction layer for this. Maybe ask a pointer in the IntelliJ forum ?

 

2. Logtalk is compiled to backed Prolog in debug mode.
    So we deal with Prolog interpreter executing code with the
clauses wrapped by Logtalk;
    Debugger should map this clauses to Logtalk (GUI)
    Further, as in Prolog.

Paulo, would you say that a useful debugging tool would be something that will allow us to visualize the full explanation of a proof, while stopping and inspecting on breakpoints defined somehow in clauses ?

Anton, I would definitely take a look to how debugging and/or visualization of proofs is currently done in SWI.

 

3. Prolog uses its own debugger.

4. Inter-language calls.
    Correct me if I'm wrong - in debug mode we, in principle, could
switch Logtalk from current backed Prolog to the one
    implemented in Java (JIProlog, GNU Prolog for Java, tuProlog).

    So, we will have two similar debug units from item 1:
    First for java debugging ( process#1,2 )
    Second for Java-Prolog   ( process#3,4 )

Maybe, but I still think it may be a good idea to start it simple and try to get first a Logtalk debugger in the IntelliJ plugin. Then we could try to expand it to include Java interactions. Or do you think we should tackle the problem from the very beginning as a Prolog/Java debugger ?

 

    Also, maybe there's the reason to have a look at PDT or something like this,

Definitely. I would include Günter Kniesel in this discussion for feedback!

 

cheers,

Sergio

 

>> >> an email to swi-prolog+unsubscribe@googlegroups.com
>> >> <mailto:swi-prolog+unsub...@googlegroups.com>.

>> >> Visit this group at https://groups.google.com/group/swi-prolog.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups "SWI-Prolog" group.

>> > To unsubscribe from this group and stop receiving emails from it, send an email to swi-prolog+unsubscribe@googlegroups.com.

>> > Visit this group at https://groups.google.com/group/swi-prolog.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> -----------------------------------------------------------------
>> Paulo Moura
>> Logtalk developer
>>
>> Email: <mailto:pmo...@logtalk.org>
>> Web:   <http://logtalk.org/>
>> -----------------------------------------------------------------
>>
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "SWI-Prolog" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to swi-prolog+unsubscribe@googlegroups.com.

>> Visit this group at https://groups.google.com/group/swi-prolog.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> -----------------------------------------------------------------
> Paulo Moura
> Logtalk developer
>
> Email: <mailto:pmo...@logtalk.org>
> Web:   <http://logtalk.org/>
> -----------------------------------------------------------------
>
>
>
>
> --

> You received this message because you are subscribed to a topic in the Google Groups "SWI-Prolog" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/swi-prolog/_7CZlBngwIo/unsubscribe.

> To unsubscribe from this group and all its topics, send an email to swi-prolog+unsubscribe@googlegroups.com.

[Anton Danilov]

---------- Forwarded message ----------
From: Anton Danilov <anton....@gmail.com>
Date: 4 February 2017 at 08:38
Subject: Re: [Spam] [SWIPL] Logtalk (Prolog)/Java debugger
To: Sergio Castro <serg...@gmail.com>

 IntelliJ should provide a convenient abstraction layer for this. Maybe ask a pointer in the IntelliJ forum ?

I think JDI is the good abstraction itself but anyways I'd take a look into IntelliJ sources about the (Java) debugger implementation and then I think (if no result) we may to knock to the IntelliJ forum.

Paulo, would you say that a useful debugging tool would be something that will allow us to visualize the full explanation of a proof, while stopping and inspecting on breakpoints defined somehow in clauses ?
Anton, I would definitely take a look to how debugging and/or visualization of proofs is currently done in SWI.

I'll definitely take a look at SWI.

4. Inter-language calls.
    Correct me if I'm wrong - in debug mode we, in principle, could
    switch Logtalk from current backed Prolog to the one
    implemented in Java (JIProlog, GNU Prolog for Java, tuProlog).

    So, we will have two similar debug units from item 1:
    First for java debugging ( process#1,2 )
    Second for Java-Prolog   ( process#3,4 )

Maybe, but I still think it may be a good idea to start it simple and try to get first a Logtalk debugger in the IntelliJ plugin. Then we could try to expand it to include Java interactions. Or do you think we should tackle the problem from the very beginning as a Prolog/Java debugger ?

'Keep it simple' is my idee fixe.
I still hope that my idea (using the Java-based backend Prolog in DEBUG mode) has at least tiny chance to survive. I'll try to finally clarify it today if it is the viable case.
If Paulo will agree then maybe we should maintain two versions of the debugger scheme, the one is Logtalk-based and the another one is mentioned above, until we can to choose the only one.

WBR,

Anton

>> >> <mailto:swi-prolog+unsubscribe@googlegroups.com>.