Re: [Dltk-dev] Welcome Johan Compagner as a new technology.dltk Committe

["Jae Gangemi" <jgangemi@xxxxxxxxx>]

  hrm - i didn't have to do any of that to get remote perl debugging up
and running. as soon as you spawn a remote launch configuration, that
should kick off the dbgp service to start listening for incoming
connections. as long as you set the 'idekey' property in the remote
launch config to be whatever you used on the remote side, it should just connect.

  of course, i could be missing something, or perhaps there was some other change that has occurred as of late (the day job has been keeping me pretty busy, so i'm playing some catch-up with the recent set of changes) that i haven't accounted for yet.

On Tue, Apr 22, 2008 at 11:40 AM, Johan Compagner <jcompagner@xxxxxxxxx> wrote:

No it works, only i have to handle disconnects and so on a bit more gracefull.
And launch configurations and other settings like port has to be better handed thats now pretty much hardcoded

But I remote debug a Rhino instance that is already running.
So instead of starting an instance i connect to it. I use the RemoteDebuggingEngineRunner that already is in the code base

public class ServoyDebuggableEngineFactory implements IInterpreterRunnerFactory
{

    public ServoyDebuggableEngineFactory()
    {
    }

    public IInterpreterRunner createRunner(IInterpreterInstall install)
    {
        return new RemoteDebuggingEngineRunner(install)
        {
            @Override
            protected String getDebugPreferenceQualifier()
            {
                return "servoy";
            }

        };
    }

}

But that didnt have any IDbgpService that it could use because the current one is purely there for starting a none remote one.
So what i did was created a class:

public class RemoteDbgpService implements IDbgpService,
        IDbgpTerminationListener, IDbgpServerListener

that can connect to an instance.

So the RemoteDebuggingEngine does this:

    protected IDbgpService getDbgpService()
    {
        return DLTKDebugPlugin.getDefault().getRemoteDbgpService();
    }

And apart from some disconnect issues that i have to handle a bit better (but on the client side not the eclipse debugger)
and the ports/addresses configuration stuff it works for us.

johan

On Tue, Apr 22, 2008 at 5:32 PM, Jae Gangemi <jgangemi@xxxxxxxxx> wrote:

  i'd like to hear about your remote debugging work - what do you have working at this point in time? what doesn't work for you?

On Tue, Apr 22, 2008 at 11:30 AM, Johan Compagner <jcompagner@xxxxxxxxx> wrote:

Hi guys (and girls if there are any..;),

thx for letting me in!
I will concentrate my efforts most of the time on the _javascript_ side but sometimes it crosses over i guess to the more general side of dltk.

I have currently loads of patches standing out, the things that are purely _javascript_ and easy bug fixes or small improvements i will checkin
the coming days. For others i guess i will first start a discussion if it is meant this way. For example my implementation for Remote Debugging..
(there is some support, some interfaces but not a implementation yet)

Johan

On Tue, Apr 22, 2008 at 4:50 PM, portal on behalf of Andrey Platov <andrey@xxxxxxxxx> wrote:

technology.dltk Committers,
This automatically generated message marks the completion of all the legal
paperwork and webmaster provisioning for Johan Compagner. Johan Compagner
is a new full Committer on the technology.dltk project.

Welcome!
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev

_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev

--
-jae
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev

_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev

-- 
-jae