[Pharo-project] A remote workspace
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, ... Bye Torsten -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
On 13 May 2010 02:22, Torsten Bergmann <astares@gmx.de> 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.
Bye Torsten
-- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
+1 On May 13, 2010, at 2:51 AM, Igor Stasenko wrote:
On 13 May 2010 02:22, Torsten Bergmann <astares@gmx.de> 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.
Bye Torsten
-- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hello, On Thu, May 13, 2010 at 2:51 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 13 May 2010 02:22, Torsten Bergmann <astares@gmx.de> 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. Best regards, Geoffroy
please please please take a look to the conversation we have with had with Eliot Miranda some time ago. His ideas were REALLY cool and interesting. yes, of course, that's much more than what we are saying here, but it is very interesting: http://forum.world.st/Fwd-squeak-dev-Smalltalk-vs-Eclipse-tp1295122p1295122.... Cheers Mariano On Thu, May 13, 2010 at 1:46 PM, Geoffroy Couprie <geo.couprie@gmail.com>wrote:
Hello,
On Thu, May 13, 2010 at 2:51 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 13 May 2010 02:22, Torsten Bergmann <astares@gmx.de> 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.
Best regards,
Geoffroy
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 13 May 2010 14:46, Geoffroy Couprie <geo.couprie@gmail.com> wrote:
Hello,
On Thu, May 13, 2010 at 2:51 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 13 May 2010 02:22, Torsten Bergmann <astares@gmx.de> 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.
Best regards,
Geoffroy
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On 13 May 2010 17:51, Igor Stasenko <siguctua@gmail.com> wrote:
On 13 May 2010 14:46, Geoffroy Couprie <geo.couprie@gmail.com> wrote:
Hello,
On Thu, May 13, 2010 at 2:51 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 13 May 2010 02:22, Torsten Bergmann <astares@gmx.de> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
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 <siguctua@gmail.com> wrote:
On 13 May 2010 14:46, Geoffroy Couprie <geo.couprie@gmail.com> wrote:
Hello,
On Thu, May 13, 2010 at 2:51 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 13 May 2010 02:22, Torsten Bergmann <astares@gmx.de> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Lukas, For GemStone, the split in OB was made such that the #changed messages are sent across the wire with Morphic running on the client (local) side. The Morphic requests for lists were then made back across the wire and so on ... There is still a fair amount of traffic that is probably unnecessary, but I think that with some focussed work, the number of round trips can be reduced even more.... For a particular window like the debugger, it might be possible to tighten things up even more ... for the debugger we'd need to blow the dust off of the OB debugger:) I would be willing to share the work on something like this for Pharo...it's not at the top of my priority list right now, but it is near the top, so I'd be willing to work with someone else to share the load ... Dale ----- "Lukas Renggli" <renggli@gmail.com> wrote: | On 13 May 2010 17:51, Igor Stasenko <siguctua@gmail.com> wrote: | > On 13 May 2010 14:46, Geoffroy Couprie <geo.couprie@gmail.com> | wrote: | >> Hello, | >> | >> On Thu, May 13, 2010 at 2:51 AM, Igor Stasenko <siguctua@gmail.com> | wrote: | >>> On 13 May 2010 02:22, Torsten Bergmann <astares@gmx.de> 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 | >> Pharo-project@lists.gforge.inria.fr | >> | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | > | > | > -- | > Best regards, | > Igor Stasenko AKA sig. | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project@lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | | | -- | Lukas Renggli | www.lukas-renggli.ch | | _______________________________________________ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 13 May 2010 19:06, Lukas Renggli <renggli@gmail.com> wrote:
On 13 May 2010 17:51, Igor Stasenko <siguctua@gmail.com> wrote:
On 13 May 2010 14:46, Geoffroy Couprie <geo.couprie@gmail.com> wrote:
Hello,
On Thu, May 13, 2010 at 2:51 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 13 May 2010 02:22, Torsten Bergmann <astares@gmx.de> 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.
Yes, the model/view separation helps greatly in reducing the complexity for implementing a remote views.
Lukas
Best regards,
Geoffroy
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Because it would be good to have an image without morphic and other and we want to be able to debug it from another place. Stef On May 13, 2010, at 1:22 AM, Torsten Bergmann 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, ...
Bye Torsten
-- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
any takers for a small description on the pharo-book? Stef On May 13, 2010, at 1:22 AM, Torsten Bergmann 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, ...
Bye Torsten
-- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hello, On Thu, May 13, 2010 at 1:22 AM, Torsten Bergmann <astares@gmx.de> 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, ...
Mostly because VNC will not work on buggy connections like the one I had at my school. It sends too much data for slow connections. And you can't send one command (like updating a Monticello package) to a lot of VMs. This idea of a remote workspace is not remote development (although that would be really cool), but remote administration. I have to admit that this is mostly a good excuse for me to poke around the system and learn a lot of things :) Best regards, Geoffroy
participants (7)
-
Dale Henrichs -
Geoffroy Couprie -
Igor Stasenko -
Lukas Renggli -
Mariano Martinez Peck -
Stéphane Ducasse -
Torsten Bergmann