Home > Archive > Smalltalk > October 2004 > VW Remote Tools
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Nevin Pratt 2004-10-16, 8:56 pm |
| Has anyone achieved any level of success in using remote tools via
Opentalk? Here is a (partial) post from Eliot back in 2003:
> Our architectural direction is towards a small core base image and
> abandoning stripping, except for special cases. Opentalk was started to
> provide the tools architecture for this. I'm not going to reiterate
> that here, but the no-stripping part of Opentalk is about remote tools
> to make it easier to derive the minimal base image.
So, using image-to-image communication via Opentalk, has anybody
successfully used developer tools in one image to debug/develop remotely
within a different image?
Nevin
| |
| Volker Zink 2004-10-18, 4:01 am |
| I tried the remote debugger. Using two headful images on the same
machine it seems to work. But when i tried it between a headful und a
headless image on different computer it does not work (i want to debug
the headless image, but when an error occurs the headless image just
dies silently).
Volker
Nevin Pratt schrieb:
> Has anyone achieved any level of success in using remote tools via
> Opentalk? Here is a (partial) post from Eliot back in 2003:
>
>
>
> So, using image-to-image communication via Opentalk, has anybody
> successfully used developer tools in one image to debug/develop remotely
> within a different image?
>
> Nevin
| |
|
| Out of curiosity, did you strip the headless image with
RuntimePackager? My question really is what is it that one has to do
differently when stripping an image so that the remote debugging is
supported.
thanks
-Charles
Volker Zink <Volker.Zink@porabo.ch> wrote in message news:<41737498$1@news.totallyobjects.com>...[color=darkred]
> I tried the remote debugger. Using two headful images on the same
> machine it seems to work. But when i tried it between a headful und a
> headless image on different computer it does not work (i want to debug
> the headless image, but when an error occurs the headless image just
> dies silently).
>
> Volker
>
> Nevin Pratt schrieb:
| |
| Volker Zink 2004-10-19, 3:59 pm |
| I did strip the headless image with RuntimePackager. I loaded the parcel
'Opentalk-Debugger-Remote-Target' and had to define the class
DebuggerService as a class to keep, but then the RuntimePackager had no
more complaints. Maybe i missed something the RemoteDebuggerService
needs, but i have no clue what (the headless image normally writes the
stack into a log file if an error occurs, but in this case the image
just dies and writes nothing into the log file).
I have written a method which i use to enable/disable remote debugging
to a specific computer (IP-Number). Enabling remote debugging generates
no error. Only when i remotely trigger an error which the remote
debugger should show, the image dies.
Volker
OCIT wrote:[color=darkred]
> Out of curiosity, did you strip the headless image with
> RuntimePackager? My question really is what is it that one has to do
> differently when stripping an image so that the remote debugging is
> supported.
>
> thanks
>
> -Charles
>
> Volker Zink <Volker.Zink@porabo.ch> wrote in message news:<41737498$1@news.totallyobjects.com>...
>
| |
| Martin Kobetic 2004-10-19, 3:59 pm |
| I wonder if parts of Opentalk were stripped out. Can you try again
making sure that's not the case ?
Volker Zink wrote:
> I did strip the headless image with RuntimePackager. I loaded the parcel
> 'Opentalk-Debugger-Remote-Target' and had to define the class
> DebuggerService as a class to keep, but then the RuntimePackager had no
> more complaints. Maybe i missed something the RemoteDebuggerService
> needs, but i have no clue what (the headless image normally writes the
> stack into a log file if an error occurs, but in this case the image
> just dies and writes nothing into the log file).
>
> I have written a method which i use to enable/disable remote debugging
> to a specific computer (IP-Number). Enabling remote debugging generates
> no error. Only when i remotely trigger an error which the remote
> debugger should show, the image dies.
>
> Volker
--
Martin Kobetic, Cincom Smalltalk Development,
http://www.cincom.com/smalltalk
| |
| Volker Zink 2004-10-19, 3:59 pm |
| I keep the whole namespace Opentalk (all classes and methods; i checked
the last runtime building image).
Volker
Martin Kobetic wrote:
> I wonder if parts of Opentalk were stripped out. Can you try again
> making sure that's not the case ?
>
> Volker Zink wrote:
>
>
>
| |
|
| If it works in a non-stripped image then it would seem that something
is indeed being stripped out necessary for Opentalk, maybe loading the
Opentalk related parcels at tuntime is an option.
-Charles
Volker Zink <Volker.Zink@porabo.ch> wrote in message news:<417532e9@news.totallyobjects.com>...[color=darkred]
> I keep the whole namespace Opentalk (all classes and methods; i checked
> the last runtime building image).
>
> Volker
>
> Martin Kobetic wrote:
>
| |
| Martin Kobetic 2004-10-20, 4:07 pm |
| Well, another thing might be stripped out pieces of PDP or something
such. To be honest we have yet to do some serious testing with stripped
images, but remote debugging those is definitely one of our goals.
Also, from time to time changes in the base debugger break the remote
one. We've had such an issue with the version released in 7.2.
Similarly, if you're using one of the recent builds of 7.3 I've just
fixed another such issue there. The patches are attached if you feel
like trying them out. Note that the 'processCommandLine' fix requires a
change to the postLoad block for the 'target' parcel.
It should read like this:
[:package | Opentalk.RemoteDebuggerService processCommandLine ]
OCIT wrote:
> If it works in a non-stripped image then it would seem that something
> is indeed being stripped out necessary for Opentalk, maybe loading the
> Opentalk related parcels at tuntime is an option.
>
> -Charles
--
Martin Kobetic, Cincom Smalltalk Development,
http://www.cincom.com/smalltalk
| |
| Volker Zink 2004-10-29, 3:58 am |
| I did some more tests. If i keep almost all of the namespaces Kernel and
Tools (i.e. the class 'RemoteString' was stripped out) the image does
not die any more, but remote debugging does still not work. Instead i
get two stack dumps when triggering a job which does try to access a
file 'L:\wb\testLaufwerk.txt' which is not accessible. The first stack
is somewhat strange (is this one related to the remote debugger?):
HandleRegistry>>evaluateWithFullProtection:
Receiver: a HandleRegistry protected by a RecursionLock with (#[96 108
242 0]->an active SocketAccessor #[48 2 243 0]->an active SocketAccessor
#[0 138 242 0]->an active SocketAccessor #[72 175 247 0]->an active
PCDiskFileAccessor #[184 137 242 0]->an active PCDiskFileAccessor #[248
104 47 0]->an active PCDiskFileAccessor )
Arg1: BlockClosure [] in HandleRegistry>>registerValueOf:
HandleRegistry>>registerValueOf:
Receiver: a HandleRegistry protected by a RecursionLock with (#[96 108
242 0]->an active SocketAccessor #[48 2 243 0]->an active SocketAccessor
#[0 138 242 0]->an active SocketAccessor #[72 175 247 0]->an active
PCDiskFileAccessor #[184 137 242 0]->an active PCDiskFileAccessor #[248
104 47 0]->an active PCDiskFileAccessor )
Arg1: BlockClosure [] in OSHandle class>>handleValue:
PCDiskFileAccessor class(OSHandle class)>>handleValue:
Receiver: PCDiskFileAccessor
Arg1: BlockClosure [] in IOAccessor
class>>openFileNamed:direction:creation:
IOAccessor class>>openFileNamed:direction:creation:
Receiver: IOAccessor
Arg1: 'L:\wb\testLaufwerk.txt'
Arg2: 1
Arg3: 3
....
The second is an expected OsInaccessibleError.
Volker
PS: Maybe i should wait for VW 7.3 :-)
Martin Kobetic wrote:[color=darkred]
> Well, another thing might be stripped out pieces of PDP or something
> such. To be honest we have yet to do some serious testing with stripped
> images, but remote debugging those is definitely one of our goals.
>
> Also, from time to time changes in the base debugger break the remote
> one. We've had such an issue with the version released in 7.2.
> Similarly, if you're using one of the recent builds of 7.3 I've just
> fixed another such issue there. The patches are attached if you feel
> like trying them out. Note that the 'processCommandLine' fix requires a
> change to the postLoad block for the 'target' parcel.
> It should read like this:
>
> [:package | Opentalk.RemoteDebuggerService processCommandLine ]
>
>
> OCIT wrote:
>
|
|
|
|
|