Quantcast

Video demo of using svSocket with data.table

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Video demo of using svSocket with data.table

Matthew Dowle
Dear r-help,
If you haven't already seen this then :
http://www.youtube.com/watch?v=rvT8XThGA8o
The video consists of typing at the console and graphics, there is no audio
or slides. Please press the HD button and maximise.  Its about 8 mins.
Regards, Matthew

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Video demo of using svSocket with data.table

Philippe Grosjean
Hello Matthew and all R-UseRs,

You video demo is very nice. This suggests various uses of svSocket that
I had not think about! The primary goal was to make it:
- flexible (I think it is clear from the demo),
- running in the background while not blocking the CLI (Rgui, R.app, or
the terminal, very clear from your demo too),
- stateful (yes, this is not in your demo, but a client can disconnect
and reconnect and got the same server state it had just before
disconnection, including possibly, partial command send to R server),

Not implemented yet, but planned for the future:
- binary transfer of R objects,
- connection to distant secured server using TSL (of course, distant
connection requires a lot of extra precautions because R is NOT an
Internet-secure language and environment, but that applies to all
client/server R solutions like Rserve or Rpad),
- mirroring of the commands, results and history on the different
clients to make a simple collaborative R session.

The primary use in SciViews is the communication engine between the
client (a code editor, or IDE program like Komodo Edit) and server (R).
Your demo gives an idea on the flexibility one got with it, including
the possibility to inspect and/or change objects while R is running a
long process. Your example of changing the plot in real-time without
interrupting the main server's process is very illustrative. So now,
imagine the debugging flexibility for long running tasks, and/or
combination of svSocket with browser()... But that's another story,
because svSocket does not work nicely with browser() for the moment.

All the best,

Philippe

..............................................<°}))><........
  ) ) ) ) )
( ( ( ( (    Prof. Philippe Grosjean
  ) ) ) ) )
( ( ( ( (    Numerical Ecology of Aquatic Systems
  ) ) ) ) )   Mons-Hainaut University, Belgium
