I would really like to have that functionality. Stef
On May 13, 2010, at 6:06 PM, Lukas Renggli wrote: > On 13 May 2010 17:51, Igor Stasenko <[email protected]> wrote: >> On 13 May 2010 14:46, Geoffroy Couprie <[email protected]> wrote: >>> Hello, >>> >>> On Thu, May 13, 2010 at 2:51 AM, Igor Stasenko <[email protected]> wrote: >>>> On 13 May 2010 02:22, Torsten Bergmann <[email protected]> wrote: >>>>> Why dont you use the VNC facility of Pharo which is >>>>> typically used to administrate Seaside images: >>>>> >>>>> http://book.seaside.st/book/advanced/deployment/maintaining/vnc >>>>> >>>>> Just install the RFB package, configure and use a normal >>>>> VNC client to remotely use and drive the image. >>>>> >>>>> So you have workspaces, debuggers, you name it, ... >>>>> >>>> Remote debugging is a must. Headless, no UI. >>>> Remote debugger can create own UI at debugger side, while debugged >>>> image could be quite small, >>>> contain no UI, Morphic & rest of stuff. >>>> >>>> Think of debugging a kernel images, where you can't afford having a >>>> lot of stuff loaded, not saying about RFB. >>>> >>> >>> I like the idea of a headless image :) >>> >>> I don't know how hard it would be to add a remote debugger. Could it >>> be done by catching the exceptions on the remote side and sending >>> commands like walking the stack from the local side? >>> >>> For remote administration, it would be fairly easy to have a local UI >>> sending commands periodically to remote VMs to ask for status, execute >>> some code, etc. >>> >> >> It should be a relatively easy. >> A debuggee should need is to encapsulate the objects by some ids, >> and then transfer these objects printstrings over a connection, so >> debugger could show them. >> The debugger consists of a number of panes - 2 inspectors and code. >> So, if you implement a remote inspector, you'll have about 40% of job done. > > You could also implement a new view for OB: meaning the model of OB > runs on the server while the view is on the client. AFAIK this is what > GemStone does for its tools in Pharo. I guess that approach could be > adapted to also work between two Pharo images. > > Lukas > > > >> >> >>> Best regards, >>> >>> Geoffroy >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
