Re: [Dltk-dev] Re: remote source lookup code comitted

[Andrei Sobolev <haiodo@xxxxxxxxx>]

Hi Jae,
> hello all -
>
>   quick update...
>
>   i've wired up the stripping off a remote working directory and searching
> the local source folders for the remote source first, give it a whirl.
>
>   these are issues i've encountered along the way:
>
> - i believe the RemoteSourceModule needs to use some kind of IStorage
> implementation instead of relying on the ScriptStackFrame like it currently
> does. that should allow it to work with the existing
> ExternalStorageEditorInput implementation and not require any additional
> changes. i'm not sure if a separate implementation here would be better or
> not.
>   
Yes, If you provide IStorage  for remote sources, we could move IStorage
support from ExternalSourceModule and RemoteSourceModule to
AbstractExternalSourceModule, I suppose this will be good.
> - breakpoints don't show up in the editor ruler for source can't be mapped
> into the project workspace. the reason for this that there is no IResource
> object returned from the call to getPartResource(part) inside the job that
> is run to toggle the breakpoint. although, upon further investigation, this
> appears to be a bug for any ISourceModule implementation that uses the
> ExternalSourceEditorInput implementation, so that includes local interpreter
> libraries.
>   
Yes, we know about it.  This problem also block some other
functionality, such as Open Resource by name.

First ideas was to implement IResource interface, but it has some
potential problems, because such resource will not be in workspace.
The second idea was to use Eclipse file system for this, (It used from
DSDP/TM project for example), but I've not looked at it yet.
> - breakpoints *do* appear correctly in files that are mapped into the
> workspace, however the breakpoints don't work. that occurs in the case where
> the remote working directory is not the same as the project root, so when
> the breakpoint gets set, the local resource path is used, which is
> incorrect. one possible solution for this would be to enhance the
> IDbgpSessionInfo interface and add methods to indicate if the session is
> remote and to store the remote working directory. when the breakpoint gets
> set, it could check the session and do the correct thing depending upon if
> it's a remote session or not.
>   
Ok.
> - how to handle differences in remote operating systems (there is that win32
> thing in the ScriptSourceLookupParticipant), encoding, etc? i gave this a
> little though as well and perhaps the best thing would be to include an
> additional tab in the remote launch configuration where these things can be
> specified.
>   
Some options could be included in addition tab.
But I suppose things like source encoding is better to handled inside of
DBGp.
May be it is possible to receive it within 'source' command response, or
specify which encoding should be.
>   there are probably others as well, but these are the ones i've encountered
> thus far. any suggestions on how to proceed would be appreciated, although
> feel free to implement yourself. ;)
>
>
> On 8/29/07, Jae Gangemi <jgangemi@xxxxxxxxx> wrote:
>   
>> hello all -
>>
>>   i just finished checking in the remote source lookup code i have been
>> working on. it's all new code, so the impact shouldn't be too big. i've
>> wired up the tcl and ruby plugins to use the new 'local' source lookup code,
>> but if you encounter problems you can revert the the previous lookup
>> director by changing the lines in the plugin.xml from this:
>>
>>      <extension
>>         point="org.eclipse.debug.core.sourceLocators">
>>         <sourceLocator
>>            class="
>> org.eclipse.dltk.launching.sourcelookup.ScriptSourceLookupDirector "
>>            id="rubySourceLocator"
>>            name="%RubySourceLocator.name" />
>>    </extension>
>>
>>   back to this:
>>
>>    <extension
>>         point="org.eclipse.debug.core.sourceLocators ">
>>         <sourceLocator
>>            class="org.eclipse.dltk.launching.ScriptSourceLookupDirector"
>>            id="rubySourceLocator"
>>            name="%RubySourceLocator.name" />
>>    </extension>
>>
>>     
Thanks Jae.

Please could you  write some tests for source lookups, and enable it by
default.

Also, I suppose we need to make all old code as deprecated.

Thanks, Andrei.
>> ----
>>
>>   as of right now, all source is being looked up remotely, but the launch
>> configuration supports specifying a working directory, but i didn't wire
>> that up in the RemoteScriptSourceLookupParticipant (i left a TODO).
>>
>>   the source is being being retrieve remotely, parsed, and the editor
>> annotations are working, but toggling breakpoints yields no results, so i'm
>> not sure what is missing there.
>>
>>   please let me know if you have quesitons, etc.
>>
>>   oh - one other thing i was thinking, but did not investigate fully. it
>> would be nice to include the remote address information in the editor
>> tooltips. i was thinking that information could just be carried along in the
>> IDbgpSessionInfo object.
>>
>> --
>> -jae
>>     
>
>
>
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> dltk-dev mailing list
> dltk-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dltk-dev
>