( ( ( ( (
..............................................................

Matthew Dowle wrote:

> Dear r-help,
> If you haven't already seen this then :
> http://www.youtube.com/watch?v=rvT8XThGA8o
> The video consists of typing at the console and graphics, there is no audio
> or slides. Please press the HD button and maximise.  Its about 8 mins.
> Regards, Matthew
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Video demo of using svSocket with data.table

Romain Francois
Hi Philippe,

When Matthew brought this up the first time on this list, there were
several replies to warn about potential problems related to R not being
thread safe, and that this might cause trouble.

Since you were on holidays, we did not get your viewpoint. Could you
elaborate on how you deal with this.

"browser" works off the REPL, so this is unlikely that svSocket can take
advantage of it, since the socket runs on a different loop. or maybe you
can add something that feeds the R main loop, but I'm not sure this is
possible unless you embed R ...

Romain

On 08/21/2009 11:04 AM, Philippe Grosjean wrote:

>
> Hello Matthew and all R-UseRs,
>
> You video demo is very nice. This suggests various uses of svSocket that
> I had not think about! The primary goal was to make it:
> - flexible (I think it is clear from the demo),
> - running in the background while not blocking the CLI (Rgui, R.app, or
> the terminal, very clear from your demo too),
> - stateful (yes, this is not in your demo, but a client can disconnect
> and reconnect and got the same server state it had just before
> disconnection, including possibly, partial command send to R server),
>
> Not implemented yet, but planned for the future:
> - binary transfer of R objects,
> - connection to distant secured server using TSL (of course, distant
> connection requires a lot of extra precautions because R is NOT an
> Internet-secure language and environment, but that applies to all
> client/server R solutions like Rserve or Rpad),
> - mirroring of the commands, results and history on the different
> clients to make a simple collaborative R session.
>
> The primary use in SciViews is the communication engine between the
> client (a code editor, or IDE program like Komodo Edit) and server (R).
> Your demo gives an idea on the flexibility one got with it, including
> the possibility to inspect and/or change objects while R is running a
> long process. Your example of changing the plot in real-time without
> interrupting the main server's process is very illustrative. So now,
> imagine the debugging flexibility for long running tasks, and/or
> combination of svSocket with browser()... But that's another story,
> because svSocket does not work nicely with browser() for the moment.
>
> All the best,
>
> Philippe
>
> ..............................................<°}))><........
> ) ) ) ) )
> ( ( ( ( ( Prof. Philippe Grosjean
> ) ) ) ) )
> ( ( ( ( ( Numerical Ecology of Aquatic Systems
> ) ) ) ) ) Mons-Hainaut University, Belgium
> ( ( ( ( (
> ..............................................................
>
> Matthew Dowle wrote:
>> Dear r-help,
>> If you haven't already seen this then :
>> http://www.youtube.com/watch?v=rvT8XThGA8o
>> The video consists of typing at the console and graphics, there is no
>> audio
>> or slides. Please press the HD button and maximise. Its about 8 mins.
>> Regards, Matthew

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/w33B : Completion for java objects
|- http://tr.im/vzip : Code Snippet : List of CRAN packages
`- http://tr.im/vsK1 : R parser package on CRAN

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Video demo of using svSocket with data.table

Philippe Grosjean
Romain Francois wrote:
> Hi Philippe,
>
> When Matthew brought this up the first time on this list, there were
> several replies to warn about potential problems related to R not being
> thread safe, and that this might cause trouble.

Well, that is true, R is not thread safe. What happens, basically, is
that R clients run in the tcltk event loop. When a client is doing
something, R is locked, processing the client's request before returning
to the main loop. On the contrary, something running in the main loop
can be interrupted pretty much anytime by a client's request. Regarding
different clients, it is first in, first served rule: requests are
processed in the order they appear.

It would be possible to adapt svSocket to delay processing of
(asynchronous only) requests from clients, waiting from flags set by,
either the main loop, or another client. That would be rather easy to do.

Otherwise, every clients and the CLI are working with the same objects
on the same environment (.GlobalEnv, as primary one), but that is a
*feature*! One constraint for designing svSocket is that the behaviour
of R has to be as much as possible identical when a command is run on
the main loop through the CLI, or from within a client.

Of course, you can imagine all sorts of bad interactions, and it is
very, very easy to write a bad-behaving client. The goal is not to write
a client-server architecture, but a multitasking way of manipulating R
by the same end-user (thus, not likely to feed bad code from one side to
destroy what he is doing from another side :-)
Best,

Philippe

> Since you were on holidays, we did not get your viewpoint. Could you
> elaborate on how you deal with this.
>
> "browser" works off the REPL, so this is unlikely that svSocket can take
> advantage of it, since the socket runs on a different loop. or maybe you
> can add something that feeds the R main loop, but I'm not sure this is
> possible unless you embed R ...
>
> Romain
>
> On 08/21/2009 11:04 AM, Philippe Grosjean wrote:
>>
>> Hello Matthew and all R-UseRs,
>>
>> You video demo is very nice. This suggests various uses of svSocket that
>> I had not think about! The primary goal was to make it:
>> - flexible (I think it is clear from the demo),
>> - running in the background while not blocking the CLI (Rgui, R.app, or
>> the terminal, very clear from your demo too),
>> - stateful (yes, this is not in your demo, but a client can disconnect
>> and reconnect and got the same server state it had just before
>> disconnection, including possibly, partial command send to R server),
>>
>> Not implemented yet, but planned for the future:
>> - binary transfer of R objects,
>> - connection to distant secured server using TSL (of course, distant
>> connection requires a lot of extra precautions because R is NOT an
>> Internet-secure language and environment, but that applies to all
>> client/server R solutions like Rserve or Rpad),
>> - mirroring of the commands, results and history on the different
>> clients to make a simple collaborative R session.
>>
>> The primary use in SciViews is the communication engine between the
>> client (a code editor, or IDE program like Komodo Edit) and server (R).
>> Your demo gives an idea on the flexibility one got with it, including
>> the possibility to inspect and/or change objects while R is running a
>> long process. Your example of changing the plot in real-time without
>> interrupting the main server's process is very illustrative. So now,
>> imagine the debugging flexibility for long running tasks, and/or
>> combination of svSocket with browser()... But that's another story,
>> because svSocket does not work nicely with browser() for the moment.
>>
>> All the best,
>>
>> Philippe
>>
>> ..............................................<°}))><........
>> ) ) ) ) )
>> ( ( ( ( ( Prof. Philippe Grosjean
>> ) ) ) ) )
>> ( ( ( ( ( Numerical Ecology of Aquatic Systems
>> ) ) ) ) ) Mons-Hainaut University, Belgium
>> ( ( ( ( (
>> ..............................................................
>>
>> Matthew Dowle wrote:
>>> Dear r-help,
>>> If you haven't already seen this then :
>>> http://www.youtube.com/watch?v=rvT8XThGA8o
>>> The video consists of typing at the console and graphics, there is no
>>> audio
>>> or slides. Please press the HD button and maximise. Its about 8 mins.
>>> Regards, Matthew
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Loading...