A remote workspace
Locked
 
|
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 13 May 2010 02:22, Torsten Bergmann <[hidden email]> 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 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Torsten Bergmann
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Torsten Bergmann
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Igor Stasenko
+1
On May 13, 2010, at 2:51 AM, Igor Stasenko wrote: > On 13 May 2010 02:22, Torsten Bergmann <[hidden email]> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Torsten Bergmann
Hello,
On Thu, May 13, 2010 at 1:22 AM, Torsten Bergmann <[hidden email]> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Igor Stasenko
Hello,
On Thu, May 13, 2010 at 2:51 AM, Igor Stasenko <[hidden email]> wrote: > On 13 May 2010 02:22, Torsten Bergmann <[hidden email]> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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.html Cheers Mariano
On Thu, May 13, 2010 at 1:46 PM, Geoffroy Couprie <[hidden email]> wrote: Hello, _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Geoffroy Couprie
On 13 May 2010 14:46, Geoffroy Couprie <[hidden email]> wrote:
> Hello, > > On Thu, May 13, 2010 at 2:51 AM, Igor Stasenko <[hidden email]> wrote: >> On 13 May 2010 02:22, Torsten Bergmann <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 13 May 2010 17:51, Igor Stasenko <[hidden email]> wrote:
> On 13 May 2010 14:46, Geoffroy Couprie <[hidden email]> wrote: >> Hello, >> >> On Thu, May 13, 2010 at 2:51 AM, Igor Stasenko <[hidden email]> wrote: >>> On 13 May 2010 02:22, Torsten Bergmann <[hidden email]> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 <[hidden email]> wrote: >> On 13 May 2010 14:46, Geoffroy Couprie <[hidden email]> wrote: >>> Hello, >>> >>> On Thu, May 13, 2010 at 2:51 AM, Igor Stasenko <[hidden email]> wrote: >>>> On 13 May 2010 02:22, Torsten Bergmann <[hidden email]> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
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" <[hidden email]> wrote: | On 13 May 2010 17:51, Igor Stasenko <[hidden email]> wrote: | > On 13 May 2010 14:46, Geoffroy Couprie <[hidden email]> | wrote: | >> Hello, | >> | >> On Thu, May 13, 2010 at 2:51 AM, Igor Stasenko <[hidden email]> | wrote: | >>> On 13 May 2010 02:22, Torsten Bergmann <[hidden email]> 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 | >> [hidden email] | >> | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | > | > | > -- | > Best regards, | > Igor Stasenko AKA sig. | > | > _______________________________________________ | > Pharo-project mailing list | > [hidden email] | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | | | -- | Lukas Renggli | www.lukas-renggli.ch | | _______________________________________________ | Pharo-project mailing list | [hidden email] | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
On 13 May 2010 19:06, Lukas Renggli <[hidden email]> wrote:
> On 13 May 2010 17:51, Igor Stasenko <[hidden email]> wrote: >> On 13 May 2010 14:46, Geoffroy Couprie <[hidden email]> wrote: >>> Hello, >>> >>> On Thu, May 13, 2010 at 2:51 AM, Igor Stasenko <[hidden email]> wrote: >>>> On 13 May 2010 02:22, Torsten Bergmann <[hidden email]> 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. > for implementing a remote views. > Lukas > > > >> >> >>> Best regards, >>> >>> Geoffroy >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |